المحرك الذي كان لديه ستة أقطاب — أسطورة العشرة أسطر من التعليمات البرمجية

تحقيق في ستة أجزاء حول الأسباب التي تجعل روبوت الدردشة الوثائقي الذي تم بيعه لك يستمر في الاختلاق — والاتجاه المختلف الذي بدأ فيه البعض في بداية عام 2026.

تحقيق في ستة أجزاء حول الأسباب التي تجعل روبوت الدردشة الوثائقي الذي تم بيعه لك يستمر في الاختلاق — والاتجاه المختلف الذي بدأ فيه البعض في بداية عام 2026.

مقدمة — المحرك الذي كان لديه ثمانية أقطاب (ولكن كان لديه ستة)

ميلانو، مارس 2026. يفتح مدير روبوت الدردشة الداخلي للشركة، من تلك التي تم تركيبها "في أسبوعين" من قبل قسم تكنولوجيا المعلومات بحماس كبير وعدم ثقة قليل. سؤال بسيط للغاية: "كم عدد الأقطاب التي يمتلكها محرك CMP40M؟". يجيب روبوت الدردشة بكل الثقة التي يمكن أن تظهرها نماذج اللغة الكبيرة: "محرك CMP40M لديه ثمانية أقطاب."

خطأ. لديه ستة أقطاب. لم تكن الإجابة الصحيحة في الكتالوج المكون من 422 صفحة الذي أودعه شخص ما، قبل أشهر، في قاعدة بيانات متجهة بثقة كاملة، مقتنعًا بأنه من الآن فصاعدًا "سيعرف النظام كل شيء". لم تكن هذه البيانات موجودة في الكتالوج على الإطلاق. كانت في ملف PDF مرفق برسالة بريد إلكتروني من فنيي SEW، مؤرشفة في مجلد لم يأخذ أحد عناء فهرسته.

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

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

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

كل فصل قائم بذاته. إذا كنت ترغب في البدء بقصة الجداول الـ 342 المفقودة، أو قصة جهاز إعادة الترتيب الكاذب، فأنت حر في ذلك. لكن القصة ككل تحمل عبرة لا تظهر إلا في النهاية: RAG المؤسسية - هذا الاختصار التقني الذي يعني Retrieval-Augmented Generation، أي "إنشاء إجابات بناءً على المستندات التي تسترجعها أولاً" - ليست منتجًا نهائيًا بعد. إنها حدود. وكجميع الحدود، فقد رويتها حتى الآن بشكل أساسي من قبل البائعين. حان الوقت للاستماع إلى أولئك الذين عاشوا فيها أيضًا.

الفصل الأول - أسطورة العشرة أسطر من التعليمات البرمجية

الشريحة متطابقة في كل مؤتمر حول الذكاء الاصطناعي منذ عام 2023: "مساعدك الوثائقي للشركة في 10 أسطر من التعليمات البرمجية." أسفل العنوان، كتلة من بايثون بألوان الباستيل تعرض مكتبة مفتوحة المصدر - عادةً واحدة من تلك الأمريكية الشهيرة، التي يستحضر اسمها سلاسل الأشجار أو اللاما التبتية - والتي تقوم بتحميل ملفات PDF وتقطيعها ولصقها داخل قاعدة بيانات متجهة والاستعلام عنها باستخدام نموذج لغوي. في خمس دقائق، لديك روبوت محادثة. في خمس دقائق، التصفيق. في خمس دقائق، تقتنع شركة إيطالية متوسطة الحجم بأن المشكلة قد حُلت وأن قسم تكنولوجيا المعلومات لديها يمكنه فعل ذلك في أسبوعين.

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

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

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

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