Evaluations | The .NET Blog

Model router-evals zijn de stap die te veel teams overslaan

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

Dit artikel is automatisch vertaald. Voor de originele versie, klik hier.

Automatische modelrouting klinkt geweldig totdat je je realiseert dat je nog steeds moet bewijzen dat het de juiste keuze is voor je workload.

Daarom is de nieuwe model router evaluation repo nuttig.

Het geeft teams een concretere manier om de vragen te beantwoorden die er echt toe doen:

behoudt routing de kwaliteit?
verbetert het de kosten?
wat doet het met de latentie?
wat verandert er als ik de modelsubset beperk?

Het bronartikel stelt de juiste vragen

Een ding dat ik erg goed vind aan het originele bericht, is dat het de model router niet behandelt als vanzelfsprekend goed.

In plaats daarvan stelt het de ongemakkelijke maar juiste vragen:

“Op mijn prompts, evenaart of overtreft het door de model router automatisch gekozen model het enkele model dat ik anders zou kiezen?”
“Bespaar ik daadwerkelijk end to end geld, of schuif ik alleen uitgaven van de ene plek naar de andere?”

Dat is precies de juiste houding.

Want automatische routing is aantrekkelijk, maar het blijft een systeembeslissing. En systeembeslissingen moeten worden gemeten, niet bewonderd.

Waarom deze repo meer betekent dan het op het eerste gezicht lijkt

Op één niveau is dit gewoon een evaluatierepo.

Op een ander niveau is het een teken van volwassenheid.

Het zegt: als je automatische routing wilt adopteren, dan is hier een meer gedisciplineerde manier om te testen:

kwaliteit
kosten
latentie
subset trade-offs
gedrag van modeldistributie

Dat is veel beter dan routing behandelen als een black box met een goede branding.

Mijn mening

Dit is een goed voorbeeld van het soort tooling dat AI-platforms meer nodig hebben: niet meer magie, maar meer manieren om de magie te valideren voordat je erop vertrouwt.

Zo voorkomen teams dat ze dure zekerheid bouwen op onbewezen aannames.

Origineel artikel: How to run evals for the model router

Het moeilijke aan AI-ontwikkeling is niet langer toegang. Het is het juiste model goed draaien

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

Dit artikel is automatisch vertaald. Voor de originele versie, klik hier.

We zijn allang voorbij het punt waarop alleen toegang tot een krachtig model genoeg was.

Dat is precies wat deze nieuwe Foundry-gids voor model-, kosten- en kwaliteitsbeheer goed begrijpt.

De echte uitdaging is nu operationeel:

het juiste model per workload kiezen
het valideren tegen je eigen data
latency en uitgaven beheren
upgrades en regressierisico sturen

Daar moeten serieuze teams goed in worden.

Het bronartikel definieert het probleem goed

Eén zin uit het originele bericht vat deze verschuiving heel goed samen:

“Het moeilijkste deel van AI-systemen bouwen is vandaag niet langer toegang krijgen tot een capabel model. Het is weten hoe je het juiste model kiest, valideert, optimaliseert en opereert gedurende de volledige levenscyclus van een echte applicatie.”

Dat is precies de juiste diagnose.

Te veel teams denken nog steeds dat modelselectie de hoofdkeuze is.

Dat is het niet.

Modeloperatie is het grotere probleem:

welke workload krijgt welk model?
hoe wordt kwaliteit geverifieerd?
welke kostenstructuur is acceptabel?
wat gebeurt er als een nieuw model verschijnt of een oud model afdrijft?
hoe test je een verandering zonder echte workflows te breken?

Dat is nu het echte engineeringwerk.

Waarom dit Foundry-stuk nuttig is

Ik vind dit artikel prettig omdat het over AI-systemen spreekt zoals ervaren platformengineers er echt over moeten nadenken.

Niet als “kies het slimste model en ga verder”.

Maar als systemen die leven onder trade-offs:

capability
latency
cost
safety
governance
upgrade pressure

Dat is veel nuttiger dan benchmarkgedreven optimisme.

De belangrijkste verschuiving is criteria-first denken

Het originele artikel raadt aan om succescriteria te definiëren voordat je de modelcatalogus opent.

Ik denk dat dit een van de belangrijkste gewoonten is die teams kunnen aannemen.

Als je eerst de catalogus opent, anker je op reputatie.

Als je eerst criteria definieert, anker je op de werkelijkheid van de workload.

Dat is een gezonder proces.

Want het model dat een benchmark wint, is niet automatisch het model dat wint op:

je prompts
je latencybudget
je kostenrails
je governancevereisten

Dat onderscheid is waar volwassen AI-engineering begint.

Het multi-modelverhaal wordt een echt voordeel

Nog iets dat ik goed vind, is de expliciet model-agnostische framing.

Het artikel presenteert Foundry niet als een bestemming voor één model, maar als een operationele surface over:

Microsoft-modellen
partner-modellen
open-source modellen
post-getrainde varianten
routing- en optimalisatiestrategieën

Dat is belangrijk, omdat modelflexibiliteit geen luxe meer is. Het is onderdeel van risicobeheer.

Als kwaliteit verschuift, prijzen bewegen of quota krapper worden, hebben teams opties nodig.

Kostencontrole is geen bijzaak

Het artikel heeft ook gelijk als het kosten als een architectuurkwestie beschouwt.

Dit is geen “we optimaliseren het later”-probleem.

Als je standaard elke taak naar het zwaarste model stuurt, werkt dat misschien geweldig in een demo en stort het in onder de economie van productie.

Daarom denk ik dat de stukken over:

routing
batching
caching
provisioned throughput
quotabeheer

belangrijker zijn dan veel mensen zouden denken.

Teams die kostendiscipline behandelen als onderdeel van het systeemontwerp, zullen veel beter standhouden dan teams die het als latere opschoning zien.

Mijn mening

Dit is een nuttig Foundry-stuk omdat het over AI-systemen spreekt zoals ervaren engineers ze echt moeten draaien.

Niet als demo’s. Niet als eenmalige prototypes. En niet als leaderboard-toerisme.

Maar als operating systems voor workloads, constraints, trade-offs en voortdurende verandering.

We moeten dat gesprek blijven optrekken.

En als je production AI-systemen bouwt, is dit precies de mindset die teams vroeg zouden moeten internaliseren.

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

Het observability-to-ROI-verhaal van Foundry is precies wat serieuze agentplatforms nodig hebben

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

Deze publicatie is automatisch vertaald. Voor de originele versie, klik hier.

Als AI-agents in productie gaan leven, mag observability niet stoppen bij logs en traces.

Daarom voelt het nieuwe observability-to-ROI-verhaal van Foundry belangrijk aan.

De echte boodschap is niet “we hebben meer dashboards toegevoegd”.

De echte boodschap is dat serieuze agentplatforms een continue operationele lus nodig hebben:

trace wat er is gebeurd
evalueer of het goed was
optimaliseer wat werk nodig heeft
koppel het resultaat aan business value

Dat is een veel sterker verhaal dan het gebruikelijke platformgepraat.

De kernzin in het bronartikel zegt alles

Het oorspronkelijke bericht begint met een zin waar elk team dat agents bouwt volgens mij aandacht aan zou moeten besteden:

“Een AI-agent uitrollen is het makkelijke deel. Hem nauwkeurig, veilig en verantwoordelijk houden in productie is waar teams vastlopen.”

Dat klopt precies.

We zijn al voorbij het stadium waarin de belangrijkste vraag was: “kan ik een agent iets tofs laten doen?”

De moeilijkere en waardevollere vraag is:

kan ik het ding beheren zodra het begint te communiceren met echte gebruikers, echte tools en echte kosten?

Dat is waar Foundry het gesprek naartoe probeert te duwen.

Waarom dit belangrijker is dan nog een agentdemo

Veel AI-agentaankondigingen richten zich nog steeds op creation: bouw de agent, koppel de tools, routeer de taken, publiceer de interface.

Dat is allemaal prima.

Maar de operationele vragen zijn het punt waarop de meeste serieuze systemen óf duurzaam worden óf dure experimenten:

wat doet de agent eigenlijk in productie?
deed hij het juiste?
wordt hij slechter naarmate de tijd verstrijkt?
is hij te duur voor de waarde die hij creëert?
welke configuratiewijzigingen hebben de kwaliteit echt verbeterd?

Daarom denk ik dat de Foundry-aankondiging belangrijker is dan een typische feature roundup. Ze probeert een Agent DevOps-lus te definiëren, niet alleen een agentcreatieverhaal.

De lus in vier delen is hier het echte product

Het artikel structureert het platform in feite rond vier mogelijkheden:

Trace
Evaluate
Monitor
Optimize

Dat is de juiste vorm.

Ik zou zelfs zeggen dat elk platform dat serieus genomen wil worden voor agent production workloads uiteindelijk alle vier nodig heeft.

Tracing alleen is niet genoeg.

Evaluatie alleen is niet genoeg.

Optimalisatie zonder bewijs is gewoon gokken.

En over ROI praten zonder telemetry is meestal theater.

De interoperabiliteitskant is bijzonder slim

Een van de sterkste keuzes in de aankondiging is dat Foundry niet doet alsof elke agent in één framework gebouwd zal worden.

Het bronbericht spreekt expliciet over tracing en evals die zich uitstrekken over:

LangChain
LangGraph
OpenAI SDK
Microsoft Agent Framework
custom frameworks via OpenTelemetry

Dat is belangrijk.

Want platform lock-in is een van de snelste manieren om een operationeel verhaal dat eerst nuttig was minder aantrekkelijk te maken.

Als teams hun frameworkkeuzes kunnen behouden en toch production-grade telemetry en evaluatie-oppervlakken krijgen, daalt de frictie aanzienlijk.

Rubric evaluation kan uiteindelijk belangrijker worden dan mensen verwachten

Het deel over rubric evaluation verdient ook aandacht.

Ik denk dat dit een van de meest praktische toevoegingen in de hele post is.

Waarom? Omdat “goed” contextafhankelijk is.

Het artikel zegt dat rubric evaluation “context-aware evaluatiecriteria uit het bedoelde gedrag van je agent” genereert. Dat is precies de richting die deze systemen nodig hebben.

Generieke kwaliteitsbeoordeling is nuttig.

Maar uiteindelijk moeten teams agents beoordelen op hun eigen standaarden:

toon
taakafronding
beleidsgedrag
latentieverwachtingen
kostenlimieten
domeinspecifieke bedrijfsregels

Daar wordt evaluatie operationeel betekenisvol in plaats van alleen academisch interessant.

ROI is het ongemakkelijkste deel, en juist daarom belangrijk

Ik vind ook dat het ROI-deel van de aankondiging belangrijk is, juist omdat het ongemakkelijk is.

Het bronbericht stelt de vraag direct:

“is deze agent de kosten waard?”

Die vraag wordt in AI-gesprekken vaak omzeild.

Maar het is de juiste vraag.

Als het platform kosten, taakafronding, bespaarde tijd en productie-traces echt op één plek kan verbinden, geeft dat engineering en leiderschap een veel betere gedeelde taal.

En eerlijk gezegd is die gedeelde taal hard nodig.

Mijn conclusie

Dit is een van de betere platformaankondigingen in deze batch, omdat ze zich richt op het beheren van agents, niet alleen op het bouwen ervan.

En daar begint het zware werk pas echt.

De sterkste AI-platforms van de komende jaren zijn niet alleen de platforms met toegang tot meer modellen of meer demo’s. Het zijn de platforms die teams helpen gedrag te traceren, uitkomsten te evalueren, veilig te optimaliseren en kosten met bewijs te rechtvaardigen.

Dit Foundry-verhaal probeert precies die kant op te bewegen.

Daarom is het de moeite waard om het serieus te nemen.

Origineel bericht: Build 2026: From observability to ROI for AI agents on any framework