تحافظ Cohere على 98.4% من جودة البحث عند استخدام الاستعلامات السريعة

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

أطلقت Cohere نموذجي Embed 5 وRerank 5 على OpenRouter. ولا تكمن القيمة العملية للإطلاق في إضافة اسمين آخرين إلى كتالوج النماذج، بل في إمكانية بناء مسار بحث متكامل عبر واجهة API واحدة: إنشاء فهرس متجهي، والعثور على المرشحين، وإعادة ترتيبهم بدقة أعلى، ثم استدعاء LLM بعد ذلك فقط. ولا حاجة إلى حسابات أو حزم SDK منفصلة من Cohere.

كيف يُقسّم العمل

تُجرى الفهرسة مرة واحدة لمجموعة المستندات بأكملها. يُقسّم النص إلى مقاطع، ثم يحول Embed 5 Pro كل مقطع إلى متجه. يُستخدم وضع search_document للمستندات، وتُطبّع المتجهات بحيث يمكن حساب التقارب بينها باستخدام حاصل ضرب قياسي عادي.

عند وصول استعلام من المستخدم، يعمل Embed 5 Fast في وضع search_query. ويستخدم Pro وFast الفضاء المتجهي نفسه، لذلك لا حاجة إلى بناء الفهرس مرة ثانية. ووفقا لبيانات Cohere، حافظت استعلامات Fast المطبقة على فهرس أنشأه Pro على 98.4% من جودة إعداد يعتمد بالكامل على Pro، وذلك عبر 40 مجموعة بيانات. أما عند استخدام Fast في الفهرسة والبحث معا، فتنخفض النسبة إلى 96.6%.

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

لماذا نحتاج إلى مرحلة ثانية

يتلقى Rerank 5 السؤال ونحو 10 إلى 20 مقطعا من نتائج البحث، ويقرأ كل زوج كاملا، ثم يعيد ترتيبا أكثر دقة. في مثال Cohere، حصلت التعليمات الصحيحة على درجة 0.808، في حين لم تتجاوز نتيجتان متقاربتان لكن عديمتا الفائدة عتبة 0.3. ولا يُرسل إلى النموذج اللغوي سوى مجموعة منقحة تتكون من ثلاثة إلى خمسة مقاطع.

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

وتؤكد Cohere بصورة منفصلة أن درجات Rerank 5 مُعايرة عبر الاستعلامات والمجالات المختلفة، ما يتيح استخدام عتبة صلة موحدة. لكن لا ينبغي اعتبار 0.3 إعدادا صالحا لكل الحالات؛ إذ يجب اختبار العتبة المستخدمة في العرض التوضيحي على بياناتكم الخاصة.

ما يجب مراعاته قبل التنفيذ

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

يؤثر حجم المقاطع أيضا في النتيجة. فالمقاطع القصيرة جدا تفقد السياق، بينما تزيد المقاطع الطويلة جدا تكلفة إعادة الترتيب. وما ورد في المثال، وهو 1,500 حرف، ليس سوى نقطة بداية. يدعم Rerank 5 ما يصل إلى 32 ألف رمز لزوج يتكون من الاستعلام والمقطع، لكن السماح بسياق كبير لا يجعل المقاطع الكبيرة مفيدة تلقائيا.

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