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

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

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

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

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

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

הגדלה

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

לכן, מקטע טוב צריך לעשות שלושה דברים:

לקדם את הדיוק על ידי הצגת הראיות המדויקות הנדרשות לביסוס התגובה של המודל.

להפחית את זמן ההשהיה והעלויות על ידי הסרת הקשר לא רלוונטי לפני קריאת מודל השפה הגדול (LLM).

להבטיח יכולת מעקב על ידי שמירה על נאמנות הציטוטים והשארת ניסוח המקור ללא שינוי.

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

מקטעים כדחיסה המודעת לשאילתה

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

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

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

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

לדוגמה, שקול את השאילתא ואת התוצאה הנשלפת הזו:

הגדלה

פלט מודל סביר יהיה לבחור את המשפט המודגש: "ב-Comet, העוזר יכול ...".

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

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

אנו מפתחים את המודל שלנו תוך מחשבה על ثلاثة שיקולים עיקריים: הבנה משותפת של שאילתא והקשר, בחירה ברמת המשפט בעלת הגרגור העדין, ויעילות להשתלב במסגרת תקציב זמן שהיה הדוק ביותר.

ארכיטקטורת מודל

אנו משתמשים במודל דיפוזיה מסוג pplx כבסיס. זוהי אותה משפחת מודלים העומדת מאחורי pplx-embed-v1, וגם העבודה האקדמית הקודמת שלנו, Diffusion-Pretrained Dense and Contextual Embeddings, וגם מדדי הביצועים שלנו בפרודקשן מאשרים שהוא מקודד דו-כיווני חזק עבור זוגות שאילתא-הקשר. אחת התכונות המרכזיות ממשפחה זו של מודלים היא הקשר דו-כיווני: כל ייצוג אסימון יכול להתייחס לשאילתא המלאה ולהקשר המועמד המלא לפני שהמודל מחליט מה יש לשמור.

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

צינור פיקוח (Supervision pipeline)

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

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

לאחר מכן התאמנו את המקטעים המוחזרים חזרה לטקסט המקור. באופן לא מפתיע, רוב פלטי השופט היו כבר העתקים מדויקים: התאמת מחרוזות נאיבית שחזרה 98% מהמקטעים. הוספת מעבר התאמה פשוט מבוסס ביטוי רגולרי (regex) הביאה את שחזור המקטעים ל-100%. זה העניק לנו מקטעים אמינים ומפורטים שניתן להמיר לפיקוח שמירה/הסרה ברמת האסימון.

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

باستخدام צינור זה, תייגנו 750 אלף זוגות שאילתא-מסמך והשתמשנו במקטעים המתקבלים כדי לאמן את ראש הדחיסה עם אנטרופיה צולבת בינארית. תהליך זה מאפשר למודל הדחיסה המודע לשאילתות שלנו לשמור על טקסט המקור ללא שינוי תוך הסרת הקשר שאינו סביר שיעזור למודל במורד הזרם לשרת את בקשת המשתמש.

הבטחת זמן שהיה בזמן אמת

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

השאלה המעשית היא כמה מקיבולת המודל אנו יכולים להסיר בבטחה לפני שאיכות הדחיסה מתחילה להידרדר. אנו משווים את בסיס דיפוזיה pplx המלא בעל 28 השכבות מול גרסאות של 11 ו-17 שכבות המיוצרות על ידי קיצוץ שכבות ומכוונות לנתיב החיפוש. עבור כל אחת מהן, אנו סורקים את סף הדחיסה ומודדים שתי כמויות: המספר הממוצע של אסימוני הקשר הנשלחים במורד הזרם לכל שאילתא, ושבר הראיות השימושיות הנשמרות לאחר הדחיסה.

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

כדי לסגור פער זה, אנו משתמשים בזיקוק ידע ברמת האסימון (token-level knowledge distillation). הגישה שלנו שגרתית: אנו מעשירים את הפסד הבדיקה הסטנדרטי במונח אנטרופיה צולבת רכה על תחזיות מודל המורה (teacher model), המושוקל על ידי מקדם זיקוק. די בכך כדי להביא את מודל הלומד לשוויון, מה שמאפשר לנו לעבור במלואו למודל בעל 17 השכבות המזוקק בפרודקשן. מודל פרודקשן חדש זה מניב ירידה של 35-40% בהשהיית ההיסק וירידה של 40-45% בחישוב ה-GPU המצרפי ללא ירידה באיכות ביחס למורה בעל 28 השכבות. זמן ההשהיה בפרודקשן עומד על מתחת ל-20 מילישניות (p99): קטן מספיק כדי להוסיף לנתיב ההגשה תוך הפחתה ניכרת של סך האסימונים המועברים למודל המענה.

הגדלה

איכות ויעילות אסימונים

אנו משתמשים ב-Agent API של Perplexity כסביבת בדיקה לניתוח היעילות של דחיסת הקשר. אנו מעריכים שלוש הגדרות מוקדמות (presets) של Agent API:

הגדרת הקשר מוקדמת “נמוכה” (low) המגבילה את תקציב האסימונים לכל קבוצת תוצאות ל-1000 אסימונים.

הגדרת הקשר מוקדמת “בינונית” (medium) המגבילה את תקציב האסימונים לכל קבוצת תוצאות ל-4000 אסימונים.

הגדרת הקשר מוקדמת “גבוהה” (high) המגבילה את תקציב האסימונים לכל קבוצת תוצאות ל-10000 אסימונים.

גם הגדרות הסטנדרט, ללא דחיסה, והדחיסה מוגדרות לכבד תקציבי אסימונים אלו.

חיפוש סוכני רב-שלבי (BrowseComp)

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

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

הגדלה

דחיסה מספקת גבול פארטו חדש לאורך כל החזיתות. עבור כל הגדרה, הצגת דחיסה מפחיתה את השימוש באסימונים ברמת השאילתא ב-10% עד 70%, עם רווחי דיוק הנעים בין 4 ל-4.81 אחוזים. הצגת דחיסה מאפשרת אפילו להגדרה המוקדמת “הנמוכה” שלנו להתעלות על ההגדרה “הגבוהה” ללא דחיסה, וכל זאת תוך הפחתת השימוש באסימונים ביותר פי שלושה.

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

SimpleQA: עובדתיות חד-שלבית

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

כמו קודם, אנו מתווים את הדיוק מול ממוצע סך הטוקנים לכל משימה באמצעות ה-prompt הקנוני של השופט. איור 4 מציג את חזית ציון-טוקנים בהקשר החד-שלבי הזה. אף שעלויות האפקט קטנות יותר בהקשר החד-שלבי, אנו שוב רואים כי הדחיסה משפרת בו-זמנית את הדיוק ואת היעילות בכל קביעות-הקדם, ובכך יוצרת חזית פארטו חדשה. עם הפעלת הדחיסה, קביעת-הקדם הבינונית משיגה דיוק של 95% עם ממוצע של 200 טוקנים בלבד לכל מסמך. בהתחשב באורך הממוצע של מסמך, שעומד על יותר מ-10,000 טוקנים, מדובר בביצועים ברמת החזית ביחס דחיסה של יותר מ-50.

הגדלה

מה בסופו של דבר מגיע למקטעים?

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

חיוני (Vital): ראיות חיוניות למתן מענה לשאילתת המשתמש.

לא רלוונטי (Off-topic): מידע שעשוי להיות שימושי למטרה אחרת אך אינו קשור לשאילתה המדוברת.

מודעות (Ads): פרסום לא רלוונטי שמסיח את הדעת מהמענה לשאילתת המשתמש.

מטא-דאטה (Metadata): מטא-דאטה אודות תכולת המסמך.

ממשק משתמש וניווט (UI & navigation): רכיבים לתצוגת צד קדמי (frontend) וניווט.

כפילות (Duplicate): חזרה על מידע ששולב קודם לכן.

ההערכה שלנו רצה על 1,000 שאילתות משולבות-תחום מסט הנתונים לאימות שלנו, ומשווה את מחסנית הייצור מול קו בסיס זהה אחרת, אך עם הדחיסה כבויה. כפי שמוצג באיור 5, הדחיסה מגדילה את שיעור הטוקנים החיוניים לכל מקטע בממוצע של 63% מעל קו הבסיס ללא דחיסה. אנו רואים ירידה מקבילה של 29% בטוקנים שאינם רלוונטיים, עם ירידות חדות במיוחד ב-UI/ניווט (-58%), במטא־נתונים (-46%) ובמודעות (-43%). תוצאות אלה מאששות את המנגנון שמאחורי שיפורי האיכות-היעילות שנדונו לעיל: הדחיסה משפרת ביצועים בשני הממדים באמצעות העלאה חדה של יחס האות לרעש של כל מקטע בנפרד.

הגדלה

איור 6 ממחיש שינוי זה עבור שאילתת חיפוש בודדת. עבור השאילתה “6 day old newborn milk intake per feeding”, אנו מציגים את המקטעים הלא דחוסים, מקור ההשוואה, והדחוסים. דחיסה מבטלת את קטגוריות התוכן שאינן חיוניות ושומרת רק על מידע ההאזנה הקשור ליילוד. חשוב לציין, דחיסה מבטלת בהצלחה תוכן שעשוי להיות בדרך כלל קשור לנושא של הדף, אך אינו קשור לשאילתה ספציפית זו הממוקדת ביילוד.

הגדלה

סיכום

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

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

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

מקורות

N. Chirkova, T. Formal, V. Nikoulina, and S. Clinchant. Provence: Efficient and Robust Context Pruning for Retrieval-Augmented Generation, 2025. Accepted to ICLR 2025. arXiv:2501.16214.

T. Do, D. P. Tran, A. Vo, S. K. Kim, and D. Kim. LooComp: Leverage Leave-One-Out Strategy to Encoder-only Transformer for Efficient Query-Aware Context Compression, 2026. arXiv:2603.09222.

S. Eslami, M. Gaiduk, M. Krimmel, L. Milliken, B. Wang, and D. Bykov. Diffusion-Pretrained Dense and Contextual Embeddings, 2026. arXiv:2602.11151.

Z. Wang, J. Araki, Z. Jiang, M. R. Parvez, and G. Neubig. Learning to Filter Context for Retrieval-Augmented Generation, 2023. arXiv:2311.08377.

ציטוט

@online{perplexity2026QueryAwareContextCompressionForBetterSnippets,
  author = {{Perplexity} and Bo Wang and Hao Zhang and Ismail Gadzhiev and Kirill Priemko and Markus Krimmel and Nandor Licker and Vitalii Polshkov and Sarah Eslami and Louis Milliken and Maksim Gaiduk and Nikita Kireev and Jerry Ma},
  title = {{Query-aware context compression for better snippets}},
  date = {2026-05-14},
  url = {https://www.perplexity.ai/hub/blog/query-aware-context-compression-for-better-snippets}
}