Membuka penyata bank bukanlah sesuatu yang menyeronokkan. Ia tiba dalam bentuk PDF imbasan, eksport CSV, atau fail XML yang dilengkapi dengan

Membuka penyata bank bukanlah sesuatu yang menyeronokkan bagi sesiapa pun. Ia tiba dalam bentuk PDF imbasan, eksport CSV, atau fail XML yang dilengkapi dengan akronim pelik seperti OFX. Bagi akauntan, kerani akaun, dan pembangun fintech, menukarkan dokumen ini kepada data yang bersih dan berstruktur adalah satu sakit kepala yang berterusan. Apabila model bahasa besar (LLM) muncul, ia seolah-olah menawarkan jalan keluar. Hanya masukkan PDF ke dalam mesin dan minta JSON. Apa yang boleh silap?

Saya mempelajari dengan tepat apa yang boleh silap semasa membina StatementDecoder, sebuah alat yang direka untuk menukar penyata bank kepada data yang boleh digunakan. Seperti kebanyakan pembangun, saya menganggap bahagian yang sukar adalah mengajar sistem untuk membaca pelbagai susun atur dokumen. Saya silap. Membaca dokumen tersebut hampir tidak sukar. Mimpi ngeri yang sebenar adalah menyedari apabila mesin secara senyap-senyap mencipta nombor sendiri atau menukar dua digit dalam jumlah transaksi.

Demo Yang Berfungsi Terlalu Baik

Percubaan pertama saya sangat mudah dan menggoda. Saya memasukkan penyata bank secara terus ke dalam LLM dan meminta JSON berstruktur sebagai balasan. Hasilnya terasa seperti magis. Model tersebut mengendalikan pelbagai susun atur dengan mudah. Ia membaca PDF imbasan yang gagal diproses oleh parser standard. Ia seolah-olah memahami jadual, pengepala, dan penyata berbilang halaman tanpa arahan eksplisit. Untuk beberapa jam yang indah, saya fikir masalah tersebut telah selesai.

Kemudian saya mengujinya dengan data pelanggan sebenar, dan magis tersebut hilang. Bank-bank di UK masing-masing menggunakan reka bentuk penyata sendiri, dan perbezaannya bukan sekadar kosmetik. Penyata Wise mempunyai keunikan formatnya sendiri. Eksport CSV Revolut kelihatan mudah sehinggalah anda menyedari bagaimana ia mengendalikan transaksi pelbagai mata wang dan medan metadata. Fail OFX lama, format yang benar-benar kelihatan seperti dari tahun 1990-an, memberikan struktur tag kuno dan isu pengekodan kepada mana-mana parser yang mengharapkan markup moden.

Model tersebut masih mengekstrak data jauh lebih baik daripada mana-mana sistem templat sedia ada. Namun, "jauh lebih baik" tidak mencukupi apabila melibatkan wang.

Apabila Ketepatan 99% Adalah Satu Kegagalan

Inilah masalah asas dalam menggunakan AI untuk pengekstrakan data kewangan. Jika satu model memproses dua ratus baris transaksi dan mendapat seratus sembilan puluh sembilan yang betul, outputnya kelihatan sempurna. JSON tersebut tersusun rapi. Kunci dan nilainya selaras. Semakan santai mungkin tidak menunjukkan apa-apa yang mencurigakan. Namun, jika satu ralat itu menukar kedudukan dua digit dalam jumlah, mengubah deposit menjadi pengeluaran, atau mengalihkan titik perpuluhan, buku akaun anda akan rosak. Anda tidak akan dapat mengesannya hanya dengan melihat timbunan data berstruktur dengan mata kasar.

Manusia yang menyemak JSON mentah jarang menyedari digit yang tertukar dalam jumlah transaksi. Formatnya sempurna, yang secara paradoks menjadikan kesilapan itu lebih berbahaya. Anda tidak boleh melancarkan alat kewangan yang hanya betul pada kebanyakan masa. Ia mesti betul, atau ia mesti menyatakan dengan jelas bahawa ia tidak pasti.

Reaksi awal saya boleh diramal. Saya membina prompt yang lebih baik. Saya menaik taraf kepada model yang lebih berupaya. Saya bereksperimen dengan penaakulan rantaian pemikiran (chain-of-thought reasoning) untuk membuatkan model menunjukkan kerjanya. Tiada satu pun daripada ini yang menyelesaikan isu teras. Saya meminta sistem probabilistik yang sama untuk menjana jawapan dan kemudian meminta sistem yang sama untuk mengesahkan bahawa jawapan itu betul. Itu bukan pengesahan. Itu hanyalah "teater konsistensi kendiri".

Biarkan Matematik Menentukan

Penyata bank mempunyai satu ciri yang tidak dimiliki oleh kebanyakan dokumen: kekangan aritmetik terbina dalam. Baki pembukaan ditambah dengan jumlah semua transaksi mestilah sama dengan baki penutup. Baki berjalan, jika ada, mestilah selaras baris demi baris. Ini bukan pilihan gaya. Ini adalah peraturan tetap.

Saya membina semula seni bina berdasarkan pemahaman ini. Kini, setiap pengekstrakan, tanpa mengira sumbernya, melalui lapisan pengesahan sebelum dilihat oleh mana-mana pengguna. Tidak kira sama ada data itu datang daripada LLM yang mentafsirkan PDF yang kabur, enjin OCR yang membaca halaman imbasan, atau parsing CSV secara terus. Pengesah (validator) menganggap semua sumber sebagai sama-sama meragukan.

Semakan ini sangat ringkas. Tambahkan setiap transaksi kepada baki pembukaan. Bandingkan hasilnya dengan baki penutup yang dinyatakan. Jika nombor tidak sepadan, ada sesuatu yang tidak kena. Tandakan penyata untuk semakan. Tolak pengekstrakan tersebut. Jangan biarkan ia sampai kepada pengguna.

Perubahan tunggal ini mengubah keseluruhan watak produk tersebut. Model bahasa tidak lagi perlu menjadi sempurna. Ia hanya perlu cukup baik untuk menghasilkan output yang boleh melepasi ujian matematik. Tekanan beralih daripada mencapai ketepatan yang mustahil dalam domain tanpa kekangan kepada membina gelung maklum balas yang ketat antara penjanaan dan pengesahan.

Pengesah itu juga mendedahkan corak dalam ralat tersebut. Jenis dokumen tertentu secara konsisten gagal dalam semakan matematik, yang memberitahu saya dengan tepat di mana usaha perlu dicurahkan. Daripada menambah baik kejuruteraan prompt secara membabi buta dalam semua aspek, saya dapat melihat bahawa susun atur bank tertentu menyebabkan kesilapan sistematik.

Kod di Tempat yang Sepatutnya, AI di Tempat ia Cemerlang

Mungkin pengajaran yang paling merendah diri adalah menyedari betapa banyak bahagian dalam saluran tersebut yang tidak memerlukan AI sama sekali. Apabila saya menghadapi fail OFX Australia yang berselerak, naluri saya adalah untuk menggunakan token bagi menyelesaikan masalah tersebut. Saya sempat mempertimbangkan untuk memasukkan XML yang rosak ke dalam model dan memintanya membaiki struktur tersebut sebelum proses penghuraian. Sebaliknya, saya menulis dua puluh baris kod deterministik. Ia membaiki keanehan pengekodan dan tag yang salah format dengan serta-merta, tanpa sebarang kos bagi setiap fail dan dengan kebolehulangan yang sempurna.

Pengalaman itu menjelaskan bagaimana saluran pengekstrakan harus disusun. Terdapat tiga tugas yang berbeza, dan ia tidak seharusnya dicampuradukkan.

• Model memahami dokumen yang berselerak. PDF imbasan dengan jadual yang herot, fon bercampur, dan tulisan tangan