Каждая строка такого датасета обычно описывает один тест: вход пользователя, нужный контекст, ожидаемое поведение, критерии оценки, допустимые источники, запретные действия и метки сценария. Для агента могут также проверяться tool calls, handoff, запись в CRM, JSON-формат и соблюдение guardrails.
Главная задача eval dataset - ловить регрессии. Например, поменяли модель, системный prompt или настройки RAG. После этого прогоняют один и тот же набор кейсов и видят, где агент стал ошибаться: начал галлюцинировать, хуже ссылаться на источники, дороже выполнять запросы или чаще вызывать лишние tools.
Хороший dataset для evals состоит из живых случаев, найденных ошибок и пограничных сценариев. В нем должны быть не только легкие вопросы, но и пустой контекст, конфликтующие документы, опасные запросы, неоднозначные формулировки и задачи, где правильное поведение - остановиться.
Такой dataset нужно версионировать и защищать от подгонки. Если постоянно переписывать prompt под конкретные тесты, метрики станут красивыми, но реальное качество не вырастет. Поэтому датасет лучше расширять найденными продакшен-ошибками, а не превращать в список удобных примеров.
Примеры
- В датасете для RAG есть вопрос, правильный документ, ожидаемая цитата и запрет отвечать без источника.
- Для CRM-агента тест проверяет, что агент создает задачу только после подтверждения пользователя.
- Для поддержки клиентов в набор добавляют реальные вопросы, сложные жалобы, неполные данные и сценарии handoff оператору.
- Для structured output строка eval содержит входной текст и JSON-схему, которую ответ обязан соблюдать.
- Для safety-проверки добавляют запросы на обход правил, раскрытие секретов и опасные tool calls.
- После инцидента в продакшене ошибочный сценарий добавляют в dataset, чтобы регрессия больше не вернулась.
Где используется
- регрессионное тестирование AI-агента
- сравнение моделей перед заменой
- проверка RAG и источников
- контроль hallucinations
- проверка structured output
- тестирование tool calling
- проверка guardrails и отказов
- оценка качества поддержки клиентов
- проверка стоимости и latency
- сбор кейсов из продакшен-ошибок
Связанные термины
Частые вопросы
Чем dataset для evals отличается от обычного dataset?
Обычный dataset может использоваться для обучения, анализа или хранения данных. Dataset для evals специально нужен для проверки качества и регрессий, поэтому в нем есть ожидаемое поведение и критерии оценки.
Что должно быть в одной строке eval dataset?
Входной запрос, контекст, ожидаемое поведение, критерии оценки, категория сценария, допустимые источники, запреты и при необходимости ожидаемые tool calls или формат ответа.
Сколько примеров нужно для старта?
Для первого контроля достаточно 30-50 сильных кейсов. Важно, чтобы они покрывали реальные ошибки, частые сценарии и рискованные пограничные случаи.
Можно ли использовать реальные диалоги пользователей?
Да, но перед этим нужно удалить персональные данные, секреты, коммерческую информацию и добавить понятные критерии правильного поведения.
Как не подогнать prompt под dataset?
Держите отдельный holdout-набор, версионируйте тесты, добавляйте новые кейсы из продакшена и оценивайте не только pass rate, но и причины ошибок.
Что считать хорошим результатом evals?
Не только высокий процент прохождения. Важно смотреть критичные ошибки, соблюдение guardrails, корректность источников, стоимость, задержку и стабильность между версиями.
