Jak vytvořit spolehlivý RAG: sedm bodů selhání a evaluační rámce podrobně

Retrieval-Augmented Generation (RAG) je zásadní pro moderní architekturu AI a slouží jako základní rámec pro tvorbu agentů, kteří zohledňují kontext.

Ale přechod od základního 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 evaluační metriky s praktickými příklady kódování.

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

Podle výzkumu Barnetta a kolegů, Retrieval Augmented Generation (RAG) systémy narazí na sedm specifických bodů selhání (FPs) v celém zpracovatelském řetězci.

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

Obrázek A. Indexování a procesy dotazů požadované pro vytvoření RAG systému. Indexování se provádí během vývoje a dotazy za běhu. Body selhání identifikované v této studii jsou označeny červenými rámečky (zdroj)

Projděme jednotlivé body selhání v pořadí zpracování, od levého horního rohu k pravému dolnímu, jak ukazuje obrázek A.

FP1. Chybějící obsah

Chybějící obsah nastává, když systém dostane 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, že neví.

FP2. Přehlédnuté top-rankované dokumenty

Toto je situace, kdy existuje správný dokument v úložišti, ale vyhledávací modul nedokáže jej řadit dostatečně vysoko, aby byl zahrnut do top-k dokumentů předaných 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 ú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, aby se vešly do kontextového okna LLM a byly dodrženy limity tokenů a četnosti požadavků.

FP4. Není extrahován

Toto je situace, kdy LLM nedokáže identifikovat správnou informaci v kontextu, ačkoli správná informace byla v úložišti a byla úspěšně načtena a zkonsolidována.

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

FP5. Špatný formát

Toto je situace, kdy jsou úspěšně zpracovány úložiště, načtení, konsolidace a interpretace LLM, ale LLM nedokáže dodržet specifické formátovací pokyny poskytnuté v dotazu, jako je tabulka, seznam s odrážkami nebo schéma JSON.

FP6. Nevhodná míra podrobnosti

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 uživatelský dotaz 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 k dispozici v kontextu.

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

Jak body selhání zhoršují výkon zpracovatelského řetězce RAG

Každý z těchto bodů selhání ovlivňuje výkon zpracovatelského řetězce RAG:

Selhání integrity dat a důvěry

Když informace chybějí nebo jsou nesprávné, systém již není spolehlivým zdrojem informací. Primární body selhání 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.

Úzká místa vyhledávání a efektivity

Zpracovatelský řetězec RAG může být neefektivní, když chybí klíčové informace ve fázích vyhledávání a konsolidace. Primární body selhání zahrnují:

• FP2 (Přehlédnuté top-rankované): Model embeddingů nedokáže vybrat top-k embeddingů.
• FP3 (Strategie konsolidace): Skript pro ořezání dokumentů, aby se vešly do limitů LLM, odstraní nejvýznamnější části.

Uživatelský zážitek & Formátovací chyby

Ačkoli je výstup správný, může být kompromitován uživatelský zážitek, pokud je výstup špatně čitelný nebo ve špatném formátu. Primární body selhání zahrnují:

• FP5 (Špatný formát): LLM nedokáže dodržet specifický formát výstupu, jako je JSON.
• FP6 (Nevhodná míra podrobnosti): LLM generuje rozsáhlý výstup pro jednoduchou otázku ano/ne nebo naopak (příliš krátká odpověď na složitou otázku).

Evaluační zásobník: Rámce pro zmírnění bodů selhání

Evaluační metriky jsou navrženy tak, aby systematicky zmírnily tyto body selhání.

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

Hlavní evaluační metriky RAG:

• DeepEval
• RAGAS
• TruLens
• Arize Phoenix
• Braintrust

DeepEval – Jednotkový test před nasazením

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

LLM jako soudce (například GPT-4o) hodnotí každé kritérium proti výstupu LLM:

DeepEval využívá G-eval, řetězec myšlenek (CoT) rámec, který využívá vícekrokový přístup k hodnocení výstupu:

1. Definujte kritérium pro měření (například “koherence”, “jazyková plynulost” nebo “relevance”).
2. Vygenerujte kroky hodnocení (pomocí evaluačního LLM).
3. Postupujte podle kroků hodnocení a analyzujte vstup a výstup LLM.
4. Vypočtěte očekávaný vážený součet skóre každého kritéria.

Obvyklá situace v praxi

• Situace: Asistent technické dokumentace (bot) pro složitý softwarový produkt zdánlivě funguje pokaždé, když inženýrský tým aktualizuje kódovou základnu.
• Problém: Žádné kvantitativní důkazy, zda bot stále dokáže odpovědět na uživatelský dotaz (pouze si myslíte, že funguje…).
• Řešení: Integrujte funkci PyTest do regresní testovací sady CI/CD v GitHub Actions, kde DeepEval spustí G-Eval a další metriky nad testovacím případem:

• Očekávané výsledky: Pokud skóre některé z metrik klesne pod prahovou hodnotu (0,85), PyTest vyvolá AssertionError – okamžitě selže sestavení CI, zabrání tiché regresi dosáhnout produkce.

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 nejdůležitější uživatelské dotazy a označené výstupy s načteným kontextem.

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

RAGAS – Optimalizátor jehly v kupce sena

Retrieval Augmented Generation Assessment (Ragas) je navržen pro hodnocení RAG bez lidsky anotované datové sady generováním syntetických testovacích sad.

Pak vypočítá hlavní metriky:

Obrázek B. Evaluační triáda RAGAS propojující otázku, kontext a odpověď prostřednictvím metrik přesnosti, úplnosti, věrnosti zdrojům a relevance (autor: Kuriko IWAI)

Hlavní metriky jsou rozděleny do tří skupin:

• Vyhledávací řetězec (černá, pevná linka, Obrázek B): Přesnost kontextu, úplnost kontextu.
• Generační řetězec (černá, tečkovaná linka, Obrázek B): Věrnost zdrojům, relevance odpovědi.
• Referenční data (červená krabička, Obrázek B): Sémantická podobnost odpovědi, správnost odpovědi.

Obvyklá situace v praxi

• Situace: Systém RAG pro právní smlouvy vynechává klíčová ustanovení. Nejste si jisti, zda problém je ve Vyhledávání (Vyhledávač) nebo ve Čtení (Generátor).
• Problém: Žádná představa o optimálním top-k (počtu načtených chunků).
• Řešení: Použijte RAGAS k vytvoření syntetické testovací sady se 100 páry otázek a důkazů. Pak spusťte zpracovatelský řetězec RAG na testovací sadě, aby se vypočítala úplnost kontextu a přesnost kontextu:
• 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.

TruLens – Specialista na zpětnou vazbu

TruLens se zaměřuje na vnitřní mechaniku procesu RAG, spíše než pouze na konečný výstup, pomocí zpětnovazebních funkcí.

Používá také skóre založené na LLM, které odráží, jak dobře odpověď splňuje záměr dotazu, pomocí 4-bodové Likertovy škály (0-3), což z něj činí lepší nástroj pro hodnocení kvality různých vyhledávacích výsledků.

Obvyklá situace v praxi

• Situace: Lékařský poradenský bot odpovídá na uživatelskou otázku správně, ale přidává pro-tip, který není v ověřené PDF základně.
• Problém: Přidaný pro-tip může být užitečný, ale není podložen těmito zdroji.
• Řešení: Použijte TruLens k implementaci funkce zpětné vazby ověřující oporu ve zdrojích s prahem, jako je score > 0.8.

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

Arize Phoenix – Mapa selhání

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

Postavený na OpenTelemetry od Arize AI, zaměřuje se na pozorovatelnost a chápe hodnocení LLM jako podmnožinu MLOps.

V kontextu hodnocení RAG vyniká Phoenix v analýze embeddingů, pomocí Uniform Manifold Approximation and Projection (UMAP) pro redukci vysokodimenzionálních vektorových embeddingů na 2D/3D prostor.

Tato analýza embeddingů matematicky odhaluje, zda neúspěšné dotazy tvoří sémantické skupiny, což indikuje mezeru ve vektorovém úložišti.

Obvyklá situace v praxi

• Situace: Zákaznický podpůrný bot funguje skvěle pro refundace, ale poskytuje nesmyslné odpovědi na dotazy o záruku.
• Problém: Databáze vektorového úložiště obsahuje díru (nelze najít v logu).
• Řešení: Použijte Arize Phoenix k vygenerování Umap Embedding Vizualizace (UEV), 3D mapy pro vektorové úložiště – pro překrytí uživatelských dotazů na dokumentové chunky.
• Očekávané výsledky: 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 nebyly nahrány do vektorového úložiště.

Braintrust – Bezpečnostní síť regrese promptu

Braintrust je navržen pro časté iterační cykly pomocí mezi-modelové komparace.

Obvyklá situace v praxi

• Situace: Inženýrský tým aktualizuje prompt z “Odpovězte na otázku” (Případ A) na složitější 500-slovnou systémovou instrukci (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). Nechte Braintrust spustit srovnání vedle sebe (SxS) pokaždé, když tým aktualizuje jediné slovo v promptu:

• Očekávaný výsledek: Zpráva o rozdílech přesně ukazuje, které ze všech N = 50 referenčních příkladů se zlepšily nebo zhoršily.

Závěrem

S vhodnými evaluačními rámci může RAG být konkurenceschopným nástrojem pro poskytování LLM kontextu, který je nejrelevantnější pro uživatelský dotaz.

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

Ačkoli neexistuje univerzální řešení, Tabulka 2 ukazuje, které evaluační metriky použít pro každý bod selhání, který jsme v tomto článku popsali:

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

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

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

Arize Phoenix poskytuje vizuální stopu procesu vyhledávání, což usnadňuje zjištění, zda se načtený dokument ztratil během konsolidace (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í s referenčními datovými sadami.