البحث المتجهي في مواجهة مخطط المعرفة: كم يكلف بناء GraphRAG والحفاظ عليه حقًا؟

• المجموعة النصية الأصلية وحجم المخطط: 10,019 بطاقة معرفية، تحولت إلى 5,237 عقدة و19,803 رابط (ملف SQLite بحجم 15 ميغابايت)
• التوفير في مرحلة البناء: خفض تكلفة الاستخراج من 1,500 دولار المقدّرة (عند 117K رمز كبادئة في كل استدعاء) إلى بضعة دولارات
• ضغط الكيانات عبر قاموس التوحيد القياسي: انهارت 1,213 صيغة كتابة للمشاريع إلى 81 مشروعًا قياسيًا (بمعدل 15 مرة)
• سرعة الدائرة الهجينة: 13 ملّي ثانية لإخراج مرتّب عبر FTS5 على 538,956 رسالة، و87 ملّي ثانية لعملية JOIN على مخطط من خطوتين

بعد سنة من تشغيل نظام الذاكرة الخاص بي، صغتُ الفرق بين النهجين في جملة واحدة: البحث المتجهي يجيب عن سؤال «جد لي اقتباسًا عن X»، أما المخطط فيجيب عن سؤال «اشرح لي كيف يُبنى X ومن يرتبط به». وعندما تسأل «ما الأدوات التي استخدمناها في المشروع على مدى سنة ونصف ومن شارك فيه»، لا توجد الإجابة الصحيحة كاملةً في أي قطعة نصية واحدة — فالبحث المتجهي يُعيد ثلاثة مقتطفات عشوائية، أما الـ 80% المتبقية من الصورة فيؤلّفها النموذج بثقة من دون أساس.

الدراسة التي كثيرًا ما يُستشهد بها من Microsoft Research (`arXiv:2404.16130`)، والتي تَعِد بتفوّق GraphRAG في 72 إلى 83% من المقارنات الثنائية من حيث شمولية الإجابة، صحيحة لكنها مشروطة بحدود صارمة. فقد أُجري القياس على مهمة تلخيص شامل للمجموعة النصية (`query-focused summarization` على 1.0 إلى 1.7 مليون رمز)، وقد ضمّن المؤلفون في نطاق 72-83% حتى تهيئة `TS` التي لا تستخدم المخطط أصلًا، بل تطبّق `map-reduce` على النصوص الأصلية مباشرة.

كيف تتجنب إنفاق 1,500 دولار على موجّه النظام عند استخراج الكيانات من

10,019 سجلًا؟

عندما شرعت في بناء مخطط فوق 10,019 بطاقة معرفية (5,658 ملاحظة تعليمية، و2,657 مقتطف كود، و1,209 مناقشة، و155 تحليل أخطاء)، كان أول تنفيذ بسيط قريبًا من أن يُفلس المشروع. بدا طبيعيًا تقسيم المجموعة إلى دفعات من 200 سجل وتشغيل وكيل سطر أوامر كعملية فرعية لكل دفعة. كلّف أول استدعاء تجريبي 15 سنتًا: فعميل CLI كان يعيد تحميل موجّه النظام والقواعد ووصف المهارات في كل بدء تشغيل — أي 117,000 رمز من البادئة التشغيلية. على 49 دفعة، كان ذلك يعني أكثر من 7 دولارات مهدورة من دون فائدة، ولو عولجت السجلات الـ 10,019 واحدًا تلو الآخر، لتجاوزت الفاتورة 1,500 دولار.

أعدنا بناء خط المعالجة: قمنا أولًا باستبعاد 287 سجلًا غير مفيد، ثم شغّلنا موجات من 5 إلى 7 وكلاء فرعيين بالتوازي داخل جلسة أم واحدة حيّة تكون البادئة فيها محفوظة مسبقًا في الذاكرة المؤقتة. أما محاولة تشغيل 20 عاملًا دفعة واحدة، فقد تعثّرت بتقييد من الخادم بعد إنجاز 411 مهمة من أصل 672، فثبّتنا النقطة المثلى: معرّفات دفعات ثابتة في بيان واحد وموجات تصل إلى 6-8 وكلاء بالتوازي.

لماذا تشغيل المخطط أكثر تكلفة من بنائه، وكيف يضغط قاموس التوحيد

القياسي المشاريع بمعدل 15؟

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

```python def canon(entity_kind: str, raw_name: str) -> str: # يحوّل اسم الكيان الخام إلى صيغته القياسية أو يحذفه كضجيج (نص فارغ) cleaned = (str(raw_name) if raw_name is not None else "").strip() return _MAPS.get(entity_kind, {}).get(cleaned, cleaned) ```

بعد تشغيل خرائط التوحيد، انهارت 1,213 صيغة خام لكتابة المشاريع إلى 81 مشروعًا حقيقيًا (بمعدل 15 مرة!)، وتقلّصت 2,542 صيغة للأدوات إلى 1,068، وانخفضت الشركات من 1,427 إلى 1,115، والأشخاص من 783 إلى 590. كما تم تحويل 66 أداة زائفة إضافية و11 «شركة» تجريدية («قابضة»، «مكتبة») إلى نص فارغ. وفي المسار نفسه، أصلحنا عثرتين كلاسيكيتين: حلقة `for t in stack` كانت تتكرر على حقل نصي بدل قائمة، فأنتجت 96,000 رابط زائف نحو حروف منفردة من الأبجدية (وقد عُولجت بفحص `isinstance(v, list)`)، وانفجارًا في الربط التلقائي عبر تطابق جزئي في العناوين أدى إلى 27,000 علاقة زائفة (عُولج بتصفية بحد أدنى 5 أحرف وشرط ألا يظهر المفتاح في أكثر من 4 مشاريع، وهو ما أعطى 543 رابطًا دقيقًا من نوع `about`).

متى تكفي جدولتان في SQLite بدلًا من خادم مخطط مخصص؟

عاشت النسخة الأولى من مخططنا على خادم داخل قاعدة بيانات FalkorDB (المبنية فوق Redis وGraphBLAS). وهناك تبيّن أن لهجة Cypher لا تدعم التعبيرات النمطية `=~` ولا `shortestPath()` غير الموجّهة، وبسبب تعطّل موصل MCP وضرورة إقامة نفق SSH، ظلّ المخطط المكوّن من 4,743 عقدة منقطعًا تمامًا عن الوكلاء لمدة 7 أسابيع.

نقلنا المخطط كاملًا إلى ملف SQLite محلي بحجم 15 ميغابايت يتكون من جدولين (`nodes` و `edges`). وعلى نطاق 5,237 عقدة و19,803 رابط، يعثر استعلام SQL عادي بعمليتي `JOIN` على أفضل المشاريع من حيث عدد الأدوات والجلسات (المشروع الأول يضم 277 جلسة و285 أداة) في 87 ملّي ثانية، بينما يستجيب البحث النصي الكامل FTS5 على نصف مليون رسالة في 13 ملّي ثانية.

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