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

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

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

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

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

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

أنظمة ذاكرة الوكلاء تتوافق مع تصنيف راسخ. فهم هذه الفئات يساعدك في تصميم بنية الذاكرة المناسبة لحالة الاستخدام المعنية.

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

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

• السعة: تختلف حسب النموذج (مثلاً 128 ألف token لـ GPT-4o، و200 ألف token لـ Claude)
• المقايضة: نوافذ السياق الأكبر تزيد التكلفة وزمن الاستجابة لكل طلب
• القيد الأساسي: السياق محدود، لذا يجب أن تقرر ما تضمنه وما تستبعده

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

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

# هيكل ذاكرة عرضية بسيط
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 أجزاء تشابهاً، حشوها في الأمر.

استعلام المستخدم → التضمين → بحث المتجهات (top-K) → الحشو في الأمر → LLM → الإجابة

قيود 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 آلاف إجمالي)
أمر النظام	10-15%	~1000 token
ذاكرة المحادثة	20-30%	~2000 token
المستندات المسترجعة	40-50%	~3500 token
محجوز للمخرجات	15-20%	~1500 token

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

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

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

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

# هيكل الإسناد
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 مع تقطيع قابل للتكوين واسترجاع وكيلي وإدارة ذاكرة وحراس هلوسة. :::