Evaluations | The .NET Blog

Model Router Evals sind der Schritt, den zu viele Teams überspringen

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

Dieser Beitrag wurde automatisch übersetzt. Für die Originalversion klicke hier.

Automatisches Model-Routing klingt großartig, bis man merkt, dass man immer noch beweisen muss, dass es die richtige Wahl für die eigene Workload ist.

Genau deshalb ist das neue Model-Router-Evaluierungs-Repository nützlich.

Es gibt Teams eine konkretere Möglichkeit, die Fragen zu beantworten, auf die es wirklich ankommt:

behält das Routing die Qualität bei?
verbessert es die Kosten?
was macht es mit der Latenz?
was ändert sich, wenn ich die Modellauswahl einschränke?

Der Ausgangsartikel stellt die richtigen Fragen

Eine Sache, die mir am Originalbeitrag besonders gefällt, ist, dass der Model Router nicht als selbstverständlich gut behandelt wird.

Stattdessen werden die unbequemen, aber richtigen Fragen gestellt:

“Stimmt auf meinen Prompts das automatisch ausgewählte Modell des Model Routers mit dem Einzelmodell überein, das ich sonst wählen würde, oder ist es besser?”
“Spare ich tatsächlich Ende zu Ende Geld, oder verschiebe ich nur Ausgaben von einem Ort an einen anderen?”

Das ist genau die richtige Haltung.

Denn automatisches Routing ist attraktiv, aber es bleibt eine Systementscheidung. Und Systementscheidungen sollten gemessen, nicht bewundert werden.

Warum dieses Repository mehr bedeutet, als es zunächst klingt

Auf einer Ebene ist das einfach ein Evaluierungs-Repository.

Auf einer anderen Ebene ist es ein Zeichen von Reife.

Es sagt: Wenn du automatisches Routing einführen willst, findest du hier eine diszipliniertere Art zu testen:

Qualität
Kosten
Latenz
Trade-offs bei Subsets
Verhalten der Modellverteilung

Das ist viel besser, als Routing als Black Box mit gutem Branding zu behandeln.

Meine Einschätzung

Das ist ein gutes Beispiel für die Art von Tools, die KI-Plattformen mehr brauchen: nicht mehr Magie, sondern mehr Möglichkeiten, die Magie zu validieren, bevor man ihr vertraut.

So vermeiden Teams, teures Vertrauen auf ungeprüfte Annahmen zu bauen.

Originalbeitrag: How to run evals for the model router

Die schwierige Seite der KI-Entwicklung ist nicht mehr der Zugriff. Es ist, das richtige Modell gut zu betreiben

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

Dieser Beitrag wurde automatisch übersetzt. Für die Originalversion klicke hier.

Wir sind längst über die Phase hinaus, in der allein der Zugang zu einem leistungsfähigen Modell ausreichte.

Das ist genau der Punkt, den dieser neue Foundry-Leitfaden für Modell-, Kosten- und Qualitätsmanagement richtig trifft.

Die eigentliche Herausforderung ist jetzt operativ:

das richtige Modell pro Workload auswählen
es gegen deine eigenen Daten validieren
Latenz und Ausgaben verwalten
Upgrades und Regression-Risiken steuern

Das ist das, worin ernsthafte Teams gut werden müssen.

Der Ausgangsartikel formuliert das Problem richtig

Ein Satz aus dem Originalpost bringt diesen Wandel sehr gut auf den Punkt:

“Der schwierigste Teil beim Bau von KI-Systemen heute ist nicht mehr, Zugriff auf ein leistungsfähiges Modell zu bekommen. Es geht darum, zu wissen, wie man das richtige Modell über den gesamten Lebenszyklus einer realen Anwendung auswählt, validiert, optimiert und betreibt.”

Das ist genau die richtige Diagnose.

Zu viele Teams denken immer noch, die Modellauswahl sei die Hauptentscheidung.

Ist sie nicht.

Die Modellbetriebsführung ist das größere Problem:

Welche Workload bekommt welches Modell?
Wie wird Qualität überprüft?
Welche Kostenstruktur ist akzeptabel?
Was passiert, wenn ein neues Modell auftaucht oder ein altes abdriftet?
Wie testet man eine Änderung, ohne reale Workflows zu brechen?

Das ist jetzt die eigentliche Ingenieursarbeit.

Warum dieser Foundry-Beitrag nützlich ist

Ich mag diesen Artikel, weil er über KI-Systeme so spricht, wie erfahrene Plattformingenieure tatsächlich darüber nachdenken müssen.

Nicht als “nimm das klügste Modell und mach weiter”.

Sondern als Systeme, die unter Zielkonflikten leben:

Fähigkeit
Latenz
Kosten
Sicherheit
Governance
Upgrade-Druck

Das ist viel hilfreicher als benchmarkgetriebener Optimismus.

Der wichtigste Wandel ist, zuerst auf Kriterien zu schauen

Der Ausgangsartikel empfiehlt, Erfolgskriterien zu definieren, bevor man den Modellschrank öffnet.

Ich finde, das ist eine der wichtigsten Gewohnheiten, die Teams entwickeln können.

Wenn du zuerst den Katalog öffnest, orientierst du dich an Reputation.

Wenn du zuerst Kriterien definierst, orientierst du dich an der Realität der Workload.

Das ist ein gesünderer Prozess.

Denn das Modell, das einen Benchmark gewinnt, ist nicht automatisch das Modell, das gewinnt bei:

deinen Prompts
deinem Latenzbudget
deinen Kostenlimits
deinen Governance-Anforderungen

Dieser Unterschied ist der Punkt, an dem reife KI-Entwicklung beginnt.

Die Multi-Modell-Geschichte wird zu einem echten Vorteil

Ein weiterer Punkt, der mir gefällt, ist die explizit modellagnostische Ausrichtung.

Der Artikel präsentiert Foundry nicht als Ein-Modell-Ziel, sondern als operative Oberfläche über:

Microsoft-Modelle
Partner-Modelle
Open-Source-Modelle
posttrainierte Varianten
Routing- und Optimierungsstrategien

Das ist wichtig, weil Modellflexibilität kein Luxus mehr ist. Sie ist Teil des Risikomanagements.

Wenn sich Qualität verschiebt, Preise ändern oder Quoten knapp werden, brauchen Teams Optionen.

Kostenkontrolle ist kein Nebenthema

Der Artikel ist auch richtig, wenn er Kosten als architektonisches Thema rahmt.

Das ist kein “wir optimieren das später”-Problem.

Wenn du standardmäßig jede Aufgabe an das schwerste Modell sendest, kann das in einer Demo hervorragend funktionieren und unter Produktionsökonomie zusammenbrechen.

Deshalb halte ich die Abschnitte zu:

Routing
Batching
Caching
Provisioned Throughput
Quotenmanagement

für wichtiger, als viele vielleicht denken.

Teams, die Kostendisziplin als Teil des Systemdesigns behandeln, werden viel besser altern als Teams, die sie als nachträgliche Aufräumarbeit sehen.

Meine Einschätzung

Das ist ein nützlicher Foundry-Beitrag, weil er über KI-Systeme so spricht, wie erfahrene Ingenieure sie tatsächlich betreiben müssen.

Nicht als Demos. Nicht als einmalige Prototypen. Und nicht als Benchmark-Tourismus.

Sondern als Betriebssysteme für Workloads, Einschränkungen, Zielkonflikte und ständige Veränderung.

Auf dieses Gesprächsniveau sollte sich die Branche weiter zubewegen.

Und wenn du produktive KI-Systeme baust, dann ist genau das die Denkweise, die Teams früh verinnerlichen sollten.

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

Foundrys Observability-to-ROI-Geschichte ist genau das, was ernsthafte Agentenplattformen brauchen

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

Dieser Beitrag wurde automatisch übersetzt. Für die Originalversion klicke hier.

Wenn KI-Agenten in der Produktion leben sollen, darf Observability nicht bei Logs und Traces enden.

Deshalb fühlt sich die neue Foundry-Story von Observability zu ROI wichtig an.

Die eigentliche Botschaft ist nicht “wir haben mehr Dashboards hinzugefügt”.

Die eigentliche Botschaft ist, dass ernsthafte Agentenplattformen einen kontinuierlichen Betriebskreislauf brauchen:

nachverfolgen, was passiert ist
bewerten, ob es gut war
das verbessern, was Arbeit braucht
das Ergebnis mit Geschäftswert verbinden

Das ist eine viel stärkere Geschichte als das übliche Plattform-Geschwurbel.

Der Schlüsselsatz im Ausgangsartikel sagt alles

Der Originalbeitrag beginnt mit einer Zeile, auf die meiner Meinung nach jedes Team, das Agenten baut, achten sollte:

“Einen KI-Agenten bereitzustellen ist der leichte Teil. Ihn in der Produktion genau, sicher und verantwortbar zu halten, ist der Punkt, an dem Teams stecken bleiben.”

Genau so ist es.

Wir sind längst über die Phase hinaus, in der die Hauptfrage lautete: “Kann ich einen Agenten dazu bringen, irgendetwas Cooles zu tun?”

Die schwierigere und wertvollere Frage ist:

Kann ich das Ding betreiben, sobald es mit echten Nutzern, echten Tools und echten Kosten interagiert?

Genau dorthin versucht Foundry die Unterhaltung zu verschieben.

Warum das wichtiger ist als noch eine Agenten-Demo

Viele KI-Agenten-Ankündigungen konzentrieren sich immer noch auf die Erstellung: Agent bauen, Tools verdrahten, Aufgaben routen, Oberfläche veröffentlichen.

Das ist alles in Ordnung.

Aber die operativen Fragen entscheiden darüber, ob die meisten ernsthaften Systeme nachhaltig werden oder zu teuren Experimenten:

Was macht der Agent in der Produktion eigentlich?
Hat er das Richtige getan?
Wird er mit der Zeit schlechter?
Ist er zu teuer für den Wert, den er schafft?
Welche Konfigurationsänderungen haben die Qualität wirklich verbessert?

Deshalb denke ich, dass die Foundry-Ankündigung wichtiger ist als eine typische Feature-Zusammenfassung. Sie versucht, einen Agent DevOps-Kreislauf zu definieren, nicht nur eine Agenten-Erzählung.

Der Vier-Teil-Kreislauf ist hier das eigentliche Produkt

Der Artikel ordnet die Plattform im Grunde um vier Fähigkeiten:

Trace
Evaluate
Monitor
Optimize

Das ist die richtige Form.

Ich würde sogar sagen, dass jede Plattform, die bei Agenten-Produktionslasten ernst genommen werden will, am Ende alle vier braucht.

Tracing allein reicht nicht.

Evaluation allein reicht nicht.

Optimierung ohne Belege ist bloß Raten.

Und ROI-Rhetorik ohne Telemetrie ist meist Theater.

Der Interoperabilitätsaspekt ist besonders klug

Eine der stärksten Entscheidungen der Ankündigung ist, dass Foundry nicht so tut, als würden alle Agenten in einem einzigen Framework gebaut.

Der Originalbeitrag spricht ausdrücklich darüber, dass Tracing und Evals sich über Folgendes erstrecken:

LangChain
LangGraph
OpenAI SDK
Microsoft Agent Framework
benutzerdefinierte Frameworks über OpenTelemetry

Das ist wichtig.

Denn Plattform-Lock-in ist einer der schnellsten Wege, um eine an sich nützliche Operations-Story weniger attraktiv zu machen.

Wenn Teams ihre Framework-Wahl behalten können und trotzdem Telemetrie- und Evaluationsoberflächen auf Produktionsniveau erhalten, sinkt die Reibung erheblich.

Rubrik-Evaluierung könnte am Ende wichtiger werden, als viele erwarten

Auch der Teil zur Rubrik-Evaluierung ist erwähnenswert.

Ich glaube, das ist eine der praktischsten Ergänzungen im gesamten Beitrag.

Warum? Weil “gut” vom Kontext abhängt.

Der Artikel sagt, dass die Rubrik-Evaluierung “kontextbezogene Bewertungskriterien aus dem beabsichtigten Verhalten Ihres Agenten” generiert. Genau in diese Richtung müssen sich diese Systeme entwickeln.

Generische Qualitätsbewertung ist nützlich.

Aber am Ende müssen Teams Agenten nach ihren eigenen Standards bewerten:

Tonfall
Aufgabenerledigung
Policy-Einhaltung
Latenzerwartungen
Kostenlimits
domänenspezifische Geschäftsregeln

Dort wird Evaluation operativ bedeutsam statt nur akademisch interessant.

ROI ist der unbequemste Teil, und genau deshalb ist er wichtig

Ich finde auch den ROI-Teil der Ankündigung wichtig, gerade weil er unbequem ist.

Der Beitrag stellt die Frage direkt:

“Ist dieser Agent das wert, was er kostet?”

Diese Frage wird in KI-Gesprächen oft umschifft.

Aber sie ist die richtige Frage.

Wenn die Plattform Kosten, Aufgabenerledigung, eingesparte Zeit und Produktionstraces wirklich an einem Ort verbinden kann, gibt das Engineering und Führung eine viel bessere gemeinsame Sprache.

Und ehrlich gesagt wird diese gemeinsame Sprache dringend gebraucht.

Mein Fazit

Das ist eine der besseren Plattform-Ankündigungen in dieser Runde, weil sie sich auf das Betreiben von Agenten konzentriert und nicht nur auf deren Bau.

Und dort beginnt die eigentliche harte Arbeit.

Die stärksten KI-Plattformen der nächsten Jahre werden nicht einfach die sein, die mehr Modelle oder mehr Demos bieten. Es werden die sein, die Teams helfen, Verhalten zu verfolgen, Ergebnisse zu bewerten, sicher zu optimieren und Kosten mit Belegen zu rechtfertigen.

Diese Foundry-Story versucht genau in diese Richtung zu gehen.

Deshalb ist sie es wert, ernst genommen zu werden.

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