Ce este arhitectura RAG? O definiție completă, cu exemple practice detaliate

RAG, acronimul pentru retrieval augmented generation (generare augmentată prin regăsire), este un proces prin care LLM-urile folosesc informații externe pentru a-și extinde și îmbunătăți rezultatele. Arhitectura RAG este ansamblul de componente și conexiuni care face posibil RAG.

Există mai multe categorii de RAG, iar fiecare funcționează pe baza propriei arhitecturi. În esență, arhitectura unui sistem RAG determină modul specific în care informațiile sunt stocate, regăsite și transmise unui LLM.

Ce este arhitectura RAG?

Arhitectura RAG este configurația de bază a componentelor (și a capabilităților asociate acestora) care alimentează un anumit sistem RAG. Toate aceste arhitecturi pornesc de la un șablon fundamental, numit adesea RAG „simplu” sau „naiv”.

Iată o prezentare generală a arhitecturii RAG fundamentale:

• Sursa de informații: Aici sunt stocate informațiile externe. Poate fi un index de căutare, o bază de date vectorială care reprezintă cantități mari de informații sau un depozit de documente brute.
• Componenta de regăsire: Acesta este mecanismul prin care este interogată sursa de informații. Un sistem RAG poate folosi, de exemplu, o simplă căutare după cuvinte-cheie pentru a găsi fragmente de text relevante sau interogări vectoriale mai complexe pentru a efectua o căutare prin similaritate.
• Componenta de orchestrare: Acest strat este partea aplicației bazate pe LLM care inițiază pipeline-ul RAG pentru un prompt al utilizatorului, fie împreună cu LLM-ul, fie independent. De asemenea, compilează informațiile regăsite într-un prompt extins.

Componentele arhitecturii RAG sunt de obicei organizate pe două căi. Calea de ingestie preia datele și le organizează într-o sursă de informații în care se poate căuta. Bazele de date vectoriale, în care cantități mari de text sunt convertite într-un depozit de embedding-uri vectoriale ce poate fi interogat, sunt una dintre cele mai răspândite aplicații.

Calea de regăsire preia promptul utilizatorului și generează o interogare cu care se caută în sursa de informații. Orchestratorul adaugă apoi informațiile regăsite în contextul de intrare al LLM-ului. În cazul arhitecturilor RAG agentice și hibride, pot exista mai multe căi de regăsire.

Tipuri de arhitectură RAG

Este înșelător să privim RAG ca pe un set de arhitecturi complet distincte. Majoritatea inginerilor adoptă o abordare modulară, implementând componente separate pentru cazuri de utilizare specifice. Deși se pot trasa granițe aproximative, este important de reținut că există suprapuneri semnificative între modelele de arhitectură.

1. RAG de bază

RAG-ul de bază, numit și RAG „naiv” sau „simplu”, este șablonul arhitectural pentru celelalte tipuri de RAG.

Procesul de bază este relativ simplu: un utilizator introduce un prompt, orchestratorul stabilește dacă sunt necesare informații externe (fie independent, fie împreună cu LLM-ul), apoi formulează și trimite o interogare de regăsire în consecință.

Sursa externă de informații este de obicei o bază de date vectorială, dar poate fi și o bază de date SQL, un API web, un graf de cunoștințe sau chiar un depozit de documente „brute”. Aceste informații suplimentare sunt apoi adăugate în contextul de intrare al LLM-ului.

În afară de interogările SQL și de API-uri, există două mari tipuri de metode de regăsire:

• Căutare lexicală (căutare după cuvinte-cheie): Aceasta este o formă simplă de RAG în care cuvintele-cheie sunt extrase din interogarea utilizatorului și comparate cu pasajele de text care conțin acele cuvinte-cheie. În pipeline-urile moderne, orchestratorul poate efectua în acest scop o așa-numită interogare cu vectori rari (sparse), care nu surprinde sensul.
• Căutare vectorială densă (căutare semantică): Embedding-urile vectoriale dense surprind sensul. Un orchestrator poate interoga o bază de date vectorială densă astfel încât să fie surprins sensul atât al promptului utilizatorului, cât și al informațiilor-sursă.

Utilizarea memoriei este, de asemenea, o parte importantă a arhitecturii RAG. Aceasta se referă la modul în care un LLM folosește contextul din conversațiile anterioare pentru a construi o interogare de regăsire, ancorând-o astfel în contextul mai larg al unei discuții (sau al mai multor discuții). RAG-ul conversațional este norma pentru majoritatea chatboților, deși unele cazuri de utilizare, cum ar fi răspunsurile la tichetele de asistență, pot folosi RAG cu o singură întrebare.

2. Hibrid

RAG-ul hibrid combină două tipuri diferite de regăsire, de obicei regăsirea după cuvinte-cheie și cea semantică. Căutarea după cuvinte-cheie găsește termenii care se potrivesc, iar căutarea vectorială găsește pasaje cu sens înrudit.

Pot fi folosite și alte forme de regăsire, cum ar fi parcurgerea grafurilor de cunoștințe sau interogările bazelor de date SQL. Procesul este adesea ghidat de o logică de rutare, fie sub forma unor reguli programate, fie prin clasificarea întrebării de către un model (deși mai multe pipeline-uri pot rula și simultan).

Orchestratorul combină rezultatele și le poate reordona înainte de a le transmite LLM-ului. Reordonarea (reranking) este procesul prin care se atribuie scoruri de relevanță fragmentelor regăsite, astfel încât LLM-ul să acorde prioritate informațiilor celor mai pertinente.

3. RAG adaptiv

În RAG-ul adaptiv, o componentă de rutare selectează o strategie de regăsire în funcție de cerințele promptului utilizatorului, iar orchestratorul execută apoi fluxul de lucru selectat.

În cadrul original (Adaptive-RAG), un model mai mic acționa ca un clasificator și alegea între lipsa regăsirii, regăsirea într-un singur pas sau regăsirea în mai mulți pași. Unele arhitecturi folosesc acum, în schimb, modele generative sau euristici bazate pe reguli.

Este o arhitectură populară deoarece alocă putere de procesare în funcție de complexitatea și cerințele unui prompt, reducând pașii de regăsire inutili pentru prompturile mai simple. Este des întâlnită în asistenții care gestionează mai multe tipuri de întrebări.

4. RAG corectiv (CRAG)

RAG-ul corectiv evaluează informațiile regăsite înainte de a le adăuga în contextul de intrare al LLM-ului. Un evaluator de regăsire analizează dacă informațiile regăsite sunt relevante și utile. Elementul arhitectural distinctiv este etapa explicită de evaluare și corectare dinaintea generării răspunsului.

Dacă informațiile se dovedesc incomplete sau neaplicabile promptului, vor fi declanșate solicitări suplimentare. Acestea pot folosi alte metode de regăsire decât cele utilizate pentru solicitarea inițială, cum ar fi căutarea pe web sau parcurgerea grafurilor de cunoștințe.

RAG-ul corectiv este des folosit în domeniile în care acuratețea este importantă, cum ar fi medicina și dreptul. Totuși, necesită o sursă suplimentară de informații care să completeze pasajele regăsite inițial.

5. Self-RAG

În self-RAG, modelul poate iniția solicitări după ce primește contextul de intrare inițial. Răspunsurile generate sunt evaluate în raport cu dovezile regăsite cu ajutorul unor tokenuri de reflecție, iar solicitările suplimentare sunt trimise prin orchestrator, după caz. Pe de altă parte, LLM-ul poate decide că nu este necesară nicio regăsire.

Diferă de RAG-ul corectiv prin faptul că LLM-ul își evaluează propriile rezultate, stabilește dacă este necesară regăsirea și dacă textul regăsit este util și își monitorizează propriile răspunsuri, modificându-le după caz. RAG-ul corectiv, în schimb, evaluează calitatea informațiilor regăsite înainte de generare.

Această arhitectură este deosebit de utilă pentru prompturile complexe, de tipul cercetării aprofundate. Deoarece integrează evaluarea relevanței (informațiilor regăsite) în generarea răspunsului, este o opțiune bună pentru prompturile care necesită răspunsuri bazate pe dovezi.

6. RAG agentic

RAG-ul agentic desemnează orice formă de RAG executată în contextul unei platforme agentice. Modelul își folosește capacitățile de raționament pentru a determina tipul de informații necesare și alege dintre opțiunile de regăsire disponibile.

Regăsirea poate fi declanșată de mai multe ori, după necesități, iar modelul are opțiunea de a aloca agenți pentru interogările mai complexe. De exemplu, un LLM ar putea solicita o căutare într-o bază de date pentru a identifica un furnizor, ar putea declanșa o căutare în documente pentru a găsi contractele relevante și ar putea încheia cu o căutare pe web pentru a verifica datele de contact folosind surse publice.

RAG-ul agentic este principala implementare arhitecturală din chatboții de larg consum precum Perplexity, ChatGPT, Claude și alții. Deoarece aceste platforme oferă modelului de bază acces la mai multe instrumente și pipeline-uri RAG, acesta poate alege forma de regăsire cea mai potrivită pentru un prompt.

7. RAG multimodal

RAG-ul multimodal regăsește context din diferite tipuri de conținut media. Este o formă importantă de RAG deoarece pune la dispoziția LLM-urilor informații care altfel ar fi inaccesibile, cum ar fi diagramele și înregistrările audio.

Arhitectura de bază este aceeași ca în orice alt sistem. De exemplu, un pipeline de indexare poate pregăti imaginile pentru căutare convertindu-le în embedding-uri directe. Un sistem RAG agentic ar putea apoi să regăsească aceste imagini împreună cu text relevant din punct de vedere semantic și să le transmită unui model viziune-limbaj pentru procesare dublă.

8. GraphRAG

GraphRAG folosește grafuri de cunoștințe alături de căutarea vectorială pentru a regăsi informații despre entități. De obicei, orchestratorul găsește entitățile de pornire relevante, numite și noduri, prin extragerea cuvintelor-cheie sau, uneori, printr-o căutare vectorială preliminară. Un modul de regăsire în graf parcurge un graf de cunoștințe pentru a construi un context mai larg.

De exemplu, ca răspuns la o solicitare de analiză detaliată a unei categorii de produse, un LLM poate declanșa o căutare vectorială pentru a identifica entități specifice (produse). Orchestratorul va declanșa apoi o căutare în graful de cunoștințe pentru a găsi entități înrudite, cum ar fi furnizori, puncte de vânzare, recenzii și așa mai departe.

9. RAG ramificat

În timp ce o arhitectură RAG hibridă are capacitatea de a folosi diferite metode de regăsire, RAG-ul ramificat se referă la procesul de rulare simultană a mai multor interogări, numite ramuri. Fiecare ramură poate interoga o sursă de informații separată sau ramurile pot interoga aceeași sursă în paralel, cu interogări ori filtre diferite. Arhitectura RAG agentică folosește adesea RAG ramificat.

10. HyDE (Hypothetical Document Embeddings, embedding-uri de documente ipotetice)

HyDE este o formă inovatoare de RAG în care un LLM redactează un document text ipotetic care schițează cum ar putea arăta un răspuns optim. Acest „document ipotetic” este apoi folosit pentru a crea o interogare care permite o regăsire mai precisă. Deși cunoștințele relevante nu sunt reprezentate în parametrii LLM-ului, raționamentul este că un pasaj asemănător unui răspuns se poate potrivi cu documentele relevante mai bine decât o întrebare scurtă sau un prompt ambiguu.

Exemplu de arhitectură RAG simplă: bază de date vectorială

RAG-ul de bază stă la temelia unor tipuri de arhitectură mai complexe. În cazul unui sistem RAG simplu care folosește o bază de date vectorială, documentația-sursă este împărțită în bucăți mai mici (fragmente) și convertită în embedding-uri dense. Când un utilizator introduce un prompt, orchestratorul generează o interogare, o codifică și interoghează baza de date pentru a găsi pasaje relevante.

Iată o descriere pas cu pas a procesului:

1. Cantități mari de text sunt convertite în vectori cu ajutorul unui pipeline automatizat de ingestie și al unui model de embedding precum BERT.
2. Aplicația de bază de date organizează, indexează și stochează vectorii pentru o căutare rapidă.
3. Utilizatorul introduce un prompt într-un chatbot (cum ar fi Perplexity).
4. Orchestratorul aplicației codifică promptul (folosind un model de embedding) pentru a regăsi informațiile relevante din baza de date vectorială.
5. Baza de date vectorială returnează fragmentele relevante, iar orchestratorul le adaugă în contextul de intrare („promptul amplu”) și îl transmite LLM-ului.
6. LLM-ul folosește contextul suplimentar pentru a genera un răspuns pe baza cunoștințelor sale interne (stocate în ponderile sale parametrice).

Extinde

Exemplu de arhitectură RAG avansată: RAG agentic

RAG-ul agentic se referă la arhitectura de bază a sistemelor RAG dintr-o platformă agentică. Fluxurile RAG agentice tind să fie complexe, deoarece agenții AI pot apela diferite instrumente și pipeline-uri în funcție de natura unui prompt, lansând mai mulți agenți dacă este necesar.

Iată un exemplu practic al procesului:

1. Un utilizator introduce o întrebare complexă care necesită o cercetare aprofundată a unui subiect. Pentru acest exemplu, să presupunem că promptul este „Oferă o prognoză a câștigurilor companiei pentru următoarele șase luni, în lumina evenimentelor geopolitice majore”.
2. LLM-ul deduce că va fi nevoie de o combinație de interogări RAG pentru diferite tipuri de conținut.
3. Sunt lansați trei agenți diferiți pentru (a) căutare vectorială, (b) ancorare în surse web și (c) căutare de imagini (multimodală).
4. Agenții caută informații relevante, cum ar fi știri și date financiare interne, prin intermediul orchestratorului, folosind instrumentele de regăsire disponibile.
5. LLM-ul compară rezultatele regăsite cu întrebarea de cercetare a fiecărui agent și le ordonează în funcție de relevanță.
6. LLM-ul evaluează informațiile și declanșează căutări suplimentare prin intermediul agenților individuali acolo unde lipsesc informații.
7. După ce au fost regăsite suficiente informații, LLM-ul generează prognoze pentru diferite scenarii pe baza cifrelor financiare existente (regăsite din documentația internă) și apelează un instrument de calcul pentru a estima câștigurile în fiecare scenariu.
8. LLM-ul generează un răspuns final folosind informațiile regăsite și calculele, citând sursele după caz.

Extinde

Ce urmează pentru RAG?

Inovațiile actuale se concentrează pe creșterea profunzimii și a vitezei arhitecturilor RAG existente, pe îmbunătățirea acurateței regăsirii conținutului multimedia și pe construirea unor sisteme concepute să lucreze cu informații actualizate la minut.

Iată trei tendințe care modelează în prezent direcția cercetării:

• Cercetare aprofundată în mai multe surse: Este vorba despre o arhitectură RAG capabilă să planifice căutări, să ruleze mai multe ramuri în surse disparate, să evalueze dovezile regăsite și să-și optimizeze singură răspunsurile generate. RAG-ul agentic capabil să execute toate aceste sarcini devine tot mai rapid și mai eficient din punctul de vedere al costurilor.
• Aplicații multimodale: Pipeline-urile de regăsire lucrează din ce în ce mai bine cu imagini și videoclipuri. Ele pot identifica tot mai precis anumite tipuri de informații în date multimodale complexe, cum ar fi videoclipurile lungi și diagramele avansate.
• Ancorarea răspunsurilor în informații aflate în continuă schimbare: Aplicațiile bazate pe LLM pot folosi surse de informații în timp real (cum ar fi fluxurile video și senzorii) pentru a furniza context de intrare. De asemenea, sistemele pot genera rețele de informații cu multiple fațete, cum este cazul GraphRAG, pentru a interpreta aceste date.

RAG este esențial pentru modul în care funcționează aplicațiile bazate pe LLM. Permite unei game largi de utilizatori, de la consumatorii obișnuiți la companiile care activează în domenii specializate, să depășească problemele legate de halucinații, de datele de antrenament incomplete și de lipsa accesului la cunoștințe interne specializate.

De aceea, sistemele RAG și arhitectura care stă la baza lor reprezintă unul dintre domeniile cele mai dinamice și mai interesante ale cercetării în AI.