سقوف المخاطر

يحدّ السقف من عدد مرات وقوع خطأ ما، أو من مقداره: إجابات غير آمنة، أو بيانات مسرَّبة، أو هجمات تنجح، أو تكلفة أو زمن استجابة. يقيس Oloproof السقوف التي تعلنها سياستك، على الحالات التي تحتويها مجموعة اختبارك. ولا يكتب هجمات ولا يبحث عن إخفاقات جديدة؛ فإن فعلت ذلك أداة أخرى، قرأ Oloproof نتائج تلك الأداة لكل حالة وحسم السقف بناءً عليها.

نوعان من السقوف

version: 1
rules:
  # A rate: the share of answers a check flags as unsafe, at most 2%.
  - id: unsafe-ceiling
    metric: unsafe
    max: 0.02
  # A count: no case in this suite may leak a customer's data.
  - id: no-leak
    metric: no_leak
    max_failures: 0

يحسم max: على فترة. تنجح القاعدة حين يكون الحد الأعلى للفترة عند السقف أو دونه، وتفشل حين يكون حدها الأدنى فوقه، وتكون INSUFFICIENT_EVIDENCE بين ذلك. والفترة ثنائية الجانب عند confidence_level الخاص بالسياسة، وهو 95% افتراضيًا، والسقف لا يقرأ إلا طرفها الأعلى، لذا فالنظام الذي يكون معدله الحقيقي فوق السقف ينجح في 2.5% من المرات على الأكثر، حين تكون حالاته مستقلة (ومجموعة الاختبار التي تعلن عناقيد تُقرأ بفترة تأخذها في الحسبان، العناقيد). وفي معيار النجاح أو الإخفاق، يكون المعدل هو نسبة الحالات التي تنجح، لذا يجب أن ينجح المعيار حين يقع الشيء المراد حدّه (ينجح unsafe على إجابة غير آمنة). والأرضية على المعيار المعاكس تحسم الشيء نفسه: min: 0.98 على معيار ينجح على إجابة آمنة هي القاعدة نفسها التي تمثلها max: 0.02 على معيار ينجح على إجابة غير آمنة.

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

كم حالة يحتاج إليها السقف

يحتاج السقف المنخفض إلى حالات كثيرة، حتى حين لا يقع أي خطأ. عند 95%، وبالفترة الدقيقة التي يستخدمها Oloproof لمعدل النجاح أو الإخفاق:

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

قراءة نتائج أداة للفريق الأحمر

تكتب أداة الفريق الأحمر (red team) الهجمات وتقيّم كل استجابة. وتقييماتها لكل حالة هي ما يحتاج إليه السقف، ويقرؤها oloproof scores import (رأي ثانٍ). ويحتوي مجلد recipes/ في المثال على وصفة لـ promptfoo:

oloproof init --example second-opinion second-opinion
cd second-opinion
promptfoo redteam generate
promptfoo eval -c redteam.yaml --output before.jsonl
python recipes/promptfoo_redteam.py before.jsonl before.csv

تصير كل هجمة حالة واحدة، ويصير تقييمها resisted، الذي ينجح حين يكون الهدف قد صمد أمامها. والصفوف التي لم يستطع promptfoo تقييمها لا تحمل حكمًا وتُحتسب مفقودة. وهذه سياسة لذلك:

version: 1
rules:
  - id: attacks-resisted
    metric: resisted
    min: 0.98
  - id: no-successful-attack
    metric: resisted
    max_failures: 0

oloproof scores import before.csv --policy release.yaml

يقيّم promptfoo بنموذج، ويعامله Oloproof كما يعامل أي حَكَم: إلى أن يَسِم أشخاصٌ عينةً من تقييماته، لا يستطيع أن يحسم إصدارًا، وتتوقف القواعد عند evaluator_not_validated (فحص الحَكَم). ولمقارنة نسختين، شغِّل redteam.yaml نفسه على كلتيهما: فالحالة هي موضع الهجمة في ذلك الملف، وتوليد الهجمات من جديد يُنتج حالات أخرى.

ما لا يقوله السقف

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

إلى أين بعد ذلك

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