Evaluace & monitoring

Proč je evaluace kritická¶

LLM se mění. OpenAI updatne model a chování se změní. Vaše data se mění — nové dokumenty, nové procesy. Uživatelské dotazy se mění — nové use-cases, nové formulace. Bez kontinuální evaluace nevíte, jestli váš AI systém funguje. Víte jen, že fungoval minulý měsíc.

Viděli jsme systémy, kde upgrade modelu z GPT-4-0613 na GPT-4-turbo zhoršil kvalitu specifických úloh o 20%. Nikdo si toho týden nevšiml — protože nebyla evaluace. Uživatelé si začali stěžovat, důvěra klesla, adopce spadla. Oprava trvala den, ale škoda na důvěře měsíce.

Tři pilíře AI observability¶

┌───────────────────────────────────────────────────────┐
│                    AI OBSERVABILITY                     │
│                                                        │
│  ┌──────────┐   ┌──────────────┐   ┌──────────────┐  │
│  │ EVALUACE │   │  MONITORING  │   │   ALERTING   │  │
│  │          │   │              │   │              │  │
│  │ Kvalita  │   │ Provoz       │   │ Anomálie     │  │
│  │ odpovědí │   │ (latence,    │   │ (pokles      │  │
│  │ (offline │   │  throughput, │   │  kvality,    │  │
│  │  + online)│   │  cost, errors│   │  spike cost, │  │
│  │          │   │  )           │   │  drift)      │  │
│  └──────────┘   └──────────────┘   └──────────────┘  │
└───────────────────────────────────────────────────────┘

Evaluace — měření kvality¶

Offline evaluace (před deploy)¶

Před každým deployem (nový prompt, nový model, nové dokumenty) proběhne automatická eval suite:

Golden dataset: 200-500 párů (dotaz, očekávaná odpověď, relevantní dokumenty) vytvořených a validovaných doménovými experty. Dataset je verzovaný a roste s každým novým edge case.

Metriky:

Metrika	Co měří	Threshold
Faithfulness	Je odpověď podložená kontextem?	>95%
Answer relevance	Odpovídá odpověď na dotaz?	>90%
Completeness	Pokrývá odpověď celý dotaz?	>85%
Hallucination rate	Kolik tvrzení nemá oporu v kontextu	<3%
Context precision	Kolik retrievnutého kontextu je relevantní	>80%
Context recall	Kolik relevantních info je v kontextu	>90%

LLM-as-judge: Pro subjektivní aspekty (je odpověď srozumitelná? má správný tón?) používáme silnější model jako hodnotitele. Kalibrujeme proti lidským anotacím (Cohen’s kappa > 0.7).

Regression testing: Každý deploy je porovnán proti předchozí verzi. Pokud jakákoliv metrika klesne o více než 2%, deploy je zablokován a vyžaduje manuální review.

Online evaluace (v produkci)¶

User feedback: Thumbs up/down na každé odpovědi. Feedback rate typicky 5-15%. Korelujeme s automatickými metrikami pro kalibraci.

Sampling: Náhodný vzorek produkčních dotazů (5-10%) evaluujeme automaticky. Detekujeme drift — postupný pokles kvality, který by jinak zůstal neviditelný.

A/B testing: Pro prompt změny, model změny, pipeline změny. Statisticky signifikantní srovnání na reálném provozu.

Monitoring — sledování provozu¶

Provozní metriky¶

Latence: - P50, P95, P99 — per endpoint, per agent - Breakdown: retrieval latency, LLM latency, tool call latency - SLA tracking — kolik požadavků splnilo SLA

Throughput: - Requests per second/minute - Queue depth (pro asynchronní workflow) - Concurrent agents

Náklady: - Token consumption (input/output, per model) - Cost per query, cost per successful resolution - Budget tracking s alertem na překročení

Errors: - Error rate per endpoint - Error kategorizace (timeout, rate limit, model error, tool error) - Retry rate, dead letter queue size

Aplikační metriky¶

Retrieval kvalita (pro RAG): - Denní eval na golden datasetu - Retrieval latency - Cache hit rate - Empty results rate

Agent kvalita (pro workflow): - Success rate per task type - Average steps per task - Eskalace rate - Revert rate (kolikrát byl výsledek agenta přepsán)

Drift detection¶

Data drift: Distribuce vstupních dotazů se mění. Měříme embedding distance nových dotazů vs. training/eval distribuce. Alert na statisticky významný posun.

Model drift: Kvalita odpovědí se postupně zhoršuje. Měříme rolling average evaluačních metrik s window 7 dní. Alert na trend poklesu.

Concept drift: Domény se mění — nové produkty, nové procesy, nové regulace. Detekujeme pomocí increasing rate of “I don’t know” odpovědí nebo zvýšené eskalace.

Alerting — reakce na problémy¶

Alert hierarchy¶

Severity	Příklad	Reakce	SLA
P1 Critical	Agent nefunkční, data leak	Okamžitý kill-switch, on-call	15 min
P2 High	Accuracy pod threshold	Degraded mode, investigace	1 hodina
P3 Medium	Latence nad SLA	Monitoring, optimalizace	4 hodiny
P4 Low	Cost spike, minor drift	Review v next sprint	24 hodin

Automatické reakce¶

Pro P1 a P2 alerty implementujeme automatické mitigace:

• Circuit breaker — pokud error rate > 10%, agent přestane přijímat nové úlohy
• Degraded mode — striktější guardrails, nižší confidence threshold pro eskalaci
• Fallback model — přepnutí na backup model při výpadku primárního
• Automatic rollback — pokud nový deploy zhorší metriky, automatický návrat na předchozí verzi

Implementace¶

Tech stack¶

Komponenta	Technologie
Traces	LangSmith, OpenTelemetry
Metriky	Prometheus + Grafana
Logy	ELK Stack / Loki
Alerty	PagerDuty, Slack, email
Eval framework	RAGAS, custom eval suite
Dashboardy	Grafana, custom stakeholder dashboard

Typický dashboard¶

Dashboard pro stakeholdery obsahuje: - Executive summary — zelená/žlutá/červená per agent/use-case - Trend grafy — kvalita, latence, náklady za posledních 30 dní - Top failing queries — dotazy s nejnižší kvalitou (input pro zlepšení) - Cost breakdown — kolik stojí jaký use-case, trend - User satisfaction — feedback rate, sentiment, NPS

Reporting¶

• Denní — automatický report do Slacku (key metrics, anomálie)
• Týdenní — detailní report s trendy a doporučeními
• Měsíční — executive report s ROI analýzou a plány na optimalizaci