बँक स्टेटमेंट उघडणे हे कोणालाही मनोरंजक वाटत नाही. ती स्कॅन केलेल्या PDF, CSV एक्सपोर्ट किंवा OFX सारख्या क्लिष्ट संक्षिप्त रूपांनी (acronyms) सजलेल्या XML फाईल्सच्या स्वरूपात येतात. अकाउंटंट्स, बुककीपर्स आणि फिनटेक बिल्डर्ससाठी, या कागदपत्रांचे स्वच्छ आणि संरचित (structured) डेटामध्ये रूपांतर करणे हे एक सततचे डोकेदुखीचे काम आहे. जेव्हा लार्ज लँग्वेज मॉडेल्स (LLMs) समोर आले, तेव्हा असे वाटले की यातून सुटका मिळेल. फक्त मशीनला PDF द्या आणि JSON मागून घ्या. यात काय चुकीचे जाऊ शकते?

बँक स्टेटमेंटला उपयुक्त डेटामध्ये रूपांतरित करण्यासाठी डिझाइन केलेल्या StatementDecoder या टूलची निर्मिती करताना मला नेमके काय चुकीचे जाऊ शकते, हे समजले. अनेक डेव्हलपर्सप्रमाणेच, मला वाटले की विविध डॉक्युमेंट लेआउट्स वाचायला शिकवणे हा कठीण भाग असेल. पण मी चुतो. कागदपत्रे वाचणे हे अगदी सोपे होते. खरी nightmare तेव्हा होती जेव्हा मशीनने गुपचूप एखादा आकडा स्वतःहून तयार केला किंवा व्यवहाराच्या रकमेतील दोन अंक बदलले, हे ओळखणे.

अतिशय प्रभावी ठरलेले डेमो

माझा पहिला प्रयत्न अत्यंत सोपा आणि मोहक होता. मी थेट बँक स्टेटमेंट LLM मध्ये टाकले आणि बदल्यात संरचित JSON ची मागणी केली. निकाल एखाद्या जादूसारखे वाटले. मॉडेलने विविध लेआउट्स सहज हाताळले. त्याने अशा स्कॅन केलेल्या PDF वाचल्या ज्या सामान्य पार्सर्सना (parsers) वाचता येत नव्हत्या. स्पष्ट सूचनांशिवायही त्याला टेबल्स, हेडर्स आणि बहु-पृष्ठीय स्टेटमेंट्स समजल्यासारख्या वाटल्या. काही सुवर्ण तासांसाठी, मला वाटले की समस्या सुटली आहे.

मग मी प्रत्यक्ष ग्राहकांच्या डेटावर त्याची चाचणी घेतली आणि ती जादू नाहीशी झाली. युकेमधील बँकांचे प्रत्येक बँकेचे स्टेटमेंट डिझाइन वेगळे असते आणि हे फरक केवळ बाह्य स्वरूपाचे नसून खोलवर आहेत. Wise स्टेटमेंट्समध्ये त्यांच्या स्वतःच्या फॉरमॅटिंगमधील वैशिष्ट्ये आहेत. Revolut CSV एक्सपोर्ट्स पाहताना सोपे वाटतात, जोपर्यंत तुम्ही ते मल्टि-करन्सी व्यवहार आणि मेटाडेटा फील्ड्स कसे हाताळतात हे पाहत नाही. जुन्या OFX फाईल्स, जे फॉरमॅट खरोखर १९९० च्या दशकातील वाटतात, ते आधुनिक मार्कअपची अपेक्षा करणाऱ्या कोणत्याही पार्सरसमोर जुन्या टॅग स्ट्रक्चर्स आणि एन्कोडिंगच्या समस्या निर्माण करतात.

मॉडेलने कोणत्याही तयार (off-the-shelf) टेम्पलेट सिस्टमपेक्षा कितीतरी पटीने चांगले डेटा काढला होता. परंतु जेव्हा पैशांचा विषय असतो, तेव्हा 'खूप चांगले' असणे पुरेसे नसते.

जेव्हा ९९% अचूकता ही अपयश ठरते

आर्थिक डेटा एक्सट्रॅक्शनसाठी AI वापरण्यातील मूलभूत समस्या ही आहे: जर एखाद्या मॉडेलने दोनशे व्यवहारांच्या ओळींवर प्रक्रिया केली आणि त्यातील एकशे नव्व्याण्णव बरोबर काढल्या, तर आउटपुट अगदी अचूक वाटते. JSON व्यवस्थित तयार केलेले असते. कीज (keys) आणि व्हॅल्यूज (values) योग्यरित्या जुळतात. वरवर पाहता काहीही संशयास्पद वाटणार नाही. तरीही, जर त्या एका चुकीमुळे रकमेतील दोन अंक बदलले, डिपॉझिटचे रूपांतर विथड्रॉवलमध्ये झाले किंवा दशांश चिन्ह (decimal point) सरकले, तर तुमचे बुककीपिंग बिघडते. संरचित डेटाच्या मोठ्या राशीकडे फक्त डोळ्यांनी पाहून तुम्ही ही चूक पकडू शकणार नाही.

कच्च्या JSON ची तपासणी करणारा माणूस व्यवहाराच्या रकमेतील बदललेला अंक क्वचितच ओळखू शकतो. फॉरमॅटिंग अगदी परिपूर्ण असते, ज्यामुळे विरोधाभासाने ही चूक अधिक धोकादायक ठरते. तुम्ही असे आर्थिक टूल बाजारात आणू शकत नाही जे बहुतेक वेळा बरोबर असते. ते एकतर पूर्णपणे बरोच असले पाहिजे किंवा ते स्वतःला अनिश्चित असल्याचे स्पष्टपणे जाहीर केले पाहिजे.

माझी सुरुवातीची प्रतिक्रिया अपेक्षित होती. मी अधिक चांगले प्रॉम्प्ट्स (prompts) तयार केले. मी अधिक सक्षम मॉडेल्सचा वापर केला. मॉडेलने आपली प्रक्रिया दाखवावी यासाठी मी 'chain-of-thought reasoning' सोबत प्रयोग केले. यापैकी कशानेही मूळ समस्या सुटली नाही. मी त्याच संभाव्य (probabilistic) सिस्टमला उत्तर तयार करण्यास सांगत होतो आणि नंतर त्याच सिस्टमला ते उत्तर बरोबर आहे याची खात्री करण्यास सांगत होतो. हे व्हेरिफिकेशन (verification) नाही. हे केवळ स्वतःची सुसंगतता सिद्ध करण्याचे नाटक (self-consistency theater) आहे.

गणिताला निर्णय घेऊ द्या

बँक स्टेटमेंटमध्ये एक वैशिष्ट्य असते जे बहुतेक कागदपत्रांमध्ये नसते: अंगभूत गणिती मर्यादा (built-in arithmetic constraints). सुरुवातीची शिल्लक (opening balance) आणि सर्व व्यवहारांची बेरीज ही शेवटच्या शिल्लकीइतकी (closing balance) असणे आवश्यक आहे. रनिंग बॅलन्स (running balances) असल्यास, ते ओळीनुसार जुळले पाहिजेत. हे केवळ शैलीचे प्रकार नाहीत, तर ते कडक नियम आहेत.

मी या माहितीच्या आधारे आर्किटेक्चर पुन्हा तयार केले. आता, प्रत्येक एक्सट्रॅक्शन, त्याचा स्रोत काहीही असो, वापरकर्त्याला दिसण्यापूर्वी व्हॅलिडेशन लेयरमधून (validation layer) जाते. डेटा एखाद्या अस्पष्ट PDF चे अर्थ लावणारे LLM, स्कॅन केलेले पान वाचणारे OCR इंजिन किंवा थेट CSV पार्समधून आला असला तरीही फरक पडत नाही. व्हॅलिडेटर सर्व स्रोतांकडे समान संशयास्पद दृष्टीने पाहतो.

ही तपासणी अत्यंत साधी आहे. प्रत्येक व्यवहार सुरुवातीच्या शिल्लकीमध्ये मिळवा. आलेल्या निकालाची तुलना दिलेल्या शेवटच्या शिल्लकीशी करा. जर आकडे जुळले नाहीत, तर काहीतरी चुकले आहे. अशा स्टेटमेंटला रिव्ह्यूसाठी फ्लॅग करा. एक्सट्रॅक्शन नाकारून टाका. ते वापरकर्त्यापर्यंत पोहोचू देऊ नका.

या एका बदलामुळे उत्पादनाचे संपूर्ण स्वरूप बदलले. लँग्वेज मॉडेलला आता परिपूर्ण असण्याची गरज नव्हती. ते फक्त इतके चांगले असावे की त्याचा आउटपुट गणिती चाचणीत टिकू शकेल. दबाव आता अनियंत्रित क्षेत्रात अशक्य अचूकता मिळवण्याकडून, जनरेशन (generation) आणि व्हेरिफिकेशन (verification) यांच्यात एक घट्ट फीडबॅक लूप तयार करण्याकडे वळला.

व्हॅलिडेटरमुळे त्रुटींमधील काही विशिष्ट नमुने देखील समोर आले. काही विशिष्ट प्रकारचे दस्तऐवज सातत्याने मॅथ चेकमध्ये अपयशी ठरत होते, ज्यामुळे मला नेमके कुठे प्रयत्न करायचे आहेत हे समजले. सर्वत्र अंधपणे प्रॉम्प्ट इंजिनिअरिंग सुधारण्याऐवजी, मला असे दिसून आले की विशिष्ट बँक लेआउट्समुळे पद्धतशीर चुका होत होत्या.

जिथे कोडची गरज आहे तिथे कोड, जिथे AI प्रभावी आहे तिथे AI

कदाचित सर्वात मोठा धडा हा होता की, पाइपलाइनचा किती मोठा भाग अजिबात AI शिवाय हाताळता येऊ शकतो हे समजणे. जेव्हा माझा सामना विस्कळीत ऑस्ट्रेलियन OFX फाईल्सशी झाला, तेव्हा माझी पहिली प्रतिक्रिया ही समस्या सोडवण्यासाठी टोकन्स वापरण्याची होती. मी थोडा वेळ विचार केला की, खराब झालेली XML मॉडेलला देऊन पार्सिंग करण्यापूर्वी तिची रचना दुरुस्त करण्यास सांगणे. त्याऐवजी, मी विसाव्या ओळींचा डिटरमिनिस्टिक कोड लिहिला. त्याने एन्कोडिंगमधील त्रुटी आणि चुकीचे टॅग्स त्वरित दुरुस्त केले, ज्याचा प्रति फाईल खर्च शून्य होता आणि तो पूर्णपणे पुनरुत्पादनीय होता.

त्या अनुभवामुळे एक्सट्रॅक्शन पाइपलाईन्स कशा प्रकारे आयोजित केल्या पाहिजेत, हे स्पष्ट झाले. यामध्ये तीन वेगळी कामे आहेत आणि ती एकमेकांत मिसळली जाऊ नयेत.

  • मॉडेल विस्कळीत दस्तऐवज समजून घेते. वाकड्या-तिकड्या टेबल्स, मिश्रित फॉन्ट्स आणि हस्तलिखित