Microsoft-Decision-1 jest już dostępny w Foundry. Jego zakładka Benchmarks jest pusta.

Najciekawsze w wydaniu Microsoftu z tego tygodnia nie jest to, co Microsoft-Decision-1 potrafi zrobić. Ciekawe jest to, o czym Microsoft postanowił nie napisać. Model jest już dostępny: wszedł do ogólnej dostępności w Microsoft Foundry 8 października 2026, dwa dni przed napisaniem tego tekstu. To model oceniający decyzje — podajesz mu stan i pytanie z ustalonym zestawem odpowiedzi, a on zwraca skalibrowane prawdopodobieństwo dla każdej odpowiedzi — dostrojony przez Microsoft na modelu o otwartych wagach Qwen3.5-9B, wykonujący jeden przebieg przez maksymalnie 32 768 tokenów i emitujący zero tokenów wyjściowych, ponieważ w ogóle niczego nie generuje. Strona katalogu ma zakładkę Benchmarki. Zawiera akapit o metodologii i żadnych liczb.

Ta luka jest sednem historii — i jest bardziej użyteczna niż kolejny materiał w stylu „Microsoft wypuszcza model”. Każde poważne pytanie o scorer to pytanie o kalibrację — czy zwrócone 0,8 oznacza 0,8 — a premiera, która pojawia się bez choćby jednego wyniku Briera albo wartości oczekiwanego błędu kalibracji, pozostawia tę jedyną liczbę, która ma znaczenie, do zmierzenia przez tego, kto go przyjmie. Poniżej opisano, co faktycznie dokumentuje strona Foundry, co wymownie pomija i co zespół ewaluacyjny może z tym zrobić w tym tygodniu.

Co zostało wydane, dokładnie

Microsoft-Decision-1 to hostowane API. Umowa jest taka: jedno wywołanie na wejściu, jeden rozkład na wyjściu, bez pętli dekodowania gdziekolwiek na ścieżce: żądanie zawiera materiał do oceny plus pytanie z ograniczonym zestawem odpowiedzi, a odpowiedź zawiera prawdopodobieństwo dla każdej opcji. Microsoft wymienia obsługiwane kształty pytań jako tak/nie, wielokrotny wybór, ocena, klasyfikacja i oparte na rubrykach, wszystko w ramach pojedynczego wywołania do 32K tokenów. Jest to tylko tekst — brak danych wejściowych w postaci obrazu, dźwięku lub wideo, a na wyjściu tylko liczby.

Wykluczenia są podane równie jasno jak funkcje i warto je przeczytać przed wszystkim innym: nie został zaprojektowany do generowania tekstu, odpowiadania na pytania otwarte, prowadzenia rozmowy, tłumaczenia ani streszczania, i nie jest przeznaczony do zadań wymagających wiedzy nieobecnej w danych wejściowych. Nie generuje uzasadnień. Opublikowane przypadki użycia to wyłącznie sytuacje, w których zespół platformy ma już do podjęcia decyzję opatrzoną etykietą — ocenianie wygenerowanej odpowiedzi według rubryki, ocenianie trafności wyszukiwania, triaż kolejki, kontrolowanie proponowanego wywołania narzędzia przez agenta, filtrowanie treści według progów definiowanych przez aplikację, a nie stałej polityki dostawcy, oraz automatyczne akceptowanie wyników o wysokiej pewności przy eskalowaniu pozostałych.

Z zestawienia wdrożenia wyróżniają się dwa szczegóły operacyjne. Po pierwsze, Microsoft wyraźnie obsługuje opcję wstrzymania się od odpowiedzi, taką jak „nie można stwierdzić”, gdy dostarczone dowody są niewystarczające — to właśnie różnica między skalibrowanym skorerem a takim, który jest jedynie pewny siebie, i to sprawia, że progowanie działa. Po drugie, wnioskowanie wsadowe jest wyłączone. Nie można zamortyzować dużego przebiegu oceniania przez kanał wsadowy tak, jak w przypadku modelu generatywnego, więc opóźnienie na wywołanie jest opóźnieniem Twojego potoku, a nie problemem zadania offline.

Dystrybucja odbywa się wyłącznie przez Foundry, w portfolio „Direct from Azure” jako wdrożenie bezserwerowe lub z ujednoliconym punktem końcowym na standardowym SKU — płatność za użycie lub zarezerwowana aprowizowana przepustowość. Wagi nie są udostępniane. Nie ma repozytorium Hugging Face, nie ma możliwości pobrania, nie ma ścieżki dostrajania, nie ma opcji samodzielnego hostowania. Aplikacje integrują się przez HTTPS ze standardowym uwierzytelnianiem Azure. Ujawnienie dotyczące treningu podaje, że zbiór danych został po raz pierwszy użyty we wrześniu 2026 i trwa gromadzenie, co stanowi najkrótszy możliwy odstęp między danymi treningowymi a datą GA i jest normalne w przypadku treningu końcowego na czyjejś udostępnionej bazie.

Zakładka z benchmarkami, zacytowana w całości

Oto całość tego, co Microsoft opublikował na temat skuteczności działania modelu. W ocenie wykorzystano „publiczne i społecznościowe benchmarki decyzyjne oraz odłożone wewnętrzne zestawy testowe nieużywane podczas treningu”. Metrykami były dokładność, błąd kalibracji, czułość bezpieczeństwa, wskaźniki fałszywie dodatnich i spójność w zakresie sprawiedliwości. Kolejność opcji była zmieniana. Zastosowano sparowane testy statystyczne. Twierdzenie ma charakter jakościowy: Microsoft-Decision-1 „osiąga wyniki na równi z wiodącymi modelami decyzyjnymi i wyprzedza inne otwarte modele decyzyjne oceniane przy użyciu tej samej metodologii”.

To kompetentny projekt ewaluacji przedstawiony bez wyniku. Wskazanie tego nie jest oskarżeniem — akapit o metodologii bez tabeli to konkretny, sprawdzalny wybór, i jest to inny wybór niż ten, na który zdecydowała się reszta tej niewielkiej kategorii. Otwarte modele decyzyjne, z którymi Microsoft pośrednio się porównuje, publikują swoje liczby: rodzina Intern-Decision od InternLM podaje na swoich kartach modeli wartości Brier i oczekiwanego błędu kalibracji, Jev od TypeSafe publikuje oba te wskaźniki, a linia d1 od Liquid AI udostępnia tabele dokładności wraz z wagami. Microsoft jest największą firmą w tej grupie i jedyną, która prosi, by brać ją na słowo.

Firma rzeczywiście wskazuje, gdzie jej zdaniem model jest mocny, a gdzie słaby, co jest bardziej użyteczne w praktyce niż wynik z nagłówka. Najmocniejsze obszary: rozumowanie, stosowanie reguł i odporność na formatowanie promptów. Konkurencyjne: klasyfikacja, wyszukiwanie informacji, sprawiedliwość, użycie narzędzi i większość zadań wielojęzycznych. Najsłabsze: wiedza specjalistyczna z konkretnej dziedziny. Ograniczenia podawane przez sam model są równie szczere — wyniki mogą się zmieniać w zależności od sformułowania i kolejności opcji, źle sformułowane pytanie nadal zwraca wynik, kalibracja jest najlepsza w przypadku znanych typów zadań, a gdy odpowiedź wygląda na błędną, nie ma wyjaśnień, które można by poddać audytowi.

Zasięg językowy ma ten sam rodzaj zastrzeżenia. 25 języków jest wymienionych jako obsługiwane, obejmując między innymi japoński, koreański, arabski, wietnamski, tajski, turecki, hindi, bengalski, suahili, hebrajski, perski i ukraiński, z wyraźnym ostrzeżeniem, że zasięg, jakość i kalibracja „mogą się różnić w zależności od języka” oraz że języki inne niż angielski, szczególnie te o niższych zasobach, są obszarem słabszych wyników. Model bazowy Qwen3.5-9B obsługuje znacznie ponad 200 języków. Po treningu zachowano około jednej czwartej z tego, a właśnie na tej ćwiartce dopasowano kalibrację.

Na stronie też nie ma ceny.

Pole cenowe w katalogu nie podaje stawki. Odsyła linkiem do własnej strony Microsoftu z cennikiem modeli, więc koszt na decyzję odczytuje się z Azure albo z rachunku, a nie z karty modelu. Dla każdego, kto modeluje koszt na decyzję przy dużej skali, to realna luka i warto powiedzieć to wprost, zamiast szacować. Z architektury wynikają jednak dwie rzeczy, które warto uwzględnić w tym szacunku: 0% kosztu wywołania to tokeny wyjściowe, ponieważ ich nie ma, a zestaw opcji jest częścią danych wejściowych, więc pytanie z sześćdziesięcioma dwoma opisowymi opcjami kosztuje więcej na wywołanie niż pytanie tak/nie — płacisz za napisane przez siebie kryteria, a nie za odpowiedź.

Dlaczego ten kształt wydania jest interesującą częścią

Skaler decyzji to zakład, że prymitywne przedsiębiorstwa w rzeczywistości potrzebują nie lepszego pisarza, lecz tańszego, bardziej niezawodnego sędziego. Ten zakład opłaca się tylko wtedy, gdy prawdopodobieństwo jest godne zaufania, ponieważ wszystko po skalerze to próg: 0,7 eskaluje do człowieka, 0,95 automatycznie akceptuje, a koszt błędnego ustalenia tej granicy ponosi się w złych decyzjach automatycznych, a nie w tokenach. Dostawca, który dostarcza skaler bez tabeli kalibracyjnej, prosi każdego klienta o ponowne wyprowadzenie jej na własnych danych.

Sama dokumentacja Microsoftu zaleca dokładnie to, co jednocześnie łagodzi krytykę i wyostrza praktyczny wniosek. Waliduj na danych reprezentatywnych dla twojego przypadku użycia. Ustawiaj progi na podstawie kosztu swoich błędów, a nie na podstawie wartości domyślnej. Zawsze uwzględniaj opcję wstrzymania się od odpowiedzi. Losowo zmieniaj kolejność opcji tam, gdzie kolejność mogłaby wpływać na odpowiedź. Zapewnij udział człowieka w procesie decyzyjnym w przypadku wszystkiego, co ma istotne konsekwencje. To rozsądna rada dla każdego oceniającego. To jedyna rada dostępna dla tego konkretnego.

Próbuję tego w tym tygodniu bez zobowiązania

Najtaniej jest wybrać decyzję, którą i tak podejmujesz ręcznie, zebrać dwieście oznaczonych przypadków wraz ze zbiorami odpowiedzi, które faktycznie dostarczyłaby Twoja aplikacja, i przepuścić je przez wdrożenie Foundry. Oblicz oczekiwany błąd kalibracji na wynikach, a dowiesz się o Microsoft-Decision-1 więcej niż z czegokolwiek, co Microsoft opublikował na jego temat, ponieważ zmierzysz go na swoim rozkładzie, a nie na wewnętrznym zestawie testowym wydzielonym do walidacji. To praca na jedno popołudnie i zamyka całą kwestię benchmarku.

Miejsce OrcaRoutera jest w drugiej połowie pętli oceniania, i to w tej połowie, która generuje. Nie hostujemy Microsoft-Decision-1 i nie ma go w naszym katalogu — model, który zwraca prawdopodobieństwa zamiast tekstu, nie jest czymś, do czego kieruje się uzupełnienia czatu, i nic tutaj nie powinno być odczytywane jako twierdzenie o dostępności. Za naszym jednym kluczem zgodnym z OpenAI stoi pula ponad 200 modeli, która wykonuje pisanie: model, który tworzy szkic rubryki, dwa, które generują odpowiedzi kandydujące, oraz ten, który emituje wywołanie narzędzia Decision-1, a następnie ocenia, zanim zostanie ono uruchomione. Cena katalogowa dostawcy jest przekazywana bez narzutu 0%, więc obniżka ceny po stronie generatora obowiązuje u nas tego samego dnia, a automatyczne przełączanie awaryjne utrzymuje działanie odnogi generującej, gdy pojedynczy dostawca zawodzi — co ma większe znaczenie w potoku, który ocenia wszystko, co widzi, niż w takim, który odpowiada użytkownikowi od czasu do czasu. Jeśli wolisz nie wybierać jednego sędziego, DSL routingu łączy kilka modeli w jedno wywołanie, a fuzja modeli raportuje ich zgodność jako oceniane pole, a nie jako prozę, którą trzeba czytać.

Tym, co zmieniłoby ten artykuł, jest tabela. Opublikujcie wyniki Brier i ECE albo pozwólcie, by niezależne uruchomienie trafiło na ranking, a powyższa ocena stanie się potwierdzeniem, a nie jedynym istniejącym dowodem. Do tego czasu trafny opis Microsoft-Decision-1 jest wąski: wagi są prawdziwe, kontrakt jest udokumentowany lepiej, niż udaje się to większości wydań hostowanych, opcja wstrzymania się od odpowiedzi jest zaprojektowana od podstaw, a nie doklejona, a twierdzenie o wydajności to jedno zdanie — dobrze napisane, niepoparte żadnymi liczbami.

Konkluzja

Microsoft-Decision-1 osiągnął ogólną dostępność w Microsoft Foundry 8 października 2026 r. jako tekstowy, 32 768-tokenowy model oceniający decyzje oparty na Qwen3.5-9B, zwracający skalibrowane prawdopodobieństwa dla własnych zestawów opcji, przy zerowej liczbie tokenów wyjściowych i bez wag do pobrania. Jego mocne strony to czysty kontrakt jednoprzebiegowy, zaprojektowana od początku ścieżka abstynencji oraz dołączone uwierzytelnianie, rozliczanie i nadzór Azure; jego słabością jest to, że nikt poza Microsoftem nie opublikował liczby określającej, jak dobrze jest skalibrowany — w tym sam Microsoft. Traktuj tę premierę jako udostępnienie API, a nie jako ustanowienie nowej możliwości, i przepuść przez nie własne oznaczone przypadki, zanim cokolwiek w dalszym przetwarzaniu zacznie zależeć od progu.