هل تحتاج فعلًا إلى RAG؟ اختبار للمؤسسين

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

عادة ما تبدأ القصة بحدس معقول: منتجنا يحتاج إلى معرفة مستنداتنا. ومن هناك تصبح الخطوة إلى "إذن نحتاج RAG" قصيرة، والأقصر منها الخطوة إلى خطة بناء تتضمن التمثيل المتجهي، وقاعدة بيانات متجهية، ومسار استرجاع، وطبقة إعادة ترتيب — ويُقرَّر معظم هذا قبل أن يكتب أحد ما الذي يجب على المنتج فعلًا أن يُتقنه. هذا هو بالضبط النمط الذي وُجدت سلسلة Build vs. Cut لمقاطعته: بنية تُختار بدافع الاندفاع لا بدافع الدليل.

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

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

ما هو RAG فعليًا (بعبارة بسيطة)

RAG (التوليد المعزّز بالاسترجاع) اختصار يصف حركة بسيطة من خطوتين: عندما يصل سؤال، يقوم النظام أولاً باسترجاع أكثر أجزاء معرفتك صلة بالسؤال — فقرة من مستند سياسات، أو صف من كتالوج منتجات، أو قسم من عقد — ثم يُوَلِّد إجابة باستخدام تلك المادة المسترجعة كسياق.¹

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

احتفظ بهذا النموذج الذهني — استرجِع، ثم أجِب مما استُرجِع — لأن كل سؤال تقريبًا حول ما إذا كنت تحتاج RAG يعود إلى شيء واحد:

متى يُثبت RAG جدارته

يُثبت RAG جدارته عندما تكون الصعوبة الأساسية في منتجك متعلقة فعلًا بالوصول إلى المعرفة — أي إيصال المعلومة الصحيحة أمام النموذج في اللحظة الصحيحة. من واقع خبرتنا، هذا صحيح حين يتحقق واحد أو أكثر مما يلي:

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

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

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

متى يكون RAG على الأرجح مبالغة

RAG يحلّ مشكلة الوصول إلى المعرفة. وإذا لم يكن الوصول إلى المعرفة مشكلتك الفعلية، فـRAG طبقة من التكلفة، وزمن الاستجابة، واحتمالات الفشل تضيفها بلا داعٍ. وغالبًا ما يكون مبالغة حين:

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

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

المهمة تحويل، لا بحث. إذا كان ما يفعله منتجك في الغالب هو التصنيف أو الاستخراج أو إعادة الصياغة أو كتابة المسودات — تحويل بريد إلكتروني فوضوي إلى تذكرة منظَّمة، أو تلخيص مستند، أو صياغة رد — فقد لا يحتاج إلى استرجاع أي شيء من الأساس. المادة موجودة أمامه بالفعل. إضافة الاسترجاع إلى مهمة تحويل مثال كلاسيكي لبناء النسخة "المبهرة" من منتج لم يكن يحتاجها.

سؤال السياق الطويل: إجابة صريحة

"ألا يمكننا فقط استخدام نموذج بنافذة سياق ضخمة وتجاوز الاسترجاع تمامًا؟" سؤال عادل، ويستحق إجابة مباشرة بدلاً من عرض ترويجي في أي من الاتجاهين.

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

لنوافذ السياق الكبيرة نقطة ضعف معروفة: النماذج لا تستخدم دائمًا كل ما في سياق طويل بالقدر نفسه من الكفاءة. المعلومة المدفونة في منتصف مُدخل طويل جدًا يمكن أن تُعطى وزنًا أقل مقارنة بمادة في البداية أو النهاية — نمط وثّقه باحثون وأطلقوا عليه اسم "الضياع في المنتصف" (lost in the middle).⁴ نافذة كبيرة ليست الشيء نفسه كاستخدام موثوق لكل ما فيها. وهناك أدلة على أن الاسترجاع، في بعض مهام الإجابة عن الأسئلة ذات السياق الطويل، يمكن أن يتفوّق أداؤه على نهج السياق الطويل الخالص.⁵

معظم "الذكاء الاصطناعي السيئ" سببه فعليًا استرجاع سيئ

إذا بنيت RAG وخيّب أملك، فإليك أهم شيء تعرفه قبل أن تلوم النموذج: معظم إخفاقات RAG هي إخفاقات استرجاع.

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

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

إذا قرّرت بناء RAG، ابنِه بهذا الترتيب

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

1. 1
   ابدأ بمجموعة مستندات نظيفة ومنسَّقة.

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

2. 2
   ابنِ مجموعة الاختبار المرجعية قبل بناء المسار.

   أسئلة حقيقية، ومستندات حقيقية، وحالات استثنائية أو صعبة، بإجابات صحيحة معروفة ومصادر صحيحة معروفة — لتتمكّن من قياس الاسترجاع والتوليد بشكل منفصل منذ اليوم الأول. يمكن تمثيل هذه الأمثلة بصيغ معدّلة أو إعادة بنائها أو توليفها للحفاظ على مستوى صعوبة المهمة دون الحاجة إلى سجلات فعلية بعينها. هذا هو الامتحان الذي يجب أن ينجح فيه نظام RAG، وينبغي أن يوجد قبل أن يوجد النظام نفسه.⁸

3. 3
   أبقِ أول مسار استرجاع بسيطًا.

   مجموعة مستندات منسَّقة، تقسيم منطقي للمستندات إلى مقاطع، استرجاع مباشر، إجابات تستشهد بمصادرها. اجعل هذا يعمل ويُقاس قبل أن تلجأ إلى أي شيء أكثر تعقيدًا.

4. 4
   الجأ إلى البحث الهجين وإعادة الترتيب عندما — وفقط عندما — تُظهر مجموعة اختبارك أنك تحتاجهما.

   هذا يستحق شرحًا خاصًا أدناه.

5. 5
   امنحه طريقة صادقة لقول "لا أعرف".

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

عن البحث الهجين وإعادة الترتيب

هناك ترقيتان تُطرحان باستمرار، وتستحقان الفهم لأنهما تعالجان مشكلتين مختلفتين.

البحث بالكلمات المفتاحية والبحث الدلالي (المعتمد على التمثيل المتجهي) يفشلان بطرق مختلفة. البحث بالكلمات المفتاحية دقيق مع المصطلحات الحرفية — رموز المنتجات، الأسماء، المعرّفات التقنية — لكنه أعمى عن إعادة الصياغة. البحث الدلالي يفهم المعنى وإعادة الصياغة لكنه قد يفوّت سلسلة نصية حرفية كان ينبغي أن يطابقها. ولأنهما يفشلان بطرق مختلفة، فإن الجمع بينهما — البحث الهجين — غالبًا ما يسترجع بشكل أفضل من أي منهما بمفرده، وخطوة إعادة الترتيب التي تعيد احتساب درجات المرشحين المسترجعين قبل وصولهم إلى النموذج يمكن أن تصقل النتائج أكثر.³⁷

RAG ليس كل شيء أو لا شيء (لكن لا تبنِ كل طبقة دفعة واحدة)

المنتجات الحقيقية غالبًا ما تجمع بين الأنماط. نظام ناضج قد يستخدم سير عمل للتحكم في العملية العامة، وRAG لترسيخ خطوة كثيفة المعرفة، ونادرًا وكيلاً حين يكون المسار غير قابل للتنبؤ فعلًا. لا حرج في الجمع بين الطبقات.

الحرج كله في البدء بها جميعًا.

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

اختبار ذاتي سريع

قبل أن تلتزم بـRAG، مرّر منتجك على هذه الأسئلة. هذا إطار من Sprint966، لا معادلة — لن يتّخذ القرار نيابة عنك، لكنه سيخبرك إلى أي جهة يميل الدليل.

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

أين تُغيّر المنتجات العربية وثنائية اللغة الصورة

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

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

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

كيف تتّخذ Sprint966 قرار RAG معك

داخل فحص نطاق منتج الذكاء الاصطناعي (AI Product Scope Check)، قرار RAG/لا RAG ليس حدسًا — إنه قراءة منظَّمة لمنتجك الفعلي. ننظر إلى:

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

أحيانًا تنتهي هذه العملية بمسار استرجاع كامل. وأحيانًا تنتهي بـ"مجموعة مستنداتك تسع داخل السياق — تجاوز RAG في الوقت الحالي". وكليهما هو البناء الصحيح، وكليهما فوز. هذا هو جوهر ما نقوم به: الهدف لم يكن أبدًا بناء RAG. كان بناء المنتج الصحيح أولًا.

الأسئلة الشائعة

المصادر

1. Lewis et al. — Retrieval-Augmented Generation
2. Microsoft: Groundedness Detection
3. Anthropic: Contextual Retrieval
4. Liu et al. — Lost in the Middle
5. LongRAG
6. Microsoft: RAG Evaluators
7. Microsoft: Hybrid Search
8. OpenAI: Evals
9. دليل نظام حماية البيانات الشخصية لجهات التحكم والمعالجة
10. نظام حماية البيانات الشخصية
11. الدليل الاسترشادي لتحديد الحد الأدنى من البيانات الشخصية
12. لائحة نقل البيانات الشخصية إلى خارج المملكة

الخلاصة القصيرة

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

اختبار المؤسس الكامن تحت هذا كله: هل البحث عن شيء هو فعلًا الجزء الصعب في منتجك؟ إذا كانت الإجابة نعم، ابنِ RAG، وابنه بإتقان. إذا كانت لا، فقد وفّرت على نفسك للتو مسارًا كاملاً.