Context Compression: איך מצמצמים חלון הקשר בלי לאבד מידע קריטי

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

עלות וזמן מול תופעת Lost in the Middle, סיכום היררכי, דחיסה סלקטיבית דרך RAG, דחיסה מבנית, Prompt Caching, ומדידת אובדן מידע.

חלון הקשר גדול יותר נשמע כמו פתרון פשוט לכל בעיית מידע — עד שמגלים ששיחה או מסמך ארוכים באמת עדיין עולים יותר, מגיבים לאט יותר, ומודל שמקבל הקשר ארוך נוטה "לאבד" מידע שנמצא באמצע (תופעת Lost in the Middle). דחיסת הקשר היא הדיסציפלינה של לצמצם כמות טוקנים בלי לאבד את המידע שבאמת קריטי להחלטה הבאה.

הבעיה הכפולה: עלות וזמן, לא רק גודל חלון

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

סיכום: הדחיסה הפשוטה והנפוצה ביותר

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

דחיסה סלקטיבית: RAG כצורה של דחיסה

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

דחיסה מבנית: מטקסט חופשי לנתונים ממוקדים

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

Prompt Caching: פתרון עלות, לא פתרון גודל

כמה ספקי מודלים מציעים Caching של חלק קבוע בתחילת ההקשר (למשל הנחיות מערכת קבועות) כך שהוא לא מחויב מחדש בכל קריאה. זה חוסך עלות משמעותית להקשר שחוזר על עצמו, אבל לא פותר את בעיית הגודל או את בעיית Lost in the Middle — זה שיפור כלכלי, לא שיפור איכות תשובה.

מדידת אובדן מידע: איך יודעים שהדחיסה לא הרסה משהו קריטי

דחיסה שמצמצמת טוקנים אבל מוחקת עובדה שקריטית להחלטה מאוחרת יותר גרועה מלא לדחוס בכלל. הבדיקה הנכונה היא לא רק "כמה טוקנים נחסכו" אלא הרצת ערכת שאלות בדיקה (Eval Set) שמוודאת שהמידע החיוני עדיין ניתן לשליפה נכונה אחרי דחיסה — לא הנחה תיאורטית שהתקציר "בטח תפס את העיקר".

שילוב עם ניהול זיכרון: שתי בעיות קרובות, לא זהות

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

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

דחיסה דינמית לפי חשיבות: לא כל המידע שווה

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

Sliding Window על היסטוריית שיחה

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

דחיסת פלטי כלים: כשתוצאת API ארוכה מדי

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

דחיסה בזמן אמת מול דחיסה מתוזמנת ברקע

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

בדיקת Regression אחרי שינוי אסטרטגיית דחיסה

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

דחיסה עם אובדן מבוקר מול דחיסה חסרת אובדן

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

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

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

שאלות נפוצות

האם דחיסת הקשר תמיד פוגעת באיכות התשובה?

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

מתי כדאי סיכום ומתי RAG?

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

האם דחיסה נדרשת גם במודלים עם חלון הקשר ענק?

כן — גם כשהחלון הטכני של המודל גדול מספיק להכיל את כל התוכן בקלות, עלות וזמן העיבוד עדיין עולים באופן ליניארי עם כל טוקן נוסף, ותופעת Lost in the Middle עדיין רלוונטית ונכונה גם בחלונות גדולים. חלון גדול נותן יותר גמישות ומרווח תמרון, אבל לא מבטל את התועלת המעשית שבדחיסה חכמה של מה שבאמת נכנס להקשר בסופו של דבר.

כמה תכוף צריך לדחוס הקשר בשיחה ארוכה?

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

אפשר לשלב כמה שיטות דחיסה יחד באותה מערכת?

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

תגיות: Context Compression · LLM · RAG · Prompt Engineering · AI

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