Întrebare interviu seria AI 11: Cum se optimizează RAG?

Optimizarea RAG nu este o ajustare a unei singure etape, ci un proces de optimizare pe întregul lanț. Mai jos, din patru dimensiuni: partea de indexare a datelor, partea de regăsire, partea de generare, partea de evaluare, ofer strategii sistematice de optimizare, împreună cu experiențe practice care pot fi menționate în interviu.

I. Optimizarea părții de indexare a datelor (îmbunătățirea calității „bazei de cunoștințe")

Acesta este cel mai adesea ignorat, dar cel mai rapid eficient.

Punct de optimizare	Problemă observată	Metodă concretă	Indicator de efect
Parsarea documentelor	Tabelele, diagramele din PDF sunt ignorate, sau textul este deteriorat, ordinea greșită.	Utilizarea unei biblioteci de parsare mai bune (de exemplu `unstructured`, modul de păstrare a layout-ului `pypdf`); pentru tabele, extrageți cu `pandas` și convertiți în Markdown.	Rata de regăsire +5~15%
Dimensiunea fragmentelor de text	Fragment prea mic pierde contextul (de exemplu, „creșterea veniturilor lui anul acesta" – referința „lui" se pierde); fragment prea mare duce la mult zgomot în regăsire.	Experimentați cu diferite dimensiuni de fragment (256/512/768 tokeni), suprapunerea (overlap) 10~20%; pentru documente lungi, tăiați pe granițe semantice (paragrafe/titluri) în loc de lungime fixă.	Rata de potrivire / fidelitate
Adăugarea de metadate	S-a regăsit paragraful relevant, dar nu se poate urmări sursa sau timpul, sau este nevoie de filtrare pe domeniu.	Adăugați metadate pentru fiecare fragment: `source` (nume fișier/URL), `timestamp`, `page_num`, `doc_type`. La regăsire, utilizați filtre (de exemplu `doc_type == 'legal'`).	Precizia filtrării
Alegerea modelului de încorporare	Embedding-ul generic funcționează prost în domenii verticale (medical, cod, juridic).	Utilizați modele fine-tunate pe domeniu (BGE‑large‑zh, GTE‑Qwen2‑7B‑instruct); sau fine-tunați propriul model de embedding (cu triplet loss).	MRR@10 +10~20%

II. Optimizarea părții de regăsire (faceți „răsfoirea" mai precisă)

Regăsirea determină calitatea „materialelor de referință" alimentate către LLM.

Punct de optimizare	Problemă observată	Metodă concretă	Efect
Regăsirea hibridă	Regăsirea vectorială nu poate potrivi termeni exacti (de exemplu, modelul produs `ABC-123`), regăsirea pe cuvinte cheie nu poate înțelege sinonimele.	Utilizați simultan regăsirea vectorială (semantică) și BM25 (cuvinte cheie), combinate prin ponderare (de exemplu 0.7vector + 0.3BM25) sau rerank.	Rata de regăsire +10~25%
Reordonarea (Rerank)	Primele rezultate returnate de regăsirea vectorială nu sunt neapărat cele mai relevante; al 10-lea poate fi cel mai bun.	Folosiți un model cross-encoder (de exemplu `BGE‑reranker-v2`, Cohere Rerank) pentru a re-scora setul de candidați (de exemplu primele 20) și luați top‑K.	Îmbunătățire semnificativă a ratei de potrivire (în special top‑1)
Rescrierea interogării	Întrebarea utilizatorului este vagă sau în dialog multi-tur referința este neclară („Care este prețul lui?").	Folosiți LLM pentru a rescrie întrebarea originală într-o formă mai potrivită pentru regăsire (de exemplu „Care este prețul iPhone 15?"); sau completați utilizând istoricul conversației.	Rata de regăsire +5~15%
HyDE	Întrebarea utilizatorului este prea scurtă sau prea abstractă (de exemplu „Explică fotosinteza"), regăsirea directă este slabă.	Mai întâi, lăsați LLM să genereze un răspuns ipotetic, apoi folosiți acest răspuns pentru a regăsi documente.	Potrivit pentru domenii deschise, dar nu pentru întrebări factuale precise
Ajustarea numărului de regăsiri Top‑K	K prea mic poate pierde informații cheie; K prea mare crește consumul de tokeni și zgomotul.	Experimentați K=3/5/10, observați echilibrul între rata de regăsire și fidelitatea răspunsului.	Compromis între eficiență și efect

III. Optimizarea părții de generare (faceți LLM să utilizeze bine materialele de referință)

Oricât de precisă ar fi regăsirea, dacă promptul nu este bun sau modelul nu este potrivit, nu funcționează.

Punct de optimizare	Problemă observată	Metodă concretă	Efect
Ingineria prompturilor	LLM ignoră conținutul regăsit sau inventează.	Instrucțiune clară: „Răspundeți doar pe baza materialelor de referință furnizate mai jos. Dacă materialele sunt insuficiente sau irelevante, răspundeți 'Nu am suficiente informații'." Adăugați exemple few-shot care arată cum să citați sursele.	Fidelitate +20~40%
Comprimarea contextului	Conținutul regăsit este prea lung (depășește fereastra de context a modelului) sau conține mult zgomot.	Utilizați `LLMLingua` sau `context selectiv` pentru a comprima, păstrând cele mai relevante propoziții înainte de a le trimite LLM-ului.	Reducerea riscului de pierdere a informațiilor
Upgrade-ul modelului LLM	Modelele mici (7B) nu pot efectua raționamente complexe sau nu rețin contexte lungi.	Înlocuiți cu modele mai puternice (GPT‑4o, Claude 3.5 Sonnet, Qwen2.5‑72B).	Precizia raționamentului crește semnificativ
Flux și citări	Utilizatorul nu poate verifica credibilitatea răspunsului.	La generare, faceți LLM să producă `[citație:1]`, corespunzând numărului documentului regăsit. În backend, atașați linkul original.	Încrederea utilizatorului + depanabilitate
Calibrarea refuzului de a răspunde	Modelul inventează când nu ar trebui să răspundă, sau spune că nu știe când ar trebui să răspundă.	Setați un prag de similaritate: dacă similaritatea cosinus între fragmentul top‑1 regăsit și întrebare este sub 0.7, indicați LLM-ului „materialele nu sunt relevante".	Reducerea ratei de halucinație

IV. Partea de evaluare și iterare (știți spre ce să ajustați)

Fără măsurare, nu puteți optimiza.

Punct de optimizare	Metodă	Indicator
Crearea unui set de evaluare	Pregătiți 100~300 de întrebări reale ale utilizatorilor + răspunsuri standard + ID-urile corecte ale documentelor regăsite.	Acoperiți diferite niveluri de dificultate și intenții.
Evaluare automată	Folosiți RAGAS (Faithfulness, Answer Relevance, Context Recall) sau TruLens.	Trei indicatori de bază: fidelitate, relevanța răspunsului, rata de regăsire a contextului.
Evaluare manuală	Săptămânal, testați 20 de cazuri problematice, analizați tipul de eroare (eșec de regăsire / eroare de generare / lipsă în baza de cunoștințe).	Prioritizarea îmbunătățirilor.
Test A/B	În mediu de producție, testați în bucket-uri diferite strategii de regăsire (de exemplu BM25 vs regăsire hibridă).	Indicatori online: satisfacția utilizatorului, rata de non-răspuns.

V. „Experiențe practice" care pot fi menționate în interviu (puncte în plus)

„În proiectul RAG de care eram responsabil, inițial rata de potrivire de bază era de doar 67%. Am făcut trei lucruri:
1. Tăierea din fix 1024 la tăiere semantică dinamică (după titluri+paragrafe), rata de potrivire a crescut la 74%;
2. Am adăugat regăsirea hibridă (vector + BM25) și un mic model de rerank, rata de potrivire a urcat la 83%;
3. Am optimizat promptul și am impus [Informație relevantă nu a fost găsită], rata de halucinație a scăzut de la 22% la sub 5%.

În plus, am construit o conductă continuă de evaluare, unde înainte de fiecare modificare rulam scorul RAGAS pe 200 de întrebări, asigurându-ne că nu există regresie."

Concluzie finală: O hartă completă a optimizării RAG

Stratul de date ─→ Curățarea documentelor, optimizarea fragmentării, îmbogățirea metadatelor, embedding pe domeniu
Stratul de regăsire ─→ Regăsire hibridă, rerank, rescrierea interogării, HyDE, ajustarea Top-K
Stratul de generare ─→ Întărirea promptului, cerințe de instrucțiuni, comprimare, citări, prag de refuz
Stratul de evaluare ─→ Set de evaluare, RAGAS, analiză manuală, experimente A/B