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

لماذا يحتاج الوكلاء للذاكرة

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

ذاكرة الوكيل تخدم ثلاثة أغراض متميزة:

الغرض	مثال	ما الذي يتعطل بدونها
سياق المحادثة	تذكر أن المستخدم قال "مشروعي يستخدم PostgreSQL" قبل خمس رسائل	الوكيل يطرح نفس الأسئلة التوضيحية بشكل متكرر
المعرفة الواقعية	استرجاع سياسة استرداد الشركة من المستندات الداخلية	الوكيل يخترع سياسات أو يعطي إجابات عامة
التفضيلات المكتسبة	معرفة أن هذا المستخدم يفضل أمثلة كود موجزة بدل الشروحات المطولة	الوكيل لا يستطيع تخصيص التفاعلات

تصنيف الذاكرة

أنظمة ذاكرة الوكلاء تتوافق مع تصنيف راسخ. فهم هذه الفئات يساعدك في تصميم بنية الذاكرة المناسبة لحالة الاستخدام المعنية — وفي المقابلة، تسمية الطبقات الأربع كلٌّ على حدة هو ما يمنع «أضِف ذاكرة» من أن تكون إجابة فضفاضة.

الذاكرة العاملة (نافذة السياق)

نافذة سياق LLM هي الذاكرة العاملة للوكيل. كل ما يمكن للنموذج "رؤيته" في وقت الاستدلال — أمر النظام، تاريخ المحادثة، المستندات المسترجعة، نتائج الأدوات — يجب أن يتسع داخل هذه النافذة.

• السعة: تختلف حسب النموذج، وقد نمت نوافذ السياق في النماذج الرائدة بمقادير هائلة خلال سنوات قليلة. اقرأ الرقم الحالي من صفحة النماذج لدى المزوّد نفسه (Anthropic وOpenAI وGoogle) بدل الاعتماد على أي رقم مكتوب في دورة — بما فيها هذه.
• المقايضة: نوافذ السياق الأكبر تزيد التكلفة وزمن الاستجابة لكل طلب
• القيد الأساسي: السياق محدود، لذا يجب أن تقرر ما تضمنه وما تستبعده

نصيحة للمقابلة: «استخدم نافذة سياق أكبر» إجابة ضعيفة حتى حين تكون النافذة ضخمة. التكلفة تتناسب مع ما تضعه فيها، وجودة الانتباه تتدهور عبر المدخلات الطويلة جداً، وخطوة استرجاع تنتقي 3 أجزاء جيدة تتفوق على أخرى تُغرق النموذج بـ 300 جزء متوسط. قل هذا بصوت مسموع — فهو التمييز الذي تقيسه الجولة.

الذاكرة العرضية (تاريخ المحادثة)

الذاكرة العرضية تخزن تسلسل التفاعلات السابقة — ما قاله المستخدم، ما فعله الوكيل، ما الأدوات التي استُدعيت، وما النتائج التي عادت.

# هيكل ذاكرة عرضية بسيط
episodic_memory = [
    {"role": "user", "content": "اعثر على جميع الطلبات فوق 500$"},
    {"role": "assistant", "content": None, "tool_calls": [
        {"name": "query_orders", "args": {"min_amount": 500}}
    ]},
    {"role": "tool", "content": "وُجد 23 طلباً بإجمالي 18,450$"},
    {"role": "assistant", "content": "وجدت 23 طلباً فوق 500$..."},
]

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

الذاكرة الدلالية (قاعدة المعرفة)

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

• التخزين: قواعد بيانات المتجهات (مثل Pinecone وWeaviate وChroma وpgvector)، مخازن المستندات
• الاسترجاع: بحث التشابه القائم على التضمين، البحث بالكلمات المفتاحية، أو الأساليب الهجينة
• النطاق: مستندات الشركة، كتالوجات المنتجات، قواعد المعرفة، مستودعات الكود

الذاكرة الإجرائية (الأنماط المكتسبة)

الذاكرة الإجرائية تلتقط كيف يجب أن يتصرف الوكيل — الأنماط وتدفقات العمل والاستراتيجيات التي تعلمها. يمكن تنفيذها كالتالي:

• أوامر النظام مع التعليمات والأمثلة
• أمثلة few-shot مخزنة ومسترجعة ديناميكياً
• أوزان نموذج مضبوطة بدقة تشفر سلوكيات محددة

بنيات RAG للوكلاء

RAG هو الآلية الأساسية لربط الوكلاء بالمعرفة الخارجية. البنية التي تختارها لها تأثير كبير على جودة الإجابات.

RAG البسيط

الأسلوب الأبسط: تضمين الاستعلام، استرجاع أعلى K أجزاء تشابهاً، حشوها في الأمر.

قيود RAG البسيط:

• تمريرة استرجاع واحدة — إذا أخطأ البحث الأول المحتوى ذا الصلة، تتدهور الجودة
• لا إعادة صياغة للاستعلام — سؤال المستخدم الخام قد لا يتطابق مع طريقة تخزين المعلومات
• لا تحقق — لا يستطيع الوكيل فحص ما إذا كان المحتوى المسترجع يجيب فعلاً على السؤال

RAG الوكيلي

RAG الوكيلي يعامل الاسترجاع كعملية استدلال متعددة الخطوات. الوكيل يخطط وي​سترجع ويقيّم ويكرر بنشاط.

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

# سؤال معقد يتطلب تفكيكاً
user_query = "قارن إيرادات الربع الثالث والرابع واشرح المحركات الرئيسية"

# الوكيل يفكك إلى استعلامات فرعية
sub_queries = [
    "أرقام وتفصيل إيرادات الربع الثالث",
    "أرقام وتفصيل إيرادات الربع الرابع",
    "الأحداث التجارية الرئيسية بين الربع الثالث والرابع",
]
# كل استعلام فرعي يُبحث بشكل مستقل، وتُجمع النتائج

التأمل الذاتي: بعد استرجاع المستندات، يقيّم الوكيل ما إذا كانت النتائج كافية للإجابة على السؤال.

# أمر التأمل الذاتي (مفاهيمي)
reflection_prompt = """
بالنظر إلى هذه المستندات المسترجعة: {retrieved_docs}
والسؤال الأصلي: {user_query}

هل تحتوي هذه المستندات على معلومات كافية للإجابة على السؤال؟
- إذا نعم: تابع لتوليد الإجابة
- إذا لا: ما المعلومات الإضافية المطلوبة؟ أعد صياغة الاستعلام.
"""

الاسترجاع متعدد القفزات: بعض الأسئلة تتطلب تسلسل عمليات استرجاع متعددة — إجابة البحث الأول تُوجه ما يجب البحث عنه بعد ذلك.

استعلام: "من يدير الفريق الذي بنى الميزة X؟"
  → بحث 1: "الميزة X" → يجد "بُنيت بواسطة فريق ألفا"
  → بحث 2: "مدير فريق ألفا" → يجد "يديره سارة تشن"
  → الإجابة: "سارة تشن تدير الفريق الذي بنى الميزة X"

اختيار البنية المناسبة

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

استراتيجيات التقطيع

كيفية تقسيم المستندات إلى أجزاء تؤثر مباشرة على جودة الاسترجاع. الاستراتيجية المناسبة تعتمد على نوع المحتوى وأنماط الاستعلام.

الاستراتيجية	كيف تعمل	الأفضل لـ	العيب
الحجم الثابت	التقسيم كل N token مع تداخل	محتوى متجانس (سجلات، نصوص مكتوبة)	يقطع في منتصف الجملة، يكسر السياق
العودي	التقسيم بالفقرات، ثم الجمل، ثم الرموز	مستندات مهيكلة (مقالات، وثائق)	يتطلب ضبط الفواصل حسب نوع المحتوى
الدلالي	تجميع الجمل حسب تشابه التضمين	مستندات متعددة المواضيع	مكلف حسابياً وقت الاستيعاب
الواعي بالمستند	التقسيم بالعناوين أو الأقسام أو الحدود المنطقية	تنسيقات مهيكلة (Markdown وHTML والكود)	يتطلب منطق تحليل خاص بالمحتوى

المبدأ الأساسي: يجب أن تكون الأجزاء مكتفية ذاتياً بما يكفي لتكون مفهومة بدون السياق المحيط، ولكن صغيرة بما يكفي لتكون دقيقة. نقطة بداية شائعة هي 256-512 token مع تداخل 10-20%.

إدارة نافذة السياق

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

التلخيص

ضغط أدوار المحادثة القديمة في ملخص، مع الاحتفاظ بالرسائل الأخيرة كما هي.

# استراتيجية إدارة السياق
context = []
context.append(system_prompt)              # ثابت: ~500 token
context.append(conversation_summary)        # مضغوط: ~200 token
context.append(recent_messages[-5:])        # حرفي: ~1000 token
context.append(retrieved_documents[:3])     # أعلى 3 أجزاء: ~1500 token
# الإجمالي: ~3200 token — يتسع بشكل مريح ضمن الميزانية

النافذة المنزلقة

الاحتفاظ فقط بآخر N رسالة في السياق، وإسقاط الأقدم.

• الميزة: بسيطة التنفيذ، استخدام متوقع للرموز
• العيب: تفقد السياق المبكر الذي قد يكون لا يزال ذا صلة

التنقية القائمة على الأهمية

تسجيل كل جزء من السياق حسب صلته بالاستعلام الحالي وإسقاط العناصر منخفضة الأهمية أولاً.

• الرسائل التي ذكر فيها المستخدم متطلبات أساسية: أهمية عالية
• رسائل المجاملة أو التأكيد: أهمية منخفضة
• نتائج الأدوات من خطوات سابقة: أهمية متوسطة (تُلخص عند الحاجة)

تخصيص ميزانية الرموز

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

تبدأ الأداة أدناه من المثال المحسوب — نافذة 8,000 رمز مقسّمة 1,000 / 2,000 / 3,500، فيتبقى 1,500 للإجابة. ارفع أي شريط من أشرطة المدخلات وراقب احتياطي المخرجات وهو ينخفض. وحين يصير سالباً، تكون قد صمّمت نظاماً لا يستطيع الرد.

كنقطة انطلاق، استهدف تقريباً 10-15% لأمر النظام، و20-30% لذاكرة المحادثة، و40-50% للمستندات المسترجعة، و15-20% محجوزة للمخرجات. هذه قيم افتراضية تنطلق منها لا قواعد ملزمة — فوكيل التلخيص يقلبها رأساً على عقب.

إسناد المصادر ومنع الهلوسة

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

إسناد المصادر

كل ادعاء في استجابة الوكيل يجب أن يرتبط بجزء محدد من المصدر:

# هيكل الإسناد
attribution = {
    "claim": "سياسة الاسترداد تسمح بالإرجاع خلال 30 يوماً",
    "source_chunk_id": "policy-doc-chunk-42",
    "source_document": "refund-policy-v3.pdf",
    "confidence": 0.92,
    "relevant_excerpt": "يمكن للعملاء إرجاع المنتجات خلال 30 يوماً تقويمياً..."
}

منع الهلوسة

يجب أن يقتصر الوكيل على الادعاءات المدعومة بالمحتوى المسترجع. الاستراتيجيات الشائعة:

• فحص التأريض: مقارنة كل جملة في الاستجابة مع الأجزاء المسترجعة
• الامتناع عند عدم اليقين: إذا لم يتناول أي محتوى مسترجع السؤال، قل "لا أملك معلومات حول ذلك" بدلاً من التخمين
• الاقتباس المباشر: تضمين مقتطفات ذات صلة من المستندات المصدرية
• تسجيل الثقة: تعيين درجات ثقة ووضع علامات على الادعاءات منخفضة الثقة للمراجعة البشرية

مقاييس التقييم

الوكلاء المدعومون بـ RAG يحتاجون تقييماً منهجياً. ثلاثة مقاييس أساسية مهمة:

المقياس	ما يقيسه	كيفية التقييم
الأمانة	هل تحتوي الإجابة فقط على معلومات من المصادر المسترجعة؟	فحص كل ادعاء مقابل أجزاء المصدر — معاقبة الادعاءات غير المدعومة
الصلة	هل المستندات المسترجعة ذات صلة بالسؤال؟	تقييم مدى تناول الأجزاء المسترجعة للاستعلام
الاكتمال	هل تتناول الإجابة جميع أجزاء السؤال؟	مقارنة تغطية الإجابة مع المجموعة الكاملة للمعلومات ذات الصلة

أبعاد تقييم إضافية لأنظمة الإنتاج:

• زمن الاستجابة: كم يستغرق خط أنابيب الاسترجاع والتوليد الكامل؟
• التكلفة: كم عدد الرموز المستهلكة لكل استعلام (الاسترجاع + التوليد)؟
• المتانة: هل تتدهور الجودة مع الاستعلامات الغامضة أو المدخلات العدائية أو الأسئلة خارج النطاق؟

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

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