Eval: оценка качества LLM-приложений

Короткая версия

У production eval в 2026 обычно есть 5 частей:

1. Dataset: реальные задачи, edge cases, failure cases, negative examples.
2. Checks: exact match, schema validity, regex, guardrails, PII/safety checks.
3. LLM grader: judge-модель оценивает качество, полезность, faithfulness или policy compliance.
4. Human calibration: люди проверяют, что grader не уехал и метрики правда что-то значат.
5. Regression gate: PR или deploy блокируется, если ключевая метрика падает.

Что реально работает

• маленький, но живой dataset из production;
• отдельные scorers под разные аспекты качества;
• judge fixed across experiments;
• human spot-check на спорных кейсах;
• регулярное пополнение набора плохими ответами из логов.

Что ломает eval

• один общий “quality score” на всё приложение;
• judge той же модели без калибровки и без baseline;
• только synthetic cases без реальных фейлов;
• отсутствие regression thresholds;
• попытка мерить subjective usefulness одной autometric.

Input: «Можно ли вернуть электронику без чека?»
Context: «Возврат электроники — 7 дней. Чек обязателен.»
Model answer: «Да, вернуть можно в течение 14 дней, чек не нужен.»

Проверки:
1. factual correctness
2. policy compliance
3. confidence in answer

1. Что такое хороший eval в 2026

Current guidance у OpenAI и Anthropic сходится на одной идее: eval должен быть task-specific. Не существует единой магической метрики “качество LLM”. Есть разные типы задач:

• factual QA;
• RAG with citations;
• tool calling;
• structured outputs;
• policy adherence;
• coding;
• agent traces;
• customer support / workflow completion.

Поэтому лучший eval-набор почти всегда собирается не “по учебнику”, а из:

• типовых запросов;
• самых дорогих ошибок;
• edge cases;
• production failures;
• adversarial / safety cases.

2. Из чего обычно состоит eval pipeline

Dataset

Dataset должен отвечать на вопрос: что именно мы хотим не сломать?

Минимальный practical состав:

• happy path;
• hard but valid;
• insufficient context;
• policy-sensitive;
• format-sensitive;
• known regressions.

Scorers

В 2026 почти всегда используют несколько scorers сразу:

Baseline и thresholds

Eval без baseline быстро превращается в “цифры ради цифр”. Нужны:

• baseline текущей production-версии;
• минимально допустимые thresholds;
• явные release gates;
• отдельные метрики для critical failures.

3. LLM-as-judge: по-прежнему полезно, но не магия

LLM-as-judge остаётся рабочим инструментом, но его давно не стоит подавать как универсальный oracle.

Что в нём полезно:

• быстро масштабируется на сотни и тысячи кейсов;
• удобно для rubric-based оценки;
• хорошо работает на pairwise comparison;
• помогает оценивать аспекты, которые трудно формализовать кодом.

Что важно в 2026:

• judge лучше держать стабильным в рамках эксперимента;
• judge желательно калибровать на human-reviewed subset;
• на high-stakes сценариях judge не должен быть единственным источником truth;
• полезно разводить judge и target system по model family или хотя бы по snapshot.

Как выбирать judge

Старое правило «судья должен быть строго сильнее вашей модели» полезно как эвристика, но слишком грубо. Более практичная версия:

1. Judge должен быть как минимум не слабее по типу задачи.
2. Judge должен быть зафиксирован на время сравнения версий.
3. Judge нужно периодически сверять с human labels.
4. Для high-stakes задач полезно иметь second-opinion judge или human review lane.

Это значит, что в 2026 judge-слой обычно строят вокруг сильных current моделей вроде GPT-5.4, Claude Opus 4.6, Claude Sonnet 4.6 или Gemini 2.5 Pro, но сама модель важна меньше, чем calibration discipline.

4. Human eval никуда не делся

Человеческая оценка всё ещё нужна как минимум в трёх случаях:

• вы запускаете новый grader и хотите проверить корреляцию;
• задача субъективна: тон, полезность, “насколько ответ внушает доверие”;
• ошибка дорогая: финансы, юриспруденция, медицина, compliance.

В production это обычно выглядит так:

• автоматический eval гоняется на всём наборе;
• 20-50 кейсов из спорной зоны уходят человеку;
• human labels обновляют baseline и помогают перенастроить grader rubric.

5. Agent eval и trace grading

Новая норма 2026: если система использует tools, memory, retrieval и multi-step planning, одного финального ответа уже мало.

Нужно отдельно оценивать:

• правильность выбора инструмента;
• лишние tool calls;
• пропущенные обязательные steps;
• groundedness промежуточных рассуждений;
• итоговую outcome success rate.

Именно поэтому trace grading стал важнее: вы оцениваете не только final answer, но и trajectory.

6. Frameworks: что для чего брать

Promptfoo

Promptfoo по-прежнему хорош как быстрый CLI-first слой для prompt regression, assertions и red teaming. Это удобный выбор, если вам нужен eval как часть developer workflow без тяжёлой платформы.

Braintrust

Braintrust силён там, где нужны experiments, dataset management, сравнение runs и closer integration с production traces. Это уже ближе к полноценной eval-платформе.

DeepEval

DeepEval удобен, если команда мыслит через Python/pytest и хочет встроить eval прямо в test suite. Он особенно полезен для RAG-метрик и CI-friendly сценариев.

Сравнение

7. Как строить regression gate

Хороший release gate редко опирается на одну среднюю метрику.

Практический шаблон:

• schema_valid_rate >= 99%
• critical_policy_failures = 0
• judge_score_avg >= baseline - 0.05
• hard_case_subset >= baseline
• latency_p95 и cost_per_case не вышли за допустимые рамки

То есть eval в 2026 уже почти всегда связывается не только с quality, но и с economics/latency.

8. Откуда брать dataset

Лучшие кейсы почти всегда приходят не из brainstorm-сессии, а из production:

• thumbs down;
• escalation tickets;
• manual QA;
• failed tool runs;
• hallucinated answers;
• bad retrieval cases;
• невалидный JSON;
• жалобы на тон и policy.

Хорошая практика:

1. Каждую неделю добавлять 5-10 новых плохих кейсов.
2. Помечать critical vs non-critical failures.
3. Держать отдельно smoke set, regression set и release set.

Production-паттерны

Минимальная структура eval-case

from dataclasses import dataclass

@dataclass
class EvalCase:
    input: str
    expected: str | None = None
    rubric: str | None = None
    tags: list[str] | None = None

Judge через API

from openai import OpenAI

client = OpenAI()

def judge_answer(question: str, answer: str, rubric: str) -> str:
    response = client.responses.create(
        model="gpt-5.4",
        input=[
            {
                "role": "developer",
                "content": (
                    "Ты eval-grader. Верни JSON с полями "
                    "score, verdict, rationale. Оценивай только по rubric."
                ),
            },
            {
                "role": "user",
                "content": (
                    f"Question: {question}\n"
                    f"Answer: {answer}\n"
                    f"Rubric: {rubric}"
                ),
            },
        ],
    )
    return response.output_text

Regression gate

def passes_release_gate(metrics: dict, baseline: dict) -> bool:
    if metrics["schema_valid_rate"] < 0.99:
        return False
    if metrics["critical_policy_failures"] > 0:
        return False
    if metrics["judge_score_avg"] < baseline["judge_score_avg"] - 0.05:
        return False
    return True

Практика по наборам

DATASETS = {
    "smoke": 20,       # быстрый PR-check
    "regression": 100, # ежедневный прогон
    "release": 300,    # перед важным релизом
}

Практический шаблон

У нас RAG-ассистент поддержки. После смены retrieval strategy ответы стали короче, но команда не уверена, выросло ли качество. Как построить eval?

Проверьте себя