Jev от TypeSafe AI не генерирует текст. Модель получает состояние и набор вопросов, а возвращает типизированные ответы с вероятностями вроде is_confidential: true, probability: 0.98. Такой ответ можно сразу подставить в условие, без парсинга JSON из свободного текста и повторных попыток. LangGraph от LangChain добавляет оркестрацию: граф состояний, узлы, условные рёбра, чекпоинты, human-in-the-loop и трассировку в LangSmith. Связка даёт паттерн, в котором рабочим процессом владеет код, а модель отвечает только за узкие семантические решения.
Цифры, на которые ссылается TypeSafe: на узких задачах маршрутизации и классификации Jev до 200 раз быстрее и до 400 раз дешевле ведущих LLM. Это замеры вендора, и относятся они к выбору из заданных вариантов, а не к генерации текста. В примере с юридическим ревью документов классификация страниц с Jev прошла в 5-6 раз быстрее, чем с Sonnet.
Ниже устройство модели, встраивание в граф LangGraph, источник разницы в скорости и границы, за которыми подход не работает.
Что такое Jev и почему это не очередная LLM
Jev это decision model, её же называют system one model. Она оценивает состояние и распределяет вероятности между вариантами, которые задал разработчик. Текста на выходе нет вообще. В блоге LangChain формулировка звучит так:
Unlike traditional LLMs, Jev doesn't generate text. It makes decisions your code can act on directly.
Механика вызова простая: вы передаёте состояние (страницу документа, сообщение пользователя, текущий шаг агента) и список вопросов. В ответ приходят типизированные значения с вероятностями. Формат ответа задан заранее, поэтому код ветвится предсказуемо, а не угадывает, что имела в виду модель. Оригинальный разбор паттерна опубликован в блоге LangChain.
Под капотом, по описанию TypeSafe, работает модель, обученная возвращать калиброванные решения. Разбор примитивов Choice, Noulli и Score и метода пост-трейнинга RLCD есть в отдельном материале про AI-примитивы в коде.
Чем Jev отличается от LLM: генерация текста vs типизированные решения
Генеративная модель выдаёт текст, даже когда от неё нужен один класс. Дальше начинается знакомая инженерия: схема ответа, инструкция «отвечай только JSON», обработка случаев, когда модель добавила пояснение перед фигурной скобкой, повторы при ошибке парсинга. Каждый такой шаг добавляет токены, задержку и точки отказа.
Jev убирает этот слой. Вместо промпта «определи, конфиденциальна ли страница» и разбора ответа код получает структуру вида {is_confidential: true, probability: 0.98} и сразу сравнивает вероятность с порогом. Вариант вне заданного списка модель выдать не может: пространство ответов закрыто разработчиком.
Второе отличие, которое часто важнее скорости: вопросы можно задавать пачкой к одному состоянию. Три независимых вопроса к странице обрабатываются вместе, и время ответа почти не растёт. Для пайплайна, где на каждом документе нужно пять-шесть проверок, это заметная экономия.
System one model: скорость и стабильность вместо рассуждений
Термин system one model отсылает к быстрым интуитивным решениям: модель не строит длинную цепочку рассуждений, а сразу выдаёт ответ. Рассуждения и планирование остаются за LLM, Jev берёт на себя распознавание ситуации и выбор из вариантов.
Вторая характеристика, отличающая его от генеративных моделей, это стабильность. Модель спроектирована так, чтобы возвращать одинаковый ответ на одинаковый вход при повторных запусках. В раннем эксперименте Jev-as-a-judge оценки почти не двигались на протяжении 100 прогонов, меньше, чем у любого протестированного LLM-судьи. Подробнее про этот тест и разброс оценок: Jev-as-a-judge.
Для продакшна это не мелочь. Когда узел агента даёт то один класс, то другой на одном и том же документе, отладить систему почти невозможно: ошибка не воспроизводится. Стабильный ответ превращает такой узел в подобие обычной функции, которую можно покрыть тестами.
LangGraph как оркестратор: код владеет процессом, модель принимает решения
LangGraph это оркестратор от LangChain. Разработчики описывают его как способ сочетать решения модели с детерминированным кодом в системах, которые остаются надёжными и наблюдаемыми. Разделение ролей здесь жёсткое: граф, переходы и условия описывает разработчик, а Jev вызывается только там, где обычному коду не хватает семантики. Определить категорию, выбрать инструмент, решить, нужно ли вмешательство человека. Интеграция с LangChain через TypeSafeClassifier и middleware разобрана в отдельной статье про Jev и LangChain.
Состояние, узлы и рёбра: как устроен граф агента
Три понятия, без которых не читается ни один пример на LangGraph:
- состояние (state): разделяемые сведения, которые передаются между шагами. Для ревью документа это текст страницы, номер документа, уже принятые решения;
- узлы (nodes): функции и вызовы моделей. Jev здесь обычный узел, который получает состояние и возвращает типизированный ответ;
- рёбра (edges): переходы между узлами. Часть из них условные, то есть выбираются по значению в состоянии.
Jev в такой схеме не управляет потоком. Он поставляет значение, по которому код выбирает ребро:
decision = jev.classify(page_text, questions)
if decision.probability < 0.9:
next_node = "llm_deep_review"
elif decision.label == "needs_signature":
next_node = "lawyer_review"
else:
next_node = "auto_approve"Это псевдокод, он показывает логику, а не конкретный API. Смысл в том, что ветвление остаётся обычным кодом: его видно в графе, его можно залогировать, протестировать и объяснить аудитору.
Чекпоинты, human-in-the-loop и трассировка: что даёт продакшн-рантайм
Три возможности, которые чаще всего решают, доберётся ли агент до продакшна:
- чекпоинты сохраняют состояние графа на каждом шаге. Если процесс упал или был остановлен, выполнение продолжается с последней точки, а не с нуля;
- human-in-the-loop позволяет прервать граф и дождаться решения человека. В юридическом кейсе это финальное подтверждение спорных страниц;
- трассировка в LangSmith показывает путь по графу, входы и выходы каждого узла. Когда решение выглядит странно, видно, на каком шаге и с какой вероятностью оно принято.
TypeSafe описывает свою философию коротко: строить «prod, not god», где код владеет рабочим процессом, а AI обрабатывает узкие структурированные решения. LangGraph подходит под эту формулу инструментами рантайма, а Jev закрывает слой решений внутри неё.
Пример: юридическое ревью документов с Jev и LangGraph
Кейс, который приводит LangChain: Jev классифицирует страницы юридических документов по трём вопросам, а LLM и юрист подключаются только на исключениях. В тестах классификация с Jev оказалась в 5-6 раз быстрее, чем с Sonnet. Детали методологии в публикации не раскрыты, поэтому цифру стоит читать как порядок величины, а не как гарантию для любого корпуса документов.
Три вопроса для классификации страниц
Точные формулировки вопросов в источнике не приводятся, но структура понятна: у каждого вопроса закрытый набор ответов, и вопросы не зависят друг от друга. По смыслу это проверки вида «есть ли на странице персональные данные», «требуется ли подпись», «ссылается ли страница на другие документы». Ответ приходит как вариант плюс вероятность, и код раскладывает страницу по маршрутам: автосогласование, доработка, ручная проверка.
Три вопроса к одной странице уходят в Jev одним вызовом и считаются параллельно, поэтому четвёртая и пятая проверки почти не увеличивают задержку. Здесь подход выигрывает у генеративной модели сильнее всего: у LLM каждая дополнительная проверка это ещё один проход по тексту страницы.
Когда подключаются LLM и юрист
Маршрутизация строится на пороге вероятности. Высокая уверенность означает автоматическое решение. Промежуточная зона уходит в LLM, которая читает страницу внимательнее и разбирает неоднозначные места. Низкая уверенность или спорный случай достаётся юристу.
Порог задаёт разработчик, и это ключевая точка настройки. Слишком высокий порог отправляет к LLM почти всё, и экономия исчезает. Слишком низкий пропускает ошибки в автоматическую обработку. Как подбирать порог на своих данных, разобрано в материале про 16 000 вызовов Jev, где модель тестировали как фильтр перед более дорогим классификатором.
Производительность и стоимость: что стоит за цифрами 200x и 400x
Заявленные показатели из бенчмарков TypeSafe: на узких задачах маршрутизации и классификации Jev до 200 раз быстрее и до 400 раз дешевле ведущих LLM. Публикация LangChain приводит эти же цифры со ссылкой на данные вендора. Обе величины относятся к задачам выбора из заданных вариантов. Генерацию текста, длинные рассуждения и работу с открытыми вопросами они не описывают.
Почему узкие задачи дают такой выигрыш
Генеративная модель порождает текст токен за токеном. Распределение вероятностей считается на каждом шаге декодирования, и это самая дорогая часть инференса. Если задаче нужен один класс из пяти, модель всё равно напишет объяснение, оформит ответ и иногда повторит вопрос. Всё это оплачивается по токенам выходного текста.
Jev не порождает последовательность. Он один раз оценивает состояние и выдаёт распределение по вариантам. Вычисления заканчиваются там, где LLM только начинает писать. Отсюда разница в задержке, а разница в цене следует за ней: платить за токены вывода не нужно.
Цифры 200x и 5-6x не противоречат друг другу, они измерены в разных условиях. 200x это бенчмарк на коротких узких решениях, 5-6x это конкретный пайплайн ревью страниц, где есть чтение длинных документов, три вопроса и накладные расходы всего графа. Чем длиннее контекст, тем скромнее выглядит выигрыш.
Ограничения и риски: где Jev не заменит LLM
- Jev не пишет текст. Пересказ, суммаризация, генерация писем и любые открытые формулировки остаются за LLM.
- Многошаговые рассуждения и планирование модель не ведёт: это не её роль в архитектуре.
- Цифры производительности взяты из бенчмарков TypeSafe. Переносить их на свой корпус документов без проверки нельзя.
- Пример с юридическим ревью опубликован без деталей методологии: неизвестно, как считали время, какие документы попали в выборку и как размечали правильные ответы.
- Порог вероятности каждый подбирает сам, и от него зависит, сколько ошибок уйдёт в автоматику.
- Продукт молодой, поэтому перед продакшном стоит отдельно проверить доступность, лимиты и условия хранения данных.
Как это меняет архитектуру агентов: от монолитных LLM к гибридным системам
Классический агент строится вокруг одной большой модели, которая и планирует, и выбирает инструмент, и формулирует вывод. Такой агент плохо тестируется: поведение меняется от прогона к прогону, а стоимость растёт вместе с длиной контекста. Гибридная схема переворачивает приоритеты. Поток решений описан в коде, а модель вызывается в точках, где нужно понимание смысла: определить тип обращения, выбрать маршрут, оценить риск.
Открытые задачи никуда не исчезают, они остаются за LLM. Меняется их доля: вместо каждого шага генеративная модель работает только на исключениях и на участках, где нужен текст. В юридическом кейсе это выглядит как поток страниц через Jev с редкими остановками на LLM и человека.
Код владеет рабочим процессом: практические следствия
- граф переходов видно целиком, поэтому логику можно обсуждать с бизнесом, а не показывать промпт;
- узлы тестируются отдельно: узел с Jev проверяется набором размеченных примеров, а не сравнением двух текстовых ответов;
- стоимость считается заранее: число вызовов Jev и LLM задано структурой графа, а не поведением модели;
- промпт-инжиниринг сжимается до набора типизированных вопросов и порогов;
- сбои локализуются одним узлом, а чекпоинты позволяют продолжить процесс с места ошибки.
Когда стоит попробовать Jev в своём агенте
Признаки, что подход подойдёт: в агенте есть повторяющиеся шаги классификации или маршрутизации, набор возможных ответов закрыт и известен заранее, важны задержка и цена на тысячу решений, а нестабильность LLM уже мешала отладке.
Начать разумно с малого: собрать граф на LangGraph, оставить LLM на открытых шагах, заменить один узел на Jev и сравнить три метрики: задержку, стоимость на 1000 решений и совпадение с разметкой человека. Порог уверенности подбирается по своим данным, потому что калибровка на чужом датасете ничего не говорит о вашем.
Обратный случай тоже стоит держать в голове. Если задача требует связного текста, длинных рассуждений или ответа в свободной форме, Jev в ней бесполезен: он вернёт выбор из вариантов, а варианта «написать абзац» в его списке нет.