إضافة نموذج لغوي إلى تطبيق ويب لا تضمن أن المنتج أصبح موثوقًا. قد يخطئ النموذج أو يختلق تفاصيل أو يتأثر بتعليمات داخل مستندات غير موثوقة. يبدأ التصميم من مهمة محددة ومصادر واضحة وتقييم متكرر وحدود تحمي البيانات والميزانية وتجربة المستخدم.
ما ستخرج به من المقال
- اختيار مهمة ومعيار نجاح واضح.
- استرجاع مصادر موثوقة عبر RAG عند الحاجة.
- حماية الأسرار وقياس الجودة والتكلفة.
ابدأ بالمشكلة وليس باسم النموذج
حدد ما يحتاج المستخدم إنجازه: تلخيص مستند، بحث في دليل، تصنيف طلب أو اقتراح صياغة. عرّف النتيجة المقبولة والأخطاء غير المقبولة، وحدد متى يجب رفض الإجابة أو إحالة المستخدم إلى مصدر. أحيانًا تكون قاعدة أو عملية بحث تقليدية أبسط وأدق من نموذج لغوي. اختبر عينة تمثل اللغة والسياق الحقيقيين، بما فيها الأسئلة الغامضة والطلبات خارج النطاق، وقارن الأداء بخط أساس واضح.
ما هو RAG ولماذا لا يضمن الحقيقة؟
Retrieval-Augmented Generation يجلب مقاطع من مصادر محددة ثم يمررها إلى النموذج كسياق. يفيد مع الوثائق المتغيرة دون تدريب جديد لكل تحديث، لكن جودة الإجابة تعتمد على جودة الفهرسة والاسترجاع وترتيب المقاطع وقدرة النموذج على استخدامها. قِس الاسترجاع منفصلًا عن جودة الصياغة، واحتفظ بالمصدر والصفحة أو الرابط، واطلب توضيح نقص الدليل بدل ملء الفراغ بثقة زائفة.
تعامل مع المستندات كمدخل غير موثوق
قد يحتوي مستند مسترجع أو سؤال المستخدم على prompt injection يحاول تغيير سلوك النموذج أو كشف بيانات. لا يكفي وضع تعليمات في prompt لحل ذلك. اجعل صلاحيات الأدوات محدودة وافصل البيانات المسترجعة عن سياسات النظام قدر الإمكان. لا تمنح النموذج صلاحية عمليات حساسة لأن نصه يبدو مقنعًا؛ الخادم هو من يفرض الصلاحيات والتحقق، والعمليات المهمة تحتاج تأكيدًا بشريًا أو ضوابط مستقلة.
الخصوصية والتكلفة والتقييم
أرسل البيانات اللازمة فقط، وحدد ما يجوز إرساله إلى مزود النموذج وفق سياسات الخصوصية والعقد، ولا تضع API keys في JavaScript الذي يصل إلى المتصفح. راقب طول المدخلات والمخرجات وزمن الاستجابة والفشل والتكلفة لكل عملية، وضع حدودًا للطلب ومهلة وإعادة محاولة مضبوطة. ابنِ مجموعة اختبار ثابتة تشمل أسئلة مرجعية وطلبات خارج النطاق ومحتوى متعارضًا؛ وبعد تغيير النموذج أو prompt أو الاسترجاع قارن النتائج وراجع عينات بشرية.
هيكل مبسّط لتدفق RAG
async function answerQuestion(question, user) {
const docs = await getDocumentsUserCanRead(user);
const passages = await retrieveRelevantPassages(question, docs);
if (!passages.length) return { answer: "لا يوجد دليل كافٍ.", sources: [] };
const result = await generateGroundedAnswer({
question, passages: passages.map(p => p.text)
});
return { answer: result.answer, sources: passages.map(p => p.source) };
}
عامل المستندات والاسترجاع كحدود ثقة
في RAG، يجلب التطبيق مقاطع من مستندات ثم يضعها في سياق النموذج كي يصيغ إجابة مرتبطة بالمصدر. هذا قد يقلل الحاجة إلى الاعتماد على المعرفة المخزنة في النموذج، لكنه لا يضمن الحقيقة؛ فقد يسترجع النظام مقاطع غير ذات صلة أو قد يسيء النموذج فهمها أو يضيف ادعاء غير مدعوم.
افصل صلاحيات الوصول عن جودة الاسترجاع. يجب ألا يدخل مستند لا يملك المستخدم صلاحية قراءته إلى السياق لمجرد أن embedding قريب من السؤال. طبّق التصفية وفق أذونات المصدر قبل أو أثناء الاسترجاع، وسجّل معرفات المستندات المسترجعة لتسهيل التدقيق دون تسريب محتواها إلى سجلات غير مناسبة.
دراسة حالة مفصلة: من العرض إلى السبب الجذري
الحالة العملية هنا هي: يعطي نظام RAG إجابة واثقة لكنه استرجع وثيقة قديمة أو غير مسموح للمستخدم بقراءتها. لا يكفي أن نصلح العَرَض الظاهر؛ ينبغي رسم مسار البيانات أو الطلب من بدايته حتى النتيجة، ومعرفة أين نشأ الاختلاف. ابدأ بتسجيل ما حدث، وما المتوقع أن يحدث، والخطوة التي يمكن إثباتها بالقياس أو السجل أو الاختبار. بعد ذلك غيّر عاملًا واحدًا واضحًا، ثم أعد السيناريو نفسه للتحقق من أن السبب الجذري عولج. إذا تغيرت عدة مكونات دفعة واحدة، فسيصعب معرفة أيها أحدث الفرق.
اربط نتيجة الحالة بمبدأ المقال: ابدأ بالمشكلة وليس باسم النموذج وما هو RAG ولماذا لا يضمن الحقيقة؟. هذان المفهومان يحددان ما الذي يجب فحصه أولًا وما الذي يمكن تأجيله. سجّل أيضًا الحالات التي لم تختبرها، حتى لا يتحول نجاح سيناريو واحد إلى ادعاء بأن النظام كله خالٍ من المشكلة.
خط أنابيب البيانات أهم من اسم النموذج
تمر منظومة RAG عادةً باستخراج النص وتنظيفه وتقسيمه وإضافة metadata وفهرسته، ثم استرجاع المقاطع وربما إعادة ترتيبها، ثم بناء السياق وإنتاج الإجابة والتحقق منها. الخلل في أي مرحلة ينعكس على النتيجة؛ تقسيم سيئ قد يفصل عنوانًا عن إجابته، وmetadata ناقصة تمنع الفلترة، واسترجاع واسع يضيف ضوضاء إلى السياق.
اختر طول المقاطع والتداخل بالاختبار على مستنداتك الفعلية، لا برقم عام ثابت. المقاطع القصيرة قد تفقد السياق، والطويلة قد تدخل نصًا غير لازم وتتجاوز حدود السياق أو تزيد الكلفة. احتفظ بإصدار للفهرس وسياسة لإعادة بنائه عند تغير المستندات أو نموذج embeddings.
من المثال إلى التنفيذ في مشروع حقيقي
ابدأ من المثال البرمجي المعروض في المقال: «هيكل مبسّط لتدفق RAG». لا تنقله حرفيًا إلى الإنتاج قبل أن تحدد مدخلاته ومخرجاته وافتراضاته. اسأل ما الذي يحدث عند غياب قيمة، أو وصول بيانات غير متوقعة، أو تكرار الطلب، أو تأخر الاعتماد الخارجي. بعد ذلك نفّذ نسخة صغيرة داخل فرع مستقل وأضف اختبارًا للحالة الأساسية وآخر لحالة فشل.
استخدم هذه الخطوات كبداية: حدد المهمة ومعيار النجاح وخط الأساس. ثم افصل استرجاع المصادر عن توليد الإجابة. ثم طبق صلاحيات الوصول قبل الاسترجاع وعلى الأدوات.. اجعل كل خطوة قابلة للمراجعة، ولا تجمع إعدادات المشروع الحقيقية والأسرار داخل مثال تعليمي. إذا اختلفت بيئتك عن المثال، وثّق الاختلاف وعدّل التنفيذ بناءً على التوثيق الرسمي بدل نسخ الحل دون فهم.
قيّم الاسترجاع والإجابة كلًا على حدة
عندما تكون الإجابة غير صحيحة، اسأل أولًا هل المقاطع اللازمة كانت ضمن النتائج؟ إن لم تكن، فالمشكلة في الاسترجاع أو التقسيم أو الفهرسة. وإذا كانت موجودة لكن النموذج تجاهلها، فافحص صياغة التعليمات وترتيب المقاطع وحدود السياق. هذا الفصل يمنع تغيير النموذج لحل مشكلة مصدرها البيانات.
كوّن مجموعة تقييم تمثل أسئلة حقيقية مع المصادر والإجابة المتوقعة أو معايير قبول واضحة. قس جودة الاسترجاع ودقة الاستشهادات والامتناع عند نقص الدليل وزمن الاستجابة والكلفة. لا تكتفِ بتجربة بعض الأسئلة التي يعرفها المطور؛ قد تخفي هذه التجربة إخفاقات شائعة في أسماء أو تواريخ أو مستندات متضاربة.
أسلوب تشخيص منهجي عند الفشل
عندما لا يعمل الحل، لا تبدأ بإضافة شرط آخر قبل تحديد دليل الفشل. دوّن المدخل، والنتيجة المتوقعة، والنتيجة الفعلية، والرسالة أو القياس الذي يدعم الاستنتاج. من الأخطاء المتكررة في هذا الموضوع: افتراض أن RAG يمنع الهلوسة بالكامل.. تعامل مع هذه النقطة كفرضية للفحص، لا كتشخيص مسبق؛ فقد يكون سبب المشكلة في طبقة مجاورة أو في افتراض غير صحيح بالاختبار.
قسّم النظام إلى حدود واضحة: مدخلات، ومعالجة، واعتماد خارجي، ونتيجة. اختبر كل حد على حدة قدر الإمكان، ثم نفّذ سيناريو متكاملًا. إذا أصلحت المشكلة، أضف اختبارًا يمنع رجوعها أو ملاحظة تشغيلية تساعد على كشفها مبكرًا. الهدف أن يصبح التشخيص قابلًا للتكرار من عضو آخر بالفريق، لا أن يظل مرتبطًا بذاكرة الشخص الذي اكتشف العطل.
حقن التعليمات والخصوصية والتكلفة
النص المسترجع بيانات غير موثوقة، حتى لو جاء من ملف داخلي؛ قد يحتوي تعليمات تحاول توجيه النموذج لتجاوز المطلوب. افصل تعليمات النظام عن المحتوى، ولا تمنح النموذج صلاحيات تنفيذية غير محدودة بناءً على نص مسترجع. إذا كان النموذج يستطيع استدعاء أدوات، فطبّق التفويض في التطبيق قبل كل عملية، لا اعتمادًا على طلب النموذج وحده.
راجع ما يرسل إلى مزود النموذج، وفترات الاحتفاظ، وتصفية المعلومات الشخصية، وتكلفة التضمينات والاسترجاع والإجابة. ضع حدًا لطول الطلب وعدد المستندات، وتحقق من مصادر الإجابة قبل عرضها في المجالات الحساسة. وضّح للمستخدم أن الاستشهاد يساعد على المراجعة لكنه لا يعادل ضمانًا بأن كل صياغة صحيحة.
اعتبارات متقدمة قبل اعتماد الحل
في المشروع الحقيقي، لا يُقيّم الحل على نجاح الحالة السعيدة فقط. راجع السلوك عند الحمل، وحالات الفشل، والتغييرات المستقبلية، والحدود الأمنية ذات الصلة. من المهم هنا أن تحقق من أذونات المستندات والاستشهادات والامتناع عند نقص الأدلة، ولا تمنح النموذج صلاحيات تنفيذية اعتمادًا على نص مسترجع. لا تُعامل هذه النقاط كملحق لاحق؛ فقرار التصميم قد يصعب تغييره عندما تتراكم البيانات أو يعتمد عليه عملاء متعددون.
حدّد مقاييس أو اختبارات قبول قبل الدمج، ودوّن حدود الحل بوضوح. قد يكون الحل مناسبًا لموقع صغير لكنه يحتاج طابورًا أو cache أو بنية أكثر صرامة عند نمو الاستخدام. لا تضف تعقيدًا مسبقًا بلا دليل، لكن لا تتجاهل علامة واضحة على أن المتطلبات تتجاوز النسخة البسيطة. القرار الجيد يوازن البساطة الحالية مع كلفة التغيير المتوقعة ويحافظ على وضوح النظام للفريق.
خطة إطلاق تدريجية لميزة ذكاء اصطناعي
ابدأ بحالة استخدام ضيقة يمكن تقييمها، مثل البحث داخل دليل مساعدة، ولا تبدأ بمساعد واسع الصلاحيات يجيب عن أي شيء. حدد الحالات التي يجب أن يجيب عنها، والحالات التي يجب أن يصرح فيها بعدم كفاية الأدلة، وحدود زمن الاستجابة والكلفة. اختبر على مجموعة محفوظة، ثم نفّذ تجربة بشرية قبل توسيع الوصول.
أثناء الإطلاق، راقب نسبة الإجابات المدعومة بالمصادر، والاسترجاع الفاشل، ومعدل امتناع النموذج، وشكاوى المستخدمين، والكلفة لكل مهمة ناجحة. اجمع التغذية الراجعة بطريقة لا تحفظ بيانات حساسة دون حاجة، واستخدم الإخفاقات لإصلاح البيانات أو الاسترجاع أو التعليمات بحسب السبب المحدد.
تطبيق عملي ومعايير قبول
جرّب هذا التمرين على مشروع تجريبي أو فرع منفصل: كوّن خمس أسئلة تقييم مع مصادرها واختبر سؤالًا بلا دليل ومستندًا غير مصرح به. اكتب النتيجة التي تتوقعها قبل التنفيذ، وسجّل ما حدث بالفعل، ثم أصلح الفرق إن ظهر. جرّب كذلك حالة حدودية أو فشلًا مقصودًا بصورة آمنة. لا تستخدم بيانات حقيقية أو نظامًا إنتاجيًا لإحداث فشل تجريبي.
اعتبر المهمة مكتملة عندما تكون خطوات إعادة التجربة موثقة، والاختبار يثبت السلوك الأساسي وحالة الفشل، ولا توجد أسرار أو معلومات حساسة في السجل، ويستطيع مطور آخر فهم سبب الحل. إذا لم يتحقق هذا، فالمطلوب ليس إضافة مزيد من الكود مباشرة؛ أعد صياغة المشكلة ووضح الافتراض الذي لم يكن صحيحًا. هذه الطريقة تجعل المقال نقطة انطلاق لممارسة تقنية، لا مجرد قراءة نظرية.
أسئلة شائعة عن RAG والذكاء الاصطناعي
هل RAG يمنع الهلوسة تمامًا؟ لا؛ يقلل بعض المخاطر لكنه لا يضمن استخدام الأدلة بصورة صحيحة.
هل يمكن للوثيقة المسترجعة توجيه النموذج؟ نعم، لذلك يجب التعامل معها كمحتوى غير موثوق وتقييد استخدام الأدوات.
ما معيار النجاح؟ تقييم مستقل لجودة الإجابة والاستشهادات والاسترجاع والخصوصية والكلفة، وليس الانطباع من محادثة واحدة.
خطة تطبيق عملية
- حدد المهمة ومعيار النجاح وخط الأساس.
- افصل استرجاع المصادر عن توليد الإجابة.
- طبق صلاحيات الوصول قبل الاسترجاع وعلى الأدوات.
- ضع حدودًا للاستخدام والبيانات والتكلفة.
- قيّم النتائج على مجموعة ثابتة وراجع عينات بشرية.
أخطاء شائعة انتبه لها
- افتراض أن RAG يمنع الهلوسة بالكامل.
- إرسال بيانات حساسة بلا مراجعة.
- السماح للنموذج بتنفيذ عمليات حساسة دون تحقق خادمي.
الخلاصة
ميزة AI موثوقة ليست prompt جيدًا فقط؛ إنها نظام يجمع مهمة محددة ومصادر واضحة وصلاحيات محدودة وتقييمًا مستمرًا. قس الاسترجاع والتوليد منفصلين، وراقب التكلفة والخصوصية، واجعل رفض الإجابة عند نقص الدليل سلوكًا مقبولًا.