Оценочные тесты: как проверить ваш новый AI-инструмент для команды, пока коллеги о нем не забыли

Метод «выкатим, а коллеги подскажут» вам тут не поможет

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

Жалобы ловят такие ошибки плохо даже у внешнего продукта. А с инструментом для своих — почти никаких. Тикет на внутреннего бота никто не заводит: проще спросить соседа или сделать по-старому. Либо вариант опасней: человек верит твердому ответу AI и не перепроверяет, а потом по этому ответу пишет клиенту, правит договор или считает деньги.

Учёные Гарвардской бизнес-школы и других университетов вместе с BCG наблюдали это на 758 консультантах. В задаче, которая модели была не по силам, консультанты с AI находили правильное решение на 19 процентных пунктов реже, чем без него. Авторы объясняют разницу тем, что люди доверяли уверенному и правдоподобному ответу.

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

Обычных тестов тут мало: генеративная модель на одном и том же входе может выдавать разные ответы. OpenAI в руководстве по evals так и объясняет, зачем нужен eval: качество вероятностной системы приходится измерять систематически. ML-инженер и консультант Хамел Хусейн (Hamel Husain) в эссе Your AI Product Needs Evals пишет, что у неудачных AI-продуктов почти всегда одна общая причина: не выстроена надёжная система оценки.

Чем запросы коллег отличаются от демо

Возьмём саммари писем в CRM. На демо команда даёт модели пять аккуратных писем и получает пять хороших саммари.

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

У ассистента по внутренней базе знаний — своя беда. В вики регламент 2021 года лежит рядом с новым, и оба выглядят одинаково официально.

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

В статье How evals drive the next chapter in AI for businesses (ноябрь 2025) OpenAI предлагает тот же порядок: сначала договориться, что значит «хорошо» для конкретного рабочего процесса, потом мерить это на своих данных и разбирать каждый новый тип ошибок, как только он найдётся.

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

Общая цифра вроде «модель отвечает правильно в 94% случаев» сама по себе мало что говорит. Интереснее, что происходит на ваших 200 или 2000 типичных и неудобных запросах.

Что мерить, кроме средней оценки

Красивое число в eval ещё не значит, что всё готово: качество у каждой задачи понимают по-разному.

Если AI раскладывает обращения по категориям, подойдут привычные accuracy, precision и recall. Сгенерированный текст сравнивать с эталоном бывает бесполезно: два разных ответа могут одинаково хорошо решать задачу. Тогда текст оценивают по отдельным критериям: верны ли факты, всё ли сказано, выполнена ли инструкция, подходит ли стиль.

У поиска по документам с генерацией ответа (RAG) проверяют две вещи: нашёлся ли нужный документ и опирается ли ответ на найденное. У агента прежде всего оценивают итог. Ход работы тоже полезно просматривать: не было ли лишних действий и позвал ли агент человека там, где следовало.

Отдельно считают долю тяжёлых ошибок.

Средние 95% выглядят прекрасно, пока не выясняется, что в оставшихся 5% система уверенно сообщает коллеге неверное, а тот пересылает это клиенту или подписывает документ. В таком инструменте эти 5% весят больше остальных девяноста пяти.

Ещё обычно смотрят, как часто система признаёт, что не знает ответа, вместо того чтобы придумать. Anthropic при оценке моделей Claude делила ответы на три группы: правильные, неправильные и те, где модель честно говорила, что не знает.

Для внутреннего ассистента «не уверен, позову человека» — нормальный ответ.

Где взять кейсы и как запустить пилот

Проверку удобно строить в три шага.

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

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

Google в руководстве по оценке безопасности AI-систем советует в дополнение к публичным бенчмаркам собирать собственные наборы и следить за их разнообразием: разные формулировки, длина, темы, сложность и провокационные запросы. Публичные бенчмарки безопасности, по наблюдению Google, быстро насыщаются: сильные модели набирают в них под 99%.

Десять тысяч примеров для начала не нужны: важнее, чтобы в наборе были неудобные случаи.

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

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

Сэкономленное время лучше мерить, чем спрашивать о нём. В эксперименте некоммерческой исследовательской организации METR в начале 2025 года 16 опытных разработчиков open-source-проектов с AI-помощником работали на 19% медленнее, а после эксперимента считали, что ускорились на 20%. Цифры замедления METR с тех пор назвала устаревшими, а самооценку ускорения считает ненадёжной.

Наблюдение после запуска. После релиза ошибки всё равно находятся. Найденный тип проблемы чинят и сразу добавляют в eval, чтобы в следующий раз он не прошёл незамеченным.

Раз коллеги сами не жалуются, сообщить об ошибке должно быть делом одного клика: кнопка «ответ неверный» прямо в инструменте.

OpenAI советует то же самое: сохранять запросы, ответы и то, чем всё закончилось, регулярно читать логи и отдавать сложные и спорные случаи экспертам.

Чего инструменту для своих нельзя ни при каких условиях

Eval отвечает на вопрос, насколько хорошо работает система. Ограничители (guardrails) — на вопрос, чего ей делать нельзя.

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

Во внутреннем инструменте главное ограничение — права доступа. Ассистент, который ищет по общей базе документов, не должен показывать человеку то, что тот не может открыть сам: зарплаты, документы HR, сделки соседнего отдела. Если в хранилище права выданы «всем, на всякий случай», модель честно найдёт и перескажет всё. Поэтому Microsoft в плане подготовки к Copilot первым шагом ставит чистку избыточного доступа.

Второе — действия. Агент, который сам меняет записи в CRM или ERP, заводит заявки или пишет клиентам от имени сотрудника, должен спрашивать подтверждение там, где ошибку не отменить.

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

Различать eval и ограничители полезно потому, что «у нас есть ограничитель» ничего не говорит о качестве ответов. А высокая оценка в eval не гарантирует, что в редком сценарии система не сделает запрещённого.

Сколько проверок нужно именно вашему инструменту

Большой конвейер оценки нужен не каждой задаче.

Когда AI предлагает пять вариантов заголовка для черновика внутреннего документа, ошибка практически ничего не стоит: человек сам выбирает, а плохой вариант просто удаляет. Черновик письма клиенту, которое коллега отправит почти не глядя, обходится дороже. А агент, который сам меняет данные во внутренних и внешних системах, может натворить такого, что уже не отменишь.

Объём проверок разумно привязывать к цене ошибки и к тому, можно ли её отменить, а не к модности технологии:

• Ошибка стоит мало: небольшой набор кейсов, ручная проверка, простой мониторинг.
• Средне: автоматический прогон набора, пилот в одном отделе, рабочие метрики, несколько ограничителей.
• Дорого: отдельные сценарии отказа, провокационные тесты, проверка экспертами, ограниченная самостоятельность и постоянный мониторинг.

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

Если инструмент отвечает внешним клиентам, вся шкала сдвигается на ступень вверх.

Что проверить перед запуском

Перед первым запуском команде нужно ответить на восемь вопросов.

1. Что мы называем хорошим результатом? Несколько конкретных критериев вместо «ответ выглядит нормально». Записывать их лучше вместе с будущими пользователями.
2. Какие ошибки обойдутся дороже всего? Каждая из них — отдельный тестовый сценарий.
3. Есть ли набор реальных кейсов? Его собирают до запуска, а не после первой тысячи пользователей.
4. Как мерить качество? Хотя бы несколько метрик, связанных с задачей инструмента.
5. Чего система не должна делать никогда? Это работа для ограничителей. И отдельно: видит ли система только то, что пользователь может открыть сам.
6. Что, если набор кейсов пройден, а в работе всё иначе? Нужны логи, метрики пилота и понятный путь, по которому новые провалы попадают в тестовый набор.
7. Можно ли запускать постепенно? Пилот в одной команде даёт настоящий сигнал без того, чтобы сразу пересаживать на инструмент всю компанию.
8. Как коллега сообщит, что ответ неверный? Если для этого нужно писать в другой чат, он не сообщит.

Сам eval тоже бывает плохим. METR в августе 2025 года вручную проверила решения агента для open-source-проектов: ни одно из них не годилось к слиянию без доработки — даже те, что прошли тесты мейнтейнеров. Не хватало тестов, документации, порядка в коде.

Что почитать и пройти дальше

Для тех, кто хочет собрать eval сам.

Разобраться в подходах. Evaluating Large Language Model Outputs: A Practical Guide — небольшой курс на Coursera с демонстрациями на Google Vertex AI. Разбирает основные способы оценки LLM: автоматические метрики, попарное сравнение ответов моделью-оценщиком (AutoSxS) и оценку людьми. Может подойти, если процесс оценки только начинает складываться. Это обзор подходов: собирать проверки под свой стек придётся самим.

Собрать первый eval руками. Testing AI Systems with DeepEval: AI Agents, Chatbots & RAG — прикладной курс на Udemy. Показывает, как тестировать агентов, чат-ботов и RAG-системы с открытой библиотекой DeepEval, собирать эталонные наборы и проверять, насколько ответ относится к вопросу и опирается ли на найденные документы. Это вариант для тех, кому после статьи хочется открыть IDE. Курс построен вокруг одной библиотеки; если у вас другой инструмент, переносить придётся только идеи.

Увидеть общую инженерную картину. Книга Чип Хьюен (Chip Huyen) Designing Machine Learning Systems — о машинном обучении в продакшене вообще: как данные, метрики, мониторинг, требования продукта и архитектура складываются в работающую систему и почему её строят итерациями. Вышла в 2022 году, до волны LLM-инструментов, поэтому оценке генеративных моделей места в ней почти нет.

С чего начать

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

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