הטמעת TaskWeaver (Microsoft) עבור סוכני בינה מלאכותית אנליטיים

סוכנים אנליטיים על TaskWeaver: היכן נשברת התפעול

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

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

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

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

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

מה נותן שכבת סוכנים מנוהלת: אפקטים מדידים

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

כדי שרשימת הבדיקה לא תהפוך לפורמליות, נדרשים שלושה דברים לפני ההתחלה:

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

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

אפשרויות פריסה של TaskWeaver: מתאר, צוות, היברידי

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

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

השוואת המצבים

מה לקחת בחשבון במעבר

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

שלבי ההטמעה: מביקורת התרחישים ועד מסירת המתאר

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

1. ביקורת תרחישים ומקורות. אוספים רשימה של שאלות שהצוות מציג לנתונים באופן קבוע ובוחנים מהיכן מגיעים המספרים. בפלט — רשימת תרחישים עם עדיפות ומפת מקורות.
2. תכנון סכימת המתאר. מפרקים כל תרחיש לשלבים: פיענוח השאילתה, פנייה לטבלאות ולקבצים, חישוב, פורמט התשובה. בנפרד מתעדים היכן הסוכן מחשב בעצמו והיכן הוא חייב לפנות לכלי חיצוני.
3. כיוונון המתאר וההרשאות. פורסים את הסביבה, מחברים מקורות, מקצים הרשאות ומפעילים תיעוד יומן. כל פנייה לנתונים נשארת ביומן — רואים על מה מבוססת התשובה.
4. בדיקת החישובים על נתונים היסטוריים. מריצים את השלבים האנליטיים על תקופות קודמות ומשווים לדוחות ייחוס. פער בנקודות ביקורת מפענחים עד הסיבה, ולא מסתירים אותו בעיגול.
5. בדיקת התנהגות בכשלים. מקור לא זמין, בחירה ריקה, שאילתה דו-משמעית: קובעים מראש אם הסוכן מבהיר, מחזיר תשובה חלקית או מסרב. את הגבולות מתארים במפורש.
6. מסירת התיעוד והמתאר. מוסרים סכימות, קונפיגורציות, כללי טיפול בכשלים והוראות תפעול, מלמדים את הצוות ומלווים את התקופה הראשונה של עבודה עצמאית.

ערכת מסירה: קונפיגורציות, מדיניות גישה, נהלים

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

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

הערכה נשארת במתאר שלכם. לפיה אפשר להקים את המערכת מאפס, להעביר את הליווי לצוות אחר או להרחיב את ספריית התרחישים בכוחות עצמכם.

מקרה בוחן: מתאר אנליטי לדיווח לפני ואחרי

לפני: הרכבה ידנית ופערים בין המקורות

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

מה שינינו ומה יצא

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

• הכנת הדוח המסכם: 2–3 ימים → 3–4 שעות, כולל בדיקה.
• שיעור הדוחות ללא תיקונים ידניים: מ-~30% ל-90%.
• חיבור מקור חדש: שבועות → ימים, בלי לשכתב את הלוגיקה.
• יכולת בדיקה: לכל מדד יש יומן שלבים — פער מפוענח לפי שלבים, ולא בחישוב מחדש מלא.
• העברת משמרת: המתודולוגיה מתוארת בקונפיגורציה, אנליטיקאי חדש מגיע לעבודה עצמאית בתוך ימים ספורים.

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

במה TaskWeaver שונה מסוכן כתוב עצמאית על סקריפטים

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

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

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

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

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

ספקות טכניים נפוצים: מפרקים לפי סעיפים

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

כיצד הסוכן מקבל גישה לנתונים רגישים?

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

כיצד מתפסים שגיאות בחישובים?

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

מה עם העומס כשמספר השאילתות גדל?

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

נדון במשימה: מה לשלוח להערכה

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

מה מספיק לשלוח מצד הלקוח:

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

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