Jak na XML tagy v promptech?

Vyvíjíte aplikace napojené na LLM? Zvyšte si kvalitu výstupu pomocí XML tagů. Jenže tento slibný přístup je provázený řadou mýtů. Jak XML tagy implementovat správně? Pojďme si to rozebrat. Co XML tagy v promptech skutečně dělají, kdy se vyplatí, kolik stojí a proč je celá debata o názvech tagů vlastně vedlejší.

Co tagy doopravdy dělají

První důležitá informace: XML tagy fungují u všech tří hlavních platforem (OpenAI, Anthropic, Google), u ostatních poskytovatelů API to musíte prověřit v dokumentaci. Všichni tři velcí poskytovatelé strukturované promptování s XML doporučují, přičemž XML je jediný formát, který explicitně podporují Anthropic, Google i OpenAI najednou. Anthropic ale mluví o speciálním trénování na XML, zatímco Google je v doporučení méně specifický ohledně formátu. My se ve článku budeme orientovat na využití v Anthropic API, bez větších potíží ale to samé rozchodíte v Gemini nebo OpenAI API.

Základní fakt zní střízlivě: XML tagy jsou oddělovač. Když prompt obsahuje instrukce, kontext, příklady a vstupní dokument v jednom bloku textu, model si musí hranice mezi nimi domyslet. Tagy tu práci přebírají — explicitně říkají, kde jedna část končí a druhá začíná. Dokumentace Anthropicu přínos popisuje třemi slovy: jasnost, přesnost, flexibilita. Tagy pomáhají Claudovi rozparsovat složité zadání bez záměny instrukcí za příklady, a vám umožňují upravovat jednotlivé části promptu bez přepisování celku.

Tady ale končí věcný popis a začíná mytologie. Virální návody tvrdí, že Claude „zná” konkrétní tagy — že <role> spouští identitní mód, <task> akční mód a <constraints> jsou tvrdá pravidla zapsaná do architektury. Anthropic říká opak. V dokumentaci výslovně stojí, že žádné kanonické „nejlepší” tagy, na které by byl Claude speciálně trénován, neexistují. Oficiální výukové materiály to formulují ještě ostřeji: mimo volání nástrojů nejsou žádné zázračné tagy maximalizující výkon. Doporučení zní pouze: pojmenujte tagy tak, aby odpovídaly obsahu, a používejte je konzistentně.

Rozdíl je podstatný. Model reaguje na přítomnost struktury, na jména tagů nikoli. <role> funguje stejně dobře jako <kdo_jsem> nebo <osoba>. Přínos vzniká z oddělení, z pojmenování jen potud, pokud vám pomáhá se v promptu vyznat a odkazovat na jeho části („použij smlouvu v tagu <contract>”). Kdo vám prodává seznam „správných” tagů jako tajné API Claudova mozku, prodává vám dekoraci…

Kdy struktura pomáhá — a kdy je to jedno

Teď k tomu, co po odečtení marketingu zůstává, protože zůstává toho dost. Struktura prokazatelně pomáhá ve třech situacích.

První situace je složitý vícesložkový prompt. Jakmile zadání kombinuje roli, kontext, úkol, omezení a formát výstupu, oddělení do bloků snižuje riziko, že model část přehlédne nebo si splete instrukci s příkladem. Druhá situace je práce s více dokumenty najednou — typicky právní analýzy nebo RAG systémy, kde potřebujete, aby model rozlišoval zdroje a vy jste mohli sledovat, odkud které tvrzení pochází. No a třetí situace je strojově zpracovávaný výstup, kde každá odchylka formátu rozbije navazující pipeline.

A teď odvrácená strana mince. U jednoduchých dotazů struktura nepřidá nic — obalovat „shrň mi tenhle článek” do pěti tagů je kargo kult. U uvažovacích úloh jsou důkazy smíšené: nezávislá srovnání ukazují, že novější modely si s prostým, přirozeně formulovaným textem vedou u vícekrokového uvažování srovnatelně, někdy i lépe, zatímco strukturované formáty vynikají u rigidních úloh typu počítání nebo zpětné vyhledávání. Praktici, kteří to měřili přímo na Claudovi, docházejí k závěru, který podepisuji: v praxi na formátu záleží méně, než se tvrdí, a jedinou jistotu vám dají evaly na vašich vlastních datech.

K tomu jeden náklad, o kterém se nemluví: tokeny. XML má otevírací i zavírací tagy, takže stejný obsah spotřebuje citelně víc vstupních tokenů než Markdown nebo prostý text — orientačně jde o rozdíl kolem patnácti procent ve prospěch Markdownu. U jednorázového promptu je to zanedbatelné. U agentní smyčky, která stejnou šablonu protáčí tisíckrát denně, už to je už určitá položka na faktuře.

Stavební bloky, které obstojí

Jak tedy na správné strukturování promptů v XML?

Základ je trojice role — kontext — úkol. Častá chyba promptů spočívá ve slití identity, prostředí a zadání do jedné věty, ze které si model sám vybírá, co je důležité:

<role>
Jsi senior právník specializovaný na obchodní smlouvy v českém právu.
</role>

<context>
Klient je malá česká firma, která podepisuje SaaS smlouvu s americkým dodavatelem.
Klient nemá právní oddělení a potřebuje srozumitelné vysvětlení.
</context>

<task>
Identifikuj tři největší rizika v přiložené smlouvě.
Pro každé riziko uveď: název, popis, doporučené řešení.
</task>

Funguje to, protože model dostal hranice a nemusí je odhadovat. Poctivá formulace přínosu zní: oddělení snižuje pravděpodobnost, že model identitu opustí nebo zamíchá kontext do instrukcí. Záruku nedává — model může uklouznout i tak, jen méně často.

Formát výstupu je nejpodceňovanější blok. Bez něj model rozhoduje o struktuře odpovědi sám a rozhoduje pokaždé trochu jinak, což vadí ve chvíli, kdy výstup parsujete softwarově:

<output_format>
{
  "rizika": [
    {
      "nazev": "string",
      "popis": "string (max 100 slov)",
      "doporuceni": "string"
    }
  ]
}
</output_format>

Tady je ale potřeba říct natvrdo: tag formát výrazně stabilizuje, garanci nedává. Kdo potřebuje stoprocentní shodu se schématem, má sáhnout po Structured Outputs, které Anthropic pro tento účel přímo nabízí a které shodu vynucují na úrovni API. Prompt je doporučení, Structured Outputs jsou vymáhání.

Pro více dokumentů fungují pojmenované bloky:

<doc id="smlouva">
[text smlouvy]
</doc>

<doc id="sablona">
[interní šablona firmy]
</doc>

Můžete se pak zeptat „posuzuj pouze podle smlouvy, je tato klauzule standardní?” a dostanete sledovatelné zdůvodnění místo slitiny obou zdrojů. Pro právní analýzy a RAG systémy je to z celého repertoáru nejužitečnější vzor.

Prioritizace omezení rozdělením na tvrdá a měkká pravidla dává modelu signál, co je absolutní limit a co preference:

<hard_rules>
- Nikdy neuváděj konkrétní právní rady, jen obecné informace
- Vždy upozorni na nutnost konzultace s právníkem
</hard_rules>

<soft_rules>
- Preferuj kratší věty
- Vyhýbej se latinským termínům, pokud není nutné
</soft_rules>

Persona se vzorkovými větami řeší notoricky těžký problém psaní v konkrétním hlasu. Abstraktní popis („buď stručný a přímý”) dává modelu koncept, ukázková věta dává rytmus:

<persona>
Píšeš jako technický manažer s 15 lety praxe. Styl:
<sample>Nasadili jsme to v pátek. V pondělí jsme řešili tři incidenty.</sample>
<sample>Architektura vypadala elegantně na papíře. V produkci to bylo jinak.</sample>
</persona>

A nakonec scratchpad — oddělení uvažování od odpovědi pomocí <thinking> a <answer>. U starších modelů to byl užitečný trik, jak vynutit přemýšlení před odpovědí a zároveň udržet čistý výstup. U současných modelů s nativním rozšířeným uvažováním je situace jiná: model přemýšlí ve vlastním vyhrazeném prostoru a ruční thinking tagy mohou být nadbytečné, případně se s nativním uvažováním tlouct. Než tenhle vzor nasadíte, ověřte si, jak se chová konkrétní model, se kterým pracujete.

Tagy jsou obálka, rozhoduje kontext

A teď to podstatné, co celé debatě o XML tagovýní chybí. Hádka o to, jestli psát <role> nebo <persona>, míjí jádro věci. Tagy jsou nádoby. O kvalitě výstupu rozhoduje, co do nich nalijete — a tady se hodí systematický pohled na to, z čeho se kontext agenta vůbec skládá.

Kontext pro jazykový model lze rozdělit do šesti typů. Instrukce: role, cíl a požadavky včetně kroků, konvencí, omezení a formátu odpovědi. Příklady: pozitivní i negativní ukázky chování a odpovědí, přičemž negativní příklady jsou podceňované — řeší problémy odhalené analýzou chyb. Znalosti: doménová fakta, dokumenty, strukturovaná data, popis systému, ve kterém agent pracuje. Paměť: krátkodobá v rámci session (historie zpráv, stav uvažování) a dlouhodobá napříč sessions (sémantická, epizodická, procedurální), uložená v databázi a připojovaná orchestrační vrstvou. Nástroje: jejich popisy fungují jako mikro-prompty pro uvažování modelu a spotřebovávají vstupní tokeny — což je mimochodem důvod, proč generické MCP servery často zklamou, jejich popisy neznají kontext vaší domény. A výsledky nástrojů: odpovědi, které orchestrační vrstva připojuje zpět do konverzace.

Z tabulky plyne praktický závěr: vy jako autor promptu reálně ovládáte první tři řádky, zbytek spravuje orchestrační vrstva. Hodnota vaší práce vzniká z toho, jak úplné a přesné instrukce, příklady a znalosti modelu dodáte. Tagy jen zajišťují, že se ty tři vrstvy nesmíchají.

K důležitosti kontextu existuje i zajímavá akademická stopa, kterou je ale potřeba citovat přesně. Studie Human Delegation Behavior in Human-AI Collaboration zjistila, že přístup ke kontextovým informacím o AI a o doméně úkolu významně zlepšuje výkon týmu člověk plus AI při delegování úloh. Pozor na rozsah toho zjištění: studie zkoumala lidi, kteří se rozhodují, kdy úkol předat AI — netvrdí nic o tom, že strategický kontext v promptu zlepšuje autonomii samotného modelu, jak se občas dezinterpretuje. Je to argument pro důležitost kontextu v celém systému člověk — AI, závěry o promptování z ní přímo nevyplývají.

Jak začít a jak si to ověřit

Praktický postup je krátký a začíná měřením, ne vírou. Vezměte svůj nejpoužívanější prompt a přidejte oddělení role, kontextu a úkolu. Pusťte obě verze — původní i tagovanou — desetkrát na různých vstupech a porovnejte konzistenci. Teprve když vidíte rozdíl, přidejte formát výstupu a měřte znovu. Pokud rozdíl nevidíte, máte cennou informaci zadarmo: vaše úloha je dost jednoduchá na to, aby struktura nehrála roli, a můžete si ušetřit tokeny.

Pro týmy je hlavní výhoda struktury modularita. Persona se dá upravit bez dotyku omezení, formát výstupu vyměnit bez přepisování celku. Každý blok je samostatná páka a taháte jednu najednou. V Claude Projects i přes API dává smysl uložit stabilní části jako systémový prompt a proměnné předávat přes placeholder:

<role>Senior code reviewer se zaměřením na bezpečnost</role>
<context>{{PROJEKT_KONTEXT}}</context>
<task>Zkontroluj přiložený kód. Hledej: SQL injection, XSS, neošetřené vstupy.</task>
<output_format>
- Nález: [název]
- Závažnost: [kritická/střední/nízká]
- Řádek: [číslo]
- Doporučení: [konkrétní fix]
</output_format>
<hard_rules>Každý nález musí mít konkrétní doporučení. Žádné obecné rady.</hard_rules>

Shrnuto: XML tagy jsou pro složité prompty u Claude, OpenAI i Gemini rozumný výchozí standard a všechny firmy je doporučují. Zázrak to ale není. Přínos závisí na úloze i modelu, struktura stojí tokeny a žádný tag negarantuje chování. Skutečná páka leží jinde: v úplnosti a přesnosti kontextu, který modelu dodáte. Tagy mu jen pomáhají se v něm vyznat.

A to je také důvod, proč se podívat na nástroje na měření kvality výstupu promptů, jako je Promptfoo (dnes patřící OpenAI), LangSmith nebo Weights & Biases Weave. Pro systematickou práci využívající prompty ve velkém jsou téměř nepostradatelné a zejména Promptfoo si rychle oblíbíte.