מנהל מבקש מסוכן AI להסביר מדוע פרויקט מתעכב. השאלה קצרה, וגם התשובה מגיעה מהר: הספק לא עמד בלוחות הזמנים, כמה משימות עדיין פתוחות, ונדרש עדכון של תוכנית העבודה. יש אפילו קישורים למקורות. אלא שעיון בהם מגלה בעיה: מועד המסירה נלקח מחוזה שכבר תוקן, המשימות הפתוחות שייכות בחלקן לשלב הבא, והסיכום שמייחס את העיכוב לספק נכתב לפני שאושרה הרחבת התכולה.
זו דוגמה מומצאת, אבל היא מחדדת שאלה הנדסית ממשית. ייתכן שהמודל קרא היטב כל פסקה שקיבל. ייתכן גם שהחיפוש מצא מסמכים שעוסקים בדיוק בפרויקט הנכון. ובכל זאת, התשובה אינה מתארת את מצב הפרויקט. כדי להבין מדוע, צריך לבחון איך נבנתה תמונת המצב שהוצגה למודל.
במאמר הזה אני מציע להתייחס להקשר כאל רכיב שיש לתכנן בארכיטקטורה: לקבוע איך בונים אותו, אילו כללים הוא חייב לקיים ואיך בודקים אותו. ההחלטות האלה משפיעות על התשובה עוד לפני שהמודל מתחיל לנסח אותה.
מה באמת מגיע למודל
כשמחברים מודל למערכות הארגון, המידע שלהן אינו הופך אוטומטית לידע פנימי שלו. בכל קריאה הוא מקבל קלט מסוים: הוראות, השאלה, חלק מהשיחה, מסמכים שנשלפו ותוצאות של כלים. בסוכן שפועל בכמה שלבים, הקלט הזה משתנה בין קריאה לקריאה. ההבחנה הזאת עומדת גם בבסיס ההסבר של Anthropic על הנדסת הקשר.
מכאן נובעת אחריות תכנונית. מישהו צריך להחליט איזה פרויקט התכוון המשתמש לבדוק, מהו המועד שאליו מתייחסת הבדיקה, אילו מערכות מחזיקות את הנתונים הדרושים, ומה יקרה אם אחת מהן אינה זמינה. גם החלטה להכניס לשיחה את עשר תוצאות החיפוש הראשונות היא מדיניות. היא פשוט משאירה למנגנון הדירוג להכריע מה ייחשב לתמונת המציאות.
בשאלה שלנו מסתתרות למעשה שתי משימות: לקבוע אם הפרויקט צפוי לחרוג מהתחייבות תקפה, ולהסביר את הגורמים לחריגה. הראשונה מחייבת תאריכים והגדרות מדויקות. השנייה מחייבת ראיות לקשר בין אירועים. ערבוב ביניהן מאפשר למערכת לכתוב הסבר משכנע עוד לפני שהוכיחה שיש עיכוב.
לפני שמחפשים הסבר, צריך לקבוע ביחס למה
נניח שבדוגמה שלנו החוזה המקורי קבע מסירה ל־15 באוקטובר. תיקון מאושר, שנכנס לתוקף ב־12 באוקטובר, העביר את המסירה ל־5 בנובמבר. במערכת המשימות עדיין מופיע התאריך המקורי. הודעת הספק מ־20 באוקטובר מעריכה שהמסירה תהיה ב־12 בנובמבר. אנחנו בודקים את המצב ב־2 בנובמבר.
התשובה המדויקת היא שקיימת תחזית לחריגה של שבעה ימים מהמועד המאושר, בהנחה שזו התחזית העדכנית ושלא אושר שינוי נוסף. עדיין אין איחור בפועל ביחס למועד החדש. הפער של 28 ימים מהמועד המקורי הוא נתון אחר, שיכול להיות רלוונטי לדיון בביצועי הפרויקט, אבל אינו תחליף להשוואה להתחייבות הנוכחית.
כדי להגיע לתוצאה הזאת, לא מספיק למיין מסמכים מהחדש לישן. מועד העלאת הקובץ, מועד כתיבתו ומועד כניסתו לתוקף עשויים להיות שונים. טיוטה שהועלתה אתמול אינה גוברת בהכרח על תיקון שאושר לפני שלושה שבועות. גם המילה "מאושר" בשם הקובץ אינה הוכחה לאישור. המערכת זקוקה לרישום מוסמך של מעמד המסמך, או שהיא צריכה להשאיר את השאלה פתוחה.
הייתי מגדיר כאן כלל עסקי מפורש: את מועד ההתחייבות לוקחים מרישום השינויים המאושרים; את תחזית הביצוע לוקחים ממקור הדיווח שנבחר; ואת הפער מחשבים בקוד, אחרי שאומתו סוג התאריך ואבן הדרך. אם המקורות סותרים זה את זה ואין כלל שמכריע ביניהם, מחזירים את הסתירה. המודל יכול להסביר אותה, אבל אין סיבה שימציא בעצמו את סדר הסמכויות של הארגון.
לא כל מידע צריך לעבור דרך חיפוש סמנטי
חיפוש לפי משמעות שימושי כשאנחנו מחפשים דיון על שינוי דרישות או הסבר מילולי לתקלה. לצורך רשימת המשימות הפתוחות של פרויקט מסוים, הייתי מתחיל בשאילתה למערכת המשימות, עם מזהה פרויקט, אבן דרך ומועד עדכון. אין יתרון ברור בהמרת טבלה למסמכים ואז בבקשה ממנוע חיפוש לשחזר את השורות הרלוונטיות.
יש כאן הבדל בין סוגי עבודה. נתונים מובנים אפשר לסנן ולחשב. מסמכים צריך לאתר ולקרוא. החלטות מחייבות צריך לאמת מול מנגנון האישור שלהן. המודל יכול לסייע בניסוח השאילתה ובפירוש התוצאות, אבל ממשק הכלי צריך להגביל את הפרמטרים ולאמת אותם. חיבור לפי מזהה פרויקט יציב גם מונע מיזוג שגוי של שני פרויקטים בעלי שם דומה.
גם בתוך החיפוש במסמכים יש כמה אפשרויות. התאמה סמנטית עשויה למצוא ניסוחים שונים של אותו רעיון, בעוד חיפוש מילולי מועיל למספר חוזה או לקוד תקלה. Anthropic מדגימה את ההשלמה ביניהם ואת הבעיה של קטעים שאיבדו את סביבתם ב־Contextual Retrieval. בדוגמה שלנו, משפט כמו "המועד נדחה בשבועיים" חסר משמעות מספקת בלי לדעת לאיזו אבן דרך הוא מתייחס והאם הוא מתאר הצעה או החלטה.
לכן הייתי מחזיר עם כל קטע גם מזהה מקור, גרסה, פרויקט וסעיף, ומאפשר פתיחה של החלק המלא במסמך כשנדרשת הבהרה. לתקציר שנוצר אוטומטית יכול להיות ערך באיתור החומר. כשהמסקנה תלויה במילה "בכפוף", צריך להגיע לנוסח המקורי. ציון רלוונטיות גבוה אינו מעיד שהמסמך מוסמך לקבוע את המועד.
מהתאריכים אל הסיבה
אחרי שחישבנו את החריגה הצפויה, עדיין לא ענינו מדוע היא מתרחשת. נניח ששלוש משימות באחריות הספק מסומנות כמאחרות. האם הן חוסמות את המסירה? אולי שתיים שייכות לשלב הבא, ולשלישית יש מרווח בתוכנית. כדי לקשור אותן לעיכוב צריך לבדוק את התלויות ואת השפעתן על אבן הדרך, ולא רק לספור משימות אדומות.
במקרה הזה הייתי מבקש מהכלי את שרשרת התלויות הרלוונטית, את השינויים בתוכנית ואת הדיווחים שמסבירים אותם. אם יש לוח זמנים אמין, חישוב השפעת התלויות צריך להיעשות בכלי תזמון מתאים. אם אין כזה, אין הצדקה להציג הערכת שפה כחישוב של הנתיב הקריטי.
גם אז צריך להבחין בין עובדה, הסבר של בעל עניין ומסקנה שלנו. "הספק דיווח שהבדיקות נדחו בגלל שינוי ממשק" היא טענה שניתן לייחס להודעה מסוימת. "שינוי הממשק גרם לכל העיכוב" היא מסקנה רחבה יותר. היא דורשת לבדוק מתי אושר השינוי, אם הבדיקות אכן היו תלויות בו ומה התרחש במקביל. תשובה רצינית יכולה לקבוע שיש תחזית לחריגה, להציג את הסבר הספק, ולציין שאין עדיין ראיות שמאפשרות לייחס לו את מלוא הפער.
ההבחנה הזאת צריכה להופיע גם במבנה התוצאה: מה ידוע, על איזה מקור כל קביעה נשענת, ומה עדיין אינו מוכרע. קישור בסוף פסקה לא מספיק אם הוא תומך רק בחצי ממנה.
הרשאות משנות גם את גבולות התשובה
ייתכן שלמשתמש יש גישה למערכת המשימות, אך אין לו גישה לתיקון החוזה. אסור לשלוח למודל את התיקון ואז להסתמך על הוראה שלא לחשוף אותו. בתכנון שאני מציע, בקרת הגישה פועלת לפני העברת התוכן למודל או לשירות עיבוד חיצוני. הזהות מגיעה מהיישום המאומת, ולא מפרמטר שהמודל רשאי לבחור.
התיעוד של Microsoft על סינון תוצאות לפי הרשאות ממחיש הבחנה חשובה: סינון לפי מזהה משתמש או קבוצה הוא מנגנון סינון; הוא אינו מאמת בפני עצמו שהמבקש אכן בעל הזהות הזאת. היישום אחראי לחיבור הנכון בין הזהות המאומתת לבין המסנן.
יש לכך גם משמעות עניינית. היעדר מסמך בתוצאות אינו מוכיח שלא התקבלה החלטה. אם אין למערכת בסיס נגיש לקביעת המועד המחייב, עליה להגביל את התשובה לנתונים שאפשר לבדוק, בלי להסגיר את עצם קיומו של חומר חסוי. גם מטמון של תשובות חייב לכבד את גבולות ההרשאה: תשובה שנבנתה עבור מנהל אחד אינה בהכרח מותרת להצגה לאחר.
אותה הפרדה נדרשת בין תוכן להוראות. הודעת ספק היא חומר לבדיקה, גם אם מופיע בה משפט שמבקש מהסוכן להתעלם ממסמך אחר או לשלוח דוח לכתובת מסוימת. עצם קריאת ההודעה אינה מעניקה סמכות לבצע פעולה. הרשאה לעדכון מערכת או למשלוח מידע צריכה להיבדק בנפרד.
כמה הקשר לשמור, ומה אסור לתקצר
אפשר להתחיל את הבדיקה עם כל מסמכי הפרויקט, אבל זו אינה תמיד בחירה טובה מבחינת זמן תגובה, עלות ויכולת לבדוק מה השפיע על התשובה. בדוגמה שלנו הייתי מתחיל במצב אבן הדרך, בהתחייבות התקפה ובתחזית העדכנית, ומרחיב את החיפוש כאשר מתגלה פער. צריך להגדיר מראש גם תנאי עצירה: אחרי כמה ניסיונות או כמה זמן מחזירים תשובה חלקית עם חוסר מוגדר.
אין כאן טענה שכל הקשר ארוך מזיק. בפרויקט קטן, קריאה של כמה מסמכים שלמים עשויה להיות פשוטה ואמינה יותר מפיצול, אינדוקס ושליפה בכמה שלבים. את הבחירה צריך לבחון על המשימה בפועל. עוד קריאה לכלי יכולה לשפר את הביסוס, אבל גם להוסיף השהיה ותלות בשירות נוסף.
כשסוכן שומר זיכרון בין בדיקות, הסיכון משתנה. תקציר כמו "הפרויקט מתעכב בגלל הספק" עלול ללוות אותו שבועות אחרי שהמצב השתנה. הייתי שומר את מועד הבדיקה, את הטענות ומקורותיהן, ובעיקר את ההסתייגויות. תחזית צריכה להישאר תחזית; החלטה מותנית צריכה להישאר מותנית. בבדיקה הבאה יש לרענן את הנתונים שעשויים להשתנות, ולא להתייחס לתשובת הסוכן מאתמול כמקור עצמאי.
איך בודקים שהארכיטקטורה עובדת
בדיקה של ניסוח התשובה לבדה מתקשה להראות היכן המערכת נכשלה. אם התיקון המאושר לא נשלף, הבעיה שונה ממצב שבו הוא נשלף והמודל התעלם ממנו. ואם שאילתת המשימות ערבבה שתי אבני דרך, החלפת המודל לא בהכרח תתקן את הנתונים שקיבל.
הייתי בונה אוסף מקרי בדיקה עם תשובות צפויות וראיות מסומנות. במקרה אחד יש חוזה ישן ותיקון תקף; באחר יש טיוטה חדשה שטרם אושרה; בשלישי חסר נתון שמונע הכרעה; וברביעי המשתמש אינו מורשה לראות חלק מהחומר. כדאי לכלול גם מקור זמין אך לא מעודכן, כלי שלא הגיב וטקסט שמנסה לתת לסוכן הוראות בתוך מסמך.
לכל מקרה מריצים שתי בדיקות עם אותו מודל ואותן הוראות. בראשונה נותנים למערכת לאסוף את החומר. בשנייה מספקים לה מראש את הראיות הנכונות והמותרות. אם הבדיקה השנייה מצליחה והראשונה נכשלת, יש סיבה לחקור את שליפת המידע והרכבתו. אם שתיהן נכשלות, בודקים את ההוראות, את אופן הצגת הראיות ואת יכולת המודל להסיק מהן. זו אינה הפרדה מושלמת, אבל היא מצמצמת את הניחוש.
המדדים צריכים להתאים לשאלה: האם נבחר המועד התקף, האם חושב הפער הנכון, האם כל טענה סיבתית נתמכת, והאם המערכת נמנעה מקביעה כשחסר בסיס. לצדם מודדים זמן תגובה ועלות. לצורך אבחון צריך לשמור עקבות של מקורות וגרסאות, קריאות לכלים וכשלים, תוך הגבלת הגישה ליומן והימנעות מהעתקה מיותרת של תוכן רגיש.
זה גם המקום שבו הייתי מתחיל יישום: בשאלה אחת שחוזרת בארגון, עם מקורות ידועים, כללי הכרעה ומקרי כשל. רק אחרי שאפשר להסביר מדוע המערכת הצליחה ומדוע נכשלה, יש בסיס להרחיב אותה. השאיפה היא שכאשר מישהו שואל "למה הפרויקט מתעכב?", נוכל לבדוק גם את התשובה וגם את הדרך שבה נבנתה תמונת המצב שמאחוריה.
התרחיש, התאריכים והפרויקט במאמר הם דוגמה להמחשה. בחירות התכנון הן הצעה ליישום, ולא תיאור של מערכת שנבדקה. המקורות הטכניים מקושרים בגוף המאמר.