RAG, nebo fine-tuning: častá záměna prodraží firemní AI

Má-li firemní AI odpovídat podle průběžně měněných dokumentů a uvádět původ informací, výchozí volbou je RAG. Má-li opakovaně dodržovat určitý styl, formát nebo postup při úzce vymezené úloze, dává smysl uvažovat o fine-tuningu. Srovnání AWS doporučuje začít RAG u otázek nad vlastními dokumenty a připouští spojení obou metod, pokud každá řeší jinou potřebu.

Rozhodnutí stojí na rozdílu mezi znalostí a chováním. RAG při každém dotazu vyhledá podklady a vloží je do zadání modelu; fine-tuning upraví model na základě příkladů vstupu a žádoucího výstupu. Pokud tým ladí model po každé změně dokumentace nebo provozuje index jen kvůli neměnnému formátu odpovědi, platí za práci, která neřeší původní problém.

Nejdřív určete, co se má změnit

Rozhodovací strom začíná otázkou, zda model nemá správný podklad, nebo s ním špatně pracuje. U každé varianty pak záleží na čerstvosti dat, potřebě citací a míře opakovatelnosti požadovaného výstupu.

• Obsah se mění, odpověď musí vycházet z interních podkladů nebo odkazovat na konkrétní dokument: začněte RAG. Přesnost bude záviset na tom, zda vyhledávání najde správnou a platnou verzi.
• Podklad je k dispozici, ale výsledek opakovaně porušuje požadovanou strukturu, tón či klasifikační pravidla: nejprve zkuste přesnější zadání a příklady v kontextu. Pokud stejná chyba přetrvává, otestujte fine-tuning na reprezentativních případech.
• Odpověď potřebuje aktuální zdroj i zvláštní způsob jeho zpracování: porovnejte RAG se systémem, v němž nalezené pasáže zpracuje doladěný model. Přidaná složitost má smysl jen při měřitelném přínosu.

Rozhodování ovlivní také maximální přijatelná latence a očekávaný počet dotazů. Vyhledání pasáží přidává síťový a výpočetní krok, zatímco ladění vyžaduje přípravu příkladů a další provoz modelu. Proto nestačí porovnat cenu jediného volání modelu bez celého postupu, který odpověď vytvoří.

RAG udržuje znalosti dohledatelné

V RAG se dokumenty připraví pro vyhledávání, při dotazu se vyberou relevantní pasáže a model z nich sestaví odpověď. Dokumentace Microsoft Foundry doporučuje tento postup pro soukromá nebo často měněná data; popisuje také citace, řízení přístupu a dodatečné náklady na vyhledávání, embeddingy a vstupní tokeny. Nový dokument tak lze zpřístupnit retrievalu aktualizací zdroje či indexu, bez dalšího trénování jazykového modelu.

U podkladů, jako jsou interní postupy nebo produktová pravidla, je důležité hledat podle platné verze. Pokud index obsahuje staré i nové znění a dotaz vrátí nesprávnou pasáž, model může vytvořit přesvědčivou, ale zastaralou odpověď. Na kvalitě se podílí způsob dělení dokumentů, jejich metadata, řazení výsledků i to, kolik nalezeného textu se vejde do kontextu.

Citace vyžadují uchovat vazbu mezi úryvkem a původním souborem či stránkou. Samotný odkaz ještě nezaručuje, že uvedený úryvek podporuje každé tvrzení v odpovědi; tuto shodu je nutné hodnotit zvlášť. U neveřejných dat musí vyhledávací vrstva zároveň respektovat práva tazatele, jinak může model dostat obsah, který by uživatel neměl vidět.

Fine-tuning učí opakovaný způsob odpovídání

Ladění je vhodné tam, kde lze na kvalitních příkladech ukázat, jak má model dlouhodobě plnit stejnou úlohu. Dokumentace Google Cloud doporučuje začít návrhem zadání, hledat opakující se chyby a pro ladění použít příklady odpovídající skutečným produkčním vstupům; jako vhodné úlohy uvádí klasifikaci, extrakci údajů nebo jednoduché shrnutí.

Pro firemní tým může jít například o konzistentní označování příchozích požadavků či pevně určenou podobu odpovědi. Podstatné je, aby příklady zahrnovaly běžné vstupy i obtížné okrajové případy; nekvalitní sada učí model také chybná pravidla. Když model správný firemní podklad vůbec nevidí, trénovací dvojice samy přístup k aktuálním informacím nezajistí.

U opakované úlohy může doladěný model vystačit s kratším zadáním, protože část vzoru chování získal při trénování. Nižší počet vstupních tokenů může zkrátit dobu odpovědi a snížit cenu inference, ale skutečný přínos závisí na zvoleném modelu, provozu a nákladech na jeho ladění. Požadavek na doslovně dohledatelný zdroj odpovědi tím nezmizí.

Do ceny patří údržba i vyhodnocování

U RAG se platí nejen za dotaz do indexu a tokeny předané modelu. Rozpočet zahrnuje převod a dělení dokumentů, tvorbu či obnovu indexu, případné embeddingy, kontrolu relevance a správu oprávnění. Změna struktury zdrojových dat může vyžadovat úpravu celého vyhledávacího toku; bez ní se čerstvý dokument do odpovědí vůbec nemusí dostat.

Fine-tuning přesouvá část práce do přípravy a kontroly trénovacích příkladů, běhů ladění a hodnocení nové varianty modelu. Přehled Microsoft Foundry upozorňuje na náklady trénování a hostování i na možnost opakovat ladění při změně dat nebo základního modelu. Do srovnání tedy patří také cena průběžné údržby, nikoli pouze účet za úspěšné požadavky.

Praktický odhad lze sestavit bez univerzální sazby: zvlášť vyčíslete jednorázovou přípravu, měsíční provoz při očekávaném objemu dotazů a práci vyvolanou změnami podkladů či modelu. Stejnou sadu typických úloh použijte pro hodnocení správnosti, doby odpovědi a počtu oprav. U RAG sledujte nalezení platného podkladu a věrnost citací; u ladění splnění požadované úlohy i výkon na případech mimo trénovací sadu.

Kombinace potřebuje vlastní důvod

Obě metody lze spojit, když vyhledávání dodává správné a aktuální pasáže, ale model je soustavně zpracovává špatným způsobem. Retrievalu zůstává odpovědnost za podklady a jejich původ, zatímco ladění se zaměří například na strukturu odpovědi nebo výběr důležitých informací z nalezeného textu. Podmínkou je dostatek kvalitních ukázek právě této práce s podklady.

Rozdíl se ukáže při srovnání základního modelu s dobrým zadáním, samostatného RAG a kombinované varianty na stejných dotazech. Selhává-li už nalezení správného dokumentu, má přednost oprava zdroje nebo vyhledávání. Jestliže je podklad správný a model opakovaně chybuje až v jeho použití, má fine-tuning konkrétní cíl, vůči němuž lze posoudit přidanou cenu.