ويكي LLM: كيف تبنيه وتحافظ على دقته

ويكي LLM قاعدة معرفة شخصية يكتبها لك وكيل ذكاء اصطناعي. تجمع مصادرك الخام في مجلد: مقالات، وأوراقًا بحثية، ونصوصًا مفرّغة، وملاحظات. فيقرؤها الوكيل ويبني فوقها مجموعة من صفحات markdown المترابطة ويحدّثها: صفحة لكل مفهوم أو شخص أو مصدر، وفهرسًا يجمعها. أضف مصدرًا، فيحدّث الوكيل كل صفحة يمسّها. واطرح سؤالًا، فيجيبك من الويكي، ويمكنه أن يحفظ الجواب فيه صفحةً جديدة.

صاحب الفكرة Andrej Karpathy. ففي 2 أبريل 2026 كتب على X عن «قواعد المعرفة المبنية بالنماذج اللغوية» (LLM Knowledge Bases)، وبعدها بيومين نشر نسخة أطول في «ملف فكرة» على GitHub، كتبه ليُلصق كما هو في وكيل مثل Claude Code أو Codex. ويضع فكرته في مقابل RAG: ففي RAG يسترجع النموذج مقاطع من ملفاتك مع كل سؤال، ولا يتراكم شيء. أما في ويكي LLM فالمعرفة «تُبنى مرة واحدة ثم تبقى محدَّثة»، فتكون الإحالات بين الصفحات جاهزة والتناقضات محسومة قبل أن تسأل.

Obsidian هو بيئة التطوير، والنموذج اللغوي هو المبرمج، والويكي هو قاعدة الشيفرة.

تلخّص هذه الجملة من الملف الإعداد الذي ينسخه معظم الناس: الوكيل مفتوح في الطرفية على جانب، ومحرّر markdown على الجانب الآخر، وبينهما مجلد من الملفات. لكن النمط نفسه لا يشترط محرّرًا بعينه: يكفيه أي مجلد، وأي وكيل يقرأ الملفات ويكتبها.

ما لا يخبرك به المحرّر هو أي الصفحات غيّرها الوكيل، وهل راجعها أحد. وهنا يأتي دور Knowtarium: قاعدة معرفة مشفّرة تشفيرًا تامًا بين الطرفين، صُمّمت لهذا الإعداد تحديدًا. يُحفظ الويكي في مساحة عمل على شكل صفحات markdown عادية، ويقرؤه وكيلك ويكتب فيه عبر MCP، وكل تغيير يجريه على صفحة موقَّع، ويُظهر من أجراه، ويمكن التراجع عنه. والبدء مجاني. يشرح باقي هذا الدليل الإعداد بملفات عادية، ويتوقّف بين حين وآخر ليبيّن كيف يتعامل معه Knowtarium.

يقسم Karpathy نمط ويكي LLM إلى ثلاث طبقات:

• المصادر الخام. مستندات اخترتها بعناية، ولا تتغيّر: يقرؤها الوكيل ولا يعدّلها أبدًا. وهي مرجعك حين تريد الحقيقة.
• الويكي. مجلد من صفحات markdown يكتبها الوكيل: ملخّصات، وصفحات للكيانات وأخرى للمفاهيم، ومقارنات، ونظرة عامة. «أنت تقرؤه، والنموذج يكتبه.»
• المخطط. ملف مثل CLAUDE.md في Claude Code أو AGENTS.md في Codex، يشرح للوكيل كيف نُظّم الويكي، وأي خطوات يتّبع في كل مهمة. وتطوّره أنت والوكيل مع الوقت.

وثلاث مهام تطلبها من الوكيل:

ويسهّل التنقّلَ فيه ملفّان. الأول index.md: يسرد كل صفحة برابطها وملخّص من سطر واحد، ويقرؤه الوكيل أولًا مع كل سؤال. ويقول Karpathy إن هذا يعمل «جيدًا على نحو مفاجئ» في حجم متوسط (نحو 100 مصدر ومئات الصفحات) دون أي بحث بالمتّجهات. وإذا تجاوز الويكي هذا الحجم، يقترح الملف أن تعطي الوكيل أداة بحث محلية في ملفات markdown. أما الثاني، log.md، فخط زمني لعمليات الإدخال والاستعلام والفحص.

الملف الأصلي مجرّد عن قصد، ويترك التفاصيل لك ولوكيلك. وإليك نسخة عملية تعمل مع Claude Code أو Codex أو Cursor. تحتاج إلى نصف ساعة تقريبًا، يذهب معظمها في كتابة المخطط.

1. أنشئ المجلدات

افصل المصادر عن الويكي، لتعرف دائمًا أي نص جاء من العالم، وأيّه كتبه الوكيل.

customer-wiki/
  CLAUDE.md            # المخطط (وفي Codex: AGENTS.md)
  raw/                 # مصادرك: يقرؤها الوكيل ولا يعدّلها أبدًا
    2026-09-12-interview-northwind.md
    2026-09-14-support-tickets.md
    assets/            # صور تُنزَّل بجانب المقالات المحفوظة
  wiki/                # صفحات الوكيل
    index.md           # سطر لكل صفحة، يقرؤه الوكيل أولًا مع كل سؤال
    log.md             # ماذا حدث ومتى
    overview.md
    concepts/
    entities/
    sources/           # صفحة ملخّص لكل مصدر خام
    answers/           # الأجوبة الجيدة، محفوظة في الويكي

في Knowtarium

استورد customer-wiki/ إلى مساحة عمل في Knowtarium، وستنتقل مجلداته معه. يُظهر مخطط الروابط ما تقادم من صفحات (ومع تفعيل المراجعة، يمكنه أن يلوّنها حسب مستوى الثقة)، والروابط إلى صفحات لم يكتبها الوكيل بعد تظهر روابطَ شبحية: قائمة مهام جاهزة للإدخال القادم.

(تُفتح بحجمها الكامل في علامة تبويب جديدة) (تُفتح بحجمها الكامل في علامة تبويب جديدة)

2. أنشئ مستودع git

شغّل git init قبل أول إدخال. فالويكي، كما يقول Karpathy، «ليس إلا مستودع git من ملفات markdown»، وgit أيضًا أرخص طريقة لترى ما غيّره الوكيل. سنعود إلى ذلك لاحقًا.

3. اكتب ملف المخطط

هذا أهم ملف في الإعداد كله. ابدأه قصيرًا، وأضف قاعدة كلما فعل الوكيل شيئًا لا تريده. وهنا تنطبق إرشادات Anthropic لملف CLAUDE.md: أبقِه في حدود 200 سطر تقريبًا، واجعل كل تعليمة محدّدة بما يكفي لتتحقّق منها. وإن كنت تستخدم أكثر من وكيل، فاكتبه مرة واحدة باسم AGENTS.md، وأضف ملف CLAUDE.md فيه السطر @AGENTS.md، فيحمّل Claude Code القواعد نفسها.

# مخطط الويكي
 
أنت مسؤول عن الويكي في wiki/. أما المصادر في raw/ فللقراءة فقط.
 
## الصفحات
- مفهوم أو كيان أو مصدر واحد في كل ملف. أسماء الملفات بصيغة kebab-case.
- تبدأ كل صفحة بقسم frontmatter فيه: type وtitle وdescription وsources.
- اربط الصفحات المتصلة بروابط markdown عادية.
- كل ادعاء يستشهد بمصدره في حاشية مفتاحها معرّف المصدر.
- ما لا تجد له مصدرًا تستشهد به فلا تكتبه. وعلّم الأسئلة المفتوحة بأنها مفتوحة.
 
## الإدخال (ingest): عندما أضيف ملفًا إلى raw/
1. اقرأ المصدر. وقبل أن تكتب، أخبرني بأهم 3 إلى 5 نقاط فيه.
2. اكتب wiki/sources/<name>.md وفيه ملخّص ومعرّف المصدر.
3. حدّث صفحات المفاهيم والكيانات التي يمسّها. وإن خالف صفحة موجودة،
   فنبّهني إلى التناقض بدل أن تكتب فوقها بصمت.
4. حدّث wiki/index.md وأضف مدخلًا إلى wiki/log.md.
5. اسرد كل ملف غيّرته.
 
## الاستعلام (query)
- اقرأ wiki/index.md أولًا، ثم افتح الصفحات التي تحتاجها فقط.
- أجب مع الاستشهادات، واعرض عليّ حفظ الأجوبة الجيدة في wiki/answers/.
 
## الفحص (lint): عندما أطلبه
- أبلغني بالتناقضات، والادعاءات القديمة، والصفحات اليتيمة، والصفحات الناقصة،
  والادعاءات التي بلا مصدر. اقترح الإصلاحات، ولا تطبّقها الآن.

في هذا الملف قاعدتان أهم مما تبدوان: «كل ادعاء يستشهد بمصدره» و«اسرد كل ملف غيّرته». لا تكلّفانك شيئًا الآن، وبهما تصبح المراجعة ممكنة لاحقًا.

4. أضف مصدرًا واحدًا وأدخِله

احفظ مقالًا بصيغة markdown في raw/، واطلب من الوكيل إدخاله. يفضّل Karpathy أن يُدخل مصدرًا واحدًا في كل مرة وأن يبقى حاضرًا: يقرأ الملخّص، ويتحقّق من التحديثات، ويخبر الوكيل بما يستحق التركيز. افعل هذا مع أول عشرة مصادر على الأقل، فهكذا تكتشف ما ينقص مخططك.

في Knowtarium

كل صفحة يكتبها الإدخال أو يغيّرها تبقى معلَّمة في الشريط الجانبي حتى تفتحها، وتحت عنوانها سطر يقول أي وكيل عدّلها ومتى، ورابط إلى التغييرات، وزر Undo. اقرأ الملخّص والتحديثات هناك، وتراجع عن كل ما لا تريده. وإن كنت تفضّل أن توافق أولًا، ففعّل المراجعة («Ask me first») لمجلد wiki/، فينتظرك كل تغيير على شكل diff.

(تُفتح بحجمها الكامل في علامة تبويب جديدة) (تُفتح بحجمها الكامل في علامة تبويب جديدة)

5. اسأل، واحتفظ بالأجوبة الجيدة

اطرح أسئلة تجمع أكثر من مصدر، لا أسئلة عن مصدر واحد فقط. وحين يستحق جواب أن يبقى، اطلب من الوكيل أن يحفظه في wiki/answers/، وأن يضع رابطًا إليه في الصفحات التي استند إليها.

# أدخِل مصدرًا واحدًا
> أدخِل raw/2026-09-14-support-tickets.md إلى الويكي. اعرض عليّ النقاط الرئيسية أولًا.
 
# اسأل، ثم احتفظ بالجواب
> بالاعتماد على الويكي وحده: أين يتعثّر العملاء الجدد؟ استشهد بالصفحات.
> احفظ الجواب في wiki/answers/onboarding-blockers.md واربطه بالويكي.
 
# فحص دوري
> افحص الويكي. لا تغيّر شيئًا الآن، أعطني قائمة.

6. حدّد موعدًا ثابتًا للفحص

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

## [2026-09-14] ingest | تذاكر الدعم، أغسطس
## [2026-09-15] query | أين يتعثّر العملاء الجدد؟
## [2026-09-20] lint | تناقضان، 4 صفحات يتيمة

$ grep "^## \[" wiki/log.md | tail -5

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

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

لا شيء من هذا يجعل النمط فكرة سيئة. لكنه يعني أن ويكي LLM يحتاج إلى ما تحتاجه أي قاعدة شيفرة كتبها مؤلف واحد: عين ثانية، وسجل يقول من كتب ماذا.

أربع عادات تسدّ معظم هذه الثغرة. ويمكنك أن تتبنّاها واحدة تلو الأخرى، بملفات عادية، ودون أي أداة جديدة.

1. سجّل أصل كل صفحة في الـ frontmatter

يجب أن تقول كل صفحة من كتبها، ومتى، ومن أي مصادر، وأن يشير كل ادعاء فيها إلى أحد تلك المصادر. والحواشي التي مفتاحها معرّف المصدر ([^northwind-call]) تصمد حين يعيد الوكيل ترتيب القائمة، أما الحواشي المرقّمة فلا. وهذه صفحة تستخدم أسماء الحقول في Open Knowledge Format، لتقرأها أدوات أخرى أيضًا:

---
type: Concept
title: التعثّر عند خطوة الاستيراد
description: لماذا يتعثّر العملاء الجدد حين يستوردون بياناتهم.
generated: { by: claude-code/2.1, at: 2026-09-20T09:12:00Z }
verified:
  - { by: human:sam, at: 2026-09-20T18:40:00Z }
stale_after: 2027-03-20T00:00:00Z
sources:
  - id: northwind-call
    resource: /raw/2026-09-12-interview-northwind.md
    title: مقابلة عميل، Northwind Traders
---
 
علِقت Northwind أسبوعًا عند استيراد ملف CSV.[^northwind-call]

يحدّد generated من كتب النص الحالي، وverified من راجعه، وتدلّ البادئة human: على شخص. أضف إلى مخططك سطرًا يقول: «وقّع في generated كل صفحة تغيّرها، ولا تضف نفسك أبدًا إلى verified». ويتوسّع دليلنا عن جعل الوكلاء يستشهدون بمصادرهم في ذلك.

2. راجع كل تغيير من الوكيل قبل أن تعتمد عليه

عامِل كل إدخال كأنه طلب دمج (pull request): نفّذ commit قبل أن تبدأ، ودع الوكيل يعمل، ثم اقرأ الـ diff واقبله أو ارفضه. وgit يتقن هذا:

$ git status --short          # أي الصفحات تغيّرت$ git diff --stat             # وحجم التغيير$ git diff wiki/concepts/     # اقرأ التعديلات نفسها$ git add -p                  # اقبلها جزءًا جزءًا$ git commit -m "ingest: support tickets"$ git restore wiki/entities/  # تخلّص مما لم تقبله

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

3. دع الوكيل يراجع تعديلاتك

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

4. ضع للصفحات تاريخ انتهاء

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

Open Knowledge Format مواصفة مفتوحة نشرتها Google Cloud للمعرفة التي يكتبها الوكلاء. وأضاف الإصدار 0.2 إشارات الثقة للحالة التي وصفناها بالضبط: نصوص يكتبها وكلاء باستمرار ويقرؤها وكلاء آخرون. وحزمة OKF على شكل ويكي LLM نفسه (مجلد من ملفات markdown مع frontmatter بصيغة YAML)، وتحجز اسمَي الملفين أنفسهما، index.md وlog.md.

ويستنتج قارئ الحزمة مستوى الثقة من verified: لا مدخلات تعني unverified، ووكلاء أو عمليات فقط تعني machine-confirmed، وشخص واحد على الأقل يعني human-reviewed. ولا يحقّ لصفحة أبدًا أن تعلن نفسها موثوقة. وثمّة فرقان صغيران بينها وبين ملف Karpathy: الملف لا يحدّد صيغة للروابط، بينما تستخدم OKF روابط markdown العادية؛ وlog.md في OKF يسرد الأحدث أولًا، تحت عناوين تواريخ بسيطة بصيغة YYYY-MM-DD. وكل الحقول اختيارية، فيمكنك أن تبدأ ويكي LLM بصيغة OKF، وتضيف حقول الثقة مع الوقت.

git هو الحدّ الأدنى: يريك ما تغيّر، بشرط أن تنفّذ commit قبل كل جلسة وتقرأ الـ diff بعدها. أما حين يكبر الويكي، فالإعداد الذي ننصح به هو Knowtarium، لأنه يحفظ السجل والتراجع وحالة الثقة بجانب الصفحات، لا في الطرفية. وهذه مقارنة بينهما.

إن كنت تُدخل بضعة مصادر في الأسبوع وتقرأ كل diff، فقد يكفيك git وحده. وKnowtarium تطبيق ويب: تُشفَّر صفحاتك على جهازك قبل أن تصل إلينا، فلا نستطيع قراءتها، ولا يستدعي التطبيق أي ذكاء اصطناعي بنفسه. أما الوكيل الذي تربطه فيرى ما يقرؤه. وإن كان الويكي محفوظًا أصلًا في خزنة Obsidian، فاستوردها إلى مساحة عمل، فتتحوّل إلى OKF دون أن يُمسّ شيء مما كتبته. يشرح ذلك دليل الانتقال، وتوضّح صفحة المقارنة الفرق بين التطبيقين.