В этом материале
Возвращённые оценки нужно связывать с позициями и режимом запроса. Они не являются самостоятельной проверкой истинности или качества ответа.
Logprobs добавляет к тексту сведения о вероятностях, но само наличие поля не подтверждает корректную реализацию возможности. Сервер может принять параметр, не вернуть данные либо выдать структуру, которую клиент связывает не с теми позициями. Проверка провайдера должна установить форму и согласованность ответа на небольшом наборе, не превращая вероятности токенов в универсальную оценку качества модели.
Зафиксируйте зависимые параметры
Документация OpenRouter описывает logprobs как включаемую возможность и связывает top_logprobs с включённым logprobs. Сохраните эту зависимость в fixture. Запрос без функции, запрос с ней и несовместимое сочетание параметров должны проверяться как разные случаи, а не как случайные варианты одного текста.
Пределы конкретного интерфейса нельзя переносить на любой upstream. В собственной матрице укажите модель, движок и версию адаптера. Если возможность не поддерживается, результатом должна быть предусмотренная контрактом классификация. Молчаливое отсутствие поля после принятого запроса требует разбора, а не автоматического статуса «успех».
Выберите простой выход
Для первого теста достаточно короткой синтетической генерации с небольшим пределом ответа. Сохраните текст, возвращённые позиции и доступные сведения о токенах. Не начинайте со сложного tool call или длинного документа: там труднее отделить ошибку ассоциации от других преобразований.
В отчёте определите, что считается позицией: токен движка, текстовый фрагмент или другая документированная единица. Нельзя восстановить это только по пробелам в ответе. Один отображаемый символ и одна строка клиента не обязаны соответствовать одной токенной позиции.
Сравните включение и отсутствие
Вариант без logprobs показывает базовую форму ответа. Вариант с функцией проверяет появление обещанной структуры. Отдельный негативный fixture задаёт неподходящий тип параметра или зависимость, которую контракт запрещает. Такие проверки подтверждают обработку API, а не детерминированность генерации.
Обзор интерфейсов vLLM напоминает, что совместимость имеет конкретные ограничения. Поэтому наблюдение на одном сервере не устанавливает поддержку всех моделей семейства. После смены backend повторите тест и сохраните исключения явно, даже если основной текст продолжает возвращаться без ошибок.
Учтите потоковую сборку
При streaming данные оценки могут приходить вместе с фрагментами вывода. Сначала соберите события по правилам интерфейса, затем проверяйте соответствие. Граница сетевого read не определяет позицию токена. Перестановка или повторное добавление события может испортить ассоциацию, сохранив правдоподобный вид текста.
RFC 8259 определяет представление чисел и объектов JSON. Успешный parse подтверждает синтаксис, но не смысл возвращённых вероятностей. Сохраните исходный envelope, чтобы отличить проблему сервера от изменения структуры клиентской библиотекой при последующей обработке.
Ограничьте интерпретацию
Даже корректные оценки относятся к модели, контексту и конкретному распределению. Они не доказывают истинность утверждения и не заменяют набор задач с известными ответами. Не сравнивайте числа разных реализаций без проверки определения, единиц и дополнительных преобразований.
Практический контекст запроса дан в примере Python, а оценка полезности — в проверке качества. Артефакт conformance содержит параметры, форму данных и найденные границы, сохраняя различие между наблюдаемым API и содержательной надёжностью ответа.