Agentic RAG: عندما يحتاج نظام الاسترجاع إلى اتخاذ القرار بشأن ما يبحث عنه

اطلب من نظام RAG التقليدي تلخيص عقد مكون من 50 صفحة، وسيعمل بشكل مثالي. لكن اطلب من نفس النظام "مقارنة بنود المسؤولية القانونية (liability clauses) في أهم ثلاث اتفاقيات مع الموردين الأوروبيين والتحقق مما إذا كان أي منها ينتهي قبل الربع الرابع (Q4)"، وسينهار تماماً. سيقوم النظام باسترجاع مجموعة عشوائية من الفقرات التي تحتوي على كلمات "مسؤولية"، "أوروبي"، و"الربع الرابع"، ثم يدمجها في فقرة تبدو واثقة، ولكنه سيفشل غالباً في الإجابة على سؤال العمل الفعلي بدقة.

يعتمد نظام توليد النصوص المدعوم بالاسترجاع التقليدي (Standard RAG) على عملية ذات خطوة واحدة (single-shot): يطرح المستخدم سؤالاً، ويقوم النظام بإجراء بحث دلالي (semantic search)، ثم يقوم النموذج اللغوي الكبير (LLM) بتلخيص النتائج. أما Agentic RAG فيغير هذه البنية بالكامل؛ حيث يتعامل مع الاسترجاع كمهمة تفكير متعددة الخطوات (multi-step reasoning)، مما يمنح النظام الاستقلالية لتفكيك الاستعلام المعقد، واختيار قواعد البيانات التي سيستعلم منها، وتقييم البيانات التي يعثر عليها، وإجراء عمليات بحث لاحقة حتى يصل إلى إجابة كاملة.

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

إليك كيف يعمل Agentic RAG في بيئة الإنتاج الفعلية، والتكلفة الحقيقية لتشغيله، وكيفية بنائه دون تراكم الديون التقنية (technical debt).

لماذا يفشل نظام RAG أحادي الخطوة (Single-Shot) في منطق الأعمال؟

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

في خط المعالجة (pipeline) الأساسي لنظام RAG، يتم تحويل استعلام المستخدم إلى متجه رياضي (تضمين - embedding). يبحث النظام في قاعدة بيانات المتجهات (vector database) عن مقاطع النصوص (chunks) الأكثر قرباً رياضياً من الاستعلام. يعمل هذا بشكل ممتاز للتشابه المفاهيمي؛ فإذا بحثت عن "سياسة العمل عن بعد"، فسيقوم نموذج التضمين باسترجاع فقرات حول "إرشادات العمل المرن" بنجاح.

ومع ذلك، نادراً ما يطرح مستخدمو الأعمال أسئلة مفاهيمية بحتة. بل يطرحون أسئلة تحليلية متعددة الخطوات (multi-hop):

• ▸"كيف كانت هوامش أرباحنا في دبي للربع الثالث مقارنة بالربع الثاني؟"
• ▸"من هم عملاؤنا النشطون الذين تفتقر عقودهم إلى ملحق الامتثال الجديد؟"
• ▸"ما هو إجمالي تذاكر الدعم الفني غير المحلولة الأسبوع الماضي لفئة الشركات الكبرى (enterprise tier)؟"

يفشل نظام RAG التقليدي هنا لأن الإجابة لا توجد في فقرة واحدة تنتظر الاسترجاع. تتطلب الإجابة على سؤال هوامش الأرباح عمليتين منفصلتين: الاستعلام من قاعدة بيانات SQL مهيكلة عن هوامش الربع الثاني، ثم الاستعلام عنها مجدداً للربع الثالث. وتتطلب الإجابة على سؤال العقود التحقق من نظام CRM عبر واجهة البرمجة (API) للعثور على "العملاء النشطين"، ثم البحث في قاعدة بيانات المتجهات لملفات PDF للتحقق من وجود ملحق الامتثال.

عندما يحاول نظام RAG تقليدي معالجة هذه الاستعلامات، فإنه يقوم ببساطة بتضمين الجملة بأكملها واسترجاع أقرب مقاطع النصوص. قد يسحب وثيقة من عام 2024 تذكر "هوامش الربع الثالث في دبي"، متجاهلاً سجل قاعدة البيانات الحالي تماماً. يعمل النظام بناءً على التقارب الدلالي (semantic proximity)، وليس التفكير المنطقي (logical reasoning).

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

آلية عمل Agentic RAG

بالنسبة لقادة الأعمال، لا يتعلق فهم آليات Agentic RAG بكتابة الكود بقدر ما يتعلق بفهم كيفية أتمتة سير العمل البشري المعقد. من خلال تفويض اتخاذ القرار إلى طبقة التنسيق (orchestration layer)، فإنك تستبدل مهام جمع البيانات اليدوية التي تستغرق ساعات بمحلل رقمي منظم يعمل في ثوانٍ معدودة. إليك كيف تعمل حلقة التفكير المؤتمتة هذه تحت الغطاء:

بدلاً من دفع الاستعلام مباشرة إلى قاعدة بيانات المتجهات، يقوم النظام بتوجيه الاستعلام إلى نموذج لغوي كبير يعمل كمخطط (planner). يتحول خط المعالجة (pipeline) من تسلسل خطي إلى حلقة تعتمد على الحالة (stateful loop).

1. تخطيط وتفكيك الاستعلام (Query Planning and Decomposition) عندما يسأل المستخدم "من هم العملاء النشطون الذين تفتقر عقودهم إلى ملحق الامتثال؟"، يقوم نموذج التوجيه (عادةً نموذج متطور من عائلة GPT-4o أو Claude 3.5) بتحليل الطلب. يدرك النموذج أن هذا يتطلب خطوات متعددة ويقوم بتفكيك الاستعلام إلى خطة:

• ▸الخطوة أ: الحصول على قائمة بالعملاء النشطين.
• ▸الخطوة ب: البحث في قاعدة بيانات العقود عن كل عميل للتحقق من الملحق.

2. اختيار الأدوات وتنفيذها (Tool Selection and Execution) يتم تزويد الوكيل (agent) بـ "أدوات" محددة—وهي دوال يمكنه استدعاؤها للتفاعل مع أنظمتك. قد يكون لديه وصول إلى أداة query_salesforce_api وأداة search_contract_vector_db. يقوم الوكيل بتنفيذ الخطوة أ عن طريق كتابة استعلام لواجهة برمجة Salesforce.

3. التقييم والتكرار (Evaluation and Iteration) بمجرد أن تعيد واجهة البرمجة (API) قائمة العملاء النشطين، يقوم الوكيل بتقييم البيانات المستلمة. يحتفظ بهذه البيانات في ذاكرته العاملة (نافذة السياق - context window) وينتقل إلى الخطوة ب، صياغة عمليات بحث محددة في قاعدة بيانات المتجهات لكل عميل في القائمة. إذا أرجع البحث نتائج غامضة، يمكن للوكيل تحسين مصطلحات البحث بشكل مستقل والمحاولة مرة أخرى.

4. الصياغة النهائية (Final Synthesis) فقط بعد أن ينجح الوكيل في جمع البيانات اللازمة من جميع الأدوات المطلوبة، يقوم بصياغة الإجابة النهائية وتقديمها للمستخدم.

تتيح هذه الحلقة التكرارية للنظام التنقل بين البيانات المهيكلة (SQL، واجهات البرمجة APIs) والبيانات غير المهيكلة (ملفات PDF، قواعد المعرفة) في نفس الوقت. وهي تحول الذكاء الاصطناعي من ملخص سلبي إلى منسق بيانات نشط، مما يوفر على فرق عملك عناء البحث اليدوي عن المعلومات عبر التطبيقات المنعزلة (siloed applications).

حسابات زمن الاستجابة والتكلفة: ما هي التكلفة الحقيقية للاستقلالية؟

إن العائق الرئيسي أمام نشر Agentic RAG ليس القدرة التقنية، بل التكلفة الفعلية للاستقلالية. في كل مرة يخطط فيها الوكيل لخطوة، أو يستدعي أداة، أو يقيم نتيجة، يجب عليه إجراء مكالمة منفصلة لواجهة برمجة تطبيقات النموذج (LLM API).

إذا كنت تدفع مقابل كل رمز (token)، فإن هذه الحلقات التكرارية تضاعف تكاليف الاستنتاج (inference). وإذا كنت تستضيف النماذج محلياً (on-premise)، فإن هذه الحلقات تستهلك طاقة معالجة وحدات معالجة الرسومات (GPUs) وتزيد بشكل كبير من زمن الوصول للرمز الأول (TTFT) للمستخدم النهائي.

لنفترض معدلاً تقريبياً مدمجاً لعائلة النماذج الرائدة (مثل GPT-4o أو Claude 3.5 Sonnet) في منتصف عام 2026: حوالي 3.00 دولارات لكل مليون رمز مدخل (input tokens) و 15.00 دولاراً لكل مليون رمز مخرج (output tokens).

إليك الحسبة الدقيقة لمقارنة استعلام واحد عبر البنيتين البرمجيتين:

RAG التقليدي (مكالمة واحدة):

• ▸استرجاع السياق، وإرساله إلى النموذج (LLM) للصياغة.
• ▸المدخلات: 3,000 رمز ($0.009)
• ▸المخرجات: 300 رمز ($0.0045)
• ▸التكلفة الإجمالية: ~0.0135$ لكل استعلام
• ▸زمن الاستجابة: ~1.5 إلى 2 ثانية

Agentic RAG (حلقة متعددة الخطوات):

• ▸المكالمة 1 (المخطط): يحلل الاستعلام. المدخلات 1,000 رمز، المخرجات 50 رمزاً = 0.00375$
• ▸المكالمة 2 (الأداة 1 - SQL): ينفذ أداة SQL. المدخلات 1,500 رمز، المخرجات 100 رمز = 0.006$
• ▸المكالمة 3 (الأداة 2 - المتجهات): يقيم نتائج SQL، ويبحث في قاعدة بيانات المتجهات. المدخلات 3,000 رمز، المخرجات 500 رمز = 0.0165$
• ▸المكالمة 4 (الصياغة): يقرأ جميع البيانات المجمعة ويجيب. المدخلات 5,000 رمز، المخرجات 400 رمز = 0.021$
• ▸التكلفة الإجمالية: ~0.047$ لكل استعلام
• ▸زمن الاستجابة: ~6 إلى 10 ثوانٍ

يعد نظام Agentic RAG أغلى بنحو 3.5 مرة لكل استعلام ويستغرق ما يصل إلى 5 مرات أطول لإرجاع الإجابة النهائية.

ولكن لتقييم الأثر الفعلي على الأعمال، قارن هذا بالبديل البشري. المحلل البشري في الولايات المتحدة أو منطقة الخليج الذي يتقاضى 80,000 دولار سنوياً يكلف حوالي 40 دولاراً في الساعة. إذا كانت مهمة الربط اليدوي بين البيانات تستغرق 15 دقيقة، فإنها تكلف الشركة 10.00 دولارات من تكلفة العمالة. بتكلفة 0.047 دولار لكل استعلام، يقدم Agentic RAG خفضاً في التكلفة بنسبة 99.5% ويقلص وقت التنفيذ من 15 دقيقة إلى 10 ثوانٍ. بالنسبة لمهام العمل عالية القيمة مثل تدقيق العقود، أو الامتثال التنظيمي، أو تركيب البيانات المالية، فإن العائد على الاستثمار (ROI) فوري ويعوض بسهولة زيادة الإنفاق على واجهات البرمجة (APIs).

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

هندسة Agentic RAG لبيئة الإنتاج

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

1. قواطع التيار وحدود الخطوات (Circuit Breakers and Step Limits) يمكن للوكيل غير المقيد أن يدخل بسهولة في حلقة مفرغة. إذا أرجعت أداة SQL خطأً، فقد يقوم وكيل سيئ الإعداد بإعادة كتابة الاستعلام والمحاولة مرة أخرى، ليفشل مراراً وتكراراً حتى يستنفد ميزانية واجهة البرمجة أو حد نافذة السياق. تتطلب أنظمة الإنتاج قواطع تيار (circuit breakers) صارمة. في LangGraph، يعني هذا تعيين حد تكرار صارم recursion_limit (على سبيل المثال، بحد أقصى 5 استدعاءات للأدوات لكل جلسة) وتوجيه الوكيل إلى خيار بديل مرن (مثل مطالبة المستخدم بالتوضيح) في حال الوصول إلى الحد الأقصى.

2. التوجيه الدلالي للتحكم في التكلفة (Semantic Routing for Cost Control) نظراً لأن Agentic RAG مكلف، تستخدم أنظمة الإنتاج موجهات دلالية (semantic routers) على مستوى البوابة. عند ورود استعلام، يحدد نموذج سريع ورخيص (مثل نموذج بـ 8 مليارات معامل أو نموذج تصنيف مخصص) مدى تعقيد الاستعلام. إذا كان السؤال "ما هي سياسة الإجازات لدينا؟"، يرسله الموجه إلى خط معالجة RAG التقليدي الرخيص. أما إذا كان السؤال "قارن معدلات تراكم الإجازات عبر فروعنا الأوروبية الثلاثة"، فيقوم الموجه بتصعيده إلى خط معالجة Agentic RAG المكلف. يحمي هذا النهج الهجين اقتصاديات الوحدة ويحافظ على انخفاض متوسط التكلفة لكل استعلام.

3. خطوط التقييم المؤتمتة (Automated Evaluation Pipelines) لا يمكنك قياس دقة نظام Agentic RAG بمجرد إلقاء نظرة سريعة على بضعة استعلامات تجريبية. نظراً لأن النظام غير حتمي (non-deterministic) ويختار مسارات البحث الخاصة به، فإن أي تغيير في الموجّه (prompt) أو وصف الأداة يمكن أن يتسبب في إخفاقات متتالية. تستخدم فرق الإنتاج أطر عمل مثل RAGAS لتشغيل اختبارات تراجع مؤتمتة (automated regression tests) مع كل عملية نشر، لتقييم النظام رياضياً بناءً على دقة السياق (Context Precision - هل عثر على البيانات الصحيحة؟) وموثوقية الإجابة (Answer Faithfulness - هل هلوس النموذج؟). يحميك هذا من نشر أخطاء صامتة قد تؤدي إلى حسابات تجارية خاطئة ومكلفة.

اتخاذ القرار بشأن البنية البرمجية

إن الاختيار بين RAG التقليدي و Agentic RAG هو عملية حسابية تجارية مباشرة تعتمد على طبيعة بياناتك وتوقعات مستخدميك.

اختر RAG التقليدي إذا:

• ▸كان مستخدموك يحتاجون أساساً إلى العثور على مستندات محددة أو البحث في إجراءات التشغيل القياسية (SOPs).
• ▸كانت بياناتك تعيش بالكامل في نصوص غير مهيكلة (ملفات PDF، مستندات Word، نصوص خام).
• ▸كان زمن الاستجابة الأقل من ثانيتين متطلباً صارماً لتبني المستخدمين للنظام.
• ▸كان يجب إبقاء التكلفة لكل استعلام أقل من بضعة سنتات.

اختر Agentic RAG إذا:

• ▸كان مستخدموك يتوقعون من النظام صياغة إجابات تجمع بين مستندات أو أنظمة متعددة ومختلفة.
• ▸كانت بياناتك هجينة، مما يتطلب من الذكاء الاصطناعي سحب السياق من قاعدة بيانات المتجهات والأرقام الدقيقة من قاعدة بيانات SQL مهيكلة أو واجهة برمجة تطبيقات (API).
• ▸كان المستخدمون على استعداد للانتظار من 5 إلى 10 ثوانٍ للحصول على إجابة شاملة وعالية الدقة.
• ▸كانت القيمة التجارية للإجابة الصحيحة (مثل تحليل العقود، تدقيق الامتثال، تركيب البيانات المالية) تبرر تكلفة حوسبة تتراوح بين 0.05$ إلى 0.10$ لكل استعلام.

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

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

كيف نبرر التكلفة العالية لنظام Agentic RAG للفريق المالي؟
يكمن التبرير في تعقيد المهمة وتكلفة العمالة البشرية. إذا كان مستخدموك يجرون عمليات بحث بسيطة (مثل البحث عن سياسات العطلات في الشركة)، فإن RAG التقليدي كافٍ وفعال للغاية من حيث التكلفة. ومع ذلك، إذا كان الاستعلام يستبدل سير عمل يدوي—مثل قضاء محلل مالي 30 دقيقة في مقارنة الأداء بين الربعين الثاني والثالث عبر قواعد بيانات إقليمية متعددة—فإن تكلفة واجهة البرمجة البالغة 0.05$ لاستعلام Agentic RAG توفر ما بين 10 إلى 20 دولاراً من تكلفة العمالة البشرية مع تقديم الإجابة في ثوانٍ. اطرح التكلفة ليس كعملية بحث باهظة الثمن، بل كعمالة رقمية منخفضة التكلفة للغاية.

هل يمكننا استخدام نماذج أصغر ومفتوحة الوزن (open-weight) لنظام agentic RAG لتقليل التكاليف؟
نعم، ولكن مع بعض المحاذير. النماذج الصغيرة مفتوحة الوزن (مثل فئة الـ 8 مليارات معامل من عائلة Llama) ممتازة لطبقة التوجيه الدلالي أو صياغة RAG التقليدي. ومع ذلك، فإن حلقة تخطيط الاستعلام واستدعاء الأدوات تتطلب قدرات تفكير منطقي عالية. بالنسبة لموجه الوكيل الأساسي (core agentic router)، ستحتاج عموماً إلى نماذج رائدة (مثل GPT-4o أو Claude 3.5، أو عمليات النشر المحلية لنماذج تزيد عن 70 مليار معامل مثل Qwen3.5 أو Llama 3.3 70B) لتنفيذ المنطق متعدد الخطوات بشكل موثوق دون التعرض للتوقف.

كيف نمنع الوكيل من كشف البيانات المقيدة أثناء بحثه؟
يجب فرض صلاحيات الوصول إلى البيانات على مستوى الأداة والبنية التحتية، وليس على مستوى الموجّه (prompt). لا تعتمد أبداً على موجّه النظام ("لا تعرض بيانات الموارد البشرية للمستخدمين غير المصرح لهم") لحماية البيانات. بدلاً من ذلك، يجب أن ترث الأدوات التي يستخدمها الوكيل للاستعلام من قاعدة البيانات هوية وصلاحيات المستخدم الذي قدم الطلب (على سبيل المثال، أمان مستوى الصف Row-Level Security في Postgres). إذا كان المستخدم لا يملك صلاحية الوصول إلى البيانات، فإن استدعاء الأداة بواسطة الوكيل سيعيد ببساطة نتيجة فارغة.

لماذا يعد إثبات المفهوم (PoC) الحالي لنظامنا بطيئاً جداً؟
تعاني معظم مشاريع إثبات المفهوم (POCs) للأنظمة الوكيلة من تضخم التوليد المتسلسل. إذا كان الوكيل بحاجة إلى فحص ثلاث قواعد بيانات، فإن التنفيذ البسيط سيستعلم منها واحدة تلو الأخرى، بانتظار معالجة النموذج (LLM) لكل خطوة. في بيئة الإنتاج، يمكنك حل ذلك عن طريق تشغيل استدعاءات الأدوات بالتوازي (مما يسمح للوكيل بإطلاق الاستعلامات الثلاثة في وقت واحد) واستخدام محركات استنتاج أسرع مثل vLLM إذا كنت تستضيف النظام محلياً. كما أن بث (streaming) الخطوات الوسيطة إلى واجهة المستخدم يمنع المستخدم من التحديق في شاشة تحميل فارغة لمدة عشر ثوانٍ.