Суть
Схема не только проверяет результат — она направляет процесс. Модель заполняет поля в заданном порядке, и этот порядок есть неявная цепочка рассуждения: сначала промежуточные выводы, затем итоговое решение.
Зачем это нужно
Обычный промпт «проанализируй и дай вывод» даёт произвольный текст: нет структуры, каждый раз другой формат, нельзя обработать автоматически. Жёсткая схема рассуждения делает результат предсказуемым и сразу пригодным для пайплайна.
Как работает
- Поля схемы располагаются в порядке рассуждения. Пример для скрининга:
brief_summary→skill_match: int→experience_fit: int→decision: Literal["hire","reject","hold"]. Модель обязана пройти все шаги. - Каждый шаг типизирован и валидируется (Structured Output) — это отличает SGR от текстового рассуждения, где промежуточные шаги ничем не ограничены.
- Типовые паттерны SGR:
- Classification —
category: Literal[...],confidence: float,reasoning: str(тикеты, намерения, контент). - Extraction — вложенные модели на каждую сущность (Person, Company, Date, Amount): модель извлекает и структурирует одновременно.
- Planning — поля как этапы плана.
- Classification —
- Эффект (кейс HR-скрининга): время на кандидата 4 мин → 40 сек, доля падавших запросов 1 из 8 → 0 форматных ошибок, 300 резюме/день.
Когда схема мешает
Схема задаёт шаги рассуждения — и в этом же её ограничение: модель пройдёт ровно предусмотренные поля и не сделает шага, которого в схеме нет. На типовой задаче это выигрыш, потому что нужные шаги известны заранее. На нестандартной — потеря: правильный ход рассуждения оказывается не предусмотрен, и модель добросовестно заполняет поля, не относящиеся к сути.
Признак, что схема начала мешать: поля заполнены корректно, а вывод всё равно неверен, и при свободном рассуждении на том же входе модель приходит к правильному ответу. Второй признак — систематически пустые или формальные значения в части полей: они говорят, что схема описывает не эту задачу.
Практический компромисс — оставить в схеме свободное поле для рассуждения перед структурированными: модель сначала думает как хочет, потом раскладывает вывод по полям. Порядок здесь критичен по той же причине, по которой вердикт судьи ставят после разбора, а не до (Structured Output, порядок полей).
Поле решения должно идти после поля доказательств
Практический случай из OpenCodeReview делает это правило проверяемым. Reflector должен сначала заполнить массив analysis по каждому комментарию и только затем comment_ids, которые будут удалены. В комментарии к реализации зафиксировано наблюдение из сохранённых сессий: при обратном порядке модель могла признать категорию защищённой в анализе, но всё равно оставить её ID в списке удаления.
Отсюда более узкое правило проектирования схемы: не ставить необратимое решение раньше evidence, на котором оно должно стоять. Сначала наблюдение и проверка критерия, затем идентификатор действия. Это не гарантирует правильность вывода, но не позволяет схеме провоцировать преждевременный commit до собственного анализа модели.
Связано с
- Chain of Thought — SGR = структурная, типизированная форма CoT
- Structured Output — механизм, на котором держится SGR
- PydanticAI — где SGR описывается через
BaseModel - Generator Evaluator — filter-only evaluator, для которого порядок полей задаёт момент решения