Jev и новый слой принятия решений для AI‑агентов

Почему модели System One могут отделять быстрые суждения от медленного рассуждения

Многие AI‑агенты используют языковую модель почти для всех своих решений. Языковая модель выбирает инструмент, оценивает результаты, решает, нужно ли продолжать, и в конце генерирует ответы. Гибко; однако этот процесс может быть дорогим, когда решения «да‑или‑нет» повторяются в больших масштабах. Unite.AI ранее обсуждал, как агентные рабочие процессы увеличивают количество вызовов модели, контекст и количество повторов. Каждое дополнительное решение может добавить время и деньги до того, как пользователям будет предоставлена полезная информация.

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

Что на самом деле делает Jev

TypeSafe запустила Jev в сентябре 2026 года, первая из их новых моделей System One. Jev не пишет прозу. Вместо этого вы отправляете ему состояние (например, сообщение поддержки и данные пользователя). Вы также отправляете один или несколько вопросов с предопределёнными типами ответов. Затем Jev отвечает типизированными ответами и вероятностями.

Согласно официальной документации компании, в ней описаны три примитива для принятия решений:

• Choice позволяет выбрать из предопределённых вариантов.
• Score позволяет оценить что‑то по упорядоченной рубрике.
• Noul оценивает вероятность того, что утверждение истинно.

Вы можете задать несколько независимых вопросов о том же состоянии в рамках одного запроса.

Например, представим, что вы решаете проблему службы поддержки. Система может попытаться определить, какая команда должна обработать этот случай. Она также может установить, насколько быстро нужно ответить, и проверить, запросил ли клиент возврат средств.

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

Сдвиг в архитектуре важнее, чем модель

Большинство этих дебатов сравнивают крупные модели с небольшими. Jev предлагает альтернативную границу. Некоторые шаги включают генерацию текста. Другие — узкие суждения, которые может использовать программное обеспечение.

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

Рисунок 1. Ограниченный путь принятия решений сохраняет пороги, разрешения и эскалацию в коде.

Существует сходство с маршрутизацией моделей, но есть критическое различие. RouteLLM принимает решения о том, какую из двух языковых моделей выбрать. Она выбирает между более сильной и более слабой моделью, чтобы сбалансировать качество и цену. Модель System One генерирует ограниченные суждения, которые код может использовать напрямую. Эти суждения могут поддерживать маршрутизацию моделей, а также другие решения внутри агента.

Почему петли агентов естественно подходят

Характер петлей агентов делает их особенно пригодными для выполнения множества суждений на очень мелком уровне. Эти суждения помогают достичь конечного результата. Другими словами, агентам приходится принимать множество \”маленьких\” решений после того, как пользователь отправил свой вопрос или запрос. Эти решения принимаются до того, как будет возвращён ответ или результат.

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

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

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

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

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

Означает ли типизация правильность?

Язык, используемый при формулировании заявлений о Jev, также должен быть тщательно подобран. Поскольку пространство вывода определяется заранее, модель не должна возвращать вымышленное поле или неразборчивый абзац. Это устраняет один тип сбоя; однако это не устраняет семантические ошибки. Ничто не мешает системе вернуть неверный отдел, присвоить неправильный уровень риска или заявить избыточную уверенность. Всё это может происходить при полном соблюдении типобезопасности.

TypeSafe’s own документация System One делает важное различие. Калибровка измеряется по группам предсказаний; она не гарантирует правильность отдельного предсказания. В продакшене это имеет последствия. Командам необходимо проверять, соответствуют ли предсказанные вероятности наблюдаемым результатам на их собственных данных.

Доказательства производительности пока ранние

TypeSafe сообщает о времени отклика от 70 до 500 миллисекунд. Он также упоминает значительные экономии затрат и ускорения в своих внутренних оценках рабочих процессов. Кроме того, TypeSafe указывает, что эти заглавные улучшения, вероятно, находятся ближе к верхнему пределу реальных достижений. TypeSafe’s публично доступное тестирование рабочих процессов использует эталонные вероятности, предоставленные другими передовыми моделями, а не истинные метки. Результаты хороши для формирования гипотез. Результаты не могут заменить независимый тест на реальной нагрузке.

Практический тест перед внедрением

Когда вы создаёте свой первый рабочий процесс принятия решений с ИИ, не выбирайте самые критические решения (например, медицинские одобрения или блокировки аккаунтов). Вместо этого выберите что‑то очень распространённое, обратимое и лёгкое для проверки другими членами команды. Это включает, но определённо не ограничивается маршрутизацией тикетов, категоризацией документов, выбором модели и низко‑рисковым контролем качества.

Четыре вопроса помогут вам оценить, будет ли это работать:

• Имеет ли вывод конечное число возможных ответов?
• Можете ли вы чётко сформулировать критерии суждения?
• Есть ли измеримые результаты? Отслеживайте предсказание, его вероятность, действие и последующие результаты. Регулярно проверяйте калибровку, сравнивая предсказанные вероятности с наблюдаемыми результатами.
• Есть ли у вас альтернативный план на случай сбоя автоматизированного процесса принятия решений? Определите конкретный момент, когда следует использовать модель рассуждения, запросить дополнительную информацию или привлечь человека.

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

Долгосрочный вывод

Если Jev добьётся успеха, изменится существенно или будет быстро заменён, одна вещь остаётся неизменной. Архитектурный вопрос остаётся открытым. Необходимо ли, чтобы каждое машинное решение представлялось в виде сгенерированного текста?

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

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