GPT-6 Luna: как проверять JSON и извлечённые данные

GPT-6 Luna поддерживает Structured Outputs, но соответствие JSON схеме ещё не подтверждает правильность извлечённых значений. При разработке системы обработки обращений нужны отдельные проверки формата, источника и смысла. В этом руководстве есть задача с тремя полями, пример запроса и код для локального запуска до платной оценки API.

24 сентября 2026 года мы сверили описание Luna и руководство Structured Outputs. Данные и ожидаемые ответы подготовлены как синтетический учебный материал. Проверены валидатор и разбор ответа, а не точность или задержка Luna.

Сначала задайте правила классификации

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

Возвращаются category, order_id и evidence. Категория ограничена значениями billing, access, other; отсутствующий номер заказа обозначается null; доказательство — короткий фрагмент, дословно скопированный из источника. В учебном правиле уведомление о доставке без просьбы о помощи относится к other. У реальной службы поддержки может быть отдельная категория доставки: тогда контракт нужно изменить.

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

Соберите запрос Responses

Скачайте учебный архив и откройте request.json. Используется точный ID gpt-6-luna и явно заданный reasoning.effort: none. Это воспроизводимая стартовая настройка, а не доказательство, что она оптимальна для всех задач извлечения.

Выходной формат задаётся в text.format:

"text": {
  "format": {
    "type": "json_schema",
    "name": "ticket",
    "strict": true,
    "schema": {"...": "use the complete schema.json in the lab"}
  }
}

Это иллюстрация расположения полей, а не полная исполняемая схема. Все три свойства обязательны; номер заказа допускает строку или null; additionalProperties имеет значение false. Правила находятся в сообщении developer, обращение — в user.

Используйте полный запрос и полную схему, а не сокращённый фрагмент с многоточиями. Отправка через вашу разрешённую интеграцию API может стоить денег; здесь она не выполнялась. Различия протоколов описаны в руководстве по переходу Sol/Luna.

Разделяйте уровни проверки

HTTP-успех — только первый этап. Перед чтением данных проверьте завершение и наличие отказа. Функция extract_text обходит содержимое сообщений, не предполагая, что ответ находится в первом элементе output. Для учебных незавершённых ответов и отказов она не возвращает принимаемый текст.

Локальный validate проверяет узкий учебный контракт и не заменяет универсальный валидатор JSON Schema. Он допускает null даже при наличии номера в тексте: полноту нужно проверять отдельно. Парсер рассчитан на официальный формат ответа, а не на произвольный повреждённый JSON.

В рабочей системе последовательно применяйте JSON-парсер, поддерживаемую библиотеку проверки схемы и бизнес-правила. Авторизацию, таймауты, ограничения частоты, сохранение и повторы реализует клиент API.

Запустите тест и изучите контрпример

В распакованной папке выполните:

python3 lab.py test

Достаточно Python 3, дополнительных зависимостей и сетевых запросов нет. 11 проверок охватывают выдуманный ID, отсутствующую цитату, лишний ключ, незавершение и отказ.

В одном контрпримере обращению о списании назначается access, но настоящая цитата сохраняется. Структура и буквальное совпадение проходят, а категория не соответствует подготовленному ожидаемому ответу. Поэтому 11 успешных проверок — результат тестирования кода, не «11 правильных ответов Luna».

Измеряйте реальное качество отдельно

Соберите независимо размеченные случаи с пропущенными ID, дубликатами, противоречиями, несколькими языками и неоднозначностью. Разделите разработку и отложенную оценку; спорные эталоны согласуйте со вторым проверяющим.

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

Критерии приёмки задавайте заранее. Дорогие ошибки в категории billing не стоит прятать в среднем показателе; анализируйте классы и языки и определите, какие случаи требуют ручной проверки. Разбор стоимости Luna помогает с учётом, а руководство Luna → Sol — с проверкой дополнительной обработки.