Jev: מדריך למודל החלטה שמכניס AI לתהליכים דטרמיניסטיים

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

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

זמן תגובה לפי TypeSafe

70-500 מילישניות

למיליון טוקני קלט

$0.042

דיוק בניסוי Banking77

81.1%

קטגוריות בניסוי העצמאי

77

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

מה Jev עושה אחרת

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

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

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

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

החיבור בין AI לתהליך דטרמיניסטי

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

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

לדוגמה, פנייה בנושא החזר כספי יכולה לעבור כך:

1. מערכת רגילה מאמתת את זהות הלקוח ואת פרטי העסקה.
2. Jev מסווג את כוונת הפנייה מתוך קטגוריות שהוגדרו מראש.
3. מנוע חוקים בודק סכום, תקופת זכאות ומדיניות.
4. החלטה בביטחון גבוה ממשיכה אוטומטית לפעולה מותרת.
5. החלטה גבולית או חריגה עוברת לתור אנושי עם כל ההקשר.

כך מתקבלת חלוקת עבודה נכונה: AI מפרש, קוד אוכף, ואדם מטפל במקרים שבהם שיקול הדעת שלו באמת נחוץ.

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

למה הסתברות מכוילת חשובה

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

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

כיול מאפשר להגדיר מדיניות תפעולית כגון:

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

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

בניסוי שפורסם ב-Towards Data Science, Jev הגיע לדיוק של 81.1% על 3,080 הודעות ממערך Banking77, לעומת 76.4% למודל Qwen שנבדק מולו. עם זאת, בטווחי ביטחון בינוניים נמצאה נטייה לביטחון יתר.

Jev81.1%

Qwen שנבדק76.4%

מקור: Towards Data Science, Banking77

גם בתוצאות שבהן Jev דיווח על ביטחון של 1.00, הדיוק שנמדד היה 97.1% ולא 100%. זהו נתון טוב, אך הוא ממחיש מדוע אסור לפרש הסתברות כהבטחה. כיול הוא מאפיין אמפירי שיש למדוד מחדש לאורך זמן, במיוחד לאחר שינוי בקטגוריות, באוכלוסיית הלקוחות או בניסוחי הקלט.

איפה כדאי להשתמש ב-Jev

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

שימושים אפשריים כוללים:

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

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

בארגונים שמפתחים סוכנים, זו הבחנה קריטית. הסוכן יכול להשתמש ב-Claude, במודל של OpenAI או במודל אחר לצורך ניתוח ופעולה. Jev יכול להשתלב בצומתי האישור, הסיווג והניתוב. מערכת ניהול התהליך, למשל n8n או Microsoft Copilot Studio, נשארת אחראית על הרצף, ההרשאות והתיעוד.

איפה Jev אינו הבחירה הנכונה

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

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

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

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

מדריך יישום בארגון

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

1. 01

   ממפים צומת החלטה

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

2. 02

   מגדירים סכמה

   מנסחים אפשרויות סגורות ומוסיפים מצבים של אחר, חסר מידע ועצירה.

3. 03

   בונים ערכת הערכה

   אוספים מקרים אמיתיים, חריגים ודוגמאות שבהן גם מומחים חלוקים.

4. 04

   מכיילים מדיניות

   קובעים ספים לפי עלות הטעות ולא לפי תחושת ביטחון כללית.

5. 05

   מחברים לתהליך

   מפרידים בין החלטת המודל, חוקי העסק והפעולות המותרות.

6. 06

   מנטרים ומשפרים

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

1. לבחור החלטה, לא תהליך שלם

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

2. לתכנן את הסכמה עם אנשי המקצוע

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

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

3. לבנות evals לפני אוטומציה

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

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

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

4. להפעיל אדם בלולאה באופן מדרגי

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

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

5. להפריד החלטה, הרשאה ופעולה

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

• המודל מציע ערך והסתברות.
• מנוע המדיניות מחליט אם מותר לפעול.
• מערכת הביצוע מפעילה פעולה מוגדרת ומתועדת.

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

def routeDecision(result, policy):
    if result["value"] == "unknown":
        return "requestMoreData"

    if result["probability"] < policy["humanThreshold"]:
        return "humanReview"

    if policy["riskLevel"] == "high":
        return "humanApproval"

    return policy["allowedAction"]

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

איך למדוד את הערך העסקי

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

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

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

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

מה Jev מלמד על עתיד מערכות ה-AI

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

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

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

ארגונים צריכים להתקדם בשני צירים במקביל. הציר הראשון הוא אוריינות AI ויכולת של עובדים לתקשר היטב עם מודלים. הציר השני הוא פיתוח תשתית פנימית להקמה, הערכה וניהול של סוכנים. כלים כגון Claude, Claude Code, Copilot, Copilot Studio ו-n8n יכולים להשתלב בשכבות שונות, אך אף מוצר אינו מחליף משילות, ידע מקצועי ותכנון תהליכים.

TypeSafe עשויה לבסס קטגוריה חדשה, או לגלות שיכולות דומות יתווספו במהירות למוצרים של Anthropic, OpenAI וספקים אחרים. לכן ההשקעה הנכונה לארגון אינה תלות עיוורת ב-Jev. ההשקעה היא ביכולת להגדיר החלטות, למדוד כיול, להחליף מודלים ולנהל תהליכי AI כמשאב תפעולי.

השורה התחתונה

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

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

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