Что на самом деле умеет Jev? Разбираем сценарии применения на 10 проектах сообщества

Навигация по сайтам, очистка контекста Agent, сборка интерфейсов, фильтрация рекламы, управление играми, классификация писем и пропуск спонсорских вставок на YouTube — если поставить эти проекты с Jev рядом, легко решить, что модель умеет почти всё.

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

Именно это различие важно для понимания Jev. Его ценность не в том, чтобы заменить чат-модель во всей задаче, а в том, чтобы превратить шаги, где языковой модели пришлось бы «подумать, написать ответ, а затем дать программе его разобрать», в выбор, оценку или вероятность, которые программа может использовать напрямую.

Чем Jev отличается от обычной чат-модели?

TypeSafe называет Jev первой моделью System One. Разработчик передаёт ей две части: state с описанием текущей ситуации и набор типизированных typed questions. Вместо длинного текста Jev возвращает три вида структурированных решений:

Тип	Для каких вопросов подходит	Типичный результат
Choice	Какую категорию, действие или инструмент выбрать?	Один вариант и вероятность каждого варианта
Score	К какому уровню относится серьёзность, релевантность или качество?	Оценка и вероятности по уровням
Noul	Верно ли некоторое утверждение?	Вероятность от 0 до 1

Например, браузерный Agent может собрать DOM текущей страницы, цель пользователя и доступные действия в state, а затем спросить Jev: «По какому элементу нужно кликнуть следующим?» Получив результат, программа выполняет клик. Если в поле ввода нужно написать текст, этот фрагмент по-прежнему передаётся генеративной модели.

Поэтому точная схема выглядит не как «Jev выполняет задачу», а так:

Текущее состояние или событие
      ↓
Jev: выбрать, оценить или вынести суждение
      ↓
Обычный код: выполнить, ранжировать, отфильтровать, остановить или передать человеку

Следующие десять проектов — не рейтинг зрелости. Их удобнее разделить по роли Jev в программе на три уровня: действия, информация и процессы.

1. Уровень действий: Jev выбирает следующий шаг, программа его выполняет

1. Browser Use: веб-действия превращаются в выбор из кандидатов

В реализации jev-ultrafast для Browser Use программа сначала читает DOM страницы и формирует набор доступных действий: нажать кнопку, выбрать вариант, перейти на следующую страницу и так далее. Jev не описывает в свободной форме, как нужно работать с сайтом, а выбирает следующий шаг из подготовленного списка.

Такой дизайн подходит Jev, потому что в каждом цикле выполнены три условия: состояние уже подготовлено программой, набор действий конечен, а код знает, как исполнить выбранное действие. Когда нужно ввести текст — например, город отправления или назначения, — система всё ещё обращается к небольшой генеративной модели; сам Jev такой текст не создаёт.

Автор сообщил, что один поиск авиабилета занял около 7 секунд и стоил примерно $0.0039, а демонстрационное видео воспроизводилось с обычной скоростью. Эти цифры описывают конкретный фиксированный процесс, но не доказывают, что любой сайт и любая задача сохранят ту же скорость и успешность. MVP также пока не охватывает shadow DOM, iframe, canvas и загрузку файлов.

Главный вывод здесь не в том, что «Jev умеет пользоваться браузером», а в другом: сначала код сужает пространство действий, затем модель делает один ограниченный выбор.

2. Голосовой браузер: Jev находится между распознаванием речи и исполнением в браузере

Цепочка голосового управления браузером ещё нагляднее показывает разделение ролей. Микрофон записывает речь, речевой сервис переводит её в текст, система читает текущую страницу и подготавливает исполнимые действия, Jev выбирает одно из них, после чего браузер его выполняет.

По данным автора, одно решение Jev занимало около 300 миллисекунд и стоило примерно $0.0002. Но это показатель только этапа принятия решения. Он не включает запись звука, распознавание речи, поиск элемента на странице, передачу по сети и выполнение действия браузером. Поэтому «Jev быстро принимает решение» не означает, что весь голосовой сценарий занимает 300 миллисекунд.

Подход лучше всего подходит для команд вроде «открой эту вкладку», «нажми отправить» или «прокрути вниз», которые можно сопоставить конечному набору действий. Если пользователь просит написать, пересказать или объяснить материал, процесс всё равно требует универсальной модели.

3. Doom и Mario: модель читает структурированное состояние, а не изображение игры

Игровые демонстрации обычно привлекают больше всего внимания. В открытом проекте с Doom положение игрока, враги, оружие и другие сведения преобразуются в структурированное текстовое состояние. Jev выбирает движение, атаку или другое действие, а программа отправляет выбор обратно в игру.

Автор сообщил о скорости около 10 вызовов в секунду и стоимости примерно $7 в час. Однако это нельзя описывать как «Jev напрямую понимает изображение и самостоятельно играет». В материалах TypeSafe о запуске прямо сказано, что демонстрация Doom использует структурированное текстовое состояние, а не исходные пиксели. Проекты сообщества с Mario также ближе к экспериментам, где состояние поступает в цикл принятия решений, а модель выбирает действие.

Эти примеры показывают, что быстрые решения можно включить в контур реального времени. Они не доказывают наличие у Jev универсального зрения или способности к долгосрочному планированию в игре.

4. Торговля в реальном времени: быстрый выбор не доказывает прибыльность стратегии

В торговых демонстрациях используется похожая схема. Цены, активы и состояние рынка структурируются и отправляются в Jev; модель выбирает buy или sell; затем программа выставляет ордер. В другом проекте сообщества утверждается, что система могла следовать темпу блоков около 300 миллисекунд.

В доступных материалах нет доходности, просадки, проскальзывания, влияния комиссий или полных результатов риск-контроля. Поэтому пример показывает лишь возможность включить Jev в низколатентный торговый прототип. Он не подтверждает прибыльность стратегии, а скорость исполнения нельзя считать инвестиционным результатом.

В реальной системе лимиты позиций, стоп-лоссы, права доступа, проверка ордеров и обработка исключений должны оставаться под контролем детерминированного кода. Рискованные сделки не следует автоматически исполнять на основе единственного выбора модели.

2. Уровень информации: Jev классифицирует, оценивает и определяет границы

5. Классификация писем и обращений: недостаточно спросить только «к какой категории относится?»

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

Автор одного из показательных проектов сообщил, что обработал 500 писем за несколько секунд примерно за $0.035. Однако в исходном сообщении не раскрыты состав набора, определения категорий, точность и матрица ошибок, поэтому результат нельзя представлять как универсальный бенчмарк классификации почты.

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

• Choice: Какой команде следует назначить обращение в первую очередь?
• Score: К какому уровню срочности оно относится?
• Noul: Есть ли запрос на возврат, угроза чарджбэка, юридический риск или необходимость передать обращение человеку?

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

6. Семантическая блокировка рекламы: от совпадения с правилами к оценке содержимого

Традиционные блокировщики рекламы часто опираются на домены, селекторы и поддерживаемые списки фильтров. В демонстрации сообщества расширение последовательно проверяет DOM-элементы и их class, просит Jev определить, похож ли элемент на рекламу или на обычное содержимое страницы, а затем удаляет элементы, признанные рекламными.

Идея показывает, как семантическое суждение может дополнять правила. Даже если элемент не совпал с известным фильтром, модель может распознать рекламное намерение по тексту и структуре страницы.

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

7. Таблицы, управляемые намерением: название столбца становится задачей семантической оценки

В проекте с предиктивной таблицей само название столбца выступает вопросом. Например, при добавлении столбца Urgency система читает текст каждой строки, просит Jev определить её срочность и записывает результат обратно в таблицу.

Здесь Jev не создаёт формулу Excel. Вместо этого один столбец данных превращается в повторяющиеся задачи классификации или оценки. Подход можно применить к приоритету лида, настроению клиента, риску контента или теме обратной связи — характеристикам, которые трудно выразить фиксированной формулой.

В видео автора указано время обработки около 100 миллисекунд, но не раскрыты число строк, границы измерения, кэширование и стабильность оценок. Поэтому нельзя заключать, что любое название столбца автоматически превращается в надёжную «умную формулу». Перед внедрением нужно зафиксировать смысл вопроса, проверить пограничные примеры и определить, какие результаты требуют участия человека.

8. Пропуск спонсорских вставок YouTube: модель находит границы, код перематывает видео

YouTube Sponsor Detection разбивает субтитры видео на пронумерованные строки. Jev определяет, какие строки относятся к спонсорскому содержимому, а также где начинается и заканчивается вставка. Затем программа сопоставляет номера строк временным меткам и управляет перемоткой плеера.

Если у видео нет пригодных субтитров, аудиорежим сначала использует сервис вроде Deepgram для расшифровки. Иными словами, Jev не слушает аудио напрямую и не управляет плеером. Его задача — семантическая оценка текста и определение границ.

Автор описал проект как открытый BYOK-прототип стоимостью около $0.005 на одно видео. Цена меняется в зависимости от длины субтитров, аудиорежима и сервиса расшифровки, а независимого теста точности в открытых материалах нет. У автоматического пропуска также есть два практических риска: субтитры могут быть недоступны, либо обычная речь может быть ошибочно принята за спонсорскую вставку.

Проект показывает типичное разделение труда: модель определяет семантические границы, а детерминированный код рассчитывает время и управляет воспроизведением.

3. Уровень процессов: Jev работает как промежуточный компонент принятия решений

9. Сжатие контекста Agent: решить, что сохранить, вместо свободного пересказа

По мере того как Agent вызывает инструменты, журналы терминала, результаты поиска и содержимое файлов быстро заполняют контекстное окно. Частый подход — попросить генеративную модель переписать историю в виде краткого резюме. fast-jev-compaction использует другой путь: сначала сопоставляет вызовы инструментов с их результатами, затем просит Jev решить, какие данные нужно сохранить полностью, сократить или удалить, после чего код выполняет конкретную обрезку.

Такой подход уменьшает свободное переписывание и упрощает отслеживание удалённых данных. Но «быстро обрезает» не означает «улучшает все последующие задачи». В оценке переноса Hermes сообщалось примерно о 1.4 секунды на сжатие, сохранении около 115K token и 75.5% по метрике восстановления, при этом отдельно использовалась базовая линия с восстановлением через поиск. Результат зависит от тестового набора, бюджета Token, способа переноса и возможности снова найти удалённые сведения. Его нельзя превращать в общий вывод, что любой Agent будет экономить в долгосрочной перспективе.

Оценивать нужно всю цепочку задачи. Повторяет ли Agent поиск после удаления? Забывает ли ограничения пользователя? Повторяет ли предыдущую ошибку, потому что сведения о ней исчезли? Если последующее восстановление стоит дороже, более быстрое сжатие может не снизить общие затраты.

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

10. json-render: выбор компонентов и связей вместо свободной генерации всего интерфейса

В описании реализации Jev для json-render генерация интерфейса разбита на два этапа. На первом определяется, какие компоненты нужны и в каком количестве. На втором задаются отношения родитель–потомок и порядок. Затем код создаёт и проверяет JSON и передаёт его рендереру для сборки интерфейса.

Это заметно отличается от запроса к универсальной модели написать всю страницу HTML или JSON одним ответом. Компоненты, привязки и действия выбираются из ограниченных множеств. Jev в основном определяет структуру, а код гарантирует соответствие результата протоколу рендеринга.

Такой подход снижает риск непарсируемого свободного текста, но «структура валидна» ещё не означает «интерфейс правильный». Компоненты могут быть выбраны неверно, иерархия может не соответствовать намерению пользователя, текст всё ещё может потребовать генеративной модели, а итоговый дизайн может оказаться неудобным или непривлекательным. В документации реализации также ограничены число элементов, добавляемых за один пакет, количество оценок и максимальная глубина. Поэтому метод лучше подходит для сборки интерфейса из конечной библиотеки компонентов, чем для неограниченного проектирования произвольных продуктовых страниц.

Какие выводы дают эти десять проектов?

Хотя проекты относятся к браузерам, видео, почте, таблицам, играм и UI, их внутренняя структура удивительно похожа:

1. Состояние можно подготовить. DOM страницы, субтитры, письмо, игровое состояние или журнал инструмента можно представить как текст, JSON или массив.
2. Ответ можно ограничить. Следующее действие, категория, уровень риска или решение о сохранении можно выразить конечным набором вариантов, шкалой или вероятностью.
3. Код знает, что делать с результатом. Для клика, удаления, перемотки, ранжирования, записи в таблицу или передачи человеку существует явная логика исполнения.
4. У ошибок есть путь отката. Если модель не уверена, API не отвечает или риск слишком высок, система может остановиться, повторить запрос, вызвать универсальную модель или привлечь человека.

Это и есть наиболее подходящее разделение ролей между Jev и универсальной LLM. Jev берёт на себя частые одношаговые семантические решения с понятными границами. Универсальная модель продолжает генерировать текст, предлагать новые планы, выполнять сложные рассуждения и объяснять результат.

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

Пять вещей, которые нельзя пропустить перед запуском

Во-первых, проверяйте формулировки вопросов как код. Результат Jev сильно зависит от вопроса и критериев. Неясный или противоречивый вопрос, а также несколько скрытых в одной формулировке суждений могут вернуть типизированный, но неверный для бизнеса ответ.

Во-вторых, калибруйте пороги на собственных данных. Вероятности и пороги из демонстраций нельзя просто перенести в продакшен. Разные языки, типы контента и уровни риска нужно тестировать отдельно.

В-третьих, предусмотрите деградацию при задержках и сбоях. Сетевой запрос может завершиться по тайм-ауту или ошибкой. Система должна заранее знать, означает ли сбой разрешение, блокировку, повтор или передачу человеку, а не воспринимать ошибку API как ответ «нет».

В-четвёртых, не основывайте рискованные действия на одном суждении модели. Необратимые операции — торговля, удаление данных, блокировка аккаунтов или публикация чувствительного к требованиям контента — должны сохранять детерминированные правила, второе подтверждение и журнал аудита.

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

Заключение

Jev лучше всего использовать не вместо чат-модели, а в тех точках программы, которые раньше было трудно выразить через if/else, но слишком дорого каждый раз отправлять в большую генеративную модель.

Browser Use позволяет ему выбирать следующее действие в браузере. Почтовая система может использовать его для маршрутизации и сигналов эскалации. YouTube-прототип просит определить границы спонсорской вставки. json-render применяет его для выбора связей компонентов, а сжатие контекста — для решения, какая история заслуживает места в окне. Эти приложения работают не потому, что Jev в одиночку выполняет всю задачу, а потому, что разработчики вместе проектируют состояние, варианты, логику исполнения, пороги и пути отката.

Jev приносит наибольшую пользу, когда границы решения ясны, результат можно ограничить, а код умеет надёжно его обработать. Если же нужны длинный текст, многошаговое рассуждение, открытое планирование или объяснимый вывод, универсальная LLM по-прежнему незаменима.