બેંક સ્ટેટમેન્ટ્સ ખોલવા એ કોઈ માટે મજાની વાત નથી. તે સ્કેન કરેલા PDF, CSV એક્સપોર્ટ અથવા OFX જેવા અટપટા ટૂંકા નામો (acronyms) ધરાવતી XML ફાઇલો તરીકે આવે છે. એકાઉન્ટન્ટ્સ, બુકકીપર્સ અને ફિનટેક બિલ્ડર્સ માટે, આ દસ્તાવેજોને સ્વચ્છ અને વ્યવસ્થિત ડેટામાં રૂપાંતરિત કરવા એ સતત માથાનો દુખાવો છે. જ્યારે લાર્જ લેંગ્વેજ મોડલ્સ (LLMs) આવ્યા, ત્યારે તેઓ આ સમસ્યામાંથી મુક્તિ આપતા હોય તેવું લાગ્યું. ફક્ત મશીનને PDF આપો અને JSON માંગો. શું ખોટું થઈ શકે?

StatementDecoder બનાવતી વખતે મને ખબર પડી કે શું ખોટું થઈ શકે છે, જે એક એવું ટૂલ છે જે બેંક સ્ટેટમેન્ટ્સને ઉપયોગી ડેટામાં રૂપાંતરિત કરવા માટે બનાવવામાં આવ્યું છે. ઘણા ડેવલપર્સની જેમ, મેં પણ એવું માન્યું હતું કે વિવિધ ડોક્યુમેન્ટ લેઆઉટ વાંચતા શીખવવું એ અઘરો ભાગ હશે. પણ હું ખોટો હતો. દસ્તાવેજો વાંચવા લગભગ સરળ હતું. સાચો кошાળ એ ઓળખવાનો હતો કે ક્યારે મશીને ચુપચાપ કોઈ નંબર બનાવી દીધો હોય અથવા ટ્રાન્ઝેક્શનની રકમમાં બે અંકો બદલી નાખ્યા હોય.

એ ડેમો જે ખૂબ જ સારી રીતે કામ કરી ગયો

મારો પહેલો પ્રયાસ અત્યંત સરળ હતો. મેં બેંક સ્ટેટમેન્ટ્સ સીધા જ LLM માં મોકલ્યા અને બદલામાં સ્ટ્રક્ચર્ડ JSON ની માંગણી કરી. પરિણામો જાદુ જેવા લાગ્યા. મોડલે વિવિધ લેઆઉટને સરળતાથી હેન્ડલ કર્યા. તેણે એવા સ્કેન કરેલા PDF વાંચ્યા જે સામાન્ય પાર્સર્સ (parsers) માટે મુશ્કેલ હતા. તે સ્પષ્ટ સૂચનાઓ વગર ટેબલ, હેડર્સ અને મલ્ટી-પેજ સ્ટેટમેન્ટ્સને સમજી શકતું હોય તેવું લાગ્યું. થોડા કલાકો માટે મને લાગ્યું કે સમસ્યાનો ઉકેલ મળી ગયો છે.

પછી મેં તેને વાસ્તવિક ગ્રાહક ડેટા સાથે ટેસ્ટ કર્યો, અને જાદુ ઓગળી ગયો. UK ની બેંકો દરેકના પોતાના સ્ટેટમેન્ટ ડિઝાઇન વાપરે છે, અને તફાવત માત્ર દેખાવ પૂરતો નથી. Wise સ્ટેટમેન્ટ્સમાં પોતાની અલગ ફોર્મેટિંગની લાક્ષણિકતાઓ હોય છે. Revolut CSV એક્સપોર્ટ દેખાવમાં સરળ લાગે છે, પરંતુ જ્યાં સુધી તમે એ ન જુઓ કે તેઓ મલ્ટી-કરન્સી ટ્રાન્ઝેક્શન અને મેટાડેટા ફીલ્ડ્સને કેવી રીતે હેન્ડલ કરે છે. જૂની OFX ફાઇલો, જેનું ફોર્મેટ ખરેખર 1990 ના દાયકાનું લાગે છે, તે આધુનિક માર્કઅપની અપેક્ષા રાખતા કોઈપણ પાર્સર સામે જૂની ટેગ સ્ટ્રક્ચર્સ અને એન્કોડિંગની સમસ્યાઓ ફેંકે છે.

મોડલે હજુ પણ કોઈપણ તૈયાર ટેમ્પલેટ સિસ્ટમ કરતા ઘણું સારું ડેટા એક્સટ્રેક્ટ કર્યું. પરંતુ જ્યારે પૈસાનો પ્રશ્ન હોય, ત્યારે 'ઘણું સારું' હોવું પૂરતું નથી.

જ્યારે 99% ચોકસાઈ પણ નિષ્ફળતા હોય

નાણાકીય ડેટા એક્સટ્રેક્શન માટે AI નો ઉપયોગ કરવામાં મૂળભૂત સમસ્યા અહીં છે. જો મોડલ બસો ટ્રાન્ઝેક્શન રો (rows) પ્રોસેસ કરે અને તેમાંથી એકસો નવ્વાણું સાચા હોય, તો આઉટપુટ એકદમ ચોખ્ખું દેખાશે. JSON વ્યવસ્થિત હશે. કી (keys) અને વેલ્યુ (values) યોગ્ય રીતે ગોઠવાયેલા હશે. ઉપરછલ્લી તપાસમાં કંઈ પણ શંકાસ્પદ દેખાશે નહીં. છતાં, જો તે એક ભૂલ રકમમાં બે અંકો બદલી નાખે, ડિપોઝિટને વિથડ્રોઅલમાં ફેરવી નાખે, અથવા ડેસિમલ પોઈન્ટ ખસેડી દે, તો તમારી બુકકીપિંગ બગડી જશે. સ્ટ્રક્ચર્ડ ડેટાના મોટા જથ્થાને માત્ર જોઈને તમે આ ભૂલ પકડી શકશો નહીં.

કાચું (raw) JSON તપાસતી વખતે માણસ ભાગ્યે જ ટ્રાન્ઝેક્શનની રકમમાં બદલાયેલા અંકને પકડી શકે છે. ફોર્મેટિંગ પરફેક્ટ હોય છે, જે વિરોધાભાસી રીતે ભૂલને વધુ જોખમી બનાવે છે. તમે એવું ફાઇનાન્શિયલ ટૂલ લોન્ચ કરી શકતા નથી જે મોટાભાગે સાચું હોય. તે કાં તો સાચું હોવું જોઈએ, અથવા તે સ્પષ્ટપણે જણાવવું જોઈએ કે તે અનિશ્ચિત છે.

મારી પ્રારંભિક પ્રતિક્રિયા અનુમાનિત હતી. મેં વધુ સારા પ્રોમ્પ્ટ્સ (prompts) બનાવ્યા. મેં વધુ સક્ષમ મોડલ્સ અપગ્રેડ કર્યા. મોડલ તેના કામની પ્રક્રિયા બતાવે તે માટે મેં 'ચેઈન-ઓફ-થોટ' (chain-of-thought) રીઝનિંગ સાથે પ્રયોગો કર્યા. આમાંથી કંઈે પણ મુખ્ય સમસ્યાનું નિરાકરણ લાવ્યું નહીં. હું એ જ સંભવિતતા આધારિત (probabilistic) સિસ્ટમને જવાબ આપવા માટે કહી રહ્યો હતો અને પછી તે જ સિસ્ટમને તે જવાબ સાચો છે તેની પ્રમાણિત કરવા માટે કહી રહ્યો હતો. તે વેરિફિકેશન (verification) નથી. તે માત્ર 'સેલ્ફ-કન્સીસ્ટન્સી થિયેટર' છે.

ગણિતને નિર્ણય લેવા દો

બેંક સ્ટેટમેન્ટ્સમાં એક એવી વિશેષતા હોય છે જે મોટાભાગના દસ્તાવેજોમાં હોતી નથી: ઇન-બિલ્ટ અંકગણિતના નિયમો (arithmetic constraints). ઓપનિંગ બેલેન્સ પ્લસ તમામ ટ્રાન્ઝેક્શનનો સરવાળો ક્લોઝિંગ બેલેન્સ જેટલો જ હોવો જોઈએ. રનિંગ બેલેન્સ (running balances), જો હોય તો, તે દરેક રો (row) મુજબ મેળ ખાતા હોવા જોઈએ. આ કોઈ શૈલીગત પસંદગી નથી. તે કડક નિયમો છે.

મેં આ સમજણના આધારે આર્કિટેક્ચર ફરીથી બનાવ્યું. હવે, દરેક એક્સટ્રેક્શન, તે ગમે ત્યાંથી આવ્યું હોય, યુઝર જોતા પહેલા વેરિફિકેશન લેયર (validation layer) માંથી પસાર થાય છે. ડેટા LLM દ્વારા અસ્પષ્ટ PDF ને સમજવાથી આવ્યો હોય, OCR એન્જિન દ્વારા સ્કેન કરેલા પેજ વાંચવાથી આવ્યો હોય, અથવા સીધા CSV પાર્સિંગથી આવ્યો હોય, તેનાથી કોઈ ફરક પડતો નથી. વેરિફાયર તમામ સ્ત્રોતોને સમાન રીતે શંકાસ્પદ માને છે.

આ તપાસ અત્યંત સરળ છે. દરેક ટ્રાન્ઝેક્શનને ઓપનિંગ બેલેન્સમાં ઉમેરો. પરિણામની સરખામણી સ્ટેટમેન્ટમાં આપેલા ક્લોઝિંગ બેલેન્સ સાથે કરો. જો આંકડાઓ મેળ ખાતા નથી, તો કંઈક ખોટું છે. સ્ટેટમેન્ટને રિવ્યુ માટે ફ્લેગ કરો. એક્સટ્રેક્શનને નકારી કાઢો. તેને યુઝર સુધી પહોંચવા ન દો.

આ એક ફેરફારે પ્રોડક્ટનું સંપૂર્ણ સ્વરૂપ બદલી નાખ્યું. લેંગ્વેજ મોડલ હવે પરફેક્ટ હોવું જરૂરી નહોતું. તેને ફક્ત એટલું જ સારું હોવું જરૂરી હતું કે તે એવું આઉટપુટ આપી શકે જે ગાણિતિક પરીક્ષણમાં ટકી શકે. દબાણ હવે અનિયંત્રિત ક્ષેત્રમાં અશક્ય ચોકસાઈ મેળવવાથી બદલાઈને, જનરેશન (generation) અને વેરિફિકેશન (verification) વચ્ચે એક મજબૂત ફીડબેક લૂપ બનાવવાની તરફ વળ્યું.

વેલિડેટરે ભૂલોમાં રહેલી પેટર્ન પણ ઉજાગર કરી. અમુક ચોક્કસ પ્રકારના દસ્તાવેજો સતત ગણિતની તપાસમાં નિષ્ફળ જતા હતા, જેનાથી મને ખબર પડી કે મારે ક્યાં મહેનત કરવાની જરૂર છે. બધે જ અંધાધૂંધ રીતે પ્રોમ્પ્ટ એન્જિનિયરિંગ સુધારવાને બદલે, હું જોઈ શક્યો કે ચોક્કસ બેંક લેઆઉટના કારણે વ્યવસ્થિત ભૂલો થઈ રહી હતી.

જ્યાં કોડની જરૂર હોય ત્યાં કોડ, અને જ્યાં AI શ્રેષ્ઠ હોય ત્યાં AI

કદાચ સૌથી નમ્રતા શીખવતો પાઠ એ હતો કે પાઈપલાઈનનો કેટલો મોટો હિસ્સો AI વગર પણ ચાલી શકે છે. જ્યારે હું અસ્તવ્યસ્ત ઓસ્ટ્રેલિયન OFX ફાઇલો સાથે મુકાયો, ત્યારે મારી પ્રથમ વૃત્તિ સમસ્યા ઉકેલવા માટે ટોકન્સનો ઉપયોગ કરવાની હતી. મેં થોડીવાર માટે વિચાર્યું કે ખરાબ થયેલ XML મોડેલને આપી દઉં અને તેને પાર્સિંગ કરતા પહેલા સ્ટ્રક્ચર સુધારવા માટે કહી દઉં. તેના બદલે, મેં વીસ લાઇનની ડિટરમિનિસ્ટિક કોડ લખ્યો. તેણે એન્કોડિંગની વિચિત્રતાઓ અને ખોટા ટેગ્સને તરત જ સુધારી દીધા, જેનાથી ફાઇલ દીઠ શૂન્ય ખર્ચ થયો અને સંપૂર્ણ પુનરાવર્તિતતા મળી.

તે અનુભવે એ સ્પષ્ટ કરી દીધું કે એક્સટ્રેક્શન પાઈપલાઈન કેવી રીતે ગોઠવવી જોઈએ. તેમાં ત્રણ અલગ-અલગ કાર્યો છે, અને તેમને એકબીજા સાથે મિક્સ ન કરવા જોઈએ.

  • મોડેલ અસ્તવ્યસ્ત દસ્તાવેજોને સમજે છે. વળેલા ટેબલ, મિશ્ર ફોન્ટ્સ અને હાથથી લખાયેલા લખાણ ધરાવતા સ્કેન કરેલા PDFs...