Jev נתן תשובה. מי מחליט אם לפעול לפיה?

בפרק הראשון הכרנו את Jev ואת שלושת סוגי השאלות שלו: Choice, Score ו־Noul. בפרק השני ראינו איפה הוא רץ: ב־Playground, בבקשת API אחת וכצעד בתהליך אוטומציה. עכשיו נשארת ההחלטה הקשה יותר: מה העסק מוכן לעשות על סמך התשובה שחוזרת.

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

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

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

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

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

השאלה היא Choice עם שלוש אפשרויות, ולכל אחת תיאור:

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

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

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

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

מה שהמודל לא מבטיח הוא עקביות חשבונית בין שאלות נפרדות. בדוגמה של TypeSafe, על פנייה של חיוב כפול, השאלה אם הלקוח מבקש החזר והשאלה ההפוכה קיבלו 0.72 ו־0.47, יחד 1.19. לכן לא מעבירים רף שכוון על Noul לשאלת Choice, ולא מניחים שתשובות לשאלות שונות מסתכמות לפי חוקי החשבון.

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

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

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

השם jev-latest הוא כינוי שזז כשיוצאת גרסה חדשה, ולכן התשובות מאחוריו יכולות להשתנות בלי שינוי בקוד. TypeSafe ממליצה לנעול את מזהה הגרסה, היום jev-1.13.0, ברגע שכוונו רפים מול גרסה מסוימת. את השדה model שחוזר בכל תשובה שומרים בלוג, ועוברים לגרסה חדשה רק אחרי שמריצים עליה שוב את קבוצת הבדיקה.

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

ב־Choice וב־Score, confidence נגזר מצורת ההתפלגות. לפי TypeSafe, כשכל ההסתברות נמצאת על אפשרות אחת הוא 1, וככל שהיא מתפזרת הוא יורד. בקירוב שהתיעוד נותן לשלוש אפשרויות, (3p − 1) / 2 כש־p היא ההסתברות הגבוהה, הסתברות של 0.58 נותנת confidence של כ־0.37. זה מדד לריכוז, לא הסתברות שהתשובה נכונה.

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

בין ״פועלים לבד״ לבין ״מעבירים לאדם״ יש אפשרות שלישית: להריץ את השאלה שוב על מודל גדול ויקר יותר. ב־AI Gateway של Vercel, שמגיש גם את Jev, אפשר להגדיר שזה יקרה אוטומטית כשה־confidence יורד מתחת לסף, ושני השלבים מחויבים. כשמודל שפה מחזיר את התשובה הסופית ל־Choice או ל־Score, confidence של 0 והסתברויות ריקות אומרים שהנתון לא זמין, לא שהביטחון אפס. קוד שמנתב לפי confidence חייב להבחין בין שני המקרים.

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

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

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

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

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

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

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

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

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