# Контракт logprobs: согласованность токенов и возвращённых оценок

Как проверять logprobs и top_logprobs в inference API: включение по запросу, соответствие позициям вывода, потоковый режим и ограничения интерпретации.

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

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

## Зафиксируйте зависимые параметры

[Документация OpenRouter](https://openrouter.ai/docs/api_reference/parameters) описывает logprobs как включаемую возможность и связывает top_logprobs с включённым logprobs. Сохраните эту зависимость в fixture. Запрос без функции, запрос с ней и несовместимое сочетание параметров должны проверяться как разные случаи, а не как случайные варианты одного текста.

Пределы конкретного интерфейса нельзя переносить на любой upstream. В собственной матрице укажите модель, движок и версию адаптера. Если возможность не поддерживается, результатом должна быть предусмотренная контрактом классификация. Молчаливое отсутствие поля после принятого запроса требует разбора, а не автоматического статуса «успех».

## Выберите простой выход

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

В отчёте определите, что считается позицией: токен движка, текстовый фрагмент или другая документированная единица. Нельзя восстановить это только по пробелам в ответе. Один отображаемый символ и одна строка клиента не обязаны соответствовать одной токенной позиции.

## Сравните включение и отсутствие

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

[Обзор интерфейсов vLLM](https://docs.vllm.ai/en/stable/serving/online_serving/) напоминает, что совместимость имеет конкретные ограничения. Поэтому наблюдение на одном сервере не устанавливает поддержку всех моделей семейства. После смены backend повторите тест и сохраните исключения явно, даже если основной текст продолжает возвращаться без ошибок.

## Учтите потоковую сборку

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

[RFC 8259](https://www.rfc-editor.org/rfc/rfc8259.html) определяет представление чисел и объектов JSON. Успешный parse подтверждает синтаксис, но не смысл возвращённых вероятностей. Сохраните исходный envelope, чтобы отличить проблему сервера от изменения структуры клиентской библиотекой при последующей обработке.

## Ограничьте интерпретацию

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

Практический контекст запроса дан в [примере Python](/ru/journal/openrouter-python-request/), а оценка полезности — в [проверке качества](/ru/journal/quantization-quality/). Артефакт conformance содержит параметры, форму данных и найденные границы, сохраняя различие между наблюдаемым API и содержательной надёжностью ответа.