Jev e i modelli decisionali: quando un agente AI non deve scrivere ma scegliere

Negli ultimi trenta giorni quasi tutti i canali che seguiamo sull’AI engineering hanno parlato di modelli decisionali, e in particolare di Jev, il primo “System One model” di TypeSafe. Non scrive una riga di testo. Prende in input uno stato e una serie di domande tipizzate, e restituisce decisioni con probabilità calibrate in qualche centinaio di millisecondi.

Sembra un dettaglio tecnico, ma cambia il modo in cui si progettano gli agenti. Molte delle chiamate che oggi facciamo a un LLM non chiedono di scrivere: chiedono di scegliere. Questo ticket va al supporto tecnico o alla fatturazione? Questo output è sicuro? Serve il modello grande o basta quello piccolo? Per queste domande i modelli decisionali sono più veloci, più economici e soprattutto più prevedibili.

In questa guida vediamo cosa sono, come si integrano in un agente reale, come usare la confidenza per decidere quando agire da soli e quando chiedere a una persona, e dove invece non servono.

Per un’azienda il tema non è tecnico, è economico. Molti processi che si vorrebbero automatizzare con l’AI, dallo smistamento delle email al controllo dei documenti in arrivo, sono fatti di decisioni ripetitive. Con i modelli decisionali queste decisioni costano frazioni di centesimo, arrivano in meno di un secondo e portano con sé un indice di affidabilità che permette di stabilire quando lasciar fare alla macchina e quando coinvolgere una persona.

In breve

• I modelli decisionali (o System One model) rispondono a domande chiuse con valori tipizzati e probabilità, non con testo libero.
• Jev di TypeSafe supporta tre primitive: Choice (scelta tra opzioni), Score (punteggio su una scala) e Noul (vero/falso con probabilità).
• Sono adatti a routing, triage, guardrail, scelta degli strumenti e “if intelligenti” dentro gli agenti.
• Non sostituiscono l’LLM: non scrivono codice, non ragionano in più passi e lavorano su stati limitati.
• Il valore vero è la confidenza: permette di decidere in codice quando agire in automatico e quando passare a una persona.
• Esistono alternative: l’API Decisions di OpenAI, Mercury Decide di Inception e modelli open come GLiNER2.5 da eseguire in locale.
• Per chi decide: i modelli decisionali rendono sostenibile automatizzare processi ad alto volume, come smistamento delle richieste, classificazione dei documenti e priorità commerciali, con un costo per decisione molto basso e un controllo esplicito su quando intervengono le persone.

Che cos’è un modello decisionale

Un modello decisionale è un modello addestrato per restituire una decisione strutturata, scelta tra opzioni definite in anticipo, insieme a una distribuzione di probabilità. Non genera token uno dopo l’altro come un LLM: valuta tutte le domande in parallelo e risponde con valori che il codice può usare direttamente.

TypeSafe ha chiamato questa categoria System One, richiamando la distinzione di Daniel Kahneman tra pensiero veloce e intuitivo (Sistema 1) e pensiero lento e deliberato (Sistema 2), resa popolare dal libro Thinking, Fast and Slow. Nell’analogia, l’LLM è il Sistema 2: ragiona, scrive, pianifica. Il modello decisionale è il Sistema 1: risponde subito a domande semplici e ben definite.

Secondo il post di lancio di TypeSafe, Jev si distingue dagli LLM su quattro punti:

• Output tipizzati: le risposte possibili sono definite prima della chiamata, quindi non c’è testo da interpretare né JSON malformato da correggere.
• Probabilità calibrate: ogni risposta arriva con una distribuzione e un valore di confidenza.
• Campionamento parallelo: tutte le domande vengono valutate insieme, in una sola chiamata.
• Addestramento dedicato: TypeSafe parla di Reinforcement Learning for Calibrated Decisions (RLCD), un metodo che premia probabilità affidabili più che risposte gradevoli.

La conseguenza pratica è semplice. Una chiamata che prima era “chiedi all’LLM, parsifica la risposta, gestisci gli errori di formato” diventa una funzione che restituisce un valore già pronto.

Cosa cambia per le aziende

I modelli decisionali spostano il confine di ciò che conviene automatizzare. Finora, usare un LLM per ogni micro-decisione di un processo ad alto volume era lento e costoso; scrivere regole a mano era fragile. Oggi esiste una terza via, e i processi candidati in una PMI sono più di quanti si pensi.

Processi tipici in cui conviene valutarli

• Servizio clienti: smistare email e ticket al reparto giusto, stimare l’urgenza, riconoscere un cliente a rischio di abbandono.
• Amministrazione: classificare i documenti in arrivo (fatture, documenti di trasporto, ordini, solleciti) e indirizzarli alla persona o al flusso corretto.
• Commerciale: dare una priorità ai contatti in arrivo dal sito in base a settore, dimensione e richiesta.
• Conformità: segnalare testi che contengono dati personali, clausole insolite o informazioni da non pubblicare.
• E-commerce: moderare recensioni e domande sui prodotti, riconoscere richieste di reso o reclami.

Il modello che funziona: automatico dove è sicuro, umano dove serve

Il valore non sta nell’automatizzare tutto, ma nel separare i casi chiari da quelli incerti. Con soglie di confidenza ben tarate, il sistema gestisce in automatico la quota di richieste su cui è affidabile e passa le altre alle persone, che lavorano così solo dove serve davvero il loro giudizio. La quota automatizzabile dipende dal processo e dai dati: si misura su un campione reale, non si promette in anticipo.

Un ordine di grandezza dei costi

Con il listino dichiarato da TypeSafe (0,042 dollari per milione di token in input), un’azienda che smista 2.000 richieste al giorno con uno stato medio di 500 token elabora circa un milione di token al giorno: pochi centesimi. Anche ipotizzando prezzi molto più alti in futuro, il costo della tecnologia non è il problema. Il vero investimento è nella progettazione delle domande, nella valutazione su dati reali e nell’integrazione con i sistemi esistenti.

Le domande da fare al fornitore o al team interno

• Dove vengono elaborati i dati dei nostri clienti, e con quali garanzie GDPR?
• Come misurate l’accuratezza sui nostri dati, prima di andare in produzione?
• Cosa succede quando il sistema non è sicuro? Chi riceve i casi incerti?
• Quanto costa cambiare fornitore del modello tra sei mesi?
• Quali indicatori vedremo ogni mese?

Gli indicatori da seguire

Quota di decisioni prese in automatico, tasso di errore su quelle automatiche (verificato a campione), tempo medio di gestione di una richiesta, costo per decisione. Quattro numeri che permettono a chi guida l’azienda di capire se il progetto rende, senza entrare nei dettagli tecnici.

Perché se ne parla adesso

Il tema è esploso per una ragione molto concreta: costi e limiti d’uso. Chi lavora con agenti di coding o agenti di automazione si è accorto che una parte consistente delle chiamate all’LLM serve a prendere micro-decisioni. Ogni micro-decisione costa token, secondi e, con i piani a consumo, denaro.

Cole Medin ha dedicato al tema una serie di video, a partire da Jev is the FIRST of a Whole New Class of AI Models, mostrando come sostituire le “porte” del suo setup di coding (regex fragili o chiamate LLM lente) con decisioni da circa 200 millisecondi. Sam Witteveen in Using Jev In Your Agent Harness ha mappato i punti del ciclo di un agente dove un modello decisionale ha senso: routing tra modelli, gating del rischio, selezione di strumenti e skill, ranking e triage. IndyDevDan ha pubblicato un repository con dieci livelli di utilizzo, dall'”if intelligente” fino a un agente che decide da solo quando interrogare Jev.

Il mercato si è mosso in fretta. Durante il DevDay del 29 settembre OpenAI ha annunciato un’API Decisions basata su una versione specializzata di GPT-6 Luna, che secondo l’azienda risponde in circa 150 millisecondi (una sintesi tecnica è nel confronto pubblicato da Firecrawl). Inception ha rilasciato Mercury Decide, disponibile su OpenRouter con lo stesso schema a domande tipizzate. In italiano, invece, il tema è ancora quasi assente: si trovano notizie sul finanziamento, ma poca guida operativa.

Come funziona Jev: stato, domande e risposte tipizzate

Una chiamata a Jev ha due ingredienti: uno stato (testo o JSON che descrive la situazione) e una o più domande tipizzate. Il modello valuta ogni domanda in modo isolato rispetto allo stesso stato e restituisce le risposte tutte insieme.

La documentazione ufficiale definisce tre primitive.

Primitiva	Cosa chiede	Cosa restituisce	Esempio d’uso
Choice	Scegli una opzione da un elenco (fino a 255)	Opzione scelta, probabilità per opzione, confidenza	Assegnare un ticket al team giusto
Score	Valuta lo stato su una scala ordinata che definisci tu	Livello, probabilità per livello, confidenza	Grado di urgenza o di rischio di una richiesta
Noul	Questa affermazione è vera?	Un valore tra 0 e 1	“Il messaggio contiene dati personali”

Il consiglio della documentazione è tenere ogni domanda stretta e atomica. Se una decisione dipende da tre fattori, conviene chiedere i tre fattori separatamente e combinarli nel proprio codice. In questo modo il peso di ogni fattore resta sotto controllo e si può modificare senza cambiare il modello.

Un primo esempio in Python

Il quickstart usa il pacchetto typesafe-sdk (Python 3.10+) o @typesafe-ai/sdk per Node.js 20+. La chiave API va nella variabile d’ambiente TYPESAFE_API_KEY. Ecco un esempio di triage di un messaggio di supporto, adattato al nostro caso:

from typesafe_sdk import Choice, Noul, Score, TypeSafeClient

stato = """Cliente: Rossi Srl (piano Business)
Messaggio: Da stamattina il gestionale non sincronizza gli ordini
con il magazzino e abbiamo 40 spedizioni ferme."""

with TypeSafeClient(model="jev-latest") as client:
    risultato = client.system_one(
        state=stato,
        questions={
            "team": Choice(
                instructions="Quale team deve gestire la richiesta",
                criteria={
                    "tecnico": "Malfunzionamenti, errori, integrazioni",
                    "amministrazione": "Fatture, pagamenti, contratti",
                    "commerciale": "Prezzi, nuovi servizi, preventivi",
                },
            ),
            "urgenza": Score(
                instructions="Impatto operativo per il cliente",
                criteria=["Basso", "Medio", "Alto", "Bloccante"],
            ),
            "dati_sensibili": Noul(
                instructions="Il messaggio contiene dati personali o credenziali"
            ),
        },
    )

team = risultato.choices["team"]
print(team.choice, team.confidence)
print(risultato.scores["urgenza"].score)
print(risultato.nouls["dati_sensibili"].noul)

Tre domande, una sola chiamata, nessun testo da interpretare. Lo stesso schema si inserisce bene in un CRM o gestionale su misura, dove il triage delle richieste è spesso il primo collo di bottiglia. Il risultato contiene anche le probabilità complete, utili per il logging e per tarare le soglie. Dave Ebbelaar ha pubblicato esempi Python completi nel suo AI Cookbook, utili come base di partenza.

La confidenza è la parte che conta

Un LLM può dirti “sono sicuro al 95%”, ma quel numero è testo generato, non una misura. Un modello decisionale restituisce una distribuzione di probabilità da cui si calcola la confidenza. Se il modello è ben calibrato, le risposte date con confidenza 0,8 sono corrette circa otto volte su dieci.

Il concetto di calibrazione non è nuovo: chi ha lavorato con il machine learning classico lo conosce dalla documentazione di scikit-learn sulla calibrazione delle probabilità. La novità è averlo in un modello generale, utilizzabile senza addestrare un classificatore per ogni problema.

James Briggs ha misurato la calibrazione di Jev e di diverse alternative su sei dataset (intenti bancari, intenti con fuori-dominio, selezione di strumenti, jailbreak, prompt injection, tossicità). Nel suo articolo con benchmark e metodologia riporta, per esempio, un errore di calibrazione (ECE) di 0,05 per Jev sul dataset CLINC150 contro 0,12 di un LLM piccolo senza ragionamento. L’osservazione più utile è qualitativa: l’LLM tendeva a dichiarare 0,99 di confidenza quasi sempre, mentre Jev distribuiva la confidenza su tutta la scala. Ed è proprio la distribuzione a rendere utile il numero.

Soglie diverse per azioni diverse

La guida sulla confidenza suggerisce tre fasce: confidenza alta, agisci in automatico; media, procedi con cautela o chiedi conferma; bassa, non agire e passa a una persona. E soprattutto ricorda che una soglia non è un numero unico: un’azione distruttiva richiede una soglia più alta di un’azione in sola lettura.

SOGLIE = {
    "sola_lettura": 0.50,   # es. suggerire una risposta in bozza
    "reversibile": 0.75,    # es. assegnare un ticket, aggiungere un'etichetta
    "irreversibile": 0.92,  # es. chiudere un ordine, inviare un'email al cliente
}

def decidi(risposta, rischio):
    if risposta.confidence < 0.50:
        return "a_persona"
    if risposta.confidence >= SOGLIE[rischio]:
        return "automatico"
    return "chiedi_conferma"

Questi valori sono un punto di partenza, non una regola. Le soglie giuste dipendono dai tuoi dati: vanno misurate su un campione reale e riviste dopo qualche settimana di produzione.

Dove inserire un modello decisionale in un agente

Un agente moderno è un ciclo: legge lo stato, decide cosa fare, chiama uno strumento, osserva il risultato, ripete. In questo ciclo ci sono molti punti in cui si prende una decisione chiusa. Sono i candidati naturali.

1. Routing tra modelli

Non tutte le richieste meritano il modello più potente (e più costoso). Una domanda Choice con opzioni come “semplice”, “media”, “complessa” può indirizzare la richiesta al modello adatto. Sam Witteveen ha mostrato un router di questo tipo nel video How to Build Things with Jev & OpenJevs, con modelli locali e cloud.

2. Gating del rischio

Prima di eseguire un comando, un agente di coding può chiedere: “questo comando modifica file fuori dal progetto?”, “cancella dati?”, “fa una richiesta di rete verso un dominio sconosciuto?”. Tre Noul in parallelo costano meno di una chiamata LLM e restituiscono valori da confrontare con soglie precise. Cole Medin usa esattamente questo schema come hook di sicurezza nel suo setup, come racconta in The BEST Jev Use Cases for AI Coding.

3. Selezione di strumenti e skill

Quando un agente ha a disposizione decine di strumenti, descriverli tutti nel prompt consuma contesto. Una domanda Choice sullo stato attuale può preselezionare i tre o quattro strumenti pertinenti, e solo quelli vengono passati all’LLM.

4. Guardrail su input e output

Prompt injection, jailbreak, dati personali, contenuti tossici: sono tutte classificazioni. Ha senso farle con un modello che risponde in decine o centinaia di millisecondi, prima che il testo arrivi all’LLM o all’utente.

5. Triage e filtri in tempo reale

Email in arrivo, notifiche, log, issue su GitHub, notizie da monitorare. Il modello decisionale scarta il rumore e lascia all’LLM solo ciò che merita attenzione. IndyDevDan lo applica a un agente che smista notizie in “hype”, “fatto” o “segnale”.

6. Ranking e giudizio

Valutare dieci varianti di una risposta, ordinare risultati di ricerca, decidere se un test generato è significativo. Una Score con una scala chiara funziona meglio di un “giudica da 1 a 10” scritto in un prompt.

Pattern di architettura consigliati

La sezione Patterns della documentazione descrive quattro schemi ricorrenti. Li riprendiamo con il nostro punto di vista.

• Speculative fan-out: invia molte domande in una sola chiamata, anche quelle che forse non ti serviranno. Il codice decide poi quali risposte usare. Costa poco perché tutte le domande condividono lo stesso stato.
• Confidence-gated routing: la confidenza diventa un secondo asse della decisione. Non solo “quale team”, ma “quale team, e quanto sono sicuro”.
• Composite scoring: più dimensioni valutate separatamente e combinate in un punteggio unico con pesi decisi da te. Utile per lead scoring, priorità dei ticket, rischio di una modifica al codice.
• Intent routing: classificare l’intento dell’utente e inviarlo al gestore corretto. È il caso d’uso più semplice e spesso il primo da implementare.

A questi aggiungiamo un pattern che vediamo spesso nei progetti reali: veloce e lento insieme. Il modello decisionale prende le decisioni frequenti e semplici; l’LLM interviene quando la confidenza è bassa o quando serve generare testo. Nei test di James Briggs su Doom, la combinazione di un modello veloce con un LLM “allenatore” ha battuto entrambi i modelli usati da soli.

Costi e prestazioni: cosa dicono i numeri

Partiamo da un’avvertenza: la maggior parte dei numeri disponibili viene dai fornitori. Vanno presi come ordini di grandezza, non come garanzie.

Opzione	Latenza dichiarata	Prezzo dichiarato	Note
Jev (TypeSafe)	70-500 ms per chiamata	$0,042 per milione di token in input, output gratuito	Early access con lista d’attesa; servizio in USA
API Decisions (OpenAI)	circa 150 ms	Da verificare sul listino OpenAI	Basata su GPT-6 Luna; supporta anche immagini
Mercury Decide (Inception)	Fino a 14 decisioni al secondo	Prezzo promozionale su OpenRouter	Stesso schema a domande tipizzate
GLiNER2.5 e simili (open)	Decine di ms in locale	Solo costo dell’hardware	Licenza Apache 2.0; nessun dato esce dall’azienda
LLM piccolo senza ragionamento	Circa 0,7-1,5 s	Da $0,20 a qualche dollaro per milione di token	Flessibile, ma confidenza poco affidabile

Per un’azienda italiana due righe di questa tabella meritano attenzione. La prima: la latenza di rete conta. Briggs misura circa 90 ms di elaborazione lato server per Jev ma circa 340 ms di andata e ritorno; dall’Europa la quota di rete sarà simile o superiore. La seconda: i modelli open eseguibili in locale risolvono anche il tema della residenza dei dati, che per molte PMI è decisivo.

Quando non usare un modello decisionale

Un modello decisionale non è un LLM più economico. È uno strumento diverso, con limiti precisi. Dai test pubblicati e dalla documentazione emergono questi casi in cui non funziona.

• Serve generare testo: risposte ai clienti, codice, query di ricerca, riassunti. Qui serve un LLM.
• Le opzioni non sono note in anticipo: se non puoi elencare le risposte possibili, non è una decisione chiusa.
• Troppe opzioni: Jev gestisce fino a 255 scelte per domanda. Oltre serve una fase di preselezione.
• Stato troppo grande: secondo i test di Briggs le prestazioni calano con stati molto lunghi, e il limite pratico è intorno ai 32.000 token. Meglio passare uno stato sintetico e pertinente.
• Ragionamento in più passi: il modello non pianifica. Se la decisione richiede di confrontare documenti, fare calcoli o seguire una catena di condizioni, va spezzata o affidata all’LLM.
• Serve trasparenza totale: Jev è un modello chiuso e senza paper tecnico. In contesti regolati può essere preferibile un modello open documentato.

Errori comuni (e cosa non ti dicono i tutorial)

Nei video le demo funzionano sempre. In produzione emergono problemi che vale la pena conoscere prima.

Domande ambigue

La qualità della decisione dipende dalla qualità della domanda. “Il cliente è arrabbiato?” è vago. “Il messaggio contiene lamentele esplicite o minacce di disdetta?” è verificabile. Scrivi le domande come scriveresti un criterio di accettazione.

Opzioni sovrapposte

Se “tecnico” e “integrazioni” sono due opzioni distinte ma un problema di sincronizzazione rientra in entrambe, la probabilità si divide e la confidenza crolla. Le opzioni devono essere mutuamente esclusive, oppure va previsto un caso “più di una”.

Soglie copiate da un tutorial

Una soglia di 0,9 può essere prudente su un dataset e inutile su un altro. Misura sempre su un campione etichettato del tuo dominio: bastano 200-300 esempi per capire se la calibrazione regge.

Nessun logging delle probabilità

Se salvi solo la scelta e non la distribuzione, perdi l’informazione che serve per correggere le soglie e per spiegare perché il sistema ha deciso in un certo modo. Salva tutto: stato, domande, probabilità, versione del modello.

Dipendenza da un solo fornitore

Il mercato è nato da poche settimane. Prezzi, limiti e API cambieranno. Conviene isolare la chiamata dietro un’interfaccia interna (per esempio una funzione decidi(stato, domande)) così da poter passare da Jev all’API Decisions o a un modello locale senza toccare il resto dell’applicazione.

Portarlo in produzione

La differenza tra un esperimento e un sistema affidabile sta in cinque aspetti.

Valutazione prima del rilascio

Costruisci un set di esempi reali con la risposta corretta. Misura accuratezza e calibrazione per ogni domanda. Ripeti la misura a ogni cambio di versione del modello: la risposta include il campo model con la versione esatta, usalo.

Privacy e dati

Lo stato che invii contiene spesso dati di clienti. Verifica dove viene elaborato, per quanto tempo viene conservato e se esiste un accordo sul trattamento dei dati conforme al GDPR. Se la risposta non è chiara, valuta un modello open in locale o pseudonimizza lo stato prima dell’invio.

Fallback

Se il servizio non risponde entro un tempo massimo, l’applicazione deve sapere cosa fare: usare un LLM, applicare una regola di default o mettere la richiesta in coda per una persona. Mai bloccare il flusso.

Osservabilità

Monitora la distribuzione della confidenza nel tempo. Se la quota di decisioni a bassa confidenza cresce, i dati in ingresso stanno cambiando: nuovi tipi di richieste, nuovi prodotti, nuovi clienti. È un segnale prezioso, non solo un problema.

Costi reali

Il prezzo per token è basso, ma il volume può essere alto: un agente che interroga il modello dieci volte al secondo produce milioni di chiamate al mese. Calcola il costo sul volume reale, non sulla singola chiamata.

Vuoi capire dove un modello decisionale può ridurre costi e tempi nei tuoi flussi? Nella nostra consulenza AI analizziamo i processi, individuiamo le decisioni ripetitive e prototipiamo una soluzione misurabile prima di scegliere il fornitore.

Alternative open source e locali

Non serve per forza un servizio cloud. Esiste una famiglia di modelli encoder piccoli, con licenza Apache 2.0, che fanno classificazione e decisioni con probabilità e girano su un normale server o persino su un portatile.

Nei test di Briggs il più costante è stato GLiNER2.5 (da 74 a 300 milioni di parametri), con latenze di 23-53 ms per decisione in locale. Altri modelli citati sono specializzati: alcuni sono forti sulla selezione degli strumenti, altri su jailbreak e prompt injection. Briggs li raccoglie sotto l’etichetta informale di “OpenJev” nel video I Tested Jev AI Against LLMs and Open Source.

I vantaggi di un modello locale sono evidenti: nessun dato esce dall’infrastruttura, nessun costo per chiamata, latenza minima. Gli svantaggi: va gestita l’infrastruttura, l’accuratezza su compiti generali è spesso inferiore, e va fatto un minimo di lavoro di valutazione. Per un primo progetto suggeriamo di partire con un servizio gestito per validare l’idea, e passare a un modello locale quando volumi o vincoli di privacy lo giustificano.

Da dove partire questa settimana

1. Elenca le decisioni ripetitive del tuo agente o della tua automazione. Cerca le chiamate LLM che restituiscono un’etichetta, un sì/no o un punteggio.
2. Scegline una con volume alto e rischio basso, per esempio la classificazione delle richieste in arrivo.
3. Prepara 200 esempi etichettati presi dai dati reali, togliendo i dati personali.
4. Confronta tre opzioni: l’LLM attuale, un modello decisionale gestito e un modello open locale. Misura accuratezza, calibrazione, latenza e costo.
5. Metti in produzione con soglie prudenti e un fallback verso una persona. Rivedi le soglie dopo due settimane di dati. È lo stesso ciclo ascolta-progetta-migliora che seguiamo nel nostro metodo di lavoro.

Checklist prima di integrare un modello decisionale

• La decisione ha opzioni note, mutuamente esclusive e inferiori a 255.
• Ogni domanda è atomica e scritta come un criterio verificabile.
• Esiste un set di valutazione con esempi reali e risposte corrette.
• Le soglie di confidenza dipendono dal rischio dell’azione.
• Stato, probabilità e versione del modello vengono registrati.
• Il trattamento dei dati è conforme al GDPR o i dati sono pseudonimizzati.
• C’è un fallback in caso di errore o lentezza del servizio.
• La chiamata è isolata dietro un’interfaccia interna sostituibile.
• Il costo è stimato sul volume reale mensile.
• Una persona controlla le decisioni a bassa confidenza.

Domande frequenti

Fonti e approfondimenti

• TypeSafe: Introducing System One Models and Jev
• Documentazione TypeSafe: introduzione e primitive
• Documentazione TypeSafe: probabilità e confidenza
• James Briggs: Understanding Jev (benchmark e metodologia)
• IndyDevDan: Ten Levels of Jev (GitHub)
• Firecrawl: OpenAI Decisions API vs Jev
• scikit-learn: calibrazione delle probabilità

Stai progettando un agente AI e vuoi tenere sotto controllo costi e affidabilità? Raccontaci cosa vuoi fare: partiamo dalle decisioni che il tuo sistema prende ogni giorno.