В этом материале
Валидный JSON и соответствие схеме — разные уровни. Объявленную поддержку нужно проверять на маленьких положительных и отрицательных fixtures.
Модель вернула объект в фигурных скобках — это ещё не означает, что сервис выполнил контракт structured output. В документе могут отсутствовать обязательные поля, числа оказаться строками, а дополнительные свойства нарушить ожидаемую структуру. Для провайдера важно отделить синтаксическую корректность от соответствия конкретной схеме и от поддержки выбранного режима backend. Проверка должна завершаться понятным результатом, а не впечатлением от похожего примера.
Зафиксируйте заявленный режим
Документация vLLM описывает настройки структурированного вывода и поддерживаемые форматы. Сохраните выбранный backend, модель, версию движка и точную схему. Изменение любого из этих условий может затронуть результат даже без изменения публичного имени endpoint.
Не приравнивайте обычную инструкцию «ответь JSON» к технически заявленной функции интерфейса. Первый сценарий оценивает поведение модели, второй дополнительно проверяет контракт параметра и ограничения реализации. В отчёте эти варианты должны иметь разные fixture IDs и ожидаемые исходы.
Проверьте синтаксис отдельно
Первый тест пытается разобрать итоговый документ стандартным JSON parser. Он обнаруживает незакрытые строки, лишний текст вокруг объекта и другие ошибки формата. Но успешный parse ещё не подтверждает, что необходимые поля присутствуют или имеют нужные значения.
После потоковой генерации парсинг выполняют на правильно собранном результате, а не на каждом незавершённом фрагменте. Иначе тест ошибочно назовёт обычную фрагментацию нарушением структурированного вывода. Одновременно сохраните terminal outcome: оборванный документ нельзя автоматически считать полным ответом.
Добавьте минимальную схему
JSON Schema различает properties, required и дополнительные поля. Возьмите маленький объект с одним обязательным числом и одним ограниченным строковым значением. Такая схема проще для диагностики, чем большой документ приложения с множеством вложенных вариантов.
Подготовьте ожидаемые свойства до запуска: поле присутствует, тип корректен, дополнительные ключи обработаны по правилам схемы. Используйте независимый validator. Проверка только тем же кодом, который сформировал ответ, может воспроизвести одну ошибку по обе стороны и создать ложное подтверждение.
Сравните позитивные и негативные fixtures
Положительный вариант должен допускать однозначный корректный результат. Негативные случаи проверяют неподдерживаемое ключевое слово, несовместимую форму параметра или невозможность выполнить заявленное ограничение. Ожидаемый отказ описывают по контракту сервиса, а не придумывают универсальный код для всех реализаций.
Обзор OpenRouter отдельно описывает JSON mode и schema mode своего внешнего API. Это помогает выбрать сравниваемую возможность, но не заменяет проверку upstream-реализации. Не объявляйте поддержку всех вариантов схем только потому, что один простой пример прошёл успешно.
Сделайте результат частью release gate
Сохраните схему, hash fixture, валидатор и итог проверки рядом с версией адаптера. После обновления повторите маленький набор и явно сравните изменения. Совпавшая структура не устанавливает фактическую истинность данных: модель может вернуть корректно типизированное, но неверное число.
Применение параметра рассмотрено в JSON schema через OpenRouter, а содержательная пригодность — в проверке качества квантизации. Контрактный набор проверяет другое: воспроизводимое соответствие форме и честное описание границ функции без обещаний о неизвестных моделях или действующей интеграции.