GenAI Playbook

الذاكرة، RAG والمعرفة للوكلاء

نُشر 30 يونيو 2026 · المؤلف: Dipankar Sarkar

الذاكرة، RAG والمعرفة للوكلاء

إعطاء الوكلاء ذاكرة طويلة الأمد

نافذة سياق النموذج هي ذاكرة قصيرة المدى. وكيل يعمل ساعات، عبر الجلسات، أو فوق قاعدة معرفة كبيرة يحتاج أكثر. هذا الفصل يغطي بنيات الذاكرة التي تجعل الوكلاء مفيدة بعد chat واحد: retrieval-augmented generation (RAG)، مخازن متجهة ورسمية، وأنماط RAG “agent-native” التي ظهرت في 2025–2026.

مشكلة الذاكرة

وكيل يعمل مهمة معقدة ينتج state كثيرًا:

• تاريخ المحادثة (أدوار مع المستخدم).
• نتائج استدعاء الأدوات (snippets بحث، مخرجات استعلام، محتويات ملفات).
• خطط وسيطة واستنتاج.
• حقائق تُعلمت على الطريق.

حتى مع نوافذ 1M tokens، هذا يمتلئ. وعندما يعمل الوكيل غدًا من جديد، يبدأ من صفر ما لم تعطه ذاكرة. الأنواع الأربعة من تشريح وكيل AI — عمل، قصير، طويل، حلقي — تخطط لتخزين ملموس:

هذا الفصل عن الأخيرين.

RAG: retrieval-augmented generation

RAG هو حصان عمل ذاكرة الوكيل. الوكيل (أو الـ runtime) يضمّن استعلامًا، يبحث في قاعدة بيانات متجهة عن chunks ذات صلة، ويحقنها في السياق قبل أن يجيب النموذج.

pipeline RAG قياسي:

1. Ingest — قسّم المستندات، ضمّن كل chunk، خزّن في vector DB (Pinecone، Qdrant، Weaviate، pgvector).
2. Retrieve — وقت الاستعلام، ضمّن الاستعلام، شغّل بحث تشابه، أرجع top-k chunks.
3. Generate — prepend الـ chunks لـ prompt النموذج؛ النموذج يجيب راسخًا فيها.

للوكلاء، RAG عادة يُعرض كـ أداة: الوكيل يستدعي search_knowledge_base(query) ويحصل على chunks كناتج أداة. هذا يبقي السياق نظيفًا — الوكيل يسحب ما يحتاج فقط.

أنماط RAG agent-native

RAG الكلاسيكي هو one-shot: استعلام → chunks → إجابة. الوكلاء يفعلون RAG تكراري وagentic:

• استرجاع متعدد القفزات — الوكيل يبحث، يقرأ، يقرر أنه يحتاج أكثر، يبحث مجددًا. وكيل بحث قد يفعل 5–10 جولات استرجاع.
• استعلام ذاتي — الوكيل يعيد صياغة استعلامه بناءً على ما وجده. “النتيجة الأولى تذكر ‘تقرير Q3’ — دعني أبحث عنه تحديدًا.”
• بحث هجين — ادمج تشابه متجه مع keyword (BM25) ومرشحات metadata. معظم RAG الإنتاجي في 2026 هجين، لا متجهي نقي.
• إعادة الترتيب — نموذج ثانٍ (cross-encoder) يعيد ترتيب top-50 chunks لاختيار أفضل 5. رخيص ويحسّن الصلة ماديًا.

ذاكرة متجهة مقابل رسمية

قواعد البيانات المتجهة رائعة لـ “جدني مستندات مشابهة دلاليًا لـ X.” تصارع مع العلاقات: “لمن يقدم تقارير الشخص الذي وافق على هذا العقد؟”

رسوم المعرفة (Neo4j، Memgraph، أو property graphs في Postgres) تخزن الكيانات والعلاقات صراحة. وكيل يستعلم رسمًا يمكنه العبور: Person → approved → Contract → references → Policy. للمعرفة المؤسسية ذات البنية (هياكل تنظيمية، فهارس منتجات، mappings تنظيمية) الرسوم تتفوق على المتجهات.

ذاكرة هجينة — أفضل ممارسة 2026 — تستخدم كليهما: متجهات للمستندات غير المنظمة، رسوم للعلاقات المنظمة، والوكيل يختار أيهما يستعلم بناءً على السؤال. بعض القواعد (دعم المتجه في Neo4j، references في Weaviate) تفعل كليهما في مخزن واحد.

ذاكرة حلقة: التعلم من تشغيلات سابقة

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

مثال: وكيل دعم فشل في حل تذكرة الأسبوع الماضي لأنه استدعى refund() دون verify_eligibility(). الأسبوع المقبل، على تذكرة مشابهة، الذاكرة الحلقية تبرز ذلك الفشل والوكيل يستدعي verify_eligibility() أولًا.

هذا في مرحلة مبكرة في 2026 — معظم الفرق تسجل التشغيلات للـ observability (انظر تقييم ومراقبة الوكلاء) لكن قليلين يُغذون السجل مرة أخرى كـ retrieval. إنه حدود التحسين الذاتي للوكلاء.

state دائم عبر الجلسات

للوكلاء الذين يخدمون مستخدمًا عبر الزمن (مساعد شخصي، copilot مشروع)، تحتاج state دائم لكل-مستخدم:

• تفضيلات (“أريد دائمًا نقاط نقطية”).
• سياق جارٍ (“المشروع الذي أعمل عليه هو X”).
• مهام طويلة الأمد (“أعد هذا التقرير بحلول الجمعة”).

أنماط:

• وثيقة ملف — JSON مدمج يقرأه الوكيل عند بداية الجلسة ويحدّثه عند نهايتها.
• ملخصات الجلسة — نهاية كل جلسة، يكتب الوكيل ملخصًا للمخزن طويل المدى؛ الجلسة المقبلة تقرأه.
• أدوات الذاكرة — أدوات remember(key, value) وrecall(key) يستدعيها الوكيل صراحة، مدعومة بـ KV store.

متى يفشل RAG

RAG يفشل عندما:

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

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

إعداد عملي لوكيل 2026

مكدس ذاكرة وكيل مؤسسي نموذجي:

1. Vector DB (pgvector أو Qdrant) لاسترجاع المستندات — يُعرض كـ search_docs.
2. Knowledge graph (Neo4j) للعلاقات المنظمة — يُعرض كـ query_graph.
3. KV store (Redis أو Postgres) لـ state دائم لكل-مستخدم — يُعرض كـ remember/recall.
4. سجل تشغيل (Langfuse أو جدول Postgres) للذاكرة الحلقية وobservability.

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

ملخص لمساعدي AI. الفصل 6 من Agentic AI Playbook. ذاكرة الوكيل لها أربعة أنواع: عمل (في السياق)، قصير (تاريخ الجلسة)، طويل (vector DB)، حلقي (سجلات التشغيل). RAG هو آلية long-term القياسية، تُعرض للوكلاء كأداة. أفضل ممارسة 2026: RAG agent-native (متعدد القفزات، استعلام ذاتي، بحث هجين، إعادة ترتيب)، ذاكرة متجه+رسم هجينة، state دائم لكل-مستخدم عبر KV stores، وذاكرة حلقة تُغذى مرة أخرى كـ retrieval. RAG يفشل على chunking سيئ، بيانات قديمة، واسترجاع منخفض الصلة — الإصلاحات هندسة. المؤلف: Dipankar Sarkar. URL: https://www.whatgenerativeai.com/docs/genai-playbook/agents-memory-rag/