Schema-Guided Reasoning: как научить языковые модели последовательно рассуждать

LLM умеют многое: генерировать тексты, анализировать документы, писать код. Но на практике их работа часто непредсказуема — сегодня модель даёт точный ответ, а завтра на тех же данных ошибается, пропускает ключевые шаги или придумывает факты.

Для AI-инженеров это системная проблема. Возьмём автоматизацию документооборота: нужно классифицировать договоры, извлекать реквизиты, проверять стандарты. Но модель работает как лотерея — результат не поддаётся логике ^[1] или меняется при повторном запуске с одинаковыми данными. Как встроить такой результат в бизнес-процесс?

Особенно остро это ощущается с локальными моделями. Они проигрывают облачным гигантам в качестве, но выигрывают в приватности, скорости и цене. Для банков, госструктур и медицинских компаний локальные решения часто единственный вариант — поэтому стабильность LLM становится ключевым требованием.

Для решения этой задачи появился подход Schema-Guided Reasoning (SGR). Его активно продвигает Ринат Абдуллин в материалах ^[2] по работе с LLM. Идея проста и эффективна: заставить модель мыслить не хаотично, а внутри заданной схемы. 

Схема служит логическим каркасом для каждого рассуждения. Обычный запрос лишь задаёт направление, а SGR выстраивает строгую структу��у, в которой модель обязана пройти все поля и пункты. Это не панацея, но SGR серьёзно снижает количество ошибок, делает процесс прозрачнее, а также позволяет тестировать отдельные компоненты рассуждений.

Когда логике нужны рельсы

В SGR схема — это структурированное описание того, как модель должна рассуждать. Обычно её задают через Pydantic-модели или JSON-схемы, где для каждого элемента указаны тип данных и описание.

from pydantic import BaseModel

from typing import List

class MathReasoning(BaseModel):

    problem: str

    steps: List[str] 

    final_answer: float

SGR использует структурированный вывод и ограниченное декодирование. Проще говоря, с помощью такого вывода модель может выдать ответ только в том виде, который заранее определили. Например, если в схеме указано, что final_answer должно быть числом, модель не напишет там «около сорока» или «сложно сказать». Она будет вынуждена предоставить конкретное число в нужном формате.

Схема не «зажимает» модель, а даёт ей понятный алгоритм. Это похоже на чек-лист доктора: сначала собрать симптомы и проверить показатели, потом выдвинуть гипотезы и назначить анализы и лишь затем ставит диагноз. Модель может думать как хочет, но в итоге обязана заполнить все поля.

Что это даёт на практике

Schema-Guided Reasoning быстро показывает эффект, когда попадает в реальные рабочие процессы. Структурированный вывод делает работу модели аккуратнее и предсказуемее — это отражается на нескольких ключевых аспектах.

Предсказуемость и стабильность
Ответы перестают быть лотереей. Модель возвращает JSON с заданными полями, а не текст, который каждый раз приходится разбирать регулярками. Это критично, когда результат встроен в систему, от которой зависят другие процессы.

Повышение точности.
Модель не может пропустить обязательные шаги рассуждения, поэтому по опыту ^[3] точность растёт на 5–10 %. Исчезает неоднозначность, а результат становится воспроизводимым: при одинаковых данных вы получаете одинаковый ответ.

Прозрачность рассуждений.
По промежуточным шагам легко понять, как модель пришла к выводу. Если SQL-запрос неверный, можно открыть поле strategy и сразу увидеть, где ошибка ^[4] — в логике или синтаксисе. Это сокращает время на отладку.

Возможность встраивать экспертные знания.
В схему можно заложить доменные правила. Например, в медицине — чёткий порядок: сбор симптомов → дифференциальная диагностика → итоговый вывод. Модель не пропустит важные этапы и сохранит последовательность мышления ^[5].

Три паттерна работы

SGR строится на паттернах — готовых схемах, которые организуют рассуждения модели. Люди тоже мыслят по шаблонам, и SGR предлагает привить тот же навык языковым моделям.

Обычно выделяют три основных подхода к структурированному мышлению: каскад, маршрутизация и цикл.

Каскад — последовательные шаги

Каскад подходит, когда задачу можно разбить на последовательные этапы, где каждый следующий шаг зависит от предыдущего. Например, при анализе текста: сначала краткое содержание, затем оценка качества и только потом итоговая рекомендация.

class TextAnalysis(BaseModel):
    summary: str
    quality_rating: int
    final_recommendation: str

Плюсы: модель движется пошагово, что помогает избежать ошибок и делает ход мысли понятным. Каждый этап можно проверить отдельно. Логика рассуждений зашита в структуру данных, которую легко контролировать.

Маршрутизация — выбор подхода под задачу

Маршрутизация нужна, когда заранее неизвестен тип входящей задачи. Например, нужно проанализировать юридические, финансовые или технические документы. Каждому типу нужен свой алгоритм разбора.

class DocumentAnalysis(BaseModel):

    document_type: str  # "legal", "financial", "technical"

    analysis_result: dict

Суть: модель сначала определяет категорию document_type, а затем запускает специализированную под этот тип цепочку действий. Вместо одного сложного алгоритма получается набор «маршрутов», каждый из которых заточен под свою задачу. Это делает систему гибкой.

Цикл — уточнение через повтор

Цикл полезен, когда результат нужно постепенно уточнять. Модель выдвигает гипотезу, затем сама её проверяет — ищет противоречия — и при необходимости пересматривает ответ. Это похоже на процесс редактирования: черновик, правки, готовый вариант.

class ComplianceAnalysis(BaseModel):

    hypothesis: str

    verification_questions: List[str]

    final_verdict: str

Цикл хорошо работает в неоднозначных ситуациях, где критична точность. Например, при проверке текста на соответствие регламенту. Модель строит гипотезу, задаёт себе уточняющие вопросы: «На какие пункты регламента это ссылается? Есть ли исключения?». При неубедительном ответе запускается новый виток. Правда, за это приходится платить — процесс занимает больше времени и ресурсов, поэтому его используют там, где качество важнее скорости ответов.

Важно помнить, что эти подходы не исключают друг друга, а часто работают вместе: маршрутизация определяет тип документа, каскад обрабатывает его по шагам, а цикл помогает улучшить результат.

Три кейса из практики

Schema-Guided Reasoning — это реальный рабочий инструмент. Рассмотрим примеры его использования: от простых учебных до сложных бизнес-кейсов. Главное — вместо хаотичного ответа модель начинает думать структурированно.

Обычная математика, но с системой

Модель, сталкиваясь с нетривиальной математикой ^[6], иногда пытается «угадать» решение по аналогии с тренировочными данными, а не выстраивать логическую цепь. Это ведёт к ошибкам.

Схема заставляет модель работать по плану:

# Чёткая структура рассуждений — никаких догадок

class MathReasoning(BaseModel):

    # 1. Сначала записываем саму задачу

    problem: str

    # 2. Затем показываем ход решения по шагам

    steps: List[str]

    # 3. И только в конце даём окончательный ответ

    final_answer: float

Простой пример:

problem = "15 + 27 = ?"

steps = ["15 + 20 = 35", "35 + 7 = 42"]

final_answer = 42.0

Сначала расписываем шаги, потом получаем ответ. Это как показать решение на уроке математики: нужно не просто написать число, а объяснить, как к нему пришли.

Когда нужно превратить вопрос в SQL

Если бизнес-аналитик просит «показать все заказы за последние 30 дней», модель, которая сразу генерирует SQL-код, часто допускает ошибки: пропускает условие или делает неправильный JOIN.

Проблему решает простая схема:

class SQLGeneration(BaseModel):

    # 1. Сначала объясняем, КАК будем решать задачу

    reasoning: str

    # 2. Затем формулируем конкретный план действий 

    strategy: str

    # 3. И только после этого пишем готовый код

    sql_query: str

Модель сначала продумывает стратегию: «Нужно взять таблицу orders, отфильтровать по дате, где date > current_date – 30 дней». Записывает этот план, и только потом пишет запрос. Такой подход повышает точность на 10–15%, потому что модель сначала думает, а потом пишет код. Как опытный разработчик, который не начинает программировать, не поняв задачу.

Разбираем документы по полочкам

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

Схема для классификации документов задаёт чёткие правила:

class DocumentClassification(BaseModel):

    # 1. Сначала анализируем содержание

    brief_summary: str

    # 2. Выявляем ключевых игроков и объекты

    key_entities: List[str]

    # 3. Определяем основные темы через ключевые слова

    keywords: List[str]

    # 4. И только после анализа делаем итоговый вывод о типе документа

    document_type: Literal["contract", "invoice", "letter", "report"]

Тип документа — только из списка: договор, счёт, письмо или отчёт. Модель обязана выделить ключевых участников, сделать краткое содержание и подобрать теги. Такой цифровой клерк, который работает строго по инструкции.

Развитие SGR в комьюнити

В больших и сложных системах всегда остаётся пространство для оптимизации — особенно там, где предметная область только формируется. Так вокруг идеи упорядочить работу LLM с помощью схем сплотилась группа первопроходцев из российского комьюнити: собственно, сам автор идеи Ринат Абдуллин ^[7], Валерий Ковальский ^[8], Артём Лысенко ^[9], Павел Zloy ^[10] и другие участники AI-сообщества.

Они начали экспериментировать с открытыми моделями, чтобы сделать их поведение ^[11] более предсказуемым и результативным. Постепенно стали появляться библиотеки и открытые проекты, демонстрирующие, как схемы помогают агентам планировать действия, анализировать документы и проводить исследования. Эти наработки легли в основу более комплексного решения.

Развитием идеи стал open-source проект SGR Deep Research ^[12]. На этом этапе к ^[13] проекту подключились команда R&D by red_mad_robot — она помогает в валидации решений, проверке бенчмарков и разработке компонентов. Сейчас SGR Deep Research объединяет сообщество разработчиков, исследователей и инженеров, которые вместе формируют новый стандарт для работы с LLM-агентами.

От идеи к production-системе

SGR Deep Research предлагает пять различных типов агентов — от чистого SGR до гибридных решений. Каждый оптимизирован под определённый размер модели.

Система построена на модульной архитектуре, где каждый компонент решает конкретную задачу. В основе лежит двухфазная модель: сначала агент рассуждает по схеме, затем выполняет действие. В состав системы входят инструменты: поиск в интернете, извлечение контента страниц, генерация планов исследований и создание отчётов с цитатами. Интеграция с Model Context Protocol (MCP) позволяет подключать внешние инструменты через стандартный протокол.

Особенность системы — потоковые ответы с возможностью прерывания. Агент может остановиться, задать уточняющий вопрос и продолжить поиски после ответа. Система используется для маркетинговых исследований, анализа технологических трендов и конкурентной разведки. Например, при изучении рынка квантовых вычислений агент самостоятельно находит актуальные данные, анализирует их и формирует структурированный отчёт с источниками.

Помимо разных типов агентов, у проекта продуманная архитектура, собранные бенчмарки и набор навыков, которыми можно снабжать агентов. Теперь любой разработчик может взять локальную модель на 8 млрд параметров, например, Mistral или Llama, обернуть её в SGR-агента и получить стабильный, повторяемый результат, который раньше был доступен только на уровне моделей GPT-4.

SGR меняет правила игры. Подход открывает путь к созданию недорогих, приватных и надёжных AI-ассистентов для бизнеса и исследований, не зависящих от закрытых API.

Результаты бенчмарка на датасете SimpleQA 

Это серьезный тест: более 4,3 тыс. вопросов из разных областей, от науки до политики. Система показала точность 86.08% — на уровне крупных облачных моделей.

• 3,7 тыс. правильных ответов из 4,3 тыс. вопросов 

• 232 млн токенов обработано

• 8 тыс. поисковых запросов выполнено 

• 170$ — общая стоимость тестирования 

Для сравнения: популярные поисковые системы показывают точность в диапазоне 70-85%. SGR Deep Research превзошёл большинство конкурентов, используя относительно небольшую модель gpt-4o-mini.

SGR против Function Calling: что выбрать

Function Calling (FC) отлично работает на больших облачных моделях от OpenAI или Anthropic. Но на локальных моделях менее 32B параметров ситуация меняется.

Реальные цифры по моделям Qwen3

• Qwen3-8B: всего 15% точности в Agentic Web Search

• Qwen3-4B: 2%

• Qwen3-1.7B: 4.5%

Даже при наличии нативной поддержки Function Calling маленькие модели не справляются с главным — понять, когда нужно вызвать инструмент. Проблема в том, что FC заставляет модель делать две сложные вещи одновременно: понять задачу и принять решение о действии. Для небольших моделей это слишком.

SGR разделяет процесс на два чётких этапа:

# Этап 1: Структурированный вывод (гарантированная надёжность)

reasoning = model.generate(format="json_schema")

# {"action": "search", "query": "BMW X6 prices", "reason": "need current data"}

# Этап 2: Детерминированное выполнение (модель не решает)

result = execute_plan(reasoning.actions)

Сначала модель обязана вернуть структурированное решение — какое действие выбрать и почему. Схема гарантирует нужный формат. Затем код выполняет выбранное действие. Модель уже не мучается выбором — решение принято на этапе рассуждения.

Наши рекомендации по выбору подхода

Практический вывод: не стоит пытаться заставить модели менее 32B параметров работать как GPT-4o в стиле ReAct с tool_mode=”auto”. Эффективнее задать им структурное мышление через SGR и детерминированное исполнение действий.

Недостатки SGR: с чем можно столкнуться

Schema-Guided Reasoning — инструмент мощный, но подходит не для всех задач. Есть несколько сложностей с его использованием.

Слишком жёсткие рамки могут навредить
Главный риск — перегнуть со структурой. Если схема излишне детализирована, модель будет буквально следовать инструкции, даже когда задача требует гибкости или творческого подхода.т Как метко отметил Ринат Абдуллин, SGR — это не «бесплатный прирост производительности». Да, точность может вырасти, но за этим стоит постоянный поиск баланса: где нужна строгость, а где — свобода манёвра.

Качество схемы = качество результата
Схема не учит модель новому — она лишь направляет мышление по заданному маршруту. Если в этом маршруте есть логическая дыра или пропущен важный шаг, модель честно воспроизведёт ошибку. Эффективность SGR напрямую зависит от экспертизы того, кто проектирует схему. Это полноценная инженерная задача, требующая времени и глубокого понимания предметной области.

Снижение производительности
Структурированный вывод и постоянная валидация через Pydantic — это дополнительные вычислительные затраты. Для GPT-4 в облаке это может быть незаметно, но при работе с локальными моделями сразу ощущается падение скорости ответа. Иногда приходится жертвовать скоростью ради точности.

Метод идеален для задач, где важны проверяемость, прозрачность и воспроизводимость. А вот для креативных задач, например, генерации идей для рекламы, жёсткие схемы, скорее, навредят. Однако SGR может отлично проявить себя в создании раскадровки для AI-мультфильма, где важна не только креативность, но и строгая логика последовательности кадров и сохранения контекста.

Будущее: новый стандарт разработки

Schema-Guided Reasoning — это попытка привнести инженерную дисциплину в мир GenAI. Вместо непредсказуемого «потока сознания» появляется управляемый и прозрачный процесс, где виден каждый шаг. Результату можно доверять, потому что его легко проверить на каждом этапе.

SGR меняет сам подход к оценке работы модели: внимание ^[14] переносится с финального ответа на ход рассуждений. Если ошибка возникает в середине процесса, сразу видно, где и почему — это даёт более честное представление о возможностях AI.

Пока SGR остаётся инструментом для энтузиастов, но подход стремительно набирает популярность. Работа со схемами может стать таким же стандартом для reasoning-систем, каким модульное тестирование стало для классической разработки. Ближайшее будущее — за удобными фреймворками, сообществом, которое будет делиться готовыми схемами, и инструментами для их тестирования.

---

Над материалом работали

Текст — Миша Мартьянов
Редактура — Игорь Решетников 
Иллюстрации — Петя Галицкий

---

Это блог red_mad_robot. Мы запускаем цифровые бизнесы и помогаем компаниям внедрять AI. Здесь наша команда разработки на собственных кейсах рассказывает о том, что происходит с AI сегодня, а стратегические аналитики подсказывают, что будет завтра. Мы бы подписались.

Наш Telegram-канал (там всё другое, а ещё есть анонсы мероприятий): t.me/redmadnews ^[15]