שני סוכני AI יכולים לערוך את אותו קובץ, שניהם מקבלים אישור "success", ובכל זאת רק שינוי אחד שלהם נשמר. בבדיקה פשוטה עם חמישה סוכנים מקביליים, ארבע מתוך חמש הכתיבות נעלמו ללא כל שגיאה או רישום בלוג — אנומלית "lost-update" קלאסית שגורמת לבזבוז הטוקנים ששולמו עבור העבודה שנעלמה.
למה הבעיה הזו חשובה
כאשר סוכן AI כותב תוצאה חזרה, השירות שבבסיסו מחייב לפי כל טוקן שנוצר. אם הכתיבה נדרסת בשקט, הספק עדיין מחייב על החישוב שהפיק את הפלט שנזרק. בצינורות עבודה (pipelines) מרובי-סוכנים — נחילי סוכנים (agent swarms), עובדי ניקוי נתונים מקביליים, או כל מערכת שבה מספר בוטים חולקים קובץ תוכנית או דף עבודה (scratchpad) — הפסדים נסתרים אלו עלולים להפוך לדליפת עלויות משמעותית. האנומליה גם מאיימת על שלמות הנתונים (data integrity): שלבים הבאים (downstream) עלולים לפעול על סמך מידע חלקי או מיושן, מה שמוביל לשגיאות שרשרת.
איך האנומליה מתרחשת
הגורם השורשי הוא race condition (מרוץ תהליכים):
- שני (או יותר) סוכנים קוראים את אותה גרסה של משאב, למשל קובץ תוכנית JSON.
- כל אחד מבצע הסקה (reasoning) או טרנספורמציה משלו על סמך ה-snapshot הזה.
- שני הסוכנים מבצעים פעולת כתיבה חזרה לאחסון המשותף.
- מערכת האחסון מקבלת את הכתיבה השנייה, ודורסת את הראשונה ללא כל זיהוי קונפליקט.
- שני הסוכנים מקבלים "ACK" המאשר שהכתיבה הצליחה, למרות שהתרומה הראשונה נעלמה.
האישור של מערכת האחסון מוכיח רק שבוצעה כתיבה; הוא אינו מבטיח שהכתיבה הייתה בטוחה ביחס לעדכונים מקבילים אחרים. לוג מסוג append-only, שלעיתים קרובות מוצג כפתרון הגנה, מתנהג באותו אופן: הוא מתעד שבוצעה כתיבה, אך אינו מונע מכתיבות מאוחרות יותר לדרוס קודמות.
מה עושה שער compare-and-set
שער compare-and-set (CAS) מוסיף בדיקת גרסה לפני שהכתיבה מתקבלת:
- קריאה (Read): הסוכן שולף את מספר הגרסה הנוכחי (או hash) של הקובץ.
- חישוב (Compute): הסוכן מבצע את עבודתו ומייצר גרסה חדשה של הקובץ.
- כתיבה (Write): הסוכן שולח את התוכן החדש יחד עם הגרסה שהוא קרא במקור.
- אימות (Validate): שכבת האחסון משווה את הגרסה שסופקה לגרסה הנוכחית. אם הן שונות, הכתיבה נדחית; אחרת, היא ממשיכה ומעלה את מספר הגרסה.
אם הגרסה השתנתה, הסוכן יודע שהתצוגה שלו הייתה מיושנת (stale) ועליו לנסות שוב את כל המחזור — קריאה, חישוב, כתיבה — באמצעות הגרסה החדשה. זה הופך דריסה בלתי נראית לכשל מפורש שניתן לתעד בלוג, לנסות שוב ולחשב בהתאם.
המחיר של בטיחות
שער ה-CAS אינו בחינם. באותה סימולציה של חמישה סוכנים:
| תרחיש | ניסיונות כתיבה | תרומות מוצלחות | עלות טוקנים |
|---|---|---|---|
| ללא שער CAS | 5 | 1 | 5 יחידות |
| עם שער CAS | 5 | 5 (לאחר ניסיונות חוזרים) | 9 יחידות |
השער מוסיף מחזורי קריאה-חישוב-כתיבה נוספים עבור סוכנים שנתקלים בקונפליקט גרסאות, מה שמעלה את צריכת הטוקנים. הטרייד-אוף (trade-off) ברור: ללא השער אתם מאבדים נתונים בשקט; עם השער אתם משלמים פרמיה מתונה אך מקבלים נראות לכל קונפליקט.
עד כמה השגיאה נפוצה?
אפילו עם שני סוכנים בלבד, הבדיקה הראתה סיכוי של 75% שאחת הכתיבות תאבד. עם חמישה סוכנים, שיעור האובדן התקרב ל-100%. מספרים אלו מרמזים כי ההנחה ש"בדרך כלל הכל בסדר" היא מסוכנת עבור כל תהליך עבודה (workflow) מרובה-סוכנים ברמת ייצור (production).
טיעון נגד: מתי לדלג על השער
אם מערכת מריצה סוכן בודד לכל משאב או אוכפת סדר (serialization) קשיח ברמה גבוהה יותר, בדיקות ה-CAS הנוספות עשויות להיות מיותרות. עם זאת, חישוב הסיכון חייב לכלול את העלות הנסתרת של הרצת העבודה שנכשלה מחדש ואת ההשפעה הפוטנציאלית על השלבים הבאים עקב נתונים חסרים.
מה כדאי לעקוב אחריו בהמשך
- תמיכה בכלי עבודה (Tooling): חפשו ממשקי API לאחסון שחושפים מספרי גרסה או ETags ומספקים פעולות CAS אטומיות (atomic) מובנות.
- מדדים (Metrics): הטמיעו כלי מדידה (instrument) בסוכנים שלכם כדי לתעד באיזו תדירות כתיבה נדחית עקב חוסר התאמה בגרסה. קצב קונפליקטים עולה מאותת על הצורך להגדיל משאבים או לעצב מחדש את תהליך העבודה.
- אסטרטגיות ניסיון חוזר (Retry): מנגנון back-off אקספוננציאלי פשוט עובד היטב, אך היו מודעים לכך שניסיונות חוזרים ונשנים מגדילים את צריכת הטוקנים. איזנו בין מגבלות ניסיון חוזר לבין אובדן נתונים מקובל.
- גישות היברידיות: חלק מהצוותים משלבים לוג מסוג append-only לצורך יכולת ביקורת (auditability) עם שער CAS לצורך עקביות (consistency), מה שמבטיח הן תיעוד של מה שקרה והן הגנה מפני דריסות.
שורה תחתונה
אנומליות של עדכון אבוד (lost-update) הופכות צינורות AI מבוססי טוקנים לחורים שחורים של דליפת כספים. שער גרסה מסוג compare-and-set מוסיף עומס (overhead) מתון של טוקנים, אך הופך אובדן נתונים שקט לאירוע גלוי וניתן לניסיון חוזר. בכל מערכת שבה סוכנים מרובים חולקים מצב (state) — מסדי נתונים, קובצי תוכנית או דפי טיוטה (scratchpads) — הטמעת בדיקת גרסה לפני כתיבות היא הביטוח הזול ביותר מפני עלויות נסתרות ותהליכי עבודה פגומים.