InfoForge: ويكيبيديا غير المتصلة بالإنترنت كمصدر RAG لوكلاء الذكاء الاصطناعي المحليين لديّ

سألت نموذجًا محليًا بحجم 8 مليارات معلمة عن من كتب رواية “Kokoro” ومتى تم نشرها. أجاب: “ناتسومي سوسيكي، عام 1914”， ثم ذكر المقالة التي قرأها للحصول على هذه المعلومات. النموذج نفسه لا يعرف هذه الحقيقة؛ بل قام بالبحث عنها في نسخة ويكيبيديا التي تبلغ حجمها 52.69 جيجابايت والموجودة على جهازي، دون الحاجة إلى الإنترنت أصلاً.

لماذا نفعل ذلك، بينما النموذج “يعرف” المعلومات بالفعل؟

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

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

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

ما النتيجة النهائية؟

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

$ infoforge "من كتب رواية Kokoro ومتى نُشرت؟"

رواية Kokoro كتبها ناتسومي سوسيكي ونُشرت عام 1914.

المصادر:
  - Kokoro

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

كيف يعمل النظام؟

خمس مراحل، ولا شيء معقد فيها؛ وهذا هو التوصية الفعلية.

استخراج الكلمات المفتاحية: السؤال ليس هو الاستعلام الفعلي؛ فعبارة “من كتب Kokoro ومتى نُشرت؟” ليست مصطلح بحث جيد، بينما “Kokoro” هي الأفضل. بضع عشرات من سطور الكود تزيل الكلمات الشائعة وتحتفظ بالعبارات المهمة، وهذا يكفي تمامًا؛ لم أرغب في تغييره.

البحث: فهرس البحث الخاص بـ Kiwix هو فهرس حقيقي وليس مجرد بحث نصي عادي، وهو السبب في سرعة العملية. عبر 19.19 مليون مدخلة، يعيد النتائج المصنفة في غضون 3 إلى 30 مللي ثانية. لا توجد في هذا النظام أي تقنيات تضمينية، ولا قواعد بيانات متجهية، ولا مخازن للمقتطفات تحتاج إلى إعادة بناء عند تحديث البيانات. محررو ويكيبيديا قاموا بالتقسيم مسبقًا؛ يُطلق على ذلك “المقالات”.

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

البرومبت المُرتكز على المصادر: تُدرج المقالات في البرومبت مع تعليمات صارمة بالإجابة فقط من هذه المصادر وذكر عناوينها. هذه هي الحيلة الأساسية، وهي مجرد تعليمات وليست ضمانًا؛ ولهذا السبب يوجد القسم التالي.

النموذج اللغوي: نموذج التفكير المحلي (DeepSeek-R1 8B، على خادم GPU داخل المنزل) يكتب الإجابة. في حالة التشغيل الحراري، تستغرق العملية بأكملها حوالي 8 ثوانٍ، ومنها 7.9 ثوانٍ تقريبًا هي وقت تفكير النموذج. الاسترجاع مجاني؛ لكن التفكير ليس كذلك.

الترسيخ كعقد رفض

هذا هو القرار التصميمي الذي سأدافع عنه بشدة، وهو ليس تقنيًا أصلًا.

البرومبت الذي يقول “استخدم فقط هذه المصادر” هو مجرد طلب؛ النماذج تلتزم به في معظم الأحيان، لكنها تتجاهله أحيانًا خاصة عندما تكون المصادر قليلة ويكون لدى النموذج ذاكرة مناسبة. إذا كان الدفاع الوحيد للنظام هو هذه الجملة، فإن “الترسيخ” يصبح مجرد شعور نفسي.

لذلك يتم تطبيق الترسيخ خارج النموذج؛ عندما لا تعثر عمليات البحث على معلومات صالحة، لا يمرر البرنامج السؤال الخام إلى النموذج كحل بديل — بل يفشل ويخرج برمز خطأ غير صفر، وهو الإشارة الوحيدة التي تُصمم جميع البرامج للاستجابة لها. والبرامج الذكية التي تستخدمه مُوجهة لالإبلاغ عن فشل البحث بدلاً من اختلاق إجابة من ذاكرتها. الرفض ينتقل عبر النظام؛ ولا يتم تلطيفه في طبقة أعلى.

النتيجة هي مساعد يخبرك بصراحة أنه لم يجد المعلومة المطلوبة. هذا قد يبدو نقطة ضعف على الورق، لكنه عكس ذلك تمامًا. نموذج يقول “لم أجدها” أفضل من نموذج أكبر يختلق إجابات؛ لأن الأول يمكن الاعتماد عليه، بينما الثاني يتطلب التحقق من كل إجابة، وبالتالي لا يتم توفير أي جهد فعلي.

الخصوصية هي بنية النظام وليست سياسة

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

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

الـ 90% غير الملفتة للنظر

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

يُشغّل خادم ويكيبيديا كحاوية بدون صلاحيات جذر على سطح مكتب لينكس غير قابل للتغيير مع تفعيل SELinux، وكل هذه الصفات كلفتني مساءً كاملاً:

• تعيين المستخدم بدون صلاحيات: يجب أن تعمل الحاوية كجذر داخل نطاقها الخاص، وهو ما يُقابل مستخدمي غير المتمتعين بالصلاحيات خارجها؛ أي خطأ هنا يؤدي إلى تشغيل الخادم وإعلانه عن صحته، لكنه لا يستطيع قراءة الملف المحدد.
• إعادة تصنيف SELinux: أي وحدة تخزين مُثبتة في حاوية ضمن نظام SELinux تحتاج إلى خيار تثبيت يُعيد تصنيفها؛ وإلا ترفض النواة القراءة بناءً على سياسة لم تسمع بوجود الحاوية من قبل. تظهر هذه المشكلة كعدم وجود ملف، مما يجعل المستخدم يبحث في المكان الخطأ تمامًا.
• تحديد المسارات بشكل صريح: آلية اكتشاف مجلد ZIM تلقائيًا لم تعمل كما تشير الوثائق داخل رؤية الحاوية للنظام؛ تحديد اسم الملف يدويًا استغرق ثلاثين ثانية فقط بعد التوقف عن افتراض وجود مشكلة في مكان آخر.

ثلاثة إعدادات فقط. استغرقت حوالي 90% من الوقت الإجمالي. هذا هو الواقع الحقيقي لمعظم أعمال الاستضافة الذاتية، وهو بالضبط ما يُهمل في المقالات التوجيهية — مما يجعل الناس يعتقدون أنهم سيئون في ذلك بينما هم فقط يقومون به لأول مرة، بمفردهم، أمام نفس الثلاثة إعدادات.

ثم توقف عن العمل، ولم يلاحظ أحد ذلك

كان يعمل بشكل جيد؛ كان سريعًا أيضًا. قمت باختباره، سجلت الأرقام اللازمة، ثم انتقلت إلى مهام أخرى.

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

الدرس المستفاد بسيط للغاية:

القدرة التي لا يتم تشغيلها تلقائيًا ولا يعرف أحد عن وجودها، لا تختلف عن القدرة التي لم تُبنَ أصلًا.

الحل كان عبارة عن وحدة خدمة مكونة من 12 سطرًا وملف Markdown واحد. الوحدة الخدمة تضمن بقاء الخادم قيد التشغيل حتى بعد إعادة التشغيل؛ أما ملف Markdown فهو عبارة عن وصف للأداة يُستخدم من قبل وكالات الذكاء الاصطناعي لمعرفة ما يمكنها فعله، ويوضح كيفية استدعاء الأداة (عبر أمر shell أو بروتوكول HTTP)، كما يشير إلى ضرورة إرفاق المراجع مع الإجابات.

النظام بأكمله يتكون من 700 سطر من الكود، لكن 13 سطرًا فقط كانت كافية لجعله يعمل فعليًا. أستمر في تعلم هذا الدرس مرارًا وتكرارًا.

متكامل مع نظام الوكالات

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

كما أن هذه الأداة تتكامل مع كل ما يوجد في النظام؛ فنفس خادم GPU يستجيب لطلبات InfoForge، ويكتب الرسائل الإلكترونية ويشارك في المحادثات؛ وبذلك أصبحت طبقة المعرفة جزءًا آخر من النظام لا يتطلب أي حسابات أو تسجيلات.

نقاط يجب الانتباه إليها

• يجب التحقق من مساحة القرص قبل التنزيل. الحجم المطلوب لتنزيل النسخة الخالية من الصور هو حوالي 53 جيجابايت، ويتضاعف تقريبًا إذا أردت تضمين الصور. تأكد من وجود مساحة كافية؛ فتنزيل ملف ZIM بشكل جزئي طريقة بطيئة للتعرف على هذه الحقيقة.
• تاريخ محدد في الملفات. مثلاً، ملفي يعود تاريخه إلى يونيو 2026؛ لكن ويكيبيديا لا تتوقف عن التحديث. أي محتوى أحدث من ذلك التاريخ غير متاح ضمن هذا النظام، وهذا جيد إذا كنت على علم بذلك، لكنه قد يكون فخًا إذا نسيته.
• جودة البحث تعتمد على استخلاص الكلمات المفتاحية. معظم الإجابات الخاطئة التي رأيتها ناتجة عن استعلامات سيئة، وليس بسبب ضعف النموذج. لذا، حسّن عملية استخلاص الكلمات المفتاحية قبل التفكير في استخدام نماذج أكبر.
• الاختصار في النصوص خيار مهم. إذا كان السياق قصيرًا جدًا، فلن تظهر الإجابة؛ وإذا كان طويلًا جدًا، فقد ينحرف النموذج عن التعليمات. لذا، يجب ضبط هذا الاختصار بناءً على الأسئلة الحقيقية التي تهمك، وليس الأسئلة المصطنعة.
• اختبر مسار الفشل بشكل متعمد. اسأل النظام عن شيء لا يوجد له أي مقالة في ويكيبيديا، وتأكد من أنه يرفض طلبك ويُرجع رمز خطأ غير صفري؛ وليس فقرة سلسة. إذا اكتفيت باختبار الأسئلة التي تعمل بشكل جيد، فأنت تختبر فقط النصف السهل من النظام.
• اكتب وحدة الخدمة في اليوم الأول. كما ذكرت سابقًا؛ اسألني كيف عرفت ذلك.

إلى أين يقودني هذا؟

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

ما يلي في القائمة: إضافة المزيد من ملفات ZIM إلى النظام — مثل مجموعات المعلومات الطبية والتقنية التي توفرها Kiwix، بالإضافة إلى بعض الويكيات الخاصة بي؛ لأن طبقة الاسترجاع لا تهتم بمحتوى هذه الملفات. وأيضًا إضافة فحص صحي للنظام، لأنني تعلمت هذا الدرس الآن بثمن باهظ.

التنزيلات

• Download InfoForge project source (zip) 80 KB

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