U klienta z energetiky sme nasadili RAG nad technickými normami a prevádzkovými smernicami. Po prvých dvoch týždňoch produkcie hlásili operátori, že systém „niekedy odpovedá správne, niekedy nie". Keď sme sa pozreli bližšie, ukázalo sa, že problém má dve úplne odlišné príčiny: v niektorých prípadoch retrieval načítal nesprávne dokumenty — správna odpoveď v knowledge base existovala, ale systém ju nenašiel. V iných prípadoch retrieval fungoval dobre, ale generatívny model ignoroval načítaný kontext a halucinoval vlastnú odpoveď. Z pohľadu používateľa vyzerali obe chyby rovnako. Bez metrík sme ich nedokázali odlíšiť.
Toto je jadro problému s evaluáciou RAG systémov: retrieval a generation sú dve odlišné komponenty, každá môže zlyhávať z iných dôvodov, a ak ich meriame spoločne, stratíme schopnosť diagnostikovať. Tento článok popisuje, ako na to — oddelene, systematicky, s nástrojmi, ktoré na to existujú.
Prečo klasické metriky nestačia
Prvý inštinkt pri hodnotení RAG systému je spýtať sa: „Je odpoveď správna?" A merať to ručne alebo cez jednoduché porovnanie s očakávaným výstupom. Tento prístup má zásadný problém: nehovorí ti *kde* pipeline zlyhala.
Predstav si tri scenáre:
- Retrieval načítal správny dokument, model z neho správne odpovedal — dobrý výsledok.
- Retrieval načítal nesprávny dokument, model z neho odpovedal konzistentne — zlý výsledok, ale faithfulness je vysoká (model nehalucinoval, len mal zlý kontext).
- Retrieval načítal správny dokument, model ho ignoroval a halucinoval — zlý výsledok, faithfulness je nízka.
Tri rôzne scenáre, dve rôzne miesta zlyhávania, jeden spoločný symptóm: nesprávna odpoveď. Ak meraš len konečný výsledok, opravíš retrieval a zistíš, že generácia stále halucinuje — alebo naopak.
Preto moderná evaluácia RAG delí meranie na dve vrstvy: retrieval metriky (context precision, context recall) a generation metriky (faithfulness, answer relevancy). A práve toto je filozofia za nástrojom RAGAS.
RAGAS — čo to je a čo nie je
RAGAS (Retrieval-Augmented Generation Assessment) je open-source evaluačný framework, ktorý meria kvalitu RAG pipeline bez potreby ručných anotácií pre každý prípad. Namiesto toho používa LLM-as-judge prístup: výrok alebo tvrdenie hodnotí ďalší jazykový model.
Čo RAGAS je: framework na offline evaluáciu RAG pipeline pomocou gold standard datasetu (nazývaného golden set). Dáš mu otázky, referenčné odpovede, kontexty načítané tvojím retrieval-om a vygenerované odpovede — a vypočíta ti štyri kľúčové metriky.
Čo RAGAS nie je: produkčný monitoring v reálnom čase, náhrada za evals celej LLM aplikácie, ani nástroj na meranie faktickej správnosti knowledge base samotnej. Ak tvoje dokumenty obsahujú nesprávne informácie, RAGAS to nezachytí — meria konzistenciu a relevantnosť, nie pravdivosť zdrojov.
Dôležité odlíšenie oproti iným typom evaluácie: RAGAS sa zameriava výlučne na RAG komponent. Ak chceš merať kvalitu LLM odpovede nezávisle od retrieval-u, alebo hodnotiť fine-tuned model, ideš na iné metriky — tie patria do samostatnej oblasti evals. Rovnako, fine-tuning eval (napríklad meranie toho, či fine-tuning pomohol) je iná disciplína než RAG eval.
Štyri kľúčové metriky RAGAS
Context Precision
Context precision meria, či dokumenty, ktoré retrieval vrátil, sú skutočne relevantné pre danú otázku. Konkrétne: aká časť načítaného kontextu je užitočná pre vygenerovanie správnej odpovede?
Vysoká context precision znamená, že retrieval nevracia šum — každý načítaný chunk prispieva k odpovedi. Nízka context precision signalizuje, že systém načítava príliš veľa nesúvisiacich dokumentov, čo degraduje kvalitu generácie (LLM sa musí orientovať cez relevantný aj nerelevantný materiál zároveň).
V praxi: ak máš nízku context precision, problém je typicky v embedding modeli, chybnej segmentácii dokumentov (chunking), alebo v nastavení top-K (načítavaš príliš veľa dokumentov). Viac o výbere a nastavení retrieval komponentov nájdete v článku o hybridnom vyhľadávaní.
Context Recall
Context recall je komplementárna metrika: aká časť informácií potrebných na správnu odpoveď sa nachádza v načítanom kontexte? Meria sa oproti referenčnej odpovedi z golden set-u.
Ak je context recall nízka, retrieval míňa relevantné dokumenty — informácia existuje v knowledge base, ale systém ju nenachádza. Príčiny bývajú: nedostatočná kvalita embedding modelu pre daný jazyk alebo doménu, zlý chunking (informácia je rozdelená cez viacero fragmentov a ani jeden z nich sám osebe nestačí), alebo príliš malé K (načítavaš napríklad len top-3, ale relevantný dokument skončil na 7. mieste).
Faithfulness
Faithfulness meria, do akej miery je vygenerovaná odpoveď podložená načítaným kontextom. RAGAS to robí tak, že rozloží odpoveď na jednotlivé tvrdenia a pre každé z nich overí, či je explicitne alebo implicitne podložené v kontexte.
Toto je najdôležitejšia metrika z pohľadu dôveryhodnosti RAG systému. Nízka faithfulness znamená, že model halucinuje — generuje informácie, ktoré sú v načítanom kontexte neprítomné, ale znejú plausibilne. Je kriticky dôležité pochopiť: faithfulness ≠ faktická správnosť. Model môže byť perfektne faithful (100 % odpovede je podložené kontextom), ale kontext samotný môže byť nesprávny. Ak chceš merat faktickú presnosť, musíš riešiť kvalitu knowledge base oddelene.
Nízka faithfulness sa typicky opravuje na úrovni systémového promptu (inštrukcie, aby model odpovedal výlučne z kontextu), výberom modelu (niektoré modely sú konzistentnejšie v sledovaní inštrukcií), alebo pridaním guardrails vrstvy. O guardrails pre AI agentov, vrátane faithful-answer checks, je viac v článku o guardrails pre AI agentov.
Answer Relevancy
Answer relevancy hodnotí, či odpoveď skutočne adresuje položenú otázku. RAGAS to meria tak, že z vygenerovanej odpovede spätne generuje viacero hypotetických otázok a overuje, či sú podobné pôvodnému dotazu.
Nízka answer relevancy môže nastať aj pri vysokej faithfulness: model môže byť verný kontextu, ale odpovedí na inú otázku, ako bola položená — typicky keď je kontext vágny alebo keď systémový prompt nie je dostatočne direktívny. V praxi táto metrika odhaľuje problémy s promptingom a formuláciou otázok.
Golden set — základ každej evaluácie
RAGAS metriky sú len tak dobré, ako je dataset, na ktorom ich počítaš. Zlatý standard (golden set) je sada testovacích prípadov vo formáte:
- Otázka — reálny alebo reprezentatívny dotaz
- Referenčná odpoveď — overená správna odpoveď (ground truth)
- Načítaný kontext — dokumenty vrátené tvojim retrieval-om pre daný dotaz
- Vygenerovaná odpoveď — výstup tvojho RAG systému
Problém je, že zostavenie golden set-u je nákladné: typicky 100–300 prípadov pre základnú evaluáciu, 500–1 000 pre robustnejšiu. Ručná tvorba každého prípadu od doménového experta je pomalá a drahá.
Tu nastupujú dve stratégie:
Syntetická generácia golden set-u: RAGAS aj ďalšie nástroje obsahujú funkcie na automatické generovanie testovacích otázok priamo z tvojich dokumentov. LLM prečíta fragment, vygeneruje otázku a referenčnú odpoveď. Výhoda: rýchlosť a škálovateľnosť. Nevýhoda: syntetické otázky môžu byť príliš jednoduché alebo nezodpovedať skutočným dotazom používateľov. V praxi odporúčame miešať: 60–70 % syntetických prípadov ako základ, 30–40 % reálnych dotazov z produkčných logov anotovaných expertom.
Ťažba z produkčných logov: Keď RAG systém beží v produkcii, loguješ páry (otázka, odpoveď). Výber reprezentatívnych prípadov, anotácia spätnou väzbou od používateľov (thumbs up/down) alebo doménovým expertom — a máš realistický golden set odrazový od skutočného použitia.
Dôležitý princíp: golden set treba udržiavať živý. Keď sa knowledge base aktualizuje, časť testovacích prípadov sa stáva zastaralou. Pri veľkých aktualizáciách dokumentácie vždy overuj, či golden set stále odzrkadľuje aktuálny stav.
RAGAS v praxi — integrácia do pipeline
RAGAS je Python knižnica, ktorá sa jednoducho integruje do existujúceho RAG workflowu. Základný prípad použitia vyzerá takto: pre každý testovací prípad z golden set-u zavoláš evaluáciu s otázkou, referenčnou odpoveďou, načítaným kontextom a vygenerovanou odpoveďou. Výstupom sú skóre pre každú metriku, agregované aj per-case.
Čo je dôležité vedieť pred nasadením:
Cena: RAGAS interne volá LLM pre výpočet metrík (LLM-as-judge). Pre golden set 200 prípadov môžeš očakávať stovky až tisíce LLM volaní, čo pri frontier modeloch predstavuje nezanedbateľné náklady. V praxi sa odporúča používať menší, lacnejší model na judge funkciu (napríklad Haiku/Flash tier), alebo kde je to možné, lokálny open-weight model. Faithfulness výpočet je zvlášť token-intenzívny, pretože rozkladá odpoveď na tvrdenia.
Kadenčná evaluácia, nie len ad-hoc: Evaluácia má zmysel ako pravidelný proces — pri každej zmene retrieval komponentu, aktualizácii knowledge base, alebo úprave promptov. Odporúčame zaradiť RAGAS evaluáciu do CI/CD pipeline-u aspoň pre sanity check na podmnožine golden set-u pred každým deploymentom.
Interpretácia absolútnych čísel: Skóre 0,80 pre faithfulness nie je objektívne dobré ani zlé — záleží na use case. Pre medicínsku dokumentáciu je 0,80 nedostatočné. Pre interný helpdesk to môže byť dostatočné. Dôležitejšie sú trendy: ak po úprave promptu klesla faithfulness z 0,85 na 0,72, máš jasný signál.
Oddelenie retrieval eval od generation eval
Kľúčová praxe, ktorú vidíme nedostatočne využívanú: eval retrieval komponentu a eval generation komponentu treba robiť aj nezávisle, nielen cez RAGAS end-to-end.
Retrieval eval samostatne: Môžeš hodnotiť retrieval bez akejkoľvek LLM generácie. Pre každú testovú otázku vieš, ktoré dokumenty by mal retrieval ideálne nájsť (z golden set-u). Meraš precision@K a recall@K — koľko z relevantných dokumentov skončilo v top-K výsledkoch. Toto ti dáva čistý signál o kvalite embedding modelu, indexovacej stratégie a nastavenia vyhľadávania — bez toho, aby generatívny model zakrýval problémy alebo kompenzoval retrieval chyby.
Generation eval samostatne: Môžeš zafixovať kontext — namiesto dynamicky načítaných dokumentov dáš modelu vždy rovnaký, manuálne overený kontext — a merať len faithfulness a answer relevancy. Toto izolovane testuje schopnosť modelu nasledovať inštrukcie a extrahovať informácie z poskytnutého textu.
Kombinácia oboch pohľadov s end-to-end RAGAS metrikami dáva komplexný obraz o tom, kde presne pipeline stráca kvalitu.
Čo RAGAS nezmeria — a na čo si dať pozor
RAGAS je mocný nástroj, ale má hranice, ktoré treba explicitne poznať.
Faktická správnosť knowledge base: Ako sme spomínali, RAGAS meria konzistenciu odpovede s kontextom. Ak dokumenty v knowledge base obsahujú zastarané alebo nesprávne informácie, RAGAS to neodhalí. Kvalitu knowledge base musíš riešiť oddelene — cez doménový review, datovania dokumentov, a mechanizmy update-u.
Latencia a náklady v produkcii: RAGAS je offline evaluačný nástroj. Nepovie ti, ako sa pipeline správa pri vysokom objeme dotazov, aká je skutočná latencia pre používateľa, ani aké sú produkčné tokenové náklady. Pre tieto metriky potrebuješ produkčný monitoring — nástroje ako LangSmith, Langfuse, alebo vlastný logging layer. O observabilite AI agentov a produkčnom monitoringu podrobnejšie píšeme v článku o observabilite AI agentov.
Bezpečnostné vlastnosti: RAGAS nemeria odolnosť voči prompt injection, schopnosť systému odmietnuť nevhodné dotazy, ani dodržiavanie bezpečnostných guardrails. Toto patrí do security eval, ktorá je oddelená disciplína.
Jazyková kvalita a register: Ak tvoji používatelia komunikujú po slovensky a knowledge base je po anglicky, RAGAS skóre ti nehovorí nič o kvalite prekladu alebo naturalnosti slovenských odpovedí. Ak pracuješ s multilingválnym setup-om, potrebuješ ľudskú evaluáciu jazykovej kvality.
Časté otázky
Koľko prípadov potrebujem v golden set-e na spoľahlivé výsledky?
Pre prvý baseline postačí 50–100 prípadov, aby si získal orientáciu. Pre rozhodnutia ako „zmeniť embedding model" alebo „upraviť chunking stratégiu" odporúčame 200–400 prípadov pokrývajúcich rôzne typy otázok a časti knowledge base. Pod 50 prípadmi sú výsledky príliš citlivé na individuálne outliers.
Môžem RAGAS používať na produkčný monitoring v reálnom čase?
Nie priamo — každé RAGAS meranie stojí LLM volania, čo je príliš drahé na každý produkčný dotaz. Typický prístup je sampling: namiesto merania každého dotazu vezmeš náhodný 1–5 % sample, spustíš RAGAS evaluáciu asynchrónne a sleduješ trendy v čase. Pre produkčný real-time monitoring sa viac hodí jednoduchšie signály: thumbs up/down feedback od používateľov, latencia, počet fallback odpovedí.
Ako viem, či je problém v retrieval-e alebo v generation-e?
Najjednoduchší test: skopíruj ručne relevantný dokument priamo do kontextu (obíď retrieval) a pošli ho modelu. Ak je odpoveď dobrá, problém je v retrieval-e. Ak aj s perfektným kontextom model halucinuje alebo odpovedá nerelevantne, problém je v generation vrstve — prompte, modeli, alebo spôsobe, akým formátuješ kontext. Tento manuálny test je rýchlejší ako plnohodnotný eval a odhalí väčšinu problémov v minútach.
Je LLM-as-judge spoľahlivý? Nemôže hodnotiť chybne?
LLM-as-judge má vlastné slepé body — napríklad dlhšie odpovede hodnotí vyššie aj keď sú menej presné, alebo uprednostňuje štýl blízky tréningovým dátam judge modelu. RAGAS to čiastočne kompenzuje tým, že faithfulness rozkladá na konkrétne tvrdenia a overuje každé zvlášť. Pre kritické use cases (regulované odvetvia, bezpečnostne citlivé systémy) odporúčame kombinovať automatický eval s ľudskou kontrolou aspoň pre podmnožinu prípadov.
Aký model použiť ako judge v RAGAS?
Pre väčšinu prípadov stačí frontier model strednej triedy (Sonnet/Flash/Haiku tier) — je dostatočne presný a výrazne lacnejší ako maximálny tier. Ak máš on-prem požiadavky alebo citlivé dáta, RAGAS podporuje aj lokálne modely cez OpenAI-compatible API — silný open-weight model z rodiny Qwen3 alebo Llama na inferencii cez vLLM funguje dobre pre judgment úlohy.
*Ak váhate, kde začať s evaluáciou vášho RAG systému, alebo chcete preveriť, kde presne vaša pipeline stráca presnosť — v MP Industrial Solutions robíme diagnostické posúdenia RAG nasadení a pomáhame nastaviť evaluačný proces, ktorý dáva akčné výsledky, nie len čísla.*