AI Evaluace
Měříme kvalitu AI. Ne vibes.
Navrhujeme evaluační frameworky pro LLM aplikace — golden datasets, automatizované eval pipelines, LLM-as-judge. Víte přesně, jak dobře vaše AI funguje a kde selhává.
Proč AI potřebuje jiný přístup k testování¶
Klasický software je deterministický. Vstup A → výstup B. Pokaždé. Test je jednoduchý: assert output == expected.
LLM aplikace jsou fundamentálně jiné. Stejný prompt, stejný model, stejná teplota — a dostanete tři různé odpovědi. Všechny mohou být správné. Nebo všechny špatné. Nebo dvě dobré a jedna halucinuje.
Změníte system prompt o dvě slova? Výstup se změní nepředvídatelně. Upgrade na novou verzi modelu? Některé odpovědi se zlepší, jiné se zhorší. Přidáte dokument do RAG pipeline? Retrieval se změní, odpovědi taky.
Bez systematické evaluace létáte naslepo. Nevíte, jestli poslední změna pomohla nebo ublížila. Nevíte, kde model selhává. Nevíte, jestli je bezpečné deployovat novou verzi. Evaluace je pro AI aplikace to, co testy jsou pro klasický software — nutnost, ne nice-to-have.
Golden datasets¶
Golden dataset je vaše ground truth — kurátorovaná sada příkladů, proti které měříte kvalitu AI výstupů.
Struktura¶
Každý záznam v golden datasetu obsahuje:
- Input — uživatelský dotaz, kontext, dokumenty (pro RAG)
- Expected output — referenční odpověď (ideální nebo akceptovatelná)
- Metadata — kategorie, obtížnost, edge case flagy
- Evaluation criteria — co přesně hodnotíme (accuracy, completeness, tone, format)
Jak stavíme golden datasets¶
Human-labeled příklady: Doménoví experti vytvářejí a hodnotí páry input/output. Nejdražší, ale nejkvalitnější zdroj. Typicky 100-200 ručně vytvořených příkladů tvoří jádro datasetu.
Produkční data: Reálné dotazy uživatelů s human-reviewed odpověďmi. Feedback loop — uživatelé hlásí špatné odpovědi, ty se přidávají jako negative examples. Nejautentičtější zdroj, protože reflektuje skutečné use cases.
Syntetická data: LLM generuje variace existujících příkladů — parafráze, edge cases, adversarial inputs. Rozšiřujeme coverage bez lineárního nárůstu lidské práce. Ale vždy s human review — syntetická data bez kontroly zavádějí bias.
Adversarial příklady: Úmyslně záludné vstupy navržené k odhalení slabých míst. Prompt injection pokusy, ambiguozní dotazy, out-of-scope témata, kulturně citlivý obsah. Testují robustnost, ne jen happy path.
Údržba¶
Golden dataset není statický. Přidáváte nové příklady z produkce, odstraňujete zastaralé, aktualizujete expected outputs při změně business logiky. Verzujeme v gitu jako kód — každá změna je trackovaná, reviewovaná, revertovatelná.
LLM-as-judge¶
Lidské hodnocení je gold standard, ale nescaluje. Nemůžete zaplatit tým hodnotitelů, aby přečetl 500 odpovědí při každém PR. LLM-as-judge automatizuje hodnocení s korelací >85% s lidským úsudkem.
Jak to funguje¶
Judge model (typicky GPT-4o nebo Claude Opus) dostane:
- Rubric — přesná kritéria hodnocení (1-5 škála pro relevanci, přesnost, úplnost)
- Input — původní uživatelský dotaz
- Reference — očekávaná odpověď z golden datasetu
- Candidate — skutečná odpověď hodnoceného modelu
Judge vrátí strukturované hodnocení: skóre na každém kritériu, odůvodnění, identifikované problémy. Vše strojově parsovatelné.
Evaluační dimenze¶
Faithfulness — odpovídá odpověď faktům z poskytnutého kontextu? Nehalucinuje model informace, které nejsou v dokumentech? Kritické pro RAG aplikace.
Relevance — odpovídá odpověď na to, co se uživatel ptal? Není off-topic, není příliš obecná, pokrývá klíčové body dotazu.
Completeness — obsahuje odpověď všechny důležité informace? Nechybí klíčový detail? Pokrývá edge cases zmíněné v dotazu?
Harmlessness — neobsahuje odpověď toxický, biased nebo nebezpečný obsah? Respektuje guidelines a content policy?
Format compliance — dodržuje odpověď požadovaný formát? JSON schema, markdown struktura, délka, jazyk.
Kalibrace judge modelu¶
LLM-as-judge není bezchybný. Kalibrujeme ho proti lidskému hodnocení:
- Lidé ohodnotí 50-100 příkladů
- Judge ohodnotí stejné příklady
- Měříme korelaci (Cohen’s kappa, Spearman)
- Iterujeme rubric, dokud korelace > 0.85
Periodicky rekalibrujeme — modely se mění, distribuce dat se mění, business požadavky se mění.
Automatizované eval pipelines¶
Evaluace musí běžet automaticky. Manuální eval „když si vzpomeneme” neposkytne systematický feedback.
CI/CD integrace¶
Eval pipeline se spouští při:
- PR se změnou promptu — porovnání nové verze vs. baseline
- Upgrade modelu — nová verze GPT/Claude/Llama vs. stávající
- Změna RAG pipeline — nový chunking, embeddings, retrieval strategy
- Scheduled — denní/týdenní eval na produkčních datech pro drift detection
Pipeline architektura¶
Golden Dataset → Inference (model under test) → Judge (LLM-as-judge + heuristic checks) → Metrics → Dashboard → Alert
Inference stage: Spustíme hodnocený model na celém golden datasetu. Zaznamenáme odpovědi, latenci, token count, cost.
Evaluation stage: Každá odpověď prochází battery of checks: - LLM-as-judge pro subjektivní kvalitu (relevance, faithfulness) - Heuristické kontroly pro objektivní metriky (format, délka, banned words) - Embedding similarity pro semantic matching s referenční odpovědí - Regex/schema validace pro strukturované výstupy
Reporting: Výsledky agregované do dashboardu. Trending přes čas — zlepšujeme se, nebo degradujeme? Breakdown po kategoriích — kde jsme silní, kde slabí? Comparison view — nová verze vs. stará, side by side.
Metriky¶
Pass rate — procento odpovědí, které splňují všechna kritéria. Hlavní KPI.
Score distribution — histogram skóre across všech dimenzí. Posun distribuce doleva = regrese.
Category breakdown — pass rate per kategorie (FAQ, technické dotazy, edge cases). Odhalí, kde specificky model selhává.
Latency a cost — nejen kvalita, ale i efektivita. Nový prompt je lepší, ale 3× dražší? Stojí to za to?
Regression alerts — automatický alert, když pass rate klesne o >5% oproti baseline. PR se nezamerguje.
Evaluace RAG pipeline¶
RAG aplikace mají specifické evaluační potřeby — hodnotíme nejen generování, ale i retrieval.
Retrieval metriky¶
Precision@k — kolik z top-k retrievnutých dokumentů je relevantních? Vysoký precision = málo šumu.
Recall — kolik relevantních dokumentů jsme našli z celkového počtu? Vysoký recall = nic důležitého nechybí.
MRR (Mean Reciprocal Rank) — jak vysoko je první relevantní dokument? Uživatel potřebuje odpověď z prvního chunky, ne z desátého.
End-to-end RAG eval¶
Nestačí hodnotit retrieval a generování zvlášť. E2E evaluace: dotaz → retrieval → generování → hodnocení finální odpovědi. Protože dobrý retrieval + špatné generování = špatná odpověď. A naopak — model může kompenzovat slabý retrieval svými znalostmi (ale neměl by).
Nástroje a frameworky¶
Eval frameworky: Ragas, DeepEval, Promptfoo, LangSmith, Braintrust.
LLM-as-judge: GPT-4o, Claude Opus, Gemini Pro — volíme podle cost/quality tradeoff.
Dataset management: Git (versioning), DVC (large files), custom tooling.
Dashboardy: Grafana, Streamlit, custom web UI.
CI/CD: GitHub Actions, GitLab CI — eval jako povinný step v pipeline.
Časté otázky
Klasické unit testy kontrolují deterministické výstupy — vstup A, výstup B. LLM generuje různé odpovědi na stejný prompt. Potřebujete metriky jako relevance, faithfulness, toxicita, completeness — a automatizované způsoby, jak je měřit. Bez evaluace nevíte, jestli změna promptu zlepšila nebo zhoršila výsledky.
Kurátorovaná sada vstupů a očekávaných výstupů, která reprezentuje reálné use cases vaší aplikace. Kombinace human-labeled příkladů a synteticky generovaných edge cases. Slouží jako benchmark — každá změna modelu nebo promptu se vyhodnotí proti golden datasetu.
Použití silnějšího LLM (typicky GPT-4o nebo Claude) k automatickému hodnocení výstupů slabšího modelu. LLM-judge dostane rubric (kritéria hodnocení), vstup, očekávaný výstup a skutečný výstup — a ohodnotí kvalitu. Korelace s lidským hodnocením je překvapivě vysoká (>85%).
Ideálně při každé změně promptu, modelu nebo RAG pipeline. V praxi: automaticky v CI/CD pipeline. Změníte system prompt? Eval suite proběhne za 15-30 minut a ukáže, jestli se kvalita zlepšila, zhoršila, nebo zůstala stejná.
Hlavní náklad jsou API calls pro LLM-as-judge. Typicky $5-20 za eval run (závisí na velikosti datasetu a modelu). S lokálními modely pro jednodušší hodnocení (toxicita, format compliance) výrazně méně. ROI: jedna zachycená regrese v kvalitě = ušetřený churn zákazníků.