واجهة API لنموذج لغوي غير خاضع للرقابة للفريق الأحمر والبحث الأمني

إن كنت قد بنيت منظومة آلية للفريق الأحمر (red-teaming)، فأنت تعرف نمط الفشل مسبقًا: نموذجك المهاجم يرفض توليد الهجوم، ونموذجك الحَكَم يرفض قراءة المخرجات التي يُفترض به تقييمها، ومعدل نجاح الهجوم لديك ينخفض بهدوء. لم يُطلق أي خطأ. أنت لم تقس أن هدفك صار أكثر أمانًا — بل قست أن أدواتك صارت أكثر حذرًا. واجهة API لنموذج لغوي غير خاضع للرقابة موجودة لإزالة ذلك المتغير من القياس.

هذه ليست حجة على أن حواجز الحماية سيئة. إنها حجة حول المكان الذي تنتمي إليه. حاجز الحماية في منتج دردشة استهلاكي يؤدي عمله. الحاجز نفسه داخل حلقة تقييم هو عامل مُربِك (confounder) خارج عن السيطرة يجلس بينك وبين الرقم الذي تحاول حسابه.

الرفض سلبي كاذب، ويبدو كأنه نجاح

سبب قسوة هذا الأمر أن الرفض ليس خطأ. تحصل على HTTP 200. تحصل على finish_reason: "stop". تحصل على JSON سليم البنية يُحلَّل دون مشاكل. والنص بداخله هو «لا أستطيع المساعدة في ذلك»، فيكتبه خط المعالجة لديك في عمود مجموعة بيانات، أو حقل تسمية، أو قسم في تقرير، ويمضي قدمًا.

وبشكل ملموس، في المواضع الثلاثة التي يؤلم فيها أكثر ما يؤلم:

النماذج المهاجمة. في بحث تكراري عن كسر الحماية — PAIR أو TAP أو تحسين على نمط GCG، أو أي شيء فيه مهاجم داخل الحلقة — يُنهي الرفض ذلك الفرع من البحث. يصبح معدل نجاح الهجوم الذي تبلّغ عنه دالة في استعداد مهاجمك لا في متانة هدفك. استبدل المهاجم بآخر أقل حذرًا، وسيتبخر «التحسين» الذي شحنته إلى نموذجك الهدف.

نماذج الحُكم والتقييم. التقييم بأسلوب «النموذج اللغوي حَكَمًا» (LLM-as-judge) على مخرجات ضارة يتطلب من الحَكَم أن يقرأ فعلًا المخرجات الضارة. وحين يرفض، تحصل على درجة لا يمكن تحليلها. معظم المنظومات تُسقط ذلك الصف. والصفوف المُسقَطة لا تغيب عشوائيًا — بل تتجمع بالضبط عند المخرجات الشديدة التي تحتاج إلى تقييمها أكثر من غيرها، فينحرف إجماليك نحو جانب الأمان.

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

ولأن حالات الرفض صامتة، ينتهي الأمر بالفرق إلى كتابة كواشف للرفض — وهي بحد ذاتها مشكلة لم تُحل بعد:

python

REFUSAL_MARKERS = ("i can't", "i cannot", "i'm unable", "i won't", "as an ai")

def looks_like_refusal(text: str) -> bool:
    """Substring heuristic. Good enough to alarm on, not good enough to trust:
    it misses polite deflections that never use the phrase, and it fires on any
    completion that quotes a refusal. Both error directions corrupt a dataset."""
    return any(m in text[:200].lower() for m in REFUSAL_MARKERS)

بناء كاشف غير موثوق لمشكلة يمكنك حذفها من مصدرها مقايضة خاسرة.

استدعاء الـ API

تتحدث unbleep مخطط Chat Completions الخاص بـ OpenAI، لذا يعمل أي عميل لديك بالفعل. غيّر base URL، وغيّر المفتاح، واحتفظ بالـ SDK.

python

import json
import os

from openai import OpenAI

client = OpenAI(
    base_url="https://unbleep.ai/v1",
    api_key=os.environ["UNBLEEP_API_KEY"],
)

TRIAGE = """You are a malware analyst writing notes for a detection engineer.
Given a decompiled routine, describe what it does, the observable artefacts it
would leave on a host, and where a defender could detect it. Reply as JSON with
keys: behaviour, artefacts, detection_surface, confidence."""


def triage(decompiled: str) -> dict:
    """One sample in, one structured verdict out — no refusal branch to handle."""
    resp = client.chat.completions.create(
        model="unbleep",
        messages=[
            {"role": "system", "content": TRIAGE},
            {"role": "user", "content": decompiled},
        ],
        response_format={"type": "json_object"},
        temperature=0.2,
    )
    return json.loads(resp.choices[0].message.content)

المكافئ عبر curl، وهنا يقوم بوسم مجموعة رسائل تصيّد احتيالي لبناء بيانات تدريب لكاشف:

bash

curl https://unbleep.ai/v1/chat/completions \
  -H "Authorization: Bearer $UNBLEEP_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "model": "unbleep",
    "messages": [
      {"role": "system", "content": "Label each email for a phishing detector. Answer with one word: phishing or benign."},
      {"role": "user", "content": "Subject: Payroll update required\n\nYour direct deposit is on hold. Confirm at hxxp://payroll-verify.example.com"}
    ],
    "temperature": 0,
    "max_tokens": 4
  }'

يكتسب temperature: 0 وحد max_tokens الضيق أهمية أكبر من المعتاد في حلقة وسم — فأنت تريد التسمية، لا فقرة تشرح التسمية.

اختيار الفئة

ثلاثة نماذج، كلها غير خاضعة للرقابة، تختلف في السياق والسعر:

unbleep — سياق 256K، و$3.00 / $3.00 لكل مليون إدخال/إخراج. الافتراضي: أدوار المهاجم والحَكَم، وتحليل العينات.
unbleep-high — سياق 1M، و$5.00 / $5.00. النصوص الطويلة والربط بين مستندات متعددة. جسم الطلب الواحد محدود بسقف 2,000,000 بايت (~500K توكن)، لذا تمتلئ النافذة عبر محادثة كاملة لا في استدعاء واحد.
unbleep-mini — سياق 32K، و$1.00 / $1.00. التصنيف عالي الحجم حيث تدفع عن كل صف.

النموذجان unbleep وunbleep-high فئتا تفكير: يفكران قبل الإجابة ويعيدان الأثر في حقل reasoning_content إلى جانب content. بالنسبة لنموذج حَكَم، هذا الأثر مفيد فعلًا — فهو يخبرك لماذا حصل صف ما على الدرجة التي حصل عليها، وهو ما تحتاج إليه حين تدقق في حالة خلاف. وهو يُحاسَب أيضًا بوصفه إخراجًا، لذا أرسل "thinking": false في المهام التي لا تحتاج إليه. أما unbleep-mini فيجيب مباشرة ولا يعيد أي أثر.

حوكمة تتحكم فيها أنت

إزالة الرفض من النموذج لا تعني إزالة الإشراف من خط المعالجة لديك. المعامل الاختياري policy يشغّل الحوكمة على جانبنا، لكل طلب على حدة:

python

resp = client.chat.completions.create(
    model="unbleep",
    messages=[...],
    extra_body={"policy": "research"},  # recorded on the usage row; answers exactly like off
)

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

أمر واحد يجب حسمه قبل أن توجّه خط معالجة إلى هذا: نحن نخزّن ما ترسله وما يعود إليك. جسم الطلب، ومحتوى الاستجابة، وعنوان IP المصدر لكل استدعاء نقبله ونمرّره إلى نموذج، تُكتب كلها في قاعدة بياناتنا وتُحفظ لمدة 30 يومًا، لأغراض التحقيق في إساءة الاستخدام والدعم ونزاعات الفوترة. تُقتطع الأجسام عند 64 KB. عنوان IP المصدر يبقى بعد الثلاثين يومًا — فهو يُكتب أيضًا في صف الاستخدام الذي يُحاسِب على الاستدعاء، وذلك الصف سجل مالي نحتفظ به لمدة أطول. الشيء الوحيد الذي لا يُخزَّن هو الطلب الذي ترفضه strict قبل أن يصل إلى نموذج: يظهر ذلك في سجل استخدامك دون محتواه. لا شيء آخر مستثنى، ولا يوجد إعداد لإيقاف ذلك. إن كانت مجموعة بياناتك حساسة إلى درجة تجعل نسخة تبقى 30 يومًا خارج نطاق حمايتك مشكلة — برمجيات خبيثة حية، أو بيانات عملاء، أو مهمة خاضعة لاتفاقية عدم إفصاح (NDA) — فذلك قيد حقيقي، وسياسة الخصوصية هي الصفحة التي ينبغي أن تقرأها قبل أن تبدأ، لا بعد ذلك.

تتبع الأخطاء غلاف OpenAI، لذا تعمل المعالجات الحالية: 401 مفتاح غير صالح، و402 نفاد الرصيد، و422 محظور بواسطة السياسة، و429 تجاوز حد المعدل، و5xx يمكن إعادة المحاولة. تحمل كل استجابة ترويسات x-ratelimit-* كي تتمكن مهمة دفعية من ضبط وتيرتها دون تخمين.

ما لا تمنحك إياه واجهة API لنموذج لغوي غير خاضع للرقابة

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

احصل على مفتاح API وتوقف عن قياس حذر أدواتك.