Как устроена Jev: неавторегрессионная модель и параллельный сэмплер

Что TypeSafe рассказала официально

В анонсе Jev компания перечисляет три компонента, которые разработала для модели:

• новую архитектуру — без технических подробностей;
• параллельный сэмплер — по словам TypeSafe, он формирует все выходы за один запрос и учитывает особенности железа;
• метод обучения RLCD — обучение с подкреплением на откалиброванные решения. Ему посвящена отдельная статья.

По описанию TechCrunch, Jev — трансформерная модель, но не большая языковая модель. На вопрос, не «уменьшенная ли это LLM», TypeSafe отвечает, что Jev и не маленькая, и не LLM. Размер модели и число параметров в открытых материалах компании не указаны.

Авторегрессия: как отвечает обычная LLM

Большие языковые модели авторегрессионны: они выдают ответ по одному токену, и каждый следующий токен зависит от предыдущих. Даже короткий JSON вроде {"category": "billing"} модель пишет по кусочку. Схема structured output ограничивает результат, но генерация всё равно может сорваться или оборваться, а длинный ответ приходит заметно дольше короткого.

Отсюда три свойства LLM, от которых Jev уходит: время ответа растёт с длиной вывода, выходные токены дороже входных (по оценке TypeSafe — примерно в пять раз), а сам ответ — строка, которую программе нужно разобрать.

Что значит «неавторегрессионная» у Jev

Jev не пишет строку. На каждый вопрос модель возвращает распределение вероятностей по вариантам, которые вы задали, и делает это для всех вопросов сразу. MindStudio описывает принцип так: модель получает описание ситуации и список допустимых действий и за один проход возвращает решение с вероятностью и уверенностью.

Из этого следуют свойства, которые видны прямо в API:

• ответ всегда совпадает со схемой: модель распределяет вероятность только между вашими вариантами;
• выходных токенов мало, и TypeSafe их не тарифицирует;
• score в ответе Score — среднее номеров уровней, взвешенное по вероятностям, поэтому оно может оказаться между уровнями;
• confidence у Choice и Score вычисляется из формы того же распределения, это не отдельный прогноз.

Параллельный сэмплер на практике

Документация описывает поведение, которое можно проверить на своих запросах.

• State читается один раз. Jev принимает состояние и параллельно оценивает относительно него каждый вопрос.
• Вопросы изолированы. Ответ на один вопрос не становится контекстом для другого. Можно добавлять и удалять вопросы, не меняя остальные ответы. По тестам TypeSafe, объединение вопросов в один запрос влияет на ответы не больше обычного шума сэмплирования.
• Время почти не растёт с числом вопросов. Каждый новый вопрос добавляет только свои токены.
• Уровни шкалы оцениваются по отдельности. В Score модель не видит номер уровня и соседние уровни, поэтому описание «хуже предыдущего» ей ничего не говорит.
• Ключи вопросов модель не видит. Они нужны только вашему коду, поэтому формулировку целиком пишите в instructions.

Лимиты контекста описаны в тех же терминах. На запрос отводится 64 тысячи токенов — state плюс все вопросы. Отдельно state вместе с самым длинным вопросом должен уложиться в 32 тысячи токенов.

Предел одного Choice — 255 вариантов. Для выбора из большего числа TypeSafe в демо с Википедией, где на странице бывают сотни ссылок, применяла двухэтапную схему: сначала варианты оцениваются независимо, затем делается явный выбор.

Скорость и повторяемость

По документации, большинство запросов к Jev выполняются примерно за 100 мс, а в анонсе компания называет полное время ответа 70–500 мс. У этих цифр есть оговорка от самой TypeSafe: замеры компания обычно делает с ноутбуков на западном побережье США, где сейчас размещён сервис. Если вы обращаетесь к API из другого региона, к ним добавится сетевая задержка.

Параллельный сэмплер не делает ответы строго детерминированными. В одном из cookbook’ов TypeSafe прогнала рубрику из 14 вопросов Noul по одному страховому случаю 15 раз подряд. Среднее стандартное отклонение вероятности по вопросу составило около 0,01. Но ответ на вопрос о том, покрывает ли полис этот случай, колебался от 0,43 до 0,53 и пересекал порог 0,5. Поэтому решениям у самой границы порога нужна серая зона, а не жёсткое «да/нет».

Что закрыто

Список неизвестного длиннее списка известного:

Что	Статус
Веса модели	Закрыты, запустить Jev у себя нельзя
Архитектура и размер	Не раскрыты
Данные обучения	Известно со слов основателя, что только синтетические
Функция потерь и схема вознаграждения RLCD	Не опубликованы
Методика калибровки, кривые калибровки	Не опубликованы
Результаты на публичных бенчмарках	Не публикуются намеренно

Первые пункты перечисляет автор разбора на Хабре, пробелы в описании RLCD — Энтони Майо в своём обзоре. Про бенчмарки TypeSafe высказалась сама: компания решила не публиковать результаты на публичных наборах и советует пользователям строить собственные тесты под свои задачи.

TechCrunch добавляет деталь: основатель TypeSafe Диогу Алмейда уходит от вопросов об архитектуре, а сторонние наблюдатели подозревают, что Jev построена поверх открытой LLM. Подтверждений этому нет, а компания, как сказано выше, настаивает, что Jev — не LLM.

Что можно проверить снаружи

Сейчас проверить можно только то, что происходит на границе модели и приложения, отмечает автор статьи на Хабре. Независимые опыты, на которые он ссылается, согласуются с изоляцией вопросов и показывают, что на ответ влияет весь список вариантов. А вот каузальный декодер, KV-кэш, отдельные выходные головы или разреженная MoE-архитектура из этих опытов не следуют. Любые подобные утверждения о Jev пока остаются догадками.

Ещё одно наблюдение оттуда же: похожий интерфейс можно собрать поверх обычной LLM — со structured output, ограниченным декодированием или оценкой логитов. TypeSafe и сама сравнивала Jev с LLM через собственную обёртку System One, которая заставляет LLM отвечать в формате её API. Поэтому Jev стоит оценивать не по форме ответа, а по качеству, калибровке и задержке на ваших данных.

Что это значит для разработчика

• Задавайте независимые вопросы одним запросом. Параллельная схема делает лишние вопросы почти бесплатными по времени.
• Зависимости стройте в коде. Если второй вопрос зависит от ответа на первый, нужен второй запрос.
• Не ждите согласованности между вопросами. В документации к версии 1.13 есть пример: вероятности для вопроса «клиент просит возврат?» и для его отрицания в сумме дали 1,19, а не 1.
• Следите за размером state. Число вопросов на скорость почти не влияет, а лишний контекст снижает точность. Как собрать состояние, рассказываем в статье о state в Jev.
• Добавляйте вариант «другое». Модель распределяет вероятность только между вашими вариантами. Почему это важно, разбираем в статье о галлюцинациях Jev.

Модель нельзя развернуть у себя, и это одно из главных ограничений для компаний с закрытым контуром. Остальные собраны в статье об ограничениях Jev.