AI-сервис читает обращение клиента и создаёт заявку в поддержке. В ответе есть все необходимые поля: категория, приоритет, идентификатор клиента, краткое описание. Формат правильный, интеграция работает. Только заявка ушла не в то подразделение.
Вот и граница возможностей structured output. Мы научились получать от модели предсказуемую структуру данных. Это никак не гарантирует, что внутри неё правильные сведения.
Обе задачи важны. Когда ответ ИИ передаётся следующей системе, программа должна уметь его надёжно прочитать. Но она также должна понимать, когда результат нельзя принимать за готовое бизнес-решение.
Свободный текст плохо подходит для интеграций
Человек легко понимает, что «срочно» и «высокий приоритет» могут означать одно и то же. Программа, которой требуется конкретное значение поля, так не умеет.
Сегодня модель вернула ожидаемую категорию, завтра добавила полезное пояснение перед данными, послезавтра немного изменила формулировку. В обычном диалоге это не проблема. Для автоматизации каждое отклонение может обернуться ошибкой обработки.
Structured output задаёт контракт результата: какие поля нужны, какие у них типы, что обязательно, какие значения допустимы. До передачи ответа дальше приложение проверяет, соблюдён ли этот контракт.
Некоторые интерфейсы моделей умеют генерировать данные сразу с ограничением по схеме. Это надёжнее, чем просто попросить в промпте «верни правильный JSON». Но на границе с остальной системой проверка всё равно должна быть явной.
У проверки есть как минимум два уровня
Первый — технический. Есть ли идентификатор клиента? Приоритет входит в список допустимых значений? Поле даты действительно содержит дату?
Второй — содержательный. Такой клиент существует? Он имеет право на запрошенную операцию? Дата допустима для этого процесса? Информация из обращения вообще позволяет назначить такой приоритет?
Именно второй уровень часто упускают. Валидный ответ приятно выглядит и создаёт ощущение надёжности. Но модель может перепутать человека, неверно классифицировать счёт или придумать значение, которое прекрасно укладывается в схему.
Если результат запускает чувствительную операцию, одной структуры недостаточно. Дополнительные проверки и согласования — часть архитектуры ограничений ИИ.
Сначала предусмотрите неудачный ответ
Что произойдёт, если поле отсутствует, структура нарушена или данные противоречат бизнес-правилу? Худший вариант — незаметно подставить догадку и продолжить выполнение.
Для одних задач разумно запросить повторный ответ, но с ограничением числа попыток. Другие нужно отправлять на ручную проверку. Иногда правильнее вернуть явную ошибку. Решение зависит от цены неправильного действия.
Это не призыв ставить человека над каждым безобидным классификатором. Но у неоднозначного результата должен быть предусмотрен маршрут. Иначе автоматизация всего лишь ускоряет попадание ошибок в соседние системы.
Я бы отдельно измерял нарушения формата и содержательные ошибки. Первые могут говорить о проблеме интеграции или промпта. Вторые — о качестве решения самой задачи, недостатке контекста или невозможности принять решение по имеющимся данным.
Схема ответа становится интерфейсом продукта
Когда другие сервисы начинают зависеть от структуры ответа, переименование поля перестаёт быть косметическим изменением. Оно может сломать интеграцию так же, как несовместимое изменение обычного API.
Значит, нужны версии контракта, правила совместимости, поведение старых потребителей при появлении новых полей. Если результаты сохраняются в базу, стоит заранее понимать, как читать старые записи после изменения схемы.
Это обычные задачи разработки ПО. И это правильно: ИИ внутри бизнес-процесса должен быть компонентом с понятным интерфейсом, а не чат-окном, из которого кто-то пытается вытащить данные.
Похожая логика применяется в Data Contracts, где о структуре и смысле данных договариваются разные системы и команды.
Правильный формат — ещё не качество
Structured output полезен при извлечении данных из документов, классификации, маршрутизации заявок и других задачах, где программу интересуют конкретные поля. Для свободного разговора строгая схема может быть вообще не нужна.
Но даже в автоматизации я бы смотрел не только на долю валидных ответов. Правильно ли определена категория? Может ли модель честно сказать «недостаточно данных»? Что происходит при противоречивом документе? Способен ли человек восстановить ход решения?
Эти вопросы относятся уже к оценке качества AI. Схема помогает обнаружить и остановить ошибку. Она не освобождает от проверки того, насколько хорошо модель выполнила саму работу.
Нам нужен предсказуемый переход от вероятностного ответа модели к обычному программному процессу. Предсказуемость здесь означает, что неправильный результат можно распознать и остановить, а не просто красиво оформить.