Evaluations | The .NET Blog

As evals do model router são o passo que equipes demais pulam

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

Este artigo foi traduzido automaticamente. Para a versão original, clique aqui.

O roteamento automático de modelos parece ótimo até você perceber que ainda precisa provar que ele é a escolha certa para a sua workload.

É por isso que o novo model router evaluation repo é útil.

Ele oferece às equipes uma forma mais concreta de responder às perguntas que realmente importam:

o routing preserva a qualidade?
ele melhora o custo?
o que ele faz com a latência?
o que muda se eu restringir o subconjunto de modelos?

O artigo de origem faz as perguntas certas

Uma coisa que eu gosto muito no post original é que ele não trata o model router como algo obviamente bom.

Em vez disso, ele faz as perguntas desconfortáveis, mas corretas:

“Nos meus prompts, o modelo selecionado automaticamente pelo model router iguala ou supera o single model que eu escolheria de outra forma?”
“Estou realmente economizando dinheiro de ponta a ponta, ou só estou deslocando o gasto de um lugar para outro?”

Essa é exatamente a atitude certa.

Porque o routing automático é atraente, mas ainda é uma decisão de sistema. E decisões de sistema devem ser medidas, não admiradas.

Por que este repo é mais importante do que parece à primeira vista

Em um nível, isso é apenas um repositório de avaliação.

Em outro nível, é um sinal de maturidade.

Ele diz: se você quiser adotar routing automático, aqui está uma forma mais disciplinada de testar:

qualidade
custo
latência
trade-offs de subconjunto
comportamento de distribuição de modelos

Isso é muito melhor do que tratar o routing como uma caixa-preta com boa marca.

Minha opinião

Este é um bom exemplo do tipo de tooling que as plataformas de IA precisam mais: não mais mágica, mas mais formas de validar a mágica antes de confiar nela.

É assim que as equipes evitam construir confiança cara sobre suposições não testadas.

Artigo original: How to run evals for the model router

A parte difícil do desenvolvimento de IA já não é o acesso. É operar bem o modelo certo

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

Este artigo foi traduzido automaticamente. Para a versão original, clique aqui.

Já passamos da fase em que simplesmente ter acesso a um modelo poderoso era suficiente.

É exatamente isso que este novo guia da Foundry para gerenciar modelos, custo e qualidade acerta.

O verdadeiro desafio agora é operacional:

escolher o modelo certo para cada workload
validá-lo com seus próprios dados
gerenciar latência e gasto
governar upgrades e risco de regressão

É nisso que equipes sérias precisam ficar boas.

O artigo original define bem o problema

Uma frase da publicação original captura muito bem essa mudança:

“A parte mais difícil de construir sistemas de IA hoje já não é ter acesso a um modelo capaz. É saber como escolher, validar, otimizar e operar o modelo certo ao longo de todo o ciclo de vida de uma aplicação real.”

Esse é exatamente o diagnóstico certo.

Muitas equipes ainda acham que a seleção do modelo é a decisão principal.

Não é.

Operar o modelo é o problema maior:

qual workload recebe qual modelo?
como a qualidade é verificada?
que forma de custo é aceitável?
o que acontece quando surge um modelo novo ou um antigo começa a derivar?
como testar uma mudança sem quebrar workflows reais?

Esse é o trabalho de engenharia de verdade agora.

Por que esta peça da Foundry é útil

Gosto deste artigo porque ele fala sobre sistemas de IA do jeito que engenheiros de plataforma experientes realmente precisam pensar neles.

Não como “escolha o modelo mais inteligente e siga em frente”.

Mas como sistemas que vivem sob trade-offs:

capacidade
latência
custo
segurança
governança
pressão por upgrades

Isso é muito mais útil do que otimismo guiado por benchmarks.

A mudança mais importante é pensar primeiro nos critérios

A publicação original recomenda definir critérios de sucesso antes de abrir o catálogo de modelos.

Acho que esse é um dos hábitos mais importantes que as equipes podem adotar.

Se você abre o catálogo primeiro, você se ancora na reputação.

Se você define os critérios primeiro, você se ancora na realidade do workload.

Esse é um processo mais saudável.

Porque o modelo que vence um benchmark não é automaticamente o que vence em:

seus prompts
seu orçamento de latência
seus guardrails de custo
seus requisitos de governança

Essa distinção é onde começa a engenharia de IA madura.

A história multi-modelo está se tornando uma vantagem real

Outra coisa que eu gosto é o framing explicitamente agnóstico em relação ao modelo.

O artigo apresenta a Foundry não como um destino de um único modelo, mas como uma superfície operacional sobre:

modelos Microsoft
modelos de parceiros
modelos open source
variantes pós-treinadas
estratégias de roteamento e otimização

Isso importa porque a flexibilidade de modelos já não é luxo. É parte do gerenciamento de risco.

Se a qualidade muda, os preços variam ou as quotas apertam, as equipes precisam de opções.

Controle de custos não é um tema secundário

O artigo também acerta ao tratar custo como uma questão de arquitetura.

Isso não é um problema de “otimizamos depois”.

Se você envia cada tarefa por padrão para o modelo mais pesado, isso pode funcionar muito bem em uma demo e desabar sob a economia de produção.

Por isso acho que as seções sobre:

routing
batching
caching
provisioned throughput
gestão de quotas

são mais importantes do que muita gente imagina.

As equipes que tratam disciplina de custo como parte do design do sistema vão envelhecer muito melhor do que as que a tratam como limpeza posterior.

Minha opinião

Esta é uma peça útil da Foundry porque fala sobre sistemas de IA como engenheiros experientes realmente precisam operá-los.

Não como demos. Não como protótipos de uma única vez. E não como turismo de rankings.

Mas como sistemas operacionais para workloads, restrições, trade-offs e mudança constante.

Precisamos continuar elevando essa conversa para esse nível.

E se você está construindo sistemas de IA em produção, essa é exatamente a mentalidade que quero que as equipes internalizem cedo.

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

A história de observabilidade até ROI da Foundry é exatamente o que plataformas de agentes sérias precisam

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

Este artigo foi traduzido automaticamente. Para a versão original, clique aqui.

Se os agentes de IA vão viver em produção, a observabilidade não pode parar em logs e traces.

É por isso que a nova história da Foundry de observabilidade até ROI parece importante.

A mensagem real não é “adicionamos mais dashboards”.

A mensagem real é que plataformas de agentes sérias precisam de um ciclo operacional contínuo:

trace o que aconteceu
avalie se foi bom
otimize o que precisa de trabalho
conecte o resultado ao valor de negócio

Isso é muito mais forte do que o discurso vago habitual de plataforma.

A frase-chave do artigo original diz tudo

O post original começa com uma linha à qual eu acho que toda equipe que constrói agentes deveria prestar atenção:

“Lançar um agente de IA é a parte fácil. Mantê-lo preciso, seguro e responsável em produção é onde as equipes travam.”

Isso é exatamente verdade.

Já passamos da fase em que a pergunta principal era: “consigo fazer um agente fazer algo legal?”

A pergunta mais difícil e mais valiosa é:

consigo operar a coisa depois que ela começa a interagir com usuários reais, ferramentas reais e custos reais?

É para esse lado que a Foundry está tentando empurrar a conversa.

Por que isso importa mais do que outra demo de agente

Muitos anúncios de agentes de IA ainda focam em criação: construa o agente, conecte as ferramentas, roteie as tarefas, publique a interface.

Tudo isso está certo.

Mas as questões operacionais são o ponto em que a maioria dos sistemas sérios se torna sustentável ou vira experimento caro:

o que o agente realmente está fazendo em produção?
ele fez a coisa certa?
ele piora com o tempo?
ele é caro demais para o valor que cria?
quais mudanças de configuração realmente melhoraram a qualidade?

É por isso que acho o anúncio da Foundry mais importante do que um resumo típico de recursos. Ele tenta definir um ciclo de Agent DevOps, não apenas uma história de criação de agentes.

O ciclo em quatro partes é o produto real aqui

O artigo organiza basicamente a plataforma em quatro capacidades:

Trace
Evaluate
Monitor
Optimize

Essa é a forma certa.

Eu até diria que qualquer plataforma que queira ser levada a sério para workloads de agentes em produção acabará precisando das quatro.

Tracing sozinho não basta.

Avaliação sozinha não basta.

Otimização sem evidência é só chute.

E falar de ROI sem telemetry geralmente é teatro.

O ângulo de interoperabilidade é especialmente inteligente

Uma das decisões mais fortes do anúncio é que a Foundry não finge que todos os agentes serão construídos em um único framework.

O post original fala explicitamente de tracing e evals que se estendem por:

LangChain
LangGraph
OpenAI SDK
Microsoft Agent Framework
frameworks personalizados via OpenTelemetry

Isso é importante.

Porque lock-in de plataforma é uma das formas mais rápidas de tornar menos atraente uma história de operações que originalmente era útil.

Se os times podem manter suas escolhas de framework e ainda assim obter telemetry e superfícies de avaliação em nível de produção, a fricção cai bastante.

A avaliação por rubricas pode acabar importando mais do que as pessoas esperam

A parte de rubric evaluation também merece destaque.

Acho que essa é uma das adições mais práticas de todo o post.

Por quê? Porque o que é “bom” depende do contexto.

O artigo diz que rubric evaluation gera “critérios de avaliação sensíveis ao contexto a partir do comportamento pretendido do seu agente”. É exatamente essa a direção de que esses sistemas precisam.

A pontuação genérica de qualidade é útil.

Mas, no fim, os times precisam avaliar agentes pelos seus próprios padrões:

tom
conclusão de tarefas
aderência a políticas
expectativas de latência
limites de custo
regras de negócio específicas do domínio

É aí que a avaliação começa a ser operacionalmente significativa, em vez de apenas academicamente interessante.

ROI é a parte mais desconfortável, e por isso importa

Também acho que a parte de ROI do anúncio é importante justamente porque é desconfortável.

O post faz a pergunta diretamente:

“esse agente vale o que custa?”

Essa pergunta é muito evitada em conversas sobre IA.

Mas é a pergunta certa.

Se a plataforma realmente consegue conectar custo, conclusão de tarefas, tempo economizado e traces de produção em um único lugar, isso dá à engenharia e à liderança uma linguagem compartilhada muito melhor.

E, sinceramente, essa linguagem compartilhada faz muita falta.

Minha opinião

Este é um dos melhores anúncios no nível de plataforma deste lote porque foca em operar agentes, não apenas em construí-los.

E é aí que o trabalho difícil realmente começa.

As plataformas de IA mais fortes dos próximos anos não serão apenas as que tiverem acesso a mais modelos ou mais demos. Serão as que ajudarem os times a traçar comportamento, avaliar resultados, otimizar com segurança e justificar custo com evidência.

Essa história da Foundry está tentando ir exatamente nessa direção.

Por isso vale a pena levá-la a sério.

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