(לחץ על התמונה למעלה כדי לצפות בסרטון של השיעור הזה)
הבנת המורכבות של האפליקציה שאתה בונה סוכן בינה מלאכותית בשבילה היא חשובה ליצירת סוכן אמין. עלינו לבנות סוכני בינה מלאכותית שמנהלים מידע ביעילות כדי לענות על צרכים מורכבים שמעבר להנדסת פרומפטים.
בשיעור זה, נבחן מהי הנדסת הקשר ותפקידה בבניית סוכני בינה מלאכותית.
שיעור זה יכסה:
• מהי הנדסת הקשר ולמה היא שונה מהנדסת פרומפטים.
• אסטרטגיות להנדסת הקשר יעילה, כולל איך לכתוב, לבחור, לדחוס ולהפריד מידע.
• כשלי קשר נפוצים שיכולים להכשיל את סוכן הבינה המלאכותית שלך ואיך לתקן אותם.
לאחר השלמת שיעור זה, תדע להבין איך:
• להגדיר הנדסת קשר ולהבדיל אותה מהנדסת פרומפטים.
• לזהות את הרכיבים המרכזיים של הקשר באפליקציות מבוססות מודל שפה גדול (LLM).
• להחיל אסטרטגיות לכתיבה, בחירה, דחיסה והפרדת הקשר לשיפור ביצועי הסוכן.
• להכיר כשלי קשר נפוצים כגון הרעלה, הסחת דעת, בלבול ועלבון, וליישם טכניקות הפחתה.
עבור סוכני בינה מלאכותית, הקשר הוא מה שמניע את התכנון של הסוכן לבצע פעולות מסוימות. הנדסת קשר היא הפרקטיקה של הבטחת הסוכן שיש לו את המידע הנכון כדי להשלים את השלב הבא במשימה. חלון ההקשר מוגבל בגודלו, ולכן כבוני סוכנים עלינו לפתח מערכות ותהליכים לניהול הוספה, הסרה ועיבוד מידע בחלון ההקשר.
הנדסת פרומפט מתמקדת בערכת הוראות סטטיות בודדות כדי להנחות ביעילות את סוכני הבינה עם ערכת חוקים. הנדסת הקשר היא ניהול סט דינמי של מידע, כולל הפרומפט הראשוני, כדי להבטיח שלסוכן הבינה יש את כל שהוא צריך לאורך זמן. הרעיון המרכזי בהנדסת הקשר הוא להפוך את התהליך הזה לחוזר על עצמו ואמין.
חשוב לזכור שהקשר אינו רק דבר אחד. המידע שסוכן הבינה זקוק לו יכול להגיע ממגוון מקורות שונים וחובתנו לוודא שלסוכן יש גישה למקורות אלה:
סוגי הקשר שסוכן בינה עשוי להזדקק לנהל כוללים:
• הוראות: אלו כמו “הכללים” של הסוכן – פרומפטים, הודעות מערכת, דוגמאות בוידאה מועטה (המראות כיצד לבצע פעולה), ותיאורים של כלים שהוא יכול להשתמש בהם. כאן מתמזגת ההתמקדות בהנדסת הפרומפט עם הנדסת הקשר.
• ידע: זה כולל עובדות, מידע שנשלף מבסיסי נתונים, או זכרונות ארוכי טווח שהסוכן צבר. זה כולל אינטגרציה של מערכת Retrieval Augmented Generation (RAG) אם לסוכן צריך גישה למאגרים שונים של ידע ובסיסי נתונים.
• כלים: אלו הן הגדרות של פונקציות חיצוניות, ממשקי API ושרתי MCP שהסוכן יכול לקרוא להם, יחד עם המשוב (התוצאות) שהוא מקבל בשימוש בהם.
• היסטוריית שיחה: הדו-שיח המתמשך עם המשתמש. עם הזמן, שיחות אלו מתארכות ומורכבות יותר, מה שאומר שהן תופסות מקום בחלון ההקשר.
• העדפות משתמש: מידע שנלמד על העדפות או אי-העדפות של המשתמש לאורך זמן. מידע זה יכול להיאגר ולהישאב בעת קבלת החלטות מרכזיות כדי לסייע למשתמש.
הנדסת קשר טובה מתחילה בתכנון טוב. להלן גישה שעוזרת לך להתחיל לחשוב איך ליישם את מושג הנדסת הקשר:
תכנון חשוב, אך ברגע שהמידע מתחיל לזרום לחלון ההקשר של הסוכן שלנו, עלינו להיות לנו אסטרטגיות מעשיות לניהולו:
בעוד שחלק מהמידע יתווסף לחלון ההקשר אוטומטית, הנדסת הקשר עוסקת בלקיחת תפקיד פעיל יותר בניהול מידע זה, שניתן לבצע בכמה אסטרטגיות:
מחברת סוכן זה מאפשר לסוכן בינה מלאכותית לרשום הערות על מידע רלוונטי בנוגע למשימות הנוכחיות ולאינטראקציות עם המשתמש במהלך מפגש יחיד. זה צריך להתקיים מחוץ לחלון ההקשר בקובץ או אובייקט ריצה שהסוכן יכול לאחזר מאוחר יותר במפגש זה אם יש צורך.
זכרונות מחברות טובות לניהול מידע מחוץ לחלון ההקשר של מפגש יחיד. זכרונות מאפשרים לסוכנים לאחסן ולאחזר מידע רלוונטי על פני מפגשים מרובים. זה יכול לכלול סיכומים, העדפות משתמש ומשוב לשיפורים בעתיד.
דחיסת הקשר כאשר חלון ההקשר גדל ומתקרב למגבלה שלו, ניתן להשתמש בטכניקות כגון סיכום וגזירה. זה כולל שמירת המידע הרלוונטי ביותר בלבד או הסרת הודעות ישנות.
מערכות רב-סוכניות פיתוח מערכות רב-סוכניות הוא צורה של הנדסת קשר כי לכל סוכן יש חלון הקשר משלו. איך ההקשר הזה משותף ומועבר לסוכנים שונים הוא דבר נוסף לתכנן בעת בניית מערכות אלה.
סביבת ‘חול’ (Sandbox) אם סוכן צריך להריץ קוד או לעבד כמויות גדולות של מידע במסמך, זה יכול לדרוש כמות גדולה של טוקנים לעיבוד התוצאות. במקום לאחסן את כל זה בחלון ההקשר, הסוכן יכול להשתמש בסביבת sandbox שמסוגלת להריץ את הקוד הזה ולקרוא רק את התוצאות ומידע רלוונטי אחר.
אובייקטים במצב ריצה זה נעשה על ידי יצירת מכולות מידע לניהול מצבים שבהם הסוכן צריך גישה למידע מסוים. למשימה מורכבת, זה יאפשר לסוכן לאחסן את תוצאות כל תת-משימה שלב אחר שלב, כך שההקשר יישאר מחובר רק לתת-המשימה הספציפית הזו.
לאחר שתיישם אחת מהאסטרטגיות האלה, כדאי לבדוק מה השיחה הבאה עם המודל בפועל קיבלה. שאלה מועילה לניפוי שגיאות היא:
האם הסוכן טען יותר מדי הקשר, הקשר לא נכון, או חסר הקשר שנדרש?
אין צורך לתעד פרומפטים גולמיים, פלטי כלים או תוכן זכרונות כדי לענות על שאלה זו. בייצור, יש להעדיף רשומות בדיקת הקשר קטנות שמכילות ספירות, מזהים, קודים, ותוויות מדיניות:
המטרה אינה לשמור יותר הקשר אלא להשאיר מספיק ראיות שמפתח יכול להבין איזו אסטרטגיית הקשר הופעלה והאם היא שינתה את השיחה הבאה עם המודל בדרך המיועדת.
נניח שאנחנו רוצים שסוכן בינה מלאכותית “יתאם לי טיול לפריס.”
• סוכן פשוט המשתמש רק בהנדסת פרומפט עשוי רק להגיב: “אוקי, מתי תרצה לנסוע לפריס?”. הוא רק עיבד את השאלה הישירה שלך בזמן שהמשתמש שאל.
• סוכן המשתמש באסטרטגיות הנדסת הקשר שנסקרו יעשה הרבה יותר. לפני שהוא אפילו מגיב, המערכת שלו עשויה:
◦ לבדוק את היומן שלך לתאריכים פנויים (שליפת נתונים בזמן אמת).
◦ לזכור העדפות נסיעה קודמות (מהזיכרון ארוך הטווח) כמו חברת התעופה המועדפת, התקציב או אם אתה מעדיף טיסות ישירות.
◦ לאתר כלים זמינים להזמנת טיסות ומלונות.
מה זה: כאשר הזייה (מידע שגוי שנוצר על ידי מודל השפה) או טעות נכנסים להקשר ומוזכרים שוב ושוב, גורמים לסוכן לרדוף אחרי מטרות בלתי אפשריות או לפתח אסטרטגיות אבסורדיות.
מה לעשות: יש ליישם אימות הקשר והפרדה. לאמת מידע לפני שהוא מתווסף לזיכרון ארוך הטווח. אם מתגלה הרעלה אפשרית, יש להתחיל נושאי הקשר חדשים כדי למנוע הפצת המידע השגוי.
דוגמה להזמנת טיול: הסוכן שלך מהזים טיסת ישירה מבעבר נמל מקומי קטן לעיר בינלאומית מרוחקת שלא באמת מציעה טיסות בינלאומיות. פרטי הטיסה שלא קיימים נשמרים בהקשר. מאוחר יותר, כשאתה מבקש מהסוכן להזמין, הוא ממשיך לנסות למצוא כרטיסים לנתיב בלתי אפשרי זה, מה שמוביל לשגיאות חוזרות.
פתרון: ליישם שלב של אימות קיום הטיסה ונתיבים עם API בזמן אמת לפני הוספת פרטי הטיסה להקשר העבודה של הסוכן. אם האימות נכשל, המידע השגוי “מופרד” ואינו בשימוש.
מה זה: כאשר ההקשר נהיה גדול מדי והמודל מתמקד יותר מדי בהיסטוריה שנצברה במקום להשתמש במה שלמד במהלך האימון, מה שמוביל לפעולות חזרתיות או חסרות תועלת. מודלים עלולים להתחיל לטעות עוד לפני שחלון ההקשר מלא.
מה לעשות: יש להשתמש בסיכום הקשר. לדחוס מדי פעם מידע שנצבר לסיכומים קצרים, לשמור על פרטים חשובים ולהסיר היסטוריה מיותרת. זה עוזר לאפס את המיקוד.
דוגמה להזמנת טיול: דיברת זמן רב על יעדי חלום לטיול, כולל תיאור מפורט של טיול הטיולים שלך לפני שנתיים. כשאתה מבקש סוף סוף “למצוא טיסה זולה לחודש הבא,” הסוכן מתבלבל בפרטים הישנים והלא רלוונטיים ושואל שוב ושוב על ציוד הטיולים או מסלולים קודמים, ומתעלם מבקשתך הנוכחית.
פתרון: לאחר מספר סיבובים או כשההקשר גדל מדי, על הסוכן לסכם את החלקים האחרונים והרלוונטיים ביותר בשיחה – תוך מיקוד בתאריכי הנסיעה והיעד הנוכחי שלך – ולהשתמש בסיכום המונגש לשיחה הבאה עם המודל, תוך הסרת השיחה ההיסטורית הפחות רלוונטית.
מה זה: כאשר הקשר מיותר, לרוב בצורת יותר מדי כלים זמינים, גורם למודל לייצר תגובות גרועות או לקרוא לכלים לא רלוונטיים. מודלים קטנים במיוחד חשופים לכך.
מה לעשות: ליישם ניהול עומס כלים באמצעות טכניקות 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 כדי לפגוש לומדים אחרים, להשתתף בשעות קבלה ולקבל מענה לשאלות שלך על סוכני בינה מלאכותית.
כתב ויתור: מסמך זה תורגם באמצעות שירות תרגום אוטומטי Co-op Translator. למרות שאנו שואפים לדיוק, יש לקחת בחשבון שתרגומים אוטומטיים עלולים להכיל שגיאות או אי-דיוקים. יש להחשיב את המסמך המקורי בשפתו הטבעית כמקור הסמכות. למידע קריטי מומלץ להשתמש בתרגום מקצועי על ידי מתרגם אדם. אנו לא אחראים לכל אי-הבנה או פירוש שגוי הנובע מהשימוש בתרגום זה.