Ce este RAG? Retrieval-Augmented Generation explicat simplu

RAG (retrieval-augmented generation) este o modalitate de a face un model AI să răspundă la întrebări folosind propriile tale informații. Când cineva pune o întrebare, aplicația ta caută mai întâi în documentele tale pasajele cele mai relevante, apoi le trimite modelului împreună cu întrebarea. Modelul scrie răspunsul pe baza acelui text, în loc să se bazeze doar pe ce a reținut din antrenare.

De ce contează RAG când construiești cu AI

Un model mare de limbaj știe multe despre lume în general, dar nimic despre afacerea ta: prețurile, politicile, manualul produsului, tichetele de suport de săptămâna trecută. De asemenea, are o dată de tăiere a antrenării, așa că nu știe nimic recent. Dacă îl întrebi oricum, poate produce un răspuns sigur pe sine, plauzibil și greșit.

Ai trei opțiuni generale pentru a rezolva asta:

Modelele moderne acceptă prompturi lungi, așa că pentru un FAQ scurt prima opțiune este adesea suficientă. RAG își câștigă locul când ai mai mult text decât vrei să trimiți de fiecare dată — pentru că fiecare cuvânt trimis costă bani și timp (vezi cum taxează API-urile LLM).

Dacă construiești o funcție de tip „discută cu documentația noastră”, un asistent de suport sau un instrument intern de cunoștințe, aproape sigur construiești o formă de RAG.

O analogie din viața de zi cu zi

Imaginează-ți un examen cu carte deschisă. Un student care trebuie să răspundă din memorie poate să uite ceva sau să improvizeze. Un student care are voie să deschidă întâi paginile potrivite, să le citească și apoi să răspundă este mult mai fiabil — cu condiția să găsească paginile potrivite.

• Studentul este modelul de limbaj.
• Manualul sunt documentele tale.
• Deschiderea paginilor potrivite este retrieval-ul.
• Scrierea răspunsului din acele pagini este generarea.

RAG este versiunea cu carte deschisă. Și, ca la examen, calitatea răspunsului depinde în mare măsură de faptul că s-au găsit paginile potrivite.

Cum funcționează RAG, pas cu pas

O configurare tipică RAG are două faze.

Pregătirea documentelor (făcută dinainte):

1. Colectează materialele sursă — articole de ajutor, PDF-uri, politici, date despre produse.
2. Împarte în bucăți (chunk): sparge documentele lungi în bucăți mai mici, adesea de câteva paragrafe, ca răsăritul să poată returna doar partea relevantă.
3. Creează embedding pentru fiecare bucată: trimite-o unui model de embedding, care transformă textul într-un embedding — o listă lungă de numere care captează sensul. Textele despre lucruri similare ajung cu numere similare.
4. Stochează bucățile și embedding-urile lor într-o bază de date care poate căuta după similaritate (de multe ori numită bază de date vectorială sau index vectorial).

Răspunsul la o întrebare (făcut de fiecare dată):

1. Creează embedding pentru întrebare cu același model de embedding.
2. Recuperează bucățile al căror embedding este cel mai apropiat de cel al întrebării — de exemplu, primele cinci.
3. Construiește promptul: instrucțiuni, bucățile recuperate și întrebarea.
4. Generează: modelul de limbaj scrie un răspuns pe baza acelor bucăți, de preferat indicând care au fost folosite.

Căutarea după sens este ceea ce face ca tot acest lucru să funcționeze: o întrebare despre „cum îmi recuperez banii” poate găsi o bucată intitulată „Politica de rambursare”, chiar dacă nu au niciun cuvânt comun.

Un exemplu lucrat: asistentul de ajutor al unei săli de sport

Să spunem că o sală are 40 de articole de ajutor și vrea un asistent de chat pe site-ul său. Un membru întreabă: „Îmi pot suspenda abonamentul cât timp sunt în deplasare?”

Aplicația creează embedding pentru întrebare și recuperează cele trei bucăți cele mai apropiate. Una dintre ele spune:

Înghețarea abonamentului: Membrii cu abonament lunar pot îngheța
abonamentul pentru până la 2 luni pe an. Solicită-o la recepție
sau în aplicație cu cel puțin 7 zile înainte de începerea înghețării.

Promptul trimis modelului arată cam așa:

Ești asistentul de ajutor pentru sala Northside Gym.
Răspunde doar din sursele de mai jos. Dacă răspunsul nu se află în ele,
spune că nu știi și sugerează să contacteze recepția.
Menționează ce sursă ai folosit.

[Sursa 1: Înghețarea abonamentului] Membrii cu abonament lunar pot îngheța...
[Sursa 2: Anularea abonamentului] ...
[Sursa 3: Invitații] ...

Întrebare: Îmi pot suspenda abonamentul cât timp sunt în deplasare?

Iar modelul răspunde: „Da — la abonamentul lunar poți îngheța abonamentul pentru până la două luni pe an. Solicită-o la recepție sau în aplicație cu cel puțin 7 zile înainte (sursa: Înghețarea abonamentului).”

Sala nu a reantrenat nimic. Când își schimbă politica de înghețare, actualizează articolul, aplicația recalculează embedding-ul bucății respective, iar următorul răspuns o reflectă.

Termeni cheie

Idei greșite frecvente

• „RAG antrenează modelul pe datele mele.” Nu. Modelul nu se schimbă; doar citește text suplimentar în momentul întrebării.
• „RAG înseamnă că nu mai sunt halucinații.” Înseamnă mai puține. Dacă recuperarea ratează bucata potrivită sau răspunsul nu se află în documente, modelul poate totuși să ghicească. Instruiește-l să spună „nu știu” și testează cu întrebări la care cunoști răspunsurile.
• „Am nevoie de o bază de date vectorială specială.” Adesea nu. Pentru cantități modeste de date, o extensie vectorială pe baza de date pe care o ai deja sau chiar o căutare simplă după cuvinte cheie pot fi suficiente.
• „Bucățile mai mari sunt mai bune.” Prea mari și trimiți mult text irelevant (mai mult cost, mai multă confuzie); prea mici și bucata pierde contextul care o făcea utilă. Te așteaptă ajustări.
• „Doar încarcă tot.” Documentele vechi, duplicate sau contradictorii produc răspunsuri contradictorii. Curățarea materialelor sursă este adesea cea mai mare îmbunătățire pe care o poți face.
• „Oricine poate vedea orice document.” Doar dacă o construiești așa. Dacă unele documente sunt private pentru anumiți utilizatori, căutarea trebuie să filtreze după cine întreabă — altfel asistentul poate cita datele unui client altui client.

Cât costă

O funcție RAG are de obicei trei costuri curente: crearea embedding-urilor pentru documente (mică și în mare parte o singură dată), crearea embedding-urilor pentru fiecare întrebare (minusculă) și apelul modelului de limbaj (costul principal, care crește odată cu numărul de bucăți trimise). Se adaugă stocarea în baza de date. Furnizorul tău de AI le facturează în contul tău, așa că setează o limită de cheltuieli acolo.

Ce să ceri constructorului tău AI

• „Înainte să construiești RAG, verifică: conținutul nostru este suficient de mic încât să fie inclus pur și simplu în prompt?”
• „Împarte articolele de ajutor în bucăți de câteva paragrafe, păstrează titlul și linkul sursei pentru fiecare bucată și stochează embedding-urile în baza noastră de date.”
• „Folosește căutare hibridă — după sens plus după cuvinte cheie — ca să se potrivească și codurile de produs.”
• „Spune modelului să răspundă doar din sursele recuperate, să spună când nu știe și să arate sursele sub fiecare răspuns.”
• „Caută doar în documentele pe care utilizatorul conectat are voie să le vadă.”
• „Recalculează automat embedding-ul unui document ori de câte ori este editat.”
• „Păstrează cheia furnizorului AI pe server, într-un secret, niciodată în browser.”
• „Înregistrează fiecare întrebare, bucățile recuperate și răspunsul, ca să pot revedea răspunsurile proaste.”

RAG în Mythex

Mythex nu include un produs gata făcut de bază de cunoștințe sau RAG. Ce face este să scrie codul pentru una în interiorul aplicației tale: aduci documentele și propria cheie a furnizorului AI, stocată ca secret al proiectului, iar agentul construiește partea de recuperare și de chat, folosind baza de date Postgres a proiectului pentru stocare. Utilizarea furnizorului se facturează în contul tău de la furnizor, nu în creditele Mythex. Documentația sugerează să începi cu o singură funcție AI simplă și să adaugi RAG după ce aceasta funcționează — vezi cum construiești o aplicație AI și ghidurile noastre despre construirea unei aplicații de chatbot AI și adăugarea funcțiilor AI.

Întrebări