वह इंजन जिसमें छह पोल थे — दस लाइनों के कोड का मिथक
मशीनी अनुवादित · मूल लेख पढ़ें
छह भागों वाली एक जांच कि आपको बेचा गया दस्तावेज़ चैटबॉट अभी भी मनगढ़ंत बातें क्यों बना रहा है — और उस अलग दिशा के बारे में जिसे 2026 की शुरुआत में कुछ लोगों ने अपनाना शुरू किया है।
जांच की अनुक्रमणिका
- वह इंजन जिसमें छह पोल थे — दस लाइनों के कोड का मिथक
- वे तालिकाएँ जो मौजूद नहीं थीं
- झूठा रीरैंकर
- विरासत में मिला मतिभ्रम (Hallucination)
- क्लाउड की छिपी हुई लागत
- दस्तावेज़ के रूप में रणनीति — सातवां अध्याय
छह भागों वाली एक जांच कि आपको बेचा गया दस्तावेज़ चैटबॉट अभी भी मनगढ़ंत बातें क्यों बना रहा है — और उस अलग दिशा के बारे में जिसे 2026 की शुरुआत में कुछ लोगों ने अपनाना शुरू किया है।
परिचय — वह इंजन जिसमें आठ पोल थे (लेकिन वास्तव में छह थे)
मिलान, मार्च 2026। एक मैनेजर कंपनी का आंतरिक चैटबॉट खोलता है, जिसे आईटी विभाग ने बड़े उत्साह और कम संदेह के साथ "दो हफ्तों में" तैयार किया था। एक बहुत ही सरल प्रश्न: "CMP40M इंजन में कितने पोल हैं?"। चैटबॉट उस पूरे आत्मविश्वास के साथ जवाब देता है जो बड़े भाषा मॉडल (LLMs) प्रदर्शित करते हैं: "CMP40M इंजन में आठ पोल हैं।"
गलत। इसके छह हैं। सही जवाब 422 पन्नों की कैटलॉग में नहीं था जिसे किसी ने, महीनों पहले, पूरी तरह से विश्वास के साथ एक वेक्टर डेटाबेस में डाला था, यह सोचकर कि आगे से सिस्टम "सब कुछ जान जाएगा"। वह डेटा, कैटलॉग में बिल्कुल भी नहीं था। यह SEW के तकनीशियनों के एक ईमेल से जुड़ी एक PDF में था, जिसे एक ऐसे फ़ोल्डर में संग्रहीत किया गया था जिसे किसी ने भी इंडेक्स करने की जहमत नहीं उठाई।
यह दृश्य, उद्योग और बोली-भाषा में भिन्नताओं के साथ, सैकड़ों इतालवी कार्यालयों में दोहराया जाता है। वादा सरल और आकर्षक था: अपने AI सहायक को सभी कंपनी दस्तावेज़ दें, और वह उन पर किसी भी प्रश्न का उत्तर दे पाएगा। वास्तविकता बहुत अधिक साधारण है: चैटबॉट पढ़ता है लेकिन समझता नहीं है, खोजता है लेकिन नहीं पाता है, और जब उसे नहीं मिलता है - कहने के बजाय - आविष्कार करता है। यह धाराप्रवाह, सही व्याकरण और प्रशंसनीय संख्याओं के साथ आविष्कार करता है। यह जवाब न देने से भी बदतर है।
2024 के अंत और 2026 की शुरुआत के बीच हमने इन विफलताओं का पोस्टमार्टम करने में महीनों बिताए। विवादों को भड़काने के लिए नहीं, बल्कि यह समझने के लिए कि एक इतनी सीधी अवधारणा - "उसे दस्तावेज़ दें और फिर उससे सवाल पूछें" - डेमो के मंच से बाहर निकलने और वास्तविक सर्वर रूम में प्रवेश करने पर इतनी मुश्किल क्यों हो जाती है।
यह छह अध्यायों की जांच बताती है कि हमें क्या मिला: चुपचाप पूरे कैटलॉग को मिटाने वाले बग, गलत स्कोर वाले क्लाउड रीरैंकर, मतिभ्रम जो मॉडल से नहीं बल्कि वर्षों पहले दूषित डेटा से उत्पन्न हुए, हर क्वेरी को उसके मूल्य से अधिक महंगा बनाने वाले आउटगोइंग बिल, और "लोकप्रिय" फ्रेमवर्क जो दस लाइनों के कोड में सब कुछ वादा करते हैं बशर्ते उनसे बहुत अधिक न मांगा जाए। और अंतिम अध्याय में, वह अलग दिशा जो किसी ने चुपचाप 2026 की शुरुआत में लेना शुरू कर दी थी - एक ऐसी वास्तुकला जहां खोज रणनीति कोड होना बंद हो जाती है और एक ऐसा दस्तावेज़ बन जाती है जिसे कंपनी में कोई भी पढ़ और संशोधित कर सके।
प्रत्येक अध्याय अपने आप में खड़ा है। यदि आप 342 गायब तालिकाओं की कहानी या झूठे रीरैंकर की कहानी से शुरू करना चाहते हैं, तो आप स्वतंत्र हैं। लेकिन पूरी कहानी में एक नैतिक है जो केवल अंत में उभरती है: कॉर्पोरेट आरएजी - वह तकनीकी संक्षिप्त नाम जिसका अर्थ है पुनर्प्राप्ति-संवर्धित पीढ़ी, यानी "पहले प्राप्त किए गए दस्तावेजों के आधार पर प्रतिक्रियाएं उत्पन्न करें" - अभी तक एक तैयार उत्पाद नहीं है। यह एक सीमांत है। और सभी सीमाओं की तरह, इसे अब तक मुख्य रूप से विक्रेताओं द्वारा बताया गया है। उन लोगों को सुनना भी समय आ गया है जिन्होंने इसके अंदर जीवन जिया है।
अध्याय 1 — दस लाइनों के कोड की मिथक
2023 से हर एआई सम्मेलन में स्लाइड समान है: "आपका कॉर्पोरेट दस्तावेज़ सहायक 10 लाइनों के कोड में." शीर्षक के नीचे, पेस्टल रंगों में पायथन का एक ब्लॉक है जो एक ओपन-सोर्स लाइब्रेरी दिखाता है - आमतौर पर उन प्रसिद्ध अमेरिकी लाइब्रेरियों में से एक, जिसका नाम पेड़ों की श्रृंखला या तिब्बती लामाओं को याद दिलाता है - जो पीडीएफ लोड करता है, उन्हें टुकड़ों में तोड़ता है, उन्हें एक वेक्टर डेटाबेस में चिपकाता है और एक भाषा मॉडल के साथ क्वेरी करता है। पांच मिनट में, आपके पास एक चैटबॉट है। पांच मिनट में, तालियां। पांच मिनट में, एक मध्यम आकार की इतालवी कंपनी को यह विश्वास हो जाता है कि समस्या हल हो गई है और इसका आईटी विभाग दो सप्ताह में इसे कर सकता है।
समस्या - वह जो स्लाइड नहीं बताती है - यह है कि डेमो तीन अच्छी तरह से स्वरूपित पीडीएफ, एक प्रश्न के साथ बनाया गया है जो सामग्री से मेल खाता है, वास्तविक विलंबता के बिना एक मंच, और एक प्रस्तुतकर्ता जिसने सब कुछ ऊपर जाने से पहले 27 बार कोशिश की थी। वास्तविकता में, कॉर्पोरेट दस्तावेज़ एक भूवैज्ञानिक आपदा हैं: स्कैन के स्कैन, टेबल जो टेक्स्ट को ओवरलैप करते हैं, फुटनोट जो पैराग्राफ में घुस जाते हैं, "RH1M" जैसे अल्फ़ान्यूमेरिक कोड जिन्हें चंकेर शब्दों के रूप में मानते हुए बीच में काट देता है, चित्र जिनमें उपयोगी जानकारी का 70 प्रतिशत होता है लेकिन कोई भी वास्तव में निकालता नहीं है, और लेआउट इतने रचनात्मक होते हैं कि उन्हें पार्सर की तुलना में पुरातत्वविद् की आवश्यकता होती है।
RAG — यह इसके नीचे का विचार है — एक बहुत अच्छा विचार है। उपयोगकर्ता के प्रश्न को लें, अपने संग्रह में सबसे प्रासंगिक दस्तावेज़ खोजें, उन्हें भाषा मॉडल को पास करें और उन दस्तावेज़ों के आधार पर एक उत्तर प्राप्त करें। सिद्धांत रूप में, यह मतिभ्रम की समस्या को खूबसूरती से हल करता है: मॉडल को अब उत्तर "जानने" की आवश्यकता नहीं है, उसे केवल उन टुकड़ों में "पढ़ने" की आवश्यकता है जो आपने उसे प्रदान किए हैं। व्यवहार में, श्रृंखला के प्रत्येक लिंक — चंकिंग, एम्बेडिंग, पुनर्प्राप्ति, रीरैंकिंग, अंतिम पीढ़ी — के टूटने के अपने तरीके हैं, और विफलता शायद ही कभी एक दृश्यमान त्रुटि के रूप में प्रकट होती है। यह थोड़ा गलत उत्तर के रूप में प्रकट होता है। फिर एक पूरी तरह से गलत उत्तर के रूप में। फिर एक प्रबंधक के रूप में जो आश्चर्यचकित है कि वह एक ऐसे सिस्टम के लिए भुगतान क्यों कर रहा है जो प्रशिक्षु से भी कम जानता है।
RAG को लोकप्रिय बनाने वाले ओपन सोर्स फ्रेमवर्क प्रदर्शन करने के लिए बने हैं, उत्पादन के लिए नहीं। वे सुंदर अमूर्तन की श्रृंखलाबद्ध श्रृंखला हैं, जिनमें प्रत्येक परत एक अघोषित धारणा को छुपाती है: कि आपके PDF में सभ्य OCR है, कि आपकी तस्वीरों का पहले से ही वर्णन किया गया है, कि आपकी तालिकाओं का एक सम्मेलन का पालन किया जाता है, कि एम्बेडिंग मॉडल वास्तव में आपकी भाषा बोलता है (स्पॉइलर: कई केवल अंग्रेजी अच्छी तरह से बोलते हैं), कि आपके संग्रह को पहले से ही डुप्लिकेट से साफ कर दिया गया है। जब इनमें से कोई धारणा विफल हो जाती है - और कम से कम एक हमेशा विफल हो जाती है, लगभग हमेशा तीन - सिस्टम काम करना बंद नहीं करता है। बदतर: यह अच्छी तरह से काम करना बंद कर देता है, लेकिन जवाब देना जारी रखता है। धाराप्रवाह, आत्मविश्वासपूर्ण उत्तर, और अक्सर सच्चाई से अलग।
एक वाक्य है जो इन प्रणालियों का निर्माण करने वाले पेशेवरों के बीच घूमता रहता है, और जिसे आप ट्यूटोरियल में कभी नहीं पढ़ेंगे: "RAG बनाना आसान है, और इसे अच्छी तरह से बनाना मुश्किल है।" पहले डेमो और उत्पादन सेवा के बीच एक खाई है जिसे GPU जोड़कर या मॉडल बदलकर नहीं भरा जा सकता है। यह एक असहज बात को समझकर भरा जाता है: जब आप एक एंटरप्राइज़ RAG बनाते हैं, तो आप कोड नहीं लिख रहे होते हैं। आप अपने दस्तावेज़ों के लिए एक छोटा, हठी सर्च इंजन डिज़ाइन कर रहे हैं, जिसमें सभी संपादकीय विकल्प शामिल हैं - क्या शोर है, क्या संकेत है, क्या दो बार अनुक्रमित किया जाना चाहिए, क्या त्याग दिया जाना चाहिए। केवल ट्यूटोरियल में दस लाइनों में, ये विकल्प आपके लिए एक बार लिए जाते हैं, किसी ऐसे व्यक्ति द्वारा जिसने आपके दस्तावेज़ कभी नहीं देखे हैं। और वे लगभग हमेशा आपके मामले के लिए गलत होते हैं।
कोई टिप्पणी? हमें लिखें
यह संदेश केवल हम तक पहुंचेगा। यदि आपकी टिप्पणी दिलचस्प है तो हम इसे लेख के अंत में प्रकाशित कर सकते हैं, लेकिन केवल मूल्यांकन के बाद।
जैसे ही आप लिखते हैं, आपका ब्राउज़र एक छोटा सा गणितीय समस्या हल कर रहा है—यह स्पैम को रोकने का हमारा तरीका है बिना किसी तीसरे पक्ष की सेवा या आपको ट्रैफिक लाइट पहचानने के लिए कहे। आपसे कुछ नहीं मांगा जा रहा है और कोई भी डेटा इस साइट से बाहर नहीं जाता।