Когда языковая модель отвечает свободным текстом, а системе нужно получить из него цену, ИНН или статус заявки, начинается ручная работа: регулярные выражения, парсинг «на глазок», костыли под каждое изменение формулировки. Структурированный вывод переводит взаимодействие с моделью в инженерную плоскость — на выходе сразу получается объект с предсказуемыми полями, который можно валидировать и передавать дальше по конвейеру.

Почему свободный текст ломает автоматизацию

Свободный ответ LLM нестабилен по своей природе: одна и та же модель при temperature выше нуля сформулирует мысль по-разному в двух соседних запросах. Если downstream-система ждёт число, а получает «примерно 12 500 рублей, возможно, с НДС», интеграция падает. Особенно болезненно это в связке с 1С, CRM и ЭДО, где формат данных жёстко зафиксирован схемой обмена.

Второй источник проблем — скрытые ошибки. Регулярка может «вытащить» не то поле, и система молча запишет мусор в справочник. Валидация по схеме отсекает такие случаи до записи в базу.

Как работает структурированный вывод

Технически есть несколько уровней контроля. Самый простой — JSON-режим, когда модель обязывают вернуть валидный JSON, но без гарантии конкретных полей. Более строгий вариант — JSON Schema: вы описываете типы, обязательные поля, перечисления, и модель обязана им соответствовать.

Третий, самый надёжный, — constrained decoding. На этапе генерации движок (llama.cpp с GBNF-грамматиками, vLLM с guided decoding, Outlines, XGrammar, SGLang) физически запрещает токены, ломающие схему. Модель в принципе не может выдать невалидный JSON — это уже не уговор, а ограничение пространства поиска.

JSON Schema, tool calling и грамматики

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

На практике схемы описывают через Pydantic или Zod, а затем конвертируют в JSON Schema. Так один и тот же контракт используется и для промпта, и для валидации ответа, и для типизации в коде — расхождений между «что просили» и «что проверяем» не возникает.

Где это критично в российской практике

Типовые сценарии: извлечение реквизитов из счетов, накладных и договоров после OCR; классификация обращений в поддержку с простановкой категории, приоритета и ответственного отдела; разбор резюме в HR-контуре; формирование проводок и заявок на основе неструктурированных писем.

В проектах с приватными LLM на собственном железе структурированный вывод даёт дополнительный выигрыш: небольшие локальные модели (Qwen, Llama, GigaChat-совместимые) со строгой грамматикой работают точнее, чем те же модели в режиме свободного текста. Это позволяет держать данные внутри периметра и не зависеть от внешних API.

Практические шаги: как добиться стабильного JSON

1. Зафиксируйте схему заранее. Опишите поля, типы, enum-значения и обязательность. Не оставляйте «свободных» строковых полей там, где можно поставить перечисление.
2. Уберите необязательность. Каждое nullable-поле — потенциальная дыра. Лучше явное значение unknown, чем отсутствующий ключ.
3. Снизьте temperature до 0–0.2 для задач извлечения. Творчество здесь не нужно.
4. Валидируйте и ретрайте. Если ответ не прошёл схему — отправьте модели текст ошибки и попросите исправить. Один-два ретрая закрывают большинство сбоев.
5. Добавьте few-shot примеры именно в формате целевого JSON, а не в свободном тексте.
6. Ограничьте вложенность. Глубоко вложенные схемы повышают риск ошибок и расход токенов.
7. Логируйте сырые ответы — без этого невозможно понять, где именно теряется качество.

Типичные ошибки и ограничения

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

Ещё одна ошибка — гигантские схемы на 50+ полей в одном запросе. Лучше разбить задачу на несколько вызовов: сначала классификация документа, затем извлечение профильных полей. Так точность выше, а отладка проще.

Как мы можем помочь

Мы проектируем контуры с приватными LLM, где структурированный вывод встроен в pipeline: схема, constrained decoding, валидация, ретраи и логирование. Разрабатываем RAG и ИИ-агентов с интеграцией в 1С и CRM, разворачиваем модели на вашем контуре и настраиваем извлечение данных из документов и обращений. Обсудить проект