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

כל מי שמריץ סוכנים בפרודקשן מכיר את רגע החרדה שבו צריך להחליט אם לשחרר פלט קריטי ללקוח או לשלוח את המודל לסיבוב בדיקה נוסף. הפתרון המקובל הוא Self-Consistency: שולחים את אותה השאלה במספר דגימות מקבילות, משווים בין הנתיבים, ומשלמים על הכפלת כמות הטוקנים כדי לקבל רשת ביטחון סטטיסטית. במשימות מורכבות, חשבון ה־API תופח והשיהוי מזנק בהתאם. עכשיו מציעים חוקרים מאוניברסיטת Cambridge גישה אחרת במאמר שהוגש השבוע: במקום לנסות שוב ושוב את אותה פעולה בזמן אמת, המודל פשוט צריך לבדוק איך הוא תפקד בעבר במשימות דומות.

התשובה נמצאת בניסיון הקודם

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

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

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

שני שלבים במקום עשר קריאות

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

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

השוואה מול דגימה עצמית מרובה

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

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

העלות האמיתית של הזיכרון

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

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

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

ההחלטה שלכם לריצת המערכת הבאה

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

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