AI série otázek k pohovoru 11: Jak optimalizovat RAG?

Optimalizace RAG není úprava jediné fáze, ale proces optimalizace celého řetězce. Níže uvádím systematické optimalizační strategie ze čtyř dimenzí: strana indexace dat, strana vyhledávání, strana generování, strana vyhodnocení, spolu s praktickými zkušenostmi, které lze zmínit u pohovoru.

I. Optimalizace na straně indexace dat (zlepšení kvality "znalostní báze")

Toto je nejčastěji přehlížené místo, ale přináší nejrychlejší výsledky.

Optimalizační bod	Problémový jev	Konkrétní postup	Metrika účinku
Zpracování dokumentů	Tabulky, vývojové diagramy v PDF jsou ignorovány, nebo je text poškozený, pořadí zmatečné.	Použít lepší parsovací knihovny (např. `unstructured`, `pypdf` s režimem zachování rozvržení); pro tabulky extrahovat pomocí `pandas` a převést do Markdown.	Recall +5~15%
Velikost rozdělení textu	Příliš malé chunk ztrácí kontext (např. "jeho letošní růst tržeb" – ztráta reference "jeho"); příliš velký chunk přináší šum při vyhledávání.	Experimentovat s různou velikostí chunků (256/512/768 tokenů), překryv (overlap) nastavit na 10–20 %; u dlouhých dokumentů rozdělovat podle sémantických hranic (odstavce/nadpisy), ne na pevnou délku.	Míra zásahu / věrnost
Přidání metadat	Nalezen relevantní odstavec, ale nelze dohledat zdroj nebo čas, nebo je třeba filtrovat podle domény.	Ke každému chunku přidat metadata: `source` (název souboru/URL), `timestamp`, `page_num`, `doc_type`. Při vyhledávání použít filtry (např. `doc_type == 'legal'`).	Přesnost filtrování
Výběr embedding modelu	Univerzální embeddingy fungují špatně ve vertikálních doménách (medicína, kód, právo).	Použít doménově jemně doladěné modely (BGE‑large‑zh, GTE‑Qwen2‑7B‑instruct); nebo doladit vlastní embedding model (pomocí triplet loss).	MRR@10 +10~20%

II. Optimalizace na straně vyhledávání (zpřesnění "listování v knize")

Vyhledávání určuje kvalitu "referenčních materiálů" předávaných LLM.

Optimalizační bod	Problémový jev	Konkrétní postup	Účinek
Smíšené vyhledávání	Vektorové vyhledávání nedokáže přesně přiřadit odborné termíny (např. produktový model `ABC-123`), klíčové slovo nechápe synonyma.	Současně používat vektorové vyhledávání (sémantické) a BM25 (klíčová slova), kombinovat vážením (např. 0.7vektor + 0.3BM25) nebo rerank.	Recall +10~25%
Přeřazování (Rerank)	Prvních několik výsledků vektorového vyhledávání není nutně nejrelevantnější, až 10. je nejlepší.	Použít cross‑encoder model (např. `BGE‑reranker-v2`, Cohere Rerank) k novému ohodnocení kandidátů (např. prvních 20) a vzít top‑K.	Výrazné zlepšení míry zásahu (zejména top‑1)
Přepis dotazu	Otázka uživatele je vágní nebo v průběhu více kol dialogu nejasná reference ("Jaká je jeho cena?").	Pomocí LLM přepsat původní otázku do formy vhodnější pro vyhledávání (např. "Jaká je cena iPhone 15?"); nebo doplnit pomocí historie dialogu.	Recall +5~15%
HyDE	Otázka uživatele je příliš krátká nebo abstraktní (např. "vysvětli fotosyntézu"), přímé vyhledávání je neefektivní.	Nechat LLM vygenerovat hypotetickou odpověď a poté tuto odpověď použít k vyhledání dokumentů.	Vhodné pro otevřené domény, ne pro přesné faktické dotazy
Úprava počtu vyhledávaných Top‑K	Příliš malé K může ztratit klíčové informace; příliš velké K zvyšuje spotřebu tokenů a šum.	Experimentovat s K=3/5/10, sledovat rovnováhu mezi recall a věrností odpovědi.	Trade‑off mezi efektivitou a kvalitou

III. Optimalizace na straně generování (aby LLM dobře využíval referenční materiály)

I když je vyhledávání přesné, špatný prompt nebo model nepomohou.

Optimalizační bod	Problémový jev	Konkrétní postup	Účinek
Inženýrství promptů	LLM ignoruje nalezený obsah nebo si vymýšlí.	Jasný pokyn: "Odpovídejte pouze na základě poskytnutých referenčních materiálů. Pokud jsou materiály nedostatečné nebo irelevantní, odpovězte 'Nemám dostatek informací'." Přidat few‑shot příklady ukazující, jak citovat zdroje.	Věrnost +20~40%
Komprese kontextu	Nalezený obsah je příliš dlouhý (přesahuje kontextové okno modelu) nebo obsahuje hodně šumu.	Použít `LLMLingua` nebo `selektivní kontext` ke kompresi a zachovat pouze nejrelevantnější věty před předáním LLM.	Snížení rizika ztráty informací
Upgrade modelu LLM	Malé modely (7B) nezvládnou složité uvažování nebo si nepamatují dlouhý kontext.	Použít silnější model (GPT‑4o, Claude 3.5 Sonnet, Qwen2.5‑72B).	Výrazné zlepšení přesnosti uvažování
Streamování a citace	Uživatel nemůže ověřit důvěryhodnost odpovědi.	Během generování nechat LLM výstupovat `[citation:1]` odpovídající číslu referenčního dokumentu. Backend přiložit odkaz na původní text.	Důvěra uživatele + laditelnost
Kalibrace odmítnutí odpovědi	Model si vymýšlí, když by neměl, nebo říká "nevím", když by měl odpovědět.	Nastavit prahovou hodnotu podobnosti: pokud je kosinová podobnost top‑1 chunku s otázkou nižší než 0,7, přimět LLM, aby řekl "Materiál není relevantní".	Snížení míry halucinací

IV. Strana vyhodnocení a iterace (vědět, kam směřovat úpravy)

Bez měření nelze optimalizovat.

Optimalizační bod	Postup	Metrika
Vytvoření vyhodnocovací sady	Připravit 100–300 skutečných otázek uživatelů + standardní odpovědi + správná ID dokumentů pro vyhledávání.	Pokrýt různé obtížnosti a záměry.
Automatizované vyhodnocení	Použít RAGAS (Faithfulness, Answer Relevance, Context Recall) nebo TruLens.	Tři klíčové metriky: věrnost, relevance odpovědi, recall kontextu.
Manuální vyhodnocení	Každý týden otestovat 20 špatných případů (bad case), analyzovat typ chyby (selhání vyhledávání / chyba generování / chybějící znalost).	Stanovení priorit pro zlepšení.
A/B testování	V produkčním prostředí testovat různé vyhledávací strategie (např. BM25 vs smíšené vyhledávání) na segmentech uživatelů.	Online metriky: spokojenost uživatelů, míra nezodpovězených otázek.

V. "Praktické zkušenosti", které lze zmínit u pohovoru (bonusové body)

"V mém RAG projektu byla počáteční baseline přesnost zásahu pouze 67 %. Udělal jsem tři věci:
1. Změnil jsem rozdělování z pevné délky 1024 na dynamické sémantické dělení (podle nadpisů a odstavců), přesnost stoupla na 74 %;
2. Přidal jsem smíšené vyhledávání (vektor + BM25) a malý rerank model, přesnost stoupla na 83 %;
3. Optimalizoval jsem prompt a vynutil požadavek [Nenalezeny relevantní informace], míra halucinací klesla z 22 % na méně než 5 %.

Navíc jsme zřídili kontinuální vyhodnocovací pipeline, před každou změnou spouštíme RAGAS na 200 otázkách, abychom zajistili, že nedojde k degradaci."

Závěrečné shrnutí: Kompletní mapa cesty pro optimalizaci RAG

Datová vrstva ─→ čištění dokumentů, optimalizace rozdělení, rozšíření metadat, doménový embedding
Vyhledávací vrstva ─→ smíšené vyhledávání, rerank, přepis dotazu, HyDE, ladění Top-K
Generační vrstva ─→ posílení promptu, instrukční požadavky, komprese, citace, práh odmítnutí
Vyhodnocovací vrstva ─→ vyhodnocovací sada, RAGAS, manuální analýza, A/B experiment