Ideea este simplă: în loc să speri că modelul „știe” ceva, îi dai informația în context și îi ceri să răspundă doar pe baza ei.
Cum funcționează
Fluxul are patru pași.
- Pregătirea. Documentele se împart în fragmente și fiecare fragment primește o reprezentare numerică care surprinde sensul lui.
- Regăsirea. La o întrebare, se caută fragmentele cele mai apropiate ca sens.
- Construirea contextului. Fragmentele găsite se pun în cererea către model, împreună cu întrebarea.
- Generarea. Modelul formulează răspunsul pe baza fragmentelor primite.
Unde eșuează în practică
Aproape toate problemele unui sistem RAG sunt probleme de regăsire, nu de generare. Dacă fragmentul corect nu ajunge în context, niciun model nu poate produce răspunsul corect.
Fragmentarea greșită. Tăierea la un număr fix de caractere rupe tabele, separă o definiție de exemplul ei și lasă fragmente fără sens de sine stătător. Fragmentarea pe structura reală a documentului — secțiuni, subcapitole — dă rezultate mult mai bune.
Întrebări formulate altfel decât documentul. Utilizatorul întreabă „cât stau în concediu”, documentul spune „durata concediului de odihnă”. Căutarea pe sens ajută, dar nu rezolvă tot; combinarea cu o căutare pe cuvinte îmbunătățește sensibil rezultatele.
Întrebări care cer agregare. „Câte contracte am semnat anul trecut” nu se rezolvă prin regăsirea câtorva fragmente. Acestea sunt întrebări pentru o bază de date, nu pentru RAG.
Documente contradictorii. Când există trei versiuni ale aceleiași proceduri, regăsirea le aduce pe toate, iar modelul alege una — de obicei fără să semnaleze conflictul.
Metadate ignorate. Data, departamentul, versiunea, nivelul de acces sunt adesea mai importante decât similaritatea de sens. Un răspuns corect dintr-o procedură expirată este tot un răspuns greșit.
Ce merită construit de la început
- Citări obligatorii. Fiecare afirmație din răspuns trebuie să indice fragmentul-sursă. Fără asta nu poți verifica nimic.
- Filtrare pe metadate înainte de căutare. Restrânge la documentele valabile și la cele pe care utilizatorul are dreptul să le vadă. Controlul accesului trebuie aplicat la regăsire, nu la afișare.
- Un set de întrebări de test. Întrebări reale, cu răspunsul corect cunoscut, folosite ca test de regresie la fiecare modificare.
- Un răspuns onest când nu găsește. „Nu am găsit informația în documentele disponibile” este un rezultat valid și mult mai util decât o aproximare.
Când RAG nu este răspunsul
Dacă informația este structurată, o interogare în baza de date este mai rapidă, mai ieftină și exactă.
Dacă întrebările cer calcule sau agregări, ai nevoie de un instrument de calcul, nu de regăsire.
Dacă documentele sunt puține și încap în contextul modelului, le poți da direct.
Ordinea investiției
Efortul se duce, în ordine, în: calitatea și curățenia documentelor, strategia de fragmentare, calitatea regăsirii, și abia la final alegerea modelului. Inversarea acestei ordini este cea mai frecventă cauză a unui proiect RAG dezamăgitor.