Как проверить, что ИИ-агент не ошибается: тест-набор без ML-команды

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

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

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

Что именно нужно проверять у ИИ-агента

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

Поэтому проверять нужно не только финальный ответ.

Удобно разделить тестирование на пять уровней:

1.  понимание задачи — правильно ли агент понял запрос;
2.  фактическая точность — использовал ли корректные данные;
3. выбор действия — вызвал ли нужный инструмент;
4.  исполнение — передал ли правильные параметры и выполнил ли допустимое действие;
5.  результат — получил ли пользователь то, что ему было нужно.

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

Пример

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

Запрос: «У меня не работает VPN. Создай заявку с высоким приоритетом».

Здесь можно отдельно проверить:

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

Если оценивать только финальный текст, часть этих ошибок останется незаметной.

 Тест-набор начинается не с вопросов, а с критериев

Одна из распространенных ошибок при проверке LLM — сначала собрать десятки вопросов, а потом решать, что считать хорошим ответом.

Лучше сделать наоборот.

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

Для каждого сценария достаточно зафиксировать четыре вещи:

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

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

Как собрать первый тест-набор

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

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

1. Обычные сценарии

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

Например:

• найти информацию во внутренней базе знаний;
• сформировать краткое резюме документа;
• проверить статус заявки;
• создать типовую заявку;
• подобрать нужную инструкцию.

Такие тесты показывают базовую работоспособность системы.

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

2. Неполные запросы

Пользователь не всегда формулирует задачу идеально.

Например: «Нужно оформить доступ к CRM».

Неясно, к какой CRM, кому нужен доступ и какой именно уровень разрешений требуется.

Хороший агент в такой ситуации не должен угадывать. Он должен запросить недостающие сведения или использовать заранее определенный безопасный сценарий.

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

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

3. Противоречивые инструкции

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

Например: «Создай заявку с обычным приоритетом. В конце поставь высокий приоритет».

Или пользователь просит выполнить действие, которое запрещено политикой компании.

Здесь проверяется не знание модели, а соблюдение правил агента.

4. Неверные предположения пользователя

Это особенно важно для корпоративного LLM.

Пользователь может написать: «В прошлом месяце лимит был 500 ГБ, увеличь его до 1 ТБ».

Но текущий лимит уже мог измениться.

Агент не должен автоматически принимать утверждение пользователя за факт. Он должен проверить актуальные данные, если у него есть соответствующий инструмент.

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

5. Запросы, на которые нет ответа

Добавьте в тест-набор вопросы, ответа на которые действительно нет в доступных данных.

Например: «Какие условия корпоративного тарифа компания утвердила на следующий квартал?»

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

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

6. Пограничные и опасные сценарии

Наконец, нужны тесты, в которых ошибка особенно дорого стоит.

Например:

• изменение финансовых данных;
• удаление объекта;
• отправка документа;
•  изменение прав доступа;
• публикация информации;
• работа с персональными данными;
• выполнение операции от имени другого пользователя.

Здесь критерий должен быть строже.

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

Не ограничивайтесь проверкой ответа

Для агентных систем одна из самых важных частей теста — проверка действий.

Представим, что сотрудник спрашивает: «Покажи мои последние заявки».

Агент должен обратиться к системе заявок.

Но возможны разные ошибки:

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

Финальный текст при этом может выглядеть совершенно убедительно.

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

1. Нужно ли было вызывать инструмент? 2. Правильный ли инструмент выбран? 3. Правильные ли данные переданы инструменту?

Проверка выбора инструмента и его параметров — отдельная категория оценки агентных систем, а не второстепенная деталь.

Простая таблица вместо сложной ML-системы

На первом этапе тест-набор можно вести в Excel или Google Sheets.

Например:

Главное здесь — не сама таблица, а единообразные критерии.

Не стоит оценивать один ответ по принципу «понравилось/не понравилось», а другой — по строгому чек-листу.

Как оценивать результаты

Для большинства корпоративных сценариев не требуется сложная математическая модель.

Можно использовать три уровня:

• Пройден— агент выполнил задачу корректно;
• Частично пройден — результат пригоден, но есть некритичная ошибка;
• Не пройден — агент нарушил обязательное условие или сделал потенциально опасное действие.

Отдельно отмечайте критические ошибки.

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

Поэтому для корпоративного использования полезнее смотреть не на одну итоговую цифру, а минимум на:

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

Почему один запуск ничего не доказывает

LLM — вероятностные системы. Один и тот же запрос не гарантирует абсолютно одинаковое поведение при каждом запуске.

Поэтому хороший тест нужно повторять.

Допустим, агент правильно выполняет сценарий 9 раз из 10. На первый взгляд результат неплохой. Но если речь идет о действии, которое должно выполняться безошибочно, 90% может быть совершенно недостаточно.

В исследованиях и практических руководствах по evals для агентов поэтому рассматривают не только факт прохождения теста, но и стабильность результата между несколькими попытками. Anthropic, например, отдельно выделяет показатели pass@k и pass^k для оценки вероятности хотя бы одного успешного результата и стабильного успеха во всех попытках соответственно.

Для обычной бизнес-команды не обязательно использовать эти термины. Практический вывод проще: Критический сценарий стоит прогонять несколько раз и смотреть, повторяется ли корректное поведение.

Какие тесты особенно важны при выборе LLM

Тест-набор полезен не только после внедрения.

Он помогает ответить на вопрос «какую LLM выбрать?»

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

Например, можно взять один и тот же набор из 50–100 корпоративных сценариев и прогнать его на нескольких моделях.

Сравнить:

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

То же относится к выбору между облачными и локальными LLM. Если компании важны требования к размещению данных, контролю инфраструктуры или внутренним контурам, можно сравнивать не абстрактное качество моделей, а их результативность в конкретной среде использования.

Тестируйте не только модель, но и всю систему

Это принципиальный момент.

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

Поэтому тестировать нужно не просто «модель», а связку:

модель + инструкции + данные + инструменты + ограничения + бизнес-логика.

Это особенно важно при внедрении LLM в корпоративные процессы.

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

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

Откуда брать тестовые сценарии

Не стоит придумывать весь набор с нуля. Лучший источник — реальные задачи сотрудников и пользователей.

Можно взять:

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

Отдельно полезно собирать ошибочные кейсы.

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

Как не превратить тестирование в отдельный IT-проект

Для первого этапа достаточно следующего процесса.

Шаг 1. Опишите 20–30 реальных задач

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

Шаг 2. Для каждого сценария определите обязательный результат

Что агент обязан сделать? Что ему запрещено делать?

Шаг 3. Добавьте неприятные случаи

Неполные данные, опечатки, устаревшие сведения, противоречивые инструкции, неизвестные вопросы.

Шаг 4. Проверьте инструменты

Если агент может что-то сделать, проверяйте не только его сообщение пользователю, но и само действие.

Шаг 5. Повторите критические сценарии

Не ограничивайтесь одним запуском.

Шаг 6. Зафиксируйте ошибки

Каждая существенная ошибка превращается в новый тест.

Шаг 7. Повторяйте набор после изменений

Обновили модель, промпт, источник данных или инструмент — прогоните тесты снова.

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

Что делать, если тест провален

Провал теста не всегда означает, что нужно менять LLM.

Ошибка может находиться на другом уровне.

Агент придумал факт. Возможно, проблема в источнике данных или в том, что системе не задано корректное поведение при отсутствии информации.

Агент выбрал неправильный инструмент. Проблема может быть в описании доступных инструментов или маршрутизации.

Агент вызвал правильный инструмент, но передал неправильный параметр. Стоит проверить структуру данных и правила извлечения параметров.

Агент правильно выполнил действие, но неправильно объяснил результат. Здесь уже может быть проблема генерации ответа.

Поэтому полезно фиксировать не только «тест провален», но и тип ошибки.

Это значительно сокращает путь от обнаружения проблемы до ее исправления.

Минимальный набор для первого корпоративного агента

Если времени мало, начните хотя бы с 30 тестов:

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

Затем повторите каждый критический сценарий несколько раз.

Это уже даст гораздо больше информации о надежности агента, чем субъективная проверка «мы задали ему несколько вопросов, и вроде всё работает».

Главный критерий — не идеальный ответ, а предсказуемое поведение

Проверка ИИ-агента — это не экзамен, где нужно доказать, что модель знает всё.

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

Хороший агент не обязан отвечать на каждый вопрос. Он должен:

• правильно понимать тип задачи;
• использовать актуальные данные;
• выбирать подходящие инструменты;
• не выполнять запрещенные действия;
• запрашивать недостающую информацию;
• признавать отсутствие данных;
• выдавать корректный результат;
• сохранять стабильность при повторных запусках.

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

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

Именно такой подход позволяет выстроить использование LLM в компании без отдельной ML-команды — на понятных бизнесу критериях, которые можно проверить, повторить и сравнить.

FAQ

развернуть все

Как проверить ИИ-агента без ML-команды?

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

Какие тесты нужны для ИИ-агента?

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

Какую LLM выбрать для корпоративного ИИ-агента?

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

Нужно ли тестировать LLM после каждого изменения?

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

Как понять, что ИИ-агент готов к внедрению?

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

Сколько тестов нужно для первого корпоративного агента?

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