Как реализовать LLM-маршрутизацию и guardrails? Примеры совместной работы Jev и больших языковых моделей

Раскрытие интересов и доказательств: PandaNpc разрабатывает слой принятия решений Agent с использованием Jev. Ниже цитируются официальная документация TypeSafe, официальный cookbook, а также реальные вызовы Jev и калибровка на синтетических сценариях из нашего репозитория. Наша калибровка использует скриптовый фиктивный LLM provider и не может представлять реальный пользовательский трафик или производительность полного production-контура.

LLM-маршрутицию можно построить так: сначала Jev определяет, к какому классу относится запрос и насколько он рискован, а затем код решает, передать его обычной функции, специализированной LLM или на ручную проверку. Jev также можно поставить между поиском и генерацией для фильтрации доказательств или после вывода LLM для проверки результата. Он возвращает закрытые варианты, оценки и вероятности; открытые ответы, генерацию кода и длинные рассуждения по-прежнему выполняет LLM. Описание TypeSafe для кодирующих агентов прямо указывает, что Jev не может напрямую заменить чат-модель, стоящую за Claude Code или Codex.

В этой статье на примере клиентского запроса, конвейера вопросов и ответов RAG и наших собственных записей калибровки Agent объясняется, где именно две категории моделей передают работу друг другу и почему у результатов с низкой уверенностью должен быть чёткий путь обработки.

Что может определять Jev и за что продолжает отвечать LLM?

По состоянию на 23 сентября 2026 года на странице моделей TypeSafe указана стабильная модель jev-1.13.0. API принимает один state и набор questions и через POST /v1/systemone возвращает соответствующие структурированные answers. jev-latest в тот день указывал на 1.13.0, но псевдоним меняется вместе с версиями; системам, откалибровавшим пороги, следует фиксировать версию и записывать фактический ID модели из ответа.

У Noul нет отдельного поля confidence; нельзя напрямую записывать вероятность Noul как «уверенность модели». Score также не следует использовать для расчёта точных сумм. Суммы, сравнение дат, квоты и проверка прав должны оставаться в детерминированных программах; официальная документация перечисляет эти границы Jev 1.13.

Минимальная форма одного вызова

Приведённая ниже форма запроса соответствует официальной справке API; пример вопросов — это иллюстративная конфигурация, созданная для этой статьи, и в этой статье мы не проводили для неё онлайн-тестирование:

В JSON ниже используется английское сообщение клиента; по-русски клиент сказал бы: “По заказу произошло повторное списание средств, пожалуйста, помогите мне вернуть деньги.”

{
  "model": "jev-1.13.0",
  "state": {
    "message": "My order was charged twice. Please help me get a refund.",
    "account_note": "Customer asks about an order charge"
  },
  "questions": {
    "intent": {
      "type": "choice",
      "instructions": "What does state.message primarily request?",
      "criteria": {
        "refund": "Money returned for a charge",
        "information": "An explanation only",
        "other": "Neither option fits"
      }
    },
    "asks_refund": {
      "type": "noul",
      "instructions": "Does state.message explicitly ask for money back?"
    }
  }
}

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

Маршрутизация LLM с помощью Jev: три пути передачи

Официальный пример маршрутизации намерений TypeSafe сначала передаёт клиентский запрос Jev для определения намерения и сложности, а затем код распределяет его: проверка статуса заказа идёт в функцию базы данных; вопросы о продукте и возвраты/обмены идут в специализированные LLM, загруженные разными материалами; сложные жалобы или результаты с низкой уверенностью попадают в очередь ручной обработки. Именно так проще всего понять взаимодействие Jev и LLM: первый даёт структурированное суждение, вторая появляется только тогда, когда нужно сгенерировать объяснение или диалог.

При внедрении можно проектировать в следующем порядке, а не позволять модели свободно решать все действия:

1. Сначала определите пути: перечислите, какие запросы могут обрабатывать обычные функции, специализированные LLM и ручная проверка, и оставьте для Choice вариант other или аналогичный запасной вариант.
2. Поместите факты в state: слова пользователя, состояние аккаунта и записи о заказах должны быть отдельными полями; не принимайте текст веб-страниц неизвестного происхождения за системные инструкции.
3. Задавайте узкие вопросы по одному: для намерения используйте Choice, для риска или срочности — Score, для отдельного факта, который нужно подтвердить, — Noul. Официальная документация рекомендует оценивать несколько независимых вопросов с одним и тем же state параллельно в одном запросе.
4. Пусть код выполняет финальную маршрутизацию: сначала проверьте права и жёсткие правила, затем посмотрите вероятности Jev и пороги, откалиброванные для этого бизнеса; запросы с низкой уверенностью или без доказательств направляйте на ручную обработку или задавайте уточняющий вопрос.
5. Записывайте результаты и перепроверяйте: сохраняйте версию модели, версию вопросов, вероятности, итоговое направление и результаты ручных исправлений — только так можно понять, подходят ли пороги.

Источник: TypeSafe AI «Introducing System One Models & Jev», 2026-09-15. Четыре workflow созданы самой TypeSafe, метрики агрегированы с равным весом по workflow; методология оценки описана в TypeSafe workflow evals.

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

Генерация с дополненной выборкой: Jev фильтрует доказательства перед ответом LLM

RAG passage cookbook от TypeSafe приводит более конкретный пример с несколькими моделями: OpenAI embedding сначала подбирает passages, Jev для каждой пары «вопрос + passage» задаёт четыре Noul — релевантен ли фрагмент, содержит ли он доказательства, пригодные для ответа, опровергает ли он предпосылку вопроса и пытается ли он дать инструкции модели-ответчику. Код последовательно обрабатывает четыре вероятности и решает, поместить passage в зону доказательств, в зону конфликтующих доказательств или отбросить; в конце Claude Sonnet 5 пишет ответ.

Этот шаг решает распространённую проблему: фрагменты с высокой векторной близостью не обязательно пригодны. Они могут просто использовать похожие слова, а могут содержать в себе внедрённую в сообщение на форуме инструкцию «игнорируй предыдущий текст». В примере cookbook проверка инъекций стоит первой в правилах маршрутизации, и там же напоминается, что пороги — это отправная точка, выбранная для того корпуса, а не значение по умолчанию для всех RAG-приложений. Демонстрационные числа взяты из jev-1.12 от 2026-08-27 и не могут считаться новыми результатами оценки для текущей jev-1.13.0.

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

Наша калибровка Agent: где застревает эскалация при низкой уверенности?

В репозитории PandaNpc клиент Jev, банк вопросов и оркестратор используют Jev для распознавания намерений Agent, оценки кандидатных изменений, проверки условий завершения и решения о коммите. Клиент также выполняет ограниченные повторные попытки при тайм-аутах, 429 и 5xx, устанавливает лимиты на бюджет запросов и устаревшие результаты; права на выполнение контролируются оркестратором и слоем управляемых инструментов и не выдаются напрямую одним суждением Jev.

22 сентября 2026 года мы с jev-1.13.0 прогнали 19 синтетических turn по одному разу в shadow и по одному разу в enforce, всего 38 запусков, и записали 165 реальных решений Jev. Этот внутренний отчёт о калибровке и сохранённые ответы реальной машины используют скриптовый фиктивный LLM provider, поэтому эти данные описывают только поведение решений в контролируемых сценариях. Они не доказывают общую успешность, долю экономии или сквозную задержку на реальных пользовательских запросах.

Самая ценная находка — не средняя скорость, а то, что «выглядящий безопасным» порог создаёт затор: из 19 turn в enforce 13 turn на Q2 «достаточно ли информации, чтобы начать изменение» эскалировались, потому что вероятность Noul попадала в изначальный интервал неопределённости 0,15–0,85; LLM Worker не получал шанса выполнить последующие шаги. Записи калибровки показывают, что среди 34 решений Q2, помеченных как содержащие достаточно информации, многие вероятности находились в средней зоне. В отчёте рекомендуется разбить сложный Q2 на более атомарные суждения или скорректировать правила эскалации; это рекомендации, а не уже развёрнутые пороги.

Наш банк вопросов классифицирует вход как answer_only, inspect, modify или out_of_scope; на пути записи предложенные Worker кандидатные изменения сначала сортируются с помощью Score, а окончательное содержимое и сводка изменений затем проходят проверку приёмки и решение о коммите. Это лишь точки принятия решений: возможность фактически читать или записывать объекты по-прежнему предоставляется управляемым исполнителем поэтапно. Jev не имеет права самостоятельно расширять белый список инструментов и не может обойти проверку согласованности перед коммитом.

Данные калибровки выявили ещё один компромисс. В режиме shadow Jev выдаёт ответ и полное распределение, но не меняет исходный путь выполнения Worker; в режиме enforce ответ влияет на то, продолжать ли работу, эскалировать или отбросить. Если напрямую принять accuracy в shadow за completion rate в enforce, можно неверно понять систему: эскалация на Q2 заранее останавливает задачу, и последующие вопросы оценки кандидатов, приёмки и коммита вообще не получают шанса появиться. Поэтому в этом отчёте распределение по каждому вопросу, направление эскалации и итоговое состояние читаются отдельно.

В кандидатных изменениях есть конкретное сопоставление: в одном и том же turn кандидат, точно изменяющий цель, получил 2,94 балла, а кандидат, перезаписывающий весь файл, — 0,38 балла; кандидат с высоким баллом был выбран. Этот пример показывает лишь то, что в данном синтетическом сценарии вопрос с оценкой различил два варианта. И наоборот, кандидат с усечёнными доказательствами получил 2,27 балла, и нельзя игнорировать его низкую уверенность и пометку об усечении только потому, что число выглядит «неплохо». Наш код отдельно помечает неполноту доказательств, чтобы модель не делала уверенный вывод о записи, опираясь только на сохранённый префикс.

Мы также разделили «какой кандидат выбран» и «разрешено ли ему записывать» на два разных шага. После того как кандидат получает оценку Jev, управляемый исполнитель открывает инструменты записи только на этапе ACT/modify; выданный одноразовый тикет привязывается к ID вызова инструмента, текущему номеру ревизии, хешу целевого объекта и сводке параметров. Даже если текст кандидата подталкивает модель «игнорировать ограничения», он не получит прав инструмента, позволяющих обойти эти проверки. Это наш опыт интеграции на уровне кода: вероятностное суждение решает, по какому пути стоит идти, а права на побочные эффекты определяются проверяемыми программными условиями.

Пути отказа тоже нужно проектировать. Клиент выполняет ограниченные повторные попытки только при тайм-ауте, сетевой ошибке, 429 или 5xx; ответы после отмены или после истечения дедлайна turn просто отбрасываются. Если Jev недоступен в режиме enforce, продолжать нельзя без разрешения на деградацию; когда разрешён переход в llm_only, исполнитель блокируется в режиме только чтения. Если ветка уже была изменена и только потом потеряла Jev, оркестратор помечает весь раунд как неуспешный, а не позволяет последующей LLM дописать запись в отсутствие слоя принятия решений. Эти пути имеют цену для пользовательского опыта, но благодаря им «модель временно недоступна» не превращается незаметно в «права на запись сохраняются».

В отчёте о калибровке также различаются «эскалация при низкой уверенности» и «отказ в выполнении». Например, корректный discard, если его уверенность не достигает единого порога 0,85, будет записан как требующий ввода пользователя; это не равно ошибочному пропуску. На основании этого в отчёте предлагается разделить пороги для коммита и отбрасывания, но пока это остаётся рекомендацией. При написании workflow необходимо различать три результата: ошибочный пропуск, ошибочный отказ и ожидание проверки, иначе одна и та же группа данных приведёт к неверным выводам о порогах.

Этот пример показывает, что взаимодействие Jev и LLM нельзя изображать просто как «Jev сначала судит, LLM потом работает». О каждом суждении нужно спрашивать: насколько широк интервал неопределённости? Не приведёт ли оно к тому, что последующий обработчик никогда не получит задачу? Если входные доказательства усечены, можно ли явно эскалировать, а не догадываться? В нашей реализации конструктор state записывает evidence_truncated и заставляет вызывающую сторону рассматривать путь с недостатком доказательств как неопределённый; детерминированные вычисления, такие как подсчёты и сортировка, сначала выполняются в коде и не передаются Jev для угадывания. Официально известные ограничения Jev 1.13 такжеют оставлять подсчёты и арифметику коде.

Где должны располагаться guardrails для LLM?

Cookbook TypeSafe по guardrails для LLM ставит Jev с обеих сторон входа и вы LLM. Он использует набор Noul для выявления разных рисков и Score для оценки серьёзности а затем код в соответствии с политикой решает, пропустить, отправить на ручную проверку, заблокировать или передать в поддержку. Выход тоже нужно проверять, потому что даже обычный ввод может дать неподходящий результат генерации.

Границы таких guardrails тоже ясны: Jev может проверять содержимое по заранее написанным вопросам, но не является универсальным доказательством безопасности. Официальный документ об ограничениях прямо упоминает, что вредоносное содержимое может влиять на суждение, и требует ясно описывать criteria и тестировать границы. В наших синтетических samples мы делали 16 инъекционных зондов по кандидатным параметрам и зафиксировали 0 переворотов ранжирования; выборка слишком мала, чтобы делать вывод, что «защита от prompt injection решена». Что действительно определяет возможности инструментов, по-прежнему задаётся списками разрешений, фазовыми шлюзами и проверками перед коммитом в коде.

Когда это подходит, а когда нет?

Jev подходит, когда: набор кандидатов известен, вопрос можно разбить на несколько коротких суждений, а программному обеспечению нужны вероятности, чтобы решить, обрабатывать автоматически или эскалировать на человека. Например: маршрутизация обращений в поддержку, фильтрация фрагментов RAG, оценка кандидатных действий Agent, проверка цитат в сгенерированном результате. Если задача требует написать ответное письмо, изменить фрагмент кода или объяснить сложный процесс рассуждения, за неё берётся LLM. Если задача состоит в точном подсчёте денег, сравнении дат или проверке контроля доступа, программа должна вычислять это напрямую. Страница моделей также указывает, что Jev принимает только текст, и английский — текущий язык обучения с наилучшими результатами; китайскоязычные сценарии нужно оценивать на собственных данных и нельзя слепо копировать пороги из англоязычного cookbook.

Если хотите посмотреть, как реальный Agent обрабатывает права и вызовы инструментов, начните с PandaNpc Agent; о границах и сценариях использования кодирующих Agent также можно прочитать в сравнении Claude Code и Codex.

Читатель может начать с очень маленького набора для проверки: подготовьте четыре класса примеров — «очевидно можно обработать автоматически», «очевидно нужно отклонить», «семантически неоднозначно», «содержит вредоносные инструкции»; сначала определите ручную разметку, затем запишите вероятности Jev по каждому вопросу и результаты маршрутизации. Критерий успеха — не то, что каждый пример проходит автоматически, а то, что частота ошибок на пути автоматической обработки и объём ручной эскалации находятся в приемлемом для вас диапазоне. Если множество неоднозначных примеров застревает на одном и том же вопросе, сначала проверьте, не смешаны ли в вопросе несколько суждений, не слишком ли длинный state и откалиброваны ли пороги по локальным данным.

FAQ

Может ли Jev заменить Claude Code, Codex или чат-модель? Нет. TypeSafe позиционирует его как модель структурированных решений внутри программного обеспечения; для чата, письма и генерации кода по-прежнему нужна LLM.

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

Сколько вопросов можно задать в одном запросе? Можно поместить несколько независимых Choice, Score и Noul, использующих один и тот же state, в один запрос. Каждый вопрос оценивается отдельно, сложные суждения всё равно следует разбивать, а затем комбинировать в коде.

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