Evaluations | The .NET Blog

Ewaluacje model routera to krok, który zbyt wiele zespołów pomija

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

Ten artykuł został automatycznie przetłumaczony. Aby zobaczyć oryginał, kliknij tutaj.

Automatyczne routowanie modeli brzmi świetnie, dopóki nie uświadomisz sobie, że nadal musisz udowodnić, że to właściwy wybór dla twojego workloadu.

Właśnie dlatego nowe repozytorium ewaluacji model routera jest przydatne.

Daje zespołom bardziej konkretny sposób odpowiadania na pytania, które naprawdę mają znaczenie:

czy routing zachowuje jakość?
czy poprawia koszt?
co robi z opóźnieniem?
co się zmienia, jeśli ograniczę podzbiór modeli?

Artykuł źródłowy zadaje właściwe pytania

Jedna rzecz, która bardzo mi się podoba w oryginalnym wpisie, to to, że nie traktuje model routera jak czegoś oczywiście dobrego.

Zamiast tego zadaje niewygodne, ale poprawne pytania:

“Na moich promptach, czy model wybrany automatycznie przez model router dorównuje albo przewyższa pojedynczy model, który wybrałbym inaczej?”
“Czy naprawdę oszczędzam pieniądze end to end, czy tylko przenoszę wydatki z jednego miejsca do drugiego?”

To dokładnie właściwe podejście.

Bo automatyczny routing jest atrakcyjny, ale nadal jest decyzją systemową. A decyzje systemowe trzeba mierzyć, a nie podziwiać.

Dlaczego to repo ma większe znaczenie, niż się na pierwszy rzut oka wydaje

Na jednym poziomie to tylko repozytorium ewaluacyjne.

Na innym poziomie to oznaka dojrzałości.

Mówi ono: jeśli chcesz wdrożyć automatyczny routing, oto bardziej zdyscyplinowany sposób testowania:

jakość
koszt
opóźnienie
kompromisy podzbioru
zachowanie dystrybucji modeli

To dużo lepsze niż traktowanie routingu jak czarnej skrzynki z dobrą marką.

Moja opinia

To dobry przykład tego rodzaju narzędzi, których platformy AI potrzebują więcej: nie więcej magii, ale więcej sposobów, by tę magię zweryfikować, zanim zacznie się jej ufać.

W ten sposób zespoły unikają budowania drogiego zaufania na nieprzetestowanych założeniach.

Oryginalny artykuł: How to run evals for the model router

Trudna część tworzenia AI to już nie dostęp. To dobre operowanie właściwym modelem

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

Ten wpis został przetłumaczony automatycznie. Aby zobaczyć oryginał, kliknij tutaj.

Minęliśmy już etap, w którym sam dostęp do mocnego modelu wystarczał.

Właśnie to dobrze uchwycił ten nowy przewodnik Foundry po zarządzaniu modelami, kosztami i jakością.

Prawdziwe wyzwanie jest teraz operacyjne:

wybór właściwego modelu dla każdego workloadu
walidacja na własnych danych
zarządzanie latencją i wydatkami
nadzorowanie aktualizacji i ryzyka regresji

To właśnie w tym muszą być naprawdę dobrzy poważni gracze.

Artykuł źródłowy dobrze definiuje problem

Jedno zdanie z oryginalnego wpisu bardzo dobrze oddaje tę zmianę:

“Najtrudniejsza część budowania systemów AI dziś nie polega już na uzyskaniu dostępu do zdolnego modelu. Chodzi o to, by wiedzieć, jak wybrać, zweryfikować, zoptymalizować i operować właściwym modelem przez cały cykl życia prawdziwej aplikacji.”

To dokładnie trafna diagnoza.

Zbyt wiele zespołów nadal uważa, że wybór modelu jest główną decyzją.

Nie jest.

Większym problemem jest operowanie modelem:

który workload dostaje który model?
jak weryfikuje się jakość?
jaka forma kosztów jest akceptowalna?
co się dzieje, gdy pojawi się nowy model albo stary zacznie się rozjeżdżać?
jak przetestować zmianę bez psucia prawdziwych workflow?

To jest teraz prawdziwa praca inżynierska.

Dlaczego ten materiał Foundry jest przydatny

Lubię ten artykuł, bo mówi o systemach AI tak, jak naprawdę muszą o nich myśleć doświadczeni inżynierowie platform.

Nie jako “wybierz najmądrzejszy model i idź dalej”.

Ale jako systemy żyjące pod kompromisami:

capability
latency
cost
safety
governance
upgrade pressure

To znacznie bardziej użyteczne niż optymizm oparty na benchmarkach.

Najważniejsza zmiana to myślenie oparte najpierw na kryteriach

Oryginalny wpis radzi, by zdefiniować kryteria sukcesu zanim otworzy się katalog modeli.

Myślę, że to jedna z najważniejszych nawyków, jakie zespoły mogą przyjąć.

Jeśli najpierw otworzysz katalog, kotwiczysz się w reputacji.

Jeśli najpierw zdefiniujesz kryteria, kotwiczysz się w realiach workloadu.

To zdrowszy proces.

Bo model, który wygrywa benchmark, nie jest automatycznie tym, który wygrywa na:

twoich promptach
twoim budżecie latencji
twoich guardrailach kosztowych
twoich wymaganiach governance

Ta różnica to punkt startowy dojrzałej inżynierii AI.

Historia multi-model staje się prawdziwą przewagą

Jeszcze jedna rzecz, którą lubię, to wyraźnie model-agnostyczne ujęcie.

Artykuł przedstawia Foundry nie jako cel dla jednego modelu, ale jako operational surface obejmujący:

modele Microsoft
modele partnerów
modele open source
warianty po doszkoleniu
strategie routingu i optymalizacji

To ważne, bo elastyczność modeli nie jest już luksusem. Jest częścią zarządzania ryzykiem.

Jeśli jakość się zmienia, ceny się ruszają albo limity stają się ciasne, zespoły potrzebują opcji.

Kontrola kosztów nie jest sprawą drugorzędną

Artykuł ma też rację, pokazując koszt jako kwestię architektury.

To nie jest problem typu “zoptymalizujemy później”.

Jeśli domyślnie wysyłasz każde zadanie do najcięższego modelu, może to świetnie działać w demo, a załamać się pod ekonomią produkcji.

Dlatego uważam, że sekcje o:

routing
batching
caching
provisioned throughput
zarządzanie quota

są ważniejsze, niż wielu osobom się wydaje.

Zespoły, które traktują dyscyplinę kosztową jako część projektowania systemu, będą starzeć się dużo lepiej niż te, które traktują ją jako późniejsze sprzątanie.

Moja opinia

To przydatny materiał Foundry, bo mówi o systemach AI tak, jak naprawdę muszą je prowadzić doświadczeni inżynierowie.

Nie jako demo. Nie jako jednorazowy prototyp. I nie jako turystyka po rankingach.

Ale jako systemy operacyjne dla workloadów, ograniczeń, kompromisów i ciągłej zmiany.

Musimy dalej podnosić tę rozmowę na ten poziom.

A jeśli budujesz produkcyjne systemy AI, to właśnie taka mentalność powinna zostać przez zespoły wcześnie przyswojona.

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

Historia Foundry od obserwowalności do ROI to dokładnie to, czego potrzebują poważne platformy agentowe

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

Ten wpis został przetłumaczony automatycznie. Aby zobaczyć oryginał, kliknij tutaj.

Jeśli agenci AI mają żyć w produkcji, obserwowalność nie może kończyć się na logach i trace’ach.

Właśnie dlatego nowa historia Foundry od obserwowalności do ROI wydaje się ważna.

Prawdziwy przekaz nie brzmi: „dodaliśmy więcej dashboardów”.

Prawdziwy przekaz jest taki, że poważne platformy agentowe potrzebują ciągłego cyklu operacyjnego:

śledzić, co się wydarzyło
oceniać, czy było dobre
optymalizować to, co wymaga pracy
łączyć wynik z wartością biznesową

To znacznie silniejsza historia niż zwykłe platformowe lanie wody.

Kluczowe zdanie z artykułu źródłowego mówi wszystko

Oryginalny wpis zaczyna się od zdania, na które moim zdaniem każdy zespół budujący agentów powinien zwrócić uwagę:

“Uruchomienie agenta AI to łatwa część. Utrzymanie go dokładnego, bezpiecznego i odpowiedzialnego w produkcji to miejsce, w którym zespoły się zacinają.”

To jest dokładnie prawda.

Minęliśmy już etap, w którym główne pytanie brzmiało: „czy mogę sprawić, by agent zrobił coś fajnego?”.

Trudniejsze i cenniejsze pytanie brzmi:

czy mogę obsługiwać ten system, gdy zaczyna wchodzić w interakcję z prawdziwymi użytkownikami, prawdziwymi narzędziami i prawdziwymi kosztami?

Właśnie w tym kierunku Foundry próbuje przesunąć rozmowę.

Dlaczego to ważniejsze niż kolejna demo agenta

Wiele ogłoszeń dotyczących agentów AI wciąż skupia się na tworzeniu: zbuduj agenta, podepnij narzędzia, zroute’uj zadania, opublikuj interfejs.

To wszystko jest w porządku.

Ale pytania operacyjne są miejscem, w którym większość poważnych systemów staje się trwała albo zamienia się w kosztowne eksperymenty:

co agent tak naprawdę robi w produkcji?
czy zrobił właściwą rzecz?
czy z czasem się pogarsza?
czy jest zbyt drogi w stosunku do wartości, którą tworzy?
które zmiany konfiguracji naprawdę poprawiły jakość?

Dlatego uważam, że ogłoszenie Foundry jest ważniejsze niż typowe podsumowanie funkcji. Próbuje zdefiniować pętlę Agent DevOps, a nie tylko historię tworzenia agenta.

Czteroelementowa pętla to tutaj prawdziwy produkt

Artykuł zasadniczo organizuje platformę wokół czterech możliwości:

Trace
Evaluate
Monitor
Optimize

To jest właściwy kształt.

Powiedziałbym nawet, że każda platforma, która chce być traktowana poważnie przy produkcyjnych workloadach agentowych, ostatecznie będzie potrzebować wszystkich czterech.

Samo tracing nie wystarczy.

Sama ewaluacja nie wystarczy.

Optymalizacja bez dowodów to po prostu zgadywanie.

A rozmowa o ROI bez telemetrii to zwykle teatr.

Interoperacyjność jest tu szczególnie sprytna

Jedną z najmocniejszych decyzji w ogłoszeniu jest to, że Foundry nie udaje, iż każdy agent będzie zbudowany w jednym frameworku.

W artykule źródłowym wyraźnie pojawia się rozszerzenie tracingu i ewaluacji na:

LangChain
LangGraph
OpenAI SDK
Microsoft Agent Framework
własne frameworki przez OpenTelemetry

To ważne.

Bo lock-in platformy to jeden z najszybszych sposobów, by użyteczna z założenia historia operacyjna stała się mniej atrakcyjna.

Jeśli zespoły mogą zachować wybór frameworka, a jednocześnie dostać telemetrię i powierzchnie oceny na poziomie produkcyjnym, tarcie znacząco spada.

Ocena rubric może okazać się ważniejsza, niż ludzie się spodziewają

Warto też zwrócić uwagę na część dotyczącą rubric evaluation.

Myślę, że to jedna z najbardziej praktycznych dodatków w całym poście.

Dlaczego? Bo „dobry” zależy od kontekstu.

Artykuł mówi, że rubric evaluation generuje „kontekstowe kryteria oceny z zamierzonego zachowania twojego agenta”. Właśnie w tym kierunku muszą iść takie systemy.

Generyczne ocenianie jakości jest użyteczne.

Ale w końcu zespoły muszą oceniać agentów według własnych standardów:

ton
ukończenie zadania
zgodność z politykami
oczekiwania dotyczące latencji
granice kosztów
specyficzne reguły biznesowe domeny

To właśnie tam ewaluacja zaczyna być operacyjnie znacząca, a nie tylko akademicko interesująca.

ROI jest najbardziej niewygodną częścią, i dlatego jest ważne

Uważam też, że część ROI w ogłoszeniu jest ważna właśnie dlatego, że jest niewygodna.

Artykuł zadaje pytanie wprost:

„czy ten agent jest wart tego, ile kosztuje?”

To pytanie często jest omijane w rozmowach o AI.

Ale to właściwe pytanie.

Jeśli platforma naprawdę potrafi połączyć koszt, ukończenie zadań, zaoszczędzony czas i trace’y produkcyjne w jednym miejscu, daje to engineeringowi i leadershipowi znacznie lepszy wspólny język.

I szczerze mówiąc, taki wspólny język jest bardzo potrzebny.

Moja opinia

To jedno z lepszych ogłoszeń na poziomie platformy w tym zestawie, bo skupia się na operowaniu agentami, a nie tylko na ich budowaniu.

A tam właśnie zaczyna się prawdziwie ciężka praca.

Najmocniejsze platformy AI w najbliższych latach nie będą po prostu tymi, które mają dostęp do większej liczby modeli albo większej liczby demo. Będą tymi, które pomagają zespołom śledzić zachowanie, oceniać wyniki, bezpiecznie optymalizować i uzasadniać koszty dowodami.

Ta historia Foundry próbuje iść dokładnie w tym kierunku.

Dlatego warto traktować ją poważnie.

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