Оценка на LLM: Ragas, DeepEval, Promptfoo

Обновено: 14 юни 2026

Оценката на LLM модели е систематичен процес на измерване на качеството, надеждността и поведението на изхода им чрез комбинация от автоматични метрики, LLM-as-a-judge оценители и регресионни тестове върху курирани датасети, обикновено реализиран чрез инструменти като Ragas за RAG пайплайни, DeepEval за unit-стил тестове и Promptfoo за бенчмаркинг между модели. В тази статия разглеждам какви метрики реално работят през 2026, кога LLM-as-a-judge е надежден, как да интегрирате evals в CI и кои капани трябва да избягвате, с код, който можете да пуснете директно.

Без evals дебъгването на промптове и агенти се превръща в гадаене, започнете с 30 примера и метрика, която отговаря на бизнес цел.
Ragas покрива RAG-специфични метрики (faithfulness, context precision/recall, answer relevancy); DeepEval е по-добър за unit-стил твърдения; Promptfoo е силен за матрично сравнение между модели и промптове.
LLM-as-a-judge с Claude Sonnet 4.6 или GPT-4.1 като оценител е надежден при ясни критерии и pairwise сравнение, но скаларни 1–5 оценки имат висока вариация, използвайте rubric-based scoring.
Evals трябва да се изпълняват в CI на всеки PR, който променя промпт, модел или retrieval конфигурация, пробивът към production без regression suite е въпрос на време.
Hallucination/faithfulness, task completion и cost-per-task са трите метрики, които предсказват реален production проблем най-добре.

Защо LLM evaluation е критичен през 2026

Честно казано, през последните две години видях твърде много екипи, които деплойват промпт промени в production въз основа на „изглежда добре в моя ноутбук". Това работи на демо ниво и се проваля катастрофално, когато започнете да обработвате реален трафик с разнообразен контекст. Без структуриран evaluation пайплайн нямате начин да отговорите на най-важния въпрос: дали последната ми промяна подобри или влоши системата?

През 2026 средата стана значително по-сложна. Имаме reasoning модели (Claude Opus 4.8, GPT-5-thinking, Gemini 2.5 Pro), агенти с tool use, multi-step RAG и MCP базирани интеграции. Всеки от тези слоеве въвежда нови failure модове: халюцинации в reasoning chain-а, неправилни tool calls, изгубен контекст между стъпки, regression при ъпгрейд на модел. Според изследване от Stanford CRFM за 2024, моделите се различават значително по производителност между бенчмарки и реални задачи, затова собствени evals са незаменими.

Като инженер, който е оптимизирал десетки production LLM пайплайни, твърдя следното: evals са еквивалентът на unit тестове за традиционен софтуер. Не са „nice to have" — те са единственото нещо, което ви позволява да правите промени с увереност.

Какви метрики реално работят за LLM

Не всички метрики имат равностойна стойност. Класически NLP метрики като BLEU и ROUGE, базирани на n-gram overlap, са почти безполезни за съвременни LLM, модел може да даде семантично перфектен отговор с напълно различни думи и да получи 0.2 BLEU. След много експерименти, ето метриките, които реално корелират с production качеството:

Faithfulness (привързаност към контекста). Измерва дали отговорът съдържа само информация, която се поддържа от подаденото retrieval контекст. Критична за RAG системи.
Answer relevancy. Дали отговорът адресира зададения въпрос, а не реагира тангенциално.
Context precision и context recall. За RAG, дали retrieval-ът върна правилните чънкове в правилния ред.
Task completion rate. За агенти, завърши ли агентът целта без грешка.
Tool call accuracy. Извикан ли е правилният tool с правилни аргументи (за подробности вижте ръководството за function calling и tool use).
Cost per successful task. Комбинира success rate и token usage; често по-полезна от accuracy.
Latency p50/p95. Потребителското възприятие се формира от tail latency, не от средна.

Reference-free метриките (faithfulness, relevancy) са особено мощни, защото не изискват „правилен отговор" в датасета, нещо, което рядко имате в production.

Ragas срещу DeepEval срещу Promptfoo: сравнение

Трите най-използвани open-source инструмента за LLM evaluation през 2026 имат различни силни страни. Не е „избери един", обикновено ги използвам в комбинация.

Характеристика	Ragas	DeepEval	Promptfoo
Основна цел	RAG евалуация	Unit тестове за LLM	Сравнение модел/промпт
Език	Python	Python (pytest-стил)	YAML + JS/TS
RAG метрики	Отлични (роден случай)	Добри	Базови
LLM-as-a-judge	Да (вграден)	Да (G-Eval, DAG)	Да (assert types)
CI интеграция	Средна	Отлична (pytest)	Отлична (GitHub Action)
UI / dashboard	Чрез Ragas Cloud	Confident AI	Локален web UI
Synthetic data generation	Да	Да	Ограничено
Multi-model матрица	Ръчно	Ръчно	Първокласна функция
Лиценз	Apache 2.0	Apache 2.0	MIT

Кратко правило: Ragas за RAG-специфичен анализ, DeepEval когато искам evals да живеят до кода като unit тестове, Promptfoo когато решавам „кой модел / промпт варианта да избера". За production пайплайн често имам всички три.

Оценка на RAG пайплайн с Ragas

Ragas е създаден специално за RAG системи и реализира reference-free метрики, които не изискват ground truth отговори. Това е критично, събирането на ръчно написани отговори е скъпо и бавно. Ето пълен пример с Ragas 0.2+:

from ragas import evaluate
from ragas.metrics import (
    faithfulness,
    answer_relevancy,
    context_precision,
    context_recall,
)
from datasets import Dataset
from langchain_openai import ChatOpenAI

# 1. Подгответе вашия evaluation dataset
data = {
    "question": [
        "Какъв е лимитът на context window на Claude Opus 4.8?",
        "Как работи prompt caching в Anthropic API?",
    ],
    "answer": [
        "Claude Opus 4.8 поддържа 200K токена context window.",
        "Prompt caching кешира префикс на промпта за 5 минути и намалява разходите с до 90%.",
    ],
    "contexts": [
        ["Claude Opus 4.8 supports a 200,000 token context window..."],
        ["Anthropic prompt caching stores a prefix in a 5-minute TTL cache..."],
    ],
    "ground_truth": [  # опционално за context_recall
        "200K токена.",
        "Кеш с 5-минутен TTL, до 90% намаление на разходите.",
    ],
}

dataset = Dataset.from_dict(data)

# 2. Конфигурирайте LLM-оценител (използвайте по-силен модел от тествания)
evaluator_llm = ChatOpenAI(model="gpt-4.1", temperature=0)

# 3. Изпълнете evaluation
result = evaluate(
    dataset,
    metrics=[faithfulness, answer_relevancy, context_precision, context_recall],
    llm=evaluator_llm,
)

print(result)
# {'faithfulness': 0.98, 'answer_relevancy': 0.93,
#  'context_precision': 1.0, 'context_recall': 0.85}

Важно: моделът-оценител трябва да е по-силен от моделът, който оценявате, иначе оценителят често пропуска фини халюцинации. Никога не използвайте същия модел за production и за evaluation.

Unit тестове за LLM с DeepEval

DeepEval въвежда pytest-стил workflow, който позволява evals да живеят в същия repo като production кода. Това е революционно — спира ситуацията „evals в Jupyter notebook, който никой не пуска".

import pytest
from deepeval import assert_test
from deepeval.metrics import (
    AnswerRelevancyMetric,
    HallucinationMetric,
    GEval,
)
from deepeval.test_case import LLMTestCase, LLMTestCaseParams

# Custom метрика чрез G-Eval, gpt-4.1 като съдия по rubric
professionalism = GEval(
    name="Professionalism",
    criteria="Определи дали отговорът поддържа професионален тон без жаргон.",
    evaluation_params=[LLMTestCaseParams.ACTUAL_OUTPUT],
    threshold=0.7,
)

@pytest.mark.parametrize("test_case", [
    LLMTestCase(
        input="Какъв е статусът на моята поръчка #12345?",
        actual_output="Вашата поръчка е изпратена и ще пристигне утре.",
        context=["Поръчка 12345: статус=изпратена, ETA=2026-06-15"],
        retrieval_context=["Поръчка 12345: статус=изпратена, ETA=2026-06-15"],
    ),
])
def test_customer_support(test_case):
    assert_test(test_case, [
        AnswerRelevancyMetric(threshold=0.8),
        HallucinationMetric(threshold=0.3),
        professionalism,
    ])

Изпълнявате с deepeval test run test_cases.py и получавате стандартен pytest exit code, перфектно за CI. Праговете (threshold) служат като SLO: ако faithfulness падне под 0.95, билдът се проваля.

Бенчмарк на модели с Promptfoo

Когато сравнявам Claude Sonnet 4.6 срещу GPT-4.1 mini срещу Gemini 2.5 Flash за конкретна задача, Promptfoo е инструментът ми по подразбиране. Декларативната YAML конфигурация прави матричните експерименти тривиални. (Първият път, когато го пуснах в реален проект, заместих два дни ръчно тестване с 20-минутен билд.)

# promptfooconfig.yaml
prompts:
  - "Класифицирай следния тикет като [bug|feature|question]: {{ticket}}"
  - file://prompts/classifier_v2.txt

providers:
  - anthropic:messages:claude-sonnet-4-6
  - openai:chat:gpt-4.1-mini
  - google:gemini-2.5-flash

tests:
  - vars:
      ticket: "Бутонът за плащане не работи в Safari"
    assert:
      - type: equals
        value: bug
      - type: cost
        threshold: 0.001
      - type: latency
        threshold: 2000
  - vars:
      ticket: "Може ли да добавите тъмен режим?"
    assert:
      - type: equals
        value: feature
      - type: llm-rubric
        value: "Отговорът трябва да е една дума без обяснение."

Стартирате с promptfoo eval и получавате локален web UI с матрица: 2 промпта × 3 модела × N теста = моментална визуализация на trade-off между качество, цена и латентност. Документацията на promptfoo.dev е изненадващо качествена за open-source проект.

Кога LLM-as-a-judge е надежден

LLM-as-a-judge, използване на голям модел като оценител, е централна техника в Ragas, DeepEval (G-Eval) и Promptfoo. Тя обаче има известни ограничения, документирани в оригиналното Chatbot Arena изследване: position bias (предпочитат първия отговор), verbosity bias (предпочитат по-дълги отговори), self-enhancement bias (модели предпочитат собствените си стилове).

След много експерименти, ето кога LLM-as-a-judge работи добре и кога не:

Pairwise сравнение (A срещу B) с randomization. Много по-надеждно от скаларни оценки 1–5. Винаги разменяйте реда на A/B на случаен принцип.
Бинарни критерии („Съдържа ли отговорът халюцинация: да/не"). Далеч по-консистентни от градуирани оценки.
Rubric-based scoring с конкретни примери. Даване на оценителя 2–3 примера за всяко ниво на скалата намалява вариацията значително.
Не работи добре: субективни критерии без rubric, оценка на дълги отговори (>2K токена), задачи където оценителят и тестваният модел имат същите слабости.

Как се интегрират evals в CI/CD

Evals имат стойност само ако се изпълняват автоматично. Ето минимална GitHub Actions конфигурация, която съм използвал в няколко production проекта:

name: LLM Evals
on:
  pull_request:
    paths:
      - "prompts/**"
      - "src/llm/**"
      - "evals/**"

jobs:
  evals:
    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 tests
        env:
          OPENAI_API_KEY: ${{ secrets.OPENAI_API_KEY }}
          ANTHROPIC_API_KEY: ${{ secrets.ANTHROPIC_API_KEY }}
        run: deepeval test run evals/ --junit-xml results.xml
      - name: Comment results on PR
        uses: EnricoMi/publish-unit-test-result-action@v2
        if: always()
        with:
          files: results.xml

Ключови принципи: (1) eval датасетът трябва да е версиониран в repo-то, не в external dashboard; (2) праговете трябва да са в кода, не магически числа; (3) при regression PR-ът се блокира, не се мерж-ва с „ще оправя после"; (4) логнете всички фейлнали примери за човешко ревю. Тази дисциплина е разликата между AI продукт, който се подобрява, и такъв, който бавно деградира.

Оценка на агенти с tool use

Оценката на агенти е значително по-сложна от single-turn LLM evals. Агентът прави поредица от tool calls и не винаги има уникален „правилен" път до отговора. Това, което измервам в production агенти:

Task completion rate. Завърши ли агентът задачата (бинарна, оценена от LLM-judge или ground truth).
Tool call precision/recall. Извикани ли са правилните tools? Извикани ли са излишни?
Trajectory length. Брой стъпки до решение; повишение е early warning за регресия.
Argument validity. Преминават ли аргументите на tool calls schema валидация?
Recovery from errors. Когато tool върне грешка, агентът адаптира ли се или зацикля?

DeepEval вече има ToolCorrectnessMetric и TaskCompletionMetric специфични за агенти. За дълбок анализ на агентни traces, комбинирам evals с observability чрез Langfuse или Arize Phoenix. Ако строите multi-agent система, разгледайте моето ръководство за мулти-агентна оркестрация, където обсъждам как evals се вграждат в архитектурата от деня нула.

Чести грешки при оценка на LLM

Виждам същите капани отново и отново. Списък на най-скъпите:

Eval датасетът не отразява production разпределението. Курирате 50 „хубави" въпроса, които работят. Production-ът ви бомбардира с правописни грешки, multi-intent заявки и адверсариални входове. Решение: семплирайте от реален трафик.
Използване на същия модел за production и за оценител. Self-enhancement bias означава, че моделът оценява себе си твърде високо. Винаги използвайте поне един клас по-силен оценител.
Прескачане на регресионно тестване. Ъпгрейд от Claude Sonnet 4.5 към 4.6 без regression suite е руска рулетка, новите модели често имат различни failure modes.
Оценка само на „happy path". Включете adversarial примери: prompt injection опити, off-topic въпроси, празни inputs, многоезични тестове.
Фокусиране само върху accuracy. 99% точност за 5 пъти повече разход и 3 пъти повече латентност често не е победа. Винаги докладвайте accuracy × cost × latency като trio.
Третиране на evals като еднократно упражнение. Distribution drift е реален, performance, който е бил добър преди 3 месеца, може да е лош сега.

Често задавани въпроси

Каква е разликата между Ragas и DeepEval?

Ragas е специализиран за RAG пайплайни и предлага reference-free метрики като faithfulness и context precision, докато DeepEval е по-широк pytest-стил framework за unit тестване на всякакви LLM приложения (RAG, агенти, чатботове). На практика често ги използвам заедно: Ragas за дълбок RAG анализ, DeepEval за CI интеграция.

Колко примера трябва да има моят LLM eval датасет?

Започнете с 30–50 ръчно курирани примера от реален потребителски трафик, това е достатъчно за смислена обратна връзка и бърза итерация. Скалирайте до 200–500 примера, когато идентифицирате конкретни failure modes, и поддържайте отделен „adversarial" subset с поне 30 примера за prompt injection и edge cases.

Надежден ли е LLM-as-a-judge за production evaluation?

Да, при правилно настройване, но не сляпо. Pairwise сравнение с randomization и rubric-based бинарни критерии работят добре; скаларни 1–5 оценки имат твърде висока вариация. Винаги калибрирайте оценителя срещу 50–100 ръчно оценени примера и измерете Cohen's kappa спрямо човешки рейтъри, под κ=0.6 не разчитайте на него.

Защо BLEU и ROUGE не работят добре за LLM оценка?

BLEU и ROUGE измерват n-gram overlap между генериран и референтен текст, което не улавя семантично сходство. LLM може да даде перфектен отговор с различни думи и да получи нисък BLEU. Съвременните метрики като faithfulness, answer relevancy и G-Eval използват самите LLM за семантична оценка и са значително по-корелирани с човешки преценки.

Колко често трябва да изпълнявам LLM evals в CI?

На всеки PR, който променя промпт, модел, retrieval конфигурация или tool definitions. За пълния eval suite (включително по-скъпи метрики) е добре да имате nightly или weekly run срещу разширен датасет. Винаги стартирайте regression suite преди ъпгрейд на основния модел, никога не се доверявайте, че „новата версия е просто по-добра".