असंरचित और अर्ध-संरचित डेटा अंतर्ग्रहण

इनवॉइस प्रोसेसिंग अब तक एक हल की गई समस्या होनी चाहिए। एक दस्तावेज़ आता है, फील्ड निकाले जाते हैं, डेटा मौजूदा रिकॉर्ड के खिलाफ मान्य किया जाता है, और परिणाम सही सिस्टम को रूट किया जाता है। वास्तविकता यह है कि अकेले इनवॉइस प्रोसेसिंग में एंटरप्राइज़ को वार्षिक मैन्युअल श्रम में अरबों की लागत आती है, और स्वचालन परियोजनाएँ जो इसे ठीक करने के लिए बनाई गई थीं, लगातार टूटती रहती हैं।

कारण फॉर्मेट विविधता है। इनवॉइस PDF, ईमेल अटैचमेंट, स्कैन की गई छवियों, स्प्रेडशीट एक्सपोर्ट, और कभी-कभी फैक्स के रूप में आते हैं। प्रत्येक विक्रेता एक अलग लेआउट का उपयोग करता है। लाइन आइटम तालिकाओं, मुक्त पाठ, या दोनों के संयोजन में दिखाई देते हैं। कर गणना क्षेत्राधिकार के अनुसार अलग-अलग नियमों का पालन करती है। मुद्रा प्रारूप भिन्न होते हैं। दिनांक प्रारूप भिन्न होते हैं। यहाँ तक कि एक ही विक्रेता बिना सूचना के अपना इनवॉइस टेम्पलेट बदलता है।

पारंपरिक RPA इसे टेम्पलेट मिलान से संभालती है। उन निर्देशांकों को परिभाषित करें जहाँ इनवॉइस नंबर दिखाई देता है, जहाँ लाइन आइटम शुरू होते हैं, जहाँ कुल रहता है। यह एकल विक्रेता के वर्तमान टेम्पलेट के लिए काम करता है। फिर विक्रेता अपना सिस्टम अपडेट करता है, एक कॉलम शिफ्ट करता है, एक हेडर पंक्ति जोड़ता है, या अपना PDF जनरेटर बदलता है, और बॉट या तो पूरी तरह विफल हो जाता है या गंदा डेटा निकालता है जो डाउनस्ट्रीम तब तक प्रचारित होता है जब तक कोई इसे मैन्युअल रूप से नहीं पकड़ता।

वही पैटर्न प्रत्येक असंरचित डेटा वर्कफ़्लो में दोहराता है। इंश्योरेंस EOB प्रोसेसिंग तब टूटती है जब कोई पेयर अपना फॉर्म लेआउट बदलता है। पूर्व प्राधिकरण सेवन तब टूटता है जब प्रक्रिया में एक नया दस्तावेज़ प्रकार जोड़ा जाता है। ग्राहक ईमेल पार्सिंग तब टूटती है जब कोई थोड़ा अलग विषय पंक्ति प्रारूप का उपयोग करता है। इन स्वचालनों को चलाते रहने की रखरखाव लागत अक्सर काम मैन्युअल रूप से करने की लागत से अधिक होती है।

Triggerfish इसे कैसे हल करता है

Triggerfish पोज़िशनल फील्ड एक्सट्रैक्शन को LLM-आधारित दस्तावेज़ समझ से बदलता है। AI दस्तावेज़ को उसी तरह पढ़ता है जैसे एक मानव करता: संदर्भ को समझना, फील्ड के बीच संबंधों का अनुमान लगाना, और लेआउट परिवर्तनों के अनुकूल होना स्वचालित रूप से। पाइपलाइन ऑर्केस्ट्रेशन के लिए वर्कफ़्लो इंजन और डेटा सुरक्षा के लिए वर्गीकरण प्रणाली के साथ संयुक्त, यह अंतर्ग्रहण पाइपलाइनें बनाता है जो दुनिया बदलने पर नहीं टूतीं।

LLM-संचालित दस्तावेज़ पार्सिंग

जब एक दस्तावेज़ Triggerfish वर्कफ़्लो में प्रवेश करता है, तो एक LLM सब-एजेंट पूरे दस्तावेज़ को पढ़ता है और संरचित डेटा निकालता है जो दस्तावेज़ के अर्थ पर आधारित होता है, न कि विशिष्ट पिक्सल कहाँ हैं। एक इनवॉइस नंबर एक इनवॉइस नंबर है चाहे वह ऊपरी-दाएँ कोने में "Invoice #" लेबल के साथ हो, पृष्ठ के मध्य में "Factura No." लेबल के साथ हो, या पाठ के एक पैराग्राफ में एम्बेड किया गया हो। LLM समझता है कि "Net 30" का अर्थ भुगतान शर्तें हैं, कि "Qty" और "Quantity" और "Units" का अर्थ एक ही है, और कि विवरण, दर, और राशि के कॉलम वाली एक तालिका कॉलम क्रम की परवाह किए बिना एक लाइन आइटम सूची है।

यह एक सामान्य "दस्तावेज़ ChatGPT को भेजें और उम्मीद करें" दृष्टिकोण नहीं है। वर्कफ़्लो परिभाषा निर्दिष्ट करती है कि LLM को क्या संरचित आउटपुट उत्पन्न करना चाहिए, कौन से सत्यापन नियम लागू होते हैं, और जब एक्सट्रैक्शन विश्वास कम होता है तो क्या होता है। सब-एजेंट कार्य विवरण अपेक्षित स्कीमा परिभाषित करता है, और वर्कफ़्लो के अगले चरण निकाले गए डेटा को किसी डाउनस्ट्रीम सिस्टम में प्रवेश करने से पहले व्यावसायिक नियमों के खिलाफ मान्य करते हैं।

दस्तावेज़ पुनर्प्राप्ति के लिए ब्राउज़र स्वचालन

कई दस्तावेज़ अंतर्ग्रहण वर्कफ़्लो पहले स्थान पर दस्तावेज़ प्राप्त करने से शुरू होती हैं। इंश्योरेंस EOBs पेयर पोर्टल में रहते हैं। विक्रेता इनवॉइस सप्लायर प्लेटफ़ॉर्म में रहते हैं। सरकारी फॉर्म राज्य एजेंसी वेबसाइटों पर रहते हैं। पारंपरिक स्वचालन इन दस्तावेज़ों को प्राप्त करने के लिए Selenium स्क्रिप्ट या API कॉल का उपयोग करती है, और जब पोर्टल बदलता है तो वे स्क्रिप्ट टूट जाती हैं।

Triggerfish का ब्राउज़र स्वचालन CDP-नियंत्रित Chromium का उपयोग करता है जिसमें LLM पृष्ठ स्नैपशॉट पढ़ने के लिए नेविगेट करता है। एजेंट पृष्ठ को उसी तरह देखता है जैसे एक मानव देखता है और हार्डकोड किए गए CSS सेलेक्टर के बजाय जो वह देखता है उसके आधार पर क्लिक, टाइप और स्क्रॉल करता है। जब एक पेयर पोर्टल अपना लॉगिन पृष्ठ पुनः डिज़ाइन करता है, तो एजेंट अनुकूलित होता है क्योंकि यह अभी भी दृश्य संदर्भ से उपयोगकर्ता नाम फील्ड, पासवर्ड फील्ड, और सबमिट बटन की पहचान कर सकता है।

यह पूरी तरह विश्वसनीय नहीं है। CAPTCHA, MFA प्रवाह, और भारी JavaScript-निर्भर पोर्टल अभी भी समस्याएं पैदा करते हैं। लेकिन विफलता का तरीका पारंपरिक स्क्रिप्ट से मौलिक रूप से अलग है। एक Selenium स्क्रिप्ट चुपचाप विफल होती है जब एक CSS सेलेक्टर मेल खाना बंद कर देता है। एक Triggerfish एजेंट रिपोर्ट करता है कि उसने क्या देखा, क्या प्रयास किया, और वह कहाँ फंस गया।

वर्गीकरण-गेटेड प्रोसेसिंग

दस्तावेज़ संवेदनशीलता के विभिन्न स्तर वहन करते हैं, और वर्गीकरण प्रणाली इसे स्वचालित रूप से संभालती है। मूल्य निर्धारण शर्तें वाला एक इनवॉइस CONFIDENTIAL हो सकता है। एक सार्वजनिक RFP प्रतिक्रिया INTERNAL हो सकती है। PHI युक्त एक दस्तावेज़ RESTRICTED है। जब LLM सब-एजेंट एक दस्तावेज़ पढ़ता है और डेटा निकालता है, तो POST_TOOL_RESPONSE hook निकाले गए सामग्री को वर्गीकृत करता है, और सत्र taint तदनुसार बढ़ता है।

यह डाउनस्ट्रीम रूटिंग के लिए मायने रखता है। CONFIDENTIAL पर वर्गीकृत निकाला गया इनवॉइस डेटा PUBLIC पर वर्गीकृत Slack चैनल में नहीं भेजा जा सकता। एक वर्कफ़्लो जो PHI युक्त इंश्योरेंस दस्तावेज़ प्रोसेस करती है, स्वचालित रूप से प्रतिबंधित करती है कि निकाला गया डेटा कहाँ जा सकता है। write-down प्रतिबंध नियम इसे प्रत्येक सीमा पर लागू करता है, और LLM के पास इसे ओवरराइड करने का शून्य अधिकार है।

स्वास्थ्य सेवा और वित्तीय सेवाओं के लिए विशेष रूप से, इसका मतलब है कि स्वचालित दस्तावेज़ प्रोसेसिंग का अनुपालन ओवरहेड नाटकीय रूप से गिर जाता है। हर पाइपलाइन के हर चरण में कस्टम एक्सेस नियंत्रण बनाने के बजाय, वर्गीकरण प्रणाली इसे समान रूप से संभालती है।

स्व-उपचार प्रारूप अनुकूलन

जब एक विक्रेता अपना इनवॉइस टेम्पलेट बदलता है, तो पारंपरिक स्वचालन टूट जाती है और तब तक टूटी रहती है जब तक कोई मैन्युअल रूप से एक्सट्रैक्शन नियमों को अपडेट नहीं करता। Triggerfish में, LLM सब-एजेंट अगले रन पर अनुकूलित होता है। यह अभी भी इनवॉइस नंबर, लाइन आइटम, और कुल खोजता है, क्योंकि यह स्थिति के बजाय अर्थ के लिए पढ़ रहा है।

समय के साथ, एजेंट क्रॉस-सत्र मेमोरी का उपयोग करके पैटर्न सीख सकता है। यदि विक्रेता A में हमेशा एक रीस्टॉकिंग शुल्क शामिल होता है जो अन्य विक्रेताओं के पास नहीं है, तो एजेंट पिछले एक्सट्रैक्शन से इसे याद रखता है और इसे खोजना जानता है। यदि एक विशेष पेयर का EOB प्रारूप हमेशा असामान्य स्थान पर समायोजन कोड डालता है, तो पिछले सफल एक्सट्रैक्शन की एजेंट की मेमोरी भविष्य को अधिक विश्वसनीय बनाती है।

जब एक प्रारूप परिवर्तन इतना महत्वपूर्ण होता है कि LLM का एक्सट्रैक्शन विश्वास वर्कफ़्लो में परिभाषित सीमा से नीचे गिर जाता है, तो वर्कफ़्लो अनुमान लगाने के बजाय दस्तावेज़ को मानव समीक्षा कतार में रूट करती है। मानव के सुधार वर्कफ़्लो के माध्यम से वापस फीड किए जाते हैं, और एजेंट की मेमोरी भविष्य के संदर्भ के लिए नए पैटर्न को संग्रहीत करती है।

पाइपलाइन ऑर्केस्ट्रेशन

दस्तावेज़ अंतर्ग्रहण शायद ही कभी सिर्फ "निकालें और संग्रहीत करें" होता है। एक पूर्ण पाइपलाइन दस्तावेज़ प्राप्त करती है, संरचित डेटा निकालती है, मौजूदा रिकॉर्ड के खिलाफ इसे मान्य करती है, अन्य प्रणालियों से डेटा के साथ इसे समृद्ध करती है, अपवादों को मानव समीक्षा के लिए रूट करती है, और मान्य डेटा को लक्ष्य सिस्टम में लोड करती है। वर्कफ़्लो इंजन एक YAML परिभाषा में यह सब संभालता है।

एक हेल्थकेयर पूर्व प्राधिकरण पाइपलाइन इस तरह दिख सकती है: ब्राउज़र स्वचालन प्रदाता पोर्टल से फैक्स छवि प्राप्त करता है, एक LLM सब-एजेंट रोगी पहचानकर्ता और प्रक्रिया कोड निकालता है, एक HTTP कॉल EHR के खिलाफ रोगी को मान्य करता है, दूसरा सब-एजेंट आकलन करता है कि क्या प्राधिकरण नैदानिक दस्तावेज़ीकरण के आधार पर चिकित्सा आवश्यकता मानदंडों को पूरा करता है, और परिणाम स्वतः-अनुमोदन या नैदानिक समीक्षक कतार में रूट किया जाता है। हर चरण वर्गीकरण-ट्रैक किया जाता है। PHI का हर टुकड़ा taint-टैग किया जाता है।

व्यवहार में यह कैसा दिखता है

एक क्षेत्रीय स्वास्थ्य प्रणाली चालीस अलग-अलग प्रदाता कार्यालयों से पूर्व प्राधिकरण अनुरोध प्रोसेस करती है, प्रत्येक अपने फॉर्म लेआउट का उपयोग करते हुए, कुछ फैक्स किए गए, कुछ ईमेल किए गए, कुछ पोर्टल पर अपलोड किए गए। पारंपरिक दृष्टिकोण के लिए आठ लोगों की एक टीम की आवश्यकता थी जो प्रत्येक अनुरोध की मैन्युअल समीक्षा और प्रवेश करे, क्योंकि कोई भी स्वचालन उपकरण प्रारूप विविधता को विश्वसनीय रूप से संभाल नहीं सका।

Triggerfish के साथ, एक वर्कफ़्लो पूरी पाइपलाइन को संभालती है। ब्राउज़र स्वचालन या ईमेल पार्सिंग दस्तावेज़ पुनर्प्राप्त करती है। LLM सब-एजेंट प्रारूप की परवाह किए बिना संरचित डेटा निकालते हैं। सत्यापन चरण निकाले गए डेटा को EHR और फार्मेसी डेटाबेस के खिलाफ जाँचते हैं। RESTRICTED का एक वर्गीकरण सीमा सुनिश्चित करती है कि PHI कभी पाइपलाइन सीमा नहीं छोड़ती।

आठ-व्यक्ति की टीम उन अपवादों को संभालने वाले दो लोग बन जाती है जिन्हें सिस्टम फ्लैग करता है, साथ ही स्वचालित एक्सट्रैक्शन के आवधिक गुणवत्ता ऑडिट। प्रदाता कार्यालयों से प्रारूप परिवर्तन स्वचालित रूप से अवशोषित होते हैं। नए फॉर्म लेआउट पहली मुठभेड़ में संभाले जाते हैं। रखरखाव लागत जो पारंपरिक स्वचालन बजट के अधिकांश का उपभोग करती थी, लगभग शून्य तक गिर जाती है।