Cohere: رفع عدد المرشحين في Rerank من 20 إلى 100 يزيد الحمل من 4,4 إلى 22 ألف توكن

نشرت Cohere تحليلًا عمليًا لكيفية الاختيار بين استدلال shared بالدفع حسب الاستهلاك، واستدلال dedicated بسعة مخصصة، لنماذج Embed وRerank. ينطلق كاتب النص، مهندس الحلول (solutions architect) Payal Singh، من فكرة بسيطة: مقارنة قوائم الأسعار لا معنى لها ما دام غير واضح كيف يستخدم التطبيق النموذج. استدعاء واحد للتضمينات (embeddings) على 100 وصف منتج، بنحو 200 توكن لكل وصف، يستهلك قرابة 20 ألف توكن. أما طلب بحث واحد من مشترٍ فلا يتجاوز بضع كلمات. في الفوترة يُحتسب كلاهما «طلبًا»، لكنهما بالنسبة إلى العتاد حملان مختلفان تمامًا.

نموذج واحد وملفّان للحمل

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

أما طلب البحث «waterproof trail running shoes» فهو على العكس تمامًا. إنه قصير، والمستخدم ينظر إلى مؤشر التحميل. هنا تهم سرعة الاستجابة، ويكون ثمنها أسوأ نسبة سعر إلى أداء (price-performance). فعمليًا يُطلب من نموذج واحد أن يؤدي عملين مختلفين. والبنية التحتية المضبوطة للدفعات الكبيرة لن تحقق بالضرورة زمن الاستجابة المطلوب عند آلاف الطلبات الصغيرة الحساسة للتأخير.

Rerank: عمق النتائج يعمل كمضاعف

لنموذج إعادة الترتيب (reranker) هندسته الخاصة. يعيد البحث المتجهي، لنقل، 50 مرشحًا، ويقيّم النموذج كل زوج «طلب — مستند» بشكل مستقل. تُعالَج صيغة الطلب من جديد لكل مرشح، ولذلك يزداد العمل طرديًا مع عددهم.

وفق تقدير Cohere، يتكون الاستدعاء النموذجي من طلب بنحو 20 توكن، إضافة إلى 50 منتجًا بنحو 200 توكن لكل منتج. والناتج نحو 11 ألف توكن لكل عملية بحث. وإذا زِيد عمق النتائج، يتغير الحمل من دون أي مستخدم جديد:

• 20 مرشحًا: نحو 4 400 توكن لكل بحث؛
• 50 مرشحًا: نحو 11 000 توكن؛
• 100 مرشح: نحو 22 000 توكن.

يبقى عدد عمليات البحث وتجربة المستخدم على حالهما، بينما تتطلب العملية حوسبة أكثر بخمس مرات. ولهذا تقترح Cohere اعتبار عمق الاسترجاع (retrieval) قرارًا متعلقًا بالبنية التحتية، لا مجرد إعداد لضبط الجودة.

الاستنتاجات من key takeaways

من أطروحات المادة يتشكل المنطق الآتي:

• شكل الطلب (request shape) أهم من حجم الطلبات: قد تستهلك بضعة استدعاءات كبيرة لـ Embed حوسبة (compute) أكثر من آلاف طلبات البحث القصيرة، ولذلك لا يمكن الاعتماد على RPM مقياسًا وحيدًا لتخطيط السعة؛
• يكون استدلال dedicated عادةً أكثر اقتصادًا مع الحمل المستقر المتوقع، بينما يناسب نموذج الدفع حسب الاستهلاك (consumption-based) الحركة المتغيرة أو ذات الذروات؛
• تعتمد نقطة التعادل على حجم الطلب وعدد التوكنات وعدد المرشحين في rerank، لا على سعر البنية التحتية وحده؛
• أقصى إنتاجية (throughput) لا تساوي السعة الفعلية المتاحة في بيئة الإنتاج (production): يجب الالتزام بمتطلبات زمن الاستجابة (latency) مع إبقاء التكلفة ضمن حدود معقولة.

كيف تقترب من الاختيار عمليًا

الترتيب هو ما تقترحه Cohere نفسها: ملف الطلب، ثم نمط الحركة، ثم الاستخدام الفعلي للموارد (utilization)، وبعدها فقط اختيار نمط النشر. ابدأ بقياس أحجام الطلبات الفعلية: كم مستندًا في دفعة الفهرسة، وكم توكنًا في المتوسط، وكم مرشحًا يُرسَل إلى نموذج إعادة الترتيب. ثم قسّم الحمل إلى خلفي (الفهرسة وإعادة الحساب بالدفعات) وتفاعلي (البحث الذي ينتظره المستخدم). الجزء الأول يمكن غالبًا إبقاؤه في وضع shared إذا كان غير منتظم. أما الثاني، مع تدفق مستقر، فهو مرشح للسعة المخصصة.

أعد حساب التكلفة بشكل منفصل عند تغيير عمق إعادة الترتيب: فالانتقال من 20 إلى 100 مرشح قد يغيّر نقطة التعادل. واختبر القدرة عند زمن الاستجابة المستهدف، لا عند الحد الأقصى المعلن للإنتاجية (throughput). ينقطع هذا الجزء من المادة في المقطع المتاح عند القسم المتعلق بأنماط الحركة، ولذلك لا ترد هنا عتبات محددة من Cohere للتبديل بين الوضعين.