बेहतर बेयसियन फ़िल्टरिंग

जनवरी 2003

(यह लेख 2003 स्पैम सम्मेलन में एक वार्ता के रूप में दिया गया था। यह उस काम का वर्णन करता है जो मैंने स्पैम के लिए एक योजना में वर्णित एल्गोरिथम के प्रदर्शन को बेहतर बनाने के लिए किया है, और मैं भविष्य में क्या करने की योजना बना रहा हूँ।)

पहली खोज जिसे मैं यहां प्रस्तुत करना चाहता हूं, वह शोध पत्रों के आलसी मूल्यांकन के लिए एक एल्गोरिथम है। बस जो चाहो लिखो और पिछले किसी भी काम का हवाला न दो, और नाराज पाठक आपको उन सभी पत्रों के संदर्भ भेजेंगे जिन्हें आपको उद्धृत करना चाहिए था। मैंने यह एल्गोरिथम खोजा जबकि "स्पैम के लिए एक योजना" [1] स्लैशडॉट पर थी।

स्पैम फ़िल्टरिंग टेक्स्ट वर्गीकरण का एक सबसेट है, जो एक अच्छी तरह से स्थापित क्षेत्र है, लेकिन बेयसियन के बारे में पहले पेपर स्पैम फ़िल्टरिंग प्रति से 1998 में एक ही सम्मेलन में दिए गए दो प्रतीत होते हैं, एक पैंटेल और लिन [2] द्वारा, और दूसरा माइक्रोसॉफ्ट रिसर्च [3] के एक समूह द्वारा।

जब मैंने इस काम के बारे में सुना तो मैं थोड़ा हैरान था। अगर लोग चार साल पहले बेयसियन फ़िल्टरिंग पर थे, तो हर कोई इसका इस्तेमाल क्यों नहीं कर रहा था? जब मैंने पेपर पढ़े तो मुझे पता चला कि क्यों। पैंटेल और लिन का फ़िल्टर था दोनों में से अधिक प्रभावी, लेकिन यह केवल 92% स्पैम पकड़ा, 1.16% गलत सकारात्मक के साथ।

जब मैंने बेयसियन स्पैम फ़िल्टर लिखने की कोशिश की, इसने 99.5% स्पैम पकड़ा .03% से कम गलत सकारात्मक [4] के साथ। जब दो लोग एक ही प्रयोग करने की कोशिश करते हैं तो व्यापक रूप से भिन्न परिणाम मिलते हैं तो यह हमेशा खतरनाक होता है। यह यहां विशेष रूप से खतरनाक है क्योंकि उन दो संख्याओं के सेट विपरीत निष्कर्ष दे सकते हैं। विभिन्न उपयोगकर्ताओं की अलग-अलग आवश्यकताएं होती हैं, लेकिन मुझे लगता है कि कई लोगों के लिए 92% की फ़िल्टरिंग दर 1.16% गलत सकारात्मक के साथ इसका मतलब है कि फ़िल्टरिंग एक स्वीकार्य समाधान नहीं है, जबकि 99.5% .03% से कम गलत सकारात्मक के साथ इसका मतलब है कि यह है।

तो हमें इतने अलग नंबर क्यों मिले? मैंने पैंटेल और लिन के परिणामों को दोहराने की कोशिश नहीं की है, लेकिन पेपर पढ़ने से मुझे पाँच चीजें दिखाई देती हैं जो शायद अंतर के लिए जिम्मेदार हैं।

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

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

तीसरा, पैंटेल और लिन ने टोकन को स्टेम किया, जिसका अर्थ है कि उन्होंने कम कर दिया जैसे कि दोनों "मेलिंग" और "मेल" रूट "मेल" में। वे हो सकते हैं ने महसूस किया कि उन्हें अपने छोटे आकार से मजबूर किया गया था कॉर्पस, लेकिन अगर ऐसा है तो यह एक तरह का समयपूर्व है अनुकूलन।

चौथा, उन्होंने संभावनाओं की गणना अलग तरह से की। उन्होंने सभी टोकन का उपयोग किया, जबकि मैं केवल 15 सबसे महत्वपूर्ण का उपयोग करता हूं। यदि आप सभी टोकन का उपयोग करते हैं तो आप लंबे स्पैम को याद करने की प्रवृत्ति रखेंगे, जिस प्रकार जहां कोई आपको अपनी जीवन कहानी बताता है उस बिंदु तक जहां वे किसी बहुस्तरीय से अमीर हो गए विपणन योजना। और ऐसा एल्गोरिथम स्पैमर के लिए स्पूफ करना आसान होगा: बस एक बड़ा जोड़ें यादृच्छिक पाठ का हिस्सा स्पैम शब्दों को संतुलित करने के लिए।

अंत में, उन्होंने गलत सकारात्मक के खिलाफ पूर्वाग्रह नहीं किया। मुझे लगता है किसी भी स्पैम फ़िल्टरिंग एल्गोरिथम में एक सुविधाजनक होना चाहिए घुंडी जिसे आप फ़िल्टरिंग दर की कीमत पर कम करने के लिए मोड़ सकते हैं गलत सकारात्मक दर। मैं नॉनस्पैम कॉर्पस में टोकन की घटनाओं की गणना करके ऐसा करता हूं।

मुझे नहीं लगता कि स्पैम फ़िल्टरिंग को सीधे टेक्स्ट वर्गीकरण समस्या के रूप में मानना ​​एक अच्छा विचार है। आप टेक्स्ट वर्गीकरण तकनीकों का उपयोग कर सकते हैं, लेकिन समाधान ऐसा हो सकता है और होना चाहिए जो इस तथ्य को दर्शाता है कि टेक्स्ट ईमेल है, और विशेष रूप से स्पैम। ईमेल केवल टेक्स्ट नहीं है; इसमें संरचना है। स्पैम फ़िल्टरिंग केवल वर्गीकरण नहीं है, क्योंकि गलत सकारात्मक गलत नकारात्मक से बहुत बदतर हैं कि आपको उन्हें एक अलग प्रकार की त्रुटि के रूप में मानना ​​चाहिए। और त्रुटि का स्रोत केवल यादृच्छिक भिन्नता नहीं है, बल्कि आपके फ़िल्टर को हराने के लिए सक्रिय रूप से काम करने वाला एक जीवित मानव स्पैमर है।

टोकन

स्लैशडॉट लेख के बाद मैंने एक और प्रोजेक्ट के बारे में सुना था जो बिल येरज़ुनिस का CRM114 [5] था। यह उस डिज़ाइन सिद्धांत का प्रति उदाहरण है जिसका मैंने अभी उल्लेख किया है। यह एक सीधा टेक्स्ट क्लासिफायर है, लेकिन इतना आश्चर्यजनक रूप से प्रभावी है कि यह स्पैम को लगभग पूरी तरह से फ़िल्टर करने का प्रबंधन करता है, यह भी जाने बिना कि यह क्या कर रहा है।

एक बार जब मैं समझ गया कि CRM114 कैसे काम करता है, तो यह अपरिहार्य लग रहा था कि मुझे अंततः एकल शब्दों के आधार पर फ़िल्टरिंग से इस तरह के दृष्टिकोण पर जाना होगा। लेकिन पहले, मैंने सोचा, मैं देखूंगा कि मैं एकल शब्दों से कितनी दूर जा सकता हूं। और इसका उत्तर है, आश्चर्यजनक रूप से दूर।

मैं ज्यादातर स्मार्ट टोकेनाइजेशन पर काम कर रहा हूं। वर्तमान स्पैम पर, मैं फ़िल्टरिंग दरें प्राप्त करने में सक्षम रहा हूं जो CRM114 के करीब हैं। ये तकनीकें ज्यादातर बिल की तकनीकों के लिए लंबवत हैं; एक इष्टतम समाधान दोनों को शामिल कर सकता है।

``स्पैम के लिए एक योजना'' एक टोकन की बहुत ही सरल परिभाषा का उपयोग करता है। अक्षर, अंक, डैश, एपोस्ट्रोफ़ी और डॉलर चिह्न घटक वर्ण हैं, और बाकी सब कुछ टोकन विभाजक है। मैंने केस को भी अनदेखा किया।

अब मेरे पास एक टोकन की अधिक जटिल परिभाषा है:

केस संरक्षित है।

विस्मयादिबोधक चिह्न घटक वर्ण हैं।

अवधि और अल्पविराम घटक होते हैं यदि वे दो अंकों के बीच होते हैं। इससे मुझे आईपी पते और कीमतें बरकरार रखने में मदद मिलती है।

$20-25 जैसी मूल्य सीमा दो टोकन उत्पन्न करती है, $20 और $25।

टोकन जो To, From, Subject, और Return-Path लाइनों के भीतर, या URL के भीतर होते हैं, उन्हें तदनुसार चिह्नित किया जाता है। उदाहरण के लिए Subject लाइन में ``foo'' Subject*foo बन जाता है। (तारांकन चिह्न कोई भी वर्ण हो सकता है जिसे आप घटक के रूप में अनुमति नहीं देते हैं।)

इस तरह के उपाय फ़िल्टर की शब्दावली को बढ़ाते हैं, जो इसे और अधिक भेदभावपूर्ण बनाता है। उदाहरण के लिए, वर्तमान फ़िल्टर में, Subject लाइन में ``free'' की स्पैम संभावना 98% है, जबकि शरीर में समान टोकन की स्पैम संभावना केवल 65% है।

यहां कुछ वर्तमान संभावनाएं [6] दी गई हैं:

SubjectFREE 0.9999 free!! 0.9999 Tofree 0.9998 Subjectfree 0.9782 free! 0.9199 Free 0.9198 Urlfree 0.9091 FREE 0.8747 From*free 0.7636 free 0.6546

स्पैम के लिए योजना फ़िल्टर में, इन सभी टोकन की समान संभावना होती, .7602। उस फ़िल्टर ने लगभग 23,000 टोकन पहचाने। वर्तमान में लगभग 187,000 को पहचानता है।

टोकन के बड़े ब्रह्मांड होने का नुकसान यह है कि चूक की अधिक संभावना है। अपने कॉर्पस को अधिक टोकन में फैलाने का प्रभाव इसे छोटा करने जैसा ही होता है। यदि आप विस्मयादिबोधक चिह्नों को घटक के रूप में मानते हैं, उदाहरण के लिए, तो आप सात विस्मयादिबोधक चिह्नों के साथ मुफ्त के लिए स्पैम संभावना नहीं रख सकते हैं, भले ही आप जानते हैं कि केवल दो विस्मयादिबोधक चिह्नों के साथ मुफ्त की संभावना 99.99% है।

इसका एक समाधान वह है जिसे मैं पतन कहता हूं। यदि आप किसी टोकन के लिए सटीक मिलान नहीं पा सकते हैं, तो इसे कम विशिष्ट संस्करण के रूप में मानें। मैं टर्मिनल विस्मयादिबोधक चिह्नों, अपरकेस अक्षरों और पांच चिह्नित संदर्भों में से एक में होने पर एक टोकन को अधिक विशिष्ट बनाने पर विचार करता हूं। उदाहरण के लिए, यदि मुझे Subject*free!'' के लिए कोई संभावना नहीं मिलती है, तो मैं Subject*free'', free!'' और free'' के लिए संभावनाओं की तलाश करता हूं, और जो भी .5 से सबसे दूर है उसे लेता हूं।

यहां विकल्प [7] दिए गए हैं जिन पर विचार किया जाता है यदि फ़िल्टर Subject लाइन में ``FREE!!!'' देखता है और इसके लिए कोई संभावना नहीं है।

विषयमुफ़्त!!! विषयमुफ़्त!!! विषयमुफ़्त! विषयमुफ़्त! विषयमुफ़्त! विषयमुफ़्त विषयमुफ़्त विषयमुफ़्त मुफ़्त!!! मुफ़्त!!! मुफ़्त!!! मुफ़्त! मुफ़्त! मुफ़्त! मुफ़्त मुफ़्त मुफ़्त

अगर आप ऐसा करते हैं, तो शुरुआती कैप्स वाले संस्करणों के साथ-साथ सभी अपरकेस और सभी लोअरकेस पर भी विचार करना सुनिश्चित करें। स्पैम में आज्ञावादी मूड में अधिक वाक्य होते हैं, और उनमें पहला शब्द एक क्रिया होता है। इसलिए शुरुआती कैप्स वाली क्रियाओं की स्पैम संभावनाएं सभी लोअरकेस की तुलना में अधिक होती हैं। मेरे फ़िल्टर में, Act'' की स्पैम संभावना 98% है और act'' के लिए केवल 62% है।

अगर आप अपने फ़िल्टर की शब्दावली बढ़ाते हैं, तो आप अपनी ``समान'' की पुरानी परिभाषा के अनुसार एक ही शब्द को कई बार गिन सकते हैं। तार्किक रूप से, वे अब समान टोकन नहीं हैं। लेकिन अगर यह आपको अभी भी परेशान करता है, तो मुझे अनुभव से जोड़ने दें कि जिन शब्दों को आप कई बार गिन रहे हैं, वे वही हैं जिन्हें आप चाहते हैं।

एक बड़ी शब्दावली का एक और प्रभाव यह है कि जब आप आने वाले मेल को देखते हैं तो आपको अधिक दिलचस्प टोकन मिलते हैं, जिसका अर्थ है कि .5 से बहुत दूर संभावनाएं हैं। मैं मेल स्पैम है या नहीं, यह तय करने के लिए 15 सबसे दिलचस्प का उपयोग करता हूं। लेकिन जब आप इस तरह की निश्चित संख्या का उपयोग करते हैं तो आपको एक समस्या का सामना करना पड़ सकता है। यदि आपको बहुत सारे अधिकतम दिलचस्प टोकन मिलते हैं, तो परिणाम समान रूप से दिलचस्प टोकन के क्रम को निर्धारित करने वाले यादृच्छिक कारक द्वारा तय किया जा सकता है। इससे निपटने का एक तरीका कुछ को दूसरों की तुलना में अधिक दिलचस्प मानना ​​है।

उदाहरण के लिए, टोकन dalco'' मेरे स्पैम कॉर्पस में 3 बार होता है और मेरे वैध कॉर्पस में कभी नहीं होता है। टोकन Url*optmails'' (जिसका अर्थ है ``optmails'' एक url के भीतर) 1223 बार होता है। और फिर भी, जैसा कि मैं टोकन के लिए संभावनाओं की गणना करता था, दोनों की स्पैम संभावना समान होगी, .99 की सीमा।

यह सही नहीं लगता। इन दो टोकन को काफी अलग संभावनाएं देने के लिए सैद्धांतिक तर्क हैं (पैंटेल और लिन करते हैं), लेकिन मैंने अभी तक ऐसा करने की कोशिश नहीं की है। ऐसा लगता है कि कम से कम अगर हमें 15 से अधिक टोकन मिलते हैं जो केवल एक कॉर्पस में होते हैं या दूसरे में होते हैं, तो हमें उन लोगों को प्राथमिकता देनी चाहिए जो बहुत अधिक होते हैं। तो अब दो थ्रेशोल्ड मान हैं। स्पैम कॉर्पस में केवल होने वाले टोकन के लिए, संभावना .9999 है यदि वे 10 से अधिक बार होते हैं और .9998 अन्यथा। वैध कॉर्पस में केवल पाए जाने वाले टोकन के लिए पैमाने के दूसरे छोर पर भी ऐसा ही है।

मैं बाद में टोकन संभावनाओं को काफी हद तक स्केल कर सकता हूं, लेकिन स्केलिंग की यह छोटी मात्रा कम से कम यह सुनिश्चित करती है कि टोकन सही तरीके से सॉर्ट हो जाएं।

एक और संभावना यह होगी कि केवल 15 टोकन पर विचार न करें, बल्कि दिलचस्पता की एक निश्चित सीमा से अधिक सभी टोकन पर विचार करें। स्टीवन हॉसर अपने सांख्यिकीय स्पैम फ़िल्टर [8] में ऐसा करते हैं। यदि आप एक थ्रेशोल्ड का उपयोग करते हैं, तो इसे बहुत अधिक बनाएं, या स्पैमर आपको अधिक निर्दोष शब्दों के साथ संदेश पैक करके धोखा दे सकते हैं।

अंत में, html के बारे में क्या करना चाहिए? मैंने विकल्पों के पूरे स्पेक्ट्रम की कोशिश की है, इसे अनदेखा करने से लेकर इसे पूरी तरह से पार्स करने तक। html को अनदेखा करना एक बुरा विचार है, क्योंकि यह उपयोगी स्पैम संकेतों से भरा है। लेकिन अगर आप इसे पूरी तरह से पार्स करते हैं, तो आपका फ़िल्टर केवल एक html पहचानकर्ता में बदल सकता है। सबसे प्रभावी दृष्टिकोण मध्य मार्ग प्रतीत होता है, कुछ टोकन को नोटिस करना लेकिन अन्य को नहीं। मैं a, img, और font टैग देखता हूं, और बाकी को अनदेखा करता हूं। लिंक और छवियों को आपको निश्चित रूप से देखना चाहिए, क्योंकि उनमें url होते हैं।

मैं शायद html से निपटने के बारे में अधिक चालाक हो सकता हूं, लेकिन मुझे नहीं लगता कि इसमें बहुत समय लगाना उचित है। html से भरे स्पैम को फ़िल्टर करना आसान है। होशियार स्पैमर पहले से ही इससे बचते हैं। इसलिए भविष्य में प्रदर्शन इस बात पर बहुत अधिक निर्भर नहीं होना चाहिए कि आप html से कैसे निपटते हैं।

प्रदर्शन

10 दिसंबर 2002 और 10 जनवरी 2003 के बीच मुझे लगभग 1750 स्पैम मिले। इनमें से 4 निकल गए। यह लगभग 99.75% की फ़िल्टरिंग दर है।

मेरे द्वारा छूटे हुए चार स्पैम में से दो निकल गए क्योंकि वे मेरे वैध ईमेल में अक्सर आने वाले शब्दों का उपयोग करते थे।

तीसरा एक ऐसा था जो तीसरे पक्ष को मेल भेजने के लिए असुरक्षित सीजीआई स्क्रिप्ट का फायदा उठाता है। सिर्फ़ सामग्री के आधार पर उन्हें फ़िल्टर करना मुश्किल है क्योंकि हेडर निर्दोष होते हैं और वे इस्तेमाल किए जाने वाले शब्दों के बारे में सावधान रहते हैं। फिर भी मैं आमतौर पर उन्हें पकड़ सकता हूँ। यह एक .88 की संभावना के साथ निकल गया, जो .9 की सीमा से कम है।

बेशक, कई टोकन अनुक्रमों को देखने से यह आसानी से पकड़ा जा सकता है। ``आपके फीडबैक फॉर्म का परिणाम नीचे दिया गया है'' एक तुरंत देनदार है।

चौथा स्पैम वह है जिसे मैं भविष्य का स्पैम कहता हूँ, क्योंकि मुझे उम्मीद है कि स्पैम इस तरह विकसित होगा: कुछ पूरी तरह से तटस्थ पाठ के बाद एक यूआरएल। इस मामले में यह किसी से था जो कह रहा था कि उसने आखिरकार अपना होमपेज पूरा कर लिया है और क्या मैं उसे देखूँगा। (पेज बेशक एक पॉर्न साइट का विज्ञापन था।)

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

अब वास्तव में चौंकाने वाली खबर: उसी एक महीने के दौरान मुझे तीन झूठे पॉजिटिव मिले।

एक तरह से यह कुछ झूठे पॉजिटिव पाने के लिए राहत की बात है। जब मैंने ``स्पैम के लिए एक योजना'' लिखी थी तो मेरे पास कोई नहीं था, और मुझे नहीं पता था कि वे कैसे होंगे। अब जब मेरे पास कुछ हैं, तो मुझे यह जानकर राहत मिली है कि वे उतने बुरे नहीं हैं जितना मैंने सोचा था। सांख्यिकीय द्वारा प्राप्त झूठे पॉजिटिव फ़िल्टर ऐसे मेल निकलते हैं जो स्पैम की तरह लगते हैं, और ये वे होते हैं जिन्हें आप कम से कम याद करने का मन करेंगे [9]।

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

तीसरा झूठे पॉजिटिव हालांकि एक बुरा था। यह मिस्र के किसी व्यक्ति से था और पूरी तरह से अपरकेस में लिखा गया था। यह टोकन केस संवेदनशील बनाने का सीधा परिणाम था; स्पैम के लिए योजना फ़िल्टर इसे नहीं पकड़ पाया होगा।

कुल झूठे पॉजिटिव दर क्या है, यह कहना मुश्किल है, क्योंकि हम सांख्यिकीय रूप से शोर में हैं। जिसने भी फ़िल्टर (कम से कम, प्रभावी फ़िल्टर) पर काम किया है, वह इस समस्या से अवगत होगा। कुछ ईमेल के साथ यह कहना मुश्किल है कि वे स्पैम हैं या नहीं, और ये वे हैं जिन्हें आप देखते हैं जब आप फ़िल्टर प्राप्त करते हैं वास्तव में तंग। उदाहरण के लिए, अब तक फ़िल्टर ने दो ईमेल पकड़े हैं जो मेरे पते पर भेजे गए थे क्योंकि एक टाइपो, और एक मुझे इस विश्वास में भेजा गया था कि मैं कोई और था। तर्क के तौर पर, ये न तो मेरे स्पैम हैं और न ही मेरा नॉनस्पैम मेल।

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

इन्हें नहीं गिनते हुए, मेरे पास अब तक कुल पाँच झूठे पॉजिटिव हैं लगभग 7740 वैध ईमेल में से, .06% की दर। अन्य दो एक नोटिस थे कि मैंने जो कुछ खरीदा था वह बैक-ऑर्डर किया गया था, और इवाइट से एक पार्टी रिमाइंडर।

मुझे नहीं लगता कि इस संख्या पर भरोसा किया जा सकता है, आंशिक रूप से क्योंकि नमूना बहुत छोटा है, और आंशिक रूप से क्योंकि मुझे लगता है कि मैं फ़िल्टर को ठीक कर सकता हूँ ताकि वह पकड़ न सके इनमें से कुछ।

झूठे पॉजिटिव मुझे झूठे नकारात्मक से अलग तरह की त्रुटि लगते हैं। फ़िल्टरिंग दर प्रदर्शन का एक माप है। झूठा पॉजिटिव मैं बग की तरह मानता हूँ। मैं फ़िल्टरिंग में सुधार के लिए दृष्टिकोण करता हूँ दर को अनुकूलन के रूप में, और झूठे को कम करना पॉजिटिव को डिबगिंग के रूप में।

तो ये पाँच गलत पॉजिटिव मेरी बग लिस्ट हैं। उदाहरण के लिए, मिस्र से आया मेल इसलिए फंस गया क्योंकि ऊपरी केस टेक्स्ट ने उसे फिल्टर के लिए नाइजीरियाई स्पैम की तरह दिखाया। यह वास्तव में एक तरह की बग है। जैसे html के साथ, ईमेल का पूरी तरह से ऊपरी केस होना वास्तव में एक फीचर है, न कि प्रत्येक शब्द के लिए एक। मुझे केस को संभालने की जरूरत है अधिक परिष्कृत तरीके से।

तो इस .06% का क्या मतलब है? कुछ नहीं, मुझे लगता है। आप इसे ऊपरी सीमा के रूप में मान सकते हैं, छोटे नमूना आकार को ध्यान में रखते हुए। लेकिन इस स्तर पर यह मेरे कार्यान्वयन में बग का अधिक माप है बेजियन फ़िल्टरिंग की कुछ आंतरिक गलत सकारात्मक दर से।

भविष्य

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

उदाहरण के लिए, स्पैमर अब फ़िल्टर से बचने के लिए आक्रामक रूप से काम कर रहे हैं, और वे जो चीजें कर रहे हैं उनमें से एक है फ़िल्टर को पहचानने से रोकने के लिए शब्दों को तोड़ना और गलत लिखना। लेकिन इस पर काम करना मेरी पहली प्राथमिकता नहीं है, क्योंकि मुझे अभी भी इन स्पैम को पकड़ने में कोई परेशानी नहीं है [10]।

दो तरह के स्पैम हैं जिनसे मुझे वर्तमान में परेशानी होती है। एक वह प्रकार है जो एक महिला से ईमेल होने का दिखावा करता है जो आपको उससे चैट करने या डेटिंग साइट पर उसकी प्रोफ़ाइल देखने के लिए आमंत्रित करती है। ये इसलिए मिल जाते हैं क्योंकि वे एक तरह की बिक्री पिच हैं जो आप बिक्री की बातों का उपयोग किए बिना कर सकते हैं। वे उपयोग करते हैं सामान्य ईमेल जैसी ही शब्दावली।

दूसरे प्रकार के स्पैम जिन्हें फ़िल्टर करने में मुझे परेशानी होती है, वे हैं बल्गेरिया की कंपनियों से जो अनुबंध प्रोग्रामिंग सेवाएँ प्रदान करती हैं। ये इसलिए मिल जाते हैं क्योंकि मैं भी एक प्रोग्रामर हूँ, और स्पैम मेरे असली मेल जैसे ही शब्दों से भरे हुए हैं।

मैं शायद पहले व्यक्तिगत विज्ञापन प्रकार पर ध्यान केंद्रित करूँगा। मुझे लगता है कि अगर मैं करीब से देखूंगा तो मैं इन और मेरे असली मेल के बीच सांख्यिकीय अंतर खोज पाऊंगा। लेखन की शैली निश्चित रूप से अलग है, हालाँकि इसे पकड़ने के लिए बहुशब्द फ़िल्टरिंग की आवश्यकता हो सकती है। इसके अलावा, मैंने देखा है कि वे यूआरएल को दोहराते हैं, और कोई व्यक्ति वैध मेल में यूआरएल शामिल करेगा तो ऐसा नहीं करेगा [11]।

आउटसोर्सिंग प्रकार को पकड़ना मुश्किल होने वाला है। यहां तक ​​कि अगर आपने साइट पर एक क्रॉलर भेजा, तो आपको धूम्रपान नहीं मिलेगा सांख्यिकीय बंदूक। शायद एकमात्र उत्तर स्पैम में विज्ञापित डोमेन की एक केंद्रीय सूची है [12]। लेकिन इस प्रकार के मेल इतने नहीं हो सकते। अगर केवल बचे हुए स्पैम बल्गेरिया से अनुबंध प्रोग्रामिंग सेवाओं के अनचाही प्रस्ताव थे, तो हम सभी शायद आगे बढ़ सकते हैं किसी और चीज पर काम करने के लिए।

क्या सांख्यिकीय फ़िल्टरिंग वास्तव में हमें उस बिंदु तक ले जाएगा? मुझे नहीं पता। अभी, मेरे लिए व्यक्तिगत रूप से, स्पैम है समस्या नहीं है। लेकिन स्पैमर ने अभी तक गंभीर प्रयास नहीं किया है सांख्यिकीय फ़िल्टर को स्पूफ करने के लिए। जब वे ऐसा करेंगे तो क्या होगा?

मैं उन फ़िल्टर के बारे में आशावादी नहीं हूँ जो काम करते हैं नेटवर्क स्तर पर [13]। जब कोई स्थिर बाधा होती है जिसके आगे निकलने लायक होती है, तो स्पैमर उसके आगे निकलने में काफी कुशल होते हैं। वहाँ पहले से ही एक कंपनी है जिसे एश्योरेंस सिस्टम्स कहा जाता है जो आपके मेल को स्पैमएसेसिन के माध्यम से चलाएगा और आपको बताएगा कि क्या यह फ़िल्टर आउट हो जाएगा।

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

जिस तरह के फ़िल्टर के बारे में मैं आशावादी हूँ, वे हैं जो प्रत्येक व्यक्तिगत उपयोगकर्ता के मेल के आधार पर संभावनाओं की गणना करें। ये बहुत अधिक प्रभावी हो सकते हैं, न केवल में गलत सकारात्मक से बचना, बल्कि फ़िल्टरिंग में भी: उदाहरण के लिए, प्राप्तकर्ता का ईमेल पता बेस-64 एन्कोडेड कहीं भी ढूँढना एक संदेश एक बहुत अच्छा स्पैम संकेतक है।

लेकिन व्यक्तिगत फ़िल्टर का असली फायदा यह है कि वे सभी अलग-अलग होंगे। अगर सभी फ़िल्टर की अलग-अलग संभावनाएँ हैं, तो यह स्पैमर के अनुकूलन लूप को, जिसे प्रोग्रामर उनके एडिट-कंपाइल-टेस्ट चक्र के रूप में बुलाते हैं, भयावह रूप से धीमा कर देगा। किसी फ़िल्टर की कॉपी के माध्यम से स्पैम को तब तक ट्विक करने के बजाय जब तक वह उनके डेस्कटॉप पर नहीं आ जाता, उन्हें प्रत्येक ट्विक के लिए एक टेस्ट मेलिंग करनी होगी। यह एक ऐसी भाषा में प्रोग्रामिंग जैसा होगा जिसमें इंटरैक्टिव टॉपलेवल नहीं है, और मैं किसी को भी यह नहीं चाहूंगा।

नोट्स

[1] पॉल ग्राहम। ``स्पैम के लिए एक योजना।'' अगस्त 2002। http://paulgraham.com/spam.html.

इस एल्गोरिथम में संभावनाएँ बेयस नियम के एक अपभ्रष्ट मामले का उपयोग करके गणना की जाती हैं। दो सरलीकृत धारणाएँ हैं: कि विशेषताओं (यानी शब्दों) की संभावनाएँ स्वतंत्र हैं, और यह कि हम किसी ईमेल के स्पैम होने की पूर्व संभावना के बारे में कुछ नहीं जानते हैं।

पहली धारणा पाठ वर्गीकरण में व्यापक है। इसका उपयोग करने वाले एल्गोरिदम को ``भोली बेयसियन'' कहा जाता है।

दूसरी धारणा मैंने इसलिए बनाई क्योंकि मेरे इनकमिंग मेल में स्पैम का अनुपात दिन-प्रतिदिन (वास्तव में, घंटे-प्रति-घंटे) इतना अधिक उतार-चढ़ाव करता था कि समग्र पूर्व अनुपात एक भविष्य कहनेवाला के रूप में बेकार लग रहा था। यदि आप मानते हैं कि P(स्पैम) और P(नॉनस्पैम) दोनों .5 हैं, तो वे रद्द हो जाते हैं और आप उन्हें सूत्र से हटा सकते हैं।

यदि आप ऐसी स्थिति में बेयसियन फ़िल्टरिंग कर रहे थे जहाँ स्पैम से नॉनस्पैम का अनुपात लगातार बहुत अधिक या (विशेष रूप से) बहुत कम था, तो आप पूर्व संभावनाओं को शामिल करके फ़िल्टर प्रदर्शन में सुधार कर सकते हैं। इसे सही करने के लिए आपको दिन के समय के अनुसार अनुपातों को ट्रैक करना होगा, क्योंकि स्पैम और वैध मेल की मात्रा दोनों में अलग-अलग दैनिक पैटर्न होते हैं।

[2] पैट्रिक पैंटेल और डेकांग लिन। ``स्पैमकॉप - एक स्पैम वर्गीकरण और संगठन कार्यक्रम।'' AAAI-98 की कार्यवाही पाठ वर्गीकरण के लिए सीखने पर कार्यशाला।

[3] मेहरन साहमी, सुसान डुमैस, डेविड हेकरमैन और एरिक हॉर्वित्ज़। ``जंक ई-मेल को फ़िल्टर करने के लिए एक बेयसियन दृष्टिकोण।'' AAAI-98 की कार्यवाही पाठ वर्गीकरण के लिए सीखने पर कार्यशाला।

[4] उस समय मेरे पास लगभग 4,000 वैध ईमेल में से शून्य गलत सकारात्मक थे। यदि अगला वैध ईमेल गलत सकारात्मक था, तो यह हमें .03% देगा। ये गलत सकारात्मक दरें अविश्वसनीय हैं, जैसा कि मैं बाद में बताता हूँ। मैं यहाँ केवल एक संख्या उद्धृत करता हूँ ताकि यह जोर दिया जा सके कि गलत सकारात्मक दर जो भी हो, वह 1.16% से कम है।

[5] बिल येराज़ुनिस। ``विरल बाइनरी बहुपद हैश संदेश फ़िल्टरिंग और CRM114 भेदक।'' 2003 की कार्यवाही स्पैम सम्मेलन।

[6] ``स्पैम के लिए एक योजना'' में मैंने .99 और .01 की थ्रेसहोल्ड का उपयोग किया। यह कॉर्पोरा के आकार के अनुपात में थ्रेसहोल्ड का उपयोग करने के लिए उचित लगता है। चूँकि मेरे पास अब प्रत्येक प्रकार के मेल के लगभग 10,000 हैं, मैं .9999 और .0001 का उपयोग करता हूँ।

[7] यहाँ एक दोष है जिसे मुझे शायद ठीक करना चाहिए। वर्तमान में, जब Subject*foo'' केवल foo'' में पतित हो जाता है, तो इसका मतलब है कि आप foo'' की घटनाओं के आँकड़े प्राप्त कर रहे हैं शरीर में या हेडर लाइनों में जो मैं चिह्नित नहीं करता। मुझे जो करना चाहिए वह है foo'' के आँकड़ों का ट्रैक रखना कुल मिलाकर साथ ही विशिष्ट संस्करण, और Subject*foo'' से foo'' में नहीं बल्कि ``Anywhere*foo'' में पतित होना। केस के लिए भी ऐसा ही: मुझे अपरकेस से किसी भी केस में पतित होना चाहिए, लोअरकेस में नहीं।

यह शायद कीमतों के साथ ऐसा करने के लिए एक जीत होगी भी, उदा. $129.99'' से $--9.99'', $--.99'', और $--'' में पतित होना।

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

[8] स्टीवन हॉसर। ``सांख्यिकीय स्पैम फ़िल्टर मेरे लिए काम करता है।'' http://www.sofbot.com.

[9] गलत सकारात्मक सभी समान नहीं होते हैं, और हमें स्पैम को रोकने के लिए तकनीकों की तुलना करते समय इसे याद रखना चाहिए। जबकि फ़िल्टर के कारण होने वाले कई गलत सकारात्मक लगभग-स्पैम होंगे जिन्हें आप याद करने से नहीं चूकेंगे, ब्लैकलिस्ट के कारण होने वाले गलत सकारात्मक, उदाहरण के लिए, केवल उन लोगों से मेल होंगे जिन्होंने गलत ISP चुना। दोनों मामलों में आप मेल पकड़ते हैं जो लगभग स्पैम है, लेकिन ब्लैकलिस्ट के लिए निकटता भौतिक है, और फ़िल्टर के लिए यह पाठ्य है।

[10] यदि स्पैमर इस समस्या को हल करने के लिए टोकन को छिपाने में सक्षम हो जाते हैं, तो हम बस व्हाइटस्पेस, पीरियड, कॉमा, आदि को हटाकर और परिणामी अनुक्रम से शब्दों को चुनने के लिए एक डिक्शनरी का उपयोग करके प्रतिक्रिया दे सकते हैं। और निश्चित रूप से इस तरह से शब्दों को खोजना जो मूल पाठ में दिखाई नहीं दे रहे थे, अपने आप में स्पैम का प्रमाण होगा।

शब्दों को चुनना तुच्छ नहीं होगा। इसमें केवल शब्द सीमाओं का पुनर्निर्माण करने से कहीं अधिक की आवश्यकता होगी; स्पैमर दोनों जोड़ते हैं (xHot nPorn cSite'') और अक्षरों को छोड़ देते हैं (P#rn'')। यहां दृष्टि अनुसंधान उपयोगी हो सकता है, क्योंकि मानव दृष्टि वह सीमा है जिसके पास ऐसी चालें पहुंचेंगी।

[11] सामान्य तौर पर, स्पैम नियमित ईमेल की तुलना में अधिक दोहराव वाले होते हैं। वे उस संदेश को घर पर पटकना चाहते हैं। मैं वर्तमान में शीर्ष 15 टोकन में डुप्लिकेट की अनुमति नहीं देता, क्योंकि यदि प्रेषक किसी खराब शब्द का कई बार उपयोग करता है तो आपको एक गलत सकारात्मक मिल सकता है। (मेरे वर्तमान फ़िल्टर में, ``dick'' की स्पैम संभावना .9999 है, लेकिन यह एक नाम भी है।) ऐसा लगता है कि हमें कम से कम दोहराव पर ध्यान देना चाहिए, इसलिए मैं स्पैमप्रोब में ब्रायन बर्टन की तरह प्रत्येक टोकन के दो तक की अनुमति देने का प्रयास कर सकता हूं।

[12] यह वह है जिसके लिए ब्राइटमेल जैसे दृष्टिकोण पतन हो जाएंगे एक बार जब स्पैमर संदेश में बाकी सब कुछ उत्पन्न करने के लिए पागल-लिब तकनीकों का उपयोग करने के लिए मजबूर हो जाते हैं।

[13] कभी-कभी यह तर्क दिया जाता है कि हमें नेटवर्क स्तर पर फ़िल्टरिंग पर काम करना चाहिए, क्योंकि यह अधिक कुशल है। लोग आमतौर पर जब यह कहते हैं तो उनका मतलब होता है: हम वर्तमान में नेटवर्क स्तर पर फ़िल्टर करते हैं, और हम खरोंच से शुरू नहीं करना चाहते हैं। लेकिन आप अपने समाधान को फिट करने के लिए समस्या को निर्धारित नहीं कर सकते।

ऐतिहासिक रूप से, दुर्लभ-संसाधन तर्क सॉफ़्टवेयर डिज़ाइन के बारे में बहसों में हारने वाला पक्ष रहा है। लोग केवल उनका उपयोग अन्य कारणों से किए गए विकल्पों (विशेष रूप से निष्क्रियता) को सही ठहराने के लिए करते हैं।

धन्यवाद सारा हार्लिन, ट्रेवर ब्लैकवेल और डैन गिफिन को इस पेपर के ड्राफ्ट पढ़ने के लिए, और डैन को फिर से इस फ़िल्टर के चलने वाले अधिकांश बुनियादी ढांचे के लिए।

संबंधित:

SubjectFREE 0.9999 free!! 0.9999 Tofree 0.9998 Subjectfree 0.9782 free! 0.9199 Free 0.9198 Urlfree 0.9091 FREE 0.8747 From*free 0.7636 free 0.6546

SubjectFree!!! Subjectfree!!! SubjectFREE! SubjectFree! Subjectfree! SubjectFREE SubjectFree Subjectfree FREE!!! Free!!! free!!! FREE! Free! free! FREE Free free