Cum se implementează rutarea și gardurile de siguranță LLM? Un exemplu de colaborare între Jev și modelele lingvistice mari

Divulgarea intereselor și a dovezilor: PandaNpc dezvoltă un strat de decizie pentru Agent care folosește Jev. În continuare cităm documentația oficială TypeSafe, cookbook-ul oficial, precum și apeluri Jev reale și calibrări pe scenarii sintetice din depozitul nostru. Calibrările noastre folosesc un provider LLM fals scriptat și nu pot reprezenta traficul real al utilizatorilor sau performanța întregului lanț de producție.

Rutarea LLM se poate face astfel: mai întâi lăsați Jev să determine cărei categorii aparține cererea și cât de mare este riscul, apoi codul decide dacă o trimite unei funcții obișnuite, unui LLM specializat sau unei revizuiriane.** Jev poate fi plasat și între recuperare și generare pentru a filtra dovezile, sau după ieșirea LLM pentru a verifica rezultatul. El returnează opțiuni închise, scoruri și probabilități; răspunsurile deschise, generarea de cod și raționamentul lung rămân în sarcina LLM. Explicația TypeSafe despre agenții de cod arată clar că Jev nu poate înlocui direct modelul de chat din spatele Claude Code sau Codex.

Acest articol folosește o cer către serviciul clienți, o conductă RAG de întrebări și răspunsuri și propriile noastre înregistrări de calibrare pentru Agent, pentru a explica unde anume se intersectează cele două tipuri de modele și de ce rezultatele cu încredere scăzută trebuie să aibă o destinație clară.

Ce poate judeca Jev și de ce rămâne responsabil LLM?

Până la 23 septembrie 2026, pagina de modele TypeSafe lista modelul stabil jev-1.13.0. API-ul acceptă un state și un set de questions, iar prin POST /v1/systemone returnează answers structurate corespunzătoare. jev-latest indica în acea zi 1.13.0, dar aliasul se schimbă odată cu versiunea; sistemele cu praguri calibrate ar trebui să fixeze versiunea și să înregistreze ID-ul real al modelului din răspuns.

Noul nu are un câmp confidence separat; nu poți scrie direct o probabilitate Noul ca „încredere a modelului”. Score nici nu ar trebui folosit pentru a calcula sume exacte. Sumele, compararea datelor, cotele și verificările de permisiuni ar trebui să rămână în programe deterministe; documentația oficială enumeră aceste limite pentru Jev 1.13.

Forma minimă a unui apel

Forma cererii de mai jos este conformă cu referința oficială API; întrebarea exemplu este o configurație ilustrativă construită în acest articol și nu a fost testată online aici:

JSON-ul de mai jos folosește un mesaj de client în engleză; în română, clientul ar spune „Comanda mea a fost debitată de două ori, așa că vă rog să-mi rambursați banii.”

{
  "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?"
    }
  }
}

Un sistem real ar trebui să verifice mai întâi, prin cod, dacă înregistrările de debitare aparțin aceleiași comenzi și dacă rambursarea este permisă. Exemplul de mai sus servește doar la interpretarea intenției utilizatorului; cererea de rambursare a utilizatorului nu înseamnă că eligibilitatea pentru rambursare a fost dovedită, cu atât mai puțin nu constituie autorizare de a executa direct rambursarea.

Rutarea LLM cu Jev: trei căi de predare

Exemplul oficial TypeSafe de rutare a intenției trimite mai întâi cererea către serviciul clienți la Jev pentru a determina intenția și complexitatea, apoi codul o direcționează: verificarea stării comenzii merge către o funcție de bază de date; întrebările despre produse și retururile/schimburile merg către LLM-uri specializate încărcate cu materiale diferite; reclamațiile complexe sau rezultatele cu încredere scăzută intră într-o coadă pentru revizuire umană. Aceasta este colaborarea cea mai ușor de înțeles dintre Jev și LLM: primul oferă o judecată structurată, iar al doilea intră în scenă doar când trebuie generate explicații sau conversație.

La implementare, poți proiecta în următoarea ordine, în loc să lași modelul să decidă liber toate acțiunile:

1. Definește mai întâi căile: enumeră clar funcțiile obișnuite, LLM-urile specializate și cererile pe care le poate trata revizuirea umană și lasă pentru Choice o opțiune de rezervă precum other sau similară.
2. Pune faptele în state: cuvintele originale ale utilizatorului, starea contului și înregistrările comenzii devin câmpuri separate; nu trata textul web de sursă necunoscută drept instrucțiuni de sistem.
3. Pune întrebări înguste câte una: folosește Choice pentru intenție, Score pentru risc sau urgență și Noul pentru fapte punctuale care trebuie confirmate. Documentația oficială recomandă ca mai multe întrebări independente despre același state să poată fi evaluate în paralel în aceeași cerere.
4. Lasă codul să facă rutarea finală: verifică mai întâi permisiunile și regulile rigide, apoi probabilitățile Jev și pragurile calibrate pentru acest business; cererile cu încredere scăzută fără dovezi merg la om sau primesc întrebări suplimentare.
5. Înregistrează rezultatele și reverifică: păstrează versiunea modelului, versiunea întrebărilor, probabilitățile, destinația finală și rezultatele corectării umane, pentru a putea judeca dacă pragurile sunt potrivite.

Sursa imaginii: TypeSafe AI „Introducing System One Models & Jev”, 2026-09-15. Cele patru fluxuri de lucru au fost construite de TypeSafe, indicatorii sunt agregați cu ponderi egale pe fluxuri; metoda de evaluare poate fi consultată la TypeSafe workflow evals.

Acest grafic oficial ajută la înțelegerea motivului pentru care se insistă pe „integrarea mai multor judecăți înguste într-un flux de lucru software”. Axa verticală din grafic păstrează denumirea „accuracy” folosită de furnizor, dar răspunsurile sale de referință provin din consensul probabilităților prezise de două modele mari, nu dintr-un singur răspuns corect verificat de oameni; costurile și indicatorii depind și de aceste patru fluxuri de lucru și de metoda de evaluare a furnizorului, așa că nu pot fi convertite în „cât se poate economisi în orice scenariu”.

Generare augmentată prin recuperare: Jev filtrează dovezile înainte ca LLM să răspundă

Cookbook-ul TypeSafe pentru pasaje RAG oferă un exemplu mai concret cu mai multe modele: embedding-ul OpenAI recuperează mai întâi pasaje, Jev pune patru întrebări Noul pentru fiecare „întrebare + pasaj” — dacă este relevant, dacă conține dovezi utilizabile pentru răspuns, dacă contrazice premisa din întrebare și dacă încearcă să dea instrucțiuni modelului care răspunde. Codul procesează în ordine cele patru probabilități și decide dacă pune pasajul în zona de dovezi, în zona de dovezi conflictuale sau îl elimină; la final, Claude Sonnet 5 scrie răspunsul.

Acest pas rezolvă o problemă frecventă: pasajele cu similaritate vectorială mare nu sunt neapărat utilizabile. Pot folosi doar cuvinte similare sau pot conține, într-o postare de forum, o injecție de prompt de tipul „ignoră textul anterior”. Exemplul din cookbook pune verificarea injecțiilor chiar la începutul regulilor de rutare și totodată avertizează că pragurile sunt un punct de plecare ales pentru acel corpus, nu valori implicite pentru toate aplicațiile RAG. Numerele demonstrative provin din jev-1.12 la 2026-08-27 și nu trebuie considerate rezultate noi de evaluare pentru jev-1.13.0 actual.

După generare se mai poate face un strat de verificare. Cookbook-ul TypeSafe pentru verificarea citărilor folosește mai întâi un program pentru a găsi textul citat, apoi Jev pentru a judeca dacă pasajul susține, contrazice sau nu menționează afirmația generată. Poate scoate în evidență citările care merită reverificate; judecata modelului în sine poate greși în continuare, așa că „trece verificarea” nu poate fi scris drept garanție de fapt.

Calibrarea Agentului nostru: unde se blochează escaladarea la încredere scăzută?

În depozitul PandaNpc, clientul Jev, banca de întrebări și orchestratorul folosesc Jev pentru recunoașterea intenției Agentului, scorarea modificărilor candidate, verificarea condițiilor de finalizare și decizia de trimitere. Clientul face și reîncercări limitate la timeout, 429, 5xx și impune limite pentru bugetul cererilor și rezultatele expirate; permisiunile de execuție sunt deținute de orchestrator și de stratul de instrumente controlate, nu sunt acordate direct de o singură judecată Jev.

La 2026-09-22 am folosit jev-1.13.0 pentru 19 turn-uri sintetice, rulând o dată shadow și o dată enforce pentru fiecare, în total 38 de rulări, și am înregistrat 165 de decizii Jev reale. Acest raport intern de calibrare și răspunsurile reale salvate folosesc un provider LLM fals scriptat, așa că aceste date descriu doar comportamentul decizional în scenarii controlate. Ele nu pot demonstra rata globală de succes, proporția de economii sau latența end-to-end pentru cereri reale ale utilizatorilor.

Cea mai valoroasă descoperire nu a fost viteza medie, ci faptul că un prag „aparent sigur” a creat un blocaj: dintre cele 19 turn-uri în enforce, 13 au fost escaladate la Q2 „informațiile sunt suficiente pentru a începe modificarea?”, deoarece probabilitatea Noul cădea în intervalul de incertitudine prestabilit 0,15–0,85; LLM Worker nu a avut ocazia să execute pașii următori. Înregistrările de calibrare arată că, dintre 34 de decizii Q2 etichetate ca având informații suficiente, multe probabilități erau în zona de mijloc. Raportul recomandă împărțirea Q2 complex în judecăți mai atomice sau ajustarea regulilor de escaladare; acestea sunt recomandări, nu praguri deja implementate.

Banca noastră de întrebări clasifică intrarea drept answer_only, inspect, modify sau out_of_scope; pe calea de scriere, modificările candidate propuse de Worker sunt mai întâi ordonate cu Score, iar conținutul final și rezumatul modificărilor trec apoi prin verificarea de acceptare și decizia de trimitere. Acestea sunt doar puncte de decizie: dacă se poate citi sau scrie efectiv un obiect rămâne stabilit de executorul controlat, care acordă permisiuni pe etape. Jev nu are dreptul să relaxeze singur lista albă de instrumente și nu poate ocoli verificarea de consistență dinaintea trimiterii.

Datele de calibrare au scos la iveală un alt compromis. În modul shadow, Jev oferă răspunsul și distribuția completă, dar nu schimbă calea de execuție originală a Worker-ului; în modul enforce, răspunsul influențează dacă se continuă, se escaladează sau se elimină. Dacă iei acuratețea din shadow drept rată de finalizare în enforce, vei înțelege greșit sistemul: escaladarea la Q2 oprește sarcina mai devreme, astfel încât scorarea ulterioară a candidaților, acceptarea și întrebarea de trimitere nu mai au deloc ocazia să apară. De aceea raportul citește separat distribuția fiecărei întrebări, direcția de escaladare și starea finală.

Există o comparație concretă între modificările candidate: în același turn, candidatul care modifica precis ținta a primit 2,94 puncte, în timp ce candidatul care suprascria întregul fișier a primit 0,38 puncte; candidatul cu punctaj mai mare a fost ales. Acest exemplu arată doar că, în acel scenariu sintetic, întrebarea de scor a distins două variante. Invers, un candidat cu dovezi trunchiate a primit 2,27 puncte; nu trebuie să ignori încrederea scăzută și marcajul de trunchiere doar pentru că valoarea pare „destul de bună”. Codul nostru marchează separat dovezile incomplete, pentru a evita ca modelul să ia o decizie de scriere certă doar pe baza prefixului păstrat.

Am separat și „care candidat este ales” de „permisiunea de a scrie” în doi pași diferiți. După ce candidatul este punctat de Jev, executorul controlat deschide instrumentele de scriere doar în etapa ACT/modify; biletul unic emis leagă ID-ul apelului de instrument, numărul reviziei curente, hash-ul obiectului țintă și rezumatul parametrilor. Chiar dacă textul candidat induce modelul să „ignore restricțiile”, nu obține permisiuni de instrument care să treacă de aceste verificări. Aceasta este experiența noastră din integrarea la nivel de cod: judecata probabilistică decide ce cale merită urmată, iar permisiunile cu efecte secundare sunt stabilite de condiții de program verificabile.

Căile de eșec trebuie și ele proiectate. Clientul face reîncercări limitate doar la timeout, eroare de rețea, 429 sau 5xx; răspunsurile anulate sau care depășesc termenul limită al turn-ului sunt eliminate direct. Dacă Jev nu este disponibil în modul enforce, nu se poate continua fără autorizare de degradare; când se permite llm_only, executorul blochează scrierea și rămâne doar în citire. Dacă ramura a suferit deja modificări înainte de a pierde Jev, orchestratorul marchează întregul ciclu ca eșuat, în loc să lase LLM-ul ulterior să facă scrierea în lipsa stratului de decizie. Aceste căi au un cost pentru experiența utilizatorului, dar împiedică „modelul este temporar indisponibil” să devină în ascuns „permisiunile de scriere rămân neschimbate”.

Raportul de calibrare distinge și între „escaladare la încredere scăzută” și „refuz de execuție”. De exemplu, un discard corect, dacă încrederea nu atinge pragul unificat de 0,85, va fi înregistrat ca necesitând intervenția utilizatorului; aceasta nu înseamnă o permitere eronată. Pe baza acestui fapt, raportul recomandă separarea pragurilor pentru trimitere și eliminare, dar deocamdată este tot o recomandare. Când scrii fluxuri de lucru, trebuie să distingi clar între permiterea eronată, refuzul eronat și verificarea în așteptare, altfel același set de date duce la concluzii greșite despre praguri.

Acest caz ne arată că colaborarea dintre Jev și LLM nu poate fi desenată doar ca „Jev judecă întâi, LLM lucrează apoi”. Pentru fiecare judecată trebuie să întrebi: cât de larg este intervalul de incertitudine? Va împiedica procesorul ulterior să primească vreodată sarcina? Dacă dovezile de intrare sunt trunchiate, se poate escalada clar în loc să se ghicească? În implementarea noastră, constructorul de state înregistrează evidence_truncated și face ca apelantul să trateze calea fără dovezi drept incertă; calculele deterministe precum numărătoarea și sortarea se fac mai întâi în cod, nu sunt lăsate pe seama ghicirii lui Jev. Limitările cunoscute ale Jev 1.13 oficial recomandă de asemenea să lăsați numărătoarea și aritmetica în cod.

Unde ar trebui plasate gardurile de siguranță pentru LLM?

Cookbook-ul TypeSafe pentru guardrails LLM plasează Jev pe ambele laturi ale LLM-ului: la intrare și la ieșire. Folosește un set de Noul pentru a identifica diferite riscuri, Score pentru a măsura gravitatea, iar codul decide conform politicii dacă permite, trimite la verificare umană, blochează sau redirecționează către suport. Ieșirea trebuie și ea verificată, deoarece o intrare obișnuită poate produce totuși un rezultat generat nepotrivit.

Limitele acestor tipuri de garduri sunt la fel de clare: Jev poate verifica conținutul pe baza unor întrebări scrise dinainte, dar nu este o dovadă universală de siguranță. Documentația oficială despre limitări menționează explicit că conținutul rău intenționat poate influența judecata, cere să scrieți clar criterii și să testați limitele. În eșantioanele noastre sintetice am făcut 16 sonde de injecție împotriva parametrilor candidați și am înregistrat 0 inversări de clasament; eșantionul este prea mic pentru a concluziona că „injecția de prompt este rezolvată”. Ceea ce decide cu adevărat ce poate face un instrument rămân lista de permisiuni din cod, porțile pe etape și verificările dinaintea trimiterii.

Când este potrivit să folosești Jev și când nu?

Jev este potrivit când: setul de candidați este cunoscut, întrebarea poate fi împărțită în câteva judecăți scurte, iar software-ul are nevoie de probabilități pentru a decide între procesarea automată și escaladarea la om. De exemplu, rutarea către serviciul clienți, filtrarea pasajelor RAG, scorarea acțiunilor candidate ale Agentului, verificarea citărilor din rezultatele generate. Dacă sarcina cere scrierea unui răspuns, modificarea unei bucăți de cod sau explicarea unui raționament complex, LLM-ul preia. Dacă sarcina este calcularea exactă a banilor, compararea datelor sau verificarea controlului accesului, programul ar trebui să calculeze direct. Pagina de modele mai explică faptul că Jev acceptă doar text, iar engleza este limba de antrenare cu cea mai bună performță actuală; scenariile în chineză trebuie evaluate cu propriile date și nu pot prelua pragur din cookbook-ul în engleză.

Dacă vrei să observi cum tratează un real permisiunile și apelurile de instrumente, poți începe cu PandaNpc Agent; despre limitele și scenariile de utilizare ale agenților de cod, poți consulta și Comparația Claude Code și Codex.

Cititorii pot începe cu un set de validare foarte mic: pregătiți patru categorii de eșantioane — „evident de procesat automat”, „evident de respins”, „ambiguu semantic” și „conține instrucțiuni rău intenționate”; stabiliți mai întâi etichetarea umană, apoi înregistrați probabilitățile Jev pentru fiecare întrebare și rezultatele rutării. Criteriul de succes nu este ca fiecare exemplu să treacă automat, ci ca rata de eroare pe calea de procesare automată și volumul de escaladare umană să se încadreze în limitele pe care le accepți. Dacă multe eșantioane ambigue se blochează la aceeași întrebare, verificați mai întâi dacă întrebarea amestecă mai multe judecăți, dacă state-ul este prea lung sau dacă pragurile au fost calibrate pe datele locale.

FAQ

Poate Jev înlocui Claude Code, Codex sau un model de chat? Nu. TypeSafe îl poziționează ca model de decizie structurată în software; chatul, scrierea și generarea de cod necesită în continuare LLM.

Dacă tipul returnat este fix, înseamnă că nu mai greșește? Nu. Tipurile fixe reduc problemele de parsare și de ieșire în afara limitelor, dar clasificarea, scorarea și judecățile de fapt pot greși în continuare. Pe căile cu încredere scăzută și risc ridicat ar trebui păstrată verificarea umană.

Câte întrebări pot fi puse într-o singură cerere? Poți pune într-o singură cerere mai multe Choice, Score și Noul independente care împart același state. Întrebările sunt evaluate separat, iar judecățile complexe ar trebui totuși despărțite și apoi combinate de cod.

Se poate folosi chineza? Documentația oficială spune că acceptă limbaje naturale, inclusiv caractere chinezești, japoneze și coreene, dar acuratețea în engleză este momentan cea mai bună. Volumele de lucru în chineză trebuie verificate și calibrate separat.