ബാങ്ക് സ്റ്റേറ്റ്മെന്റുകൾ തുറന്നു നോക്കുന്നത് ആർക്കും ഇഷ്ടമുള്ള കാര്യമല്ല. അവ സ്കാൻ ചെയ്ത PDF-കളായോ, CSV എക്സ്പോർട്ടുകളായോ, അല്ലെങ്കിൽ OFX പോലുള്ള സങ്കീർണ്ണമായ ചുരുക്കപ്പേരുകളാൽ (acronyms) നിറഞ്ഞ XML ഫയലുകളായോ ആണ് വരുന്നത്. അക്കൗണ്ടന്റുമാർക്കും ബുക്ക് കീപ്പർമാർക്കും ഫിൻടെക് നിർമ്മാതാക്കൾക്കും ഈ രേഖകളെ വൃത്തിയുള്ളതും ഘടനാപരമായതുമായ (structured) ഡാറ്റയാക്കി മാറ്റുന്നത് ഒരു വലിയ തലവേദനയാണ്. ലാർജ് ലാംഗ്വേജ് മോഡലുകൾ (LLMs) രംഗപ്രവേശം ചെയ്തപ്പോൾ, അവ ഇതിനൊരു പരിഹാരമായി തോന്നി. ഒരു PDF മെഷീന് നൽകി JSON ആവശ്യപ്പെട്ടാൽ മാത്രം മതി. ഇതിൽ എന്ത് തെറ്റ് സംഭവിക്കാനാണ്?
ബാങ്ക് സ്റ്റേറ്റ്മെന്റുകളെ ഉപയോഗപ്രദമായ ഡാറ്റയാക്കി മാറ്റാൻ രൂപകൽപ്പന ചെയ്ത StatementDecoder എന്ന ടൂൾ നിർമ്മിക്കുന്നതിനിടയിലാണ് എനിക്ക് ഇതിൽ എന്ത് തെറ്റുകൾ സംഭവിക്കാമെന്ന് കൃത്യമായി മനസ്സിലായത്. പല ഡെവലപ്പർമാരെയും പോലെ, വൈവിധ്യമാർന്ന ഡോക്യുമെന്റ് ലേഔട്ടുകൾ വായിക്കാൻ സിസ്റ്റത്തെ പഠിപ്പിക്കുന്നതാണ് പ്രയാസകരമായ കാര്യമെന്ന് ഞാൻ കരുതി. എന്നാൽ ഞാൻ തെറ്റായിരുന്നു. രേഖകൾ വായിക്കുന്നത് വളരെ ലളിതമായിരുന്നു. യഥാർത്ഥ പേടിസ്വപ്നം എന്നത്, മെഷീൻ നിശബ്ദമായി ഒരു നമ്പർ സ്വയം നിർമ്മിക്കുകയോ അല്ലെങ്കിൽ ഒരു ഇടപാടിന്റെ തുകയിലെ രണ്ട് അക്കങ്ങൾ പരസ്പരം മാറ്റുകയോ ചെയ്യുമ്പോൾ അത് തിരിച്ചറിയുക എന്നതായിരുന്നു.
അമിതമായി വിജയിച്ച ഡെമോ
എന്റെ ആദ്യ ശ്രമം വളരെ ലളിതവും ആകർഷകവുമായിരുന്നു. ഞാൻ ബാങ്ക് സ്റ്റേറ്റ്മെന്റുകൾ നേരിട്ട് ഒരു LLM-ലേക്ക് നൽകുകയും പകരം ഘടനാപരമായ JSON ആവശ്യപ്പെടുകയും ചെയ്തു. ഫലങ്ങൾ മാന്ത്രികമായി തോന്നി. മോഡൽ വിവിധ ലേഔട്ടുകൾ എളുപ്പത്തിൽ കൈകാര്യം ചെയ്തു. സാധാരണ പാഴ്സറുകൾക്ക് (parsers) പ്രയാസമുണ്ടാക്കുന്ന സ്കാൻ ചെയ്ത PDF-കൾ പോലും അത് വായിച്ചു. പ്രത്യേക നിർദ്ദേശങ്ങളില്ലാതെ തന്നെ ടേബിളുകളും ഹെഡറുകളും മൾട്ടി-പേജ് സ്റ്റേറ്റ്മെന്റുകളും മനസ്സിലാക്കാൻ അതിന് കഴിയുന്നതായി തോന്നി. കുറച്ചു മണിക്കൂറുകൾ ഞാൻ കരുതി പ്രശ്നം പരിഹരിക്കപ്പെട്ടു എന്ന്.
എന്നാൽ യഥാർത്ഥ ഉപഭോക്താക്കളുടെ ഡാറ്റ ഉപയോഗിച്ച് പരീക്ഷിച്ചപ്പോൾ ആ മാന്ത്രികത ഇല്ലാതായി. യുകെയിലെ ബാങ്കുകൾ ഓരോന്നും അവരുടേതായ സ്റ്റേറ്റ്മെന്റ് ഡിസൈനുകളാണ് ഉപയോഗിക്കുന്നത്, അവ തമ്മിലുള്ള വ്യത്യാസങ്ങൾ വെറും കാഴ്ചയിൽ മാത്രമുള്ളതല്ല. Wise സ്റ്റേറ്റ്മെന്റുകൾക്ക് അവരുടേതായ ഫോർമാറ്റിംഗ് രീതികളുണ്ട്. Revolut CSV എക്സ്പോർട്ടുകൾ ലളിതമായി തോന്നുമെങ്കിലും, അവ മൾട്ടി-കറൻസി ഇടപാടുകളും മെറ്റാഡാറ്റ ഫീൽഡുകളും എങ്ങനെ കൈകാര്യം ചെയ്യുന്നു എന്ന് ശ്രദ്ധിച്ചാൽ വ്യത്യാസം മനസ്സിലാകും. 1990-കളിലെ കാലഘട്ടത്തിൽപ്പെട്ടതായി തോന്നിക്കുന്ന പഴയ OFX ഫയലുകൾ, ആധുനിക മാർക്കപ്പ് പ്രതീക്ഷിക്കുന്ന പാഴ്സറുകൾക്ക് പഴയ ടാഗ് ഘടനകളും എൻകോഡിംഗ് പ്രശ്നങ്ങളും ഉയർത്തുന്നു.
നിലവിലുള്ള ഏതൊരു ടെംപ്ലേറ്റ് സിസ്റ്റത്തേക്കാളും മികച്ച രീതിയിൽ മോഡൽ ഡാറ്റ വേർതിരിച്ചെടുത്തു. എന്നാൽ പണമിടപാടുകൾ ഉൾപ്പെട്ടിരിക്കുമ്പോൾ 'മികച്ച രീതിയിൽ' എന്നത് മാത്രം പോരാ.
99% കൃത്യത പോലും പരാജയമാകുമ്പോൾ
സാമ്പത്തിക ഡാറ്റ വേർതിരിച്ചെടുക്കാൻ AI ഉപയോഗിക്കുമ്പോൾ ഉണ്ടാകുന്ന അടിസ്ഥാനപരമായ പ്രശ്നം ഇതാണ്. ഒരു മോഡൽ ഇരുന്നൂറ് ഇടപാടുകൾ പ്രോസസ്സ് ചെയ്യുകയും അതിൽ നൂറ്റി തൊണ്ണൂറ്റൊൻപത് ശരിയായി നൽകുകയും ചെയ്താൽ, ഔട്ട്പുട്ട് തികച്ചും കൃത്യമായി തോന്നും. JSON ശരിയായ രീതിയിലായിരിക്കും, കീകളും വാല്യൂസും കൃത്യമായിരിക്കും. ഒരു സാധാരണ പരിശോധനയിൽ സംശയാസ്പദമായ ഒന്നും കാണില്ല. എന്നാൽ ആ ഒരു തെറ്റ് ഒരു തുകയിലെ രണ്ട് അക്കങ്ങൾ പരസ്പരം മാറ്റുകയോ, ഒരു നിക്ഷേപത്തെ (deposit) പിൻവലിക്കലായി (withdrawal) മാറ്റുകയോ, അല്ലെങ്കിൽ ഒരു ഡെസിമൽ പോയിന്റ് മാറ്റുകയോ ചെയ്താൽ നിങ്ങളുടെ ബുക്ക് കീപ്പിംഗ് തെറ്റായിപ്പോകും. ഘടനാപരമായ ഡാറ്റകൾ കണ്ണോടിച്ചു നോക്കിയാൽ മാത്രം ഇത് കണ്ടെത്താൻ കഴിയില്ല.
ഒരു മനുഷ്യൻ റോ JSON പരിശോധിക്കുമ്പോൾ ഇടപാടിന്റെ തുകയിലെ ഒരു അക്കത്തിന്റെ മാറ്റം തിരിച്ചറിയാൻ പ്രയാസമാണ്. ഫോർമാറ്റിംഗ് കൃത്യമായതുകൊണ്ട് തന്നെ, വൈരുദ്ധ്യേന ആ തെറ്റ് കൂടുതൽ അപകടകരമായി മാറുന്നു. മിക്കവാറും സമയങ്ങളിൽ മാത്രം ശരിയാകുന്ന ഒരു സാമ്പത്തിക ടൂൾ വിപണിയിൽ എത്തിക്കാൻ കഴിയില്ല. അത് കൃത്യമായിരിക്കണം, അല്ലെങ്കിൽ തനിക്ക് ഉറപ്പില്ല എന്ന് വ്യക്തമായി അറിയിക്കുകയും വേണം.
എന്റെ ആദ്യ പ്രതികരണം പ്രവചിക്കാവുന്നതായിരുന്നു. ഞാൻ മികച്ച പ്രോംപ്റ്റുകൾ തയ്യാറാക്കി, കൂടുതൽ ശേഷിയുള്ള മോഡലുകളിലേക്ക് മാറി, മോഡൽ അതിന്റെ പ്രവർത്തനരീതി കാണിക്കുന്നതിനായി 'chain-of-thought reasoning' പരീക്ഷിച്ചു. ഇവയൊന്നും അടിസ്ഥാന പ്രശ്നം പരിഹരിച്ചില്ല. ഒരു പ്രോബബിലിസ്റ്റിക് സിസ്റ്റത്തോട് തന്നെ ഒരു ഉത്തരം നൽകാൻ ആവശ്യപ്പെടുകയും, അതേ സിസ്റ്റത്തോട് തന്നെ ആ ഉത്തരം ശരിയാണെന്ന് സാക്ഷ്യപ്പെടുത്താൻ ആവശ്യപ്പെടുകയും ചെയ്യുന്നതായിരുന്നു ഞാൻ ചെയ്തത്. അത് വെരിഫിക്കേഷൻ (verification) അല്ല, മറിച്ച് ഒരു 'self-consistency theater' മാത്രമാണ്.
ഗണിതം തീരുമാനിക്കട്ടെ
മിക്ക രേഖകൾക്കും ഇല്ലാത്ത ഒരു പ്രത്യേകത ബാങ്ക് സ്റ്റേറ്റ്മെന്റുകൾക്കുണ്ട്: അവയിൽ ഉൾപ്പെട്ടിരിക്കുന്ന ഗണിതപരമായ നിയന്ത്രണങ്ങൾ (arithmetic constraints). ഓപ്പണിംഗ് ബാലൻസും എല്ലാ ഇടപാടുകളുടെയും തുകയും ചേരുമ്പോൾ അത് ക്ലോസിംഗ് ബാലൻസിന് തുല്യമായിരിക്കണം. റണ്ണിംഗ് ബാലൻസ് ഉണ്ടെങ്കിൽ അത് ഓരോ വരിയിലും കൃത്യമായിരിക്കണം. ഇവ വെറും ശൈലികളല്ല, മറിച്ച് കർശനമായ നിയമങ്ങളാണ്.
ഈ തിരിച്ചറിവോടെ ഞാൻ ആർക്കിടെക്ചർ പുനർനിർമ്മിച്ചു. ഇപ്പോൾ, ഏത് ഉറവിടത്തിൽ നിന്നുള്ള ഡാറ്റയായാലും, ഉപയോക്താവ് കാണുന്നതിന് മുമ്പ് അത് ഒരു വാലിഡേഷൻ ലെയറിലൂടെ (validation layer) കടന്നുപോകുന്നു. ഒരു LLM വ്യാഖ്യാനിച്ച PDF-ൽ നിന്നോ, ഒരു OCR എൻജിൻ വായിച്ച സ്കാൻ ചെയ്ത പേജിൽ നിന്നോ, അല്ലെങ്കിൽ നേരിട്ടുള്ള CSV പാഴ്സിംഗിൽ നിന്നോ വന്ന ഡാറ്റയായാലും വാലിഡേറ്റർ എല്ലാ ഉറവിടങ്ങളെയും ഒരുപോലെ സംശയിക്കുന്നു.
ഈ പരിശോധന വളരെ ലളിതമാണ്. ഓരോ ഇടപാടും ഓപ്പണിംഗ് ബാലൻസുമായി കൂട്ടുക. കിട്ടുന്ന തുക സ്റ്റേറ്റ്മെന്റിലെ ക്ലോസിംഗ് ബാലൻസുമായി താരതമ്യം ചെയ്യുക. സംഖ്യകൾ ഒത്തുപോയില്ലെങ്കിൽ എന്തോ തെറ്റുണ്ട് എന്ന് ഉറപ്പാണ്. അത്തരം സ്റ്റേറ്റ്മെന്റുകൾ പരിശോധനയ്ക്കായി അടയാളപ്പെടുത്തുക. ഡാറ്റ വേർതിരിച്ചെടുക്കൽ നിരസിക്കുക. അത് ഉപയോക്താവിലേക്ക് എത്താൻ അനുവദിക്കരുത്.
ഈ ഒരു മാറ്റം ഉൽപ്പന്നത്തിന്റെ സ്വഭാവം തന്നെ മാറ്റിമറിച്ചു. ലാംഗ്വേജ് മോഡൽ ഇനി പൂർണ്ണതയുള്ളതാകണമെന്നില്ല. ഗണിതപരമായ പരിശോധനയിൽ വിജയിക്കാൻ പാകത്തിലുള്ള ഔട്ട്പുട്ട് നൽകിയാൽ മതിയാകും. അനിശ്ചിതത്വങ്ങളുള്ള ഒരു മേഖലയിൽ അസാധ്യമായ കൃത്യത കൈവരിക്കുക എന്നതിലുപരി, ഡാറ്റ നിർമ്മിക്കുന്നതിനും (generation) അത് പരിശോധിക്കുന്നതിനും (verification) ഇടയിൽ ശക്തമായ ഒരു ഫീഡ്ബാക്ക് ലൂപ്പ് നിർമ്മിക്കുക എന്നതിലേക്ക് ശ്രദ്ധ മാറി.
വാലിഡേറ്റർ പിശകുകളിലെ പാറ്റേണുകളും വെളിപ്പെടുത്തി. ചില ഡോക്യുമെന്റ് തരങ്ങൾ ഗണിത പരിശോധനയിൽ (math check) തുടർച്ചയായി പരാജയപ്പെട്ടു, ഇത് എവിടെയാണ് കൂടുതൽ ശ്രദ്ധ കേന്ദ്രീകരിക്കേണ്ടതെന്ന് എനിക്ക് കൃത്യമായി പറഞ്ഞുതന്നു. എല്ലാ കാര്യങ്ങളിലും പ്രോംപ്റ്റ് എൻജിനീയറിങ് (prompt engineering) അന്ധമായി മെച്ചപ്പെടുത്തുന്നതിന് പകരം, ചില പ്രത്യേക ബാങ്ക് ലേഔട്ടുകളാണ് വ്യവസ്ഥാപിതമായ തെറ്റുകൾക്ക് കാരണമാകുന്നത് എന്ന് എനിക്ക് മനസ്സിലാക്കാൻ കഴിഞ്ഞു.
കോഡിന് ആവശ്യമുള്ളിടത്ത് കോഡും, AI-ക്ക് തിളങ്ങാൻ കഴിയുന്നിടത്ത് AI-യും
പൈപ്പ്ലൈനിന്റെ വലിയൊരു ഭാഗത്തിന് AI ഒട്ടും ആവശ്യമില്ലെന്ന് തിരിച്ചറിഞ്ഞതാണ് ഒരുപക്ഷേ എനിക്ക് ലഭിച്ച ഏറ്റവും വലിയ പാഠം. ക്രമരഹിതമായ ഓസ്ട്രേലിയൻ OFX ഫയലുകൾ കണ്ടപ്പോൾ, പ്രശ്നം പരിഹരിക്കാൻ ടോക്കണുകൾ (tokens) ഉപയോഗിക്കണമെന്നതായിരുന്നു എന്റെ ആദ്യത്തെ ചിന്ത. പാഴ്സിംഗിന് (parsing) മുൻപ് തകരാറിലായ XML മോഡലിന് നൽകി അതിന്റെ ഘടന ശരിയാക്കാൻ ആവശ്യപ്പെടുന്നത് ഞാൻ ആലോചിച്ചുപോയി. എന്നാൽ അതിനുപകരം, ഞാൻ ഇരുപത് വരികളുള്ള ഒരു ഡിറ്റർമിനിസ്റ്റിക് കോഡ് (deterministic code) എഴുതി. അത് എൻകോഡിംഗ് വ്യതിയാനങ്ങളും തെറ്റായ ടാഗുകളും ഉടനടി ശരിയാക്കി; ഓരോ ഫയലിനും ചിലവില്ലാതെ തന്നെ പൂർണ്ണമായ പുനരാവർത്തനക്ഷമതയോടെ (reproducibility) ഇത് സാധ്യമായി.
എക്സ്ട്രാക്ഷൻ പൈപ്പ്ലൈനുകൾ എങ്ങനെ സംഘടിപ്പിക്കണം എന്നതിനെക്കുറിച്ച് ആ അനുഭവം എനിക്ക് വ്യക്തമായ ധാരണ നൽകി. അതിൽ മൂന്ന് വ്യത്യസ്ത ജോലികളുണ്ട്, അവ പരസ്പരം കലർത്താൻ പാടില്ല.
- മോഡൽ ക്രമരഹിതമായ ഡോക്യുമെന്റുകൾ മനസ്സിലാക്കുന്നു. വളഞ്ഞ ടേബിളുകളും, മിശ്രിത ഫോണ്ടുകളും, കൈപ്പടയിലുള്ള എഴുത്തുകളുമുള്ള സ്കാൻ ചെയ്ത PDF-കൾ