Anderson का एंगल

AI को मिलने वाली सभी वेब प्रतिक्रियाओं में से 20 प्रतिशत ‘ठीक’ नहीं होतीं

mm
Unite.AI को Google पर अपने पसंदीदा स्रोतों में जोड़ें
AI-generated image (GPT Image 2): A smiling cartoon clown with red hair, a striped hat, spotted bow tie and outstretched hands sits above a large “Welcome!” sign. Beneath the canopy, four metal turnstiles are boarded with plywood, chains and padlocks. Rusted barriers, striped columns, weeds, cracked pavement and blue sky complete the scene.

एआई की मदद से वेब से डेटा निकालने के मेरे हालिया प्रयोगों ने मुझे यह एहसास कराया है कि वेब किस हद तक ‘बंद’ होता जा रहा है। इस सख्ती के पीछे, ज़ाहिर है, एआई द्वारा वेब से डेटा निकालने में चौंकाने वाली वृद्धि है; नए डेटा की उसकी असीमित माँग के चलते वेबसाइटें ठप तक हो सकती हैं।

यह वेबसाइटों के लिए वह कदम उठाने का अच्छा बहाना है, जो उनमें से कई लंबे समय से उठाना चाहती थीं: अपनी सामग्री को सिर्फ़ उन्हीं लोगों के लिए उपलब्ध कराना जो लॉग इन हों (हालाँकि, स्वाभाविक रूप से, Googlebot को आम तौर पर बिना रोक-टोक आने दिया जाता है)। Facebook ने इस नीति को धीरे-धीरे अपनाने की प्रक्रिया 2023 में पूरी की, और Twitter/X ने भी उसी साल ऐसा किया। Reddit इसे इस महीने के अंत में अपनाएगा।

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

दूसरी ओर, उपयोगकर्ताओं को पंजीकृत करने के बजाय सीधे बॉट्स से बचाव के उद्देश्य से उठाए गए उपायों में साल-दर-साल 58% से अधिक की वृद्धि हुई है, Cloudflare के अनुसार; और बॉट गतिविधि में यह बढ़ोतरी स्वाभाविक रूप से वेबसाइटों को जाँच-पड़ताल करने के लिए प्रेरित करती है कि वीपीएन और प्रॉक्सी पते किसके हैं। इसके चलते किसी भी ‘दुर्भावनापूर्ण’ ट्रैफ़िक के साथ-साथ वैध उपयोगकर्ताओं को भी पहुँच से वंचित किया जा सकता है।

इसका निजी अनुभव यह है कि मुझे ‘ब्लॉक’ करने वाली प्रतिक्रियाओं या चुनौतियों का सामना लगातार ज़्यादा बार करना पड़ता है; यहाँ तक कि अगर कोई वेबसाइट इन्हें लोड करना शुरू कर दे, तो मैं उसे छोड़ भी सकता हूँ। और चूँकि यह पाया गया है कि कैप्चा की दीवारें उपयोगकर्ताओं और संभावित ग्राहकों को हतोत्साहित करती हैं, इसलिए अंदाज़ा लगाया जा सकता है कि इस नुकसान के बावजूद वेबसाइट मालिकों पर इन्हें अपनाने का कितना दबाव होता है।

archive.is का एक कैप्चा। यह उन कई वेबसाइटों में से एक है जिन्होंने चुनौतियाँ लागू की हैं, अक्सर इंसानों के बजाय स्वचालित अनुरोधों की अत्यधिक संख्या के जवाब में।

archive.is का एक कैप्चा। यह उन कई वेबसाइटों में से एक है जिन्होंने चुनौतियाँ लागू की हैं, अक्सर इंसानों के बजाय स्वचालित अनुरोधों की अत्यधिक संख्या के जवाब में।

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

चूँकि एआई क्रॉलर को बड़े पैमाने पर काम करना होता है, इसलिए वे Playwright ढाँचे के तहत Chrome के ‘हेडलेस’ इंस्टेंस इस्तेमाल करते हैं। इन दिनों, बढ़ती संख्या में वेबसाइटों पर ऐसा करने से 403 (‘निषिद्ध’) त्रुटि मिलती है (Playwright), यानी होस्ट समझ जाता है कि आप स्वचालित ट्रैफ़िक हैं और आपको तुरंत निकल जाने को कहता है:

changedetection.io का स्थानीय इंस्टॉलेशन किसी वेबसाइट को बार-बार जाँचने की कोशिश करता है, लेकिन वेबसाइट को उस ब्राउज़र से परेशानी है जिसे यह ढाँचा पहचानता है, इसलिए वह 403 (‘निषिद्ध’) प्रतिक्रिया देती है।

changedetection.io का स्थानीय इंस्टॉलेशन किसी वेबसाइट को बार-बार जाँचने की कोशिश करता है, लेकिन वेबसाइट को उस ब्राउज़र से परेशानी है जिसे यह ढाँचा पहचानता है, इसलिए वह 403 (‘निषिद्ध’) प्रतिक्रिया देती है।

मकसद ‘200’ (‘ठीक’) क्लाइंट प्रतिक्रिया पाना है—भले ही इसके लिए आवासीय प्रॉक्सी फ़ार्म को ढेर सारा पैसा देना पड़े और इसके साथ कई तरह की दूसरी गुप्त, गैर-मानवीय तरकीबें भी अपनानी पड़ें।

200 प्रतिक्रिया से बेहतर कुछ नहीं; दूसरे शब्दों में, इससे ज़्यादा सकारात्मक संकेत देने वाला कोई क्लाइंट प्रतिक्रिया कोड नहीं है। यह अस्पष्ट प्रतिक्रिया भी नहीं है; यह कभी ‘लगभग ठीक’, ‘बाद में ठीक हो जाएगा’ या ‘और ज़्यादा ठीक होता जा रहा है’ नहीं होती; यह तो ‘ठीक!’ होती है। अगर सब ठीक नहीं है, तो प्रतिक्रिया 200 नहीं है।

नमस्ते! दूर हटो

लेकिन एक नए शोधपत्र के अनुसार, इस बारीकी की कमी एआई डेटासेट, सांख्यिकीय अनुमानों और ‘सफल’ स्थिति की रिपोर्टिंग को काफ़ी हद तक विकृत कर सकती है, जबकि वास्तव में स्थिति सफल न हो।

इस अध्ययन* का अनुमान है कि 200 श्रेणी की लगभग पाँचवीं प्रतिक्रियाओं में पृष्ठ की कोई भी उपयोगी सामग्री नहीं होती, बल्कि उनमें खाली वेबसाइट ढाँचे, कैप्चा चुनौतियाँ, पहुँच प्रतिबंध या वैकल्पिक पृष्ठ मिलते हैं।

शोधपत्र में कहा गया है:

‘स्टेटस 200 के साथ स्थिर क्लाइंट को मिलने वाले पृष्ठों में से 20.9% में पृष्ठ की मुख्य सामग्री नहीं होती: इनमें ऐप के खाली ढाँचे, बॉट चुनौतियाँ, ब्लॉक पृष्ठ, त्रुटि और प्लेसहोल्डर पृष्ठ तथा आंशिक सामग्री शामिल हैं।’

इस लिहाज़ से, अधीर स्वचालित प्रणालियाँ अपनी ही सीमित समझ के कारण उलझ जाती हैं, क्योंकि ‘200’ प्रतिक्रिया को सफल डेटा प्राप्ति के बराबर माना जा सकता है—भले ही डेटा प्राप्त करने पर सिर्फ़ कैप्चा की दीवार, पेवॉल या कोई दूसरी बाधा ही मिले।

शोधपत्र में उन सात प्रकार की सामग्री का ब्यौरा दिया गया है जो अक्सर 200 प्रतिक्रिया को पेचीदा बना देती हैं:

200 प्रतिक्रिया में ऐसी सामग्री की सात श्रेणियाँ जो ‘ठीक’ से कोसों दूर हैं। स्रोत - https://arxiv.org/pdf/2611.00884

200 प्रतिक्रिया में ऐसी सामग्री की सात श्रेणियाँ जो ‘ठीक’ से कोसों दूर हैं। स्रोत

इस अध्ययन के लिए तीन दिनों में 10,307 वेब पतों को एक बुनियादी वेब-फ़ेचिंग प्रोग्राम और JavaScript लोड करने में सक्षम ब्राउज़र—दोनों की मदद से जाँचा गया। प्रतिक्रियाओं का वर्गीकरण उनके HTTP स्थिति कोड के बजाय प्राप्त की गई सामग्री के आधार पर किया गया।

‘अनुपयोगी’ 202 प्रतिक्रियाओं की सबसे बड़ी श्रेणियाँ खाली वेबसाइट ढाँचे और त्रुटि या विकल्प के तौर पर दिखाए गए पेज थे; कुल मिलाकर इनकी वजह से दो-तिहाई से अधिक विफलताएँ हुईं।

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

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

इसके बाद, अधिक संसाधन लेने वाले ब्राउज़र टूल का इस्तेमाल केवल तभी किया जा सकता है, जब लगे कि कोई पेज ठीक से लोड नहीं हुआ। इसके अलावा, AI मूल्यांकन यह जाँच सकते हैं कि उद्धृत स्रोतों में वास्तव में अपेक्षित जानकारी मौजूद है या नहीं, बजाय इसके कि HTTP 200 प्रतिक्रिया को इस बात का प्रमाण मान लिया जाए कि सामग्री सफलतापूर्वक प्राप्त हुई।

नए शोध के लेखक यह भी बताते हैं कि पेज की लंबाई, रीडायरेक्ट और मौजूद न होने वाले पेजों से समानता की बुनियादी जाँचों के ज़रिए ‘कम लागत वाली अनुमान-आधारित जाँचें’ लगभग 86% अनुपयोगी प्रतिक्रियाओं की आसानी से पहचान कर सकती हैं:

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

वेब-फ़ेचिंग रणनीतियों की तुलना: केवल संदिग्ध चिह्नित पेजों को रेंडर करने पर हर पेज को रेंडर करने की तुलना में थोड़ा अधिक उपयोगी कंटेंट (81.4%) मिला (80.3%), जबकि हर पेज को प्राप्त करने का औसत समय घटकर 20.6 से 5.8 सेकंड रह गया। 

इतनी सारी गलत 200 प्रतिक्रियाएँ क्यों?

पिछले कुछ वर्षों में डेवलपर समुदायों में इस बात पर कुछ बहस हुई है कि 202 (‘स्वीकार किया गया’) त्रुटि (‘अनुरोध स्वीकार किया गया, लेकिन अभी पूरा नहीं हुआ’) इन ‘विफल’ 200-स्थिति वाले अनुरोधों के बीच अंतर स्पष्ट कर सकती है। लेकिन असल में, 202 नए शोधपत्र में बताए गए सभी मामलों को समेट नहीं सकता, और ऐसा करने वाला कोई मौजूदा कोड भी नहीं है।

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

इसकी एक वजह यह हो सकती है कि 200 के अलावा कोई भी स्थिति मूलतः किसी तरह का त्रुटि-पेज या बाधा होती है। इनमें सबसे आम 404 (‘नहीं मिला’) त्रुटियाँ हैं, जिनमें माँगी गई सामग्री पूरी तरह गायब होती है। कुछ लोगों का मानना है कि ऐसी त्रुटियाँ बहुत अधिक होने पर SEO (और, संभवतः, GEO) में दंड भुगतना पड़ सकता है, हालाँकि Google इससे इनकार करता है।

दरअसल, Google गलत 200 प्रतिक्रियाओं को ‘सॉफ्ट’ 404 मानता है। इन्हें सामान्य 404 त्रुटियों से बड़ी समस्या समझे जाने की आशंका स्पष्ट रूप से अधिक है, क्योंकि ये मूलतः भ्रामक परिणाम हैं—चाहे जानबूझकर दिए गए हों या नहीं।

उद्धरण का अर्थ बदलना

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

उदाहरण के लिए, गलत 200 प्रतिक्रियाओं से जुड़ी एक उल्लेखनीय समस्या ‘उद्धरण का अर्थ बदल जाना’ है। ऐसा तब होता है, जब AI से तैयार जवाब को अब उस वेबपेज का समर्थन नहीं मिलता, जिसे मूल रूप से साक्ष्य के तौर पर उद्धृत किया गया था। यानी, पेज बदल गया हो सकता है, संबंधित पाठ हटा दिया गया हो सकता है या लिंक अब किसी दूसरी जगह ले जा सकता है।

नए अध्ययन में पाया गया कि उद्धरण का अर्थ बदलने के स्पष्ट मामलों की दर 5.8% से बढ़कर 21.9% हो गई, जब सभी HTTP 200 प्रतिक्रियाओं को सफलतापूर्वक प्राप्त सामग्री माना गया—उनमें क्या था, इसकी परवाह किए बिना।

इसका मतलब है कि किसी स्रोत को गलत ढंग से ऐसा माना जा सकता है कि वह बदल गया है, गायब हो गया है या अब AI से तैयार किए गए किसी दावे का समर्थन नहीं करता—सिर्फ इसलिए कि मूल सामग्री के बजाय CAPTCHA, खाली पेज या कोई दूसरी बाधा प्राप्त हुई थी।

बस कह दो कि ऐसा है!

जान-बूझकर गढ़े गए ऐसे वेब पतों पर किए गए परीक्षणों से भी यह समस्या सामने आई, जो मौजूद ही नहीं थे। जब वेबसाइटों से बेतरतीब, मनगढ़ंत पाथ माँगे गए, तो जवाब देने वाली वेबसाइटों में से 13.1% ने 200 (‘ठीक है’) स्थिति कोड लौटाया, जबकि माँगे गए पेज मौजूद नहीं थे†।

‘बेतरतीब पाथ की जाँच का जवाब देने वाली 13.1% साइटों ने 200 लौटाया (S1 10.5%, S2 13.3%, S3 17.3%, S4 13.7%, S5 13.1%)। ऐसी हर प्रतिक्रिया अपने आप में सॉफ्ट 404 है, लेकिन हर प्रतिक्रिया यह बात बताती नहीं है।

‘172 सॉफ्ट-404 प्रतिक्रियाओं के खोजपरक विश्लेषण में, लेबलकर्ता ने 98 को त्रुटि या विकल्प पृष्ठ, 32 को खाली ढाँचा और 28 को सामग्री बताया: किसी यादृच्छिक पथ पर दिया गया होमपेज या सूची-पृष्ठ सामान्य पृष्ठ जैसा दिखता है।’

निष्कर्ष

यदि समस्या को उच्च स्तर पर पहचाना जाता, तो IANA संभवतः एक नया और अधिक उपयुक्त HTTP स्थिति कोड बना सकता था, जैसे कि [X] (‘अनुरोध सफल हुआ, लेकिन माँगी गई सामग्री नहीं दी गई’)। हालाँकि, यह वास्तव में हो रही स्थिति का वर्णन करता, लेकिन इसके लिए स्वाभाविक रूप से होस्ट की ओर से लेन-देन की असामान्य रूप से गहरी समझ की आवश्यकता होती।

ऐसे ही कोड पहले से मौजूद हैं, हालाँकि उनमें से कोई भी पूरी तरह उपयुक्त नहीं है: 451 (‘कानूनी कारणों से अनुपलब्ध’) अस्पष्ट है और काफ़ी चिंताजनक भी (!); 206 (‘आंशिक सामग्री’) तकनीकी रूप से सटीक है, लेकिन इसका इस्तेमाल अधूरे डेटा (फ़ेच) के लिए किया जाता है; और चौंकाने वाला 203 (‘गैर-प्रामाणिक जानकारी’), जिसे 1997 में बनाया गया था, मौजूदा उपयोग-स्थिति से केवल परोक्ष रूप से जुड़ा है।

शायद सबसे नज़दीकी विकल्प दरअसल अप्रत्याशित नाम वाला 103 (‘प्रारंभिक संकेत’) है, जो बताता है कि URL के सभी संसाधन अभी लोड नहीं हुए हैं (हालाँकि यह स्पष्ट रूप से कोड के आशय की गंभीर गलत व्याख्या होगी)।

 

* शीर्षक: ‘जब 200 OK जवाब नहीं होता: एजेंट-आधारित वेब सामग्री अधिग्रहण में मौन फ़ेच विफलताएँ।‘ कृपया ध्यान दें कि यह शोधपत्र, ऐसा प्रतीत होता है, मुख्य रूप से मशीन द्वारा पढ़े जाने के लिए लिखा गया है—शायद AI से पूछताछ के लिए—और इसे पढ़ना अपने आप में आसान नहीं है।

†यांत्रिक ढंग से दिए गए उद्धरण के लिए क्षमा चाहता हूँ, लेकिन जैसा कि मैंने ऊपर बताया है, पूरा शोधपत्र इसी शैली में लिखा गया है—इसे इंसानों के लिए समझने योग्य बनाने के बजाय ‘मशीन द्वारा पढ़े जाने योग्य’ बनाने के लिए—हालाँकि इसे JSON प्रारूप में प्रस्तुत करने की हद तक नहीं।

पहली बार प्रकाशित: बुधवार, 4 नवंबर 2026

mm

मशीन लर्निंग पर लेखक, मानव छवि संश्लेषण में डोमेन विशेषज्ञ। Metaphysic.ai में शोध सामग्री के पूर्व प्रमुख, जब तक यह DNEG की Brahma.ai में विलीन नहीं हो गया।
वेबसाइट: martinanderson.ai
संपर्क: martin@martinanderson.ai