איך עושים ניתוב ו-guardrails ל-LLM? דוגמה לשיתוף פעולה בין Jev למודלי שפה גדולים

גילוי אינטרסים וראיות: PandaNpc מפתחת שכבת החלטות ל-Agent שמשתמשת ב-Jev. להלן אנו מצטטים בנפרד מתיעוד רשמי של TypeSafe, מ-cookbook רשמי, ומקריאות Jev אמיתיות וכיולים של תרחישים סינתטיים במאגר שלנו. הכיול שלנו משתמש ב-LLM provider מדומה מבוסס תסריט, ואינו יכול לייצג תעבורת משתמשים אמיתית או ביצועי נתיב ייצור מלא.

ניתוב LLM יכול להיעשות כך: קודם נותנים ל-Jev לקבוע לאיזו קטגוריה שייכת הבקשה ומהי רמת הסיכון, ואז הקוד מחליט אם להעביר אותה לפונקציה רגילה, ל-LLM מתמחה, או לבדיקה אנושית. אפשר גם למקם את Jev בין שליפה ליצירה כדי לסנן ראיות, או אחרי פלט ה-LLM כדי לבדוק תוצאות. הוא מחזיר אפשרויות סגורות, ציונים והסתברויות; תשובות פתוחות, יצירת קוד והיסק ארוך עדיין מבוצעים על ידי LLM. ההסבר של TypeSafe על coding agents מבהיר במפורש ש-Jev אינו יכול להחליף ישירות את מודל הצ'אט שמאחורי Claude Code או Codex.

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

מה Jev יכול לשפוט, ומה נשאר באחריות ה-LLM?

נכון ל-23 בספטמבר 2026, עמוד המודלים של TypeSafe מפרט את המודל היציב jev-1.13.0. ה-API מקבל state אחד וקבוצת questions, ומחזיר דרך POST /v1/systemone answers מובנים בהתאמה. jev-latest הצביע באותו יום על 1.13.0, אך כינויים משתנים עם גרסאות; מערכת שכיילה ספים צריכה להצמיד גרסה ולתעד את מזהה המודל בפועל מהתגובה.

ל-Noul אין שדה confidence נפרד; אין לכתוב הסתברות Noul ישירות כ"ביטחון המודל". גם אין להשתמש ב-Score כדי לחשב סכום מדויק. סכומים, השוואות תאריכים, מכסות ובדיקות הרשאה צריכים להישאר בתוכנית דטרמיניסטית; בתיעוד הרשמי מפורטים הגבולות האלה של Jev 1.13.

הצורה המינימלית של קריאה אחת

צורת הבקשה שלהלן תואמת לעיון ה-API הרשמי; שאלות הדוגמה הן תצורה המחשה שנבנתה למאמר זה, ולא בוצע עבורה כאן מבחן מקוון:

ה-JSON שלהלן משתמש בהודעת לקוח באנגלית; בעברית הלקוח היה אומר “בוצע חיוב כפול על ההזמנה, בבקשה עזרו לי לקבל החזר.”

{
  "model": "jev-1.13.0",
  "state": {
    "message": "My order was charged twice. Please help me get a refund.",
    "account_note": "Customer asks about an order charge"
  },
  "questions": {
    "intent": {
      "type": "choice",
      "instructions": "What does state.message primarily request?",
      "criteria": {
        "refund": "Money returned for a charge",
        "information": "An explanation only",
        "other": "Neither option fits"
      }
    },
    "asks_refund": {
      "type": "noul",
      "instructions": "Does state.message explicitly ask for money back?"
    }
  }
}

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

שימוש ב-Jev לניתוב LLM: שלושה מסלולי מסירה

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

בעת יישום אפשר לעצב לפי הסדר הבא, במקום לתת למודל להחליט בחופשיות על כל הפעולות:

1. להגדיר קודם מסלולים: לפרט אילו בקשות יכולות להיות מטופלות על ידי פונקציות רגילות, כל אחד מה-LLM המתמחים, ובדיקה אנושית, ולהשאיר ל-Choice אפשרות other או חלופת גיבוי דומה.
2. להכניס עובדות ל-state: דברי המשתמש, מצב החשבון ורשומות ההזמנה כשדות נפרדים; אין להתייחס לטקסט מאתר לא ידוע כמעט הוראות מערכת.
3. לשאול שאלות צרות בכל פעם: כוונה עם Choice, סיכון או דחיפות עם Score, ועובדה נקודתית שצריך לאשר עם Noul. בתיעוד הרשמי מומלץ להעריך במקביל באותה בקשה כמה שאלות בלתי תלויות שחולקות state.
4. לתת לקוד לבצע ניתוב סופי: קודם לבדוק הרשאות וחוקים קשיחים, ואז להסתכל על ההסתברויות של Jev ועל ספים שכויילו לעסק הזה; בקשות בביטחון נמוך או בלי ראיות עוברות לאדם או לשאלת השלמה.
5. לתעד תוצאות ולחזור ולבדוק: לשמור גרסת מודל, גרסת שאלות, הסתברויות, יעד סופי ותוצאות תיקון אנושי, כדי לדעת אם הספים מתאימים.

מקור התמונה: TypeSafe AI, "Introducing System One Models & Jev", 2026-09-15. ארבעת ה-workflows נבנו על ידי TypeSafe, והמדדים מסוכמים במשקל שווה לפי workflow; שיטת ההערכה מופיעה ב-TypeSafe workflow evals.

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

יצירה מוגברת באמצעות שליפה (RAG): Jev מסנן ראיות לפני תשובת LLM

ה-RAG passage cookbook של TypeSafe מספק דוגמה קונקרטית יותר עם כמה מודלים: OpenAI embedding שולף תחילה פסקאות, ו-Jev שואל עבור כל "שאלה + פסקה" ארבעה Noul — האם רלוונטי, האם מכיל ראיה שאפשר להשתמש בה לתשובה, האם סותר את ההנחה שבשאלה, והאם מנסה לתת הוראות למודל המשיב. הקוד מטפל בארבע ההסתברויות לפי סדר, ומחליט אם להכניס את הפסקה לאזור הראיות, לאזור הראיות הסותרות, או לזרוק אותה; לבסוף Claude Sonnet 5 כותב את התשובה.

השלב הזה פותר בעיה נפוצה: פסקה עם דמיון וקטורי גבוה אינה בהכרח שמישה. ייתכן שהיא משתמשת רק במילים דומות, וייתכן שהיא פוסט בפורום שמכיל prompt injection מסוג "התעלם מההקשר הקודם". הדוגמה ב-cookbook שמה את בדיקת ה-injection בראש כללי הניתוב, ובמקביל מזכירה שהספים הם נקודת פתיחה שנבחרה עבור אותו קורפוס, ולא ברירת מחדל לכל יישום RAG. מספרי ההדגמה שלה מגיעים מ-jev-1.12 מתאריך 2026-08-27, ואין להתייחס אליהם כתוצאות הערכה חדשות של jev-1.13.0 הנוכחי.

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

הכיול של ה-Agent שלנו: היכן הסלמה בביטחון נמוך נתקעת?

במאגר של PandaNpc, לקוח Jev, מאגר השאלות והמתזמר משתמשים ב-Jev לזיהוי כוונה של Agent, ניקוד שינויי מועמדים, בדיקת תנאי סיום והחלטות הגשה. הלקוח גם מבצע ניסיונות חוזרים מוגבלים על timeout, 429 ו-5xx, ומגביל תקציב בקשות ותוצאות שפג תוקפן; הרשאות ביצוע נמצאות בידי המתזמר ושכבת הכלים המבוקרת, ולא ניתנות ישירות על ידי שיפוט בודד של Jev.

ב-2026-09-22 הרצנו עם jev-1.13.0 19 turn-ים סינתטיים, כל אחד פעם אחת ב-shadow ופעם אחת ב-enforce, בסך הכול 38 ריצות, ותעדנו 165 החלטות Jev אמיתיות. דוח הכיול הפנימי הזה והתגובות שנשמרו מהמכונה משתמשים ב-LLM provider מדומה מבוסס תסריט, ולכן הנתונים האלה מתארים רק ביצועי החלטה בתרחישים מבוקרים. הם אינם יכולים להוכיח שיעור הצלחה כולל, שיעור חיסכון או השהיה מקצה לקצה בבקשות משתמשים אמיתיות.

הממצא בעל הערך הרב ביותר אינו מהירות ממוצעת, אלא סף ש"נראה בטוח" שגרם לחסימה: מתוך 19 ה-turn-ים ב-enforce, 13 הוסלמו ב-Q2 "האם יש מספיק מידע כדי להתחיל שינוי", מפני שההסתברות של Noul נפלה לתוך טווח אי-הוודאות המקורי 0.15–0.85; ל-LLM Worker לא הייתה הזדמנות לבצע את השלבים הבאים. רשומות הכיול מראות שמתוך 34 החלטות Q2 שסומנו כבעלות מידע מספיק, רבות מההסתברויות היו באמצע הטווח. הדוח ממליץ לפצל את Q2 המורכב לשיפוטים אטומיים יותר, או להתאים את כללי ההסלמה; אלה המלצות, לא ספים שכבר הוטמעו.

מאגר השאלות שלנו מסווג את הכניסה כ-answer_only, inspect, modify או out_of_scope; בנתיב הכתיבה, שינויי המועמדים שהציע ה-Worker ממוינים תחילה על ידי Score, והתוכן הסופי ותקציר השינויים עוברים בדיקת קבלה והחלטת הגשה. אלה רק נקודות החלטה: האם ניתן בפועל לקרוא או לכתוב לאובייקט עדיין נקבע על ידי מבצע מבוקר שמעניק הרשאות לפי שלב. ל-Jev אין סמכות להרחיב בעצמו את רשימת הכלים המותרים, והוא גם לא יכול לעקוף בדיקת עקביות לפני הגשה.

נתוני הכיול חושפים פשרה נוספת. במצב shadow, Jev נותן תשובה והתפלגות מלאה, אך אינו משנה את נתיב הביצוע המקורי של ה-Worker; במצב enforce, התשובה משפיעה על האם להמשיך, להסלים או לזרוק. להתייחס לדיוק ב-shadow כאליעור ההשלמה ב-enforce זה לקרוא את המערכת לא נכון: הסלמה ב-Q2 עוצרת את המשימה מוקדם, כך שלניקוד מועמדים בהמשך, לקבלה ולשאלות ההגשה כלל אין הזדמנות להופיע. לכן הדוח קורא בנפרד את התפלגות כל שאלה, כיוון ההסלמה והמצב הסופי.

בשינויי מועמדים יש השוואה קונקרטית: באותו turn, מועמד ששינה את היעד במדויק קיבל ציון 2.94, ואילו מועמד שהחליף את הקובץ כולו קיבל 0.38; המועמד בעל הציון הגבוה נבחר. הדוגמה הזו רק מראה שבמצב הסינתטי הזה שאלת הניקוד הבדילה בין שתי הצעות. לעומת זאת, מועמד שהראיות שלו נחתכו קיבל 2.27, ואין להתעלם מהביטחון הנמוך ומסימון החיתוך רק מפני שהמספר נראה "בסדר". הקוד שלנו מסמן חוסר ראיות בנפרד, כדי למנוע מהמודל להסיק מסקנת כתיבה החלטית רק על סמך הקידומת שנשמרה.

אנחנו גם מפרידים בין "איזה מועמד לבחור" לבין "לאשר לו לכתוב" לשני שלבים שונים. אחרי שמועמד מקבל ציון מ-Jev, המבצע המבוקר פותח כלי כתיבה רק בשלב ACT/modify; כרטיס חד-פעמי שהונפק נקשר למזהה קריאת הכלי, למספר הגרסה הנוכחי, ל-hash של אובייקט היעד ולסיכום הפרמטרים. גם אם טקסט המועמד מנסה לשכנע את המודל "להתעלם מהמגבלות", הוא לא מקבל הרשאת כלי שעוברת את הבדיקות האלה. זו התובנה שלנו מאינטגרציה ברמת הקוד: שיפוט הסתברותי קובע איזה מסלול שווה ללכת בו, והרשאת תופעות לוואי נקבעת על ידי תנאי תוכנית שניתנים לבדיקה חוזרת.

גם נתיבי כשל צריכים תכנון. הלקוח מבצע ניסיונות חוזרים מוגבלים רק ב-timeout, שגיאת רשת, 429 או 5xx; תשובות לאחר ביטול או מעבר לזמן היעד של ה-turn נזרקות ישירות. אם Jev אינו זמין במצב enforce, אין להמשיך בלי הרשאת נפילה לאחור; כאשר מאושר לעבור ל-llm_only, המבצע נועל למצב קריאה בלבד. אם הענף כבר ביצע שינויים ואז איבד את Jev, המתזמר מסמן את כל הסבב ככישלון, במקום לתת ל-LLM הבא להשלים כתיבה בלי שכבת ההחלטות. לנתיבים האלה יש מחיר בחוויית המשתמש, אבל הם מונעים ממצב "המודל לא זמין זמנית" להפוך בשקט ל"הרשאות כתיבה נשארות כמו שהיו".

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

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

היכן צריך למקם guardrails ל-LLM?

ה-cookbook של TypeSafe ל-LLM guardrails ממקם את Jev בשני צידי הקלט והפלט של ה-LLM. הוא משתמש בקבוצת Noul כדי לזהות סיכונים שונים, ב-Score כדי למדוד חומרה, ואז הקוד מחליט לפי מדיניות אם לאשר, לבדוק בידי אדם, לחסום או להעביר לתמיכה. גם את הפלט יש לבדוק, כי קלט רגיל עדיין עשוי להניב תוצאת יצירה לא מתאימה.

גבולות ה-guardrails האלה גם ברורים: Jev יכול לבדוק תוכן לפי שאלות שנכתבו מראש, אבל אינו הוכחת בטיחות כוללת. מסמך המגבלות הרשמי מזכיר במפורש שתוכן זדוני עשוי להשפיע על השיפוט, ודורש לכתוב criteria בבירור ולבדוק גבולות. במדגם הסינתטי שלנו ביצענו 16 בדיקות injection שכוונו לפרמטרים של מועמדים, ותעדנו 0 היפוכי דירוג; המדגם קטן מדי, ואין להסיק ממנו ש"עמידות בפני prompt injection נפתרה". מה שקובע באמת מה כלים יכולים לעשות הם עדיין רשימת ההיתרים, שערי השלבים והבדיקות לפני הגשה בקוד.

מתי מתאים להשתמש, ומתי לא?

Jev מתאים כאשר: קבוצת המועמדים ידועה, אפשר לפצל את השאלה לכמה שיפוטים קצרים, והתוכנה זקוקה להסתברות כדי להחליט על טיפול אוט או הסלמה לאדם. לדוגמה ניתוב שירות לקוחות, סינון פסקאות RAG, ניקוד פעולות מועות של Agent ובדיקת ציטוטים בתוצרי יצירה. אם המשימה דורשת כתיבת מכתב תשובה, שינוי קטע קוד או הסבר של תהליך היסק מורכב, ה-LLM מקבל את המושכות. אם המשימה היא חישוב מדויק של כסף, השוואת תאריכים או בדיקת בקרת גישה, התוכנית צריכה לחשב ישירות. עמוד המודלים גם מסביר ש-Jev מקבל רק טקסט, ושאנגלית היא שפת האימון בעלת הביצועים הטובים ביותר כרגע; תרחישים בסינית דורשים הערכה עם נתונים משלך, ואין להעתיק את הספים של cookbook באנגלית.

אם רוצים לראות איך Agent אמיתי מטפל בהרשאות ובקריאות לכלים, אפשר להתחיל מ-PandaNpc Agent; לגבי הגבולות ותרחישי השימוש של סוכני קידוד, אפשר לעיין גם ב-השוואה בין Claude Code ל-Codex.

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

שאלות נפוצות (FAQ)

האם Jev יכול להחליף את Claude Code, Codex או מודל צ'אט? לא. TypeSafe מציבה אותו כמודל החלטות מובנה בתוך תוכנה; צ'אט, כתיבה ויצירת קוד עדיין דורשים LLM.

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

כמה שאלות אפשר לשאול באותה בקשה? אפשר לשים בבקשה אחת כמה Choice, Score ו-Noul בלתי תלויים שחולקים אותו state. כל שאלה מוערכת בנפרד, ושיפוטים מורכבים עדיין צריכים להיות מפוצלים ואז משולבים בקוד.

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