Съест ли OpenAI обед Jev: у TypeSafe нет преимуществ, кроме данных для обучения

· 2 мин чтения
jev openai llm classification analysis
Съест ли OpenAI обед Jev: у TypeSafe нет преимуществ, кроме данных для обучения

Jev от TypeSafe — System One-модель, которая не генерирует текст, а мгновенно выдаёт калиброванные вероятностные решения — стал самым быстрым хитом года. По данным Vercel, Jev приняли быстрее, чем любую другую модель в истории AI Gateway. Но на горизонте сгущаются тучи: OpenAI наверняка обратила внимание и решает, что делать дальше.

Автор материала — Джон Берриман, основатель Arcturus Labs и бывший инженер GitHub Copilot. Его тезис в двух словах: OpenAI годами неявно использовала собственные LLM как классификаторы — просто не обучала их для общих задач классификации и не упаковывала классификацию в отдельный продукт. Если OpenAI воспроизведёт обучение, она быстро повторит Jev. А главное — сможет встроить классификатор внутрь своих моделей и агентов, получив более быстрый выбор модели, более эффективное рассуждение, защитные механизмы безопасности и в целом более умные, быстрые и дешёвые модели. Всё решает один вопрос: есть ли у TypeSafe ров (moat). Самый серьёзный кандидат — обучающие данные и процессы обучения.

Всё новое — хорошо забытое старое

Основное допущение автора: Jev — это почти обычная большая языковая модель. Косвенное подтверждение — отчёт Latent Space, что многие ранние клоны действительно построены на LLM.

Механика проста. По состоянию state и набору вопросов LLM генерирует распределение вероятностей по всем возможным следующим токенам. Для вопроса типа noul модель смотрит только на токены true и false и нормализует их вероятности. Для choice — берёт относительные вероятности перечисленных вариантов, скажем A=happy, B=sad, C=angry, D=afraid, и выбирает самый вероятный. Этот паттерн Берриман описывал ещё в 2025 году в статье Supercharging LLM Classifications with Logprobs — и даже без fine-tuning он уже тогда показывал потенциал. Примитив score, скорее всего, вариация того же приёма.

Ключевая мысль: OpenAI использует отдельные токены как микро-классификаторы минимум со времён появления tool calling. В ChatML — внутреннем языке разметки диалогов OpenAI — токены <|im_start|> и <|im_end|> размечают границы сообщений. Первый токен после <|im_start|>assistant — это классификатор «вызвать инструмент или ответить текстом»: модель предсказывает либо \n, либо to=function.. Следующие токены выбирают конкретный инструмент из списка — ещё один классификатор. Затем генерируются имена и значения аргументов. Наконец, токен <|im_end|> — классификатор «сообщение завершено».

Эффектная иллюстрация из практики Берримана во времена работы над Copilot: сырой внутренний API GPT-4 требовал задать заголовки, разрешающие использовать спецтокены <|im_start|> и <|im_end|>. Без них модель физически не могла предсказать конец ответа — и после связного текста бесконечно продолжала: «Если будут вопросы — обращайтесь. Хорошего дня. Отличной недели. Прекрасного времяпрепровождения. Чудесной жизни...» — до лимита токенов.

Разница между этими микро-классификаторами и Jev лишь в одном: первые — специалисты под конкретные задачи, вторые — универсальны. Но LLM сама по себе и есть чрезвычайно общий классификатор, непрерывно выдающий распределение вероятностей для каждого следующего токена.

Есть ли у TypeSafe ров?

Архитектурного рва нет — по причинам, описанным выше. Настоящий ров — в обучающих данных и технике превращения их в калиброванность. Сооснователь TypeSafe Диогу Алмейда прямо подтвердил это в ответе в Twitter:

возможно, вы первый, кто говорит о данных, а не об архитектуре! 🥲 мы считаем себя data research lab! подавляющая часть исследований была о том, как сделать по-настоящему общие данные (в духе cognitive core), и 100% наших данных — синтетические (но не тот мусор, который просто выплёвывает LLM)

Если бы автор строил такой датасет, он бы собирал примеры, где исход уже известен: тикеты поддержки и их реальную маршрутизацию, резюме и факт найма, отзывы и реальные звёзды рейтинга, очереди модерации и вердикты, рынки предсказаний и их итоговое разрешение. Дело не в обучении конкретным доменам — дело в тысячах ситуаций из разных сфер, на которых тренируется способность обобщать классификацию. Дальше идёт reinforcement learning — возможно, автономные агенты, navigating decisions с ограниченным набором опций как в демо с Wikipedia и Doom на сайте TypeSafe, или предсказание исходов событий после pre-training cutoff. Если и есть секретный ингредиент — то здесь.

Но ничто из этого не является рвом, если Jev неточен. Скорость, цена и удобство очевидны, а вот точность проверить труднее всего. Автор уже нашёл домены, где вероятности Jev не выдерживают проверки. Время покажет, достаточно ли Jev универсален и точен.

Следующий ход за OpenAI

Очевидный ход — скопировать Jev и выпустить как новый тип модели. Но куда интереснее встроить классификацию внутрь обычной LLM.

LLM, которая отвечает на собственные вопросы

Точно так же, как to=function. сигнализирует о вызове инструмента, OpenAI могла бы ввести новый тег — скажем, <prediction> — который модель вставляет в собственный контекст, когда ей нужен быстрый классификаторский вердикт:

<user> So Donny said "nice haircut" to me today. Does he like me? </user>
<assistant>
<thinking>
Let me size this up.
<prediction> claim: Donny is romantically interested in Jess. probability: 0.04 </prediction>
Yeah, "nice haircut" is not exactly a love confession.
</thinking>
I hate to break it to you, but... probably not.
</assistant>

Ключевое отличие от обычного tool calling: при вызове инструмента генерация останавливается, агентский харнесс должен перехватить управление, вызвать функцию и вернуть результат. Здесь передачи нет — классификатор не внешний инструмент, а встроенная способность модели. Она задаёт вопрос и отвечает на него одним дыханием, не покидая GPU.

Технически это guided decoding: в позиции после probability: вместо обычного декодирования читаются логиты токенов true и false, нормализуются друг относительно друга, и результат записывается в последовательность текстом — 0.04. Дальше модель продолжает декодирование, как будто сгенерировала это число сама. Второй трюк — дообучить одну специализацию в mixture of experts именно под калиброванные мгновенные суждения, пока остальная модель продолжает делать то, что умеет.

Что это даёт

Такие мини-вердикты — если верить TypeSafe — точны и меньше склонны к галлюцинациям, чем просьба к модели назвать уверенность текстом. (Оговорки есть — TypeSafe сама честно описывает шероховатости Jev: модель хороша для быстрых суждений System One, но не для математики и многошаговых рассуждений.) Возможные применения:

  • Контроль рассуждения. Во время длинной цепочки рассуждений модель периодически проверяет, закончила ли она и какую задачу взять следующей: <prediction> query: Which of these remaining tasks should I do next? options: A=verify the test suite passes, B=update the changelog, C=nothing, I'm done probabilities: A=0.71, B=0.24, C=0.05 answer: A </prediction>. Дешёвый способ оборвать блуждающий reasoning trace.
  • Безопасность tool calls. Сразу после генерации вызова модель проверяет, безопасен ли он. В примере из статьи пользователь просит проверить баланс и открыто передаёт живой API-ключ sk-live-83fj2ndk9 — модель оценивает claim: This tool call is unsafe to run. probability: 0.97 и отказывается отправлять ключ в открытом виде. Тот же паттерн — для сканирования ответов инструментов на prompt injection, вплоть до синтаксиса вроде <safety_score>0.94</safety_score>.
  • Маршрутизация моделей. Периодический вопрос «нужна ли для этой задачи модель побольше, поменьше или эта?» — с reinforcement learning, подталкивающим ответ к самому дешёвому варианту без потери точности.
  • Неявная маршрутизация экспертов. Если в MoE действительно появится выделенный «эксперт» мгновенных суждений, специальный синтаксис <prediction> может вообще не понадобиться — эксперт подключается посреди предложения как обычная часть forward pass.
  • Картинки и речь. Как только Jev-подобная классификация заработает внутри текстовой LLM, general classification появится и для изображений, и для речи. Классификация внутри речевой модели особенно ценна для голосовых агентов реального времени: прервать, эскалировать или продолжать слушать.

Переживёт ли TypeSafe?

Проверка времени покажет, выдерживают ли заявления Jev о точности и универсальности. Если да, выживание TypeSafe сводится ко рву: насколько действительно трудно воспроизвести их обучающие данные и процесс reinforcement learning. Если трудно — TypeSafe, вероятно, в порядке, и даже в необычно выгодной позиции: не быть поглощённой конкурентом, а быть приобретённой самой OpenAI. Всё описанное выше — реальное улучшение способностей для frontier-лаборатории: более быстрое и дешёвое мышление с встроенным в флагманскую модель суждением System One.

Если же ров тонкий — OpenAI построит всё сама, и окно TypeSafe закроется стремительно. Основатель и CEO TypeSafe Диогу Алмейда, впрочем, уверен — в интервью Latent Space он сказал: «Если качество модели имеет значение, мы будем в очень хорошей позиции ещё долго».

Источник: https://arcturus-labs.com/blog/2026/09/21/will-openai-eat-jevs-lunch/