IWE وOpenAI: كيف تحوّل ملاحظات markdown إلى رسم بياني للمعرفة لوكلاء الذكاء الاصطناعي

أظهر مثال مبني على IWE كيف يمكن تحويل مجموعة من ملاحظات markdown إلى رسم بياني معرفي متكامل يخدم البشر ووكلاء AI على حد سواء. وبنى المؤلفون فوقه agentic RAG، وربطوه بـ OpenAI function calling، وعلّموا النموذج أن يبحث عن الإجابات عبر الروابط بين الوثائق، لا عبر ملفات مسطحة.

رسم بياني بدل المجلد

يقوم المثال على IWE، وهي أداة محلية مكتوبة بلغة Rust للعمل مع الملاحظات عبر CLI وLSP. فكرتها بسيطة: كل صفحة markdown تصبح عقدة في الرسم البياني، وتصبح wiki-روابط وروابط markdown العادية حوافَّ موجَّهة بين العقد. بفضل ذلك لا تُقرأ الملاحظات فحسب، بل يمكن التنقل عبرها بوصفها بنية مترابطة، يملك فيها كل مستند سياقه وجيرانه وموقعه في التسلسل الهرمي.

يبدأ كاتب الشرح التعليمي (tutorial) ببناء قاعدة معرفة صغيرة لمطوّر، تشمل المعمارية والمصادقة وقاعدة البيانات وواجهات API والواجهة الأمامية والنشر والتخزين المؤقت (caching) وملاحظات الأداء (performance). بعد ذلك يُبنى من هذه الملفات كائن KnowledgeGraph يحلّل العناوين والوسوم والروابط. وفوقه تُنفَّذ العمليات الأساسية في IWE ليتبيّن أن الرسم البياني لا يصلح للتخزين فقط، بل للتنقل والتحليل أيضًا.

• find — يبحث عن الملاحظات ذات الصلة بالاستعلام
• retrieve — يجلب المستند مع السياق المرتبط به
• tree — يعرض التسلسل الهرمي وخريطة الأقسام
• squash — يدمج عدة مستندات مترابطة في مستند واحد
• export dot — يجهّز تصوّرًا مرئيًا للرسم البياني عبر Graphviz

أين يدخل OpenAI

الطبقة التالية هي تحويلات الوثائق بالذكاء الاصطناعي. لهذا الغرض يبني المقال دالة ai_transform، التي ترسل الملاحظة إلى نموذج OpenAI وتطبّق أحد خمسة سيناريوهات: rewrite أو summarize أو expand أو extract_todos أو generate_links. أي أن قاعدة المعرفة نفسها لا تكتفي بتخزين البنية، بل تبدأ بإعادة صياغة عقدها وتلخيصها وتوسيعها وربطها تلقائيًا.

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

الوكيل يتنقل عبر الرسم البياني

أكثر الأجزاء إثارة للاهتمام هو agentic RAG فوق الرسم البياني المعرفي. يُوصَف للوكيل أربع أدوات: iwe_find وiwe_retrieve وiwe_tree وiwe_stats. وعبر OpenAI function calling يقرّر النموذج بنفسه متى يبحث عن نقطة دخول، ومتى يقرأ مستندًا مرتبطًا، ومتى يطّلع على شجرة الأقسام، ومتى يطلب إحصاءات عامة عن القاعدة.

بعد ذلك تعمل حلقة search-retrieve-synthesize إلى أن يجمع الوكيل إجابته. وفي الأمثلة يجيب الوكيل عن أسئلة حول اعتماديات نظام المصادقة، ومسار النشر (deploy pipeline)، والمعمارية العامة للمشروع. ثم يذهب المؤلف أبعد من ذلك: يبحث الذكاء الاصطناعي عن الفجوات في الرسم البياني، ويولّد ملاحظة جديدة عن استراتيجية معالجة الأخطاء، ويضيفها إلى القاعدة، ويحدّث التصوّر المرئي. أما الاختبار الأخير فهو سؤال multi-hop عن ارتفاع الحمل من 1000 إلى 5000 RPS، يتعيّن فيه على النموذج الربط بين قاعدة البيانات والتخزين المؤقت والرموز المميزة (tokens) والبنية التحتية، لا مجرد إعادة سرد ملف واحد.

ماذا يعني ذلك

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

وهذه إشارة مهمة للفرق: فالقيمة لم تعد تكمن في النموذج نفسه بقدر ما تكمن في مدى حسن تنظيم السياق وتوافره لديك.