Почему одного удачного ответа недостаточно
Промпт для ИИ в бизнесе может превращать обращение клиента в сводку для менеджера. На аккуратном примере расплывчатая инструкция иногда выглядит рабочей: все сведения уже есть, и модели незачем выбирать между фактом и предположением. Но такой ответ мало говорит о поведении промпта, когда сообщение неполное или содержит конфликт.
Условная заявка на поставку содержит товар и желаемую дату, но не объём. Если модель впишет правдоподобное число, сводка станет гладкой, но бесполезной для следующего шага. Если отметит пробел, менеджер поймёт, что запросить. Здесь качество — не красота формулировки, а сохранение исходных фактов и видимость нерешённого вопроса.
Что показывает сравнение трёх входов
Три входа проверяют разные свойства. Обычный служит контрольной точкой: сохраняет ли промпт факты и форму? Неполный показывает, замечает ли он отсутствие данных. Противоречивый выявляет, удерживается ли модель от самовольного выбора. Заранее запишите критерии для каждого результата: так оценка не будет зависеть от того, насколько убедительно звучит ответ.
Чтобы критерии были наблюдаемыми, задайте ожидаемый формат сводки до теста: например, отдельные поля «факт», «не хватает» и «требует решения». Тогда проверяющий может отметить не только ошибочное значение, но и место, где потерялся важный статус. Это особенно полезно, когда ответ передают дальше без исходного письма.
| Вход | Что проверяется | Приемлемый результат |
|---|---|---|
| Обычный: товар, объём и дата указаны | Точность и формат | Данные переданы без добавлений |
| Неполный: объём не указан | Обработка пропуска | Пробел отмечен, значение не придумано |
| Противоречивый: в письме две даты | Обработка конфликта | Обе даты показаны, выбор не сделан за человека |
Как установить источник ошибки
Для подготовки повторяемых тестовых входов пригодится карточка рабочего промпта с примерами.
- Измените только вход
Для заявки без объёма добавьте недостающее значение, оставив промпт прежним. Если результат стал точным, вероятная причина — полнота исходных данных; если нет, проверьте, задаёт ли инструкция правило для пропусков.
- Затем проверьте правило
При двух датах формулировка «выбери подходящую» поручает модели решить без основания. Точнее потребовать перечислить обе даты и обозначить, что выбор остаётся ответственному сотруднику.
- Сравните узкую правку
До изменения сводка называет одну дату; после показывает обе и помечает конфликт. Поскольку изменено одно правило, можно оценить его влияние, не переписывая весь промпт.
Как зафиксировать решение о приёмке
Запись проверки должна позволять коллеге повторить сравнение: сохраните версию промпта, входы, критерии, ответы, обнаруженные дефекты и решение — принять, исправить или передать неоднозначность человеку. При сравнении версий оставляйте входы и критерии неизменными, меняя только инструкцию. Так проще установить, какое именно изменение повлияло на результат.
В итоговой записи кратко укажите границы проверки: например, «добавлено правило не заполнять отсутствующий объём; проверены неполная и полная заявки». Это помогает следующему сотруднику понять, какие сценарии покрыты, а какие требуют отдельного теста. Также назначьте владельца версии и событие пересмотра: смену формы заявки или обязательных полей. Тогда обновление процесса станет поводом повторить релевантный сценарий, а не перепроверять всё без разбора.
Как организовать хранение проверенных версий и командных правил, разбираем в материале о корпоративной библиотеке промптов и стандартов работы с ИИ.