מדוע Contextual Compression RAG נתקל במגבלת הקונטקסט
הכשל הקלאסי נראה כך: בסיס ידע של תקנות וחוזים ארוכים, שאלה של משתמש, והחיפוש מחזיר כמה עשרות קטעים. לחלון הקונטקסט של המודל נכנס רק חלק, והשאר נזרק לפי סימן פורמלי — לעיתים קרובות יחד עם אותה פסקה בודדת שבה טמונה התשובה. כלפי חוץ המערכת ממשיכה לעבוד: התשובה מגיעה, יש הפניה למקור, אבל העובדה הנדרשת אינה שם.
החצי השני של הבעיה — רעש. כדי לא לאבד דבר, מגדילים את עומק הדגימה, ולחלון נכנסים קטעים עם מילים תואמות אבל נושא אחר: ניסוחים דומים, סעיפים תבניתיים, מהדורות מיושנות של המסמך.
במסמכים ארוכים ההידרדרות בולטת במיוחד: המודל ממצע כמה גרסאות של אמת ומייצר תשובה בטוחה אך שגויה, שקשה לתפוס בבדיקת הקבלה.
חיתוך פשוט של ההתחלה והסוף של הקטע חוסך מקום, אבל משאיר מהפסקה קטעים קרועים בלי הקשר. לכן הדחיסה נעשית סמנטית: כל קטע מתקצר למשפטים שבאמת עונים על השאלה, תוך שמירה על הזיקה לטקסט המקור. לחלון נכנסים יותר מקורות שונים שעונים לעניין, ולא יותר קטעים דומים זה לזה.
אנחנו מפרטים כיצד זה נסגר: היכן למקם את הדחיסה — לפני או אחרי הדירוג, כיצד לשמר ציטוטים ובדיקוּת של מקורות, מה לעשות כשהדחיסה עצמה מתחילה לזרוק תוכן רלוונטי, ולפי אילו מדדים רואים שהאובדן של עובדות נפסק.
האפקט של דחיסת הקונטקסט: דיוק, מהירות, נפח
דחיסת קונטקסט אינה ניקוי קוסמטי של השאילתה, אלא חלוקה מחדש של תשומת הלב של המודל. החיפוש מחזיר עשרים קטעים, כל אחד רלוונטי לשאלה רק באופן חלקי, ובלי דחיסה הם עוברים למודל בשלמותם ומתחרים זה בזה. אנחנו חותכים את המיותר — ובחלון נשארים רק המשפטים שבאמת עונים על השאלה.
דיוק: פחות רעש — פחות שגיאות
כל קטע עובר סינון ודחיסה חוזרים: נחתכים חלקים שאינם נוגעים לשאלה, כפילויות מתמזגות. שיעור הקטעים שנזרקים בקורפוסים טיפוסיים — 60–85%. שיעור התשובות הנכונות עולה בעיקר במקומות שבהם המודל התבלבל קודם בין מסמכים קרובים בנושא: בסטים פנימיים של שאלות העלייה היא 15–25 נקודות אחוז.
מהירות: קונטקסט קצר יותר — תשובה מוקדמת יותר
נפח הטקסט המועבר למודל מצטמצם פי 3–5. המודל מעבד פחות נתונים, וזמן הכנת התשובה יורד בהתאם — זה ניכר גם בשאילתות בודדות וגם בעיבוד מרוכז של ארכיון מסמכים.
נפח: מקום למקורות נוספים
המקום שהתפנה בחלון מוקדש למסמכים חדשים: במקום שלושה, באותה מגבלה נכנסים עשרה, והשאלה נסגרת בלי פיצול לכמה פניות. את המכניקה של הסינון והדירוג מחדש אנחנו בונים על כלים כמו LangChain — כללי הרלוונטיות נשארים שלכם ומותאמים לקורפוס, ולא קבורים בפתרון של מישהו אחר.
מצבי דחיסת קונטקסט ל-RAG: השוואת גישות
אפשר לדחוס קונטקסט בשלושה שלבים שונים — לפני החיפוש, בתוכו ואחרי ההחזרה, והמצבים האלה לא מחליפים זה את זה אלא משלימים זה את זה.
כל אחד נותן פשרה משלו בין שלמות התשובה לעלות העיבוד, ולכן כדאי לבחור לפי המקום שבו הדיוק הולך לאיבוד: בניסוח השאילתה, בדירוג, או בנפח הקטעים שעוברים למודל.
השוואת המצבים
| מצב | מתי מתאים | במה מוגבל |
|---|---|---|
| דחיסה בשלב החיפוש: ניסוח מחדש של השאילתה, חיתוך תנאים מיותרים | שאילתות דיאלוגיות ורבות־רכיבים עם ניסוח רועש | אובדן של ישויות נדירות וסימונים מדויקים; נוסף קריאה למודל על כל שאילתה |
| דחיסה בתוך החיפוש: תקצירים מחושבים מראש וקטעים קטנים | קורפוס אחיד, חזרות, נפח מסמכים גדול | עריכה של מסמך דורשת חישוב מחדש של הייצוגים; התקציר מסתיר פרטים |
| סינון קטעים אחרי החיפוש: סף רלוונטיות, מטא-נתונים | אינדקס רועש, הרבה כמעט-כפילויות | סף נוקשה חותך תוכן שימושי; נדרש כיול לפי תיוג |
| דירוג מחדש אחרי החיפוש באמצעות מודל דירוג מדויק | הסדר חשוב, מאגר המועמדים מוגבל | השהיה על כל שאילתה; לא מתאים לקנה מידה של האינדקס כולו |
| חילוץ משפטים רלוונטיים מתוך הקטע שנמצא | קטעים ארוכים בתקציב קונטקסט צר | סיכון לקריעה של המשמעות; נדרשת בקרה על שלמות התשובה |
בפועל משלבים בין המצבים: סינון לפי סף חותך רעש ברור לפני דירוג מחדש יקר, וחילוץ משפטים מהדק את תקציב הקונטקסט בשלב האחרון. סדר ההפעלה כאן חשוב יותר מהסט עצמו — דירוג מחדש לפני סינון הוא חסר טעם, הוא רק יסדר בקפידה את מה שממילא ייזרק.
כיצד אנחנו מטמיעים דחיסה: מניתוח הקורפוס ועד למסירה
דחיסה אינה «חיתוך» של הקטעים שנמצאו, אלא החלפה של מה שנכנס בכלל לקונטקסט של המודל. לכן אנחנו מתחילים במלאי של הקורפוס: היכן נמצאים המסמכים, באיזו תדירות הם משתנים, אילו סעיפים נושאים משמעות ואילו משכפלים זה את זה במהדורות שונות. משם העבודה מתקדמת בשלבים, ובכל שלב יש תוצאה ניתנת לבדיקה, ולא רק שירות מוגדר.
- ניתוח קורפוס המסמכים. אוספים את המקורות, מתייגים סוגים (תקנות, חוזים, התכתבויות, ספרי עזר), מסירים כפילויות ומהדורות מיושנות. בפלט — מפת קורפוס עם תדירות עדכון לכל מקור.
- תכנון סכמת בחירת הקטעים. קובעים לפי אילו יחידות לחפש (סעיף, פסקה, נקודה), כמה מועמדים להעלות במעבר הראשון ולפי איזה סימן לפסול את המיותר. את גבולות החיתוך מקבעים כך שהתשובה לא תאבד משמעות במפגש בין הקטעים.
- הגדרת הדחיסה. בוחרים סינון לפי קרבה סמנטית וניסוח מחדש של השאילתה, קובעים סף שמתחתיו הקטע לא נכנס כלל לקונטקסט, ומגבלת נפח. חלק מהשאילתות שאינן דורשות חיפוש נחתכות מיד בכניסה.
- הרכבת סט בדיקה. מרכיבים שאלות עם מקורות נכונים ידועים מראש — כולל מקרים שבהם התשובה הנדרשת מפוזרת על פני כמה מסמכים, ושבהם השאלה מנוסחת אחרת מהטקסט.
- מדידת איכות. מחשבים את שיעור השאילתות עם המקור הנכון בקונטקסט, את שלמות התשובה, את הנפח הממוצע של הטקסט המועבר ואת זמן התגובה. משווים לגרסה המקורית בלי דחיסה — לפי כל סוג מסמך בנפרד.
- נוהל עדכון. מתארים כיצד מסמכים חדשים נכנסים לקורפוס, מי מאשר מחיקה של מיושנים, באיזו תדירות נבנה האינדקס מחדש ובאילו סטיות במדידות מופעלת הגדרה מחדש.
- מסירה. מוסרים קונפיגורציות, את סכמת הבחירה, את סט שאלות הבדיקה והוראות מדידה, כדי שהצוות ילווה את הפתרון בעצמו.
רשימת השלבים אינה נוקשה: אם הקורפוס קטן ואחיד, שלבים 1 ו-4 מתנהלים כמעט במקביל, וההגדרה תופסת מחזור אחד. תארו את המשימה — נחזור עם הערכה ותוכנית עבודה לפי המקורות שלכם.
ארטיפקטים של ההטמעה: קונפיגורציות, סכמות, תיעוד
אחרי הפעלת דחיסת קונטקסט במסלול החיפוש בבסיס הידע, נשאר לצוות הלקוח לא רק שירות עובד, אלא גם סט שלם של ארטיפקטים. בלעדיהם כל שינוי — החלפת מודל, מקור חדש או בחינה מחדש של הספים — הופך להנדסה לאחור מתוך הקוד. להלן רשימת מה שאנחנו מוסרים ומפרטים יחד עם המהנדסים שלכם.
- קונפיגורציית הבחירה. ספי רלוונטיות, כללי הסרת כפילויות, עדיפות מקורות ומגבלת נפח הקונטקסט. נמצאת בקובץ נפרד — משתנה בלי לבנות מחדש את השירות.
- סכמת עיבוד השאילתה. המסלול משאלת המשתמש ועד לתשובה: ניתוח, חיפוש מועמדים, דחיסה, הרכבת הקונטקסט, קריאה למודל — עם נקודות כשל ומקומות הפעלה של המסננים.
- כללי גישה לנתונים. הפרדה לפי תפקידים ויחידות: אילו אוספים זמינים לעובד ומה נחתך לפני השליחה למודל.
- נוהל עדכון האינדקס. תדירות האינדוקס מחדש, סדר חיבור מסמכים חדשים, טיפול ברשומות מחוקות ומיושנות.
- סט בדיקות איכות. שאלות ייחוס עם הקטעים הצפויים ומדדי פגיעה — הרצה לפני כל שינוי בהגדרות.
- תיעוד ונוהלים. תיאור הקונפיגורציה, סכמת זרימת השאילתה, הוראות תפעול, סדר חזרה לגרסת הגדרות קודמת.
- לוגים ולוח ניטור. מה נכתב על כל שאילתה, היכן לראות את שיעור הכשלים ואת זמן התשובה.
אנחנו מוסרים לא כארכיון, אלא כפירוט: עוברים על כל סעיף עם הצוות שלכם, כדי שמכאן והלאה השינויים ייעשו באופן עצמאי.
מקרה בוחן: צמצמנו את נפח הקונטקסט, הדיוק עלה
הלקוח — אסיסטנט של תמיכה פנימית, שהשיב מתוך בסיס של תקנות והוראות: החיפוש עבד על אינדקס וקטורי, ולשאילתה למודל עברו שמונה קטעים שנמצאו. בנקודת הפתיחה זה נתן קונטקסט בנפח של כחמישה עשר אלף טוקנים, שיעור תשובות נכונות של 61% ושבע-שמונה שניות לתשובה.
המהנדסים ראו כשל אופייני: כשהשאילתה התאימה חלקית לפסקה, המודל ציטט בביטחון סעיף שבו הופיעו אותן מילים, אבל המשמעות הייתה אחרת.
הניתוח הראה שהבעיה אינה במודל, אלא בהרכב הקונטקסט — לתוכו נכנסו פסקאות סמוכות במסמך שאינן קשורות לשאלה. הוספנו שכבת דחיסת קונטקסט מבוססת LangChain: כל קטע שנמצא עובר מודול חילוץ ומשאיר רק משפטים רלוונטיים לשאילתה לפי משמעות, לא לפי התאמת ניסוחים. אחר כך הקטעים המוקטנים עוברים דירוג מחדש, וכל מה שמתחת לסף הרלוונטיות לא נכנס לקונטקסט בכלל.
המדדים אחרי השיפור. נפח הקונטקסט הצטמצם פי 3.4 — אותם שמונה מקורות נכנסים בערך לארבעת אלפים וחצי טוקנים. שיעור התשובות הנכונות עלה מ-61% ל-84% על מדגם בדיקה קבוע של 400 שאלות, וזמן התשובה ירד לשלוש שניות: המודל מעבד פחות נתוני קלט ופחות «רעש».
התוצאה העיקרית — לא ההאצה, אלא סוג כשל שחוסל. התשובות «בהשראת פסקה דומה» נעלמו: המערכת או נותנת ציטוט מדויק מהתקנון, או מודיעה שאין בבסיס סעיף מתאים. כשל כזה נראה למשתמש מיד ואינו מערער את האמון באסיסטנט.
במה שונה דחיסה בזמן החיפוש מדחיסה בזמן התשובה?
נקודת הדחיסה היא המקום במסלול שבו קטע ארוך הופך לתמצית קצרה. יש שתי אפשרויות: לדחוס מיד אחרי החיפוש, כשהמועמדים רק נבחרו לפי קרבה לשאילתה, או מאוחר יותר — כשהקונטקסט נבנה עבור שאלה מסוימת. מהבחירה הזו תלוי מה בדיוק אנחנו מייעלים: את מהירות התגובה או את שלמות התשובה.
דחיסה בזמן החיפוש מעבדת כל קטע שנמצא באופן בלתי תלוי ולפני שהרכב הקונטקסט הסופי ידוע. הפעולה זולה: היא מצמצמת את הנפח שיעבור אחר כך למודל ומפחיתה את השהיית העיבוד. הצד השני — חלק מהפרטים נחתך בלי לראות, והסתייגות חשובה עשויה לא להגיע ליצירה.
דחיסה בזמן התשובה עובדת עם סט שכבר נבחר ויודעת את ניסוח השאלה, ולעיתים גם טיוטה של התשובה. איכות הבחירה כאן גבוהה יותר: התמצית נבנית למשימה מסוימת, ולקונטקסט נכנסות בדיוק אותן צירופים שנדרשים להסקה. המחיר — השהיה: הפעולה נמצאת במסלול הקריטי של היצירה, ולא ברקע.
הפשרה העיקרית — דיוק מול נפח. ככל שאנחנו דוחסים חזק יותר, כך הקונטקסט קומפקטי יותר והתשובה מהירה יותר, אבל הסיכון לאבד מספר, תנאי או שלילה שהמשמעות תלויה בהם גבוה יותר. דחיסה רכה מדי מחזירה אותנו לבעיה המקורית: קונטקסט עמוס מדי, תשומת לב מפוזרת של המודל ועלייה בזמן העיבוד.
בפועל נוטים לקחת סכמה דו-שלבית: מסנן גס בשלב החיפוש חותך רעש ברור, ומסנן מדויק בשלב התשובה משאיר את העיקר. את השלבים מודדים בנפרד — שיעור הקטעים הנדרשים בקונטקסט הסופי, ההשהיה בכל שלב, וכמה תשובות נפגעו בדיוק בגלל הדחיסה.
שאלות של מהנדסים: מגבלות ומלכודות של הדחיסה
דחיסה מצמצמת את נפח הקונטקסט, אבל לא תמיד משפרת את התשובה. להלן הספקות שאנחנו סוגרים לפני ההתחלה: היכן הגישה מאבדת היגיון, האם נדרש אימון נוסף, כיצד היא מתיישבת מעל החיפוש הקיים ובאילו מדידות מאשרים את האפקט.
האם המשמעות לא תאבד בדחיסה?
הסיכון אמיתי: הדוחס זורק כל מה שנחשב ללא רלוונטי, ובשאלות מורכבות («השווה את התנאים של שני חוזים») הוא עלול לחתוך חצי מהנדרש. אנחנו מחזיקים שני מצבים — חילוץ משפטים רלוונטיים וכתיבה מחדש תוך שמירה על מספרים והפניות — ובוחרים מצב לפי סוג השאילתה, לא באופן גורף. בודקים לא «התקצר», אלא «התשובה לא השתנתה».
האם נצטרך לאמן את המודל מחדש עבור התחום שלנו?
בדרך כלל לא. המודל הבסיסי עובד בביטחון על טקסטים בשפה כללית, וכישלונות בטרמינולוגיה שלכם נסגרים עם מילון תחומי, מילות עצירה וכללים על מבנה המסמכים. אימון נוסף מוצדק במקומות שבהם בקורפוס יש ז'רגון עקבי וטבלאות שדוחס כללי חותך בגבולות שגויים.
כיצד זה משתלב בחיפוש שכבר עובד?
דחיסה היא שכבה אחרי החיפוש והדירוג מחדש, לא תחליף: האינדקס, סכמת האחסון ושאילתות הלקוח לא משתנים. מתווסף שלב שמקבל את הקטעים המובילים ומוסר למודל סט מקוצר — ב-LangChain זהו רטריבר נפרד. אם החיפוש בנוי על מנוע אחר, אנחנו מתחברים דרך ממשק התוכנה שלו ומשאירים מתג לחזרה לאחור. בעדכון מסמך מבוטלים רק הייצוגים הדחוסים שלו — שאר הקורפוס נשאר חם.
איך לדעת שיש אפקט?
מריצים סט אחד של שאלות עם מקורות ייחוס בשתי גרסאות — עם דחיסה ובלעדיה. מסתכלים על ארבעה מספרים: שיעור התשובות עם הפניה נכונה למקור, גודל הקונטקסט הממוצע, זמן התשובה ושיעור השאילתות שבהן הדחיסה חתכה את הנדרש. את ההחלטה מקבלים לפי התמונה הכוללת, לא לפי חיסכון בנפח.
נדבר על המשימה: אילו נתונים נדרשים להערכה
כדי לחשב את האפקט של Contextual Compression, אנחנו צריכים לא גישה למסלול העבודה, אלא פרוסת נתונים והגדרות החיפוש הנוכחיות. להלן המינימום שאחריו נחזור עם הערכה ותוכנית עבודה, ולא עם הרהורים כלליים.
- הרכב הקורפוס: כמה מסמכים, אורך ממוצע ומקסימלי, פורמטים (PDF, DOCX, HTML, טבלאות), שיעור הסריקות וההוצאות ממערכות מידע.
- דוגמאות לשאילתות: 50-100 ניסוחים אמיתיים של משתמשים עם התשובה הצפויה — לפיהם מחשבים את שלמות התוצאות לפני ואחרי דחיסה.
- סכמת החיפוש הנוכחית: כיצד נבנה האינדקס, לפי אילו שדות מתבצע הסינון, כמה מועמדים נלקחים בקלט והיכן מיושם הדירוג.
- עבודה עם קונטקסט: איזה חלק מהמסמך עובר למודל, כיצד נחתכים קטעים ארוכים, והאם היו כשלים בגלל הצפת החלון.
- מגבלות: פריסה בשירות חיצוני או במסלול סגור, זמן תשובה מותר, דרישות לאחסון ולזכויות גישה.
- מדדי איכות: כיצד אתם מודדים כיום את התוצאה — דיוק הפגיעה, שיעור התשובות «לא נמצא», פניות חוזרות לתמיכה.
לפי הנתונים האלה אנחנו מרכיבים מדידה על הקורפוס שלכם: מתעדים את המדדים הנוכחיים, מוסיפים דחיסה בשלב בחירת הקטעים ומשווים. את תוכנית העבודה נפרט לפי שלבים — הכנת נתונים, הגדרת דחיסה, מדידה, מסירת תיעוד. תארו את המשימה בצורה חופשית, ואת השאר נברר בעצמנו.







