Verziovanie prompt-šablón: Git-workflow pre prompty

Verziovanie promptov znamená zaobchádzať s prompt-šablónami ako s kódom: parametrizovať ich, oddeliť od aplikačnej logiky, verziovať v Gite, kontrolovať cez review, testovať evalmi proti regresii a v prípade potreby vrátiť rollbackom. Zmeny promptov sú tak dohľadateľné, reprodukovateľné a auditovateľné a nie sú náhodne roztrúsené v kóde. Pre produkčných agentov to v roku 2026 nie je nadštandard, ale základ toho, aby sa zmeny v správaní agenta nasadzovali kontrolovane.

• Prompty sú artefakty, nie doplnok. Patria do systému na správu verzií s diffom, review a rollbackom, nie inline do aplikačného kódu.
• Každú zmenu treba zmerať. Bez evaluačnej sady je zmena promptu nepreukázaná. Konsenzus praktikov v roku 2026: ak to nedokážeš zmerať, nestalo sa to.
• Verziovanie je aj ekonomika a compliance. Stabilné, verziované prompty zachovávajú prompt cache (Anthropic dáva podľa modelu 90 až 97,5 % zľavu na čítanie z cache, stav 2026) a poskytujú dohľadateľnosť, ktorú čl. 12 EU AI Act vyžaduje pri vysokorizikových systémoch.

Prečo treba s promptami zaobchádzať ako s kódom

Prechod od jedného šikovného promptu k viacstupňovej slučke agenta zásadne zmenil nároky na prompty. Prompt, ktorý riadi správanie produkčného agenta, spolurozhoduje o výbere nástrojov, formáte výstupu a správaní pri chybách. Nenápadná zmena jedného slova môže posunúť presnosť výberu nástrojov (tool selection accuracy) alebo rozbiť výstupnú schému, ktorú očakáva nadväzujúci systém.

Ladenie promptov metódou pokus-omyl, pri ktorom sa prompt upravuje priamo v kóde, preto už nie je udržateľné. Nahrádza ho verziovaná iterácia riadená evalmi. Kľúčové vlastnosti, ktoré na to prompt potrebuje:

• Oddelenie promptu a kódu. Prompt existuje ako samostatný artefakt (súbor, šablóna, záznam v registri), nie ako reťazcový literál v biznis logike. Vďaka tomu ho môžeš nezávisle verziovať, kontrolovať v review a vymieňať.
• Parametrizácia. Dynamické časti (dátum, ID používateľa, aktívny workflow, načítané dokumenty) sa vkladajú ako zástupné premenné, nie natvrdo do kódu. Anthropic navyše odporúča štruktúrovať sekcie XML tagmi alebo nadpismi v Markdowne. Prompty sa tak dajú lepšie porovnávať v diffe a model ich spoľahlivejšie parsuje.
• Verziovanie v Gite. Každá zmena vytvorí commit s autorom, časom a odôvodnením. Diffy presne ukazujú, čo sa zmenilo. Branche umožňujú paralelné experimentovanie.

Git-workflow pre prompty v detaile

Produktívny workflow pre prompty sleduje rovnaké vzory ako dobrý workflow pre kód, s jedným zásadným doplnkom: evaluačnou bránou (eval gate).

1. Feature branch. Variant promptu vzniká vo vlastnom branchi, nie priamo na main.
2. Review. Diff prechádza review v pull requeste. Revieweri kontrolujú formulácie, príklady výstupného formátu, klauzuly „when not to use“ v popisoch nástrojov a to, či bezpečnostné pravidlá zostávajú označené ako nevyjednateľné.
3. PR eval (merge gate). Smoke-test eval s 20–50 reprezentatívnymi úlohami beží automaticky a pri regresii zablokuje merge.
4. Pre-deploy eval (deploy gate). Pred nasadením beží celá evaluačná sada s 200–2 000 úlohami a pri regresii zablokuje rollout.
5. Detekcia driftu po nasadení. Nad produkčnými záznamami (traces) beží každý týždeň kontrola driftu.
6. Štvrťročná revalidácia. Samotná evaluačná sada sa každý štvrťrok kontroluje z hľadiska relevantnosti a rozširuje sa o novo objavené typy zlyhaní (failure modes).

Rollback funguje ako pri kóde: posledná stabilná verzia promptu je známy Git commit, na ktorý sa vrátiš. Práve tu sa ukazuje hodnota oddelenia: rollback je zmena verzie, nie deploy kódu.

Verziovanie a prompt caching: podceňovaná súvislosť

Hospodárnosť produkčných agentov v roku 2026 zásadne závisí od prompt cachingu. Podľa dokumentácie Anthropic stojí čítanie z cache podľa modelu 2,5 až 10 % štandardnej ceny za vstup (pri Sonnet 4.6 približne 0,30 $/M namiesto 3,00 $/M, stav 2026), zatiaľ čo zápis do 5-minútovej cache stojí 1,25×. Problém: hierarchia cache je Tools → System → Messages a každá zmena na vyššej úrovni invaliduje všetko za ňou. Podľa tej istej dokumentácie invaliduje celú cache už zmenená definícia nástroja (názov, popis, parametre). Pri Skills Anthropic varuje rovnako: kto zmení zoznam Skills v kontajneri, rozbije cache.

Dôsledok pre verziovanie je priamy: zmeny promptov a katalógu nástrojov sa zoskupujú a nasadzujú v plánovaných releasoch, zvyčajne mesačne, a nie ako nekontrolované hotfixy. Štúdia na arXiv z januára 2026 („Don't Break the Cache“) zmerala, že prompt caching pri dlhých agentových úlohách znižuje náklady na API o 41–80 % a zlepšuje time-to-first-token o 13–31 %. Spoľahlivejšie než cachovanie celého kontextu pritom funguje cielené riadenie cache blokov, napríklad keď dynamický obsah presunieš na koniec system promptu. Kto mení prompty bez verziovania a ad hoc, zaplatí za to zničenou cache hit rate.

Najznámejší anti-pattern z referenčných architektúr (blueprints) koncernov preto znie: „Skills/Capabilities bez verziovania: katastrofa invalidácie cache.“

Testovanie, regresia a A/B testy

Verziovanie bez testov je len účtovníctvo. Skutočnou pákou je postup riadený evalmi. Poznatok komunity praktikov v roku 2026: zmeny kontextu a promptov sa overujú evalmi, nie intuíciou.

Pre A/B testy platia jasné pravidlá:

• Jedna premenná na test. Variant system promptu A oproti B. Nemeň súčasne RAG-K, re-ranking a popis nástroja.
• Pevná evaluačná sada. Aspoň 50–200 úloh, reprezentatívnych pre produkčnú prevádzku.
• Štatistická porovnateľnosť. Pri menej ako 100 úlohách uvádzaj veľkosť efektu (effect size), nie len „lepšie/horšie“.
• Shadowing produkčnej prevádzky. Nový variant beží paralelne so starým a výstupy sa porovnávajú bez vplyvu na používateľov.

Rovnako dôležitá je úprimnosť voči folklóru: tipy ako „Si expert“, „Think step by step“ alebo „I'll tip you $200“ na dôsledných evaloch väčšinou nevykazujú merateľný efekt. Sú to hypotézy, nie pravdy. Ako verziované varianty ich treba otestovať proti evaluačnej sade, nie ich naslepo prevziať do produkčného promptu.

Tooling: správa promptov a registre (stav 2026)

Viacero frameworkov operacionalizuje verziovanie promptov, evaluačné datasety a sledovanie experimentov. V stacku relevantnom pre DACH:

Langfuse je v prostredí koncernov v DACH často defaultom, pretože hosting v EÚ a self-hosting spĺňajú požiadavky GDPR a suverenity. Pre stacky založené na modeloch Anthropic ponúka navyše vzor Skills natívnu formu modulárnych, verziovateľných stavebných blokov promptov: Skill je priečinok so súborom SKILL.md (YAML frontmatter s name a description, telo v Markdowne), ktorý môžeš verziovať v Gite ako každý iný súbor.

Praktický príklad: verziovaný release promptu

Predpokladajme, že agent zákazníckeho servisu (Sonnet 4.6, 4–5 nástrojov, RAG nad približne 10 000 dokumentmi) má robiť presnejšie rozhodnutia o eskalácii. Verziovaný workflow ako náčrt v pseudokóde:

```

prompts/support_agent/system.md (v1.4.0 -> v1.5.0)

version: 1.5.0
model: sonnet-4.6
owner: agent-platform

Identity

Si agent zákazníckej podpory pre {org_name}. ...

Behavioral

Eskaluj na človeka, ak je confidence < 0.7. ... # zmenené vo v1.5.0
```

Priebeh:

1. Branch prompt/escalation-threshold, diff ukazuje len zmenený riadok v sekcii Behavioral.
2. PR review + PR eval na 30 smoke-test úlohách: 0 regresií, merge povolený.
3. A/B oproti v1.4.0 na 150 skutočných záznamoch (traces) v shadowingu: miera správnych eskalácií 81 % → 88 % (+7 pp), falošné eskalácie bez zmeny.
4. Pre-deploy eval na 600 úlohách prešiel, release ako tag v1.5.0, zoskupený s mesačným releasom katalógu nástrojov, aby sa cache invalidovala len raz.
5. Ak by miera eskalácií v produkcii klesla, rollback je zmena verzie späť na predchodcu v1.5.0.

Každý beh zaznamenáva verziu promptu a verziu katalógu nástrojov. Pre vysokorizikové systémy AI vyžaduje čl. 12 EU AI Act automatické zaznamenávanie, ktoré umožňuje spätne dohľadať udalosti počas celej životnosti systému. Poskytovatelia musia tieto logy podľa čl. 19 uchovávať najmenej šesť mesiacov. Podľa nariadenia Digital Omnibus (EÚ) 2026/1744 to platí pre systémy z prílohy III od 2. decembra 2027 a pre produkty z prílohy I od 2. augusta 2028. Agent zákazníckeho servisu, ako je tento, spravidla nie je vysokorizikový systém. Logovať verziu promptu a katalógu nástrojov pri každom behu sa napriek tomu oplatí: každú odpoveď vieš priradiť ku konkrétnej konfigurácii a pri vysokorizikových systémoch je to logický spôsob, ako implementovať čl. 12.

Tímový workflow a compliance rámec v DACH

V praxi sa zodpovednosť rozdeľuje podľa stupňa zrelosti. V stredných firmách často stačí 0,25–1 FTE na jedného agenta, pričom prevláda údržba (aktualizácie evalov, katalóg nástrojov, obnova RAG indexu). V koncernoch s flotilou agentov má verziovanie promptov a kontextu na starosti tím agentovej platformy (3–10 FTE), ktorý používa eval pipeline v CI/CD ako blokáciu merge a priebežné A/B testovanie cez shadowing prevádzky.

V DACH formujú stratégiu verziovania tri rámcové podmienky: nemecká tokenizácia vytvára o 30–50 % viac tokenov na ekvivalentný obsah, čo ešte zvyšuje ROI cachovania stabilných, verziovaných promptov. GDPR vyžaduje disciplínu pri PII (logy s pseudonymami plus samostatná, vymazateľná mapovacia tabuľka). A pri vysokorizikových systémoch vyžaduje čl. 12 EU AI Act automatické zaznamenávanie. Zachytávanie verzie system promptu a katalógu nástrojov je na to logický spôsob implementácie.

Pre agentúry a B2B tímy

Pre AI agentúru je verziovanie promptov pákou, ktorá oddeľuje škálovanie od chaosu jednorazových riešení (snowflakes). Udržateľný vzor: základná šablóna agentúry (agency baseline), z ktorej klientske prompty dedia a prepisujú branding aj správanie. Vyhneš sa tak samostatným riešeniam pre každého klienta s exponenciálne rastúcou náročnosťou údržby. Rozhodujúca je izolácia klientov (multi-tenant) a oddelené cache kľúče pre každého klienta, aby nikdy nevznikli cache hity naprieč klientmi ani úniky PII, a k tomu spoločný evaluačný framework (napríklad self-hostovaný Langfuse) so samostatnými evaluačnými sadami pre každého klienta.

Pre B2B rozhodovateľov je hlavný odkaz jednoduchý: agent, ktorého prompty ležia neverziované v kóde, nie je pripravený na produkciu. Nedá sa auditovať, nedá sa bezpečne vrátiť rollbackom a nedá sa nákladovo efektívne cachovať. Kto plánuje verziovanie promptov ako architektúru od prvého dňa a nelepí ho dodatočne, má v rokoch 2026–2027 štrukturálnu výhodu v stabilite, nákladoch a compliance. Blck Alpaca stavia agentov presne na tomto základe: verziovaných, riadených evalmi a od začiatku v súlade s GDPR a EU AI Act.