ИИ вернул правильный JSON: почему данные ещё надо проверить

Правильный JSON от ИИ подтверждает только выполненные проверки: синтаксис, описанные ограничения схемы и другие явно заданные условия. Он сам по себе не доказывает актуальность офиса, права пользователя или точное понимание заявки. До действия сверьте значения с разрешёнными справочниками и исходными сведениями, сохранив возможность честно сообщить о неизвестном.

Учебная заявка: форма верная, действие неверное

Представим запрос: «Нужно настроить доступ к сети в офисе А. Не срочно». Модель вернула три поля: service со значением network, office со значением office_B и urgency со значением urgent. В учебной схеме service допускает network или printer, office должен быть строкой, urgency допускает routine или urgent. Все три поля обязательны, дополнительные запрещены.

Такой объект соответствует перечисленным требованиям формы: поля присутствуют, тип офиса строковый, значения перечислений допустимы. Но офис Б не входит в разрешённый набор этого учебного пользователя, а срочность противоречит исходному тексту. Если результат сразу превратить в рабочую команду, аккуратный формат не защитит от неправильной заявки.

Что именно проверяет схема

В описании объектов JSON Schema properties задаёт правила для свойств, required — их обязательность, а дополнительные поля контролируются отдельно. Одного списка properties недостаточно, чтобы автоматически потребовать наличие каждого поля или запретить все остальные. Условия нужно описать в выбранной схеме.

Часть бизнес-правил тоже можно выразить формально: допустимое перечисление, ограничения значений и зависимости, поддерживаемые выбранным диалектом и механизмом. Поэтому неверно говорить, что схема проверяет только скобки. Она проверяет именно выраженные условия, но не узнаёт сама, что разрешённый офис переехал или запись справочника устарела.

Карта подтверждений до действия

Таблица относится к вымышленной заявке выше. Пример вручную сопоставлен с явно описанной схемой; это не отчёт о вызове модели или тесте определённого провайдера. Каждый следующий слой добавляет своё доказательство, а не отменяет предыдущий.

Структурированный вывод не является проверкой источника

В документации Meta Model API описано ограничение генерации по переданной JSON Schema. Это пример механизма конкретного поставщика. Его свойства и поддерживаемый набор схем нельзя автоматически переносить на все модели. И даже гарантии формы в заявленном режиме не означают, что каждый внешний факт был проверен.

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

Актуальный справочник — отдельное условие

Если набор допустимых значений известен заранее, можно включить его в подходящее перечисление. Но нужно решить, когда оно обновляется и что произойдёт между генерацией ответа и исполнением. Код, бывший допустимым при подготовке запроса, может оказаться закрыт или недоступен конкретному пользователю к моменту действия.

Сохраняйте связь с использованной версией источника, когда она значима для объяснения результата. Перед выполнением повторно проверяйте изменяемые условия по принятой политике. Не объявляйте текстовое описание в подсказке равным принудительному ограничению сервера. Контекст помогает модели, но границу допустимого действия реализует система.

Неизвестность не нужно маскировать заполненным полем

Предусмотрите допустимый путь для недостающих сведений: уточнение, отдельное состояние проверки либо значение неизвестности, разрешённое схемой. Если null запрещён, нельзя просто поставить его в обязательное поле и считать результат корректным. Схема и продуктовый путь должны быть согласованы, иначе требование заполнить всё подталкивает к выдуманным значениям.

Для учебного запроса без офиса разумно запросить уточнение или использовать явно принятый контекст. Нельзя по умолчанию выбрать первый офис из чужого справочника. Аналогично отсутствие срочности не доказывает срочность и не всегда означает обычный приоритет: конкретное правило выбирает владелец процесса.

Граница между предложением и выполнением

В веб-приложении отдельно обозначьте черновик, проверенное предложение и подтверждённое действие. Если человеку нужно согласовать параметры, покажите значимые значения до исполнения. Кнопка подтверждения должна относиться именно к показанному варианту, а не к новой скрытой генерации, выполненной после нажатия.

Для автоматического сценария заранее определите условия допуска и маршрут исключения. Ошибка внешнего источника не должна превращаться в разрешение выполнить всё на доверии. Повтор запроса также не должен бесконтрольно создавать новые заявки. Проверку полномочий и связей результата полезно включить в аудит API.

Как проверить цепочку без оценки «модель вроде справилась»

1. Подготовьте вымышленные исходные заявки с явными параметрами, отсутствующим значением и неоднозначностью. Задайте ожидаемые допустимые действия.
2. Проверьте синтаксис и согласованную схему, включая обязательность и дополнительные поля. Не называйте один разбор JSON полной валидацией.
3. Добавьте формально допустимые, но неверные значения: чужой офис, устаревшую услугу, противоречащую исходнику срочность.
4. Сверьте реакцию приложения: отказ, уточнение или допустимый проверенный маршрут. Полномочия должны проверяться независимо от ответа модели.
5. Измените внешний справочник между предложением и действием. Поведение должно соответствовать правилу актуальности.
6. Проверьте подтверждение, ошибку и повтор без реальных рабочих операций. Сохраните, какая проверка дала какое основание для решения.

Готовый результат — не только предсказуемые ключи JSON. Для каждого выполняемого действия должно быть понятно, что подтверждает форма, что подтверждает источник и кто разрешил исполнение. Тогда структурированный ответ становится полезным промежуточным представлением, а не подменой доказательства правильности.