Исследовательская команда Nokia опубликовала AnyJev — Python-библиотеку, которая использует открытую большую языковую модель для выбора ответа из заранее заданного набора вариантов. Вместо генерации и последующего разбора текста система считывает распределение вероятностей следующего токена.
О выпуске 23 сентября 2026 года сообщило издание MarkTechPost. Пакет также представлен в каталоге PyPI, а исходный код опубликован в репозитории Nokia на GitHub. Согласно описанию проекта, AnyJev распространяется по лицензии Apache-2.0 и поддерживает бэкенды на основе Transformers и vLLM.
Инструмент рассчитан на маршрутизацию обращений, классификацию запросов и другие сценарии, где приложению нужен не свободный текст, а одно решение с оценкой уверенности. Дообучать саму LLM для базового режима не требуется.
Решение без генерации текста
Разработчик передаёт AnyJev контекст, типизированный вопрос и допустимые варианты. Библиотека обращается к распределению следующего токена модели и возвращает вероятности для каждой опции. Полученный результат можно сравнить с порогом: например, автоматически направить обращение в нужный отдел только при достаточно высокой уверенности, а остальные случаи передать оператору.
Такой подход отличается от обычного prompting-сценария. Модель не должна написать название категории в свободной форме, поэтому приложению не приходится исправлять формат ответа, извлекать метку из предложения или обрабатывать лишние пояснения. Это снижает число технических сбоев на границе между LLM и прикладной системой, но не гарантирует правильность самой классификации.
Ограничение следующего токена допустимыми метками уже применяется в открытых инструментах. Команда Nokia выделяет у простого варианта два недостатка. Выбор модели может измениться после перестановки вариантов, а значения вероятностей часто не соответствуют реальной доле правильных ответов. Во втором случае модель, например, способна регулярно выдавать уверенность 90% для группы решений, среди которых верными оказываются заметно меньше девяти из десяти.
Чем различаются уровни L0 и L1
Каждый результат AnyJev содержит обозначение уровня обработки. Базовый режим L0 включён по умолчанию и не требует размеченных примеров. Он применяет поправки к исходным оценкам модели, чтобы уменьшить влияние меток и порядка вариантов.
За это приходится платить дополнительными вычислениями. По данным проекта, L0 выполняет K префиллов для одного решения. Они могут обрабатываться пакетом с общим префиксом, что позволяет повторно использовать часть вычислений.
L1 добавляет температурное масштабирование поверх L0. Для настройки этого уровня уже нужны размеченные примеры: в описании указано от 100 до 500 на вопрос. Подобранные параметры сохраняются в небольшом JSON-файле.
Температурное масштабирование корректирует величину уверенности, но не переставляет варианты местами. Если один ответ имел наибольшую оценку до L1, он должен остаться первым и после калибровки. Следовательно, этот режим предназначен не для роста точности, а для более осмысленного использования порогов.
Заявление о работе «без обучения» поэтому требует уточнения. L0 действительно не предполагает настройки весов модели или подготовки размеченного набора. L1 также не дообучает LLM, однако для подбора температуры ему нужны примеры с известными правильными ответами.
Накладные расходы и условия измерения
В материалах проекта приводится ориентир около 0,25 секунды на решение при K = 20, размере пакета 32 и работе на одном ускорителе Nvidia H100. Это результат для конкретной конфигурации, а не универсальная оценка задержки.
На фактическую скорость будут влиять выбранная модель, длина общего контекста, число вариантов, размер пакета и эффективность префиксного кэширования. Для серверного развёртывания разработчики предлагают запускать vLLM с таким кэшированием и подключать к нему VLLMBackend. Отдельный бэкенд предусмотрен для экосистемы Hugging Face Transformers.
Дополнительные вычисления особенно существенны для интерактивных продуктов и сервисов с большим потоком запросов. Командам придётся сравнивать более стабильные вероятностные оценки с ростом задержки и расходов на GPU. Приведённый показатель на H100 нельзя напрямую переносить на потребительские видеокарты, CPU или облачные инстансы другой конфигурации.
Что AnyJev не обещает
Калибровка не делает базовую модель умнее и сама по себе не повышает точность классификации. Если LLM систематически выбирает неверную категорию, L1 может скорректировать заявленную уверенность, но не исправит порядок ответов. Это принципиальное различие между качеством выбора и качеством вероятностной оценки.
Формулировку о поддержке «любой открытой LLM» также следует воспринимать как описание подхода, а не как подтверждение совместимости со всеми моделями. Для работы библиотеке необходим доступ к оценкам следующего токена и подходящий бэкенд. Совместимость конкретной архитектуры, токенизатора и формата меток нужно проверять отдельно.
Опубликованные показатели производительности и качества исходят от авторов проекта или пересказывающего их материала. Независимые тесты в предоставленных данных не указаны. Нет и достаточных оснований переносить результаты одной модели или одного набора классов на медицинские, финансовые и другие сценарии с высокой ценой ошибки.
Лицензия Apache-2.0 относится к самой библиотеке. Она не отменяет условия лицензирования выбранной LLM, её весов, датасетов и других зависимостей.
Как проверить библиотеку на своей задаче
Перед внедрением AnyJev стоит собрать отдельную тестовую выборку и провести три сравнения: с обычным prompting-подходом, с прямым чтением вероятностей без поправок и с уровнями L0 или L1. В каждом варианте нужно измерить не только точность, но и задержку, стоимость запроса и калибровочную ошибку.
Полезен также тест на перестановку: один и тот же набор запросов следует обработать несколько раз, меняя порядок допустимых ответов. Если предсказания заметно меняются, проблема действительно влияет на конкретную модель и задачу.
Для систем с автоматическими действиями отдельно подбирается порог уверенности и проверяется доля ошибок выше этого порога. Настраивать его на той же выборке, по которой затем оценивается качество, не следует. Командам, рассматривающим L1, потребуется отделить данные для температурного масштабирования от финального тестового набора.
Начинать безопаснее с некритичного процесса — например, предварительной маршрутизации обращений с возможностью ручной проверки. После этого результаты можно сопоставить с базовым классификатором меньшего размера: более сложная LLM-схема оправдана только тогда, когда улучшение качества или гибкости покрывает дополнительные задержки и вычислительные расходы.