Microsoft-Decision-1 עלה לאוויר ב-Foundry. לשונית המדדים שלו ריקה.

הדבר המעניין ביותר בשחרור של Microsoft השבוע הוא לא מה ש-Microsoft-Decision-1 יכול לעשות. זה מה ש-Microsoft בחרה שלא לפרסם עליו. המודל פעיל: הוא הפך לזמין באופן כללי ב-Microsoft Foundry ב-8 באוקטובר 2026, יומיים לפני שנכתבו הדברים. זהו מודל לדירוג החלטות — אתם נותנים לו מצב ושאלה עם קבוצה קבועה של תשובות, והוא מחזיר הסתברות מכוילת לכל תשובה — שעבר אימון נוסף על ידי Microsoft על המודל בעל המשקולות הפתוחות Qwen3.5-9B, המבצע מעבר אחד על עד 32,768 טוקנים ומפיק אפס טוקנים של פלט משום שהוא לעולם לא מייצר דבר כלל. בדף הקטלוג יש לשונית Benchmarks. היא מכילה פסקת מתודולוגיה, בלי שום נתונים.

הפער הזה הוא הסיפור, והוא שימושי יותר מעוד פריט בסגנון "Microsoft משחררת מודל". כל שאלה רצינית לגבי מדד היא שאלת כיול — האם 0.8 שמוחזר אומר 0.8 — והשקה שמגיעה בלי אף ציון Brier או נתון של שגיאת כיול צפויה מותירה את המספר היחיד שחשוב להימדד על ידי מי שמאמץ אותו. מה שלפנינו הוא מה שדף Foundry באמת מתעד, מה שהוא משמיט באופן בולט, ומה שצוות הערכה יכול לעשות בקשר לזה השבוע.

מה נשלח, בדיוק

Microsoft-Decision-1 הוא API מתארח. החוזה הוא קריאה אחת נכנסת, התפלגות אחת יוצאת, ללא לולאת פענוח בשום מקום בנתיב: הבקשה נושאת את החומר שיש לשפוט בתוספת שאלה עם קבוצת תשובות מוגבלת, והתגובה נושאת הסתברות לכל אפשרות. Microsoft מפרטת את צורות השאלות הנתמכות ככן/לא, רב-ברירה, דירוג, סיווג ומבוססות רובריקה, כולן בתוך הפעלה אחת של עד 32K אסימונים. הוא טקסט בלבד — ללא קלט תמונה, אודיו או וידאו, ופלט של מספרים בלבד.

ההחרגות מנוסחות בפשטות כמו היכולות, וכדאי לקרוא אותן לפני כל דבר אחר: לא מיועד ליצירת טקסט, למענה על שאלות פתוחות, לשיחה, לתרגום או לסיכום, ולא נועד למשימות הדורשות ידע שאינו נמצא בקלט. הוא אינו מפיק נימוקים. מקרי השימוש שפורסמו הם כולם מקומות שבהם לצוות פלטפורמה כבר יש החלטה מתויגת לקבל — לדרג תשובה שנוצרה לפי רובריקה, לשפוט רלוונטיות של אחזור, למיין תור, להפעיל שער על קריאת כלי סוכן מוצעת, לסנן תוכן לפי ספים שהאפליקציה מגדירה ולא לפי מדיניות ספק קבועה, ולקבל אוטומטית תוצאות בעלות ביטחון גבוה תוך הסלמת השאר.

שני פרטים תפעוליים בולטים מתוך פירוט הפריסה. הראשון הוא ש-Microsoft תומכת במפורש באפשרות הימנעות כגון "לא ניתן לדעת" כאשר הראיות שסופקו אינן מספיקות — זהו ההבדל בין מודל ניקוד מכויל לבין אחד שהוא רק בטוח בעצמו, וזה מה שמאפשר לעבוד עם ספי החלטה. השני הוא שהסקה באצווה מושבתת. אי אפשר לפרוס את העלות של ריצת ניקוד גדולה דרך ערוץ האצווה כפי שהיית עושה עם מודל גנרטיבי, ולכן זמן ההשהיה לכל קריאה הוא זמן ההשהיה של צינור העיבוד שלך, ולא בעיה של משימת אופליין.

ההפצה היא ב-Foundry בלבד, בתיק "Direct from Azure" כפריסה ללא שרת או בנקודת קצה מאוחדת על SKU סטנדרטי — תשלום לפי שימוש או תפוקה מוקצית שמורה. המשקולות אינן מופצות. אין מאגר Hugging Face, אין הורדה, אין מסלול כוונון עדין, ואין אפשרות אירוח עצמי. יישומים משתלבים דרך HTTPS עם אימות Azure סטנדרטי. גילוי האימון מדווח שמערך הנתונים שימש לראשונה ב-ספטמבר 2026 כשהאיסוף נמשך, שזה המרחק הקצר ביותר האפשרי בין נתוני אימון לתאריך השקה כללית והוא נורמלי עבור אימון-המשך על בסיס שמישהו אחר פרסם.

לשונית מדדי הביצועים, מצוטטת במלואה

הנה מלוא המידע שפרסמה Microsoft לגבי ביצועי המודל. ההערכה השתמשה ב"מדדי החלטה ציבוריים וקהילתיים ובמערכי בדיקה פנימיים שמורים שלא נעשה בהם שימוש באימון". המדדים היו: דיוק, שגיאת כיול, רגישות בטיחות, שיעורי חיוביים שגויים ועקביות הוגנות. סדר האפשרויות שונה. בוצעו מבחנים סטטיסטיים מזווגים. הטענה היא איכותנית: Microsoft-Decision-1 "מתפקד ברמה דומה למודלים מובילים לקבלת החלטות ומקדים מודלים אחרים בקוד פתוח לקבלת החלטות שהוערכו באותה מתודולוגיה."

זהו תכנון הערכה כשיר שמתואר בלי תוצאה. להצביע על כך אינו האשמה — פסקת מתודולוגיה בלי טבלה היא בחירה ספציפית ובת-בדיקה, והיא בחירה שונה מזו שעשתה שאר הקטגוריה הקטנה הזו. מודלי ההחלטה הפתוחים שמיקרוסופט משווה אליהם במרומז מפרסמים את המספרים שלהם: משפחת Intern-Decision של InternLM מדפיסה נתוני Brier ושגיאת כיול צפויה בכרטיסי המודל שלה, Jev מבית TypeSafe מפרסם את שניהם, וקו d1 של Liquid AI מספק טבלאות דיוק עם המשקלים שלו. מיקרוסופט היא החברה הגדולה בקבוצה הזו והיחידה שמבקשת שיאמינו לה.

החברה כן מציינת היכן לדעתה המודל חזק וחלש, וזה שימושי יותר לפעולה מאשר ציון כותרת. החזקים ביותר: הסקה, יישום כללים ועמידות לעיצוב הפרומפט. תחרותיים: סיווג, אחזור, הוגנות, שימוש בכלים ורוב המשימות הרב־לשוניות. החלשים ביותר: ידע תחומי מתמחה. המגבלות המדווחות על ידה גלויות באותו אופן — ציונים יכולים להשתנות לפי ניסוח וסדר אפשרויות, שאלה מנוסחת בצורה לקויה עדיין מחזירה ציון, הכיול חזק ביותר בסוגי משימות מוכרים, ואין הסברים לבדיקה כאשר תשובה נראית שגויה.

לכיסוי השפות יש אותה צורת הסתייגות. 25 שפות רשומות כנתמכות, ובהן יפנית, קוריאנית, ערבית, וייטנאמית, תאית, טורקית, הינדי, בנגלית, סווהילית, עברית, פרסית ואוקראינית, בין היתר, עם אזהרה מפורשת שהכיסוי, האיכות והכיול "עשויים להשתנות משפה לשפה", וששפות שאינן אנגלית, ובמיוחד שפות בעלות מעט משאבים, הן תחום של ביצועים ירודים. הבסיס Qwen3.5-9B תומך בהרבה יותר מ-200 שפות. השלב שלאחר האימון המקדים שמר על כ�רבע מכך, והרבע הזה הוא המקום שבו הותאם הכיול.

גם אין מחיר בדף

שדה התמחור בקטלוג אינו מציג תעריף. הוא מקשר אל משטח התמחור של המודלים של מיקרוסופט עצמה, כך שהעלות לכל החלטה היא משהו שקוראים מ-Azure או מחשבון ולא מכרטיס המודל. למי שמודל עלות לכל החלטה בהיקף, זה פער של ממש, וראוי לומר אותו בגלוי במקום להעריך. שני דברים כן נובעים מהארכיטקטורה וראוי להביא בחשבון באותה הערכה: 0% מעלותה של קריאה הם אסימוני פלט, מפני שאין כאלה, וקבוצת האפשרויות היא חלק מהקלט, כך ששאלה עם שישים ושתיים אפשרויות תיאוריות עולה יותר לקריאה מאשר כן/לא — אתם משלמים על הרובריקה שכתבתם, לא על התשובה.

למה דווקא צורת השחרור הזאת היא החלק המעניין

מנקד החלטות הוא הימור שהפרימיטיב שארגונים באמת זקוקים לו אינו כותב טוב יותר אלא שופט זול ואמין יותר. ההימור הזה משתלם רק אם ההסתברות מהימנה, מפני שכל מה שבמורד הזרם של מנקד הוא סף: 0.7 מועבר לטיפול אנושי, 0.95 מתקבל אוטומטית, והעלות של טעות בקו הזה משולמת בהחלטות אוטומטיות גרועות ולא בטוקנים. ספק שמשחרר את המנקד בלי טבלת הכיול מבקש מכל לקוח לגזור אותה מחדש על הנתונים שלו.

התיעוד של מיקרוסופט עצמה ממליץ בדיוק על כך, מה שמרכך את הביקורת ומחדד בו-זמנית את המסקנה המעשית. בצעו ולידציה על נתונים שמייצגים את מקרה השימוש שלכם. קבעו ספים לפי העלות של הטעויות שלכם ולא לפי ברירת מחדל. תמיד כללו אפשרות הימנעות. סדרו באקראי את סדר האפשרויות במקרים שבהם הסדר עלול להטות את התשובה. השאירו אדם בתהליך בכל דבר בעל השלכות. זו עצה מוצקה לכל מדרג. זו העצה היחידה שזמינה עבורו.

מנסה את זה השבוע בלי להתחייב

ההערכה הזולה ביותר היא לבחור החלטה שאתם כבר מקבלים באופן ידני, להרכיב מאתיים מקרים מתויגים עם מערכי התשובות שהאפליקציה שלכם באמת תספק, ולהריץ אותם דרך פריסת Foundry. חשבו שגיאת כיול צפויה על הפלט ותדעו על Microsoft-Decision-1 יותר מכל מה שמיקרוסופט פרסמה עליו, מפני שתמדדו אותו על ההתפלגות שלכם ולא על מערך בדיקות פנימי שנשמר בצד. זו עבודה של אחר צהריים והיא מבטלת את כל שאלת הבנצ'מרק.

המקום שבו OrcaRouter משתלב הוא בחצי השני של לולאת ניקוד, והוא החצי שמייצר. אנחנו לא מארחים את Microsoft-Decision-1 והוא אינו בקטלוג שלנו — מודל שמחזיר הסתברויות במקום טקסט אינו משהו שאליו מנתבים השלמות צ׳אט, ואין לקרוא כאן דבר כטענת זמינות. מאחורי מפתח אחד תואם OpenAI שלנו נמצא המאגר של יותר מ-200 מודלים שעושה את הכתיבה: המודל שמנסח את מחוון ההערכה, השניים שמפיקים תשובות מועמדות, זה שפולט את קריאת הכלי Decision-1 ואז מדרג לפני שהיא רצה. מחיר המחירון של הספק מועבר הלאה במרווח של 0%, כך שהורדת מחיר בצד המחולל פעילה אצלנו באותו יום, ומעבר אוטומטי לגיבוי שומר על רגל הייצור חיה כשספק בודד נפגע — מה שחשוב יותר בצינור שמנקד כל מה שהוא רואה מאשר באחד שעונה למשתמש מדי פעם. אם אתם מעדיפים לא לבחור שופט יחיד, ה-DSL לניתוב מרכיב כמה מודלים לקריאה אחת, ומיזוג מודלים מדווח על ההסכמה ביניהם כשדה מנוקד ולא כפרוזה שאתם צריכים לקרוא.

מה שישנה את המאמר הזה הוא טבלה. פרסמו את ציוני Brier ואת ה-ECE, או תנו להרצה בלתי תלויה לנחות על לוח תוצאות, וההערכה שלמעלה תהפוך לאישוש במקום להיות הראיה היחידה שקיימת. עד אז, התיאור המדויק של Microsoft-Decision-1 הוא צר: המשקלים אמיתיים, החוזה מתועד טוב יותר מכפי שרוב המהדורות המתארחות מצליחות לעשות, אפשרות ההימנעות מתוכננת מראש ולא הולחמה בדיעבד, וטענת הביצועים היא משפט — אחד כתוב היטב, בלי שום מספרים בכלל.

שורה תחתונה

Microsoft-Decision-1 הגיע לזמינות כללית ב-Microsoft Foundry ב-8 באוקטובר 2026 כמערכת לניקוד החלטות טקסטואלית בלבד, בת 32,768 טוקנים, הבנויה על Qwen3.5-9B, המחזירה הסתברויות מכוילות על פני מערכי האפשרויות שלך עם אפס טוקני פלט וללא משקלים להורדה. החוזקות שלה הן חוזה חד-מעברי נקי, נתיב הימנעות מובנה מראש, ו-Azure, חיוב מחוברים; החולשה שלה היא שלאיש מחוץ ל-Microsoft אין מספר מפורסם למידת הכיול שלה, כולל Microsoft. התייחס להשקה כאל API שנעשה זמין, לא כאל יכולת שמתבססת, והעבר דרכו את המקרים המתויגים שלך לפני שמשהו במורד הזרם יהיה תלוי בסף.