إنه اليوم الثالث من مشروع تعاون مع شركة وساطة تأمين متوسطة الحجم، ويطلب مدير عمليات المطالبات أداة محادثة قادرة على تقديم إجابات سريعة لمسؤولي تسوية المطالبات. إنهم يريدون من الأداة اقتباس أحدث قواعد وثيقة التأمين، وشرح الاستثناءات، والإشارة إلى الصفحة المحددة في الدليل الصحيح. وفي الاجتماع نفسه، يضيف القسم القانوني قيداً آخر: يجب ألا تعرض الأداة أبداً محتوى من عقد عميل ما لم يكن مسؤول التسوية مكلفاً بذلك الحساب تحديداً.
هنا تبرز أهمية تقنية التوليد المعزز بالاسترجاع (RAG) المخصصة للعميل في سياق العمل الميداني المباشر (FDE). تعتمد هذه التقنية المخصصة للعميل على آلية يقوم فيها نظام الذكاء الاصطناعي بالإجابة عن طريق استخلاص الحقائق أولاً من مصادر العميل نفسه، ثم صياغة الرد باستخدام تلك الحقائق. وتُعد هذه التقنية “مخصصة للعميل” لأن المصادر تتغير بمرور الوقت، ولأن العميل -وليس نحن- هو من يحدد ما يُعتبر إجابة مقبولة.
من الناحية العملية، نحن لا نقدم مجرد “روبوت محادثة” (chatbot) عام، بل نقدم سير عمل لتوليد الإجابات مرتبطاً بوثائق حقيقية، وصلاحيات وصول فعلية، ونتائج أعمال ملموسة. بالنسبة لشركة الوساطة، تعني كلمة “صحيح” أن الإجابة تتوافق مع الإصدار الحالي للدليل وتقتبس منه، وتحترم قواعد الوصول على مستوى الحساب حتى عندما يكون السؤال غامضاً.
تتمثل الخطوة الجوهرية في نهج FDE في التعامل مع تقنية RAG كنظام متكامل (من البداية إلى النهاية) وليس مجرد ميزة برمجية. فإذا اقتصر تفكيرنا على صياغة الأوامر (prompts) الموجهة للنموذج، فإننا نغفل الجوانب التي تضمن أمان النظام وموثوقيته في بيئة التشغيل الفعلية. سيستمر باقي هذا الدرس في التركيز على حالة شركة الوساطة هذه، لأن كل قرار تتخذه سينعكس مباشرة على ما يراه مسؤول تسوية المطالبات في اللحظة التي يحتاج فيها إلى إجابة.
نادراً ما تكون حالات الفشل في أنظمة RAG أثناء التشغيل الفعلي درامية أو صارخة؛ فهي عادة ما تكون هادئة ومقنعة (تبدو صحيحة) ومكلفة في آن واحد. يتلقى مسؤول التسوية إجابة تبدو سليمة ويتصرف بناءً عليها، ولا يكتشف أحد إلا لاحقاً أن المطالبة عولجت وفقاً لقاعدة خاطئة.
لنتأمل هذا السيناريو: تقوم شركة الوساطة بتحميل نشرة جديدة حول “استثناءات أضرار المياه” يوم الاثنين. وبحلول يوم الأربعاء، تظل أداة المحادثة تجيب استناداً إلى دليل الشهر الماضي لأن مسار معالجة المحتوى لم يقم بإعادة استيعاب الملف الجديد. لا يظهر أي خطأ تقني، وقد يشير النظام حتى إلى رقم صفحة حقيقي؛ لكنه ببساطة رقم الصفحة الخطأ بالنسبة لمجموعة القواعد الحالية.
ثمة خلل شائع آخر يتعلق بحدود صلاحيات الوصول؛ فإذا كانت مرحلة الاسترجاع قادرة على الوصول إلى وثيقة ما، فقد ينتهي الأمر بنظام الذكاء الاصطناعي إلى تلخيصها، حتى وإن لم يكن من المفترض أن يطلع عليها المستخدم النهائي. ولهذا السبب، لا تُعد إدارة الصلاحيات مجرد تفصيل يتعلق بواجهة المستخدم في أنظمة RAG. تُعد هذه العناصر جزءاً من تصميم عملية الاسترجاع، ويجب تطبيقها قبل تمرير أي نص إلى النموذج.
وتُشكل حالات “الإخفاق الصامت” (Silent misses) خطراً جسيماً آخر؛ إذ قد يتطلب سؤال مثل “هل يمكننا التغاضي عن إجراء الفحص إذا كانت قيمة الضرر أقل من 2000؟” الرجوع إلى بند استثناء محدد. فإذا فشلت عملية الاسترجاع في العثور على هذا البند، غالباً ما سيحاول النموذج تقديم المساعدة على أي حال، فيسد الفجوة بمعلومة أو قاعدة تبدو عامة. ودون وجود آليات للقياس، لن تلاحظ هذا الانحراف في الأداء إلا بعد أن تبدأ جهة العمل في تقديم الشكاوى.
استكشف الطرق الرئيسية التي ترتبط بها حالات الفشل هذه بتأثيرها على الأعمال.
افترض حدوث انحراف في الأداء، وأثبت جودته إذا لم تكن تتابع مستوى الجودة بمرور الوقت، فاعلم أن الجودة تتغير بالفعل دون أن تدرك ذلك بعد.
تُمهّد أنماط الفشل هذه الطريق للسؤال الجوهري المتعلق بـ FDE (هندسة البيانات الموجهة للنماذج): ما هي القرارات التي نحتاج لاتخاذها، وبأي ترتيب، لضمان بقاء النظام دقيقاً وصحيحاً مع تغير المستندات والمستخدمين وقواعد العمل؟
تُعد مشاريع RAG (التوليد المعزز بالاسترجاع) المخصصة لعميل معين بمثابة سلسلة من القرارات، حيث تؤثر كل حلقة في السلسلة على ما يمكن للحلقة التالية القيام به بأمان. فإذا قفزنا مباشرة إلى مرحلة “التضمينات” (embeddings) أو تحديد أحجام أجزاء النصوص (chunk sizes)، سنجد أنفسنا مضطرين لإعادة كتابة النظام لاحقاً عند ظهور قاعدة عمل كان ينبغي اعتبارها متطلباً أساسياً منذ البداية.
ابدأ بمتطلبات محددة بما يكفي لإجراء الاختبارات عليها. بالنسبة لشركة الوساطة، نضع معايير قبول مثل “يجب الاستشهاد بالقسم الدقيق من الدليل الإرشادي” و"يجب رفض الطلب إذا لم يكن المستخدم يملك صلاحية الوصول". هذه ليست أهدافاً غامضة، بل هي فحوصات تعتمد على مبدأ “النجاح أو الفشل” ويمكن تحويلها إلى مجموعة بيانات للتقييم.
تأتي البيانات في المرحلة التالية؛ حيث نحدد المصادر التي ستغذي عملية الاسترجاع وكيفية تغيرها (مثل الأدلة الإرشادية في SharePoint، والنشرات المرسلة عبر البريد الإلكتروني، وعقود الحسابات المستخرجة من نظام CRM). كما نحدد صلاحيات الوصول (من يحق له رؤية ماذا)، لأن نموذج الصلاحيات هذا سيحدد كيفية عمل الفهرسة والتصفية أثناء الاستعلام.
بعد ذلك يأتي تصميم عملية الاسترجاع. تشير عملية الاسترجاع إلى كيفية اختيار النظام لأجزاء المستندات التي سيتم عرضها على النموذج. ويتمثل القرار الأهم هنا في تحديد ما إذا كان بإمكاننا التصفية بناءً على الصلاحيات وقت الاستعلام، أم أننا بحاجة إلى فهارس منفصلة لكل قطاع لتجنب تسرب المعلومات. في حالة شركة الوساطة، غالباً ما تدفع عقود الحسابات نحو تطبيق تصفية صارمة، لأن خطأً واحداً قد يؤدي إلى حادثة جسيمة.
تُعد عملية “التأصيل” (Grounding) الإجراء الذي نتبعه لضمان ارتباط النموذج بالنص المسترجع. وعادةً ما تتضمن قواعد مثل “أجب فقط بناءً على السياق المقدم” و"أدرج المراجع أو الاستشهادات". كما تشمل تحديد تصرف النظام عند غياب السياق، مثل طرح سؤال توضيحي أو الرد بعبارة “لا يمكنني العثور على ذلك في وثائق السياسة الحالية”.
التقييم هو المرحلة التي نجعل فيها الموثوقية قابلة للقياس. وتتمثل عملية التقييم في مجموعة قابلة للتكرار من أسئلة الاختبار ذات النتائج المتوقعة، والتي يتم تشغيلها قبل التغييرات وبعدها. وبالنسبة لشركة الوساطة هذه، فإننا نركز على دقة الاستشهاد بالمصادر، وصحة قرارات الرفض المتعلقة بالمستندات المقيدة، ومدى تغطية النظام لسيناريوهات المطالبات عالية المخاطر.
تحوّل قرارات النشر كل ما سبق إلى نظام تشغيل فعلي؛ حيث نحدد كيفية عمل استيعاب البيانات، ومعدل تحديث الفهارس، وآلية تسجيل الطلبات بأمان، وطريقة طرح التحديثات. وتصبح عملية التطوير التكراري (Iteration) بمثابة حلقة عمل محكومة بضوابط وقائية؛ فعندما يبلغ مسؤولو تسوية المطالبات عن خطأ أو قصور، نحدد ما إذا كان السبب خللاً في البيانات، أو في عملية الاسترجاع، أو في التعليمات الموجهة للنموذج، ومن ثم نقوم بمعالجة الخلل في الطبقة المناسبة.
انظر إلى المراحل باعتبارها نظاماً مترابطاً من الخيارات.