ضغط السياق المدرك للاستعلام لمقتطفات أفضل

تبدأ كل إجابة بالأدلة. في نظام البحث، تأتي هذه الأدلة عادةً من المستندات: العناوين، والملخصات، والقطع، والمقتطفات التي يتم تمريرها كسياق إلى نموذج الإجابة أو الوكيل.

هذا السياق الخام مليء بالتشويش. على سبيل المثال، قد تحتوي صفحة ويب على المعلومات اللازمة لطلب المستخدم، ولكنها قد تحتوي أيضًا على عناصر مشتتة للانتباه. يمكن أن تظهر هذه المشتتات في متن النص الرئيسي وفي العناصر المساعدة، مثل عناصر نص التنقل، والإعلانات غير ذات الصلة، والبيانات الوصفية، والمزيد. إن تمرير هذه المشتتات إلى وكيل لاحق يخلق ثلاث مشكلات.

أولاً، إنه يضر بالدقة. حتى أقوى النماذج لها سعة محدودة. إن تدفقات المعلومات الطويلة وغير ذات الصلة تستهلك سعة النموذج، مما يؤدي إلى "تعفن السياق" الذي يضعف قدرة النموذج على معالجة طلب المستخدم الفعلي. ونتيجة لذلك، تصبح الاستجابة النهائية أكثر عرضة لتفويت الحقائق الرئيسية، أو إعطاء وزن مفرط للمعلومات منخفضة الجودة، أو إنتاج ادعاءات يصعب ترسيخها في المصدر.

ثانياً، إنه يؤخر زمن الاستجابة. السياق الأطول يعني رموزاً أكثر ليقوم النموذج اللاحق معالجتها، خاصة عندما يحتاج استعلام إلى أدلة من صفحات مرشحة عديدة. على الرغم من تحمل جزء من تكلفة زمن الاستجابة هذه في مرحلة التعبئة المسبقة، يتم دفع تكلفة أكبر بكثير في الاستدلال، حيث تتطلب النماذج رموز استدلال أكثر للتعامل مع السياق غير ذي الصلة.

ثالثاً، إنه يرفع التكلفة. كل رمز غير ضروري يتم تمريره إلى النموذج يجعله أكثر تكلفة لتلبية طلب المستخدم، حيث يتزاييد استخدام كل من رموز الإدخال ورموز الاستدلال مع السياق المشوش. لا تقتصر المشتتات على تقليل الجودة فحسب؛ بل تجبرك في النهاية على دفع المزيد مقابل تلك الجودة الأسوأ.

تكبير

لتحسين الدقة والسرعة وفعالية التكلفة في نفس الوقت عبر تطبيقات Perplexity ومنصة واجهة برمجة التطبيقات (API Platform)، نستثمر بقوة في تحسين دقة السياق. تتمثل إحدى الطرق التي نقوم بها بذلك في تنقيح خوارزميات توليد المقتطفات الخاصة بنا. نحن نتعامل مع توليد المقتطفات كمشكلة ضغط السياق. النماذج التي تبحث عن معلومات محددة لا تستفيد من الملخصات العامة أو مقتطفات المستند. بل إنها تحتاج إلى أصغر وأدق جزء مستخلص من معلومات المصدر للاستجابة لطلب المستخدم. كل ما عدا ذلك يمكن ويجب إزالته.

لذلك ينبغي للمقتطف الجيد أن يقوم بثلاثة أمور:

تعزيز الدقة من خلال تقديم الأدلة الدقيقة اللازمة لترسيخ استجابة النموذج.

تقليل زمن الاستجابة والتكلفة عن طريق إزالة السياق غير ذي الصلة قبل استدعاء نموذج اللغة الكبير (LLM).

ضمان إمكانية التتبع من خلال الحفاظ على دقة الاستشهاد وإبقاء صياغة المصدر سليمة.

هذا الشهر، قمنا نشر مولد مقتطفات جديد ومتطور داخل تطبيقاتنا ومنصة واجهة برمجة التطبيقات (API Platform). يكمن جوهر هذه الوحدة في نموذج ضغط سياق مدرك للاستعلام والذي يحدد، لكل استعلام ونتيجة مرشحة، مجموعة فرعية من الامتدادات التي يجب الاحتفاظ بها. تصف هذه المقالة نهجنا في بناء وتدريب النموذج لتحقيق أداء رائد في فئته في هذه المهمة الحاسمة.

المقتطفات كضغط مدرك للاستعلام

الأمر الأول هو تحديد المهمة نفسها. ماذا نريد لهذا النموذج أن يفعل، وكيف يجب أن نحدد مخطط الإدخال والإخراج؟

تنقسم طرق المقتطفات إلى عائلتين رئيسيتين. الأولى قائمة على الاختيار: ابحث عن نافذة أو قطعة أو جملة أو مقطع ذي صلة، وقم بتمريره إلى اللاحق. والثانية قائمة على التوليد: اطلب من نموذج كتابة ملخص يركز على الاستعلام من الصفحة.

إن تركيزنا على الدقة وزمن الاستجابة والتكلفة يجعل خيار التصميم واضحًا. يمكننا استبعاد التوليد، نظراً لأن إنشاء ملخص جديد لكل صفحة يضر بالاداء عبر جميع المحاور الثلاثة. التلخيص ليس مناسبًا لطبقة الأدلة التي نُعنى بها. فقد يقوم بإعادة صياغة المصدر، مما يجعل مطابقة الاستشهاد أكثر صعوبة. ويمكنه أيضًا إدخال صياغة لم تكن موجودة في الصفحة، وهو أمر محفوف بالمخاطر عندما يُستخدم المقتطف كدليل وليس كإجابة نهائية. إن زمن الاستجابة والتكلفة المتضمنين يجعلا التوليد أكثر رفضاً.

بدلاً من ذلك، نحدد مهمتنا كضغط استخراجي مدرك للاستعلام: فصل الأجزاء المفيدة من السياق المسترجع عن الأجزاء المشتتة. على وجه التحديد، يجب أن يقبل نموذجنا استعلامًا ونتيجة مرشحة، ويقرر الامتدادات التي يجب الاحتفاظ بها، وتلك التي تدعم الاستعلام بشكل أفضل، وما الذي يجب إسقاطه، والباقي. يحافظ مخرجات النموذج على نص المصدر بدلاً من إعادة كتابته. وهذا يجعل النتيجة أسهل في الاستشهاد بها، وأسهل في التحقق منها، وأرخص في التمرير إلى المراحل اللاحقة.

على سبيل المثال، ضع في اعتبارك هذا الاستعلام والنتيجة المسترجعة:

تكبير

المخرج المحتمل للنموذج سيكون اختيار الجملة الغامقة: “In Comet, the assistant can ...”.

يتبع نهجنا نفس الفكرة العامة لأعمال ضغط السياق السابقة مثل FliCo وProvence وLooComp، والمصممة خصيصًا لتوليد المقتطفات في نظام بحث إنتاجي. والأهم من ذلك، أن النموذج يعمل كمرحلة دقة بعد مرحلة الاسترجاع الخام الخاصة بنا. كما ناقشنا في مقالة أبحاث Perplexity السابقة، تقديم واجهة برمجة تطبيقات البحث من Perplexity (Introducing the Perplexity Search API)، فإننا نصمم أنظمة الاسترجاع الخاصة بنا للعمل محليًا على مستوى دون المستند، أو المقتطف، مما يسمح لنا بالفعل بموازنة الدقة والاصطياد بشكل جيد للغاية. إن تقديم نموذج ضغط سياق مدرك للاستعلام يدفع حدود باريتو للدقة والاصطياد إلى آفاق أبعد.

بناء وتدريب نموذج ضغط السياق

نطور نموذجنا مع وضع ثلاثة اعتبارات رئيسية في الاعتبار: الفهم المشترك للاستعلام والسياق، والاختيار دقيق الحبيبات على مستوى الجملة، والفعالية لتناسب ميزانية زمن استجابة ضيقة للغاية.

هندسة النموذج

نحن نستخدم نموذج انتشار pplx (pplx-diffusion) كعمود فقري. هذه هي نفس عائلة النموذج وراء pplx-embed-v1، وكل من عملنا الأكاديمي السابق، الضمائر الكثيفة والسياقية المدربة مسبقًا بالانتشار (Diffusion-Pretrained Dense and Contextual Embeddings)، ومعايير الإنتاج الخاصة بنا تؤكد أنها مشفر ثنائي الاتجاه قوي لازواج الاستعلام والسياق. إحدى الخصائص الرئيسية من عائلة النموذج هذه هي السياق ثنائي الاتجاه: يمكن لكل تمثيل رمز الانتباه إلى الاستعلام الكامل وسياق المرشح الكامل قبل أن يقرر النموذج ما يجب الاحتفاظ به.

فوق هذا العمود الفقري، ندرب رأس ضغط خفيف الوزن يتنبأ بأجزاء السياق التي يجب الاحتفاظ بها. نظرًا لعدم وجود أي توليد، يتم إجراء هذه التنبؤات بالتوازي عبر السياق بأكمله. في وقت التقديم، يجمع محرك المقتطفات هذه التنبؤات على مستوى الجملة، ويطبق حدًا عتبياً، ويشذب النتيجة إلى ميزانية الرموز المطلوبة.

خط أنابيب الإشراف

يتطلب تدريب هذا الضاضغط إشرافًا بالمستوى الصحيح من الحبيبات. إن علامة الصلة على مستوى المستند غير مناسبة تمامًا لمهمة الضغط الاستخراجي الخاصة بنا. لتوليد بيانات دقيقة الحبيبات بما يكفي للتعلم الخاضع للإشراف، أنشأنا خط أنابيب تصنيف نطاق يحدد نطاقات الأدلة ذات الصلة بالاستعلام، إلى جانب نطاقات المشتتات التي يجب إزالتها.

يستخدم خط الأنابيب الخاص بنا إعداد نموذج اللغة الكبير كحكم (LLM-as-a-judge). بالنظر إلى استعلام المستخدم وصفحة الويب المرشحة برابطها وعنوانها وملخصها، يقوم الحكم أولاً بإجراء فهم الاستعلام، وتحليل الاستعلام وإنتاج قائمة بنوايا المستخدم المحتملة. استنادًا إلى هذه النوايا، يعالج الحكم بعد ذلك سياق المرشح ويرجع النطاقات المنسوخة حرفياً من النص، مع فئة لكل نطاق لجعل التسميات أسهل في الفحص.

ثم قمنا بمطابقة النطاقات المرتجعة مرة أخرى مع نص المصدر. ومما لا يثير الدهشة، أن معظم مخرجات الحكم كانت نسخًا دقيقة بالفعل: استردت مطابقة السلسلة البسيطة 98% من النطاقات. أدى إضافة تمرير مطابقة بسيط يعتمد على التعبير النمطي (regex) إلى رفع استرداد النطاق إلى 100%. وقد منحنا هذا نطاقات موثوقة ودقيقة الحبيبات يمكن تحويلها إلى إشراف الاحتفاظ/الإسقاط على مستوى الرمز.

قمنا بتقييم خط أنابيب الإشراف هذا باستخدام مجموعة بيانات منسقة صغيرة ذات نطاقات معصومة يدويًا، مقارنة نماذج الحكم الأصغر، والمطالبات المختلفة، وتكوينات الخطوات المختلفة. كان الإعداد الأفضل أداءً هو خط أنابيب من مرحلتين: فهم الاستعلام أولاً، يليه تصنيف النطاق المصنف. لقد تحققنا أيضًا من مجموعة النطاقات المستخرجة من خلال تقييمات قابلة للتحقق لاحقة مثل BrowseComp وSimpleQA, حيث حافظ استخدام نطاقات الأدلة المحتفظ بها فقط على درجات قوية مع تقليل رموز الإدخال بشكل كبير.

باستخدام خط الأنابيب هذا، قمنا بتسمية 750 ألف زوج استعلام-مستند ونستخدم النطاقات الناتجة لتدريب رأس الضغط باستخدام الإنتروبيا الثنائية المتقاطعة. تسمح هذه العملية لنموذج الضغط المدرك للاستعلام الخاص بنا بالحفاظ على نص المصدر سليماً بينما يزيل السياق الذي من غير المرجح أن يساعد النموذج اللاحق في تلبية طلب المستخدم.

ضمان زمن الاستجابة في الوقت الفعلي

يقع ضغط السياق قبل النموذج اللاحق، مما يجعله عملية حظر. علاوة على ذلك، فإن كل ضغط يعتمد على الاستعلام. لذلك، يجب على المسار عبر الإنترنت تسجيل أزواج الاستعلام والسياق لكل مستند مرشح ضمن غلاف زمن استجابة دقيق. إن نموذج الضغط البطيء يؤدي إلى نتائج عكسية، حيث يتم محو فوائد زمن الاستجابة من الدقة الأعلى بواسطة زمن الاستجابة للضغط نفسه. في الوقت نفسه، سيقوم نموذج الضغط الأقل ذكاءً باتخاذ قرارات أسوأ بشأن ما يجب قصه والاحتفاظ به.

السؤال العملي هو كم سعة نموذج يمكننا إزالتها بأمان قبل أن تبدأ جودة الضغط في التدهور. نقارن العمود الفقري لانتشار pplx الكامل المكون من 28 طبقة بمتغيرات مكونة من 11 و 17 طبقة تم إنتاجها عن طريق تقليم الطبقات والموجهة نحو مسار البحث. لكل منها، نتصفح حد الضغط ونقيس كميتين: متوسط عدد رموز السياق المرسلة لاحقا لكل استعلام، ونسبة الأدلة المفيدة المحفوظة بعد الضغط.

يوضح الشكل 2 حدود الجودة والكفاءة. يكون النموذج أفضل عندما يتحرك نحو أعلى اليسار: رموز لاحقة أقل مع أدلة أكثر فائدة محفوظة. يوفر نموذج ال28 طبقة مرجع الجودة. يوضح نموذج ال11 طبقة مخاطر ضغط النموذج بقسوة شديدة. يمثل نموذج ال17 طبقة المقلم منطقة وسطى: فهو يتتبع عن كثب نموذج ال28 طبقة في النظام المشبع، ولكن فجوة صغيرة تنفتح في الجزء الحاد من المنحنى حيث يعمل معظم حركة الإنتاج.

لسد هذه الفجوة، نستخدم تقطير المعرفة على مستوى الرمز. نهجنا روتيني: نقوم بتعزيز الخسارة القياسية بمصطلح إنتروبيا متقاطع ناعم على تنبؤات نموذج المعلم، مرجحًا بمعامل تقطير. هذا يكفي لجعل نموذج الطالب مساوياً للمعلم، مما يسمح لنا بالتحول الكامل إلى نموذج ال17 طبقة المقطر في الإنتاج. ينتج نموذج الإنتاج الجديد هذا انخفاضًا بنسبة 35-40% في زمن استجابة الاستدلال وانخفاضًا بنسبة 40-45% في إجمالي حوسبة وحدة معالجة الرسومات (GPU) مع عدم وجود انخفاض في الجودة مقارنة بمعلم ال28 طبقة. يسجل زمن استجابة الإنتاج أقل من 20 مللي ثانية (p99): صغير بما يكفي لإضافته إلى مسار التقديم مع تقليل إجمالي الرموز الم تمررة إلى نموذج الإجابة بشكل كبير.

تكبير

الجودة وكفاءة الرموز

نستخدم واجهة برمجة تطبيقات الوكيل (Agent API) الخاصة بـ Perplexity كمنصة اختبار لتحليل فعالية ضغط السياق. نقيم ثلاثة إعدادات مسبقة لواجهة برمجة تطبيقات الوكيل:

إعداد سياق مسبق "منخفض" يقيد ميزانية الرموز لكل مجموعة نتائج بـ 1000 رمز.

إعداد سياق مسبق "متوسط" يقيد ميزانية الرموز لكل مجموعة نتائج بـ 4000 رمز.

إعداد سياق مسبق "عالي" يقيد ميزانية الرموز لكل مجموعة نتائج بـ 10000 رمز.

تم تكوين كل من إعدادات القياسية، وعدم الضغط، وضغط السياق لاحترام ميزانيات الرموز هذه.

البحث الوكيلي متعدد الخطوات (BrowseComp)

نحن ندرس أولاً تأثير الضغط على سير عمل البحث الوكيلي متعدد الخطوات على معيار BrowseComp. نقوم بهذا التقييم باستخدام أداة search_evals مفتوحة المصدر الخاصة بنا. التقييم متطابق عبر جميع التشغيلات، باستخدام مطالبة حكم نموذج اللغة الكبير لـ BrowseComp الكانونية لـ OpenAI.

البعدان اللذان يثيران الاهتمام هما دقة المعيار واستخدام الرموز. والأهم من ذلك، أننا نقيس استخدام الرموز على مستوى الاستعلام بدلاً من مستوى الخطوة الفردية من أجل قياس عبء الرموز الفعلي المتكبد عبر دورة حياة الطلب. يوضح الشكل 3 حدود "الدرجة-الرمز"، درجة الدقة مقابل استخدام الرموز.

تكبير

يوفر الضغط حدًا جديدًا لباريتو في جميع الجوانب. لكل إعداد، يؤدي إدخال الضغط إلى تقليل استخدام الرموز على مستوى الاستعلام بنسبة تتراوح من 10% إلى 70%، مع تحقيق مكاسب في الدقة تتراوح بين 4 و 4.81 نقطة مئوية. يتيح إدخال الضغط حتى للإعداد المسبق "المنخفض" الخاص بنا التفوق على الإعداد المسبق "العالي" بدون ضغط، وكل ذلك مع تقليل استخدام الرموز بأكثر من ثلاثة أضعاف.

نلاحظ أنه مع الضغط، ينتج عن "العالي" دقة أكبر من "المتوسط" كما قد نتوقع. ومع ذلك، من المثير للاهتمام أنه يفعل ذلك باستخدام رموز أقل. يكشف هذا عن تأثير خفي ولكنه مهم للضغط: مع الضغط، قد يؤدي حتى زيادة حجم سياق الخطوة الواحدة إلى تمكين النموذج من اتخاذ خطوات أقل للوصول إلى النتيجة الصحيحة. إن استكشاف هذه اللارتابعية هو اتجاه واعد للعمل المستقبلي.

SimpleQA: دقة الحقائق أحادية الخطوة

BrowseComp يؤكد على البحث متعدد الخطوات، إلا أن العديد من سير العمل الإنتاجية تتضمن استرجاعًا واقعيًا بخطوة واحدة. ولتحديد ما إذا كان الضغط يفيد أيضًا في سيناريو الخطوة الواحدة، نفحص أيضًا الأداء على SimpleQA، وهو معيار يضم 4,326 سؤالًا ينبغي الإجابة عنها في خطوة بحث واحدة، بدلًا من حلقة وكيل.

كما كان من قبل، نقوم برسم الدقة مقابل متوسط إجمالي الرموز لكل مهمة باستخدام مطالبة الحكم الكانونية. يوضح الشكل 4 حدود الدرجة-الرمز في هذا الإعداد أحادي الخطوة. على الرغم من أن حجوم التأثير أكثر ضغطًا في الإعداد أحادي الخطوة، إلا أننا نلاحظ مرة أخرى أن الضغط يحسن في نفس الوقت الدقة والكفاءة عبر جميع الإعدادات المسبقة، مما يطرح بالتالي حدًا جديدًا لباريتو. مع تمكين الضغط، يحقق الإعداد المسبق المتوسط دقة بنسبة 95% بمتوسط 200 رمز فقط لكل مستند. بالنظر إلى متوسط طول المستند الذي يزيد عن 10000 رمز، يمثل هذا أداءً بمستوى رائد بنسبة ضغط تزيد عن 50.

تكبير

ما الذي ينتهي به الأمر في المقتطفات؟

مكاسب المجرى اللاحق في القسمين 4.1 و 4.2 هي من طرف إلى طرف. لفهم كيف يغير الضغط المقتطفات الفردية، نقوم بتشغيل تقييم منفصل يستخدم حكم نموذج اللغة الكبير (LLM) لتصنيف كل رمز من كل مقتطف مسترجع إلى واحدة من ست فئات:

حيوي: الأدلة الأساسية للإجابة على استعلام المستخدم.

خارج الموضوع: معلومات قد تكون مفيدة لغرض آخر ولكنها لا تتعلق بالاستعلام قيد البحث.

إعلانات: إعلانات غير ذات صلة تشتت الانتباه عن الإجابة على استعلام المستخدم.

بيانات وصفية: بيانات وصفية حول محتويات المستند.

واجهة المستخدم والتنقل: عناصر لعرض الواجهة الأمامية والتنقل.

مكرر: تكرار معلومات تم دمجها مسبقًا.

يعمل تقييمنا على 1000 استعلام مختلط المجال من مجموعة التحقق الخاصة بنا، مقارنة تكديس الإنتاج مقابل خط أساس متطابق بخلاف ذلك مع تعطيل الضغط. كما يظهر في الشكل 5، يزييد الضغط من نسبة الرموز الحيوية لكل مقتطف بمتوسط 63% مقارنة بخط أساس عدم الضغط. نلاحظ انخفاضًا مققابلاً بنسبة 29% في الرموز غير ذات الصلة، مع انخفاضات حادة بشكل خاص في واجهة المستخدم/التنقل (-58%)، والبيانات الوصفية (-46%)، والإعلانات (-43%). تؤكد هذه النتائج الآلية الخاصة بتحسينات الجودة والكفاءة التي تمت مناقشتها أعلاه: يحسن الضغط الأداء عبر كلا البعدين من خلال زيادة نسبة الإشارة إلى الضوضاء لكل مقتطف فردي بشكل حاد.

تكبير

يوضح الشكل 6 هذا التغيير لاستعلام فردي. بالنسبة للاستعلام "6 day old newborn milk intake per feeding" (تناول حليب حديث الولادة بعمر 6 أيام لكل رضعة)، نعرض كلاً من المقتطفات غير المضغوطة، وخط الأساس، والمضغوطة. يلغي الضغط فئات المحتوى غير الحيوية ويحتفظ فقط بمعلومات التغذية المتعلقة بالمولود الجديد. والأهم من ذلك، أن الضغط يزيل بنجاح المحتوى الذي قد يكون خارج الموضوع بشكل عام للصفحة، ولكنه خارج الموضوع لهذا الاستعلام المحدد الذي يركز على المولود الجديد.

تكبير

خاتمة

تعتمد أنظمة الذكاء الاصطناعي على معلومات عالية الإشارة لخدمة طلبات المستخدمين بذكاء وفعالية. يجب تقديم هذه المعلومات بأكبر قدر ممكن من الدقة لتعظيم الصلة بكل استعلام. تقوم نماذج الضغط الجديدة المدركة للاستعلام الخاصة بنا بذلك بدقة من خلال تعظيم الأدلة ذات الصلة بالموضوع لكل مقتطف وإقصاء المشتتات غير ذات الصلة بقوة.

من خلال نشر هذه النماذج الجديدة داخل تكديس البحث الخاص بنا، نحن قادرون على توفير استجابات أسرع وأفضل لأولئك الذين يعتمدون على منتجاتنا وواجهات برمجة التطبيقات الخاصة بنا. يخلق نهجنا سطح تحكم بسيط، مما يسمح لأنظمتنا وعملاء واجهة برمجة التطبيقات بضبط درجة الضغط للموازنة بين الاستدعاء وزمن الاستجابة والتكلفة.

تنظيم السياق هو مجال متطور، وهناك الكثير الذي يتعين القيام به لتحسين قيمة كل رمز مستخدم داخل أنظمة الذكاء الاصطناعي الرائدة اليوم. نحن نعمل بنشاط لجعل تقنيات تنظيم السياق الخاصة بنا أفضل من خلال تحسينات النماذج وهندسة الأنظمة لجعل استخدام هذه النماذج أكثر اتساعًا.

المراجع

N. Chirkova, T. Formal, V. Nikoulina, and S. Clinchant. Provence: تقليم السياق الفعال والقوي لتوليد المعزز بالاسترجاع (Efficient and Robust Context Pruning for Retrieval-Augmented Generation), 2025. مقبول في ICLR 2025. arXiv:2501.16214.

T. Do, D. P. Tran, A. Vo, S. K. Kim, and D. Kim. LooComp: الاستفادة من استراتيجية اترك-واحد-خارج (Leave-One-Out) لمحول المشفر فقط لضغط السياق الفعال المدرك للاستعلام (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://perplexity.coolkeypoint.com/hub/blog/query-aware-context-compression-for-better-snippets}
}