Перевод с разбором · для Вани

XML-теги в промптах

Зачем тебе это нужно

Для структурированных задач — парсинг заявок, формирование BOM (bill of materials, спецификация материалов), расчёт сметы — XML-теги прямо в промпте работают как самый надёжный способ разметки входа и выхода. Модели Claude (и в целом современные LLM) отлично их узнают, потому что видели в обучающих данных. Это не настоящий XML с валидацией, а текстовые маркеры — но эффект предсказуемый.

Зачем теги помогают

• Модель перестаёт путать разные куски промпта (инструкции, примеры, заявку).
• Просишь положить ответ в тег — легко вытащить регуляркой или парсером.
• Переменные подстановки чётко отделены от инструкций.

Пример: промпт для расчёта BOM

Ты составляешь BOM (спецификацию материалов) для деревянной лестницы.

<order>
  <floors>2</floors>
  <wood_type>oak</wood_type>
  <run_length_mm>2800</run_length_mm>
  <width_mm>900</width_mm>
  <type>marshevaya</type>
</order>

<rules>
- Ступеней: длина марша / 200 мм, округление вверх.
- Материалы указывай в метрах (для доски), штуках (для крепежа), литрах (для лака).
- Учитывай стандартный перерасход 15% на распил.
</rules>

Верни результат внутри тега <bom> строго в следующем JSON-виде:

<bom_schema>
{
  "items": [
    {"name": string, "unit": "m|pcs|l", "qty": number, "wood_type": string|null}
  ],
  "total_wood_meters": number,
  "total_estimated_cost_rub": number|null
}
</bom_schema>

Не выдумывай цены — если прайса нет, ставь total_estimated_cost_rub в null.

Что здесь происходит: заявка, правила и схема ответа — каждый в своём теге. Модель чётко видит, где вход, где правила, где шаблон выхода. Финальный BOM она завернёт в <bom>...</bom>.

Как вытащить ответ в Kotlin

val response = openAi.chatCompletion { ... }
val text = response.choices.first().message.content

val regex = Regex("<bom>(.*?)</bom>", RegexOption.DOT_MATCHES_ALL)
val bomJson = regex.find(text)?.groupValues?.get(1)?.trim()
    ?: error("BOM tag not found in model response")

val bom = Json.decodeFromString<Bom>(bomJson)

Что здесь происходит: регуляркой выдираем содержимое тега, парсим JSON в data class. Если LLM иногда сопровождает ответ прозой (особенно не-Anthropic модели), этот подход спасает — вытащим только содержимое <bom>.

Альтернатива: Structured Outputs

У OpenAI есть встроенная фича structured outputs — она гарантирует, что ответ будет валидным JSON по указанной схеме. У Anthropic аналогичное есть в API Claude. Для критичных пайплайнов это предпочтительнее, чем парсить XML-теги вручную. Подробнее — в статье про evals и полной документации.

Правила хорошего тона

• Имена тегов — единообразные во всех промптах (<order> всегда так, не <Order>).
• Вложенность — только там, где есть естественная иерархия.
• Не оборачивай всё подряд. Если промпт короткий и однородный — теги лишние.

Что это значит для твоей системы

• Для каждого LLM-эндпоинта (parse_order, generate_bom, review_estimate) — свой шаблон с тегами. Положи их в src/main/resources/prompts/.
• Входные данные (заявка, конфигурация пользователя, user_notes) — в отдельные теги внутри промпта. Подстановка через .replace("{{ORDER}}", orderXml).
• Ответ всегда проси завернуть в тег (<bom>, <parsed>, <review>). Парсить регуляркой — надёжнее, чем бороться с «почти JSON».
• Для критичных пайплайнов включай Structured Outputs на уровне API. Тогда JSON гарантированно валидный.

Полная версия — в docs/use-xml-tags.html.