ذاكرة وكيل بتتذكر فعلاً: الـ knowledge graphs وتجميع السياق

المشكلة: نماذج بلا حالة، ومحادثات إلها حالة

خليني أحكي معك دغري: نموذج اللغة ما عنده ذاكرة. كل استدعاء صفحة بيضا. الإيهام بنظام "بيتذكرك" هو كله هندسة بتصير برا النموذج، قبل ما ينبعت الـ prompt أصلاً.

إذا غلطت بهالهندسة، رح توقع بالفشلين الكلاسيكيين. يا الوكيل بينسى شو قال المستخدم قبل تلات أدوار، يا بتحشي كل تاريخ المحادثة بكل طلب وبتتفرج على فاتورة الـ tokens والـ latency عم يتفجروا بينما الصلة بالموضوع عم تنزل. ذاكرة الوكيل الحقيقية هي انضباط إنك تقرر، لكل طلب، شو بالضبط لازم يشوف النموذج وولا شي زيادة.

الذاكرة مش شي واحد بتشغّله. هي أربع آليات مختلفة بتكاليف مختلفة ووظايف مختلفة، بتتجمع بنافذة سياق واحدة وقت الطلب.

نحنا مشغّلين هالشي بالإنتاج بـ Exfinity، منصة التجارة بالـ AI متعددة المستأجرين تبعنا، اللي فيها تمن وكلاء بيتشاركوا طبقة ذاكرة ومعرفة عبر آلاف المحادثات. هالدليل هو العمارة الحقيقية، مش لعبة. للنظرة الأعلى على الأنظمة الوكيلية، شوف دليل أنظمة الـ AI الوكيلية عنا، ولتعرف كيف الـ retrieval بيركب بالصورة، دليل أنظمة RAG للمؤسسات. هاد شغل من صلب خدمات الـ AI عنا.

مين بيهتم بشو

أربع أنواع من الذاكرة

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

غلطة الجونيور إنه يعامل الذاكرة كأنها كتلة "تاريخ شات" وحدة. الغلطة اللي السنيور بيتجنبها هي إنه يدفع لسياق النموذج مش محتاجه بهالدور.

تجميع السياق: الطبقات السبع

كل طلب بـ Exfinity بيمر بـ pipeline لتجميع السياق بيبني مصفوفة مرتبة من الرسايل بتنحقن قبل نص المستخدم. كل طبقة شرطية. هاد قلب النظام، فهي الـ pipeline كامل.

في قرارين تصميميين هون أهم من الجدول نفسه.

أولاً، مش كل الطبقات بتشتغل. الطبقة 4 بتشتغل بس لما يكون بالـ graph تبع الـ tenant عقد كفاية ليكون مفيد، والطبقة 5 بتفوت باللعبة بس لما يصير الـ thread طويل كفاية ليحتاج تلخيص. ما بتدفع لسياق إنت مش محتاجه.

ثانياً، وهاد قرار الأمان: الطبقات اللي بتحمل بيانات أنتجها مستخدمين تانيين ما بتنحقن أبداً كتعليمات نظام. قواعد المنصة ورسالة المستخدم نفسه هنن الصوتين الوحيدين اللي إلهن سلطة. رؤى الـ graph، التاريخ المضغوط، المنتجات المسترجعة والمستندات المسترجعة كلها بتتغلف كبيانات غير موثوقة وبتنحقن بدور الـ user، مع شيل محددات الـ fence من المحتوى حتى النص المحقون ما يقدر يكسر البلوك ويطلع. منرجع لليش بقسم الـ guardrails.

User message
   │
   ▼
[1] Platform rules      (system, always)
[2] Date context        (system, always)
[3] Tenant persona      (system, if configured)
[4] Graph insights      (untrusted-data, if graph is big enough)
[5] Compacted history   (untrusted-data, if thread is long)
[6] Product context     (system, if product-like query)
[7] Knowledge passages  (untrusted-data, if question-like query)
   │
   ▼
Assembled context ──▶ Agent ──▶ Model

الـ working memory: القالب اللي الوكيل بيكتب فيه

حمل الرسايل الحديثة للأبد غالي. الـ working memory بتحل هالشي بقالب منظّم الوكيل بيقراه وبيكتب فيه عبر الأدوار. بدل ما يعيد قراءة "معي 200 يورو لشخصين بالغين السبت الجاي" من التاريخ الخام كل دور، الوكيل بيستخرجها مرة وحدة لقالب وبيحمل القالب.

<user_context>
preferences:
budget:
travel_dates:
group_size:
interests:
viewed_products:
current_intent:
</user_context>

لما المستخدم يحكي ميزانية وتواريخ، الوكيل بيكتب هالقيم بالحقول. بالدور الجاي، القالب بينحمّل رجعة بالسياق، فالوكيل بيتذكر بدون ما تكون الرسايل الأصلية موجودة. هاد أرخص بكتير من حمل التاريخ الكامل، وبيعيش بعد الضغط. الوكلاء اللي مش محتاجين schema صارم بيحتفظوا ببلوك working memory حر بدالها.

قاعدة التصميم: حط الحقائق الدايمة والمنظّمة بالـ working memory، وخلي نافذة الرسايل الخام تتولى الأخد والرد الفوري. دليل تصميم الـ AI workflows عنا بيغطي كيف تقرر شو بيروح وين.

الاستدعاء الدلالي مقابل النافذة الحديثة

آليتين بيغطوا تاريخ المحادثة، مضبوطين لكل وكيل.

النافذة الحديثة هي آخر N رسالة، محمّلة حرفياً. رخيصة ودايماً ذات صلة بالتبادل الفوري.

الاستدعاء الدلالي بيعمل embedding للرسالة الحالية وبيفتش بتاريخ الـ thread الأقدم عن رسايل قديمة مشابهة دلالياً، وبيرجّع كم تطابق مع الرسايل اللي حواليهن. هيك الوكيل بيتذكر شي قاله المستخدم قبل عشرين دور لما يرجع يصير مهم، بدون ما يحمل العشرين دور كلهن.

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

// إعدادات الذاكرة لكل وكيل: نافذة حديثة + استدعاء دلالي
const bookingAgent = {
  memory: {
    lastMessages: 15,                       // نافذة حديثة حرفية
    semanticRecall: { topK: 3, messageRange: 2 }, // ماضي مشابه + الجيران
    workingMemory: { enabled: true },
  },
};

const recommendationAgent = {
  memory: {
    lastMessages: 15,
    semanticRecall: { topK: 5, messageRange: 3 }, // استدعاء أعمق
    workingMemory: { enabled: true },
  },
};

الـ knowledge graph: ذاكرة بتمتد عبر الجلسات

كل اللي فوق محصور بمحادثة وحدة. الـ knowledge graph هو ذاكرة بتعيش بعد الجلسة وبتمسك الأنماط عبر كل تفاعل عند الـ tenant. هي الطبقة اللي أغلب الفرق بتتخطاها، وهون السياق بيوقف يكون "شو قلت هلق" وبيصير "شو اللي بيميل يكون صحيح هون".

الـ graph لكل tenant، بعقد إلها أنواع وحواف إلها أنواع.

أنواع العقد بتشمل product وquery وresponse وuser وdocument وtool call وbooking وcompetitor price. أنواع الحواف بتشمل searched-for وanswered-by وbooked وviewed وcited وsimilar-to وasked-about وused-tool وpriced-against.

query ──searched_for──▶ product
query ──answered_by──▶ response ──cited──▶ document
user  ──booked──▶ product
user  ──viewed──▶ product
product ──similar_to──▶ product

مسار الكتابة. بعد كل رد من الوكيل، job من نوع fire-and-forget بيسجل التفاعل: عقدة query فيها رسالة المستخدم بعد تنظيفها من البيانات الشخصية، عقدة response فيها الجواب المنظّف، حافة answered-by موزونة بالـ feedback (اللايك بيقويها، الديسلايك بيضعفها)، وعقدة product مع حافة searched-for لكل منتج انذكر. بيشتغل بشكل غير متزامن فما بيضيف أبداً latency عالرد.

مسار القراءة. أثناء تجميع السياق (الطبقة 4)، الـ graph بيطلع رؤى بس لما يكون عنده عقد كفاية ليكون إلها معنى. استعلامين بيشتغلوا بالتوازي: المنتجات الأكتر بحثاً، والأسئلة الحديثة اللي ما إلها جواب منيح. هدول بيصيروا بلوك مضغوط من بيانات غير موثوقة بيقول للوكيل شو فعلاً بيهم مستخدمين هالـ tenant.

// مسار القراءة: بس اعرض الرؤى لما يكون الـ graph كبير كفاية
async function buildGraphInsights(tenantId) {
  const stats = await graph.getStats(tenantId);
  if (stats.totalNodes < GRAPH_MIN_NODES_FOR_INSIGHTS) return null;

  const [popular, unanswered] = await Promise.all([
    graph.getPopularProducts(tenantId, 5),      // الأكتر بحثاً
    graph.getUnansweredQuestions(tenantId, 3),  // الفجوات اللي بدها تتسكر
  ]);
  return fenceUntrusted(formatInsights(popular, unanswered));
}

منع النمو للأبد. في job صيانة تنين مهمين. تلاشي الحواف بيطبق تلاشي أسي حسب العمر على أوزان الحواف، فالتفاعلات القديمة بتبهت صلتها، وبيعيد الحساب من الوزن الأولي بكل تشغيلة فهو idempotent مش تراكمي. تنظيف العقد بيحذف العقد المؤقتة اللي عدّت حد معين وبيتسلسل للحواف اليتيمة، بينما العقد الدايمة متل المنتجات بتضل.

weight = initial_weight * exp(-ln(2) / halfLifeDays * ageDays)   # floored at 0.1

المحو. لطلب حذف حسب GDPR، الـ graph بيحدد عقد الـ query تبع المستخدم حسب الـ thread، بيتبع حواف answered-by لعقد الـ response تبعها، وبيحذف هالعقد مع كل حافة بتلمسها. عقد الـ product المشتركة ما بتنمحي أبداً. الحذف الموجّه عبر مخازن الذاكرة شرط صعب، مش رفاهية، ومنغطي جانب الامتثال بـ دليل GDPR والـ AI عنا.

الثقة والـ auto-learn: ذاكرة بتتحسن

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

الثقة مركّبة من أربع عوامل، بأوزان.

const composite =
  retrieval * 0.4 + policy * 0.2 + completeness * 0.2 + memory * 0.2;

لما رد ينزل تحت عتبة محددة لكل tenant، بينمسك كمرشّح تعلم وبيتصنف بصنف فشل: retrieval فاشل، حظر policy، إشارة هلوسة متل تاريخ ماضي معروض كأنه مستقبلي، feedback سلبي، وهيك. إنسان بيراجع المرشّح بـ dashboard. عند الموافقة، الجواب بينسق كمستند معرفة، بينعمله embedding، وبينشر رجعة بقاعدة المعرفة، حتى نفس السؤال يرجّع جواب منيح المرة الجاية. حتى العتبة بتتضبط لحالها: إذا المراجعين عم يوافقوا عالكل تقريباً، بتنزل لتمسك أكتر؛ وإذا عم يرفضوا كتير، بتطلع لتقص الضجيج.

هاد نمط الـ human-in-the-loop مطبق على طبقة الذاكرة نفسها، وهو اللي بيفرق بين نظام عم يتدهور ونظام عم يتراكم لصالحه. دليل مراقبة الـ AI عنا بيغطي المقاييس اللي بتراقبها لتعرف أي واحد عم يصير.

الـ guardrails: حقن الـ prompt والبيانات غير الموثوقة

هي نمط الفشل اللي بتجيبه الذاكرة: نص خزّنه مستخدم، أو نجا من الضغط، ممكن يحاول يخطف جلسة مستخدم تاني. لو المحتوى المسترجع أو رؤى الـ graph انحقنوا كتعليمات نظام، مستند خبيث فيه يقول "تجاهل قواعدك" وينطاع.

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

هالشي بيصير أهم كل ما كبرت الذاكرة، لأن مساحة "نص سببه ناس تانيين" بتكبر معها. دليل حوكمة الـ AI ودليل أنماط فشل الـ AI عنا بيغوصوا أعمق بالدفاع عن الأنظمة الوكيلية.

الكلفة: الذاكرة مش ببلاش

كل طبقة بتضيفها هي tokens، والـ tokens هي latency ومصاري. تلات ضوابط بتخلي الشغلة محدودة.

الضغط بيلخص الرسايل الأقدم لما يطول الـ thread، بيستبدل التاريخ الخام بملخص منظّم مضغوط وبيخلي ميزانية الـ tokens ثابتة مع نمو المحادثات. الـ prompt caching بيقدم البادئة الثابتة تبع النظام من كاش المزود بالاستدعاءات المكررة، فما عم تعيد تدفع لنفس القواعد كل دور. وسقوف صارمة لكل دور على خطوات التفكير واستدعاءات الأدوات وtokens الخرج بتمنع دور واحد إنه يهرب فيك.

منغطي موازنات الكلفة والـ latency عبر الـ stack كلها بـ دليل الـ latency والدقة بالـ AI عنا.

من وين تبلش

إضافة ذاكرة لوكيل، بترتيب العائد:

1. النافذة الحديثة أول شي. احمل آخر N رسالة. هاد لحاله بيخلي الوكيل يبين متماسك.
2. الـ working memory بعدها. ضيف قالب منظّم للحقائق الدايمة. رخيص وأثره كبير.
3. الاستدعاء الدلالي لما تطول الـ threads. رجّع الرسايل القديمة المهمة بدل ما تحملها كلها.
4. الضغط لما تعض الكلفة. لخص التاريخ القديم لما تصير الـ threads طويلة.
5. knowledge graph لما يصير عندك حجم. ما بيسوى إلا لما يكون عندك تفاعلات كفاية لتطلع أنماط.

لا تبني الـ graph أول شي. بيستاهل مكانه بس مع الحجم. منهجيتنا مبنية حول هالنوع من التسليم على مراحل، وفرق البرمجيات المخصصة والاستشارات عنا بيبنوا هالطبقات مع العملاء. ابلش من تواصل معنا أو خود عرض سعر.

الطرق الشائعة اللي بتخرب فيها الشغلة

1. رمي كل التاريخ بكل دور. الكلفة والـ latency بينفجروا، والصلة بتنزل. جمّع، لا ترمي.
2. إعدادات ذاكرة عامة. وكلاء مختلفين بدهن نوافذ واستدعاءات مختلفة. اضبط لكل دور.
3. حقن النص المسترجع كتعليمات نظام. هاد ثغرة حقن prompt. سيّجه كبيانات غير موثوقة.
4. graph بلا تلاشي ولا تنظيف. بيكبر بلا حدود والضجيج القديم بيغرق الإشارة. ضيف jobs صيانة.
5. ما في مسار محو. إذا ما فيك تحذف ذاكرة مستخدم، ما فيك تلبي طلب GDPR. صمم الحذف من البداية.
6. تراكم بلا تحسن. ضيف درجة ثقة وحلقة مراجعة، وإلا النظام بس بيكبر، مش بيتحسن.

مين بيبني هالشي

Oronts شركة برمجيات بقيادة مؤسسها، مقرها ميونخ. Refaat Al Ktifan، مؤسسنا ومهندس الحلول عنا، بيقود فريق senior بالـ backend والبيانات والـ AI. العمارة اللي بهالدليل هي طبقة الذاكرة الحقيقية ورا Exfinity، اللي منشغلها على حالنا قبل ما نجيب هالأنماط للعملاء. منصمم pipeline السياق، منبني طبقات الذاكرة والـ graph، ومنسلمك نظام فيك تشغله وتراجعه. شوف صفحات الخدمات والحلول عنا للصورة الكاملة.

الخلاصة

• النموذج ما عنده ذاكرة. كل شي تجميع بيصير قبل الـ prompt.
• استعمل الأربع آليات: النافذة الحديثة، الاستدعاء الدلالي، الـ working memory، والـ knowledge graph.
• جمّع السياق بطبقات شرطية، ولا تحقن أبداً بيانات مستخدمين تانيين كتعليمات نظام.
• الـ knowledge graph بيعطي ذاكرة بتمتد عبر الجلسات، بس بده تلاشي وتنظيف ومسار محو.
• ضيف درجة ثقة وحلقة مراجعة بشرية حتى الذاكرة تتحسن بدل ما بس تتراكم.

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

عم تبني وكيل لازم يتذكر، بأمان وبكلفة معقولة؟ خبرنا عنه عبر تواصل معنا أو خود عرض سعر محدد النطاق.