In Men in Black II, l'agente J fa visita a K in un ufficio postale apparentemente normale. Apre una macchina smistatrice di posta e rivela un alieno all'interno, intento a smistare rapidamente le lettere.
È una scenetta ridicola, ma ci offre anche un modo utile per pensare all'IA.
Tra il ricevere qualcosa e il farci qualcosa, c'è spesso una decisione più piccola da prendere: dove va collocato questo?
Se prendi questa decisione correttamente fin dall'inizio, il resto del sistema può seguire il percorso appropriato.
Ho pensato molto a quel piccolo alieno mentre sviluppavo software basato sull'IA.
Un'applicazione riceve una domanda sulla fatturazione, una segnalazione di bug, la foto di un prodotto e una richiesta per prenotare una demo. Ognuna richiede una gestione diversa. Eppure rischiamo di chiedere allo stesso large language model di esaminare tutto e capire cosa fare dopo. Non è né efficiente né economico.
Ecco perché credo che i modelli specializzati giocheranno un ruolo molto più grande nel futuro dell'IA. Ad esempio, Jev è costruito per decisioni strutturate su cui il software può agire. Coinbase ha adattato Qwen3.5-9B specificamente per il rilevamento delle frodi nel suo servizio Onramp. Ognuno si concentra su un compito definito, con risultati misurabili.
https://x.com/brian_armstrong/status/2109412046244913643
Sto costruendo il livello di smistamento
Le richieste familiari possono andare direttamente a un flusso di lavoro definito. Le richieste che richiedono più ragionamento passano a un altro modello. Quelle ambigue vengono segnalate per chiarimenti o revisione.
Il potenziale risparmio deriva dal dare a ogni richiesta la quantità di elaborazione di cui ha bisogno. Poi dobbiamo misurare se lo smistatore prende abbastanza decisioni corrette da giustificare la sua presenza.
Il nostro punto di partenza è stato CludeMem. Stavamo cercando di decidere cosa un'IA dovesse ricordare, cosa dovesse recuperare e cosa stesse consumando token inutilmente. Una preferenza duratura, un'istruzione temporanea e una domanda irrisolta meritano trattamenti diversi. Prima di prendere queste decisioni, avevamo bisogno di classificare le informazioni.
Da qui è nata l'idea di un livello di classificazione più ampio. Lo stesso passaggio potrebbe aiutare a smistare una richiesta di supporto, instradare un documento o scegliere quale specialista dovrebbe gestire un'attività.
GIF
Man mano che emergono modelli più specializzati, le applicazioni dovranno decidere quali input meritano la loro attenzione. Questa è la parte che stiamo costruendo: classificare ciò che arriva, gestire localmente i casi familiari e passare quelli più difficili al modello o al processo di revisione appropriato.
Entra in scena Clude Cat (Cat sta per categorizzazione 😉)
Prima di memorizzare un ricordo, recuperare un documento, chiamare uno strumento o generare una risposta, di solito c'è una decisione da prendere sul tipo di informazione con cui abbiamo a che fare.
Queste decisioni sono ovunque.
Immagina che qualcuno scriva a un'azienda software:
"Dove posso scaricare la mia fattura?"
Un agente IA potrebbe leggere il messaggio, ispezionare i suoi strumenti, considerare l'intento del cliente e decidere di cercare una fattura.
Un flusso di lavoro più diretto potrebbe essere questo:
Messaggio → richiesta di documento di fatturazione → verifica dell'account → recupero della fattura.
Un modello linguistico potrebbe comunque scrivere la risposta. La decisione iniziale di instradamento potrebbe essere gestita localmente.
Ora cambiamo il messaggio:
"Mi è stato addebitato due volte, il mio account è bloccato e voglio disdire."
Inviare con sicurezza questo messaggio in un singolo flusso di lavoro per le fatture creerebbe solo più lavoro. Ci sono diversi problemi da risolvere e la risposta giusta potrebbe richiedere chiarimenti o l'intervento di una persona.
Lo smistatore deve avere il permesso di dire: "Non riesco a classificare questo in modo affidabile".
Questa è una parte essenziale del prodotto. Un sistema che invia con sicurezza le richieste alla destinazione sbagliata può annullare il suo vantaggio in termini di velocità a causa del lavoro necessario per correggere i propri errori.
Per il cliente, il beneficio previsto è meno attesa e meno ripetizioni.
Per lo sviluppatore, è una decisione esplicita che può ispezionare, testare e modificare. Può vedere la categoria selezionata, la versione del modello, il tempo di elaborazione e se il sistema ha rifiutato di prendere una decisione.
Sotto il cofano, l'implementazione testuale inizia con un piccolo modello pre-addestrato chiamato encoder.
Converte un messaggio in un elenco di numeri che rappresentano aspetti del suo significato. Gli sviluppatori chiamano questa rappresentazione embedding.
"Dov'è la mia fattura?" e "Ho bisogno di una copia del mio conto" usano parole diverse. Le loro rappresentazioni numeriche possono comunque essere abbastanza simili da permettere al sistema di riconoscere lo stesso tipo di richiesta.
Un livello di classificazione usa queste rappresentazioni per assegnare un punteggio alle categorie definite dallo sviluppatore.
Abbiamo implementato due approcci. Uno confronta il messaggio in arrivo con esempi di ciascuna categoria. L'altro apprende i confini tra le categorie partendo da esempi etichettati.
Nell'approccio fitted (addestrato), manteniamo l'encoder fisso e addestriamo un livello decisionale più piccolo sopra di esso. Non abbiamo bisogno di addestrare un nuovo modello di base per ogni applicazione.
Lo sviluppatore deve comunque definire il significato delle categorie e collegarle ad azioni utili. Il classificatore non può inventare i reparti dell'azienda, la politica di rimborso o i permessi degli account.
Serve anche una policy di accettazione.
La categoria con il punteggio più alto potrebbe comunque non corrispondere bene. Due categorie potrebbero essere quasi in parità. Una richiesta sconosciuta potrebbe assomigliare a qualcosa di familiare.
I nostri attuali punteggi locali non sono probabilità calibrate. Un punteggio di 0.92 non significa automaticamente "92% di probabilità di essere corretto".
Dobbiamo testare cosa succede quando quei punteggi controllano le decisioni.
L'output distingue quindi tra una categoria accettata, una richiesta che necessita di revisione e un errore tecnico. Anche timeout, annullamenti ed errori del modello necessitano di una gestione prevedibile.
Questa è l'ingegnerizzazione attorno allo smistatore. Determina se un'altra applicazione può usare il risultato in modo sicuro e coerente.
Abbiamo condotto un esperimento su 770 richieste bancarie per vedere se questo approccio potesse ridurre il lavoro dei modelli generativi.
La prima configurazione inviava ogni richiesta a un modello Qwen2.5 7B in esecuzione locale per la classificazione.
La seconda utilizzava prima il nostro classificatore locale e inviava le richieste irrisolte a Qwen.
I risultati sono stati:
- Le chiamate a Qwen sono scese da 770 a 227.
- Le classificazioni corrette sono aumentate da 535 a 642.
- L'accuratezza su tutti gli input è passata dal 69.5% all'83.4%.
- La somma dei tempi di query misurati è scesa da 299.7 secondi a 87.7 secondi.
Lo stadio locale ha evitato 543 chiamate a Qwen, una riduzione del 70.5%.
La cache è rimasta abilitata e l'approccio diretto è stato eseguito prima di quello combinato. I dati sui tempi escludono setup e warmup. Abbiamo misurato la classificazione, senza generare risposte finali ai clienti o pagare un fornitore di modelli.
Quei numeri descrivono questa configurazione. Non stabiliscono una superiorità rispetto a qualsiasi LLM né dimostrano risparmi per i clienti.
Un esperimento successivo e separato ha testato un classificatore locale fitted su 24 intent relativi a viaggi e ambiente di lavoro.
Su 720 richieste, ne ha accettate 688 localmente. Di queste, 681 erano corrette e sette sbagliate. Ne ha lasciate 32 per la revisione.
Questo ci dà due misurazioni diverse:
- Copertura: ha gestito il 95.6% delle richieste localmente.
- Precisione sulle accettate: è stato corretto nel 99.0% delle decisioni che ha accettato.
Entrambe fanno parte del risultato. Un classificatore potrebbe raggiungere una precisione impressionante accettando solo una manciata di richieste facili.
Abbiamo anche testato 100.000 input sconosciuti che dovrebbero ricadere fuori dalle sue categorie supportate. È stato accurato più del 94% delle volte.
Riconoscere ciò che il sistema non sa rimane parte del lavoro.
Anche la velocità richiede la stessa attenzione. In un test separato con CPU calda, il classificatore bancario completo ha impiegato circa 1.8 millisecondi per richiesta come valore mediano su M4 Max. Questo includeva tokenizzazione, embedding e scoring.
Escludeva il download del modello e il suo avvio. È una misurazione della classificazione, non il tempo necessario per risolvere l'intera richiesta dell'utente. Inoltre, non garantisce le stesse prestazioni su un telefono o un normale laptop.
Jev rientra in questa discussione perché affronta già una classe simile di decisioni.
TypeSafe documenta Jev come un modello per giudizi delimitati, inclusa la scelta tra opzioni fornite e l'instradamento delle richieste verso codice ordinario, modelli specialistici o esseri umani. \Documentazione sull'intent-routing di Jev\
Il ruolo che vedo per Jev è quello di un percorso di escalation opzionale per le richieste che il classificatore locale non riesce a risolvere in modo affidabile.
L'architettura verso cui stiamo lavorando è semplice:
Richiesta in arrivo → classificazione locale → le richieste familiari seguono un percorso definito; quelle incerte passano a Jev, a un altro modello o alla revisione umana.
Senza Jev, lo stesso stadio di classificazione locale può restituire le richieste irrisolte all'LLM esistente dell'applicazione, al passaggio di chiarimento o al processo di revisione.
Lo sviluppatore controlla le categorie, le soglie di accettazione e il fallback. Può introdurre il classificatore locale in un flusso di lavoro esistente e misurare quali decisioni può assumere.
Oggi, l'integrazione con Jev opera in shadow mode, confrontando le decisioni su cinque macro-argomenti senza modificare il comportamento dell'applicazione. Il passo successivo è testare se l'escalation selettiva migliora l'intero flusso di lavoro. I risultati di Qwen riportati sopra non sono un benchmark di Jev.
Questo è ciò che dobbiamo misurare: meno chiamate inutili ai modelli, gestione più rapida delle richieste familiari e un percorso esplicito per i casi che richiedono maggiore attenzione.
Abbiamo iniziato a estendere lo stesso approccio alle immagini.
Immagina un'azienda che riceve uno scontrino, lo screenshot di un errore e la fotografia di un prodotto. Ognuno richiede un percorso di elaborazione diverso.
Uno scontrino potrebbe andare all'estrazione dei dati di ricevuta. Uno screenshot potrebbe entrare in un flusso di lavoro di supporto. La foto di un prodotto potrebbe entrare in un flusso di lavoro di catalogo. Un'immagine incerta potrebbe andare in revisione.
Il classificatore seleziona la destinazione. Leggere il totale dell'acquisto, diagnosticare l'errore e identificare i dettagli del prodotto rimangono compiti separati.
La nostra implementazione sperimentale per le immagini utilizza un encoder CLIP pre-addestrato per produrre una rappresentazione numerica dell'immagine.
Un candidato di ricerca fitted ha classificato correttamente 19 fotografie di prodotti alimentari su 20 in un piccolo test diagnostico. Ha anche inviato tutte e 30 le immagini di foglie di fagiolo in revisione.
L'errore è stato classificare l'etichetta nutrizionale e il codice a barre di una bottiglia come uno scontrino.
Il problema è evidente. Entrambi possono contenere testo denso, numeri e layout rettangolari. Abbiamo bisogno di esempi che insegnino il confine che interessa alla nostra applicazione.
Quel campione è troppo ristretto per un'affermazione valida in produzione. Le etichette derivavano dal dataset anziché essere valutate in modo indipendente, e non c'erano nuovi esempi di scontrini o screenshot nel test. La demo pubblica utilizza una baseline separata, quindi il risultato del candidato fitted non dovrebbe essere attribuito ad essa.
Anche l'elaborazione delle immagini era più pesante della classificazione del testo. L'elaborazione mediana a caldo ha richiesto circa 36 millisecondi in Node e 197 millisecondi in Chromium su M4 Max. Il browser ha prima bisogno di circa 85 MiB di asset del modello, oltre al suo runtime.
L'esecuzione locale ha comunque dei costi. Dimensioni del download, memoria, tempo di avvio e prestazioni del dispositivo fanno tutti parte della valutazione.
Il prodotto che ho in mente si inserisce in un'applicazione esistente dove decide cosa succede dopo.
Uno sviluppatore definisce le categorie, fornisce esempi rappresentativi, collega le destinazioni e sceglie cosa dovrebbe accadere quando la classificazione è incerta.
Il primo deployment dovrebbe osservare il flusso di lavoro attuale senza modificarne il risultato. Possiamo poi confrontare le decisioni proposte con i risultati verificati prima di consentire al classificatore di controllare l'instradamento.
Dobbiamo ispezionare gli errori accettati con la stessa attenzione delle richieste rifiutate. Altrimenti, una decisione sbagliata ma presa con sicurezza può scomparire dietro un punteggio rassicurante.
Anche training, calibrazione e test necessitano di dati separati. Il training insegna le categorie. La calibrazione seleziona le regole di accettazione. Un test protetto verifica il risultato congelato.
Una volta che un errore del test influenza il modello successivo, quell'esempio diventa dato di sviluppo. La valutazione successiva richiede un test fresco.
Il piccolo alieno nello smistatore di posta offre alle persone un modo per visualizzare il compito. Costruire una versione utile significa scoprire esattamente quali input può gestire, quando dovrebbe chiedere aiuto e quanto costano i suoi errori.
Il passo successivo è un flusso di lavoro rappresentativo con etichette indipendenti e un registro di ogni risultato. Dobbiamo misurare quante richieste prendono il percorso locale, quante raggiungono un altro modello, quante vanno storte e se l'intera applicazione diventa più veloce o economica dopo aver tenuto conto di quegli errori.
È ora di scalare e dare un po' di steroidi a questo modello locale.
