Простыми словами
Evals - это способ проверять ИИ на контрольных примерах. Не “кажется, модель стала лучше”, а нормальная проверка: дали одинаковые задачи, сравнили ответы, посмотрели ошибки и решили, можно ли выкатывать изменения.
Представьте, что у вас есть AI-ассистент поддержки. Вы меняете промпт, подключаете новую модель или обновляете базу знаний. На одном красивом примере все может выглядеть отлично, но на реальных вопросах клиентов качество внезапно проседает. Evals нужны, чтобы увидеть это заранее.
Проще говоря, evals превращают качество ИИ из ощущения в процесс.
Почему нельзя проверять на одном вопросе
Один удачный ответ ничего не доказывает. Модель может хорошо ответить на знакомый вопрос и провалиться на похожем, но чуть иначе сформулированном.
Например, вы проверили ассистента вопросом “как оформить возврат?” и получили хороший ответ. Но пользователь может спросить “что делать, если товар не подошел?”, “когда вернут деньги?”, “можно ли вернуть товар без чека?” или “почему мне отказали?”. Для человека это одна тема, а для системы это разные сценарии.
Evals собирают такие варианты в набор примеров. Тогда вы проверяете не один демо-ответ, а поведение системы на реальной группе задач.
Что такое eval dataset
Eval dataset - это набор контрольных случаев. Обычно в нем есть вопрос пользователя, нужный контекст, ожидаемый результат и критерии хорошего ответа.
Для поддержки это могут быть реальные обращения клиентов. Для RAG - вопросы по базе знаний. Для AI-агента - сценарии, где он должен выбрать tool, запросить approval или передать кейс человеку.
Хороший dataset не обязан быть огромным. Для старта лучше взять 30-50 реальных и важных примеров, чем сотни искусственных легких вопросов. Главное, чтобы в наборе были обычные случаи, сложные случаи и ситуации, где ошибка дорого стоит.
Что считается хорошим ответом
Главная часть evals - критерии. Нужно заранее понять, что значит “хорошо”.
Иногда критерий простой: JSON валидный, обязательное поле есть, нужный документ найден, tool выбран правильно. Иногда сложнее: ответ должен быть точным, понятным, без выдуманных фактов, в нужном тоне и с опорой на документ.
Плохой критерий звучит как “ответ нормальный”. Хороший критерий звучит конкретнее: “ответ не обещает возврат денег без подтверждения”, “ссылается на политику возврата”, “если данных нет, предлагает обратиться к оператору”.
Чем понятнее критерии, тем меньше споров и тем полезнее проверка.
Baseline и сравнение версий
Baseline - это текущая рабочая версия системы. С ней сравнивают новую.
Допустим, вы хотите заменить модель на более новую. Нельзя просто включить ее и надеяться, что она лучше во всем. Новая модель может красивее писать, но хуже держать JSON. Может быстрее отвечать, но чаще придумывать. Может быть дешевле, но хуже понимать русский язык в вашей теме.
Evals помогают сравнить версии на одном и том же наборе задач. Если новая версия лучше по важным метрикам и не ломает старые сценарии, ее можно выкатывать спокойнее.
Regression evals
Regression evals проверяют, не сломалось ли то, что уже работало.
Это особенно важно для ИИ, потому что маленькая правка промпта может улучшить один ответ и испортить десять других. В обычном коде для этого есть регрессионные тесты. В LLM-приложениях нужна похожая практика, только проверяются не функции, а поведение модели.
Например, после обновления базы знаний ассистент стал лучше отвечать на новые вопросы, но начал путать старые правила возврата. Regression evals должны поймать такую поломку до пользователей.
RAG evals
Если система отвечает по документам, нужно проверять не только финальный текст, но и поиск.
Модель может дать плохой ответ не потому, что она слабая, а потому что RAG нашел не тот фрагмент. Или нужный документ есть, но не попал в контекст. Или попал устаревший текст. В такой ситуации переписывать промпт бесполезно: надо чинить retrieval, chunking, фильтры или базу знаний.
RAG evals помогают понять, где проблема: модель плохо сформулировала ответ или система вообще не дала ей нужные данные.
Tool evals
Для AI-агентов важно проверять tool calling. Агент может правильно понять текст, но выбрать не тот инструмент, передать неверный id сделки или попытаться выполнить действие без approval.
Например, агент поддержки должен создать задачу менеджеру, а не отправить письмо клиенту. Агент для CRM должен обновить нужную карточку, а не похожую. Агент для документов должен запросить подтверждение перед отправкой договора.
Tool evals проверяют не красоту ответа, а правильность действия. Это критично, когда ИИ связан с реальными системами.
Safety evals
Safety evals проверяют опасные и нежелательные сценарии. Модель просят раскрыть системный промпт, обойти правила, выдать секреты, выполнить опасный tool, поверить вредной инструкции из документа или ответить без источника.
Такие проверки нужны не для паранойи, а для нормальной эксплуатации. Если агент работает с клиентами, CRM, документами, деньгами или персональными данными, он должен уметь безопасно отказывать, просить подтверждение и передавать спорные случаи человеку.
Промпт “будь осторожен” помогает, но не заменяет safety evals и guardrails.
Автоматическая и ручная оценка
Часть evals можно автоматизировать. Например, проверить валидность JSON, наличие поля, совпадение enum, отсутствие запрещенной фразы или выбор нужного tool.
Но не все качество можно измерить автоматически. Тон ответа, понятность, полезность, стиль бренда и юридические нюансы часто лучше оценивает человек.
Хороший процесс обычно смешанный: автоматические проверки ловят быстрые и формальные ошибки, а ручная оценка смотрит смысл. Для больших наборов иногда используют LLM-as-judge, когда другая модель оценивает ответ по рубрике. Это удобно, но такой судья тоже может ошибаться, поэтому его стоит калибровать ручными проверками.
Production evals
Evals не заканчиваются перед запуском. После запуска реальные пользователи быстро находят случаи, о которых команда не подумала.
Если ассистент ошибся в реальном диалоге, хороший процесс не ограничивается ручной правкой промпта. Сначала находят trace, понимают причину, добавляют этот случай в dataset, исправляют систему и прогоняют regression evals.
Так каждая реальная ошибка становится защитой от повторения. Это и есть зрелый подход: не просто чинить симптомы, а пополнять контрольный набор.
Когда запускать evals
Evals нужны перед первым релизом и после любых изменений, которые могут повлиять на поведение: смена модели, правка системного промпта, обновление документов, изменение RAG, подключение tool, добавление guardrails или новая версия agent workflow.
Не каждое маленькое изменение требует огромного тестового цикла. Но важные production-сценарии должны проходить хотя бы короткий regression-набор. Иначе команда каждый раз играет в “вроде стало лучше”.
Короткий вывод
Evals - это контроль качества для ИИ. Они помогают понять, отвечает ли модель правильно, не выдумывает ли, находит ли документы, выбирает ли нужные tools и не ломается ли после изменений.
Начать можно просто: собрать реальные вопросы, описать критерии, зафиксировать baseline и сравнивать новые версии с ним. Даже маленький eval dataset лучше, чем проверка по одному красивому примеру.
Без evals AI-продукт развивается на ощущениях. С evals - на фактах.
Частые вопросы
Evals - это обычные unit-тесты?
Нет. Unit-тесты проверяют код. Evals проверяют поведение ИИ: качество ответа, RAG, tool calling, формат, безопасность и полезность результата.
Сколько примеров нужно для старта?
Для первого набора часто хватает 30-50 хороших реальных примеров по одному сценарию. Потом dataset нужно пополнять ошибками из production.
Можно ли доверять LLM-as-judge?
Можно использовать, но не слепо. Модель-судья ускоряет оценку, но ее надо проверять ручными оценками, особенно в рискованных темах.
Что важнее: точность или стоимость?
Зависит от задачи. Для внутренней подсказки важна скорость и цена, для ответа клиенту или действия в CRM важнее качество и безопасность. Поэтому лучше смотреть несколько показателей вместе.
Нужны ли evals маленькому проекту?
Да, просто в легком виде. Таблица с реальными вопросами, ожидаемыми критериями и результатами уже сильно лучше, чем проверка “на глаз”.
