Microsoft-Decision-1 เปิดให้ใช้งานจริงบน Foundry แล้ว แต่แท็บ Benchmarks ของมันว่างเปล่า

สิ่งที่น่าสนใจที่สุดเกี่ยวกับการเปิดตัวของ Microsoft ในสัปดาห์นี้ไม่ใช่สิ่งที่ Microsoft-Decision-1ทำได้ แต่เป็นสิ่งที่ Microsoft เลือกที่จะไม่เปิดเผยเกี่ยวกับมัน โมเดลนี้เปิดใช้งานแล้ว โดยเปิดให้ใช้ทั่วไปบน Microsoft Foundry เมื่อ 8 ตุลาคม 2026 สองวันก่อนที่บทนี้จะถูกเขียนขึ้น มันเป็นโมเดลให้คะแนนการตัดสินใจ — คุณป้อนสถานะและคำถามที่มีชุดคำตอบตายตัว แล้วมันจะคืนค่าความน่าจะเป็นที่ปรับเทียบแล้วสำหรับแต่ละคำตอบ — ผ่านการฝึกต่อโดย Microsoft บน Qwen3.5-9B แบบเปิดน้ำหนัก รันหนึ่งรอบบนโทเคนสูงสุด 32,768 โทเคน และส่งออก โทเคนเอาต์พุตเป็นศูนย์ เพราะมันไม่สร้างสิ่งใดเลย หน้าแคตตาล็อกมีแท็บ Benchmarks ซึ่งมีเพียงย่อหน้าอธิบายวิธีการ และไม่มีตัวเลขใด ๆ

ช่องว่างนั้นคือเรื่องราว และมันมีประโยชน์มากกว่ารายการ "Microsoft ส่งโมเดล" อีกชิ้นหนึ่ง ทุกคำถามจริงจังเกี่ยวกับตัวให้คะแนนคือคำถามเรื่องการสอบเทียบ — ค่า 0.8 ที่ส่งคืนมานั้นหมายถึง 0.8 จริงหรือไม่ — และการเปิดตัวที่มาพร้อมโดยไม่มี Brier score หรือตัวเลข expected-calibration-error เพียงค่าเดียว ย่อมปล่อยให้ตัวเลขเดียวที่สำคัญต้องถูกวัดโดยใครก็ตามที่นำไปใช้ สิ่งที่ตามมาคือสิ่งที่หน้า Foundry เอกสารไว้จริง สิ่งที่มันละเว้นไว้อย่างเห็นได้ชัด และสิ่งที่ทีมประเมินผลทำได้เกี่ยวกับเรื่องนี้ในสัปดาห์นี้

ปล่อยอะไรออกไปกันแน่

Microsoft-Decision-1 เป็น API ที่โฮสต์ สัญญาคือเรียกหนึ่งครั้งเข้า แจกแจงหนึ่งออก โดยไม่มีลูปการถอดรหัสที่ใดในเส้นทาง: คำขอจะนำเนื้อหาที่จะถูกตัดสินบวกกับคำถามที่มีชุดคำตอบจำกัด และการตอบกลับจะมีความน่าจะเป็นสำหรับแต่ละตัวเลือก Microsoft ระบุรูปแบบคำถามที่รองรับ ได้แก่ ใช่/ไม่ใช่ หลายตัวเลือก การให้คะแนน การจำแนกประเภท และแบบอิงรูบริก ทั้งหมดภายในหนึ่งการเรียกใช้สูงสุด 32K โทเค็น เป็นข้อความเท่านั้น — ไม่มีอินพุตรูปภาพ เสียง หรือวิดีโอ และส่งออกเป็นตัวเลขเท่านั้น

ข้อจำกัดเหล่านี้ถูกระบุไว้อย่างตรงไปตรงมาไม่ต่างจากคุณสมบัติต่าง ๆ และคุ้มค่าที่จะอ่านก่อนสิ่งอื่นใด: ไม่ได้ออกแบบมาสำหรับการสร้างข้อความ การตอบคำถามแบบปลายเปิด การสนทนา การแปล หรือการสรุปความ และไม่ได้มีไว้สำหรับงานที่ต้องใช้ความรู้ซึ่งไม่มีอยู่ในข้อมูลนำเข้า มันไม่สร้างคำอธิบายเหตุผลประกอบ กรณีการใช้งานที่เผยแพร่ไว้ล้วนเป็นจุดที่ทีมแพลตฟอร์มมีการตัดสินใจที่มีป้ายกำกับอยู่แล้ว ได้แก่ การให้คะแนนคำตอบที่สร้างขึ้นเทียบกับเกณฑ์รูบริก การตัดสินความเกี่ยวข้องของการค้นคืน การคัดแยกและจัดลำดับคิว การอนุมัติการเรียกเครื่องมือของเอเจนต์ที่เสนอ การคัดกรองเนื้อหาเทียบกับเกณฑ์ที่แอปพลิเคชันกำหนดเองมากกว่านโยบายตายตัวของผู้ขาย และการยอมรับผลลัพธ์ที่มีความมั่นใจสูงโดยอัตโนมัติพร้อมกับส่งต่อผลลัพธ์ที่เหลือให้ดำเนินการต่อไป

รายละเอียดเชิงปฏิบัติสองประการโดดเด่นจากรายการการปรับใช้ ประการแรกคือ Microsoft สนับสนุนตัวเลือกการงดตอบอย่างชัดเจน เช่น "cannot tell" เมื่อหลักฐานที่ให้มาไม่เพียงพอ นั่นคือความแตกต่างระหว่างตัวให้คะแนนที่ปรับเทียบความน่าจะเป็นแล้วกับตัวที่เพียงแค่มีความมั่นใจสูง และนั่นคือสิ่งที่ทำให้การกำหนดเกณฑ์ตัดสินทำงานได้ ประการที่สองคือการอนุมานแบบเป็นชุดถูกปิดใช้งาน คุณไม่สามารถเฉลี่ยต้นทุนของการรันให้คะแนนขนาดใหญ่ผ่านช่องทางแบบเป็นชุดได้เหมือนกับที่ทำกับโมเดลเชิงสร้าง ดังนั้นความหน่วงต่อการเรียกใช้จึงเป็นความหน่วงของไปป์ไลน์ของคุณ ไม่ใช่ปัญหาของงานแบบออฟไลน์

การจัดจำหน่ายมีให้เฉพาะบน Foundry ในพอร์ตโฟลิโอ "Direct from Azure" โดยเป็นการปรับใช้แบบ serverless หรือ unified endpoint บน SKU มาตรฐาน — แบบจ่ายตามการใช้งานหรือ provisioned throughput แบบจองไม่มีการเผยแพร่เวต ไม่มีรีโพซิทอรี Hugging Face ไม่มีให้ดาวน์โหลด ไม่มีเส้นทางการ fine-tuning และไม่มีตัวเลือก self-hosting แอปพลิเคชันเชื่อมต่อผ่าน HTTPS ด้วยการรับรองความถูกต้องมาตรฐานของ Azure การเปิดเผยข้อมูลการฝึกอบรมระบุว่าชุดข้อมูลถูกใช้ครั้งแรกในกันยายน 2026 โดยยังคงมีการเก็บรวบรวมอย่างต่อเนื่อง ซึ่งเป็นระยะห่างที่สั้นที่สุดเท่าที่จะเป็นไปได้ระหว่างข้อมูลการฝึกอบรมกับวันเปิดตัว GA และเป็นเรื่องปกติสำหรับการ post-train บนฐานที่ผู้อื่นเปิดตัวแล้ว

แท็บเกณฑ์มาตรฐาน ที่ยกมาทั้งหมด

นี่คือทั้งหมดที่ Microsoft เผยแพร่เกี่ยวกับประสิทธิภาพการทำงานของโมเดล การประเมินใช้ "เกณฑ์มาตรฐานการตัดสินใจแบบสาธารณะและจากชุมชน และชุดทดสอบภายในที่กันไว้ซึ่งไม่ได้ใช้ในการฝึก" ตัวชี้วัด ได้แก่ ความแม่นยำ ความคลาดเคลื่อนของการสอบเทียบ การเรียกคืนด้านความปลอดภัย อัตราผลบวกลวง และความสอดคล้องด้านความเป็นธรรม ลำดับตัวเลือกถูกสลับเปลี่ยน มีการใช้การทดสอบทางสถิติแบบจับคู่ ข้อกล่าวอ้างเป็นเชิงคุณภาพ: Microsoft-Decision-1 "มีประสิทธิภาพทัดเทียมกับโมเดลการตัดสินใจชั้นนำ และเหนือกว่าโมเดลการตัดสินใจแบบเปิดอื่น ๆ ที่ประเมินด้วยระเบียบวิธีเดียวกัน"

นั่นเป็นรูปแบบการประเมินที่ใช้ได้ดีซึ่งอธิบายไว้โดยไม่มีผลลัพธ์ การชี้ให้เห็นเช่นนั้นไม่ใช่การกล่าวหา — ย่อหน้าว่าด้วยระเบียบวิธีวิจัยที่ไม่มีตารางเป็นทางเลือกที่เฉพาะเจาะจงและตรวจสอบได้ และเป็นทางเลือกที่แตกต่างจากที่ส่วนอื่น ๆ ในกลุ่มเล็ก ๆ นี้ได้เลือกไว้ โมเดลการตัดสินใจแบบเปิดที่ Microsoft กำลังเปรียบเทียบด้วยโดยนัยนั้นเผยแพร่ตัวเลขของตน: ตระกูล Intern-Decision ของ InternLM พิมพ์ค่าตัวเลข Brier และ expected-calibration-error ไว้บนการ์ดโมเดลของตน ตระกูล Jev ของ TypeSafe เผยแพร่ทั้งสองอย่าง และไลน์ d1 ของ Liquid AI แนบตารางความแม่นยำมาพร้อมกับเวตส์ของมัน Microsoft เป็นบริษัทที่ใหญ่ที่สุดในกลุ่มนี้ และเป็นรายเดียวที่ขอให้ผู้คนไว้วางใจ

บริษัทระบุว่าตนเชื่อว่าโมเดลมีจุดแข็งและจุดอ่อนตรงไหน ซึ่งนำไปใช้ประโยชน์ได้จริงมากกว่าคะแนนพาดหัว จุดแข็งที่สุด: การให้เหตุผล การประยุกต์ใช้กฎ และความทนทานต่อการจัดรูปแบบพรอมป์ แข่งขันได้: การจำแนกประเภท การค้นคืน ความเป็นธรรม การใช้เครื่องมือ และงานหลายภาษาส่วนใหญ่ จุดอ่อนที่สุด: ความรู้เฉพาะทาง ข้อจำกัดที่รายงานด้วยตนเองก็ตรงไปตรงมาในลักษณะเดียวกัน — คะแนนอาจเปลี่ยนไปตามถ้อยคำและการเรียงลำดับตัวเลือก คำถามที่ตั้งไว้ไม่ดีก็ยังคงได้คะแนน การปรับเทียบจะแม่นยำที่สุดกับประเภทงานที่คุ้นเคย และไม่มีคำอธิบายให้ตรวจสอบเมื่อคำตอบดูเหมือนผิด

ความครอบคลุมทางภาษาก็มีข้อแม้ในรูปแบบเดียวกัน 25 ภาษาถูกระบุว่าได้รับการรองรับ ครอบคลุมทั้งญี่ปุ่น เกาหลี อาหรับ เวียดนาม ไทย ตุรกี ฮินดี เบงกาลี สวาฮีลี ฮิบรู เปอร์เซีย และยูเครน รวมถึงภาษาอื่น ๆ โดยมีคำเตือนชัดเจนว่าความครอบคลุม คุณภาพ และการปรับคาลิเบรชัน "อาจแตกต่างกันไปตามภาษา" และภาษาที่ไม่ใช่ภาษาอังกฤษ โดยเฉพาะภาษาที่มีทรัพยากรต่ำ เป็นพื้นที่ที่ยังมีประสิทธิภาพต่ำกว่า โมเดลฐาน Qwen3.5-9B รองรับมากกว่า 200 ภาษา การฝึกภายหลัง (post-training) เก็บไว้ประมาณหนึ่งในสี่ของจำนวนนั้น และหนึ่งในสี่ส่วนนั้นคือส่วนที่ทำการปรับคาลิเบรชัน

ไม่มีราคาบนหน้าเว็บเช่นกัน

ฟิลด์ราคาในแค็ตตาล็อกไม่แสดงอัตราค่าบริการ แต่จะลิงก์ออกไปยังหน้าดูราคาโมเดลของไมโครซอฟต์เอง ดังนั้นค่าใช้จ่ายต่อการตัดสินใจจึงเป็นสิ่งที่คุณต้องไปอ่านเอาจาก Azure หรือจากใบเรียกเก็บเงิน ไม่ใช่จากโมเดลการ์ด สำหรับใครก็ตามที่กำลังจำลองต้นทุนต่อการตัดสินใจในปริมาณมาก นี่ถือเป็นช่องว่างที่มีอยู่จริง และควรพูดให้ชัดเจนตรง ๆ ดีกว่าจะไปกะประมาณเอง สองสิ่งนี้ตามมาจากสถาปัตยกรรมและควรนำไปใส่ในการประมาณนั้น: 0% ของต้นทุนการเรียกใช้หนึ่งครั้งคือโทเคนเอาต์พุต เพราะไม่มีเอาต์พุตเลย และชุดตัวเลือกก็เป็นส่วนหนึ่งของอินพุต คำถามที่มีตัวเลือกเชิงพรรณนา 62 ข้อจึงมีต้นทุนต่อการเรียกใช้สูงกว่าคำถามแบบใช่/ไม่ใช่ — คุณกำลังจ่ายสำหรับเกณฑ์การให้คะแนนที่คุณเขียนขึ้นมา ไม่ใช่จ่ายสำหรับคำตอบ

ทำไมการเปิดตัวในรูปแบบนี้ถึงเป็นส่วนที่น่าสนใจ

ตัวให้คะแนนการตัดสินใจคือการเดิมพันว่าสิ่งที่องค์กรแบบดั้งเดิมต้องการจริง ๆ ไม่ใช่เครื่องมือเขียนที่ดีกว่า แต่เป็นผู้ตัดสินที่ถูกกว่าและเชื่อถือได้มากกว่า การเดิมพันนั้นจะคุ้มก็ต่อเมื่อความน่าจะเป็นนั้นเชื่อถือได้ เพราะทุกสิ่งหลังจากตัวให้คะแนนคือเกณฑ์ตัดสิน: 0.7 ส่งต่อไปยังคน, 0.95 ยอมรับอัตโนมัติ และต้นทุนของการกำหนดเส้นนั้นผิดจะจ่ายด้วยการตัดสินใจอัตโนมัติที่ไม่ดี แทนที่จะเป็นโทเค็น ผู้ขายที่ส่งมอบตัวให้คะแนนโดยไม่มีตารางปรับเทียบกำลังขอให้ลูกค้าแต่ละรายคำนวณมันใหม่บนข้อมูลของตนเอง

เอกสารของ Microsoft เองแนะนำแบบนั้นเป๊ะ ซึ่งช่วยลดทอนคำวิจารณ์และทำให้ข้อสรุปเชิงปฏิบัติคมชัดขึ้นในเวลาเดียวกัน ตรวจสอบความถูกต้องบนข้อมูลที่เป็นตัวแทนของกรณีการใช้งานของคุณ กำหนดเกณฑ์จากต้นทุนของข้อผิดพลาดของคุณ แทนที่จะกำหนดจากค่าเริ่มต้น ให้มีตัวเลือกในการงดตอบเสมอ สุ่มลำดับตัวเลือกในจุดที่ลำดับอาจทำให้คำตอบเอนเอียง ให้มีมนุษย์อยู่ในวงจรสำหรับเรื่องที่มีนัยสำคัญ นั่นเป็นคำแนะนำที่สมเหตุสมผลสำหรับระบบให้คะแนนใด ๆ และเป็นคำแนะนำเดียวที่มีให้สำหรับระบบนี้

ลองดูสัปดาห์นี้แบบไม่ผูกมัด

การประเมินที่ถูกที่สุดคือการเลือกการตัดสินใจที่คุณทำด้วยมืออยู่แล้ว รวบรวมเคสที่มีป้ายกำกับสักสองร้อยเคสพร้อมชุดคำตอบที่แอปพลิเคชันของคุณจะให้จริง แล้วรันมันผ่านดีพลอยเมนต์ Foundry คำนวณ expected calibration error จากผลลัพธ์ แล้วคุณจะรู้เกี่ยวกับ Microsoft-Decision-1 มากกว่าทุกสิ่งที่ Microsoft เผยแพร่เกี่ยวกับมัน เพราะคุณจะได้วัดมันบนการกระจายของคุณเอง แทนที่จะวัดบนชุดทดสอบภายในที่กันไว้ นั่นเป็นงานแค่บ่ายเดียว และมันทำให้คำถามเรื่อง benchmark ทั้งหมดหมดไป

จุดที่ OrcaRouter เข้าที่คืออีกครึ่งหนึ่งของลูปการให้คะแนน และเป็นครึ่งที่สร้างผลลัพธ์ขึ้นมา เราไม่ได้โฮสต์ Microsoft-Decision-1 และมันไม่ได้อยู่ในแคตตาล็อกของเรา — โมเดลที่คืนค่าความน่าจะเป็นแทนข้อความไม่ใช่สิ่งที่คุณจะส่งคำขอ chat completions ไปหา และไม่ควรตีความสิ่งใดที่นี่ว่าเป็นการยืนยันว่ามีให้ใช้ได้ สิ่งที่อยู่เบื้องหลังคีย์ที่เข้ากันได้กับ OpenAI เพียงคีย์เดียวของเราคือกลุ่มของ โมเดลมากกว่า 200 รายการที่ทำหน้าที่เขียน ได้แก่ โมเดลที่ร่างรูบริก สองโมเดลที่สร้างคำตอบที่เป็นตัวเลือก และโมเดลที่ปล่อย tool call Decision-1 แล้วให้คะแนนก่อนที่มันจะรัน ราคาตามรายการของผู้ให้บริการถูกส่งผ่านโดยบวกกำไร 0%, ดังนั้นเมื่อฝั่งผู้สร้างลดราคา ราคาของเราก็เป็นจริงในวันเดียวกัน และการสลับสำรองอัตโนมัติทำให้ขาการสร้างยังทำงานอยู่เมื่อผู้ให้บริการรายใดรายหนึ่งมีปัญหา — ซึ่งสำคัญกว่าในไปป์ไลน์ที่ให้คะแนนทุกสิ่งที่มันเห็น มากกว่าในไปป์ไลน์ที่ตอบผู้ใช้เป็นครั้งคราว หากคุณไม่อยากเลือกผู้ตัดสินเพียงตัวเดียว routing DSL ประกอบโมเดลหลายตัวไว้ในคำสั่งเดียว และ model fusion รายงานความสอดคล้องระหว่างกันเป็นฟิลด์ที่ให้คะแนนแล้ว แทนที่จะเป็นข้อความร้อยแก้วที่คุณต้องอ่านเอง

สิ่งที่ทำให้บทความนี้เปลี่ยนไปได้คือตาราง เผยแพร่คะแนน Brier และ ECE หรือปล่อยให้การรันอิสระไปอยู่บนลีดเดอร์บอร์ด แล้วการประเมินข้างต้นจะกลายเป็นการยืนยัน แทนที่จะเป็นหลักฐานเดียวที่ดำรงอยู่ จนกว่าจะถึงตอนนั้น คำอธิบายที่แม่นยำของ Microsoft-Decision-1 ก็ยังแคบ: ค่าน้ำหนักนั้นมีจริง สัญญาฉบับนี้มีเอกสารกำกับที่ดีกว่าที่รีลีสแบบโฮสต์ส่วนใหญ่ทำได้ ตัวเลือกการงดตอบถูกออกแบบมาแต่แรก ไม่ใช่เอามาแปะเพิ่มทีหลัง และคำกล่าวอ้างเรื่องประสิทธิภาพก็เป็นเพียงประโยคเดียว — ประโยคที่เขียนได้ดี แต่ไม่ผูกกับตัวเลขใด ๆ เลย

ประเด็นสำคัญ

Microsoft-Decision-1 เปิดให้ใช้ทั่วไปบน Microsoft Foundry เมื่อวันที่ 8 ตุลาคม 2026 ในฐานะตัวให้คะแนนการตัดสินใจแบบข้อความล้วนขนาด 32,768 โทเคนที่สร้างบน Qwen3.5-9B โดยคืนค่าความน่าจะเป็นที่ปรับเทียบแล้วสำหรับชุดตัวเลือกของคุณเอง โดยใช้โทเคนเอาต์พุตเป็นศูนย์และไม่มีน้ำหนักโมเดลให้ดาวน์โหลด จุดแข็งของมันคือข้อกำหนดการใช้งานแบบรอบเดียวที่ชัดเจน เส้นทางงดตอบที่มีมาแต่การออกแบบ และการยืนยันตัวตน การเรียกเก็บเงิน และการกำกับดูแลของ Azure ที่มาพร้อมกัน จุดอ่อนคือไม่มีใครนอก Microsoft ที่มีตัวเลขเผยแพร่เกี่ยวกับว่ามันปรับเทียบได้ดีเพียงใด รวมถึง Microsoft เอง ให้มองการเปิดตัวครั้งนี้เป็น API ที่เพิ่งพร้อมใช้งาน ไม่ใช่ขีดความสามารถที่ได้รับการพิสูจน์แล้ว และนำเคสที่มีป้ายกำกับของคุณเองมาทดลองกับมันก่อนที่สิ่งใดในปลายทางจะต้องพึ่งพาค่าเกณฑ์