AI जाँच टूल अच्छे नतीजे को बिगाड़ देते हैं। मॉडल को कमज़ोर मत करो
सिर्फ़ गलतियाँ पकड़ो। पसंद को मत छुओ।
विषय सूची
निरीक्षण आउटपुट को कम करने का कार्य नहीं है, बल्कि वास्तविक त्रुटियों को खोजने और ठीक करने का कार्य है।
अक्षर स्लाइड से बाहर निकल आए थे। भेजने से ठीक पहले की बात है।
एक और गड़बड़ थी। एक घंटे पहले मॉडल ने जो पुराना वर्शन बनाया था, उसने चुपके से मेरी एक्सेल फ़ाइल के बदलाव वापस लौटा दिए थे। टेबल के पाँच में से सिर्फ़ तीन खानों पर ही बॉर्डर थी। यह पसंद का मामला नहीं है। यह सीधे-सीधे गलत है। भेजने से पहले मुझे ऐसा कुछ चाहिए था जो इसे पकड़ ले। इसलिए मैंने पहले से मौजूद AI जाँच टूल इंस्टॉल करके देखे।
जाँच का काम निचली सीमा उठाना है
जाँच टूल का असली काम नतीजे की निचली सीमा उठाना है। स्लाइड से बाहर निकला टेक्स्ट, टूटा हुआ फ़ॉर्मूला, अधूरा प्लेसहोल्डर, दस्तावेज़ में बचा markdown, ऐसी चीज़ें कोई भी देखे तो गलत हैं। इन्हें जल्दी पकड़ना चाहिए, क्योंकि ये छोटी दिखती हैं पर भेजने लायक फ़ाइल को तोड़ देती हैं। लेकिन यहीं रेखा पार करना आसान है। गलती पकड़ने के लिए बना टूल धीरे-धीरे स्टाइल थोपने लगता है।
स्टाइल को गलती बना देंगे तो ऊपरी सीमा नीचे आ जाती है
ज़्यादातर टूल वह काम कर रहे थे जो मैंने माँगा ही नहीं था। फ़ॉन्ट कितने तक हों। एक स्लाइड पर अक्षर इतने ही हों। रंग इन्हीं में से चुनो। बुलेट छह तक ही हों। ये गलतियाँ नहीं पकड़ रहे थे। ये अपना फ़ॉर्मेट थोप रहे थे और उसी को “क्वालिटी” कह रहे थे।
मॉडल जितना समझदार, जाँच टूल उसे उतना ही काट देता है। असली दिक्कत यहाँ है। किसी दिन इससे बेहतर मॉडल आएगा। ऐसा मॉडल जो उन सब नियमों को जान-बूझकर तोड़ते हुए भी घनी और सचमुच अच्छी स्लाइड बनाएगा।
तब वह जाँच टूल उस मॉडल को इसलिए सज़ा देगा क्योंकि उसने बेहतर काम किया। पसंद से जुड़े नियम अगले मॉडल के लिए रुकावट बन जाते हैं। वे नतीजे को उसी पुराने समय और उसी कमज़ोर मॉडल के स्तर पर बाँध देते हैं, जिस समय नियम बने थे।
गलती और पसंद को अलग करने वाला सवाल
यह सिर्फ़ साफ़ गलतियाँ हटाता है। बाकी सब को रास्ता देता है। इसलिए हर जाँच को दो शर्तें पार करनी पड़ती हैं।
पहली। क्या यह पसंद से अलग, सच में गलत है। कैनवस से बाहर निकला टेक्स्ट गलत है। #REF! एरर गलत है। ऐसी टेबल जिसमें हर पंक्ति में खानों की गिनती अलग है, गलत है। यहाँ पसंद की कोई जगह नहीं।
दूसरी। क्या ज़्यादा सक्षम मॉडल भी इसे हमेशा टालेगा। अगर कोई समझदार मॉडल बेहतर काम करने के लिए उस नियम को जान-बूझकर तोड़ सकता है, तो वह नियम इस टूल में नहीं आ सकता। न एरर के रूप में, न चेतावनी के रूप में।
अच्छा जाँच उपकरण मॉडल के रचनात्मक प्रयासों को नहीं मिटाता; उसे केवल वास्तविक दोष वाले आउटपुट की पहचान करनी चाहिए।
हर समस्या को काला-सफेद में नहीं बाँटा जा सकता
घनापन, रंग, फ़ॉन्ट की गिनती, हाशिया, वाक्य की क्वालिटी। ये सब दूसरी शर्त पर गिर जाते हैं। इसलिए मैंने इनमें से एक भी नहीं रखा।
कई बातें पूरी तरह गलती नहीं होतीं, पर इंसान की नज़र माँगती हैं। टेक्स्ट थोड़ा टकरा रहा है, अक्षर बहुत छोटे हैं, तस्वीर का अनुपात बदला है, या लेआउट असामान्य है। ये कभी गलती हो सकती हैं, कभी जान-बूझकर चुना गया डिज़ाइन। इसलिए साफ़ टूटे हुए हिस्से को ERROR कहना चाहिए, और जहाँ इंसान देखे तो बेहतर हो, उसे WARN पर रखना चाहिए। चेतावनी दोष-सिद्धि नहीं है। वह सिर्फ़ देखने का संकेत है।
वह गलती नहीं है, वह ऊपरी सीमा (ceiling) है। ऊपरी सीमा को ऊँचा उठाना तो शुरू से ही जाँच टूल का काम था ही नहीं।
ऑटोमेटेड जाँच अंतिम फैसला नहीं लेती
इस सबके नीचे एक सोच टिकी है।
हर खराबी एक ही जगह से आती है। मॉडल उस चीज़ पर आदेश भेजता है जिसे वह देख ही नहीं सकता। रेंडर हुई स्लाइड, सेल की असली शक्ल। वह सच की जगह अंदाज़े से भरता है, और उस नतीजे को जाँचता नहीं।
हल स्टाइल के नियम नहीं हैं। लिखने से पहले सच को पढ़ो, और लिखने के बाद उसे जाँचो।
मॉडल जितना समझदार होगा, इस बात को उतना ही अच्छे से निभाएगा। यही असली बात है। यह अनुशासन मॉडल से लड़ता नहीं, बल्कि मॉडल के साथ बढ़ता है।
Office File Inspector बनाने की वजह
इसे GitHub पर MIT लाइसेंस के साथ डाल दिया है। अगर आप LLM से कुछ बनाते हैं, तो मुझे बताइए कि मेरी जाँचों में से कौन-सी असल में पसंद से जुड़ी है। ऐसी जाँच को तो यहाँ होना ही नहीं चाहिए। → GitHub पर llm-office-qa