Jak vytvořit spolehlivý RAG: Podrobný pohled na 7 bodů selhání a evaluační rámce

Retrieval-Augmented Generation (RAG) je kritický pro moderní architekturu AI, sloužící 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 evaluační metriky s praktickými příklady kódování.

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

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

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 během runtime. Body selhání identifikované v této studii jsou označeny červenými rámečky (zdroj)

Podívejme se na každý bod selhání podle pořadí potrubí, následujícím postupem zleva doprava podle Obrázku A.

FP1. Chybějící obsah

Chybějící obsah nastává, 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é 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, limitů tokenů nebo limitů rychlosti.

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é zmástí LLM.

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, odrážka 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 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 jednou nebo dvěma zdroji.

Jak body selhání kompromitují výkon RAG potrubí

Každý z těchto bodů selhání ovlivňuje výkon RAG potrubí:

Data integrity & Trust Failures

Když jsou přítomny chybějící nebo nesprávné informace, 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.

Vyhledávací & Efektivní láhve

RAG potrubí 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 vkládání nedokáže vybrat top-k vkládání.
• FP3 (Konsolidace strategie): 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 (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).

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 – Jediný 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ý přijímá vícekrokový přístup k hodnocení výstupu:

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

Obvyklá situace v praxi

• Situace: Technický asistent dokumentace (bot) pro složitý software produkt parece fungovat 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…).
• Riešenie: Integrujte funkci PyTest do regresního souboru CI/CD, 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 většinu důležitých uživatelských dotazů 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á vlajkové metriky:

Obrázek B. RAGAS evaluační triáda diagram spojující Otázku, Kontext a Odpověď přes Přesnost, Recall, Věrohodnost a Relevance metriky (Vytvořeno Kuriko IWAI)

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

• Vyhledávací potrubí (černá, pevná linka, Obrázek B): Kontext přesnost, kontext recall.
• Generační potrubí (černá, tečkovaná linka, Obrázek B): Věrohodnost, odpověď relevance.
• Pozemský truth (červená krabička, Obrázek B): Odpověď semantická podobnost, odpověď správnost.

Obvyklá situace v praxi

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

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í založen na faktech.
• Riešenie: Použijte TruLens k implementaci funkce zpětné vazby pro založení se na prahu, jako je skóre > 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 – Tichá 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,扱ující hodnocení LLM jako podmnožinu MLOps.

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

Tato analýza vkládání matematicky odhaluje, zda selhané dotazy jsou seskupeny dohromady, 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).
• Riešenie: 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 vysoké frekvenční iterace 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.
• Riešenie: 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, která ukazuje, které případy se zlepšily/zhoršily pro každou ze zlatých dat (N = 50).

Závěrem

Když jsou správně zpracovány evaluační rámce, RAG může 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ěrohodnosti 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 dokument načtený 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ání s pozemským truth.