Meta-prompting: keď si agenti píšu vlastné prompty

Meta-prompting označuje techniky, pri ktorých jazykový model sám generuje, hodnotí alebo zlepšuje vlastné prompty namiesto toho, aby ich manuálne formuloval človek. Namiesto pokusov a omylov proces riadený evaluáciami programovo optimalizuje inštrukcie, few-shot príklady a výstupné formáty na testovacej sade. Frameworky ako DSPy to automatizujú tým, že s promptmi zaobchádzajú ako s kompilovateľným kódom s definovaným vstupom, výstupom a metrikou úspechu.

Pojem zahŕňa dve príbuzné praktiky: LLM, ktorý navrhne lepší prompt pre úlohu, a optimalizačnú slučku, ktorá testuje varianty promptu na vzorových dátach. V oboch prípadoch sa tvorba promptu mení z ručného remesla na automatizovaný, merateľný proces. Úzko príbuzná je kompresia promptov, ktorá zmenší dlhý kontext s minimálnou stratou informácií.

• Čo to je: LLM zlepšuje alebo generuje vlastné prompty. Automatická optimalizácia overená evaluáciami nahrádza ručne riadený prompt engineering.
• Kedy je to vhodné: Pri škálovaní (veľa volaní), pri existujúcej evaluačnej sade a validnej metrike a vtedy, keď záleží na reprodukovateľnosti naprieč mnohými požiadavkami.
• Kde je hranica: Bez čistej testovacej sady systém optimalizuje na nesprávny cieľ; automaticky generované prompty sa ťažšie vysvetľujú a auditujú.

Prečo ručné ladenie promptov naráža na hranice

Vývoj praxe okolo LLM prebieha vo fázach. V ére prompt engineeringu (2022-2023) stálo v centre pozornosti napísanie jediného šikovného promptu: umenie sformulovať prompt tak, aby model dodal požadovanú odpoveď. S nástupom agentických systémov to už nestačí: prompty musia stabilne fungovať naprieč mnohými kolami inferencie a pracovať s nástrojmi, pamäťou a meniacim sa kontextom.

Tu nastupuje meta-prompting. Inžiniersky konsenzus roku 2026 je jednoznačný: ladenie promptov metódou pokusov a omylov nahrádzajú A/B testy riadené evaluáciami. Namiesto hádania, či je určitá formulácia lepšia, sa to zmeria na pevnej testovacej sade. A len čo sa meria, ďalší krok je nasnade: automatizovať samotné hľadanie lepších promptov.

Jedno z najúprimnejších zistení rokov 2024-2026: mnohé populárne tipy na prompt engineering prinášajú pri dôsledných evaluáciách minimálne alebo žiadne zlepšenie. „Si expert“ nemá na moderných modeloch väčšinou merateľný efekt. „Think step by step“ je pri reasoning modeloch už predvolené správanie a ručne pridané býva často kontraproduktívne. „Dám ti 200 dolárov prepitného“ fungovalo v roku 2023 anekdoticky, dnes je väčšinou neutrálne alebo negatívne. Poučenie: folklórne tipy poslúžia ako hypotézy, ale treba ich overiť na evaluačnej sade. Práve táto disciplína robí automatickú optimalizáciu zmysluplnou, pretože optimalizátor bez validnej metriky optimalizuje naprázdno.

Dve formy meta-promptingu a jeden príbuzný postup

1. Prompty, ktoré model sám generuje a zlepšuje

V najjednoduchšom prípade silnejší model vygeneruje prompt pre slabší model alebo pre seba. Príbuzné sú reflexné slučky: model vygeneruje odpoveď, skritizuje ju a prepracuje (vzor „Reflect-and-Revise“, resp. Reflexion). Patrí sem aj vzor LLM-as-Judge: samostatné volanie hodnotiaceho modelu posúdi výstup podľa hodnotiacej rubriky. Tieto stavebné prvky sa dajú reťaziť: jeden model napíše prompt, druhý vyhodnotí výsledok a prvý prompt doladí.

2. Programatická optimalizácia (DSPy)

Najväčší skok prináša programatická optimalizácia. DSPy, známy open-source framework z akademického prostredia, nezaobchádza s promptmi ako s textom, ale ako s kompilovateľnými programami. Vývojár deklaratívne opíše, čo má krok robiť (signatúra: vstup → výstup), a definuje metriku úspechu. Optimalizátor potom automaticky prehľadáva priestor možných inštrukcií a few-shot príkladov a skompiluje prompt, ktorý na testovacej sade maximalizuje metriku. Človek už nepíše znenie promptu, ale špecifikáciu a metriku.

Príbuzný postup: kompresia promptov

Príbuzná technika, no nie meta-prompting: kompresia promptov znižuje náklady na tokeny a brzdí context rot. Model pritom zhŕňa kontext, ale nepíše vlastný prompt. Compaction je štruktúrovaný variant: keď sa dosiahne prahová hodnota (typicky 70-85 percent nominálnej kapacity), sumarizačný krok zhustí doterajšiu konverzáciu do kompaktnej reprezentácie. Anthropic pre Claude Code opisuje, že sa pritom zachovajú architektonické rozhodnutia, nevyriešené chyby a implementačné detaily, zatiaľ čo redundantné výstupy nástrojov sa zahodia. Inžinierske pravidlo: kritické artefakty ako cesty k súborom, ID a presné úryvky kódu zachovať doslovne, komprimovať len prózu. Anthropic odporúča optimalizovať najprv na recall (nestratiť žiadny dôležitý detail) a potom iteratívne na precision.

Kedy sa automatická optimalizácia oplatí a kedy nie

Praktické pravidlo: automatická optimalizácia sa oplatí, keď sa škálovanie stretne so zrelosťou evaluácií. Kto už udržiava evaluačnú sadu zo záznamov reálnych používateľov (user traces) a spracúva tisíce požiadaviek mesačne, vyťaží z automatickej optimalizácie najviac. Pri jednorazových alebo úzko vymedzených úlohách je náročnosť nastavenia väčšia než úžitok.

Konkrétny príklad: optimalizácia klasifikácie ticketov

Stredne veľká firma v regióne DACH prevádzkuje agenta zákazníckej podpory, ktorý zaraďuje prichádzajúce tickety do piatich kategórií a smeruje ich do správneho frontu. Ručne napísaná klasifikačná inštrukcia dosahuje na testovacej sade 150 reálnych označených ticketov presnosť 78 percent. Každé nesprávne nasmerovanie stojí čas na spracovanie.

Pseudokód nastavenia programatickej optimalizácie:

```

1. Deklarovať signatúru namiesto písania promptu

classify = Signatura("ticket_text -> kategoria, zdovodnenie")

2. Definovať metriku (povinné pri každej optimalizácii)

def metrika(priklad, predikcia):
return priklad.kategoria == predikcia.kategoria

3. Optimalizátor beží na trénovacej sade (napr. 100 ticketov)

optimalizovany_prompt = optimizer.compile(
program=classify,
trainset=tickety[:100],
metric=metrika
)

4. Validácia na odloženej testovacej sade (50 ticketov)

score = evaluate(optimalizovany_prompt, tickety[100:150], metrika)
```

Optimalizátor automaticky testuje rôzne formulácie inštrukcie a z trénovacích príkladov vyberá najvýpovednejšie few-shot príklady. Validuje sa výlučne na 50 odložených ticketoch, ktoré optimalizátor nikdy nevidel. Inak by sa meral overfitting namiesto skutočného zlepšenia. Ak sa presnosť posunie napríklad zo 78 na 86 percent, je to spoľahlivý a reprodukovateľný výsledok. Dôležité: zlepšenie sa počíta len na hold-out sade; lepšie číslo len na trénovacích dátach nemá žiadnu hodnotu.

Popri tom platia bežné pravidlá A/B testovania: v jednom teste meniť len jednu premennú, používať pevnú evaluačnú sadu s aspoň 50-200 úlohami a pri malých vzorkách výslovne uvádzať veľkosť efektu, a nie iba „lepšie alebo horšie“.

Hranice a riziká

Meta-prompting nefunguje samospádom. V praxi rozhodujú štyri hranice:

• Garbage-in pri cieli: Optimalizátor je len taký dobrý ako metrika. Slabá alebo skreslená metrika vedie k tomu, že systém optimalizuje na nesprávny cieľ a zosilňuje chyby. Pri metrikách typu LLM-as-Judge pribúdajú známe skreslenia: length bias, confidence bias, position bias a self-preference (modely uprednostňujú vlastné výstupy). Hodnotiace modely potrebujú explicitnú hodnotiacu rubriku a kalibráciu na aspoň 100 označených príkladoch.
• Overfitting na testovaciu sadu: Ak sa optimalizuje príliš agresívne na malú sadu, prompt zle generalizuje na produkčnú prevádzku. Hold-out validácia a production-trace shadowing sú povinné.
• Náklady reflexie: Verifikačné a reflexné slučky stoja typicky dvoj- až trojnásobok tokenov za 5-15 percentuálnych bodov zlepšenia kvality. Pri agentovi, ktorý schvaľuje hodnotnú objednávku, je návratnosť (ROI) zjavná; pri agentovi zákazníckeho servisu s maržou v centoch na interakciu treba presne počítať.
• Vysvetliteľnosť a compliance: Automaticky generované prompty sa ťažšie spätne sledujú. Čl. 12 EU AI Act vyžaduje, aby vysokorizikové systémy technicky umožňovali automatické zaznamenávanie udalostí počas celej doby ich životnosti. Po prijatí AI omnibusu platí táto povinnosť pre vysokorizikové systémy podľa prílohy III od 2. decembra 2027 a pre vysokorizikovú AI vo výrobkoch, na ktoré sa vzťahujú právne akty podľa prílohy I, od 2. augusta 2028 (časový harmonogram Európskej komisie). Verzie systémového promptu a katalógu nástrojov čl. 12 výslovne neuvádza. Ukladať obe tak, aby sa dali auditovať, je napriek tomu osvedčená prax, pretože inak sa zaznamenané výstupy nedajú priradiť k žiadnemu promptu. Prompt, ktorý sa neustále automaticky mení, sťažuje práve túto spätnú sledovateľnosť. Praktický vzor: optimalizované prompty verziovať a zaobchádzať s nimi ako s riadnymi vydaniami, nie ako s hotfixom.

K tomu sa pridáva ekonomická poznámka pre región DACH: nemčina vytvára v bežných tokenizéroch o 30-50 percent viac tokenov než angličtina. Optimalizácia, ktorá prompt skráti, sa preto pri nemeckojazyčných úlohách prejaví silnejšie. Prompt caching tento efekt ešte zosilňuje, pretože zľava na čítanie z cache (u Anthropicu približne 90 percent, stav v roku 2026) pôsobí na väčší počet tokenov.

Pre agentúry a vedenie B2B firiem

Meta-prompting je v roku 2026 menej módna téma a viac stupeň zrelosti: predpokladá, že svojich agentov už meriaš. Pre marketingové agentúry to konkrétne znamená: skôr než klientom sľúbiš automatickú optimalizáciu promptov, postav evaluačný základ s testovacou sadou z reálnych prípadov, validnou metrikou a A/B pipeline. Až potom prinesie DSPy alebo porovnateľný prístup reprodukovateľné výsledky namiesto folklóru. Pre vedenie B2B firiem znie odkaz: investuj do meracej infraštruktúry (evaluačné sady, tracing, logovanie v súlade s predpismi EÚ), ktorá je predpokladom. Kto škáluje a meria, znižuje automatickou optimalizáciou náklady na tokeny a preukázateľne zvyšuje úspešnosť. Kto prompty len háda, optimalizuje naslepo. V Blck Alpaca spájame práve tieto dve strany: spoľahlivú evaluačnú prax a automatizovanú optimalizáciu promptov, oboje v súlade s EU AI Act a GDPR.