Когда вы описываете функцию с ИИ-компонентой, критерий приёмки перестаёт быть «при вводе X система возвращает Y». Критерий приёмки становится eval: размеченный набор данных, функция оценки и целевой балл, который система должна взять до запуска и брать заново после каждой смены модели или правки промпта. Простое правило: если вы не можете написать eval, функция ещё не описана. В этой статье разобраны четыре составляющие вероятностного критерия приёмки и то, как их формулировать на практике.
Что именно ломается в традиционном техзадании
Классическое техзадание держится на одном допущении: одинаковый вход всегда даёт одинаковый выход. Из него выведена вся структура тестов, определений и условий готовности. В тот момент, когда компонентой системы становится языковая модель, это допущение рушится, а вместе с ним рушится и весь построенный поверх инструментарий.
Нагляднее всего это проявляется в приёмочном тесте. «Пользователь нажимает отправить и получает краткое изложение обращения» — не проверяемое требование, потому что единственного правильного ответа не существует. Два разных изложения могут быть одинаково хорошими, а третье, внешне похожее, — полностью ошибочным. Требуется определить диапазон приемлемого поведения, а не единственный результат.
Проверка, экономящая месяцы разработки: прежде чем писать строку кода, попробуйте написать eval. Если вы не можете определить, что считается хорошим ответом и как его измерить, требование остаётся размытым. Функции, застревающие на пилоте, почти всегда проваливаются именно на этом этапе, а не на реализации.
Четыре составляющие критерия приёмки ИИ-функции
| Составляющая | Что она задаёт | Пример |
|---|---|---|
| Описание поведения | Что система должна делать, сформулировано так, чтобы допускать вариативность | Изложение обращения, содержащее проблему, предпринятое действие и статус |
| Порог оценки | Минимальный балл на отложенной тестовой выборке, никогда не использовавшейся в разработке | 90% изложений содержат все три элемента |
| Ограничение безопасности | Что считается недопустимым выводом независимо от балла | Ни одно изложение никогда не содержит телефон клиента |
| Точка передачи человеку | Что происходит в случаях, которые модель не может разрешить | Низкая оценка уверенности направляет обращение в человеческую очередь |
Различие между второй и третьей составляющей принципиально. Порог статистичен и терпит отдельные сбои. Ограничение бинарно и не терпит ни одного. Без этого разделения вы получаете функцию, которая проходит с 92% успеха, тогда как в оставшихся 8% прячется утечка данных.
Как построить eval без исследовательской команды
Eval — не проект. В типичном случае это три небольших актива, поддерживаемых во времени:
Набор данных. От 50 до 150 реальных случаев из существующей системы, включая неудобные. Важно, чтобы они были собраны с поля, а не придуманы, потому что придуманные случаи всегда слишком удобны. К каждому приложите ответ, который дал бы профильный эксперт.
Функция оценки. Она не обязана быть изощрённой. Во многих случаях достаточно проверить наличие обязательных элементов, соответствие заданной структуре или совпадение ключевых слов. Там, где требуется суждение, можно использовать модель в роли судьи — при условии, что вы вручную выборочно проверяете часть оценок и убеждаетесь, что сам судья не дрейфует.
Порог и базовый замер. Измерьте один раз до того, как что-либо менять. Без базового замера вы не поймёте, улучшила правка промпта результат или сломала его, и большинство команд узнаёт об этом слишком поздно.
Когда её запускать: eval — не разовая проверка перед релизом. Она перезапускается при каждой смене модели, каждой правке промпта и каждом изменении источника данных, питающего систему. Именно это отличает eval от тест-кейса и именно поэтому её нужно встроить в процесс сборки с первого дня.
Шесть разделов, которые стоит добавить в документ требований
| Раздел | Что в него входит |
|---|---|
| Описание поведения модели | Что модель должна делать, каким тоном и что находится вне рамок |
| Пороги приёмки | Метрики и минимальные баллы, включая данные, на которых они измеряются |
| Каталог режимов отказа | Перечень способов, которыми функция может отказать, и что происходит в каждом |
| Поведенческие ограничения | Бинарные красные линии: чего никогда не должно быть в выводе |
| План оценки | Набор данных, метод оценки и частота запуска |
| Данные и приватность | Какие данные попадают в промпт и на каком уровне классификации |
Последний раздел напрямую связан с вашей политикой классификации данных. Если вы её ещё не определили, четырёхуровневая модель классификации — отправная точка, потому что без неё техзадание опишет возможность, которой вам не разрешено пользоваться.
Каталог режимов отказа: раздел, который важнее всего написать
В детерминированной системе режим отказа — это ошибка. В системе с ИИ-компонентой режим отказа — это обычно ответ, который выглядит совершенно нормально и при этом неверен. Поэтому каталог должен перечислять отказы по тому, что переживает пользователь, а не по тому, что сообщает система.
Особенно часты четыре: уверенный неверный ответ, для проверяемости которого нужны ссылки на источники; отказ отвечать на законный вопрос, требующий обходного пути; частичный ответ, опускающий существенное условие; и дрейф во времени, когда источник данных меняется и качество вывода падает, хотя никто не трогал ни строки кода. Последний — главная причина, по которой eval должна запускаться регулярно, а не только перед релизом.
Что это делает со сроками и бюджетом
Практический эффект — смещение усилий. В классическом техзадании основное время уходит на описание экранов и сценариев. В ИИ-функции существенная доля смещается в сбор и разметку тестовых случаев, а это работа профильного эксперта, а не разработчика. Заложите её в бюджет явно, иначе её выдавят, и вы придёте к релизу без возможности понять, работает ли система.
Второе смещение: функция никогда не «заканчивается». Она несёт постоянную стоимость сопровождения — запуск eval и поддержание тестового набора. Когда вы считаете жизнеспособность, эта статья должна входить в юнит-экономику с самого начала, а не всплывать во втором квартале.
А если функция отвечает по вашим собственным документам, техзадание должно покрывать и слой поиска, потому что именно там решается большая часть реальной точности. Полный разбор — в руководстве по корпоративной базе знаний. Мы сопровождаем весь процесс, от техзадания до релиза, в рамках наших направлений экспертизы.
Часто задаваемые вопросы
Что такое eval и чем она отличается от обычного приёмочного теста?
Eval — это размеченный набор данных вместе с функцией оценки и минимальным порогом. Обычный приёмочный тест проверяет единственный вывод и возвращает «прошёл» или «не прошёл», тогда как eval измеряет распределение качества по десяткам случаев и перезапускается при каждой смене модели, промпта или источника данных.
Сколько тестовых случаев нужно для старта?
От 50 до 150 реальных случаев из существующей системы хватает для большинства функций. Важно, чтобы они были собраны с поля, а не придуманы, и чтобы включали трудные случаи, а не только удобные.
Как писать критерии приёмки для вывода без единственного правильного ответа?
Определите четыре составляющие: описание поведения, допускающее вариативность, порог оценки на отложенной тестовой выборке, бинарное ограничение безопасности без исключений и маршрут передачи человеку для случаев, которые модель не может разрешить.
Зачем разделять порог оценки и ограничение безопасности?
Потому что порог статистичен и терпит долю сбоев, а ограничение бинарно. Без этого разделения функция может пройти с высоким баллом, тогда как серьёзное нарушение — например, раскрытие персональных данных — прячется внутри процента отказов.
Можно ли использовать модель в роли судьи для оценки вывода?
Да, и это распространённый метод там, где требуется суждение. Условие — вручную выборочно проверять часть оценок и сравнивать их с человеческим суждением, чтобы убедиться, что сам судья не дрейфует со временем.