Як реалізувати маршрутизацію LLM і запобіжники? Приклад співпраці Jev із великими мовними моделями

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

Маршрутизацію 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?"
    }
  }
}

Реальна система також має спершу кодом перевірити, чи записи про списання стосуються того самого замовлення і чи дозволено повернення коштів. Наведений приклад призначений лише для тлумачення наміру користувача; запит користувача на повернення коштів не означає, що право на повернення вже підтверджено, і тим більше не є дозволом негайно виконати повернення.

Використання Jev для маршрутизації LLM: три шляхи передавання

Офіційний приклад маршрутизації за наміром від TypeSafe спочатку передає запит служби підтримки Jev, щоб визначити намір і складність, а потім кодом розводить його: перевірка статусу замовлення йде до функції бази даних; питання про продукт і повернення/обмін — до спеціалізованих LLM, завантажених різними матеріалами; складні скарги або результати з низькою впевненістю потрапляють у чергу для ручного опрацювання. Саме це найзрозуміліша форма співпраці Jev і LLM: перший дає структуроване судження, друга з’являється лише тоді, коли потрібно згенерувати пояснення чи діалог.

Під час впровадження можна проєктувати в такому порядку, а не дозволяти моделі вільно вирішувати всі дії:

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

Джерело зображення: TypeSafe AI «Представляємо System One Models і Jev», 2026-09-15. Чотири робочі процеси створені TypeSafe; показники узагальнено з рівною вагою за робочими процесами; методику оцінювання див. Оцінювання робочих процесів TypeSafe.

Ця офіційна ілюстрація допомагає зрозуміти, чому наголошується на «вбудовуванні багатьох вузьких суджень у програмний робочий процес». Вертикальна вісь на графіку зберігає назву «accuracy» від виробника, але її довідкові відповіді походять із консенсусу прогнозованих імовірностей двох великих моделей, а не з єдиної правильної відповіді, перевіреної людиною; витрати й показники також залежать від цих чотирьох робочих процесів і методики оцінювання виробника, тож їх не можна перерахувати в «скільки саме можна заощадити в будь-якому сценарії».

Генерація з розширеним пошуком: Jev фільтрує докази перед відповіддю LLM

RAG passage cookbook від TypeSafe пропонує конкретніший приклад із кількома моделями: OpenAI embedding спершу вибирає абзаци, Jev для кожного «питання + абзац» ставить чотири Noul — чи це релевантно, чи містить доказ, придатний для відповіді, чи спростовує передумову в питанні, чи намагається дати інструкції моделі-відповідачеві. Код послідовно обробляє чотири ймовірності й вирішує,істити цей абзац у зону доказів, у зону конфліктних доказів або відкинути; зрештою відповідь пише 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.

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

Найцінніше відкриття — не середня швидкість, а те, що «на вигляд безпечний» поріг створює затор: із 19 turn у enforce 13 перейшли в ескалацію на 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 за показник завершення в enforce, можна неправильно зрозуміти систему: ескалація на Q2 завчасно зупинить завдання, і подальші оцінювання кандидатів, приймання та подання взагалі не матимуть шансу з’явитися. Тому цей звіт читає розподіл за кожним питанням, напрямок ескалації та кінцевий стан окремо.

Серед кандидатів на зміну є конкретне порівняння: у тому самому turn кандидат із точним редагуванням цілі отримав 2,94 бала, а кандидат із перезаписом усього файлу — 0,38 бала; кандидата з високим балом було вибрано. Цей приклад лише показує, що в цьому синтетичному контексті питання Score розрізнило два варіанти. І навпаки, кандидат із обрізаними доказами отримав 2,27 бала, і не можна через те, що число виглядає «непогано», ігнорувати його низьку впевненість і позначку обрізання. Наш код окремо позначає неповноту доказів, щоб модель не ухвалювала впевнене рішення про запис лише на основі збереженого префікса.

Ми також розділили «який кандидат вибрати» і «дозволити йому запис» на два різні кроки. Після оцінювання кандидата через Jev контрольований виконавець відкриває інструменти запису лише на етапі ACT/modify; виданий одноразовий квиток прив’язується до ID виклику інструмента, поточного номера ревізії, хешу цільового об’єкта й підсумку параметрів. Навіть якщо текст кандидата спонукає модель «ігнорувати обмеження», вона не отримає прав інструментів в обхід цих перевірок. Це досвід, який ми здобули з інтеграції на рівні коду: ймовірнісне судження вирішує, який шлях варто обрати, а права на побічні дії визначаються умовами програми, які можна перевірити.

Шляхи помилок теж потрібно проєктувати. Клієнт робить обмежені повторні спроби лише в разі тайм-ауту, помилки мережі, 429 або 5xx; відповіді після скасування чи після дедлайну turn одразу відкидаються. Якщо Jev недоступний у режимі enforce, продовжувати не можна без дозволу на деградацію; коли дозволено llm_only, виконавець переходить у режим лише читання. Якщ гілка вже зазнала змін і лише потім втрачає Jev, оркестратор позначає весь цикл як невдалий, а не дозволяє наступній LLM без шару рішень додатково виконати запис. Ці шляхи мають ціну для користувацького досвіду, але завдяки їм «модель тимчасово недоступна» нетворюється тихо на «права наис без змін».

Звіт про калірування також розрізняє «ескалацію заької впевненості» та «відмову від виконання». Наприклад, правильний discard ізевненістю, що не досягла єдиного порогу 0,85, буде позначено такий, що потребує введення користувача; це не дорівнює помилковому пропуску. На цій підставі звіт радить розділити пороги для подання й відкидання, але наразі це лише рекомендація. Пишучи робочий процес, потрібно чітко розрізняти помилковий пропуск, помилкову відмову й очікування перевірки, інакше той самий набір даних приведе до хибних висновків про пороги.

Цей приклад показує, що співпрацю Jev і LLM не можна зображати лише як «Jev спершу вирішує, LLM потім працює». Для кожного судження треба запитати: який завширшки інтервал невизначеності? Чи не призведе це до того, що наступні обробники ніколи не отримають завдання? Якщо вхідні докази обрізано, чи можна явно ескалувати, а не вгадувати? У нашій реалізації конструктор state записує evidence_truncated і змушує викликача вважати шлях без доказів невизначеним; детерміновані обчислення, як-от підрахунок і сортування, спершу виконуються в коді, а не віддаються Jev на здогад. Офіційно відомі обмеження Jev 1.13 також радять залишати підрахунки й арифметику в коді.

Де мають бути запобіжники LLM?

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

Межі таких запобіжників так само чіткі: Jev може перевіряти вміст за наперед написаними питаннями, але не є універсальним доказом безпеки. Офіційний документ про обмеження прямо зазначає, що зловмисний вміст може впливати на судження, і вимагає чітко писати criteria та тестувати межі. У наших синтетичних зразках ми зробили 16 ін’єкційних проб щодо параметрів кандидатів і зафіксували 0 змін порядку; вибірка надто мала, щоб зробити висновок, що «стійкість до ін’єкцій підказок уже розв’язано». Що насправді можуть робити інструменти, усе ще визначають списки дозволів у коді, етапні шлюзи та перевірки перед поданням.

Коли доречно використовувати, а коли ні?

Для Jev підходить: набір кандидатів відомий, питання можна розбити на кілька коротких суджень, програмі потрібні ймовірності, щоб вирішити між автоматичною обробкою та ескалацією до людини. Наприклад, маршрутизація звернень підтримки, фільтрування абзаців RAG, оцінювання кандидатів на дії Agent, перевірка цитат у згенерованих результатах. Якщо завдання вимагає написати лист-відповідь, змінити фрагмент коду або пояснити складний процес міркування, його бере на себе LLM. Якщо завдання — точно порахувати гроші, порівняти дати чи перевірити контроль доступу, програма має обчислювати це напряму. Сторінка моделі також пояснює, що Jev приймає лише текст, а англійська наразі є мовою тренування з найкращими результатами; для китайськомовних сценаріїв потрібно оцінювати на власних даних і не можна просто копіювати пороги з англомовного cookbook.

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

Читач може почати з дуже малої валідаційної вибірки: підготуйте чотири категорії зразків — «явно можна обробити автоматично», «явно слід відхилити», «семантично неоднозначно», «містить зловмисні інструкції»; спершу визначте ручну розмітку, а потім записуйте ймовірності Jev за кожним питанням і результати маршрутизації. Критерій успіху не в тому, щоб кожен випадок автоматично проходив, а в тому, щоб і частка помилок на шляху автоматичної обробки, і обсяг ручної ескалації були в межах, прийнятних для вас. Якщо багато неоднозначних зразків застрягає на одному й тому самому питанні, спершу перевірте, чи в питання не змішано кілька суджень, чи не занадто довгий state або чи пороги відкалібровано за локальними даними.

FAQ

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

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

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

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