Если ответ агента читает человек, формат — вопрос удобства. Если ответ едет дальше в CRM, в учётную систему или в платёжный реестр, формат становится вопросом целостности данных, и просьбой в тексте инструкции он не решается. Модель почти всегда возвращает то, что вы попросили, и именно слово «почти» стоит денег: на потоке в полторы тысячи записей в месяц один процент сбоев — это пятнадцать испорченных карточек, часть из которых обнаружится не сразу.
Задача формулируется просто: получить от модели структуру, которую программа примет без ручного вмешательства, и заранее решить, что делать в тех случаях, когда структура всё-таки нарушена. Второе важнее первого — сбой не устраняется полностью, он переводится из категории «испорченная запись в CRM» в категорию «повторный запрос, о котором никто не узнал».
Ниже — три способа зафиксировать формат и что каждый реально гарантирует, механика сбоя, расчёт стоимости брака, порядок обработки сбоя, готовые наборы полей для трёх типовых задач и правило отбора полей. Сквозной пример прежний для раздела: оптовая компания с интернет-магазином, 1 500 записей в месяц. Ставки модельные: инженер подрядчика 3 000 ₽/час, менеджер и методист внутри компании 900 ₽/час.
Три способа зафиксировать формат
Способы не альтернативные, а вложенные: третий не отменяет второго, второй не отменяет первого. Разница между ними в том, кто отвечает за соблюдение структуры — модель, платформа или ваш код.
| Способ | Где живёт | Что гарантирует | Чего не ловит |
|---|---|---|---|
| Описание в промпте с примером | Текст инструкции: перечень полей, типы, пример заполненного ответа | Ничего не гарантирует. На практике даёт 99 из 100 корректных ответов | Оставшийся процент: лишний текст вокруг структуры, пропущенное поле, число словами |
| Проверка по схеме на стороне кода | Код вокруг модели: разбор ответа, сверка со схемой, повтор при несоответствии | Структура на выходе корректна всегда — некорректный ответ просто не проходит дальше | Смысловые ошибки внутри правильных полей: не тот ИНН, перепутанные телефон и факс |
| Режим строгого вывода у модели | Платформа: ограничение генерации по схеме или вызов функции с описанными параметрами | Структура задаётся до генерации, доля сбоев формата падает почти до нуля | Те же смысловые ошибки. Плюс доступен не у всех моделей и не во всех версиях API |
Про третью строку стоит сказать отдельно. Вызов функции с описанной схемой параметров есть у основных российских платформ — GigaChat и Yandex AI Studio, — и его же обычно используют как способ получить предсказуемую структуру; у локальных моделей, развёрнутых через Ollama, ограничение вывода по схеме тоже поддерживается. Но конкретное поведение режима зависит от версии API, поэтому его проверяют на своей платформе до того, как закладывают в архитектуру, а не после. Механика самого вызова функций разобрана в отдельном материале про то, как модель нажимает кнопки в ваших системах.
Строгий вывод гарантирует форму, а не содержание: поле «сумма» будет числом, но это не значит, что число верное, а поле «ИНН» будет строкой из цифр, но не обязательно существующим ИНН. Правило то же, что и с любым другим требованием к агенту: то, что дороже неловкости, проверяется вне текста инструкции. Как раскладывать требования по уровням надёжности, разобрано в опорной статье раздела — что должно жить в промпте, а что в коде.
Почему просьба отвечать в JSON ломается на сотом ответе
Модель составляет ответ по одному фрагменту за раз, взвешивая всё, что ей дали: инструкцию, найденные документы и сообщение клиента. Требование формата — такое же правило, как остальные, и оно конкурирует с ними. Пока обращение типовое, формат держится. Ломается он на нетипичном входе: клиент прислал две заявки в одном письме, в тексте оказалась таблица, поле нечем заполнить, или сообщение само похоже на структуру и модель пытается её продолжить.
- Обёртка вокруг структуры. Модель добавляет вежливую фразу перед ответом или пояснение после. Формально данные есть, программа их не разбирает.
- Пропущенное поле вместо явной пустоты. Поле, которое нечем заполнить, просто исчезает. Это самая коварная разновидность: карточка создаётся, менеджер видит её заполненной и не знает, что телефона в ней нет.
- Число словами или с единицей измерения. Вместо суммы приходит «примерно 240 тысяч» или «240 000 ₽» строкой. Дальше это либо не разбирается, либо разбирается неправильно.
- Две записи вместо одной. В письме было два запроса, и модель вернула структуру с двумя объектами там, где код ожидает один.
Один процент — это модельная величина для несложной структуры и типового потока; на своих данных она снимается за вечер по журналу. Устойчиво другое: доля сбоев растёт вместе с числом полей и с разнородностью входящих сообщений, и почти не зависит от того, насколько настойчиво написано требование в инструкции.
Шесть записей из пятнадцати — та часть, ради которой всё и делается. Испорченная карточка, замеченная сразу, стоит двадцати минут; испорченная карточка, замеченная через две недели, стоит часа и одного неловкого звонка клиенту, а иногда и сорванной отгрузки. Разница между этими двумя ситуациями — не в качестве модели, а в наличии или отсутствии двадцати строк проверки в коде.
Что делать со сбоем: повтор, дефолт, человек
Проверка по схеме нужна не сама по себе, а ради заранее описанного поведения при сбое. Порядок из трёх ступеней закрывает практически все случаи, и важно, что переход между ступенями происходит автоматически, а не по звонку в поддержку.
- 1Ступень 1. Повторный запрос с указанием на ошибку
Ответ не прошёл схему — модель получает тот же вход и короткое дополнение: какое поле отсутствует или какого типа оказалось значение. Один повтор закрывает большинство сбоев формата. Двух повторов достаточно; после третьего повторять бессмысленно и дорого — каждый повтор это ещё один вызов модели и плюс одна-три секунды к ответу.
- 2Ступень 2. Явное значение «неизвестно» вместо пустоты
Если после повторов поле по-прежнему не заполнено, оно записывается как явно неизвестное, а не как пустая строка. Разница принципиальная: пустая строка выглядит как заполненное поле и не поднимает тревогу, явное «неизвестно» видно в списке и попадает в фильтр. Это дешёвая правка схемы, которая снимает половину историй про «карточка была заполнена, а телефона нет».
- 3Ступень 3. Передача человеку с сохранением исходника
Запись не создаётся, исходное сообщение уходит в очередь на ручной разбор вместе с тем, что модель успела извлечь. Это нормальный исход для 0,1–0,3 % потока, то есть для двух-пяти записей в месяц в нашем примере. Главное требование к ступени — счётчик: если доля ручного разбора вышла за один процент, дело не в формате, а в том, что на вход пошли документы другого типа.
Наборы полей для трёх типовых задач
Ниже — рабочие составы полей, с которых имеет смысл начинать. Они намеренно короткие: каждое лишнее поле оплачивается ростом доли сбоев, а не только счётом за модель.
- 1Карточка лида, 8 полей. Имя контакта, компания, телефон, канал обращения, товарная группа, объём запроса, срок потребности, требуемое действие. Каждое поле помечено как обязательное или явно допускающее значение «неизвестно». Как это ложится на реальный процесс продаж, разобрано в решении автозаполнение CRM.
- 2Резюме звонка, 6 полей. Дата и длительность, кто участвовал, суть запроса одной фразой, достигнутая договорённость, срок следующего шага, признак «требует руководителя». Последнее поле — булево, и оно важнее остальных: именно по нему строится очередь на просмотр, чтобы руководителю не приходилось читать все резюме подряд.
- 3Поля из счёта, 7 полей. Поставщик, ИНН, номер документа, дата, сумма, сумма НДС, срок оплаты. Здесь к схеме обязательно добавляются арифметические проверки в коде: сумма НДС не больше суммы, дата не из будущего, ИНН нужной длины. Модель их не заменяет — она заполняет поля, а не сверяет документ.
Лишние поля — это сбои, задержка и деньги
Соблазн описать схему «с запасом» возникает у всех: раз уж мы всё равно извлекаем данные, добавим ещё десяток полей на будущее. Цена такого запаса измеряется не только счётом за модель. Практический ориентир: восемь полей карточки лида проходят стабильно, шестнадцать дают модельно около 5 % сбоев вместо одного. В той же арифметике, что и в расчёте выше, это 75 битых записей в месяц вместо 15 и порядка 40 000 ₽ ручного разбора вместо 8 100 ₽.
Денежная сторона токенов при таких объёмах вторична. На потоке 1 500 ответов в месяц разница между компактной и раздутой структурой в счёте за модель измеряется сотнями рублей и сама по себе решения не меняет. Значимой она становится в двух случаях: когда поток идёт на десятки тысяч ответов в месяц и когда каждый сбой тянет за собой повторный запрос — тогда лишние поля оплачиваются дважды, деньгами и задержкой ответа.
Поле попадает в схему, только если у него есть читатель — человек, отчёт или другая система, которая его использует прямо сейчас. Поля, добавленные «на будущее», ухудшают надёжность сегодня в обмен на пользу, которая может не наступить. Если поле всё-таки нужно, но заполняется редко, — выносите его во вторую, отдельную схему, которая запускается только на тех обращениях, где оно уместно.
Когда строгий формат не нужен
Схема с проверкой — это 6–10 часов инженера на первую задачу и постоянная работа по её сопровождению при каждом изменении состава полей. Есть три ситуации, где эти часы не окупаются.
- Ответ читает человек и дальше никуда не едет. В диалоге с клиентом формат — это косметика: длина, порядок фраз, наличие ссылки на источник. Такие требования спокойно живут в блоке формата обычной инструкции, разобранном в материале про каркас из восьми блоков. Жёсткая схема здесь добавит сбоев и не добавит ничего полезного.
- Полей одно-два. Если агент возвращает только категорию обращения или только признак «требует руководителя», полная схема избыточна: достаточно закрытого перечня допустимых значений и проверки на вхождение в список. Это две строки кода и ноль сопровождения, а работает так же надёжно.
- Пилот, где состав полей ещё меняется. Пока каждую неделю добавляется новое поле, схему фиксировать рано — вы будете переписывать её вместе с проверками и контрольным набором. Правильный порядок обратный: стабилизировать состав полей на пилоте, затем зафиксировать схему и завести на неё контрольный набор.
Формат ответа перестаёт быть просьбой в момент, когда ответ уезжает в учётную систему. Дальше это либо проверка в коде, либо чья-то ручная работа каждый месяц.
