مطوّر يبني نظام RAG بالاعتماد على نماذج محلية ويرفع دقة البحث من 20% إلى 53%

لماذا فشل البحث المتجهي التقليدي مع الكلمات المتجانسة

نشر مطوّر يُعرف باسم tzar26 على GitHub تحليلًا مفصلًا لنظامه الخاص بتحليل الأخبار — نظام مستقل بالكامل، دون أي استدعاء لواجهات برمجة سحابية مثل OpenAI أو Anthropic. تعمل جميع النماذج محليًا عبر Ollama: Qwen 2.5 14B للاستدلال والتصنيف، وBGE-M3 لإنشاء التمثيلات المتجهة للنصوص. السبب وراء هذا النهج مذكور بوضوح في المقال: الصمود في مواجهة العقوبات والاستقلال عن مزوّدي الخدمة الخارجيين. تتضمن البنية الناتجة Python وFastAPI وPostgreSQL مع إضافة pgvector، وCelery للمهام الخلفية، وLangGraph للوكيل، وLangfuse للمراقبة — جمعها المطوّر في حاويات Docker وغطاها باختبارات عبر GitHub Actions.

جمع النظام أكثر من 12,000 مقال، وفي البداية كان البحث فيها يعتمد فقط على المسافة التجيبية (cosine distance) بين التمثيلات المتجهة لـ BGE-M3. كانت الاستعلامات البسيطة تعمل بشكل سليم، لكن المواضيع المعقدة مثل «سعر الفائدة الأساسي للبنك المركزي» كانت تُعيد نتائج غير دقيقة. وأظهر استعلام «الذهب» المشكلة بوضوح أكبر: فبدلًا من أخبار أسعار المعدن، كان البحث يعيد بصدق مقالات عن متزلج فاز بالذهب في منافسة — وهو خلط كلاسيكي ناتج عن تعدد معاني الكلمة، إذ لا يميّز المتجه بين السياقات المختلفة.

كان الحل هو البحث الهجين: أُضيف إلى المقارنة المتجهية بحث نصي دقيق بخوارزمية BM25 معتمد على PostgreSQL (عبر tsvector المدمج)، ودُمجت نتائج الطريقتين باستخدام خوارزمية RRF (Reciprocal Rank Fusion) — التي تأخذ موضع المستند في كل قائمة نتائج وتحسب رتبة إجمالية. تتفوق BM25 في رصد المصطلحات الدقيقة مثل «أوبك» أو «الفائدة»، بينما يتفوق البحث المتجهي في رصد المرادفات والعلاقات الدلالية. وبشكل إجمالي، ارتفعت نسبة المستندات ذات الصلة ضمن أفضل خمس نتائج بحث (مقياس Recall@5) من 0.2 إلى 0.53، أي بأكثر من الضعف.

كيف يتوقف النظام عن تكديس كل شيء في فئة «أخرى»

ظهرت مشكلة مستقلة أثناء التصنيف الآلي للمقالات حسب المواضيع. في النسخة الأولى من الموجّه (prompt)، كان النموذج يضع 74% من جميع المقالات في فئة «أخرى» — أي أن قرابة ثلاثة أرباع القاعدة كانت بلا تصنيف مفيد. وتبيّن أن السبب بسيط: تضمّنت التعليمات عبارة «إذا شككت، اختر أخرى»، وكان النموذج، خوفًا من الخطأ، يستغل هذه العبارة بشكل مكثف.

أعاد المطوّر كتابة الموجّه: أضاف وصفًا دقيقًا لكل فئة، بما في ذلك تجارة التجزئة (retail) والاقتصاد الكلي (macro) والحوادث (incident)، وحذف عبارة الشك نفسها. بعد ذلك، انخفضت نسبة المقالات غير المصنّفة إلى 0.03%. وللتأكد من دقة هذه الأرقام، فحص المطوّر يدويًا عينة عشوائية من المقالات المصنّفة — وبلغت دقة التصنيف 85%.

وكيل يحسب، لا يبحث فقط

يجيب البحث العادي في القاعدة عن أسئلة مثل «ماذا يُكتب عن النفط»، لكن ذلك لا يكفي للتحليل المتقدم. لذا بنى المطوّر على LangGraph وكيلًا يختار من بين ثلاث أدوات:

• `search_articles` — بحث هجين عادي في النص
• `get_metrics` — تجميع بلغة SQL، مثل حساب عدد المقالات عن الطاقة خلال الأيام الثلاثة الماضية
• `search_by_entity` — بحث عن أسماء الشركات المستخرجة مع مراعاة مشاعر النص (نتيجة نماذج مستقلة للتعرف على الكيانات وتحليل المشاعر)

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

عقبات تقنية على الأجهزة المحلية

جلب تشغيل النماذج محليًا مشكلات خاصة لا تظهر عند استخدام واجهات برمجة سحابية:

• كانت Ollama تفرّغ النماذج من ذاكرة بطاقة الرسوميات عند التبديل بينها، وقد يستغرق الطلب الواحد حتى 60 ثانية — حُلّت المشكلة باستخدام متغيّر `OLLAMA_MAX_LOADED_MODELS=2`
• تستخدم مكتبة LangChain داخليًا تجميعًا متدفقًا (streaming) للردود، مما كان يسبب تباطؤًا بمعدل تسع مرات — فتم استبعادها من خط المعالجة لصالح العميل المباشر `ollama.AsyncClient`
• تربط SQLAlchemy تجمّع الاتصالات (connection pool) بحلقة الأحداث (event loop)، وعندما تُقاطع Celery مهمة ما، تبقى الاتصالات «زومبي» — حُلّت المشكلة باستدعاء `await engine.dispose()` بعد كل مهمة
• تعالج Ollama الطلبات تسلسليًا بشكل افتراضي؛ كان تصنيف مقال واحد يستغرق نحو 10 ثوان، وزيادة معامل `OLLAMA_NUM_PARALLEL` من 1 إلى 2 سرّعت العملية بمعدل 1.5 مرة على الأقل

يقع المشروع حاليًا في مرحلة نسخة أولية عامة (MVP) ومتاح للجميع على GitHub. وتتمثل الخطوة التالية، بحسب المطوّر، والتي لا تزال خاصة حتى الآن، في ربط الشركات المذكورة برموز التداول في بورصة موسكو (مثل SBER وGAZP) وبناء لوحات بيانات تنبؤية لأسهم محددة. وبالنسبة للمهندسين الذين يفكرون في بنية محلية بدلًا من واجهات برمجة سحابية، فإن الاستنتاج العملي الرئيسي هو: التوفير في تكاليف استدعاءات واجهات البرمجة حقيقي، لكن ثمنه هو الوقت المستغرق في ضبط البنية التحتية — من تهيئة التوازي في Ollama إلى معالجة إدارة الاتصالات في الكود غير المتزامن.