تحديد نطاق مشروع RAG أو مساعد ذكاء اصطناعي: قائمة تحقق

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

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

1. حالة الاستخدام ومعايير النجاح#

اكتب هذه قبل أن يفتح أحد دفتر ملاحظات أو يقارن النماذج.

• مهمة رئيسية واحدة. سمِّ المهمة الوحيدة التي يجب أن يجيدها المساعد أولاً، مثل الإجابة عن أسئلة وكلاء الدعم عن المنتجات أو العثور على بنود في عقود الموردين. يمكن لحالات استخدام أخرى أن تتبع بعد قياس الأولى؛ فخلط عدة حالات في البداية يشوّش المتطلبات والتقييم معاً.
• المستخدمون ووضعهم. صِف من يسأل، وكم مرة، وبأي لغة وعلى أي جهاز، وماذا يفعلون بالإجابة. خبير داخلي يتحقق من المصادر يحتاج شيئاً مختلفاً عن عميل يتصرف بناءً على الإجابة مباشرةً.
• أسئلة حقيقية بإجابات مثالية. اجمع 20–50 سؤالاً حقيقياً من التذاكر أو البريد الإلكتروني أو سجلات المحادثة، واجعل خبير مجال يكتب الإجابة المثالية ويسمّي المصدر الذي يجب أن تأتي منه. تحدد هذه المجموعة ما يعنيه «جيد» وتصبح بذرة مجموعة التقييم لديك.
• خارج النطاق وحالات الرفض. عدّد ما يجب ألا يفعله المساعد: تقديم استشارات قانونية أو طبية أو مالية، أو الإجابة خارج مصادره، أو تقديم التزامات نيابة عن الشركة. قرّر ماذا يجب أن يقول بدلاً من ذلك وأين يوجّه المستخدم.
• خط الأساس للعملية الحالية. سجّل كيف تُنجَز المهمة اليوم، وكم تستغرق، ومن يؤديها، وكم تكلّف. دون خط أساس، فإن «المساعد يساعد» رأي لا نتيجة.

2. مصادر البيانات#

جودة الإجابات محدودة بجودة المحتوى خلفها وإمكانية الوصول إليه.

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

3. التحكم في الوصول والخصوصية#

احسم هذه قبل أن تغادر أي بيانات حقيقية أنظمتك.

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

4. تصميم الاسترجاع#

معظم الإجابات الخاطئة في أنظمة RAG تعود إلى الاسترجاع لا إلى النموذج؛ وبالنسبة لمجموعة نصية صغيرة وثابتة، قد يحل السياق الطويل مع التخزين المؤقت للموجّهات محل الاسترجاع كلياً (انظر RAG أم fine-tuning).

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

5. اختيار النموذج والمزود#

اختر النموذج بعد أن يكون لديك مجموعة تقييم، حتى يستند القرار إلى بياناتك لا إلى معايير عامة.

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

6. التقييم#

إذا لم تستطع قياس الجودة، فلن تستطيع تحسينها ولا الدفاع عن قرار الإطلاق.

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

7. التكامل والتشغيل#

يجب أن يعيش المساعد في مكان ما، وعلى أحد أن يشغّله بعد الإطلاق.

• القناة وتسجيل الدخول. قرّر أين يعيش المساعد: أداة موقع ويب، أو Slack أو Microsoft Teams، أو أداة داخلية، أو نظام تذاكر قائم. استخدم SSO القائم لديك حتى تأتي الهوية والصلاحيات من المكان نفسه كما في كل مكان آخر.
• التسليم البشري والتغذية الراجعة. حدّد كيف يصل المستخدم إلى شخص عندما يعجز المساعد عن المساعدة، مع تمرير المحادثة. أضف أزرار تغذية راجعة بسيطة ووجّه التغذية السلبية إلى مجموعة التقييم.
• نموذج التكلفة والمراقبة. قدّر التكلفة لكل استعلام ولكل شهر عند الاستخدام المتوقع والذروة، واضبط تنبيهات الميزانية. راقب زمن الاستجابة ومعدلات الخطأ ومعدلات الرفض وتغذية المستخدمين، مع سجلات منقَّحة كما اتُّفق في القسم 3.
• إعادة الفهرسة وملكية المحتوى والحوادث. أتمت إعادة الفهرسة عند تغيّر المستندات المصدرية، بما فيها الحذف، حتى لا يقتبس المساعد محتوى مسحوباً أبداً. سمِّ من يصلح مشكلات المحتوى وعرّف عملية حوادث للإجابات الخاطئة أو الضارة أو المسرَّبة، بما فيها كيفية إطفاء المساعد بسرعة.

8. معايير البدء أو الإيقاف#

اتفق على قواعد القرار قبل وصول النتائج، حتى لا يُتخذ القرار بقوة عرض جيد.

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

كيف يمكننا المساعدة#

إذا أردت العمل على هذه القائمة معنا، فالطريق الأكثر مباشرةً هو برنامجنا محدد النطاق AI Proof-of-Value Sprint. في أسبوعين نحدّد معك حالة الاستخدام، ونبني نموذجاً أولياً RAG أو وكيلاً على بياناتك، وننشئ مجموعة تقييم، ونُعدّ نموذج تكلفة، ونسلّم تقرير بدء/إيقاف يمكنك تقديمه لصنّاع القرار. التفاصيل على صفحة الأسعار وفي خدمات الذكاء الاصطناعي والأتمتة.

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