Содержание
Построив ИИ-агента, вы всегда упираетесь в одну и ту же стену: «Хорошо, но он вообще работает?» Вы поменяли промпт, сменили модель, добавили инструмент — а механизм, позволяющий решить, стало от этого лучше или хуже на основе данных, а не интуиции, — это evals (оценки).
LLM может выдавать разный результат каждый раз для одного и того же ввода (это вероятностная модель). Поэтому релиз по принципу «вроде работает» приводит к тихим регрессиям и сбоям на пограничных случаях в продакшене. Эта статья рассказывает, что такое evals, о пяти способах измерить качество, об оценке, специфичной для агентов, и о том, как начать с малого — она написана для практиков.
Главное — за 30 секунд
Если читать только одно
1. Зачем нужны evals
Обычное программное обеспечение детерминировано: одинаковый ввод — одинаковый вывод. Именно поэтому работает юнит-тест, проверяющий, «совпадает ли вывод с ожидаемым значением». Но LLM вероятностна — даже один и тот же вопрос каждый раз возвращается сформулированным или поданным немного иначе. В терминах ИИ-агентов против RPA это не детерминированная «рука», а вероятностный «мозг», поэтому тесты на точное совпадение в чистом виде не работают.
Здесь обычно проявляются три режима отказа.
Вы вручную пробуете пару примеров и решаете, что «стало лучше». Вы так и не замечаете, что другой случай сломался.
Вы меняете промпт или модель, и только один тип ввода становится хуже. Вы узнаёте об этом из жалобы в продакшене.
«Иногда выдаёт что-то странное». Поскольку модель вероятностная, одна попытка это не воспроизведёт, и причину не отследить.
Evals предотвращают все три сразу. Подготовьте набор данных для оценки, прогоняйте на нём весь набор при каждом изменении и сравнивайте оценки — уже одно это превращает «ощущения» в «данные» и делает регрессии видимыми. Чем больше суждений вы делегируете агенту, тем сильнее evals становятся фундаментом качества — наравне с ограждениями (guardrails).
2. Что такое evals
Evals (оценки) = измерение того, работает ли вывод ИИ или поведение агента корректно и стабильно, как ожидается. Говоря по-человечески, это выставление оценок. Строительные блоки просты и разбиваются на три части.
Набор входных данных, на которых вы оцениваете. Соберите реальные примеры использования, прошлые логи и ожидаемые пограничные случаи.
Как вы превращаете вывод в оценку: точное совпадение, проверки по правилам или оценивание другим ИИ.
Оцените весь набор и сравните «до» и «после» изменения, чтобы решить, лучше стало или хуже.
Evals — это не «сделал один раз и забыл»: суть в том, чтобы прогонять их как регрессионный тест при каждом изменении промпта, модели или инструмента. Как и тестовый код, это актив, который вы наращиваете.
3. Пять способов измерить качество
Существует пять типовых подходов к оцениванию. Правило большого пальца — выбирать по характеру задачи и комбинировать несколько.
Подготовьте ожидаемый вывод (эталонную метку) для каждого входа и оценивайте по доле совпадений. Лучше всего для задач с фиксированным ответом: классификация, извлечение, да/нет.
Механически проверяйте регулярные выражения, точное совпадение, валидность JSON, наличие обязательных ключей. Сильны для контроля «всегда должен возвращать этот формат» — быстро и дёшево.
Пусть другая LLM выставляет оценку по рубрике. Для задач, где ответ не единственный: качество резюме, тон, релевантность.
Сравнивайте оценки на одном и том же наборе данных до и после изменения промпта/модели. Ловит «скрытую регрессию», когда общий показатель растёт, а часть падает.
Непрерывно оценивайте и наблюдайте живые логи. Следите за долей отказов, стоимостью, задержкой и дрейфом входных данных, чтобы рано поймать деградацию.
| Метод | Подходит для | Стоимость | Объективность |
|---|---|---|---|
| ① Эталон | Классификация, извлечение, решения | Низкая | ◎ Высокая |
| ② По правилам | Проверки формата / структуры | Низкая | ◎ Высокая |
| ③ LLM-as-judge | Резюме, генерация, качество диалога | Сред. | ○ Зависит от рубрики |
| ④ Регрессия | Обнаружение регрессий от изменений | Сред. | ◎ Относительная |
| ⑤ Мониторинг в продакшене | Обнаружение живой деградации | Сред.–высокая | ○ Постоянная |
Ключ — в послойности: «измеряйте механически то, что можно (① ②), используйте LLM-as-judge для качества, которое нельзя (③), и продолжайте прогонять через регрессию и продакшен (④ ⑤)». LLM-as-judge (③) удобен, но сама оценивающая LLM варьируется, поэтому пропишите рубрику явно и, где возможно, откалибруйте её по человеческим оценкам.
4. Оценка, специфичная для агентов
Для одиночного ответа (один ввод → один вывод) пяти способов выше достаточно. Но ИИ-агент выполняет несколько шагов, сам вызывает инструменты и по ходу принимает решения. Поэтому нужно оценивать не только итоговый вывод, но и процесс.
Достиг ли он в итоге цели (например, оформил правильную бронь)? Главная метрика агента.
Вызвал ли он нужный инструмент с правильными аргументами и в правильном порядке? Ловите ошибочные или лишние вызовы.
Разумен ли путь из шагов и решений? Оценивайте обходные пути, бесконечные циклы и ненужные повторы.
При том же успехе меньше токенов, шагов и меньшая задержка — лучше. В продакшене это важно.
Чтобы это наблюдать, нужна трассировка, фиксирующая каждый шаг (ввод, размышление, вызов инструмента, результат). Многие фреймворки и инструменты ниже поставляют трассировку и оценку вместе. Для мультиагентной конфигурации ведите иерархические трассы, чтобы точно определить, какой агент дал сбой.
5. Как начать — стройте по-малому
Идеальная платформа для evals с первого дня не нужна. Начать с набора из 20 примеров — реалистично.
- Соберите примеры отказов: сначала 10–20 «входов, которые пошли не так». Реальные логи и жалобы — золотая жила: это ядро набора evals.
- Опишите ожидаемое поведение: прикрепите к каждому входу «правильный ответ» или «условия, которые нужно выполнить». Не всё требует строгого ответа (качество измеряйте через ③).
- Выберите оценщик: проверки формата → ② по правилам; фиксированный ответ → ① эталон; качество → ③ LLM-as-judge. Одного-двух для старта достаточно.
- Прогоните один раз и зафиксируйте базовую линию: запишите текущую оценку. Это ваша точка отсчёта.
- Прогоняйте при каждом изменении: после смены промпта/модели перезапустите и сравните через ④ регрессию. Если показатель падает — не выкатывайте.
- Добавьте наблюдение в продакшене: как только всё живое, продолжайте следить за долей отказов и стоимостью через ⑤ мониторинг и возвращайте плохие реальные примеры в набор evals.
💡 Совет: смещайте набор evals в сторону «отказов, которых вы не хотите» а не «типичных успехов». Включение пограничных случаев, состязательных входов и расплывчатых запросов позволяет заранее защищаться от того, что ломается при изменении. Хорошая рубрика, как и хороший дизайн промптов, тем воспроизводимее, чем она конкретнее.
6. Частые ловушки
- Слишком маленький / слишком перекошенный набор данных: собирая только успехи, вы упускаете реальные отказы. Намеренно подмешивайте отказы и пограничные случаи.
- Слепое доверие к LLM-as-judge: оценивающая LLM тоже варьируется и имеет предвзятости. Пропишите рубрику явно и периодически калибруйте по человеческим оценкам. Остерегайтесь конфликта интересов (одна и та же модель пишет и хвалит собственный вывод).
- Взгляд только на итоговый вывод: для агентов процесс — это всё. Без вызовов инструментов, траектории и стоимости вы благословите результат, который «повезло».
- Решение по одному прогону: поскольку модель вероятностная, для важных оценок прогоняйте несколько раз и смотрите на разброс.
- Отказ от обновления evals: спецификации и сценарии использования меняются. Продолжайте добавлять в набор evals новые отказы из продакшена.
7. Ключевые инструменты
Начать можно и с собственных скриптов, но растёт число специализированных инструментов, которые совмещают трассировку и оценку. Типовые примеры (все — официальные сайты).
| Инструмент | Что делает |
|---|---|
| Anthropic Console / Evals | Тестирование и оценка промптов для Claude в интерфейсе. Также для сравнения выбора моделей. |
| OpenAI Evals | OSS-фреймворк для определения и запуска evals. Базовая форма «набор данных + оценщик». |
| LangSmith | Трассировка + оценка. Записывает каждый шаг агента, включая регрессию и мониторинг в продакшене. |
| Langfuse | OSS-наблюдаемость для LLM. Трассировка, оценка и мониторинг стоимости вместе. |
| Ragas | Оценка, специализированная для RAG (генерация с дополненным поиском): релевантность, достоверность и другое. |
Что бы вы ни использовали, суть одна: набор данных + оценщик + дисциплина сравнения. Инструменты просто упрощают это. Лучший старт — один небольшой набор evals, пусть даже в скрипте на вашей машине.
Итоги
- Что такое evals: «выставление оценок», измеряющее вывод и поведение ИИ числами — решение «лучше/хуже» по данным, а не по ощущениям.
- Зачем они нужны: LLM вероятностны и варьируются, поэтому юнит-тесты не подходят, а регрессии и пограничные случаи проскальзывают незаметно.
- Пять методов: ① эталон ② по правилам ③ LLM-as-judge ④ регрессия ⑤ мониторинг в продакшене. Измеряйте механически то, что можно, оценивайте качество с помощью LLM и продолжайте прогонять.
- Агентам тоже нужна оценка процесса: доля успешных задач, вызовы инструментов, траектория, стоимость. Трассировка — обязательное условие.
- Как начать: 20 примеров отказов. Зафиксируйте базовую линию, затем прогоняйте при каждом изменении.
Между «я это построил» и «этим можно пользоваться» лежит мост под названием evals. Если ограждения (guardrails) — это защита, останавливающая неуправляемое поведение, то evals — это нападение, которое измеряет качество и продолжает его повышать. Один небольшой набор evals превращает разработку агентов из «ощущений» в инженерию.
FAQ
В. Чем evals отличаются от обычных юнит-тестов?
Юнит-тесты проверяют, «совпадает ли вывод в точности с ожидаемым значением». Но LLM вероятностна и выдаёт разный вывод каждый раз, поэтому точное совпадение в чистом виде не работает. Evals отличаются тем, что поверх сверки с эталоном комбинируют измерения, подходящие для вероятностного вывода — проверки по правилам, оценивание с помощью LLM и наблюдение за разбросом по нескольким прогонам.
В. Можно ли доверять LLM-as-judge (оцениванию с помощью ИИ)?
Это удобно, но не серебряная пуля. Оценивающая LLM может варьироваться и быть предвзятой. Важно прописать конкретную рубрику, периодически калибровать по человеческим оценкам и разделять роли/модели для генерации и оценивания, чтобы избежать конфликта интересов. Относительное сравнение (что лучше, A или B) обычно стабильнее абсолютных оценок.
В. Сколько нужно элементов в наборе evals?
Можно неплохо стартовать с 10–20. Даже несколько помогают с относительным сравнением «поднялась оценка после изменения или упала». Реалистично — наращивать набор, добавляя отказы, найденные в продакшене. Важнее количества правильно включить отказы, исключения и пограничные случаи.
В. Действительно ли нужно оценивать «траекторию» агента?
Если вы запускаете его в продакшене — да. Даже когда итоговый вывод корректен, обходные пути, ненужные вызовы инструментов и бесконечные циклы бьют по стоимости и надёжности. Добавьте трассировку, фиксирующую каждый шаг, и смотрите на процесс вместе с долей успешных задач. Чем больше сценарий связан с правами и побочными эффектами — как сценарии автоматизации бизнеса или автоматизация облачных операций — тем больше окупается оценка процесса.
