ИИтог

Ventor-QTest: как проверить, честно ли провайдер обслуживает заявленную LLM через API

исследованияРедакция ИИтогHugging Face🔥71Рейтинг ИИтог71Влияние65Новизна72Релевантность100Неожиданность42Участники68Достоверность87
Ventor-QTest: как проверить, честно ли провайдер обслуживает заявленную LLM через API

Всё больше сторонних провайдеров хостят open-weight LLM (модели с открытыми весами) и продают доступ к ним через API, но проверить, действительно ли на другом конце работает именно заявленная модель без скрытой деградации качества (например, из-за упрощённого квантования или маршрутизации на более дешёвую версию), до сих пор было нечем. Авторы формализуют выдачу такого хостингового маршрута как стохастический процесс и предлагают Ventor-QTest, составной аудит «чёрного ящика», которому не нужен доступ к вероятностям токенов (logprobs) со стороны целевого API.

Метод состоит из двух компонентов. Первый, повторный запрос: один и тот же зафиксированный ограниченный контекст отправляется в целевой API многократно, а по подсчёту возвращаемых текстов восстанавливается категориальное распределение ответов; на этой основе считается средняя потеря точности (average fidelity loss, AFL), статистика на базе огрублённого KL-расхождения с поправкой на смещение и усреднением внутри окна. Второй компонент, длинные последовательности: по независимым прогонам считается крайняя потеря точности (extreme fidelity loss, EFL) через верхний хвост эмпирического распределения статистики неожиданности (surprisal) на уровне отдельного прогона относительно эталона.

На трёх маршрутах, где доступны логпробы, AFL показал сильное линейное соответствие с эталонным показателем на основе логпробов и огрублённого KL-расхождения. На семи снимках маршрутов 20-прогонные пробы длинных последовательностей выявили разброс EFL, специфичный для конкретного маршрута. При этом AFL и EFL почти не связаны с точностью на бенчмарке знаний GPQA-Diamond, зато заметный EFL совпадает со снижением доли успешных прохождений Terminal-Bench (бенчмарк длинных агентных задач) по мере роста длины задачи. Авторы объясняют это тем, что корректность в длинных агентных задачах сильнее чувствительна к экстремальным потерям точности, и рекомендуют отчитываться по AFL и EFL совместно, особенно при аудите длинных агентных сценариев. Открытая реализация метода выложена на GitHub в репозитории Tencent AI-Infra-Guard.

Ключевые факты

  • Ventor-QTest, метод аудита «чёрного ящика» для проверки, честно ли сторонний провайдер обслуживает заявленную open-weight LLM через API, без доступа к вероятностям токенов.
  • Два компонента: повторные короткие запросы дают метрику AFL (средняя потеря точности), серии длинных последовательностей, метрику EFL (крайняя потеря точности).
  • На трёх маршрутах с доступными логпробами AFL показал сильное линейное соответствие с эталонным KL-показателем; на семи снимках маршрутов 20-прогонные пробы выявили разброс EFL.
  • AFL и EFL почти не связаны с точностью на бенчмарке GPQA-Diamond, но заметный EFL совпадает со снижением успешности Terminal-Bench по мере роста длины задачи.
  • Открытая реализация выложена на GitHub в репозитории Tencent AI-Infra-Guard.

Почему это важно

Компании всё активнее пользуются API сторонних провайдеров, которые хостят open-weight модели вместо того, чтобы разворачивать их у себя. Но заявленная модель на бумаге и то, что реально отвечает на запросы, не всегда одно и то же: провайдер может незаметно урезать качество через агрессивное квантование или маршрутизацию части трафика на более дешёвый вариант. До сих пор надёжного способа проверить это со стороны клиента, не имея доступа к внутренним вероятностям токенов API, не было. Ventor-QTest закрывает именно этот пробел.

Кому это важно

Метод адресован тем, кто строит продукты поверх сторонних LLM API, платит за конкретную модель и должен быть уверен, что получает именно её, а не тихо подменённую версию. В первую очередь это касается разработчиков агентных систем с длинными цепочками действий: по данным работы, именно в таких задачах деградация качества API заметнее всего сказывается на результате.

Как это применить

Реализация Ventor-QTest выложена в открытом доступе на GitHub, в репозитории Tencent AI-Infra-Guard (папка services/api_checker/ventor_qtest). Практически аудит состоит из двух прогонов: повторные короткие запросы дают метрику AFL (средняя потеря точности), а серии длинных последовательностей, метрику EFL (крайняя потеря точности). Авторы советуют смотреть на обе метрики вместе, а не полагаться на одну, особенно если API используется для длинных агентных сценариев.

Можно ли доверять

Страница Hugging Face Papers указывает имя первого автора и ссылку на открытый код, но сама аннотация не называет ни полный состав авторов, ни организацию-разработчика, только путь к репозиторию Tencent. Метод при этом проверен не только на словах: на трёх маршрутах, где было можно сравнить с эталонным показателем на основе логпробов, AFL показал с ним сильное линейное соответствие, это независимая проверка того, что метрика действительно отражает реальные расхождения, а не шум.

Риски и подводные камни

В самой аннотации нет числовых значений AFL и EFL и нет данных о размере снижения успешности Terminal-Bench, судить о практической чувствительности метода по абстракту нельзя. Метрики Ventor-QTest почти не связаны с точностью на бенчмарке знаний GPQA-Diamond: метод ловит деградацию, заметную в длинных агентных задачах, но не гарантированно ловит падение точности на обычных вопросах-ответах. Имена всех авторов и их принадлежность к организациям в тексте не названы, что затрудняет независимую проверку репутации команды.