← Все статьи

20 августа 2026

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

LLM умеют многое: генерировать тексты, анализировать документы, писать код. Но на практике их работа часто непредсказуема — сегодня модель даёт точный ответ, а завтра на тех же данных ошибается, пропускает ключевые шаги или придумывает факты. Для AI-инженеров это системная проблема. Возьмём автоматизацию документооборота: нужно классифицировать договоры, извлекать реквизиты, проверять стандарты. Но модель работает как лотерея — результат не поддаётся логике или меняется при повторном запуске с одинаковыми данными. Как встроить такой результат в бизнес-процесс? Особенно остро это ощущается с локальными моделями. Они проигрывают облачным гигантам в качестве, но выигрывают в приватности, скорости и цене. Для банков, госструктур и медицинских компаний локальные решения часто единственный вариант — поэтому стабильность LLМ становится ключевым требованием. Для решения этой задачи появился подход Schema-Guided Reasoning (SGR). Его придумал и активно развивает Ринат Абдуллин в своих материалах. Идея проста и эффективна: заставить модель мыслить не хаотично, а внутри заданной схемы. Схема служит логическим каркасом для каждого рассуждения. Обычный запрос лишь задаёт направление, а 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 с заданными полями, а не текст, который каждый раз приходится разбирать регулярками. Это критично, когда результат встроен в систему, от которой зависят другие процессы. Повышение точности Модель не может пропустить обязательные шаги рассуждения, поэтому по опыту точность растёт на 5–10 %. Исчезает неоднозначность, а результат становится воспроизводимым: при одинаковых данных вы получаете одинаковый ответ. Прозрачность рассуждений По промежуточным шагам легко понять, как модель пришла к выводу. Если SQL-запрос неверный, можно открыть поле strategy и сразу увидеть, где ошибка — в логике или синтаксисе. Это сокращает время на отладку. Возможность встраивать экспертные знания В схему можно заложить доменные правила. Например, в медицине — чёткий порядок: сбор симптомов → дифференциальная диагностика → итоговый вывод. Модель не пропустит важные этапы и сохранит последовательность мышления.

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

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 — это реальный рабочий инструмент. Рассмотрим примеры его использования: от простых учебных до сложных бизнес-кейсов. Главное — вместо хаотичного ответа модель начинает думать структурированно.

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

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

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 в комьюнити

В больших и сложных системах всегда остаётся пространство для оптимизации — особенно там, где предметная область только формируется. Так вокруг идеи упорядочить работу LLМ с помощью схем сплотилась группа первопроходцев из российского комьюнити: собственно, сам автор идеи Ринат Абдуллин, Валерий Ковальский, Артём Лысенко, Павел Zloy и другие участники AI-сообщества. Они начали экспериментировать с открытыми моделями, чтобы сделать их поведение более предсказуемым и результативным. Постепенно стали появляться библиотеки и открытые проекты, демонстрирующие, как схемы помогают агентам планировать действия, анализировать документы и проводить исследования. Эти наработки легли в основу более комплексного решения. Развитием идеи стал open-source проект SGR Deep Research. На этом этапе к проекту подключились команда R&D by red_mad_robot — она помогает в валидации решений, проверке бенчмарков и разработке компонентов. Сейчас SGR Deep Research объединяет сообщество разработчиков, исследователей и инженеров, которые вместе формируют новый стандарт для работы с LLМ-агентами.

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

SGR Deep Research предлагает пять различных типов агентов — от чистого SGR до гибридных решений. Каждый оптимизирован под определённый размер модели.
sgr type.png
Типы агентов SGR Deep Research Система построена на модульной архитектуре, где каждый компонент решает конкретную задачу. В основе лежит двухфазная модель: сначала агент рассуждает по схеме, затем выполняет действие. В состав системы входят инструменты: поиск в интернете, извлечение контента страниц, генерация планов исследований и создание отчётов с цитатами. Интеграция с Model Context Protocol (MСP) позволяет подключать внешние инструменты через стандартный протокол. Особенность системы — потоковые ответы с возможностью прерывания. Агент может остановиться, задать уточняющий вопрос и продолжить поиски после ответа. Система используется для маркетинговых исследований, анализа технологических трендов и конкурентной разведки. Например, при изучении рынка квантовых вычислений агент самостоятельно находит актуальные данные, анализирует их и формирует структурированный отчёт с источниками. Помимо разных типов агентов, у проекта продуманная архитектура, собранные бенчмарки и набор навыков, которыми можно снабжать агентов. Теперь любой разработчик может взять локальную модель на 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)
Сначала модель обязана вернуть структурированное решение — какое действие выбрать и почему. Схема гарантирует нужный формат. Затем код выполняет выбранное действие. Модель уже не мучается выбором — решение принято на этапе рассуждения.

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

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

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

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

Слишком жёсткие рамки могут навредить

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

Качество схемы = качество результата

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

Снижение производительности

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

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

Schema-Guided Reasoning — это попытка привнести инженерную дисциплину в мир GenAI. Вместо непредсказуемого «потока сознания» появляется управляемый и прозрачный процесс, где виден каждый шаг. Результату можно доверять, потому что его легко проверить на каждом этапе. SGR меняет сам подход к оценке работы модели: внимание переносится с финального ответа на ход рассуждений. Если ошибка возникает в середине процесса, сразу видно, где и почему — это даёт более честное представление о возможностях AI. Пока SGR остаётся инструментом для энтузиастов, но подход стремительно набирает популярность. Работа со схемами может стать таким же стандартом для reasoning-систем, каким модульное тестирование стало для классической разработки. Ближайшее будущее — за удобными фреймворками, сообществом, которое будет делиться готовыми схемами, и инструментами для их тестирования.
Оригинал статьи опубликован на Хабре
Schema-Guided Reasoning: как научить языковые модели последовательно рассуждать