RLCD מוסבר: מדוע TypeSafe מאמן את Jev להיות כן לגבי ביטחון במקום להיות אהוד

Jev 1.13 (typesafe/jev-1.13) מאומן בשיטה שהיוצר שלו מכנה Reinforcement Learning for Calibrated Decisions — RLCD — וראשי התיבות הזה הוא חידוש של TypeSafe עצמה, ולא מונח תעשייתי שאמורים כבר להכיר. בפוסט ההשקה זה נאמר במפורש: החברה בנתה "ארכיטקטורת מודל חדשה, דוגם מקבילי ליעילות מרבית, ושיטת אימון שאנו מכנים Reinforcement Learning for Calibrated Decisions (RLCD)". זו תשובה שלישית לשאלה שהיו לה שתיים, והסיבה שהיא קיימת היא אי-התאמה שרוב הצוותים נתקלים בה בפעם הראשונה שהם מנסים להכניס מודל שפה לתוך החלטה. לפני שמגיעים לזה, שני תאריכים חשובים, מפני שהעמוד הזה אינו כתבת השקה. TypeSafe שחררה את המודל עצמו ב-2026-09-15, תאריך שנמצא מחוץ לחלון שבעת הימים שהבלוג הזה מסקר, ואין לקרוא כאן דבר כמיצוב של Jev כחדש. האירוע המתוארך הוא 2026-09-24, כאשר OrcaRouter הוסיפה את typesafe/jev-1.13 לקטלוג שלה ופתחה עבורו את כרטיס המודל — הפעם הראשונה שניתן לקרוא ל-Jev דרך שער של צד שלישי ולא רק דרך נקודת הקצה של TypeSafe עצמה. זה השינוי שהעמוד הזה נשען עליו, וההשלכה המעשית היא שהטכניקה שלהלן היא כעת משהו שאפשר לנסות בקוד עם מפתח שאולי כבר נמצא בידיכם, ולא רעיון מחקרי שקראתם עליו.

מה שלהלן הוא הקונספט, לא המודל. השליש הראשון של העמוד הזה עוסק בשתי שיטות האימון ש-RLCD תוכנן כנגדן, מפני ש-RLCD מובן רק כתיקון למה ששתי אלו עושות כשהמשימה מפסיקה להיות שיחה והופכת לשיפוט. אם אתם כבר יודעים למה RLHF ו-RLVR מטבות, הקטע שאתם רוצים הוא השלישי, שבו הטבלה התלת-כיוונית של TypeSafe עצמה עושה את העבודה.

RLHF עושה אופטימיזציה לתשובה שאדם מעדיף

למידת חיזוק ממשוב אנושי היא השיטה שהפכה מודלים לשוניים מאומנים מראש לעוזרים. הפריימר של TypeSafe עצמה מציג את המטרה בצורה יבשה, בכרטיס שכותרתו RLHF: היא "הפכה מודלים מאומנים מראש לצ'אטבוטים. היא מאמנת מודלים להפיק תגובות שאנשים מעדיפים." InstructGPT ו-ChatGPT אומנו באמצעותה, והפריימר מוסיף פרט שרלוונטי כאן מסיבה אחרת — הגישה הומצאה במשותף על ידי דיוגו אלמיידה, שהוא ממייסדי TypeSafe ומחבר פוסט ההשקה של Jev. החברה אינה דוחה את השיטה: היא נוסדה על ידי מישהו שעזר לבנות אותה. היא טוענת שהמטרה שגויה למשימה מסוימת.

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

מצבי הכשל ש-TypeSafe מנה בפריימר נובעים ישירות מכך:

• חנופה — המודל לומד לייצר את מה שהמדרג רוצה לשמוע, וזו מטרה שונה ממה שנכון.

- הזיה שנשמעת בטוחה — שטף ודאות מתוגמלים על ידי העדפה גם כשהם לא נשענים על דבר.

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

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

RLVR מבצע אופטימיזציה עבור פלטים שתוכנית יכולה לבדוק — ולהחלטות יש אחד כזה לעיתים רחוקות

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

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

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

מה RLCD עושה, במסגור של TypeSafe עצמה

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

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

• מה שהוא מייעל עבורו — RLHF מייעל העדפה אנושית, "כתבים ותגובות צ'אט שמדרגים אנושיים מעדיפים"; RLVR מייעל "פלטים שניתנים לאימות פרוגרמטי"; RLCD מייעל כיול, "תשובות עם הסתברויות כנות מבחינה אפיסטמית במשימות System One."

• מה נכנס — השניים הוותיקים יותר מקבלים נתונים לא מובנים "בדגש על הודעות עוקבות"; מודל החלטות מכויל מקבל נתונים לא מובנים "בדגש על מצב תוכנית מובנה".

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

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

• מה זה עולה — אסימוני קלט מ־$0.20 עד $10 למיליון עבור מודלי ההשוואה, כשהפלט הוא בערך פי חמישה ממחיר הקלט, לעומת $0.042 למיליון אסימוני קלט כשהפלט מחויב באפס אצל Jev.

• כמה מהר הוא עונה — 3 עד 329 שניות מקצה לקצה עבור מודלים חזיתיים לעומת 70 עד 500 מילישניות, שהספק מאפיין כמהיר פי 40 עד 200 בשאילתות בעלות צורה של System One.

• מה היא אומרת על הביטחון העצמי שלה — שני המודלים הוותיקים יותר "נוטים להיות בעלי ביטחון יתר ולא עקביים" אפילו כשמבקשים מהם הערכת ביטחון; RLCD "תמיד מתקשר ביטחון ואי-ודאות עם כל פלט," כאשר "ביטחון גבוה יותר פירושו דיוק גבוה יותר."

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

• תוצאות שהוקצתה להן הסתברות של 0.2 אמורות להתרחש בכ-20% מהמקרים.

• תוצאות שהוקצתה להן הסתברות של 0.8 אמורות להתרחש בכ-80% מהמקרים.

• תוצאות שהוקצתה להן הסתברות של 1.0 אמורות להתרחש ב-100% מהמקרים.

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

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

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

מדוע כיול הוא הדבר שהופך מודל החלטות זול לשמיש

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

• ביטחון גבוה — פעל אוטומטית. למודל יש תמונה ברורה ואתה יכול להמשיך ללא מעורבות אנושית.

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

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

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

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

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

המגבלה הכנה: מכויל אינו נכון

הדבר החשוב ביותר להבין נכון לגבי RLCD הוא מה ש-RLCD לא טוען. כיול הוא תכונה של רמות הביטחון, לא הבטחה לגבי התשובות, והספק אומר זאת בתיעוד שלו עצמו במקום להשאיר זאת למבקרים. העמוד של System One: "מודלים של System One מאומנים לקבלת החלטות מכוילות: ההסתברויות שלהם מותאמות כנגד תוצאות כדי לשקף אי-ודאות. כיול נמדד על פני קבוצות של תחזיות; הוא אינו מבטיח שתשובה בודדת נכונה." מודל יכול להיות מכויל באופן מושלם ועדיין לקבל החלטה שגויה לגבי הפנייה שלך, מפני ש-0.9 פירושו תשעה מתוך עשרה, וזה יכול להיות העשירי.

נתוני ההגשה שלנו עצמם הם משקל הנגד המועיל כאן, בדיוק משום שהם מדידות של המודל בסביבת ייצור ולא טענות לגבי מה שהשיטה משיגה. בשבעת הימים שהסתיימו ב-2026-09-30, על תעבורה דרך ה-playground של OrcaRouter מאז שהמודל נוסף לקטלוג, כרטיס Jev 1.13 מדווח על שיעור שגיאות של 0.49% על פני 76.2 מיליון טוקנים, לצד זמן p50 עד לטוקן הראשון של 151 מ״ש, p95 של 247 מ״ש, ובערך 349 טוקני פלט בשנייה. שני דברים לגבי המספר הזה ראויים להיאמר בבירור. הוא שלנו, לא של הספק, והוא חלון מתגלגל ולא מערכת בדיקה קבועה — אותו שדה הראה 0.57% מוקדם יותר בחלון, משום שהוא מחושב מחדש על פני שבעת הימים האחרונים של תעבורה חיה, והקריאות של אתמול יוצאות מהחלון. זה גם לא מדידת כיול. שיעור שגיאות אומר לך כמה פעמים משהו השתבש בתעבורה שלנו; הוא לא אומר לך אם ערכי הביטחון היו כנים, שזו שאלה אחרת, וכזו שדורשת נתונים מתויגים כדי להשיב עליה.

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

שתי מגבלות נוספות יש להזכיר באותה נשימה. הראשונה היא שאין כרטיס בנצ'מרק ציבורי לדגם הזה שמולו אפשר לבדוק משהו מכל זה — הספק לא פרסם כזה, ואף לוח דירוג של צד שלישי לא כולל את הדגם; עמוד הדגם ב-Artificial Analysis מחזיר 404 נכון ל-2026-09-30. לכן טיעון הכיול נשען על תיאור האימון, החוזה המתועד, וכל מה שאתם מודדים בעצמכם, ולא על עקומה מפורסמת. השנייה היא שהצהרות הביצועים של הספק הן שלו עצמו: פוסט ההשקה מציין בגלוי שהערכות תהליכי העבודה שמאחורי הכותרת של מהירות ועלות נבנו בידי צוות יכולות המודל שלו, שתשובות הייחוס שמולן מודדים אותן הן הממוצע של שני דגמים חיצוניים, ושהמספרים הם "בקצה הגבוה של הרווחים בעולם האמיתי." הוא גם אומר שאי אפשר להוכיח שהתמחור אינו מסובסד. שום דבר מזה לא מערער את שיטת האימון, שהיא טענה נפרדת מטענת המהירות, אבל זה כן אומר שהמקרה בעד RLCD הוא טיעון על עיצוב המטרה ולא תוצאה אמפירית מוגמרת. התייחסו לזה כאל השערה שאפשר לבדוק בזול, וזה מצב טוב יותר מזה שרוב טענות שיטות האימון מותירות אתכם בו.

מה אתה יכול לעשות עם זה היום

שני האיברים של הטיעון נפגשים במקום אחד. RLCD הוא הסיבה לכך שמידת הביטחון של מודל החלטה שווה הסתעפות; סף בקוד שלך הוא המקום שבו אותו ענף נמצא; והסלמה היא בהישג יד רק אם המסלול השכיח זול מספיק כדי לרוץ בכל מקום. Jev 1.13 ניתן לקרוא כ-typesafe/jev-1.13 ב-OrcaRouter — API אחד ל-200+ מודלים, 0% תוספת, מחיר המחירון של הספק מועבר הלאה כמו שהוא, כך שהורדת מחיר של ספק נכנסת לתוקף כאן באותו יום — מה שאומר שמסלול הרוב הבטוח ומסלול ההסלמה הגנרטיבי מחויבים על אותו מפתח במקום על שני חוזים נפרדים עם ספקים. אתה עדיין קורא לו בצורה משלו, POST /v1/systemone, ללא סטרימינג, מול חלון הקשר של 65,536 טוקנים, מפני שזה אינו נתיב ה-chat-completions של OpenAI וזה אינו מקופל לתוך נקודת הקצה של הצ'אט. שתי הערות מתוארכות מהפצות ה-SDK של הספק כדאי להכיר אם אתה מחבר את זה: גרסה 0.7.1, ששוחררה ב-2026-09-21, הוסיפה דוגמאות לשימוש עם שערי AI, וגרסה 0.7.2, ששוחררה ב-2026-09-26, הוסיפה תוסף http2 לחבילת ה-Python. השנייה היא מסוג הפרטים שמופיעים רק בהערות הפצה — כדאי שיהיה לקוח HTTP/2 כשמדובר במודל שכל הצעת הערך שלו היא סבבי הלוך-ושוב של פחות מ-200 מילישניות.

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

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