Разрыв между способностью и надёжностью
Вот паттерн, который обжигает почти каждого, кто впервые выкатывает ИИ для реальных пользователей:
Модель идеально делает нужное в вашем тесте. В продакшене она проваливается. Вы в недоумении, ведь вы видели, как это работает.
То, на что вы наткнулись, — это разрыв между способностью и надёжностью.
Способность означает, что модель может выполнить задачу — она выдаёт корректный результат хотя бы раз, при некоторых условиях.
Надёжность означает, что модель стабильно выполняет задачу корректно — на разнообразных входных данных, при повторных запусках, при небольших изменениях формулировки или контекста.
Демонстрации доказывают способность. Продакшен требует надёжности. Это разные свойства, и большинство руководств их путает.
Почему демонстрации лгут
Когда вы тестируете промпт, вы обычно:
- Запускаете его на входных данных, которые сами и придумали
- Запускаете несколько раз
- Выбираете тот вывод, что выглядит хорошо
- Подкручиваете промпт, пока он не станет выглядеть как надо
Этот процесс оптимизирует под способность. Теперь промпт работает на ваших примерах. Вы видели корректный вывод. Вы его выкатываете.
Проблема в том, что входные данные пользователей в продакшене — это не ваши примеры. Они грязнее, разнообразнее, сформулированы способами, которых вы не предвидели. Модель на них никогда не тестировалась. Вы понятия не имеете, как она на них работает.
Один хороший вывод — это не оценка производительности. Это анекдот.
Дисперсия — скрытая переменная
LLM стохастичны. Запустите один и тот же промпт дважды — и вы часто получите разные выводы. Эта дисперсия нормальна и обычно не страшна. Но она означает, что важный вопрос не «сработало ли?», а «в какой доле случаев оно срабатывает?».
Задача, в которой модель преуспевает в 95% случаев, отлично выглядит в демонстрации и ломается примерно на одном из двадцати пользователей. Задача, в которой она преуспевает в 60% случаев, выглядит нормально, когда запускаете её вы сами. Это очень разные ситуации, и вы не отличите их друг от друга без измерений.
Спектр способность–надёжность на практике
| Измерение | Способна, но ненадёжна | Надёжна |
|---|---|---|
| Тестируемые входные данные | Придуманные автором примеры | Разнообразные, реальные пользовательские входные данные |
| Размер выборки | Несколько запусков | Повторные запуски на многих примерах |
| Видимость режима отказа | Отказы редки в тестах, часты в продакшене | Отказы измерены и поняты |
| Как вы узнаёте, что сломалось | Жалобы пользователей | Ваш набор оценок (eval suite) |
| Как вы это улучшаете | Гадаете и проверяете промпты | Отслеживаете долю прохождений, систематически разбираете отказы |
| Уверенность при выкатке | На основе ощущений | На основе доказательств |
Оценки — это настоящий ров
Лучшие промпты могут поднять способность. Только оценки могут сказать, подняли ли вы надёжность.
Оценка (eval) — это структурированный тест: набор входных данных, ожидаемые выводы или критерии оценивания и способ измерить долю прохождений. Вы прогоняете модель на входных данных, оцениваете выводы и получаете число. Затем вы что-то меняете — промпт, модель, температуру — и прогоняете снова. Теперь у вас есть сигнал.
Это не гламурно. Это та часть работы над ИИ-продуктом, которую большинство туториалов пропускает целиком. Но это единственный способ ответить на вопрос, который действительно важен при выкатке: «Как часто это работает на входных данных, которых я не видел?»
Простой способ начать
Чтобы начать, инфраструктура не нужна. Вот минимальный жизнеспособный цикл оценки:
-
Соберите эталонный набор. Соберите 20–50 реальных или реалистичных входных данных. Для каждого опишите, как выглядит корректный вывод (или критерии его оценки). Это ваши эталонные примеры.
-
Запустите N раз. Прогоните ваш промпт на каждом примере несколько раз. Дисперсия между запусками говорит о стабильности промпта; дисперсия между примерами — о покрытии.
-
Отслеживайте долю прохождений. Для каждой пары (вход, запуск) фиксируйте «прошёл» или «провалил». Вычислите общую долю. Это число — начало вашей картины надёжности.
-
Сделайте это регрессионным тестом. Каждый раз, меняя промпт, прогоняйте оценку заново. Если доля прохождений падает — вы что-то сломали. Если растёт — вы добились настоящего улучшения.
Вот и всё. Подойдёт и таблица. Дисциплина важнее инструментария.
Почему это инженерная проблема, а не проблема промптинга
Инстинкт при провале модели — переписать промпт. Иногда это правильно. Но часто это способ оптимизироваться под тот случай отказа, который вы увидели, ценой регресса на случаях, которые вы не проверили.
Инженерия надёжности для ИИ выглядит так:
- Определение того, что значит «корректно», до того как вы что-либо запускаете
- Измерение на репрезентативном распределении входных данных
- Отслеживание изменений во времени по единой методологии
- Различение «эта модель не может выполнить эту задачу» и «эта задача недоопределена»
Инженерия промптов — инструмент внутри этого процесса. Она не заменяет его.
Честная формулировка
Большинство возможностей ИИ реальны. Модели действительно способны на замечательные вещи. Разрыв между способностью и надёжностью — это не аргумент о том, что возможности фальшивы; это аргумент о том, что знать об их существовании недостаточно.
Если вам нужно, чтобы задача работала в 95% случаев, вам нужны доказательства, что она работает в 95% случаев. Эти доказательства приходят из прогона структурированных тестов, а не из уверенности в демонстрации.
Инженеры, которые строят долговечные ИИ-продукты, — не обязательно те, кто пишет лучшие промпты. Это те, кто знает, что значит «работает», прежде чем выкатить, и у кого есть измерение, говорящее им, правда ли это.