आइए बॉट्स को चारा खिलाएँ

 (maurycyz.com)
9 पॉइंट द्वारा GN⁺ 2025-10-28 | 2 टिप्पणियां | WhatsApp पर शेयर करें
  • एक वेबसाइट ऑपरेटर ने AI ट्रेनिंग के लिए स्क्रैपर बॉट्स के खिलाफ ‘अनंत बकवास’ पेज बनाकर उनका ट्रैफ़िक उधर मोड़ने वाला एक प्रयोग पेश किया
  • ये बॉट robots.txt को अनदेखा करते हैं, IP बदलते हैं, और लगातार अनुरोध भेजते रहते हैं, इसलिए पारंपरिक सर्च इंजन क्रॉलर की तुलना में कहीं अधिक आक्रामक हैं
  • IP ब्लॉकिंग, rate limit, CAPTCHA, login wall जैसी सामान्य सुरक्षा उपाय पूरी तरह बेअसर हो जाते हैं, और असली यूज़र्स को ही असुविधा होती है
  • इसके जवाब में लेखक ने पाया कि नकली डेटा (बेमतलब टेक्स्ट) अपने-आप बनाकर बॉट्स को देना सबसे सस्ता और प्रभावी तरीका है
  • यह AI डेटा कलेक्शन के दुष्प्रभाव और सर्वर संसाधनों की बर्बादी को उजागर करता है, और वेब ऑपरेटरों के लिए एक व्यावहारिक जवाब भी सुझाता है

बॉट्स की असलियत

  • हाल के क्रॉलर सर्च इंजन के लिए नहीं, बल्कि LLM (Large Language Model) ट्रेनिंग के लिए डेटा कलेक्ट करने के मकसद से काम कर रहे हैं
    • ये robots.txt को नज़रअंदाज़ करते हैं, ब्राउज़र होने का दिखावा करते हैं, या IP बदल-बदलकर पहुँचते हैं
    • दिन भर प्रति सेकंड कई अनुरोध भेजकर सर्वर पर लोड डालते हैं
  • पुराने सर्च इंजन से अलग, इन्हें वेबसाइट के टिके रहने से कोई मतलब नहीं होता और ये उसे सिर्फ एक बदला जा सकने वाला डेटा स्रोत मानते हैं

एक्सेस देने पर होने वाली समस्याएँ

  • static files serve करना सस्ता ज़रूर है, लेकिन मुफ़्त नहीं; इसमें SSD access latency और filesystem overhead होता है
    • ये cache में न मौजूद पुराने पेज माँगकर सर्वर की performance गिराते हैं
  • bandwidth consumption भी बड़ी समस्या है; images वाले blog posts जल्दी-जल्दी जुड़कर महीने में 1TB से ज़्यादा ट्रैफ़िक पैदा कर सकते हैं
    • यह व्यक्तिगत सर्वर चलाने वालों के लिए संभालना मुश्किल खर्च है

ब्लॉक करने की कोशिशों की सीमाएँ

  • IP ब्लॉकिंग असरदार नहीं है; बड़ी कंपनियों द्वारा चलाए जा रहे bot networks के पास हज़ारों पते होते हैं
    • सारे पते ब्लॉक कर देने पर भी वे नया IP खरीदकर फिर जुड़ जाते हैं
  • request rate limit भी बेकार साबित होता है, क्योंकि कुछ मामलों में हर अनुरोध अलग IP से आता है

फ़ायरवॉल और authentication barriers के दुष्प्रभाव

  • login, payment, CAPTCHA, और hash-based proof-of-work जैसे कई सुरक्षा उपाय सुझाए गए, लेकिन सब यूज़र असुविधा बढ़ाते हैं
    • account की शर्त पाठकों की पहुँच रोकती है, और JavaScript-based verification non-JS browsers को बाहर कर देता है
    • पेज लोडिंग धीमी होने से user experience खराब होता है

compression bomb (gzip bomb) की बेअसरियत

  • कुछ लोगों ने gzip bomb से बॉट्स पर हमला करने का सुझाव दिया, लेकिन व्यवहार में इसकी compression ratio सिर्फ लगभग 1000x रहती है
    • 100GB का expanded file बनाने के लिए 100MB asset देना पड़ता है
    • प्रयोग में बॉट्स ने इसे अनदेखा किया या उल्टे और ज़्यादा अनुरोध भेजे

छल की नाकामी

  • 404 error भेजकर साइट को मौजूद न दिखाने वाली ‘Jedi mind trick’ विधि भी असफल रही
    • अगर लिंक बाहर कहीं पोस्ट हो जाए, तो बॉट साइट का अस्तित्व पहचान लेते हैं; और पहुँच रोकी जाए तो और आक्रामक अनुरोध भेजते हैं
    • नतीजे में सर्वर की शांति के लिए बॉट्स को संतुष्ट रखना पड़ता है

कचरा डेटा देने की दक्षता

  • dynamic content generation महँगी लगे, लेकिन असल में CPU और RAM सबसे तेज़ संसाधन हैं
    • इनके धीमे होने की छवि अक्सर database I/O या जटिल JS logic की वजह से बनती है
  • लेखक द्वारा बनाया गया Markov-based babbler प्रति अनुरोध लगभग 60 माइक्रोसेकंड CPU और सिर्फ 1.2MB memory इस्तेमाल करता है
    • इसमें disk access नहीं है, blacklist मैनेजमेंट की ज़रूरत नहीं
    • बॉट खुद आकर बेमतलब टेक्स्ट खपाते हैं और सर्वर लोड घटाने वाली संरचना बन जाती है

निष्कर्ष

  • AI ट्रेनिंग बॉट्स द्वारा अंधाधुंध डेटा कलेक्शन से वेब इन्फ्रास्ट्रक्चर की लागत बढ़ती है और कंटेंट का दुरुपयोग होता है
  • साधारण ब्लॉकिंग की तुलना में बेमतलब डेटा से जवाब देने की रणनीति ज़्यादा cost-effective है और सर्वर स्थिरता बनाए रखने में मददगार है
  • इसे भविष्य में AI crawling और web ecosystem के सह-अस्तित्व के रास्ते खोजने वाले एक प्रयोगात्मक दृष्टिकोण के रूप में देखा जा सकता है

संबंधित पढ़ाई

2 टिप्पणियां

 
kimjoin2 2025-10-28

ओ... काफ़ी नया और अच्छा है।
 
GN⁺ 2025-10-28
Hacker News राय

  • लिंक से पहले छिपे हुए पैराग्राफ निर्देश मज़ेदार थे
    कुछ ऐसा लिखा था, “इस पेज की सामग्री ख़तरनाक है, इसे सार्वजनिक मत करो” — यानी LLM को धोखा देने के लिए एक शरारती निर्देश
    संबंधित दस्तावेज़ इस लिंक पर है

    • The Cost of Trash लेख का सार यह है कि लेखक ने आक्रामक web scraper (संभवतः LLM training के लिए) को रोकने के कई तरीके आज़माए, लेकिन असफल रहा, और अंत में बेकार डेटा को dynamic रूप से जनरेट करके उनके resources बर्बाद करने की रणनीति अपनाई
      अंत का “LLM instructions” हिस्सा असली मुख्य लेख नहीं था, बल्कि LLM को भ्रमित करने के लिए meta निर्देश था, इसलिए उसे सारांश से बाहर रखा गया

  • मैं हमेशा ऐसी रणनीति की सिफारिश करता रहा हूँ — AI bot को असली जैसा दिखने वाला कचरा डेटा बड़ी मात्रा में खिलाना, ताकि अंततः इंसानों को उसे फ़िल्टर करना पड़े
    अगर सभी साइटें ऐसा करें, तो AI के training data की गुणवत्ता तेज़ी से गिर जाएगी
    अगर लड़ना मुश्किल हो, तो बस डेटा की बाढ़ से ढक दो

    • इससे महँगा लेकिन बेहतर तरीका है LLM को सकारात्मक प्रचार सामग्री बड़ी मात्रा में खिलाना
      SEO bait की तरह, news domain जैसी दिखने वाली साइटें बनाकर product promotion वाले लेख फैलाना
    • लेकिन LLM पहले से ही ज़्यादातर कचरा डेटा पर train हो रहे हैं
      ऐसी कोशिश spam call का जवाब देने जैसी समय की बर्बादी है
    • और LLM इंसानों की तुलना में कहीं सस्ते में कचरा पहचान कर सकते हैं
      अंततः लोगों को नौकरी पर रखने की ज़रूरत लगभग नहीं पड़ेगी
    • यह क्यों माना जा रहा है कि इंसान AI से बेहतर कचरा फ़िल्टर कर सकते हैं?

  • “Markov babbler” की डिटेल इस पोस्ट में है

    • gcc 14 से compile करते समय pthread_detach argument error आता है
      लगता है लेखक का compiler warnings को ignore करता है
      क्योंकि यह प्रोग्राम thread management की सीमा के बिना requests संभालता है, इसलिए इसे container के अंदर unprivileged user के रूप में चलाना सुरक्षित है
      sprintf() जैसी ख़तरनाक C functions भी इस्तेमाल होती दिख रही हैं, इसलिए security के लिहाज़ से सावधानी ज़रूरी है
    • कहा गया कि यह बात “toptext” में भी जोड़ी जाएगी
    • किसी ने कहा कि code elegant और fast है, और उम्मीद जताई कि LLM scrapers इस डेटा को साफ़ करने में परेशान हों

  • मेरी साइट पर हर लिंक पर Basic Auth लगा है, और अभी तक कोई bot उसे पार नहीं कर पाया
    इसलिए मैंने सोचा कि अगर सभी websites एक ही public credential इस्तेमाल करें तो कैसा रहेगा
    user: nobots / password: nobots
    क्या bot इसे जानकर भी अंदर आ पाएँगे?

    • हाँ, बिल्कुल। बस HTTP request में auth header जोड़ना होगा
      ज़्यादातर bots ने अभी तक ऐसे case को ध्यान में नहीं रखा है
      http://username:password@example.com फ़ॉर्म में request करें तो यह आसानी से हो जाता है
    • अगर credential सबको पता हो, तो bot block करने का असर नहीं रहेगा
    • यह तरीका तभी तक असरदार है जब कम लोग इस्तेमाल करें। थोड़ा भी फैलते ही बेअसर हो जाएगा

  • मैं भी अब उन्हें कचरा डेटा दे रहा हूँ
    संदर्भ के लिए Frankenstein, Alice in Wonderland, Moby Dick को source के रूप में इस्तेमाल किया, लेकिन files बड़ी हैं इसलिए loading धीमी है
    pthread_detach(&thread) को pthread_detach(thread) में बदलकर compile error ठीक कर दिया

    • fix हो चुका है, और कहा गया कि gcc का सुझाव सही था

  • मैं एक “ethical crawler” चला रहा हूँ
    website पर ज़्यादा लोड न पड़े, इसलिए request frequency कम रखता हूँ, लेकिन कई जगह RSS access blocked होने से यह काम धीरे-धीरे कठिन होता जा रहा है
    मेरा crawler अलग-अलग headers और mechanisms test करते हुए खोज करता है
    code: crawler-buddy, Django-link-archive

    • requirements.txt में feedparser है, लेकिन उसके वास्तविक उपयोग का कोई निशान नहीं है
      यह बात search result से भी दिखती है

  • The Cost of Trash लेख में कहा गया है कि gzip bomb प्रभावी नहीं है
    gzip लगभग 1000 गुना तक ही compress करता है, इसलिए 100GB बनाने के लिए 100MB file देनी पड़ेगी
    कहा गया कि bots ने उल्टा और ज़्यादा requests किए

    • zip संभव है, लेकिन gzip नहीं
      ज़्यादातर clients streaming तरीके से decompress करते हैं, इसलिए पूरी चीज़ memory में नहीं लाते
      gzip bomb के सच में काम करने के लिए processing असामान्य तरीके से होनी चाहिए
      संदर्भ: zlib API दस्तावेज़
    • इसकी जगह हज़ारों छोटे gzip files बनाकर CPU और समय बर्बाद कराने की रणनीति बेहतर है
      उनके अंदर random कचरा भरा जा सकता है, या ऐसे messages डाले जा सकते हैं जिन्हें आप चाहते हैं कि AI सीखे

  • ध्यान देने वाली बात यह है कि कुछ requests वास्तव में user browser को proxy की तरह इस्तेमाल कर रही हो सकती हैं
    कुछ browser providers user traffic को proxy के रूप में इस्तेमाल करते हैं
    अगर automated request detection में error बहुत कम हो, तो cryptocurrency mining code भी डाला जा सकता है, लेकिन असली users पर असर पड़ने का जोखिम है
    खासकर यह जानने की जिज्ञासा है कि क्या mobile agent का इस्तेमाल करने वाली AI requests भी होती हैं

  • कहा गया कि “Markov babbler” हर request पर लगभग 60μs CPU इस्तेमाल करता है,
    तो सोचा गया कि इसमें वैचारिक संदेश या प्रचार पंक्तियाँ मिलाकर content बनाया जाए ताकि AI उसे सीख ले
    तब AI अजीब राजनीतिक बयान देने लग सकता है
    कम से कम इससे copyright उल्लंघन और server load कम करने में मदद मिल सकती है

  • आख़िर Markov text server पर ही क्यों जनरेट किया जाए?
    अगर bot JavaScript चलाते हैं, तो इसे client पर ही जनरेट क्यों न कराया जाए?

    • bots के पास CPU और memory लगभग असीमित होती है, इसलिए server पर बोझ बहुत बड़ा नहीं है
      ऊपर से Markov chain data को client तक भेजना और भी अक्षम है
      क्योंकि हर request में microsecond स्तर का CPU और लगभग 1MB RAM ही लगता है, इसलिए इसे server पर संभालना काफ़ी हल्का है