दस्तावेज़ों ने दशकों तक अपनी सामग्री को सॉफ़्टवेयर से सुरक्षित रखने में हठपूर्वक खर्च किया है। 1960 के दशक के उत्तरार्ध में, पहली OCR (ऑप्टिकल कैरेक्टर रिकग्निशन) तकनीकों ने स्कैन किए गए दस्तावेज़ों को कच्चे पाठ में बदल दिया। इन डिजीटल दस्तावेजों से पाठ को अनुक्रमित और खोजकर, सॉफ्टवेयर ने पूर्व में श्रमसाध्य कानूनी खोज और अनुसंधान परियोजनाओं को गति दी।
आज, Google, Microsoft और Amazon अपनी क्लाउड सेवाओं की पेशकश के हिस्से के रूप में उच्च गुणवत्ता वाले OCR प्रदान करते हैं। लेकिन सॉफ़्टवेयर टूलचेन में दस्तावेज़ों का कम उपयोग किया जाता है, और मूल्यवान डेटा समाप्त हो जाता है
प्रचलित धारणा यह है कि मशीन लर्निंग, जिसे अक्सर "एआई" के रूप में अलंकृत किया जाता है, इसे प्राप्त करने का सबसे अच्छा तरीका है, पुरानी और भंगुर टेम्पलेट-आधारित तकनीकों का स्थान लेना। यह धारणा पथभ्रष्ट है। दस्तावेज़ों के विशाल बहुमत को संरचित डेटा में बदलने का सबसे अच्छा तरीका अगली पीढ़ी के शक्तिशाली, लचीले टेम्प्लेट का उपयोग करना है जो किसी व्यक्ति के रूप में दस्तावेज़ में डेटा ढूंढते हैं।
मशीन लर्निंग का वादा यह है कि आप एक मॉडल को एक बार प्रतिनिधि दस्तावेजों के एक बड़े समूह पर प्रशिक्षित कर सकते हैं और फिर बिना किसी प्रशिक्षण के आउट-ऑफ-सैंपल दस्तावेज़ लेआउट को आसानी से सामान्यीकृत कर सकते हैं। उदाहरण के लिए, आप कंपनी ए, बी, और सी की गृह बीमा पॉलिसियों पर एक एमएल मॉडल को प्रशिक्षित करना चाहते हैं, और फिर कंपनी जेड द्वारा जारी किए गए समान दस्तावेजों से समान डेटा निकालना चाहते हैं। यह तीन कारणों से व्यवहार में हासिल करना बहुत मुश्किल है:
आपका लक्ष्य अक्सर प्रत्येक दस्तावेज़ से दर्जनों या सैकड़ों व्यक्तिगत डेटा तत्वों को निकालना होता है। विवरण के दस्तावेज़ स्तर पर एक मॉडल अक्सर इनमें से कुछ मूल्यों को याद करेगा, और उन त्रुटियों का पता लगाना काफी मुश्किल है। एक बार जब आपका मॉडल उन दर्जनों या सैकड़ों डेटा तत्वों को आउट-ऑफ-सैंपल दस्तावेज़ प्रकारों से निकालने का प्रयास करता है, तो आपको सामान्यीकरण विफलता के अवसरों का एक विस्फोट मिलता है।
जबकि कुछ साधारण दस्तावेजों में एक फ्लैट कुंजी/मूल्य ऑन्कोलॉजी हो सकती है, अधिकांश में एक सबस्ट्रक्चर होगा: एक घर निरीक्षण रिपोर्ट में कमियों की सूची या बैंक स्टेटमेंट में लेनदेन के सेट के बारे में सोचें। कुछ मामलों में आप जटिल नेस्टेड सबस्ट्रक्चर का भी सामना करेंगे: बीमा पॉलिसियों की एक सूची के बारे में सोचें, जिनमें से प्रत्येक का दावा इतिहास है। इन पदानुक्रमों का अनुमान लगाने के लिए आपको या तो अपने मशीन लर्निंग मॉडल की आवश्यकता है, या आपको प्रशिक्षण से पहले इन पदानुक्रमों और समग्र वांछित ऑन्कोलॉजी के साथ मॉडल को मैन्युअल रूप से पैरामीटर करने की आवश्यकता है।
एक दस्तावेज़ कुछ भी है जो कागज की एक या एक से अधिक शीट पर फिट बैठता है और इसमें डेटा होता है! दस्तावेज़ वास्तव में विविध और मनमाने डेटा अभ्यावेदन के बैग हैं। टेबल्स, लेबल्स, फ्री टेक्स्ट, सेक्शन, इमेज, हेडर और फुटर: आप इसे नाम देते हैं और एक दस्तावेज़ डेटा को एन्कोड करने के लिए इसका इस्तेमाल कर सकता है। इस बात की कोई गारंटी नहीं है कि एक ही शब्दार्थ के साथ भी दो दस्तावेज़ एक ही प्रतिनिधित्वात्मक टूल का उपयोग करेंगे।
यह कोई आश्चर्य की बात नहीं है कि एमएल-आधारित दस्तावेज़ पार्सिंग परियोजनाओं में महीनों लग सकते हैं, इसके लिए बहुत सारे डेटा की आवश्यकता होती है, जो प्रभावशाली परिणाम देते हैं, और सामान्य तौर पर "भीषण" होते हैं (अंतरिक्ष में एक अग्रणी विक्रेता के साथ ऐसी एक परियोजना में एक प्रतिभागी को सीधे उद्धृत करने के लिए) )
ये मुद्दे दृढ़ता से सुझाव देते हैं कि दस्तावेजों की संरचना के लिए हमले का उपयुक्त कोण संपूर्ण-दस्तावेज़ स्तर के बजाय डेटा तत्व स्तर पर है। दूसरे शब्दों में, हमें टेबल, लेबल और फ्री टेक्स्ट से डेटा निकालने की जरूरत है; एक समग्र "दस्तावेज़" से नहीं। और डेटा तत्व स्तर पर, हमें दस्तावेज़ों में पाए जाने वाले प्रतिनिधित्वात्मक मोड के ब्रह्मांड और सॉफ़्टवेयर के लिए उपयोगी डेटा संरचनाओं के बीच संबंध व्यक्त करने के लिए शक्तिशाली टूल की आवश्यकता होती है।
तो चलिए वापस टेम्पलेट्स पर आते हैं।
ऐतिहासिक रूप से, टेम्प्लेट में प्रतिनिधित्वात्मक मोड और डेटा संरचना के बीच उस मानचित्रण को व्यक्त करने का एक खराब साधन रहा है। उदाहरण के लिए, वे निर्देश दे सकते हैं: पेज 3 पर जाएं और इन बॉक्स निर्देशांकों के भीतर कोई भी टेक्स्ट लौटाएं। यह कई कारणों से तुरंत टूट जाता है, जिसमें निम्न शामिल हैं:
दस्तावेज़ लेआउट में इन मामूली परिवर्तनों में से कोई भी मानव पाठक को भ्रमित नहीं करेगा।
सॉफ़्टवेयर के लिए जटिल दस्तावेज़ों को सफलतापूर्वक संरचित करने के लिए, आप एक ऐसा समाधान चाहते हैं जो महीनों तक चलने वाली एमएल परियोजनाओं बनाम भंगुर टेम्पलेट्स की लड़ाई को दरकिनार कर दे। इसके बजाय, आइए एक दस्तावेज़-विशिष्ट क्वेरी भाषा का निर्माण करें जो (जब उपयुक्त हो) ML को दस्तावेज़, स्तर के बजाय डेटा तत्व पर एम्बेड करती है।
सबसे पहले, आप उस भाषा में आदिम (यानी, निर्देश) चाहते हैं जो प्रतिनिधित्वात्मक मोड (जैसे लेबल/मूल्य जोड़ी या दोहराए जाने वाले उपखंडों) का वर्णन करता है और सामान्य लेआउट विविधताओं के लिए लचीला रहता है। उदाहरण के लिए, यदि आप कहते हैं:
"इस शब्द से शुरू होने वाली एक पंक्ति खोजें और इससे सबसे कम डॉलर की राशि प्राप्त करें"
आप "पंक्ति" पहचान चाहते हैं जो व्हाइटस्पेस भिन्नता, लंबवत जिटर, कवर पेज, और दस्तावेज़ तिरछा के लिए लचीला है, और आप शक्तिशाली प्रकार का पता लगाना और फ़िल्टर करना चाहते हैं।
दूसरा, एक दृश्य या प्राकृतिक भाषा घटक के साथ डेटा प्रतिनिधित्व के लिए, जैसे कि टेबल, चेकबॉक्स और मुक्त पाठ के पैराग्राफ, आदिम को एमएल को एम्बेड करना चाहिए। विश्लेषण के इस स्तर पर, Google, Amazon, Microsoft और OpenAI सभी के पास ऐसे उपकरण हैं जो शेल्फ से काफी अच्छी तरह से काम करते हैं।
सेंसिबल बस यही तरीका अपनाता है: मशीन लर्निंग के साथ शक्तिशाली और लचीले टेम्प्लेट का सम्मिश्रण। साथ
सेंसएमएल की प्राइमेटिव की विस्तृत श्रृंखला आपको जटिल नेस्टेड सबस्ट्रक्चर सहित उपयोगी डेटा संरचनाओं के लिए प्रतिनिधित्वात्मक मोड को त्वरित रूप से मैप करने की अनुमति देती है। ऐसे मामलों में जहां आदिम लोग एमएल का उपयोग नहीं करते हैं, वे मजबूत व्यवहार और सटीकता की गारंटी प्रदान करने के लिए निश्चित रूप से व्यवहार करते हैं। और यहां तक कि हमारे एमएल-संचालित प्राइमेटिव के गैर-निर्धारक आउटपुट के लिए, जैसे कि टेबल, सत्यापन नियम एमएल आउटपुट में त्रुटियों की पहचान कर सकते हैं।
इसका मतलब यह है कि सेंसिबल के साथ पार्सिंग दस्तावेज़ अविश्वसनीय रूप से तेज़, पारदर्शी और लचीला है। यदि आप किसी टेम्पलेट में कोई फ़ील्ड जोड़ना चाहते हैं या किसी त्रुटि को ठीक करना चाहते हैं, तो ऐसा करना आसान है।
सेंसिबल के रैपिड टाइम टू वैल्यू के लिए ट्रेडऑफ़ यह है कि प्रत्येक अर्थपूर्ण रूप से अलग दस्तावेज़ लेआउट के लिए एक अलग टेम्पलेट की आवश्यकता होती है। लेकिन यह ट्रेडऑफ़ वास्तविक दुनिया में इतना बुरा नहीं है। अधिकांश व्यावसायिक उपयोग के मामलों में, लेआउट की एक गणनीय संख्या होती है (उदाहरण के लिए, संयुक्त राज्य अमेरिका में दर्जनों ट्रकिंग वाहक दर की पुष्टि उत्पन्न करते हैं; कुछ मुट्ठी भर सॉफ्टवेयर सिस्टम जो घरेलू निरीक्षण रिपोर्ट तैयार करते हैं)। हमारे ग्राहक हज़ारों दस्तावेज़ टेम्प्लेट नहीं बनाते हैं - अधिकांश केवल कुछ के साथ जबरदस्त मूल्य उत्पन्न करते हैं।
बेशक, हर व्यापक रूप से इस्तेमाल किए जाने वाले टैक्स फॉर्म, बीमा पॉलिसी और रोजगार के सत्यापन के लिए, सामूहिक रूप से हमें केवल एक बार एक टेम्प्लेट बनाने की आवश्यकता होती है। इसलिए हमने पेश किया है ...
हमारा खुला स्रोत
हम मानते हैं कि यह हाइब्रिड दृष्टिकोण रसद, वित्तीय सेवाओं, बीमा और स्वास्थ्य देखभाल सहित उद्योगों की एक विस्तृत श्रृंखला के लिए दस्तावेजों को संरचित डेटा में बदलने की समस्या को पारदर्शी और कुशलता से हल करने का मार्ग है। यदि आप इस यात्रा में हमारे साथ जुड़ना चाहते हैं और अपने दस्तावेज़ों को सॉफ़्टवेयर से जोड़ना चाहते हैं,