La scelta dei modelli parte dai task

Le classifiche sono input, non policy di deployment

Il modo più rapido per scegliere male un modello AI è chiedere “qual è il migliore?” senza descrivere il lavoro che deve svolgere. Una classifica può mostrare che un modello ragiona meglio, un altro è più veloce, un altro costa meno per task, un altro ancora funziona bene nel coding o nei workflow agentici. Sono segnali utili. Non sono una policy di deployment.

La tesi è una sola: la scelta dei modelli AI ha bisogno di portfolio di task, non di vincitori di classifica.

Un workflow di prodotto raramente contiene un solo compito. Un copilot per il supporto può classificare l’intento, recuperare una policy, scrivere una risposta, controllare il tono, riconoscere un rischio di escalation e aggiornare il CRM. Un workflow di coding può leggere un ticket, modificare codice, lanciare test, spiegare la diff e preparare il materiale per la review. Un workflow di ricerca può cercare, sintetizzare, confrontare, citare e segnalare incertezza. Chiamare tutto questo “un caso d’uso LLM” nasconde le decisioni vere.

Artificial Analysis è utile proprio perché non riduce il confronto tra modelli a un solo punteggio universale. La sua analisi pubblica permette di confrontare modelli per intelligence, velocità, costo per task, performance dei coding agent, capacità agentiche, comportamento degli output e prezzi. È quindi una buona base per selezionare candidati, non per delegare la decisione di prodotto. Il riferimento è qui: Artificial Analysis.

Il product leader deve però tradurre quei segnali in regole operative. Un benchmark non conosce la promessa fatta al cliente, la latenza accettabile, il margine, il costo di un errore o la capacità di review del team. Queste cose vivono nel prodotto. Per questo la scelta del modello dovrebbe partire da un portfolio di task.

Cosa deve contenere un portfolio di task?

Un portfolio di task è un artefatto operativo di una pagina che scompone un workflow AI in classi di compiti. Ogni riga descrive un lavoro svolto dal modello e i vincoli che rendono accettabile una scelta. Non è una tabella comparativa tra vendor. È una superficie di controllo del prodotto.

Si parte dalla classe di task. Il modello deve classificare, scrivere, estrarre, ragionare, programmare, cercare, ordinare, trasformare dati, usare strumenti o proporre una raccomandazione? L’etichetta conta perché gli errori non pesano tutti allo stesso modo. Una bozza creativa lenta può essere accettabile. Un assistente lento dentro un checkout può ridurre la conversione. Una risposta compliance falsa ma sicura di sé può creare rischio. Un riassunto interno mediocre può generare solo rilavorazione.

Poi serve una soglia di qualità. Non basta scrivere “abbastanza buono”. La soglia deve essere osservabile. Per un classificatore può essere la precisione minima sulle categorie ad alto rischio. Per un’estrazione può essere l’accuratezza sui campi obbligatori. Per un agente di coding può essere il superamento dei test insieme a una checklist di review umana. Questo si collega bene al principio discusso in Inference, contesto, eval: principi prima dei modelli: il team deve sapere cosa valuta prima di decidere cosa usare.

Poi va definito un tetto di latenza. Alcuni task possono aspettare. Altri stanno dentro un’esperienza interattiva in cui ogni secondo cambia il comportamento dell’utente. Un modello più forte nei benchmark può essere sbagliato per una UX in linea se rompe il ritmo. Al contrario, un task notturno di riconciliazione può meritare un modello più lento e più robusto se evita pulizia manuale.

Serve anche il costo per task, non solo il prezzo per token. Il prezzo dei token è una parte del costo. Prompt lunghi, retry, chiamate a tool, token di ragionamento, cache e tempo di review possono cambiare l’economia reale. Il costo per task costringe a chiedere: “quanto costa una singola azione di prodotto completata?” È il numero che un product owner può confrontare con margine, risparmio di supporto, aumento di conversione o capacità operativa.

Infine vanno aggiunti fallback, owner e cadenza di review. Il fallback dice cosa succede se il modello principale non è disponibile, è troppo lento, costa troppo o scende sotto soglia. L’owner dice chi risponde della riga. La cadenza di review dice quando la scelta viene rimessa in discussione. Senza questi tre campi il portfolio diventa documentazione. Con questi tre campi diventa governance.

La matrice batte il dibattito sul modello

Il dibattito sul modello di solito parte dalle preferenze. Un engineer si fida di un provider. Un altro vuole l’ultimo modello frontier. Finance vuole ridurre il costo. Design vuole risposte più rapide. Legal vuole output meno incontrollati. Hanno tutti una parte di ragione, ma la conversazione è al livello sbagliato.

La matrice cambia l’unità del confronto. Invece di discutere un solo modello per tutto il prodotto, il team discute l’aderenza per classe di task. Scrivere una risposta per l’help center richiede tono e contesto. Riconoscere un’escalation richiede classificazione prudente. Una risposta basata su retrieval richiede disciplina sulle fonti e capacità di rifiutare. Una modifica al codice richiede uso di tool, test e prove per la review.

Qui il model routing diventa una conseguenza, non una moda. In AI coding governabile con model routing, il routing è utile perché attività diverse di coding richiedono controlli diversi. La stessa logica vale fuori dal coding. Non si instradano modelli perché sembra avanzato. Si instradano perché il portfolio mostra che un solo modello non è ottimale per ogni riga.

La matrice deve rendere visibili i tradeoff. Se il modello migliore per qualità è troppo lento per un task interattivo, va scritto. Se il modello più economico aumenta il carico di review, va scritto. Se un modello piccolo va bene per estrarre dati ma non per raccomandazioni finali, va scritto. Il portfolio è utile quando rende concreto il dissenso.

Una riga pratica può contenere: classe di task, impatto utente o interno, soglia di qualità, tetto di latenza, tetto di costo, livello di rischio, modello primario, modello fallback, segnale di monitoraggio, trigger di review umana, owner, prossima data di review. È abbastanza struttura per evitare il teatro delle classifiche senza trasformare la selezione in un programma architetturale di sei mesi.

Rivedi la scelta come una scommessa di prodotto

La scelta del modello invecchia. Arrivano nuovi modelli, cambiano i prezzi, i provider migliorano la latenza, i prompt crescono, i workflow si espandono e il comportamento degli utenti si sposta. Un modello corretto tre mesi fa può essere ancora corretto oggi, ma il team dovrebbe sapere perché.

Rivedere la scelta come una scommessa di prodotto significa fissare le regole decisionali prima di cambiare. Quale evidenza giustifica uno switch? Costo più basso a parità di qualità? Qualità più alta dentro lo stesso tetto di latenza? Meno escalation? Meno tempo di review umana? Più task completati? Se la risposta è “è uscita una nuova classifica”, il team sta reagendo al rumore di mercato, non a evidenza operativa.

Questo non significa che i benchmark siano inutili. Sono strumenti di scouting essenziali. Aiutano a scoprire candidati, capire tradeoff ed evitare di testare tutto da zero. Il problema nasce quando il benchmark diventa un sostituto della verità di prodotto. La verità di prodotto è il portfolio di task insieme alla performance osservata nel tuo workflow.

Per le righe ad alto rischio la review dovrebbe includere campioni di output e analisi degli errori. Per le righe ad alto volume dovrebbe includere costo per task completato e distribuzione della latenza. Per le righe agentiche dovrebbe includere errori dei tool, azioni incomplete e qualità dell’handoff. Per le righe customer-facing dovrebbe includere correzioni degli utenti, abbandoni, escalation e reclami.

Il portfolio protegge anche dall’overkill di moda. Non ogni riga merita il modello più capace. Alcuni task hanno bisogno di affidabilità, velocità e costo prevedibile più che di massimo ragionamento. Altri meritano un modello premium perché una sola risposta sbagliata costa molto. Il portfolio permette a entrambe le cose di essere vere.

Prima di cambiare modello, audita un workflow

Se il team sta per cambiare modello, fermati per un’ora. Scegli un workflow AI che conta già per il business. Scrivi in sequenza ogni task mediato dal modello. Per ogni task compila qualità, latenza, costo, fallback, owner e soglia di review. Non partire dai nomi dei modelli. Parti dal lavoro.

Poi confronta i candidati contro le righe. Usa analisi esterne per creare una shortlist, eval interni per testare l’aderenza, telemetria di produzione per riconoscere drift e review umana per ispezionare gli errori ad alto rischio. L’output non dovrebbe essere “abbiamo scelto il Modello X”. Dovrebbe essere: “per questo task, con questi vincoli, usiamo questo modello, con questo fallback, finché questa condizione di review non cambia.”

Quella frase è noiosa nel modo giusto. Trasforma la scelta dei modelli AI da preferenza a operazione di prodotto. Dà all’engineering un target, a finance una vista sul costo unitario, ai team di rischio un trigger di review e ai product leader un modo per spiegare perché parti diverse del workflow usano modelli diversi.

I vincitori di classifica continueranno a cambiare. Il portfolio di task serve a decidere quali cambiamenti contano davvero.