வங்கி அறிக்கைகளைத் (bank statements) திறப்பது யாருக்கும் மகிழ்ச்சியான விஷயம் அல்ல. அவை ஸ்கேன் செய்யப்பட்ட PDFs, CSV ஏற்றுமதி அல்லது OFX போன்ற புரியாத சுருக்கப்பெயர்களைக் கொண்ட XML கோப்புகளாக வருகின்றன. கணக்காளர்கள், கணக்கு வைப்பாளர்கள் (bookkeepers) மற்றும் ஃபின்டெக் (fintech) உருவாக்குநர்களுக்கு, இந்த ஆவணங்களை சுத்தமான, கட்டமைக்கப்பட்ட தரவுகளாக மாற்றுவது ஒரு தொடர்ச்சியான தலைவலியாகும். பெரிய மொழி மாதிரிகள் (Large Language Models) அறிமுகமானபோது, அவை இதிலிருந்து தப்பிக்க ஒரு வழியாகத் தோன்றின. ஒரு PDF-ஐ இயந்திரத்திற்கு வழங்கி, JSON கோப்பைக் கேட்டால் போதும். இதில் என்ன தவறு நடக்க முடியும்?
வங்கி அறிக்கைகளைப் பயன்பாட்டுத் தரவுகளாக மாற்ற வடிவமைக்கப்பட்ட StatementDecoder என்ற கருவியைக் கட்டியெழுப்பும்போது, என்ன தவறு நடக்கக்கூடும் என்பதை நான் துல்லியமாகக் கற்றுக்கொண்டேன். பல டெவலப்பர்களைப் போலவே, பல்வேறு ஆவண அமைப்புகளை (layouts) வாசிக்கத் தொடரக் கற்பிப்பதே கடினமான பகுதி என்று நான் நினைத்தேன். நான் தவறாக இருந்தேன். ஆவணங்களை வாசிப்பது மிகவும் எளிதானது. இயந்திரம் ஒரு எண்ணைத் தானாகவே உருவாக்கிவிட்டாலோ அல்லது ஒரு பரிவர்த்தனைத் தொகையில் இரண்டு இலக்கங்களை மாற்றியமைத்தாலோ, அதை அடையாளம் காண்பதே உண்மையான பயங்கரமான விஷயமாக இருந்தது.
மிகச் சிறப்பாகச் செயல்பட்ட டெமோ
எனது முதல் முயற்சி மிகவும் எளிமையாக இருந்தது. நான் வங்கி அறிக்கைகளை நேரடியாக ஒரு LLM-க்கு அனுப்பி, பதிலுக்கு கட்டமைக்கப்பட்ட JSON கோப்பைக் கேட்டேன். அதன் முடிவுகள் மந்திரம் போலத் தெரிந்தன. அந்த மாதிரி (model) பல்வேறு அமைப்புகளை எளிதாகக் கையாண்டது. சாதாரண பார்சர்கள் (parsers) கையாள முடியாத ஸ்கேன் செய்யப்பட்ட PDFs-களைக் கூட அது வாசித்தது. தெளிவான அறிவுறுத்தல்கள் இல்லாமலேயே அட்டவணைகள், தலைப்புகள் மற்றும் பல பக்கங்களைக் கொண்ட அறிக்கைகளைப் புரிந்துகொண்டது போல் தோன்றியது. சில மணிநேரங்களுக்கு, இந்தப் பிரச்சனை தீர்ந்துவிட்டது என்று நான் நினைத்தேன்.
பின்னர் நான் உண்மையான வாடிக்கையாளர் தரவுகளைக் கொண்டு அதைச் சோதித்தபோது, அந்த மந்திரம் மறைந்து போனது. இங்கிலாந்து (UK) வங்கிகள் ஒவ்வொன்றும் தமக்கே உரிய அறிக்கைப் வடிவமைப்புகளைப் பயன்படுத்துகின்றன, மேலும் அந்த வேறுபாடுகள் வெறும் தோற்ற ரீதியானது மட்டுமல்ல. Wise அறிக்கைகள் அவற்றின் சொந்த வடிவமைப்புக் குறைகளைக் கொண்டுள்ளன. Revolut CSV ஏற்றுமதிகள் பார்ப்பதற்கு எளிமையாகத் தோன்றலாம், ஆனால் அவை பல நாணயப் பரிவர்த்தனைகளையும் (multi-currency transactions) மெட்டாடேட்டா புலங்களையும் (metadata fields) எவ்வாறு கையாளுகின்றன என்பதைக் கவனிக்கும்போது நிலைமை மாறும். 1990-களின் காலத்தைச் சேர்ந்தது போன்ற பழைய OFX கோப்புகள், நவீன மார்க்கப் பதிவுகளை (markup) எதிர்பார்க்கும் எந்தவொரு பார்சருக்கும் பழமையான டேக் கட்டமைப்புகளையும் (tag structures) என்கோடிங் சிக்கல்களையும் கொடுக்கின்றன.
எந்தவொரு வழக்கமான டெம்ப்ளேட் முறையை விடவும் அந்த மாதிரி தரவுகளை மிகச் சிறப்பாகப் பிரித்தெடுத்தது. ஆனால் பணம் சம்பந்தப்பட்ட விஷயத்தில், "மிகச் சிறந்தது" என்பது போதுமானதல்ல.
99% துல்லியம் என்பது ஒரு தோல்வியாக இருக்கும்போது
நிதித் தரவுகளைப் பிரித்தெடுக்க AI-ஐப் பயன்படுத்துவதில் உள்ள அடிப்படைப் பிரச்சனை இதுதான். ஒரு மாதிரி இருநூறு பரிவர்த்தனை வரிசைகளைச் செயலாக்கி, அதில் நூற்று தொண்ணூற்று ஒன்பது சரியாகச் செய்தாலும், வெளியீடு மிகத் தூய்மையாகத் தோன்றும். JSON சரியாக இருக்கும். கீயும் (keys) மதிப்புகளும் (values) சரியாகப் பொருந்தும். ஒரு மேலோட்டமான ஆய்வில் எந்தத் தவறும் தெரியாது. ஆனால் அந்த ஒரே ஒரு தவறு ஒரு தொகையில் இரண்டு இலக்கங்களை மாற்றியமைத்தாலோ, டெபாசிட்டை (deposit) வித்ராயலாக (withdrawal) மாற்றியாலோ அல்லது தசமப் புள்ளியை (decimal point) நகர்த்தியாலோ, உங்கள் கணக்குப்பதிவு சிதைந்துவிடும். கட்டமைக்கப்பட்ட தரவுகளின் ஒரு பெரிய தொகுப்பை வெறும் கண்களால் பார்த்து மட்டும் இதைக் கண்டறிய முடியாது.
ஒரு மனிதன் மூல JSON-ஐ ஆய்வு செய்யும்போது, பரிவர்த்தனைத் தொகையில் மாறிய ஒரு இலக்கத்தைக் காண்பது அரிது. அதன் வடிவம் (formatting) மிகச் சரியாக இருப்பதால், முரண்பாடாக அந்தத் தவறு இன்னும் ஆபத்தானதாக மாறுகிறது. பெரும்பாலான நேரங்களில் சரியாகச் செயல்படும் ஒரு நிதித் கருவியை நீங்கள் சந்தைக்குக் கொண்டு வர முடியாது. அது சரியாக இருக்க வேண்டும், அல்லது தான் உறுதியாக இல்லை என்பதைத் தெளிவாகத் தெரிவிக்க வேண்டும்.
எனது ஆரம்பகால எதிர்வினை கணிக்கத்தக்கதாக இருந்தது. நான் சிறந்த ப்ராம்ப்ட்களை (prompts) உருவாக்கினேன். அதிக திறன் கொண்ட மாதிரிகளுக்குத் தரம் உயர்த்தினேன். மாதிரி தனது செயல்பாட்டை விளக்குவதற்காக 'chain-of-thought reasoning' முறையைப் பயன்படுத்தினேன். இவை எதுவுமே அடிப்படைப் பிரச்சனையைத் தீர்க்கவில்லை. அதே நிகழ்தகவு அடிப்படையிலான (probabilistic) அமைப்பிடம் ஒரு பதிலை உருவாக்கச் சொல்லிவிட்டு, அதே அமைப்பிடம் தான் அந்தப் பதில் சரியானது என்று சான்றளிக்கச் சொன்னேன். அது சரிபார்ப்பு (verification) அல்ல. அது ஒரு சுய-நிலைத்தன்மை நாடகம் (self-consistency theater) மட்டுமே.
கணிதத்தை முடிவெடுக்க விடுங்கள்
பெரும்பாலான ஆவணங்களில் இல்லாத ஒரு அம்சம் வங்கி அறிக்கைகளில் உள்ளது: அதுதான் உள்ளமைக்கப்பட்ட கணிதக் கட்டுப்பாடுகள் (arithmetic constraints). ஆரம்ப இருப்புடன் (opening balance) அனைத்துப் பரிவர்த்தனைகளின் கூட்டுத்தொகையும் இறுதி இருப்புடன் (closing balance) சமமாக இருக்க வேண்டும். தொடர்ச்சியான இருப்புத் தொகைகள் (running balances) இருந்தால், அவை வரிசை வாரியாகச் சரியாக இருக்க வேண்டும். இவை வெறும் பாணி சார்ந்த விருப்பங்கள் அல்ல; இவை மாறாத விதிகள்.
இந்தத் தெளிவின் அடிப்படையில் நான் கட்டமைப்பை மீண்டும் உருவாக்கினேன். இப்போது, எந்தத் தரவாக இருந்தாலும், அது பயனருக்குத் தெரிவதற்கு முன்பு ஒரு சரிபார்ப்பு அடுக்கின் (validation layer) வழியாகச் செல்கிறது. தரவு ஒரு மங்கலான PDF-ஐப் புரிந்துகொள்ளும் LLM-லிருந்து வந்தாலும், ஸ்கேன் செய்யப்பட்ட பக்கத்தைப் படிக்கும் OCR இயந்திரத்திலிருந்து வந்தாலும் அல்லது நேரடி CSV பகுப்பாய்விலிருந்து வந்தாலும் அது பொருட்டல்ல. சரிபார்ப்பாளர் (validator) அனைத்து ஆதாரங்களையும் சமமான சந்தேகத்திற்குரியதாகவே கருதுகிறார்.
இந்தச் சரிபார்ப்பு மிகவும் எளிமையானது. ஒவ்வொரு பரிவர்த்தனையையும் ஆரம்ப இருப்புடன் கூட்டவும். அதன் முடிவைக் கொடுக்கப்பட்ட இறுதி இருப்போடு ஒப்பிடவும். எண்கள் பொருந்தவில்லை என்றால், ஏதோ தவறு நடந்துள்ளது என்று அர்த்தம். அந்த அறிக்கையை மறுஆய்வுக்குக் குறிக்கவும் (flag). அந்தத் தரவைப் பிரித்தெடுப்பதைத் தவிர்க்கவும். அதை பயனருக்குச் சென்றடைய விடாதீர்கள்.
இந்த ஒரு மாற்றம் தயாரிப்பின் முழுத் தன்மையையும் மாற்றியது. மொழி மாதிரி (language model) இனித் துல்லியமாக இருக்க வேண்டிய அவசியமில்லை. கணிதச் சோதனையில் வெற்றிபெறக்கூடிய தரவை உருவாக்கும் அளவுக்கு அது போதுமானதாக இருந்தால் போதும். கட்டுப்பாடற்ற ஒரு களத்தில் சாத்தியமற்ற துல்லியத்தைப் பெறுவதிலிருந்து, தரவு உருவாக்கம் மற்றும் சரிபார்ப்பு ஆகியவற்றிற்கு இடையே ஒரு வலுவான பின்னூட்டச் சுழற்சியை (feedback loop) உருவாக்குவதே முக்கிய நோக்கமாக மாறியது.
The validator also exposed patterns in the errors. Certain document types consistently failed the math check, which told me exactly where to invest effort. Instead of blindly improving prompt engineering across the board, I could see that specific bank layouts caused systematic mistakes.
Code Where Code Belongs, AI Where It Shines
Perhaps the most humbling lesson was realizing how much of the pipeline did not need AI at all. When I encountered messy Australian OFX files, my instinct was to throw tokens at the problem. I briefly considered feeding the broken XML to the model and asking it to repair the structure before parsing. Instead, I wrote twenty lines of deterministic code. It fixed the encoding quirks and malformed tags instantly, with zero cost per file and perfect reproducibility.
That experience crystallized how extraction pipelines should be organized. There are three distinct jobs, and they should not be mixed together.
- The model understands messy documents. Scanned PDFs with warped tables, mixed fonts, and handwritten