بنية Agentic RAG: تجاوز البحث المتجهي البسيط في بيئات الإنتاج

يعمل نظام توليد النصوص المدعوم بالاسترجاع (RAG) الأساسي بشكل مثالي خلال المرحلة التجريبية (pilot). تطرح سؤالاً، فيعثر على مقطع (chunk) ذي صلة في قاعدة بيانات المتجهات (vector database)، ثم يلخص الإجابة. ولكن عندما تنشر هذه البنية نفسها في بيئة الإنتاج (production) ويسأل المستخدم: "كيف تغيرت التزامات المسؤولية عن البيانات لدينا بين اتفاقيات الموردين لعامي 2024 و2026؟"، ينهار خط المعالجة (pipeline). حيث يسترجع بنوداً مفككة، ويهلوس بمقارنة غير صحيحة، مما يزعزع ثقة المستخدم.

المشكلة ليست في نموذج اللغة (LLM)، بل في البنية المعمارية (architecture). لقد وصل البحث الدلالي التقليدي (semantic search) إلى سقف دقة محدود عند التعامل مع استعلامات المؤسسات المعقدة، مما جعل الاسترجاع التكراري الموجه بالوكلاء (agent-driven retrieval) هو المعيار الجديد في بيئات الإنتاج.

على مستوى القطاع، تتعثر معظم مشاريع الذكاء الاصطناعي للمؤسسات في مرحلة التجريب اللانهائية بسبب تراكم ديون الذكاء الاصطناعي (AI debt): سلاسل موجّهات (prompt chains) متشابكة، ووكلاء غير مراقبين، وخطوط معالجة RAG بجودة العرض التجريبي لا يمكنها التعامل مع التفكير متعدد الخطوات (multi-step reasoning). بالنسبة لقادة الأعمال، يمثل هذا مئات الآلاف من الدولارات المهدرة في رواتب المهندسين وفرص الكفاءة التشغيلية الضائعة. تنقل Verel Systems الذكاء الاصطناعي من هذه الحالة العشوائية إلى بيئة الإنتاج الفعلية. إن إصلاح نظام الاسترجاع المعطل يتطلب الابتعاد عن عمليات البحث المتجهي أحادية المسار، وتطبيق بنية معمارية يخطط فيها النظام، ويسترجع، ويقيم، ويصحح نفسه قبل عرض الإجابة على المستخدم—مما يحمي استثمارك الرأسمالي ويزيد من تبني المستخدمين للنظام.

سقف دقة البحث المتجهي البسيط

يعتمد نظام RAG البسيط (Naive RAG) على عملية خطية مباشرة: تضمين (embed) استعلام المستخدم، وإجراء بحث تشابه جيب التمام (cosine similarity) في قاعدة بيانات المتجهات للعثور على المقاطع النصية الأكثر تشابهاً (top-k)، ثم تمرير هذه المقاطع إلى النموذج لتوليد الإجابة.

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

عندما يطلب أحد المديرين مقارنة البيانات المالية الربع سنوية أو تلخيص نمط متكرر عبر خمسين تقريراً عن الحوادث، فإن عملية بحث دلالي واحدة لا يمكنها العثور على الإجابة. يتطلب هذا الاستعلام تفكيراً متعدد الخطوات (multi-hop reasoning). وللإجابة على سؤال مقارنة العقود المذكور أعلاه، سيقوم المحامي البشري أولاً بتحديد موقع اتفاقية 2024، والعثور على قسم المسؤولية وقراءته، ثم تحديد موقع اتفاقية 2026، والعثور على قسم المسؤولية الخاص بها، وأخيراً مقارنة الاثنين.

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

العواقب التجارية لهذا الخلل الهيكلي وخيمة. يدرك المستخدمون سريعاً أنه لا يمكن الوثوق بالنظام في الأسئلة المعقدة، فيعودون إلى القراءة اليدوية—مما يعني دفع رواتب عالية لموظفين كبار للقيام بالبحث اليدوي—ويتحول استثمار المؤسسة في أداة الذكاء الاصطناعي الداخلية إلى تكلفة غارقة. يتطلب استبدال خط المعالجة الهش هذا نقل تدفق التحكم (control flow) من سكربت ثابت إلى طبقة تنسيق ذاتية (autonomous orchestration layer) لحماية العائد على الاستثمار (ROI) لبرمجياتك.

ما هو الـ Agentic RAG فعلياً؟

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

في هذه البنية المعمارية، يستخدم agentic RAG نماذج LLMs لصياغة الاستعلامات بشكل تكراري والتحقق من السياق المسترجع قبل التوليد. عندما يطرح المستخدم سؤالاً معقداً، يقوم نموذج التنسيق (orchestrator model) أولاً بكتابة خطة، حيث يفكك موجّه (prompt) المستخدم إلى سلسلة من استعلامات البحث الأصغر والمستهدفة.

في مثال مقارنة العقود، ينفذ الوكيل (agent) أولاً بحثاً يستهدف تحديداً بنود المسؤولية لعام 2024، ويقرأ السياق المسترجع، ثم يقيم ما إذا كان هذا السياق يحتوي بالفعل على المعلومات المطلوبة. وإذا أعاد البحث بيانات غير ذات صلة، يعيد الوكيل كتابة استعلام البحث ويحاول مجدداً. وبمجرد تأمين بيانات عام 2024، ينتقل للبحث عن بيانات عام 2026. ولا يقوم بصياغة الإجابة النهائية إلا بعد جمع كافة المكونات المطلوبة والتحقق منها بنجاح.

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

بنية الاسترجاع التكراري

على الرغم من أن تطبيق الرسوم البيانية الحافظة للحالة (stateful graphs) وأدوات إعادة الترتيب (rerankers) يبدو قراراً هندسياً بحتاً، إلا أنه في جوهره استراتيجية للحد من المخاطر. فمن خلال إنفاق المزيد قليلاً على المعالجة الحاسوبية الإضافية (computational overhead)، تحمي المؤسسات سمعتها التجارية من الأخطاء العلنية وتضمن اتخاذ قرارات الأعمال المصيرية بناءً على نقاط بيانات موثقة، وليس على ضوضاء إحصائية. يتطلب بناء هذا النظام تنسيقاً حافظاً للحالة (stateful orchestration). وعادةً ما نقوم بتطبيق ذلك باستخدام أطر عمل قائمة على الرسوم البيانية مثل LangGraph، والتي تتيح لنا تحديد عقد معينة (تفكيك الاستعلام، الاسترجاع، التقييم، التوليد) والروابط الشرطية (conditional edges) التي تصل بينها.

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

فبدلاً من الاعتماد فقط على درجة التشابه الخاصة بقاعدة بيانات المتجهات، يمرر النظام المستندات المسترجعة عبر نموذج متخصص تم تدريبه خصيصاً لتقييم مدى الصلة. إن إضافة إعادة الترتيب عبر التشفير المتقاطع (مثل Cohere Rerank v3) يضيف زمن استجابة (latency) تقديرياً يتراوح بين 50 إلى 150 مللي ثانية لكل خطوة بحث، ولكنه يحسن درجات NDCG. ويعد مقياس الكسب التراكمي المخصوم المعياري (NDCG) معياراً صناعياً لجودة البحث؛ حيث تعني الدرجة الأعلى وضع المستندات الأكثر صلة في مقدمة القائمة بشكل موثوق.

ورغم أن 50-150 مللي ثانية تبدو ضئيلة، إلا أنه في الحلقة التكرارية حيث قد يجري الوكيل ثلاثة أو أربعة عمليات بحث قبل توليد الإجابة، يتراكم زمن الاستجابة (latency). قد يعيد نظام RAG البسيط إجابة في ثانيتين، بينما قد يستغرق نظام Agentic RAG الذي يتعامل مع استعلام معقد ما بين 8 إلى 12 ثانية تقريباً.

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

قياس الأثر التجاري: ملاءمة الإجابة (Answer Relevancy)

لا يمكنك إدارة نظام ذكاء اصطناعي في بيئة الإنتاج بناءً على انطباعات المستخدمين العشوائية. يجب أن تمتلك مقاييس حتمية (deterministic metrics) لإثبات أن بنية الوكلاء تتفوق فعلياً على خط المعالجة البسيط الذي حلت محله.

نحن نقيم أنظمة الاسترجاع باستخدام أطر عمل برمجية تقيس مخرجات خط المعالجة مقابل بيانات مرجعية حقيقية (ground-truth)، مما يقيس التحسن في ملاءمة الإجابة (answer relevancy) عند استخدام الاسترجاع الموجه بالوكلاء مقارنة بالبحث البسيط بطريقة top-k.

يقيس معيار ملاءمة الإجابة (Answer relevancy) مدى مباشرة استجابة النظام للموجّه الأصلي للمستخدم، مع خصم درجات في حال كانت الإجابات غير مكتملة أو تحتوي على تفاصيل جانبية غير ضرورية. بالنسبة لمؤسسة تضم 500 موظف معرفي، فإن الانتقال من دقة استرجاع تبلغ 60% إلى 95% يوفر في المتوسط 4 ساعات أسبوعياً لكل موظف كانت تضيع في المراجعة والتحقق اليدوي—مما يترجم إلى أكثر من 1.2 مليون دولار من الإنتاجية المستردة سنوياً. هذا التحسن الكبير هو الفارق بين أداة داخلية تحمي الإيرادات بفعالية عبر الكشف عن مخاطر العقود بدقة، وبين مشروع تجريبي مهجور.

إلى جانب ملاءمة الإجابة، يجب على أنظمة الإنتاج قياس:

• ▸دقة السياق (Context Precision): هل نجح البحث التكراري وإعادة الترتيب في وضع الفقرات الصحيحة في مقدمة نافذة السياق (context window)؟
• ▸الموثوقية (Faithfulness): هل يمكن إرجاع كل ادعاء في الإجابة النهائية المولدة مباشرة إلى مستند مسترجع محدد؟

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

وبدلاً من بناء خطوط التقييم المعقدة هذه، وآلات الحالة (state machines)، وأدوات إعادة الترتيب المخصصة من الصفر—وهو ما يتطلب عادةً من 3 إلى 6 أشهر من رواتب كبار المهندسين—يمكن للمؤسسات نشر أنظمة جاهزة للإنتاج ومصممة مسبقاً للتعامل مع هذه المقايضات بدقة ومباشرة.

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

إن الانتقال إلى بنية الوكلاء (agentic architecture) يزيد من الوقت المستغرق للإجابة على الاستعلام وتكاليف واجهة برمجة التطبيقات (API) المرتبطة به. ففي كل مرة يخطط فيها الوكيل لخطوة، أو يقيم مستنداً، أو يعيد كتابة بحث، فإنه يستهلك رموزاً (tokens).

لنأخذ بعين الاعتبار تطبيقاً قياسياً للمؤسسات باستخدام عائلة النماذج الرائدة الحالية، بافتراض تكلفة تقديرية لواجهة برمجة التطبيقات تبلغ 2.50 دولار لكل مليون رمز مدخل (input tokens) و10.00 دولار لكل مليون رمز مخرج (output tokens).

*حساب التكلفة لـ Agentic RAG: 8,500 رمز مدخل * (2.50 دولار / 1,000,000) = 0.021 دولار. 900 رمز مخرج * (10.00 دولار / 1,000,000) = 0.009 دولار. الإجمالي: 0.030 دولار.

إن القفزة من سنت واحد إلى ثلاثة سنتات لكل استعلام تعد غير ذات أهمية بالنسبة لبيئات العمل الداخلية للمؤسسات. فإذا كان فريقك القانوني يجري 1,000 استعلام معقد عن العقود شهرياً، فإن تكلفة استنتاج (inference) النموذج ترتفع من 11 دولاراً إلى 30 دولاراً فقط. في المقابل، فإن القيمة التجارية لمنع بند عقد واحد مهلوس تعادل تكلفة تشغيل الاسترجاع الموجه بالوكلاء لسنوات.

ومع ذلك، تتطلب هذه البنية المعمارية مهندسين كباراً لتطبيقها بشكل صحيح. فبناء آلة الحالة (state machine)، وضبط أداة إعادة الترتيب (reranker)، وإعداد خطوط التقييم يتطلب مجموعة مهارات مختلفة تماماً عن كتابة سكربت Python بسيط يربط قاعدة بيانات المتجهات بواجهة برمجة تطبيقات LLM.

الأسئلة الشائعة

ما هو العائد المتوقع على الاستثمار (ROI) وتكلفة تطبيق الترقية إلى بنية Agentic RAG؟ في حين أن تكاليف استعلام الـ API ترتفع قليلاً (من حوالي 0.01 دولار إلى 0.03 دولار لكل استعلام)، فإن الاستثمار الأساسي يكمن في الإعداد الهندسي، والذي يتراوح عادةً بين 15,000 إلى 50,000 دولار اعتماداً على تعقيد الأنظمة القديمة. ويتحقق العائد على الاستثمار من خلال مسارين: الحد الفوري من المخاطر (منع أخطاء الامتثال أو الأخطاء التشغيلية المكلفة الناتجة عن البيانات المهلوسة) واستعادة الإنتاجية المفقودة. بالنسبة للفرق التي تتعامل مع مستندات معقدة، فإن تقليل وقت التحقق اليدوي بنسبة 80% يؤدي عادةً إلى استرداد كامل التكاليف في غضون 3 إلى 6 أشهر من النشر.

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

هل نحتاج إلى استبدال قاعدة بيانات المتجهات الحالية لدينا لاستخدام هذه البنية؟ في الغالب لا. إن Agentic RAG عبارة عن طبقة تنسيق (orchestration layer) تعمل فوق قاعدة بياناتك الحالية. وسواء كنت تستخدم Qdrant أو pgvector أو Pinecone, فإن الوكيل ببساطة يستخدم قاعدتك الحالية كأداة من أدواته. الترقية تتم في منطق التطبيق (application logic) وليس في طبقة التخزين.

ما مدى بطء عملية الاسترجاع التكراري بالنسبة للمستخدم النهائي؟ عادةً ما يستجيب نظام RAG البسيط في أقل من 3 ثوانٍ. أما نظام الوكلاء الذي يحل استعلاماً معقداً يتطلب عمليات بحث متعددة فقد يستغرق ما بين 8 إلى 15 ثانية تقريباً اعتماداً على عدد حلقات الاسترجاع. يجب عليك تصميم واجهة المستخدم لبث عملية تفكير الوكيل (مثل: "قراءة تقرير الربع الثاني...") حتى يفهم المستخدمون أن النظام يعمل بنشاط على طلبهم المعقد.

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

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