הנדסת מעטפת לסוכני AI: הגישה שלי

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

מה אני עושה כמהנדס Harness

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

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

ההקשר מתחיל בבחירת מקור

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

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

מקרה אמיתי: מנגנון שהיה קיים, אבל לא הועיל

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

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

תזמור, אישור ובדיקה של התוצאה

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

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

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

למי העבודה הזו מועילה

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

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

לקריאה נוספת ולשיחה

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

שאלות על AI Harness Engineering

האם Harness הוא רק אוסף פרומפטים?

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

האם חייבים לעבוד עם כמה מודלים?

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

איך יודעים שהרצה הצליחה?

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

האם העבודה מחייבת החלפת המודל הקיים?

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