Il framework di OpenRouter per i modelli agent rifiuta l'impostazione predefinita basata sul punteggio più alto

OpenRouter ha pubblicato un framework per modelli agent che mette in discussione, in tre passaggi, un presupposto familiare: il modello con il punteggio più alto è raramente il vincitore automatico. L'alternativa parte da una soglia di qualità specifica per attività, testa tre fasce di modelli su 20-50 esempi rappresentativi e seleziona l'opzione meno costosa che supera la soglia in modo affidabile.

Sembra una formula di approvvigionamento, ma modifica una decisione di prodotto più profonda. I team trattano spesso la selezione del modello come un problema di classifica. OpenRouter propone di affrontarla come un problema di test di accettazione, in cui i requisiti aziendali stabiliscono il punteggio minimo prima che qualsiasi modello entri in competizione.

Il principale avversario è la selezione basata prima di tutto sulle classifiche. I benchmark pubblici restano utili per creare una rosa di candidati, ma non possono rappresentare i prompt, gli strumenti, i costi dei fallimenti, i limiti di latenza e il traffico di produzione di una singola azienda. Il nuovo framework di selezione pone quindi una domanda più circoscritta: quale modello soddisfa i requisiti di questa attività al minor costo misurato?

Il framework di OpenRouter per i modelli agent parte da una soglia di qualità

L'istruzione più rilevante di OpenRouter è definire cosa sia “abbastanza buono” prima di confrontare i modelli.

Il framework considera la soglia di qualità come un requisito di accesso, non come una preferenza. Un modello economico che resta sotto la soglia viene squalificato. Un modello di frontiera che la supera ampiamente rimane idoneo, ma la sua qualità in eccesso non giustifica automaticamente un costo operativo più alto.

La sequenza conta perché i team spesso la invertono. Confrontano i punteggi dei benchmark, scelgono un modello impressionante e solo in seguito chiedono cosa richieda davvero la loro applicazione. A quel punto, la scelta del modello ha già influenzato prompt, infrastruttura, test e aspettative dei clienti.

OpenRouter propone tre passaggi. Per prima cosa, il team stabilisce una soglia di qualità per un'attività definita. In secondo luogo, misura il costo per punto di qualità usando esempi rappresentativi e una singola rubrica di valutazione. Infine, sceglie il modello meno costoso che supera la soglia con un margine maggiore della variazione di punteggio osservata tra diverse esecuzioni.

La soglia cambia in base alle conseguenze del fallimento. Un classificatore per l'assistenza clienti può inoltrare i ticket incerti a una persona. Un agent di compliance potrebbe creare esposizione legale se non rileva una clausola critica. Questi sistemi non dovrebbero ereditare lo stesso tasso di errore accettabile.

Anche la latenza aggiunge un altro requisito di accesso. Un modello può essere conveniente e accurato, ma fallire comunque in un flusso di lavoro live perché risponde troppo lentamente. OpenRouter inquadra quindi la selezione del modello come un vincolo a tre vie che coinvolge qualità, costo e velocità.

Questa impostazione evita un confronto fuorviante. Un modello lento non diventa adatto solo perché ottiene un buon punteggio. Allo stesso modo, un modello a basso costo non diventa economico quando i suoi errori causano tentativi ripetuti, escalation o attività non completate.

Il framework raccomanda inoltre di iniziare con un modello di fascia intermedia quando i requisiti restano poco chiari. I team possono poi spostare verso il basso le attività semplici e verso l'alto quelle difficili, in base ai fallimenti misurati. Ciò crea un portafoglio di scelte a livello di attività anziché un unico mandato sul modello.

L'evento non è il lancio di un nuovo modello né una vittoria in un benchmark. È un tentativo di standardizzare il modo in cui gli acquirenti interpretano un mercato dei modelli sempre più affollato. OpenRouter sostiene di fatto che l'unità di selezione dovrebbe essere un'attività di produzione, non una famiglia di modelli.

Questa distinzione diventa più importante per gli agent. Una risposta in chat spesso implica una sola chiamata al modello. Un agent può effettuare diverse chiamate, utilizzare strumenti, rivedere il proprio piano e ritentare azioni fallite prima di restituire un risultato.

Ogni passaggio aggiuntivo moltiplica l'effetto di un'impostazione predefinita costosa. Può anche amplificare piccole differenze di affidabilità. Il confronto corretto deve quindi coprire l'intera esecuzione dell'agent, non un singolo completamento isolato.

La selezione basata sulle classifiche affronta il controllo della realtà in produzione

Una classifica pubblica descrive prestazioni medie nei benchmark, mentre un agent ha successo o fallisce all'interno di uno specifico flusso di lavoro.

Le classifiche comprimono molte capacità in punteggi comparabili. Ciò le rende utili per la scoperta, ma rischiose come regole finali d'acquisto. Il modello in testa a un ampio benchmark di ragionamento potrebbe non superare un'alternativa meno costosa nel routing dei ticket, nell'estrazione di campi o nella risoluzione delle FAQ.

L'argomentazione di OpenRouter mette sotto pressione i team che utilizzano un solo modello di frontiera per ogni passaggio. Mette sotto pressione anche i fornitori di modelli il cui posizionamento premium dipende dalla leadership nelle capacità generali. In un test specifico per attività, l'eccellenza generale deve tradursi in un miglioramento significativo sul carico di lavoro reale dell'acquirente.

La pressione è immediata per gli agent ad alto volume. Un flusso di assistenza potrebbe classificare una richiesta, recuperare la cronologia del cliente, chiamare uno strumento interno, generare una risposta e controllare la propria risposta. Inviare ogni passaggio al modello disponibile più potente trasforma una decisione costosa in diverse decisioni costose.

L'economia di produzione dipende anche dai fallimenti. Il costo più basso per token può produrre un'attività completata costosa quando un modello ritenta spesso o invia troppi casi a un fallback più potente. Un modello apparentemente costoso può risultare conveniente quando completa il lavoro in modo affidabile con meno passaggi.

Per questo OpenRouter misura il costo rispetto all'output valutato. Il denominatore rilevante non è costituito soltanto da token o richieste. È una prestazione accettabile nell'attività che l'azienda deve completare.

L'approccio si allinea a un più ampio cambiamento nella valutazione degli agent. Le linee guida di Anthropic sulla valutazione degli agent distinguono un'attività da una prova e raccomandano prove ripetute perché gli output dei modelli variano. Separano inoltre la trascrizione dall'esito finale.

Questa separazione conta nelle implementazioni reali. Un agent può affermare di aver prenotato un volo, aggiornato un record o emesso un rimborso. Il risultato significativo è se il corrispondente stato del sistema sia effettivamente cambiato correttamente.

Il framework più ristretto di OpenRouter non sostituisce un sistema completo di valutazione. Colloca invece una decisione economica al di sopra di esso. La rubrica di valutazione determina se il modello supera il test, mentre l'utilizzo osservato determina quanto costa quel risultato.

Il metodo mette in evidenza anche una questione organizzativa. La selezione del modello appartiene spesso a un responsabile engineering, mentre la tolleranza al fallimento appartiene a prodotto, legale, operations o assistenza clienti. Una soglia di qualità obbliga questi gruppi a rendere esplicito il compromesso nascosto.

Per esempio, “usa il modello migliore” sembra prudente, ma lascia indefinito il termine “migliore”. Migliore potrebbe significare massima accuratezza nei benchmark, tempo di risposta più breve, costo di fallimento più basso o revisione della compliance più semplice. Questi obiettivi indicano spesso modelli diversi.

Una soglia definita trasforma questa ambiguità in una registrazione della decisione. I team possono dichiarare cosa hanno testato, cosa contava come successo, quale modello ha superato il test e quale margine rimaneva. Questa registrazione diventa utile quando un fornitore pubblica un aggiornamento.

Rende inoltre il disaccordo più produttivo. Uno stakeholder può contestare i casi di test, la rubrica o la soglia invece di discutere sulla reputazione di un marchio. La scelta del modello diventa falsificabile.

Questo metodo di valutazione dei modelli è particolarmente rilevante per i team che costruiscono flussi di lavoro AI interni. Gli ingegneri hanno bisogno di evidenze riproducibili quando un agent gestisce documenti aziendali, ticket di assistenza o record operativi. Una base di conoscenza engineering ricercabile può aiutare a conservare casi di test, decisioni e schemi di fallimento noti.

Il costo per punto di qualità cambia ciò che conta come vincitore

Il framework premia il modello meno costoso che supera il requisito, non il modello con il punteggio assoluto più alto.

OpenRouter raccomanda di testare tre candidati: un modello economico, un modello di fascia intermedia e un modello di frontiera. Ogni candidato riceve gli stessi 20-50 esempi e la stessa rubrica di valutazione.

Gli esempi dovrebbero provenire dal carico di lavoro che l'agent incontrerà realmente. I team di assistenza dovrebbero usare ticket rappresentativi. Gli agent per documenti dovrebbero usare i file, i layout e gli obiettivi di estrazione presenti in produzione. Gli agent che usano strumenti dovrebbero affrontare risposte degli strumenti e condizioni di fallimento realistiche.

I dataset pubblici non soddisfano da soli questo requisito. Spesso omettono vocabolario specifico dell'azienda, input malformati, eccezioni alle policy e comportamenti insoliti dei clienti. Possono anche incoraggiare l'ottimizzazione per domande che non compaiono mai nel prodotto distribuito.

Le attività deterministiche possono usare una valutazione a corrispondenza esatta. Un agent di routing, per esempio, potrebbe dover restituire un'unica etichetta di categoria approvata. Le attività aperte richiedono una rubrica che distingua risposte accettabili, incomplete, non supportate e pericolose.

Un giudice LLM può scalare questa valutazione, ma introduce un altro modello nella catena di valutazione. Gli online evaluator di LangSmith mostrano come i team possano valutare le tracce di produzione e campionare soltanto esecuzioni selezionate. La revisione umana resta importante quando la rubrica dipende dal giudizio o comporta conseguenze gravi.

La coerenza dell'output aiuta a prevenire differenze accidentali nella valutazione. OpenRouter indica gli output strutturati per fare in modo che ogni candidato restituisca lo stesso schema. Questo impedisce che variazioni di formattazione si spaccino per differenze di capacità.

Il framework divide quindi il costo normalizzato del carico di lavoro per il punteggio di qualità. Ciò produce un costo per punto di qualità, un confronto pensato per funzionare tra candidati e dimensioni dei set di test diverse.

Tuttavia, la soglia di qualità viene prima. Supponiamo che il candidato più economico ottenga un risultato impressionante in termini di costo per punto, ma non raggiunga la soglia richiesta. Perde comunque. L'efficienza non può salvare un risultato inaccettabile.

Tra i candidati che superano il test, vince il modello meno costoso. Un modello di frontiera può fornire un punteggio più alto e perdere comunque perché i punti aggiuntivi non soddisfano un requisito definito. Questo è il capovolgimento centrale del framework.

OpenRouter lo illustra con uno scenario di routing dell'assistenza che coinvolge opzioni economiche, di fascia intermedia e di frontiera. La fascia più bassa non raggiunge la soglia degli esempi, mentre entrambi i candidati più potenti la superano. Il modello di fascia intermedia vince perché soddisfa l'attività senza acquistare margine inutile.

Alzare la soglia cambia la risposta. Un carico di lavoro più severo può eliminare il candidato di fascia intermedia e giustificare il modello di frontiera. Il framework non sostiene che i modelli economici siano universalmente sufficienti.

Sostiene che il valore di un modello dipende dalla distanza tra la prestazione misurata e la prestazione richiesta da un'attività. Questo rende la soglia un input aziendale anziché una riflessione successiva dell'engineering.

La misurazione dei costi evita inoltre le stime manuali quando possibile. OpenRouter consiglia di leggere l'importo addebitato dal campo usage.cost della risposta. La sua contabilizzazione dell'utilizzo registra l'importo associato a ciascuna richiesta.

Questo conta perché gli agent non consumano sempre contesto prevedibile. I risultati degli strumenti variano in dimensione. I tentativi ripetuti aggiungono chiamate. Le conversazioni lunghe inviano nuovamente la cronologia. Anche le impostazioni di ragionamento, le rotte dei provider, la cache e le opzioni di servizio possono influire sull'addebito finale.

Misurare l'intera esecuzione cattura questi effetti. I team dovrebbero aggregare ogni chiamata necessaria per raggiungere l'esito valutato, inclusi tentativi ripetuti e richieste di fallback. Altrimenti, confrontano i prezzi dei modelli ignorando il comportamento dell'agent.

Il costo per punto di qualità non è ancora un’unità scientifica universale. Un miglioramento di un punto vicino a una soglia critica può contare più di diversi punti molto al di sopra di essa. Il framework affronta questo problema applicando prima una soglia e ottimizzando solo dopo.

Questo processo in due fasi è più difendibile che comprimere ogni aspetto in un unico punteggio ponderato. Un punteggio combinato può nascondere un grave fallimento di qualità dietro costi bassi. La soglia rende visibile il livello minimo di accettabilità.

I piccoli set di test rendono essenziale il margine di sicurezza

La parte più debole della proposta non è la sua logica, ma l’incertezza creata da esempi limitati e dal comportamento variabile dei modelli.

Un set da 20 a 50 esempi è pratico per un confronto iniziale. È però troppo piccolo per rappresentare ogni condizione di produzione. Errori rari, input avversariali, comportamento su contesti lunghi e stati insoliti degli strumenti possono restare invisibili.

OpenRouter affronta parte di questo problema attraverso il margine. I team dovrebbero eseguire i candidati più di una volta, oppure testarli su un campione di traffico nuovo, e registrare di quanto variano i punteggi. Il modello selezionato dovrebbe superare la soglia di qualità di un margine maggiore rispetto all’oscillazione osservata.

È una salvaguardia importante. Un modello che raggiunge la soglia una volta potrebbe scendere al di sotto nel test successivo. La sola variazione del campionamento può modificare sensibilmente un punteggio quando ogni errore rappresenta una quota rilevante di un piccolo set di test.

Le prove ripetute contano anche perché la generazione è non deterministica. Anthropic osserva che ogni tentativo in un’attività di valutazione costituisce una prova separata. Più prove producono una visione più stabile delle prestazioni dell’agente.

Il requisito diventa più rigoroso per gli agenti multi-step. Una risposta del modello può variare e quella variazione può modificare ogni successiva chiamata a uno strumento. Un piano appena diverso potrebbe produrre una traiettoria, un costo, una latenza e uno stato finale differenti.

I team dovrebbero quindi evitare di interpretare il framework come una sfida una tantum. La prima valutazione individua un candidato promettente. Il monitoraggio in produzione determina se quel candidato resta al di sopra della soglia.

Anche il metodo di scoring introduce un’altra fonte di incertezza. La corrispondenza esatta funziona bene quando esiste una sola etichetta corretta. Funziona male quando più risposte o sequenze di azioni possono raggiungere lo stesso risultato valido.

Un agente che usa strumenti può seguire un percorso inatteso e completare comunque correttamente l’attività. Al contrario, può produrre una trascrizione convincente senza modificare il sistema esterno. I valutatori dell’esito dovrebbero avere la precedenza quando l’ambiente offre uno stato verificabile.

Anche i giudici LLM richiedono calibrazione. Possono preferire risposte più lunghe, formulazioni familiari o output che ricordano il proprio stile. I team dovrebbero confrontare i punteggi dei giudici con decisioni umane prima di lasciare che un valutatore automatizzato determini l’approvvigionamento dei modelli.

La stessa soglia di qualità può essere sbagliata. Un team di prodotto potrebbe scegliere una soglia apparentemente ragionevole ma non corrispondente al danno per i clienti o al carico operativo. Tassi di escalation, tassi di reclamo, tempo di revisione manuale e costi di correzione a valle offrono un fondamento più solido.

La deriva del traffico aggiunge ulteriori rischi. Gli esempi utilizzati durante la selezione potrebbero rappresentare i clienti, i formati dei documenti o le policy del mese scorso. Un nuovo segmento di clienti può introdurre input che mettono in difficoltà il modello scelto.

OpenRouter raccomanda esplicitamente di rieseguire il confronto quando cambiano modelli o prezzi. Lo stesso principio dovrebbe valere quando cambia il carico di lavoro. Nuovi strumenti, prompt, schemi, lingue e policy possono invalidare un risultato precedente.

Il fornitore del modello può anche aggiornare il comportamento senza modificare il codice dell’applicazione. I punteggi possono variare anche quando il team mantiene lo stesso identificatore del modello. Un margine riduce questa esposizione, ma non la elimina.

Anche la latenza merita misurazioni ripetute. Un tempo medio di risposta può nascondere comportamenti lenti nella coda. Gli agenti al servizio di clienti reali dovrebbero monitorare la latenza ai percentili più elevati e la durata dell’attività completa, non soltanto la media delle singole chiamate.

Sicurezza e conformità impongono vincoli che il costo per punto non può rappresentare pienamente. Un modello può superare una soglia media di qualità producendo al contempo una divulgazione inaccettabile o un’azione non autorizzata. Alcuni fallimenti richiedono controlli rigidi, non un punteggio combinato.

I team dovrebbero quindi considerare il framework di OpenRouter per i modelli degli agenti come un livello decisionale all’interno di un sistema di valutazione più ampio. Non dimostra che un modello sia sicuro, conforme o affidabile per ogni input. Organizza la scelta economica dopo che tali requisiti diventano misurabili.

La scelta statica del modello e il routing dinamico stanno convergendo

Il framework favorisce un vincitore fisso per attività, mentre la direzione più ampia del prodotto OpenRouter punta a instradare richieste diverse verso modelli diversi.

Una scelta fissa funziona quando l’attività è circoscritta e stabile. Classificazione dei ticket, estrazione strutturata ed escalation basata su policy possono spesso utilizzare un unico modello finché il monitoraggio non rileva una deriva.

I carichi di lavoro misti pongono un problema diverso. Un singolo agente può ricevere riepiloghi semplici, domande di ricerca difficili, richieste di codice e attività di pianificazione guidate da strumenti. Una sola soglia di qualità non può descrivere tutti questi lavori.

L’instradamento automatico di OpenRouter classifica i prompt in circa 30 tipi di attività. Classifica i modelli usando modelli aggregati di spesa su una finestra mobile di sette giorni, quindi applica una fascia di costo selezionata e altre restrizioni.

Quel sistema e il nuovo framework risolvono problemi correlati a livelli differenti. Il framework usa gli esempi di un’azienda per scegliere un modello per un’attività nota. Il router usa il comportamento del mercato e la classificazione dei prompt per effettuare una scelta per richiesta.

La tensione è utile. Un router informato dal mercato offre praticità e adattamento continuo. Una valutazione privata offre fedeltà all’attività e controllo organizzativo.

Nessuno dei due prevale automaticamente. La spesa aggregata può rivelare quali modelli i professionisti ritengono affidabili, ma la popolarità non è una prova delle prestazioni per una singola applicazione. Un piccolo test interno può aderire strettamente all’applicazione, ma può diventare obsoleto o non includere nuovi candidati.

Un’implementazione matura può combinarli. I team possono definire soglie specifiche per attività, testare livelli di candidati e instradare verso l’alto i casi incerti o difficili. Le richieste semplici restano sul modello meno costoso che le gestisce in modo affidabile.

La guida separata di OpenRouter sull’escalation basata sulla confidenza segue questo schema. Un modello a costo inferiore gestisce il traffico normale, mentre le richieste al di sotto di una soglia di confidenza calibrata ricevono un’altra chiamata. Ciò può ridurre il costo medio senza accettare gli output più deboli.

Tuttavia, il routing crea costi propri. Il classificatore richiede tempo e calcolo. Le richieste inoltrate in escalation comportano più chiamate. Le differenze tra modelli possono influire su tono, uso degli strumenti, schemi e continuità della conversazione.

Il routing dinamico complica anche il debugging. Quando si verifica un fallimento, il team deve identificare il modello, il fornitore, la classificazione del prompt, la traccia degli strumenti e il percorso di fallback selezionati. Un modello fisso offre una base operativa più semplice.

L’architettura più difendibile potrebbe quindi evolvere per fasi. Prima, stabilire un modello fisso misurato per ogni attività stabile. Poi, raccogliere fallimenti e casi ambigui. Infine, introdurre l’escalation dove le evidenze la supportano.

Questo approccio preserva il principio centrale del framework. Il routing non dovrebbe diventare un altro modo per evitare di definire una qualità accettabile. Ogni ramo necessita comunque di criteri di successo e monitoraggio.

La tendenza più ampia del settore va verso portafogli di modelli. I modelli frontier per uso generale restano importanti per il lavoro difficile, ma modelli specializzati più economici possono assorbire fasi di routine ad alto volume. L’agente diventa un orchestratore di capacità anziché un wrapper attorno a un unico modello.

Questa transizione mette pressione sui fornitori affinché giustifichino i modelli premium a livello di attività. Affida inoltre maggiore responsabilità ai team applicativi. Devono assumersi la responsabilità dei dati di valutazione, della policy di routing e dell’analisi dei fallimenti, anziché delegare il giudizio a una classifica.

Tre segnali metteranno alla prova l’argomentazione di OpenRouter

Il framework conterà solo se i team riusciranno a riprodurne i risparmi senza spingere fallimenti nascosti in produzione.

Il primo segnale è se gli sviluppatori pubblicheranno confronti a livello di attività basati su traffico reale. I grafici di benchmark generici non convalideranno l’affermazione di OpenRouter. Valutazioni ripetute che mostrano risultati simili tra agenti di supporto, estrazione, programmazione o ricerca la rafforzerebbero.

I report più convincenti includeranno i costi delle esecuzioni complete, non stime per singola chiamata. Dovrebbero conteggiare uso degli strumenti, retry, fallback ed escalation umana. Dovrebbero inoltre dichiarare la soglia e la variazione osservata da un’esecuzione all’altra.

Se questi studi mostrano che i modelli di fascia intermedia superano ripetutamente soglie di qualità ristrette, l’approvvigionamento basato prima sulle classifiche si indebolirà. Se i modelli frontier continueranno a vincere dopo il test dell’intero workflow, il framework resterà utile documentando perché il premio è necessario.

Il secondo segnale è la rapidità con cui il monitoraggio in produzione modifica la scelta iniziale. I team dovrebbero osservare la deriva dei punteggi, la frequenza delle escalation, la latenza e gli esiti di business dopo l’implementazione. Un modello che supera un piccolo test ma fallisce con traffico eterogeneo renderebbe evidenti i limiti di campionamento del framework.

Prestazioni stabili sosterrebbero la regola del margine proposta da OpenRouter. Inversioni frequenti implicherebbero che i team necessitano di dataset più ampi, valutatori più solidi o una valutazione online più aggressiva prima di cambiare modello.

Il terzo segnale è l’adozione del routing ibrido. La tesi di OpenRouter diventa più forte quando i team usano modelli economici per il lavoro di routine e riservano la capacità frontier ai casi incerti. Si indebolisce quando overhead di routing, comportamento incoerente o costi di debugging annullano il beneficio previsto.

Gli acquirenti dovrebbero anche osservare come rispondono i fornitori. I provider di modelli possono introdurre varianti più piccole, output strutturati migliori, inferenza più veloce o strumenti di valutazione enterprise. Questi cambiamenti potrebbero spostare il confine tra costo e qualità senza modificare il framework stesso.

Il contributo duraturo non è un particolare modello vincente. I cataloghi di modelli cambiano troppo rapidamente perché quella conclusione possa durare. Il contributo è una regola decisionale ripetibile, riapplicabile ogni volta che cambia il mercato.

Per gli sviluppatori, l’azione immediata è semplice. Scegliere un’attività di produzione, definire una soglia basata sull’esito e raccogliere esempi rappresentativi. Testare candidati di livelli di capacità distinti con lo stesso prompt, strumenti, schema di output e valutatore.

Poi ripetere l’esecuzione. Misurare il costo totale dell’attività e la variazione del punteggio, non soltanto il risultato migliore. Conservare il modello più economico solo quando il suo margine resiste a quella ripetizione.

Per gli acquirenti enterprise, il framework offre una domanda migliore da porre ai fornitori e ai team interni. Chiedere quali evidenze sul carico di lavoro giustificano una scelta di modello, quali fallimenti la valutazione intercetta e con quale frequenza la decisione viene riesaminata.

Per i knowledge worker, la conseguenza è meno visibile ma comunque importante. Una migliore selezione dei modelli può rendere le funzionalità AI più rapide ed economiche senza ridurre automaticamente la qualità. Una selezione scadente può produrre il risultato opposto, nascondendosi dietro un prestigioso nome di modello.

Il framework OpenRouter per i modelli degli agenti sostituisce in definitiva una scorciatoia rassicurante con una disciplina operativa. Il punteggio più alto non chiude più la discussione. Il modello vincente deve superare una soglia pertinente, resistere alle normali variazioni e giustificare ogni unità di costo aggiuntiva.

Quale attività degli agenti è abbastanza costosa, frequente o rischiosa da valutare per prima? Conservatene gli esempi reali, definite cosa significa successo e fate sì che la prossima decisione sul modello risponda a quelle evidenze.