Retrieval-Augmented Generation (RAG) je dnes základní architektura pro napojení jazykových modelů na firemní data. Princip je jednoduchý: model dostane otázku, vyhledá relevantní fragmenty v databázi a na jejich základě odpovídá. Co ale dělá, když vyhledávání selže? Většina systémů to řeší tím nejprimitivnějším způsobem – zkusí to znovu. Skill-RAG, čerstvá práce publikovaná na arXiv, přináší zásadně odlišný přístup: místo slepého opakování diagnostikuje příčinu selhání a vybere specifickou opravu.

Problém: Opakování bez poučení

Představte si lékaře, který pacientovi předepíše lék. Když lék nezabere, nezvýší prostě dávku a nedoufá. Provede diagnostiku – proč nezabral? Špatná diagnóza? Interakce s jiným lékem? Nedostatečná délka léčby? Teprve na základě diagnózy změní postup.

Současné RAG systémy se ale chovají jako ten lékař, který jen zvyšuje dávku. Když vyhledávání nepřinese relevantní výsledky, systém buď zopakuje dotaz v nezměněné podobě, nebo ho mírně přeformuluje bez pochopení toho, co vlastně selhalo. Výzkumníci za Skill-RAG identifikovali zásadní vhled: většina přetrvávajících selhání vyhledávání není způsobena tím, že by v databázi relevantní informace neexistovaly, ale strukturálním nesouladem mezi tím, jak se ptáme, a tím, jak jsou data indexována.

A co je klíčové – tento nesoulad není jednoho typu. Existují různé kategorie selhání, z nichž každá vyžaduje jinou opravnou strategii.

Jak Skill-RAG funguje

Systém stojí na dvou komponentách, které spolupracují v uzavřené smyčce.

Hidden-State Prober: Diagnostik uvnitř modelu

První komponenta je lehká neuronová síť (feed-forward prober), která analyzuje skryté stavy jazykového modelu v průběhu generování odpovědi. Model při zpracování dotazu interně „ví“ více, než co vypíše – jeho skryté vrstvy obsahují signály o tom, zda si je odpovědí jistý, zda nalezený kontext odpovídá dotazu, nebo zda je v potížích.

Prober tyto signály čte ve dvou fázích:

1. Před vyhledáváním – rozhodne, zda je vyhledávání vůbec potřeba (model možná zná odpověď z vlastních parametrů).
2. Po vyhledávání – zhodnotí, zda nalezený kontext vedl ke správné odpovědi, nebo zda se jedná o selhání.

Skill Router: Čtyři opravné dovednosti

Když prober detekuje selhání, aktivuje se druhá komponenta – prompt-based skill router. Ten analyzuje neúspěšné uvažování, vygenerovanou odpověď a nalezený kontext, a diagnostikuje příčinu problému. Na základě diagnózy vybere jednu ze čtyř „dovedností“:

Query Rewriting (přeformulování dotazu). Původní otázka je formulovaná jinak, než jak jsou data indexovaná. Typický příklad: uživatel se ptá „Jak řešit problém s padáním aplikace“ a v databázi jsou dokumenty o „crash handling“ a „exception management“. Skill router dotaz přeformuluje tak, aby odpovídal jazyku korpusu.

Question Decomposition (rozložení na podotázky). Otázka je příliš komplexní na to, aby ji jedno vyhledání pokrylo. Router ji rozloží na dílčí podotázky, které se zodpoví postupně. Například „Jaký je vliv nové regulace na pricing enterprise produktů a jak to ovlivní retenci?“ se rozloží na dvě samostatné otázky.

Evidence Focusing (zaostření na relevantní evidenci). Vyhledávání nalezlo mnoho fragmentů, ale model se „ztratil“ v přemíře informací. Router zpřesní zaměření na relevantní podmnožinu nalezených výsledků.

Exit Skill (ukončení). Některé dotazy jsou skutečně nezodpověditelné – data v korpusu prostě neexistují. Místo nekonečného opakování systém čistě ukončí zpracování a přizná, že odpověď nemá. To je zásadní rozdíl oproti systémům, které se cyklí ve smyčce a spotřebovávají tokeny bez výsledku.

Klíčový vhled: Selhání mají strukturu

Nejzajímavější zjištění práce je, že různé typy selhání zaujímají oddělené, strukturované oblasti ve stavovém prostoru modelu. Jinými slovy – selhání způsobené špatně formulovaným dotazem „vypadá“ jinak v skrytých stavech modelu než selhání způsobené příliš komplexní otázkou.

To znamená, že nesoulad mezi dotazem a evidencí není monotonní fenomén, ale typovaný. Každý typ má svou charakteristiku a vyžaduje svou opravu. Skill-RAG je první framework, který toto rozlišení systematicky využívá.

Výsledky na benchmarcích

Autoři testovali Skill-RAG s modelem Gemma2-9B na standardních QA a reasoning benchmarcích:

Benchmark	Typ	Výsledek Skill-RAG
HotpotQA	Multi-hop QA	Konkurenční se state-of-the-art
Natural Questions	Open-domain QA	Silné výsledky
TriviaQA	Open-domain QA	Silné výsledky
MuSiQue	Out-of-distribution	Výrazně lepší než jednoduché přístupy
2WikiMultiHopQA	Out-of-distribution	Výrazně lepší než jednoduché přístupy

Nejsilnější výsledky Skill-RAG dosahuje na out-of-distribution datasetech – tedy na datech, která se liší od trénovací distribuce. To je přesně tam, kde jednoduché metody (opakování bez diagnostiky) selhávají nejvíce.

Praktické závěry a tipy

Pro vývojáře RAG systémů

Přestaňte opakovat naslepo. Pokud váš systém při selhání vyhledávání jednoduše přeformuluje dotaz a zkusí znovu bez diagnostiky, plýtváte tokeny a latencí. Skill-RAG ukazuje, že diagnóza příčiny selhání a cílená oprava je výrazně efektivnější než slepé opakování.

Sledujte skryté stavy modelu. Hidden-state probing je technika s širším využitím než jen RAG. Skryté vrstvy modelu obsahují signály o nejistotě, relevanci kontextu a kvalitě odpovědi, které se nedostanou do výstupního textu. Lehký prober je nenákladný doplněk vaší pipeline, ale výrazně zvyšuje schopnost systému detekovat vlastní chyby.

Exit skill je důležitější, než si myslíte. Většina produkčních RAG systémů nemá mechanismus pro čistě řízené ukončení, když odpověď neexistuje. Výsledkem jsou buď halucinace, nebo nekonečné smyčky. Explicitní „tuto otázku nedokážu zodpovědět“ je z hlediska uživatelské důvěry mnohem lepší než přesvědčivě znějící, ale vymyšlená odpověď.

Pro architekty AI systémů

Selhání nejsou jednoho typu. To je asi nejdůležitější konceptuální přínos práce. Pokud monitorujete svůj RAG systém jedinou metrikou „procento úspěšných vyhledávání“, přicházíte o zásadní informaci. Rozlišujte, zda selhání je způsobeno formulací dotazu, komplexitou otázky, přetížením kontextu nebo absencí dat. Každý typ vyžaduje jinou reakci.

Kombinujte s evaluační pipeline. Skill-RAG přirozeně zapadá do evaluačního frameworku typu RAGAS. Prober poskytuje signál o kvalitě vyhledávání v reálném čase, skill router loguje, kterou opravu zvolil. Tato data jsou cenná pro průběžnou optimalizaci celého systému.

Pro byznys rozhodování

Vyhledávání, které se samo opravuje, znamená méně eskalací. V produkčním nasazení (zákaznický support, interní helpdesk, compliance dotazy) každé nesprávně zodpovězené vyhledávání buď vyžaduje lidskou eskalaci, nebo způsobí chybu v rozhodování. Systém, který diagnostikuje a automaticky opravuje selhání, snižuje obojí.

Omezení a otevřené otázky

• Závislost na konkrétním modelu. Experimenty jsou provedeny výhradně s Gemma2-9B. Přenositelnost hidden-state proberu na jiné architektury (Llama, Mistral, Phi) není validována. Skryté stavy mají u každé rodiny modelů jinou strukturu, takže prober vytrénovaný na Gemma2 nebude přímo fungovat na jiném modelu.
• Latence opravných smyček. Každá aktivace skill routeru přidává další krok inference. U query decomposition to může znamenat 2-3 dodatečná vyhledávání. Pro interaktivní chat aplikace s požadavkem na odpověď pod 3 sekundy to může být nepřijatelné.
• Čtyři dovednosti nemusí stačit. Paper identifikuje 4 kategorie selhání. V produkčních systémech existují další typy problémů – jazykový nesoulad (dotaz v češtině, data v angličtině), stale data, oprávněnický kontext (uživatel nemá přístup k relevantním dokumentům). Rozšiřitelnost skill routeru o další dovednosti není v paperu adresována.
• Trénovací náklady proberu. Paper neuvádí, kolik anotovaných příkladů selhání je potřeba pro natrénování hidden-state proberu. Pro vlastní doménu to znamená manuální anotaci případů selhání, což je nákladné.
• Benchmarky jsou anglické. Všechny evaluační datasety (HotpotQA, Natural Questions, TriviaQA, MuSiQue) jsou v angličtině. Chování na multilingválních datech není testováno.

Co udělat jako první krok

1. Klasifikovat selhání manuálně. Projděte posledních 100 neúspěšných dotazů ve vašem RAG systému a ručně je roztřiďte: špatná formulace dotazu, příliš komplexní otázka, přetížení kontextu, nebo data neexistují. Pokud některá kategorie dominuje, máte jasný cíl pro optimalizaci.
2. Implementovat exit skill. Nejjednodušší a okamžitě prospěšná změna: přidejte do své pipeline detekci, kdy odpověď na dotaz v korpusu neexistuje. Snížíte tím halucinace a zbytečné iterace.
3. Přečíst paper. Prostudujte originální práci na arXiv (odkaz níže), zejména sekce o skill routeru a hidden-state probingu. Konceptuální přínos (typované selhání) je cennější než konkrétní implementace.
4. Logovat retrieval metriky. Začněte měřit, kolik procent dotazů projde prvním vyhledáním úspěšně. Pokud je to pod 70 %, máte silný argument pro diagnostické vyhledávání.
5. Experimentovat s query rewriting. I bez plného Skill-RAG můžete okamžitě implementovat jednoduché přeformulování dotazu (synonyma, rozšíření klíčových slov) jako první opravnou dovednost.

Závěr

Skill-RAG přináší do světa RAG něco, co tam překvapivě chybělo – zdravý rozum. Když vyhledávání selže, je potřeba nejprve pochopit proč, a teprve na základě diagnózy jednat. Čtyři opravné dovednosti pokrývají hlavní kategorie selhání a exit skill zabraňuje plýtvání zdroji u nezodpověditelných dotazů.

Pro každého, kdo provozuje RAG v produkci a trápí se s kvalitou odpovědí na složitější dotazy, Skill-RAG nabízí konkrétní a implementovatelný rámec: přidejte diagnostiku, kategorizujte selhání, a pro každou kategorii mějte specifickou opravu. Je to lékařský přístup k retrieval selhání – nejprve diagnóza, pak léčba.

Zdroje a reference

• Skill-RAG: Failure-State-Aware Retrieval Augmentation – arXiv, duben 2026
• HotpotQA – jeden z evaluačních benchmarků
• MuSiQue – out-of-distribution benchmark
• RAGAS – evaluační framework kompatibilní se Skill-RAG přístupem

Shrnutí

Verdikt: Konceptuálně cenný pro každého, kdo provozuje RAG v produkci. Klíčový vhled (typované selhání) je implementovatelný i bez plného frameworku.