Séria AI otázok na pohovor 11: Ako optimalizovať RAG?

Optimalizácia RAG nie je úprava jednej časti, ale proces celkovej optimalizácie reťazca. Nižšie uvádzam systematické stratégie optimalizácie zo štyroch dimenzií: strana indexovania údajov, strana vyhľadávania, strana generovania a strana vyhodnocovania, spolu s praktickými skúsenosťami, ktoré môžete spomenúť na pohovore.

1. Optimalizácia na strane indexovania údajov (zlepšenie kvality „znalostnej bázy“)

Toto je najčastejšie prehliadaná, ale najrýchlejšie účinná oblasť.

Bod optimalizácie	Problémový jav	Konkrétny postup	Metrika účinnosti
Parsovanie dokumentov	Tabuľky a vývojové diagramy v PDF sú ignorované, alebo text je pomiešaný, poradie je zmätočné.	Použiť lepšiu knižnicu na parsovanie (napr. `unstructured`, režim zachovania rozloženia `pypdf`); pre tabuľky extrahovať pomocou `pandas` a previesť na Markdown.	Miera vyvolania +5~15%
Veľkosť blokov textu	Malý chunk stráca kontext (napr. „jeho tohtoročný rast príjmov“ – „jeho“ odkazuje na niečo stratené); veľký chunk prináša veľa šumu pri vyhľadávaní.	Experimentovať s rôznymi veľkosťami chunkov (256/512/768 tokenov), prekrytie nastaviť na 10~20%; pri dlhých dokumentoch deliť podľa sémantických hraníc (odseky/nadpisy) namiesto pevnej dĺžky.	Miera zhody / vernosť
Pridávanie metadát	Vyhľadá sa relevantný odsek, ale nie je možné zistiť zdroj alebo čas, prípadne je potrebné filtrovať podľa oblasti.	Ku každému chunku pridať metadáta: `source` (názov súboru/URL), `timestamp`, `page_num`, `doc_type`. Pri vyhľadávaní použiť filter (napr. `doc_type == 'legal'`).	Presnosť filtrovania
Výber vkladacieho modelu	Všeobecný embedding sa v špecializovanej oblasti (medicína, kód, právo) správa zle.	Použiť doménovo dolaďovaný model (BGE‑large‑zh, GTE‑Qwen2‑7B‑instruct); alebo dolaďovať vlastný embedding model (pomocou triplet loss).	MRR@10 pri vyhľadávaní +10~20%

2. Optimalizácia na strane vyhľadávania (aby „listovanie“ bolo presnejšie)

Vyhľadávanie určuje kvalitu „referenčných materiálov“ dodávaných LLM.

Bod optimalizácie	Problémový jav	Konkrétny postup	Účinok
Hybridné vyhľadávanie	Vektorové vyhľadávanie nedokáže nájsť presné termíny (napr. model produktu `ABC-123`), kľúčové slová nechápu synonymá.	Súčasne používať vektorové vyhľadávanie (sémantické) a BM25 (kľúčové slová), kombinovať vážením (napr. 0.7vektor + 0.3BM25) alebo rerankingom.	Miera vyvolania +10~25%
Reranking	Prvých pár výsledkov vektorového vyhľadávania nie je vždy najrelevantnejších, 10. výsledok je lepší.	Použiť cross‑encoder model (napr. `BGE‑reranker-v2`, Cohere Rerank) na prehodnotenie kandidátov (napr. prvých 20) a vybrať top‑K.	Výrazné zlepšenie miery zhody (hlavne top‑1)
Prepísanie dotazu	Otázka používateľa je nejasná alebo vo viackolovom dialógu s nejasnými odkazmi („Aká je jeho cena?“).	Použiť LLM na prepísanie pôvodnej otázky do formy vhodnejšej na vyhľadávanie (napr. „Aká je cena iPhone 15?“); alebo doplniť pomocou histórie dialógu.	Miera vyvolania +5~15%
HyDE	Otázka používateľa je príliš krátka alebo abstraktná (napr. „Vysvetlite fotosyntézu“), priame vyhľadávanie je slabé.	Najprv nechať LLM vygenerovať hypotetickú odpoveď, potom touto odpoveďou vyhľadávať v dokumentoch.	Vhodné pre otvorené domény, nie pre presné faktické otázky
Úprava počtu vyhľadávaných Top‑K	Príliš malé K môže zmeškať kľúčové informácie; príliš veľké K zvyšuje spotrebu tokenov a šum.	Experimentovať s K=3/5/10, sledovať rovnováhu medzi mierou vyvolania a vernosťou odpovede.	Kompromis medzi efektívnosťou a kvalitou

3. Optimalizácia na strane generovania (aby LLM dobre využíval referenčné materiály)

Aj keď je vyhľadávanie presné, zlý prompt alebo slabý model je zbytočný.

Bod optimalizácie	Problémový jav	Konkrétny postup	Účinok
Prompt inžinierstvo	LLM ignoruje vyhľadaný obsah alebo si vymýšľa.	Dať jasnú inštrukciu: „Odpovedajte len na základe nasledujúcich poskytnutých referenčných materiálov. Ak materiály nestačia alebo nie sú relevantné, odpovedzte „Nemám dostatok informácií“.“ Pridať few‑shot príklady ukazujúce, ako citovať zdroje.	Vernosť +20~40%
Kompresia kontextu	Vyhľadaný obsah je príliš dlhý (presahuje okno kontextu modelu) alebo obsahuje veľa šumu.	Použiť `LLMLingua` alebo `Selektívny kontext` na kompresiu, ponechať najrelevantnejšie vety a potom odoslať LLM.	Zníženie rizika straty informácií
Upgrade LLM modelu	Malý model (7B) nezvládne komplexné uvažovanie alebo si nepamätá dlhý kontext.	Použiť silnejší model (GPT‑4o, Claude 3.5 Sonnet, Qwen2.5‑72B).	Výrazné zlepšenie presnosti uvažovania
Streamovanie a citácie	Používateľ nemôže overiť dôveryhodnosť odpovede.	Pri generovaní nechať LLM vypísať `[citation:1]` zodpovedajúce číslu vyhľadaného dokumentu. Na backend pridať odkaz na pôvodný text.	Dôvera používateľa + možnosť ladenia
Kalibrácia odmietnutia odpovede	Model si vymýšľa, keď nemá odpovedať, alebo hovorí „neviem“ tam, kde by mal vedieť.	Nastaviť prah podobnosti: ak je kosínová podobnosť top‑1 chunku s otázkou nižšia ako 0,7, upozorniť LLM „materiály nie sú relevantné“.	Zníženie miery halucinácií

4. Strana vyhodnocovania a iterácie (vedieť, kam smerovať optimalizáciu)

Bez merania nie je možné optimalizovať.

Bod optimalizácie	Postup	Metrika
Vytvorenie eval setu	Pripraviť 100~300 skutočných otázok používateľov + štandardné odpovede + správne ID vyhľadaných dokumentov.	Pokryť rôzne úrovne obtiažnosti a rôzne zámery.
Automatizované vyhodnocovanie	Použiť RAGAS (Faithfulness, Answer Relevance, Context Recall) alebo TruLens.	Tri kľúčové metriky: vernosť, relevantnosť odpovede, miera vyvolania kontextu.
Ručné vyhodnocovanie	Týždenne otestovať 20 zlých prípadov, analyzovať typ chyby (zlyhanie vyhľadávania / chyba generovania / chýbajúca znalosť).	Stanovenie priorít zlepšenia.
A/B testovanie	V produkčnom prostredí rozdeliť do skupín a testovať rôzne stratégie vyhľadávania (napr. BM25 vs hybridné vyhľadávanie).	Online metriky: spokojnosť používateľov, miera neodpovedania.

5. „Praktické skúsenosti“ na pohovor (bonusové body)

„V mojom projekte RAG bola počiatočná miera zhody základnej línie len 67 %. Urobil som tri veci:
1. Zmenil som pevné delenie na 1024 na dynamické sémantické delenie (podľa nadpisov+odsekov), čím sa miera zhody zvýšila na 74 %;
2. Pridal som hybridné vyhľadávanie (vektorové + BM25) a malý reranking model, miera zhody stúpla na 83 %;
3. Optimalizoval som prompt a vynútil [Nenašli sa relevantné informácie], miera halucinácií klesla z 22 % na menej ako 5 %.

Okrem toho sme vytvorili kontinuálny eval pipeline, ktorý pred každou zmenou spúšťa RAGAS skóre na 200 otázkach, aby sme zabezpečili, že nedôjde k degradácii.“

Záverečné zhrnutie: Kompletná mapa optimalizácie RAG

Dátová vrstva ─→ Čistenie dokumentov, optimalizácia delenia, obohatenie metadát, doménový embedding
Vyhľadávacia vrstva ─→ Hybridné vyhľadávanie, reranking, prepisovanie dotazu, HyDE, ladenie Top-K
Generovacia vrstva ─→ Posilnenie promptu, inštrukcie, kompresia, citácie, prah odmietnutia
Vyhodnocovacia vrstva ─→ Eval set, RAGAS, ručná analýza, A/B experimenty