Как принимать ИИ-решение: приёмочные критерии вместо впечатления

Метрики качества, доля эскалаций, поведение на краевых случаях, регресс при обновлении модели.

Что произошло

ИИ-решения перестали быть пилотами на бюджете инноваций и стали предметом договоров: техническое задание, этапы, акты, гарантийные обязательства. Классическая приёмка программного обеспечения строится на проверке «вход А даёт выход Б». Для ИИ-функции, отвечающей на вопросы по документам или классифицирующей обращения, такой проверки не существует: входов бесконечно много, выходы не повторяются буквально, а правильность ответа — не бинарная величина.

В результате приёмка сводится к впечатлению. Руководитель задаёт системе десять вопросов, она отвечает уверенно, акт подписан. Через месяц выясняется, что на реальном потоке система ошибается в заметной доле случаев, а за пределами своей области отвечает выдуманными фактами. Или обратная ситуация: заказчик находит три примера неверных ответов, подрядчик показывает тридцать верных, и спор не имеет процедуры разрешения, потому что в договоре нет ни метрик, ни порогов.

По нашему опыту проектов, значительная часть конфликтов между заказчиком и подрядчиком в ИИ-проектах возникает не из-за качества модели, а из-за отсутствия договорённости о том, как это качество измерять. Сдвиг, который произошёл за последний год: зрелые заказчики начали требовать приёмочные критерии до старта работ, а не после демонстрации. Это изменило и содержание договоров, и саму практику разработки.

Почему классическая приёмка не работает с LLM

Детерминизм против распределения

Обычная программа детерминирована: один и тот же вход всегда даёт один и тот же выход, и тест либо проходит, либо нет. Языковая модель работает иначе. Даже при фиксированных настройках ответ на один и тот же вопрос может отличаться формулировкой, структурой, полнотой. После обновления модели вендором — а вендоры обновляют модели без согласования с вами — распределение ответов сдвигается целиком.

Поэтому приёмка ИИ-функции не может быть проверкой отдельных случаев. Она может быть только статистической: на фиксированном наборе сценариев доля приемлемых ответов должна быть не ниже согласованного порога. Единичный неверный ответ — не основание для отказа в приёмке, если доля верных укладывается в порог. Единичный верный — не основание для подписания акта.

Пространство входов не перечислимо

Для обычной системы можно описать все допустимые входы: поля формы, диапазоны значений, форматы файлов. Для системы, принимающей естественный язык, пространство входов не имеет границ. Пользователь может задать вопрос с опечатками, на смеси языков, с двумя вопросами в одном, с ложной предпосылкой, с просьбой сделать то, что системе запрещено.

Единственный способ работать с бесконечным пространством — репрезентативная выборка. Это и есть эталонный набор сценариев: зафиксированный, версионированный список реальных запросов с эталонными ответами и критериями оценки.

Как собирается работающий эталонный набор:

источник — реальная история обращений (журналы контакт-центра, тикеты, переписка), а не придуманные вопросы;
стратификация по типам запросов: частые и редкие, простые и составные, из разных подразделений и ролей;
обязательная доля краевых случаев — вопросов, на которые правильный ответ «не знаю» или «передаю специалисту»;
эталонные ответы пишут эксперты предметной области заказчика, а не подрядчик;
набор замораживается, получает номер версии, и любая правка фиксируется.

Метрики, а не одна цифра точности

Точность — необходимая, но недостаточная метрика: её легко поднять, отвечая реже, и легко обесценить, отвечая всегда. Нужен набор метрик, и у каждой — не только порог, но и допустимый диапазон.

Метрика	Что измеряет	Где ломается, если смотреть только на неё
Точность	Доля ответов, признанных корректными, среди данных ответов	Редкие, но верные ответы — и нулевая польза
Полнота	Доля вопросов, на которые дан содержательный ответ, когда он должен быть дан	Ответы там, где система должна молчать
Доля ответов с источником	Доля утверждений, привязанных к конкретному фрагменту документа	Источник указан формально и не подтверждает утверждение
Доля эскалаций	Доля обращений, переданных человеку	Слишком низкая — модель самоуверенна; слишком высокая — не снимает нагрузку
Доля галлюцинаций	Доля ответов с утверждениями, не подтверждёнными источниками	Дорого измерять сплошным методом, нужна выборка и ручная проверка
Стоимость и время ответа	Ресурс на один запрос	Точность за счёт перезапросов может обнулить экономику

Пороги для каждой метрики берутся не из пожеланий, а из базовой линии — того, как этот процесс сегодня выполняют люди. Если операторы контакт-центра отвечают верно в определённой доле случаев, порог для системы задаётся относительно этой доли, а не как «без ошибок».

Краевые случаи и контроль галлюцинаций

Основные потери от ИИ-систем происходят не на типовых запросах, а на краях: там, где система должна отказаться, но отвечает. Приёмка обязана проверять поведение на таких входах отдельно, и для них критерий обычно строже, чем для основного потока.

Классы краевых случаев, которые стоит включить в эталонный набор:

вопросы вне области знаний системы — ожидаемое поведение: отказ или эскалация, а не ответ из общих знаний модели;
вопросы, на которые в источниках есть противоречивые ответы — ожидаемое поведение: указание на противоречие, а не выбор одного варианта;
вопросы по устаревшим документам — ожидаемое поведение: ответ по актуальной версии с указанием даты;
запросы, содержащие инструкции для модели внутри пользовательского текста или внутри документа — ожидаемое поведение: игнорирование инструкций;
попытки получить персональные данные или сведения ограниченного доступа — ожидаемое поведение: отказ;
вопросы на границе компетенции с юридическими или медицинскими последствиями — ожидаемое поведение: эскалация с сохранением контекста.

Галлюцинация в прикладном смысле — утверждение в ответе, которое не подтверждается ни одним из источников, доступных системе. Контроль строится в два слоя. Автоматический слой: каждое фактическое утверждение в ответе должно ссылаться на фрагмент источника, и отдельная модель-проверяющий сверяет, подтверждает ли фрагмент утверждение. Ручной слой: выборочная проверка экспертом, потому что автоматический проверяющий тоже ошибается, и его точность должна быть измерена отдельно.

Регресс: три подвижные части

В ИИ-решении три компонента, каждый из которых меняется независимо и каждый способен ухудшить результат без единой строки изменённого кода.

Модель. Вендор выпускает новую версию, подрядчик переключается на более дешёвую, компания переезжает с внешнего API на модель в закрытом контуре. Поведение меняется целиком.

Промпт. Правка одной фразы в системной инструкции меняет ответы на весь класс вопросов. Правки промптов часто делаются «на живую» в ответ на жалобу, и их последствия для остальных сценариев никто не проверяет.

Индекс. Для систем на базе поиска по документам добавление новых документов, удаление старых, изменение способа разбиения на фрагменты или смена модели эмбеддингов меняют то, что попадает в контекст ответа.

Отсюда следует, что приёмка — не событие, а процедура, которая повторяется при любом изменении любого из трёх компонентов. Прогон эталонного набора должен быть автоматизирован, а результат — сравниваться с зафиксированной базовой линией. В договоре это оформляется как регрессионный контроль на гарантийный период.

Приёмочный критерий — это не порог, который нужно перешагнуть один раз. Это измерение, которое должно оставаться воспроизводимым весь срок жизни системы.

Как это выглядит на практике

Сеть клиник, ассистент для контакт-центра. Демонстрация впечатлила руководство, приёмку провели по вопросам, которые задал директор по сервису. После запуска доля эскалаций оказалась близка к нулю, что выглядело как успех. Выборочная проверка через месяц показала, что система уверенно отвечала на вопросы о показаниях к процедурам — то, что по регламенту должно передаваться врачу. Решением стало добавление в эталонный набор отдельного блока краевых случаев и установление для доли эскалаций не порога, а диапазона: ниже нижней границы — такой же дефект, как выше верхней.

Производственная компания, поиск по нормативной документации. Подрядчик в рамках поддержки обновил модель. На эталонном наборе, который к тому моменту существовал только в виде презентации, никто прогон не делал. Качество ответов по одному из классов документов упало, и это выяснилось через квартал по косвенному признаку — росту обращений в отдел стандартизации. После этого эталонный набор был переведён в исполняемый вид, а прогон стал обязательной частью любого изменения.

Банк из первой сотни, спор по приёмке. Договор описывал функциональность, но не метрики. Заказчик представил подборку неверных ответов, подрядчик — подборку верных. Спор не имел процедуры разрешения. Стороны согласовали эталонный набор задним числом, зафиксировали пороги относительно текущих показателей операторов и провели повторную приёмку. Проект был принят с задержкой на месяцы, которых не было бы при наличии критериев в договоре.

Что это значит для российской компании

Закрытый контур и данные. Эталонный набор строится на реальных обращениях, а значит, содержит персональные данные и сведения ограниченного доступа. Его нельзя передать подрядчику для прогона на внешней инфраструктуре. Приёмка должна выполняться внутри контура заказчика, а сам набор — обезличиваться с сохранением смысла запросов. Это требование 152-ФЗ, и эксперты, размечающие ответы, работают внутри контура.

Частая смена моделей. Российский рынок живёт в режиме миграций: с внешних API на отечественные модели, с одной модели с открытыми весами на другую, из облака в контур. Каждый такой переход — это полная замена одного из трёх подвижных компонентов. Без исполняемого эталонного набора миграция превращается в повторный пилот с неизвестным исходом.

Регулируемые отрасли. Для финансового сектора, медицины, объектов КИИ результаты прогонов эталонного набора становятся доказательной базой при проверках: границы зафиксированы, изменения контролируются, поведение на критических случаях подтверждено.

Договор. Приёмочные критерии — часть технического задания, а не приложение к акту. В договоре фиксируются: состав и владелец эталонного набора (владелец — заказчик), метрики и пороги, процедура измерения, порядок разрешения спорных случаев, регрессионный контроль на гарантийный период.

Кадры. Разметка эталонного набора требует времени экспертов предметной области — юристов, врачей, технологов, старших операторов. Это время нужно запланировать и защитить: без него приёмка либо не состоится, либо будет проведена силами подрядчика с понятным конфликтом интересов.

Что делать: пошагово

Определите границы задачи. Что система должна делать, что не должна, и что должна передавать человеку. Граница «не должна» важнее границы «должна»: именно на ней происходят дорогие ошибки.
Соберите эталонный набор из реальной истории. Возьмите обращения за период, покрывающий сезонность. Стратифицируйте по типам и источникам. Добавьте краевые случаи по каждому классу из списка выше. Обезличьте.
Разметьте силами экспертов заказчика. Для каждого сценария — эталонный ответ или критерий приемлемости и ожидаемое поведение (ответ, отказ, эскалация). Зафиксируйте версию.
Измерьте базовую линию. Как этот процесс выполняется сегодня людьми: доля верных ответов, время, стоимость. Пороги для системы задаются относительно этой линии.
Выберите метрики и диапазоны. Не одна точность, а набор из таблицы выше, с нижней и верхней границей там, где это применимо.
Внесите критерии в договор. Техническое задание, порядок приёмки, регрессионный контроль на гарантийный срок, право заказчика на владение набором и результатами прогонов.
Автоматизируйте прогон. Набор в исполняемом виде, автоматический отчёт, сравнение с базовой линией, выборочная ручная проверка результатов автоматического оценивания.
Введите правило изменений. Любая правка модели, промпта или индекса сопровождается прогоном и решением: принять, откатить, доработать.

Типичные ошибки

Приёмка по демонстрации. Почему: демонстрация показывает лучшие сценарии, а деньги теряются на худших. Что вместо: прогон эталонного набора с зафиксированными метриками, демонстрация — только как иллюстрация.
Эталонный набор составляет подрядчик. Почему: подрядчик выберет сценарии, на которых система выглядит хорошо, не из злого умысла, а потому что видит систему изнутри. Что вместо: набор составляет и размечает заказчик, подрядчик может предложить дополнения.
Единственная метрика — точность. Почему: точность легко поднять, снизив полноту или подняв эскалации. Что вместо: набор метрик с диапазонами, где ухудшение одной не компенсируется улучшением другой.
Порог «без ошибок». Почему: он не связан с реальностью процесса, недостижим, и проект не будет закрыт никогда. Что вместо: пороги относительно базовой линии людей с запасом, о котором договорились стороны.
Набор из удобных вопросов. Почему: типовые запросы система пройдёт, а убытки принесут краевые случаи. Что вместо: обязательная доля краевых случаев с более строгими критериями.

Как понять, что вы на верном пути

Эталонный набор существует в исполняемом виде, имеет номер версии и владельца со стороны заказчика.
Пороги метрик привязаны к измеренной базовой линии, а не к ожиданиям.
Для доли эскалаций задан диапазон, а не только верхняя граница.
Краевые случаи выделены в отдельный блок с более строгими критериями.
Любое изменение модели, промпта или индекса сопровождается прогоном, и результаты прогонов хранятся.
Автоматический оценщик сам прошёл проверку на выборке, размеченной людьми.
В договоре с подрядчиком описаны метрики, процедура измерения и регрессионный контроль на гарантийный период.

Вопросы, которые нам задают

Сколько сценариев должно быть в эталонном наборе?

Столько, чтобы каждый значимый класс запросов был представлен достаточно для статистической оценки, а краевые случаи — по каждому типу риска. По нашему опыту, речь идёт о сотнях сценариев, и набор растёт по мере эксплуатации. Важнее не размер, а стратификация: набор, покрывающий все классы и края, полезнее набора вдесятеро большего, но однотипного.

Кто должен оценивать ответы — люди или модель?

И те и другие, в разных ролях. Модель-оценщик делает сплошную проверку по формализуемым критериям: наличие источника, соответствие утверждения фрагменту, соблюдение формата, факт отказа там, где он ожидался. Люди делают выборочную проверку и разбор спорных случаев. Точность модели-оценщика измеряется на выборке, размеченной людьми, и если она недостаточна — её оценки не могут быть основанием для приёмки.

Подрядчик отказывается фиксировать метрики в договоре. Что это значит?

Обычно одно из двух: у подрядчика нет опыта промышленной эксплуатации, и он не знает, какие показатели достижимы, либо он знает и не уверен, что достигнет их. В обоих случаях риск переходит на вас. Компромисс — фиксировать метрики после короткого обследования и сбора эталонного набора, но до основного объёма работ, с правом сторон выйти из договора по результатам обследования.

Модель обновляется вендором автоматически. Как принимать такую систему?

Так же, только чаще. Прогон эталонного набора должен запускаться по расписанию, а не только при ваших изменениях, и его результаты — сравниваться с базовой линией. При ухудшении сверх допустимого — откат на предыдущую версию, если вендор её сохраняет, или переход к модели, версию которой вы контролируете. Если ни то ни другое невозможно, это аргумент в пользу размещения модели в собственном контуре: там обновления происходят тогда, когда вы к ним готовы, и каждое из них проходит тот же прогон, что и первая приёмка.