Evaluations | The .NET Blog

Las evaluaciones del model router son el paso que demasiados equipos se saltan

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

Este artículo fue traducido automáticamente. Para la versión original, haz clic aquí.

El enrutamiento automático de modelos suena genial hasta que te das cuenta de que todavía tienes que demostrar que es la opción correcta para tu carga de trabajo.

Por eso es útil el nuevo repositorio de evaluación del model router.

Ofrece a los equipos una forma más concreta de responder a las preguntas que realmente importan:

el enrutamiento preserva la calidad?
mejora el coste?
qué hace con la latencia?
qué cambia si restrinjo el subconjunto de modelos?

El artículo original hace las preguntas correctas

Una cosa que me gusta mucho del artículo original es que no trata al model router como algo bueno por defecto.

En su lugar, hace las preguntas incómodas pero correctas:

“En mis prompts, el modelo seleccionado automáticamente por el model router iguala o supera al modelo único que yo elegiría?”
“Estoy realmente ahorrando dinero de extremo a extremo, o solo estoy moviendo el gasto de un sitio a otro?”

Esa es exactamente la actitud correcta.

Porque el enrutamiento automático es atractivo, pero sigue siendo una decisión de sistema. Y las decisiones de sistema deben medirse, no admirarse.

Por qué este repositorio importa más de lo que parece al principio

A un nivel, esto es solo un repositorio de evaluación.

A otro nivel, es una señal de madurez.

Dice: si quieres adoptar el enrutamiento automático, aquí tienes una forma más disciplinada de probar:

calidad
coste
latencia
compensaciones del subconjunto
comportamiento de distribución de modelos

Eso es mucho mejor que tratar el enrutamiento como una caja negra con buena marca.

Mi opinión

Este es un buen ejemplo del tipo de herramientas que las plataformas de IA necesitan más: no más magia, sino más formas de validar la magia antes de confiar en ella.

Así es como los equipos evitan construir una confianza cara sobre suposiciones no probadas.

Artículo original: How to run evals for the model router

La parte difícil del desarrollo de IA ya no es el acceso. Es operar bien el modelo correcto

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

Esta publicación se ha traducido automáticamente. Para la versión original, haz clic aquí.

Ya hemos pasado la fase en la que simplemente tener acceso a un modelo potente era suficiente.

Eso es exactamente lo que acierta esta nueva guía de Foundry para gestionar modelos, coste y calidad.

El verdadero reto ahora es operativo:

elegir el modelo adecuado para cada carga de trabajo
validarlo con tus propios datos
gestionar la latencia y el gasto
gobernar las actualizaciones y el riesgo de regresión

Eso es en lo que los equipos serios tienen que aprender a destacar.

El artículo original define bien el problema

Una frase de la publicación original captura muy bien este cambio:

“La parte más difícil de construir sistemas de IA hoy ya no es conseguir acceso a un modelo capaz. Es saber cómo elegir, validar, optimizar y operar el modelo correcto a lo largo de todo el ciclo de vida de una aplicación real.”

Ese es exactamente el diagnóstico correcto.

Demasiados equipos siguen pensando que la selección del modelo es la decisión principal.

No lo es.

La operación del modelo es el problema mayor:

¿qué carga de trabajo recibe qué modelo?
¿cómo se verifica la calidad?
¿qué forma de coste es aceptable?
¿qué pasa cuando aparece un modelo nuevo o uno viejo se degrada?
¿cómo pruebas un cambio sin romper flujos de trabajo reales?

Ese es el trabajo de ingeniería real ahora.

Por qué esta pieza de Foundry es útil

Me gusta este artículo porque habla de los sistemas de IA del modo en que los ingenieros de plataforma con experiencia realmente tienen que pensarlos.

No como “elige el modelo más inteligente y sigue adelante”.

Sino como sistemas que viven bajo compensaciones:

capacidad
latencia
coste
seguridad
gobernanza
presión de actualizaciones

Eso es mucho más útil que el optimismo basado en benchmarks.

El cambio más importante es pensar primero en los criterios

La publicación original recomienda definir criterios de éxito antes de abrir el catálogo de modelos.

Creo que es uno de los hábitos más importantes que los equipos pueden adoptar.

Si abres primero el catálogo, te anclas en la reputación.

Si defines primero los criterios, te anclas en la realidad de la carga de trabajo.

Ese es un proceso más sano.

Porque el modelo que gana un benchmark no es automáticamente el que gana en:

tus prompts
tu presupuesto de latencia
tus límites de coste
tus requisitos de gobernanza

Esa diferencia es donde comienza la ingeniería madura de IA.

La historia multmodelo se está convirtiendo en una ventaja real

Otra cosa que me gusta es el enfoque explícitamente agnóstico respecto al modelo.

El artículo presenta Foundry no como un destino de un solo modelo, sino como una superficie operativa sobre:

modelos de Microsoft
modelos de socios
modelos de código abierto
variantes postentrenadas
estrategias de enrutamiento y optimización

Eso importa porque la flexibilidad del modelo ya no es un lujo. Es parte de la gestión del riesgo.

Si la calidad cambia, los precios se mueven o la cuota se restringe, los equipos necesitan opciones.

El control de costes no es un tema secundario

El artículo también acierta al tratar el coste como una cuestión arquitectónica.

Esto no es un problema de “ya lo optimizaremos más tarde”.

Si envías cada tarea al modelo más pesado por defecto, eso puede funcionar de maravilla en una demo y colapsar bajo la economía de producción.

Por eso creo que las secciones sobre:

enrutamiento
batching
caching
provisioned throughput
gestión de cuotas

son más importantes de lo que mucha gente podría pensar.

Los equipos que tratan la disciplina del coste como parte del diseño del sistema envejecen mucho mejor que los que la tratan como trabajo de limpieza posterior.

Mi opinión

Esta es una pieza útil de Foundry porque habla de los sistemas de IA como realmente tienen que operarlos los ingenieros con experiencia.

No como demos. No como prototipos de una sola vez. Y no como turismo de rankings.

Sino como sistemas operativos para cargas de trabajo, restricciones, compensaciones y cambio constante.

Ese es el nivel de conversación hacia el que hay que seguir moviéndose.

Y si estás construyendo sistemas de IA en producción, esa es exactamente la mentalidad que quiero que los equipos adopten pronto.

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

La historia de observabilidad a ROI de Foundry es lo que necesitan las plataformas de agentes serias

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

Esta publicación se ha traducido automáticamente. Para la versión original, haz clic aquí.

Si los agentes de IA van a vivir en producción, la observabilidad no puede quedarse en logs y traces.

Por eso la nueva historia de Foundry de observabilidad a ROI se siente importante.

El mensaje real no es “hemos añadido más paneles”.

El mensaje real es que las plataformas de agentes serias necesitan un bucle operativo continuo:

trazar lo que pasó
evaluar si fue bueno
optimizar lo que necesita trabajo
conectar el resultado con el valor de negocio

Esa es una historia mucho más sólida que la típica palabrería de plataforma.

La frase clave del artículo original lo dice todo

La publicación original empieza con una línea a la que creo que todo equipo que construye agentes debería prestar atención:

“Lanzar un agente de IA es la parte fácil. Mantenerlo preciso, seguro y con responsabilidad en producción es donde los equipos se atascan.”

Eso es exactamente cierto.

Ya hemos pasado la fase en la que la pregunta principal era “¿puedo hacer que un agente haga algo interesante?”

La pregunta más difícil y más valiosa es:

¿puedo operar la cosa una vez que empieza a interactuar con usuarios reales, herramientas reales y costes reales?

Ahí es donde Foundry intenta empujar la conversación.

Por qué esto importa más que otra demo de agente

Muchos anuncios de agentes de IA siguen centrados en la creación: construye el agente, conecta las herramientas, enruta las tareas, publica la interfaz.

Todo eso está bien.

Pero las cuestiones operativas son el punto en el que la mayoría de los sistemas serios o bien se vuelven sostenibles o bien se convierten en experimentos caros:

¿qué está haciendo realmente el agente en producción?
¿hizo lo correcto?
¿empeora con el tiempo?
¿es demasiado caro para el valor que crea?
¿qué cambios de configuración mejoraron de verdad la calidad?

Por eso creo que el anuncio de Foundry es más importante que un resumen típico de características. Está intentando definir un bucle de Agent DevOps, no solo una historia de creación de agentes.

El bucle de cuatro partes es el producto real aquí

El artículo organiza básicamente la plataforma alrededor de cuatro capacidades:

Trace
Evaluate
Monitor
Optimize

Esa es la forma correcta.

De hecho, diría que cualquier plataforma que quiera ser tomada en serio para cargas de trabajo de agentes en producción terminará necesitando las cuatro.

Trace por sí solo no basta.

Evaluate por sí solo no basta.

Optimizar sin pruebas es simplemente adivinar.

Y hablar de ROI sin telemetría suele ser teatro.

El ángulo de interoperabilidad es especialmente inteligente

Una de las decisiones más acertadas del anuncio es que Foundry no finge que todos los agentes se construirán en un solo framework.

La publicación original habla explícitamente de extender tracing y evaluaciones a través de:

LangChain
LangGraph
OpenAI SDK
Microsoft Agent Framework
frameworks personalizados vía OpenTelemetry

Eso es importante.

Porque el lock-in de plataforma es una de las formas más rápidas de hacer que una historia de operaciones que en teoría era útil termine siendo menos atractiva.

Si los equipos pueden conservar sus opciones de framework y aun así obtener telemetría y superficies de evaluación de nivel producción, la fricción baja muchísimo.

La evaluación con rúbricas podría acabar importando más de lo que la gente espera

La parte de evaluación con rúbricas también merece destacarse.

Creo que esta es una de las incorporaciones más prácticas de todo el post.

¿Por qué? Porque lo que es “bueno” depende del contexto.

El artículo dice que la evaluación con rúbricas genera “criterios de evaluación sensibles al contexto a partir del comportamiento previsto de tu agente”. Esa es exactamente la dirección que necesitan estos sistemas.

La puntuación de calidad genérica es útil.

Pero al final los equipos necesitan puntuar a los agentes según sus propios estándares:

tono
finalización de tareas
adhesión a políticas
expectativas de latencia
límites de coste
reglas de negocio específicas del dominio

Ahí es donde la evaluación empieza a ser operativamente significativa en lugar de solo académicamente interesante.

El ROI es la parte más incómoda, y por eso importa

También pienso que la parte de ROI del anuncio es importante precisamente porque resulta incómoda.

La publicación hace la pregunta directamente:

“¿vale este agente lo que cuesta?”

Esa pregunta se esquiva mucho en las conversaciones sobre IA.

Pero es la pregunta correcta.

Si la plataforma puede conectar de verdad coste, finalización de tareas, tiempo ahorrado y traces de producción en un solo lugar, eso da a la ingeniería y al liderazgo un lenguaje compartido mucho mejor.

Y sinceramente, ese lenguaje compartido hace mucha falta.

Mi opinión

Este es uno de los mejores anuncios a nivel de plataforma de todo el lote porque se centra en operar agentes, no solo en construirlos.

Y ahí es donde de verdad empieza el trabajo duro.

Las plataformas de IA más fuertes de los próximos años no serán solo las que tengan acceso a más modelos o más demos. Serán las que ayuden a los equipos a trazar el comportamiento, evaluar resultados, optimizar con seguridad y justificar el coste con evidencia.

Esta historia de Foundry intenta avanzar exactamente en esa dirección.

Por eso merece tomarse en serio.

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