ai-agents-for-beginners
הנדסת הקשר לסוכני AI
(לחצו על התמונה למעלה לצפייה בסרטון של השיעור)
הבנת המורכבות של היישום עבורו אתם בונים סוכן AI היא חשובה כדי ליצור סוכן אמין. עלינו לבנות סוכני AI שמנהלים מידע ביעילות כדי לענות על צרכים מורכבים שמעבר להנדסת הפרומפט.
בשיעור זה, נבחן מהי הנדסת הקשר ומה תפקידה בבניית סוכני AI.
מבוא
בשיעור זה נסקור:
• מהי הנדסת הקשר ומדוע היא שונה מהנדסת פרומפט.
• אסטרטגיות להנדסת הקשר יעילה, כולל כיצד לכתוב, לבחור, לדחוס ולהפריד מידע.
• כישלונות נפוצים בהקשר שעשויים לשבש את סוכן ה-AI שלך ואיך לתקן אותם.
מטרות הלמידה
בסיום השיעור תדע להבין איך:
• להגדיר הנדסת הקשר ולהבדיל אותה מהנדסת פרומפט.
• לזהות את הרכיבים המרכזיים של ההקשר ביישומים מבוססי מודלי שפה גדולים (LLM).
• ליישם אסטרטגיות לכתיבה, בחירה, דחיסה והפרדת הקשר לשיפור ביצועי הסוכן.
• להכיר כישלונות נפוצים בהקשר כגון זיהום, הסחת דעת, בלבול וסתירה, ולהפעיל טכניקות להקטנת הנזק.
מהי הנדסת הקשר?
לסוכני AI, הקשר הוא מה שמניע את תכנון הסוכן לבצע פעולות מסוימות. הנדסת הקשר היא הפרקטיקה של הבטחת הסוכן שיש בידיו את המידע הנכון כדי להשלים את הצעד הבא במשימה. חלון ההקשר מוגבל בגודלו, ולכן כבוני סוכנים עלינו לבנות מערכות ותהליכים לניהול הוספה, הסרה ועיבוי המידע בחלון ההקשר.
הנדסת פרומפט לעומת הנדסת הקשר
הנדסת פרומפט מתמקדת בקבוצת הוראות סטטית אחת כדי להנחות את סוכני ה-AI ביעילות עם סט של כללים. הנדשת הקשר עוסקת בניהול סט דינמי של מידע, כולל הפרומפט ההתחלתי, כדי להבטיח שלסוכן ה-AI יש את הנדרש לאורך זמן. הרעיון המרכזי בהנדסת הקשר הוא להפוך תהליך זה לחוזר ואמין.
סוגי הקשר
חשוב לזכור שההקשר אינו דבר אחד בלבד. המידע שסוכן ה-AI זקוק לו יכול להגיע ממגוון מקורות, ואנו אחראים לוודא שלסוכן יש גישה למקורות אלה:
סוגי ההקשר שסוכן AI עשוי לנהל כוללים:
• הוראות: אלו הן כמו “כללי” הסוכן – פרומפטים, הודעות מערכת, דוגמאות בודדות (הצגת דרך פעולה ל-AI), ותיאורים של כלים שבהם הוא יכול להשתמש. כאן ממוקד השילוב בין הנדסת פרומפט להנדסת הקשר.
• ידע: מכסה עובדות, מידע שנשלף מבסיסי נתונים, או זיכרונות ארוכי טווח שהסוכן צבר. כולל גם שילוב של מערכות כמו Retrieval Augmented Generation (RAG) אם הסוכן זקוק לגישה למאגרים ובסיסי מידע שונים.
• כלים: אלו הם ההגדרות של פונקציות חיצוניות, APIs ושרתים MCP שהסוכן יכול לקרוא להם, יחד עם המשוב (תוצאות) שהוא מקבל משימוש בהם.
• היסטוריית שיחה: הדיאלוג המתמשך עם משתמש. עם הזמן, שיחות אלה מתארכות ומורכבות יותר, מה שתופס נפח בחלון ההקשר.
• העדפות משתמש: מידע שנלמד על טעמיו או העדפותיו של המשתמש עם הזמן. מידע זה עשוי להיות מאוחסן ומשמש בהחלטות מפתח כדי לסייע למשתמש.
אסטרטגיות להנדסת קשר יעילה
אסטרטגיות תכנון
הנדסת קשר טובה מתחילה עם תכנון טוב. הנה גישה שתעזור לך להתחיל לחשוב על איך ליישם את מושג הנדסת הקשר:
-
הגדר תוצאות ברורות - יש להגדיר בבירור את תוצאות המשימות שיוקצו לסוכני ה-AI. השב על השאלה - “איך ייראה העולם כאשר סוכן ה-AI יסיים את המשימה?” במילים אחרות, איזה שינוי, מידע או תגובה המשתמש אמור לקבל לאחר האינטראקציה עם הסוכן.
-
מפה את ההקשר - לאחר שהגדרת את תוצאות הסוכן, עליך להשיב על השאלה “איזה מידע צריך סוכן ה-AI על מנת להשלים את המשימה?”. כך תוכל להתחיל למפות את ההקשר ולהבין היכן המידע נמצא.
-
צרו צינורות הקשר - עכשיו כשאתה יודע איפה המידע נמצא, עליך להשיב על השאלה “איך הסוכן יקבל את המידע הזה?”. ניתן לעשות זאת בדרכים שונות, כולל RAG, שימוש בשרתי MCP וכלים נוספים.
אסטרטגיות מעשיות
תכנון חשוב, אך ברגע שהמידע מתחיל לזרום לתוך חלון ההקשר של הסוכן, נחוצות אסטרטגיות מעשיות לניהולו:
ניהול הקשר
בעוד שחלק מהמידע יתווסף אוטומטית לחלון ההקשר, הנדסת הקשר עוסקת בנטילת תפקיד פעיל יותר באותו מידע, שניתן לבצע בכמה אסטרטגיות:
-
מחברת סוכן מאפשרת לסוכן AI לרשום הערות על מידע רלוונטי לגבי המשימות הנוכחיות ואינטראקציות עם המשתמש במהלך סשן יחיד. זה צריך להתקיים מחוץ לחלון ההקשר בקובץ או אובייקט ריצה שהסוכן יכול לשחזר במהלך הסשן במידת הצורך.
-
זיכרונות מחברות הן טובות לניהול מידע מחוץ לחלון ההקשר בסשן בודד. זיכרונות מאפשרים לסוכנים לאחסן ולשחזר מידע רלוונטי בין סשנים מרובים. זה יכול לכלול תקצירים, העדפות משתמש ומשוב לשיפורים עתידיים.
-
דחיסת הקשר ברגע שחלון ההקשר גדל ומתקרב למגבלתו, ניתן להשתמש בטכניקות כגון תקצור וגזירה. זה כולל לשמור רק על המידע הרלוונטי ביותר או להסיר הודעות ישנות.
-
מערכות ריבוי סוכנים פיתוח מערכת ריבוי סוכנים הוא צורת הנדסת הקשר כיוון שלכל סוכן יש את חלון ההקשר שלו. איך הקשר זה משותף ומועבר לסוכנים השונים הוא עניין נוסף שיש לתכנן בזמן בניית המערכות הללו.
-
סביבות סנדבוקס אם סוכן צריך להריץ קוד או לעבד כמויות גדולות של מידע במסמך, זה עלול לקחת הרבה טוקנים לעיבוד התוצאות. במקום לאכסן את כל זה בחלון ההקשר, הסוכן יכול להשתמש בסביבת סנדבוקס שמסוגלת להריץ את הקוד ולקרוא רק את התוצאות ומידע רלוונטי אחר.
-
אובייקטי מצב ריצה זה נעשה על ידי יצירת מכולות מידע לניהול מצבים שבהם הסוכן צריך גישה למידע מסוים. למשימה מורכבת, זה יאפשר לסוכן לאחסן את תוצאות כל שלב של תת-המשימה שלב אחר שלב, מה שמאפשר להכיל את ההקשר רק לתת-המשימה המסוימת.
דוגמה להנדסת הקשר
נניח שאנו רוצים שסוכן AI “יערגן לי טיול לפריז.”
• סוכן פשוט המשתמש רק בהנדסת פרומפט עשוי להיענות פשוט: “בסדר, מתי תרצה לנסוע לפריז?” הוא רק עיבד את השאלה הישירה שלך בזמן המשתמש שאל.
• סוכן שמשתמש באסטרטגיות הנדסת הקשר שנסקרו יעשה הרבה יותר. לפני שהוא מגיב, המערכת שלו עשויה:
◦ לבדוק את לוח הזמנים שלך לתאריכים זמינים (שליפת נתונים בזמן אמת).
◦ להיזכר בהעדפות הנסיעות הקודמות שלך (מזיכרון ארוך טווח) כמו חברת התעופה המועדפת, התקציב או האם אתה מעדיף טיסות ישירות.
◦ לזהות כלים זמינים להזמנת טיסה ומלון.
- אז, תגובה לדוגמה יכולה להיות: “היי [שמך]! אני רואה שאתה פנוי בשבוע הראשון של אוקטובר. האם לחפש טיסות ישירות לפריז בחברת התעופה [מועדפת] במסגרת התקציב הרגיל שלך של [תקציב]?” תגובה עשירה ומודעת להקשר זו ממחישה את כוח הנדסת הקשר.
כישלונות נפוצים בהקשר
זיהום הקשר
מה זה: כאשר הלוצינציה (מידע שגוי שנוצר על ידי ה-LLM) או שגיאה נכנסת להקשר ומוזכרת שוב ושוב, מה שגורם לסוכן לרדוף אחרי מטרות בלתי אפשריות או לפתח אסטרטגיות טפלות.
מה לעשות: להטמיע אימות הקשר ובידוד. לאמת מידע לפני שהוא מתווסף לזיכרון ארוך טווח. אם מזוהה זיהום פוטנציאלי, להתחיל שרשורי הקשר חדשים כדי למנוע הפצת מידע רע.
דוגמה להזמנת טיול: הסוכן שלך מעלה השגה על טיסה ישירה מבנמל תעופה מקומי קטן לעיר בינלאומית רחוקה שלא מציעה טיסות בינלאומיות בפועל. פרט הטיסה הלא קיים נשמר בהקשר. בהמשך, כשאתה מבקש לסוכן להזמין, הוא ממשיך לנסות למצוא כרטיסים לנתיב הבלתי אפשרי הזה וגורם לשגיאות חוזרות.
פתרון: להטמיע שלב של אימות קיום מסלול וטיסות עם API בזמן אמת לפני הוספת פרט הטיסה להקשר העובד של הסוכן. אם האימות נכשל, המידע השגוי “מבודד” ולא ממשיך להיות בשימוש.
הסחת דעת בהקשר
מה זה: כאשר ההקשר נעשה כה גדול שהמודל מתמקד יותר מדי בהיסטוריה המצטברת במקום להשתמש במה שלמד במהלך ההכשרה, מה שמוביל לפעולות חוזרות או לא מועילות. מודלים עשויים להתחיל לטעות אפילו לפני שחלון ההקשר מלא.
מה לעשות: להשתמש בתקצור הקשר. לעיתים לדחוס את המידע המצטבר לתקצירים קצרים, לשמור על פרטים חשובים ולהסיר היסטוריה מיותרת. זה עוזר לאתחל את המיקוד.
דוגמה להזמנת טיול: דיברת זמן רב על יעדים חלומיים שונים, כולל סיפור מפורט על טיול בתרמילנות לפני שנתיים. כשאתה מבקש סוף סוף “למצוא לי טיסה זולה לחודש הבא,” הסוכן מתבלבל בפרטים הישנים והלא רלוונטיים, ושואל שוב ושוב על ציוד תרמילאות או מסלולים קודמים, תוך הזנחת הבקשה הנוכחית.
פתרון: לאחר מספר סבבים או כשההקשר גדל מדי, הסוכן צריך לסכם את החלקים העדכניים והרלוונטיים ביותר בשיחה – תוך התמקדות בתאריכי והיעד הנוכחי – ולהשתמש בתקציר המרוכז הזה לקריאה הבאה ל-LLM, תוך זריקת השיחה היסטורית הפחות רלוונטית.
בלבול בהקשר
מה זה: כאשר יש הקשר מיותר, לעיתים בצורה של יותר מדי כלים זמינים, מה שגורם למודל ליצור תגובות לא טובות או לקרוא לכלים שאינם רלוונטיים. קטנים מודלים סובלים במיוחד מכך.
מה לעשות: ליישם ניהול טעינה של כלים באמצעות טכניקות RAG. לאחסן תיאורי כלים בבסיס נתונים וקטורי ולבחור רק את הכלים הרלוונטיים ביותר לכל משימה ספציפית. מחקרים מראים שיש להגביל את הבחירה לפחות מ-30 כלים.
דוגמה להזמנת טיול: לסוכן יש גישה לעשרות כלים: book_flight, book_hotel, rent_car, find_tours, currency_converter, weather_forecast, restaurant_reservations ועוד. שאלת, “מה הדרך הטובה ביותר להתנייד בפריז?” בגלל מספר הכלים הרב, הסוכן מתבלבל ומנסה לקרוא ל-book_flight בתוך פריז, או ל-rent_car אף על פי שאתה מעדיף תחבורה ציבורית, כי תיאורי הכלים עשויים לחפוף או שהוא פשוט לא מבחין מהו הטוב ביותר.
פתרון: להשתמש ב-RAG על תיאורי הכלים. כאשר אתה שואל על הדרך להתנייד בפריז, המערכת שולפת דינמית רק את הכלים הרלוונטיים כמו rent_car או public_transport_info בהתבסס על השאלה שלך, ומציגה “טעינה” ממוקדת של כלים ל-LLM.
סתירה בהקשר
מה זה: כאשר מידע סותר קיים בתוך ההקשר, מה שגורם להסקת מסקנות לא עקבית או לתגובות סופיות גרועות. זה קורה לעיתים כאשר המידע מגיע בשלבים מוקדמים, והנחות שגויות מוקדמות נשארות בהקשר.
מה לעשות: להשתמש בגיזום הקשר והעברה החוצה. גיזום פירושו להסיר מידע מיושן או סותר עם הגעת פרטים חדשים. העברה החוצה נותנת למודל “מחברת” נפרדת לעיבוד מידע מבלי להעמיס את ההקשר הראשי.
דוגמה להזמנת טיול: בתחילה אמרת לסוכן, “אני רוצה לטוס במחלקת תיירים.” מאוחר יותר בשיחה שינית דעתך ואמרת, “למעשה, בטיול הזה, אנחנו טסים במחלקת עסקים.” אם שתי ההוראות נשארות בהקשר, הסוכן עלול לקבל תוצאות חיפוש סותרות או להתבלבל איזו העדפה עדיף לקחת בחשבון.
פתרון: להטמיע גיזום הקשר. כאשר הוראה חדשה סותרת ישנה, ההוראה הישנה מוסרת או מתבטלת במפורש בהקשר. לחלופין, הסוכן יכול להשתמש במחברת לפתרון סתירות בהעדפות לפני קבלת החלטה, כך שרק ההוראה הסופית, העקבית, מנחה את פעולותיו.
רוצים לשאול עוד על הנדסת הקשר?
הצטרפו ל-Microsoft Foundry Discord כדי להיפגש עם לומדים נוספים, להשתתף בשעות משרד ולקבל תשובות לשאלות על סוכני AI.
כתב ויתור: מסמך זה תורגם באמצעות שירות תרגום מבוסס בינה מלאכותית Co-op Translator. למרות שאנו שואפים לדיוק, יש להיות מודעים לכך שתרגומים אוטומטיים עלולים להכיל שגיאות או אי-דיוקים. המסמך המקורי בשפת המקור נחשב למקור הסמכותי. למידע קריטי מומלץ להשתמש בתרגום מקצועי על ידי אדם. אנו לא אחראים להצלבות או לפרשנויות שגויות הנובעות משימוש בתרגום זה.