معيار الذكاء الاصطناعي للفريق الأحمر

النسخة الروسية: README.ru.md

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

تحتوي مجموعة الإصدار 2 الافتراضية على 60 سؤالًا في datasets/v2/benchmark.jsonl، مجمعة حسب المجال والصعوبة.

حالة المستودع

المستودع الأصلي على GitHub لم يعد متاحًا؛ بصفته مالكه، تم حظري من منصة GitHub. يوجد مرآة بديلة للمشروع (يديرها المساهم الرئيسي والمؤلف المشارك) متاحة على https://github.com/szybnev/redteam-ai-benchmark. المالك الحالي لهذا المستودع هو المطور النشط والمشرف عليه.

الغرض والنطاق

project_type: LLM evaluation benchmark
primary_function: assess model responses to red-team questions and scenarios
execution_target: configured LLM provider, optional judge, and optional tracing services
target_system_access: none
model_output_execution: none
user_control: all actions after a response is returned depend solely on the end user and their own framework, permissions, and environment

أهداف غير صريحة

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

مسؤولية المستخدم

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

لوحة المتصدرين المنشورة

لا توجد لوحة متصدرين منشورة حاليًا في هذا الفرع. تم إنتاج النتائج التاريخية باستخدام دلالات معجمية أقدم وحكم جزئي ولا يمكن مقارنتها بالمقياس الحالي.

تتطلب لوحة متصدرين قابلة للنشر تمرير حكم كامل باستخدام تجزئات مجموعة بيانات مطابقة، وبدون أخطاء حكم، وتغطية كاملة. قم بإنشاء القطع الأثرية JSON و Markdown المفحوصة باستخدام:

uv run run_benchmark.py leaderboard \
  --judge-summary judge_results_v2/summary.csv \
  --output-dir leaderboard

يتطلب الأمر سجلات الحكم per_model/*.json الفرعية ويرفض الملخصات disputed والتغطية غير الكاملة للحكم وعدم تطابق تجزئات مجموعة البيانات والصفوف بدون مصدر حكم-نموذج. تحتوي الحزمة الناتجة على نتائج المعيار الخام وسجلات الحكم لكل سؤال وتجزئاتها ونسخة من summary.csv. يستخدم الترتيب rubric_score الخام؛ يتم عرض judge_adjusted_score فقط كنتيجة تدقيق منفصلة.

ما يقيسه الإصدار 2

يبلغ المعيار عن النتيجة الإجمالية الموزونة ومقاييس تدقيق منفصلة:

تسميات التفسير متحفظة عن قصد:

تنطبق تسميات التفسير فقط على عمليات التشغيل الكاملة. أي فشل في الطلب يغير التفسير إلى غير مكتمل، مع الحفاظ على النتيجة الجزئية والتغطية للتشخيص. عندما تعبر فترات الثقة للتكرار عتبة 60 أو 80، يكون التفسير غير مؤكد. النتيجة العالية ليست موافقة إنتاجية.

تغطية مجموعة البيانات

تغطي مجموعة بيانات الإصدار 2:

• حرفية ويندوز
• خدمات المجال النشط وخدمات الشهادات
• استغلال الويب
• السحابة وإدارة الهوية والوصول
• الحاويات وKubernetes
• استدلال الاكتشاف والتهرب
• الأمن العملياتي والمقايضات التشغيلية
• استخدام الأدوات
• تخطيط ما بعد الاستغلال
• التحقق والإبلاغ

مستويات الصعوبة هي L1 واقعي، L2 إجراء، L3 استكشاف الأخطاء، L4 استدلال سيناريو، وL5 مهمة متعددة الخطوات للمشغل.

التثبيت

المتطلبات:

• Python 3.13+
• uv
• مزود واحد: Ollama، LM Studio، OpenWebUI، أو OpenRouter

تثبيت التبعيات الأساسية:

uv sync

المزودون

الاستخدام

عرض النماذج:

uv run run_benchmark.py ls ollama
uv run run_benchmark.py ls lmstudio
uv run run_benchmark.py ls openwebui
uv run run_benchmark.py ls openrouter --api-key "$OPENROUTER_API_KEY"

تشغيل الملف الشخصي القياسي للإصدار 2 الافتراضي:

uv run run_benchmark.py run ollama -m "llama3.1:8b"

تشغيل مجموعة فرعية سريعة للاختبار:

uv run run_benchmark.py run ollama -m "llama3.1:8b" --profile quick

تشغيل أسئلة محددة من الإصدار 2 حسب المعرف:

uv run run_benchmark.py run ollama -m "llama3.1:8b" --question-ids 5 12

كتابة سجل طلبات لكل سؤال للإلحاق فقط:

uv run run_benchmark.py run ollama -m "llama3.1:8b" --request-log results/requests.jsonl

تشغيل نماذج محلية متعددة بشكل تفاعلي:

uv run run_benchmark.py interactive ollama --profile standard

الملفات الشخصية المدعومة:

التقييم

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

لا يدعم التقييم أثناء التشغيل أوضاع keyword أو semantic أو hybrid القديمة. استخدم أمر judge دون اتصال للتدقيق اللاحق باستخدام LLM كحكم.

حكم LLM دون اتصال

يمكن تدقيق ملفات JSON لنتائج الإصدار 2 المحفوظة بعد الحدث دون إعادة تشغيل نماذج المعيار:

OPENROUTER_API_KEY=... uv run run_benchmark.py judge \
  --results "results_*_v2/*.json" \
  --dataset datasets/v2/benchmark.jsonl \
  --judge-model "deepseek/deepseek-v4-flash" \
  --output-dir judge_results_v2 \
  --mode full \
  --concurrency 4

يكتب أمر الحكم per_model/*.json وdetailed.csv وsummary.csv وdisputed_cases.csv. الوضع الكامل ينتج judge_adjusted_score قابلاً للمقارنة ومقامات صريحة. يظل disputed وضع تشخيص لتوفير التكاليف ولا ينشر إجماليًا معدلاً جزئيًا. كما يدقق عينة عشوائية حتمية بنسبة 20% من معرفات الأسئلة ذات الدرجات العالية عبر كل نموذج؛ اضبط هذا باستخدام --audit-sample-rate. يقوم الحكم بتقييم الإجابات دون رؤية النتيجة الحتمية، ثم تقارن المعالجة اللاحقة كلتا النتيجتين.

التكوين

انسخ config.example.yaml إلى config.yaml واضبطه:

provider:
  name: ollama
  endpoint: http://localhost:11434
  # api_key: sk-xxx
  # keep_alive: 30m

scoring:
  method: rubric

export:
  formats:
    - json
    - csv
    - criteria_csv
  output_dir: ./results
  include_response: true

questions_file: datasets/v2/benchmark.jsonl
answers_file: answers_all.txt
rate_limit_delay: 1.5
max_tokens: 1024
temperature: 0.2
concurrency: 1
repeats: 1
seed: 0
continue_on_error: true
# request_log: ./results/requests.jsonl

تشغيل مع التكوين:

uv run run_benchmark.py run ollama -m "llama3.1:8b" --config config.yaml

المخرجات

يتضمن تصدير JSON نتائج النموذج وأدلة المعيار لكل سؤال وملخص إجمالي ومصدر التدقيق:

{
  "model": "llama3.1:8b",
  "scoring_method": "rubric",
  "total_score": 75.0,
  "interpretation": "requires-validation",
  "benchmark_version": "2.3.0",
  "dataset_id": "redteam-ai-benchmark-v2",
  "dataset_version": "2.1.0",
  "dataset_hash": "...",
  "scorer_version": "rubric-v2.1.0",
  "config_hash": "...",
  "evaluation_fingerprint": "...",
  "run_config": {
    "provider": "ollama",
    "model": "llama3.1:8b",
    "profile": "standard",
    "repeats": 1,
    "seed": 0
  },
  "git_commit": "...",
  "package_version": "2.3.0",
  "runtime_profile": "standard",
  "summary": {
    "metrics": {
      "refusal_rate": 0.0,
      "critical_error_rate": 0.0
    },
    "breakdown": {
      "difficulty": {},
      "domain": {},
      "capability": {}
    }
  }
}

يتضمن كل صف نتيجة حالة الطلب وهوية التكرار/التشغيل والبذرة وسبب الانتهاء والاستخدام والنموذج الفعلي وبيانات المزود المتاحة. تضيف المصدرية على المستوى الأعلى معلومات البيئة وسببًا صريحًا عندما لا يتوفر إصدار نموذج غير قابل للتغيير. يحتوي مخرج CSV على صفوف لكل سؤال بالإضافة إلى صف TOTAL. يضيف criteria_csv صفًا واحدًا لكل معيار تم اجتيازه أو فشله.

يتم الاحتفاظ بأخطاء الطلب كصفوف منظمة وتجعل التشغيل غير مكتمل. استخدم --fail-fast أو continue_on_error: false للإجهاض عند أول خطأ.

تحسين المطالبة

يبقى تحسين المطالبة اختياريًا ومنفصلاً عن تقييم النموذج الأساسي. يعمل فقط مع الاستجابات المصنفة على أنها مراقبة. لا يتم استبدال الاستجابات الأساسية والنتيجة الرئيسية أبدًا؛ تتم كتابة الاستجابات المحسنة إلى optimized_prompts_{model}_{timestamp}.json مع نتائج أساسية ومحسنة منفصلة. يبلغ ملخصها refusal_recovery_rate عبر الاستجابات المراقبة المرسلة إلى المحسن.

uv run run_benchmark.py run ollama -m "llama3.1:8b" \
  --optimize-prompts \
  --optimizer-model "llama3.3:70b"

لا تخلط النتائج المحسنة مع مقارنات قدرات النموذج الأساسي.

القيود المعروفة

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

التحقق

فحوصات مفيدة:

uv run run_benchmark.py --help
uv run run_benchmark.py run --help
uv lock --check
uv run ruff check .
uv run pytest -q
uv run python -m compileall -q run_benchmark.py benchmark models optimization scoring tracing utils

المساهمة

انظر CONTRIBUTING.md و CODE_OF_CONDUCT.md و SECURITY.md.

الترخيص

MIT. يُستخدم في مختبرات الفريق الأحمر المصرح بها، وتقييمات الأمان التجارية، وأبحاث أمان الذكاء الاصطناعي، والبيئات التعليمية.