Context Engineering
הדיסציפלינה החמה של 2026: לא רק מה אתה שואל את המודל, אלא מה אתה שם לו בחלון ההקשר. זה מה שמפריד בין מערכת שעובדת למערכת ש"מתבלבלת".
מה זה Context Engineering
אם Prompt Engineering הוא לנסח נכון את ההוראה, Context Engineering הוא הצעד הרחב יותר: לנהל את כל מה שנכנס לחלון ההקשר של המודל בכל קריאה — ההוראות, הידע שנשלף, ההיסטוריה, תוצאות הכלים והדוגמאות. בשנת 2026, כשמערכות הפכו לסוכנים מרובי-שלבים, זו הפכה למיומנות הקריטית ביותר.
הרעיון המרכזי: המודל טוב רק כמו ההקשר שנתת לו. תזרוק לו יותר מדי מידע לא רלוונטי — הוא יתבלבל ויתייקר. תיתן לו מעט מדי — הוא ינחש. Context Engineering זה למצוא את התמהיל הנכון: המידע הנכון, בכמות הנכונה, בסדר הנכון.
"רוב כשלי ה-LLM בייצור הם לא כשלי מודל — הם כשלי הקשר." יותר מדי, פחות מדי, או מידע לא רלוונטי בחלון.
חלון ההקשר והבעיות שלו
חלון ההקשר (context window) הוא כמות הטקסט (בטוקנים) שהמודל יכול "לראות" בקריאה אחת. גם כשהוא ענק, יש שלוש בעיות אמיתיות:
- Lost in the middle: מודלים נוטים לשים לב יותר לתחילת ולסוף ההקשר, ופחות לאמצע. מידע קריטי שקבור באמצע עלול "להיעלם".
- Context rot: ככל שההקשר מתארך ומצטבר (בשיחה או בסוכן), האיכות יורדת — המודל מתבלבל בין פרטים ומאבד מיקוד.
- עלות וזמן: כל טוקן בהקשר עולה כסף וזמן. הקשר מנופח = חשבון גדול ותגובה איטית.
המסקנה: יותר הקשר זה לא בהכרח יותר טוב. המטרה היא הקשר רלוונטי ותמציתי, לא מקסימלי.
מרכיבי ההקשר
הקשר טוב מורכב מכמה חלקים, וכל אחד צריך ניהול:
- System prompt / הוראות: תפקיד, כללים, פורמט. יציב יחסית.
- ידע שנשלף (RAG): הקטעים הרלוונטיים ביותר ממאגר הידע — לא הכל, רק הרלוונטי.
- היסטוריית שיחה: הודעות קודמות. הראש שגדל ומצריך ניהול.
- תוצאות כלים: פלטים מ-tool calls (חיפוש, API). יכולים להיות ענקיים.
- דוגמאות (few-shot): 1-3 דוגמאות שמכוונות את המודל.
- השאילתה הנוכחית: מה שהמשתמש שאל עכשיו.
טכניקות מרכזיות
1. אחזור סלקטיבי (Retrieval)
במקום לדחוף מסמך שלם, שלוף רק את הקטעים הרלוונטיים עם RAG. זה הכלי הבסיסי לצמצום הקשר בלי לאבד מידע.
2. דחיסה וסיכום (Compression)
כשההיסטוריה או תוצאת כלי גדולה מדי — מסכמים אותה לפני שמכניסים להקשר. למשל, בשיחה ארוכה: סכם את ה-10 הודעות הראשונות לפסקה, ושמור מלאות רק את האחרונות.
3. סדר וממשק (Ordering & Structuring)
שים את המידע הקריטי בהתחלה או בסוף (לא באמצע). השתמש בתגיות/כותרות ברורות (<knowledge>...</knowledge>) כדי שהמודל יבחין בין חלקים. מבנה ברור משפר דיוק.
4. ניהול זיכרון (Memory)
לא הכל צריך להיות בכל קריאה. שמור "זיכרון ארוך-טווח" (העדפות משתמש, עובדות) בנפרד, ושלוף רק את הרלוונטי לכל אינטראקציה — בדיוק כמו RAG, אבל על זיכרון.
5. גיזום תוצאות כלים (Tool result pruning)
כלי שמחזיר 5,000 שורות JSON — אל תכניס הכל. סנן/סכם לפני שמחזירים למודל. זו אחת הבעיות הגדולות בסוכנים.
האתגר הגדול: הקשר בסוכנים
בסוכן מרובה-שלבים, ההקשר מצטבר — כל שלב מוסיף מחשבה, קריאת כלי ותוצאה. אחרי 15 שלבים, ההקשר מנופח, יקר, וסובל מ-context rot. זו הסיבה שסוכנים "מתפרקים" במשימות ארוכות.
אסטרטגיות שעובדות:
- סיכום ביניים: כל כמה שלבים, סכם את ההתקדמות ו"אפס" את ההיסטוריה המפורטת.
- Sub-agents: פצל משימה לסוכני-משנה, כל אחד עם הקשר נקי משלו, והחזר רק את התוצאה.
- Scratchpad חיצוני: שמור מצב/ממצאים מחוץ להקשר (קובץ/DB) ושלוף לפי צורך במקום לגרור הכל.
- גיזום אגרסיבי של תוצאות כלים: שמור רק את מה שדרוש להמשך.
טעויות נפוצות
- "יותר הקשר = יותר טוב". הטעות הנפוצה. הקשר מנופח פוגע בדיוק ובעלות.
- לזרוק מסמך שלם. במקום לשלוף את הקטע הרלוונטי בלבד.
- לא לנהל היסטוריה בסוכן. ההקשר תופח עד שהמערכת קורסת.
- מידע קריטי באמצע. נעלם בגלל lost in the middle. שים בהתחלה/סוף.
- הקשר לא מובנה. ערבוב הוראות, ידע והיסטוריה בלי הפרדה מבלבל את המודל.