لماذا تفشل حواجز حماية الموجّه (Prompt Guardrails) في بيئة الإنتاج، وما الذي يفعله فحص المخرجات بدلاً من ذلك

إذا كان وكيل (agent) خدمة العملاء الخاص بك يعتمد على تعليمات مثل "لا تناقش المنافسين أبدًا" أو "قم دائمًا بتضمين إخلاء المسؤولية هذا" الموجودة داخل موجّه النظام (system prompt)، فأنت على بُعد محادثة طويلة واحدة من وقوع كارثة. القواعد على مستوى الموجّه (prompt) هي مجرد اقتراحات لنموذج احتمالي، وليست تطبيقًا إلزاميًا. إنها تنجح في العروض التوضيحية (demos) لأنها قصيرة. أما في بيئة الإنتاج (production)، حيث تمتد المحادثات لعشرين جولة، وتُرجع الأدوات بيانات غير متوقعة، ويسأل المستخدمون نفس الشيء بست طرق مختلفة، فإن انتباه النموذج (model) لهذه القواعد يتدهور. الحل ليس في كتابة موجّه أفضل. بل في فحص يعمل بعد أن يُصدر النموذج استجابته وقبل أن يراها المستخدم.

ما هو "حاجز حماية الموجّه" (prompt guardrail) فعليًا، ولماذا تلجأ إليه الفِرق

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

ينجح الأمر في أول مائة اختبار يدوي. ثم يصطدم بالواقع في بيئة الإنتاج.

الآليات الأربع التي تكسر حواجز حماية الموجّه

1. تدهور الانتباه (Attention decay) عبر السياق الطويل

انتباه النموذج عبر نافذة السياق (context window) ليس متساويًا. تتنافس التعليمات الموجودة في بداية محادثة طويلة مع كل ما يأتي بعدها: رسائل المستخدم، مخرجات الأدوات، المستندات المسترجعة (retrieved)، وردود المساعد السابقة. بحلول الجولة الخامسة عشرة من دردشة الدعم، تصبح قاعدة "لا تعد أبدًا باسترداد الأموال" مجرد سطر مدفون تحت عشرة آلاف توكن (token) من ضوضاء المحادثة. النموذج لم ينسها بالمعنى الحرفي. بل قلل من أولويتها، وهو ما يبدو متطابقًا من الخارج عندما تكسر المخرجات السياسة المحددة.

هذه خاصية من خصائص الانتباه في بنية المحولات (transformer attention) في ظل السياق الطويل، وليست عيبًا في عائلة نماذج معينة. نوافذ السياق الأكبر تقلل من عدد مرات الاقتطاع (truncation). لكنها لا تجعل التعليمات الموجودة في منتصف السياق بارزة مثل النص الأخير للمستخدم.

2. تعارض التعليمات مع صياغة المستخدم

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

3. مخرجات الأدوات كتسريب للثقة

يستدعي الوكيل (agent) الأدوات. تُرجع الأدوات نصوصًا. يدخل هذا النص في السياق وكأنه حقيقة مطلقة (ground truth). إذا كان هناك مستند في قاعدة المعرفة الخاصة بك يحتوي على مقارنة مع المنافسين، وكانت قاعدتك تنص على "لا تذكر المنافسين"، فغالبًا ما سيقوم النموذج بتلخيص ما تم استرجاعه (retrieval) للتو على أي حال، لأن المحتوى المسترجع يُقرأ وكأنه مقترن بالتعليمات. هذه هي الآلية وراء معظم حوادث "البوت قال شيئًا قيل له ألا يقوله أبدًا" في أنظمة RAG في بيئة الإنتاج.

4. الحالات الطرفية (Edge cases) التي لم يتخيلها كاتب الموجّه

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

ما يفعله فحص المخرجات (output check) بدلاً من ذلك

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

• ▸قاعدة حتمية (deterministic rule)، مثل تعبير نمطي (regex) يحظر أرقام الهواتف، أو المبالغ بالدولار، أو أسماء منتجات معينة.
• ▸مُصنّف (classifier)، مثل نموذج صغير تم تدريبه لاكتشاف الادعاءات الطبية، أو وعود استرداد الأموال، أو المحتوى التشهيري.
• ▸استدعاء ثانٍ لنموذج LLM مع موجّه ضيق ومخصص لغرض واحد: "هل تعد هذه الاستجابة باسترداد الأموال؟ نعم أو لا."
• ▸مدقق للمخطط (schema validator)، إذا كانت الاستجابة مهيكلة (structured).

يُرجع الفحص واحدًا من ثلاثة أحكام: تمرير (pass)، أو حظر (block)، أو تصعيد (escalate). عند التمرير، تذهب الاستجابة إلى المستخدم. وعند الحظر، يتم استبدال الاستجابة برد بديل آمن (fallback). وعند التصعيد، يتم احتجاز الاستجابة لمراجعة بشرية.

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

حسابات توضيحية للتكلفة

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

افترض وجود 50,000 رسالة عميل يوميًا. لنفترض أن استدعاء التوليد الرئيسي يبلغ في المتوسط 2,000 توكن إدخال و 300 توكن إخراج. ولنفترض أن فحص المخرجات هو استدعاء ثانٍ بـ 400 توكن إدخال (موجّه سياسة قصير بالإضافة إلى الاستجابة) و 10 توكنات إخراج (الحكم بالإضافة إلى كود السبب).

التوكنات اليومية للفحص: 50,000 × 410 = 20.5 مليون توكن. بتسعير النماذج الصغيرة، هذا بند يُقاس بعشرات الدولارات المنخفضة يوميًا، وليس بالآلاف. الرقم الدقيق يعتمد على مزود الخدمة الخاص بك؛ لكن شكل الحسابات لا يتغير. حادثة واحدة يتم منعها، سواء كانت تعرضًا تنظيميًا أو لقطة شاشة عامة محرجة، تدفع تكلفة عام كامل من الفحوصات.

شكل البنية المعمارية التي تصمد

الوكيل (agent) في بيئة الإنتاج الذي يجتاز تدقيقًا كفؤًا يميل إلى أن يبدو هكذا:

1. ▸مُصنّف النوايا (Intent classifier) على الرسالة الواردة. رخيص، سريع، ويوجّه الطلب إلى المعالج المناسب.
2. ▸مُولّد مدرك للسياسات (Policy-aware generator) مع موجّه نظام يُحفظ قصيرًا بما يكفي لتسهيل إدارة تدهور الانتباه. الموجّه يعلن عن النية، وليس التطبيق الإلزامي.
3. ▸فحص المخرجات (Output check) بين المُولّد والمستخدم. القواعد الحتمية أولاً لأنها فورية وقابلة للتدقيق. ثم مُصنّف أو فحص LLM ضيق لأي شيء لا تستطيع القواعد الحتمية رؤيته.
4. ▸استجابة بديلة (Fallback response) عند الحظر. رسالة بسيطة ومعتمدة مسبقًا توضح ما لا يمكن للوكيل القيام به وتقدم مسارًا للتواصل مع إنسان.
5. ▸طابور تصعيد (Escalation queue) لأي شيء يضع عليه الفحص علامة عدم اليقين. يقوم إنسان بالمراجعة، أو الموافقة، أو إعادة الكتابة، ويتم تسجيل القرار.
6. ▸سجل القرارات (Decision log) لكل إدخال، وكل استدعاء لأداة، وكل إخراج، وكل حكم، وكل كود سبب. مطلوب لعمليات التدقيق، وضروري لتصحيح الأخطاء (debugging).

تم بناء Verel Coordinator على هذا النمط. بوابة الامتثال هي فحص المخرجات، وليست الموجّه.

ما الذي يجب التحقق منه أولاً

إذا كنت تقوم بتحديث وكيل (agent) حالي، فابدأ بالفحوصات التي تغطي أنماط الفشل الأكثر تأثيرًا لديك:

• ▸الوعود التي لا يمكنك الوفاء بها: استرداد الأموال، تواريخ التسليم، تمديد الضمان، التسعير.
• ▸الادعاءات الخاضعة للتنظيم: النصائح الطبية، والقانونية، والمالية، خاصة في الولايات القضائية التي تفرض متطلبات إفصاح محددة.
• ▸ذكر المنافسين والمقارنات، إذا كانت فرق المبيعات والشؤون القانونية لديك تهتم بذلك.
• ▸تسريب معلومات التعريف الشخصية (PII): أرقام الهواتف، عناوين البريد الإلكتروني، معرفات الحسابات التي تظهر في مخرجات لا ينبغي أن تتضمنها.
• ▸بصمات كسر الحماية (Jailbreak signatures): صياغات لعب الأدوار (role-play)، "تجاهل التعليمات السابقة"، وحمولات base64 في رسائل المستخدم. هذه تمثل فحصًا على الإدخال، لكن الاقتران بينهما مهم.

يمكن أن يكون كل من هذه الفحوصات مزيجًا من التعبيرات النمطية (regex) وتصنيف النماذج الصغيرة. لا تحتاج إلى نموذج متقدم (frontier model) لاكتشاف علامة الدولار في استجابة من بوت ممنوع من ذكر الأسعار.

ما لا يصلحه هذا الحل

فحص المخرجات ليس كاشفًا للهلوسة (hallucination) في الحالة العامة. إذا اختلق المُولّد بثقة حقيقة غير مشمولة بأي قاعدة، فلن يكتشفها الفحص. للحصول على دقة واقعية، تحتاج إلى استرجاع (retrieval) مع الاستشهادات وفحص يتحقق من وجود الاستشهاد. هذا موضوع لمقال آخر.

كما أن فحص المخرجات لا يحل محل التقييم (evaluation). لا تزال بحاجة إلى تقييمات غير متصلة بالإنترنت (offline evals) تختبر الوكيل مقابل مجموعة ثابتة من المدخلات العدائية (adversarial inputs) عند كل تغيير. الفحص هو تطبيق إلزامي في وقت التشغيل (runtime). والتقييمات هي ثقة ما قبل النشر. كلاهما مهم.

الأسئلة الشائعة (FAQ)

ألا يؤدي إضافة فحص المخرجات إلى إبطاء الاستجابة؟ نعم، بمقدار زمن الاستجابة (latency) لاستدعاء إضافي واحد. بالنسبة لمُصنّف صغير أو فحص LLM قصير، يتراوح ذلك عادةً بين 100 إلى 400 مللي ثانية. بالنسبة للدردشة، هذا مقبول. أما بالنسبة لـ الصوت بأقل من ثانية، يمكنك تشغيل الفحص بالتوازي مع أول مقطع (chunk) صوتي أو استخدام طبقة قواعد حتمية تُرجع النتيجة فورًا.

هل يمكننا ببساطة استخدام نموذج أكبر وتخطي الفحص؟ لا. النموذج الأكبر يتبع التعليمات بشكل أفضل في المتوسط، مما يقلل من معدل انتهاكات السياسة. لكنه لا يقضي عليها تمامًا، ولا يمنحك مسار تدقيق (audit trail) عند حدوثها. الفحص موجود من أجل الحالات النادرة (long tail) ومن أجل الجهات التنظيمية.

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