XML Tags Prompting

Суть в двух словах

XML нужен не потому, что модели "любят XML", а потому что теги помогают явно разделить слои запроса.

Типичный каркас:

<context>...</context>
<task>...</task>
<constraints>...</constraints>
<output_format>...</output_format>

<context>У нас B2B SaaS для бухгалтерии малого бизнеса.</context>
<task>Сформулируй 3 гипотезы для роста trial-to-paid conversion.</task>
<constraints>Не предлагай скидки как основной механизм. Смотри на onboarding и activation.</constraints>
<output_format>Для каждой гипотезы: hypothesis, why it may work, experiment.</output_format>

На практике XML-tags — это способ заставить prompt выглядеть как интерфейс между несколькими смысловыми слоями, а не как один большой текст.

Когда XML особенно полезен

XML становится особенно полезен там, где prompt уже перестаёт быть "ручным вопросом" и превращается в составной объект с несколькими независимыми слоями:

• policy;
• user request;
• retrieved context;
• tool results;
• output contract.

Если эти слои не разделять, модель начинает путать:

• что является инструкцией;
• что является данными;
• что является внешним результатом;
• что является желаемым форматом ответа.

XML vs Markdown

Markdown чаще выигрывает по читаемости для человека. XML чаще выигрывает по явной сегментации, особенно когда prompt собирается программно.

Практически граница выглядит так:

• Markdown лучше для human-authored prompts.
• XML лучше для programmatic prompt assembly.
• Schema/tool args лучше для machine-validated outputs.

То есть XML — это не конкурент JSON, а скорее промежуточный слой организации входа.

Хорошие практики

Практические правила:

• используйте 3-6 стабильных тегов, а не 20;
• называйте теги очевидно;
• не смешивайте в одном теге и данные, и инструкции;
• отдельно маркируйте retrieved content и output format.

Хороший XML prompt чаще всего похож на аккуратный контракт. Плохой — на pseudo-HTML, где теги размножаются только ради красоты.

Полезные шаблоны тегов

Базовый template

<role>...</role>
<task>...</task>
<context>...</context>
<constraints>...</constraints>
<output_format>...</output_format>

Agent pipeline template

<system_rules>...</system_rules>
<retrieved_context>...</retrieved_context>
<tool_result>...</tool_result>
<user_request>...</user_request>
<output_contract>...</output_contract>

Review template

<artifact>...</artifact>
<evaluation_rubric>...</evaluation_rubric>
<hard_constraints>...</hard_constraints>
<response_format>...</response_format>

Эти каркасы полезны не потому, что "они универсально магические", а потому что они дисциплинируют prompt design и уменьшают скрытое смешение ролей.

Anti-patterns

Плохие паттерны:

1. Вкладывать теги слишком глубоко без необходимости.
2. Дублировать одну и ту же инструкцию в context и constraints.
3. Помещать retrieved documents внутрь того же тега, где лежат policy rules.
4. Использовать нестандартные теги вроде <super_important_secret_context_block> вместо простых имён.
5. Пытаться решать XML-тегами задачу, где нужен уже schema-constrained output.

Отдельная проблема — отсутствие экранирования данных. Если вы программно подставляете в XML пользовательский текст, полезно думать не только о prompt clarity, но и о том, чтобы payload не ломал структуру шаблона.

Техническая реализация

Программная сборка prompt-а

def build_prompt(context, task, constraints, output_format):
    return f"""
<context>
{context}
</context>

<task>
{task}
</task>

<constraints>
{constraints}
</constraints>

<output_format>
{output_format}
</output_format>
""".strip()

Полезный паттерн для agents

<system_rules>...</system_rules>
<retrieved_context>...</retrieved_context>
<tool_result>...</tool_result>
<user_request>...</user_request>
<output_contract>...</output_contract>

Этот каркас помогает не смешивать:

• policy-layer;
• retrieved knowledge;
• tool outputs;
• саму задачу пользователя.

Минимальный safe builder

from html import escape

def xml_block(tag: str, value: str) -> str:
    return f"<{tag}>{escape(value)}</{tag}>"

Даже если модель не "парсит XML как браузер", такой builder полезен для:

• аккуратной сборки шаблонов;
• избежания поломанной структуры;
• более предсказуемого prompt assembly.

Когда переключаться с XML на schema

def choose_structure(input_complexity: str, output_needs_schema: bool) -> str:
    if output_needs_schema:
        return "schema"
    if input_complexity == "high":
        return "xml"
    return "markdown"

Это хорошая ментальная модель:

• XML в первую очередь структурирует вход;
• schema в первую очередь структурирует выход.