Оценка LLM (evals)

Оценка LLM, или evals (от evaluations), — систематическое измерение качества языковых моделей и построенных на них приложений. Различают два уровня: оценку моделей на публичных бенчмарках (насколько модель умна в целом) и оценку приложения на собственном наборе задач (насколько хорошо ваша система решает вашу задачу). Второе важнее на практике: без своих тестов любое изменение промпта, модели или поиска — это гадание, а галлюцинации и регрессии обнаруживают пользователи.^[4]

Публичные бенчмарки

Ограничения бенчмарков: загрязнение (тестовые вопросы попадают в обучающие данные), насыщение (лучшие модели набирают почти максимум, и различия теряются), несоответствие реальным задачам. Высокий балл на MMLU не гарантирует хорошей работы с вашей документацией на русском языке. Для запуска стандартных бенчмарков на своих моделях используют lm-evaluation-harness и Inspect.^[2][3]

Собственный набор тестов

Основа — набор примеров (eval set): входы, которые реально приходят в систему, и критерии хорошего ответа. Рекомендации:

1. Начать с 20–50 примеров из реальных логов и известных провалов; расширять по мере появления новых ошибок.
2. Покрыть типичные случаи, крайние случаи и случаи, где правильный ответ — отказ или «не знаю».
3. Сформулировать критерии заранее и измеримо: «ответ содержит номер статьи», «JSON соответствует схеме», «нет фактов вне контекста».
4. Хранить набор в репозитории и прогонять при каждом изменении промпта, модели или параметров — как регрессионные тесты в CI/CD.

Способы проверки

• Точное совпадение и правила — для классификации, извлечения полей, структурированного вывода; дёшево и надёжно. Метрики — как в классическом ML.
• Исполнение кода — сгенерированный код запускается против тестов.
• Модель-судья (LLM-as-a-judge) — другая модель оценивает ответ по рубрике или сравнивает два ответа. Хорошо согласуется с людьми в среднем, но имеет перекосы: предпочитает длинные ответы, ответы на первой позиции и ответы собственного семейства.^[1] Помогают чёткая рубрика с примерами, бинарные вопросы вместо шкалы 1–10, перестановка порядка и выборочная проверка судьи людьми.
• Оценка людьми — эталон качества, но дорого; нужна для калибровки автоматических проверок.

# promptfoo: регрессионные тесты промпта
prompts: [file://prompts/answer.txt]
providers: [anthropic:messages:claude-sonnet-4-5, openai:gpt-5-mini]
tests:
  - vars: {question: "Какой порт у HTTPS?"}
    assert:
      - {type: contains, value: "443"}
  - vars: {question: "Сколько стоит подписка Pro?"}
    assert:
      - {type: llm-rubric, value: "Отвечает, что в документации нет этой информации, и не выдумывает цену"}

promptfoo, DeepEval, Inspect и OpenAI Evals позволяют описывать такие наборы декларативно и сравнивать модели в таблице.^[5]

Оценка RAG и агентов

Для RAG оценивают отдельно поиск (нашёлся ли нужный фрагмент: recall@k, MRR) и генерацию (опирается ли ответ на найденное — faithfulness, отвечает ли он на вопрос — relevance). Библиотека Ragas реализует эти метрики.^[7] Раздельная оценка показывает, где проблема: в чанкинге и поиске или в промпте. Для агентов важны доля успешно завершённых задач, число шагов, стоимость и безопасность действий; проверяется итоговое состояние среды, а не только текст.

В продакшене

Онлайн-оценка дополняет офлайн-наборы: явная обратная связь пользователей, косвенные сигналы (переформулировка вопроса, копирование ответа), выборочная проверка логов моделью-судьёй. Трассировку и оценку объединяют платформы вроде MLflow, Langfuse и LangSmith. Неудачные случаи из продакшена пополняют eval set — так замыкается цикл улучшений.

См. также

• Галлюцинации LLM
• Метрики качества классификации
• Промпт-инжиниринг
• RAG (генерация с дополнением поиском)
• MLflow

Источники

1. Zheng et al. — Judging LLM-as-a-Judge with MT-Bench and Chatbot Arena (2023)
2. UK AISI — Inspect
3. EleutherAI — lm-evaluation-harness
4. Anthropic — Define success criteria and build evaluations
5. promptfoo — документация
6. Jimenez et al. — SWE-bench (2023)
7. Ragas — документация