אחרי כמה שנים שבהן הנדסת פרומפטים (prompt engineering) הייתה מוקד תשומת הלב בתחום ה-AI היישומי, מונח חדש תופס כעת מקום מרכזי: הנדסת הקשר. פיתוח עם מודלי שפה גדולים (LLMs) הופך פחות לחיפוש אחר המילים והביטויים הנכונים לפרומפטים שלכם, ויותר למתן מענה לשאלה הרחבה יותר: "איזו תצורת הקשר תניב באופן הסביר ביותר את ההתנהגות הרצויה מהמודל שלנו?"

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

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

הנדסת הקשר מול הנדסת פרומפטים

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

בימיה הראשונים של הנדסת ה-LLMs, יצירת פרומפטים הייתה המרכיב הגדול ביותר בעבודת הנדסת ה-AI, שכן רוב מקרי השימוש מחוץ לאינטראקציות צ'אט יומיומיות דרשו פרומפטים אופטימליים למשימות סיווג חד-פעמי או יצירת טקסט. כפי שהמונח מרמז, המיקוד העיקרי של הנדסת פרומפטים הוא כיצד לכתוב פרומפטים יעילים, ובמיוחד System Prompts. אולם, ככל שאנו מתקדמים לעבר הנדסת סוכנים בעלי יכולות רחבות יותר, הפועלים לאורך מספר סבבי הסקה וטווח זמן ארוך יותר, אנו זקוקים לאסטרטגיות לניהול מצב ההקשר השלם (הוראות מערכת, כלים, Model Context Protocol (MCP), נתונים חיצוניים, היסטוריית הודעות וכו').

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

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

למרות מהירותם ויכולתם לנהל כמויות הולכות וגדלות של נתונים, אנו מבחינים כי LLMs, בדומה לבני אדם, מאבדים מיקוד או חווים בלבול בנקודה מסוימת. מחקרים על מדדי ביצועים בסגנון 'מחט בערימת שחת' (needle-in-a-haystack) חשפו את המושג של 'ריקבון הקשר' (context rot): ככל שמספר הטוקנים בחלון ההקשר עולה, יכולת המודל לשלוף מידע בצורה מדויקת מאותו הקשר פוחתת.

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

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

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

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

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

האנטומיה של הקשר אפקטיבי

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

System Prompts צריכים להיות ברורים ביותר ולהשתמש בשפה פשוטה וישירה המציגה רעיונות בגובה הנכון עבור הסוכן. ה"גובה הנכון" הוא אזור "כיפה אדומה" (Goldilocks zone) בין שני מצבי כשל נפוצים. בקצה אחד, אנו רואים מהנדסים מקודדים לוגיקה מורכבת ושבירה ישירות בפרומפטים שלהם כדי להפיק התנהגות סוכנית מדויקת. גישה זו יוצרת שבריריות ומגבירה את מורכבות התחזוקה לאורך זמן. בקצה השני, מהנדסים מספקים לעיתים הנחיות מעורפלות וברמה גבוהה שאינן מעניקות ל-LLM איתותים קונקרטיים לפלטים רצויים או מניחות בטעות הקשר משותף. הגובה האופטימלי משיג איזון: ספציפי מספיק כדי להנחות התנהגות ביעילות, אך גמיש מספיק כדי לספק למודל היוריסטיקות חזקות להנחיית התנהגות.

אנו ממליצים לארגן פרומפטים לקטעים נפרדים (כמו <background_information>, <instructions>, ## Tool guidance, ## Output description וכו') ושימוש בטכניקות כמו תיוג XML או כותרות Markdown כדי להגדיר קטעים אלו, אם כי הפורמט המדויק של פרומפטים כנראה הופך לפחות חשוב ככל שהמודלים נעשים בעלי יכולת רבה יותר.

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

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

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

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

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

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

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

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

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

אנו רואים כעת שינוי באופן שבו מהנדסים חושבים על עיצוב הקשר עבור סוכנים. כיום, יישומי AI-native רבים משתמשים בצורה כלשהי של שליפה מבוססת embedding לפני זמן ההסקה, כדי להציג הקשר חשוב שהסוכן יחשוב עליו. ככל שהתחום עובר לגישות סוכניות יותר, אנו רואים יותר ויותר צוותים משפרים את מערכות השליפה הללו באמצעות אסטרטגיות הקשר "בזמן אמת" (just in time).

במקום עיבוד מוקדם של כל הנתונים הרלוונטיים מראש, סוכנים הבנויים בגישת "בזמן אמת" שומרים מזהים קלים (נתיבי קבצים, שאילתות שמורות, קישורי אינטרנט וכו') ומשתמשים בהפניות אלו כדי לטעון נתונים באופן דינמי לתוך ההקשר בזמן ריצה באמצעות כלים. פתרון הקידוד הסוכני של אנתרופיק, Claude Code, משתמש בגישה זו לביצוע ניתוח נתונים מורכב על פני מסדי נתונים גדולים. המודל יכול לכתוב שאילתות ממוקדות, לאחסן תוצאות ולמנף פקודות Bash כמו head ו-tail כדי לנתח כמויות גדולות של נתונים מבלי לטעון אי פעם את אובייקטי הנתונים המלאים לתוך ההקשר. גישה זו משקפת את הקוגניציה האנושית: אנחנו בדרך כלל לא משננים קורפוסים שלמים של מידע, אלא מציגים מערכות ארגון ואינדוקס חיצוניות כמו מערכות קבצים, תיבות דואר וסימניות כדי לשלוף מידע רלוונטי לפי דרישה.

מעבר ליעילות האחסון, המטא-דאטה של הפניות אלה מספק מנגנון לזיקוק יעיל של התנהגות, בין אם הוא מסופק במפורש או באופן אינטואיטיבי. עבור סוכן הפועל במערכת קבצים, נוכחות קובץ בשם test_utils.py בתיקיית tests מרמזת על מטרה שונה מאשר קובץ באותו שם הנמצא בתיקיית src/core_logic/. היררכיות תיקיות, מוסכמות שמות וחותמות זמן מספקים כולם איתותים חשובים המסייעים לבני אדם ולסוכנים כאחד להבין כיצד ומתי לנצל מידע.

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

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

בהגדרות מסוימות, הסוכנים היעילים ביותר עשויים להשתמש באסטרטגיה היברידית, לשלוף חלק מהנתונים מראש עבור מהירות, ולבצע חקירה אוטונומית נוספת לפי שיקול דעתם. גבול ההחלטה לרמת האוטונומיה ה'נכונה' תלוי במשימה. Claude Code הוא סוכן המשתמש במודל היברידי זה: קבצי CLAUDE.md מוזנים באופן פשוט להקשר מראש, בעוד פרימיטיבים כמו glob ו-grep מאפשרים לו לנווט בסביבתו ולשלוף קבצים "בזמן אמת", ובכך לעקוף ביעילות את הבעיות של אינדוקס מיושן ועצי תחביר מורכבים.

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

הנדסת הקשר למשימות ארוכות טווח

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

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

דחיסה

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

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

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

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

רישום הערות מובנה

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

אסטרטגיה זו מספקת זיכרון מתמשך עם תקורה מינימלית. בדומה ל-Claude Code היוצר רשימת מטלות (to-do list), או לסוכן המותאם אישית שלכם המתחזק קובץ NOTES.md, תבנית פשוטה זו מאפשרת לסוכן לעקוב אחר התקדמות במשימות מורכבות, ולשמר הקשרים ותלויות קריטיות שאחרת היו אובדים על פני עשרות קריאות כלים.

קלוד משחק פוקימון מדגים כיצד זיכרון משנה את יכולות הסוכן בתחומים שאינם קידוד. הסוכן מתחזק ספירות מדויקות לאורך אלפי צעדי משחק – עוקב אחר יעדים כמו "במהלך 1,234 הצעדים האחרונים אימנתי את הפוקימון שלי בנתיב 1, פיקאצ'ו עלה 8 רמות מתוך יעד של 10". ללא כל פרומפט לגבי מבנה הזיכרון, הוא מפתח מפות של אזורים שנחקרו, זוכר אילו הישגים מרכזיים הוא פתח, ומתחזק הערות אסטרטגיות של טקטיקות לחימה המסייעות לו ללמוד אילו התקפות עובדות בצורה הטובה ביותר נגד יריבים שונים.

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

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

ארכיטקטורות תת-סוכנים

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

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

הבחירה בין גישות אלו תלויה במאפייני המשימה. לדוגמה:

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

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

מסקנה

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

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

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

תודות

נכתב על ידי צוות ה-AI היישומי של אנתרופיק: פריטבי ראג'סקרן (Prithvi Rajasekaran), איתן דיקסון (Ethan Dixon), קרלי ריאן (Carly Ryan) וג'רמי הדפילד (Jeremy Hadfield), עם תרומות מחברי הצוות רפי איוב (Rafi Ayub), חנה מורן (Hannah Moran), קאל רוב (Cal Rueb) וקונור ג'נינגס (Connor Jennings). תודות מיוחדות למולי וורוורק (Molly Vorwerck), סטיוארט ריצ'י (Stuart Ritchie) ומגי וו (Maggie Vo) על תמיכתם.