تفشل مشاريع ذكاء اصطناعي كثيرة لأن تقنية RAG تُختار بشكل تلقائي. إليك الأسئلة التي يجب طرحها قبل الاختيار بين RAG والبحث التقليدي أو استدعاء واجهة برمجية بسيطة.
ما هي تقنية RAG فعلاً، ولماذا تُطرح كحلّ لكل شيء؟
استرجاع المعلومات المعزّز بالتوليد (Retrieval Augmented Generation) هو نمط معماري بسيط في جوهره: بدل أن تطلب من النموذج اللغوي الإجابة من ذاكرته، تبحث أولاً في مصدر معرفة تملكه أنت — مستندات، قاعدة بيانات، موقع داخلي — ثم تمرّر المقاطع المسترجَعة إلى النموذج ليصوغ الجواب اعتماداً عليها.
المشكلة ليست في التقنية، بل في الطريقة التي تُعتمد بها. في كثير من المشاريع، يُقرَّر استخدام RAG قبل تحديد المشكلة أصلاً، لأنها تبدو الخيار "الحديث" أو "الآمن". والنتيجة: نظام معقّد، تكلفة تشغيل متكررة، وصيانة دائمة، بينما كان الحل المطلوب أبسط بكثير.
الأسئلة الأربعة قبل أي قرار
1. هل يحتاج المستخدم إلى صياغة أم إلى معلومة؟
إذا كان المطلوب هو العثور على مستند أو رقم أو بند قانوني، فالبحث التقليدي المحسّن (بحث نصي مع فهرسة جيدة، أو بحث دلالي بسيط) يعطي نتيجة أدق وأرخص وأسهل في التحقق. المستخدم يريد أن يرى المصدر بنفسه.
أما إذا كان المطلوب تلخيصاً، أو مقارنة بين ثلاثة عقود، أو إجابة مباشرة على سؤال يمتد عبر عدة مستندات، فهنا تبدأ قيمة RAG الحقيقية.
2. هل المعرفة تتغيّر باستمرار؟
هذا هو المعيار الأهم. RAG يتفوّق حين تتغيّر المعرفة يومياً أو أسبوعياً: أسعار، سياسات، وثائق تقنية، مراسلات داخلية. تحدّث الفهرس، فيتحدّث النظام دون إعادة تدريب.
في المقابل، إذا كانت المعرفة ثابتة ونمط الإجابة ثابتاً، فإن الضبط الدقيق (fine-tuning) على أمثلة محدودة قد يكون أنسب وأخف على البنية التحتية. القاعدة العملية: RAG للمعرفة المتغيّرة، والضبط الدقيق للأسلوب والصيغة والسلوك.
3. هل تملك المصدر أصلاً؟
RAG لا يخلق معرفة. إذا كانت المستندات مبعثرة في مجلدات شخصية، أو بصيغ ممسوحة ضوئياً بلا نص قابل للاستخراج، أو مكرّرة بإصدارات متعددة ومتناقضة، فأنت لا تحتاج مساعداً ذكياً — تحتاج أولاً إلى تنظيف قاعدة المعرفة. أي مشروع RAG يُبنى على مصدر فوضوي سيقدّم إجابات واثقة وخاطئة، وهذا أسوأ من عدم تقديم إجابة.
4. ما تكلفة الخطأ؟
في سياق استشاري داخلي، إجابة ناقصة تُصحَّح بسهولة. أما في سياق يتعلق بالالتزامات التعاقدية أو الصحة أو المال، فيجب أن يكون النظام مُلزَماً بالاستشهاد بالمصدر، وأن يمتنع صراحةً عن الإجابة عند غياب الدليل. إن لم يكن الامتناع ممكناً تقنياً، فأعد النظر في المشروع كله.
متى تتجنّب RAG؟
- عندما تكفي واجهة برمجية بنمط ثابت. إذا كان الطلب "لخّص هذا النص" أو "صنّف هذه الرسالة"، فلا حاجة إلى فهرس ولا استرجاع. استدعاء مباشر للنموذج أرخص وأسرع وأقل عرضة للأعطال.
- عندما يكون السؤال حسابياً أو بنيوياً. "كم إجمالي الفواتير في الربع؟" سؤال لقاعدة بيانات، لا لنموذج لغوي. الحل الصحيح: استعلام SQL ثم صياغة النتيجة، لا بحث دلالي في ملفات PDF.
- عندما لا يوجد من يراجع المخرجات. نظام بلا مراجعة بشرية في مرحلة الإطلاق يبني ثقة على أساس هش.
- عندما تكون الميزانية التشغيلية غير محسوبة. الاسترجاع يستهلك تخزيناً وحوسبة، وكل استعلام يستهلك رموزاً. احسب التكلفة الشهرية عند الحجم المتوقع قبل البدء، لا بعده.
كيف تبني نظاماً يستحق البقاء؟
ابدأ من التقييم، لا من البنية. اجمع ثلاثين إلى خمسين سؤالاً حقيقياً من المستخدمين، مع الإجابة الصحيحة المتوقعة لكل منها. هذه المجموعة هي بوصلة المشروع: بدونها لن تعرف إن كان التعديل تحسيناً أم تراجعاً.
قسّم المستندات بذكاء. التقسيم الأعمى إلى مقاطع متساوية يكسر السياق. احترم البنية: عنوان، قسم، فقرة، جدول. أضف إلى كل مقطع بيانات وصفية — التاريخ، القسم، مستوى السرية — واستخدمها في التصفية قبل البحث.
افصل الاسترجاع عن التوليد في القياس. قِس أولاً: هل المقطع الصحيح ضمن النتائج؟ إن لم يكن، فلا فائدة من تحسين صياغة النموذج. هذه الخطوة وحدها توفّر أسابيع من العمل في الاتجاه الخاطئ.
اطلب الاستشهاد دائماً. كل جواب يجب أن يحمل مرجعاً يمكن للمستخدم فتحه. هذا يبني الثقة، ويكشف أخطاء الاسترجاع بسرعة.
راقب بعد الإطلاق. سجّل الأسئلة التي لم يجد النظام لها مصدراً، والأسئلة التي أعاد فيها المستخدم الصياغة. هذه السجلات هي خارطة الطريق الحقيقية للتحسين.
احترم الخصوصية منذ التصميم. حدّد ما يجوز إرساله إلى مزوّد خارجي وما يجب أن يبقى داخلياً، وطبّق صلاحيات الوصول على مستوى الاسترجاع نفسه، لا على مستوى الواجهة فقط.
الخلاصة
RAG أداة ممتازة لمشكلة محددة: جعل نموذج لغوي يجيب من معرفة مؤسسية متغيّرة، مع إمكانية التحقق من المصدر. وهي أداة خاطئة عندما تكون الحاجة بحثاً، أو حساباً، أو صياغة ثابتة. القرار الصحيح لا يبدأ بالسؤال "كيف نبني RAG؟" بل بـ"ما المشكلة التي نحلّها، وما أرخص طريقة تحلّها بشكل موثوق؟"
---
إن كنت تفكّر في مساعد ذكي لمستنداتك الداخلية، أو تتساءل إن كان ما تحتاجه هو RAG أو مجرد بحث محسّن أو استدعاء بسيط لواجهة برمجية، يسعدني أن نناقش الحالة بلا التزام: contact@hamzabelgacem.com.