بینک اسٹیٹمنٹس کھولنا کسی کے لیے بھی خوشی کا باعث نہیں ہوتا۔ یہ اسکین شدہ PDFs، CSV ایکسپورٹس، یا OFX جیسے پیچیدہ مخففوں والے XML فائلوں کی صورت میں آتے ہیں۔ اکاؤنٹنٹس، بک کیپرز، اور فن ٹیک (fintech) بنانے والوں کے لیے، ان دستاویزات کو صاف ستھرے اور منظم ڈیٹا میں تبدیل کرنا ایک مستقل سر درد ہے۔ جب لارج لینگویج ماڈلز (LLMs) منظرِ عام پر آئے، تو ایسا لگا کہ انہوں نے اس مشکل سے نکلنے کا راستہ فراہم کر دیا ہے۔ بس مشین کو ایک PDF دیں اور JSON مانگ لیں۔ اب غلط کیا ہو سکتا ہے؟

مجھے بالکل اندازہ ہو گیا کہ کیا غلط ہو سکتا ہے جب میں StatementDecoder بنا رہا تھا، جو بینک اسٹیٹمنٹس کو قابلِ استعمال ڈیٹا میں تبدیل کرنے کے لیے ڈیزائن کیا گیا ایک ٹول ہے۔ بہت سے ڈویلپرز کی طرح، میں نے یہ سمجھا کہ مشکل کام سسٹم کو مختلف دستاویز کے لے آؤٹ پڑھنا سکھانا ہوگا۔ میں غلط تھا۔ دستاویزات کو پڑھنا تقریباً معمولی کام تھا۔ اصل ڈراونا خواب یہ پہچاننا تھا کہ کب مشین نے خاموشی سے کوئی نمبر خود سے ایجاد کر لیا ہے یا ٹرانزیکشن کی رقم میں دو ہندسوں کو آپس میں بدل دیا ہے۔

وہ ڈیمو جو بہت زیادہ کامیاب رہا

میری پہلی کوشش پرکشش حد تک سادہ تھی۔ میں نے بینک اسٹیٹمنٹس کو براہ راست ایک LLM میں بھیجا اور بدلے میں منظم JSON کی درخواست کی۔ نتائج جادوئی محسوس ہوئے۔ ماڈل نے مختلف لے آؤٹس کو آسانی سے سنبھال لیا۔ اس نے ان اسکین شدہ PDFs کو پڑھ لیا جن پر عام پارسرز (parsers) ناکام ہو جاتے تھے۔ ایسا لگتا تھا کہ وہ واضح ہدایات کے بغیر ٹیبلز، ہیڈرز اور کثیر صفحات والے اسٹیٹمنٹس کو سمجھ رہا ہے۔ چند گھنٹوں کے لیے، مجھے لگا کہ مسئلہ حل ہو گیا ہے۔

پھر میں نے اسے اصل کسٹمر ڈیٹا پر آزمایا، اور جادو غائب ہو گیا۔ برطانیہ کے بینک اپنے اپنے اسٹیٹمنٹ ڈیزائن استعمال کرتے ہیں، اور یہ فرق محض ظاہری نہیں ہے۔ Wise کے اسٹیٹمنٹس کے اپنے فارمیٹنگ کے انداز ہیں۔ Revolut کے CSV ایکسپورٹس دیکھنے میں سادہ لگتے ہیں جب تک کہ آپ یہ نہ دیکھیں کہ وہ ملٹی کرنسی ٹرانزیکشنز اور میٹا ڈیٹا فیلڈز کو کیسے سنبھالتے ہیں۔ پرانی OFX فائلیں، ایک ایسا فارمیٹ جو واقعی 1990 کی دہائی کا لگتا ہے، کسی بھی ایسے پارسر کے لیے قدیم ٹیگ اسٹرکچر اور انکوڈنگ کے مسائل پیدا کرتی ہے جو جدید مارک اپ کی توقع رکھتا ہو۔

ماڈل اب بھی کسی بھی تیار شدہ ٹیمپلیٹ سسٹم کے مقابلے میں کہیں بہتر ڈیٹا نکال رہا تھا۔ لیکن جب معاملہ پیسوں کا ہو، تو "بہتر" ہونا کافی نہیں ہے۔

جب 99% درستگی بھی ناکامی ہو

مالیاتی ڈیٹا نکالنے کے لیے AI کے استعمال میں بنیادی مسئلہ یہ ہے۔ اگر ایک ماڈل دو سو ٹرانزیکشن روز (rows) پر کارروائی کرتا ہے اور ان میں سے ایک سو ننانوے درست نکالتا ہے، تو آؤٹ پٹ بالکل صاف ستھرا نظر آتا ہے۔ JSON درست طریقے سے بنا ہوتا ہے۔ کیز (keys) اور ویلیوز (values) ایک دوسرے کے مطابق ہوتی ہیں۔ ایک عام جائزہ لینے پر کچھ بھی مشکوک نظر نہیں آئے گا۔ لیکن اگر وہ ایک غلطی رقم میں دو ہندسوں کو بدل دے، ڈپازٹ کو ودڈرال (withdrawal) میں تبدیل کر دے، یا ڈیسیمل پوائنٹ کو ہٹا دے، تو آپ کا بک کیپنگ کا ریکارڈ خراب ہو جائے گا۔ آپ منظم ڈیٹا کے ڈھیر کو محض دیکھ کر اسے نہیں پکڑ سکیں گے۔

خام JSON کا جائزہ لینے والا انسان ٹرانزیکشن کی رقم میں بدلے ہوئے ہندسے کو شاذ و نادر ہی پہچان پاتا ہے۔ فارمیٹنگ مکمل طور پر درست ہوتی ہے، جو تضاد کے طور پر اس غلطی کو مزید خطرناک بنا دیتی ہے۔ آپ ایسا مالیاتی ٹول نہیں لانچ کر سکتے جو زیادہ تر وقت درست ہو۔ اسے یا تو بالکل درست ہونا چاہیے، یا پھر اسے واضح طور پر اعلان کرنا چاہیے کہ وہ غیر یقینی ہے۔

میرا ابتدائی ردعمل قابلِ پیش گوئی تھا۔ میں نے بہتر پرامپٹس (prompts) تیار کیے۔ میں نے زیادہ باصلاحیت ماڈلز پر اپ گریڈ کیا۔ میں نے ماڈل کو اپنا کام دکھانے کے لیے chain-of-thought reasoning کے ساتھ تجربات کیے۔ ان میں سے کسی نے بھی بنیادی مسئلے کو حل نہیں کیا۔ میں اسی امکانی (probabilistic) سسٹم سے جواب تیار کرنے کا کہہ رہا تھا اور پھر اسی سسٹم سے یہ تصدیق کرنے کا کہہ رہا تھا کہ جواب درست ہے۔ یہ تصدیق (verification) نہیں ہے۔ یہ صرف self-consistency theater ہے۔

ریاضی کو فیصلہ کرنے دیں

بینک اسٹیٹمنٹس میں ایک ایسی خصوصیت ہوتی ہے جو زیادہ تر دستاویزات میں نہیں ہوتی: اندرونی ریاضیاتی پابندیاں۔ اوپننگ بیلنس اور تمام ٹرانزیکشنز کا مجموعہ کلوزنگ بیلنس کے برابر ہونا چاہیے۔ رننگ بیلنس (running balances)، اگر موجود ہوں، تو انہیں لائن بہ لائن درست ہونا چاہیے۔ یہ محض انداز یا ترجیحات نہیں ہیں۔ یہ سخت قوانین ہیں۔

میں نے اسی بصیرت کے گرد آرکیٹیکچر کو دوبارہ ترتیب دیا۔ اب، ہر ڈیٹا نکالنے کا عمل، چاہے اس کا ذریعہ کچھ بھی ہو، صارف کے دیکھنے سے پہلے ایک ویلیڈیشن لیئر (validation layer) سے گزرتا ہے۔ اس سے کوئی فرق نہیں پڑتا کہ ڈیٹا ایک دھندلے PDF کی تشریح کرنے والے LLM سے آیا ہے، ایک اسکین شدہ صفحہ پڑھنے والے OCR انجن سے، یا براہ راست CSV پارس سے۔ ویلیڈیٹر تمام ذرائع کو یکساں طور پر مشکوک سمجھتا ہے۔

یہ چیک انتہائی سادہ ہے۔ ہر ٹرانزیکشن کو اوپننگ بیلنس میں جمع کریں۔ نتیجے کا موازنہ بیان کردہ کلوزنگ بیلنس سے کریں۔ اگر نمبرز میچ نہیں کرتے، تو کچھ غلط ہے۔ اسٹیٹمنٹ کو نظرثانی کے لیے نشان زد (flag) کریں۔ ڈیٹا نکالنے کے عمل کو مسترد کریں۔ اسے صارف تک نہ پہنچنے دیں۔

اس ایک تبدیلی نے پروڈکٹ کی پوری نوعیت بدل دی۔ اب لینگویج ماڈل کا مکمل طور پر درست ہونا ضروری نہیں تھا۔ اسے صرف اتنا اچھا ہونا چاہیے تھا کہ وہ ایسا آؤٹ پٹ دے سکے جو ریاضیاتی جانچ کا مقابلہ کر سکے۔ دباؤ غیر محدود ڈومین میں ناممکن درستگی حاصل کرنے سے ہٹ کر، ڈیٹا کی تخلیق (generation) اور تصدیق (verification) کے درمیان ایک مضبوط فیڈ بیک لوپ بنانے پر منتقل ہو گیا۔

ویلیڈیٹر نے غلطیوں میں پیٹرنز (patterns) کو بھی ظاہر کیا۔ دستاویزات کی کچھ اقسام ریاضیاتی چیک (math check) میں مسلسل ناکام ہو رہی تھیں، جس سے مجھے بالکل اندازہ ہو گیا کہ مجھے اپنی کوششیں کہاں صرف کرنی ہیں۔ ہر جگہ اندھا دھند پرامپٹ انجینئرنگ (prompt engineering) کو بہتر بنانے کے بجائے، میں دیکھ سکتا تھا کہ مخصوص بینک لے آؤٹس (bank layouts) منظم غلطیوں کا باعث بن رہے تھے۔

جہاں کوڈ کا کام ہو وہاں کوڈ، جہاں AI کا کمال ہو وہاں AI

شاید سب سے بڑا سبق یہ تھا کہ مجھے احساس ہوا کہ پائپ لائن کے کتنے بڑے حصے کو بالکل بھی AI کی ضرورت نہیں تھی۔ جب میرا سامنا بکھری ہوئی (messy) آسٹریلوی OFX فائلوں سے ہوا، تو میرا رجحان مسئلے پر ٹوکنز (tokens) خرچ کرنے کا تھا۔ میں نے مختصر طور پر اس بارے میں سوچا کہ خراب XML کو ماڈل کو دے دیا جائے اور اسے پارسنگ (parsing) سے پہلے ڈھانچے کی مرمت کرنے کے لیے کہا جائے۔ اس کے بجائے، میں نے بیس لائنوں کا ڈیٹرمینسٹک کوڈ (deterministic code) لکھا۔ اس نے انکوڈنگ کی پیچیدگیوں (encoding quirks) اور غلط طریقے سے بنائے گئے ٹیگز (malformed tags) کو فوری طور پر ٹھیک کر دیا، جس میں فی فائل لاگت صفر تھی اور اسے مکمل طور پر دوبارہ (reproducibility) کیا جا سکتا تھا۔

اس تجربے نے یہ بات واضح کر دی کہ ایکسٹریکشن پائپ لائنز (extraction pipelines) کو کیسے منظم کیا جانا چاہیے۔ تین الگ الگ کام ہیں، اور انہیں آپس میں نہیں ملانا چاہیے۔

  • ماڈل بکھرے ہوئے (messy) دستاویزات کو سمجھتا ہے۔ اسکین شدہ پی ڈی ایف (PDFs) جن میں ٹیبلز ٹیڑھے میڑھے ہوں، ملے جلے فونٹس ہوں، اور ہاتھ سے لکھی ہوئی...