بناء مستودع محلي لذاكرة الذكاء الاصطناعي

عمار نجار · نُشر في 21 أكتوبر 2026 · 9 دقائق قراءةaiproductivity

صورة منشأة بالذكاء الاصطناعي

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

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

لماذا اخترت مستودعاً محلياً؟

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

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

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

الفصل بين Obsidian ومستودع الذاكرة

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

جاءت الإجابة من اختلاف الغرض الذي أستخدم من أجله كل نظام.

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

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

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

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

تنظيم المعلومات المستقرة والمتغيرة

قسّمت المستودع إلى مجلدين رئيسيين لأنني أردت التمييز بين المعلومات التي أتوقع بقاءها مستقرة نسبياً، والملاحظات التي قد تتطور مع استمرار العمل.

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

أما memory/، فأخصصه للمعلومات التي تنشأ وتتطور أثناء العمل، مثل الملاحظات والأنماط المتكررة والأسئلة المفتوحة والسجلات التي حلت محلها معلومات أحدث.

تبدو بنية المستودع المبسطة على النحو التالي:

my-ai-memory/
├── AGENTS.md
├── context/
│   ├── profile.md
│   └── principles.md
└── memory/
    ├── inbox.md
    ├── patterns.md
    └── superseded.md

توضح بنية المجلدات الطريقة التي أتوقع استخدام المعلومات وصيانتها بها. أما مدى الثقة الذي ينبغي أن يمنحه الوكيل لمعلومة معينة، فيعتمد على حالة السجل نفسه. فوجود معلومة داخل context/ لا يعني بالضرورة أنها مؤكدة، كما أن حداثة ملاحظة داخل memory/ لا تجعلها غير موثوقة تلقائياً. وتوجد التعليمات التي تحدد كيفية تعامل الوكلاء مع هذه السجلات بصورة منفصلة في ملف AGENTS.md.

على سبيل المثال، قد يحتوي ملف للسياق المستقر على معلومات عن بيئة عملي وبعض التفضيلات المرتبطة بها:

# Working environment

- Prefer local tools that run on my hardware.
- Use version control for all tracked changes.
- Document configuration decisions alongside their reasoning.

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

أما الجزء المتغير من الذاكرة، فيؤدي وظيفة مختلفة. فقد يحتفظ ملف الوارد بملاحظة قبل أن أحدد مدى موثوقيتها أو كيفية تصنيفها:

# Inbox

## Pattern: Debug logs expose infrastructure state

- **Confidence:** Low (single observation)
- **Source:** 2026-08-12 deployment discussion
- **Status:** Needs review

Observation: Container debug logs included internal IP addresses and service topology, revealing infrastructure details that should not appear in standard output.

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

وأحتفظ أيضاً بالمعلومات التي استُبدلت بمعلومات أحدث، مع سياق كافٍ لفهم المراجع القديمة ومعرفة البيانات المعتمدة حالياً. أما الأنماط المتكررة، فأوثّق الملاحظات التي تستند إليها، إلى جانب ما قد يبقى من شكوك حول الاستنتاجات المرتبطة بها.

سير العمل المتوقع: من المحادثة إلى المستودع

حددت في ملف AGENTS.md سير العمل التالي. وهو يوضح السلوك الذي كنت أتوقعه من الوكلاء عندما تنتج عن محادثة معلومات تستحق الاحتفاظ بها.

انتهاء المحادثة
    │
    ▼
يراجع الوكيل المحادثة بحثاً عن معلومات مفيدة
    │
    ▼
القرار: هل تستحق الملاحظة الحفظ؟
    │
    ├── لا  → لا يُسجَّل شيء
    └── نعم → الحفظ في memory/inbox.md
                    │
                    ▼
             تسجيل مستوى الثقة والمصدر والحالة
                    │
                    ▼
             (اختياري) اقتراح تحديث في context/
             للمراجعة قبل اعتماده

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

التعامل مع المعلومات المتعارضة

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

لهذا السبب، تضمنت تعليماتي الأولى ترتيباً للأولويات عند التعامل مع التعارضات. تأتي التعليمات الصريحة أولاً، ثم الأدلة الحديثة، ثم الحالة الحالية الموثقة، وأخيراً الملاحظات الأقدم.

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

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

ربط وكلاء الذكاء الاصطناعي بمستودع الذاكرة

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

في بيئة الذكاء الاصطناعي المحلية لدي، كان بإمكان وكلاء البرمجة الوصول مباشرةً إلى مستودع الذاكرة من خلال عمليات نظام الملفات المعتادة. واستخدم Claude Code الطريقة نفسها للوصول إلى ملفات المستودع.

أما ChatGPT، فكان الوضع مختلفاً. ولأنني لم أفترض وجود وصول مباشر منه إلى المستودع المحلي، واصلت تزويده بالمعلومات المطلوبة يدوياً، من خلال اختيار المحتوى المناسب من ملفات Markdown ونسخه إلى المحادثة بحسب الحاجة.

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

تعليمات الذاكرة من خلال AGENTS.md

أحتفظ بالتعليمات المشتركة في ملف AGENTS.md الموجود في المجلد الرئيسي للمستودع.

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

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

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

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

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

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

حدود الاعتماد على التعليمات وحدها

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

لكن الحفاظ على تحديث الذاكرة واسترجاع المعلومات المناسبة بصورة موثوقة ظل تحدياً.

ظهرت ثلاث مشكلات رئيسية:

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

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

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

ساعد تحسين التعليمات في بعض الحالات، لكن العملية الأساسية ظلت تعتمد على التزام الوكيل بتنفيذها أثناء أداء المهمة. ولم تكن هناك آلية مستقلة للتأكد من مراجعة المحادثة بحثاً عن معلومات مفيدة، أو اكتشاف تحديث لم يُنفَّذ، أو استكمال معالجة معلومات فات تسجيلها.

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

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

ما الذي أعمل على تحسينه؟

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

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

إذا كنتم تحتفظون بذاكرة خاصة لأدوات الذكاء الاصطناعي التي تستخدمونها، فكيف تقررون المعلومات التي تستحق الحفظ؟ وما مقدار المسؤولية التي تتركونها للوكيل في تحديث تلك المعلومات والمحافظة عليها؟