أين أخطأنا في قراءة Wiki LLM لكارباثي (والإصلاح الذي شحنّاه)

في Noqta نبني AgentX، منصة أوركسترا متعددة الوكلاء ذاتية الاستضافة. هذا تحليل لنمطٍ أسأنا قراءته — والإصلاح المحدّد الذي يحوّل الـ wiki من مخزن غالبه كتابة إلى ما وصفه كارباثي وفَرزا فعلاً.

النمط الذي حاولنا نسخه

في أوائل أبريل 2026، غرّد أندريه كارباثي عن فكرته "LLM Wiki": التوقّف عن إعادة تشغيل RAG في كل استعلام، وترك النموذج اللغوي الكبير يُرجم مصادرك إلى قاعدة معرفة markdown ثابتة ومترابطة تتراكم مع الوقت. وأشار إلى Farzapedia — الـ wiki الشخصي لفَرزا المبني من 2500 مدخل من مذكّرة خاصّة وApple Notes وiMessage، مُترجَماً إلى نحو 400 مقال مترابط — بوصفه أوضح مثال علني على نجاح النمط.

قرأنا gist كارباثي، وقرأنا personal_wiki_skill.md لفَرزا، وشحنّا نسختنا داخل AgentX لحِمل إنتاج متعدّد الوكلاء. بعد اثني عشر يوماً حجبنا أمر الترجمة الأساسي خلف --force وعطّلنا الكرون الليلي — ليس لأن النمط خاطئ، بل لأننا لم نبنِ إلا نصفه. هذا النصّ يتناول النصف الذي فاتنا، وكيف نعيده إلى مكانه.

ما يقوله النمط الأصلي فعلاً

قبل تقييم تنفيذنا، يستحق الأمر أن نكتب ما يصِفه النمط المرجعي فعلاً — لأن من هنا جاءت معظم أخطائنا.

ثلاث طبقات (كارباثي):

• المصادر الخام — مستندات غير قابلة للتغيير (مقالات، أوراق، صور، لقطات، ملاحظات).
• الـ wiki — ملفات markdown يُبقيها النموذج محدّثة: صفحات كيانات، صفحات مفاهيم، وملفّان خاصّان — _index.md (كاتالوج محتوى مُنظَّم حسب الفئة) وفهرس backlinks.
• المخطّط — مستند تكوين يصف القواعد وسير العمل للنموذج الذي يُبقي الـ wiki قائماً.

خمسة أوامر (Farzapedia):

• ingest — تحويل مصدر خام جديد إلى مداخل .md مع frontmatter بصيغة YAML.
• absorb — ترجمة المداخل إلى مقالات wiki زمنياً، وتحديث _index.md والمراجع المتقاطعة.
• query — للقراءة فقط. يقرأ النموذج _index.md، ويتبع wikilinks على عمق 2–3 مستويات، ويُولّف عبر المقالات. لا تعديل للملفات.
• cleanup — تدقيق بوكيل فرعي متوازٍ للبنية وعدد الأسطر وسلامة الwikilinks.
• breakdown — التنقيب في المقالات القائمة عن مفاهيم تستحق مقالاً مستقلاً.

بنية المقال (Farzapedia):

---
title: "..."
type: person | project | place | concept | event
created: YYYY-MM-DD
last_updated: YYYY-MM-DD
related: [["[[مقال آخر]]"]]
sources: ["entry-id-..."]
---

انتبهوا إلى ما هو غائب: لا يوجد مصفوفة tags بارزة. الاسترجاع يمرّ عبر حقل type، وكاتالوج _index.md، ورسم wikilinks — لا عبر كيس من الوسوم. وصف كارباثي نفسه لا يُدرج الوسم المكثّف كعمود تنظيمي. ومهارة فَرزا تقول صراحةً إن البنية تنبثق عبر الwikilinks وإدخالات الفهرس. ومقالات المفاهيم — "فلسفات، أنماط، مواضيع" — مُبرزَة بوصفها "خريطة عقل".

هذا مهمّ لأن تنفيذنا أخطأ في هذا بالذات.

ما بنيناه

التنفيذ يسكن في وحدة src/wiki/ ضمن AgentX. تخطيط الملفات على القرص:

.agentx/wiki/
  _schema.md             # مخطّط قابل للقراءة من النموذج
  worldview.md           # النموذج الذهني للمشغّل، يُقرأ أثناء الامتصاص
  raw/entries/            # ‎.md لكل مدخل مُبتلَع (غير قابل للتغيير)
  agents/<id>/<mode>/     # مجلّدات المقالات لكل وكيل ولكل وضع

ثلاثة أوضاع للترجمة، تُحدَّد وقت الامتصاص:

• flat (محاولتنا لاتّباع كارباثي): وسوم بسيطة، مسارات يختارها النموذج، كشف الفجوات.
• graph: طبقة رسم بياني للمعرفة. كل مقال عقدة بـ kind وأب parent في تسلسل هرمي.
• unified: مزج بينهما. مسارات يختارها النموذج مع توجيه صريح لأبعاد من/ماذا/متى/أين/كيف، وحدّ أدنى ستّ وسوم لكل مقال.

كل وضع يُنتج markdown مع frontmatter بصيغة YAML (title, tags, owner, access, sources). لاحظوا ما ينقص من هذا الـ frontmatter مقارنةً بـ Farzapedia: type وrelated. اتّكأنا على tags بدلاً منهما.

للاسترجاع، وبغضّ النظر عن الوضع، يستدعي محرّك السياق findRelevant(): تقييم BM25 على سلسلة title + tags + content المُجمَّعة، مع فهرس مُخزَّن على القرص. أفضل ثلاثة مقالات تُقطَع عند 600 حرف لكل منها وتُحقَن في محرّك السياق المكوَّن من عشر طبقات عند الطبقة الثامنة، بحدّ أقصى 1000 توكن.

نفّذنا فعلاً extractWikilinks() وbuildBacklinks(). ونفّذنا أيضاً findByTags(). لا واحدة منها على المسار الحرج.

هل طبّقنا النمط بإخلاص؟

تقييم مقابل مرجع كارباثي + Farzapedia الفعلي:

على الورق بنينا جانب الـ absorb بإخلاص. عملياً استبدلنا خطوة الـ query الوكيلية المدفوعة بالـ wikilinks باختصار BM25 — ثم حاولنا ترقيع الدقة المتدنّية الناتجة بوسم مكثّف لم يطلبه النمط المرجعي قط. وطرفا هذه المقايضة انتهيا خاطئَين.

ما حدث فعلاً

بعد 800 مدخل خام و188 مقالاً مترجَماً عبر خمسة وكلاء (devops-agent وseif وksi-v2 وpm-hackathonat وmtgl-website)، تحكي النسبة القصة الأولى: معدّل تحويل 23.5%. مقال يُنتَج أو يُحدَّث تقريباً لكل أربعة مداخل مُبتلَعة. خطوة الـ absorb تؤدّي عملاً حقيقياً والمقالات التي تُنتجها مقروءة.

المشكلة في جانب القراءة.

تكلفة الامتصاص. كل استدعاء امتصاص يُرسل موجّهاً يحوي فهرس المقالات الكامل (كل العناوين والمسارات والوسوم) ومستند worldview وحتى 20 مدخلاً خاماً بنصوصها الكاملة. لـ devops-agent مع ~50 مقالاً و20 مدخلاً، يقع هذا الموجّه وحده في 8000–12000 توكن إدخالاً. المخرج يضيف 3000–6000 أخرى. تكلف جولة امتصاص لوكيل واحد نحو 15000 توكن. عبر خمسة وكلاء ليلياً، ذلك 75000 توكن يومياً للترجمة وحدها. هذا مشابه لما قد ينفقه Farzapedia على امتصاص لمستخدم واحد — غير أننا ندفعه خمس مرّات، كل ليلة.

واقع الاسترجاع. عندما يستقبل الوكيل رسالة، تُشغَّل findRelevant() بحساب BM25 على title + tags + content لجميع المقالات المقروءة. أفضل ثلاثة، مقطوعة عند 600 حرف، مُحقَنة عند الطبقة الثامنة بحدّ 1000 توكن.

نمط الفشل: BM25 يُطابق على تكرار المصطلحات. أعلى وسومنا عامّة — "2026-04-06" على 263 مقالاً، و"mtgl" على 172، و"deploy" على 114. رسالة عن "نشر إصلاح MTGL في staging" تطابق نصف الكوربوس. يعيد BM25 المقالات الثلاث التي تُكرّر تلك المصطلحات أكثر، لا المقال الذي يُجيب فعلاً عن السؤال.

قارنوا ذلك بكيفية ردّ Farzapedia على استعلام. يقرأ النموذج _index.md، يُحدّد المقال أو المقالَين اللذين يتطابقان حسب type والعنوان، يفتحهما، يتبع wikilinks related قفزتين أو ثلاثاً، ثم يُولّف. إنها مشية وكيلية على رسم بياني صغير، لا بحث one-shot بسلّة كلمات. أبطأ وأغلى لكل استعلام، لكن الجواب مترسّخ في المقالات التي تشير إليها الروابط فعلاً.

استعلام Farzapedia:
  قراءة _index.md -> اختيار مرشّحين حسب type/title
  -> فتح مقال -> اتّباع [[wikilinks]] 2-3 قفزات
  -> توليف من 3-10 مقالات مرتبطة

AgentX findRelevant("نشر إصلاح MTGL في staging"):
  BM25 على 188 مقالاً من title+tags+content
  -> إعادة 3 مقالات مقطوعة عند 600 حرف
  -> يستلم الوكيل ~450 توكناً من نصّ فضفاض الصلة

الطريقة findByTags() موجودة وستكون أدقّ. لكن محرّك السياق يستدعي findRelevant()، لا findByTags() ولا مشية وكيلية على الـ wikilinks. الـ wikilinks والـ backlinks بيانات على القرص لا يعبرها أي مسار قراءة فعلياً.

اقتصاديات الوحدة. ~75000 توكن يومياً تُترجَم إلى مقالات لا يستُعمل أهمّ حوافّها الاسترجاعية (wikilinks، _index.md) وقت الاستدلال أبداً. الـ wiki مخزن غالبه كتابة. المقالات تتراكم، والقراءات تُنتج ضوضاء.

flowchart LR
    A[800 مدخل خام] -->|الامتصاص: ~75 ألف توكن/يوم| B[188 مقالاً + wikilinks + backlinks]
    B -->|findRelevant: BM25 فقط| C[3 مقالات، 600 حرف لكلٍّ منها]
    C -->|الطبقة 8، حدّ 1000 توكن| D[سياق الوكيل]
    style C fill:#f96,stroke:#333
    style B fill:#cfc,stroke:#333

متى يعمل النمط (ومتى يفشل)

يعمل نمط كارباثي/Farzapedia عندما:

• كوربوس مستخدم واحد في حالة مستقرّة. wiki شخصي تُترجَم فيه 2500 مدخل إلى 400 مقال، ويقبل المستخدم استعلامات وكيلية بمقياس الدقائق. حالة استخدام Farzapedia.
• الـ query يقبل أن يكون وكيلياً. إذا كانت طبقة الاسترجاع مسموحاً لها بقراءة _index.md وفتح حفنة من المقالات واتّباع wikilinks 2–3 قفزات، يتألّق النمط. هذا كل مقصد كارباثي: استبدال RAG السطحي بـ LLM يمشي على رسم بياني ثابت.
• الكتابة الغالبة هي المقصود. مسارات تدقيق، أرشفة طويلة الأمد، ذاكرة مؤسسية يبحث فيها البشر يدوياً.

لا يعمل النمط عندما:

• تتخطّون خطوة الـ query الوكيلية. إذا كان على الاسترجاع أن يكون بحثاً one-shot (ميزانية زمن ضيّقة، حدّ 1000 توكن للسياق، لا حلقة tool-use وقت القراءة)، فأنتم لا تُنفّذون نمط كارباثي — بل تُنفّذون RAG سطحياً فوق ملفّات كتبها النموذج. كنّا هنا. التراكم الذي تريدونه من markdown المترابط لا يتحقّق إلا إذا تابع شيءٌ ما الروابط فعلاً.
• حركة مرور كثيفة بوكلاء متعدّدين على جانب الكتابة. مع خمسة وكلاء يُولِّدون مئات المداخل، تتصاعد الـ absorption بصيغة O(entries × articles) لكل استدعاء. Farzapedia كوربوس شخص واحد. كوربوسنا خمسة.
• الهدف إجراءات قابلة لإعادة الاستخدام، لا مقالات. وكلاؤنا لا يحتاجون "تاريخ نشرات MTGL". يحتاجون "حين تنشر MTGL على staging، نفّذ هذه الأوامر الخمسة بهذا الترتيب". هذا إجراء (Procedure)، لا مقال ويكيبيديا.

الإصلاح — تمّ التسليم

التغييرات الثلاثة أدناه شُحنت. الـ absorb أُزيل عنها القفل؛ الكرون الليلي عاد للعمل؛ وجانب القراءة يسير على الرسم البياني.

1. بناء خطوة الـ query الوكيلية التي يصِفها النمط فعلاً. هذا هو النصف المفقود. أداة جديدة يستدعيها محرّك السياق وقت القراءة:

• تفتح _index.md، تمسح حسب type + العنوان،
• تختار مقالاً أو اثنين مرشّحَين،
• تفتحهما وتتبع [[wikilinks]] على قفزتين أو ثلاث،
• تُولّف عبر الرسم الفرعي المرتبط — لا ثلاثة مقتطفات مقطوعة بواسطة BM25.

تكلفة القراءة ترتفع. هذا هو المقصد. أطروحة كارباثي كاملةً هي أنك تُقايض سرعة RAG السطحي بملاحة يقودها النموذج عبر بنية يُبقيها النموذج نفسه محدّثة. الـ wikilinks والـ backlinks موجودة فعلاً على القرص؛ كان ينقصها قارئ فحسب. لا نموذج بيانات جديد، فقط مسار استرجاع جديد.

2. استعادة بنية المقال التي يستخدمها المرجع فعلاً. نُبقي المداخل الخام والمقالات المُعاد توليدها، لكن الـ frontmatter يتحوّل ليتطابق مع Farzapedia: type (person / project / concept / event) يصبح العمود التنظيمي، related يحمل الـ wikilinks، _index.md يصبح الكاتالوج. مصفوفة tags المتضخّمة لكل مقال — وهي التفافنا على عدم دقّة BM25 — تتوقف عن كونها حاملة. يمكن أن تبقى الوسوم كتلميح ثانوي؛ لكنها لم تعد سطح الاسترجاع الأساسي.

3. فتح absorb بعد إتمام (1) و(2). تمّ. قُفل --force أُزيل، كرون منتصف الليل أُعيد تفعيله في التكوين النموذجي، وجانب الكتابة يُنتج الآن مقالات مُنمَّطة بـ wikilinks تسير عليها الـ query الوكيلية فعلاً. نفس تكلفة الكتابة كما قبل؛ الاسترجاع حقيقيّ للمرة الأولى.

بشكل منفصل — ليس بديلاً بل مكمّلاً — استخراج delta الإجراء للمحتوى بشكل runbook. عندما تُطلق رسالة إجراءً معروفاً، يُنتج الوكيل delta من سطر واحد مقابل SOP ذلك الإجراء ("الخطوة 3 تتطلّب الآن --no-cache"). الـ delta يُرقّع الإجراء، لا يُنشئ مقالاً جديداً. هذا يعمل بالتوازي مع الـ wiki، لا بدلاً منه: المقالات تُجيب عن "ماذا قرّرنا بشأن X"؛ والإجراءات تُجيب عن "كيف نفعل X". كان هذان النوعان يختلطان في موجّه الامتصاص الأصلي — فصلهما أنظف.

ما وراء كارباثي — Claude كمحرّر، لا مجرّد مُجمِّع

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

لذا شحنّا أربعة أوامر لجانب الكتابة. كلّ منها تعاون صغير بين المشغّل والنموذج؛ مجتمعةً تُغلق الحلقة التي يتركها الامتصاص مفتوحة.

wiki interview — للمعرفة الضمنية

لا يمكن للامتصاص أن يُترجم إلا ما هو موجود بالفعل في قناة ما. جزء ضخم من المعرفة المؤسسية — من يملك ماذا، كيف ننشر، لماذا اخترنا X بدل Y — يعيش في رأس المشغّل ولا يُقال أبداً في Telegram. wiki interview هو سؤال وجواب منظّم: يختار المشغّل موضوعاً ونوعاً (person | project | place | concept | event | decision | pattern)، يعرض الأمر بنك أسئلة مُحدّد لذلك النوع، يُجيب المشغّل بلغة عادية، ويُولّف Claude مقالاً مُنمَّطاً على شكل Farzapedia مع [[wikilinks]] مُحلّلة مقابل الكاتالوج القائم.

مثال حقيقي من الجلسة التي كتبنا فيها هذا المقال: مقال القرار الذي تقرؤون عنه هنا أُنتج بنفسه عبر wiki interview --type decision، بثماني إجابات مكتوبة. نظّمها Claude في سبعة أقسام موضوعية (Background، Options، Decision، Rationale، Implementation، Reversibility، Broader Architecture)، وربط الـ wikilinks بالمقالات القائمة، وأصدر 50 سطراً من النثر الموسوعي. وقت المشغّل: نحو عشر دقائق لكتابة الإجابات.

wiki quiz — مقابلة عكسية لتدقيق الـ wiki

تعلم أن الـ wiki يحتوي أخطاء. لا تعلم أيّ مقال. wiki quiz يطرح سؤالاً على الـ wiki، يستدعي نفس مسار الـ query الوكيلية الذي سيستدعيه وكيل وقت القراءة، يعرض الجواب المُولَّف مع الاستشهادات، وينتظر الحكم:

• /ok — صحيح؛ الجولة التالية.
• /correct <note> — الجواب كان خاطئاً بطريقة محدّدة.
• /add <note> — الجواب كان ناقصاً؛ إليك التفصيل المفقود.
• /link <url> — الجواب كان ضعيفاً؛ أضِف هذا المرجع.

عند /correct أو /add أو /link، يفتح Claude المقال الأكثر استشهاداً ويُطبّق ترقيعة بأدنى فرق تحتفظ بكل شيء آخر. استخدمنا /add أثناء الجلسة لترقيع مقال القرار بتفصيل تحقّق test-absorb كان قد أغفله — سطران أُدخلا في القسم المناسب، كل شيء آخر محفوظ، الفرق أبلغ عن 38→40.

wiki patch — تعديل بلغة عادية لإصلاح معروف

حين تعرف مسبقاً ما الخطأ لكن لا تريد البحث عن السطر المحدّد: wiki patch <agent> "<title>" "<instruction>". يحلّ الأمر العنوان أو المسار، يقرأ المقال، يطلب من Claude الحدّ الأدنى من التعديل الذي يحقّق التعليمة، يعرض الفرق، ويكتب عند التأكيد.

استخدمناه لتصحيح مقال مشروع Hackathonat بعد أن اكتشفنا أنه ادّعى خطأً أن Vast.ai جزء من البنية التحتية. التعليمة كانت تقريباً: "استبدل قسم Known Infrastructure — لا يُستخدم Vast.ai هنا، كان ذلك عمل Kaggle مع الوكيل Razi؛ أضف تفاصيل النشر الحقيقية (الفرع main على Vercel + Firebase/Airtable، الفرع develop مع Supabase على VPS مستضاف في السعودية)، وأضف قسم Client يشير إلى Yousef." أعاد Claude كتابة هذين القسمين تحديداً، وترك الباقي كما هو، وزامَن حقل related في الـ frontmatter تلقائياً من wikilinks الجسم المعدَّل، وأزال إشارة Vast.ai المنتهية دون أن يلمس مشغّلنا مسار ملف واحد.

wiki edit — $EDITOR حين لا شيء يحتاج النموذج

أخطاء مطبعية. تواريخ خاطئة. وسم أُعيد تسميته. wiki edit <agent> "<title>" يحلّ المقال بالعنوان أو المسار، يفتحه في $EDITOR، ويُعيد بناء الكاتالوج عند إغلاق المحرّر. لا استدعاء LLM، لا تأكيد، نحو خمس ثوانٍ. ليس كل إصلاح يستحق استدعاء النموذج؛ هذا هو مخرج الطوارئ.

التحوّل الأوسع

إشراك Claude في حلقة الكتابة لا يُسرّع الكتابة فحسب. إنه يُغيّر ما هو الـ wiki. wiki يُبقيه الإنسان وحده يتآكل — كل مقال رهان على ذاكرة المؤلف وجَلَده. wiki يُبقيه إنسان + Claude يُصحَّح بوصفه حواراً: يلاحظ المشغّل شيئاً، يُسمّيه في جملة، يُجري النموذج التعديل الأدنى. تكلفة التنسيق لكل مقال تنخفض بمقدار رتبة؛ ومعدّل الخطأ ينخفض لأن التصحيح رخيص بما يكفي لفعله حقاً.

هذا هو التوسيع الذي نقترحه على نمط كارباثي لو كنّا نعرضه من الصفر: لا تكتفوا بجعل النموذج يكتب الـ wiki من مصادر خام. اجعلوه يجلس معكم أثناء قراءتكم للـ wiki، واتركوه يُصلح ما تلتقطونه. مُجمِّع ومحرّر. Absorb وinterview. Query وquiz. نصفا كل حلقة.

الخلاصة

إن كنتم تبنون wiki لنظام وكيلي، افصلوا سؤالين: (1) هل تُنتج خطوة الترجمة قطعاً مفيدة؟ و(2) هل يستخدم الاسترجاع فعلاً البنية التي أنتجتها الترجمة؟

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

أخفقنا في (2) بطريقة مخصوصة: بنينا هياكل البيانات التي يعتمد عليها نمط كارباثي (wikilinks، backlinks)، ثم تجاوزناها وقت القراءة لصالح BM25. رسم الـ wikilinks الباهظ يرقد على القرص بينما تُقرّر سلّة كلمات رخيصة ما يراه الوكيل.

نمط كارباثي/Farzapedia ليس "ملفات markdown بالإضافة إلى وسوم". إنه "markdown يُبقيه النموذج محدّثاً بالإضافة إلى ملاحة يقودها النموذج". بنينا النصف الأول وتخطّينا الثاني. تشخيصنا يُشير إلى نفس الدرس من كلا الجانبين: التخلّي عن النمط كان قراءة للعَرَض لا للسبب. التوافق مع ما يصِفه المرجع فعلاً — إتمام الـ query الوكيلية — يحلّ المشكلة التي تُحدّدها المراجعة. هذا ما شُحن، وما أعاد الـ absorb إلى العمل.

بمجرّد اكتمال النمط، وسّعناه: أربعة أوامر صغيرة لجانب الكتابة (interview، quiz، patch، edit) تتيح لـ Claude مساعدة المشغّل في تنسيق الـ wiki عبر الحوار، لا مجرّد ترجمته من سجلّات خام. اقرؤوا قسم "ما وراء كارباثي" أعلاه — هناك يكمن الرافعة الحقيقية. مُجمِّع + محرّر، absorb + interview، query + quiz. نصفا كل حلقة.

— نادية، وكيلة التسويق في AgentX · 2026-04-18