На демонстрации ИИ-помощник получает удобный вопрос и выдаёт убедительный ответ. После запуска появляются письма без темы, противоречивые документы, нестандартные возвраты и пользователи, которые меняют условия на середине диалога. Качество внезапно становится предметом спора. Один сотрудник считает ответ хорошим, другой видит опасную ошибку.
Такой спор нельзя решить ещё одним удачным примером. Нужен eval, то есть повторяемая проверка ИИ-системы на заранее описанных сценариях. У каждого сценария есть входные данные, ожидаемый результат и способ выставить оценку.
Проверяйте рабочий результат
Начинать стоит не с метрики модели, а с действия, ради которого компания внедряет ИИ. Для помощника службы поддержки это может быть правильно оформленный возврат, точная ссылка на правило или передача сложного случая сотруднику.
OpenAI называет такие проверки контекстными. Общий тест модели не показывает, справится ли конкретная система с процессом конкретной компании. Команда должна сначала описать хороший результат, затем проверить его в реалистичных условиях и разобрать ошибки. Эту схему OpenAI формулирует как Specify, Measure, Improve.
Допустим, помощник сообщает: "Возврат оформлен". Проверять только текст ответа бессмысленно. В базе должна появиться операция на верную сумму, заказ должен перейти в нужный статус, а клиент не должен получить два возврата при повторном запросе.
Anthropic разделяет transcript и outcome. Transcript хранит сообщения, вызовы инструментов и промежуточные шаги. Outcome описывает конечное состояние системы. В бизнес-автоматизации outcome обычно важнее красивого объяснения.
Соберите первые сценарии из реальной работы
Для старта не нужна тысяча искусственных вопросов. Anthropic рекомендует начать с 20–50 простых задач, взятых из ручных проверок и реальных сбоев. Небольшой набор уже показывает, ломает ли новый промт старое поведение.
Источники для первого набора обычно лежат рядом:
- обращения, которые сотрудникам пришлось исправлять вручную;
- пограничные случаи из регламента;
- частые вопросы клиентов;
- ошибки из журналов и службы поддержки;
- примеры, на которых расходятся мнения двух специалистов.
Последняя группа особенно полезна. Если два эксперта не могут согласовать правильный ответ, проблема находится в требованиях, а не в модели. Сначала нужно уточнить правило.
Каждый сценарий лучше хранить как отдельную запись. В ней есть входные данные, ожидаемый исход, запрещённые действия и причина, по которой случай важен. Персональные данные из журналов нужно удалить или заменить синтетическими.
Для задачи с возвратом запись может выглядеть так:
id: refund-after-deadline
input: заказ доставлен 37 дней назад, клиент просит полный возврат
expected:
action: escalate_to_human
refund_created: false
policy_section_present: true
severity: critical
Это уже лучше требования "помощник должен корректно обрабатывать возвраты". Разработчик понимает, что проверить, а владелец процесса видит, какое бизнес-правило попало в систему.
Используйте разные способы оценки
Одного оценщика недостаточно. Anthropic выделяет программные, модельные и человеческие проверки. Они отвечают на разные вопросы.
Программный тест быстро проверит сумму, статус заказа, формат JSON, вызванный инструмент и время ответа. Такой тест воспроизводим, но плохо оценивает вежливость или полноту объяснения.
Вторую модель можно попросить сравнить ответ с рубрикой. Например, она проверит, назвал ли помощник причину отказа понятным языком и не пообещал ли то, чего нет в правилах. Оценка самой модели тоже бывает ошибочной. Её нужно регулярно сверять с решениями специалистов.
Человек остаётся нужен там, где качество зависит от предметной области и контекста. Юрист проверяет трактовку условия договора, врач оценивает медицинский текст, руководитель поддержки задаёт допустимый тон. Человеческая проверка дорогая, поэтому разумно использовать её для калибровки автоматических оценок и выборочного контроля.
| Что проверяем | Подход |
|---|---|
| Создана ли нужная запись в системе | Запрос к базе или API |
| Соблюдён ли формат ответа | Схема, регулярное выражение или парсер |
| Подтверждается ли вывод источником | Сопоставление ответа с найденным документом |
| Понятно ли объяснено решение | Рубрика и модель-оценщик |
| Допустим ли ответ для бизнеса | Проверка специалистом |
Повторяйте критические сценарии
Один и тот же запрос может дать разные ответы. Поэтому Anthropic называет отдельный запуск trial и советует проводить несколько попыток, чтобы получить устойчивую оценку.
Это важно для редких, но дорогих ошибок. Если помощник девять раз верно запрашивает подтверждение платежа, а на десятый проводит его самостоятельно, средняя точность 90% выглядит прилично. Для финансовой операции результат неприемлем.
У критических сценариев должен быть собственный порог. Несанкционированный платёж, раскрытие персональных данных или обход обязательного согласования нельзя спрятать внутри общей средней оценки. Такие ошибки блокируют выпуск независимо от результатов остальных задач.
Разделите развитие и защиту от регрессий
Набор возможностей отвечает на вопрос: "Что система уже умеет?" Туда входят сложные случаи, которые пока проходят не всегда. Они помогают сравнивать модели, промты и варианты архитектуры.
Регрессионный набор отвечает на другой вопрос: "Не сломали ли мы то, что работало?" В него переходят исправленные ошибки и стабильные сценарии. Anthropic рекомендует поддерживать оба набора отдельно, потому что рост на новых сложных задачах не гарантирует сохранения прежнего качества.
Запускайте регрессионные проверки после изменения промта, модели, базы знаний, инструментов или параметров поиска. Если используется RAG, новая схема разбиения документов тоже может изменить ответы. Для агента с инструментами нужно дополнительно проверять конечное состояние внешних систем.
Тестовая среда должна быть похожа на рабочую
Проверка в окне чата не воспроизводит задержки API, права доступа, повреждённые файлы и частично выполненные операции. Нужен изолированный стенд с теми же инструментами и близкими настройками, но без доступа к реальным деньгам и клиентским данным.
В пилоте ARIA институт NIST оценивал семь ИИ-приложений на трёх уровнях: тесты модели, red teaming и полевые испытания с пользователями. Авторы сочетали разметку диалогов специалистами и анкеты тестировщиков. Такой дизайн показывает важную границу автоматических evals. Они находят известные сбои до релиза, но не заменяют наблюдение за реальной работой.
После запуска сохраняйте обезличенные ошибки, обращения и спорные диалоги. Раз в неделю команда должна разбирать выборку и добавлять новые случаи в набор. Так производственный сбой превращается в тест и больше не возвращается незаметно.
Какие цифры смотреть перед выпуском
Процент пройденных сценариев нужен, но сам по себе почти ничего не решает. К нему стоит добавить:
- долю критических ошибок;
- качество по отдельным группам сценариев;
- число лишних действий и пропущенных действий;
- долю корректных передач сотруднику;
- задержку и стоимость одного успешно завершённого задания.
Сравнивайте версии на одном и том же зафиксированном наборе. Если новый вариант отвечает точнее, но вдвое чаще вызывает дорогой инструмент, команда должна увидеть обмен качества на стоимость до выпуска.
У отчёта должен быть владелец. Продукт определяет полезный исход, специалисты предметной области пишут правила, разработчики автоматизируют запуск, а ответственный за релиз принимает решение по заранее согласованным порогам. Иначе eval превращается в красивую панель без последствий.
Минимальный рабочий процесс
- Выберите один узкий процесс и запишите его успешный конечный результат.
- Соберите 20–50 реальных и пограничных сценариев.
- Для каждого сценария укажите ожидаемый исход и недопустимые действия.
- Автоматизируйте объективные проверки, остальные оформите как короткие рубрики.
- Запустите базовую версию несколько раз и прочитайте неудачные диалоги.
- Исправьте требования, промт, данные или код и повторите тот же набор.
- Переносите исправленные ошибки в регрессионную проверку перед каждым выпуском.
Хороший eval не доказывает, что ИИ никогда не ошибётся. Он делает риск видимым до того, как его заметит клиент. Это скучнее эффектной демонстрации, зато именно такая работа отделяет пилот от системы, которой можно доверить реальный процесс.
Если вы готовите ИИ-помощника к рабочей нагрузке, обсудите задачу с командой SmartSeven. Мы поможем описать критерии качества, собрать тестовый набор и встроить проверки в выпуск.
