जब भी कोई नई तकनीक सामने आती है, तो वह अतिशयोक्ति में डूब जाती है। मेरा ट्विटर "प्रभावशाली लोगों" से भरा पड़ा है जो दावा करते हैं कि उन्होंने एक ही प्रॉम्प्ट से पूरी वेबसाइट बना दी है, लेकिन जो कोई भी वेबसाइट बनाने की कोशिश कर रहा है, वह जानता है कि वे वर्तमान में छोटे-छोटे कार्यों को लागू करने और किसी भी लंबी दूरी के कार्य को संदर्भ के रूप में संपूर्ण कोड रिपॉजिटरी के साथ गहराई से करने के लिए पर्याप्त रूप से सक्षम हैं।
याद है जब लगभग दस साल पहले हमसे वादा किया गया था कि कल सेल्फ-ड्राइविंग कार आ जाएगी? 8 साल पहले एलन मस्क ने कहा था कि सेल्फ-ड्राइविंग एक हल की गई समस्या है।
जब हम टेस्ला द्वारा डोनट्स बनाने की शुरुआत का इंतज़ार कर रहे थे, तब कम आकर्षक प्रयास भी चल रहे थे। मोबाइलआई ने एक सेंसर बनाया जो तब बीप करता है जब आप किसी चीज़ से टकराने वाले होते हैं। उन्होंने अनगिनत लोगों की जान बचाई और बीमा दावों में लगभग 90% की कमी की। उन्होंने 17 बिलियन डॉलर की कंपनी बनाई।
मेरा मानना है कि दस्तावेज़ों को समझना एलएलएम के लिए मोबाइलआई तकनीक है। वित्तीय तालिकाओं को समझना, बीमा दावों को सारणीबद्ध करना और डॉक्टर के नोट्स से मेडिकल कोड निकालना बड़े सपनों की तुलना में मामूली लगता है। लेकिन अगर आप इस समस्या पर डबल-क्लिक करते हैं, तो आप पाएंगे कि यह पहले अनसुलझी थी और यह बहुत सारे मूल्य अनलॉक करती है।
एक दशक पहले, मैंने लिंक्डइन की शानदार डेटा मानकीकरण टीम के लिए काम किया था। हम एक भ्रामक सरल समस्या को हल करने की कोशिश कर रहे थे: आप किसी भी रिज्यूमे को कैसे समझ सकते हैं, चाहे वह कहीं से भी आया हो, और उसके शीर्षकों को मान्यता प्राप्त शीर्षकों के एक छोटे समूह से कैसे जोड़ा जाए?
आपको लगता होगा कि यह आसान होगा। मेरा मतलब है, "सॉफ्टवेयर इंजीनियर" एक बहुत ही सीधा-सादा शीर्षक है, है न? लेकिन अगर कोई "एसोसिएट" लिखता है तो क्या होगा? वे अलमारियों में सामान रख सकते हैं या किसी लॉ फर्म में छह-अंकीय वेतन पा सकते हैं। स्टेशन हैंड (ऑस्ट्रेलियाई काउबॉय) क्या है, कंसल्टेंट (सलाहकार/फ्रीलांस का मतलब हो सकता है, लेकिन अगर आप ब्रिटिश हैं और आपके पास इसके लिए सही पृष्ठभूमि है तो इसका मतलब डॉक्टर भी हो सकता है) क्या है? यदि आप नौकरी के शीर्षकों को मान्यता प्राप्त वस्तुओं की सूची में फिट करने की कोशिश कर रहे हैं ताकि आप खोज, बिक्री आदि के लिए अनुक्रमणिका बना सकें - तो आप एक ऐसा मॉडल कैसे बनाएंगे जो सभी भाषाओं और संस्कृतियों की बारीकियों को जानता हो, और "कार्यकारी सहायक" को कार्यकारी न समझे, जबकि सहायक क्षेत्रीय प्रबंधक वास्तव में क्षेत्रीय प्रबंधक का डिप्टी है?
ठीक है, तो यह अच्छा है, लेकिन अगर मैं लिंक्डइन के लिए काम कर रहा हूं, तो मुझे ठोस डेटा प्रकारों की आवश्यकता होगी। मुझे JSON चाहिए।
नौकरी के शीर्षकों को एक मानक वर्गीकरण में मैप करने के लिए और अधिक काम करने की आवश्यकता है - स्वीकार्य पूर्वनिर्धारित नौकरी के शीर्षकों की एक सीमित सूची। लेकिन आप देख सकते हैं कि कैसे अतीत में जो बहुत कठिन था वह तुच्छ हो जाता है।
रिज्यूमे पढ़ना एक अच्छा प्रयोग है, लेकिन मुझे लगता है कि यह क्रांतिकारी नहीं है। लिंक्डइन एक तकनीकी कंपनी है और हमेशा इस समस्या के लिए सबसे तेज़ धारदार हथियार इस्तेमाल करती रही है। यह कुछ हद तक बेहतर हो सकता है, लेकिन हम केवल एक कोड स्वचालन प्रक्रिया को दूसरे से बदल रहे हैं।
जब आप थकाऊ शारीरिक श्रम को हटा देते हैं तो चीजें और भी दिलचस्प हो जाती हैं। अर्थव्यवस्था का एक बड़ा हिस्सा ऐसे लोगों पर आधारित है जो विशेषज्ञ कार्य करते हैं जो “किसी दस्तावेज़ को पढ़ना, यह समझना कि उसमें क्या लिखा है, और उस प्रक्रिया को बार-बार दोहराना” तक सीमित होते हैं।
मैं आपको कुछ उदाहरण देता हूँ:
व्यय प्रबंधन: आपके पास एक चालान है, और किसी को इसे संख्याओं की सूची में बदलना है - क्या भुगतान किया गया, किसे, और किस मुद्रा में। आसान लगता है? नहीं, जब यह अतिरिक्त जानकारी, अधूरी तालिकाओं, या पीडीएफ के ढेर में दबा हुआ हो, जो ऐसा दिखता हो जैसे किसी ने उन्हें ब्लेंडर में डाल दिया हो।
हेल्थकेयर क्लेम प्रोसेसिंग: यह एक दुःस्वप्न है, जिसे हेल्थकेयर क्लेम निर्णायकों की एक सेना द्वारा हल किया जाता है। वे चालान, क्लिनिशियन नोट्स और चालान के ढेरों को छानते हैं, जिन्हें डुप्लिकेट के साथ एक उलझी हुई गड़बड़ी में एक साथ लाना होता है, और इसे मौजूदा स्वास्थ्य बीमा पॉलिसी से मिलाना होता है और यह पता लगाना होता है कि क्या चार्ज कवर किया गया है, किस श्रेणी के तहत और कितनी राशि के लिए। लेकिन जब आप इस पर आते हैं तो यह ज्यादातर सिर्फ पढ़ना, छांटना और लेबल लगाना होता है। निर्णय कठिन नहीं हैं; यह डेटा निष्कर्षण है जो चुनौती है।
लोन अंडरराइटिंग: किसी के बैंक स्टेटमेंट की समीक्षा करना और उनके नकदी प्रवाह को वर्गीकृत करना। फिर से, यह रॉकेट साइंस से ज़्यादा असंरचित जानकारी को संरचित करने के बारे में है।
ग्लैमरस? नहीं। उपयोगी? मुझे ऐसा लगता है।
अब तक, एलएलएम मतिभ्रम के लिए कुख्यात हो चुके हैं - यानी बकवास करना। लेकिन वास्तविकता अधिक सूक्ष्म है: जब आप दुनिया के बारे में जानकारी मांगते हैं तो मतिभ्रम की उम्मीद की जाती है, लेकिन मूल रूप से एक ग्राउंडेड कार्य में इसे समाप्त कर दिया जाता है।
एलएलएम विशेष रूप से यह आकलन करने में अच्छे नहीं हैं कि वे क्या "जानते हैं" - यह एक सौभाग्यपूर्ण उपोत्पाद है कि वे ऐसा कर सकते हैं क्योंकि उन्हें इसके लिए स्पष्ट रूप से प्रशिक्षित नहीं किया गया था। उनका प्राथमिक प्रशिक्षण पाठ अनुक्रमों की भविष्यवाणी करना और उन्हें पूरा करना है। हालाँकि, जब किसी एलएलएम को एक ग्राउंडेड कार्य दिया जाता है - जहाँ केवल स्पष्ट रूप से दिए गए इनपुट की भविष्यवाणी करने की आवश्यकता होती है, तो मतिभ्रम की दर को मूल रूप से शून्य तक लाया जा सकता है। उदाहरण के लिए, यदि आप इस ब्लॉग पोस्ट को ChatGPT में पेस्ट करते हैं और पूछते हैं कि क्या यह बताता है कि अपने पालतू फेरेट की देखभाल कैसे करें, तो मॉडल 100% समय सही उत्तर देगा। कार्य पूर्वानुमान योग्य हो जाता है। एलएलएम पाठ के एक हिस्से को संसाधित करने और यह अनुमान लगाने में माहिर हैं कि एक सक्षम विश्लेषक रिक्त स्थान कैसे भरेगा, जिनमें से एक {“फेरेट देखभाल पर चर्चा”: गलत} हो सकता है।
एक पूर्व एआई सलाहकार के रूप में, हमने दस्तावेजों से जानकारी निकालने पर केंद्रित परियोजनाओं पर काम किया, विशेष रूप से बीमा और वित्त जैसे उद्योगों में। आम डर था "एलएलएम भ्रम में हैं," लेकिन व्यवहार में, सबसे बड़ी चुनौतियाँ अक्सर तालिकाओं को निकालने में त्रुटियों या अन्य इनपुट असंगतियों के कारण होती थीं। एलएलएम केवल तभी विफल होते हैं जब हम उन्हें साफ, स्पष्ट इनपुट के साथ प्रस्तुत करने में विफल होते हैं। दस्तावेज़ प्रसंस्करण को सफलतापूर्वक स्वचालित करने के लिए दो प्रमुख घटक हैं:
परफेक्ट टेक्स्ट एक्सट्रैक्शन - इसमें दस्तावेज़ को साफ, मशीन-पठनीय टेक्स्ट में बदलना शामिल है, जिसमें टेबल, हस्तलिखित नोट्स या विभिन्न लेआउट शामिल हैं। LLM को काम करने के लिए स्पष्ट, समझने योग्य टेक्स्ट की आवश्यकता होती है।
मजबूत स्कीमा - इन स्कीमा को यह परिभाषित करना चाहिए कि आप किस आउटपुट की तलाश कर रहे हैं, एज मामलों को कैसे संभालना है, और डेटा का प्रारूप क्या है, जिससे यह सुनिश्चित हो सके कि सिस्टम को पता है कि प्रत्येक दस्तावेज़ प्रकार से क्या निकालना है।
मतिभ्रम के संभावित जोखिम और वास्तविक तकनीकी बाधाओं के बीच का अंतर बहुत बड़ा हो सकता है, लेकिन इन बुनियादी बातों के साथ, आप दस्तावेज़ प्रसंस्करण वर्कफ़्लो में एलएलएम का प्रभावी ढंग से लाभ उठा सकते हैं।
यहां बताया गया है कि LLM के क्रैश होने और जलने तथा अत्यंत खराब आउटपुट प्राप्त करने के क्या कारण हैं:
यह याद रखना हमेशा मददगार होता है कि वास्तविक दुनिया के दस्तावेजों में क्या गड़बड़ होती है। यहाँ एक यादृच्छिक कर फ़ॉर्म है:
बेशक, असली टैक्स फॉर्म में ये सभी फ़ील्ड भरे होते हैं, अक्सर हस्तलिखित रूप में
या ये रहा मेरा बायोडाटा
या सार्वजनिक रूप से उपलब्ध उदाहरण प्रयोगशाला रिपोर्ट (यह गूगल का प्रथम पृष्ठ परिणाम है)
वैसे, सबसे खराब चीज जो आप कर सकते हैं, वह है GPT की मल्टीमॉडल क्षमताओं से टेबल को ट्रांसक्राइब करने के लिए कहना। अगर हिम्मत है तो इसे आजमाएं - यह पहली नज़र में सही लगता है, कुछ टेबल सेल के लिए बिल्कुल बेतरतीब चीजें बनाता है, चीजों को पूरी तरह से संदर्भ से बाहर ले जाता है, आदि।
जब हमें इस प्रकार के दस्तावेजों को समझने का काम सौंपा गया, तो मेरे सह-संस्थापक निताई डीन और मैं इस बात से हैरान थे कि इन पाठों को समझने के लिए कोई भी तात्कालिक समाधान उपलब्ध नहीं था।
कुछ लोग इसे हल करने का दावा करते हैं, जैसे AWS Textract। लेकिन वे हमारे द्वारा परीक्षण किए गए किसी भी जटिल दस्तावेज़ पर कई गलतियाँ करते हैं। फिर आपके पास छोटी-छोटी ज़रूरी चीज़ों की लंबी पूंछ होती है, जैसे चेकमार्क, रेडियो बटन, क्रॉस-आउट टेक्स्ट, फ़ॉर्म पर हस्तलिखित स्क्रिबल्स आदि को पहचानना।
इसलिए, हमने Docupanda.io बनाया - जो सबसे पहले आपके द्वारा डाले गए किसी भी पेज का एक साफ टेक्स्ट प्रतिनिधित्व तैयार करता है। बाएं हाथ पर आपको मूल दस्तावेज़ दिखाई देगा, और दाईं ओर, आप टेक्स्ट आउटपुट देख सकते हैं।
तालिकाओं को भी इसी तरह से संभाला जाता है। हुड के नीचे, हम बस तालिकाओं को मानव और LLM-पठनीय मार्कडाउन प्रारूप में परिवर्तित करते हैं:
एलएलएम के साथ डेटा को समझने का अंतिम चरण कठोर आउटपुट प्रारूपों को उत्पन्न करना और उनका पालन करना है। यह बहुत बढ़िया है कि हम एआई को अपने आउटपुट को JSON में ढाल सकते हैं, लेकिन डेटा पर नियम, तर्क, क्वेरी आदि लागू करने के लिए - हमें इसे नियमित रूप से व्यवहार करने की आवश्यकता है। डेटा को स्लॉट के पूर्वनिर्धारित सेट के अनुरूप होना चाहिए जिसे हम सामग्री से भर देंगे। डेटा की दुनिया में, हम इसे स्कीमा कहते हैं।
हमें स्कीमा की आवश्यकता इसलिए है क्योंकि नियमितता के बिना डेटा बेकार है। अगर हम मरीज़ों के रिकॉर्ड प्रोसेस कर रहे हैं, और वे “पुरुष” “पुरुष” “एम” और “एम” से मेल खाते हैं - तो हम बहुत खराब काम कर रहे हैं।
तो आप स्कीमा कैसे बनाते हैं? किसी पाठ्यपुस्तक में, आप लंबे समय तक बैठकर और दीवार को घूरकर स्कीमा बना सकते हैं, और परिभाषित कर सकते हैं कि आप क्या निकालना चाहते हैं। आप वहां बैठते हैं, अपने स्वास्थ्य सेवा डेटा ऑपरेशन पर विचार करते हैं, और कहते हैं "मैं रोगी का नाम, तिथि, लिंग और उनके चिकित्सक का नाम निकालना चाहता हूं। ओह, और लिंग एम/एफ/अन्य होना चाहिए।"
वास्तविक जीवन में, यह निर्धारित करने के लिए कि दस्तावेजों से क्या निकालना है, आप अपने दस्तावेजों को घूरते रहते हैं... बहुत बार। आप ऊपर बताए गए तरीके से शुरू करते हैं, लेकिन फिर आप दस्तावेजों को देखते हैं और पाते हैं कि उनमें से एक में एक के बजाय चिकित्सकों की सूची है। और उनमें से कुछ में चिकित्सकों का पता भी सूचीबद्ध है। कुछ पतों पर एक यूनिट नंबर और एक बिल्डिंग नंबर होता है, इसलिए शायद आपको उसके लिए एक स्लॉट की आवश्यकता हो। यह सिलसिला चलता रहता है।
हमने यह महसूस किया कि यह निर्धारित कर पाना कि आप क्या-क्या निकालना चाहते हैं, न केवल आसान है, बल्कि कठिन भी है, तथा एआई के माध्यम से इसे आसानी से हल किया जा सकता है।
यह DocuPanda का एक महत्वपूर्ण हिस्सा है। किसी LLM को हर दस्तावेज़ के लिए आउटपुट सुधारने के लिए कहने के बजाय, हमने ऐसा तंत्र बनाया है जो आपको यह करने देता है:
अंत में आपको एक शक्तिशाली JSON स्कीमा प्राप्त होगी - एक टेम्पलेट जो यह बताता है कि आप प्रत्येक दस्तावेज़ से क्या निकालना चाहते हैं, तथा उनमें से सैकड़ों-हजारों का मानचित्रण करता है, उन सभी के उत्तर निकालता है, तथा साथ ही हमेशा एक ही प्रारूप में तिथियों को निकालने, पूर्वनिर्धारित श्रेणियों के एक सेट का सम्मान करने आदि जैसे नियमों का पालन करता है।
किसी भी खरगोश के बिल की तरह, हमेशा उससे ज़्यादा चीज़ें होती हैं जो पहली नज़र में दिखती हैं। जैसे-जैसे समय बीतता गया, हमने पाया कि और भी चीज़ों की ज़रूरत है:
अक्सर संगठनों को गुमनाम दस्तावेजों की आने वाली धारा से निपटना पड़ता है, इसलिए हम स्वचालित रूप से उन्हें वर्गीकृत करते हैं और निर्णय लेते हैं कि उन पर कौन सी स्कीमा लागू करनी है
दस्तावेज़ कभी-कभी कई दस्तावेज़ों का एक संयोजन होते हैं, और आपको एक बहुत लंबे दस्तावेज़ को उसके परमाणु, अलग घटकों में तोड़ने के लिए एक बुद्धिमान समाधान की आवश्यकता होती है
उत्पन्न परिणामों का उपयोग करके सही दस्तावेज़ों के लिए क्वेरी करना बहुत उपयोगी है
अगर इस पोस्ट से कोई एक सीख मिलती है, तो वह यह है कि आपको नियमित तरीके से दस्तावेजों को समझने के लिए एलएलएम का उपयोग करना चाहिए। अगर दो सीख मिलती हैं, तो वह यह है कि आपको Docupanda.io को भी आज़माना चाहिए। मैं इसे इसलिए बना रहा हूँ क्योंकि मुझे इसमें विश्वास है। शायद यह इसे आज़माने के लिए पर्याप्त कारण है?