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

Generarea augmentată de recuperare (RAG) este critică pentru arhitectura modernă a inteligenței artificiale, 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ă aprofundată 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 (FPs)

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 interogarea 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, dispuse în ordinea secvenței pipeline, urmând progresia de sus în jos din Figura A.

FP1. Conținut lipsă

Conținutul lipsă se întâmplă atunci când sistemul este întrebat o întrebare care nu poate fi răspunsă pentru că informația relevantă nu este prezentă în magazinul vectorial disponibil din start.

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. Documentele clasate pe locul întâi au fost ratate

Acesta este un situație în care un document corect există în magazinul vectorial, dar recuperatorul nu reușește să îl clasifice 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 situație în care un document corect există și este recuperat din magazinul vectorial, 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 încadra în fereastra de context a LLM-ului, limitele de token sau limitele de rată.

FP4. Nu a fost extras

Acesta este un situație în care un LLM nu reușește să identifice informația corectă în context, chiar dacă informația corectă era în magazinul vectorial ș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 situație î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ă

Un output 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 obiectiv profesional complex.

FP7. Răspunsuri incomplete

Acesta este un situație în care un LLM generează un output care nu este neapărat greșit, dar lipsește bucăți cheie de informație care erau disponibile în context.

De exemplu, atunci când un utilizator întreabă o întrebare complexă, cum ar fi “Care sunt punctele cheie din documentele A, B și C?”, LLM 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:

Integritatea datelor și eșecurile de încredere

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

• FP1 (Conținut lipsă): Răspunsul nu este în document de la început.
• FP4 (Nu a fost extras): LLM decide să ignore răspunsul corect din document.
• FP7 (Incomplet): LLM oferă jumătăți de adevăr, lipsind bucăți importante.

Gâtuirile de recuperare și eficiență

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

• FP2 (Documentele clasate pe locul întâi au fost ratate): Modelul de încorporare nu reușește să selecteze încorporările top-k.
• FP3 (Consolidare): Scriptul pentru a tăia documente pentru a se încadra în limitele LLM elimină părțile cele mai importante.

Erori de experiență a utilizatorului și formatare

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

• FP5 (Format greșit): LLM nu reușește să urmeze formatul de ieșire specific, cum ar fi JSON.
• FP6 (Specificitate incorectă): LLM generează un output lung pentru o întrebare simplă da/nu, sau invers (prea scurt pentru o întrebare complexă).

Stiva de evaluare: Cadre pentru a mitigă punctele de eșec

Metricele de evaluare sunt proiectate pentru a mitigă în mod sistematic aceste puncte de eșec.

Acestă secțiune explorează metricele de evaluare majore cu cazuri practice.

Metrice de evaluare RAG majore:

• 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 unui output LLM:

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

1. Definirea unui criteriu de măsurat (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 inputul și outputul LLM.
4. Calculați o sumă ponderată așteptată a scorului fiecărui 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ă dovezi cantitative că botul poate răspunde întrebărilor utilizatorului (pur și simplu “credeți” că funcționează…).
• Soluție: Integrați o funcție PyTest într-un pachet de regresie CI/CD în Github Action, unde DeepEval rulează G-Eval și alte metrice 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ă să ajungă în producție.

Avantaje

• O varietate de metrice (50+) inclusiv verificări specializate de bias și toxicitate sunt disponibile.
• Se integrează fără probleme cu pipeline-urile CI/CD existente.
• Nu este necesară o referință. Evaluarea unui output se bazează doar pe prompt și contextul furnizat.

Dezavantaje

• Calitatea evaluării depinde puternic de capacitățile judecătorului LLM.
• Costisitor din punct de vedere computațional atunci când judecătorul LLM este un model de înaltă performanță.

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 Generării Augmentate de Recuperare (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ă metricele de bază:

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

Metricele de bază sunt împărțite în trei grupuri:

• Pipeline-ul de recuperare (linie neagră, solidă, Figura B): Precizie de context, rechemare de context.
• Pipeline-ul 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 legale lipsește clauze cheie. Nu sunteți sigur dacă problema este în căutare (Recuperator) sau în citire (Generator).
• Problemă: Nu aveți idee despre top-k (numărul de bucăți recuperate) optim.
• 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. Plan de acțiune de diagnostic RAGAS – Asocierea scorurilor cu ajustări ale sistemului.

Avantaje

• Excelent pentru un proiect în stadiu incipient, fără seturi de date de referință (Așa cum am văzut în exemplul de cod, RAGAS poate crea un set de test sintetic).

Dezavantaje

• Setul de test sintetic poate să nu includă erori factuale nuanțate.
• Cere un model de extragere robust pentru a descompune răspunsurile în afirmații individuale (am folosit gpt-4o în exemplu).

TruLens – Specialistul în buclă de feedback

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

De asemenea, folosește un scor LLM bazat pe cât de bine răspunsul satisface intenția întrebării, utilizând o scară Likert de 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 are bază.
• Soluție: Folosiți TruLens pentru a implementa o funcție de feedback de bază cu un prag, cum ar fi scor > 0,8.

• Rezultate așteptate: Atunci când LLM generează un răspuns care conține informații care nu sunt prezente în bucățile recuperate, TruLens marchează înregistrarea în dashboard-ul dvs.

Avantaje

• Vizualizează lanțul de raționament pentru a identifica exact unde a derapat agentul.
• Oferează suport încorporat pentru ancorare pentru a prinde halucinații în timp real.

Dezavantaje

• Curbă de învățare pentru definirea funcțiilor de feedback personalizate.
• Dashboard-ul poate părea greu de utilizat pentru scripturi simple.

Arize Phoenix – Harta eșecului silent

Arize Phoenix este un instrument de evaluare și observabilitate open-source pentru a evalua outputurile 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 UMAP (Uniform Manifold Approximation and Projection) pentru a reduce încorporările vectoriale de înaltă dimensiune în spațiu 2D/3D.

Această analiză a încorporării revelează matematic dacă întrebările 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 poate găsi î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 bucățile de document.
• Rezultat așteptat: 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.

Avantaje

• Native OpenTelemetry; se integrează cu stivele de monitorizare enterprise existente.
• Cel mai bun instrument pentru vizualizarea punctelor oarbe ale magazinului vectorial.

Dezavantaje

• Mai puțin axat pe scoruri, mai mult pe observare.
• Poate fi excesiv pentru aplicații mici sau unelte cu un singur agent.

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

Braintrust este proiectat pentru cicluri de iterație de înaltă frecvență, folosind comparația cross-model.

Scenariu comun în practică

• Situație: O echipă de ingineri actualizează promptul de la “Răspundeți 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 strica 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 laterală (SxS) la fiecare actualizare a unui singur cuvânt în prompt:

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

Avantaje

• Extrem de rapid pentru a testa înainte de implementare.
• Interfață excelentă pentru stakeholderi non-tehnici pentru a revizui și a evalua outputul.

Dezavantaje

• Proprietar/SaaS-orientat (deși au componente open-source).
• Mai puține metrice tehnice încorporate în comparație cu DeepEval sau RAGAS.

Încheiere

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

Strategia de implementare: Asocierea metricilor la punctele de eșec

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

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

DeepEval și RAGAS pot folosi metricele 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 output – evaluând eficient FP2.

Arize Phoenix oferă o urmărire vizuală a procesului de recuperare, făcând ușor să vedeți dacă documentul recuperat a fost pierdut în timpul consolidării (FP3).

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