Evals — собирательное название практик и инструментов, с помощью которых измеряют качество больших языковых моделей (LLM) и агентных систем. В эту зону входят: офлайн-бенчмарки, автоматические метрики, «LLM-as-a-Judge» (модель-судья), A/B-тесты с людьми, а также доменные проверки (код, поиск фактов, безопасность, длинный контекст, RAG и др.). Корректные evals позволяют выбирать модель, настраивать промпты, контролировать регрессии после обновлений и доказывать прогресс.
Связанные страницы: AI: общий обзор, Контекстное окно, RAG: извлечение и дополнение, LoRA (дообучение), Guardrails (защита и политика), AI Security Hub.
Зачем нужны Evals (оценка моделей и агентов)
- Сравнение моделей и настроек. Выбрать «лучший» промпт/temperature/top_p или базовую модель под задачу.
- Детекция регрессий. После обновления модели/политик/датасетов.
- Контроль качества в проде. Мониторинг метрик и алёрты по падению качества.
- Доказательство соответствия. Для заказчиков, комплаенса, сертификаций и аудиторов.
- Оптимизация затрат. Понять, когда «дешевле/быстрее» не разрушает качество.
Типы задач и подходящие метрики
| Класс задачи | Примеры | Типичные метрики/оценки |
|---|---|---|
| Точное QA / извлечение фактов | «Какой курс…», «Кто автор…» | EM (Exact Match), F1 (token/char), строгое соответствие цитате, атрибуция источника |
| Открытое QA / генерация | ответы эссе-стиля, объяснения | LLM-as-a-Judge (pairwise win rate), человеческие A/B, рубрикаторы (Likert) |
| Математика/логика | GSM8K, MATH, арифметика | Доля правильных решений, шаг-за-шагом (chain-of-thought) валидатор |
| Код | HumanEval/MBPP/интерн. задачи | pass@1 / pass@k (юнит-тесты), компиляция, покрытие тестами |
| Перевод/суммаризация | ru↔en, краткие выжимки | BLEU/chrF/COMET (перевод), ROUGE/precision-recall (извлеч.), LLM-judge |
| Длинный контекст | большие PDF, стенограммы | «Needle in a haystack», Long-bench-стили, позиционные тесты, доля найденных иголок |
| RAG/поиск | ассистент по базе статей | Answerable-rate, faithfulness/groundedness, citation-precision/recall |
| Безопасность/политики | jailbreak, токсичность | Процент блокировок/ложных блоков, токс-скоры, jailbreak-проходимость |
| Агенты/оркестрация | многошаговые задачи | Task-success-rate, время/шаги, стоимость, доля ретраев, надёжность инструментов |
Бенчмарки (ориентиры)
- Общее знание/много-доменность: MMLU, BIG-bench/BBH.
- Математика и логика: GSM8K (арифметика естественным языком), MATH, SAT-style/Logic.
- Кодирование: HumanEval, MBPP, Codeforces-подборки, внутренние задачники с юнит-тестами.
- Длинный контекст: наборы в стиле LongBench, «needle»-тесты с контролем позиции факта.
- RAG: датасеты Q/A с обязательными цитатами; практично формировать собственные золотые по вашей базе знаний.
- Безопасность и доверие: коллекции jailbreak-подсказок, токсичность/предвзятость, политические и медицинские сценарии (см. guardrails).
Важно: публичные бенчмарки полезны для ориентира, но реальные продукты почти всегда требуют собственных evals — из ваших документов, логов и кейсов.
LLM-as-a-Judge (модель как судья)
Когда нет «единственно правильного» ответа (эссе, резюме, абстракция), используют модель-судью. Практика:
- Оценивают парами (A vs B) с гибким рубрикатором (стиль, факты, полнота, вред).
- Считают win rate (сколько раз вариант B лучше A) и доверительные интервалы.
- Для снижения смещений: фиксируют системный промпт судьи, порядок ответов, обнуляют подсказки брендов, добавляют self-consistency (несколько прогонов судьи).
Комбинация LLM-judge + выборочная проверка людьми даёт на практике хорошую скорость и точность.
Человеческая оценка (Human eval)
- A/B-тесты и слепые сравнения. Респонденты видят только варианты и критерии; порядок ответов перемешивается.
- Лайкерт-шкалы под рубрики: фактичность, полезность, лаконичность, ясность.
- Калибровка асессоров и контроль межсоглашения (κ-коэффициент).
- Семплирование задач из прод-логов (репрезентативность) и стратификация по темам/языкам.
RAG-evals: что важно мерить
В системах RAG модель отвечает только на основе найденных источников.
- Retrieval Precision/Recall@k. Доля релевантных фрагментов среди вытянутых и доля найденных релевантных в целом.
- Answerable Rate. Доля вопросов, где в контексте есть достаточный факт.
- Faithfulness / Groundedness. Ответ опирается на контекст? Проверяют LLM-судьёй и/или строгими сопоставлениями с цитатой.
- Citation Precision. Корректность ссылок (не «галлюцинированные»).
- Latency и стоимость на запрос, стабильность индекса.
Хорошая практика — собирать golden-set (вопрос → кусок источника → ожидаемый ответ/цитата) из вашей базы.
Длинный контекст: отдельные evals
См. контекстное окно. Проверяют:
- Позиционную устойчивость. Вставляют «иголку» в начало/середину/конец и проверяют узнавание.
- Чувствительность к дубликатам/воде. Насколько шум «размывает» ответ.
- Стабильность при усечении истории. Скользящее окно, суммаризация старых реплик.
Код и pass@k
В кодовых задачах качество считают юнит-тестами:
- pass@1 — прошёл ли образец №1;
- pass@k — прошёл ли хоть один из k сэмплов (важно фиксировать temperature/seed).
- Дополнительно: компилируемость, покрытие тестами, время выполнения.
Метрики под рукой
| Метрика | Что значит | Где уместна |
|---|---|---|
| EM (Exact Match) | Строгое совпадение строки/ответа | Короткие факты/идентификаторы |
| F1 (token/char) | Гармоническая средняя precision/recall по токенам | Извлекаемые ответы, неточные формулировки |
| BLEU/chrF/COMET | Точность n-грамм/семантики | Перевод |
| ROUGE | Перекрытие n-грамм | Суммаризация (извлеч.) |
| Win Rate (Pairwise) | Доля побед варианта B над A | Сложные генерации (эссе, объяснения) |
| Faithfulness/Groundedness | Соответствие контексту/источникам | RAG, долгая цитируемая генерация |
| Toxicity/Harms | Токсичность/предвзятость | Безопасность/политики |
| pass@k | Доля успешных сэмплов среди k | Код/инструменты |
| Latency/Cost | Время/стоимость запроса | Прод-мониторинг |
Репрезентативные наборы (goldens)
Сердце evals — репрезентативные данные. Рекомендации:
- Брать реальные запросы из логов (с обезличиванием).
- Поддерживать стратификацию: темы, языки (ru/en), длина, чувствительность.
- Вести версионирование (v1, v2…), хранить «замороженные» копии.
- Сборка ответов-эталонов: источники, цитаты, рубрики оценки, негативные примеры.
Воспроизводимость и честность эксперимента
- Фиксируйте параметры: модель/версию, системный промпт, temperature/top_p, длину ответа, seed, число сэмплов.
- Изоляция теста: избегайте подгона промптов «под набор».
- Анти-утечки: проверка контаминации (чтобы тесты не попали в обучение/дообучение).
- Бой с «length bias»: нормализуйте длину или штрафуйте за пустые/слишком длинные ответы.
- Статистика: доверительные интервалы, бутстрэп, значимость различий.
LLM-judge: приёмы и гигиена
- Используйте чёткий рубрикатор (factuality, relevance, style, safety).
- Скройте подсказки брендов и порядок ответов; оценивайте вслепую.
- Прогоняйте несколько судей и усредняйте; добавляйте self-consistency.
- Валидируйте на ручной подвыборке (sanity-check).
Как строить eval-контур в компании
- Быстрый слой (PR-checks). Малый набор 50–200 задач, гоняется на каждый релиз промпта/правил.
- Глубокий слой. 1–5 тыс. примеров по доменам, nightly/weekly.
- Прод-мониторинг. Онлайновые сигналы: отказ-rate, жалобы, репорты «не нашёл/неправильно».
- Регистры версий. Кто и когда менял промпт/модель/правила; связка с метриками.
Инструменты и фреймворки
| Класс | Примеры/идеи использования |
|---|---|
| Библиотеки бенчмарков | lm-eval-harness-подобные наборы для запусков MMLU/ARC/HELLASWAG и др. |
| Оценка кодовых задач | Изолированные раннеры тестов, песочницы, подсчёт pass@k |
| LLM-as-a-Judge | Обвязка для pairwise-оценок, контроль подсказок/порядка |
| RAG-оценка | Скрипты для precision/recall@k, faithfulness, цитируемость |
| Дашборды | Аггрегация офлайн-метрик и онлайн-сигналов по релизам |
Типичные ошибки и как их избегать
| Ошибка | Почему плохо | Что делать |
|---|---|---|
| «Гоним только публичные бенчи» | Не отражают ваши задачи | Добавляйте собственные наборы из логов |
| Переподгон промпта под тест | Псевдопрогресс, регресс в проде | Держите замороженный golden, проверяйте переносимость |
| Оценка длиной/красотой | Побеждает «словесный» ответ | Рубрикатор, LLM-judge, факты/цитаты, penalize verbosity |
| Без контроля параметров | Нельзя повторить | Логи эксперимента, seed/temperature/top_p фиксировать |
| Нет мульти-языка | Падает качество на ru | Стратифицируйте наборы по языкам |
| Игнор RAG-контекста | «Галлюцинации» и ложные цитаты | Мерьте faithfulness и citation-precision |
Мини-плейбук для продуктовой команды
- Сформируйте golden-набор (минимум 300–500 задач) и разметьте рубрики.
- Введите PR-evals на каждый релиз промпта/правил/модели.
- Еженедельно гоняйте «глубокий» слой; храните метрики в едином дашборде.
- Для RAG — контролируйте retrieval@k и faithfulness.
- Для кода — pass@k с воспроизводимыми тестами.
- Проверяйте мульти-язык и длинный контекст отдельно.
- Смешивайте LLM-judge и маленькую долю ручной проверки.
FAQ
Что выбрать: автоматические метрики или LLM-as-a-Judge?
Комбинируйте. Для коротких фактов и кода — EM/F1/pass@k. Для открытой генерации — pairwise win rate c LLM-judge и выборочной ручной проверкой.
Почему результаты на публичных бенчах «не переносятся» в мой продукт?
Потому что данные, язык, стиль и ограничения иные. Нужны доменные evals из ваших запросов/документов.
Как оценивать «правдивость» ответа при RAG?
Используйте связку: faithfulness (LLM-judge с жёсткими указаниями «ссылаться только на контекст») + citation-precision (проверка ссылок/цитат).
Как избежать утечек тестов в обучение?
Версионируйте наборы, храните «закрытые» золотые, проверяйте поставщиков дообучения, мониторьте подозрительно «идеальные» результаты.