Microsoft-Decision-1 đã ra mắt trên Foundry. Tab Benchmarks của nó trống không.

Điều thú vị nhất về bản phát hành Microsoft tuần này không phải là những gì Microsoft-Decision-1 có thể làm. Điều đáng nói là những gì Microsoft chọn không công bố về nó. Mô hình đã hoạt động: nó được phát hành chính thức trên Microsoft Foundry vào ngày 8 tháng 10 năm 2026, hai ngày trước khi bài này được viết. Đây là một mô hình chấm điểm quyết định — bạn đưa cho nó một trạng thái và một câu hỏi với tập câu trả lời cố định, và nó trả về xác suất đã hiệu chỉnh cho mỗi câu trả lời — được Microsoft hậu huấn luyện trên mô hình trọng số mở Qwen3.5-9B, chạy một lượt qua tối đa 32.768 token và phát ra không có token đầu ra bởi vì nó không bao giờ sinh ra bất cứ thứ gì cả. Trang danh mục có một thẻ Benchmarks. Nó chứa một đoạn phương pháp luận và không có số liệu.

Khoảng trống đó chính là câu chuyện, và đó là một câu chuyện hữu ích hơn một mục “Microsoft phát hành một mô hình” khác. Mọi câu hỏi nghiêm túc về một bộ chấm điểm đều là câu hỏi về hiệu chuẩn — liệu một 0,8 được trả về có nghĩa là 0,8 hay không — và một bản ra mắt chỉ đi kèm một điểm Brier hoặc một chỉ số hiệu chuẩn kỳ vọng duy nhất sẽ để con số duy nhất quan trọng bị đo bởi bất kỳ ai áp dụng nó. Phần tiếp theo là những gì trang Foundry thực sự ghi lại, những gì nó bỏ qua một cách đáng chú ý, và những gì một nhóm đánh giá có thể làm về điều đó trong tuần này.

Chính xác thì đã phát hành những gì

Microsoft-Decision-1 là một API được lưu trữ. Hợp đồng là một lệnh gọi vào, một phân phối ra, không có vòng lặp giải mã ở bất kỳ đâu trong luồng xử lý: yêu cầu chứa nội dung cần đánh giá cùng với một câu hỏi có tập câu trả lời có giới hạn, và phản hồi chứa xác suất cho mỗi lựa chọn. Microsoft liệt kê các dạng câu hỏi được hỗ trợ gồm có/không, trắc nghiệm, chấm điểm, phân loại và dựa trên rubric, tất cả trong một lần gọi duy nhất tối đa 32K token. Nó chỉ dành cho văn bản — không nhận đầu vào hình ảnh, âm thanh hay video, và đầu ra không có gì ngoài các con số.

Các trường hợp loại trừ được nêu rõ ràng không kém gì các tính năng, và chúng đáng được đọc trước tiên: không được thiết kế để tạo văn bản, trả lời câu hỏi mở, hội thoại, dịch hoặc tóm tắt, và không nhằm cho các tác vụ yêu cầu kiến thức không có trong đầu vào. Nó không đưa ra lý lẽ giải thích nào. Các trường hợp sử dụng được công bố đều là những nơi mà một đội ngũ nền tảng đã có sẵn một quyết định gán nhãn cần đưa ra — chấm điểm một câu trả lời được tạo ra theo bộ tiêu chí, đánh giá mức độ liên quan của truy xuất, phân loại ưu tiên một hàng đợi, kiểm soát việc cho phép một lệnh gọi công cụ tác nhân được đề xuất, sàng lọc nội dung theo các ngưỡng do ứng dụng xác định thay vì chính sách cố định của nhà cung cấp, và tự động chấp nhận các kết quả có độ tin cậy cao trong khi chuyển phần còn lại lên cấp xử lý cao hơn.

Hai chi tiết vận hành nổi bật từ danh sách triển khai. Thứ nhất là Microsoft hỗ trợ một cách rõ ràng tùy chọn từ chối trả lời như "không thể xác định" khi bằng chứng được cung cấp không đủ — đó là sự khác biệt giữa một bộ chấm điểm đã được hiệu chỉnh và một bộ chỉ đơn thuần tỏ ra tự tin, và chính điều đó khiến việc đặt ngưỡng phát huy tác dụng. Thứ hai là suy luận theo lô bị vô hiệu hóa. Bạn không thể phân bổ dần một lượt chấm điểm lớn qua kênh theo lô theo cách bạn vẫn làm với một mô hình sinh, nên độ trễ mỗi lần gọi chính là độ trễ của pipeline của bạn chứ không phải là vấn đề của một tác vụ ngoại tuyến.

Phân phối chỉ có trên Foundry, trong danh mục "Direct from Azure" dưới dạng triển khai serverless hoặc unified endpoint trên SKU tiêu chuẩn — trả theo mức sử dụng hoặc provisioned throughput dành riêng. Trọng số không được phân phối. Không có kho Hugging Face, không có bản tải xuống, không có lộ trình fine-tuning và không có tùy chọn tự lưu trữ. Ứng dụng tích hợp qua HTTPS với xác thực Azure tiêu chuẩn. Hồ sơ công bố về huấn luyện báo cáo rằng bộ dữ liệu được sử dụng lần đầu vào tháng 9 năm 2026 với quá trình thu thập vẫn đang tiếp diễn, đây là khoảng cách ngắn nhất có thể giữa dữ liệu huấn luyện và ngày GA, và là điều bình thường đối với một post-train trên nền tảng đã phát hành của người khác.

Tab điểm chuẩn, được trích dẫn toàn văn

Đây là toàn bộ những gì Microsoft đã công bố về mức độ hoạt động của mô hình. Quá trình đánh giá đã sử dụng "các benchmark ra quyết định công khai và cộng đồng cùng các bộ kiểm thử nội bộ được giữ riêng không dùng trong huấn luyện." Các chỉ số gồm độ chính xác, lỗi hiệu chỉnh, recall an toàn, tỷ lệ dương tính giả và tính nhất quán về công bằng. Thứ tự phương án đã được thay đổi. Các kiểm định thống kê theo cặp đã được áp dụng. Tuyên bố mang tính định tính: Microsoft-Decision-1 "hoạt động ngang bằng với các mô hình ra quyết định hàng đầu và vượt lên trên các mô hình ra quyết định mở khác được đánh giá bằng cùng phương pháp luận."

Đó là một thiết kế đánh giá chỉn chu nhưng được mô tả mà không kèm kết quả. Việc chỉ ra điều đó không phải là một lời buộc tội — một đoạn phương pháp luận không có bảng là một lựa chọn cụ thể, có thể kiểm chứng, và đó là một lựa chọn khác với lựa chọn mà phần còn lại của nhóm nhỏ này đã đưa ra. Các mô hình quyết định mở mà Microsoft đang ngầm so sánh đều công bố số liệu của họ: dòng Intern-Decision của InternLM in các chỉ số Brier và sai số hiệu chuẩn kỳ vọng trên thẻ mô hình của mình, Jev của TypeSafe công bố cả hai, và dòng d1 của Liquid AI phát hành kèm bảng độ chính xác cùng với trọng số. Microsoft là công ty lớn nhất trong nhóm này và là công ty duy nhất yêu cầu được tin tưởng.

Công ty có nói rõ nơi họ tin rằng mô hình mạnh và yếu, điều này hữu ích hơn cho hành động so với một điểm số tiêu đề. Mạnh nhất: suy luận, áp dụng quy tắc và khả năng chống chịu với định dạng prompt. Cạnh tranh: phân loại, truy xuất, công bằng, sử dụng công cụ và hầu hết các tác vụ đa ngôn ngữ. Yếu nhất: kiến thức chuyên ngành. Các hạn chế do chính họ báo cáo cũng thẳng thắn theo cách tương tự — điểm số có thể thay đổi theo cách diễn đạt và thứ tự lựa chọn, một câu hỏi được đặt kém vẫn trả về điểm số, độ hiệu chuẩn mạnh nhất ở những loại tác vụ quen thuộc, và không có lời giải thích nào để kiểm chứng khi một câu trả lời có vẻ sai.

Phạm vi bao phủ ngôn ngữ cũng mang dạng lưu ý tương tự. 25 ngôn ngữ được liệt kê là được hỗ trợ, trải rộng từ tiếng Nhật, tiếng Hàn, tiếng Ả Rập, tiếng Việt, tiếng Thái, tiếng Thổ Nhĩ Kỳ, tiếng Hindi, tiếng Bengal, tiếng Swahili, tiếng Do Thái, tiếng Ba Tư và tiếng Ukraina cùng nhiều ngôn ngữ khác, với cảnh báo rõ ràng rằng độ bao phủ, chất lượng và hiệu chuẩn "có thể khác nhau tùy theo ngôn ngữ" và rằng các ngôn ngữ không phải tiếng Anh, đặc biệt là những ngôn ngữ ít tài nguyên, là một mảng hoạt động kém. Mô hình nền Qwen3.5-9B hỗ trợ vượt xa 200 ngôn ngữ. Hậu huấn luyện chỉ giữ lại khoảng một phần tư số đó, và chính phần tư ấy là nơi hiệu chuẩn được áp vào.

Trên trang cũng không có giá.

Trường giá của danh mục không in ra một mức giá. Nó dẫn liên kết ra ngoài tới bề mặt định giá mô hình của chính Microsoft, nên chi phí trên mỗi quyết định là thứ bạn đọc từ Azure hoặc từ hóa đơn chứ không phải từ thẻ mô hình. Với bất kỳ ai đang mô hình hóa chi phí trên mỗi quyết định ở quy mô lớn, đó là một lỗ hổng thực sự, và đáng để nói thẳng ra thay vì ước lượng. Có hai điều rút ra từ kiến trúc và đáng đưa vào ước tính đó: 0% chi phí của một lần gọi là token đầu ra, vì không có token nào cả, và tập lựa chọn là một phần của đầu vào, nên một câu hỏi với sáu mươi hai lựa chọn mô tả tốn kém hơn mỗi lần gọi so với một câu hỏi có/không — bạn đang trả tiền cho bộ tiêu chí bạn đã viết, chứ không phải cho câu trả lời.

Vì sao kiểu phát hành này lại là phần thú vị

Một bộ chấm điểm quyết định là một canh bạc rằng điều mà các doanh nghiệp sơ khai thực sự cần không phải là một người viết tốt hơn mà là một người phán xử rẻ hơn, đáng tin cậy hơn. Canh bạc đó chỉ sinh lời nếu xác suất là đáng tin cậy, bởi vì mọi thứ ở hạ nguồn của một bộ chấm điểm đều là một ngưỡng: 0.7 sẽ được chuyển cho một người, 0.95 tự động chấp nhận, và cái giá của việc đặt sai ngưỡng đó được trả bằng những quyết định tự động tồi tệ chứ không phải bằng token. Một nhà cung cấp phát hành bộ chấm điểm mà không kèm bảng hiệu chuẩn là đang yêu cầu mỗi khách hàng tự suy ra lại nó trên dữ liệu của chính họ.

Tài liệu của chính Microsoft khuyến nghị đúng điều đó, điều này vừa làm dịu bớt sự chỉ trích vừa làm sắc bén hơn kết luận thực tiễn cùng một lúc. Hãy xác thực trên dữ liệu đại diện cho trường hợp sử dụng của bạn. Hãy đặt ngưỡng dựa trên chi phí từ các lỗi của bạn thay vì dựa trên một giá trị mặc định. Luôn bao gồm một lựa chọn không trả lời. Hãy ngẫu nhiên hóa thứ tự lựa chọn ở nơi thứ tự có thể làm sai lệch câu trả lời. Luôn có con người trong vòng lặp đối với bất kỳ điều gì quan trọng. Đó là lời khuyên hợp lý cho bất kỳ hệ thống chấm điểm nào. Đó là lời khuyên duy nhất hiện có cho hệ thống này.

Thử nó trong tuần này mà không cam kết

Cách đánh giá rẻ nhất là chọn một quyết định mà bạn vốn đã đưa ra thủ công, tập hợp hai trăm trường hợp đã gán nhãn với đúng các tập câu trả lời mà ứng dụng của bạn thực sự sẽ đưa ra, rồi chạy chúng qua một triển khai Foundry. Hãy tính sai số hiệu chuẩn kỳ vọng (expected calibration error) trên đầu ra, và bạn sẽ biết về Microsoft-Decision-1 nhiều hơn mọi thứ Microsoft từng công bố về nó, bởi vì bạn đã đo nó trên chính phân phối của mình thay vì trên một tập kiểm thử nội bộ được giữ kín. Đó chỉ là công việc của một buổi chiều, và nó khép lại toàn bộ câu hỏi về benchmark.

Vị trí của OrcaRouter nằm ở nửa còn lại của một vòng lặp tính điểm, và đó chính là nửa tạo sinh. Chúng tôi không lưu trữ Microsoft-Decision-1 và nó không có trong danh mục của chúng tôi — một mô hình trả về xác suất thay vì văn bản không phải là thứ bạn định tuyến các chat completion tới, và không có gì ở đây nên được hiểu là một tuyên bố về tính khả dụng. Thứ nằm sau một khóa tương thích OpenAI duy nhất của chúng tôi là nhóm hơn 200 mô hình đảm nhận phần viết: mô hình phác thảo bộ tiêu chí, hai mô hình tạo ra các câu trả lời ứng viên, mô hình phát ra lệnh gọi công cụ mà Decision-1 sau đó chấm điểm trước khi nó chạy. Giá niêm yết của nhà cung cấp được chuyển nguyên với mức chênh lệch 0%, vì vậy khi bên phía mô hình tạo sinh giảm giá thì bên chúng tôi cũng áp dụng ngay trong cùng ngày, và tính năng chuyển đổi dự phòng tự động giữ cho nhánh tạo sinh luôn hoạt động khi một nhà cung cấp đơn lẻ gặp sự cố — điều này còn quan trọng hơn trong một pipeline chấm điểm mọi thứ nó thấy so với một pipeline chỉ thỉnh thoảng trả lời người dùng. Nếu bạn không muốn chỉ chọn một mô hình đánh giá duy nhất, DSL định tuyến kết hợp nhiều mô hình vào một lệnh gọi, và tính năng hợp nhất mô hình báo cáo mức độ đồng thuận của chúng dưới dạng một trường được chấm điểm thay vì văn xuôi mà bạn phải đọc.

Điều có thể thay đổi bài viết này là một bảng. Công bố điểm Brier và ECE, hoặc để một lần chạy độc lập góp mặt trên một bảng xếp hạng, thì phần đánh giá ở trên sẽ trở thành sự xác nhận thay vì bằng chứng duy nhất đang tồn tại. Cho đến lúc đó, mô tả chính xác về Microsoft-Decision-1 vẫn còn hẹp: các trọng số là thật, hợp đồng được tài liệu hóa tốt hơn mức mà hầu hết các bản phát hành được host làm được, tùy chọn từ chối trả lời được thiết kế tích hợp thay vì gắn thêm chắp vá, và tuyên bố về hiệu năng chỉ là một câu — một câu được viết tốt, không gắn với bất kỳ con số nào.

Điểm mấu chốt

Microsoft-Decision-1 đạt trạng thái khả dụng chung trên Microsoft Foundry vào ngày 8 tháng 10 năm 2026 dưới dạng một bộ chấm điểm quyết định chỉ dùng văn bản, 32.768 token, được xây dựng trên Qwen3.5-9B, trả về xác suất đã hiệu chỉnh trên các tập lựa chọn của riêng bạn với không token đầu ra và không có trọng số nào phải tải về. Điểm mạnh của nó là một hợp đồng một lượt gọn gàng, một đường thoái thác được thiết kế sẵn, cùng xác thực, thanh toán và quản trị Azure đi kèm; điểm yếu của nó là không ai ngoài Microsoft có một con số được công bố về mức độ hiệu chỉnh tốt của nó, kể cả Microsoft. Hãy coi việc ra mắt này là một API đang trở nên khả dụng, chứ không phải một năng lực đang được thiết lập, và hãy đưa các trường hợp có nhãn của riêng bạn qua nó trước khi bất cứ thứ gì ở hạ nguồn phụ thuộc vào một ngưỡng.