Cum să construiți un RAG fiabil: O analiză profundă a celor 7 puncte de eșec și a cadrelor de evaluare

Generarea augmentată de recuperare (RAG) este critică pentru arhitectura modernă AI, servind ca un cadru esențial pentru construirea de agenți conștienți de context.

Dar trecerea de la un prototip de bază la un sistem gata de producție implică navigarea unor obstacole semnificative în recuperarea datelor, consolidarea contextului și sinteza răspunsului.

Acest articol oferă o analiză profundă a celor șapte puncte de eșec tipice RAG și a metricilor de evaluare cu exemple practice de cod.

Anatomia eșecului RAG – 7 puncte de eșec (FP)

Conform cercetătorilor Barnett et al., sistemele RAG întâlnesc șapte puncte de eșec specifice pe tot parcursul pipeline-ului.

Diagrama de mai jos ilustrează aceste etape:

Figura A. Procesele de indexare și interogare necesare pentru crearea unui sistem RAG. Procesul de indexare se efectuează la momentul dezvoltării, iar interogările la momentul rulării. Punctele de eșec identificate în acest studiu sunt afișate în cutii roșii (sursă)

Să explorăm fiecare punct de eșec, dispus în ordinea pipeline-ului, urmând progresia de sus în jos din Figura A.

FP1. Conținut lipsă

Conținutul lipsă apare atunci când sistemul este întrebat cu o întrebare care nu poate fi răspunsă pentru că informația relevantă nu este prezentă în magazinul de vectori disponibil din primul loc.

Eșecul apare atunci când un LLM oferă un răspuns care sună plauzibil, dar este incorect, în loc de a spune nu știu.

FP2. Documente clasate greșit

Acesta este un caz în care un document corect există în magazinul de vectori, dar recuperatorul nu reușește să îl claseze suficient de sus pentru a fi inclus în documentele top-k furnizate LLM-ului ca context.

În consecință, informația corectă nu ajunge niciodată la LLM.

FP3. Nu este în context (limitări ale strategiei de consolidare)

Acesta este un caz în care un document corect există și este recuperat din magazinul de vectori, dar este exclus în timpul procesului de consolidare.

Acest lucru se întâmplă atunci când prea multe documente sunt returnate și sistemul trebuie să le filtreze pentru a se potrivi în fereastra de context a LLM-ului, limitele de token sau limitele de rată.

FP4. Nu a fost extras

Acesta este un caz în care un LLM nu reușește să identifice informația corectă în context, chiar dacă informația corectă era în magazinul de vectori și a fost recuperată și consolidată cu succes.

Acest lucru se întâmplă atunci când contextul este prea zgomotos sau conține informații contradictorii care îl confundă pe LLM.

FP5. Format greșit

Acesta este un caz în care stocarea, recuperarea, consolidarea și interpretarea LLM sunt gestionate cu succes, dar LLM nu reușește să urmeze instrucțiunile de formatare specifice furnizate în prompt, cum ar fi o tabelă, o listă cu puncte sau un schema JSON.

FP6. Specificitate incorectă

Ieșirea LLM este tehnic prezentă, dar prea generală sau prea complexă în comparație cu nevoile utilizatorului.

De exemplu, un LLM generează răspunsuri simple la o întrebare a utilizatorului cu un scop profesional complex.

FP7. Răspunsuri incomplete

Acesta este un caz în care un LLM generează o ieșire care nu este în mod necesar incorectă, dar lipsește informații cheie care erau disponibile în context.

De exemplu, atunci când un utilizator solicită un punct cheie din documente A, B și C, LLM-ul abordează doar una sau două dintre surse.

Cum compromit punctele de eșec performanța pipeline-ului RAG

Fiecare dintre aceste puncte de eșec afectează performanța pipeline-ului RAG:

Eșecuri de integritate a datelor și încredere

Atunci când informații lipsă sau incorecte sunt prezente, sistemul nu mai este o sursă de încredere a informațiilor. Punctele de eșec principale includ:

• FP1 (Conținut lipsă): Răspunsul nu este în documentul din primul loc.
• FP4 (Nu a fost extras): LLM-ul decide să ignore răspunsul corect din document.
• FP7 (Incomplet): LLM-ul oferă jumătăți de adevăruri, lipsind informații importante.

Stenoză și eficiență de recuperare

Pipeline-ul RAG poate fi ineficient atunci când ratează informații cheie în etapele de recuperare și consolidare. Punctele de eșec principale includ:

• FP2 (Documente clasate greșit): Modelul de încorporare nu reușește să selecteze încorporările top-k.
• FP3 (Consolidare): Scriptul care taie documentele pentru a se potrivi în limitele LLM-ului scapă părțile cele mai importante.

Eroare de experiență a utilizatorului și formatare

Deși corect, o ieșire cu o citire slabă sau într-un format greșit poate compromite experiența utilizatorului. Punctele de eșec principale includ:

• FP5 (Format greșit): LLM-ul nu reușește să urmeze formatul de ieșire specific, cum ar fi JSON.
• FP6 (Specificitate incorectă): LLM-ul generează un răspuns lung pentru o întrebare simplă cu un scop profesional complex sau invers.

Stiva de evaluare: Cadre pentru a reduce punctele de eșec

Metricile de evaluare sunt concepute pentru a reduce în mod sistematic aceste puncte de eșec.

Acestă secțiune explorează principalele metrici de evaluare RAG cu exemple practice.

Principalele metrici de evaluare RAG:

• DeepEval
• RAGAS
• TruLens
• Arize Phoenix
• Braintrust

DeepEval – Testul unitar înainte de implementare

DeepEval calculează un scor ponderat pe baza criteriilor.

Un LLM-judecător (de exemplu, GPT-4o) evaluează fiecare criteriu împotriva ieșirii LLM-ului:

DeepEval folosește G-eval, un cadru de gândire în lanț (CoT) care abordează o abordare multi-etapă pentru a evalua ieșirea:

1. Definirea unui criteriu de măsurare (de exemplu, “coerență”, “fluență” sau “relevanță”).
2. Generarea pașilor de evaluare (folosind un LLM evaluator).
3. Urmați pașii de evaluare și analizați intrarea și ieșirea LLM-ului.
4. Calculați o sumă ponderată așteptată a scorului pentru fiecare criteriu.

Scenariu comun în practică

• Situație: Un asistent de documentație tehnică (bot) pentru un produs software complex pare să funcționeze la fiecare actualizare a bazei de cod de către echipa de ingineri.
• Problemă: Nu există nici o dovadă cantitativă că botul poate răspunde în continuare la întrebarea utilizatorului (doar “crezi” că funcționează…).
• Soluție: Integrați o funcție PyTest într-un pachet de regresie CI/CD în acțiunea Github, unde DeepEval rulează G-Eval și alte metrici peste un caz de test:

• Rezultate așteptate: Dacă orice scor al metricilor scade sub pragul (0,85), PyTest ridică o AssertionError – imediat eșuând construcția CI, prevenind regresia silentă de a ajunge în producție.

Notă pentru dezvoltatori – Cazul de test pentru DeepEval
Un set de obiecte LLMTestCase definește cazul de test pe care DeepEval îl rulează.

În practică, acest caz de test ar trebui să conțină cele mai importante întrebări ale utilizatorilor și ieșiri etichetate cu contextul recuperat.

Acestea pot fi recuperate dintr-un fișier JSON sau CSV.

RAGAS – Optimizatorul acului într-un mănunchi de fân

Evaluarea RAG (RAGAS) are ca scop evaluarea RAG fără a necesita un set de date etichetate de către om prin generarea de seturi de test sintetice.

Apoi, calculează metrici de referință:

Figura B. Diagrama triunghiulară de evaluare RAGAS care conectează Întrebarea, Contextul și Răspunsul prin metrici de precizie, rechemare, fidelitate și relevanță (Creat de Kuriko IWAI)

Metricile de referință sunt grupate în trei categorii:

• Conducta de recuperare (linie neagră, solidă, Figura B): Precizie a contextului, rechemare a contextului.
• Pipeline de generare (linie neagră, punctată, Figura B): Fidelitate, relevanță a răspunsului.
• Adevărul (cutie roșie, Figura B): Similaritate semantică a răspunsului, corectitudinea răspunsului.

Scenariu comun în practică

• Situație: Sistemul RAG pentru contracte juridice lipsește clauze cheie. Nu sunteți sigur dacă problema este în căutare (Recuperator) sau în citire (Generator).
• Problemă: Nu aveți nici o idee despre numărul optim de top-k (numărul de fragmente recuperate).
• Soluție: Folosiți RAGAS pentru a crea un set de test sintetic cu 100 de perechi de întrebări și dovezi. Apoi, rulați pipeline-ul RAG împotriva setului de test pentru a calcula rechemarea contextului și precizia contextului:
• Rezultat așteptat: În funcție de rezultatele metricilor, planul de acțiune poate fi următorul:

Tabelul 1. Planul de acțiune de diagnostic RAGAS – Mapping Scoruri la ajustări ale sistemului.

TruLens – Specialistul în buclă de feedback

TruLens se concentrează pe mecanica internă a procesului RAG, mai degrabă decât doar pe ieșirea finală, folosind funcții de feedback.

De asemenea, utilizează un scor LLM bazat pe cât de bine răspunsul satisface intenția întrebării, folosind o scară Likert cu 4 puncte (0-3), făcându-l superior pentru clasarea calității diferitelor rezultate de căutare.

Scenariu comun în practică

• Situație: Un bot de consiliere medicală răspunde corect la o întrebare a utilizatorului, dar adaugă un sfat care nu este în baza de date PDF verificată.
• Problemă: Sfatul adăugat poate fi util, dar nu este întemeiat.
• Soluție: Folosiți TruLens pentru a implementa o funcție de feedback de întemeiere cu un prag, cum ar fi scor > 0,8.

• Rezultate așteptate: Atunci când LLM-ul generează un răspuns care conține informații care nu sunt prezente în fragmentele recuperate, TruLens semnalează înregistrarea în panoul dvs. de control.

Arize Phoenix – Harta eșecului silențios

Arize Phoenix este un instrument de observabilitate și evaluare cu sursă deschisă pentru a evalua ieșirile LLM, inclusiv sisteme RAG complexe.

Construit pe OpenTelemetry de Arize AI, se concentrează pe observabilitate, tratând evaluarea LLM ca o submulțime a MLOps.

În contextul evaluării RAG, Phoenix excelează în analiza încorporării, folosind Uniform Manifold Approximation and Projection (UMAP) pentru a reduce încorporările vectoriale de înaltă dimensiune în spațiu 2D/3D.

Această analiză a încorporării dezvăluie matematic dacă cererile eșuate sunt grupate semantic împreună, ceea ce indică o lacună în baza de date vectorială.

Scenariu comun în practică

• Situație: Un bot de suport pentru clienți funcționează bine pentru rambursări, dar oferă răspunsuri fără sens pentru revendicări de garanție.
• Problemă: Gaură de date în baza de date vectorială (Nu se găsește în jurnale).
• Soluție: Folosiți Arize Phoenix pentru a genera o vizualizare UMAP (UEV), o hartă 3D pentru baza de date vectorială – pentru a suprapune întrebările utilizatorilor peste fragmentele de document.
• Rezultate așteptate: Vedeți vizual un cluster de întrebări ale utilizatorilor care aterizează în zona întunecată unde nu există documente, spunându-vă că unele documente au fost uitate să fie încărcate în magazinul vectorial.

Braintrust – Rețeaua de siguranță a regresiei promptului

Braintrust este conceput pentru cicluri de iterare de înaltă frecvență, folosind comparația între modele.

Scenariu comun în practică

• Situație: O echipă de ingineri actualizează promptul de la “Răspunde la întrebare” (Caz A) la o instrucțiune de sistem mai complexă de 500 de cuvinte (Caz B).
• Problemă: Îmbunătățirea promptului pentru Caz B ar putea rupe accidental Caz A.
• Soluție: Folosiți Braintrust pentru a crea un set de date aur cu un set de N exemple perfecte (de exemplu, N = 50). Lăsați Braintrust să ruleze o comparație paralelă (SxS) la fiecare actualizare a unui singur cuvânt din prompt:

• Rezultat așteptat: Un raport de diferență care arată exact care cazuri s-au îmbunătățit sau înrăutățit pentru fiecare dintre setul de date aur (N = 50).

Încheiere

Atunci când sunt gestionate cu cadre de evaluare corespunzătoare, RAG poate fi un instrument competitiv pentru a oferi un context LLM cel mai relevant pentru întrebarea utilizatorului.

Strategia de implementare: Mapping Metricilor la Puncte de Eșec

Deși nu există o soluție care se potrivește tuturor, Tabelul 2 arată care metrici de evaluare să se aplice pentru fiecare punct de eșec pe care l-am acoperit în acest articol:

Tabelul 2. Matricea de reducere a punctelor de eșec – Care instrument rezolvă care punct de eșec?

DeepEval și RAGAS pot folosi metricile lor de fidelitate pentru a măsura eșecurile de integritate a datelor (FP1, FP4, FP7).

TruLens folosește precizia și rechemarea contextului pentru a măsura relevanța contextului pentru ieșire – evaluând eficient FP2.

Arize Phoenix oferă o urmă vizuală a procesului de recuperare, făcându-l ușor de văzut dacă documentul recuperat a fost pierdut în timpul consolidării (FP3).

Pentru eșecurile UX, DeepEval creează metrici personalizate pentru a evalua eșecurile UX, în timp ce Braintrust excelează în comparația setului de date de adevăr.