Choosing Where and How to Moderate: End-to-End Trade-offs in Filter Placement and Response Rewriting

कल्पना कीजिए कि आप एक विशाल, अराजक समाचार पत्र के संपादक हैं जो हर सेकंड लाखों कहानियाँ छापता है। आपकी कुछ कहानियाँ शानदार, मज़ेदार और मददगार होती हैं। अन्य खतरनाक, बदमिज़ाज या बस निरर्थक होती हैं। आपका काम यह सुनिश्चित करना है कि पाठक को दी जाने वाली अंतिम प्रति सुरक्षित और उपयोगी हो। लेकिन यहाँ पेचीदा बात यह है कि आपके पास "सुरक्षा गार्डों" (कंप्यूटर प्रोग्राम) की एक टीम है जो बुरी चीज़ों को पहचान सकती है। बड़ा सवाल यह नहीं है कि क्या गार्ड बुरी चीज़ों को ढूँढ सकते हैं; बल्कि यह है कि उन्हें यह कब और कैसे करना चाहिए।

क्या गार्डों को कहानी लिखे जाने से पहले ही पाठक के अनुरोध की जाँच करनी चाहिए? क्या उन्हें कहानी पूरी होने तक इंतज़ार करना चाहिए और फिर उसकी जाँच करनी चाहिए? या उन्हें दोनों करना चाहिए? यह शोध पत्र ठीक इसी पहेली को लेकर है जो AI चैटबॉट्स के लिए है। यह AI को एक लेखक की तरह और सुरक्षा फिल्टरों को संपादकों की तरह मानता है, और यह देखने के लिए विभिन्न तरीकों का परीक्षण करता है कि उन्हें कैसे व्यवस्थित किया जाए जिससे सबसे अच्छा परिणाम मिले: सबसे मददगार उत्तर और सबसे कम खतरनाक चूक।

---

द ग्रेट AI सेफ्टी डांस: कहाँ खड़े हों और क्या करें

इस शोध पत्र के लेखकों, माइक्रोसॉफ्ट रिस्पॉन्सिबल AI और गुडफायर की एक टीम ने सुरक्षा फिल्टरों को अलग-थलग देखना बंद करने का निर्णय लिया। आमतौर पर, वैज्ञानिक केवल यह मापते हैं कि एक फिल्टर बुरे शब्दों को पकड़ने में कितना अच्छा है, जैसे कि एक स्पेलचेकर गलतियों की गिनती करता है। लेकिन वास्तविक दुनिया अधिक जटिल है। यदि कोई फिल्टर बहुत सख्त है, तो वह एक बेहतरीन कहानी को भी ब्लॉक कर सकता है क्योंकि उसमें ऐसा शब्द इस्तेमाल हुआ जो जोखिम भरा लगता है। यदि यह बहुत ढीला है, तो एक खतरनाक कहानी निकल सकती है।

इसलिए, टीम ने उनके सुरक्षा तंत्र के लिए चार अलग-अलग "डांस मूव्स" (नृत्य की चालों) का परीक्षण करने के लिए एक विशाल प्रयोग किया। वे उस 'स्वीट स्पॉट' को खोजना चाहते थे जहाँ AI सबसे अधिक मददगार (आपको एक शानदार उत्तर दिखाना) हो लेकिन फिर भी सुरक्षित (आपको कुछ भी हानिकारक न दिखाना) रहे।

चार डांस मूव्स

उन्होंने चार विशिष्ट सेटअपों का परीक्षण किया, जिन्हें वे कॉन्फ़िगरेशन कहते हैं:

1. इनपुट ओनली (केवल इनपुट): गार्ड पाठक के सवाल की जाँच करता है इससे पहले कि AI कुछ भी लिखे। यदि सवाल जोखिम भरा दिखता है, तो गार्ड पूरी प्रक्रिया को तुरंत रोक देता है। कोई कहानी नहीं लिखी जाती।
2. रिस्पॉन्स ओनली (केवल रिस्पॉन्स): गार्ड AI को पहले कहानी लिखने देता है। फिर, गार्ड तैयार कहानी की जाँच करता है। यदि वह खराब है, तो कहानी को फेंक दिया जाता है।
3. इनपुट + रिस्पॉन्स (इनपुट + रिस्पॉन्स): गार्ड सवाल और जवाब दोनों की जाँच करता है। यदि दोनों में से कोई भी जोखिम भरा दिखता है, तो कहानी को ब्लॉक कर दिया जाता है।
4. रिस्पॉन्स + रीराइट (रिस्पॉन्स + रीराइट): यह एक फैंसी नया मूव है। गार्ड तैयार कहानी की जाँच करता है। यदि यह जोखिम भरा है, तो उसे सिर्फ फेंकने के बजाय, एक "फिक्सर" (एक दूसरा AI) कहानी को सुरक्षित बनाने के लिए उसे फिर से लिखने की कोशिश करता है। फिर, गार्ड अंतिम बार नए संस्करण की जाँच करता है। यदि वह पास हो जाता है, तो आपको सुधारी हुई कहानी मिलती है!

बड़ी खोज: अंत तक प्रतीक्षा करें!

टीम ने इन परीक्षणों को दो अलग-अलग चरणों पर चलाया: एक निजी, मानव-लेबल वाला डेटासेट जिसमें 1,250 बातचीत शामिल थी ("इंटरनल बेंचमार्क") और एक सार्वजनिक डेटासेट जिसमें 5,000 से अधिक विषाक्त (toxic) चैट थीं ("पब्लिक टॉक्सिकचैट")।

यहाँ आश्चर्यजनक परिणाम मिला: अंत तक प्रतीक्षा करना (रिस्पॉन्स ओनली) चीजों को मददगार बनाए रखने के लिए सबसे अच्छी रणनीति थी।

जब उन्होंने कहानी लिखे जाने के बाद बुरे जवाबों को ब्लॉक किया, तो सिस्टम ने 85.68% बातचीत को मददगार और विषय पर रखा। लेकिन जब उन्होंने AI द्वारा कुछ भी लिखने से पहले ही बुरे सवालों को ब्लॉक करने की कोशिश की (इनपुट ओनली), तो उन्होंने गलती से आधी अच्छी बातचीत को भी फेंक दिया! वास्तव में, आधुनिक AI मॉडल पहले से ही बुरे सवालों को अनदेखा करने और सुरक्षित उत्तर लिखने में काफी अच्छे हैं। इसलिए, प्रक्रिया को जल्दी रोकना ऐसा था जैसे किसी बाउंसर द्वारा क्लब में लोगों को उनकी आईडी दिखाने का मौका मिलने से पहले ही बाहर निकाल देना, भले ही उनमें से कई लोग बिल्कुल ठीक थे।

हालाँकि, एक पेच था। जबकि "रिस्पॉन्स ओनली" सबसे मददगार था, इसने इनपुट और आउटपुट दोनों की जाँच करने की तुलना में थोड़ी अधिक हानिकारक सामग्री को अंदर आने दिया। यदि आपके पास एक बहुत सख्त सुरक्षा बजट है (यानी आप कोई भी बुरी चीज़ अंदर नहीं आने देना चाहते), तो इनपुट और आउटपुट दोनों की जाँच करना (इनपुट + रिस्पॉन्स) सबसे सुरक्षित था, लेकिन इसने सिस्टम को बहुत कम मददगार बना दिया।

"फिक्सर" का जादू

टीम ने पूछा, "क्या हम दोनों दुनिया का सर्वश्रेष्ठ हिस्सा पा सकते हैं? क्या हम 'रिस्पॉन्स ओनली' रणनीति को उसकी मददगार प्रकृति के लिए रख सकते हैं, लेकिन कुछ बुरे जवाबों को ठीक कर सकते हैं?"

उन्होंने "रिस्पॉन्स + रीराइट" रणनीति का परीक्षण किया। जब गार्ड ने एक बुरा जवाब पकड़ा, तो उसे केवल ब्लॉक करने के बजाय, उन्होंने उसे एक "फिक्सर" AI को भेज दिया। यह फिक्सर जवाब को फिर से लिखता ताकि बुरे हिस्सों को हटाया जा सके और अच्छे हिस्सों को बरकरार रखा जा सके।

परिणाम प्रभावशाली थे। इस रीराइट ट्रिक का उपयोग करके, उन्होंने लगभग सारा ट्रैफ़िक बचा लिया जो ब्लॉक हो जाता।

• आंतरिक परीक्षण में, मददगार होना 85.68% से बढ़कर 95.04% हो गया।
• ब्लॉक की गई बातचीत की संख्या 9.60% से घटकर केवल 0.24% रह गई।

महत्वपूर्ण रूप से, उपयोगकर्ताओं तक पहुँचने वाले हानिकारक जवाबों की संख्या बिल्कुल वैसी ही रही जैसी "रिस्पॉन्स ओनली" रणनीति में थी। रीराइट ने अधिक बुराई को अंदर नहीं आने दिया; इसने बस उस अच्छे हिस्से को बचा लिया जिसे लगभग फेंक दिया जाने वाला था।

गति और "रीराइट" की लागत

बेशक, कुछ भी मुफ्त नहीं आता। रीराइट करने में समय लगता है। टीम ने एक कहानी को ठीक करने में लगने वाले समय को मापा।

• यदि उन्होंने यह तय करने के लिए कि क्या रीराइट करना है और कैसे, एक विशाल, धीमे AI का उपयोग किया, तो इसमें लगभग 13.8 सेकंड लगे। चैट के समय में यह एक अनंत काल जैसा है!
• लेकिन, उन्होंने छोटे, विशेषीकृत "प्रोब्स" (छोटे, तेज़ डिटेक्टर) का उपयोग करके एक स्मार्ट शॉर्टकट खोजा। इससे समय घटकर केवल 0.47 सेकंड रह गया।

इसका मतलब है कि आप बिना उपयोगकर्ता को हमेशा के लिए इंतज़ार कराए एक ऐसा सिस्टम बना सकते हैं जो बहुत मददगार और सुरक्षित हो।

बारीक विवरण: रीराइट ने क्या मिस किया

लेखकों ने केवल नंबरों को नहीं देखा; उन्होंने पुनर्लिखित कहानियों को पढ़ा भी ताकि देख सकें कि वास्तव में क्या हो रहा था। उन्होंने पाया कि "फिक्सर" सामान्यीकरण (generalizing) करने में अच्छा था। उदाहरण के लिए, यदि किसी कहानी में किसी विशिष्ट खतरनाक ऐप का उल्लेख था, तो फिक्सर ने उस नाम को "एक सुरक्षित प्लेटफॉर्म" से बदल दिया और सुरक्षित रहने के बारे में अच्छी सलाह भी दी।

हालाмबा, उन्होंने एक सीमा भी पाई। कुछ संवेदनशील मामलों में, जैसे आत्म-क्षति (self-harm) के बारे में कहानियाँ, रीराइट ने कभी-कभी अतिरिक्त सुरक्षा के चक्कर में विशिष्ट, सहायक संसाधनों (जैसे संकट हेल्पलाइन नंबर) को हटा दिया। शोध पत्र नोट करता है कि हालांकि सिस्टम सुरक्षा और उपयोगिता के बीच संतुलन बनाने में महान है, लेकिन यह पूर्ण नहीं है। कभी-कभी, सुरक्षित रहने की जल्दबाजी में, यह अनजाने में सहायता की जानकारी को छोड़ सकता है जिसे एक इंसान रखना चाहेगा।

निष्कर्ष

यह शोध पत्र हमें यह नहीं बताता कि सभी AI सुरक्षा के लिए कोई एक "परफेक्ट" नियम है। इसके बजाय, यह हमें एक मानचित्र देता है। यह दिखाता है कि:

1. बहुत जल्दी ब्लॉक न करें: AI को पहले लिखने देने से आमतौर पर अधिक मददगार उत्तर मिलते हैं।
2. ब्लॉक करने के बजाय रीराइट करें: यदि आप एक बुरा जवाब पकड़ते हैं, तो उसे ठीक करने की कोशिश करें। यह बहुत सारी अच्छी बातचीत को बिना खतरा बढ़ाए बचा लेता है।
3. गति मायने रखती है: आप सही उपकरणों का उपयोग करके चीजों को तेज़ी से ठीक कर सकते हैं।

लेखक निष्कर्ष निकालते हैं कि कोई सार्वभौमिक "एक ही आकार सबके लिए उपयुक्त" (one-size-fits-all) नियम नहीं है। इसके बजाय, कंपनियों को अपनी विशिष्ट आवश्यकताओं को देखना चाहिए। यदि वे अधिक मददगार उत्तर पाने के लिए थोड़े से जोखिम को सहन कर सकते हैं, तो उन्हें "रिस्पॉन्स ओनली" रणनीति के साथ "रीराइट" फिक्सर का उपयोग करना चाहिए। यदि उन्हें बिल्कुल शून्य-जोखिम की आवश्यकता है, तो उन्हें इनपुट की भी जाँच करनी पड़ सकती है, भले ही इसका अर्थ अधिक अच्छी बातचीत को ब्लॉक करना हो। यह आपके अपने क्लब के लिए सही संतुलन खोजने के बारे में है।