Fine-tuning vs. prompt engineering: kdy co použít?

Základní orientace: co je prompt engineering, fine-tuning a proč spolu nesoupeří

Prompt engineering je návrh instrukcí, kontextu a ukázkových interakcí tak, aby základní model (bez tréninku) plnil specifický úkol. Patří sem role a pravidla, požadovaný formát (například JSON nebo strukturované odstavce), few-shot příklady a guardraily. Dobře navržené prompty snižují halucinace, zvyšují konzistenci a zkracují čas na první funkční prototyp.

Fine-tuning znamená cílené doučení modelu na vašich příkladech. Cíle mohou být různé: naučit „hlas značky“, doménovou terminologii, přísný formát výstupu, odmítání zakázaných požadavků, robustní extrakci polí apod. Fine-tuning může být plný (nákladný) nebo lehký (LoRA/QLoRA, adaptery) a často se kombinuje s prompt engineeringem a RAG.

Důležitá teze: nejde o volbu „buď–anebo“. V praxi se osvědčuje trojkombinace: prompty pro chování a strukturu, RAG pro fakta a citace, lehký fine-tune pro konzistenci a latenci u vybraných úloh s vysokou zátěží.

Rychlá volba: rozhodovací mapa „prompt vs. fine-tune vs. kombinace s RAG“

Následující mapu použijte jako první filtr. Pokud alespoň dvě odpovědi padnou do stejného sloupce, máte silnou indicii.

Kdy preferovat prompt engineering (a jak ho dělat profesionálně)

Prompt engineering je ideální, když potřebujete rychle ověřit byznys hodnotu, když se úkol vyvíjí nebo když lze většinu přesnosti získat správným kontextem. Klíčové postupy:

Modularizace promptu

• System část popisuje roli, pravidla, bezpečnostní zásady a formát výstupu.
• Task část drží konkrétní požadavek uživatele a proměnné (například požadovaný jazyk, publikum, délku, schéma výsledku).
• Kontext dodává RAG: vyhledané pasáže, tabulky, metadata, odkazované dokumenty, citace.

Few-shot ukázky

Připravte 3–7 kontrastních příkladů, které pokryjí běžné i hraniční scénáře. Důležitá je rozmanitost a kratší, precizní ukázky místo jednoho monolitu. Ukázky musejí být ve stejném stylu jako požadovaný výstup.

Guardraily a determinismus

• Vyžadujte strukturované odpovědi (sekce, odrážky, JSON), ale mějte validátor a fallback, pokud model formát poruší.
• Specifikujte, co dělat při nedostatku informací (např. „vrať frázi – nemám dost informací – a citace“).
• Zakotvěte bezpečnostní zásady (žádné osobní údaje, žádné právní rady bez odkazu na interní manuál atd.).

Verzování a testovatelnost

Prompty držte jako šablony s verzemi, testy a linterem. Při každé změně proveďte aspoň základní regresní eval nad reprezentativním vzorkem dotazů. Sjednoťte definice metrik, jinak ztrácíte srovnání „před/po“.

Kdy dává smysl fine-tuning (a jaké má varianty)

Fine-tuning se vyplatí, pokud potřebujete konzistentní chování, přísný formát, brandový hlas nebo robustní extrakci z vysoce variabilních dokumentů. Rychlý přehled variant:

• Instrukční fine-tuning: učí model dodržovat pokyny, bezpečnostní pravidla a preferovaný styl.
• LoRA/QLoRA a další adaptery: lehké moduly trénované na menší compute, snadno přepínatelné a kombinovatelné.
• Preference learning (DPO, podobné přístupy): model se učí preferovat „lepší“ odpovědi na základě párových srovnání.
• Doménové dotrénování: specializace na konkrétní oborovou terminologii a konvence (právo, finance, zdravotnictví, telco atd.).

Typické přínosy: kratší prompty (nižší tokeny a latence), vyšší „poslušnost“ k formátu, méně re-promptů, konzistentnější styl a menší potřeba ručních oprav. Riziko: bez kvalitního datasetu hrozí přeučení na šablony, degradace obecné schopnosti a obtížnější odhalování chyb bez dobrých evalů.

RAG jako třetí cesta: když řešíte fakta, aktualitu a citace

RAG (Retrieval-Augmented Generation) připojuje k dotazu relevantní dokumenty – ať už jde o interní manuály, smlouvy, tabulky, e-maily či databázové záznamy. Model pak odpovídá s oporou ve faktech a s citacemi. Pro většinu podnikových nasazení je RAG nepostradatelný, protože:

• řeší aktualitu a právní auditovatelnost,
• umožňuje přesné citace a transparentnost,
• odděluje „paměť firmy“ od modelu – aktualizace probíhá reindexací, ne re-tréninkem.

RAG se obvykle kombinuje s promptem (chování) a lehkým FT (konzistence). Správný návrh retrievalu (vektorové vyhledávání, BM25, re-ranking, chunking a metadata) má často na kvalitu větší vliv než volba samotného LLM.

Porovnávací tabulka: náklady, konzistence, latence, udržitelnost

Use-cases: od interního FAQ po právní redlining a extrakci

Interní FAQ a znalostní báze

Pro HR, IT support, procurement či bezpečnost stačí často prompt + RAG. Získáte rychlou dobu uvedení do provozu, citace a audit. Fine-tuning přidávejte až v momentě, kdy chcete jednotný tón, přísné formátování nebo robustní handling edge-case dotazů s vysokým objemem.

Extrakce strukturovaných dat

U vysoce variabilních faktur, objednávek, smluv a zpráv je kombinace RAG (pro kontext a slovník) a lehkého FT na JSON schéma a „poslušnost“ často nejlepší volbou. Samotný prompt může mít potíže s konzistencí při velké variabilitě vstupu.

Právní redlining a compliance

Redlining podle playbooku vyžaduje přesný styl, důvody změn a citace. Kombinace je klíč: RAG přinese pravidla a vzory, FT zajistí konzistentní návrhy a prompt vyjeví formu a limity. Samotný FT nezajistí aktuální pravidla ani citace.

Marketingový „brand voice“

Pro kampaně, e-maily a landing stránky je FT na brand voice (1000+ kurátorovaných párů) výraznou výhodou. Prompt pak řeší zadání a kontext, RAG případně přináší produktová fakta a USP.

Technické Q&A a analytické odpovědi

V datech bohatých doménách (finanční analýzy, bezpečnostní monitoring) bývá nutný RAG pro fakta, prompty pro strukturu a volitelný lehký FT pro robustní dodržení schémat a odmítání nesmyslných dotazů.

Datová příprava pro fine-tuning: kvalita, množství, rozmanitost

Fine-tuning stojí a padá na datech. Platí pravidlo kvalita × rozmanitost × konzistence:

• Kvalita znamená, že „ideální odpověď“ je skutečně ideální, ne kompromis. Trénujete budoucí chování – nepřenášejte do něj vlastní chyby.
• Rozmanitost pokrývá běžné i hraniční případy, slang, různé délky a šumy. Záměrně vkládejte „ošklivé“ vstupy, které model v reálu potká.
• Konzistence zajišťuje stejný formát výstupu (sekce, klíče, tón). Bez ní se model učí „průměr“ a vy dostanete nedůslednost.

Kolik příkladů? Pro style/voice a instrukční FT stovky až jednotky tisíc vysoce kvalitních záznamů. Pro složitou extrakci z heterogenních dokumentů spíše tisíce a průběžné rozšiřování o nové typy.

Před tréninkem odstraňte PII, přidejte „difficulty tagy“, sjednoťte schémata a vytvořte validační a testovací subset, který simuluje produkci. Logujte verze datasetu – budete je potřebovat pro audit i regresní srovnání.

Měření kvality: eval sady, metriky, A/B testy a „as-of“ přístup

Bez měření se debata vrací k dojmům. Doporučená praxe:

• Offline eval sada 100–1000 případů s jasnou „zlatou pravdou“ a rubric (správnost, úplnost, formát, citace, bezpečnostní pravidla).
• Automatické metriky: exact match pro extrakci, F1 na entitách, validace JSON, penalizace za chybějící citace; u generativních úloh human rating (double-blind) a preference testy.
• Online A/B test s byznys KPI: čas do odpovědi, počet re-promptů, počet eskalací na člověka, spokojenost uživatelů, konverze.
• As-of vyhodnocení: srovnávejte se stavem znalostí v okamžiku dotazu. Reklasifikace a pozdější opravy do evalu nepatří, jinak si zkreslíte výsledky.

TCO a rozpočet: trénink, inference, indexy, bezpečnost

TCO tvoří čtyři velké bloky:

1. Trénink a kurátorství: příprava datasetu, anotace, validace, compute, iterace; u LoRA/QLoRA je compute výrazně nižší.
2. Inference: počet tokenů (prompt + kontext + odpověď), latence, cache, případně vlastní hostování menšího modelu pro predikovatelnou cenu.
3. RAG infrastruktura: vektorová databáze, BM25 index, re-rankery, pipeline pro ingest a čištění dokumentů, sledování kvality retrievalu.
4. Bezpečnost a compliance: PII redakce, filtr rizikového obsahu, auditní logy, řízení přístupů, rezidence dat.

Ekonomické pravidlo palce: pokud je use-case úzký, stabilní a s vysokou zátěží, lehký fine-tuning se vrátí na snížení tokenů a re-promptů. Pokud je doména široká a rychle se mění, investujte do RAG a promptů; FT přidejte až po stabilizaci chování.

LLMops a governance: verze, drift, release, audit

Produkční LLM bez LLMops dlouho nevydrží. Zaveďte:

• Model registry: kdo nasadil kterou verzi, na jakých datech, s jakými metrikami, jaký je rollback plán.
• Verzování promptů a indexů: prompty jako kód, testy a linting; indexy s datovou linií a datem „as-of“.
• Monitoring driftu: změna distribuce dotazů, pokles skóre, nové typy dokumentů; automatické upozornění a re-indexace.
• Release proces: QA brána, regresní eval, schvalování bezpečností a právem, evidence pack pro audit.

Bezpečnost a compliance: PII, citlivý obsah, smluvní závazky

V podnikových projektech je bezpečnost stejně důležitá jako přesnost. Doporučení:

• Data minimization: do promptu a retrievalu posílejte jen to, co je nezbytné. Pseudonymizujte PII a obchodní tajemství, zejména v logách.
• Smluvní záruky: u vendorů vyžadujte, že vaše data nebudou použita pro trénink cizích modelů; jasně definujte retenční politiku a auditní práva.
• Role a přístupy: SSO, RBAC, citlivé kolekce indexů jen pro oprávněné týmy; obsahové logy očišťujte o PII.
• Zásady odpovídání: při nedostatku informací musí model vrátit bezpečnou odpověď a odkázat na citace; žádné „vymýšlení“ mimo zdroje.

Doporučené workflow krok za krokem

1. Definujte úkol, uživatele a metriky úspěchu (technické i byznysové).
2. Postavte první verzi s prompt engineeringem a RAG, ať rychle měříte hodnotu a získáte logy o chování uživatelů.
3. Vytvořte eval sadu, dolaďte retrieval (chunking, metadata, re-ranking) a prompt (role, formát, guardraily, few-shot).
4. Spusťte MVP do omezené skupiny, měřte A/B, sbírejte „těžké“ případy a edge-cases.
5. Vyhodnoťte, zda vás brzdí konzistence, formát či latence. Pokud ano, připravte kvalitní dataset a proveďte lehký fine-tuning.
6. Zaveďte LLMops: registry, verze, drift, QA brány a evidence pack. Plánujte pravidelné re-indexace a refresh FT.

Antipatterny: čemu se vyhnout už v návrhu

• Sázet vše na jeden supermodel bez retrievalu: bez zdrojů budou odpovědi zastarávat a auditovatelnost klesne.
• Předčasná optimalizace fine-tuningem: nejdřív stabilizujte prompt a RAG; FT dělejte na datech, která reprezentují realitu.
• Prompty jako „řemeslo jednotlivce“: bez verzí, testů a šablon se kvalita rozpadne s růstem týmu.
• Eval na „umytých“ datech: porovnání s realitou musí být as-of; jinak si přikrášlíte výsledky.
• Ignorování nákladů na inference: dlouhé prompty a zbytečně široký kontext výrazně prodraží provoz.

Závěrečné doporučení pro byznys i technické vedení

Prompt engineering, fine-tuning a RAG nejsou konkurenční tábory, ale komplementární nástroje. V praxi se osvědčuje postup: nejprve prompt + RAG, abyste rychle doručili hodnotu, získali citace a metriky; následně lehký fine-tuning pro konzistenci, formát a latenci u use-casů s jasným přínosem. Investujte do evalů, verzí a governance, jinak nepoznáte, co se skutečně zlepšilo a proč. Pokud tuto disciplínu zvládnete, získáte přesné, nákladově efektivní a udržitelné LLM řešení, které se přizpůsobuje byznysu – a nikoli naopak.