التحقق من صلاحية مخرجات LLM

لماذا يهم

في درس اختبار الهلوسة سألتَ هل الإجابة مطابقة لمصادرها. أما هذا الدرس فيسأل: هل يستطيع التطبيق استخدامها بأمان؟ فحقل مفقود يُسقط المحلّل (Parser)، و"Refund" بدلاً من "refund" يرسل التذكرة إلى الطابور الخاطئ، ورقم طلب مختلَق يُطلق إجراءً على طلب عميل آخر، وشيفرة (Script) مخبّأة في الرد تعمل في متصفح الموظف. هذه عيوب عادية مصدرها غير عادي.

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

المخرجات المهيكلة: امنح الاستجابة عقداً

المخرجات المهيكلة (Structured Output) تعني أن يجيب النموذج بصيغة تقرؤها الآلة، وهي JSON في الغالب، بأسماء حقول ثابتة وقيم مسموح بها. وعبارة في الموجّه مثل «أجب بصيغة JSON فقط» طلبٌ لا ضمان. وتوفر واجهات برمجية كثيرة للنماذج أيضاً وضع JSON أو خيار مخرجات مهيكلة أو استدعاء الأدوات (Tool Calling)، فتقيّد الاستجابة بدرجات متفاوتة بصيغة JSON صالحة أو بمخطط تزوّدها به. اقرأ ما يضمنه مزوّدك فعلاً: فقد يقتصر الضمان على صحة الصياغة أو على جزء من JSON Schema، وقد تنقطع الاستجابة عند حدّ رموز المخرجات (Output Tokens) أو تأتي رفضاً بدلاً من البيانات.

اكتب العقد على هيئة JSON Schema محفوظ في المستودع، يستخدمه مدقّق التطبيق والاختبارات معاً. في المخطط أدناه ترفض additionalProperties: false الحقول التي لم يطلبها أحد، وتحدد enum القيم المسموح بها (مع التمييز بين الأحرف الكبيرة والصغيرة)، ويقيّد pattern رقم الطلب. والحقل order_id مطلوب لكنه قد يكون null: فالرسالة التي لا تحوي رقم طلب تحصل على القيمة null صراحةً، لا على حقل مفقود ولا على رقم مختلَق. ويشرح دليل JSON كيف يذهب التحقق من المخطط أبعد من فحص أن النص JSON صالح. ولاحظ أن قيم format مثل date مجرد توصيفات (Annotations) افتراضياً في الإصدارات الحديثة من المواصفة، فكثير من المدققات يتجاهلها ما لم يُضبط لذلك؛ استخدم pattern أو فحصاً في الشيفرة حين تهمّ الصيغة.

{
  "$schema": "https://json-schema.org/draft/2020-12/schema",
  "type": "object",
  "required": ["intent", "priority", "order_id", "reply"],
  "additionalProperties": false,
  "properties": {
    "intent":   { "enum": ["refund", "delivery", "account", "other"] },
    "priority": { "enum": ["high", "normal", "low"] },
    "order_id": { "type": ["string", "null"], "pattern": "^ORD-[0-9]{6}$" },
    "reply":    { "type": "string", "minLength": 1, "maxLength": 800 }
  }
}

جرّبها: مدقّق JSON Schema جرّبها: مدقّق JSON

تحقّق على طبقات: التحليل والمخطط والقواعد وضوابط الحماية

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

• التحليل (Parsing): هل هي JSON أصلاً؟ نص قبل JSON، أو سياج شيفرة Markdown، أو كائن مبتور، كلها تفشل هنا. وإذا كان التطبيق يُصلح المخرجات، كأن يحذف السياج، فهذا الإصلاح سلوك منصوص عليه في المواصفات يجب اختباره.
• المخطط (Schema): الحقول المطلوبة، والأنواع، والقيم المسموح بها، والأطوال، وعدم وجود حقول زائدة. وفشل المخطط يجعل المخرجات غير قابلة للاستخدام مهما كانت صياغتها جيدة.
• قواعد العمل (Business Rules): هل للقيم معنى بالنسبة إلى هذا المدخل وهذه البيانات؟ يجب أن يظهر order_id في الرسالة وأن يخص ذلك العميل. وهذه الطبقة تلتقط القيم المختلَقة التي تطابق المخطط تماماً.
• ضوابط الحماية (Guardrails): فحوص سياسات حول النموذج تحجب المخرجات أو تنقّحها أو تستبدلها، مثل بيانات شخصية في الرد، أو موضوع محظور، أو رابط خارج قائمة السماح. اختبرها في الاتجاهين: المخرجات السيئة تُوقَف، والمخرجات العادية لا تُحجب خطأً.

جرّبها: أداة اختبار Regex

الاتساق بين التشغيلات

قد يعطي المدخل نفسه مخرجات مختلفة في استدعاءات مختلفة. وخفض درجة الحرارة (Temperature) يقلل التباين لكنه لا يضمن استجابات متطابقة، لذا فتشغيل ناجح واحد لا يثبت الكثير. شغّل كل حالة مهمة عدة مرات، مثلاً ⁦10⁩ مرات، بإصدار النموذج وإصدار الموجّه والمعاملات المستخدمة في بيئة الإنتاج، وسجّل N وكل نتيجة.

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

• صلاحية المخطط: يجب أن ينجح كل تشغيل. فمع حجم الاستخدام في بيئة الإنتاج، يعني فشل واحد في كل ⁦10⁩ استدعاءات طلبات فاشلة كثيرة كل يوم.
• اتفاق القرارات: عُدّ القيم المختلفة التي أخذها كل حقل ثابت عبر التشغيلات.
• حين يتقلّب قرار، اسأل هل القاعدة معرّفة أصلاً. وكثيراً ما يكون الإصلاح بذكر القاعدة في الموجّه، أو بحساب ذلك الحقل بشيفرة عادية.

جرّبها: مقارنة JSON

عامل مخرجات النموذج كمدخل غير موثوق

تُدرج قائمة OWASP لأهم عشرة مخاطر لتطبيقات النماذج اللغوية لعام ⁦2025⁩ المعالجةَ غير السليمة للمخرجات (LLM05) خطراً مستقلاً: مخرجات نموذج تُمرَّر إلى مكونات أخرى دون تحقق وتعقيم ومعالجة كافية. فمن كتب المدخل، أو كتب المستندات التي قرأها النموذج، يستطيع التأثير فيما يكتبه، لذا لا يجوز للشيفرة المستقبِلة أن تثق بالمخرجات لأنها «جاءت من نموذجنا».

صلاحية المخطط ليست أماناً: "reply": "<b>Sorry</b>" نص صالح. وكل مستهلك يعالج المخرجات بحسب سياقه: رمّزها أو استخدم معقِّماً صارماً قبل عرضها في HTML، ومرّرها إلى SQL معاملاً لا نصاً ملصوقاً، وتحقق من عناوين URL وأسماء الملفات والأوامر مقابل قائمة سماح، ولا تدع النموذج يُطلق إجراءً لا يحق للمستخدم تنفيذه. اختبر بوسوم وأحرف خاصة غير ضارة، وعلى أنظمة تملكها أو لديك إذن مكتوب باختبارها فقط. ويسرد دليل اختبار أمان النماذج اللغوية حالات اختبار غير ضارة لكل سياق.

جرّبها: مولّد مجموعات الأحرف الخاصة جرّبها: مرمّز كيانات HTML

مثال تطبيقي: حالة فرز واحدة وعشرة تشغيلات

المدخل: «مرحباً، الطلب ORD-204913 وصل مكسوراً، وأريد استرداد أموالي». شغّل المختبِر هذه الحالة ⁦10⁩ مرات مقابل المخطط أعلاه، وسجّل لكل استجابة مختلفة أول طبقة فشلت فيها، إن وُجدت، فظهرت خمسة أنماط (أدناه). والنمط R4 هو الأكثر فائدة: رقم الطلب فيه يطابق النمط، لكنّ فيه رقمين متبادلَي الموضع، فلا تلتقطه إلا قاعدة العمل.

في التشغيلات العشرة كلها كانت قيمة intent هي refund، لكن priority جاءت normal ⁦7⁩ مرات وhigh ⁦3⁩ مرات. ويذكر تقرير الخطأ المدخلَ، وN = ⁦10⁩، والتوزيع، وإصداري النموذج والموجّه، وسؤالاً واحداً لمالك المنتج: هل البضاعة التالفة أولوية عالية؟ وبعد الاتفاق على القاعدة، إما أن تُذكر في الموجّه مع أمثلة، وإما أن يستخرج النموذج الواقعة وحدها (هل وصل المنتج تالفاً؟) ثم تُحسب priority منها في شيفرة عادية يفحصها اختبار مطابقة تامة.

R1  {"intent":"refund","priority":"normal","order_id":"ORD-204913","reply":"..."}
    parse ok, schema ok, rules ok                        -> accept
R2  Here is the JSON: {"intent":"refund", ...}
    parse fails: text before the JSON                    -> reject, one retry
R3  {"intent":"refund","priority":"normal","reply":"..."}
    schema fails: required field order_id is missing     -> reject, one retry
R4  {..., "order_id":"ORD-204931", ...}
    rules fail: order number is not in the message       -> reject, human queue
R5  {..., "reply":"<b>Sorry</b>, the item arrived broken..."}
    all layers pass                                      -> accept, show as text

جرّبها: مدقّق JSON Schema

أسئلة شائعة

المراجع

• OWASP Top 10 for LLM Applications 2025OWASP Gen AI Security Project · 2025أخطر عشرة مخاطر أمنية في تطبيقات النماذج اللغوية الكبيرة (LLM01:2025–LLM10:2025)، بدءاً بحقن الموجّهات والإفصاح عن المعلومات الحساسة.
• JSON Schema SpecificationJSON Schemaالمفردات المستخدمة لوصف بنية مستندات JSON والتحقق منها (الأنواع والحقول المطلوبة والصيغ).
• OWASP Cheat Sheet Series: Cross Site Scripting PreventionOWASP Foundationمنع XSS: الترميز عند الإخراج بحسب كل سياق، وتعقيم HTML الذي يكتبه المستخدم، ومواضع الإدراج الآمنة في DOM وحمايات الأطر، مع اعتبار CSP طبقة دفاع إضافية فقط.
• Define success criteria and build evaluationsAnthropicإرشادات مزوّد نماذج لكتابة معايير نجاح قابلة للقياس ومجموعات تقييم تُصحَّح بالكود أو بالمطابقة التامة أو بنموذج.