"Red teaming" शब्द Cold War के सैन्य अभ्यासों से आता है जहाँ एक नामित प्रतिकूल टीम (red) रक्षात्मक टीम (blue) की योजनाओं पर हमला करती थी। Cybersecurity में, यह दुर्भावनापूर्ण लोगों के पहले vulnerabilities ढूँढ़ने के लिए ethical hackers को नियुक्त करने की प्रथा में विकसित हुआ। AI red teaming उसी दर्शन को लागू करता है: मान लें कि मॉडल में कमज़ोरियाँ हैं, फिर systematically उन्हें ढूँढ़ें। पारंपरिक pen testing से key अंतर यह है कि AI मॉडल fuzzy, probabilistic तरीक़ों से fail होते हैं — कोई एकल exploit नहीं है जो एक language मॉडल को "roots" करता है, बल्कि prompts और contexts का एक landscape है जहाँ मॉडल अप्रत्याशित रूप से या हानिकारक रूप से व्यवहार करता है।
आधुनिक AI red teaming आम तौर पर failure की कई categories को कवर करता है। Safety testing हानिकारक सामग्री generation के लिए probes — क्या आप मॉडल को हथियारों, detailed self-harm content, या child exploitation material के लिए instructions उत्पन्न करने के लिए प्राप्त कर सकते हैं? Bias और fairness testing जाँचता है कि क्या मॉडल जनसांख्यिकीय समूहों के साथ अलग व्यवहार करता है या stereotypes को reinforces करता है। Factuality testing confident hallucinations की तलाश करता है, विशेष रूप से medicine और law जैसे high-stakes डोमेन में। Privacy testing जाँचता है कि क्या मॉडल अपने प्रशिक्षण डेटा से व्यक्तिगत जानकारी को regurgitate करेगा (शोधकर्ताओं ने GPT-3 से verbatim प्रशिक्षण डेटा निकाला है, जिसमें phone numbers और email addresses शामिल हैं)। और capability evaluations आकलन करते हैं कि क्या मॉडल genuinely ख़तरनाक कार्यों जैसे bioweapons design या cyberattacks में सहायता कर सकता है — ये वे evaluations हैं जो सूचित करते हैं कि क्या एक मॉडल बिल्कुल भी deploy करने के लिए safe है।
प्रथा तेज़ी से professionalized हो गई है। Anthropic, OpenAI, Google DeepMind, और Meta सभी प्रमुख releases से पहले आंतरिक red teams चलाते हैं, और वे तेज़ी से बाहरी विशेषज्ञों को लाते हैं। Anthropic ने Claude के pre-release evaluations के लिए biosecurity और cybersecurity में domain experts के साथ partner किया। OpenAI ने 50 से अधिक experts के साथ GPT-4 के लिए एक large-scale बाहरी red teaming अभ्यास चलाया। HackerOne और Scale AI जैसे startups ने red-teaming-as-a-service platforms बनाए हैं। स्वतंत्र AI red teamers का एक बढ़ता समुदाय भी है — DEF CON के 2023 Generative AI Red Teaming event में हज़ारों प्रतिभागी थे जो एक साथ कई providers से मॉडलों का परीक्षण कर रहे थे, और इसने वास्तविक vulnerabilities surface कीं जिन्हें कंपनियों ने बाद में patched किया।
Automated red teaming मानव परीक्षण के लिए तेज़ी से एक महत्वपूर्ण पूरक है। विचार दूसरे मॉडल के defenses का परीक्षण करने वाले adversarial prompts उत्पन्न करने के लिए एक AI मॉडल का उपयोग करना है। तकनीकों में gradient-आधारित हमले शामिल हैं (Greedy Coordinate Gradient, या GCG, जो nonsensical लेकिन प्रभावी adversarial suffixes ढूँढ़ता है), LLM-as-attacker दृष्टिकोण (जहाँ एक "red" मॉडल target की प्रतिक्रियाओं के आधार पर jailbreak prompts को iteratively refine करता है), और fuzzing (नए variants ढूँढ़ने के लिए known-successful हमलों को systematically mutating)। Anthropic और अन्य labs scale पर परीक्षण करने के लिए इन automated methods का उपयोग करते हैं — एक मानव red teamer एक session में सैकड़ों हमलों का प्रयास कर सकता है, जबकि एक automated सिस्टम लाखों का प्रयास कर सकता है। पकड़ यह है कि automated methods "weird" failures (gibberish tokens की प्रतिक्रियाएँ) ढूँढ़ने की प्रवृत्ति रखते हैं जबकि मानव socially realistic attack vectors (वह तरह जो वास्तविक उपयोगकर्ता प्रयास करेंगे) ढूँढ़ने में बेहतर हैं।
red teaming करने वाले किसी भी व्यक्ति के लिए एक व्यावहारिक gotcha: परिणाम अत्यधिक संवेदनशील हैं कि आप अभ्यास को कैसे frame करते हैं। यदि आप केवल उन failures के लिए परीक्षण करते हैं जिनकी आप अपेक्षा करते हैं, तो आप केवल वे ही ढूँढ़ेंगे। सबसे मूल्यवान red teaming अक्सर AI से असंबंधित domain expertise वाले लोगों से आती है — एक social worker manipulation patterns को spot कर सकता है जिनका परीक्षण करने के बारे में एक security शोधकर्ता नहीं सोचता, जबकि एक chemist जानता होगा कि कौन से synthesis instructions वास्तव में ख़तरनाक हैं बनाम कौन से textbook ज्ञान हैं। यही कारण है कि विविध red teams homogeneous वालों की तुलना में consistently अधिक और अलग vulnerabilities ढूँढ़ती हैं। यह भी कारण है कि red teaming कभी "done" नहीं है — हर नया use case, हर नया integration, हर मॉडल update potentially failure modes पेश करता है जिन्हें पिछले परीक्षण ने कवर नहीं किया।