Meta-prompting: Keď si agenti píšu vlastné prompty
Meta-prompting označuje techniky, pri ktorých LLM generuje, hodnotí alebo zlepšuje vlastné prompty namiesto ich manuálnej formulácie. Namiesto pokusov a omylov optimalizuje eval-riadený proces inštrukcie, príklady a výstupné formáty programaticky voči testovacej sade. Frameworky ako DSPy to automatizujú tým, že s promptmi zaobchádzajú ako s kompilovateľným kódom.
Key Takeaways
- ✓Meta-prompting presúva optimalizáciu promptov od ľudskej intuície k merateľným, automatizovaným eval-slučkám - LLM zlepšuje vlastné inštrukcie voči fixnej testovacej sade.
- ✓DSPy zaobchádza s promptmi ako s kompilovateľnými programami: definuješ signatúry vstupu/výstupu a metriku, optimizer automaticky hľadá lepšie prompty a few-shot príklady.
- ✓Tento prístup sa oplatí pri škálovaní a eval-zrelosti: kto už meria 50-200 reprezentatívnych úloh a beží tisíce callov mesačne, získava z automatickej optimalizácie najväčšiu páku.
- ✓Empiricky sa ukazuje: mnohé populárne tipy na prompty (rola experta, sľub prepitného) na rigoróznych evaloch neprinášajú žiadny merateľný efekt - bez merania je optimalizácia folklór.
- ✓Kompresia promptov a compaction výrazne znižujú náklady na tokeny, no riskujú stratu detailov; kritické artefakty (ID, cesty, code-snippety) by sa mali zachovať verbatim.
- ✓Hranica: Automatická optimalizácia potrebuje dobrú testovaciu sadu a validnú metriku - bez čistých evalov systém optimalizuje na nesprávny cieľ a zosilňuje chyby.
Meta-prompting označuje techniky, pri ktorých jazykový model generuje, hodnotí alebo zlepšuje vlastné prompty namiesto toho, aby ich človek formuloval manuálne. Namiesto pokusov a omylov optimalizuje eval-riadený proces inštrukcie, few-shot príklady a výstupné formáty programaticky voči 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.
Tento pojem zhŕňa viacero príbuzných praktík: LLM, ktorý navrhne lepší prompt pre úlohu; optimalizačnú slučku, ktorá testuje varianty promptov voči ukážkovým dátam; a kompresiu promptov, ktorá zmenší dlhý kontext s minimálnou stratou. Spoločné im je to, že konštrukcia promptu sa z manuálneho remesla mení na automatizovaný, merateľný proces.
- Čo to je: LLM zlepšuje alebo generuje vlastné prompty - manuálne riadený prompt engineering je nahradený automatickou, eval-validovanou optimalizáciou.
- Kedy je to zmysluplné: Pri škálovaní (mnoho callov), pri existujúcej eval-sade a validnej metrike, a 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 manuálne 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 vytváranie jediného, šikovného promptu - umenie sformulovať prompt tak, aby model dodal požadovanú odpoveď. So vzostupom agentických systémov to už nestačí: prompty musia fungovať stabilne naprieč mnohými inferenčnými ťahmi, interagovať s nástrojmi, pamäťou a meniacim sa kontextom.
Tu prichádza na rad meta-prompting. Inžiniersky konsenzus roku 2026 je jednoznačný: ladenie promptov metódou pokusov a omylov je nahradené eval-riadenými A/B testami. Namiesto hádania, či je nejaká formulácia lepšia, sa to meria voči fixnej testovacej sade. A akonáhle sa meria, ďalší krok je nablízku - automatizovať samotné hľadanie lepších promptov.
Jedno z najúprimnejších zistení rokov 2024-2026: Mnohé populárne tipy na prompt engineering vykazujú na rigoróznych evaloch minimálne alebo žiadne zlepšenie. „Si expert" nemá na moderných modeloch väčšinou žiadny merateľný efekt. „Think step by step" je na reasoning modeloch už predvolené správanie a manuálne č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 slúžia ako hypotézy, no musia sa overiť voči eval-sade. Práve táto disciplína robí automatickú optimalizáciu vôbec zmysluplnou - pretože optimizer bez validnej metriky optimalizuje naprázdno.
Tri formy meta-promptingu
1. Samogenerované a samozlepšované prompty
V najjednoduchšom prípade silnejší model vygeneruje prompt pre slabší model alebo pre seba samého. Príbuzné sú reflexné slučky: model vygeneruje odpoveď, kritizuje ju a reviduje (vzor „Reflect-and-Revise", resp. Reflexion). Sem patrí aj vzor LLM-as-Judge - samostatný judge-call hodnotí výstup voči rubriku. Tieto stavebné prvky sa dajú zreťaziť: jeden model napíše prompt, druhý vyhodnotí výsledok, prvý dolaďuje.
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. Optimizer potom automaticky prehľadáva priestor možných inštrukcií a few-shot príkladov a skompiluje prompt, ktorý maximalizuje metriku na testovacej sade. Človek už nepíše znenie promptu, ale špecifikáciu a metriku.
3. Kompresia promptov
Tretia forma adresuje náklady na tokeny a context rot. Compaction je štruktúrovaný variant: pri dosiahnutí prahovej hodnoty (typicky 70-85 percent nominálnej kapacity) skomprimuje sumarizačný krok doterajšiu konverzáciu do kompaktnej reprezentácie. Anthropic pre Claude Code popisuje, že pritom zostávajú zachované architektonické rozhodnutia, nevyriešené bugy a implementačné detaily, zatiaľ čo redundantné výstupy nástrojov sa zahodia. Inžinierske pravidlo: kritické artefakty - cesty k súborom, ID, presné code-snippety - zachovať verbatim, komprimovať len prózu. Anthropic odporúča optimalizovať najprv na recall (nestratiť žiadny dôležitý detail), potom iteratívne na precision.
Kedy sa automatická optimalizácia oplatí - a kedy nie
Kritérium | Manuálny, eval-validovaný prompting | Programatická optimalizácia (napr. DSPy) |
|---|---|---|
Objem | Málo až stredne callov | Vysoký objem, mnoho callov/mesiac |
Eval-zrelosť | Malá smoke-test sada postačuje | Potrebná testovacia sada s 50-200+ reprezentatívnymi úlohami |
Metrika | Kvalitatívna, hodnotená človekom | Kvantitatívna, automaticky vypočítateľná (povinnosť) |
Reprodukovateľnosť | Stredná | Vysoká - prompt sa „skompiluje" |
Nastavovací výdavok | Nízky | Vyšší (signatúry, metrika, pipeline) |
Vysvetliteľnosť | Vysoká (človek pozná každú vetu) | Nižšia (prompt sa generuje strojovo) |
Najlepší use-case | Jednotlivé, špecifické úlohy | Škálujúce pipeline s jasným cieľom |
Pravidlo: Automatická optimalizácia sa oplatí, keď sa stretne škálovanie a eval-zrelosť. Kto už udržiava eval-sadu z reálnych user-traces a vedie tisíce požiadaviek mesačne, získava najväčšiu páku. Pri jednorazových alebo úzko vymedzených úlohách je nastavovací výdavok väčší než úžitok.
Konkrétny príklad: optimalizácia klasifikácie ticketov
Stredne veľká firma v regióne DACH prevádzkuje support agenta, ktorý prichádzajúce tickety zaraďuje do piatich kategórií a smeruje ich do správnej queue. Manuálne napísaná klasifikačná inštrukcia dosahuje na testovacej sade 150 reálnych, oštítkovaných ticketov presnosť 78 percent. Každé chybné nasmerovanie stojí čas na spracovanie.
Pseudokód programatického optimalizačného setupu:
```
1. Deklarovať signatúru namiesto písania promptu
classify = Signatura("ticket_text -> kategoria, zdovodnenie")
2. Definovať metriku (povinnosť pre každú optimalizáciu)
def metrika(priklad, predikcia):
return priklad.kategoria == predikcia.kategoria
3. Optimizer beží voči trénovacej sade (napr. 100 ticketov)
optimalizovany_prompt = optimizer.compile(
program=classify,
trainset=tickety[:100],
metric=metrika
)
4. Validácia na zadržanej testovacej sade (50 ticketov)
score = evaluate(optimalizovany_prompt, tickety[100:150], metrika)
```
Optimizer automaticky testuje rôzne formulácie inštrukcií a z trénovacích príkladov vyberá najvýrečnejšie few-shot príklady. Validuje sa výlučne na 50 zadržaných ticketoch, ktoré optimizer nikdy nevidel - inak sa meria overfitting namiesto skutočného zlepšenia. Ak sa presnosť posunie napríklad zo 78 na 86 percent, je to spoľahlivý, 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 je bezcenné.
Sprievodne platia bežné A/B disciplíny: meniť len jednu premennú na test, používať fixnú eval-sadu s minimálne 50-200 úlohami a pri malých množstvách explicitne reportovať veľkosť efektu, nielen „lepšie alebo horšie".
Hranice a riziká
Meta-prompting nie je samospád. V praxi sú rozhodujúce štyri hranice:
- Garbage-in pri cieli: Optimizer 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 pristupujú známe skreslenia - length bias, confidence bias, position bias a self-preference (modely uprednostňujú vlastné výstupy). Judgeovia potrebujú explicitný rubrik a kalibráciu na minimálne 100 oštítkovaných príkladoch.
- Overfitting na testovaciu sadu: Ak sa optimalizuje príliš tvrdo na malú sadu, prompt zle generalizuje na produkčnú prevádzku. Hold-out validácia a production-trace shadowing sú povinnosťou.
- Náklady reflexie: Verifikačné a reflexné slučky stoja typicky dvoj- až trojnásobok tokenov za 5-15 percentuálnych bodov nárastu kvality. Pri agentovi, ktorý uvoľní hodnotnú objednávku, je to triviálny ROI; pri customer-service agentovi s centovými maržami na interakciu sa musí presne počítať.
- Vysvetliteľnosť a compliance: Automaticky generované prompty sa ťažšie sledujú. Pre vysokorizikové systémy budú logovacie povinnosti podľa EU AI Act čl. 12 plne aplikovateľné od 2. augusta 2026 - verzia systémového promptu a verzia tool-katalógu musia byť perzistované auditovateľne. Neustále automaticky mutujúci prompt sťažuje práve túto traceabilitu. Praktický vzor: optimalizované prompty verzionovať a zaobchádzať s nimi ako s releasmi, nie ako s hotfixom.
K tomu pristupuje hospodárska poznámka pre región DACH: Nemčina produkuje v bežných tokenizéroch o 30-50 percent viac tokenov než angličtina. Optimalizácia, ktorá robí prompt stručnejším, sa teda pri nemeckojazyčných workloadoch prejaví silnejšie - a navyše ju zosilňuje prompt caching, keďže read-discount (u Anthropicu okolo 90 percent, stav 2026) pôsobí na väčší počet tokenov.
Pre agentúry a B2B rozhodovateľov
Meta-prompting je v roku 2026 menej hype-téma než stupeň zrelosti: predpokladá, že svojich agentov už meriate. Pre marketingové agentúry to konkrétne znamená - skôr než zákazníkom sľúbite automatickú optimalizáciu promptov, postavte eval-základ: testovaciu sadu z reálnych prípadov, validnú metriku, A/B pipeline. Až potom DSPy alebo porovnateľný prístup dodáva reprodukovateľnú pridanú hodnotu namiesto folklóru. Pre B2B rozhodovateľov je odkaz: Investujte do meracej infraštruktúry (eval-sady, tracing, EU-konformné logovanie) ako predpokladu. Kto škáluje a meria, znižuje s automatickou optimalizáciou náklady na tokeny a preukázateľne zvyšuje úspešnosť - kto len háda prompty, optimalizuje naslepo. V Blck Alpaca spájame práve tieto dve stránky: spoľahlivú eval-prax a automatizovanú optimalizáciu promptov, zasadenú do DACH-konformnej compliance.
Často kladené otázky
Aký je rozdiel medzi meta-promptingom a bežným prompt engineeringom?
Čo je DSPy a na čo sa používa?
Kedy sa oplatí automatická optimalizácia promptov?
Aké riziká má meta-prompting?
Je kompresia promptov to isté ako meta-prompting?
Ísť hlbšie?
Získajte nové analýzy priamo do schránky – alebo sa pozrite, ako tieto poznatky nasadzujeme pre firmy.