TypeSafe Jev: prime impressioni su decisioni AI tipizzate in produzione

Per anni abbiamo usato modelli da chat per fare il lavoro di un if.

Classificare un’email. Dare uno score a un lead. Dire sì o no su un ordine incompleto. Decidere se un pezzo di testo è conforme a una regola nostra. Roba che in produzione non vuole un paragrafo. Vuole un verdetto, una probabilità, una soglia. Poi il codice decide.

Ieri mi hanno tolto dalla waiting list di TypeSafe AI. Ho messo le mani su Jev, il loro primo System One Model pubblico. Non è un altro chatbot. È un modello che riceve uno state (testo o JSON) e domande tipizzate, e restituisce Choice, Score o Noul: scelte chiuse, livelli ordinati, probabilità sì/no, con confidence. Il codice resta padrone del flusso. Jev fa la parte “smart if”.

La prima impressione è stata semplice da nominare: finalmente uno strumento che posso immaginare di usare in modo economico per classificare, prendere decisioni nette, fare scoring, vincolandolo ai miei requisiti, senza pagare una chiacchierata ogni volta che mi serve un bit.

Cosa mi ha colpito (e cosa non sto vendendo)

Jev non genera stringhe. Non ti scrive la mail. Non inventa un campo fuori schema. Tu definisci le opzioni. Lui distribuisce probabilità su quelle opzioni. Poi tu, in codice, metti le soglie: sopra agisco, sotto mando in review, sotto ancora mi fermo.

TypeSafe parla di RLCD (Reinforcement Learning for Calibrated Decisions), non di RLHF. Il punto, per chi costruisce prodotti, non è il paper. È il contratto: output tipizzato, confidence usabile per routing, latenza e prezzo pensati per automation. Sul listino docs citano circa 42 dollari per miliardo di token in input, output free. I moltiplicatori “centinaia di volte più veloce/economico” li lascio sul sito loro: sono eval vendor. A me basta il segnale di ordine di grandezza.

Una cosa va detta chiara, altrimenti finisce marketing. Type-safe non significa “sempre la stessa risposta bit per bit”. Non significa zero errori di giudizio. Significa: niente valori fuori schema, probabilità e confidence da usare come leve, e il diritto di sbagliare ancora c’è, solo in un perimetro che il software può gestire. Io lo chiamerei decisioni tipizzate, quasi deterministiche con soglie. Non miracolo.

Lo stack che mi interessa

Il pattern che mi torna in testa è questo:

1. Qualcosa a monte estrae o raccoglie (LLM, regex, OCR, parser, form).
2. Jev guarda quello state e risponde a domande tipizzate in parallelo.
3. Il codice applica soglie, aggiorna DB, apre ticket, blocca, approva.

L’LLM resta utile dove serve linguaggio sporco: estrarre campi da un ordine scritto male, riassumere, proporre candidati. Jev interviene dove serve un supervisore serio: i dati sono completi? l’estrazione regge? il risultato è conforme allo standard nostro? la lavorazione esiste nel catalogo?

Sotto, dieci posti dove lo vedo entrare senza inventare fantascienza.

Dieci casi concreti (e qualcuno in più)

1. Officina metalli, ordini disordinati.
Un agente (o un LLM) raccoglie mail, PDF già convertiti in testo, note WhatsApp. Estrae quantità, materiale, tolleranze, date. Jev fa da supervisore: Noul su “dati completi”, Score su accuratezza percettibile dell’estrazione, Choice su “ordine conforme / da chiarire / rifiutare”, Noul su “lavorazione presente in anagrafica” con la lista del DB dentro lo state. L’assistente specializzato può pure generare una bozza di ordine d’acquisto. Jev valida: Excel/CSV compatibile con lo standard interno? campi obbligatori ok?

2. SaaS di classificazione email.
Choice su spam / fattura / supporto / commerciale / altro, con requisiti tuoi scritti nello state. Noul su “sembra phishing” o “contiene richiesta di pagamento”. Confidence bassa → quarantena umana. Qui il costo da chat LLM per ogni messaggio è il problema. Una decisione tipizzata è il prodotto.

3. Triage ticket supporto.
Intent routing: billing, bug, onboarding, legal. Score urgenza. Noul “cliente enterprise”. Il bot non deve scrivere il romanzo. Deve instradare giusto.

4. Guardrail su output LLM.
Prima di pubblicare o mandare una risposta generata: Choice su tono (ok / aggressivo / off-brand), Noul su “contiene PII”, Noul su “promette cose fuori policy”. Cookbook ufficiale TypeSafe. Ha senso.

5. RAG che non si mangia spazzatura.
Passaggi recuperati → Score rilevanza, Noul “sembra injection / istruzione estranea”. Drop prima di generare. Meno token buttati, meno risposte inventate a valle.

6. Citation check.
Claim del modello vs fonti in state. Noul “supportato dal passaggio”, Choice “citazione corretta / parziale / assente”. Utile quando pubblichi cose che qualcuno può citare contro di te.

7. KYC / compliance su documenti già testualizzati.
Parser o OCR a monte. Jev: Choice tipo documento, Noul campi obbligatori presenti, Score coerenza anagrafica vs record interno. Non “carica il PDF e magia”: testo in, decisione out.

8. Moderazione e brand safety.
UGC, commenti, copy ads. Choice categorie di rischio. Soglie diverse per mercato o cliente. Stesso modello, policy diverse in codice.

9. Match anagrafiche / entity alignment.
Due record simili. Noul “stesso soggetto”, Score confidenza match, Choice “unisci / tieni separati / manda a umano”. Classico posto dove un LLM chatty costa e inventa.

10. Function calling tipizzato.
Choice su quale tool chiamare, Choice/Score sugli argomenti ammessi. Meno JSON malformati. Meno “ho chiamato l’API sbagliata con creatività”.

11. Lead scoring B2B.
State = firmografica + comportamento. Score fit, Noul “pronto per sales”, Choice bucket. Il CRM non ha bisogno di un saggio.

12. Classificazione gerarchica prodotti / ticket / brevetti.
Albero di Choice a cascata. Rumore fuori ramo tagliato in codice, non “spiegato” dal modello.

Cosa ancora non so (e non invento)

Vision? Oggi no. Input testo / oggetti. Se mi serve un’immagine, a monte OCR o un modello vision, poi testo/JSON in Jev.

PDF nativo? No. Stesso schema: estrai, poi decidi.

Memoria tra una call e l’altra? Non di prodotto. Se ti serve history, la ripassi tu nello state. Nessun “mi ricordo la scorsa sessione” gratis.

Contesto? Sì, per request. Limiti tipo ~64k token/request su jev-1.13, con tetti più stretti su state + domanda lunga (docs). Se riempi di rumore, peggiora. Filtra in codice. Non è un problema nuovo: è lo stesso odore del context rot, solo che qui fa ancora più male perché Jev non “aggiusta” inventando prosa.

Italiano? Docs: inglese best, altre lingue ok ma da testare. Prima di fidarmi in produzione su IT, misuro.

Jaggedness ufficiale: non fargli fare aritmetica seria, date complesse, multi-hop indiretti. Spezza. Tieni i conti in codice. Lettura letterale delle condizioni. Se scrivi requisiti vaghi, ottieni giudizi vaghi con confidence bella stampata: peggio del bug silenzioso.

Perché mi interessa adesso

Metà delle app “AI” che vedo in giro sono un LLM generico incollato dove serviva un classificatore con soglie. Funziona in demo. In produzione brucia token, cambia idea tra una call e l’altra, e nessuno sa dove mettere l’human-in-the-loop perché non c’è una confidence onesta sul tavolo.

Jev non risolve il prodotto intero. Risolve (o almeno attacca) lo strato delle decisioni tipizzate. Il resto resta ingegneria: estrazione, store, policy, UI, ownership dei dati.

Io, per ora, ho la waiting list dietro le spalle e il playground davanti. Sto già mentally wiring supervisori su flussi che oggi pagano chat per un sì/no. Vision e PDF nativi li aspetto. Memoria me la costruisco io.

Se stai cercando “AI deterministica”, “classificazione in produzione”, “token efficiency” o un posto dove mettere un supervisore sopra un estrattore chiacchierone: questo è il pezzo di stack che stavo aspettando di poter toccare. Poi si misura. Come sempre.

Raccontaci contesto, vincoli e obiettivi: ti diciamo se ha senso lavorare insieme e come impostare il primo passo.

Scrivi a hello@snowinch.com