Як виміряти якість RAG: метрики, інструменти та перший evaluation pipeline — гайд 2026

Ви побудували RAG-систему, відповіді генеруються, retrieval працює. Але як дізнатися, чи працює він на 90% запитів чи на 55%? Eyeball evaluation не скейлиться: variance між ревьюерами, нульове покриття edge cases, неможливість відловити регресії. Спойлер: п'ять метрик + 50 тестових питань + один eval-прогін — і ви отримаєте діагностичну картину за пару годин. Далі — формули, код, порогові значення і CI/CD інтеграція.

📚 Зміст статті

• 📌 1. Чому eyeball evaluation не скейлиться
• 📌 2. 5 метрик якості RAG: retrieval + generation
• 📌 3. Тестовий набір: категорії, synthetic generation, ground truth
• 📌 4. RAGAS vs DeepEval: архітектура, код, вартість
• 📌 5. Evaluation на Ollama: що працює, де деградація
• 💼 6. Інтерпретація результатів: пороги, кореляції, діагностика
• 💼 7. CI/CD інтеграція: regression suite, nightly runs
• ❓ Часті питання (FAQ)
• ✅ Висновки

🎯 Розділ 1. Чому eyeball evaluation не скейлиться

Якщо ви не можете назвати число — ви не контролюєте систему. Ви реагуєте на скарги.

Ручна перевірка працює на етапі прототипу, але ламається при масштабуванні. Ось три конкретні причини.

Покриття: 5 питань ≠ evaluation

RAG з accuracy 50% може правильно відповісти на 5 із 5 випадкових питань з ймовірністю ~3%. Мінімальний набір для статистично значущих висновків — 50 питань. При 200–500 питаннях ви отримуєте стабільні метрики, які не стрибають між прогонами (PremAI, 2026).

Variance: люди оцінюють по-різному

Дослідження LLM-as-a-Judge показують, що навіть GPT-4o як scorer досягає ~80% agreement з людськими експертами (Let's Data Science, 2025). Між людьми-ревьюерами agreement ще нижчий — особливо на питаннях faithfulness і relevancy, де оцінка залежить від інтерпретації контексту. LLM-judge принаймні консистентний: однакові inputs дають однакові scores.

Regression detection: неможливо без baseline

Ви змінили chunk size з 512 на 1024 токенів. Якість покращилась? Погіршилась? Без числового baseline ви цього не знаєте. Evaluation pipeline дозволяє порівнювати конфігурації A/B і бачити delta по кожній метриці. Це не luxury — це інженерна гігієна.

Висновок розділу: eyeball evaluation — це confirmation bias з додатковими кроками. Переходимо до метрик.

📌 Розділ 2. 5 метрик якості RAG: retrieval + generation

Retriever metrics показують, чи знайшли правильні документи. Generator metrics — чи правильно їх використали.

RAG Triad: як метрики утворюють систему

Метрики RAG — це не ізольований список. Вони утворюють трикутник контрольних точок на шляху даних від запиту користувача до фінальної відповіді. Кожне ребро трикутника — це окремий failure mode, і кожне покривається своєю групою метрик:

                    ┌──────────┐
                    │  Query   │
                    └────┬─┬───┘
                         │ │
       Context Recall /  │ │  Answer
       Context Precision │ │  Relevancy
       NDCG@K            │ │
                         │ │
                    ┌────▼─┴───┐
    ┌───────────────┤ Context  ├───────────────┐
    │               └──────────┘               │
    │                                          │
    │            Faithfulness                   │
    │                                          │
    │               ┌──────────┐               │
    └──────────────►│  Answer  │◄──────────────┘
                    └──────────┘

• ✔️ Query → Context (ребро retrieval): Context Recall, Context Precision, NDCG@K — наскільки якісний "сировинний матеріал", який отримав generator? Якщо тут проблема — навіть ідеальний LLM не допоможе.
• ✔️ Context → Answer (ребро generation): Faithfulness — чи generator використав саме той контекст, який отримав? Чи не нагалюцинував фактів, яких немає у retrieved chunks?
• ✔️ Query → Answer (ребро end-to-end): Answer Relevancy — чи вирішена проблема користувача? Відповідь може бути faithful контексту, але не відповідати на питання.

Чому це важливо інженерно: якщо ви бачите низький score на одному ребрі — ви одразу знаєте, який компонент pipeline потребує уваги. Низький Context Recall? Проблема в retriever — chunking, embedding model, top_k. Низький Faithfulness при високому Recall? Проблема в generator — prompt, модель, temperature. Низький Answer Relevancy при високому Faithfulness? Prompt не фокусує LLM на питанні. Діагностична таблиця з повними комбінаціями — у Розділі 6.

Тепер розберемо кожну метрику детально.

Метрика 1: Context Recall (Query → Context)

Вимірює, яка частка фактів із еталонної відповіді (ground truth) може бути знайдена у retrieved context. Потребує reference answer — це reference-based метрика.

Формула: Context Recall = (кількість фактів з ground truth, знайдених у context) / (загальна кількість фактів у ground truth).

Що діагностує: низький Context Recall (< 0.7) означає, що retriever не знаходить потрібні документи. Причини: поганий chunking, невідповідна embedding model, недостатній top_k.

Зв'язок з іншими статтями: якщо Context Recall низький — проблема в retrieval pipeline. Див. Chunking Strategies і Embedding Models.

Метрика 2: Context Precision (Query → Context)

Оцінює, чи знаходяться релевантні чанки на початку ranked list, а не розмазані по всьому top-K. Важлива для систем, де LLM обробляє контекст послідовно — чанки на початку мають більшу вагу. Детальніше читайте у статті про контекстне вікно LLM.

Формула: зважена precision, де позиція кожного релевантного чанка у ranked list впливає на score. Чим вище релевантний чанк — тим вищий precision.

Що діагностує: високий Recall + низький Precision = retriever знаходить правильні документи, але вони тонуть серед нерелевантних. Рішення: reranking (Cross-encoder, Cohere Rerank — тема RAG від PoC до production).

Метрика 3: Faithfulness (Context → Answer)

Ключова метрика для виявлення галюцинацій. Вимірює, яка частка тверджень (claims) у відповіді підтримується retrieved context.

Формула (RAGAS docs):

Faithfulness = Number of Truthful Claims / Total Number of Claims

Як працює scorer: LLM-judge виконує два кроки. Крок 1: витягує всі claims (фактичні твердження) із відповіді. Крок 2: для кожного claim перевіряє, чи він підтримується фактами у retrieved context. Claim вважається truthful, якщо він не суперечить контексту (DeepEval Faithfulness docs).

Що діагностує: низький Faithfulness (< 0.85) означає, що LLM ігнорує context і генерує з власних "знань". Причини: занадто широкий prompt, слабка модель, недостатній контекст.

⚠️ Нюанс: Faithfulness ≠ Correctness. Відповідь може бути 100% faithful контексту, але якщо контекст застарілий або неправильний — відповідь теж буде неправильною. Faithfulness перевіряє лише відповідність відповіді контексту, а не істинність самого контексту.

Метрика 4: Answer Relevancy (Query → Answer)

Оцінює, наскільки відповідь релевантна запиту. Відповідь може бути faithful (не суперечить контексту), але не відповідати на питання — наприклад, якщо LLM "загубився" у контексті і почав переказувати нерелевантні факти.

Як обчислюється: LLM генерує N потенційних питань, на які могла б відповісти ця відповідь, і порівнює їх embedding similarity з оригінальним запитом. Чим вища середня similarity — тим вищий score.

Що діагностує: низький Answer Relevancy при високому Faithfulness = контекст правильний, але prompt не фокусує LLM на питанні. Рішення: уточніть system prompt, додайте instruction "відповідай конкретно на запит користувача".

Метрика 5: NDCG@K (Normalized Discounted Cumulative Gain)

Класична IR-метрика, яка враховує і релевантність, і позицію документів у ranked list. На відміну від бінарних Context Recall / Precision, NDCG працює з graded relevance (0–3), що дає точнішу картину. Дослідження показують, що NDCG корелює з end-to-end якістю RAG сильніше, ніж бінарні метрики (PremAI, 2026).

Коли використовувати: коли у вас є graded relevance labels (0 — нерелевантний, 1 — частково, 2 — релевантний, 3 — ідеальний). Потребує більше annotation effort, але дає точнішу картину retrieval якості.

Рекомендовані стартові пороги (PremAI, 2026): Precision@5 ≥ 0.7 для вузьких knowledge bases, Recall@20 ≥ 0.8 для широких корпусів.

Як метрики Triad взаємодіють: приклад діагностики

Уявімо, ви запустили evaluation на 200 питаннях і отримали:

• Context Recall: 0.91 ✅
• Context Precision: 0.62 ⚠️
• Faithfulness: 0.78 ⚠️
• Answer Relevancy: 0.85 ✅

Діагноз через Triad: ребро Query → Context частково зламане — retriever знаходить правильні документи (високий Recall), але вони тонуть серед "сміття" (низький Precision). Це впливає на ребро Context → Answer: LLM отримує забагато нерелевантного контексту і починає галюцинувати (Faithfulness 0.78). При цьому ребро Query → Answer ще тримається (Relevancy 0.85) — LLM поки відповідає на питання.

Action: додати reranking (Cross-encoder) між retriever і generator. Очікуваний ефект: Precision ↑ → менше "сміття" у контексті → Faithfulness ↑. Повна діагностична таблиця з усіма комбінаціями — у Розділі 6.

З мого досвіду: RAG Triad — це не теоретична абстракція, а практичний фреймворк для діагностики. Коли ви бачите scores через призму трикутника Query–Context–Answer, причина проблеми стає очевидною за секунди, а не за години дебагу.

📌 Розділ 3. Тестовий набір: категорії, synthetic generation, ground truth

Тестовий набір визначає, що саме ви вимірюєте. Поганий тестовий набір = безглузді метрики. Статичний тестовий набір = метрики, які не відповідають реальності.

5 категорій тестових питань

Розбийте тестовий набір на категорії, щоб бачити, де саме RAG ламається:

• ✔️ Фактоїдні (10 питань): "хто", "коли", "скільки" — одна відповідь, один чанк. Базова перевірка retrieval.
• ✔️ Порівняльні (10 питань): "чим відрізняється X від Y" — потребують multi-chunk retrieval.
• ✔️ Аналітичні (10 питань): "чому", "як працює" — перевіряють reasoning LLM на основі контексту.
• ✔️ Edge cases (10 питань): питання, на які відповіді НЕМАЄ в базі знань. Перевіряють, чи LLM чесно відповідає "не знаю" замість галюцинацій.
• ✔️ Реальні з логів (10 питань): запити реальних користувачів. Найцінніша категорія — показує, що насправді запитують люди.

Synthetic generation через RAGAS

RAGAS використовує evolutionary paradigm для генерації різноманітних питань (RAGAS TestsetGenerator docs). Процес: документи → KnowledgeGraph → сценарії → питання різних типів (simple, multi-context, reasoning).

from ragas.testset import TestsetGenerator
from ragas.llms import LangchainLLMWrapper
from ragas.embeddings import LangchainEmbeddingsWrapper
from langchain_openai import ChatOpenAI, OpenAIEmbeddings

generator_llm = LangchainLLMWrapper(ChatOpenAI(model="gpt-4o"))
generator_embeddings = LangchainEmbeddingsWrapper(OpenAIEmbeddings())

generator = TestsetGenerator(
    llm=generator_llm,
    embedding_model=generator_embeddings
)

dataset = generator.generate_with_langchain_docs(docs, testset_size=50)
df = dataset.to_pandas()

⚠️ Обмеження synthetic generation:

• ✔️ LLM-згенеровані питання можуть не відображати реальні запити користувачів
• ✔️ RAGAS іноді повертає NaN для ground truth, особливо для складних reasoning-питань
• ✔️ Для неанглійських корпусів якість синтетичних питань помітно нижча
• ✔️ Рекомендація: замініть 30–50% синтетичних питань реальними з продакшн-логів протягом перших 2 тижнів

Ground truth annotation pipeline

Для кожного тестового питання потрібні: input (запит), expected_output (еталонна відповідь), і retrieval_context (очікувані чанки). Expected output потрібен для Context Recall і Contextual Precision. Retrieval context генерується вашим RAG pipeline при запуску evaluation — його не потрібно писати вручну.

Evolving Dataset: чому статичний golden set — це технічний борг

Типова помилка: команда створює golden dataset на старті, запускає evaluation в CI/CD — і більше ніколи його не оновлює. Через 3–6 місяців knowledge base змінилася, патерни запитів еволюціонували, а ви тестуєте систему на застарілих питаннях. Метрики зелені, але користувачі незадоволені. Це data drift applied to evaluation.

Два типи drift, які вбивають eval dataset:

• ✔️ Knowledge drift: knowledge base оновилась — нові документи, видалені розділи, змінені факти. Ground truth відповіді стають неактуальними. Context Recall може впасти не тому що retriever погіршився, а тому що "правильні" чанки більше не існують у тому вигляді.
• ✔️ Query drift: реальні запити користувачів змінюються з часом. Нові продукти, нові фічі, сезонні теми — а ваш eval dataset все ще тестує питання, які ніхто не задає. Високі scores на eval, але низька задоволеність на production.

Human-in-the-loop pipeline для живого eval dataset

Golden dataset має бути живою системою, а не статичним файлом. Ось архітектура, яка перетворює фідбек користувачів у evaluation кейси:

  Production RAG
       │
       ▼
  User feedback ("👎 погана відповідь")
       │
       ▼
  Feedback queue (DB / spreadsheet)
       │
       ▼
  ┌─────────────────────────────────────┐
  │  Human review (щотижня, 30 хв):    │
  │  • Анонімізація (PII removal)       │
  │  • Верифікація: дійсно поганий?     │
  │  • Ground truth: яка правильна      │
  │    відповідь? Які чанки потрібні?   │
  │  • Категоризація: фактоїдне /       │
  │    порівняльне / edge case          │
  └─────────────────┬───────────────────┘
                    │
                    ▼
  Golden Dataset v2.1 (versioned!)
       │
       ▼
  Nightly eval run (CI/CD)

Ключові правила evolving dataset:

• ✔️ Версіонування обов'язкове. Якщо dataset змінився між eval runs — scores не можна порівнювати. Тегуйте версію dataset разом з pipeline version: eval-v2.1_pipeline-v3.4
• ✔️ Core set + rotating set. Зберігайте 70% питань незмінними (core) для tracking трендів. 30% — rotating set з нових production кейсів. Так ви бачите і стабільність, і адаптацію.
• ✔️ Щомісячний review cycle. Раз на місяць: додайте 5–10 нових кейсів із feedback queue, видаліть або оновіть кейси з застарілим ground truth, перегенеруйте synthetic питання якщо knowledge base суттєво змінилась.
• ✔️ Автоматичний збір кандидатів. Коли Faithfulness на конкретному production-запиті < 0.5 — автоматично додайте його у feedback queue для human review. Це найдешевший спосіб знаходити реальні failure modes.

⚠️ Anti-pattern: синтетичний dataset без ревізії

RAGAS генерує правдоподібні питання, які можуть містити фактичні помилки або посилатися на неіснуючий контент. Завжди переглядайте sample перед включенням у eval suite. Команди, які пропускають human review, регулярно пропускають системні проблеми — особливо у compliance-heavy доменах (фінанси, медицина, legal) (Label Your Data, 2026).

Я раджу: починайте з 50 категоризованих питань. Synthetic generation через RAGAS економить 90% часу на старті, але з першого тижня в production запустіть feedback loop. Через місяць ваш eval dataset буде набагато ціннішим, ніж будь-який synthetic set — тому що він відображатиме реальні failure modes вашої конкретної системи.

📌 Розділ 4. RAGAS vs DeepEval: архітектура, код, вартість

Почніть з RAGAS для генерації golden dataset і дослідження метрик, перейдіть на DeepEval для систематичного тестування.

RAGAS: exploration-first

RAGAS (Retrieval Augmented Generation Assessment) — open-source фреймворк, представлений у 2023 році (arXiv:2309.15217). Reference-free evaluation: не потребує ground truth для Faithfulness і Answer Relevancy.

from openai import AsyncOpenAI
from ragas.llms import llm_factory
from ragas.metrics.collections import Faithfulness

client = AsyncOpenAI()
llm = llm_factory("gpt-4o-mini", client=client)

scorer = Faithfulness(llm=llm)

result = await scorer.ascore(
    user_input="Коли відбувся перший Super Bowl?",
    response="Перший Super Bowl відбувся 15 січня 1967 року",
    retrieved_contexts=[
        "The First AFL-NFL World Championship Game was played on January 15, 1967..."
    ]
)
print(f"Faithfulness Score: {result.value}")

Сильні сторони: synthetic testset generation (KnowledgeGraph → scenarios → questions), підтримка FaithfulnesswithHHEM (використовує спеціалізовану відкриту модель для claim verification без LLM-calls), інтеграція з LangChain і LlamaIndex.

Обмеження: іноді повертає NaN scores через невалідний JSON від LLM-judge. Відсутні вбудовані production observability, experiment tracking і CI/CD інтеграція.

DeepEval: CI/CD-first

DeepEval — open-source LLM evaluation framework з нативною pytest-інтеграцією. Кожна метрика повертає score (0–1) + reason (DeepEval docs).

from deepeval import evaluate
from deepeval.test_case import LLMTestCase
from deepeval.metrics import (
    FaithfulnessMetric,
    AnswerRelevancyMetric,
    ContextualPrecisionMetric,
    ContextualRecallMetric
)

test_case = LLMTestCase(
    input="Як працює OAuth 2.0?",
    actual_output="OAuth 2.0 використовує access tokens...",
    expected_output="OAuth 2.0 — протокол авторизації...",
    retrieval_context=["OAuth 2.0 is an authorization framework..."]
)

metrics = [
    FaithfulnessMetric(threshold=0.7, model="gpt-4.1"),
    AnswerRelevancyMetric(threshold=0.8),
    ContextualPrecisionMetric(threshold=0.7),
    ContextualRecallMetric(threshold=0.7)
]

evaluate(test_cases=[test_case], metrics=metrics)

Сильні сторони: self-explaining metrics (кожна метрика пояснює, чому такий score), JSON confinement (менше NaN ніж RAGAS), pytest integration для CI/CD, підтримка custom criteria через GEval.

Обмеження: steep learning curve для нетехнічних стейкхолдерів, потребує окремих інструментів для observability (Langfuse, Arize Phoenix).

Порівняння вартості

З GPT-4o-mini як judge (PremAI, 2026):

• ✔️ ~$0.001–0.003 за test case (5 метрик)
• ✔️ 200-question golden dataset → менше $1 за eval run
• ✔️ 1000 production samples щоденно → $3–5/день

Висновок: RAGAS для дослідження і генерації тестів, DeepEval для автоматизації. Можна комбінувати: генеруєте dataset в RAGAS, запускаєте evaluation в DeepEval.

📌 Розділ 5. Evaluation на Ollama: що працює, де деградація

Безкоштовно ≠ безкоштовно. Ви платите часом на inference і деградацією точності scorer'а.

Як підключити Ollama до RAGAS і DeepEval

Обидва фреймворки підтримують будь-який OpenAI-compatible endpoint (PremAI, 2026). Достатньо вказати base_url на локальний Ollama:

# Для RAGAS
from openai import AsyncOpenAI
from ragas.llms import llm_factory

client = AsyncOpenAI(
    base_url="http://localhost:11434/v1",
    api_key="ollama"  # Ollama не потребує ключ, але параметр обов'язковий
)
llm = llm_factory("llama3.1:70b", client=client)

# Для DeepEval
from deepeval.metrics import FaithfulnessMetric

metric = FaithfulnessMetric(
    threshold=0.7,
    model="llama3.1:70b",  # будь-яка модель з Ollama
)

Де деградація якості

Калібровані fine-tuned моделі 7–13B параметрів на 500 human-labeled прикладах можуть перевершити GPT-4o як judge для конкретного домену (Let's Data Science, 2025). Але "з коробки" Llama 3.1 8B як scorer дає помітно гіршу якість:

• ✔️ Faithfulness: найбільша деградація. Маленькі моделі гірше виявляють тонкі суперечності між claims і context
• ✔️ Answer Relevancy: помірна деградація. Embedding similarity допомагає компенсувати
• ✔️ Context Recall/Precision: мінімальна деградація — це переважно classification task

Рекомендація: якщо дані не можуть покидати інфраструктуру (data residency, GDPR) — Ollama + Llama 3.1 70B це production-viable рішення. Для всіх інших випадків — GPT-4o-mini як judge при $1/200 питань не є bottleneck бюджету.

Висновок: Ollama підходить для data-sensitive середовищ і початкового exploration. Для production evaluation GPT-4o-mini дає найкраще співвідношення якість/ціна.

💼 Розділ 6. Інтерпретація результатів: пороги, кореляції, діагностика

Метрики — це не цілі. Це діагностичні інструменти. Optimizing for metrics ≠ optimizing for quality.

Рекомендовані порогові значення

Ці пороги базуються на практичному досвіді і рекомендаціях (PremAI, 2026):

• ✔️ General-purpose Q&A: Faithfulness ≥ 0.80, Context Recall ≥ 0.75, Answer Relevancy ≥ 0.75
• ✔️ Customer-facing docs: Faithfulness ≥ 0.85, Context Recall ≥ 0.80
• ✔️ Regulated industries: Faithfulness ≥ 0.90, Context Recall ≥ 0.85

Діагностична таблиця: комбінації метрик → дії

• ✔️ Низький Context Recall + низький Faithfulness: retriever не знаходить документи → LLM вигадує. Починайте з retrieval: chunking, embedding model, top_k
• ✔️ Високий Context Recall + низький Faithfulness: документи знайдені, але LLM їх ігнорує. Проблема в prompt або моделі. Додайте instruction "відповідай ТІЛЬКИ на основі контексту"
• ✔️ Високий Context Recall + низький Context Precision: правильні документи є, але тонуть серед нерелевантних. Потрібен reranking (Cross-encoder, Cohere Rerank)
• ✔️ Високий Faithfulness + низький Answer Relevancy: відповідь не суперечить контексту, але не відповідає на питання. Проблема в prompt template — LLM "загубився" у контексті
• ✔️ Все високе, але users незадоволені: тестовий набір не відображає реальні запити. Додайте більше питань з production логів

⚠️ Anti-pattern: overfitting на eval metrics

Optimizing prompt безпосередньо під RAGAS scores створює системи, які добре скорять на eval і ламаються на production запитах, що виглядають трохи інакше. Метрики — для tracking, не для optimization target.

Висновок розділу: інтерпретуйте метрики як діагностику, не як KPI. Кожна комбінація вказує на конкретний компонент pipeline.

💼 Розділ 7. CI/CD інтеграція: regression suite, nightly runs

Evaluation без автоматизації — це evaluation, яке скоро перестануть робити.

pytest + DeepEval: базовий setup

DeepEval дозволяє писати evaluation тести як звичайні pytest test cases (Confident AI, 2025):

# test_rag_quality.py
import pytest
from deepeval import assert_test
from deepeval.test_case import LLMTestCase
from deepeval.metrics import FaithfulnessMetric, AnswerRelevancyMetric
from deepeval.dataset import EvaluationDataset

dataset = EvaluationDataset()
dataset.add_test_cases_from_csv_file("golden_dataset.csv")

faithfulness = FaithfulnessMetric(threshold=0.8, model="gpt-4o-mini")
relevancy = AnswerRelevancyMetric(threshold=0.75, model="gpt-4o-mini")

@pytest.mark.parametrize("test_case", dataset.test_cases)
def test_rag(test_case: LLMTestCase):
    assert_test(test_case, [faithfulness, relevancy])

Запуск:

deepeval test run test_rag_quality.py

GitHub Actions workflow

# .github/workflows/rag-eval.yml
name: RAG Evaluation
on:
  schedule:
    - cron: '0 2 * * *'  # nightly о 2:00
  push:
    paths:
      - 'prompts/**'
      - 'config/rag/**'

jobs:
  eval:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-python@v5
        with:
          python-version: '3.12'
      - run: pip install deepeval
      - run: deepeval test run tests/test_rag_quality.py
        env:
          OPENAI_API_KEY: ${{ secrets.OPENAI_API_KEY }}

Коли запускати evaluation

• ✔️ Nightly: baseline monitoring. Виявляє drift якщо knowledge base оновлюється
• ✔️ Per-release: при зміні prompt, моделі, chunking config або embedding model
• ✔️ Post-ingestion: після великого оновлення knowledge base. Context Recall може впасти, якщо нові документи мають інші chunking характеристики

⚠️ Fail gates: обережно з порогами

Pipeline, який блокує кожен build, буде вимкнений через тиждень. Почніть з м'яких порогів (warning, не block), встановіть baseline за 2–3 тижні, потім підвищуйте пороги поступово.

Висновок: DeepEval + pytest + GitHub Actions = повний evaluation pipeline за день. Вартість nightly run з 200 питань — менше $1.

❓ Часті питання (FAQ)

Скільки тестових питань потрібно для reliable метрик?

50 добре підібраних питань дають стабільні метрики для відстеження змін. Менше 20 — scores будуть значно стрибати між прогонами. Для synthetic regression datasets 200–500 питань забезпечують достатнє покриття (PremAI, 2026).

Чи можна запустити evaluation без відправки даних у OpenAI?

Так. RAGAS і DeepEval підтримують будь-який OpenAI-compatible endpoint як judge model. Через Ollama або vLLM evaluation працює повністю на вашій інфраструктурі. Стандартний підхід для команд з вимогами data residency.

Що робити, якщо baseline метрики після першого прогону дуже низькі?

Це нормально і це цінність evaluation — ви побачили реальну картину. Використовуйте діагностичну таблицю з Розділу 6: визначте, який компонент (retrieval чи generation) потребує уваги першим. Зазвичай найбільший ROI дає покращення chunking і додавання reranking.

Чи є circular bias коли GPT-4o оцінює RAG, який теж використовує GPT-4o?

Так, це відома проблема. GPT-4o як judge може бути лояльнішим до відповідей, згенерованих GPT-4o. Рішення: використовуйте cross-model evaluation (наприклад, Claude як judge для GPT-based RAG), або калібруйте scorer на human-labeled dataset.

Як часто потрібно оновлювати golden dataset?

Версіонуйте eval dataset разом з model і pipeline версіями. Якщо golden dataset змінюється між прогонами — scores не можна порівнювати. Додавайте нові питання з production логів щомісяця, але зберігайте core набір незмінним для tracking.

✅ Висновки

• 🔹 5 метрик — Context Recall, Context Precision, Faithfulness, Answer Relevancy, NDCG@K — покривають retrieval і generation компоненти RAG pipeline
• 🔹 50 категоризованих питань — мінімальний набір для першого evaluation. Synthetic generation через RAGAS + 30–50% реальних запитів
• 🔹 RAGAS для exploration, DeepEval для CI/CD — комбінуйте: генеруйте dataset в RAGAS, автоматизуйте в DeepEval
• 🔹 GPT-4o-mini як judge — $1/200 питань. Ollama для data-sensitive середовищ, але з ~15–20% деградацією точності
• 🔹 Метрики — діагностика, не KPI. Кожна комбінація низьких/високих scores вказує на конкретний компонент для покращення
• 🔹 Автоматизація обов'язкова. DeepEval + pytest + GitHub Actions = evaluation pipeline за день, < $1/прогін

Головна думка: Без метрик ви не знаєте, чи ваш RAG працює — ви сподіваєтесь. 5 метрик, 50 питань, один eval-прогін — і через 2 години ви маєте діагностичну картину і конкретний план покращення.