Evaluations | The .NET Blog

Le eval del model router sono il passaggio che troppi team saltano

Emiliano Montesdeoca — Fri, 29 May 2026 00:00:00 +0000

Questo articolo è stato tradotto automaticamente. Per la versione originale, clicca qui.

Il routing automatico dei modelli sembra fantastico finché non ti rendi conto che devi comunque dimostrare che è la scelta giusta per il tuo carico di lavoro.

Per questo il nuovo repository di valutazione del model router è utile.

Dà ai team un modo più concreto di rispondere alle domande che contano davvero:

il routing preserva la qualità?
migliora il costo?
cosa fa alla latenza?
cosa cambia se restringo il sottoinsieme di modelli?

L’articolo sorgente fa le domande giuste

Una cosa che mi piace molto del post originale è che non tratta il model router come ovviamente buono.

Piuttosto, pone le domande scomode ma corrette:

“Sui miei prompt, il modello selezionato automaticamente dal model router eguaglia o supera il singolo modello che altrimenti sceglierei?”
“Sto davvero risparmiando denaro end to end, o sto solo spostando la spesa da una parte all’altra?”

Questa è esattamente l’atteggiamento giusto.

Perché il routing automatico è allettante, ma resta comunque una decisione di sistema. E le decisioni di sistema dovrebbero essere misurate, non ammirate.

Perché questo repository conta più di quanto sembri all’inizio

A un livello, è solo un repository di valutazione.

A un altro livello, è un segnale di maturità.

Dice: se vuoi adottare il routing automatico, ecco un modo più disciplinato per testare:

qualità
costo
latenza
compromessi del sottoinsieme
comportamento della distribuzione dei modelli

È molto meglio che trattare il routing come una scatola nera con un buon branding.

Il mio parere

Questo è un buon esempio del tipo di strumenti di cui le piattaforme AI hanno bisogno di più: non più magia, ma più modi per validare la magia prima di fidarsi di essa.

È così che i team evitano di costruire fiducia costosa su ipotesi non testate.

Articolo originale: How to run evals for the model router

La parte difficile dello sviluppo AI non è più l'accesso. È gestire bene il modello giusto

Emiliano Montesdeoca — Tue, 26 May 2026 00:00:00 +0000

Questo articolo è stato tradotto automaticamente. Per la versione originale, fai clic qui.

Abbiamo superato la fase in cui il semplice accesso a un modello potente bastava.

È esattamente il punto che questa nuova guida Foundry per gestire modelli, costi e qualità coglie bene.

La vera sfida ora è operativa:

scegliere il modello giusto per ogni workload
validarlo sui propri dati
gestire latenza e spesa
governare aggiornamenti e rischio di regressione

È questo che i team seri devono imparare a fare bene.

L’articolo sorgente definisce bene il problema

Una frase dell’articolo originale cattura molto bene questo cambiamento:

“La parte più difficile di costruire sistemi AI oggi non è più ottenere accesso a un modello capace. È sapere come scegliere, validare, ottimizzare e operare il modello giusto lungo l’intero ciclo di vita di una vera applicazione.”

È esattamente la diagnosi corretta.

Troppi team pensano ancora che la selezione del modello sia la decisione principale.

Non lo è.

L’operazione del modello è il problema più grande:

quale workload riceve quale modello?
come si verifica la qualità?
quale forma di costo è accettabile?
cosa succede quando compare un nuovo modello o uno vecchio si degrada?
come si testa un cambiamento senza rompere i workflow reali?

Questa è la vera attività di ingegneria adesso.

Perché questo pezzo di Foundry è utile

Mi piace questo articolo perché parla dei sistemi AI nel modo in cui gli ingegneri di piattaforma esperti devono davvero pensarli.

Non come “scegli il modello più intelligente e vai avanti”.

Ma come sistemi che vivono sotto trade-off:

capacità
latenza
costo
sicurezza
governance
pressione degli upgrade

È molto più utile dell’ottimismo guidato dai benchmark.

Il cambiamento più importante è pensare prima ai criteri

L’articolo originale consiglia di definire i criteri di successo prima di aprire il catalogo dei modelli.

Penso che questo sia uno degli abitudini più importanti che i team possano adottare.

Se apri prima il catalogo, ti ancora alla reputazione.

Se definisci prima i criteri, ti ancora alla realtà del workload.

È un processo più sano.

Perché il modello che vince un benchmark non è automaticamente quello che vince su:

i tuoi prompt
il tuo budget di latenza
i tuoi guardrail di costo
i tuoi requisiti di governance

Questa distinzione è il punto da cui inizia l’ingegneria AI matura.

La storia multi-modello sta diventando un vero vantaggio

Un’altra cosa che mi piace è il framing esplicitamente agnostico rispetto al modello.

L’articolo presenta Foundry non come una destinazione a modello singolo, ma come una superficie operativa su:

modelli Microsoft
modelli dei partner
modelli open source
varianti post-addestrate
strategie di routing e ottimizzazione

Questo conta perché la flessibilità del modello non è più un lusso. È parte della gestione del rischio.

Se la qualità cambia, i prezzi si muovono o le quote si restringono, i team hanno bisogno di opzioni.

Il controllo dei costi non è una preoccupazione secondaria

L’articolo ha anche ragione nel trattare il costo come una questione architetturale.

Non è un problema del tipo “lo ottimizzeremo più tardi”.

Se mandi ogni task al modello più pesante per impostazione predefinita, può funzionare benissimo in una demo e crollare sotto l’economia di produzione.

Per questo penso che le sezioni su:

routing
batching
caching
provisioned throughput
gestione delle quote

siano più importanti di quanto molti potrebbero pensare.

I team che trattano la disciplina dei costi come parte del design del sistema invecchieranno molto meglio di quelli che la trattano come lavoro di pulizia successivo.

La mia opinione

Questo è un pezzo utile di Foundry perché parla dei sistemi AI nel modo in cui gli ingegneri esperti devono davvero operarli.

Non come demo. Non come prototipi una tantum. E non come turismo dei benchmark.

Ma come sistemi operativi per workload, vincoli, trade-off e cambiamento continuo.

Questo è il livello di conversazione verso cui dobbiamo continuare a muoverci.

E se stai costruendo sistemi AI in produzione, questa è esattamente la mentalità che voglio che i team adottino presto.

Articolo originale: A Developer’s Guide to Managing Models, Cost and Quality in Microsoft Foundry

La storia di Foundry dall'osservabilità al ROI è ciò che serve alle piattaforme di agenti serie

Emiliano Montesdeoca — Mon, 25 May 2026 00:00:00 +0000

Questo articolo è stato tradotto automaticamente. Per la versione originale, fai clic qui.

Se gli agenti AI devono vivere in produzione, l’osservabilità non può fermarsi ai log e ai trace.

Per questo la nuova storia di Foundry dall’osservabilità al ROI sembra importante.

Il vero messaggio non è “abbiamo aggiunto più dashboard”.

Il vero messaggio è che le piattaforme di agenti serie hanno bisogno di un ciclo operativo continuo:

tracciare ciò che è successo
valutare se è stato buono
ottimizzare ciò che richiede lavoro
collegare il risultato al valore di business

Questa è una storia molto più solida del solito parlare a vuoto di piattaforma.

La frase chiave dell’articolo originale dice tutto

Il post originale si apre con una frase a cui penso che ogni team che costruisce agenti dovrebbe prestare attenzione:

“Rilasciare un agente AI è la parte facile. Tenerlo accurato, sicuro e responsabile in produzione è il punto in cui i team si bloccano.”

È esattamente vero.

Abbiamo già superato la fase in cui la domanda principale era: “posso far fare a un agente qualcosa di interessante?”

La domanda più difficile e più preziosa è:

posso gestire il sistema una volta che inizia a interagire con utenti reali, strumenti reali e costi reali?

È lì che Foundry sta cercando di spostare la conversazione.

Perché questo conta più di un’altra demo di agente

Molti annunci di agenti AI continuano a concentrarsi sulla creazione: costruisci l’agente, collega gli strumenti, instrada i task, pubblica l’interfaccia.

Va tutto bene.

Ma le domande operative sono il punto in cui la maggior parte dei sistemi seri diventa sostenibile oppure si trasforma in esperimenti costosi:

cosa sta davvero facendo l’agente in produzione?
ha fatto la cosa giusta?
sta peggiorando nel tempo?
costa troppo rispetto al valore che crea?
quali modifiche di configurazione hanno davvero migliorato la qualità?

Per questo penso che l’annuncio di Foundry sia più importante di un tipico riepilogo di funzionalità. Sta cercando di definire un ciclo di Agent DevOps, non solo una storia di creazione dell’agente.

Il ciclo in quattro parti è il vero prodotto qui

L’articolo organizza sostanzialmente la piattaforma attorno a quattro capacità:

Trace
Evaluate
Monitor
Optimize

Questa è la forma giusta.

Direi persino che qualunque piattaforma voglia essere presa sul serio per workload di agenti in produzione finirà per aver bisogno di tutte e quattro.

Il tracing da solo non basta.

La valutazione da sola non basta.

L’ottimizzazione senza prove è solo un’ipotesi.

E parlare di ROI senza telemetria è spesso teatro.

L’angolo dell’interoperabilità è particolarmente intelligente

Una delle scelte più forti dell’annuncio è che Foundry non finge che tutti gli agenti saranno costruiti in un unico framework.

Il post originale parla esplicitamente di tracing e valutazioni che si estendono a:

LangChain
LangGraph
OpenAI SDK
Microsoft Agent Framework
framework personalizzati tramite OpenTelemetry

Questo è importante.

Perché il lock-in di piattaforma è uno dei modi più rapidi per rendere meno attraente una storia operativa che in origine era utile.

Se i team possono mantenere le proprie scelte di framework e comunque ottenere telemetria e superfici di valutazione di livello production, l’attrito diminuisce parecchio.

La valutazione con rubriche potrebbe finire per contare più di quanto la gente si aspetti

Anche la parte di rubric evaluation merita di essere citata.

Penso che sia una delle aggiunte più pratiche dell’intero post.

Perché? Perché ciò che è “buono” dipende dal contesto.

L’articolo dice che la rubric evaluation genera “criteri di valutazione sensibili al contesto a partire dal comportamento previsto del tuo agente”. È esattamente la direzione di cui questi sistemi hanno bisogno.

Il punteggio di qualità generico è utile.

Ma alla fine i team devono valutare gli agenti secondo i propri standard:

tono
completamento delle attività
aderenza alle policy
aspettative di latenza
limiti di costo
regole di business specifiche del dominio

È lì che la valutazione diventa operativamente significativa invece che solo interessante dal punto di vista accademico.

Il ROI è la parte più scomoda, ed è per questo che conta

Penso anche che la parte ROI dell’annuncio sia importante proprio perché è scomoda.

Il post pone la domanda direttamente:

“questo agente vale quello che costa?”

Questa domanda viene spesso evitata nelle conversazioni sull’AI.

Ma è la domanda giusta.

Se la piattaforma può davvero collegare costi, completamento dei task, tempo risparmiato e trace di produzione in un unico posto, offre a engineering e leadership un linguaggio condiviso molto migliore.

E sinceramente, quel linguaggio condiviso serve eccome.

La mia opinione

Questo è uno degli annunci a livello di piattaforma migliori del gruppo, perché si concentra sull’operare gli agenti, non solo sul costruirli.

Ed è lì che inizia davvero il lavoro duro.

Le piattaforme AI più forti dei prossimi anni non saranno solo quelle con accesso a più modelli o a più demo. Saranno quelle che aiutano i team a tracciare il comportamento, valutare i risultati, ottimizzare in sicurezza e giustificare i costi con prove.

Questa storia di Foundry sta cercando di andare esattamente in quella direzione.

Per questo vale la pena prenderla sul serio.

Articolo originale: Build 2026: From observability to ROI for AI agents on any framework