Как протестировать ИИ-ассистента до запуска: собрать тестовый набор из своих случаев, задать проходные пороги и решить, кто утверждает запуск

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

Почему хорошее демо ИИ — ещё не тест?

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

Руководство OpenAI по лучшим практикам оценки начинается именно с этого: «Генеративный ИИ изменчив. Модели иногда выдают разные результаты при одних и тех же входных данных, из-за чего традиционных методов тестирования ПО недостаточно для ИИ-архитектур». Все источники в этой статье открывались 4 ноября 2026 года.

Тесты ответов модели руководство называет evals — это сокращение от evaluations (оценки). Одна из ошибок, которые в нём перечислены, — vibe-based eval, то есть оценка по ощущениям: «Использовать „кажется, работает“ в качестве стратегии оценки или ждать выпуска продукта, прежде чем внедрять какие-либо evals».

NIST, Национальный институт стандартов и технологий США, в июле 2024 года опубликовал Generative AI Profile в качестве добровольных рекомендаций. В профиле генеративный ИИ сокращённо обозначается как GAI. Одно из предлагаемых в нём действий звучит так: «Избегайте экстраполяции эффективности или возможностей системы GAI на основе узких, несистематических и единичных оценок».

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

Откуда брать тестовые случаи?

Из вашей собственной работы, примерно в том же соотношении, в каком они будут встречаться ассистенту. Руководство Anthropic о том, как определять критерии успеха и строить оценки для моделей Claude, гласит: «Проектируйте evals так, чтобы они отражали реальное распределение ваших задач».

Руководство OpenAI добавляет: «Убедитесь, что ваши тестовые данные включают типичные, пограничные и состязательные случаи». Пограничные случаи — это редкие или нестандартные входные данные. Состязательные случаи пытаются заставить ассистента вести себя неправильно. Берите случаи из таких источников:

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

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

В наборе хранятся реальные данные клиентов, поэтому применяйте к нему те же правила доступа, что и к тикетам и документам, из которых он собран.

Кто пишет ожидаемые ответы и что в них входит?

Ожидаемые ответы пишут ваши собственные эксперты, а не компания, которая строит ассистента. Ожидаемый ответ, который инженеры называют эталоном (ground truth), — это ответ, который принял бы внимательный сотрудник. Его форма зависит от задачи:

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

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

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

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

Как задать проходные пороги?

Проходной порог — это минимальный результат, который вы готовы принять до запуска. Задайте его для каждого типа вопросов и каждого вида ошибок, потому что единый проходной порог для всего ассистента слишком многое скрывает. Руководство Anthropic отмечает: «Большинству сценариев использования нужна многомерная оценка по нескольким критериям успеха».

Отнесите каждый проваленный случай к одному виду ошибок:

• Неверный факт: ответ утверждает что-то ложное. Профиль NIST называет это конфабуляцией: «Генерация уверенно изложенного, но ошибочного или ложного контента (в обиходе известного как „галлюцинации“ или „выдумки“), который может ввести пользователей в заблуждение или обмануть их».
• Пропущенный ответ: ответ был в документах, но ассистент сказал, что не знает, или упустил ключевой факт
• Неверный источник: ответ ссылается на документ, который его не подтверждает, или на устаревшую версию
• Опасный ответ: провален случай с нулевой терпимостью к ошибкам
• Форма и тон: факты верны, но ответ слишком резкий или не в том формате

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

Все случаи с нулевой терпимостью к ошибкам должны быть пройдены. Один провал останавливает запуск, пока вы не устраните причину и весь набор снова не будет пройден.

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

Кто или что оценивает ответы ассистента?

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

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

У модели в роли оценщика есть известные склонности. Руководство OpenAI называет среди трудностей «позиционную предвзятость (порядок ответов), предвзятость к многословию (предпочтение более длинных ответов)». То есть на вердикт может повлиять порядок ответов, а более длинный ответ может выиграть только за счёт своей длины. Среди советов руководства есть такой: «Используйте обратную связь от людей, чтобы калибровать автоматическую оценку». На практике ваши эксперты оценивают выборку, которую оценивает и модель, а вы исправляете чек-лист везде, где их оценки расходятся.

Для черновиков полезен слепой тест. Смешайте черновики ассистента с ответами ваших сотрудников на те же тикеты и дайте проверяющим оценить их, не зная, где чей ответ. Руководство OpenAI приводит «рандомизированный слепой тест» как один из примеров оценки людьми.

Поскольку в каждом ожидаемом ответе указан его источник, можно проверить и поиск (retrieval) — этап, на котором система находит фрагменты, которые потом читает модель. Если поиск так и не нашёл нужный фрагмент, исправляйте поиск, а не модель. Профиль NIST предлагает похожую проверку: «Проверяйте и верифицируйте источники и цитаты в результатах систем GAI в ходе измерения рисков перед развёртыванием и текущего мониторинга».

Прогоняйте каждый случай несколько раз, а ключевые вопросы задавайте в нескольких формулировках. Руководство Anthropic рассматривает согласованность как отдельный критерий: «Если пользователь задаёт один и тот же вопрос дважды, насколько важно, чтобы он получил семантически схожие ответы?» Семантически схожие — значит, ответы говорят одно и то же, пусть и разными словами.

Когда снова прогонять тестовый набор?

После каждого изменения, до того как оно дойдёт до клиентов. Имеются в виду новая версия модели, отредактированные документы, новые настройки поиска или новый промпт — письменные инструкции, которым следует модель. В руководстве OpenAI это отдельный шаг: «Настройте непрерывную оценку (CE), чтобы запускать evals при каждом изменении».

Каждый прогон ищет регрессии, то есть случаи, которые проходили до изменения и не проходят после него. Среднее может расти, пока один тип вопросов ломается, поэтому смотрите на каждый тип отдельно. Изменение уходит в работу, только когда:

• Ни один случай с нулевой терпимостью к ошибкам не провален
• Ни один тип вопросов не опустился ниже своего проходного порога
• Человек разобрал каждый новый провал и знает его причину

Храните результаты каждого прогона вместе с версиями модели, промпта и документов, которые тестировались.

Кроме того, провайдеры выводят модели из эксплуатации по собственному графику. На странице OpenAI о выводе из эксплуатации (deprecations) указано, что для общедоступных моделей уведомление даётся не менее чем за шесть месяцев, если соображения безопасности или комплаенса не требуют более сжатых сроков. Preview-модели могут выводиться из эксплуатации с гораздо более коротким уведомлением. Страница Anthropic обещает уведомлять о выводе публично выпущенных моделей не менее чем за 60 дней и предупреждает: «Запросы к моделям после даты вывода из эксплуатации будут завершаться ошибкой».

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

Что проверять после запуска?

Каждую неделю эксперт оценивает по тому же чек-листу случайную выборку реальных ответов и черновиков, потому что живой трафик приносит случаи, о которых никто не подумал. Это ручная проверка выборки, а не каждого ответа.

AI Risk Management Framework от NIST — добровольные рекомендации, опубликованные в январе 2023 года, — гласит: «Системы ИИ следует тестировать до их развёртывания и регулярно во время эксплуатации». NIST сообщает, что готовит обновлённую версию.

Дайте сотрудникам и клиентам простой способ отметить плохой ответ и превращайте каждый подтверждённый провал в новый тестовый случай. Один из советов OpenAI гласит: «Ведите логи в ходе разработки, чтобы потом находить в них хорошие случаи для evals».

Кто утверждает запуск и на основании каких доказательств?

Результаты утверждает владелец процесса: например, для ассистента поддержки — руководитель поддержки. Случаи с нулевой терпимостью к ошибкам утверждает служба комплаенса или юридический отдел. Исполнитель представляет результаты, но не утверждает собственную работу.

Фреймворк NIST описывает похожее разделение ролей при оценке: «Внутренние эксперты, которые не были непосредственными разработчиками системы, и/или независимые оценщики участвуют в регулярных оценках и обновлениях». Затем часть фреймворка под названием Manage открывается решением о системе ИИ: «следует ли продолжать её разработку или развёртывание».

Пакет доказательств для этого решения должен показывать:

• Как собран набор, его размер по каждому типу вопросов и кто писал ответы
• Протестированные версии: модель, промпт, документы и настройки поиска
• Результаты по каждому типу вопросов и виду ошибок в сравнении с заранее согласованными проходными порогами
• Каждый случай с нулевой терпимостью к ошибкам и его результат
• Каждый провал — с разбором и объяснением
• Результаты вашей команды на тех же случаях
• С чем ассистент не работает и кто проверяет еженедельную выборку после запуска

Утверждение может быть частичным. Ассистент может начать работу по тем типам вопросов, которые прошли проверку, а остальные будут уходить человеку, пока тоже не пройдут.

Кому принадлежит тестовый набор?

Вашей компании должны принадлежать случаи, ожидаемые ответы, чек-листы, скрипты и история результатов. Вместе они — ваше письменное определение хорошего ответа. Они позволяют предъявлять те же требования к любой следующей модели или любому вендору.

Храните их в хранилище, которое вы контролируете, потому что инструменты вендоров тоже выводят из эксплуатации. На странице OpenAI о выводе из эксплуатации сказано, что 3 июня 2026 года компания уведомила разработчиков, которые пользуются её платформой Evals, о том, что продукт выводится из эксплуатации. Там указано 31 октября 2026 года как дата, когда существующие evals станут доступны только для чтения, и 30 ноября 2026 года — как дата запланированного отключения дашборда и API.

Назначьте на своей стороне владельца набора и выделите ему время, чтобы добавлять случаи и обновлять ответы, когда меняются политики.

Что спросить у вендора или компании, которая будет строить ассистента?

Когда вендор называет показатель точности, спросите, на чём он измерен. Профиль NIST предлагает: «Оценивайте заявления о возможностях модели с помощью эмпирически подтверждённых методов». Затем задайте эти вопросы каждому вендору или компании из вашего списка:

• Будете ли вы тестировать на наших случаях, с ожидаемыми ответами, которые написали наши люди?
• Какую часть тестового набора вы не увидите до финального прогона?
• Какие проходные пороги вы предлагаете для каждого типа вопросов и вида ошибок и почему?
• Как вы оцениваете свободный текст и как сверяли свою модель-оценщика с оценками людей?
• Сможем ли мы сами, без вас, заново прогонять весь набор после каждого изменения?
• Кто платит за повторное тестирование, когда провайдер выводит модель из эксплуатации?
• Получим ли мы в конце случаи, чек-листы, скрипты и историю результатов?

Где здесь место amBrain?

amBrain ведёт этот блог. О собственном продукте компания говорит: «Наш собственный продукт shyash.ai работает на ИИ-агентах, которые исследуют, пишут, проверяют и измеряют на основе единой общей памяти о фактах компании. Человек одобряет всё, что уходит наружу».

О клиентской работе с языковой моделью amBrain говорит: «Мы вывели интеграцию LLM в прод внутри FinTech-периметра клиента: извлечение и нормализация неструктурированных уведомлений брокеров и торговых площадок — о корпоративных действиях, изменениях по инструментам и марже — в структурированные записи, которые потребляет торговая система».

Эта статья — не кейс и не описывает никакой работы для клиентов, кроме этой строки, в которой не сказано, как тестировался проект. Здесь нигде не утверждается, что amBrain создавал описанные выше тестовые наборы, проходные пороги или процедуры утверждения, и не говорится, как тестируется shyash.ai. Примеры — общие, а не взятые из работы amBrain.

Организации, названные здесь, цитируются по их опубликованным страницам. Статья не утверждает, что между amBrain и кем-либо из них есть какие-либо отношения, и цен и сроков amBrain не приводит.

amBrain делает софт с 2019 года. О том, как компания работает с клиентами, она говорит: «Три формата: полная разработка, выделенная команда или инженеры внутри вашей команды». О владении у неё такая строка: «Клиент сохраняет полное владение продуктом и кодом, кроме наших переиспользуемых компонентов». До подписания попросите поимённый список этих компонентов.

Эта статья — и не юридическая консультация. Спросите своих юристов, как законодательство о приватности применяется к тестовым наборам, собранным из данных клиентов. Если amBrain в вашем шорт-листе, задайте ему те же вопросы, что и любой другой компании.