Files

busya d67af98363 init

2026-05-20 20:55:03 +03:00

46 KiB

Raw Blame History

ГЛАВА 14. ОЦЕНКА КАЧЕСТВА LLM-СИСТЕМ: EVALS, ТЕСТОВЫЕ НАБОРЫ И РЕГРЕССИИ

В 2005 году инженер-новичок мог выпустить код без единого теста и сказать: «у меня на машине работает». В 2015-м такое было уже неприлично — CI/CD, юнит-тесты, линтеры стали частью ремесла. В 2026 году LLM-системы находятся на том же перекрёстке. Команды меняют промпт, переключают модель, обновляют retriever — и оценивают результат фразой «вроде стало лучше». Это тот самый «works on my machine» для эпохи фронтирных моделей.

Evals — это юнит-тесты LLM-инженерии. Не в метафорическом смысле: eval-набор фиксирует ожидаемое поведение, автоматически прогоняется при каждом изменении и блокирует деплой, если качество упало. Без evals вы ведёте машину с заклеенным спидометром — может быть, хорошо, а может быть, не очень.

В предыдущих главах мы уже касались отдельных элементов оценки: агентные бенчмарки (Глава 10, §10.7), eval-метрики для RAG (Глава 12, §12.8), CoVe как верификация на лету (Глава 13), LDD как инфраструктура для сбора eval-данных из production (Глава 13, §13.3). Эта глава собирает разрозненные элементы в единую eval-дисциплину — от golden dataset до regression gate в CI/CD.

14.1. Зачем нужна eval-дисциплина

Проблема: оценка «на глаз»

Типичный сценарий: техлид просит «улучшить промпт для суммаризации». Инженер меняет системный промпт, прогоняет три примера вручную, видит, что ответы стали длиннее и подробнее, и деплоит. Через неделю приходят жалобы: модель начала галлюцинировать имена авторов. Три ручных примера не покрывали этот кейс.

Без evals вы не можете:

Детектировать регрессии: изменение, улучшившее одну метрику, может ухудшить другую.
Сравнивать эксперименты: «промпт A vs промпт B» без общего набора данных — субъективная оценка.
Обосновать выбор модели: «Claude лучше GPT для нашей задачи» — голословно, если нет числа.

Eval как контракт

Каждый eval определяет «что значит хорошо» для конкретной задачи. Это контракт между командой и системой — аналог интерфейса в typed-языке. Контракт содержит:

Входные данные — набор примеров (golden dataset).
Ожидаемое поведение — метрики и пороги (faithfulness ≥ 0.85, format validity = 100%).
Способ проверки — автоматический скоринг (LLM-judge, regex, schema validation).

Три уровня оценки

Уровень	Когда	Что проверяет	Пример
Offline	До деплоя	Качество на фиксированном наборе	CI/CD regression gate
Online	В production	Качество на реальном трафике	Мониторинг faithfulness в дашборде
Human review	По триггеру	Экспертная оценка сложных кейсов	Энтропия LLM-judge > порог → эскалация

Offline evals ловят грубые регрессии до того, как пользователи их увидят. Online evals обнаруживают drift — медленное ухудшение, незаметное на статичном наборе. Human review замыкает контур: ошибки, пойманные людьми, возвращаются в golden dataset.

14.2. Golden dataset: строительный материал evals

Структура golden dataset

Golden dataset — это набор троек (input, expected_output, context), где:

input — запрос пользователя или входные данные для пайплайна.
expected_output — эталонный ответ или набор допустимых ответов.
context — (опционально) документы, которые модель должна использовать (для RAG-сценариев).

Формат хранения — JSONL (каждая строка — один пример). Каждый пример содержит поля: input, expected_output, context, а также метаданные — tags (категория теста: factual, edge_case, multi-turn) и difficulty.

Как собирать: правило 50–100

Начните с 50–100 примеров для каждого core use case. Это минимум, позволяющий получить осмысленную статистику (см. §14.9). Источники:

Ручная курация — эксперт пишет примеры, покрывающие основные сценарии и edge-кейсы. Это самый дорогой, но самый точный способ.
Production-логи — берёте реальные запросы из LDD-логов (Глава 13, §13.3), фильтруете по success/failure, добавляете эталонные ответы. Это feedback loop: production → golden dataset → eval → production.
Синтетическая генерация — используете LLM для создания вариаций существующих примеров. DeepEval и RAGAS поддерживают генерацию синтетических тестовых данных из источников (документов, FAQ).

Версионирование

Golden dataset эволюционирует вместе с продуктом. Новые кейсы появляются, старые становятся нерелевантными. Версионируйте golden dataset рядом с промптами — в том же репозитории, в том же коммите. Diff промпта без diff'а eval-набора — полуслепое изменение.

prompts/
├── summarization_v3.txt
├── summarization_v4.txt     # новая версия промпта
evals/
├── summarization_golden_v3.jsonl
├── summarization_golden_v4.jsonl  # обновлённый eval-набор

Анти-паттерн: overfitting на eval-данные

Если вы используете golden dataset для итеративной подстройки промпта, вы рискуете overfitting'ом: промпт оптимизирован под конкретные 100 примеров, а не под задачу в целом. Решение: разделите набор на dev-split (для итерации) и test-split (для финальной оценки). Тестовый split трогается только один раз перед деплоем — точно как в ML.

14.3. Метрики: что измерять

Метрики по типам задач

Тип задачи	Ключевые метрики	Инструмент / источник
Open-ended QA	G-Eval, Faithfulness, Answer Relevancy	DeepEval, RAGAS
RAG	Context Precision, Context Recall, Faithfulness	RAGAS (см. Главу 12)
Кодогенерация	pass@k	Chen et al. 2021
Классификация / Извлечение	Exact match, F1, Precision, Recall	Стандартные ML-метрики
Суммаризация	Factuality, Conciseness (G-Eval с кастомными критериями)	Liu et al. 2023

Правило: минимум одна LLM-judge метрика + одна детерминированная метрика на каждый eval-прогон. LLM-judge ловит семантические проблемы (ответ не по теме, неполный). Детерминированная метрика ловит структурные (невалидный JSON, превышение длины, отсутствие обязательных полей).

Классические NLP-метрики: почему их недостаточно

BLEU, ROUGE и BERTScore долго были стандартом для оценки генерации текста. Для современных LLM-систем их недостаточно по трём причинам:

Низкая корреляция с человеческой оценкой на открытых задачах. BLEU измеряет n-gram overlap — два семантически эквивалентных, но по-разному сформулированных ответа получат низкий BLEU.
Неприменимость к задачам с множественными правильными ответами. На вопрос «Объясни, что такое attention» существует бесконечно много хороших ответов.
Отсутствие оценки фактуальности. ROUGE не различает грамотный текст с правильными фактами и грамотный текст с галлюцинациями.

Используйте BLEU/ROUGE/BERTScore как baseline или для задач с жёстким reference (перевод, извлечение данных), но не как основную метрику для open-ended генерации.

Пример: комбинированный eval для RAG-пайплайна

Комбинированный eval объединяет детерминированную проверку формата (валидность JSON, наличие обязательных полей) и LLM-judge метрики (faithfulness ≥ 0.85, answer relevancy ≥ 0.8, conciseness через G-Eval с кастомными критериями). Все метрики запускаются за один прогон.

Промпт для генерации: «Напиши Python-скрипт с использованием DeepEval, который: 1) проверяет формат JSON-ответа на наличие полей "answer" и "sources"; 2) оценивает faithfulness (порог 0.85), answer relevancy (порог 0.8) и conciseness через G-Eval (порог 0.7); 3) запускает все метрики через evaluate() на одном test case с retrieval context. Модель-судья — GPT-5.4.»

14.4. LLM-as-Judge

Принцип: модель оценивает модель

LLM-as-Judge — подход, при котором сильная модель оценивает output другой модели. Это как рецензирование в науке: автор (generator) пишет статью, рецензент (judge) оценивает качество. Рецензент не обязан быть соавтором — он должен быть компетентным и незаинтересованным.

Zheng et al. (2023) показали, что GPT-4 как judge достигает >80% согласия с человеческими оценками на MT-Bench — сопоставимо с inter-annotator agreement между людьми-экспертами. Это превратило LLM-as-Judge из эксперимента в production-инструмент.

G-Eval: CoT + form-filling

G-Eval (Liu et al., 2023) — метод, объединяющий chain-of-thought рассуждение с оценкой по заданным критериям. Судья получает набор критериев и инструкцию сначала пошагово обосновать оценку (CoT), затем — выставить числовой балл. G-Eval показал лучшую корреляцию с человеческими оценками на задачах суммаризации по сравнению с предшествующими автоматическими метриками.

Промпт G-Eval для оценки суммаризации:

You will be given a source document and a summary.

Evaluation criteria:
- Coherence (1-5): Is the summary well-organized and logically structured?
- Consistency (1-5): Does the summary contain only facts from the source?
- Fluency (1-3): Is the summary grammatically correct and readable?
- Relevance (1-5): Does the summary capture the key information?

Steps:
1. Read the source document carefully.
2. Read the summary.
3. For each criterion, provide a brief justification.
4. Assign a score for each criterion.

Output format: JSON with "coherence", "consistency", "fluency", "relevance" keys.

Известные bias'ы LLM-judge

Использовать модель как судью — мощно, но не безопасно без калибровки. Три основных bias'а задокументированы в литературе:

1. Position bias. Порядок ответов влияет на оценку. Wang et al. (2023) показали, что при pairwise comparison результат существенно зависит от порядка: модель, чей ответ стоит первым, систематически получает предпочтение. Судья непропорционально предпочитает первый (или последний) ответ.

2. Verbosity bias. Судья предпочитает более длинные ответы, даже если короткий ответ точнее и полнее. Длина воспринимается как «полнота».

3. Self-enhancement bias. Модель предпочитает собственные ответы. Если GPT-5.4 оценивает output GPT-5.4 vs Claude Opus 4.6, есть систематический сдвиг в пользу своих текстов.

Стратегии калибровки

Balanced Position. Запускайте каждое pairwise сравнение дважды — с обоими порядками ответов. Агрегируйте: если результат меняется при смене порядка — помечайте как tie. Если A побеждает в обоих позициях — победа надёжна.

Промпт для генерации: «Напиши асинхронную Python-функцию balanced_pairwise(judge, answer_a, answer_b), которая запускает pairwise comparison в обоих порядках (A/B и B/A). Если одна сторона побеждает в обоих случаях — возвращай победителя, иначе — tie (обнаружен position bias).»

Multiple Evidence. Генерируйте несколько rationale перед выставлением оценки. Среднее по нескольким «мнениям» одной модели более стабильно, чем единичное (аналог self-consistency из Главы 8).

Human-in-the-Loop. Вычисляйте entropy оценок судьи. Если для конкретного примера оценки нестабильны (высокая энтропия при multiple evidence) — маршрутизируйте к человеку. Судья обрабатывает 90% случаев, человек — оставшиеся 10% сложных.

Анти-паттерн: circular validation

Использовать одну и ту же модель как генератор и как судью — circular validation. Модель склонна подтверждать собственные ответы (self-enhancement bias). Правило: судья должен быть другой моделью или более сильной версией того же семейства. В production-пайплайне 2026 года типичная пара: generator = GPT-5.3 Instant (быстрый, дешёвый), judge = Claude Opus 4.6 (точный, дорогой).

14.5. Pairwise comparison и Elo-ranking

Chatbot Arena: 240K+ голосов

Chatbot Arena (lmarena.ai) — де-факто стандарт для сравнения LLM по человеческим предпочтениям. Пользователи получают анонимные ответы двух моделей и выбирают лучший. В оригинальной публикации (Chiang et al., 2024) платформа насчитывала свыше 240 000 голосов; к 2026 году объём значительно вырос. Это самая масштабная crowd-sourced оценка LLM в мире.

Почему pairwise comparison надёжнее абсолютных оценок? Людям сложно дать стабильную оценку по 5-балльной шкале: один эксперт ставит 4, другой — 3 за один и тот же ответ. Но при выборе «A лучше B» согласие экспертов значительно выше. Сравнение — более естественная операция для человеческого суждения.

Elo и Bradley-Terry

Результаты pairwise-сравнений агрегируются в рейтинг через Elo — систему, изначально разработанную для шахмат. Интуиция простая: чем больше разрыв в рейтинге между двумя моделями, тем ожидаемее победа сильной стороны и тем меньше меняется рейтинг после такой победы. Если же побеждает аутсайдер, рейтинг сдвигается заметно сильнее.

Bradley-Terry — статистически более строгая модель с той же базовой идеей: у каждой модели есть скрытая «сила», и вероятность победы определяется сравнением сил двух участников. Bradley-Terry удобен тем, что даёт confidence intervals для рейтингов — критически важно при малом количестве сравнений.

Production-применение: A/B-тестирование промптов

Тот же принцип — в вашем проекте. Вместо абсолютных оценок промптов спрашивайте: «какой из двух ответов лучше?» Это работает как для человеческой оценки, так и для LLM-as-Judge.

Промпт для генерации: «Напиши асинхронный Python-скрипт для pairwise eval двух версий промпта (v3 и v4). Для каждого примера из golden dataset сгенерируй ответы обеих версий, передай их LLM-judge для сравнения по критериям accuracy, completeness, conciseness. Подсчитай wins/ties и выведи процент побед каждой версии.»

Evalica: open-source toolkit для pairwise ranking

Evalica (Ustalov, COLING 2025) — библиотека на Python и Rust для агрегации pairwise-сравнений. Реализует Elo, Bradley-Terry, PageRank и другие алгоритмы ранжирования. Для небольших eval-наборов — достаточно Elo; для статистической строгости — Bradley-Terry с confidence intervals.

Промпт для генерации: «Напиши Python-скрипт, который загружает CSV с pairwise-результатами (столбцы: winner, loser, tie) через библиотеку Evalica, вычисляет Bradley-Terry ранжирование и выводит рейтинг моделей.»

14.6. Failure taxonomy

Девять категорий ошибок

Без классификации ошибок eval — это просто число. «Faithfulness = 0.72» — и что? Какие именно ошибки составляют те 28%? Failure taxonomy превращает число в actionable insights: вы видите, что 15% — hallucinations, 8% — format failures, 5% — retrieval failures, и знаете, что чинить в первую очередь.

Категория	Описание	Метод детекции
Hallucination	Фактически неверный контент	Faithfulness, Factuality
Format non-compliance	Невалидный JSON/XML/schema	Schema validation, regex
Instruction non-following	Игнорирование части инструкций	G-Eval с кастомными критериями
Retrieval failure	Неверный или неполный контекст	Context Precision, Context Recall
Attribution error	Ответ не подтверждается источниками	Faithfulness, entity recall
Safety violation	Токсичный, вредный, предвзятый контент	Moderation API, LLM Guard
Verbosity / compression	Слишком длинный или слишком короткий ответ	Token count, Conciseness
Reasoning error	Неверная цепочка рассуждений	pass@k, CoT verification
Multi-turn inconsistency	Противоречия между репликами в диалоге	Conversational metrics

Как использовать таксономию

Тегируйте ошибки в golden dataset — каждый пример с "expected_failure_types".
Классифицируйте отказы при eval-прогоне — не просто «fail», а «fail: hallucination».
Трекайте распределение ошибок по категориям во времени. Если после обновления промпта hallucinations снизились, но instruction non-following вырос — это не улучшение, а перераспределение.
Приоритизируйте по impact: safety violation > hallucination > format non-compliance > всё остальное.

Пример: тегирование при eval-прогоне

Алгоритм классификации: для каждого eval-результата проверяются пороги по метрикам (faithfulness < 0.7 → hallucination, невалидная schema → format non-compliance, answer relevancy < 0.5 → instruction non-following, длина > 2× ожидаемой → verbosity) и формируется список категорий ошибок.

Промпт для генерации: «Напиши Python-функцию classify_failure(test_case, actual_output, metrics), которая возвращает список категорий ошибок из таксономии (hallucination, format_non_compliance, instruction_non_following, verbosity и др.) на основе пороговых значений метрик. Также создай dataclass EvalResult с полями: test_case_id, passed, score, failure_categories, details.»

14.7. Eval-фреймворки: ландшафт 2026

Обзор инструментов

К 2026 году eval-фреймворки стали зрелой категорией. Выбор зависит от задачи: RAG-specific eval, general-purpose eval + CI/CD, pairwise ranking.

Фреймворк	Язык	Фокус	Stars (GitHub)	Ключевая особенность
Promptfoo	TypeScript	Red-team + eval	~20K	CI/CD gates, YAML-конфиг. Стал частью OpenAI (март 2026)
DeepEval	Python	Full eval	~14.7K	Pytest-интеграция, G-Eval, DAG, agentic metrics
RAGAS	Python	RAG eval	~13.3K	Context precision/recall, faithfulness
Braintrust (Autoevals)	Python/JS	Eval + observability	—	LLM-as-judge, heuristic, statistical scorers
Evalica	Python/Rust	Pairwise ranking	62	Elo, Bradley-Terry, PageRank. Быстрый (Rust core)

Promptfoo

Самый популярный eval-фреймворк общего назначения. Конфигурация через YAML, встроенная поддержка CI/CD gates, red-teaming (генерация adversarial-примеров). В марте 2026 года стал частью OpenAI, что не помешало ему остаться open-source. Подходит для команд, которым нужен eval + red-team в одном инструменте.

Репозиторий: https://github.com/promptfoo/promptfoo

DeepEval

Python-native eval-фреймворк с интеграцией в pytest — eval-тесты запускаются так же, как обычные тесты. Поддерживает G-Eval, faithfulness, answer relevancy, DAG-based metrics для агентных пайплайнов. Запуск через deepeval test run test_eval.py — exit code = количество failures, что даёт CI/CD gate из коробки. Идеален для Python-команд, которые хотят evals как часть тестового пайплайна.

Репозиторий: https://github.com/confident-ai/deepeval

RAGAS

Специализированный фреймворк для оценки RAG-пайплайнов. Реализует context precision, context recall, faithfulness, answer relevancy. Подробно разобран в Главе 12, §12.8. Для RAG-системы RAGAS — обязательный инструмент.

Репозиторий: https://github.com/vibrantlabsai/ragas

Braintrust (Autoevals)

Библиотека eval-scorer'ов от Braintrust: LLM-as-judge, heuristic (Levenshtein, JSON diff), statistical. Лёгкий, без фреймворк-оверхеда — можно интегрировать отдельные scorer'ы в любой пайплайн.

Репозиторий: https://github.com/braintrustdata/autoevals

Evalica

Минималистичная библиотека для pairwise ranking, описанная в §14.5. Rust-core обеспечивает скорость на больших наборах сравнений.

Репозиторий: https://github.com/dustalov/evalica

14.8. Regression gates: evals в CI/CD

Паттерн: prompt change → eval → gate → deploy

Regression gate — это автоматическая проверка качества, блокирующая деплой при падении метрик. Точно как CI/CD pipeline не пропускает код с красными тестами, regression gate не пропускает промпт с упавшим faithfulness.

[Prompt change] → [Git push] → [CI: run evals] → [JSON results]
                                                      │
                                               ┌──────┴──────┐
                                               │             │
                                          [Pass ✓]     [Fail ✗]
                                               │             │
                                          [Deploy]    [Block + alert]

Три стратегии gate'ов

1. Hard fail. Любой провалившийся тест блокирует деплой. Подходит для safety-критичных кейсов (медицина, финансы). Строго, но хрупко — один flaky-тест блокирует всё.

2. Threshold. Pass rate < X% блокирует деплой. Например: «не менее 90% test cases проходят faithfulness ≥ 0.8». Устойчивее к шуму, но требует калибровки порога.

3. Comparison. Текущий эксперимент сравнивается с baseline (предыдущая версия). Блокировка, если метрики ухудшились статистически значимо. Самая надёжная стратегия, но требует хранения baseline-результатов.

GitHub Actions: Promptfoo

Общий паттерн CI/CD gate: при изменении файлов в prompts/ или evals/ запускается eval-прогон, результат парсится, при наличии failures — PR блокируется.

Промпт для генерации: «Напиши GitHub Actions workflow (YAML), который при pull request с изменениями в prompts/** или evals/** устанавливает Promptfoo, запускает npx promptfoo eval --output results.json, парсит количество failures через jq и блокирует PR при failures > 0. API-ключ — из GitHub Secrets.»

DeepEval: pytest-интеграция

DeepEval работает через pytest: команда deepeval test run tests/test_eval.py возвращает exit code, равный количеству провалившихся тестов. Стандартный pytest + CI/CD = regression gate без дополнительной обвязки.

Промпт для генерации: «Добавь в существующий GitHub Actions workflow шаг, запускающий deepeval test run для файлов tests/test_eval.py. Exit code != 0 должен блокировать PR.»

Анти-паттерн: evals только в production

Запускать evals только на production-трафике — значит ждать, пока регрессия дойдёт до пользователей. Evals в CI/CD ловят проблему до деплоя. Production evals — дополнительный слой, а не замена.

14.9. Статистическая значимость

Проблема малых выборок

С eval-набором из 30 примеров вы получаете «90% accuracy». Звучит хорошо. Но какова реальная точность? На малых выборках разброс слишком широк, чтобы принимать серьёзные решения по одному числу.

Если наблюдаемое качество равно 90%, картина примерно такая:

Размер eval-набора	Примерный 95% диапазон	Что это значит
30 примеров	~79–100%	Разброс слишком широкий, gate по такому числу хрупкий
100 примеров	~84–96%	Уже можно принимать решения, но пороги стоит ставить аккуратно
200 примеров	~86–94%	Достаточно узкий диапазон для CI/CD gate и финальной валидации

Практические рекомендации

Контекст использования	Минимум примеров	Почему
Локальная итерация (dev)	50	Быстрая обратная связь, допустим широкий CI
CI/CD regression gate	100–200	Actionable CI, блокировка по порогу
Финальная валидация / A/B-тест	200+	Узкий CI, статистическая значимость

Сравнение двух промптов

Для сравнения двух промптов (A vs B) используйте McNemar's test или paired proportions test. При 100 примерах разница в 5% (90% vs 85%) может быть незначимой — нужно 200+ примеров, чтобы различить с уверенностью 95%.

Правило большого пальца: если вы не можете позволить себе 100+ примеров — используйте pairwise comparison (§14.5) вместо абсолютных метрик. Pairwise более чувствителен к различиям при малых выборках.

14.10. Trace-level и workflow-level оценка агентов

Всё, что описано выше (golden sets, LLM-as-Judge, метрики, regression gates), оценивает результат: текст ответа, извлечённые факты, классификацию. Агентные системы требуют другого уровня оценки — поведения. Агент может вернуть правильный финальный ответ, но использовать неправильные инструменты, нарушить workflow-политику или потратить десять шагов на то, что решается за два. OpenAI Evals (2025–2026) формализует traces и graders как отдельную поверхность оценки.

Что такое trace в контексте eval

Trace — полная запись поведения агента: последовательность LLM-вызовов, tool calls, решения о маршрутизации, handoff'ы между агентами, промежуточные результаты. В классическом eval оценивается пара input → output. В trace eval оценивается цепочка input → [step₁, step₂, …, step_n] → output.

Trace eval позволяет оценить четыре измерения, невидимых для output-only подхода:

Эффективность — сколько шагов потребовалось и сколько было оптимально.
Корректность маршрута — правильные ли инструменты выбрал агент на каждом этапе.
Соответствие политике — не нарушил ли агент workflow constraints (порядок действий, обязательные approval checkpoints).
Качество tool use — правильные ли параметры передал, получил ли ожидаемый результат от инструмента.

Graders для агентных trace'ов

Grader	Что оценивает	Пример
Tool choice correctness	Правильный ли инструмент выбран на каждом шаге	Агент вызвал search вместо calculator для арифметики → штраф
Handoff correctness	Корректность передачи между агентами в multi-agent системе	Задача передана triage-агенту вместо specialist → штраф
Step efficiency	Количество шагов относительно оптимального	Задача решена за 8 шагов при оптимуме 3
Policy compliance	Соответствие workflow-правилам	Агент сделал внешний API-вызов без approval checkpoint → нарушение
Environment outcome	Результат действий в среде (не только текст)	Файл создан, тест прошёл, ticket закрыт
Long-horizon success	Конечный результат задачи, требующей десятков шагов	Код-агент: PR merged и тесты зелёные

Workflow policy violations

В production агент работает в рамках политик: какие инструменты доступны, какие действия требуют подтверждения, в каком порядке должны вызываться этапы. Policy violation — это не ошибка модели в привычном смысле, а нарушение контракта. Пример: агент отправил email клиенту без прохождения через approval-этап.

Eval для policy violations строится как проверка trace на соответствие workflow DAG. Каждый шаг агента — узел графа; допустимые переходы — рёбра. Если шаг выполнен вне допустимого порядка или без required precondition — это violation, и grader фиксирует нарушение.

Практическая реализация

Trace eval требует structured logging: каждый шаг агента записывается с типом (llm_call, tool_call, handoff, decision), входными и выходными данными, timestamp. Grader может быть двух типов:

Rule-based — определить состояния workflow как конечный автомат, проверить trace на допустимые переходы, наличие обязательных этапов, ограничения на количество шагов. Быстро, детерминированно, но хрупко при изменении workflow.
LLM-based — модель-судья получает trace как структурированный лог и оценивает по критериям (эффективность, корректность маршрута, policy compliance). Гибче, но дороже и с inherent стохастичностью.

На практике оба типа комбинируются: rule-based graders проверяют hard constraints (policy violations, обязательные шаги), LLM-based — soft quality (выбор оптимального инструмента, качество промежуточных решений).

Trace eval естественно интегрируется с OpenTelemetry spans (см. Главу 17) — тот же trace, другая функция: не мониторинг, а оценка. Span'ы, собранные для observability, переиспользуются как input для eval graders.

Практический вывод

Чек-лист eval-дисциплины

#	Действие	Детали
1	Соберите golden dataset	50–100 примеров на каждый core use case. Dev-split + test-split
2	Выберите метрики	Минимум 1 LLM-judge + 1 детерминированная метрика на задачу
3	Автоматизируйте	Evals в CI/CD как regression gates. Promptfoo или DeepEval
4	Классифицируйте ошибки	9 категорий failure taxonomy. Трекайте распределение
5	Версионируйте всё	Промпты, golden datasets, eval-конфиги — в Git, в одном коммите
6	Калибруйте судей	Balanced position, multiple evidence для LLM-as-Judge
7	Обеспечьте значимость	Не меньше 100 примеров для CI gates и не меньше 200 для финальной валидации
8	Замкните feedback loop	Production failures → golden dataset → eval → production

Минимальный старт за один день

Если вы ещё не используете evals — начните с малого:

Вручную соберите 50 примеров из production-логов.
Добавьте одну метрику (faithfulness или exact match).
Напишите один test_eval.py для DeepEval.
Добавьте deepeval test run в CI.

Это не идеальная система — но это уже лучше, чем «вроде стало лучше».

Задания

Задание 1. Соберите golden dataset из 50 примеров для вашего основного use case. Используйте production-логи как источник, разделите на dev-split (35) и test-split (15). Добавьте теги по категориям (factual, edge_case, multi-turn, format) и уровню сложности. Ожидаемый результат: версионированный JSONL-файл в репозитории рядом с промптами.

Задание 2. Настройте regression gate в CI/CD: напишите eval-тест с DeepEval (одна LLM-judge метрика + одна детерминированная), добавьте deepeval test run в CI-пайплайн. Проверьте, что изменение промпта с намеренной регрессией блокирует PR. Ожидаемый результат: работающий eval gate, Который ловит регрессию при каждом PR.

Задание 3. Проведите A/B-тест двух вариантов промпта через pairwise comparison (§14.5) на вашем golden dataset. Используйте balanced position (оба порядка ответов) и LLM-judge. Оцените (сс.§14.9): достаточен ли размер выборки, чтобы различить промпты. Ожидаемый результат: числовое сравнение двух промптов с оценкой статистической значимости различий.

Задание 4. Возьмите агента из вашего проекта (или демо-агента). Записывайте structured trace каждого запуска в течение недели. Определите 3–5 workflow-правил (порядок инструментов, обязательные approval checkpoints, максимальное число шагов). Напишите rule-based grader, который проверяет trace на соответствие. Подсчитайте долю нарушений. Ожидаемый результат: набор workflow-правил, grader и статистика policy violations за неделю.

Источники

Zheng, L., et al. (2023). "Judging LLM-as-a-Judge with MT-Bench and Chatbot Arena." NeurIPS 2023. arXiv:2306.05685
Liu, Y., et al. (2023). "G-Eval: NLG Evaluation using GPT-4 with Better Human Alignment." arXiv:2303.16634
Wang, P., et al. (2023). "Large Language Models are not Fair Evaluators." arXiv:2305.17926
Shankar, S., et al. (2024). "Who Validates the Validators? Aligning LLM-Assisted Evaluation of LLM Outputs." arXiv:2404.12272
Yu, T., et al. (2025). "Self-Generated Critiques Boost Reward Modeling." NAACL 2025. arXiv:2411.16646
Chiang, W., et al. (2024). "Chatbot Arena: An Open Platform for Evaluating LLMs by Human Preference." arXiv:2403.04132
Ustalov, D. (2025). "Reliable, Reproducible, and Really Fast Leaderboards with Evalica." COLING 2025. arXiv:2412.11314
Chen, M., et al. (2021). "Evaluating Large Language Models Trained on Code." arXiv:2107.03374
Promptfoo. https://github.com/promptfoo/promptfoo
DeepEval. https://github.com/confident-ai/deepeval
RAGAS. https://github.com/vibrantlabsai/ragas
Braintrust Autoevals. https://github.com/braintrustdata/autoevals

Evals отвечают на вопрос «насколько хорошо система решает задачу». Но качество — не единственное измерение: safety eval — подмножество quality eval, но безопасность выходит за рамки оценок к архитектурным решениям. Следующая глава — о том, как защитить LLM-систему от атак, утечек и непредвиденного поведения.

Навигация:

46 KiB Raw Blame History Unescape Escape