Keď sme prvýkrát nasadili LLM do produkčného prostredia u klienta z výroby, trvalo nám tri týždne, kým sme pochopili, prečo model občas odpovie v angličtine namiesto slovenčiny, prečo ignoruje formátovanie a prečo si v jednom z desiatich prípadov vymyslí číslo zo vzduchu. Všetky tri problémy mali rovnaké riešenie: systémový prístup k promptom — nie intuícia, nie pokus-omyl, ale overená štruktúra.
Prompt engineering je dnes jedna z najčastejšie skloňovaných, ale aj najmenej správne pochopených disciplín v AI projektoch. Keď sa pýtame technických riaditeľov, čo od neho očakávajú, väčšina povie „lepšie odpovede". To je pravda — ale len do určitej miery. Tento článok rozkladá, čo prompt engineering reálne dokáže, kde sú jeho hranice a čo patrí do iného nástrojového poľa.
Čo prompt engineering naozaj je
Prompt engineering je systematické navrhovanie a verzovanie vstupov pre jazykový model s cieľom dosiahnuť konzistentné, predvídateľné a merateľné výstupy. Kľúčové slovo je konzistentné — nie „občas skvele".
V produkčnom systéme nestačí, že prompt funguje v 80 % prípadov. Ak ho nasadíte do zákazníckej podpory, tých 20 % zlyhaní sa zákazníci zapamätajú. Ak ho nasadíte do spracovania faktúr, 20 % chýb je katastrofa. Prompt engineering je teda menej o kreativite a viac o inžinierskej disciplíne: dokumentovanie, verzovanie, testovanie, meranie.
Čo funguje — overené vzory
1. Jasná inštrukcia s explicitným výstupným formátom
Najväčší jednotlivý vplyv na kvalitu výstupu má to, ako presne model vie, čo má produkovať. Vágna inštrukcia „zhrň tento dokument" dáva vágne výsledky. Špecifická inštrukcia funguje dramaticky lepšie:
- Povedzte modelu, kto je cieľové publikum výstupu
- Definujte presný formát: počet odrážok, maximálnu dĺžku, či má výstup obsahovať záver alebo nie
- Pri štruktúrovaných dátach vždy používajte structured outputs a JSON mode — model viazaný na schému halucinuje výrazne menej ako model s voľným textovým výstupom
Videli sme u klientov, že iba prechod od „extrahuj údaje z faktúry" k „vráť JSON objekt s poľami: dodávateľ (string), IČO (string 8 znakov), suma (číslo), dátum (ISO 8601)" znížil chybovosť extrakcie o rádovo desiatky percent.
2. Few-shot príklady — keď a ako ich použiť
Few-shot prompting (niekoľko príkladov vstup-výstup priamo v prompte) je jeden z najspoľahlivejších nástrojov, ale len vtedy, keď sú príklady reprezentatívne. Pravidlá:
- 1.Príklady musia pokrývať edge cases, nie len happy path
- 2.Formát príkladov musí byť konzistentný — ak raz použijete „Vstup:" a inokedy „Input:", model si to všimne
- 3.Počet príkladov závisí od zložitosti tasku — pre jednoduchú klasifikáciu stačia 2–3, pre viacstupňové uvažovanie 5–7
- 4.Príklady si vyberte z reálnych dát, nie vymyslených — syntetické príklady mávajú iné štatistické vlastnosti ako produkčné vstupy
Few-shot je obzvlášť silný pri formátovaní a pri taskoch s jasnou vzorovou štruktúrou. Je menej efektívny pri znalostiach, kde modelu chýba doménový kontext — tam je odpoveďou RAG alebo fine-tuning.
3. Role a persona
Explicitné priradenie roly funguje — nie preto, že by model „uveril", že je nejaký iný, ale preto, že rola posúva pravdepodobnostné rozdelenie výstupov k relevantnejším vzorcom. „Ste senior právnik špecializovaný na slovenské pracovné právo" aktivuje iné jazykové vzory ako „Ste asistent".
Dôležité: rola definuje tón a slovnú zásobu, ale nenahradí znalosť. Model s rolou „expert na ATEX smernice" stále môže halucinovať, ak o ATEX smernice nemá dostatok tréningových dát. Rola je jazykový filter, nie znalostná databáza.
4. Reťazenie krokov (Chain-of-Thought)
Pri zložitých analytických úlohách — porovnávanie, viacstupňový výpočet, rozhodovanie podľa podmienok — explicitná inštrukcia „postupuj krok za krokom" alebo rozdelenie na viacero subpromptov výrazne zlepšuje spoľahlivosť. Modely robia menej chýb, keď môžu „myslieť nahlas" pred záverečnou odpoveďou.
V praxi to znamená: nežiadajte od modelu záver priamo. Nechajte ho najprv rozložiť problém, identifikovať relevantné faktory, a až potom sformulovať záver. Výsledok je spoľahlivejší a navyše ľahšie overiteľný — vidíte, ako model dospel k záveru.
5. Negatívne inštrukcie — čo nerobiť
Väčšina promptov hovorí modelu, čo má robiť. Rovnako dôležité je povedať, čo nemá robiť. „Nikdy nezačínaj odpoveď frázou 'Samozrejme!'", „Nepoužívaj anglické slová tam, kde existuje slovenský ekvivalent", „Ak nevieš odpovedať z poskytnutého kontextu, povedz to explicitne — nedomýšľaj." Negatívne inštrukcie redukujú výskyt konkrétnych opakujúcich sa chýb.
Čo nefunguje — mýty
Mýtus 1: „Prosím" a odmeny zlepšujú výsledky
Krátka odpoveď: nie. Výzvy ako „za každú správnu odpoveď dostaneš 100 dolárov" alebo úctivé „prosím, pomôž mi s..." nemajú merateľný efekt na kvalitu produkčného výstupu. Model nereaguje na sociálnu manipuláciu ani na emócie — reaguje na štatistické vzory v tréningových dátach. Čas strávený „motivovaním" modelu je čas stratený.
Mýtus 2: Dlhší prompt = lepší výsledok
Dĺžka a kvalita sú dve rôzne veci. Videli sme systémové prompty s tisíckami tokenov, ktoré fungovali horšie ako päťriadkové. Problém je, že modely majú tendenciu „strácať" pokyny uprostred veľmi dlhého kontextu — efekt nazývaný „lost in the middle". Štruktúra a jasnosť sú dôležitejšie ako objem. Ak váš prompt rastie, je to skôr príznak, že sa pokúšate promptom riešiť problém, ktorý patrí do systémového dizajnu.
Mýtus 3: Dobrý prompt nahradí eval
Toto je pravdepodobne najnebezpečnejší mýtus. Prompt bez evaluácie je hypotéza, nie riešenie. V praxi vídame tímy, ktoré strávia týždeň ladením promptu, nasadia ho do produkcie a po mesiaci zistia, že 15 % výstupov je nesprávaných — pretože nikdy systematicky nemerali.
Eval — automatizované hodnotenie výstupov na testovacej sade — je predpokladom produkčného nasadenia, nie voliteľný doplnok. Viac o tom, ako merať kvalitu LLM aplikácie.
Mýtus 4: Prompt engineering je trvalé riešenie
Prompt je krehký artefakt. Keď provider vydá novú verziu modelu, váš prompt sa môže správať inak — aj keď ste ho nemenili. Videli sme prípady, kde aktualizácia modelu zlepšila všeobecnú kvalitu, ale rozbila konkrétne formátovacie inštrukcie, ktoré boli „nalepené" na správanie staršej verzie.
Prompt engineering je iteratívna, nie jednorazová práca. Ak si to neuvedomíte pred nasadením, uvedomíte si to po ňom.
Mýtus 5: System prompt je bezpečný kontajner pre citlivé informácie
System prompt je pre model inštrukcia, nie sejf. Prompt extraction (extrahovanie obsahu system promptu) je dobre zdokumentovaný útok — existujú techniky, ktorými útočník dokáže z modelu vytiahnuť obsah system promptu cez normálne používateľské rozhranie. Nikdy do system promptu nepatrí: heslá, API kľúče, interné cenníky, osobné dáta zamestnancov ani žiadna informácia, ktorej únik by bol problémom. System prompt patria inštrukcie o správaní, nie tajomstvá.
Prompt ako kód — verzovanie a správa
V tímoch, s ktorými pracujeme, sa opakovane objavuje ten istý problém: prompt je uložený v kóde ako hardcoded reťazec, nikto nevie, kto ho naposledy zmenil a prečo, a keď sa niečo pokazí, nie je história, ku ktorej sa vrátiť.
Prompt je kód. Platia pre neho rovnaké princípy:
- Verzovanie v git — každá zmena promptu je commit so zmysluplným commit message
- Semantic versioning — major verzia pri zmene, ktorá mení výstupné správanie; minor pri doplnení; patch pri oprave pravopisu
- Testovacia sada — ku každej verzii promptu existuje sada testovacích prípadov s očakávanými výstupmi; zmena promptu prešla, iba ak testy zelení
- Prompt register — centrálne miesto (môže byť jednoduchý YAML v repe, alebo nástroj ako
Langfuse) kde je vidno, ktorý prompt je kde nasadený, v akej verzii a kto je vlastník
Nástroje ako Promptfoo umožňujú automatické testovanie promptov v CI/CD pipeline — každý pull request s úpravou promptu automaticky spustí testovaciu sadu pred mergom. Toto je prax, ktorú odporúčame každému tímu, ktorý má viac ako jeden aktívny prompt v produkcii.
Kedy prompt nestačí — a čo namiesto neho
Prompt engineering je silný nástroj v úzkom pásme problémov. Je slabý tam, kde:
Chýba znalosť — model nevie to, čo potrebuje vedieť, pretože to nie je v tréningových dátach. Prompt nevie pridať znalosť. Riešenie: RAG (retrieval-augmented generation) pre faktografickú podporu, alebo fine-tuning pre hlbokú doménovú adaptáciu.
Chýba konzistentný formát — výstup sa má vždy riadiť presnou schémou. Prompt môže pomôcť, ale spoľahlivejšie riešenie je structured outputs (JSON schema viazaný na model). Viac v článku o structured outputs a JSON mode.
Chýba bezpečnosť — ak systém spracúva nedôveryhodné vstupy (napr. zákaznícke správy, externé dokumenty), prompt injection je reálne riziko. Prompt sám sa nedokáže zabrániť vlastnému prepisaniu. Potrebujete architektonické guardrails — validáciu vstupov, allowlisty akcií, sandboxing. Detailnejšie v článku o prompt injection a jailbreakoch.
Chýba meranie — ak neviete, či prompt funguje, prompt engineering je len tipovanie. Bez evalu neverte ani výbornému promptu.
Praktické verzovanie promptov — ako začať
Pre tímy, ktoré ešte nemajú systematickú správu promptov, odporúčame jednoduchý postup:
- 1.Vytvorte adresár
prompts/v repozitári s jedným YAML súborom na prompt - 2.Každý YAML obsahuje:
name,version,description,system_prompt,user_prompt_template,model,temperature,test_cases - 3.Zmeny cez pull request — review promptu rovnako ako review kódu
- 4.Pred nasadením novej verzie: spustite testovaciu sadu na stávajúcej aj novej verzii, porovnajte metriky
- 5.Po nasadení: monitorujte výsledky v produkcii; anomálie (náhly nárast chybovosti, zmenená dĺžka výstupov) sú príznakom regresie
Toto nie je overkill — je to minimum. Tímy, ktoré to nerobia, objavujú problémy v produkcii namiesto v testovaní.
Prompt engineering a modely — čo sa mení s modelom
Dôležitá vec, ktorú vídame ignorovanú: rôzne modely reagujú na rovnaký prompt inak. Prompt optimalizovaný pre jeden model môže fungovať podstatne horšie na inom. Niekoľko konkrétnych vzorcov:
- Instruction following: novšie frontier modely (Claude, GPT-4 trieda) sú výrazne lepšie v dodržiavaní explicitných inštrukcií ako staršie alebo menšie modely
- Few-shot sensitivity: niektoré modely reagujú na few-shot príklady silno, iné menej — závisí od veľkosti a tréningového postupu
- Jazyková kvalita: slovenčina je low-resource jazyk; frontier modely ju zvládajú dobre, menšie open-weight modely môžu degradovať — vždy testujte v cieľovom jazyku
- Temperature: pri deterministických taskoch (extrakcia, klasifikácia) nastavte
temperature=0alebo veľmi nízko — výstupy budú konzistentnejšie; pri generatívnych taskoch (písanie) trochu vyššie
Keď meníte model, vždy spustite existujúcu testovaciu sadu. Nečakajte, že prompt „funguje rovnako".
Časté otázky
Oplatí sa investovať čas do prompt engineeringu, alebo je lepšie rovno fine-tuniť?
Prompt engineering je prvý krok, fine-tuning je ďalší — nie alternatíva. Ak máte dobre navrhnutý prompt a stále nie ste spokojní s výsledkami napriek few-shot príkladom a štruktúre, skúmajte, či problém nie je v chýbajúcej doménovej znalosti (riešenie: RAG) alebo v konzistencii štýlu výstupu (riešenie: fine-tuning). Fine-tuning bez dobre navrhnutého promptu a bez eval je premárnený čas a peniaze.
Môžem prompt engineering použiť na zabezpečenie toho, aby model nikdy neodpovedal na určité témy?
Nie spoľahlivo. Prompt-only obrany (inštrukcia „nikdy neodpovedaj na X") sú obíditeľné — to je hlavný záver výskumu prompt injection a jailbreakovania. Pre produkčné systémy sú nevyhnutné architektonické opatrenia: filtrovanie vstupov pred odovzdaním modelu, validácia výstupov pred zobrazením, monitoring. Inštrukcia v prompte je prvá vrstva, nie jediná.
Ako viem, že môj prompt je dobrý?
Jedine cez meranie. Definujte si testovaciu sadu prípadov (minimálne 20–50 pre jednoduchý task, viac pre komplexné) s očakávanými výstupmi alebo kritériami hodnotenia. Spustite prompt na testovacej sade a zmerajte relevantnú metriku (presnosť, formátovanie, jazyková správnosť, faktická správnosť). Bez čísla je „dobrý prompt" len pocit.
Koľko tokenov by mal mať systémový prompt?
Neexistuje univerzálna odpoveď, ale v praxi vidíme, že efektívne systémové prompty sú zvyčajne v rozsahu 200–800 tokenov. Kratšie sú nedostatočne špecifické, dlhšie začínajú trpieť efektom „lost in the middle" — model stráca track pokynov uložených uprostred. Ak váš prompt prekračuje tisíc tokenov bez jasného dôvodu, je čas ho refaktorovať alebo premýšľať, či niektoré informácie nepatria do RAG kontextu namiesto systémového promptu.
Platí to isté pre open-weight modely nasadené lokálne?
Väčšina princípov platí, ale s dôležitou výhradou: menšie open-weight modely (7B–13B parametrov) sú menej robustné v dodržiavaní inštrukcií ako frontier modely. Few-shot príklady sú dôležitejšie, formátovanie promptu musí byť precíznejšie a testovaciu sadu musíte prispôsobiť konkrétnej rodine modelov. Prompt navrhnutý pre frontier modely nemusí fungovať rovnako na Mistral 7B alebo podobne veľkých open-weight modeloch — a to ani po starostlivej optimalizácii. Slovenčina navyše predstavuje extra výzvu pre menšie modely — testujte vždy v produkčnom jazyku.
*Prompt engineering je remeslo, nie mágiu — a ako každé remeslo sa dá naučiť, systematizovať a merať. Ak riešite nasadenie LLM do produkcie a nie ste si istí, kde začať, radi posúdime váš konkrétny prípad a pomôžeme nastaviť základy, na ktorých sa dá stavať.*