מה זה Harness ואיך הוא באמת הופך מודל AI חכם לסוכן שמסוגל לעבוד בשבילנו?

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

אז מה זה בעצם Harness?

בפשטות, Harness הוא מכלול התשתיות, ההוראות ומנגנוני ההפעלה שמאפשרים למודל AI לעבוד בתוך מערכת מסוימת.

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

אפשר לחשוב על מודל AI כמו על נהג מוכשר. היכולת שלו לנהוג חשובה, אבל מה הוא יוכל לעשות ללא מכונית, כבישים, מערכת ניווט, בלמים וכללי תנועה?

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

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

כדי להבין כיצד ה-Harness מתרחב ככל שהסוכן מקבל יותר יכולות, אפשר לחלק את ההתפתחות שלו לחמישה שלבים:

חמש שכבות בהתפתחות ה-Harness

שלב ראשון: צ'אטבוט שיודע לענות

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

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

בשלב הזה ה-Harness פשוט יחסית וכולל שלושה רכיבים מרכזיים:

Chatbot: שלושת הרכיבים הבסיסיים

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

שלב שני: נותנים לסוכן כלים ויכולת לפעול

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

בשביל זה נוסיף ל-Harness שלושה מרכיבים:

הרנס (Harness) מורחב

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

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

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

שלב שלישי: סוכן שזוכר וממשיך מאיפה שהפסיק

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

כאן נכנס הרעיון של Persistent Agent, סוכן שהמערכת שלו מאפשרת לשמר מידע והמשכיות בין הפעלות.

לצורך זה ה-Harness עשוי לכלול Memory לשמירת מידע רלוונטי, State לתיעוד מצב המשימות, ו-Persistent Environment, סביבת עבודה שניתן לחזור אליה.

נוספים גם רכיבים כמו Identity ו-Credentials, שמאפשרים למערכת לזהות את הסוכן ולנהל באופן מאובטח את הגישה שלו לשירותים. במערכות מורכבות אפשר לשלב גם Multi-Agent, כמה סוכנים שמחלקים ביניהם משימות.

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

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

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

שלב רביעי: הסוכן מתחיל לעבוד גם בלי שביקשנו

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

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

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

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

שלב חמישי: מי מחליט מה מותר לסוכן לעשות?

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

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

לשם כך ה-Harness עשוי לכלול כמה מנגנונים:

חמשת מנגנוני הבקרה של אוטונומיה

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

את ההגבלות הרגישות צריך לאכוף גם ברמת הכלים והמערכות, ולא להסתפק בהוראה מילולית למודל.

ומה קורה כשהסוכן טועה?

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

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

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

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

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

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

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

איך מתחילים לבנות Harness נכון?

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

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

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

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

המודל חשוב, אבל הוא רק חלק מהמערכת

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

ה-Harness קובע כיצד יכולות המודל יתורגמו לעבודה ממשית, איזה מידע יהיה זמין לו, עד כמה יוכל לפעול בעצמו וכיצד אפשר יהיה לבקר את הפעולות שלו.

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

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