המגבלה היא חלון ההקשר; הנדסת הקשר היא מה שנבנה סביבה
כדי להבין את המונח הזה צריך קודם להפריד בין שני דברים שנשמעים כמעט זהים.
חלון הקשר (Context Window) הוא תכונה של המודל: כמות הטקסט שהוא מסוגל לקחת בחשבון בבת אחת. הוא נקבע בבנייה של המודל, המשתמש אינו יכול לשנות אותו, ויש לו ערך משלו באתר הזה בקטגוריית מודלים ושפה. הנדסת הקשר (Context Engineering) היא משהו אחר לגמרי: המקצוע שהתפתח סביב המגבלה הזו. היא לא עוסקת בשאלה כמה מקום יש, אלא בשאלה מה נכנס לתוך המקום הזה בכל פנייה למודל — ולא פחות חשוב, מה נשאר בחוץ.
ההבחנה הזו נעשית ברורה כשמסתכלים מה בעצם נמצא בחלון ברגע נתון בסוכן פועל. יש שם הוראות-המערכת, תיאורי-הכלים שהסוכן רשאי להפעיל, קטעי-מסמכים שנשלפו ממאגר, היסטוריית-השיחה, ותוצאות של כל כלי שהופעל עד כה. רק חלק קטן מזה הוקלד על ידי אדם; את רובו מרכיב הקוד שמריץ את הסוכן, מחדש, לפני כל פנייה.
מסמך הנדסי של Anthropic מספטמבר 2025 מגדיר את התחום כך: אוסף השיטות שבוחרות ומתחזקות את אוסף הטוקנים הטוב ביותר בזמן שהמודל רץ — כלומר איזה טקסט בדיוק יעמוד מול המודל ברגע שהוא עונה, ולא רק מה שנכתב בפרומפט.
מאיפה המונח הגיע, ומה ההבדל בינו לבין הנדסת פרומפטים
המונח עצמו צעיר, ואפשר להצביע על החודש שבו הוא נכנס לשימוש רחב. ביוני 2025 כתב טובי לוטקה (Tobi Lütke), מנכ״ל Shopify, שהוא מעדיף את המונח הנדסת הקשר על פני הנדסת פרומפטים, כי הוא מתאר טוב יותר את המיומנות-המרכזית: האמנות של לספק את כל ההקשר שדרוש כדי שהמשימה תהיה פתירה באופן סביר על ידי המודל. באותו חודש הצטרף אנדריי קרפטי (Andrej Karpathy) בניסוח שהפך למצוטט ביותר בתחום: אנשים מקשרים פרומפט עם תיאורי משימה קצרים שנותנים למודל ביום-יום, בעוד שבכל יישום מודל-שפה ברמה-תעשייתית, הנדסת הקשר היא האמנות והמדע העדינים של מילוי חלון ההקשר במידע הנכון בדיוק לצעד הבא. שני הציטוטים מובאים כאן כפי שריכז אותם סיימון ויליסון (Simon Willison) ברשומה מ-27 ביוני 2025.
ההבדל מול הנדסת פרומפטים, שגם לה ערך משלה באתר, אינו הבדל של יוקרה אלא של תחום-אחריות. הנדסת פרומפטים עוסקת בניסוח: איך לכתוב את ההוראה כך שהמודל יבין מה רוצים ממנו. הנדסת הקשר עוסקת בהרכבה: אילו פריטי-מידע בכלל ייכנסו לפנייה הזו, מתוך כמות גדולה בהרבה של מידע שקיים ורלוונטי-אולי, ובאיזה סדר. אותו מסמך של Anthropic מציב את ההבדל כך: הנדסת פרומפטים מתייחסת לשיטות לכתיבה ולארגון של הוראות למודל, ואילו הנדסת הקשר מטפלת במכלול הרחב יותר — כל מה שנמצא בחלון לאורך סוכן שרץ תורות רבים.
למה זה בעיה בכלל: תשומת-לב היא משאב מוגבל
הנחת-היסוד האינטואיטיבית היא שיותר מידע פירושו תשובה טובה יותר. זו בדיוק ההנחה שהתחום הזה קם כדי לסתור.
מסמך Anthropic מנסח את זה במונח תקציב תשומת-לב: למודלי-שפה יש תקציב כזה, שממנו הם מושכים כשהם מפענחים כמויות גדולות של הקשר. ההסבר ההנדסי נעוץ בארכיטקטורת הטרנספורמר, שבה כל טוקן נבחן מול כל טוקן אחר: הכפלת אורך הקלט אינה מכפילה את מספר ההשוואות אלא מגדילה אותו פי ארבעה. המסקנה שהמסמך מסיק מזה היא העיקרון-המנחה של התחום כולו: לחפש את קבוצת הטוקנים הקטנה ביותר שעדיין נושאת את מרב המידע המועיל (במקור: highest-signal), זו שממקסמת את הסיכוי לתוצאה הרצויה. לא הכי הרבה מידע — הכי מעט מידע שעדיין מספיק.
לכך מצטרפות שתי תופעות שנמדדו במחקר ומתוארות בהרחבה בערך חלון הקשר. הראשונה, אבוד באמצע, נמדדה במאמר של נלסון ליו (Nelson F. Liu) ועמיתיו מיולי 2023: הביצועים לרוב גבוהים ביותר כשהמידע הרלוונטי נמצא בתחילת הקלט או בסופו, ומתדרדרים משמעותית כשהמודל נדרש להגיע אליו מאמצע הקשר ארוך — גם במודלים שנבנו במפורש להקשר ארוך. השנייה, ריקבון הקשר, היא ירידה מתמשכת באיכות ככל שהקלט מתארך, גם כשהכול עדיין בתוך החלון. שתיהן אומרות אותו דבר למי שמרכיב את הקלט: המיקום והכמות משנים, ולא רק התוכן.
ארבע הדרכים שבהן הקשר מתקלקל
דרו ברוניג (Drew Breunig), שכתב ביוני 2025 סקירה שהפכה נקודת-ייחוס בתחום, מיין את מצבי-הכשל של ההקשר לארבעה, ולכל אחד שם משלו. הרשימה נותנת מילים לתופעות שכל משתמש-כבד נתקל בהן בלי לדעת איך לקרוא להן.
הרעלת הקשר (Context Poisoning) היא מה שקורה כאשר הזיה או טעות אחרת נכנסת להקשר, ומשם מוזכרת שוב ושוב. הדוח-הטכני של Gemini 2.5, שברוניג מצטט, מתאר צורה חריפה שלה בניסוי משחק: חלקים רבים מההקשר, ובהם המטרות והסיכום, מורעלים במידע-שגוי על מצב-המשחק, ולעיתים קרובות לוקח זמן רב מאוד לבטל את זה.
הסחת הקשר (Context Distraction) היא כשההקשר גדל עד שהמודל מתמקד בו יתר על המידה ומזניח את מה שלמד באימון. אותו דוח מתאר את הסימן: הסוכן נטה לחזור על פעולות מההיסטוריה-הארוכה שלו במקום לגבש תוכניות-חדשות.
בלבול הקשר (Context Confusion) הוא כשתוכן-מיותר שנמצא בהקשר משמש בפועל לייצור תשובה באיכות ירודה — למשל כשמעמיסים על המודל כלים שאינם נדרשים למשימה הנוכחית.
התנגשות הקשר (Context Clash) היא כשמידע וכלים חדשים שנצברו סותרים מידע שכבר נמצא שם. כאן יש מספר מדוד: מחקר של פיליפ לאבאן (Philippe Laban) ועמיתיו ממאי 2025 מדווח שכל המודלים המובילים שנבדקו הציגו ביצועים נמוכים משמעותית בשיחות רב-תוריות לעומת תור-בודד, בירידה ממוצעת של 39 אחוזים על פני שש משימות-ייצור. המחברים מפרקים את הירידה לאובדן קטן ביכולת ולעלייה משמעותית בחוסר-האמינות, ומסבירים שמודלים נוטים להניח הנחות בתורים המוקדמים ולנסות מוקדם מדי לייצר פתרון-סופי, שאחר כך הם נסמכים עליו יתר על המידה.
הכלים של המקצוע: מה נבחר, מה נדחס, מה נזרק
מול הבעיות האלה התגבשו כמה מהלכים חוזרים, ורובם עוסקים בהוצאת מידע החוצה ולא בהכנסתו.
הבחירה מה בכלל נכנס היא הצעד הראשון. במקום להעמיס מראש כל מה שאולי יידרש, מביאים כל פריט ברגע שמתברר שהוא נחוץ. זה בדיוק המנגנון שמאחורי אחזור-מוגבר-בייצור, שיש לו ערך משלו כאן — שליפת הקטעים הרלוונטיים בלבד מתוך מאגר גדול, במקום הזנת המאגר כולו.
מסמך Anthropic מונה שלושה מהלכים למשימות ארוכות במיוחד. דחיסה היא סיכום של תוכן השיחה שנצברה ופתיחת חלון-חדש עם הסיכום המכווץ במקום ההיסטוריה המלאה. רישום מובנה (Structured Note-Taking) הוא כתיבת הערות על ידי הסוכן עצמו, שנשמרות מחוץ לחלון ההקשר ונשלפות בהמשך לפי הצורך — אותו רעיון שמתואר בערך זיכרון סוכן. ארכיטקטורת תת-סוכנים היא הפניית משימה-ממוקדת לסוכן-נפרד, שמחזיר לסוכן המרכז סיכום-מכווץ במקום את כל מה שעבר בדרך.
מעבר לשלושה האלה יש עוד שני מהלכים פשוטים שקל להחמיץ. האחד הוא סדר: מכיוון שמידע באמצע קלט-ארוך נקרא פחות טוב, מיקומם של הפריטים החשובים אינו שרירותי. השני הוא צמצום ערכת-הכלים — לתת לסוכן בכל שלב רק את הכלים שרלוונטיים לשלב הזה, ולא את כל מה שהמערכת יודעת לעשות.
מה זה אומר בפועל, ואיפה עובר הגבול של התחום
למי שאינו בונה מערכות, שלוש מסקנות-מעשיות עולות מכל זה.
הראשונה: שיחה ארוכה מאוד אינה בהכרח שיחה חכמה יותר. כשצ'אט מתחיל לחזור על עצמו, להיצמד להנחה-מוקדמת או לאבד דבר שנאמר בהתחלה, הפתרון הטוב לרוב אינו להסביר שוב באותה שיחה אלא לפתוח שיחה חדשה ולהזין אליה רק את מה שבאמת נחוץ. השנייה: יותר חומר-מצורף אינו בהכרח תשובה טובה יותר, ולעיתים ההפך — מסמך גדול ולא רלוונטי מדלל את תשומת-הלב של המודל בדיוק כמו רעש. השלישית: כשמשהו השתבש בתשובה, שווה לשאול לא רק מה ביקשתי אלא גם מה בכלל היה מונח לפניו כשענה.
ואשר לגבול של התחום — כדאי לשמור עליו חד, כי הוא מיטשטש בשיווק. חלון הקשר גדול יותר הוא תכונה של המודל, לא הישג של הנדסת הקשר; הוא מגדיל את התקציב, ולא מייתר את הצורך לנהל אותו, כפי שמראים אבוד באמצע וריקבון ההקשר. ניסוח מוצלח של הוראה הוא הנדסת פרומפטים. הנדסת הקשר היא מה שנשאר באמצע: ההחלטה החוזרת, לפני כל פנייה, מה מהמידע הקיים ראוי להיכנס הפעם. וכמו כל החלטה כזו היא נמדדת — השאלה אם הרכב-ההקשר השתפר או נשבר אחרי שינוי היא בדיוק מה שהערך הערכת סוכנים עוסק בו.
המעבר כתופעה תעשייתית: LangChain והביקורת הציבורית
השינוי לא נעצר בציוץ בודד. LangChain, אחת מחברות-התשתית המרכזיות לבניית סוכני-AI, פרסמה סדרת-מאמרים תחת הכותרת "עליית הנדסת-ההקשר" (The Rise of Context Engineering), ולנס מרטין מהחברה פירט בספטמבר 2025 חמישה תחומי-עיסוק נפרדים בתוך המקצוע החדש — מבידוד-הקשר במערכות רב-סוכניות, דרך שאלת-הבחירה בין אחזור-מידע (RAG) לחיפוש אגנטי, ועד ניהול-זיכרון מתמשך בין-סשנים. מרטין תיאר את הצורך בכך במונחים מעשיים: משימת-סוכן טיפוסית כוללת סביב חמישים קריאות-כלי, כך שכמות ההקשר שנצבר גדלה במקביל למורכבות המשימה, ולא ניתן עוד להתייחס אליה כניסוח-הוראה חד-פעמי.
השינוי לא התקבל פה-אחד. בדיון פומבי ב-Hacker News מ-4 ביולי 2025 כתב מגיב אחד בחריפות שרה-מיתוג "הנדסת-פרומפטים" ל"הנדסת-הקשר" ו"העמדת-פנים שזה משהו שונה היא בורות במקרה-הטוב והרסנית-טיפשית במקרה-הרע" — בטענה שמדובר באריזה מחדש של רעיונות ותיקים מתחום-אחזור-המידע. המגן על ההבחנה השיב שמדובר בשתי אסטרטגיות-אופטימיזציה מנוגדות: את ההקשר צריך למזער תוך שמירה על המידע הדרוש, בעוד את ההוראות עצמן כדאי להרחיב לפירוט-מרבי כדי למנוע הנחות-שגויות מצד המודל.