Pyetje interviste të serisë AI 11: Si të optimizojmë RAG?

Optimizimi i RAG nuk është rregullim i një hallke të vetme, por një proces optimizimi i zinxhirit të plotë. Më poshtë jap strategji sistematike optimizimi nga katër dimensione: ana e indeksimit të të dhënave, ana e kërkimit, ana e gjenerimit, ana e vlerësimit, dhe bashkangjit përvojë praktike që mund të përmendet në intervista.

1. Optimizimi i anës së indeksimit të të dhënave (përmirësimi i cilësisë së "bazës së njohurive")

Ky është vendi më i neglizhuar por më i shpejtë për të parë rezultate.

Pika e optimizimit	Problemi	Veprimi konkret	Indikatori i efektit
Parsimi i dokumenteve	Tabelat në PDF, diagramet e rrjedhës injorohen, ose teksti është i çrregullt, renditja gabon.	Përdor biblioteka më të mira parsimi (si `unstructured`, modaliteti i ruajtjes së layout-it të `pypdf`); për tabelat përdor `pandas` për nxjerrje dhe konverto në Markdown.	Shkalla e kthimit +5~15%
Madhësia e copëzave të tekstit	Copëza shumë e vogël humb kontekstin (p.sh. "ai" në "të ardhurat e tij këtë vit u rritën" humb referencën); copëza shumë e madhe sjell zhurmë në kërkim.	Eksperimento me madhësi të ndryshme copëzash (256/512/768 token), mbivendosje 10~20%; për dokumente të gjata, ndaj sipas kufijve semantikë (paragrafë/tituj) në vend të gjatësisë fikse.	Shkalla e goditjes / Besnikëria
Shtimi i meta të dhënave	Gjetet paragrafi përkatës, por nuk mund të gjurmohet burimi ose koha, ose nevojitet filtrimi sipas fushës.	Shto meta të dhëna për çdo copëzë: `source` (emri i skedarit/URL), `timestamp`, `page_num`, `doc_type`. Gjatë kërkimit përdor filtra (si `doc_type == 'legal'`).	Saktësia e filtrimit
Zgjedhja e modelit të embedding	Embedding-u i përgjithshëm performon keq në fusha vertikale (mjekësi, kod, ligj).	Përdor modele të finetunuara për fushën (BGE‑large‑zh, GTE‑Qwen2‑7B‑instruct); ose finetuno modelin tënd të embedding (me triplet loss).	MRR@10 e kërkimit +10~20%

2. Optimizimi i anës së kërkimit (bëj "fletët" më të sakta)

Kërkimi përcakton cilësinë e "materialeve referuese" që i jepen LLM-së.

Pika e optimizimit	Problemi	Veprimi konkret	Efekti
Kërkimi hibrid	Kërkimi vektorial nuk përputh terma të saktë (si model produkti `ABC-123`), kërkimi me fjalë kyçe nuk kupton sinonime.	Përdor njëkohësisht kërkim vektorial (semantik) dhe BM25 (fjalë kyçe), duke peshuar (p.sh. 0.7vektorial + 0.3BM25) ose duke bashkuar me rerank.	Shkalla e kthimit +10~25%
Rirenditja (Rerank)	Rezultatet e para nga kërkimi vektorial nuk janë domosdoshmërisht më të rëndësishmet, i 10-ti mund të jetë më i miri.	Përdor model cross‑encoder (si `BGE‑reranker-v2`, Cohere Rerank) për të ri-vlerësuar kandidatët (p.sh. 20 të parët) dhe merr top‑K.	Shkalla e goditjes rritet ndjeshëm (veçanërisht top‑1)
Rishkrimi i pyetjes	Pyetja e përdoruesit e paqartë ose me referenca të paqarta në dialogë shumë-rrjedhësh ("Sa është çmimi i tij?").	Përdor LLM për të rishkruar pyetjen origjinale në një formë më të përshtatshme për kërkim (p.sh. "Sa është çmimi i iPhone 15?"); ose plotëso duke përdorur historinë e dialogut.	Shkalla e kthimit +5~15%
HyDE	Pyetja e përdoruesit shumë e shkurtër ose abstrakte (p.sh. "Shpjego fotosintezën"), kërkimi direkt jep rezultate të dobëta.	Fillimisht bëj LLM të gjenerojë një përgjigje hipotetike, pastaj përdor këtë përgjigje për të kërkuar dokumente.	I përshtatshëm për domene të hapura, por jo për pyetje faktike të sakta
Rregullimi i Top‑K	K shumë i vogël mund të humbasë informacion kyç; K shumë i madh rrit konsumin e tokenëve dhe zhurmën.	Eksperimento me K=3/5/10, vëzhgo ekuilibrin midis shkallës së kthimit dhe besnikërisë së përgjigjes.	Trade‑off midis efikasitetit dhe efektit

3. Optimizimi i anës së gjenerimit (bëj LLM të përdorë mirë materialet referuese)

Edhe nëse kërkimi është i saktë, nëse prompti nuk është i mirë ose modeli nuk është i mirë, nuk funksionon.

Pika e optimizimit	Problemi	Veprimi konkret	Efekti
Inxhinieria e promptit	LLM injoron përmbajtjen e kërkuar ose shpik.	Udhëzim i qartë: "Përgjigju vetëm duke u bazuar në materialet referuese të mëposhtme. Nëse materialet nuk janë të mjaftueshme ose të parëndësishme, përgjigju 'Nuk ka informacion të mjaftueshëm'." Shto shembuj few‑shot që tregojnë si të citohet burimi.	Besnikëria +20~40%
Kompresimi i kontekstit	Përmbajtja e kërkuar është shumë e gjatë (tej kalon dritaren e kontekstit të modelit), ose pjesa më e madhe është zhurmë.	Përdor `LLMLingua` ose `kontekst selektiv` për kompresim, ruaj fjalitë më të rëndësishme përpara se t'i dërgosh LLM-së.	Redukton rrezikun e humbjes së informacionit
Përmirësimi i modelit LLM	Modelet e vogla (7B) nuk mund të kryejnë arsyetim kompleks ose nuk mbajnë mend kontekst të gjatë.	Përdor modele më të forta (GPT‑4o, Claude 3.5 Sonnet, Qwen2.5‑72B).	Saktësia e arsyetimit rritet ndjeshëm
Streaming dhe citimet	Përdoruesi nuk mund të verifikojë besueshmërinë e përgjigjes.	Gjatë gjenerimit bëj LLM të nxjerrë `[citation:1]` që korrespondon me numrin e dokumentit të kërkuar. Në backend bashkëngjit lidhjen origjinale.	Besimi i përdoruesit + debugim i mundshëm
Kalibrimi i refuzimit të përgjigjes	Modeli shpik kur nuk duhet të përgjigjet, ose thotë se nuk di kur duhet të përgjigjet.	Vendos një prag ngjashmërie: nëse ngjashmëria kosinus e copëzës top‑1 me pyetjen është më e ulët se 0.7, njofto LLM se "materialet nuk janë të rëndësishme".	Redukton shkallën e halucinacioneve

4. Ana e vlerësimit dhe përsëritjes (di ku të bësh rregullime)

Pa matje nuk mund të optimizosh.

Pika e optimizimit	Veprimi	Indikatori
Krijimi i grupit të vlerësimit	Përgatit 100~300 pyetje reale të përdoruesve + përgjigje standarde + ID-të e sakta të dokumenteve të kërkuara.	Mbulon nivele të ndryshme vështirësie dhe qëllimesh.
Vlerësimi automatik	Përdor RAGAS (Faithfulness, Answer Relevance, Context Recall) ose TruLens.	Tre indikatorë kryesorë: besnikëria, rëndësia e përgjigjes, shkalla e kthimit të kontekstit.
Vlerësimi njerëzor	Çdo javë testo 20 raste të këqija, analizo llojin e gabimit (dështim kërkimi / gabim gjenerimi / mungesë në bazën e njohurive).	Rendit prioritetet e përmirësimit.
Testimi A/B	Në mjedisin e prodhimit, ndaj në grupe për të testuar strategji të ndryshme kërkimi (p.sh. BM25 vs kërkim hibrid).	Indikatorë online: kënaqësia e përdoruesit, shkalla e pa-përgjigjes.

5. "Eksperiencë praktike" që mund të thuhet në intervista (pikë bonus)

"Në projektin RAG që drejtoja, fillimisht shkalla e goditjes bazë ishte vetëm 67%. Bëra tri gjëra:
1. Ndryshova ndarjen e copëzave nga 1024 fikse në ndarje dinamike semantike (sipas titujve + paragrafëve), shkalla e goditjes u ngrit në 74%;
2. Shtova kërkim hibrid (vektorial + BM25) dhe një model të vogël rerank, shkalla e goditjes u rrit në 83%;
3. Optimizova promptin dhe detyrova të kthejë [Nuk u gjet informacion përkatës], shkalla e halucinacioneve ra nga 22% në nën 5%.

Gjithashtu, ndërtuam një tubacion të vazhdueshëm vlerësimi, çdo ndryshim testonte 200 pyetje me rezultatin RAGAS për të siguruar që nuk kishte regres."

Përmbledhje përfundimtare: Një hartë e plotë e rrugës së optimizimit të RAG

Shtresa e të dhënave ─→ Pastrimi i dokumenteve, optimizimi i copëzimit, përmirësimi i meta të dhënave, embedding i fushës
Shtresa e kërkimit ─→ Kërkimi hibrid, rerank, rishkrimi i pyetjes, HyDE, optimizimi i Top-K
Shtresa e gjenerimit ─→ Forcimi i promptit, kërkesat e udhëzimit, kompresimi, citimet, pragu i refuzimit
Shtresa e vlerësimit ─→ Grupi i vlerësimit, RAGAS, analiza njerëzore, eksperimentet A/B