Jak verzovat prompty, aby šla dohledat změna i vrátit předchozí verze

V pondělí kolegyně upraví zadání pro asistenta, který připravuje stručné odpovědi na servisní požadavky. Odpoledne už nový text kopírují další lidé. Ve středu někdo zjistí, že odpovědi přestaly obsahovat číslo případu. Které zadání se používá, odkdy a kde je jeho předchozí znění? Pokud existuje jen „aktuální prompt“ ve sdíleném dokumentu, tři jednoduché otázky mohou zabrat víc času než samotná oprava.

Verzování dává zadání jednoznačný název, ukládá každou schválenou podobu a eviduje, kdo ji pustil do práce. Potřebujete ještě záznam o tom, která verze je aktivní. Praktický postup níže ukazuje, jak to zavést ve sdílené složce i ve vlastní aplikaci a jak vrátit vadnou změnu, když se mezitím posunuly i podklady nebo formát výstupu.

Rozlište šablonu, konkrétní vstup a nasazení

Prompt může být jeden příkaz, který člověk kopíruje do chatu. Ve vlastní aplikaci to často bývá soubor několika instrukcí a šablon, do nichž se doplňují údaje o případu. Začněte tím, že si vedle sebe položíte text pravidel a jeden příklad vyplněného zadání. V šabloně může stát „zachovej identifikátor z pole číslo případu“, ve skutečném vstupu dostane asistent konkrétní číslo. Verze patří šabloně. Jednotlivé dotazy si vedou vlastní záznam o tom, se kterou verzí se zpracovaly.

Stejné zadání může být připravené, schválené i vypnuté. Schválená verze ve složce nemusí běžet v nástroji všech uživatelů. V ručním procesu mohou mít kolegové starou kopii v soukromých poznámkách a ve vlastní aplikaci může část provozu číst jinou konfiguraci. Evidujte aktivní verzi v místě, odkud se opravdu používá. Potřebujete se k ní dostat i v den, kdy autor zadání není v práci.

Rozdělení pomáhá s ochranou dat. Do historie šablony se hodí příklad s vymyšleným číslem případu. Kopie konkrétní konverzace se jménem, přílohou nebo obsahem interního nástroje má jiný účel a vyžaduje odpovídající zacházení. Pokud zjistíte, že se citlivá hodnota dostala do historie, pouhé odstranění z nejnovější verze předchozí revize nevyčistí. Řešte ji podle interního postupu a prověřte všechny kopie, které se v práci používají.

Zapište i proměnné a podmínky, bez nichž zadání nedává smysl

Představte si šablonu pro odpovědi na servisní požadavky. Proměnná číslo případu je povinná, technické podklady mohou někdy chybět a v takové situaci má asistent vytvořit žádost o doplnění. Jiný člověk si může návod vyložit tak, že má do místa chybějících podkladů vložit starý e-mail. Pokud je pravidlo jen v hlavě autora, reprodukce nefunguje. U každé důležité proměnné uveďte, kdo ji dodává a jak se má postup chovat při prázdné hodnotě.

K verzi patří také výstupní dohoda. V ruční práci to může být předmět a dva odstavce e-mailu. V automatizaci očekává další část systému pojmenovaná pole. Jakmile přejmenujete pole nebo změníte jeho význam, může rozhraní vypadat stejně, ale další zpracování selže. Verzi zadání spojte s verzí výstupu, pokud se na něj napojuje aplikace nebo import.

• Uložte identifikátor a popis účelu, například servisní odpověď a číslo verze. Stejnou značku nepoužívejte pro dva různé texty.
• Zapište původ šablony, seznam vstupů a postup pro prázdné či rozporné údaje. V ručním procesu přidejte jeden vyplněný modelový příklad.
• Připojte očekávanou podobu výstupu a seznam povolených akcí. U nástroje, který může skutečně měnit stav, odkažte na použitou konfiguraci oprávnění.
• Zaznamenejte výsledek ověření, odpovědného člověka a důvod úpravy. Při problému chcete vědět, kterou dřívější chybu nová verze řešila.
• Přidejte údaj o nasazení a známé závislosti, například verzi směrnice, vyhledávání nebo označení modelu.

Připojené nástroje mají vlastní pravidla. Pouhé uložení věty o tom, které akce smí agent provádět, neříká, co mu systém opravdu dovolil. Pokud měníte i přístupy, zaznamenejte změnu odděleně. Konkrétní otázky při volbě přístupů rozebírá náš průvodce oprávněními AI agenta.

Zvolte jedno místo, odkud se zadání bere

Tým, který kopíruje zadání do chatu ručně, může začít ve sdílené složce se čtením pro všechny, kdo ho používají, a omezeným právem upravovat schválené šablony. Na rozcestníku ukáže jednu platnou verzi a návod, jak ji použít. Staré verze zůstanou dohledatelné pro srovnání. Výhoda je malá režie. Nevýhoda spočívá v tom, že označení verze ve složce samo neodstraní kopie na pracovních plochách jednotlivců.

Ve vlastní aplikaci může být šablona součástí zdrojového kódu nebo samostatně spravovaným zdrojem. Git eviduje změny a značkou může označit konkrétní vydání. Uložená značka ovšem nepotvrzuje, že produkční služba opravdu načítá odpovídající soubor. Aplikace musí při běhu evidovat zvolený identifikátor. Pokud šablona žije mimo kód, může stejnému účelu sloužit registr promptů, který umožňuje vybrat konkrétní revizi. Dokumentace Google Cloud například popisuje uložení, načtení, seznam verzí a obnovení staršího znění. Praktické vlastnosti se u jednotlivých služeb liší.

Kde uchovávat verze zadání podle způsobu práce Na mobilu lze tabulku posouvat do stran.

I bez registru můžete verze používat důsledně. Podstatné je, aby každá schválená podoba zůstala dohledatelná a aby se při úpravách neposouval obsah za už vydaným označením. Ukazatel „aktivní“ může být pohyblivý, jeho cíl musí být konkrétní. Když někdo později otevře evidenci požadavku, potřebuje verzi použitou v daný okamžik. Samotná poznámka „použito nejnovější zadání“ mu starý stav neprozradí.

Změnu ověřte na stejných případech

K úpravě si napište jednu větu o očekávaném výsledku. Ve vzorovém servisu může být cílem přidat do návrhu žádost o doplnění chybějícího sériového čísla. Připravte proto dotaz, kde sériové číslo chybí, a dotaz, kde je dostupné. Ověřte, že nový text v prvním případě požádá o doplnění a ve druhém číslo správně převezme. Přidejte případ s nečitelným nebo zjevně rozporným údajem, pokud se v praxi vyskytuje.

1. Otevřete starou a novou verzi a zvýrazněte konkrétní rozdíl. Nechte zkontrolovat i změny, které editor provedl mimo původní záměr.
2. Vyberte případy, které mají reagovat jinak, a obvyklé případy, jejichž výstup má zůstat použitelný.
3. Zkoušejte ve shodném prostředí, pokud chcete připsat rozdíl zadání. Oddělte souběžné změny modelu, příloh nebo navazujícího zpracování.
4. Uložte verzi testu a poznamenejte podmínky, které návrh splnil. Připojte také rozhodnutí a osobu, která odpovídá za spuštění.
5. Na omezeném vzorku ověřte, že práce skutečně běží s vybranou verzí. Zkontrolujte i navazující formulář nebo záznam v evidenci.

Pro širší ověření použijte testovací sadu pro změny AI. Obsahuje očekávání pro běžné i obtížné případy. Ruční kontrola je důležitá i u návodu, který lidé používají v chatu. Když jednu verzi zkoušíte v nové konverzaci a druhou po půlhodinovém upřesňování, porovnáváte i vliv historie. Souvislost vysvětluje přehled kontextového okna a paměti AI.

Před návratem ověřte, co se změnilo kolem zadání

Při vadě potřebujete vědět, jestli lze předchozí verzi jednoduše znovu zapnout. V modelovém příkladu staré zadání vytvářelo předmět e-mailu a text jako jediný výstup. Nová verze má předmět a tělo ve dvou oddělených polích a mezitím se na ně napojila aplikace. Pouhé přepnutí textu zadání by poslalo do aplikace původní formát. K návratu je potřeba kompatibilní kombinace zadání a zpracování. Pokud taková kombinace není připravena, může být dočasně vhodné zpracovat požadavky ručně podle ověřeného postupu.

Po návratu zkontrolujte nový vstup a jeho výsledný stav. Ve sdílené složce upravte rozcestník a informujte lidi, kteří si šablonu už stáhli. V automatizaci ověřte, že se identifikátor správné verze zapisuje ke každému novému požadavku a že nečeká stará dávka s jiným nastavením. Rozlišujte běžící, čekající a dokončené požadavky. Přepnutí zadání obvykle změní budoucí zpracování. Dříve odeslanou zprávu nebo už vytvořený záznam je potřeba posoudit zvlášť.

Udržujte historii čitelnou. V Gitu se k odvolání změny v zaznamenané historii používá například nový commit vytvořený příkazem git revert. Oprava tím zůstává vysvětlitelná v posloupnosti změn. Ve sdíleném seznamu stačí nový řádek se záznamem, kdo a proč obnovil dřívější šablonu. Samotnou variantu, která způsobila problém, můžete označit jako pozastavenou. Později tak dohledáte konkrétní rozdíl a vyhnete se návratu stejné úpravy z lokální kopie.

Co zjistíte až z údajů o skutečném běhu

Když uživatel hlásí, že se změnil styl nebo zmizelo číslo případu, potřebujete nejdřív dohledat verzi opravdu použitou u konkrétního požadavku. Ve větším systému může existovat více pracovních prostředí, různá pravidla pro skupiny uživatelů nebo režim se záložním modelem. V ručním postupu často pomůže dohledat označení šablony přímo v pracovních poznámkách. Pokud ho nikdo nezapisuje, zjistíte nejvýš to, jaké znění se v danou dobu mělo používat.

Samotné zadání navíc není úplný záznam příčin. Zvažte čtyři situace. Někdo zkrátil instrukci o formátu. Poskytovatel změnil model za stejným viditelným názvem. Případ přišel s prázdným polem. Aplikace odřízla část podkladů kvůli limitu vstupu. Výsledek může být ve všech případech podobný, oprava pokaždé jiná. Proto má smysl uchovat vedle verze promptu i dostupný identifikátor modelu, verzi relevantních podkladů a výsledek technického zpracování. U služby, která přesnou revizi modelu neposkytuje, evidujte alespoň zobrazovaný režim a čas.

Tým někdy začne verze zavádět až po chybě. Může si zapsat dnešní obsah a datum, které bezpečně zná, a založit první řízené vydání. U nejasných starších kopií uveďte, odkud pocházejí a kdy byly nalezeny. Pak je můžete použít k rozboru rozdílu. Chybějící evidence z minulosti sama neukazuje, která kopie způsobila incident.

Kdy má být nová verze i při drobné opravě

Jednu zkušební větu můžete v pracovní kopii přepsat mnohokrát. Jakmile ale text používá další člověk nebo aplikace k rozhodnutí, počítejte s tím, že i drobná úprava může změnit odpověď. Oprava překlepu u interní poznámky má menší dopad než oprava záporu v instrukci. Stejné číslo verze přesto spojujte se stejným vydaným zněním. Rozsah kontroly podle dopadu klidně odstupňujte.

Dobře popsané zadání poznáte podle krátkého ověření. Člověk, který ho dnes neupravoval, najde platnou verzi, pochopí povinné vstupy a podle záznamu přepne na ověřenou variantu v testovacím prostředí. Když se zasekne u odkazu do osobního chatu nebo v souboru chybí vysvětlení, jakou verzi výsledku očekává aplikace, víte, kde začít s úpravou evidence.

Jak udržet pořádek při práci více lidí

Představte si dva souběžné návrhy. První mění podmínku, kdy má asistent požádat o přílohu. Druhý zkracuje výsledný e-mail. Oba vznikly ze stejného schváleného zadání. Kdyby oba autoři přepsali soubor nazvaný aktuální, poslední uložení může jednu úpravu smazat. Připravte proto obě změny odděleně, s odkazem na výchozí verzi. Po schválení první znovu zkontrolujte druhou proti novému stavu. Zkrácením e-mailu by například mohla zmizet právě nově přidaná žádost o přílohu.

U sdílené šablony bývá užitečné dát kolegům právo navrhovat změny formou komentáře nebo pracovní kopie. Platný text mění osoba odpovědná za vydání. Pokud se podmínky práce liší mezi dvěma týmy, zvažte dvě pojmenované šablony a ke každé uveďte účel. Jinak může jeden tým do společného zadání doplnit vlastní výjimku, která u druhého způsobí nesprávný návrh. Přitom ještě dává smysl sdílet některé části, třeba požadavek na jasné označení chybějícího údaje.

V automatizaci dávejte pozor na změny sdílených částí. Pokud několik šablon odkazuje na jeden společný text a aplikace si jej pokaždé bere v nejnovějším znění, změna tohoto textu může ovlivnit všechny současně. Záznam o vydání může obsahovat i verze těchto částí, případně přesný sestavený text šablony bez zákaznických údajů. Pak víte, zda se v konkrétním případě použila dřívější, nebo nová instrukce o formátu a zda stejnou změnu převzala i jiná automatizace.

Jednou za čas projděte místa, odkud lidé zadání kopírují. Když po aktualizaci hlavního souboru najdete starý pokyn v týmové příručce, nahraďte kopii odkazem na udržovanou šablonu. Důvod není estetický. Právě na takových místech se vrací už opravené chování, protože uživatel otevře první známý návod a nemá jak poznat, že už není platný.

Časté otázky

Potřebuji pro tři kolegy specializovaný registr?

Pro ruční práci obvykle stačí sdílená složka s historií a jediný jasný odkaz na používanou šablonu. Registr může usnadnit provoz, když aplikace vybírá revizi automaticky, šablon přibývá nebo potřebujete přidělovat různá oprávnění.

Je poznámka o změně povinná u každé pracovní kopie?

Rozlište pokusy od vydání. Pro schválenou podobu zapište důvod a rozsah změny. Průběžné experimenty můžete seskupit, pokud zůstane jasné, z čeho vydaná verze vznikla a co se skutečně ověřilo.

Jak zaznamenat rozdíl mezi zadáním a výstupem?

Označte verzi šablony při odeslání vstupu a připojte ji k výsledku jako samostatný údaj. Výsledný text pak můžete posoudit s vědomím, jaká instrukce ho vytvořila, i když je verze v rozcestníku už novější.

Mám po návratu spustit znovu všechny staré požadavky?

Nejprve rozdělte požadavky podle skutečného stavu a možných následků. U už odeslané zprávy může nové spuštění způsobit duplicitu. Určete, které položky potřebují opravu, kdo ji schválí a jak ji bezpečně provést.

Pomůže verze promptu obnovit přesně stejnou odpověď?

Pomůže znovu sestavit významnou část podmínek. Výsledek může ovlivnit model, nástroje, podklady, paměť i proměnlivost samotného generování. Pro přesnou historii konkrétní odpovědi potřebujete podle účelu uchovat příslušný výstup nebo schválený záznam.

Kdo má rozhodovat o vydání?

Dohodněte vlastníka pracovního postupu a způsob schvalování odpovídající dopadu. U návrhu interního textu může stačit druhý pár očí. Pokud další systém podle výstupu mění data, zkontrolujte i použité rozhraní a schvalování této akce.