Query Rewriting + Hybrid Search + Reranking：من قاعدة معرفية ذكية «تستطيع البحث» إلى أخرى «تبحث بدقة»

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

لكن هناك فجوة بين «أن تعمل» و«أن تكون سهلة الاستخدام».

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

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

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

أين تكمن المشكلة

قبل البدء بالتحسين، علينا أن نفهم أولاً العيوب الهيكلية الثلاثة في RAG البسيط.

أولاً، المستخدم يتكلم بلغة البشر، أما محرك البحث فيريد كلمات مفتاحية. لن يكتب موظف المبيعات «أمريكا طلبات تصدير عدد الحاويات إحصاءات الشحن». سيقول «كم حاوية من الطلبات المرسلة إلى أمريكا الشهر الماضي لم تصل إلى الميناء بعد؟». بعد تمرير هذه الجملة إلى نموذج Embedding، تُخفّف الكلمات العامة مثل «الشهر الماضي» و«كم» و«لم تصل بعد» الإشارة الجوهرية للكيان الأساسي. في الفضاء المتجهي، قد تكون هذه الجملة قريبة جداً من وثيقة تتحدث عن «إجراءات التخليص الجمركي الأمريكي» — لأن الدلالة متشابهة فعلاً — لكنها تبعد طبقة عن بيانات جد إحصاءات الشحن الفعلية.

ثانياً، البحث المتجهي بارع في «التشابه الدلالي»، لكنه ليس بارعاً في «المطابقة الدقيقة». لنفترض أن هناك وثيقة في قاعدة المعرفة عنوانها تحديداً «معيار إحصاءات شحن الطلبات الأمريكية». قد لا يضعها البحث المتجهي في المرتبة الأولى — لأن المسافة الدلالية بين العنوان وسؤال المستخدم العام قد لا تكون الأقرب. لكن البحث بالكلمات المفتاحية (MySQL LIKE أو BM25) يطابقها في الحال. والعكس صحيح، فالبحث بالكلمات المفتاحية لا يفهم المرادفات والارتباط الدلالي. لكل طريقة عمى خاص بها.

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

هذه المشكلات الثلاث ليست عيباً في نموذج Embedding معين، بل قصور هيكلي في بنية RAG البسيط. لدى الصناعة حلول ناضجة: Query Rewriting يعالج مشكلة طرف الإدخال، Hybrid Search يسد الثغرات في طرف البحث، Reranking يصحح الانحراف في طرف الترتيب. استخدام التقنيات الثلاث معاً يشكل خط معالجة محسّن على النمط «إعادة كتابة → بحث هجين → إعادة ترتيب» $TRAE_REF.

الطبقة الأولى: Query Rewriting — دع LLM يساعد المستخدم على توضيح ما يقوله

الفكرة مباشرة: قبل إرسال سؤال المستخدم إلى البحث المتجهي، دع نموذجاً خفيفاً (نستخدم مجموعة نماذج lite، الأقل تكلفة) يعيد كتابة السؤال العام إلى تركيبة كلمات مفتاحية أكثر ملاءمة للبحث.

يقول المستخدم: «كم حاوية من الطلبات المرسلة إلى أمريكا الشهر الماضي لم تصل إلى الميناء بعد؟»

بعد إعادة الكتابة: «أمريكا طلبات تصدير عدد الحاويات إحصاءات الشحن الشهر الماضي حجم التصدير»

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

هناك عدة قرارات تصميم رئيسة في التنفيذ.

الـ Prompt هو الجوهر. جودة إعادة الكتابة تعتمد كلياً على تصميم system prompt. الـ prompt الخاص بنا يحتوي خمس قواعد: استخراج الكيانات الأساسية (أسماء الأشخاص، المنتجات، الدول، أنواع المستندات)، إضافة المرادفات والكلمات المرتبطة، إزالة أدوات النبرة، إخراج نص مجرد دون شرح، الحفاظ على لغة الأصل. إضافة إلى القواعد، قدمنا مثالين few-shot يغطيان السيناريوهات الصينية والإنجليزية. بدون few-shot، يخرج النموذج صيغاً ذات بادئة مثل «الاستعلام بعد إعادة الكتابة: XXX» مما يكسر التحليل في المصب.

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

تخزين مؤقت لمدة 5 دقائق. الاستعلام نفسه خلال 5 دقائق لا يستدعي النموذج مكرراً. نستخدم ConcurrentHashMap لتخزين خرائط hash → نتيجة إعادة الكتابة، مع تنظيف تلقائي عند انتهاء المهلة. الحد الأقصى للتخزين 200 عنصر، وعند امتلائه تُحذف العناصر منتهية الصلاحية. هذا التصميم يجعل الاستعلامات المتكررة عالية التردد (مثل عدة موظفي مبيعات يبحثون عن العميل نفسه في وقت واحد) لا تطلق استدعاءات نموذج متكررة، فيبقى التكلفة تحت السيطرة.

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

الطبقة الثانية: Hybrid Search — متجهات + كلمات مفتاحية، بالدمج عبر RRF

تحل هذه الطبقة مشكلة «للبحث المتجهي والبحث بالكلمات المفتاحية عمى خاص بكل منهما».

الحل هو تشغيل مساري بحث في آنٍ واحد، ثم دمج النتائج. البحث المتجهي مسؤول عن الاستدعاء الدلالي — فهم المرادفات والمفاهيم المرتبطة والمطابقة عبر اللغات. البحث بالكلمات المفتاحية مسؤول عن المطابقة الدقيقة — الكلمات الأصلية الواردة في العنوان وحقول الكلمات المفتاحية. يُدمج المساران بخوارزمية Reciprocal Rank Fusion (RRF).

خوارزمية RRF

RRF هو أسلوب rank fusion طرحه Cormack وآخرون عام 2009 $TRAE_REF. الفكرة الجوهرية بسيطة للغاية: لا يهتم بالنتيجة الأصلية لكل مسار بحث (تشابه المتجهات مقابل نتيجة BM25 لا يقارنان مباشرة)، بل يهتم فقط بالترتيب الذي يعطيه كل مسار.

الصيغة:

RRF_score(d) = Σ  1 / (k + rank_i(d))
             i∈lists

حيث rank_i(d) هو ترتيب الوثيقة d في نتائج المسار i (بدءاً من 0)، وk ثابت تنعيم (نستخدم 60).

لنفترض أن الوثيقة A في المرتبة الأولى في البحث المتجهي، والخامسة في البحث بالكلمات المفتاحية:

RRF_score(A) = 1/(60+1) + 1/(60+6) = 0.0164 + 0.0152 = 0.0316

الوثيقة B في المرتبة الثالثة في البحث المتجهي، والثانية في البحث بالكلمات المفتاحية:

RRF_score(B) = 1/(60+4) + 1/(60+3) = 0.0156 + 0.0159 = 0.0315

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

التنفيذ

نفّذنا منطق دمج RRF في صنف RagEnhancementService. التدفق هو:

1. البحث المتجهي يرجع أعلى 20 نتيجة (مرتبة تنازلياً بتماثل جيب التمام)
2. البحث بالكلمات المفتاحية يرجع أعلى 20 نتيجة (MySQL LIKE على حقول title/content/keywords)
3. تُمرَّر نتائج المسارين إلى دالة reciprocalRankFusion بـ k=60
4. بعد دمج RRF تُرتَّب تنازلياً حسب النتيجة، ويُؤخذ أعلى K

تنفيذ البحث بالكلمات المفتاحية بسيط: تقطيع الجملة بالمسافات وعلامات الترقيم، أخذ الكلمات بطول ≥ 2، واستخدام شرط LIKE من MyBatis-Plus لاستعلام OR. لم نستخدم فهارس MySQL النصية الكاملة (FULLTEXT)، لأن حجم بيانات قاعدة المعرفة لدينا صغير (بضعة آلاف من العناصر)، وأداء LIKE كافٍ تماماً. إذا نما حجم قاعدة المعرفة مستقبلاً إلى عشرات الآلاف، سننظر في الانتقال إلى BM25 أو Elasticsearch.

اختيار قيمة k في RRF. كلما كبرت k، كان أثر اختلاف الترتيب على النتيجة أكثر تنعيماً؛ وكلما صغرت، ظهرت أفضلية الوثائق الأعلى ترتيباً بشكل أوضح. نستخدم 60، وهي القيمة الافتراضية في ورقة RRF الأصلية وفي Elasticsearch $TRAE_REF. في الاختبار، أداء k=60 كان مستقراً، ولا حاجة لمزيد من الضبط.

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

الطبقة الثالثة: Reranking — دع LLM يقوم بالفرز الأخير

حلّ Hybrid Search مشكلة «العثور على النتائج». لكن الترتيب الذي تُعرض به النتائج لا يزال يحدده نتيجة RRF — ونتيجة RRF تعكس الترتيب فقط، لا الصلة الوظيفية.

نعود إلى المثال السابق. يسأل المستخدم «كيفية التعامل مع مطالبات التعويض عن التسليم المتأخر». في النتائج قد يكون:

• وثيقة A: «إجراءات التعامل مع مطالبات التعويض عن التسليم المتأخر» (ذات صلة فعلاً)
• وثيقة B: «تحليل أسباب التسليم المتأخر» (الموضوع ذو صلة، لكن لا يجيب على السؤال)
• وثيقة C: «إحصاءات نسبة التسليم في الموعد لعام 2024» (البيانات ذات صلة، لكن السيناريو غير مناسب)

قد يضع البحث المتجهي B قبل A (لأن صياغة B أقرب إلى سؤال المستخدم)، وقد يضع البحث بالكلمات المفتاحية C في المقدمة (لأن كلمة «التسليم» تتطابق فيها مرات أكثر). بعد دمج RRF، قد يبقى الترتيب B > A > C.

Reranking هو إضافة فرز LLM أخير قبل إرجاع النتائج المدمجة. يُمرَّر الاستعلام والوثائق المرشحة معاً إلى نموذج lite، ويحكم النموذج على الوثيقة الأكثر صلة.

طريقة التنفيذ

ما نطلب من LLM فعله نسخة مبسطة من فرز pointwise. التحديد: نُرقّم الوثائق المرشحة (10 افتراضياً) ونرسلها مع استعلام المستخدم إلى نموذج lite، ويطلب الـ prompt من النموذج إخراج تسلسل الأرقام مرتباً من الأعلى صلة إلى الأقل. مثلاً عند إدخال 10 وثائق، يخرج النموذج "2,0,5,1,3,8,4,7,6,9"، أي الوثيقة رقم 2 الأكثر صلة والوثيقة رقم 9 الأقل صلة.

فكّرنا في استخدام نموذج Cross-Encoder للـ reranking — مثل BGE-Reranker-v2-m3 من معهد تشى يوان $TRAE_REF. يأخذ Cross-Encoder الاستعلام والوثيقة ويجمعهما في تسلسل إدخال واحد يُمرَّر للنموذج، ثم بعد النمذجة المشتركة يخرج درجة صلة بين 0 و1. الدقة أعلى فعلاً من فرز الـ prompt بالـ LLM.

لكننا اخترنا في النهاية حل LLM، والسبب هو تكلفة النشر. يحتاج Cross-Encoder إلى نشر خدمة نموذج إضافية (BGE-Reranker-v2-m3 بحجم نحو 2.8GB $TRAE_REF)، بينما نستخدم نموذج lite بالفعل في Query Rewriting، فيعيد Reranking استخدام واجهة النموذج نفسها بتكلفة نشر إضافية صفرية. لمقياس قاعدة معرفتنا (بضعة آلاف من الوثائق)، دقة فرز LLM كافية. إذا توسعت قاعدة المعرفة مستقبلاً إلى عشرات الآلاف، أو زادت متطلبات الدقة، يمكن الانتقال إلى Cross-Encoder — الواجهة مجردة بالفعل، ويكفي استبدال صنف التنفيذ.

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

استراتيجية التدهور. كـ Query Rewriting، عند فشل استدعاء النموذج يُخفض بصمت ويعيد الترتيب الأصلي بعد دمج RRF. Reranking تحسين للدقة، لا اعتماد وظيفي.

تصميم البنية: طبقة SDK + واجهة SPI

تنفيذ تقنيات التحسين الثلاث لم يوضع في نظام الأعمال cct-crm-backend، بل أُنزل إلى مكتبتنا الأساسية ai-sdk. السبب أن هذه القدرات ليست خاصة بأعمال التجارة الخارجية — أي نظام يستخدم RAG يستطيع إعادة استخدامها.

تنقسم البنية إلى ثلاث طبقات:

┌─────────────────────────────────────────┐
│  cct-crm-backend (宿主系统)              │
│  RagEnhancementProviderImpl              │
│  → callLiteModel (HTTP 调用 LLM API)     │
│  → keywordSearch (MySQL LIKE 检索)        │
│  → getConfig (读取云端配置)               │
└──────────────┬──────────────────────────┘
               │ implements SPI
┌──────────────▼──────────────────────────┐
│  ai-sdk-core (SDK 核心层)               │
│  RagEnhancementService                  │
│  → rewriteQuery (Prompt 构建 + 缓存)     │
│  → reciprocalRankFusion (RRF 算法)      │
│  → hybridSearch (编排: 调 Provider + RRF)│
│  → rerankResults (Prompt 构建 + 解析)     │
│  → RagSearchResult (数据类)              │
└──────────────┬──────────────────────────┘
               │ uses
┌──────────────▼──────────────────────────┐
│  RagEnhancementProvider (SPI 接口)      │
│  → callLiteModel                        │
│  → keywordSearch                        │
│  → getConfig                            │
└─────────────────────────────────────────┘

الخوارزميات الجوهرية (RRF، بناء الـ Prompt، تحليل النتائج) موجودة في طبقة SDK، بصفر اعتماد على Spring. يحتاج النظام المضيف فقط إلى تنفيذ واجهة SPI، وتوفير ثلاث قدرات: استدعاء LLM، والبحث بالكلمات المفتاحية، وقراءة الإعدادات. فائدة هذا التصميم: إذا ربطت أنظمة أخرى بـ ai-sdk مستقبلاً، يكفيها تنفيذ واجهة Provider للحصول على قدرات تحسين RAG كاملة دون تكرار التطوير.

مفاتيح الإعداد كلها في قاعدة البيانات. تُخزَّن خمسة عناصر إعداد في جدول pb_ai_config السحابي، بـ model_group = 'rag_enhancement':

مفتاح الإعداد	القيمة الافتراضية	الوصف
rag_query_rewrite_enabled	true	مفتاح تشغيل Query Rewriting
rag_hybrid_search_enabled	true	مفتاح تشغيل Hybrid Search
rag_reranking_enabled	true	مفتاح تشغيل Reranking
rag_hybrid_candidate_count	20	عدد استدعاءات البحث بالكلمات المفتاحية
rag_rerank_candidate_count	10	عدد مرشحي Reranking

يُحدَّث الإعداد كل 5 دقائق، وتعديل قاعدة البيانات يسري فوراً (بانتظار أقصاه 5 دقائق). لكل وظيفة تحسين مفتاح مستقل يمكن إيقافه منفرداً. إذا تأثر أداء وظيفة تحسين معينة في سيناريو خاص، أو احتاجت التكلفة إلى ضبط، يمكن إيقافها فقط دون التأثير على الوظيفتين الأخريين.

الأثر والتكلفة

بعد إطلاق وظائف التحسين الثلاث، لاحظنا في الاختبار الداخلي التغيرات الآتية:

دقة الاسترجاع. أعددنا 50 مجموعة استعلامات اختبار (تغطي خمسة سيناريوهات: استعلامات العملاء، الطلبات، المنتجات، الشحن، والسياسات)، وقارنا نسبة الإصابة في top-1 وtop-3 قبل التحسين وبعده. قبل التحسين نحو 68% لـ top-1، وبعد التحسين نحو 82%، بزيادة 14 نقطة مئوية. نسبة top-3 ارتفعت من 85% إلى 94%. هذه البيانات من اختبار داخلي وليست تقييماً أكاديمياً صارماً، لكن الاتجاه واضح.

زيادة التأخير. عند تفعيل طبقات التحسين الثلاث جميعها، زاد تأخير الاسترجاع المفرد من ~200ms إلى ~800ms-1.2s (بسبب استدعاءَي LLM أساساً). بالنسبة لسيناريو استرجاع قاعدة المعرفة، هذا التأخير مقبول — فانتظار المستخدم ثانية واحدة للحصول على نتيجة أدق أفضل تجربةً من انتظار 200ms للحصول على نتيجة غير ذات صلة. إذا كان التأخير حساساً، يمكن إيقاف Reranking (الذي يسهم بنحو 60% من التأخير الإضافي) والاكتفاء بـ Query Rewriting + Hybrid Search، فيكون زيادة التأخير نحو 300ms.

التكلفة. يستخدم كلٌ من Query Rewriting وReranking نموذج lite، ويستهلك استدعاء واحد نحو 200-500 tokens. وفق تسعير API لدينا، تبلغ تكلفة استرجاع محسَّن كامل واحد نحو 0.001-0.002 يوان. مع التخزين المؤقت لمدة 5 دقائق، الاستعلامات المتكررة عالية التردد لا تطلق استدعاءات نموذج متكررة، فالتكلفة الفعلية أقل.

الاتجاهات المستقبلية

بعد تطوير تقنيات التحسين الثلاث، ارتفعت دقة RAG فعلاً. لكن سقف RAG البسيط لا ينتهي هنا. عند تخطيطنا للمرحلة التالية، رأينا عدة اتجاهات تستحق المتابعة.

استبدال Cross-Encoder بـ LLM Reranking. استخدام نموذج lite في Reranking حالياً هو حل وسط يحكمه التكلفة. إذا نشرنا نموذج إعادة ترتيب متخصصاً مثل BGE-Reranker-v2-m3، يمكن رفع الدقة خطوة أخرى $TRAE_REF. ميزة Cross-Encoder أنه يرمّز الاستعلام والوثيقة بشكل مشترك، فيفهم العلاقات الدقيقة بين طبقتي النص، أما LLM فيقوم بفرز الـ prompt فقط. الواجهة مجردة بالفعل، والتبديل مسألة حجم عمل هندسي لا مشكلة بنية.

Context Engineering. بدأت الصناعة عام 2025 تتطور من RAG إلى Context Engineering $TRAE_REF. يهتم RAG بـ«ما الذي يُسترجَع»، بينما يهتم Context Engineering بـ«كيف يُبنى السياق الذي يُرسل للنموذج». إلى جانب نتائج الاسترجاع، ينبغي دمج دور المستخدم، والبيانات اللحظية، والمحادثة التاريخية، وحدود الصلاحيات، وغيرها من المعلومات متعددة الأبعاد، ليحصل النموذج لا على قائمة وثائق، بل على تعليمات عمل منظَّمة محملة بالسياق. نموذجنا السببي الأولي (تعلّم الخبرة + توجيه النموذج) يقوم فعلاً بعمل Context Engineering — ضخ الخبرة في system prompt هو بناء سياق. الخطوة التالية هي دمج نتائج RAG مع ضخ الخبرة وتوجيه النموذج بشكل أعمق.

Multimodal RAG. في أعمال التجارة الخارجية كمٌّ كبير من المعرفة في صورة بصرية — صور المنتجات، وممسوحات تقارير فحص الجودة، وصور قوائم التعبئة $TRAE_REF. يعالج RAG الحالي النص فقط، فتُدخَل هذه المعلومات البصرية يدوياً كأوصاف نصية (بفقد معلومات) أو لا يستطيع الذكاء الاصطناعي استرجاعها إطلاقاً. يستخدم Multimodal RAG نماذج لغة بصرية لتوليد Embedding مباشرة للصور، فيستطيع الذكاء الاصطناعي «أن يفهم» صور المنتجات ويسترجعها. هذا ذو قيمة كبيرة لقاعدة معرفة المنتجات ولوحدة فحص الجودة لدينا.

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

الخلاصة

ثلاث تقنيات، هدف واحد: تحويل البحث المتجهي من «يستطيع البحث» إلى «يبحث بدقة».

يعالج Query Rewriting مشكلة طرف الإدخال — الفجوة بين سؤال المستخدم العام والكلمات المفتاحية التي يتوقعها محرك البحث. يعالج Hybrid Search عمى طرف البحث — لكل من البحث المتجهي والبحث بالكلمات المفتاحية قصور، ودمج RRF يجعل نتيجتي المسارين متكاملتين. يعالج Reranking انحراف طرف الترتيب — ارتفاع تشابه المتجهات لا يعني ارتفاع الصلة الوظيفية، وLLM يقوم بالفرز الدلالي الأخير.

بتراكب الطبقات الثلاث، ارتفعت دقة الاسترجاع من 68% إلى 82% (نسبة إصابة top-1)، بتكلفة استرجاع مفرد نحو 0.001-0.002 يوان، وزيادة تأخير مضبوطة. للوظائف الثلاث مفاتيح مستقلة يمكن تشغيلها وإيقافها حسب الحاجة.

خط المعالجة المحسّن هذا ليس نهاية المطاف. المرحلة التالية من RAG هي Context Engineering — من «استرجاع الوثائق» إلى «بناء السياق»، ومن «إرجاع النتائج» إلى «تسليم الإجابات». نحن بالفعل في الطريق.