Jak postavit spolehlivý RAG: Podrobný pohled na 7 bodů selhání a rámce hodnocení

Retrieval-Augmented Generation (RAG) je kritický pro moderní architekturu AI, slouží jako základní rámec pro budování kontextově vědomých agentů.

Ale přechod od základní prototypu k produkčnímu systému zahrnuje překonání významných překážek v oblasti získávání dat, konsolidace kontextu a syntézy odpovědí.

Tento článek poskytuje podrobný pohled na sedm typických bodů selhání RAG a metriky hodnocení s praktickými příklady kódování.

Anatomie selhání RAG – 7 bodů selhání (FPs)

Podle výzkumníků Barnett et al., Retrieval Augmented Generation (RAG) systémy narazí na sedm konkrétních bodů selhání (FPs) v rámci potrubí.

Níže uvedený diagram ilustruje tyto fáze:

Figure A. Indexing and Query processes required for creating a RAG system. The indexing process is done at development time and queries at runtime. Failure points identified in this study are shown in red boxes (source)

Podívejme se na každý FP uspořádaný podle pořadí potrubí, následujícím horní-levý-dolní-pravý postup podle Figure A.

FP1. Chybějící obsah

Chybějící obsah se vyskytuje, když systém je požádán o otázku, na kterou nelze odpovědět, protože relevantní informace nejsou přítomny v dostupném vektorovém úložišti.

Selhání nastává, když LLM poskytuje věrohodně znějící, ale nesprávnou odpověď místo toho, aby uvedl neví.

FP2. Přehlédnuté nejvyšší dokumenty

Toto je situace, kdy existuje správný dokument v vektorovém úložišti, ale vyhledávač selhává při jeho zařazení do top-k dokumentů, které jsou předány LLM jako kontext.

V důsledku toho se správná informace nikdy nedostane k LLM.

FP3. Není v kontextu (omezení strategie konsolidace)

Toto je situace, kdy existuje správný dokument a je načten z vektorového úložiště, ale je vyloučen během procesu konsolidace.

To se stane, když je vráceno příliš mnoho dokumentů a systém musí filtrovat dolů, aby se vešel do kontextového okna LLM, limitů tokenů nebo limitů rychlosti.

FP4. Není extrahován

Toto je situace, kdy LLM selhává při identifikaci správné informace v kontextu, i když správná informace byla v vektorovém úložišti a byla úspěšně načtena/konsolidována.

To se stane, když je kontext příliš hlučný nebo obsahuje protichůdné informace, které zmást LLM.

FP5. Špatný formát

Toto je situace, kdy úložiště, načtení, konsolidace a interpretace LLM jsou úspěšně zpracovány, ale LLM selhává při dodržení specifických pokynů pro formátování poskytnutých v podnětu, jako je tabulka, odrážkový seznam nebo schéma JSON.

FP6. Nesprávná specificita

Výstup LLM je technicky přítomen, ale buď příliš obecný nebo příliš komplexní ve srovnání s potřebami uživatele.

Například LLM generuje jednoduché odpovědi na dotaz uživatele s komplexním profesionálním cílem.

FP7. Neúplné odpovědi

Toto je situace, kdy LLM generuje výstup, který není nutně špatný, ale chybí klíčové části informací, které byly dostupné v kontextu.

Například když uživatel položí složitou otázku, jako “Jaké jsou klíčové body v dokumentech A, B a C?”, LLM se zabývá pouze jednou nebo dvěma zdroji.

Jak FPs ohrožují výkon potrubí RAG

Každý z těchto FPs má dopad na výkon potrubí RAG:

Integrita dat a selhání důvěry

Když jsou přítomny chybějící nebo nesprávné informace, systém již není spolehlivým zdrojem informací. Primární FPs zahrnují:

• FP1 (Chybějící obsah): Odpověď není v dokumentu od začátku.
• FP4 (Není extrahován): LLM se rozhodne ignorovat správnou odpověď v dokumentu.
• FP7 (Neúplný): LLM poskytuje polopravdy, chybí důležité části.

Vyhledávání a úzká místa efektivity

Potrubí RAG může být neefektivní, když přehlíží klíčové informace ve fázích vyhledávání a konsolidace. Primární FPs zahrnují:

• FP2 (Přehlédnuté nejvyšší): Model vložení selhává při výběru top-k vložení.
• FP3 (Strategie konsolidace): Skript pro ořezání dokumentů, aby se vešly do limitů LLM, odstraní nejimportantnější části.

Uživatelský zážitek a chyby formátování

Ačkoli je výstup správný, výstup s špatnou čitelností nebo ve špatném formátu může ohrozit uživatelský zážitek. Primární FPs zahrnují:

• FP5 (Špatný formát): LLM selhává při dodržení specifického formátu výstupu, jako je JSON.
• FP6 (Nesprávná specificita): LLM generuje rozsáhlý výstup pro jednoduchou otázku ano/ne, nebo naopak (příliš krátká odpověď na složitou otázku).

Hodnotící zásobník: Rámce pro zmírnění FPs

Metriky hodnocení jsou navrženy tak, aby systematicky zmírnily tyto FPs.

Tato sekce prozkoumá hlavní metriky hodnocení s praktickými příklady použití.

Hlavní metriky hodnocení RAG:

• DeepEval
• RAGAS
• TruLens
• Arize Phoenix
• Braintrust

DeepEval – Jednotkový test před nasazením

DeepEval vypočítá vážený skór na základě kritérií.

LLM-as-a-judge (například GPT-4o) vyhodnotí každé kritérium proti výstupu LLM:

DeepEval využívá G-eval, rámec řetězec myšlení (CoT), který přistupuje k hodnocení výstupu 多 krokovým přístupem:

1. Definujte kritérium pro měření (například “koherence”, “proud” nebo “relevance”).
2. Vygenerujte kroky hodnocení (pomocí hodnotícího LLM).
3. Sledujte hodnocení kroků a analyzujte vstup a výstup LLM.
4. Vypočtěte očekávanou váženou sumu skóre každého kritéria.

Častý scénář v praxi

• Situace: Technický asistent dokumentace (bot) pro komplexní software produkt parece fungovat pokaždé, když inženýrský tým aktualizuje kódovou základnu.
• Problém: Žádný kvantitativní důkaz, zda bot může stále odpovědět na dotaz uživatele (pouze “myslíte” si, že funguje…).
• Řešení: Integrujte funkci PyTest jako regresní sadu CI/CD do Github Action, kde DeepEval spustí G-Eval a další metriky nad testovacím případem:

• Očekávaný výsledek: Pokud skór kteréhokoli z metrik klesne pod prahovou hodnotu (0,85), PyTest vyvolá AssertionError – okamžitě selže sestavení CI, čímž se zabrání tiché regresi, aby se dostala do produkce.

Pros

• Široká škála metrik (50+) včetně specializovaných kontrol偏见 a toxicity.
• Bezproblémová integrace se stávajícími potrubími CI/CD.
• Žádná reference není nutná. Hodnotí výstup pouze na základě podnětu a poskytnutého kontextu.

Cons

• Kvalita hodnocení silně závisí na schopnostech soudního LLM.
• Výpočetně náročné, když soudní LLM je model vysoké třídy.

Poznámka vývojáře – Testovací případ pro DeepEval
Sada LLMTestCase objektů definuje testovací případ, který DeepEval spustí.

V praxi by tento testovací případ měl obsahovat většinu důležitých dotazů uživatelů a označené výstupy s načteným kontextem.

Tyto lze načíst z souboru JSON nebo CSV.

RAGAS – Optimalizátor jehly v kupce sena

RAGAS (Retrieval Augmented Generation Assessment) má za cíl hodnotit RAG bez lidsky anotované datové sady generováním syntetických testovacích sad.

Pak vypočítá vlajkové metriky:

Figure B. RAGAS hodnocení triáda diagram spojující Otázku, Kontext a Odpověď přes Přesnost, Recall, Faithfulness a Relevancy metriky (Vytvořeno Kuriko IWAI)

Vlajkové metriky jsou rozděleny do tří skupin:

• Vyhledávací potrubí (černá, pevná linka, Figure B): Kontext přesnost, kontext recall.
• Generační potrubí (černá, tečkovaná linka, Figure B): Faithfulness, odpověď relevancy.
• Ground truth (červená krabička, Figure B): Odpověď semantická podobnost, odpověď správnost.

Častý scénář v praxi

• Situace: RAG systém pro právní smlouvy postrádá klíčové klauzule. Jste si jisti, zda je problém ve Vyhledávání (Vyhledávač) nebo ve Čtení (Generátor).
• Problém: Žádná idea o optimálním top-k (počtu chunků načtených).
• Řešení: Použijte RAGAS k vytvoření syntetické testovací sady se 100 páry otázek a důkazů. Pak spusťte potrubí RAG proti testovací sadě, aby se vypočítaly kontext recall a kontext přesnost:
• Očekávaný výsledek: V závislosti na výsledcích metrik, akční plán může být následující:

Tabulka 1. RAGAS Diagnostický akční plán – Mapování skórů na systémové úpravy.

Pros

• Vynikající pro ranou fázi projektu bez ground-true datových sad (jak jsme viděli v ukázce kódu, RAGAS může vytvořit syntetickou testovací sadu).

Cons

• Syntetická testovací sada může přehlédnout nuancované faktické chyby.
• Vyžaduje robustní extrakční model pro rozložení odpovědí na jednotlivé nároky (použil jsem gpt-4o v ukázce).

TruLens – Specialista na zpětnou vazbu

TruLens se zaměřuje na vnitřní mechanismy procesu RAG spíše než na konečný výstup pomocí funkcí zpětné vazby.

Také používá LLM-založený skór, který odráží, jak dobře odpověď uspokojí záměr dotazu, pomocí 4-bodové Likertovy škály (0-3), což z něj dělá lepší nástroj pro hodnocení kvality různých výsledků vyhledávání.

Častý scénář v praxi

• Situace: Lékařský poradenský bot odpovídá na otázku uživatele správně, ale přidává pro-tip, který není v ověřené PDF základně.
• Problém: Přídavek pro-tip může být užitečný, ale není založen na skutečných datech.
• Řešení: Použijte TruLens k implementaci funkce zpětné vazby založené na skutečných datech s prahovou hodnotou, jako je skór > 0,8.

• Očekávaný výsledek: Když LLM generuje odpověď, která obsahuje informace, které nejsou přítomny v načtených chunkách, TruLens označí záznam v Ihrem dashboardu.

Pros

• Vizualizuje řetězec myšlení pro identifikaci přesně toho, kde agent selhal.
• Poskytuje vestavěnou podporu pro zakotvení, aby chytil hallucinace v reálném čase.

Cons

• Směrnice pro definici vlastních funkcí zpětné vazby.
• Dashboard může cítit heavyweight pro jednoduché skripty.

Arize Phoenix – Mapa tichého selhání

Arize Phoenix je open-source nástroj pro pozorovatelnost a hodnocení, který hodnotí výstupy LLM, včetně komplexních systémů RAG.

Postavený na OpenTelemetry od Arize AI, se zaměřuje na pozorovatelnost, kterou behandluje jako podmnožinu MLOps.

V kontextu hodnocení RAG vyniká Arize Phoenix v analýze vložených analýz, pomocí Uniform Manifold Approximation and Projection (UMAP) pro redukci vysokodimenzionálních vektorových vložených analýz do 2D/3D prostoru.

Tato analýza vložených analýz matematicky odhalí, zda selhané dotazy jsou seskupeny dohromady, což indikuje mezeru ve vektorové databázi.

Častý scénář v praxi

• Situace: Zákaznický podpůrný bot funguje skvěle pro refundace, ale poskytuje nesmyslné odpovědi na nároky na záruku.
• Problém: Databáze mezery ve vektorové databázi (nemožné najít v logitech).
• Řešení: Použijte Arize Phoenix k vygenerování Umap Embedding Visualization (UEV), 3D mapy pro vektorovou databázi – pro překrytí uživatelských dotazů na dokumenty chunky.
• Očekávaný výsledek: Vizualizujte cluster uživatelských dotazů, které přistávají v tmavé zóně, kde neexistují žádné dokumenty, což naznačuje, že některé dokumenty jsou zapomenuty nahrát do vektorového úložiště.

Pros

• OpenTelemetry-native; integruje se se stávajícími podnikovými monitorovacími stavy.
• Nejlepší nástroj pro vizualizaci slepých míst vektorového úložiště.

Cons

• Méně zaměřeno na skóre, více na pozorování.
• Může být přehnané pro malé aplikace nebo single-agent nástroje.

Braintrust – Bezpečnostní síť regrese promptu

Braintrust je navržen pro vysoké frekvence iterací pomocí porovnání mezi modely.

Častý scénář v praxi

• Situace: Inženýrský tým aktualizuje prompt z “Odpovězte na otázku” (případ A) na komplexnější 500-slovní systémový instrukce (případ B).
• Problém: Vylepšení promptu pro případ B může náhodou rozbít případ A.
• Řešení: Použijte Braintrust k vytvoření zlaté datové sady se sadou N perfektních příkladů (například N = 50). Nechejte Braintrust spustit srovnávací porovnání (SxS) pokaždé, když tým aktualizuje jeden word v promptu:

• Očekávaný výsledek: Zpráva o rozdílech, která ukazuje přesně, které případy se zlepšily/zhoršily pro každou zlatou datovou sadu (N = 50).

Pros

• Extrémně rychlý test před nasazením.
• Skvělé UI pro netechnické stakeholdery, aby recenzovali a ohodnotili výstup.

Cons

• Proprietary/SaaS-focused (i když mají open-source komponenty).
• Méně vestavěných hlubokých technických metrik ve srovnání s DeepEval nebo Ragas.

Závěrem

Když jsou správně zpracovány s rámcem hodnocení, RAG může být konkurenceschopný nástroj pro poskytování LLM kontextu, který je nejrelevantnější pro dotaz uživatele.

Strategie implementace: Mapování metrik na body selhání

Ačkoli neexistuje žádný univerzální řešení, Tabulka 2 ukazuje, které metriky hodnocení použít pro každý FP, který jsme pokryli v tomto článku:

Tabulka 2. Matice zmírnění bodů selhání – Který nástroj řeší který FP?

DeepEval a RAGAS mohou využít své metriky faithfulness k měření selhání integrity dat (FP1, FP4, FP7).

TruLens využívá svou přesnost kontextu / recall k měření relevance kontextu k výstupu – efektivně hodnotí FP2.

Arize Phoenix poskytuje vizuální stopu procesu vyhledávání, což usnadňuje vidět, zda dokument načtený během procesu konsolidace byl ztracen (FP3).

Pro selhání uživatelského zážitku DeepEval vytváří vlastní metriky pro hodnocení selhání uživatelského zážitku, zatímco Braintrust vyniká v porovnávání ground-truth datových sad.