బ్యాంక్ స్టేట్‌మెంట్‌లను చూడటం అనేది ఎవరికీ ఇష్టమైన పని కాదు. అవి స్కాన్ చేసిన PDFలు, CSV ఎగుమతులు లేదా OFX వంటి అర్థం కాని సంక్షిప్త నామాలతో కూడిన XML ఫైల్‌లుగా వస్తాయి. అకౌంటెంట్లు, బుక్‌కీపర్లు మరియు ఫిన్‌టెక్ బిల్డర్లకు, ఈ పత్రాలను స్పష్టమైన, క్రమబద్ధమైన డేటాగా మార్చడం అనేది ఒక నిరంతర తలనొప్పి. లార్జ్ లాంగ్వేజ్ మోడల్స్ (LLMs) రంగంలోకి ప్రవేశించినప్పుడు, అవి ఒక పరిష్కారంగా కనిపించాయి. కేవలం ఒక PDFని మెషీన్‌కు ఇచ్చి JSON కావాలని అడిగితే సరిపోతుంది. ఇందులో తప్పు ఏం జరుగుతుంది?

బ్యాంక్ స్టేట్‌మెంట్‌లను ఉపయోగించదగిన డేటాగా మార్చడానికి రూపొందించిన StatementDecoder అనే సాధనాన్ని తయారు చేస్తున్నప్పుడు, సరిగ్గా ఏం తప్పు జరుగుతుందో నేను తెలుసుకున్నాను. చాలా మంది డెవలపర్ల మాదిరిగానే, విభిన్న డాక్యుమెంట్ లేఅవుట్‌లను చదవడం నేర్పించడమే కష్టమైన పని అని నేను అనుకున్నాను. కానీ నేను పొరబడ్డాను. డాక్యుమెంట్లను చదవడం చాలా సులభం. అసలైన సమస్య ఏమిటంటే, మెషీన్ నిశ్శబ్దంగా ఒక నంబర్‌ను ఊహించి సృష్టించినప్పుడు లేదా లావాదేవీ మొత్తంలో రెండు అంకెలను మార్చినప్పుడు దానిని గుర్తించడం.

మరీ బాగా పనిచేసిన డెమో

నా మొదటి ప్రయత్నం చాలా ఆకర్షణీయంగా, సరళంగా ఉంది. నేను బ్యాంక్ స్టేట్‌మెంట్‌లను నేరుగా ఒక LLMకి పంపి, తిరిగి క్రమబద్ధమైన JSON కావాలని కోరాను. ఫలితాలు మాయాజాలంలా అనిపించాయి. మోడల్ వివిధ లేఅవుట్‌లను సులభంగా హ్యాండిల్ చేసింది. సాధారణ పార్సర్‌లు విఫలమయ్యే స్కాన్ చేసిన PDFలను కూడా అది చదివేసింది. ఎటువంటి ప్రత్యేక సూచనలు లేకుండానే టేబుల్స్, హెడర్లు మరియు మల్టీ-పేజీ స్టేట్‌మెంట్‌లను అది అర్థం చేసుకున్నట్లు అనిపించింది. కొన్ని గంటల పాటు, సమస్య పరిష్కారం అయిపోయిందని నేను అనుకున్నాను.

ఆ తర్వాత నేను నిజమైన కస్టమర్ డేటాతో దానిని పరీక్షించాను, అప్పుడు ఆ మాయాజాలం మాయమైపోయింది. UK బ్యాంకులు ఒక్కొక్కటి తమ స్వంత స్టేట్‌మెంట్ డిజైన్లను ఉపయోగిస్తాయి, మరియు ఆ తేడాలు కేవలం బాహ్య రూపానికి సంబంధించినవి మాత్రమే కావు. Wise స్టేట్‌మెంట్‌లు వాటి స్వంత ఫార్మాటింగ్ ప్రత్యేకతలను కలిగి ఉంటాయి. Revolut CSV ఎగుమతులు చూడటానికి సరళంగా అనిపిస్తాయి, కానీ అవి మల్టీ-కరెన్సీ లావాదేవీలను మరియు మెటాడేటా ఫీల్డ్‌లను ఎలా హ్యాండిల్ చేస్తాయో గమనించే వరకు. 1990ల కాలానికి చెందినట్లు అనిపించే పాత OFX ఫైల్‌లు, ఆధునిక మార్కప్‌ను ఆశించే ఏ పార్సర్‌కైనా పాతకాలపు ట్యాగ్ నిర్మాణాలు మరియు ఎన్‌కోడింగ్ సమస్యలను ఎదురుచూపుతాయి.

మోడల్ ఇప్పటికీ ఏవైనా సిద్ధంగా ఉన్న టెంప్లేట్ సిస్టమ్ కంటే చాలా మెరుగ్గా డేటాను సేకరించింది. కానీ డబ్బుతో సంబంధం ఉన్నప్పుడు, "చాలా మెరుగ్గా ఉండటం" అనేది సరిపోదు.

99% ఖచ్చితత్వం అనేది వైఫల్యం అయినప్పుడు

ఆర్థిక డేటా వెలికితీత కోసం AIని ఉపయోగించడంలో ఉన్న ప్రాథమిక సమస్య ఇదే. ఒక మోడల్ రెండు వందల లావాదేవీల వరుసలను ప్రాసెస్ చేసి, అందులో వంద తొంభై తొమ్మిది సరిగ్గా చేస్తే, అవుట్‌పుట్ చాలా శుభ్రంగా కనిపిస్తుంది. JSON ఫార్మాట్ బాగుంటుంది. కీలు మరియు విలువలు సరిగ్గా అమర్చబడి ఉంటాయి. పైపైన చూస్తే ఏ అనుమానం కూడా కలగదు. కానీ ఆ ఒక్క తప్పు ఒక మొత్తంలో రెండు అంకెలను మార్చినా, డిపాజిట్‌ను విత్‌డ్రాయల్‌గా మార్చినా, లేదా డెసిమల్ పాయింట్‌ను జరిపినా, మీ బుక్‌కీపింగ్ మొత్తం పాడైపోతుంది. క్రమబద్ధమైన డేటా గోడను కేవలం కళ్లతో చూసి మీరు దానిని పట్టుకోలేరు.

ముడి JSONని సమీక్షించే మనిషి, లావాదేవీ మొత్తంలో మారిన అంకెను అరుదుగా గుర్తిస్తారు. ఫార్మాటింగ్ పరిపూర్ణంగా ఉంటుంది, ఇది విచిత్రంగా ఆ తప్పును మరింత ప్రమాదకరంగా మారుస్తుంది. చాలా సార్లు సరిగ్గా ఉండే ఆర్థిక సాధనాన్ని మీరు విడుదల చేయలేరు. అది ఖచ్చితంగా ఉండాలి, లేదా తనకు తెలియదని స్పష్టంగా చెప్పాలి.

నా ప్రాథమిక ప్రతిస్పందన ఊహించదగినదే. నేను మెరుగైన ప్రాంప్ట్‌లను రూపొందించాను. మరింత సామర్థ్యం ఉన్న మోడల్‌లకు అప్‌గ్రేడ్ అయ్యాను. మోడల్ తన పనితీరును వివరించేలా చేయడానికి chain-of-thought reasoningతో ప్రయోగాలు చేశాను. వీటిలో ఏదీ ప్రధాన సమస్యను పరిష్కరించలేదు. నేను ఒకే సంభావ్యత (probabilistic) వ్యవస్థను ఒక సమాధానాన్ని రూపొందించమని అడుగుతున్నాను మరియు ఆ సమాధానమే సరైనదని ధృవీకరించమని అదే వ్యవస్థను అడుగుతున్నాను. అది ధృవీకరణ కాదు. అది స్వయం-స్థిరత్వ నాటకం (self-consistency theater).

గణితాన్ని నిర్ణయించనివ్వండి

చాలా పత్రాలకు లేని ఒక ప్రత్యేకత బ్యాంక్ స్టేట్‌మెంట్‌లకు ఉంది: అంతర్నిర్మిత గణిత నిబంధనలు (built-in arithmetic constraints). ప్రారంభ బ్యాలెన్స్ (opening balance) మరియు అన్ని లావాదేవీల మొత్తం కలిపితే క్లోజింగ్ బ్యాలెన్స్ (closing balance) రావాలి. రన్నింగ్ బ్యాలెన్స్‌లు ఉన్నప్పుడు, అవి వరుసవారీగా సరిపోలాలి. ఇవి కేవలం శైలికి సంబంధించినవి కావు. ఇవి కఠినమైన నియమాలు.

నేను ఈ అవగాహనతో ఆర్కిటెక్చర్‌ను మళ్లీ నిర్మించాను. ఇప్పుడు, ప్రతి వెలికితీత (extraction), అది ఎక్కడి నుండి వచ్చినా, వినియోగదారుడు చూడకముందే ఒక ధృవీకరణ పొర (validation layer) ద్వారా వెళుతుంది. డేటా ఒక అస్పష్టమైన PDFని విశ్లేషించే LLM నుండి వచ్చినా, స్కాన్ చేసిన పేజీని చదివే OCR ఇంజిన్ నుండి వచ్చినా లేదా నేరుగా CSV పార్స్ నుండి వచ్చినా అది ముఖ్యం కాదు. ధృవీకరణ వ్యవస్థ (validator) అన్ని వనరులను సమానంగా అనుమానిస్తుంది.

ఈ తనిఖీ చాలా సరళమైనది. ప్రారంభ బ్యాలెన్స్‌కు ప్రతి లావాదేవీని కలపండి. వచ్చిన ఫలితాన్ని పేర్కొన్న క్లోజింగ్ బ్యాలెన్స్‌తో పోల్చండి. సంఖ్యలు సరిపోలకపోతే, ఏదో తప్పు జరిగినట్లు అర్థం. ఆ స్టేట్‌మెంట్‌ను సమీక్ష కోసం ఫ్లాగ్ చేయండి. వెలికితీతను తిరస్కరించండి. అది వినియోగదారుడికి చేరకుండా చూడండి.

ఈ ఒక్క మార్పు ఉత్పత్తి యొక్క పూర్తి స్వభావాన్ని మార్చేసింది. లాంగ్వేజ్ మోడల్ ఇకపై పరిపూర్ణంగా ఉండాల్సిన అవసరం లేదు. గణిత పరీక్షలో నిలబడగలిగేంత అవుట్‌పుట్‌ను అందించడం దానికి సరిపోతుంది. అసంబద్ధమైన డొమైన్‌లో అసాధ్యమైన ఖచ్చితత్వాన్ని సాధించాలనే ఒత్తిడి నుండి, జనరేషన్ మరియు వెరిఫికేషన్ మధ్య ఒక బలమైన ఫీడ్‌బ్యాక్ లూప్‌ను నిర్మించడం వైపు దృష్టి మళ్లింది.

వ్యాలిడేటర్ లోపాలలో ఉన్న నమూనాలను కూడా వెల్లడించింది. కొన్ని రకాల డాక్యుమెంట్ రకాలు నిరంతరం మ్యాథ్ చెక్‌లో విఫలమవుతున్నాయి, దీనివల్ల నేను ఎక్కడ శ్రమించాలో ఖచ్చితంగా అర్థమైంది. అన్ని చోట్లా ప్రాంప్ట్ ఇంజనీరింగ్‌ను గుడ్డిగా మెరుగుపరచడానికి బదులుగా, నిర్దిష్ట బ్యాంక్ లేఅవుట్‌లు క్రమబద్ధమైన తప్పులకు కారణమవుతున్నాయని నేను గమనించాను.

కోడ్ ఎక్కడ ఉండాలో అక్కడ, AI ఎక్కడ మెరుస్తుందో అక్కడ

బహుశా అత్యంత వినమ్రత కలిగించే పాఠం ఏమిటంటే, పైప్‌లైన్‌లో ఎంత భాగం అసలు AI అవసరం లేదో గ్రహించడం. నేను గందరగోళంగా ఉన్న ఆస్ట్రేలియన్ OFX ఫైళ్లను ఎదుర్కొన్నప్పుడు, సమస్యను పరిష్కరించడానికి టోకెన్లను ఉపయోగించడమే నా సహజ ప్రవృత్తిగా అనిపించింది. పార్సింగ్ చేయడానికి ముందు, పాడైపోయిన XMLని మోడల్‌కు అందించి, దాని నిర్మాణాన్ని సరిచేయమని అడగాలని నేను కొద్దిసేపు ఆలోచించాను. దానికి బదులుగా, నేను ఇరవై లైన్ల డెటెర్మినಿಸ್ಟిక్ కోడ్‌ను రాశాను. ఇది ఎన్‌కోడింగ్ లోపాలను మరియు తప్పుగా ఉన్న ట్యాగ్‌లను తక్షణమే సరిచేసింది; దీని వల్ల ఫైల్‌కు అయ్యే ఖర్చు సున్నా మరియు ఇది ఖచ్చితమైన పునరుత్పత్తి సామర్థ్యాన్ని (reproducibility) కలిగి ఉంది.

ఆ అనుభవం ఎక్స్‌ట్రాక్షన్ పైప్‌లైన్‌లను ఎలా నిర్వహించాలో స్పష్టం చేసింది. ఇందులో మూడు విభిన్న పనులు ఉన్నాయి, వాటిని కలిపి చేయకూడదు.

  • మోడల్ గందరగోళంగా ఉన్న డాక్యుమెంట్లను అర్థం చేసుకుంటుంది. వంకరగా ఉన్న టేబుల్స్, మిశ్రమ ఫాంట్లు మరియు చేతిరాతతో ఉన్న స్కాన్ చేసిన PDFలు