Этап 3 — Управление структурой ответа (критично для продакшена)

Если модель пишет «красивый текст», но без строгой структуры — интеграции ломаются.

Темы этапа

• Явные форматы (JSON, таблицы, списки)
• Схемы ответа
• Валидация вывода
• Принцип «ничего кроме JSON»

Почему структура важнее красоты

Для системных сценариев ответ модели — это вход для другого сервиса.
Нужен не «интересный текст», а машиночитаемый контракт.

Явные форматы

Задавай:

• типы полей,
• обязательные ключи,
• допустимые значения,
• поведение при отсутствии данных.

Схемы ответа

Практика:

• описать JSON schema (или хотя бы псевдосхему),
• запретить лишние поля,
• требовать валидный JSON без prose-обёртки.

Валидация

Никогда не доверяй ответу модели «как есть».
Пайплайн должен валидировать:

• синтаксис,
• структуру,
• бизнес-ограничения.

«Ничего кроме JSON»

В интеграционных задачах полезно жёстко указать:

• возвращать только JSON,
• без markdown,
• без комментариев,
• без дополнительного текста.

Prompting от контракта

Структурированный prompt должен начинаться с потребителя результата. Если ответ читает человек, может хватить заголовков и коротких абзацев. Если результат читает другой сервис, до генерации нужен контракт. В контракте должно быть сказано, какие поля существуют, что означает каждое поле, какие значения допустимы и что модель должна делать, если значение нельзя вывести безопасно.

Именно поэтому схема сильнее, чем одни примеры. Примеры показывают форму, но схема задаёт правило. В production самый безопасный поток выглядит так: prompt -> ответ модели -> parser -> validator -> бизнес-решение. Модель не должна быть единственным компонентом, который решает, что её собственный ответ валиден.

Главная теория этапа

• Модель должна быть ограничена чёткими рамками.
• Свободный текст — антипаттерн для автоматических интеграций.

Объяснение для новичка

Шаблон prompt-а нужен тогда, когда одну и ту же задачу будут запускать много раз: разные пользователи, разные документы, разные входные данные, но одинаковый ожидаемый результат. Без шаблона каждый разработчик пишет запрос по-своему, и ответы начинают отличаться по структуре, стилю и полноте. В продукте это быстро становится проблемой, потому что downstream-код не может надёжно разобрать свободный текст.

Простейший template состоит из постоянной части и переменных. Постоянная часть описывает задачу, правила и формат. Переменные подставляются из runtime: текст обращения, язык пользователя, список допустимых категорий, фрагмент документации. Такой prompt уже можно хранить как артефакт, ревьюить и тестировать.

Классифицируй обращение пользователя.
Допустимые категории: {{categories}}.
Текст обращения: {{message}}.

Верни JSON:
{
  "category": "one_of_categories",
  "confidence": 0.0,
  "reason": "short explanation"
}

Если модель должна вернуть JSON, одного слова «JSON» недостаточно. Нужно показать поля, типы и ограничения. Затем приложение должно проверить ответ schema validator-ом. Prompt просит модель соблюдать контракт, а backend проверяет, что контракт реально соблюдён. Это особенно важно, если результат идёт в БД, API, очередь сообщений или автоматическое действие.

Мини-сценарии из практики

• Интеграция падает на парсинге: модель добавляет пояснительный текст вокруг JSON.
• Ответ формально валиден, но не проходит бизнес-правила: схема не описывает обязательные ограничения.
• Разные эндпоинты получают разные формы ответа на одинаковую задачу: нет единого output contract.

Быстрые правила принятия решений

• Для интеграций всегда задавай строгий формат и требования к полям.
• Валидация должна быть двуступенчатой: синтаксис (schema) и бизнес-правила.
• Свободный текст используй только там, где он действительно нужен продукту.

Вопросы для самопроверки

1. Почему «валидный JSON» не всегда означает «готово к продакшену»?
2. Какие ограничения важно задавать прямо в схеме ответа?
3. Когда оправдан ответ в свободной форме вместо структурированного?