# Structured output провайдера: тест JSON отдельно от соответствия схеме

Как тестировать structured output на стороне провайдера: синтаксис JSON, required, типы, лишние поля и совместимость выбранного backend.

Автор: Команда Retrivium
Обновлено: 2026-11-01
Канонический URL: https://retrivium.ai/ru/journal/provider-structured-output-conformance-tests/
Language: ru

Модель вернула объект в фигурных скобках — это ещё не означает, что сервис выполнил контракт structured output. В документе могут отсутствовать обязательные поля, числа оказаться строками, а дополнительные свойства нарушить ожидаемую структуру. Для провайдера важно отделить синтаксическую корректность от соответствия конкретной схеме и от поддержки выбранного режима backend. Проверка должна завершаться понятным результатом, а не впечатлением от похожего примера.

## Зафиксируйте заявленный режим

[Документация vLLM](https://docs.vllm.ai/en/stable/features/structured_outputs/) описывает настройки структурированного вывода и поддерживаемые форматы. Сохраните выбранный backend, модель, версию движка и точную схему. Изменение любого из этих условий может затронуть результат даже без изменения публичного имени endpoint.

Не приравнивайте обычную инструкцию «ответь JSON» к технически заявленной функции интерфейса. Первый сценарий оценивает поведение модели, второй дополнительно проверяет контракт параметра и ограничения реализации. В отчёте эти варианты должны иметь разные fixture IDs и ожидаемые исходы.

## Проверьте синтаксис отдельно

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

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

## Добавьте минимальную схему

[JSON Schema](https://json-schema.org/understanding-json-schema/reference/object) различает properties, required и дополнительные поля. Возьмите маленький объект с одним обязательным числом и одним ограниченным строковым значением. Такая схема проще для диагностики, чем большой документ приложения с множеством вложенных вариантов.

Подготовьте ожидаемые свойства до запуска: поле присутствует, тип корректен, дополнительные ключи обработаны по правилам схемы. Используйте независимый validator. Проверка только тем же кодом, который сформировал ответ, может воспроизвести одну ошибку по обе стороны и создать ложное подтверждение.

## Сравните позитивные и негативные fixtures

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

[Обзор OpenRouter](https://openrouter.ai/docs/api_reference/overview) отдельно описывает JSON mode и schema mode своего внешнего API. Это помогает выбрать сравниваемую возможность, но не заменяет проверку upstream-реализации. Не объявляйте поддержку всех вариантов схем только потому, что один простой пример прошёл успешно.

## Сделайте результат частью release gate

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

Применение параметра рассмотрено в [JSON schema через OpenRouter](/ru/journal/openrouter-json-schema/), а содержательная пригодность — в [проверке качества квантизации](/ru/journal/quantization-quality/). Контрактный набор проверяет другое: воспроизводимое соответствие форме и честное описание границ функции без обещаний о неизвестных моделях или действующей интеграции.