ذاكرة ثابتة خماسية الطبقات لوكيل الذكاء الاصطناعي: لماذا لا تكفي قاعدة متجهية واحدة أبدًا

• حجم الفهرس الحَدَثي: 66,995 جلسة و538,956 رسالة في قاعدة SQLite FTS5 بحجم 1,353 ميجابايت
• قاعدة «العقل الثاني» والمتجهات: 10,019 بطاقة معرفية منظمة وقاعدة `brain.db` بحجم 2.37 جيجابايت
• سرعة بدء التشغيل بعد التخلي عن الخطافات الثقيلة: انخفاض زمن انتظار التهيئة من 5–15 ثانية إلى أقل من 0.2 ثانية
• عتبات التوحيد الليلي: دمج التكرارات عند تشابه جيب التمام >= 0.70، وكاشف تناقضات بعتبة 0.40 دون استدعاء نموذج لغوي كبير

كانت نقطة الانطلاق لبنية ذاكرتي عطلًا مفاجئًا في محرر الكود. فعند محاولة فتح سجل المحادثات مع وكيل الذكاء الاصطناعي، تجاوزت عملية Extension Host حدّ الذاكرة المسموح وانهارت مع الطرفية (Terminal). وعلى مدى ستة أشهر من الاستخدام، تراكم 2.45 جيجابايت من سجلات JSONL الخام للجلسات، وكانت الإضافة تحاول قراءة عناوينها من القرص عند كل بدء تشغيل. والأسوأ أن الإعداد الافتراضي `cleanupPeriodDays=30` كان يحذف الجلسات الأقدم من شهر دون أي تنبيه — وإلى أن استبدلته بقيمة `99999`، كان جزء من أرشيف الشتاء قد اختفى فعلًا.

أظهرت المراجعة أن قاعدتين من قواعد الذاكرة الأربع كانتا معطّلتين، لأنهما تطلبتا تشغيل عمليات خدمة (daemons) يدويًا. لكن الاكتشاف الأهم كان أن «ذاكرة الوكيل» ليست شيئًا واحدًا، بل خمس فئات مختلفة من الأسئلة، تحتاج كل منها إلى محرّك خاص بها.

لماذا تفوّق SQLite FTS5 على

Qdrant وعلى أمر grep في نصف مليون رسالة؟

بالنسبة للذاكرة الحَدَثية («أين ناقشنا إعداد الـ webhooks منذ ثلاثة أشهر؟»)، كان أمر `grep` عبر غيغابايتات من النص بطيئًا جدًا، في حين أن تشغيل نسخة محلية من `Qdrant` مع `fastembed` عند بدء الجلسة كان يؤخر الإقلاع بمقدار 5–15 ثانية ويستهلك مئات الميغابايتات من الذاكرة العشوائية (RAM).

والفائز هو محرك SQLite FTS5 المدمج في Python، مع ترتيب BM25 ونمط `WAL`. تقوم أداة الفهرسة `search_chats.py` بمقارنة `file_mtime` مع جدول `sessions`: فإذا كان الفرق أقل من ثانية واحدة، يُتجاوَز الملف.

أما السجلات الخام الأقدم من 14 يومًا والملفات التي يتجاوز حجمها 20 ميغابايت، فتُنقل إلى أرشيف بارد — فانخفض حجم دليل العمل من 2.45 جيجابايت إلى 527 ميغابايت، وتوقفت الأعطال، وتضخّم الفهرس إلى 66,995 جلسة و538,956 رسالة (290,544 من الإنسان و248,412 من المساعد) بحجم إجمالي 1,353 ميغابايت. وبالنسبة للمراجع الحرجة (مثل دليل من 20 فصلًا جُمع من 2,240 رسالة و177 ملاحظة صوتية مُفرّغة عبر Deepgram)، يُعتمد نظام احتياطي من 4 مستويات: ملخص في الذاكرة العاملة، فهرس في `MEMORY.

md` (محدود بصرامة بـ200 سطر وحوالي 22 كيلوبايت)، قاعدة توجيه، وبصمة متجهية.

لماذا نحتاج معرّف UUID5 حتميًا في قاعدة البيانات المتجهية، وكيف تعمل

ثنائية الزمن؟

عندما لا تتضمن الاستعلامية الكلمات الدقيقة الموجودة في القاعدة (فيسأل أحدهم «كيف أغسل الفواكه دون مواد كيميائية» بينما تحتوي القاعدة على ملاحظة عن النمط القلوي لمُؤيّن ماء بـ`pH 11.5`)، تتدخل الطبقة الدلالية القائمة على المتجهات (ببُعد 384 محليًا و1536 للكتب). وفي الواقع، تبدو معرّفات الوثائق كسلاسل نصية مثل `knowledge:42` أو `session/2026-04-10/msg-17` وقد تحتوي أحيانًا على حروف سيريلية، لكن محرك Qdrant المتجهي يتطلب أن يكون `point_id` إما عددًا صحيحًا أو UUID صارمًا. ومعرّف `uuid4()` العشوائي يولّد تكرارات عند كل إعادة فهرسة، لذلك اعتمدنا معرّف `uuid5` حتميًا مبنيًا على فضاء أسماء DNS:

```python import uuid

def to_deterministic_point_id(raw_doc_id: str) -> str: # يحوّل أي سلسلة تحتوي على حروف سيريلية أو رموز خاصة إلى UUID5 ثابت بترميز ASCII return str(uuid.uuid5(uuid.NAMESPACE_DNS, raw_doc_id))

point_id = to_deterministic_point_id(doc_id) payload = {**metadata, "doc_id": doc_id, "content": text_chunk} ```

السلسلة النصية نفسها تُعطي دائمًا UUID مطابقًا، فتتحول عملية إعادة الكتابة إلى عملية `upsert` متكرّرة الأثر (idempotent)، مع الاحتفاظ بالمفتاح الأصلي داخل `payload`.

ولكي يتذكّر الوكيل تاريخ تغيّر القرارات («لماذا اختارنا محركًا آخر في الربيع؟»)، استعرنا فكرة من Datomic ومنعنا تمامًا أي عملية `UPDATE` تمحو الماضي. فكل رابط يتضمن حقول `valid_from` و`valid_to` و`ingested_at`، وتضيف قاعدة العقل الثاني أيضًا عدّادات استخدام `use_count` و`last_used`. وعندما يصبح قرار ما قديمًا، يُسجَّل حقل `valid_to` على الرابط القديم، ويُدرَج سجل جديد بجانبه مرتبط به عبر حقل `supersedes`.

كيف ينظّف «النوم الخوارزمي» القائم على منحنى ويبول الذاكرة من التناقضات؟

لمنع القاعدة من التحول إلى مكب للبيانات، يقوم خط أنابيب توحيد يعمل في الخلفية (`dream` ووحدات `sleeptime`) بتنظيف دوري على ثلاث مراحل:

1. تجميع التكرارات (SHMR): مصفوفة تشابه جيب التمام على متجهات ببُعد 1024 (نموذج `Qwen3-Embedding-0.6B` داخل LanceDB) تدمج السجلات التي يبلغ تشابهها `>= 0.70`. 2. تلاشٍ انتقائي وفق توزيع ويبول: الملاحظات العابرة (`observation`) تتلاشى خلال 336 ساعة (حوالي أسبوعين)، والوقائع التشغيلية خلال 2,160 ساعة، في حين أن التفضيلات الشخصية (`preference`) والإجراءات وأنماط الأخطاء (`error_pattern`) محمية بقائمة `EXEMPT_TYPES`. 3. كشف التناقضات دون نموذج لغوي كبير: يبحث فاحص حتمي عن التناقضات خلال نافذة 7 أيام، اعتمادًا على إشارات موزونة (`negation: 0.35`، `antonym: 0.25`، `numeric: 0.25`، `temporal: 0.15`)، بعتبة قدرها 0.40.

هذا المخطط الخماسي الطبقات للذاكرة (SQLite FTS5، وLanceDB، والرسم البياني الزمني) مدمج في نواة [Nomad AI](https://nomadnet.ai) ومنصة السحابة [agent.nomadnet.ai](https://agent.nomadnet.ai). وتتوفر دورة تدريبية في هندسة الذاكرة على [Hamidun Academy](https://academy.hamidun.com) (نسخة تجريبية لمدة 72 ساعة)، بينما تتوفر سكريبتات الفهرسة في مكتبة [Vibe Club](https://hamidun.com/club).