Mở các bản sao kê ngân hàng chẳng phải là một trải nghiệm thú vị gì. Chúng xuất hiện dưới dạng PDF quét, tệp xuất CSV, hoặc các tệp XML đi kèm với những từ viết tắt khó hiểu như OFX. Đối với các kế toán viên, nhân viên ghi chép sổ sách và những người xây dựng fintech, việc chuyển đổi các tài liệu này thành dữ liệu sạch và có cấu trúc là một nỗi đau đầu thường trực. Khi các mô hình ngôn ngữ lớn (LLM) xuất hiện, chúng dường như mang đến một lối thoát. Chỉ cần đưa một tệp PDF cho máy và yêu cầu JSON. Có gì sai sót được chứ?
Tôi đã học được chính xác những gì có thể sai sót trong quá trình xây dựng StatementDecoder, một công cụ được thiết kế để chuyển đổi sao kê ngân hàng thành dữ liệu có thể sử dụng được. Giống như nhiều nhà phát triển khác, tôi đã cho rằng phần khó nhất sẽ là dạy hệ thống cách đọc các bố cục tài liệu đa dạng. Tôi đã lầm. Việc đọc tài liệu gần như là chuyện nhỏ. Cơn ác mộng thực sự là việc nhận ra khi máy tính âm thầm tự "chế" ra một con số hoặc tráo đổi hai chữ số trong số tiền giao dịch.
Bản Demo Hoạt Động Quá Tốt
Nỗ lực đầu tiên của tôi đơn giản đến mức đầy cám dỗ. Tôi đưa trực tiếp các bản sao kê ngân hàng vào một LLM và yêu cầu trả về JSON có cấu trúc. Kết quả mang lại cảm giác như phép màu. Mô hình xử lý các bố cục khác nhau một cách dễ dàng. Nó đọc được cả các tệp PDF quét mà các bộ phân tích (parser) tiêu chuẩn thường bị lỗi. Nó dường như hiểu được các bảng, tiêu đề và các bản sao kê nhiều trang mà không cần hướng dẫn cụ thể. Trong vài giờ huy hoàng, tôi đã nghĩ rằng vấn đề đã được giải quyết.
Sau đó, tôi thử nghiệm nó với dữ liệu khách hàng thực tế, và phép màu tan biến. Các ngân hàng tại Vương quốc Anh mỗi nơi sử dụng một thiết kế sao kê riêng, và sự khác biệt không chỉ nằm ở vẻ bề ngoài. Sao kê của Wise có những đặc điểm định dạng riêng biệt. Các tệp xuất CSV của Revolut trông có vẻ đơn giản cho đến khi bạn nhận ra cách chúng xử lý các giao dịch đa tiền tệ và các trường siêu dữ liệu (metadata). Các tệp OFX cũ, một định dạng thực sự trông như đến từ những năm 1990, gây ra các cấu trúc thẻ cổ xưa và các vấn đề về mã hóa cho bất kỳ bộ phân tích nào mong đợi các đánh dấu (markup) hiện đại.
Mô hình vẫn trích xuất dữ liệu tốt hơn nhiều so với bất kỳ hệ thống mẫu (template) có sẵn nào. Nhưng "tốt hơn nhiều" vẫn là chưa đủ khi có liên quan đến tiền bạc.
Khi Độ Chính Xác 99% Vẫn Là Một Thất Bại
Đây là vấn đề cốt lõi khi sử dụng AI để trích xuất dữ liệu tài chính. Nếu một mô hình xử lý hai trăm dòng giao dịch và làm đúng một trăm chín mươi chín dòng, kết quả trông vẫn rất hoàn hảo. JSON được định dạng chuẩn. Các khóa (keys) và giá trị (values) khớp nhau. Một lần xem xét sơ qua có thể không thấy gì khả nghi. Tuy nhiên, nếu một lỗi duy nhất đó tráo đổi hai chữ số trong một số tiền, biến một khoản tiền gửi thành một khoản rút tiền, hoặc làm lệch dấu phẩy thập phân, thì việc ghi chép sổ sách của bạn sẽ bị sai lệch hoàn toàn. Bạn sẽ không thể phát hiện ra lỗi đó chỉ bằng cách nhìn lướt qua một khối dữ liệu có cấu trúc.
Một người kiểm tra JSON thô hiếm khi nhận ra một chữ số bị tráo đổi trong số tiền giao dịch. Định dạng hoàn hảo, điều này trớ trêu thay lại khiến sai sót trở nên nguy hiểm hơn. Bạn không thể tung ra một công cụ tài chính mà chỉ đúng trong hầu hết thời gian. Nó phải luôn đúng, hoặc phải thông báo rõ ràng rằng nó không chắc chắn.
Phản ứng ban đầu của tôi rất dễ đoán. Tôi thiết kế các câu lệnh (prompt) tốt hơn. Tôi nâng cấp lên các mô hình mạnh mẽ hơn. Tôi thử nghiệm với lập luận chuỗi suy nghĩ (chain-of-thought reasoning) để mô hình trình bày các bước thực hiện. Không điều nào trong số này giải quyết được vấn đề cốt lõi. Tôi đang yêu cầu cùng một hệ thống xác suất tạo ra câu trả lời, rồi sau đó lại yêu cầu chính hệ thống đó xác nhận rằng câu trả lời là đúng. Đó không phải là xác minh. Đó chỉ là một màn kịch về sự tự nhất quán (self-consistency theater).
Hãy Để Toán Học Quyết Định
Sao kê ngân hàng có một đặc điểm mà hầu hết các tài liệu khác không có: các ràng buộc toán học tích hợp sẵn. Số dư đầu kỳ cộng với tổng tất cả các giao dịch phải bằng số dư cuối kỳ. Số dư lũy kế, nếu có, phải khớp chính xác theo từng dòng. Đây không phải là sở thích về phong cách. Chúng là những quy tắc cứng.
Tôi đã xây dựng lại kiến trúc dựa trên hiểu biết này. Giờ đây, mọi hoạt động trích xuất, bất kể nguồn gốc từ đâu, đều phải đi qua một lớp xác thực trước khi người dùng nhìn thấy. Không quan trọng dữ liệu đến từ một LLM đang giải mã một tệp PDF mờ nhòe, một công cụ OCR đang đọc một trang quét, hay một quá trình phân tích CSV trực tiếp. Bộ xác thực coi tất cả các nguồn đều có khả năng sai sót như nhau.
Việc kiểm tra cực kỳ đơn giản. Cộng mọi giao dịch vào số dư đầu kỳ. So sánh kết quả với số dư cuối kỳ đã ghi. Nếu các con số không khớp, nghĩa là có gì đó không ổn. Đánh dấu bản sao kê để xem xét. Từ chối kết quả trích xuất. Không để nó đến tay người dùng.
Thay đổi duy nhất này đã thay đổi hoàn toàn bản chất của sản phẩm. Mô hình ngôn ngữ không còn cần phải hoàn hảo nữa. Nó chỉ cần đủ tốt để tạo ra kết quả có thể vượt qua được một bài kiểm tra toán học. Áp lực đã chuyển từ việc đạt được độ chính xác không tưởng trong một lĩnh vực không có ràng buộc sang việc xây dựng một vòng lặp phản hồi chặt chẽ giữa quá trình tạo dữ liệu và xác minh.
The validator also exposed patterns in the errors. Certain document types consistently failed the math check, which told me exactly where to invest effort. Instead of blindly improving prompt engineering across the board, I could see that specific bank layouts caused systematic mistakes.
Code Where Code Belongs, AI Where It Shines
Perhaps the most humbling lesson was realizing how much of the pipeline did not need AI at all. When I encountered messy Australian OFX files, my instinct was to throw tokens at the problem. I briefly considered feeding the broken XML to the model and asking it to repair the structure before parsing. Instead, I wrote twenty lines of deterministic code. It fixed the encoding quirks and malformed tags instantly, with zero cost per file and perfect reproducibility.
That experience crystallized how extraction pipelines should be organized. There are three distinct jobs, and they should not be mixed together.
- The model understands messy documents. Scanned PDFs with warped tables, mixed fonts, and handwritten