Graphify يحوّل مجلداً إلى رسم معرفي، ورقم 71.5x يحتاج سياقاً

جمع Graphify نحو 7,300 نجمة هذا الأسبوع، وهو ما يضعه في مقدمة قائمة GitHub الأسبوعية ويرفع إجماليه إلى ما يتجاوز 137,000. الفكرة تُقال في سطر واحد: وجّه وكيلك البرمجي إلى مجلد، واكتب /graphify .، فتحصل على رسم معرفي لكل ما يحتويه.

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

من أين جاء

يقدّم المؤلف safishamsi المشروع كردّ على عادة محددة عند Andrej Karpathy: مجلد /raw تُلقى فيه الأوراق والتغريدات ولقطات الشاشة والملاحظات، ثم لا يعثر المرء على شيء فيه لاحقاً. المشكلة مألوفة، وقصة الأصل أصدق من معظم نظيراتها، لأنها تصف نمط فشل لا سوقاً.

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

ما الذي يفعله فعلاً

التثبيت أمران اثنان، ونعم، اسم حزمة PyPI خاطئ مؤقتاً:

pip install graphifyy && graphify install

حرف Y المكرر ناتج عن نزاع على الاسم، لا عن خطأ مطبعي. ما زال كلٌّ من CLI وأمر skill باسم graphify. على Windows، إذا لم يُعرَف الأمر بعد التثبيت، فلا بد من إضافة مجلد Scripts الخاص بـ Python إلى PATH، أو استخدام pipx install graphifyy لتجاوز المشكلة أصلاً.

ثم، داخل Claude Code، وفي أي مجلد:

/graphify .
/graphify ./raw --mode deep
/graphify query "what connects attention to the optimizer?"
/graphify path "DigestAuth" "Response"
/graphify explain "SwinTransformer"

يستقر الناتج في graphify-out/. هناك graph.html تفاعلي يمكن النقر فيه، ومجلد obsidian/ يُفتح كـ vault، وملف graph.json دائم يتيح الاستعلام بعد أسابيع دون إعادة قراءة أي شيء، ومجلد cache/ مفتاحه SHA256 حتى لا تعالج عمليات التشغيل المتكررة سوى الملفات المتغيرة، وملف GRAPH_REPORT.md يسرد ما يسمّيه god nodes، أي المفاهيم الأعلى درجة، إضافة إلى «صِلات مفاجئة» مرتبة بحسب درجة مركّبة تكون فيها الحواف من الشيفرة إلى الورقة أثقل من الحواف من شيفرة إلى شيفرة.

الجزء متعدد الوسائط ليس تسويقاً. تمر ملفات الشيفرة عبر tree-sitter لتحليل AST ثم تمريرة على رسم النداءات. وتمر ملفات Markdown وملفات PDF والصور عبر Claude: مفاهيم وعلاقات من النثر، واستخراج اقتباسات من الأوراق، ورؤية حاسوبية للقطات الشاشة والمخططات وصور السبورة البيضاء والصور المكتوبة بلغات أخرى.

هناك أيضاً صيغ تصدير تهم كل من لا يريد العيش داخل هذه الأداة: --svg، و--graphml لـ Gephi أو yEd، و--neo4j الذي يولّد ملف cypher.txt بدل أن يفرض وجود قاعدة بيانات تعمل. الحزمة التقنية هي NetworkX، وتجميع Leiden عبر graspologic، وtree-sitter، وvis.js. لا خادم. ولا شيء يغادر الجهاز سوى نداءات Claude.

رقم 71.5x تحت المجهر

مجموعة القياس 52 ملفاً: مستودعات Karpathy، وخمس أوراق، وأربع صور. والنتيجة: رموز أقل بمقدار 71.5x في كل استعلام مقارنة بقراءة الملفات الخام.

المستودع صريح على نحو غير معتاد حول كيفية تغيّر هذا مع الحجم، وهذه الصراحة نادرة بما يستحق نقل جوهرها: الانخفاض في الرموز ينمو مع حجم المجموعة، وعند ستة ملفات تكون قيمة الرسم في الوضوح البنيوي لا في الضغط، لأن ستة ملفات تتسع في نافذة سياق على أي حال. مثالهم الخاص على شيفرة graphify مع ورقة Transformer يعطي 5.4x. وعلى ستة ملفات مكتبة اصطناعية، نحو 1x.

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

المقارنة ترفع Graphify قليلاً في اتجاه، وتنتقصه في اتجاه آخر. قراءة الملفات الخام هي أسوأ خط أساس ممكن؛ وفهرس استرجاع جيد الضبط سيبدو أفضل أمام الملفات الخام. لكن فهرس الاسترجاع يعيد مقاطع، وما يعيده Graphify علاقات: الجواب عن «ما الذي يصل الانتباه بالمحسِّن» ليس مقطعاً، بل مساراً. هذان استعلامان مختلفان، ولا يخدم مخزن الأشعة أحدهما إلا واحدا.

«بلا مخزن أشعة» موقف معماري حقيقي

معظم أنظمة الاسترجاع تقطّع النص، وتحوّله إلى تضمينات، ثم تجري بحثاً بأقرب الجيران. يتجاوز Graphify كل ذلك: تحليل AST محلي وحتمي للشيفرة، واستخراج بـ LLM للنثر والصور، ثم رسم. لا خطوة تضمين ولا بحث تشابه.

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

الثمن هو التغطية. الرسم لا يعرف إلا ما وجده المستخرِج. وإذا فوّتت تمريرة الاستخراج علاقة ما، فلن يُظهرها أي استعلام، ولا يوجد بديل تقريبي. وسم AMBIGUOUS هو الاعتراف الصادق بذلك، وخيار --mode deep موجود لأن التمريرة الافتراضية متحفظة في استنباط الحواف.

أين يستحق مكانه

سيرتا عمل، بحسب خبرتي في أدوات من هذا النوع.

الأولى هي الانضمام إلى قاعدة شيفرة غير مألوفة. ليس «أين تقع الدالة X»، فـ grep يكفي لذلك، بل «ما المفاهيم الحاملة هنا، وأيها يلامس شيفرة الفوترة». هذا سؤال رسم، وتقرير god nodes يجيب عنه في صيغة تُقرأ في دقيقتين.

الثانية هي حالة الوكلاء المتعددين. عندما يكتب عدة وكلاء شيفرة بالتوازي، تصبح صورة كل واحد منهم للمستودع قديمة في غضون دقائق. والرسم الذي يُعاد بناؤه عند كل commit (أمر graphify hook install يثبّت hook بعد الـ commit) أو عند حفظ الملف (--watch) يمنح كل الوكلاء الخريطة الحالية نفسها بدل خمسة تخمينات متباعدة.

الحد الواضح: هذا مبني أولاً كـ skill لـ Claude Code. ومسار التثبيت اليدوي يضع ملف SKILL.md في ~/.claude/skills/graphify/ ويضيف سطراً إلى CLAUDE.md. وهناك وضع خادم MCP (--mcp) يمكن لعملاء آخرين استخدامه، لكن سهولة الاستخدام محسّنة بوضوح لمنظومة واحدة، والاعتماد على Claude يعني أن تمريرة الاستخراج تكلّف مالاً حقيقياً على مجموعة كبيرة.

الحكم الصادق

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

تخميني أن معظم الناس سيستخدمون query، ويتجاهلون وسوم الحواف، ولن يفتحوا graph.json أبداً. أما من سيبقى فسيكون من كان يحتاج الخريطة، لا مفتاح الإجابات.