ಬ್ಯಾಂಕ್ ಸ್ಟೇಟ್‌ಮೆಂಟ್‌ಗಳನ್ನು (bank statements) ತೆರೆಯುವುದು ಯಾರಿಗೂ ಇಷ್ಟವಾಗುವ ಕೆಲಸವಲ್ಲ. ಅವು ಸ್ಕ್ಯಾನ್ ಮಾಡಿದ PDFಗಳು, CSV ಎಕ್ಸ್‌ಪೋರ್ಟ್‌ಗಳು ಅಥವಾ OFX ನಂತಹ ವಿಚಿತ್ರ ಸಂಕ್ಷಿಪ್ತ ರೂಪದ (acronyms) XML ಫೈಲ್‌ಗಳ ರೂಪದಲ್ಲಿ ಬರುತ್ತವೆ. ಅಕೌಂಟೆಂಟ್‌ಗಳು, ಬುಕ್‌ಕೀಪರ್‌ಗಳು ಮತ್ತು ಫಿನ್‌ಟೆಕ್ (fintech) ನಿರ್ಮಾತೃಗಳಿಗೆ, ಈ ದಾಖಲೆಗಳನ್ನು ಸ್ವಚ್ಛವಾದ, ರಚನಾತ್ಮಕ ಡೇಟಾ (structured data) ಆಗಿ ಪರಿವರ್ತಿಸುವುದು ನಿರಂತರ ತಲೆನೋವು. ಲಾರ್ಜ್ ಲ್ಯಾಂಗ್ವೇಜ್ ಮಾಡೆಲ್‌ಗಳು (LLMs) ಮಾರುಕಟ್ಟೆಗೆ ಬಂದಾಗ, ಅವು ಒಂದು ಸುಲಭ ಪರಿಹಾರದಂತೆ ಕಂಡವು. ಯಂತ್ರಕ್ಕೆ ಒಂದು PDF ನೀಡಿ, ಅದಕ್ಕೆ JSON ಬೇಕೆಂದು ಕೇಳಿದರೆ ಸಾಕು. ಇದರಲ್ಲಿ ತಪ್ಪೇನಾದರೂ ಆಗಲು ಸಾಧ್ಯವೇ?

ಬ್ಯಾಂಕ್ ಸ್ಟೇಟ್‌ಮೆಂಟ್‌ಗಳನ್ನು ಬಳಸಬಹುದಾದ ಡೇಟಾವಾಗಿ ಪರಿವರ್ತಿಸಲು ವಿನ್ಯಾಸಗೊಳಿಸಲಾದ StatementDecoder ಎಂಬ ಸಾಧನವನ್ನು ತಯಾರಿಸುವಾಗ, ತಪ್ಪೇನಾದರೂ ಆಗಬಹುದು ಎಂಬುದನ್ನು ನಾನು ಕರಗತ ಮಾಡಿಕೊಂಡೆ. ಅನೇಕ ಡೆವಲಪರ್‌ಗಳಂತೆ, ವಿವಿಧ ದಾಖಲೆಗಳ ವಿನ್ಯಾಸಗಳನ್ನು (layouts) ಓದಲು ಸಿಸ್ಟಮ್‌ಗೆ ಕಲಿಸುವುದೇ ಕಷ್ಟದ ಕೆಲಸ ಎಂದು ನಾನು ಭಾವಿಸಿದ್ದೆ. ಆದರೆ ನಾನು ತಪ್ಪಾಗಿದ್ದೆ. ದಾಖಲೆಗಳನ್ನು ಓದುವುದು ಬಹಳ ಸುಲಭವಾಗಿತ್ತು. ಯಂತ್ರವು ಯಾವುದೋ ಒಂದು ಸಂಖ್ಯೆಯನ್ನು ತಾನಾಗಿಯೇ ಸೃಷ್ಟಿಸಿದಾಗ ಅಥವಾ ವಹಿವಾಟಿನ ಮೊತ್ತದಲ್ಲಿ (transaction amount) ಎರಡು ಅಂಕಿಗಳನ್ನು ಬದಲಾಯಿಸಿದಾಗ ಅದನ್ನು ಗುರುತಿಸುವುದೇ ನಿಜವಾದ ದುಸ್ತರ ಕೆಲಸವಾಗಿತ್ತು.

ಅತಿಯಾಗಿ ಯಶಸ್ವಿಯಾದ ಡೆಮೊ

ನನ್ನ ಮೊದಲ ಪ್ರಯತ್ನ ಅತ್ಯಂತ ಸರಳವಾಗಿತ್ತು. ನಾನು ಬ್ಯಾಂಕ್ ಸ್ಟೇಟ್‌ಮೆಂಟ್‌ಗಳನ್ನು ನೇರವಾಗಿ LLM ಗೆ ಕಳುಹಿಸಿ, ಬದಲಾಗಿ ರಚನಾತ್ಮಕ JSON ಅನ್ನು ಕೇಳಿದೆ. ಅದರ ಫಲಿತಾಂಶಗಳು ಮ್ಯಾಜಿಕ್‌ನಂತೆ ಕಂಡವು. ಮಾಡೆಲ್ ವಿವಿಧ ವಿನ್ಯಾಸಗಳನ್ನು ಸುಲಭವಾಗಿ ನಿಭಾಯಿಸಿತು. ಸಾಮಾನ್ಯ ಪಾರ್ಸರ್‌ಗಳು (parsers) ವಿಫಲವಾಗುವ ಸ್ಕ್ಯಾನ್ ಮಾಡಿದ PDFಗಳನ್ನು ಇದು ಓದಿತು. ಯಾವುದೇ ನಿರ್ದಿಷ್ಟ ಸೂಚನೆಗಳಿಲ್ಲದೆಯೇ ಟೇಬಲ್‌ಗಳು, ಹೆಡರ್‌ಗಳು ಮತ್ತು ಬಹು-ಪುಟಗಳ ಸ್ಟೇಟ್‌ಮೆಂಟ್‌ಗಳನ್ನು ಇದು ಅರ್ಥಮಾಡಿಕೊಂಡಂತೆ ಕಂಡಿತು. ಕೆಲವು ಗಂಟೆಗಳ ಕಾಲ, ಸಮಸ್ಯೆ ಬಗೆಹರಿದಿದೆ ಎಂದು ನಾನು ಭಾವಿಸಿದ್ದೆ.

ನಂತರ ನಾನು ಇದನ್ನು ನೈಜ ಗ್ರಾಹಕರ ಡೇಟಾದೊಂದಿಗೆ ಪರೀಕ್ಷಿಸಿದೆ, ಆಗ ಆ ಮ್ಯಾಜಿಕ್ ಮಾಯವಾಯಿತು. UK ಬ್ಯಾಂಕ್‌ಗಳು ಪ್ರತಿಯೊಂದೂ ತಮ್ಮದೇ ಆದ ಸ್ಟೇಟ್‌ಮೆಂಟ್ ವಿನ್ಯಾಸಗಳನ್ನು ಬಳಸುತ್ತವೆ ಮತ್ತು ಅವುಗಳ ನಡುವಿನ ವ್ಯತ್ಯಾಸಗಳು ಕೇವಲ ಬಾಹ್ಯವಾಗಿಲ್ಲ. Wise ಸ್ಟೇಟ್‌ಮೆಂಟ್‌ಗಳು ತಮ್ಮದೇ ಆದ ವಿಶಿಷ್ಟ ಫಾರ್ಮ್ಯಾಟಿಂಗ್ ಹೊಂದಿವೆ. Revolut CSV ಎಕ್ಸ್‌ಪೋರ್ಟ್‌ಗಳು ಸರಳವಾಗಿ ಕಾಣುತ್ತವೆ, ಆದರೆ ಅವು ಮಲ್ಟಿ-ಕರೆನ್ಸಿ ವಹಿವಾಟುಗಳು ಮತ್ತು ಮೆಟಾಡೇಟಾ ಫೀಲ್ಡ್‌ಗಳನ್ನು ಹೇಗೆ ನಿರ್ವಹಿಸುತ್ತವೆ ಎಂಬುದನ್ನು ಗಮನಿಸಿದರೆ ಪರಿಸ್ಥಿತಿ ತಿಳಿಯುತ್ತದೆ. 1990ರ ದಶಕಕ್ಕೆ ಸೇರಿದಂತೆ ಕಾಣುವ ಹಳೆಯ OFX ಫೈಲ್‌ಗಳು, ಆಧುನಿಕ ಮಾರ್ಕಪ್ ನಿರೀಕ್ಷಿಸುವ ಯಾವುದೇ ಪಾರ್ಸರ್‌ಗೆ ಹಳೆಯ ಟ್ಯಾಗ್ ರಚನೆಗಳು ಮತ್ತು ಎನ್ಕೋಡಿಂಗ್ ಸಮಸ್ಯೆಗಳನ್ನು ಎದುರಿಸುವಂತೆ ಮಾಡುತ್ತವೆ.

ಮಾಡೆಲ್ ಈಗಲೂ ಯಾವುದೇ ಸಾಮಾನ್ಯ ಟೆಂಪ್ಲೇಟ್ ಸಿಸ್ಟಮ್‌ಗಿಂತ ಉತ್ತಮವಾಗಿ ಡೇಟಾವನ್ನು ಹೊರತೆಗೆಯುತ್ತಿತ್ತು. ಆದರೆ ಹಣದ ವಿಷಯ ಬಂದಾಗ, 'ಉತ್ತಮ hơn' ಎಂಬುದು ಸಾಕಾಗುವುದಿಲ್ಲ.

99% ನಿಖರತೆಯು ಯಾವಾಗ ವೈಫಲ್ಯವಾಗುತ್ತದೆ

ಹಣಕಾಸಿನ ಡೇಟಾ ಹೊರತೆಗೆಯಲು AI ಬಳಸುವಲ್ಲಿನ ಮೂಲಭೂತ ಸಮಸ್ಯೆ ಇಲ್ಲಿದೆ. ಒಂದು ಮಾಡೆಲ್ ಇನ್ನೂರು ವಹಿವಾಟಿನ ಸಾಲುಗಳನ್ನು ಪ್ರಕ್ರಿಯೆಗೊಳಿಸಿ, ನೂರೊಂಬತ್ತೊಂಬತ್ತನ್ನು ಸರಿಯಾಗಿ ಮಾಡಿದ್ದರೆ, ಔಟ್‌ಪುಟ್ ಅತ್ಯಂತ ಪರಿಪೂರ್ಣವಾಗಿ ಕಾಣುತ್ತದೆ. JSON ಸರಿಯಾಗಿರುತ್ತದೆ. ಕೀಗಳು (keys) ಮತ್ತು ವ್ಯಾಲ್ಯೂಗಳು (values) ಹೊಂದಾಣಿಕೆಯಾಗಿರುತ್ತವೆ. ಮೇಲ್ನೋಟಕ್ಕೆ ನೋಡಿದಾಗ ಯಾವುದೇ ಅನುಮಾನಾಸ್ಪದ ಅಂಶಗಳು ಕಾಣಿಸುವುದಿಲ್ಲ. ಆದರೆ ಆ ಒಂದು ತಪ್ಪಿನಿಂದ ಮೊತ್ತದಲ್ಲಿನ ಎರಡು ಅಂಕಿಗಳು ಬದಲಾದರೆ, ಅಥವಾ ಡೆಪಾಸಿಟ್ ಅನ್ನು ವಿತ್‌ಡ್ರಾಲ್ ಆಗಿ ಬದಲಾಯಿಸಿದರೆ ಅಥವಾ ದಶಮಾಂಶ ಬಿಂದುವು (decimal point) ಸರಿಯಾದ ಜಾಗದಲ್ಲಿಲ್ಲದಿದ್ದರೆ, ನಿಮ್ಮ ಬುಕ್‌ಕೀಪಿಂಗ್ ಹಾಳಾಗುತ್ತದೆ. ರಚನಾತ್ಮಕ ಡೇಟಾದ ರಾಶಿಯನ್ನು ಕಣ್ಣಿನಿಂದ ನೋಡಿ ನೀವು ಇದನ್ನು ಪತ್ತೆಹಚ್ಚಲು ಸಾಧ್ಯವಿಲ್ಲ.

ರ ಕಚ್ಚಾ JSON ಅನ್ನು ಪರಿಶೀಲಿಸುವ ಮನುಷ್ಯನಿಗೆ ವಹಿವಾಟಿನ ಮೊತ್ತದಲ್ಲಿ ಬದಲಾದ ಅಂಕಿಗಳನ್ನು ಪತ್ತೆಹಚ್ಚುವುದು ಅಪರೂಪ. ಫಾರ್ಮ್ಯಾಟಿಂಗ್ ಪರಿಪೂರ್ಣವಾಗಿರುವುದರಿಂದ, ವಿಪರ್ಯಾಸವೆಂದರೆ ಆ ತಪ್ಪನ್ನು ಗುರುತಿಸುವುದು ಮತ್ತಷ್ಟು ಅಪಾಯಕಾರಿಯಾಗುತ್ತದೆ. ಹೆಚ್ಚಿನ ಸಮಯ ಸರಿಯಾಗಿರುವ ಹಣಕಾಸಿನ ಸಾಧನವನ್ನು ನೀವು ಮಾರುಕಟ್ಟೆಗೆ ತರಲು ಸಾಧ್ಯವಿಲ್ಲ. ಅದು ಸರಿಯಾಗಿರಲೇಬೇಕು, ಅಥವಾ ತನಗೆ ಖಚಿತವಿಲ್ಲ ಎಂದು ಸ್ಪಷ್ಟವಾಗಿ ತಿಳಿಸಬೇಕು.

ನನ್ನ ಆರಂಭಿಕ ಪ್ರತಿಕ್ರಿಯೆ ಮುನ್ಸೂಚನೆ ನೀಡಬಹುದಾದಂತಿತ್ತು. ನಾನು ಉತ್ತಮ ಪ್ರಾಂಪ್ಟ್‌ಗಳನ್ನು (prompts) ಸಿದ್ಧಪಡಿಸಿದೆ. ಹೆಚ್ಚು ಸಾಮರ್ಥ್ಯವುಳ್ಳ ಮಾಡೆಲ್‌ಗಳಿಗೆ ಅಪ್‌ಗ್ರೇಡ್ ಮಾಡಿದೆ. ಮಾಡೆಲ್ ತನ್ನ ಕೆಲಸವನ್ನು ತೋರಿಸುವಂತೆ ಮಾಡಲು 'chain-of-thought reasoning' ಮೂಲಕ ಪ್ರಯೋಗ ಮಾಡಿದೆ. ಇವುಗಳಲ್ಲಿ ಯಾವುದೂ ಮೂಲ ಸಮಸ್ಯೆಯನ್ನು ಬಗೆಹರಿಸಲಿಲ್ಲ. ನಾನು ಅದೇ ಸಂಭವನೀಯ (probabilistic) ಸಿಸ್ಟಮ್‌ನಿಂದ ಉತ್ತರವನ್ನು ನೀಡಲು ಕೇಳುತ್ತಿದ್ದೆ ಮತ್ತು ನಂತರ ಅದೇ ಸಿಸ್ಟಮ್‌ನಿಂದ ಆ ಉತ್ತರ ಸರಿಯಾಗಿದೆ ಎಂದು ಪ್ರಮಾಣೀಕರಿಸಲು ಕೇಳುತ್ತಿದ್ದೆ. ಅದು ಪರಿಶೀಲನೆಯಲ್ಲ (verification). ಅದು ಕೇವಲ 'self-consistency theater'.

ಗಣಿತವೇ ನಿರ್ಧರಿಸಲಿ

ಹೆಚ್ಚಿನ ದಾಖಲೆಗಳಲ್ಲಿ ಇಲ್ಲದ ಒಂದು ವೈಶಿಷ್ಟ್ಯ ಬ್ಯಾಂಕ್ ಸ್ಟೇಟ್‌ಮೆಂಟ್‌ಗಳಲ್ಲಿದೆ: ಅಂತರಾಳದ ಗಣಿತದ ನಿಯಮಗಳು (arithmetic constraints). ಆರಂಭಿಕ ಬಾಲೆನ್ಸ್ (opening balance) ಮತ್ತು ಎಲ್ಲಾ ವಹಿವಾಟುಗಳ ಮೊತ್ತವು ಕೊನೆಯ ಬಾಲೆನ್ಸ್‌ಗೆ (closing balance) ಸಮನಾಗಿರಬೇಕು. ರನ್ನಿಂಗ್ ಬಾಲೆನ್ಸ್ (running balances) ಇದ್ದರೆ, ಅವು ಸಾಲು ಸಾಲಾಗಿ ಹೊಂದಾಣಿಕೆಯಾಗಬೇಕು. ಇವು ಕೇವಲ ಶೈಲಿಯ ಆಯ್ಕೆಗಳಲ್ಲ, ಇವು ಕಟ್ಟುನಿಟ್ಟಾದ ನಿಯಮಗಳು.

ನಾನು ಈ ಒಳನೋಟದ ಸುತ್ತ ವಾಸ್ತುಶಿಲ್ಪವನ್ನು (architecture) ಮರುನಿರ್ಮಿಸಿದೆ. ಈಗ, ಪ್ರತಿಯೊಂದು ಎಕ್ಸ್‌ಟ್ರಾಕ್ಷನ್ (extraction) ಮೂಲ ಏನೇ ಇರಲಿ, ಬಳಕೆದಾರರು ನೋಡುವ ಮೊದಲು ವ್ಯಾಲಿಡೇಶನ್ ಲೇಯರ್ (validation layer) ಮೂಲಕ ಹಾದುಹೋಗುತ್ತದೆ. ಡೇಟಾವು ಅಸ್ಪಷ್ಟವಾದ PDF ಅನ್ನು ಅರ್ಥೈಸುವ LLM ಇಂದ ಬಂದಿರಲಿ, ಸ್ಕ್ಯಾನ್ ಮಾಡಿದ ಪುಟವನ್ನು ಓದುತ್ತಿರುವ OCR ಎಂಜಿನ್ ಇಂದ ಬಂದಿರಲಿ ಅಥವಾ ನೇರ CSV ಪಾರ್ಸ್ ಇಂದ ಬಂದಿರಲಿ, ಅದರಿಂದ ನಮಗೆ ವ್ಯತ್ಯಾಸವಿಲ್ಲ. ವ್ಯಾಲಿಡೇಟರ್ ಎಲ್ಲಾ ಮೂಲಗಳನ್ನು ಸಮಾನವಾಗಿ ಸಂಶಯಾಸ್ಪದವಾಗಿ ಪರಿಗಣಿಸುತ್ತದೆ.

ಈ ಪರಿಶೀಲನೆಯು ಅತ್ಯಂತ ಸರಳವಾಗಿದೆ. ಪ್ರತಿಯೊಂದು ವಹಿವಾಟನ್ನು ಆರಂಭಿಕ ಬಾಲೆನ್ಸ್‌ಗೆ ಸೇರಿಸಿ. ಬಂದ ಫಲಿತಾಂಶವನ್ನು ತಿಳಿಸಲಾದ ಕೊನೆಯ ಬಾಲೆನ್ಸ್‌ಗೆ ಹೋಲಿಸಿ. ಸಂಖ್ಯೆಗಳು ಹೊಂದಿಕೆಯಾಗದಿದ್ದರೆ, ಏನೋ ತಪ್ಪಾಗಿದೆ ಎಂದರ್ಥ. ಸ್ಟೇಟ್‌ಮೆಂಟ್ ಅನ್ನು ಪರಿಶೀಲನೆಗಾಗಿ ಗುರುತಿಸಿ (flag). ಎಕ್ಸ್‌ಟ್ರಾಕ್ಷನ್ ಅನ್ನು ತಿರಸ್ಕರಿಸಿ. ಅದನ್ನು ಬಳಕೆದಾರರಿಗೆ ತಲುಪಲು ಬಿಡಬೇಡಿ.

ಈ ಒಂದು ಬದಲಾವಣೆಯು ಉತ್ಪನ್ನದ ಸಂಪೂರ್ಣ ಸ್ವರೂಪವನ್ನೇ ಬದಲಿಸಿತು. ಭಾಷಾ ಮಾಡೆಲ್ (language model) ಈಗ ಪರಿಪೂರ್ಣವಾಗಿರಬೇಕಾಗಿಲ್ಲ. ಗಣಿತದ ಪರೀಕ್ಷೆಯಲ್ಲಿ ತಾನೇ ಉಳಿಯುವಂತಹ ಔಟ್‌ಪುಟ್ ನೀಡಲು ಅದು ಸಾಕಾಗುವಷ್ಟು ಉತ್ತಮವಾಗಿದ್ದರೆ ಸಾಕು. ಅನ್-ಕನ್‌ಸ್ಟ್ರೈನ್ಡ್ ಡೊಮೇನ್‌ನಲ್ಲಿ (unconstrained domain) ಅಸಾಧ್ಯವಾದ ನಿಖರತೆಯನ್ನು ಸಾಧಿಸಬೇಕೆಂಬ ಒತ್ತಡವು, ಜನರೇಷನ್ ಮತ್ತು ವೆರಿಫಿಕೇಶನ್ ನಡುವೆ ಒಂದು ಬಿಗಿಯಾದ ಫೀಡ್‌ಬ್ಯಾಕ್ ಲೂಪ್ ಅನ್ನು ನಿರ್ಮಿಸುವುದಕ್ಕೆ ಬದಲಾಯಿತು.

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