В последние два дня, если вы регулярно чистите технологические круги и сообщество разработчиков, большая вероятность, что уже Яв Имя пробилось на экран.
Странно, что она выглядит совсем не так, как «большая модель», которую мы знаем.
Он не будет разговаривать с вами, не отвечает за написание статей, и не подходит для того, чтобы он написал фрагмент кода в прямом эфире.Трудно даже воспринимать его как продукт, подобный ChatGPT или Claude.
Но именно такая модель «ничего не писать» быстро привлекла внимание сообщества разработчиков в последние годы.
Причины очень просты:
Jev не для того, чтобы писать ответы за людей, а для того, чтобы выносить суждения за процесс.
Если традиционные большие модели умеют «генерировать», то Jev пытается решить другой тип проблем, которые в программных системах имеют огромное количество, но часто игнорируются:
Что выбирать дальше?
Это может показаться небольшим изменением, но на самом деле это может быть очень важное направление в архитектуре AI Agent.
А что же такое Джев?
Сначала рассмотрим несколько вопросов, которые легко запутать.
Jev из стартапа AI в Сан-Франциско TypSafeЭто замкнутая модель.
Это отличается от позиционирования продукта ChatGPT и Claude, и это не просто замена традиционной модели чата на упаковку API.
С самого начала Jev был направлен на очень узкий круг задач:
Позвольте моделям быстро классифицировать, выбирать, судить и оценивать.
Таким образом, вы не будете использовать это как обычный LLM, чтобы сделать:
«Помоги мне написать статью об ИИ».
В чем он действительно хорош:
«Это сообщение пользователя - вопрос о возмещении денег, логистике или другом вопросе? »
или:
«Какая кнопка на этой странице лучше всего соответствует текущей задаче? »
Или еще:
«Должен ли этот вывод проходить аудит? »
Другими словами:
Традиционная большая модель больше похожа на говорящего эксперта, а Джев больше похож на модуль высокоскоростного принятия решений.
В настоящее время Jev предоставляет услуги в основном через API и не имеет публичных весов модели.Таким образом, большинство связанных проектов, которые можно увидеть на GitHub, являются приложениями и инструментами, построенными разработчиками вокруг API Jev, а не весом с открытым исходным кодом самой модели Jev.
Во-вторых, самое главное отличие: он не отвечает за «писывание».
Самый простой способ понять Jev - это сравнить традиционный LLM с Jev вместе.
Предположим, что ваша программа получила сообщение о поддержке клиентов:
Когда вы мне вернете деньги? »Я ждал уже неделю! »
Если вы используете ChatGPT или Claude, вам обычно нужно сказать модели:
- Анализ намерений пользователей
- Судить эмоции.
- Классификация экспорта
- Возвращение в заданном формате JSON
Наконец, программа извлекает результаты из текста, генерируемого моделью.
Проблема заключается в том, что:
Программа может знать только одну вещь:
refund
или:
true
И даже:
0.93
Предыдущий длинный анализ является дополнительной стоимостью для процедуры.
Мысли Евгения были противоположными.
Поскольку программа в конечном итоге требует только одного решения, не позволяйте моделям генерировать лишний текст.
И это самое главное, что заслуживает внимания Джева.
В-третьих, он решает главным образом три категории проблем.
Если рассматривать Jev как API, а не как чат-бота, то его возможности можно легко объяснить тремя типами.
1.Вопрос: да или нет
Первая категория - булевой суд.
Например:
«Содержит ли этот комментарий нападки на сотрудников службы поддержки клиентов? »
Модели не должны объяснять причины, и не должны писать анализ.
Он напрямую дает вероятность, например:
true: 0.94
false: 0.06
После получения результатов процедуры, вы можете самостоятельно решить:
confidence > 0.8
Затем запускается соответствующий процесс.
Это особенно удобно для проверки контента, фильтрации спама, автоматического отвлечения и т. д.
2.Выбор: Выберите один из фиксированных вариантов
Вторая категория более близка к традиционным задачам классификации.
Например, система обслуживания клиентов предусматривает:
0 = 账单问题
1 = 物流问题
2 = 退款问题
3 = 其他
Задача модели заключается не в создании самостоятельной категории, а в том, чтобы:
Выбирайте между этими вариантами.
Это очень важно для инженерной системы.
Традиционный LLM часто требует прохождения запросов Prompt:
"Просьба выполнить экспорт в строгом соответствии с форматом JSON."
Но модель, в конце концов, генерирует текст, и теоретически все еще возможно:
- Дополнительное объяснение.
- Ошибка в формате JSON
- Создание несуществующей категории.
- Экспорт меток с различным написанием
Модель с фиксированными опциями может напрямую ограничивать выходное пространство набором кандидатов, заданных разработчиком.
Для программы это означает большое разница:
ИИ больше не отвечает за «пись результатов», а за «выбор результатов».
3.Оценка: присвоение оценочной оценки объекту
Третья категория - это баллы.
Например, вы хотите оценить эмоциональную интенсивность сообщения клиента:
1 = 非常平静
2 = 有些不满
3 = 明显不满
4 = 愤怒
5 = 极度愤怒
Модель возвращает не анализ эмоций, а все распределение баллов.
Таким образом, программа может разработать свою собственную стратегию:
- 1 - 2: Автоматическая обработка
- 3: Общий сервис заказчиков
- 4 - 5: Модернизация ручного руководителя
Он несет ответственность за суждение.
Оперативные правила по-прежнему регулируются процедурами.
На самом деле, это очень важная инженерная идея.
По-настоящему интересно: один ввод позволяет ответить на множество вопросов одновременно.
Еще одна особенность Jev заключается в том, что можно одновременно принимать несколько решений вокруг одного и того же ввода.
К примеру, на рабочем заказе по обслуживанию клиентов, вы можете быть заинтересованы одновременно:
- Какой бизнес-категория?
- Какова степень экстренной ситуации?
- Каковы настроения клиентов?
- Нужна ли ручная проверка?
Традиционные схемы могут требовать нескольких вызовов модели.
Эта модель, ориентированная исключительно на принятие решений, позволяет решать эти вопросы вместе.
Таким образом, вход больше не является:
Прочитать один раз → Создать ответ → Прочитать еще раз → Создать ответ снова
Больше похож на:
Читать один раз → выполнять несколько суждений одновременно.
Для систем, которые должны обрабатывать большое количество событий, такой дизайн может быть более важным, чем простое стремление к тому, «будет ли модель написана лучше».
5 Почему это так быстро?
Здесь речь идет о фундаментальном различии в методах рассуждения между Jev и традиционной генеративной большой моделью.
Знакомые нам модели, такие как GPT, Claude и другие, по своей сути сильно зависят от авторегрессивной генерации.
Проще понять:
Модель генерирует первый токен, затем генерирует следующий токен на основе предыдущего, а затем продолжает генерировать.
Если попросить его написать отрывок, он должен постоянно декодировать токен-за-токен.
Однако для многих программных решений не требуется создавать десятки, сотни или даже тысячи токенов.
Предположим, что проблема заключается в следующем:
«Какую из 30 кнопок на этой странице следует нажать? »
Результаты, которые на самом деле требуются программой, могут быть:
button_17
Так почему же модель должна думать, а затем организовывать язык, а затем выводить объяснение?
Именно в этом и пытается проникнуть Евгений.
Ограничить пространство вывода ИИ ограниченным пространством для принятия решений.
С инженерной точки зрения, это эквивалентно:
«Создание ответа»
Превратится в:
"Расчитывать вероятность и делать выбор среди ограниченных кандидатов".
Задачи просты, выход короткий, и логическая связь, естественно, может быть значительно сжата.
Таким образом, основной показатель, который официально подчеркивает Джев, не «как долго он может писать», а:
Сколько задержек, сколько вычислений и сколько денег требуется для принятия решения.
Реальный убийца может быть не «быстрым», а «вероятным».
Если у Jev есть только одна особенность:
«Классификационная модель быстро».
На самом деле это не так удивительно.
По-настоящему интересно, что он пытается решить еще одну давнюю проблему:
Доверенность модели на самом деле?
Традиционные классификационные модели часто сталкиваются с проблемой:
Модель вполне убеждена, что она права.
Но на самом деле, это может быть очень неправильно.
Например:
预测：退款问题
置信度：99%
Результаты после ручного осмотра обнаружили:
Пользователи на самом деле задают вопросы о логистике.
Если такая модель будет помещена в автоматизированную систему, то проблема будет сложной.
Потому что инженер может написать:
confidence > 95%
→ 自动执行
Если степень доверия не калибрована, этот порог не имеет большого смысла.
Так что одно из направлений, на которое выделяет Джев,Вероятностная калибровка。
Идеальное состояние:
Модель говорит, что она имеет 80% уверенности, и в долгосрочной перспективе она должна иметь приблизительно 80% точности.
Таким образом, вероятность вывода модели действительно имеет инженерную ценность.
Потому что ИИ не просто говорит программе:
«Я думаю, что ответ - А. »
Также он говорит программе:
"Насколько я уверен в А."
На самом деле, разница между этими двумя очень велика.
Как это связано с агентом?
Возможно, именно это и является истинной причиной того, что Jev в последнее время привлекал внимание разработчиков.
В прошлом мы говорили о агентах ИИ и часто обращали внимание на «мозг»:
- Увеличение способности рассуждать
- Более широкий контекст
- Более длительный процесс мышления
- Более сложные вызовы инструментов
Но действительно работающий агент, на самом деле, должен принимать множество очень мелких решений.
Например:
Не хотите вызвать поиск?
Какой инструмент переместить?
Выполнено ли текущее задание?
Доверен ли этот результат?
Хотите продолжать цикл?
Каким рабочим потокам принадлежит этот запрос пользователя?
Ни один из этих вопросов не кажется сложным.
Но агент может делать это десятки, даже сотни раз в минуту.
Если каждый раз вызывать тяжелый вес LLM, задержки и затраты быстро накапливаются.
В этом случае у таких моделей, как Джев, есть свое место:
Большие модели отвечают за сложные рассуждения, а небольшие модели отвечают за высокочастотные решения.
Возможно, это больше соответствует реальной архитектуре программного обеспечения, чем мысль о «решении всех проблем одной моделью».
Как разработчики начали использовать его?
В настоящее время в общинах уже проводятся некоторые весьма репрезентативные попытки.
1.Браузер-агент: позволяйте ИИ отвечать за «где нажать»
Автоматизация браузера - типичный сценарий.
Когда агент открывает веб-страницу, он часто сталкивается с десятками или даже сотнями элементов DOM.
Реальная проблема состоит в том, что:
«Какой элемент я должен выбрать в текущей задаче? »
Естественно, это вопрос выбора.
В сообществе Browser Use появился Jev Ultrafast Проект, использующий Jev в процессе принятия решений браузерного агента.
Browser-use /jev-ultrafast Проект GitHub
Идея заключается не в том, чтобы Jev выполнял весь браузерный агент, а в том, чтобы он взял на себя очень специфический уровень:
Быстро выберите следующее действие.
Создание сложных текстов по-прежнему можно передать традиционной модели.
По сути, эта структура является весьма репрезентативной:
Для агента не обязательно требуется модель, которая отвечает от начала до конца.
2.Игра Агент: Высокочастотные решения
Игры - еще одна сцена, которая очень подходит для этой модели.
Предположим, что искусственный интеллект играет в Doom, и ему может потребоваться судить каждый момент:
- Влево или направо?
- Огонь открывается?
- Хочешь поменять оружие?
- Убегают ли?
- Продолжается ли движение вперед?
Эти действия не обязательно требуют длинных аргументов.
Это больше похоже на:
Введите текущее состояние → выберите следующее действие.
Если модель может многократно принимать такие решения с очень низкой задержкой, то открываются новые возможности для сценариев в реальном времени, которые традиционные LLM трудно охватить.
3.Мартировка агента: решить, «кто будет вызывать дальше»
Эта возможность особенно непосредственна в многоагентных системах.
Предположим, что в системе есть:
搜索 Agent
代码 Agent
数据库 Agent
客服 Agent
人工审核
После того, как пользователь входит, система должна определить:
Кому следует направить эту просьбу?
Это и есть классификационная тема.
Дальше:
Действующий агент должен вызывать инструменты поиска или базы данных?
Еще одна тема выбора.
Если каждый маршрутизатор выполняет большую языковую модель, то агент может потратить много времени на «решение, что делать дальше».
В то время как высокоскоростная модель, специализирующаяся на маршрутизации, может отделять этот уровень.
Девятое, это означает, что будущие системы ИИ могут быть все более «уровневыми».
В прошлом любили говорить:
«Какая модель самая сильная? »
Но для реальной производственной системы проблема может постепенно превратиться в:
Какая модель отвечает за какую работу? »
Типичная система AI может выглядеть так:
用户请求
↓
高速决策模型
↓
┌────────┬────────┬────────┐
↓ ↓ ↓ ↓
搜索工具 数据库 Agent 人工审核
↓
复杂任务
↓
大型推理模型
↓
最终结果
В этой структуре:
Большие модели больше не берут на себя все.
Он отвечает за то, что действительно требует рассуждения, творчества и генерирования.
В то время как высокоскоростные модели отвечают за большое количество мелко разбитых потоков управления.
С точки зрения разработки программного обеспечения, это вполне естественно.
Потому что компьютерные программы не работают на естественном языке.
Большая часть бизнес-логики в конечном итоге можно свести к следующему:
if
else
switch
route
score
filter
То, что делает Джев, по сути, пытается взять часть этого if / switch Стать более «умным».
10. Но он также не всемогущ.
Здесь необходимо особое предупреждение:
Ценность Jev заключается именно в его специализации, а специализация также означает ограничения.
Он не является заменой ChatGPT или Claude.
Если задание требует:
- Длинное письмо
- Создание сложного кода
- Многораундный диалог
- Открытые вопросы и ответы на знания
- Длинная цепочка рассуждений
- Точные математические вычисления
Таким образом, такая модель, ориентированная исключительно на принятие решений, не подходит для непосредственного выполнения всей работы.
Кроме того, такие задачи, как языковое покрытие, сложные рассуждения, математика и арифметика, отношения дат и т. д., также должны быть проверены с помощью собственных наборов тестов, а не только на основе материалов для пропаганды моделей.
Еще одна проблема, которую легко игнорировать:
Модели могут ошибаться.
Даже если модель дает высокий уровень доверия, это не означает:
«Процедура может быть исполнена без каких-либо условий»
В частности, касается:
- Возврат денежных средств
- Выплаты
- Удалить данные
- Изменение прав
- Операции с базами данных
Для этих высокорискованных действий следует сохранить традиционный контроль прав программного обеспечения, проверку правил и ручное подключение.
И он может отвечать за суждение.
Однако окончательные границы безопасности должны оставаться в руках процесса.
В чем же действительно интересное место в Явве?
Если мы понимаем, что Евгений:
"Более быстрая классификационная модель".
На самом деле, легко его недооценить.
Что действительно интересно, это то, что он ставит очень простой вопрос:
Нам действительно нужно иметь модель, которая будет писать длинные статьи и участвовать в каждом судебном процессе?
Во многих случаях ответ может быть отрицательным.
В зрелой системе агентов ИИ, не обязательно самые сложные рассудительные задачи, которые действительно требуют больших затрат.
Возможно, это просто множество мелких решений:
要不要搜索？
选哪个工具？
是不是垃圾信息？
属于哪个类别？
要不要继续？
需要不需要人工？
Каждая тема в одиночку очень проста.
Но если умножить их на миллионы вызовов, то затраты и задержки становятся реальной инженерной проблемой.
Именно в этом и стоит обратить внимание на модели Jev:
Вместо того, чтобы стать большим «мозг», он пытается стать нервными окончаниями в системе ИИ.
Письмо в конце
В последние два года отрасль ИИ стремилась к более крупным моделям.
Большее количество параметров, более длинный контекст, более сложные рассуждения, более мощные кодирующие способности.
Но когда ИИ действительно входит в программную систему, мы можем обнаружить:
Многие взаимодействия между компьютерами не требуют естественного языка.
Программа не нуждается в модели, чтобы написать для нее документ.
Может потребоваться просто:
true
или:
refund
или:
tool_7
Или еще:
confidence = 0.91
Это и самое интересное направление, которое представляет Jev.
Это не замена ChatGPT, и это не значит, что Клод может писать больше, чем кто-то.
Он пытается сделать еще одну вещь:
Превратить ИИ из «человека, который говорит» в «компонент программы, ответственный за принятие решений».
Если эта идея будет развиваться, то будущие приложения ИИ, возможно, больше не будут «супермодельным пакетом».
Скорее всего, это:
Один отвечает за мышление, один за создание, один за суждение, один за маршрутизацию, один за аудит.
Большие модели отвечают за сложные вопросы.
Маленькая модель отвечает за принятие решений высокой частоты.
Традиционный код отвечает за окончательные ограничения.
В совокупности все три составляют действительно долгосрочную программную систему ИИ.
Так что, если обязательно вспомнить Евгений одним словом:
ChatGPT дает людям ответы, а Jev делает выбор для программы.
Возможно, именно это и является причиной того, что в последнее время он вдруг привлекал внимание разработчиков.