До prompt определите, что значит "хорошо"
Без критерия успеха промптинг превращается в дегустацию: вы меняете слова, смотрите на один удачный ответ и не знаете, стало ли лучше или просто повезло. Поэтому первый инженерный шаг делается ещё до prompt - решить, что вообще считать выполнением.
Начать удобно с минимальной карточки задачи: зачем она, что на входе, что на выходе и по каким сигналам судить об успехе.
use_case: support_policy_answer
user_value: клиент получает точный ответ без ожидания оператора
inputs: вопрос, язык, tenant_id, найденные фрагменты
success:
- ответ опирается только на действующую политику
- каждое проверяемое утверждение имеет source_id
- при нехватке данных модель не угадывает
- p95 latency укладывается в продуктовый бюджет
failure_cost:
low: лишнее уточнение
high: выдуманная цена или обещание возврата
baseline: поиск по FAQ + готовые ответыДальше "хорошо" стоит разложить на три измерения - иначе легко оптимизировать одно и не заметить, как проседает другое.
- Outcome - изменилось ли реальное состояние. Тикет закрыт, нужное поле извлечено, перевод принят редактором. Это то, ради чего задача вообще существует.
- Behavior - правильно ли модель себя вела. Тот ли tool, маршрут, handoff, уточнение и цитата, и вовремя ли она остановилась. Хороший исход при плохом поведении - удача, а не система.
- Operational - чего это стоило. Latency, токены, ошибки tools, доля эскалаций, прерывания и стоимость одного успешного результата.
И проверять всё это нужно не на придуманных примерах. Dataset начинается с реальности - с настоящих запросов, включая неудобные и граничные, а не только happy path.
Промптинг начинается не с prompt. Anthropic требует определить success criteria и способ эмпирической проверки ещё до оптимизации. OpenAI и Google так же строят production-рекомендации вокруг datasets, evals и traces.
Проверка знаний
С чего начинается инженерный промптинг?