איך מעדכנים ידע של סוכן AI בלי לשבור את העבודה
# איך מעדכנים ידע של סוכן AI בלי לשבור את העבודה
בשעה 09:12 נכנס לתוקף מחירון חדש. בשעה 09:20 סוכן AI מכין הצעה לפי המחיר החדש, אבל הלקוח קיבל אתמול הצעה שעדיין בתוקף. איזו גרסה נכונה?
התשובה אינה נמצאת בקובץ העדכני ביותר. היא תלויה בתאריך התחולה, בסוג העסקה, בהתחייבות שכבר ניתנה ובכלל שקובע אם שינוי חל על תהליך פתוח. עדכון ידע לסוכן AI הוא לכן שינוי תפעולי, לא החלפת מסמך בתיקייה.
זו התזה של המאמר: ידע חדש צריך להיכנס לסוכן כגרסה מנוהלת, עם בעלים, מועד תחולה, בדיקות ודרך חזרה. אם פשוט מחליפים את הקובץ הישן, מקבלים מערכת שיודעת יותר ובטוחה פחות.
## 09:12, המחירון החדש עולה לאוויר
ניקח עסק שמוכר שירותים בכמה מסלולים. המחירון החדש משנה את מחיר החבילה, את תוקף ההצעה ואת התנאי לקבלת הנחה. מנהלת המכירות מעלה קובץ מעודכן, ואיש התפעול מחליף את הקישור במאגר שהסוכן קורא.
על פניו, העבודה הסתיימה. בפועל, נפתחו כמה שאלות שלא מופיעות בקובץ:
* האם הצעות שנשלחו אתמול נשארות בתוקף?
* מה קורה לטיוטות שהוכנו לפני העדכון וטרם אושרו?
* האם עסקה קיימת ממשיכה לפי התנאים הישנים?
* מי מאשר חריגה ללקוח שקיבל התחייבות בעל פה?
אלה אינן שאלות על חיפוש מידע. אלה החלטות עסקיות. הסוכן יכול למצוא את המחיר החדש בדיוק מושלם ועדיין לבחור תשובה שגויה למקרה שנמצא באמצע הדרך.
המקרה הזה חושף הבדל שימושי: מסמך אומר מה כתוב עכשיו. מדיניות תחולה אומרת על אילו מקרים הכתוב חל. סוכן שעובד עם מסמכים בלי מדיניות תחולה עלול לערבב בין עדכני לבין נכון.
## הבעיה אינה מידע ישן, אלא שתי אמיתות תקפות
קל לחשוב שהמטרה היא למחוק גרסאות ישנות כדי שהסוכן לא יתבלבל. לפעמים זו דווקא הטעות.
מחירון קודם יכול להישאר תקף להצעות שנשלחו לפני תאריך מסוים. נוסח חוזה ישן עשוי לחול על לקוחות קיימים, בזמן שנוסח חדש מיועד למצטרפים. נוהל משלוחים מעודכן יכול להתחיל רק בתחילת השבוע הבא, אף שכבר אושר היום.
בכל המצבים האלה קיימות שתי גרסאות נכונות. הבחירה ביניהן תלויה בהקשר. לכן כל פריט ידע תפעולי צריך לקבל כמה שדות פשוטים: מזהה גרסה, בעלים, תאריך אישור, מועד תחולה, קהל או סוג מקרה, והגרסה שהוא מחליף.
הסוכן לא צריך לראות את כל היסטוריית החברה בכל ריצה. הוא כן צריך לקבל את הגרסה שמתאימה למקרה ואת הסיבה לבחירה. בהצעת מחיר, למשל, אפשר לקבוע שהגרסה נבחרת לפי מועד פתיחת העסקה או לפי מועד ההתחייבות האחרונה שנשלחה ללקוח. זה כלל שהעסק מחליט עליו. המערכת רק אוכפת אותו.
## 09:35, טיוטה ישנה פוגשת כלל חדש
כעת מנהל מכירות פותח טיוטה שהסוכן הכין בשעה 08:50. המחיר בה מבוסס על הגרסה הקודמת. האם צריך לעדכן אותה אוטומטית?
לא בהכרח. לפני כל החלפה צריך לסווג את מצב העבודה. טיוטה פנימית שלא נבדקה יכולה לעבור חישוב מחדש. הצעה שכבר אושרה ומחכה לשליחה דורשת אזהרה והחלטה. מסמך שכבר יצא ללקוח הוא רשומה היסטורית, לא טיוטה שמותר לשכתב.
כאן נדרש גבול בין ידע חי לבין תוצאה שנוצרה בעזרתו. ידע חי משתנה. הצעה שנשלחה, החלטה שאושרה או הודעה שנמסרה צריכות לשמור את גרסת המקור ששימשה בזמן הפעולה. אחרת אי אפשר להסביר אחר כך מדוע התקבל מחיר מסוים.
בפועל, כל תוצאה משמעותית שהסוכן יוצר צריכה לשאת קבלה קטנה: איזו גרסת ידע שימשה, מתי נקראה, ואיזה כלל תחולה הכריע. הקבלה אינה מיועדת ללקוח. היא נועדה לאדם שיצטרך לבדוק חריגה בעוד שבועיים, כשהזיכרון הארגוני כבר יהיה עסוק במשהו אחר.
## לפני ההחלפה מריצים את המקרים שלא מסתדרים יפה
בדיקה של מחיר אחד מתוך המחירון החדש אינה מספיקה. היא מוכיחה שהקובץ נגיש, לא שהשינוי בטוח.
ערכת בדיקה טובה נבנית סביב קווי התפר. במקרה שלנו כדאי להריץ עסקה חדשה, הצעה פתוחה מהיום הקודם, לקוח עם תנאי מיוחד, טיוטה שטרם אושרה ומקרה שבו חסר תאריך ההתחייבות. לכל מקרה כותבים מראש איזו גרסה אמורה להיבחר ומה הסוכן צריך לעשות אם אי אפשר להכריע.
הבדיקה החשובה ביותר היא דווקא האחרונה. כשחסר המידע שקובע תחולה, הסוכן לא אמור לבחור את הקובץ החדש מפני שהוא חדש. הוא צריך לעצור, לציין איזה פרט חסר ולהעביר את המקרה לבעל התהליך.
מסגרת ניהול הסיכונים של NIST ממליצה לבדוק מערכות AI לפני פריסה וגם במהלך ההפעלה, ולכלול בניטור מנגנונים לשינוי, התאוששות ועקיפה אנושית. לעסק קטן אין צורך להפוך את זה לפרויקט ציות. המשמעות המעשית פשוטה: שינוי במקור ידע שעשוי לשנות החלטה עובר בדיקה לפני שהוא משפיע על עבודה אמיתית.
## הפעלה מדורגת עדיפה על החלפה שקטה
אחרי שהבדיקות עברו, עדיין לא חייבים להפנות מיד את כל הפעילות לגרסה החדשה. אפשר להפעיל אותה תחילה במצב השוואה.
במצב הזה הסוכן ממשיך לעבוד לפי הגרסה הפעילה, ובמקביל מחשב מה היה עושה לפי הגרסה החדשה. הוא אינו שולח את התוצאה השנייה ואינו משנה רשומות. הוא רק מציג את הפערים. אם שתי הגרסאות נותנות אותה תשובה במקרים שבהם ציפינו לשינוי, ייתכן שהכלל החדש כלל לא נטען. אם הן שונות במקומות שלא אמורים להשתנות, מצאנו בעיה לפני שהגיעה ללקוח.
אין צורך להריץ השוואה על כל פעולה. בוחרים מדגם שמכסה מקרים רגילים וקווי תפר. בעל התהליך עובר על ההבדלים ומאשר שהשינוי מתנהג כפי שהתכוון, לא רק כפי שנכתב במסמך.
לאחר ההפעלה שומרים חלון מעקב ממוקד. בודקים בחירות גרסה, עצירות בגלל מידע חסר ותיקונים של אנשי הצוות. ניטור כזה שימושי יותר מספירת תשובות, מפני שהוא בודק את הנקודה שבה השינוי באמת יכול להזיק.
## חזרה לאחור צריכה לקחת דקות, לא ישיבת חירום
נניח שבשעה 11:10 מתברר שסעיף הנחה במחירון נוסח בצורה עמומה. חלק מהמקרים קיבלו פירוש שלא היה מקובל על מנהלת המכירות. עכשיו צריך לעצור את הגרסה החדשה.
אם העדכון בוצע באמצעות דריסה של הקובץ, מתחיל חיפוש: מי שמר עותק, אילו הצעות כבר הוכנו, ומה בדיוק השתנה. אם הגרסאות נשמרו בנפרד, אפשר להחזיר את הגרסה הקודמת כפעילה, לעצור מקרים שהושפעו ולתקן את הכלל לפני ניסיון נוסף.
חזרה לאחור אינה מוחקת את מה שכבר קרה. לכן רשימת הפעולות שהשתמשו בגרסה החדשה חשובה כמעט כמו כפתור החזרה. היא מאפשרת לבדוק טיוטות והצעות שנוצרו בחלון התקלה בלי לעבור על כל פעילות היום.
הכלל כאן חד: לא מפעילים שינוי שאין דרך לזהות את השפעתו ולבטל את המשך השימוש בו. מקור ידע ללא היסטוריית גרסאות הוא אולי נוח לעריכה, אבל אינו בסיס טוב לפעולה אוטונומית.
## מי רשאי לפרסם ידע לסוכן
תיקייה משותפת אינה מנגנון אישור. העובדה שעובד רשאי לערוך מסמך אינה אומרת שכל שמירה שלו צריכה לשנות מיד את החלטות הסוכן.
לכל תחום ידע צריך להיות בעלים עסקי. מנהלת מכירות יכולה להיות בעלת המחירון, מנהל תפעול בעל נוהל המשלוחים, ואחראית משאבי אנוש בעלת מדיניות החופשות. הבעלים מאשר תוכן ותחולה. אדם טכני יכול לבצע את החיבור, אבל לא להחליט איזו התחייבות תקפה.
כדאי להפריד בין עריכה, אישור ופרסום. בעסק קטן אותו אדם עשוי לבצע שני תפקידים, ועדיין חשוב שהפעולות יהיו מובחנות. טעות הקלדה שנשמרה באמצע עבודה אינה צריכה להפוך למדיניות חיה.
גם עדכון דחוף צריך מסלול. אפשר לקצר את הבדיקה, להגביל זמנית את סוגי הפעולות או להחזיר אישור אנושי לכל הצעה. דחיפות אינה סיבה לוותר על שליטה. היא סיבה לצמצם את שטח הפעולה עד שהמידע מתייצב.
## מבחן השינוי שאפשר לעשות לפני העדכון הבא
לפני שמפרסמים מקור ידע חדש לסוכן AI, צריך להיות אפשר לענות על השאלות הבאות:
1. מי אישר את הגרסה ומתי היא נכנסת לתוקף?
2. על אילו מקרים היא חלה, ואילו מקרים נשארים עם הגרסה הקודמת?
3. אילו תוצאות פתוחות צריך לחשב מחדש ואילו חייבות להישאר כפי שנוצרו?
4. אילו מקרי תפר עברו בדיקה?
5. כיצד מחזירים גרסה קודמת ומאתרים את הפעולות שהושפעו?
אם אחת התשובות חסרה, העדכון עדיין אינו מוכן להפעלה. אפשר לשמור אותו כטיוטה, להריץ השוואה או להעביר זמנית את המקרים הרגישים לאישור. מה שלא כדאי לעשות הוא לקוות שהסוכן יבין לבד את כוונת הכותב.
עסקים משקיעים הרבה בשאלה איזה מידע הסוכן יכול לקרוא. השאלה הבוגרת יותר היא כיצד המידע הזה משתנה בלי לערער עבודה שכבר מתבצעת. שם מתחילה מערכת שאפשר לתחזק, ולא הדגמה שחיה כל עוד איש אינו נוגע בקבצים.
אם אתם עומדים לעדכן מחירון, נוהל או מדיניות שסוכן AI כבר משתמש בהם, הביאו לפגישת [גילוי אוטומציה](/automation-discovery) את הגרסה הנוכחית, הגרסה החדשה ושלושה מקרים שנמצאים כרגע בתהליך. ב־AI BUDDY נמפה את כללי התחולה, הבדיקות ודרך החזרה לפני שהעדכון נכנס לעבודה.
### מקורות
* [מסגרת NIST לניהול סיכוני AI](https://airc.nist.gov/airmf-resources/airmf/5-sec-core/)
* [מדריך NIST לניהול שינויים והתאוששות](https://airc.nist.gov/airmf-resources/playbook/manage/)
* [מחקר NIST על ניטור מערכות AI פעילות](https://www.nist.gov/publications/challenges-monitoring-deployed-ai-systems-center-ai-standards-and-innovation)