Статья
Обычная генерация LLM выдаёт свободный текст. В программных системах его нужно разобрать парсером, валидировать схемой, обработать ошибки и предусмотреть деградацию при невалидном выходе. Каждая интеграция ИИ в продакшен-пайплайн превращается в инженерное обременение: код парсинга, retry-логика, мониторинг расхождений, фоллбэки.
Чем серьёзнее задача — финансовая, медицинская, юридическая, операционная, — тем выше цена ошибки парсинга. А чем сложнее prompt, тем выше шанс, что модель ответит в формате, который инженер не предусмотрел. Под нагрузкой это приводит к незаметным частичным сбоям в системе, которые сложно диагностировать.
Задача разбивается на последовательность обязательных блоков (полей схемы). Каждый блок задаёт, о чём именно модель должна сейчас «подумать» — и в каком формате выдать результат. Заполняя блоки по очереди, модель не может пропустить шаг рассуждения или забежать вперёд: структура форсирована не подсказкой в prompt, а самой формой выходного объекта.
Пример. Для задачи классификации обращения клиента схема может содержать поля: customer_intent (краткая формулировка намерения), key_phrases (массив цитат из обращения), category (enum из допустимых категорий), priority (число 1–5), recommended_action (enum из доступных действий). Модель заполняет их по порядку: сначала формулирует намерение, потом подтверждает его цитатами, потом классифицирует, потом приоритизирует, потом выбирает действие. Каждый следующий блок опирается на предыдущий.
Constrained decoding обеспечивает физическую невозможность нарушения. На каждом шаге генерации в кандидаты на следующий токен попадают только те, что валидны по схеме. Если поле — enum, модель выбирает только из его значений. Если поле — число, модель выдаёт только цифры. Если поле — массив, модель не может закрыть его раньше, чем сгенерирует хотя бы один элемент. Парсер на выходе не нужен: результат гарантированно валиден.
Prompt-инжиниринг — это просьба: «пожалуйста, верни ответ в JSON по такой-то схеме». Модель обычно понимает её, но без гарантий: на части запросов выдаст текст с лишними пояснениями, на части — пропустит обязательное поле, на части — добавит лишнее. Под нагрузкой инженер строит retry-логику и валидаторы поверх свободного выхода и платит за это компьютом и временем.
SGR работает уровнем ниже. Ограничение не выражено в тексте промпта — оно встроено в процедуру выбора токенов. Модель не «соглашается» соблюдать схему — она физически не может её нарушить. Это снимает целый класс граничных случаев и делает систему предсказуемой: один и тот же запрос на одной и той же модели даёт ответ той же формы независимо от нагрузки, температуры или формулировки prompt.
Другой эффект — экономия токенов. Модель не тратит выход на пояснения, маркеры «вот ответ», «надеюсь, помог», вступления и заключения. На задачах с миллионами вызовов в день это даёт измеримую экономию compute.
SGR — общая основа для всех наших продуктов.
Трёхстадийный пайплайн создания проекта (декомпозиция / описание / зависимости); каждая стадия валидируется через схему коллекции.
Продукт создаёт схемы SGR и иные правила constrained decoding и сам работает на основе SGR-генераций.
Извлечение структурированного знания из коммуникаций.
Создание навыка робота как спецификации в грамматике действий — подробнее в секции 05.
Schema-guided reasoning интересен не только для генерации текстовых артефактов. Если описать пространство возможных действий робота как грамматику с альтернативами (например, регулярное выражение верхнего уровня вида (move | grasp | place | wait)+ и подграмматики для каждой ветки с её аргументами), VLM с constrained decoding превращается из генератора текста в движок принятия решений по визуальному входу.
Каждое решение модели — это краткая последовательность токенов по грамматике (часто десятки или сотни); серия таких решений — навык. Грамматика кодирует пространство действий, понятных конкретному типу робота; few-shot примеры обучают модель выбирать правильно в типичных сценах; constrained decoding гарантирует, что выход всегда исполним выбранным телом.
На этом основан наш Skill Builder: навык — это спецификация (грамматика действий + few-shot + пороговые параметры), которую может исполнить любой совместимый робот через универсальную VLM. Не нужно обучать отдельную VLA-модель под каждый навык — достаточно описать грамматику и подготовить набор примеров. Подробности и измеренные показатели — в статье /tech/local-ai и на странице /segments/robotics.
Чтобы разобраться в SGR на практике, мы сделали бесплатный тренажёр SGR Exercises. В нём собраны живые задачи разной сложности — от классификации обращений до планирования и принятия решений по визуальной сцене. Для каждой задачи показано, как переходить от свободной формулировки к схеме, какие поля закладывать, в каком порядке и почему.
Тренажёр подходит для разработчиков, которые встраивают SGR в свои продукты, и для команд, оценивающих, насколько SDD-подход применим к их задачам.
Связанные ресурсы