Evaluations | The .NET Blog

Les avaluacions del model router són el pas que massa equips es salten

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

Aquest article s’ha traduït automàticament. L’original és aquí.

L’encaminament automàtic de models sembla fantàstic fins que t’adones que encara has de demostrar que és la millor opció per a la teva càrrega de treball.

Per això és útil el nou repositori d’avaluació del model router.

Ofereix als equips una manera més concreta de respondre a les preguntes que realment importen:

l’encaminament preserva la qualitat?
millora el cost?
què fa amb la latència?
què canvia si restrinyo el subconjunt de models?

L’article original fa les preguntes correctes

Una de les coses que més m’agrada del post original és que no tracta el model router com si fos bo per defecte.

En lloc d’això, fa les preguntes incòmodes però correctes:

“Als meus prompts, el model seleccionat automàticament pel model router iguala o supera el model únic que jo triaria?”
“Estic realment estalviant diners de punta a punta, o només estic movent la despesa d’un lloc a un altre?”

Aquesta és exactament l’actitud correcta.

Perquè l’encaminament automàtic és atractiu, però continua sent una decisió de sistema. I les decisions de sistema s’han de mesurar, no pas admirar.

Per què aquest repositori importa més del que sembla al principi

En un nivell, això és només un repositori d’avaluació.

En un altre, és un senyal de maduresa.

Diu: si vols adoptar l’encaminament automàtic, aquí tens una manera més disciplinada de provar:

qualitat
cost
latència
compensacions del subconjunt
comportament de distribució de models

Això és molt millor que tractar l’encaminament com una caixa negra amb un bon màrqueting.

La meva opinió

Aquest és un bon exemple del tipus d’eines que necessiten més les plataformes d’IA: no més màgia, sinó més maneres de validar la màgia abans de confiar-hi.

Així és com els equips eviten construir una confiança cara sobre supòsits no provats.

Article original: How to run evals for the model router

La part difícil del desenvolupament d'IA ja no és l'accés. És fer servir bé el model correcte

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

Aquesta publicació s’ha traduït automàticament. Per a la versió original, fes clic aquí.

Ja hem superat l’etapa en què simplement tenir accés a un model potent era suficient.

Això és el que aquesta nova guia de Foundry per gestionar models, cost i qualitat encerta.

El veritable repte ara és operatiu:

triar el model adequat per a cada càrrega de treball
validar-lo amb les teves pròpies dades
gestionar la latència i la despesa
governar les actualitzacions i el risc de regressió

Això és el que els equips seriosos han d’aprendre a fer bé.

L’article original defineix bé el problema

Una frase de la publicació original captura molt bé aquest canvi:

“La part més difícil de construir sistemes d’IA avui ja no és accedir a un model capaç. És saber com triar, validar, optimitzar i operar el model correcte durant tot el cicle de vida d’una aplicació real.”

Aquesta és exactament la diagnosi correcta.

Massa equips encara pensen que la selecció del model és la decisió principal.

No ho és.

L’operació del model és el problema més gran:

quin model rep cada càrrega de treball?
com es verifica la qualitat?
quin nivell de cost és acceptable?
què passa quan apareix un model nou o un de vell es degrada?
com proves un canvi sense trencar fluxos de treball reals?

Això és la feina d’enginyeria real ara.

Per què aquesta peça de Foundry és útil

M’agrada aquest article perquè parla dels sistemes d’IA com realment els han de pensar els enginyers de plataforma amb experiència.

No com “tria el model més intel·ligent i segueix”.

Sinó com sistemes que viuen sota compensacions:

capacitat
latència
cost
seguretat
governança
pressió de les actualitzacions

Això és molt més útil que l’optimisme basat només en benchmarks.

El canvi més important és pensar primer en els criteris

La publicació original recomana definir els criteris d’èxit abans d’obrir el catàleg de models.

Penso que aquest és un dels hàbits més importants que poden adoptar els equips.

Si obres primer el catàleg, t’ancores en la reputació.

Si defineixes primer els criteris, t’ancores en la realitat de la càrrega de treball.

És un procés més sa.

Perquè el model que guanya en un benchmark no és automàticament el que guanya en:

les teves promptes
el teu pressupost de latència
els teus límits de cost
els teus requisits de governança

Aquesta distinció és on comença l’enginyeria d’IA madura.

La història multillenguatge s’està convertint en un avantatge real

Una altra cosa que m’agrada és el plantejament explícitament agnòstic respecte al model.

L’article presenta Foundry no com una destinació d’un sol model, sinó com una superfície operativa sobre:

models de Microsoft
models de socis
models de codi obert
variants postentrenades
estratègies d’enrutament i optimització

Això importa perquè la flexibilitat del model ja no és un luxe. És part de la gestió del risc.

Si la qualitat canvia, els preus es mouen o la quota es restringeix, els equips necessiten opcions.

El control de costos no és una preocupació secundària

L’article també té raó en presentar el cost com una qüestió arquitectònica.

Això no és un problema de “ja ho optimitzarem més endavant”.

Si envies cada tasca al model més pesat per defecte, això pot funcionar molt bé en una demo i col·lapsar sota l’economia de producció.

Per això crec que les seccions sobre:

enrutament
batching
caching
provisioned throughput
gestió de quota

són més importants del que molta gent podria pensar.

Els equips que tracten la disciplina del cost com a part del disseny del sistema aguantaran molt millor que els que la tracten com una feina de neteja posterior.

La meva opinió

Aquesta és una peça útil de Foundry perquè parla dels sistemes d’IA tal com els han d’operar realment els enginyers experimentats.

No com a demos. No com a prototips d’una sola vegada. I no com a turisme de classificacions.

Sinó com a sistemes operatius per a càrregues de treball, restriccions, compensacions i canvi constant.

Aquest és el nivell de conversa cap al qual cal continuar movent-se.

I si estàs construint sistemes d’IA en producció, aquest és exactament el tipus de mentalitat que vull que els equips adoptin aviat.

Publicació original: A Developer’s Guide to Managing Models, Cost and Quality in Microsoft Foundry

La història d'observabilitat a ROI de Foundry és el que necessiten les plataformes d'agents serioses

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

Aquesta publicació s’ha traduït automàticament. Per a la versió original, fes clic aquí.

Si els agents d’IA han de viure en producció, l’observabilitat no pot quedar-se en logs i traces.

Per això la nova història de Foundry d’observabilitat a ROI sembla important.

El missatge real no és “hem afegit més panells”.

El missatge real és que les plataformes d’agents serioses necessiten un bucle operatiu continu:

traçar què ha passat
avaluar si ha estat bo
optimitzar el que necessita feina
connectar el resultat amb el valor de negoci

Aquesta és una història molt més sòlida que el bla bla habitual de plataforma.

La frase clau de l’article original ho diu tot

L’article original comença amb una línia a la qual crec que tot equip que construeixi agents hauria de prestar atenció:

“Llançar un agent d’IA és la part fàcil. Mantenir-lo precís, segur i responsable en producció és on els equips es queden encallats.”

Això és exactament cert.

Ja hem passat la fase en què la pregunta principal era “puc fer que un agent faci una cosa interessant?”

La pregunta més difícil i més valuosa és:

puc operar la cosa un cop comença a interactuar amb usuaris reals, eines reals i costos reals?

Aquí és on Foundry intenta empènyer la conversa.

Per què això importa més que una altra demo d’agent

Molts anuncis d’agents d’IA encara se centren en la creació: construeix l’agent, connecta les eines, enruta les tasques, publica la interfície.

Tot això està bé.

Però les qüestions operatives són el punt en què la majoria de sistemes seriosos acaben sent sostenibles o experiments cars:

què està fent realment l’agent en producció?
ha fet la cosa correcta?
empitjora amb el temps?
és massa car per al valor que crea?
quins canvis de configuració han millorat de debò la qualitat?

Per això crec que l’anunci de Foundry és més important que un resum de funcionalitats típic. Intenta definir un bucle d’Agent DevOps, no només una història de creació d’agents.

El bucle de quatre parts és el producte real aquí

L’article organitza bàsicament la plataforma al voltant de quatre capacitats:

Trace
Evaluate
Monitor
Optimize

Aquesta és la forma correcta.

De fet, diria que qualsevol plataforma que vulgui ser presa seriosament per a càrregues de treball d’agents en producció acabarà necessitant les quatre.

Traçar sol no és suficient.

Avaluar sol no és suficient.

Optimitzar sense proves és només endevinar.

I parlar de ROI sense telemetria normalment és teatre.

L’angle d’interoperabilitat és especialment intel·ligent

Una de les decisions més encertades de l’anunci és que Foundry no fa veure que tots els agents es construiran en un sol framework.

L’article original parla explícitament d’estendre el tracing i les avaluacions a través de:

LangChain
LangGraph
OpenAI SDK
Microsoft Agent Framework
frameworks personalitzats via OpenTelemetry

Això és important.

Perquè el lock-in de plataforma és una de les maneres més ràpides de fer que una història d’operacions que en teoria era útil acabi sent menys atractiva.

Si els equips poden conservar les seves opcions de framework i, alhora, obtenir telemetria i superfícies d’avaluació de nivell producció, la fricció baixa molt.

L’avaluació amb rúbriques pot acabar important més del que la gent espera

La part d’avaluació amb rúbriques també val la pena destacar-la.

Crec que aquesta és una de les incorporacions més pràctiques de tot el post.

Per què? Perquè el que és “bo” depèn del context.

L’article diu que l’avaluació amb rúbriques genera “criteris d’avaluació sensibles al context a partir del comportament previst del teu agent”. Aquesta és exactament la direcció que necessiten aquests sistemes.

La puntuació de qualitat genèrica és útil.

Però al final els equips necessiten puntuar els agents segons els seus propis estàndards:

to
finalització de tasques
adhesió a polítiques
expectatives de latència
límits de cost
regles de negoci específiques del domini

Aquí és on l’avaluació comença a ser operativament significativa en lloc de només acadèmicament interessant.

El ROI és la part més incòmoda, i per això importa

També penso que la part de ROI de l’anunci és important precisament perquè és incòmoda.

L’article fa la pregunta directament:

“aquest agent val el que costa?”

Aquesta pregunta s’esquiva molt en les converses d’IA.

Però és la pregunta correcta.

Si la plataforma realment pot connectar cost, finalització de tasques, temps estalviat i traces de producció en un sol lloc, això dona a l’enginyeria i al lideratge un llenguatge compartit molt millor.

I sincerament, aquest llenguatge compartit és molt necessari.

La meva opinió

Aquest és un dels millors anuncis a nivell de plataforma del lot perquè se centra a operar agents, no només a construir-los.

I aquí és on de debò comença la part difícil.

Les plataformes d’IA més fortes dels pròxims anys no seran només les que tinguin accés a més models o més demos. Seran les que ajudin els equips a traçar el comportament, avaluar resultats, optimitzar amb seguretat i justificar el cost amb proves.

Aquesta història de Foundry intenta avançar exactament en aquesta direcció.

Per això val la pena prendre-la seriosament.

Publicació original: Build 2026: From observability to ROI for AI agents on any framework