Структурированный вывод — это ответ модели в заранее оговорённой форме: набор именованных полей с известными типами, который ваша программа может прочитать без разбора текста. Нужен он ровно там, где ответ адресован не человеку, а системе: карточка сделки в CRM, тема обращения, реквизиты из счёта, статус заявки. Пока ответ читает человек, свободный текст удобен. Как только его читает код, свободный текст превращается в постоянный источник сбоев — причём тихих.
Механика поломки простая. Модель не «нарушает договорённость» — она продолжает текст наиболее правдоподобным образом, и правдоподобным ей иногда кажется добавить перед ответом вежливое «Конечно, вот результат:», обернуть его в оформление, переименовать поле на синоним или вернуть число словами. Для человека это незаметная мелочь. Для программы, которая ожидает шесть полей и получает семь, — отказ разбора либо, что хуже, успешный разбор с неверным значением.
Дальше — три способа получить строгий формат, обязательный минимум проверок и модельный расчёт по состоянию на сентябрь 2026 года. Сценарий в примере: автозаполнение карточек в CRM по расшифровкам обращений, 2 400 карточек в месяц, шесть полей в каждой. Ставки: инженер-подрядчик — 3 000 ₽/час, полная стоимость часа менеджера по продажам — 900 ₽.
Три способа по возрастанию надёжности
| Способ | Как устроен | Что гарантирует | Чего стоит |
|---|---|---|---|
| 1. Просьба в инструкции | В промте написано: «ответь только объектом с полями такими-то, без пояснений» | Ничего. Работает большую часть времени и молча ломается на нетипичных входах | Бесплатно, входит в текст промта |
| 2. Схема формата на стороне провайдера | Провайдеру передаётся описание структуры ответа, и он возвращает ответ этой формы | Форму: набор полей и их типы. Содержание полей — не гарантирует | 4–6 часов настройки; поддерживается не всеми провайдерами и не во всех режимах |
| 3. Проверка на приёме и повторный запрос | Ваш код разбирает ответ, сверяет со схемой и при несоответствии запрашивает заново | Что в систему не попадёт запись, не прошедшая проверку | 16 часов инженера — 48 000 ₽ разово |
Способы не заменяют друг друга, а складываются. Правильная сборка — все три сразу: инструкция задаёт намерение, схема провайдера снимает большую часть отклонений формы, валидатор ловит остаток и то, что схема поймать не может в принципе. Экономить надо на первых двух, а не на третьем: третий — единственный, который остаётся вашим при любой смене модели и провайдера.
Это место понимают неправильно чаще всего. Схема провайдера обязывает модель вернуть поле «тема» строкой — и она вернёт строкой. Но окажется ли в этой строке одна из ваших двенадцати тем или сочинённая на ходу тринадцатая, схема не решает. То же с числами: поле придёт числом, а вот сумма в нём может быть выдуманной — это отдельная проблема, разобранная в материале про то, почему модель ошибается в арифметике. Форма и содержание проверяются разными механизмами, и второй всегда ваш.
Три горизонтальные полосы одна под другой, слева направо изображающие путь ответа. Первая подписана «Просьба в инструкции», в конце полосы широкий разрыв с подписью «проходит и то, что не по формату». Вторая — «Схема на стороне провайдера», разрыв заметно уже, подпись «форма соблюдена, содержание любое». Третья — «Проверка на приёме», вместо разрыва изображён фильтр-решётка и стрелка возврата назад с подписью «повторный запрос». Справа от полос столбец «Что попадёт в систему»: «что угодно», «нужные поля с любыми значениями», «только проверенное». Тонкие чертёжные линии, все надписи по-русски.
Что обязан проверять валидатор на приёме
Минимальный набор проверок короткий, и каждая ловит свой класс сбоев. Пропущенная проверка обычно оборачивается не отказом, а тихой порчей данных — это хуже, потому что обнаруживается через месяц в отчёте.
- 1Все обязательные поля на месте. Отсутствие поля — самый частый и самый безобидный случай: он ловится сразу.
- 2Значение входит в закрытый список. Тема, статус, категория, приоритет. Пришло «Возврат товара» вместо «возврат» — не подставлять похожее, а отправлять на повторный запрос.
- 3Числа пришли числами. «2 000 ₽», «две тысячи» и «2000.00» — три разных ответа, и только один из них годится. Не пытайтесь чинить это разбором строки: чините повторным запросом, иначе будете дописывать разбор бесконечно.
- 4Даты в одном формате. Отдельно проверяйте осмысленность: дата поставки в прошлом году — формально валидная и фактически неверная.
- 5Нет лишних полей. Появление поля, которого нет в схеме, — признак того, что модель начала отвечать иначе. Само по себе оно безобидно, но как сигнал бесценно.
- 6Пустая строка — не то же самое, что «значения нет». Договоритесь, как обозначается отсутствие данных, и проверяйте именно это обозначение. Иначе в CRM появятся карточки с пустым текстом вместо честного «не указано».
Из 2 400 записей проверку с первого раза проходят 2 328, и это нормальная картина. Повторный запрос при несоответствии делается не бесконечно: два раза, потом запись уходит в очередь ручного разбора с указанием, какая именно проверка не прошла. Очередь обязана быть видимой — с ответственным и сроком, ровно как в любом другом контуре, где часть потока не обрабатывается автоматически.
Схема слева направо. Блок «Ответ модели — 2 400 в месяц» ведёт к вертикальному столбцу из шести проверок с подписями: «поля на месте», «значение из списка», «число числом», «дата в формате», «нет лишних полей», «отсутствие обозначено явно». От столбца две ветки: верхняя «прошло — 2 328 записей» ведёт к блоку «Карточка в CRM», нижняя «не прошло — 72 записи» ведёт к блоку «Повторный запрос, до двух попыток». От него стрелка обратно к проверкам и вторая стрелка вниз к блоку «Очередь ручного разбора — 7 записей, ответственный и срок». Тонкие чертёжные линии, все надписи по-русски.
Сколько это стоит и когда окупается
Для расчёта нужна доля ответов, не соответствующих формату. Она сильно зависит от модели, сложности схемы и качества входных данных, поэтому измерять её надо на своём потоке, а не брать из статьи. Возьмём для примера 3 % — величина условная, нужная здесь только чтобы показать структуру расходов.
Строка на 68 ₽ показательна: повторные запросы стоят копейки, потому что средний запрос в нашем контуре обходится в 0,94 ₽ — методика этого счёта разобрана в материале про токены и стоимость запросов. Спорить о цене повторов не нужно вовсе: даже удвоение числа попыток не сдвинет бюджет. Спорить стоит о другом — о том, сколько испорченных карточек никто не заметил. Эта часть в расчёт не попала, и она обычно больше видимой.
Закрытый список значений — самый дешёвый приём качества
Есть настройка, которая улучшает результат сильнее, чем смена модели, и не стоит ничего: заменить свободную формулировку закрытым перечнем. Вместо «определи тему обращения» — «выбери одну из двенадцати тем: …». Вместо «оцени срочность» — «выбери: обычная, срочная, критическая».
- Точность растёт, потому что задача из «сформулируй» превращается в «выбери», а выбор из закрытого набора модели даётся заметно лучше формулирования.
- Результат становится измеримым. По двенадцати темам можно построить отчёт, сравнить месяцы, заметить рост доли возвратов. По свободным формулировкам нельзя построить ничего: «не пришёл заказ», «заказ не доехал» и «где мой заказ» окажутся тремя разными темами.
- Появляется валидируемое условие. Значение либо в списке, либо нет — проверка занимает одну строку кода и ловит целый класс расхождений.
- Нужен пункт «другое» с текстовым пояснением. Без него модель начнёт втискивать непонятные случаи в ближайшую по смыслу тему, и вы получите чистый отчёт вместо честного. Рост доли «другое» — сам по себе полезный сигнал: значит, список пора расширять.
Строгая схема как сторож при смене версии модели
Побочная польза контура проверок, ради которой его стоило бы построить, даже если бы данные были идеальны. Когда провайдер обновляет версию модели, ответы меняются не по смыслу, а по форме: другая длина, другой тон, другая трактовка инструкции. В логах при этом ни одной ошибки — всё выглядит нормальной работой.
Валидатор превращает это невидимое изменение в измеримое: доля ответов, не прошедших проверку с первого раза, — это метрика. Держите её на глазах. Скачок с трёх процентов до восьми означает, что поведение модели изменилось, и это надо разобрать до того, как в CRM накопится месяц странных карточек. Что именно ломается при обновлении версии и как устроен сторожевой прогон, разобрано в соседнем материале раздела; а про то, почему один и тот же запрос вообще даёт разные ответы, есть отдельный разбор недетерминизма.
Отдельно стоит различать структурированный вывод и вызов функций. Во втором случае модель тоже возвращает строгую структуру, но эта структура — заявка на действие: «выполни такую-то операцию с такими-то параметрами». Проверки там те же, а последствия ошибки другие, потому что за разбором следует действие; подробности — в материале про вызов функций.
Когда строгий формат не нужен
- Ответ читает человек и больше никто. Черновик письма, краткое содержание встречи, подсказка оператору — здесь строгая схема только мешает, а свободный текст и есть продукт.
- Поток меньше 200 записей в месяц. Контур на 48 000 ₽ окупается разбором битых записей; при 200 записях и трёх процентах несоответствий это 6 карточек в месяц, то есть около 1 080 ₽ ручной работы. Возвращать вложение придётся почти четыре года. Ограничьтесь схемой провайдера и одной проверкой на обязательные поля.
- Схема ещё не устоялась. Если состав полей меняется каждую неделю, потому что процесс проектируется на ходу, строгие проверки придётся переписывать вместе с ним. Сначала зафиксируйте набор полей на месяц работы, потом стройте контур.
- Данные всё равно проверяет человек перед сохранением. Если менеджер в любом случае открывает карточку и подтверждает поля, автоматическая валидация дублирует его работу. Здесь полезнее вложиться в удобство подтверждения, чем в проверки на приёме.
Модель, которая в 97 случаях из 100 отвечает в нужном формате, — это не «работает почти всегда». Это три испорченные записи на каждые сто, и через год их будет тысяча.
