ड्रॉइंग की समझ खोए बिना हाईवे प्लैन्स पढ़ना: PlanSightRAG पर एक नज़र
आधारित शोध-पत्र: PlanSightRAG: A Visual-First Multimodal RAG for Automating Question Answering and Compliance Checking for Civil Standard Plans — Nabaraj Subedi, Shuvo Dip Datta, Ahmed Abdelaty, Shivanand Venkanna Sheshappanavar
हाईवे इंटरचेंज के लिए किसी स्टेट DOT (Department of Transportation) की प्लान शीट की कल्पना कीजिए। एक गार्डरेल पोस्ट से पेवमेंट के किनारे तक एक डायमेंशन लाइन जा रही है, जिस पर "24'-0"" लिखा है। पास ही एक कॉलबबल (callout bubble) पाइप के डायमीटर वाले नोट के साथ एक कल्वर्ट (culvert) की तरफ इशारा कर रहा है। इसमें से किसी का भी कोई स्वाभाविक रीडिंग ऑर्डर नहीं होता। संख्या 24 का उस तीर (arrow) के बिना कोई मतलब नहीं जिससे वह जुड़ी है, और उस तीर का उन दो बिंदुओं के बिना कोई अर्थ नहीं जिन्हें वह जोड़ता है। अब उस पन्ने को OCR से गुज़ारिए। आपको शब्दों का एक ढेर (bag of text) मिलेगा: "24'-0"", "CULVERT", पाइप का डायमीटर, कुछ स्टेशन नंबर्स—एक्सट्रैक्टेड स्ट्रिंग्स के रूप में ये सभी सही हैं, लेकिन पूरी तरह बेकार हैं। ऐसा इसलिए, क्योंकि जिस चीज़ ने उन्हें अर्थपूर्ण बनाया था (कौन सी लाइन किस ऑब्जेक्ट को छूती है, पन्ने पर वह कहाँ स्थित है), वह पूरी तरह गायब हो चुकी है।
PlanSightRAG नामक एक नया रिसर्च पेपर इसी समस्या को हल करने की कोशिश कर रहा है। यह उस फ़ेलियर मोड का एक बेहतरीन उदाहरण है, जिसे नज़रअंदाज़ करना तब बहुत आसान होता है जब आप OCR को एक सुलझ चुकी समस्या (solved problem) मान लेते हैं। ड्रॉइंग्स के लिए यह समस्या अभी सुलझी नहीं है; यह सिर्फ़ उन दस्तावेज़ों के लिए सुलझी है जिनमें मुख्य रूप से वाक्य होते हैं।
सिविल प्लैन्स स्टैंडर्ड Document-AI प्लेबुक को क्यों फेल कर देते हैं
डॉक्यूमेंट्स के लिए अधिकतर रिट्रीवल-ऑगमेंटेड जेनरेशन (RAG) सिस्टम एक ही तय तरीक़े (recipe) पर चलते हैं: पेज को OCR के ज़रिए टेक्स्ट में बदलना, टेक्स्ट के चंक्स (chunks) बनाना, इन चंक्स को एम्बेड करना, और किसी लैंग्वेज मॉडल को उन पर रिट्रीवल और रीज़निंग करने देना। यह तरीक़ा कॉन्ट्रैक्ट्स, इनवॉइस और रिपोर्ट्स के लिए काफ़ी हद तक ठीक काम करता है, क्योंकि वहाँ जानकारी शब्दों में होती है और शब्द एक तय क्रम में पढ़े जाते हैं।
सिविल इंजीनियरिंग के स्टैंडर्ड प्लैन्स इस तरह काम नहीं करते। किसी स्टेट डिपार्टमेंट ऑफ़ ट्रांसपोर्टेशन (DOT) के प्लान सेट की एक ही शीट में कई चीज़ें एक साथ हो सकती हैं:
- एक ही पन्ने पर अलग-अलग स्केल्स में एक प्लान व्यू (ऊपर से सीधा दृश्य) और एक प्रोफ़ाइल व्यू (साइड एलिवेशन)
- डायमेंशन लाइन्स और लीडर लाइन्स, जो विशुद्ध रूप से ज्योमेट्री के ज़रिए संबंधों को एनकोड करती हैं
- सिम्बल्स और हैचिंग पैटर्न्स, जो किसी टेक्स्ट लेबल के बजाय परंपरा और मानकों (conventions) के आधार पर विशिष्ट अर्थ रखते हैं
- दूसरी शीट्स, टेबल्स और एक अलग स्पेसिफिकेशन बुक के क्रॉस-रेफ़रेंसेज़, जो वास्तविक संख्यात्मक सीमाओं (numeric limits) को परिभाषित करते हैं
OCR के ज़रिए लेआउट हटाते ही आप वह सब कुछ खो देते हैं जो ड्रॉइंग को पढ़ने योग्य बनाता है। लेखकों ने अपने एब्स्ट्रैक्ट में इसे साफ़ तौर पर कहा है: OCR-आधारित ऑटोमेशन "इन प्लैन्स को समझने के लिए ज़रूरी ज्योमेट्री और लेआउट को छीन लेता है।" इंजीनियर्स आज भी इस तरह के दस्तावेज़ों की कम्प्लायंस चेकिंग (compliance checking) अपनी आँखों से, शीट-दर-शीट करते हैं, और सैकड़ों पन्नों के स्पेसिफिकेशन दस्तावेज़ों से क्रॉस-रेफ़रेंस मिलाते हैं। यह बेहद धीमा काम है, और ठीक उसी तरह का दोहराव भरा व गलतियों की आशंका वाला (error-prone) काम है जिसे ऑटोमेशन को बेहतर ढंग से करना चाहिए—दिक्कत बस यह है कि स्टैंडर्ड डॉक्यूमेंट-AI टूलकिट इसमें फ़िट नहीं बैठता।
समाधान: ड्रॉइंग को टेक्स्ट में बदलना पूरी तरह बंद करना
PlanSightRAG का मुख्य कदम इंडेक्सिंग और रिट्रीवल के लिए OCR-आधारित टेक्स्ट एक्सट्रैक्शन को पूरी तरह छोड़ देना है। किसी प्लान शीट को टेक्स्ट में बदलकर उस टेक्स्ट को सर्च करने के बजाय, यह हर पेज को एक इमेज मानता है और इमेजेस के ज़रिए ही इमेजेस को सर्च करता है।
इस रिट्रीवल का मुख्य आधार (backbone) ColNomic-3B नामक एक मॉडल है। इसका मतलब समझने के लिए यह जानना मददगार होगा कि यह किस मॉडल फ़ैमिली से आता है। स्टैंडर्ड डॉक्यूमेंट रिट्रीवल पूरे पेज को एक सिंगल वेक्टर (संख्याओं की सूची) में कंप्रेस कर देता है, जो उस पन्ने की हर चीज़ को संक्षेप में दर्शाने के लिए होता है। यह तेज़ तो है लेकिन इसमें डेटा का नुकसान (lossy) होता है: बारह अलग-अलग कॉलबल्स वाला पन्ना भी उसी आकार के वेक्टर में सिमट जाता है जिसमें सिर्फ़ एक पैराग्राफ वाला पन्ना। इसके उलट, ColNomic एक मल्टी-वेक्टर (multi-vector) दृष्टिकोण का उपयोग करता है जो ColPali नामक विधि से विकसित हुआ है: यह इमेज को पैचेज़ (patches) के एक ग्रिड में काटता है और हर पैच के लिए एक अलग वेक्टर बनाता है। इससे कोई भी क्वेरी पन्ने के उस खास हिस्से से मैच हो सकती है जहाँ प्रासंगिक जानकारी वास्तव में मौजूद है, न कि पूरे पन्ने के किसी औसत से। जब आप सिस्टम से कोई सवाल पूछते हैं (जैसे, "इस गार्डरेल प्रकार के लिए न्यूनतम क्लीयरेंस क्या है?"), तो यह आपकी क्वेरी की तुलना हर पेज के हर पैच से करता है और सबसे मजबूत मैच ढूंढता है। यही वजह है कि ज्योमेट्री सुरक्षित रहती है। आप मॉडल से ड्रॉइंग को पहले शब्दों में बयां करने के लिए कभी नहीं कहते।
इस रिट्रीवल लेयर के ऊपर वह सिस्टम मौजूद है जिसे पेपर में एजेंटिक (agentic) Planner-Retriever-Auditor-Synthesizer पाइपलाइन कहा गया है। इसमें चार भूमिकाएं हैं, जिन्हें एक ही बड़े (monolithic) प्रॉम्प्ट के बजाय पाइपलाइन के अलग-अलग चरणों द्वारा संभाला जाता है:
- Planner यह विश्लेषण करता है कि सवाल में वास्तव में क्या पूछा जा रहा है (कौन सी शीट प्रकार प्रासंगिक हैं, क्या जाँचना ज़रूरी है)
- Retriever ColNomic मल्टी-वेक्टर सर्च का उपयोग करके संभावित प्लान पेजेस और संदर्भ स्पेसिफिकेशन पेजेस निकालता है
- Auditor यह जाँचता है कि रिट्रीव किया गया साक्ष्य वास्तव में उत्तर का समर्थन करता है या नहीं, बजाय इसके कि जो कुछ भी मिला उसे आगे बढ़ा दे
- Synthesizer रिट्रीव किए गए पेजेस पर आधारित अंतिम उत्तर या कम्प्लायंस का फ़ैसला (compliance verdict) तैयार करता है
एक और पहलू जो ध्यान देने योग्य है, वह है जिसे वे MaxSim हीटमैप्स (heatmaps) कहते हैं। चूँकि रिट्रीवल मॉडल पैच-लेवल पर सिमिलैरिटी स्कोर की गणना करता है, इसलिए आप विज़ुअलाइज़ कर सकते हैं कि किसी पन्ने पर किन पैचेज़ के कारण मैच हुआ। यह मूल ड्रॉइंग के ऊपर एक हीटमैप ओवरले तैयार करता है, जो आपको सटीक रूप से दिखाता है कि सिस्टम के अनुसार प्रासंगिक डायमेंशन, सिंबल या नोट कहाँ मौजूद है। यह बात पहली नज़र में जितनी सामान्य लगती है, उससे कहीं ज़्यादा मायने रखती है। एक कम्प्लायंस चेक जो सिर्फ़ "PASS" या "FAIL" लौटाता है, उस पर कोई इंजीनियर आँख मूँद कर साइन नहीं कर सकता। लेकिन एक ऐसा कम्प्लायंस चेक जो यह कहे कि "FAIL, और ड्रॉइंग पर ठीक यही वह जगह है जिसने इसे ट्रिगर किया", उसकी आप वास्तव में समीक्षा कर सकते हैं, उस पर भरोसा कर सकते हैं, या गलती होने पर उसे पकड़ सकते हैं।
आंकड़े असल में क्या बताते हैं
टीम ने वास्तविक सामग्री से एक बेंचमार्क तैयार किया: पाँच राज्यों के DOTs से 1,898 पन्नों के स्टैंडर्ड प्लैन्स, जिन्हें 4,056 सवाल-जवाब जोड़ों में बदला गया। ज़ीरो-शॉट रिट्रीवल (zero-shot retrieval—यानी मॉडल को पहले से प्लैन्स के इस विशिष्ट सेट पर फ़ाइन-ट्यून नहीं किया गया था) पर, PlanSightRAG ने 91.47% Recall@5 हासिल किया। इस मीट्रिक का अर्थ है: किसी दिए गए प्रश्न के लिए, क्या सही सोर्स पेज सिस्टम द्वारा रिट्रीव किए गए शीर्ष 5 पेजेस में शामिल है? इतनी घनी और असंरचित (unstructured) ड्रॉइंग्स पर 91% से अधिक बार सही परिणाम पाना एक ठोस उपलब्धि है।
मेरे लिए अधिक आश्वस्त करने वाला आंकड़ा वह है जो मिशिगन DOT के एक अलग रखे गए (held-out) कॉर्पस पर सामने आया, जो मूल पाँच राज्यों का हिस्सा नहीं था: 91.40% Recall@5, जो इन-डिस्ट्रीब्यूशन (in-distribution) परिणाम के लगभग बराबर है। अलग-अलग राज्य अपने स्टैंडर्ड प्लैन्स को अलग तरह से फ़ॉर्मेट करते हैं। ऐसा सिस्टम जो केवल उन्हीं ड्रॉइंग्स पर काम करता है जिनके आधार पर उसे ट्यून किया गया था, उस DOT के किसी काम का नहीं जो ट्रेनिंग सेट में शामिल नहीं था। किसी नए राज्य के प्लान फ़ॉर्मेट पर इतनी सटीकता से जनरलाइज़ कर पाना ही वह परिणाम है जो असल में यह दर्शाता है कि यह दृष्टिकोण महज़ कुछ लेआउट्स को रटने के बजाय सामान्य प्लान-रीडिंग संरचना को समझ रहा है।
जहाँ पेपर अधिक ईमानदार और अधिक दिलचस्प हो जाता है
कम्प्लायंस-चेकिंग के नतीजों पर मैं थोड़ा रुकना चाहूँगा, क्योंकि यहाँ दी गई मुख्य हेडलाइन संख्या के साथ एक शर्त (asterisk) जुड़ी है, जिसे खुद रिसर्च पेपर में ही स्पष्ट किया गया है।
सिंथेटिक और पैरामीट्रिकली जेनरेटेड कम्प्लायंस ड्रॉइंग्स (यानी ऐसी ड्रॉइंग्स जिन्हें ज्ञात और प्रोग्रामेटिक रूप से नियंत्रित मानों के साथ बनाया गया है ताकि सही उत्तर पूरी तरह स्पष्ट हो) पर, 72-बिलियन पैरामीटर वाले विज़न-लैंग्वेज मॉडल Qwen2.5-VL-72B पर आधारित पाइपलाइन 100% वर्डिक्ट एक्यूरेसी (verdict accuracy) तक पहुँचती है। लेकिन यह केवल एक विशेष शर्त के तहत ही संभव होता है: जब सिस्टम को वह नियम थ्रेशोल्ड पहले से किसी संख्या के रूप में सुलझा कर सौंप दिया जाता है जिसके आधार पर उसे जाँच करनी है। दूसरे शब्दों में, यदि आप मॉडल से कहते हैं कि "यहाँ अधिकतम अनुमत मान 6 इंच है", तो वह हर बार ड्रॉइंग के डायमेंशन की तुलना 6 इंच से बिल्कुल सही करता है।
यह एक नियंत्रित सीमा (controlled ceiling) है, और पेपर में साफ़ तौर पर स्वीकार किया गया है कि यह एक अधिकतम सीमा है, न कि एंड-टू-एंड कम्प्लायंस चेकिंग का कोई संपूर्ण प्रदर्शन। यह केवल यह दिखाता है कि मॉडल ड्रॉइंग पर मौजूद किसी संख्या की तुलना किसी दूसरी संख्या से सही तरीके से कर सकता है—जिसकी पुष्टि होना अच्छा है, लेकिन यह इस कार्य का कठिन हिस्सा बिल्कुल नहीं है। वास्तव में उपयोगी तुलना यह है: बिना किसी विज़न मॉडल के, केवल नॉन-VLM OCR बेसलाइन ही उसी सेटअप पर पहले से 76.4% तक पहुँच जाता है। इसका मतलब है कि इस विशिष्ट बेंचमार्क का एक बड़ा हिस्सा ड्रॉइंग की ज्योमेट्री को समझे बिना भी, केवल संख्याओं को एक्सट्रैक्ट करके और उनकी तुलना करके हल किया जा सकता है। 76.4% और 100% के बीच का अंतर वास्तविक ज़रूर है, लेकिन यह अंतर "OCR बनाम एक फैंसी विज़न सिस्टम" के पहली नज़र वाले दावे की तुलना में कहीं छोटा है। जब कोई पेपर 100% के आंकड़े से शुरुआत करे, तो यह बात याद रखना ज़रूरी है।
मेरे विचार में इस पेपर का सबसे महत्वपूर्ण योगदान अंत में दिया गया वह छोटा और कम चमकदार परिणाम है: ऑटोनॉमस रूल-ग्राउंडिंग (autonomous rule-grounding)। इसमें सिस्टम को कम्प्लायंस थ्रेशोल्ड पहले से नहीं थमाया जाता, बल्कि वह किसी स्पेसिफिकेशन कॉर्पस से सीधे संख्यात्मक सीमा निकालता है, जहाँ कोई इंसान पहले से नियम तय करके नहीं देता। यह इस कार्य का वह रूप है जो व्यावहारिक रूप से कम्प्लायंस चेकिंग की वास्तविक ज़रूरतों से मेल खाता है: आपको सीधे नियम की संख्या नहीं मिलती, बल्कि आपको स्पेक बुक (spec book) में जाकर उसे ढूंढना होता है और फिर ड्रॉइंग पर सही ढंग से लागू करना होता है। यह पहले से तय दो संख्याओं की तुलना करने से कहीं अधिक कठिन समस्या है, और यदि इस सिस्टम को प्रोडक्शन में डिप्लॉय करने लायक बनना है तो उसे इसी काम में लगातार भरोसेमंद साबित होना होगा। पेपर यह दिखाता है कि यह काम करता है, हालाँकि इसके लिए कोई प्रमुख एक्यूरेसी आंकड़ा नहीं दिया गया है—जो खुद यह संकेत देता है कि इस घटक को बेंचमार्क-रेडी होने के लिए अभी कितना लंबा सफ़र तय करना बाकी है।
Document AI बनाने या खरीदने वालों के लिए यह क्यों मायने रखता है
यदि आप ऐसे डॉक्यूमेंट पाइपलाइन्स बना रहे हैं जो इंजीनियरिंग ड्रॉइंग्स, आर्किटेक्चरल प्लैन्स, इलेक्ट्रिकल स्कीमेटिक्स, या ऐसी किसी भी चीज़ से निपटते हैं जहाँ अर्थ शब्दों के बजाय निशानों के बीच स्थानिक संबंधों (spatial relationships) में छुपा होता है, तो यह पेपर एक अहम नियम को अपनाने का ठोस तर्क देता है: पहले OCR करके बाद में सवाल मत पूछिए। टेक्स्ट में बदलने से ऐसी जानकारी नष्ट हो जाती है जिसे आसानी से दोबारा नहीं बनाया जा सकता, और OCR आउटपुट पर कितनी भी चतुराई भरी प्रॉम्प्टिंग क्यों न कर ली जाए, वह जानकारी वापस नहीं आती।
OCR या document-AI वेंडर्स का मूल्यांकन करने वाली प्रोडक्ट टीमों के लिए, यहाँ दिए गए रिट्रीवल आंकड़े (91%+ Recall@5, जो किसी नए राज्य के प्लान फ़ॉर्मेट पर भी कायम रहते हैं) एक बेहद उपयोगी पैमाना हैं, खासकर यदि आप लेआउट-प्रधान दस्तावेज़ों से निपट रहे हों: जैसे नक्शे, तकनीकी ड्रॉइंग्स, जटिल तालिकाओं वाले फ़ॉर्म, या ऐसा कुछ भी जहाँ कोई इंसान पन्ने को केवल ऊपर से नीचे के क्रम में नहीं पढ़ता। (वैसे भी, तकनीकी रूप से यह समझना ज़रूरी है कि अंग्रेज़ी में मजबूत OCR प्रदर्शन कभी भी देवनागरी जैसी लिपियों के लिए अच्छे OCR की गारंटी नहीं देता, इसलिए विज़न-फर्स्ट दृष्टिकोण और भी प्रासंगिक हो जाता है।)
और किसी प्रेजेंटेशन डेक में 100% कम्प्लायंस-वर्डिक्ट के आंकड़े को कोट करने की इच्छा रखने वालों को पहले बारीक अक्षरों (fine print) को पढ़ लेना चाहिए। यह संख्या उस सिस्टम का वर्णन करती है जो ऐसे मान की जाँच कर रहा है जिसका नियम उसे पहले ही बता दिया गया था। वास्तविक परीक्षा—बिना किसी उत्तर कुंजी के किसी स्पेक कॉर्पस से ऑटोनॉमस रूल-ग्राउंडिंग करना—ही वह चीज़ है जिस पर नज़र रखनी चाहिए, और यही वह हिस्सा भी है जिसका कोई स्पष्ट एक्यूरेसी आंकड़ा अभी सामने नहीं आया है। यह पेपर की कोई आलोचना नहीं है। आपकी पाइपलाइन का कौन सा हिस्सा पूरी तरह परीक्षित है और कौन सा हिस्सा एक होनहार शुरुआती डेमो है, इसे लेकर ईमानदार होना किसी एक विजयी प्रतिशत की तुलना में इंडस्ट्री के लोगों के लिए कहीं अधिक उपयोगी है।
क्या कमियाँ अभी बाकी हैं
कुछ बातों को ध्यान में रखना ज़रूरी है। बेंचमार्क के रिट्रीवल आंकड़े पाँच राज्यों के प्लैन्स से बने सवाल-जवाब जोड़ों पर Recall@5 से आते हैं—जो एक अच्छी शुरुआत तो है, लेकिन सभी पचास राज्यों के DOT फ़ॉर्मेटिंग नियमों की विविधता से अभी काफ़ी दूर है; काउंटी और म्युनिसिपल मानकों की तो बात ही छोड़ दीजिए जो DOT टेम्पलेट्स का बिल्कुल पालन नहीं करते। इसके अलावा कम्प्लायंस पाइपलाइन 72-बिलियन पैरामीटर वाले मॉडल पर निर्भर करती है, जिसे प्रोडक्शन में चलाना बिल्कुल भी हल्का काम नहीं है, और पेपर में लागत (cost) या लेटेंसी (latency) के ऐसे आंकड़े नहीं दिए गए हैं जो यह बता सकें कि किसी वास्तविक DOT समीक्षा कार्यालय की भारी ज़रूरतों के लिए इसे चलाना व्यावहारिक होगा या नहीं। साथ ही, सिंथेटिक कम्प्लायंस ड्रॉइंग्स एक साफ़ ग्राउंड ट्रुथ (ground truth) पाने का एक उचित तरीक़ा भले ही हों, लेकिन वे उन पुराने, हाथ से लिखे नोट्स वाले और दशकों पुराने जटिल प्लान सेट्स की तुलना में कहीं अधिक सरल हैं जिन पर आज भी असल इन्फ्रास्ट्रक्चर रिव्यू निर्भर करता है।
इनमें से कोई भी बात इसके मूल विचार को कमज़ोर नहीं करती। किसी प्लान शीट को ट्रांसक्राइब किए जाने वाले पन्ने के बजाय सर्च की जाने वाली इमेज के रूप में देखना, इस श्रेणी के दस्तावेज़ों के लिए बिल्कुल सही नज़रिया है, और रिट्रीवल के नतीजे इसका समर्थन करते हैं। कम्प्लायंस-चेकिंग वाली कहानी अभी शुरुआती दौर में है जितना कि उसके प्रस्तुतीकरण से लगता है, लेकिन पेपर इस बात को लेकर बेहद स्पष्ट है कि यह सीमा रेखा कहाँ खिंचती है—और इस क्षेत्र के अधिकांश बेंचमार्क पेपर्स के बारे में ऐसा शायद ही कहा जा सकता है।