Context Engineering — תכנון ההקשר שמודל AI מקבל

מאת צוות מדיה דיל · 09.08.2026 · AI · 7 דק׳

מעבר ל-Prompt Engineering: איך בונים ומנהלים בצורה שיטתית את כל ההקשר שמודל שפה רואה — הוראות, זיכרון, כלים ותוצאות RAG — כדי לקבל תוצאות עקביות וזולות יותר.

צוות שבנה Agent שמתפקד מצוין בדמו, אבל אחרי כמה שבועות בפרודקשן הוא מתחיל "לשכוח" הוראות, מתבלבל בין כלים דומים, ומחזיר תשובות לא עקביות — כמעט תמיד הבעיה היא לא במודל עצמו, אלא במה שמוזן לו. ככל שהמערכת גדלה, נוספים עוד כלים, עוד מסמכי RAG, עוד היסטוריית שיחה — וחלון ההקשר (Context Window) הופך לעמוס, לא ממוין ולפעמים סותר את עצמו. Context Engineering הוא המשמעת שמטפלת בדיוק בזה: לא "איך לנסח פרומפט טוב", אלא איך לתכנן, לסדר ולתחזק את כל המידע שנכנס למודל בכל קריאה.

מה ההבדל בין Prompt Engineering ל-Context Engineering

Prompt Engineering מתמקד בניסוח: איך לכתוב הוראה בצורה שתניב את התוצאה הרצויה. Context Engineering הוא רמה מעל — הוא מטפל בשאלה איזה מידע בכלל נכנס לחלון ההקשר, מאיזה מקור, באיזה סדר, ובאיזה פורמט. באפליקציית צ'אט פשוטה ההבדל לא מורגש, אבל ב-Agent שמתמודד עם כלים, זיכרון והיסטוריה ארוכה, ההקשר מורכב מכמה שכבות: הוראות מערכת (System Prompt), הגדרות כלים זמינים, תוצאות RAG שנשלפו, זיכרון שיחה קודם, ותוצאות ביניים מקריאות כלים. כל שכבה כזו תופסת token budget, וכל שכבה יכולה "להסיח" את המודל אם היא לא רלוונטית לרגע הנוכחי.

איך זה עובד מתחת למכסה המנוע: Context Window כמשאב מוגבל

חלון ההקשר הוא לא זיכרון אינסופי — הוא buffer בגודל קבוע (למשל מאות אלפי tokens, תלוי במודל) שנשלח מחדש בכל קריאת API. שני מאפיינים קריטיים נובעים מכך: עלות — כל token בהקשר משולם בכל בקשה, גם אם הוא לא רלוונטי לשאלה הנוכחית, ואיכות ההיסק — מחקר ותצפיות בפרודקשן מראים שביצועי מודל יורדים ככל שההקשר גדל ומתמלא במידע לא ממוקד, תופעה שמכונה לעיתים Context Rot. מודל שמקבל 50 עמודי תיעוד לא רלוונטי לפני השאלה האמיתית נוטה "לאבד" את הפרטים החשובים באמצע, גם אם טכנית הם נכנסו לחלון.

המשמעות המעשית: המטרה היא לא "למקסם כמה שיותר מידע בהקשר" אלא למצוא את קבוצת המידע המינימלית והרלוונטית ביותר לכל קריאה — עיקרון שמזכיר את ה-precision/recall trade-off בחיפוש מידע קלאסי.

שכבות ההקשר וסדר העדיפויות

מערכת מסודרת בונה את ההקשר משכבות מוגדרות בסדר עדיפויות ברור:

• System Prompt — הוראות קבועות, זהות ה-Agent, מגבלות. יציב ולא משתנה תכופות, ולכן מועמד טוב ל-Prompt Caching.
• הגדרת כלים — רק הכלים הרלוונטיים למשימה הנוכחית, לא כל הכלים הזמינים במערכת.
• מידע שנשלף (RAG/Tool Results) — דינמי, משתנה בכל קריאה, ולכן דורש דחיסה וסינון קפדניים.
• זיכרון שיחה — היסטוריה רלוונטית, לרוב עם sliding window או סיכום של חלקים ישנים.
• הבקשה הנוכחית — השאלה או המשימה שהמשתמש מבקש כרגע.

הסדר משנה: מודלים נוטים לתת משקל גבוה יותר למידע שמופיע קרוב לתחילת ובסוף ההקשר (תופעה שמזכירה את ה-"lost in the middle"), ולכן הוראות קריטיות כדאי למקם ב-System Prompt ובסמוך לבקשה עצמה, לא קבורות באמצע גוש מידע ארוך. בפועל זה אומר שכדאי לבנות את "מרכיב ההקשר" (Context Assembler) כרכיב נפרד באפליקציה, עם אחריות ברורה: לקבל את המשימה הנוכחית, לשלוף את המקורות הרלוונטיים מכל שכבה, לחתוך לפי תקציב טוקנים מוגדר מראש, ולהרכיב את הפרומפט הסופי בסדר קבוע וניתן לבדיקה. כשההרכבה מפוזרת בין כמה מקומות בקוד, קשה מאוד לדעת בדיעבד למה מודל התנהג בצורה מסוימת.

context_budget = {
  "system_prompt": 800,      # קבוע, ממוקם ראשון
  "tool_defs": 1200,         # רק כלים רלוונטיים למשימה
  "retrieved_docs": 3000,    # top-k אחרי rerank, לא raw retrieval
  "conversation_memory": 2000,  # sliding window / סיכום
  "current_turn": 500
}
# total ~7500 tokens מתוך חלון של 128k — לא "ממלאים" את החלון

דחיסה, סיכום וניהול חלון נגלל

כשההיסטוריה גדלה, שתי אסטרטגיות עיקריות מונעות התנפחות: סיכום פרוגרסיבי — כל כמה תורות שיחה, המערכת מסכמת את החלק הישן ומחליפה אותו בתקציר קצר, תוך שמירה על עובדות קריטיות; וsliding window עם עוגן — שמירה על הודעות אחרונות בשלמותן, יחד עם "עוגן" קבוע (למשל מטרת השיחה המקורית) שלא נגזם לעולם. הבחירה בין השתיים תלויה בסוג המשימה: Agent שמנהל שיחת שירות לקוחות יכול להסתפק ב-sliding window, בעוד Agent שמבצע משימה ארוכת טווח (למשל דיבוג קוד לאורך שעות) זקוק לזיכרון מובנה יותר — נושא שמפורט במדריך ארכיטקטורת הזיכרון של סוכנים.

RAG כמקרה פרטי של Context Engineering

כשמזריקים תוצאות חיפוש להקשר, לא מספיק "לשלוף ולהדביק". צריך למיין לפי רלוונטיות אמיתית (לא רק דמיון וקטורי גולמי — ראו Reranking ב-RAG), לגזור לכמות המינימלית שמכסה את השאלה, ולסמן כל קטע במקור שלו כדי שהמודל יוכל לצטט נכון. שגיאה נפוצה היא שליפת 20 מסמכים "ליתר ביטחון" — זה לא רק מבזבז tokens, אלא לרוב פוגע באיכות התשובה כי המודל צריך "לסנן" רעש בעצמו. שיטת עבודה טובה היא צינור דו-שלבי: שליפה ראשונית רחבה יחסית (למשל 30-50 מועמדים) מבוסס דמיון וקטורי, ואז reranker ייעודי שממיין לפי רלוונטיות סמנטית אמיתית ומחזיר רק את חמשת-עשרת הקטעים הטובים ביותר להזרקה בפועל. הפרדה כזו שומרת על recall גבוה בשלב השליפה בלי לשלם את מחיר ה-precision הנמוך בהקשר עצמו.

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

Trade-offs מרכזיים

• עלות מול הקשר עשיר — יותר הקשר = יותר טוקנים = יותר עלות ו-latency, לא בהכרח תוצאה טובה יותר.
• Caching מול טריות — הקשר קבוע (System Prompt, כלים) שנשמר קבוע מאפשר prompt caching זול, אבל דורש משמעת שלא "לזהם" אותו במידע דינמי.
• אוטומציה מול שליטה ידנית — ניתן לבנות "Context Assembler" חכם שבוחר דינמית מה להכניס, אבל זה מוסיף שכבת מורכבות ונקודת כשל נוספת שדורשת ניטור בפני עצמה — ראו LLM Observability.
• עקביות מול התאמה אישית — הקשר שמותאם מאוד לכל משתמש ולכל בקשה נותן תוצאות מדויקות יותר, אבל קשה יותר לבדוק (test) ולתחזק לאורך זמן מאשר תבנית הקשר קבועה וידועה מראש; זו סוגיה מרכזית גם בבניית Evals אמינים.

דוגמה מהשטח

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

טעויות נפוצות בניהול הקשר

• "למקסם" את חלון ההקשר — צוותים רבים מניחים שככל שנותנים למודל יותר מידע, כך התוצאה תהיה טובה יותר. בפועל, הזרקת מידע לא ממוין פוגעת בדיוק ומייקרת כל קריאה, בלי תועלת מקבילה.
• ערבוב הקשר סטטי ודינמי באותה שכבה — כשמידע שמשתנה בכל קריאה (תוצאות RAG) מעורבב עם מידע קבוע (System Prompt) באותו בלוק טקסט, אי אפשר לנצל Prompt Caching בצורה יעילה, וכל שינוי קטן "שובר" את המטמון כולו.
• הזנחת סדר המידע — מיקום הוראה קריטית באמצע גוש טקסט ארוך, כשידוע שמודלים נותנים משקל נמוך יותר למידע "קבור" באמצע ההקשר.
• העדר תקציב טוקנים מוגדר — בניית מערכת בלי הגדרה מפורשת כמה tokens כל שכבה מותר לה לתפוס, מה שמוביל לצמיחה בלתי מבוקרת ככל שמוסיפים כלים ומקורות מידע חדשים לאורך זמן.
• אי-בדיקת ההקשר בפועל — הרבה צוותים בודקים רק את הפרומפט הכתוב מראש, ולא את ההקשר המלא שנשלח בפועל למודל אחרי הרכבה דינמית — כולל תוצאות כלים והיסטוריה. לוגים מלאים של ההקשר בכל קריאה הם קריטיים לניפוי שגיאות, ראו מדריך LLM Observability.

שאלות נפוצות

האם חלון הקשר גדול יותר פותר את בעיית ה-Context Engineering?

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

מה ההבדל בין Context Engineering ל-RAG?

RAG הוא טכניקה אחת לאכלוס הקשר (שליפת מידע ממאגר חיצוני). Context Engineering הוא המשמעת הרחבה יותר שכוללת גם ניהול זיכרון שיחה, בחירת כלים, סדר עדיפויות ודחיסה — RAG הוא חלק ממנה, לא כולה.

איך יודעים שההקשר "עמוס מדי"?

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

האם כדאי לבנות Context Assembler אוטומטי?

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

איך Context Engineering משפיע על עלות?

ישירות — כל token בהקשר נספר בכל קריאה, הן בקלט והן לעיתים בעיבוד פנימי. הקטנת הקשר מיותר היא לרוב הדרך הזולה והמהירה ביותר לצמצם עלויות AI, עוד לפני מעבר למודל זול יותר או אופטימיזציות תשתית מורכבות. ראו AI Cost Engineering.

מי בצוות אחראי על Context Engineering?

בארגונים בשלים זה לרוב תפקיד משותף בין מהנדסי Backend שבונים את צינור ההרכבה לבין מי שאחראי על איכות התשובות — לעיתים בשיתוף עם מי שמתחזק את מאגר הידע עצמו, כי איכות ה-Context Engineering תלויה במידה רבה באיכות המקורות שממנה הוא שואב.

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

תגיות: Context Engineering · Prompt Engineering · Context Window · RAG · LLM · Token Budget

← חזרה לבלוג · צור קשר