AI serija pitanja 11: Kako optimizovati RAG?

Optimizacija RAG-a nije podešavanje jedne komponente, već celoviti proces optimizacije lanca. U nastavku dajem sistematske strategije optimizacije iz četiri dimenzije: strane indeksiranja podataka, strane pronalaženja, strane generisanja i strane evaluacije, uz praktična iskustva koja možete pomenuti na intervjuu.

1. Optimizacija strane indeksiranja podataka (poboljšanje kvaliteta „baze znanja")

Ovo je najčešće zanemareno mesto koje donosi najbrže rezultate.

Tačka optimizacije	Problem	Konkretna praksa	Metrika uticaja
Parsiranje dokumenata	Tabele, dijagrami u PDF-u su ignorisani, ili je tekst nečitljiv, redosled pogrešan.	Koristite bolje biblioteke za parsiranje (npr. `unstructured`, `pypdf` sa režimom očuvanja rasporeda); za tabele koristite `pandas` za ekstrakciju i pretvaranje u Markdown.	Stopa pronalaženja +5–15%
Veličina fragmenta teksta	Premali chunk gubi kontekst (npr. „on" u „on je ostvario rast prihoda ove godine" gubi referencu); preveliki chunk unosi šum.	Eksperimentišite sa različitim veličinama chunka (256/512/768 tokena), preklapanje (overlap) postavite na 10–20%; za duge dokumente, delite po semantičkim granicama (pasus/naslov) umesto fiksne dužine.	Stopa pogađanja / vernost
Dodavanje metapodataka	Pronađen relevantan pasus, ali ne može da se prati do izvora ili vremena, ili je potrebno filtriranje po domenu.	Dodajte metapodatke za svaki chunk: `source` (naziv fajla/URL), `timestamp`, `page_num`, `doc_type`. Koristite filtere prilikom pronalaženja (npr. `doc_type == 'legal'`).	Preciznost filtriranja
Izbor modela embeddinga	Generički embedding slabo radi u vertikalnim domenima (medicina, kod, pravo).	Koristite fino podešene modele za domen (BGE‑large‑zh, GTE‑Qwen2‑7B‑instruct); ili fino podesite sopstveni embedding model (koristeći triplet loss).	MRR@10 +10–20% pronalaženja

2. Optimizacija strane pronalaženja (preciznije „listanje")

Pronalaženje određuje kvalitet „referentnog materijala" koji se daje LLM-u.

Tačka optimizacije	Problem	Konkretna praksa	Uticaj
Hibridno pretraživanje	Vektorsko pretraživanje ne može da obradi precizne termine (npr. model proizvoda `ABC-123`), ključno pretraživanje ne razume sinonime.	Istovremeno koristite vektorsko pretraživanje (semantičko) i BM25 (ključne reči), kombinujte ponderisanjem (npr. 0.7vektor + 0.3BM25) ili rerankiranjem.	Stopa pronalaženja +10–25%
Ponovno rangiranje (Rerank)	Prvih nekoliko rezultata vektorskog pretraživanja nisu nužno najrelevantniji, deseti je možda najbolji.	Koristite cross‑encoder model (npr. `BGE‑reranker-v2`, Cohere Rerank) da ponovo ocenite kandidate (npr. prvih 20) i uzmete top‑K.	Značajno poboljšanje stope pogađanja (posebno top‑1)
Prepravljanje upita	Korisničko pitanje je nejasno ili sa referencama iz više rundi („Kolika je njegova cena?").	Koristite LLM da prepravite originalno pitanje u oblik pogodniji za pretragu (npr. „Kolika je cena iPhone 15?"); ili dopunite istorijom dijaloga.	Stopa pronalaženja +5–15%
HyDE	Korisničko pitanje je previše kratko ili apstraktno (npr. „Objasni fotosintezu"), direktna pretraga je loša.	Prvo neka LLM generiše hipotetički odgovor, pa tim odgovorom pretražujte dokumente.	Pogodno za otvorene domene, ali ne i za precizna faktička pitanja
Podešavanje broja pronađenih Top‑K	Premalo K može da propusti ključne informacije; previše K povećava potrošnju tokena i šum.	Eksperimentišite sa K=3/5/10, posmatrajte ravnotežu između stope pronalaženja i vernosti odgovora.	Trade‑off između efikasnosti i efekta

3. Optimizacija strane generisanja (kako da LLM bolje koristi referentni materijal)

Bez obzira na preciznost pronalaženja, loš prompt ili model neće dati dobre rezultate.

Tačka optimizacije	Problem	Konkretna praksa	Uticaj
Inženjering prompta	LLM ignoriše pronađeni sadržaj ili izmišlja.	Jasna instrukcija: „Odgovarajte samo na osnovu datog referentnog materijala. Ako materijal nije dovoljan ili nije relevantan, odgovorite sa 'nema dovoljno informacija'." Dodajte few‑shot primere koji pokazuju kako citirati izvore.	Vernost +20–40%
Kompresija konteksta	Pronađeni sadržaj je predug (prevazilazi kontekstni prozor modela) ili sadrži mnogo šuma.	Koristite `LLMLingua` ili `selektivni kontekst` za kompresiju, zadržavajući najrelevantnije rečenice pre slanja LLM-u.	Smanjenje rizika od gubitka informacija
Nadogradnja LLM modela	Mali model (7B) ne može da izvede složeno zaključivanje ili ne pamti dugačak kontekst.	Zamenite jačim modelom (GPT‑4o, Claude 3.5 Sonnet, Qwen2.5‑72B).	Značajno poboljšanje tačnosti zaključivanja
Strimovanje i citiranje	Korisnik ne može da proveri verodostojnost odgovora.	Tokom generisanja neka LLM ispiše `[citation:1]`, koji odgovara broju pronađenog dokumenta. Na backend-u priložite link ka originalu.	Poverenje korisnika + mogućnost debugovanja
Kalibracija odbijanja odgovora	Model izmišlja kada ne treba da odgovori, ili kaže da ne zna kada bi trebalo da odgovori.	Postavite prag sličnosti: ako je kosinusna sličnost između najboljeg chunka i pitanja niža od 0.7, naložite LLM-u „materijal nije relevantan".	Smanjenje stope halucinacija

4. Strana evaluacije i iteracije (znati gde podešavati)

Bez merenja nema optimizacije.

Tačka optimizacije	Praksa	Metrika
Formiranje evaluacionog skupa	Pripremite 100–300 stvarnih korisničkih pitanja + standardne odgovore + tačne ID-e pronađenih dokumenata.	Pokrijte različite nivoe težine i namere.
Automatska evaluacija	Koristite RAGAS (Faithfulness, Answer Relevance, Context Recall) ili TruLens.	Tri ključne metrike: vernost, relevantnost odgovora, stopa pronalaženja konteksta.
Ručna evaluacija	Nedeljno testirajte 20 loših slučajeva, analizirajte tip greške (neuspešno pronalaženje / greška generisanja / nedostatak u bazi znanja).	Prioriteti za poboljšanje.
A/B testiranje	U produkciji podelite korisnike u grupe i testirajte različite strategije pronalaženja (npr. BM25 vs hibridno pretraživanje).	Online metrike: zadovoljstvo korisnika, stopa bez odgovora.

5. „Praktična iskustva" koja možete pomenuti na intervjuu (plus poeni)

„U RAG projektu kojim sam rukovodio, početna stopa pogađanja je bila samo 67%. Uradio sam tri stvari:
1. Promenio sam fiksni chunk od 1024 na dinamičku semantičku podelu (po naslovu + pasusu), stopa pogađanja je porasla na 74%;
2. Dodao sam hibridno pretraživanje (vektor + BM25) i mali rerank model, stopa pogađanja je porasla na 83%;
3. Optimizovao sam prompt i obavezno zahtevao [nije pronađena relevantna informacija], stopa halucinacija je pala sa 22% na ispod 5%.

Pored toga, uspostavili smo kontinuirani evaluacioni pipeline, pre svake promene proveravajući RAGAS skor na 200 pitanja kako bismo osigurali da nema degradacije."

Konačni sažetak: Potpuna mapa puta za optimizaciju RAG-a

Sloj podataka → Čišćenje dokumenata, optimizacija fragmentacije, poboljšanje metapodataka, domen-specifični embedding
Sloj pronalaženja → Hibridno pretraživanje, rerankiranje, prepravljanje upita, HyDE, podešavanje Top-K
Sloj generisanja → Pojačavanje prompta, instrukcije, kompresija, citiranje, prag odbijanja
Sloj evaluacije → Evaluacioni skup, RAGAS, ručna analiza, A/B eksperimenti