Оценка LLM в 2026: RAGAS и DeepEval

Обновлено: 4 июня 2026

Оценка LLM (LLM evaluation), это процесс измерения качества ответов языковой модели на наборе тестовых примеров с помощью метрик, эталонных датасетов и моделей-судей (LLM-as-a-Judge). На практике 2026 года это означает связку из четырёх компонентов: golden dataset, набор референс-фри метрик (faithfulness, answer relevance, context precision), пайплайн прогона в CI и панель регрессий. В этом руководстве я разбираю RAGAS, DeepEval, Promptfoo, LangSmith и Langfuse на одном и том же RAG-кейсе, показываю рабочий код и объясняю, почему BLEU/ROUGE в 2026 году можно выбросить.

BLEU и ROUGE для генеративных задач 2026 года не работают: они корректно ранжируют только парафразы, а не семантически разные правильные ответы.
RAGAS, лучший выбор для RAG-пайплайнов. Метрики faithfulness, answer relevance, context precision/recall и context entity recall покрывают типичные баги.
DeepEval подходит для unit-тестов LLM-приложений в pytest, поддерживает G-Eval (LLM-as-a-Judge с chain-of-thought) и интеграцию с CI.
Promptfoo, единственный фреймворк, заточенный под grid-search по промптам и моделям одновременно (YAML-конфиг, дёшево для A/B).
LangSmith и Langfuse решают другую задачу: трассировка и observability продакшена, а не офлайн-оценка. Их стоит ставить рядом, не вместо.
LLM-as-a-Judge экономит разметку, но требует калибровки. Pairwise + position-swap снимают ~80% systematic bias.

Зачем вообще оценивать LLM

Я работаю с LLM-пайплайнами с 2022 года и видел один и тот же сценарий десятки раз: команда поднимает RAG, ставит pgvector, прикручивает GPT-4 или Claude Sonnet, демо проходит хорошо, и через две недели приходит первый репорт «модель врёт, но мы не видим где». Это происходит потому, что без офлайн-оценки вы не отличаете «модель стала хуже после изменения системного промпта» от «изменился запрос пользователя». Без эвалов любое улучшение, это вера, а не инженерия.

В 2026 году ситуация ещё острее. Модели обновляются раз в 2–3 месяца (Claude Opus 4.7, GPT-5, Gemini 2.5), а API-провайдеры тихо меняют системные дефолты. Единственный способ ловить регрессии, это иметь зафиксированный набор тестов и метрик, которые прогоняются автоматически. Это и есть LLM evaluation: не «опросить редактора», а воспроизводимый процесс с числами на выходе.

Честно говоря, я скептически отношусь к подходу «just prompt it» именно потому, что без эвалов промпт-инжиниринг превращается в театр. Переставили слова, стало «вроде лучше», выкатили, поломали кейсы, которые никто не проверял. Eugene Yan хорошо описал эту проблему: качественная оценка, это первое, что нужно строить, а не последнее.

Сравнение фреймворков: RAGAS, DeepEval, Promptfoo, LangSmith, Langfuse

Прежде чем углубляться в код, разберёмся, кто из инструментов что решает. Самая частая ошибка, это пытаться использовать LangSmith как замену RAGAS или наоборот. Это разные слои стека: одни считают метрики, другие хранят трассы и дашборды.

Критерий	RAGAS	DeepEval	Promptfoo	LangSmith	Langfuse
Основной сценарий	RAG-метрики	Unit-тесты LLM	A/B промптов	Трассировка + eval	Open-source observability
Тип	Библиотека Python	Библиотека Python	CLI + YAML	SaaS	Self-host / SaaS
LLM-as-a-Judge	Да, встроено	G-Eval с CoT	Да (assertions)	Да	Да
Reference-free метрики	Отлично (faithfulness)	Хорошо	Базово	Базово	Базово
CI-интеграция	Через pytest	Нативная (pytest)	Нативная (GitHub Actions)	Через SDK	Через SDK
Цена	Open-source	Open-source	Open-source	$$ платно	Open-source / SaaS
Когда выбирать	RAG-пайплайны	Регрессионные тесты	Подбор промптов	Продакшен трейсы	Self-host observability

На реальном проекте обычно стоит комбинация: RAGAS или DeepEval для офлайн-эвалов на CI, Promptfoo для быстрого A/B перед мерджем, и Langfuse либо LangSmith для онлайн-трассировки в проде. Подробнее про устройство RAG-стека я уже разбирал в материале архитектура и продвинутые техники RAG-пайплайнов. Рекомендую прочитать его, если вы только заходите в эту область.

Какие метрики использовать для RAG и агентов

Метрики делятся на три большие группы: classical NLP (BLEU, ROUGE, METEOR, BERTScore), reference-based LLM-eval (требует эталонного ответа) и reference-free LLM-eval (требует только запрос и сгенерированный ответ). Для генеративных задач 2026 года первая группа практически бесполезна. Я несколько раз видел, как ROUGE-L «доказывал», что ответ-пересказ хуже дословной копии, хотя по смыслу он был точнее.

Метрики для RAG

Faithfulness: какая доля утверждений из ответа подтверждается извлечёнными чанками. Ловит галлюцинации.
Answer relevance: насколько ответ отвечает именно на заданный вопрос. Ловит «уход в сторону».
Context precision: какая доля извлечённых чанков релевантна вопросу. Метрика ретривера.
Context recall: насколько полно ретривер достал всё необходимое для ответа. Требует reference-ответ.
Context entity recall: покрытие именованных сущностей. Полезно для документов с большим количеством имён и ID.

Метрики для агентов

Task success: бинарная или 5-балльная оценка, завершил ли агент задачу.
Tool correctness: выбрал ли агент правильный инструмент на каждом шаге.
Trajectory match: совпадает ли последовательность действий с эталоном (по экстремуму точно, мягко с порядком).
Cost / latency: экономические метрики, без которых эваловая «правильность» уводит в дорогую продакшен-яму.

Что такое LLM-as-a-Judge и как избежать его смещений

LLM-as-a-Judge, это паттерн, в котором другая (обычно более сильная) модель оценивает ответ оцениваемой модели по заранее заданным критериям. Идея появилась в работе MT-Bench и Chatbot Arena от Zheng et al. и стала де-факто стандартом, потому что для большинства генеративных задач нет «правильного» ответа, который можно сравнить exact-match.

Проблема в том, что судьи систематически смещены. Известные баги:

Position bias: первый ответ в pairwise-сравнении выигрывает в ~60% случаев независимо от качества.
Verbosity bias: длинные ответы получают более высокие оценки.
Self-enhancement bias: GPT-4 ставит выше ответам GPT-семейства, Claude ответам Claude-семейства.
Sycophancy: если в промпте намекнуть «второй ответ кажется лучше», судья согласится.

Как с этим жить. Используйте pairwise + position-swap (прогоните оба порядка и усредните), просите судью писать обоснование до оценки (chain-of-thought существенно снижает шум), и калибруйте на ~50 размеченных примерах. Я обычно беру Claude Opus как судью для GPT-генераций и наоборот, это убирает self-enhancement.

RAGAS на практике

RAGAS, самый зрелый набор RAG-метрик, ориентированный на reference-free оценку. Минимальный рабочий пример на актуальной версии 0.2.x:

# pip install ragas==0.2.14 datasets langchain-openai
import os
from datasets import Dataset
from ragas import evaluate
from ragas.metrics import (
    faithfulness,
    answer_relevancy,
    context_precision,
    context_recall,
)
from langchain_openai import ChatOpenAI, OpenAIEmbeddings

os.environ["OPENAI_API_KEY"] = "sk-..."

# В реальности эти данные приходят из прогона вашего RAG-пайплайна.
examples = {
    "question": [
        "Какой максимальный размер контекста у Claude Opus 4.7?",
    ],
    "answer": [
        "Claude Opus 4.7 поддерживает контекстное окно 200 тысяч токенов.",
    ],
    "contexts": [
        ["Claude Opus 4.7 имеет контекстное окно 200K токенов и поддерживает prompt caching."],
    ],
    "ground_truth": [
        "200 000 токенов",
    ],
}

dataset = Dataset.from_dict(examples)

judge_llm = ChatOpenAI(model="gpt-4o-2024-11-20", temperature=0)
embeddings = OpenAIEmbeddings(model="text-embedding-3-large")

result = evaluate(
    dataset,
    metrics=[faithfulness, answer_relevancy, context_precision, context_recall],
    llm=judge_llm,
    embeddings=embeddings,
)
print(result.to_pandas())

На что обратить внимание: faithfulness и context_precision считаются без ground_truth (reference-free). context_recall требует эталон. На датасете из 200 примеров полный прогон стоит примерно $1–2 при использовании gpt-4o как судьи, что вполне приемлемо для еженощного CI.

DeepEval и unit-тесты в pytest

DeepEval, это единственный фреймворк, который ощущается как нативный pytest для LLM-приложений. Удобен, когда нужны регрессионные тесты в репозитории, а не Jupyter-блокнот. Поддерживает G-Eval (это chain-of-thought версия LLM-as-a-Judge с авто-генерацией evaluation steps) и больше двадцати готовых метрик.

# pip install deepeval==2.4.0
# tests/test_rag_quality.py
from deepeval import assert_test
from deepeval.test_case import LLMTestCase
from deepeval.metrics import (
    AnswerRelevancyMetric,
    FaithfulnessMetric,
    GEval,
)

def test_factual_answer():
    test_case = LLMTestCase(
        input="Какой размер контекста у Claude Opus 4.7?",
        actual_output="Claude Opus 4.7 поддерживает 200K токенов.",
        retrieval_context=[
            "Claude Opus 4.7 имеет контекстное окно 200K токенов."
        ],
    )

    correctness = GEval(
        name="Correctness",
        criteria="Ответ должен быть фактически точным и не противоречить retrieval_context.",
        evaluation_params=["input", "actual_output", "retrieval_context"],
        threshold=0.7,
        model="gpt-4o",
    )

    assert_test(
        test_case,
        [
            AnswerRelevancyMetric(threshold=0.75),
            FaithfulnessMetric(threshold=0.85),
            correctness,
        ],
    )

Прогон через deepeval test run tests/ или обычный pytest. Метрики имеют пороги, тест падает при их нарушении, и это и есть точка интеграции с CI. Документация DeepEval по G-Eval подробно объясняет, как калибровать критерии.

Promptfoo: grid-search по промптам и моделям

Promptfoo решает узкую, но болезненную задачу: сравнить N вариантов промпта на M моделях, посмотреть числа в табличке и выкатить лучшее. YAML-first подход делает его дешёвым в поддержке и удобным для PR-ревью.

# promptfooconfig.yaml
prompts:
  - "Ответь кратко на вопрос: {{question}}"
  - "Ты — технический эксперт. Дай развёрнутый ответ: {{question}}"

providers:
  - openai:chat:gpt-4o-mini
  - anthropic:messages:claude-haiku-4-5-20251001

tests:
  - vars:
      question: Какой размер контекста у Claude Opus 4.7?
    assert:
      - type: contains
        value: "200"
      - type: llm-rubric
        value: Ответ фактически верен и не содержит галлюцинаций
      - type: latency
        threshold: 3000
      - type: cost
        threshold: 0.01

Запуск: npx promptfoo eval, результаты в веб-UI через npx promptfoo view. Я использую его в момент, когда нужно решить «перейти ли с gpt-4o на haiku-4-5», и не хочется тащить ради этого pytest и Python-окружение.

Как собрать golden dataset

Любая оценка ровно настолько хороша, насколько хорош её тестовый набор. Я обычно строю golden dataset в три волны:

Seed (20–50 примеров): вручную написанные вопросы и ответы от доменного эксперта. Это самые ценные данные, их нельзя пропустить.
Production mining (100–500 примеров): реальные запросы из продакшен-логов, прошедшие фильтрацию по PII. Сюда добавляются варианты, которые модель проваливала.
Synthetic (опционально): RAGAS testset generator или собственный LLM-генератор для расширения покрытия. Обязательно с ручной валидацией выборкой.

Минимальный воспроизводимый набор полей: question, reference_answer (если есть), reference_contexts (если RAG), tags (категория: factual / reasoning / safety / multi-hop), difficulty. Без тегов вы не сможете объяснить, на какой подгруппе модель деградировала.

Как тестировать AI-агентов с tool use

Оценка агентов сложнее, чем оценка RAG, потому что у агента есть многошаговая траектория, и метрика «правильности конечного ответа» скрывает половину багов. У меня в практике пять обязательных уровней:

Tool selection accuracy: на каждом шаге, выбран ли правильный инструмент. Метрика отдельная для каждого шага.
Argument validity: корректны ли аргументы tool call (типы, формат, обязательные поля). Часто ловится JSON-schema валидацией без LLM-судьи.
Trajectory match: exact или fuzzy совпадение последовательности шагов с эталоном.
Final answer correctness: обычные RAG-метрики на финальном ответе.
Cost / latency budget: агент, который дал правильный ответ за 40 tool calls вместо 4, всё равно плохой агент.

В DeepEval для этого есть ToolCorrectnessMetric и TaskCompletionMetric, в LangSmith встроенная trajectory evaluation поверх трасс. Если строите свою связку, минимум: записывайте каждый tool call с inputs, outputs, latency и стоимостью в структурированный лог. Потом любая агрегация делается за полчаса.

Интеграция в CI/CD

Эвалы, которые не запускаются автоматически, через месяц мертвы. Минимальная схема для GitHub Actions, которую я ставлю на каждый проект:

# .github/workflows/llm-eval.yml
name: LLM Evaluation
on:
  pull_request:
    paths:
      - "src/llm/**"
      - "prompts/**"
      - "evals/**"

jobs:
  eval:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-python@v5
        with:
          python-version: "3.12"
      - run: pip install -r requirements.txt
      - name: Run DeepEval
        env:
          OPENAI_API_KEY: ${{ secrets.OPENAI_API_KEY }}
        run: pytest evals/ --junitxml=eval-results.xml
      - name: Comment PR with results
        if: always()
        uses: dorny/test-reporter@v1
        with:
          name: LLM Eval Results
          path: eval-results.xml
          reporter: java-junit

Несколько практических уроков, которые я набил лбом:

Запускайте на подмножестве (20–30 примеров) для PR-checks и полный (300+) ночью на main. Полный прогон на каждом PR разорит вас на API.
Кэшируйте ответы оцениваемой модели по хешу (prompt, model, temperature). Судью кэшировать тоже можно. Promptfoo это умеет из коробки.
Используйте temperature=0 и для оцениваемой модели, и для судьи. Иначе ваши «регрессии», это просто шум.
Сохраняйте сырые ответы модели в артефактах CI, без них дебажить упавший eval невозможно.

Если вы только начинаете строить эваловую инфраструктуру, начните с DeepEval + 50 ручных примеров. Не пытайтесь сразу делать pairwise Elo и synthetic generation, это вторая итерация. Первая, это просто «у нас есть числа, и они не падают между релизами».

Часто задаваемые вопросы

В чём разница между RAGAS и DeepEval?

RAGAS специализирован на метриках RAG-пайплайнов (faithfulness, answer relevance, context precision/recall) и работает как библиотека для офлайн-прогона датасетов. DeepEval, это фреймворк для unit-тестов LLM-приложений в pytest с поддержкой G-Eval и порогов для CI. На реальном проекте они часто работают вместе: RAGAS для метрик ретривера, DeepEval как раннер.

Как измерить галлюцинации LLM?

Используйте метрику faithfulness (RAGAS) или FaithfulnessMetric (DeepEval). Обе разбивают ответ на отдельные утверждения и проверяют, поддерживается ли каждое из них извлечёнными чанками. Для случаев без RAG-контекста используйте reference-based метрику: LLM-as-a-Judge с эталонным ответом и критерием factual consistency.

Можно ли заменить разметку асессоров на LLM-as-a-Judge?

Частично да, но обязательно с калибровкой. Соберите 50–100 примеров с человеческой разметкой, прогоните на них судью и считайте корреляцию (Cohen's kappa или Pearson). Корреляция выше 0.7, судье можно доверять для скрининга, но финальное A/B перед запуском всё равно лучше проверять руками.

Какие метрики использовать для RAG в 2026 году?

Минимальный набор: faithfulness (галлюцинации), answer relevance (попадание в вопрос), context precision (качество ретривера), context recall (полнота ретривера). Дополнительно для документов с большим количеством сущностей: context entity recall. BLEU и ROUGE не используйте, они корректно ранжируют только парафразы.

Чем LangSmith отличается от Langfuse?

Оба это observability-платформы для LLM-приложений с трассировкой, eval и дашбордами. LangSmith, закрытый SaaS от LangChain с глубокой интеграцией в LangChain/LangGraph. Langfuse, open-source, можно поднять self-hosted, и не привязан к LangChain. Для большинства команд выбор сводится к «нужен ли self-host».