RAG vs. doladění: kdy použít co (s reálnými čísly)

RAG vs. doladění: kdy použít co (s reálnými čísly)

Většina rad na téma rag vs doladení přeskakuje jediný experiment, který změřil oba přístupy na stejném úkolu. Balaguer a kol. v arXiv:2401.08406 (citováno 162krát) prohnali zemědělskou QA sadu oběma cestami: doladění přineslo přes 6 bodů přesnosti a RAG k tomu přidal dalších 5. Jejich tabulka 18 uvádí GPT-4 na 75 % bez úprav, 81 % po doladění a 86 % po doladění s retrievalem. Proč tedy většině týmů stále doporučujeme začít s RAG? Protože čerstvost dat, citace a nákladová matematika níže rozhodují víc projektů než jednobodový rozdíl v přesnosti.

Klíčové závěry

• RAG je výchozí volba, když se znalosti často mění nebo odpovědi musí uvádět zdroje; doladění vyhrává na konzistentním formátu a latenci.
• Náklady na doladění přicházejí na začátku (trénink); náklady RAG přicházejí s každým dotazem (embeddingy plus vstupní tokeny navíc).
• Publikované důkazy na stejném úkolu: doladění přidalo 6 bodů přesnosti, RAG dalších 5 navrch a hybrid porazil oba samostatné přístupy.
• Před napsáním jakéhokoli tréninkového kódu projděte pět kontrol (čerstvost dat, označené příklady, latence, citace, dovednosti týmu).

Kdy použít RAG vs. doladění? (Rychlý verdikt)

Zvolte RAG, pokud se vaše znalosti často mění nebo odpovědi musí nést citace. Zvolte doladění, pokud potřebujete konzistentní formát výstupu a nízkou latenci a máte stovky označených příkladů. Jakmile produkt dozraje, použijte obojí. RAG upravuje kontext, který model čte; doladění upravuje samotný model. Většina týmů potřebuje to první, ne to druhé.

Jedna věta na zapamatování: RAG mění, co model čte; doladění mění, čím model je. Rozhodujte se podle toho, co váš úkol skutečně vyžaduje.

Glosář RAG od NVIDIA definuje retrievalovou stranu čistě, pokud chcete učebnicovou verzi. Definice ale nevybírají vaši architekturu. Důkazy ano, takže začněte tam.

Co ukazují důkazy? Jeden úkol, oba přístupy, změřeno

Jediné měřené srovnání na stejném úkolu, které se umisťuje v top pěti Googlu pro tento dotaz, je Balaguer a kol. 2024, studie Microsoft Research citovaná 162krát. Tým provedl jeden zemědělský QA úkol přes RAG pipeline, doladěný model a hybrid obou a odpovědi nechal hodnotit GPT-4. V jejich nastavení doladění samo o sobě těsně porazilo RAG samotné a kombinace obou porazila každý přístup s větším odstupem.

Zemědělská případová studie (arXiv:2401.08406)

Studie, odeslaná v lednu 2024 Angels Balaguer a 15 spoluautory, zkoumá, co je potřeba k poskytování lokalitně specifických poznatků zemědělcům. Jejich pipeline extrahuje informace z PDF, generuje z nich dvojice otázka-odpověď a hodnotí Llama2-13B, GPT-3.5 a GPT-4 s retrievalem i bez něj.

Balaguer a kol. uvádějí nárůst přesnosti o více než 6 procentních bodů z doladění, kumulativní s RAG, které přidalo dalších 5 bodů navrch. Hybridní pipeline porazila každý přístup samostatně. Jejich tabulka 18 ukazuje pořadí pro GPT-4: 75 % bez pomoci, 80 % s RAG, 81 % po doladění, 86 % po doladění plus RAG. Všimněte si, jak blízko u sebe leží 80 % a 81 %; rozdíl mezi samotným RAG a samotným doladěním je jeden bod, zatímco hybrid je od obou o pět bodů výš. V jednom experimentu doladěný model čerpal znalosti z jiných geografických oblastí, aby odpověděl na regionálně specifické otázky, a zvedl podobnost odpovědí ze 47 % na 72 %.

Ekonomické důkazy

Publikovaná studie Snorkel AI (listopad 2022) pokrývá nákladovou stranu. Na 100třídním právním klasifikačním benchmarku (LEDGAR, 80 000 smluvních ustanovení) doladěný model RoBERTa dosáhl kvality doladěného GPT-3, přitom byl 1 400× menší, použil méně než 1 % ground-truth označení a běžel za 0,1 % produkčních inferenčních nákladů doladěného GPT-3, tedy zhruba za jednu tisícinu. Celkové náklady na sestavení: 1 915 $ s programovým označováním oproti 7 418 $ za ruční anotaci plus doladění GPT-3. Jedna výhrada: jde o klasifikaci, ne generativní QA, takže poměry berte jako směrové.

Náš pohled

Naše interpretace: jejich nastavení je nejpříznivější případ, jaký doladění může dostat, a přesto vyhrálo jen o bod. Balaguer a kol. trénovali na pevném PDF korpusu a hodnotili proti témuž zmrazenému korpusu, takže nic, co se váhy naučily, nemělo šanci zastarat během experimentu. Většina produkčních znalostních bází takto v klidu nezůstane. Podporovací bot odpovídající na otázky k minulému releasu musí 6 bodů znovu získat v každém retrainovém cyklu, zatímco index, který živí RAG, se aktualizuje totéž odpoledne. Proto čteme jednobodový náskok v přesnosti jako nejslabší vstup do tohoto rozhodování a čerstvost jako ten nejsilnější. Kde se důkazy nedají zobecnit: výsledek Snorkel je klasifikační benchmark a ani jedna studie netestuje kontrolu tónu nebo formátu, což zůstává nejsilnějším argumentem doladění.

Doladění je správná odpověď méně často, než si týmy myslí; většina projektů, které říkají „doladit", ve skutečnosti myslí „načíst".

Jak funguje RAG a kdy vyhrává?

RAG (retrieval-augmented generation) odpovídá z dokumentů, které kontrolujete, místo z toho, co si model zapamatoval během tréninku. Poprvé navržen Lewisem a kol. v roce 2020, stal se výchozí volbou pro znalostní práci, protože znalosti žijí mimo model: aktualizujte index a každá odpověď se změní zítra bez retrainu.

Pipeline má čtyři kroky:

1. Ingest. Parsování dokumentů (PDF, wiki, tickety) do korpusu.
2. Chunkování a embedding. Rozdělení na chunky o několika stech tokenech a převod každého na vektor pomocí embeddingového modelu.
3. Retrieval. V čase dotazu najděte top-K nejpodobnějších chunků plus keyword shody pro přesné řetězce jako SKU a chybové kódy.
4. Augmentace a generování. Vložte tyto chunky do promptu a nechte LLM odpovědět s přiloženými zdroji.

RAG vyhrává na třech osách: čerstvost (re-indexace místo retrainu), citace (každá odpověď ukazuje na chunk, ze kterého pochází) a kontrola dat (zákaznická data nikdy nevstoupí do tréninkového běhu). Pokud chcete kompletní návod na sestavení, zde je postup, jak sestavit RAG aplikaci krok za krokem.

Jedno varování ohledně kvality retrievalu: pipeline je jen tak dobrá jako její kombinace embeddingu a retrievalu. Contextual Retrieval od Anthropic změřil 5,7% míru selhání retrievalu top-20 u základních nastavení, klesající na 2,9 % s kontextovými embeddingy plus BM25 a na 1,9 % po přidání rerankeru. Pokud dotazy na přesnou shodu stále selhávají, hybridní vyhledávání (BM25 vs. vektor) je řešení.

Kdy vyhrává doladění? (A co je PEFT?)

Doladění vyhrává, když problém spočívá v tom, jak model odpovídá, ne v tom, co ví: konzistentní formát výstupu, tón značky nebo tvrdý rozpočet latence bez retrievalového round-tripu. Je také pákou pro ekonomiku malých modelů. Výsledek Snorkel „kvalita GPT-3 za 0,1 % nákladů" výše existuje jen proto, že někdo doladil malý model místo toho, aby servíroval velký.

Plné doladění vs. PEFT (LoRA / QLoRA)

Plné doladění aktualizuje každou váhu v modelu. Je drahé, pomalé a vzácné mimo velké laboratoře. Téměř každý nasazuje PEFT (parameter-efficient fine-tuning). LoRA (Hu a kol. 2021) zmrazí základní váhy a trénuje malý nízko-hodnostní adaptér, typicky 0,1–1 % počtu parametrů. QLoRA přidává navrch 4bitovou kvantizaci, takže 13B model se vejde na jednu spotřebitelskou GPU. Jeden příbuzný termín, který stojí za znalost: kontinuální pretraining, kde model pokračuje v pretrainingu na surovém doménovém korpusu (bez dohledu) před supervised doladěním na označených příkladech.

Minimální konfigurace LoRA podle dokumentace Hugging Face PEFT:

from peft import LoraConfig, get_peft_model

config = LoraConfig(
    r=16,                          # low-rank dimension; 8-64 typical
    lora_alpha=32,                 # scaling factor, commonly 2x r
    target_modules=["q_proj", "v_proj"],
    lora_dropout=0.05,
    bias="none",
    task_type="CAUSAL_LM",
)

model = get_peft_model(base_model, config)
model.print_trainable_parameters()
# trainable params: ~13M || all params: 6.7B || trainable%: 0.19

Pro přípravu datasetu, počty epoch a evaluaci viz náš průvodce doladěním krok za krokem.

Rizika jsou reálná: přetrénování na malých datasetech (několik set příkladů se může naučit nazpaměť místo naučit se vzory), zastaralost (váhy zmrazí vaše znalosti k datu tréninku) a žádná atribuce zdrojů (doladěný model nemůže ukázat své doklady). Pokud je cokoli z těchto tří dealbreaker, právě jste se přesvědčili zpět k RAG.

RAG vs. doladění vs. prompt engineering: kam zapadají ostatní?

Ty tři jsou žebřík, ne rivalové. Prompt engineering mění instrukce, RAG mění kontext, který model čte, a doladění mění váhy. Vlastní průvodce doladěním od OpenAI řadí doladění na konec smyčky: nejdřív evaluace, pak prompty, trénink až když promptování přestane stačit. Dvě novější možnosti doplňují sadu nástrojů.

Jeden zmatek, který stojí za pojmenování: MCP servery a agent frameworky jsou orchestrace, ne přizpůsobení. Rozhodují, ke kterým nástrojům a zdrojům se model dostane; nemění, jak model odpovídá. Můžete spustit RAG pipeline uvnitř agenta a doladit model pod ním a mnoho produkčních systémů dělá obojí. Války automatického doplňování („vs mcp", „vs agenti") jsou kategoriální chyby.

Je RAG levnější než doladění? Reálný nákladový model

Krátká odpověď: při realistických objemech dotazů ano. Účet za doladění přichází na začátku (označená data plus trénink), zatímco účet za RAG přichází s každým dotazem (embeddingy plus vstupní tokeny navíc). Dokumentace doladění OpenAI účtuje trénink po tokenech, ale poplatky za tokeny jsou drobné vedle lidských nákladů na označené příklady. Zde je matematika podle veřejných ceníků.

Otázka zvratu: kolik dotazů, než se kumulativní daň RAG na dotaz vyrovná investici do doladění?

break_even = training_cost / per_query_retrieval_delta
           = $1,915 / $0.0003
           ≈ 6.4 million queries

Při 50 000 dotazů měsíčně je to více než deset let. Pro většinu produktů se investice do doladění nikdy nevrátí jen přes úspory tokenů; doladíte kvůli formátu a latenci, ne abyste porazili RAG na náklady. Matematika se obrátí za miliony dotazů měsíčně nebo s velmi velkými načtenými kontexty. A všimněte si asymetrie: účet za doladění se obnovuje pokaždé, když datový drift vynutí retrain, zatímco RAG škáluje lineárně s objemem krát velikost chunku. Pokud jsou náklady na dotaz skutečnou starostí, začněte s omezením nákladů na dotaz LLM; pokud přesto půjdete cestou tréninku, porovnejte nástroje pro doladění, než vypíšete šek.

Jedna poznámka o čerstvosti: k červenci 2026 dokumentace doladění OpenAI uvádí, že hostovaná platforma se pro nové uživatele utlumuje, přičemž stávající uživatelé si ponechávají přístup k tréninku na nadcházející měsíce. Je to další důvod, proč se týmy přiklánějí k PEFT na otevřených modelech nebo prostému RAG.

5 kontrol, než se rozhodnete

Projděte těchto pět kontrol ano-ne, než napíšete jakýkoli tréninkový kód; vzorec odpovědí ukáže na RAG, doladění nebo hybrid spolehlivěji než jakýkoli benchmark. Odpovězte upřímně, pak počítejte.

1. Mění se znalosti rychleji, než byste stíhali retrainovat? Ano → RAG. Retrain při každé aktualizaci dokumentu není provozní plán.
2. Máte několik set označených příkladů? Ne → RAG nebo prompt engineering. Doladění na 40 příkladech se učí nazpaměť; neučí se vzory.
3. Existuje tvrdý rozpočet latence? Těsný → doladění se nabízí. Vynechání retrievalového round-tripu ušetří 50–200 ms.
4. Musí odpovědi nést citace nebo auditní stopu? Ano → RAG. Doladěné modely nemohou ukázat na zdrojový chunk.
5. Má tým ML dovednosti plus GPU nebo API rozpočet na trénink? Ne → RAG. Index, který můžete přestavět, poráží váhy, které nemůžete retrainovat.

Většinou ano na 1, 4, 5 → RAG. Většinou ano na 2 a 3 se stabilní doménou → doladění. Rozdělené odpovědi nebo zralý produkt s reálným provozem → hybrid (další sekce). Smyslem checklistu je rozhodovat se podle důkazů, ne podle toho, která technika zrovna letí na vašem feedu.

Můžete použít RAG a doladění dohromady?

Ano a pro zralá nasazení je hybridní vzor norma, ne výjimka. Dolaďte pro doménovou plynulost a formát výstupu (jak), načítejte pro fakta v čase inference (co). Balaguer a kol. uvádějí přesně toto na svém zemědělském úkolu: hybridní pipeline porazila každý přístup samostatně, přičemž 5bodový zisk RAG se navršil na 6 bodů doladění.

Cesta zralosti, kterou doporučujeme: začněte s prompt engineeringem, přidejte RAG ve chvíli, kdy odpovědi potřebují soukromá nebo čerstvá data, a přidejte doladění teprve, když nekonzistence formátu nebo latence začnou bolet v produkci. Přeskočte rovnou na doladění a zaplatíte tréninkovou daň, než zjistíte, zda retrieval problém nevyřešil.

Hybridní vzor není kompromis; pro zralá nasazení je to výchozí stav: dolaďte pro formát, načítejte pro fakta.

Jak vyhodnotíte svého vítěze?

Vyberte vítěze stejně, jako byste vybírali databázi: měřte na své zátěži, ne podle pocitu. Postup se vejde do jednoho odstavce a pokrývá čtyři čísla, která skutečně rozhodují.

• Podržená sada otázek. 100–300 reálných uživatelských otázek. Ne syntetických, nikdy nic, co bylo viděno během tréninku nebo indexace.
• Věrohodnost a správnost odpovědi. Věrohodnost zkoumá, zda je odpověď zakotvena v načteném kontextu; správnost odpovědi zkoumá, zda je skutečně správná. Dvojice, zpopularizovaná RAGAS, zachytí halucinace i retrievalové výpadky.
• Latence na p95, ne průměr. Retrieval přidává round-trip; měřte chvost.
• Náklady na 1 000 dotazů, tokeny plus infrastruktura, měřeno, ne odhadováno.
• Opakujte při driftu. Nové dokumenty, nový snapshot modelu, nové čtvrtletí: opakujte sadu.

Kompletní rozbor metrik včetně nástrojů najdete v našem průvodci evaluací LLM.

O autorovi

Mert Batur je spoluzakladatel Techsy.io, kde tým dodává AI agenty, automatizační systémy a hlasové/SDR pipeline pro B2B klienty. Píše o stacku nástrojů LLM, který tým Techsy skutečně používá v produkci. Spojte se na LinkedIn.

Často kladené otázky

Můžete použít RAG a doladění dohromady?

Ano. Dolaďte pro formát výstupu a doménovou plynulost a ponechte retrieval pro fakta v čase inference. Balaguer a kol. změřili tento hybrid na zemědělském QA úkolu a zjistili, že porazil každý přístup samostatně, přičemž zisky přesnosti se sčítaly. Většina zralých produkčních systémů skončí zde: váhy pro jak, retrieval pro co.

Kdy nepoužívat doladění?

Přeskočte doladění, když se vaše znalosti mění rychleji, než stíháte retrainovat, když máte méně než několik set označených příkladů, když odpovědi musí nést citace nebo auditní stopy, nebo když neexistuje rozpočet na retrain při datovém driftu. Tyto čtyři podmínky popisují většinu raných produktů, proto je RAG obvykle správný první krok.

Je doladění vyvráceno?

Ne, ale jeho území se zmenšilo. Dlouhá kontextová okna a levný RAG pohltil případy použití, které v roce 2023 vyžadovaly doladění. Co zůstává, je reálné: striktní formát výstupu, tón značky, rozpočty latence bez retrievalového round-tripu a ekonomika malých modelů. Pokud je váš problém v tom, jak model odpovídá, spíše než v tom, co ví, doladění je stále nástroj.

Kdy použít RAG vs. doladění?

Použijte RAG, když odpovědi závisí na soukromých nebo často aktualizovaných znalostech, nebo když potřebujete citace. Použijte doladění, když potřebujete konzistentní formát, tón nebo latenci a máte dostatek označených příkladů. Použijte obojí, jakmile produkt dozraje. Pokud si nejste jisti, začněte s RAG: je levnější vrátit zpět než tréninkový běh.

Je RAG levnější než doladění?

Na začátku ano. Náklady RAG jsou na dotaz (embeddingy plus vstupní tokeny navíc), zatímco doladění účtuje jednou za trénink a označená data a pak se obnovuje při každém retrainu. Podle veřejných ceníků vychází bod zvratu v našem propočtu přibližně na 6,4 milionu dotazů, takže při typických objemech zůstává RAG levnější po celou dobu životnosti produktu.

Je RAG lepší než doladění na halucinace?

Obvykle, ale ne zadarmo. RAG zakotví odpovědi v načtených chuncích, takže můžete citovat zdroje a auditovat selhání. Špatný retrieval ale odpověď otráví: Anthropic změřil 5,7% míru selhání retrievalu top-20 u základních nastavení, sníženou na 1,9 % s kontextovým retrievalem plus rerankingem. Doladění naproti tomu může zapéct chyby do vah bez možnosti je vysledovat.

RAG vs. doladění vs. prompt engineering: jaký je rozdíl?

Prompt engineering mění instrukce, které posíláte. RAG mění kontext, který model čte v čase dotazu. Doladění mění váhy modelu. Každý je větší zásah než ten předchozí: zkuste nejprve prompty, přidejte retrieval, když jsou znalosti úzké hrdlo, a trénujte teprve, když formát, tón nebo latence stále bolí.

Jak vyhodnotíte výkon RAG vs. doladění?

Sestavte podrženou sadu 100–300 reálných uživatelských otázek a ohodnoťte na ní oba přístupy: věrohodnost (je zakotvená?), správnost odpovědi (je správná?), latence p95 a náklady na 1 000 dotazů. Opakujte sadu, kdykoli se změní vaše dokumenty nebo snapshot modelu. Syntetické otázky lichotí oběma systémům; reálné je rozliší.

Doladění vs. RAG na vícekrokové otázky na nových znalostech?

RAG, s lepším retrievalem. Mechanismus o tomto rozhoduje: doladěný model může uvažovat jen nad tím, co jeho váhy absorbovaly, takže znalosti, které nikdy neviděl, jsou nedosažitelné bez ohledu na to, jak dobře byl natrénován. Retrieval mu předá chybějící kousky v čase dotazu. Háček je v tom, že jeden průchod retrievalu zřídka posbírá každý krok, takže plánujte dekompozici dotazu nebo iterativní retrieval plus reranker, ne jediné top-K vyhledání.

Závěr

Shrnutí bez vytáček:

• RAG je výchozí volba pro měnící se znalosti a citované odpovědi. Doladění je specialista na formát, tón a latenci.
• Důkazy na stejném úkolu (Balaguer a kol.) dávají doladění +6 p. b. a RAG dalších +5 p. b. navrch, přičemž hybrid je nejlepší ze tří. Naše rada začít s RAG spočívá na čerstvosti, citacích a nákladech, ne na tom skóre.
• Nákladová matematika vychází ve prospěch RAG při realistických objemech: bod zvratu ležel v našem propočtu kolem 6,4 milionu dotazů.
• Rozhodujte se podle pěti kontrol, ne podle zvyku.

Zvolili jste RAG? Podívejte se na náš žebříček nástrojů RAG pro stack kolem pipeline.