Jev: куда в наших графах LangGraph поместилась бы модель, которая не пишет предложений

«Модель, которая никогда не пишет предложений» звучало как шутка, пока мы не посчитали, сколько предложений наш собственный стек генерирует без всякой необходимости. Пятнадцатого сентября TypeSafe AI представила Jev — первую модель класса «System One System One — новый класс моделей ИИ (первая — Jev от TypeSafe AI), которая вместо текста возвращает типизированное решение с калиброванной вероятностью — без генерации и разбора строки, поэтому работает значительно быстрее и дешевле обычной LLM. Полное определение →»: она получает фрагмент состояния программы и набор вопросов с заранее известным множеством ответов, а возвращает не текст, а типизированное решение с калиброванной вероятностью, за 70–500 мс. Вместо того чтобы читать это как ещё один релиз модели, мы прошли пять собственных графов LangGraph LangGraph — это инструмент для разработчиков, который позволяет строить ИИ-агентов с многошаговыми сценариями и ветвлением, а не с одним разовым ответом. Полное определение → — тех самых, что рендерим на страницах продуктов — узел за узлом и задали каждой точке решения один вопрос: это задача для Jev, это всё ещё работа для LLM LLM (Large Language Model) — это тип ИИ-модели, такой как лежит в основе ChatGPT, обученной на огромном объёме текста, чтобы понимать и генерировать человеческий язык. Полное определение →, или это вообще не решение модели.

Зачем эта статья

Можно было написать «мы протестировали новую модель от TypeSafe» — таких текстов после релиза будет десяток, и ни один не будет иметь отношения к нашему коду. Мы предпочитаем ответить на вопрос, который у нас действительно есть: у нас пять продакшен-агентов на LangGraph, у каждого свой граф управления, и в каждом графе есть места, где языковая модель не генерирует контент, а выбирает один из нескольких заранее известных вариантов. Jev нацелен именно на эту вторую категорию. Поэтому мы прошли граф за графом, выписали каждую такую точку и вынесли ей вердикт: кандидат, остаётся за LLM, или вообще не решение модели. Полная таблица — ниже, вместе с тремя причинами, почему мы пока ничего не переносим.

Что такое класс System One на примере Jev

Обычная LLM, даже вызванная как классификатор, делает то же самое, что и при генерации длинного текста: предсказывает токен Токен — это фрагмент текста, обычно часть слова: ИИ-модели измеряют в токенах и длину запроса, и стоимость, поэтому счёт приходит за токены, а не за вопросы. Полное определение → за токеном, последовательно, пока не получится строка, которую потом нужно распарсить обратно в структуру. Jev пропускает этот шаг. Он получает блок состояния и набор типизированных вопросов с закрытым множеством ответов, оценивает их все за один параллельный проход и возвращает значение и калиброванную вероятность для каждого варианта — без генерации строки, без разбора на выходе. Отсюда заявленная задержка end-to-end 70–500 мс и преимущество по стоимости в 40–200 раз против передовых моделей на этом классе задач.

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

Стоит быть точным в одной вещи. «Не может галлюцинировать» в материалах самой TypeSafe означает «не может вернуть значение вне заявленного типа», а не «не может ошибиться». Это гарантия формата, а не гарантия точности. На собственном бенчмарке из четырёх воркфлоу TypeSafe заявляет 67,8% точности — цифру, которую стоит держать рядом с каждым заявлением «без галлюцинаций Галлюцинация — это ответ ИИ, который звучит убедительно, но неправдив: модель заполняет пробел догадкой вместо того, чтобы признать, что не знает. Полное определение →», а не вместо него.

Цена и то, что ею пока нельзя посчитать

Jev стоит 0,042 доллара за миллион входных токенов, а выход бесплатный — формулировка самой TypeSafe: «too cheap to meter». Такой структуры цены нет ни у одной модели в нашем собственном калькуляторе стоимости агента: самая дешёвая позиция в нашей таблице цен, gpt-5.4-nano, стоит 0,20 доллара за миллион входа и 1,25 доллара за миллион выхода, а сам тип данных в коде калькулятора предполагает, что цена выхода всегда существует и больше нуля. Конкретно: чтобы посчитать экономию от перехода на Jev в нашем собственном инструменте, сначала нужно изменить структуру данных, которая его описывает. Это не аргумент против миграции — это пункт в списке того, что нужно сделать, прежде чем кто-то назовёт конкретную цифру экономии.

Наш стек: пять графов, двенадцать точек решения

На страницах продуктов мы публикуем диаграммы LangGraph пяти агентов: бухгалтерского ассистента, бюджетного ассистента, ассистента по e-marketing, оркестрации Оркестрация — это координация нескольких моделей, инструментов и агентов, чтобы они решали одну задачу в заданном порядке и передавали результаты друг другу. Полное определение → тестирования и базы правовых знаний. Мы прошли каждую и выписали каждый узел, где граф ветвится на заранее известное множество ответов — не каждый шаг обработки, а только точки, где кто-то (модель или обычный код) выбирает один из нескольких вариантов. Получилось двенадцать таких точек в пяти графах.

flowchart TB
  subgraph KEEP["Остаётся за LLM (оценка сгенерированного контента)"]
    K1["Корректен ли<br/>сгенерированный тест"]
    K2["Корректен ли<br/>сгенерированный чек-лист"]
    K3["Корректен ли исправленный<br/>правовой текст"]
  end
  subgraph CAND["Кандидат на модель решений (закрытое множество ответов)"]
    C1["Вызвать инструмент<br/>(на каждом шаге цикла)"]
    C2["Тип действия: ответ,<br/>чтение или запись"]
    C3["Какой из 7 специалистов<br/>берёт задачу"]
    C4["Тип сообщения"]
    C5["Покрывает ли база знаний<br/>вопрос"]
    C6["Намерение: вопрос<br/>или правка"]
  end
  subgraph SKIP["Не переносим или неясно"]
    S1["Подтверждение<br/>пользователя"]
    S2["Какой из 5 тестовых агентов<br/>(механизм неизвестен)"]
    S3["Фильтр персональных данных<br/>(fail-closed)"]
  end

Распределение неравномерное. Три точки — это генерация или оценка свободного текста, и там Jev предложить нечего: по определению он не генерирует текст. Шесть — закрытая классификация или маршрутизация с небольшим числом вариантов, ровно та задача, под которую спроектирован Jev. Оставшиеся три вообще не являются решением модели: подтверждение пользователя — это ввод от человека, а не вывод модели; фильтр персональных данных работает fail-closed, то есть обязан быть детерминированным по определению; а про один узел диаграмма просто не говорит, кто сегодня его решает.

Вердикт по каждому узлу

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

Диспетчеризация специалиста в ассистенте по e-marketing — самая часто вызываемая точка решения во всём стеке: она срабатывает на каждом сообщении пользователя, прежде чем подключится любой из семи специализированных агентов (контент, SEO, email, чек-листы, стратегия, аналитика, документы). Сегодня это решение принимает GPT-4o как часть вызова инструмента. Это ровно тот тип работы, о котором прямо говорят собственные материалы релиза TypeSafe: высокий объём, повторяющееся решение, заранее известный набор ответов.

Выбор агента в оркестрации тестирования выбирает одного из пяти специализированных агентов (генератор тестов, детектор багов, генератор чек-листов, советник по покрытию, детектор нестабильных тестов) в зависимости от того, что пришло на вход — изменение кода или PR. Диаграмма не говорит прямо, LLM это или обычная маршрутизация по типу триггера, поэтому мы считаем это условным кандидатом: если сегодня это LLM, Jev подходит; если это маршрутизация по метке PR, заменять нечего.

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

Самый интересный случай: порог вместо модели

Большинство «кандидатов» в этой таблице — сегодня вызов LLM, который можно заменить более дешёвым и быстрым вызовом. Покрытие — другое: судя по диаграмме, узел стоит сразу после «retrieve · cosine top-K» и решает, достаточно ли покрытия, чтобы ответить, или системе следует воздержаться и сказать «не знаю». Это похоже на обычный числовой порог по оценке косинусного сходства — подобранный вручную и, вероятно, не раз поправленный после того, как система либо ответила на то, чего не должна была касаться, либо без причины отказала.

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

Что остаётся за LLM и почему

Три точки мы сознательно оставляем как есть: оценку корректности сгенерированных тестов и чек-листов (циклы «valid? refine» в генераторе тестов и генераторе чек-листов) и проверку исправленного правового текста в базе знаний. У всех трёх формально закрытое множество ответов — два или три варианта, — так что на первый взгляд они подходят под Jev не хуже диспетчеризации в e-marketing. Разница в том, что модель должна оценить, чтобы прийти к этому ответу: не состояние системы, описанное полями и числами, а только что сгенерированный, свободный по форме контент — код теста, чек-лист, абзац исправленного правового текста. Оценка того, корректен ли такой текст, семантически согласован и не вносит ли новую ошибку, требует рассуждения над содержанием, а не классификации заранее известного состояния. Это ровно та граница, о которой прямо пишет сама TypeSafe: Jev — для решений над состоянием, а не для оценки свободного текста.

Три причины пока ничего не переносить

Даже для самых сильных кандидатов — диспетчеризации в e-marketing и покрытия в базе знаний — у нас есть три причины подождать, а не три причины отказаться.

Во-первых, 67,8% точности на собственном четырёхворкфлоу-бенчмарке TypeSafe — это цифра из их тестов, а не из нашего трафика, а при семиходовой маршрутизации ошибочное решение означает запуск не того специалиста, а не просто ответ похуже. Прежде чем что-либо переносить, нам нужен собственный тестовый набор на реальных сообщениях, а не чужой бенчмарк.

Во-вторых, фильтр персональных данных работает fail-closed — то есть при сомнении обязан блокировать, а не пропускать. Такой предохранительный барьер требует детерминированного, проверяемого поведения, а не калиброванной вероятности, которая по определению иногда ошибается. Даже если бы этот фильтр сегодня был построен на LLM — а диаграмма этого не подтверждает, — он всё равно не был бы первым кандидатом на замену вероятностной моделью.

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

Чего эта статья не решает

Честно: этот аудит построен на диаграммах, которые мы сами публикуем на страницах продуктов, а не на построчном чтении исходного кода каждого агента. Диаграмма говорит, что узел существует и куда ведут его ветви; она не всегда говорит, принимает ли сегодняшнее решение языковая модель, обычное условие в коде или regex-правило. Там, где узел стоит сразу после блока, явно описанного как вызов конкретной модели, предположение «это LLM» оправдано. Там, где это не так — как с выбором тестового агента, — мы прямо пометили это как неопределённость, а не угадали в ту сторону, которая сделала бы таблицу аккуратнее.

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

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

Итог

Jev попадает ровно в ту часть нашего стека, о которой мы редко пишем: не генерация текста, а тихие выборы между несколькими заранее известными вариантами, которые сегодня делает LLM просто потому, что более дешёвой альтернативы не было. Из двенадцати проверенных точек решения шесть — реальные кандидаты, три остаются за LLM, потому что оценивают свободный текст, а три вообще не являются решением модели или не должны им быть. Самый интересный вывод здесь не про стоимость и не про скорость: как минимум в одном месте — пороге покрытия в RAG RAG (Retrieval-Augmented Generation) — это когда ИИ сначала находит нужную информацию в ваших документах, а потом отвечает, опираясь на неё, а не на догадки. Полное определение → — переход на модель System One означал бы больше, чем замену движка: добавление вывода там, где сегодня есть только вручную подобранное число.