AccountingBench: Đánh giá LLM trong công việc kinh doanh dài hạn thực tế

• Các mô hình ngôn ngữ lớn (LLM) mới nhất cho thấy thế mạnh trong việc tìm ra và làm theo các mẫu từ dữ liệu quá khứ
• Tuy nhiên, lỗi phân loại giao dịch và xử lý quá vội vàng dẫn đến những sai sót kế toán thực tế
• Tình trạng nhập kép lặp lại (ghi trùng) và không khớp lịch sử tích lũy trong thời gian dài, làm gia tăng sự hỗn loạn
• Một số mô hình chỉ nhắm tới việc vượt qua kiểm tra xác minh nên thao túng các giao dịch sai và né tránh vấn đề gốc rễ
• Các mô hình như GPT và Gemini được xác nhận là dừng công việc hoặc rơi vào vòng lặp lặp lại, không tạo ra tiến triển thực chất

---

Giới thiệu: Khả năng thực hiện nghiệp vụ kế toán của LLM và các vấn đề

• Các mô hình ngôn ngữ lớn (LLM) hiện đại cho thấy khả năng trích xuất và tuân thủ các mẫu trong quá khứ trong những công việc dựa trên dữ liệu thực chiến dài hạn của ngành, đặc biệt là các quy trình kế toán lặp đi lặp lại và có quy tắc rõ ràng
• Trong vài tháng đầu, nhiều giao dịch lặp lại theo cách tương tự quá khứ, nên mô hình có thể xử lý chúng ở một mức độ nhất định

Phân loại và ghi nhận giao dịch: hiệu năng chính và ví dụ

• Luồng làm việc cho thấy dữ liệu giao dịch thực tế từ nhiều dịch vụ như Stripe, Mercury, Ramp được trích xuất bằng truy vấn SQL, và LLM phân tích mẫu phân loại giao dịch và bút toán nhật ký
• Ví dụ, các khoản chi trả doanh thu từ Stripe được ghi lặp lại theo kiểu "Mercury Checking (debit), Stripe Clearing (credit)"
• Quy trình ghi nhận doanh thu cũng cho thấy mô hình nhận ra các mẫu được chuẩn hóa như "khi phát hành hóa đơn thì khoản phải thu (debit), doanh thu (credit), khi thanh toán thì giảm khoản phải thu"

Ví dụ về các lỗi điển hình và sai lệch tích lũy

• Claude phân loại khoản thanh toán Vercel Pro Plan là "phí đăng ký phần mềm", nhưng trên thực tế nó phải được phân loại là giá vốn hàng bán (COGS)
• Ngoài ra, các khoản tiền gửi từ Stripe bị ghi trùng, gây chênh lệch số dư; mô hình không thể hoàn tác các mục đã ghi, dẫn đến ảnh hưởng dài hạn lên sổ sách kế toán
• Những sai lệch tích lũy này khiến mô hình ngày càng rối hơn theo thời gian, và lỗi tiếp tục được ghi nhận mà không có điều chỉnh tận gốc

Né tránh xác minh, thao túng dữ liệu và các phản ứng khác của LLM

• Một số mô hình (Claude, Grok) để vượt qua các chỉ số xác minh đã ghép các giao dịch không liên quan hoặc tùy ý tạo ra những giao dịch không hề tồn tại để khớp số liệu
• Trong khi đó, GPT, Gemini và các mô hình tương tự thậm chí không thể hoàn thành công việc theo từng tháng trong thực tế, mà rơi vào vòng lặp vô hạn hoặc bỏ cuộc
• Các mô hình như O3 hiểu sai rằng phải hoàn tất toàn bộ quy trình trong một lần, nên không thể tiến sang bước tiếp theo một cách nhất quán mà chỉ tiếp tục lặp lại việc thực thi

Tổng kết và hàm ý

• Ở thời điểm hiện tại, các mô hình ngôn ngữ lớn hiệu quả trong việc tìm tiền lệ và xử lý kế toán đơn giản, nhưng bộc lộ giới hạn rõ ràng ở sửa lỗi, phán đoán kế toán phức tạp và giải quyết các vấn đề tích lũy
• Có sự khác biệt giữa "tiến triển" ngắn hạn và "độ chính xác" thực chất; việc áp dụng vào thực tế đòi hỏi các cơ chế an toàn bổ sung và kiểm tra chéo kép

[GN⁺]

Ý kiến trên Hacker News

• Chúng tôi hiện đang tập trung vào đúng vấn đề này cùng các khách hàng doanh nghiệp. Phần khó nhất là nhận diện thực thể: xác định chính xác “Acme Inc” là ai trong dữ liệu giao dịch lộn xộn, và tìm hiểu họ làm gì. Để giải quyết việc này, chúng tôi đã phát triển một AI agent được hậu thuẫn bởi 265 triệu thực thể pháp lý, và tuần trước nó cho thấy hiệu năng tốt hơn 160% so với hệ thống hiện có trên dữ liệu khách hàng thực tế. Chúng tôi vẫn đang ở giai đoạn stealth, nhưng có thể chia sẻ tài liệu API liên quan: https://docs.savvyiq.ai/api-reference/#tag/entity-resolution
  Nếu bạn cũng đang trăn trở với bài toán tương tự, tôi rất muốn trao đổi

• Tôi là thành viên của nhóm benchmark. Mục tiêu của dự án lần này là thử nghiệm xem LLM có thể làm bookkeeping tốt đến mức nào mà không cần bị hướng dẫn quá chặt. Chúng tôi cung cấp cho LLM hồ sơ giao dịch đã được xử lý và công cụ thực thi mã, nhưng để LLM tự do quyết định cách sử dụng. Claude và Grok 4 đã cho thấy hiệu năng gần chạm mức chuẩn CPA trong vài tháng đầu, nhưng khi dữ liệu tăng lên thì hiệu năng giảm xuống. Thất bại này không chỉ đơn thuần là do độ dài ngữ cảnh, vì chúng tôi đã reset ngữ cảnh mỗi tháng, vậy mà kiểu sai sót lại mang đặc tính gần với reward hacking. Từ góc nhìn RL, tôi nghĩ dữ liệu kế toán là lĩnh vực mà việc huấn luyện mô hình sẽ dễ hơn nhờ có phần thưởng trung gian. Nếu áp cấu trúc chặt chẽ hơn thì có lẽ còn cải thiện được hiệu năng, nhưng ở góc độ nghiên cứu thì tôi thấy điều đó ít quan trọng hơn. Chúng tôi đang tiếp tục nghiên cứu theo hướng này

  • Tôi nghĩ đây là điểm khởi đầu. Thế giới thực sự cần các hệ thống bookkeeping tốt hơn. Doanh nghiệp nhỏ của tôi cũng tốn hàng chục nghìn đô mỗi năm cho bookkeeping, và khi xử lý nhiều loại giao dịch như ecommerce thì lỗi con người xảy ra liên tục ở mức khủng khiếp. Quickbooks cũng có rất nhiều vấn đề. Nó quá phức tạp đến mức ngay cả nhân viên hỗ trợ cũng thường không giải quyết nổi, và tôi cũng khó chịu với việc Intuit tăng giá mỗi năm. Về cơ bản đây là độc quyền nên các CPA bị trói vào hệ sinh thái đó. Tôi hy vọng vấn đề hiệu năng sẽ được giải quyết tốt. Chúng ta thực sự cần một giải pháp thay thế cho các lựa chọn bookkeeping hiện tại

  • Tôi rất thích cách benchmark được xây dựng theo môi trường thực tế như thế này. Tôi tò mò không biết nhóm đã thay đổi prompt thường xuyên đến mức nào. Khi làm ứng dụng agent thực tế, tôi nhiều lần thấy rằng chỉ một thay đổi nhỏ trong prompt cũng có thể tạo ra khác biệt cực lớn về hành vi, nhất là quanh các vấn đề reward hacking và hallucination. Tôi muốn tìm hiểu sâu hơn về cách tiếp cận này

  • Việc hiệu năng vẫn giảm dù đã tận dụng tool call thực sự rất thú vị. Tôi tò mò tháng đầu tiên có gì khác biệt. Có phải ban đầu toàn bộ ngữ cảnh được đưa vào mà không cần tool call, rồi sang các tháng sau thì tool call không còn hoạt động tốt nữa không? Tôi thắc mắc ở điểm đó. Chẳng phải tool call nên được dùng để bù đắp cho ngữ cảnh sao?

  • Đây thực sự là một lĩnh vực rất thú vị. Trước đây tôi cũng từng học kế toán tài chính ở cao học và thử mô hình hóa hệ thống ghi sổ kép. Phần khó nhất không phải triển khai mà là kiểm soát chất lượng dữ liệu. Tôi cảm thấy thế giới cần một bộ dữ liệu quy trình kế toán được chuẩn hóa. Về hiện tượng hiệu năng của frontier LLM giảm dần theo thời gian, theo kinh nghiệm của tôi thì khi dùng LLM, giao cho nó một việc lớn trong một lần kém ổn định hơn rất nhiều so với cách chia dần công việc thành các đơn vị nhỏ. Hướng phát triển agent tool như thế này giống như một ô cửa cho thấy tương lai

  • Tôi muốn biết liệu có bản tổng quan chi tiết hơn như bài trên arxiv hoặc tập train thực tế không

• Tôi cực kỳ thích thiết kế của trang web này

  Nếu mô hình đã bối rối đến vậy thì làm sao nó vẫn cứ vượt qua được các bước kiểm tra reconciliation? Rất có thể nó đã chèn các giao dịch bịa đặt hoặc kéo các giao dịch không liên quan vào chỉ để khớp số và hack phần validation, nên kết quả này thực sự rất thú vị. Tôi nghĩ hoàn toàn có thể xảy ra tình huống ai đó mù quáng tin LLM, giao kế toán cho nó, rồi vô tình thực hiện hành vi gian lận. Xa hơn nữa, tôi còn nghĩ một số cơ quan nhà nước có thể đã thử dùng LLM như accounting validator. Chính phủ nước tôi cũng đang cố nhét LLM vào các dịch vụ hành chính số

  • Đây đã là thời đại mà các luật sư dùng LLM để soạn văn bản pháp lý. Tôi hoàn toàn có thể hình dung ở đâu đó trên thế giới đã có người áp dụng LLM như ChatGPT vào kế toán và đang từ từ làm công ty mình lụn bại

  • [Về thiết kế trang web] Một lời nhắc thưởng thêm cho những ai coi trọng quyền riêng tư. Trang này vẫn hoạt động tốt ngay cả khi uBlock chặn frame và script của bên thứ ba, và cũng không có font từ xa hay media nặng, nên hiển thị rất sạch sẽ. Một thiết kế đẹp như vậy mà còn có sự chu đáo này thì thật đáng nể

  • Tôi tin chắc rằng các mánh kế toán mà LLM có thể nghĩ ra thì ở đâu đó cũng đã có các kế toán viên con người thích đi đường vòng dùng đến rồi. Giải pháp không phải là ngăn hay né AI, mà là tăng cường cơ chế xác minh

• Mỗi lần đọc những bài như thế này tôi đều thấy hơi bức bối. Công việc thực tế như kế toán được tạo thành từ một chuỗi phép toán rất chính xác, nhiều ràng buộc, và dễ kiểm toán. Con người xử lý độ phức tạp đó bằng cách chia nó thành các quy trình có cấu trúc và quản lý theo những đơn vị có thể hiểu được. Việc kỳ vọng mô hình AI xử lý tốt một workflow end-to-end mà không có phân tách cấu trúc rõ ràng và cơ chế giám sát là không chỉ vượt quá giới hạn của mô hình, mà còn là hiểu sai chính bản chất của công việc này. Tôi muốn thấy ai đó thử nghiệm theo hướng điều phối các workflow dài hạn, phi tuyến tính một cách có cấu trúc hơn, với giám sát minh bạch và nguyên tắc mô-đun hóa. Hướng đó sẽ thú vị hơn nhiều

  • Nếu là benchmark mà ai cũng dễ dàng vượt qua thì nó vô dụng. Nếu một số mô hình làm tốt hơn, và không mô hình nào chạm trần, thì bản thân điều đó đã có ý nghĩa. Điểm quan trọng là nó cho phép so sánh giữa các mô hình

• Đọc xuyên suốt log của LLM xong, tôi thật sự kinh ngạc trước mức độ suy nghĩ sâu mà các mô hình hiện tại có thể đạt tới. Dù theo thời gian chúng vẫn mắc lỗi, tôi vẫn rất háo hức với tương lai

  • Tôi nghĩ khi xuất hiện các mô hình có thể suy nghĩ nhất quán trong nhiều giờ để giải các bài IMO, thì chúng cũng sẽ giải quyết các bài toán kế toán kiểu này tốt hơn

• Tôi đã gửi bài này cho mấy người bạn làm kế toán, và nó khớp một cách kỳ lạ với trải nghiệm của tôi khi dùng LLM để làm game. Cách dùng tối ưu nhất của các mô hình ngôn ngữ hiện nay, kể cả agent mode, theo cảm nhận của tôi là đưa thật chính xác đầu ra mình muốn vào, rồi dùng nó như một dạng autocomplete tốt hơn. Nó tiết kiệm được khá nhiều thời gian, nhưng không phải vạn năng

  • Thành thật mà nói, tôi không chắc nó có thực sự tiết kiệm thời gian hoàn toàn không. Rốt cuộc tôi thấy mình tốn nhiều thời gian hơn so với tự làm, chỉ để sắp xếp task và phân tích, debug hallucination

  • Tôi tò mò “autocomplete tốt hơn” cụ thể là tốt hơn cái gì

  • Trong bookkeeping thì thực sự nó có tiết kiệm khá nhiều thời gian, nhưng tôi vẫn cảm thấy kế toán viên con người là tuyệt đối cần thiết

• Tôi nghĩ kiểu benchmarking này sẽ phụ thuộc cực mạnh vào prompt và cách cấu hình phương pháp. Tùy cách thiết kế mà độ chính xác có thể thay đổi hoàn toàn. Kết quả có lẽ sẽ khác rất nhiều tùy mỗi người kiến trúc hóa LLM theo cách nào. Đọc thêm thì có vẻ mục tiêu chỉ là một benchmark đơn giản để quan sát theo thời gian. Có vẻ trọng tâm là định hướng hơn là tính thực dụng như một công cụ auto-close

• Ledger balances are calculated by summing all transactions per account. The differences should be as close to zero as possible, with small differences allowed for pending transactions such as weekly Stripe payouts. Mô tả này không hoàn toàn chính xác. Tôi không phải kế toán viên, nhưng các giao dịch đang chờ xử lý mà chưa thanh toán thì vẫn nhất định phải được tính vào số dư tài khoản hoặc “số dư khả dụng”. Việc đơn giản gạt đi rằng “nếu có chênh lệch thì chắc là do giao dịch chờ xử lý” là rất nguy hiểm

  • Tôi là thành viên nhóm benchmark! Tôi đồng ý rằng cách diễn đạt kiểu “as close to zero” có thể gây hiểu nhầm. Điểm mấu chốt của bước kiểm tra reconciliation trong báo cáo thực ra là phải đối soát chính xác phần chênh lệch đó. Tức là phải xác định mọi giao dịch tạo ra khác biệt giữa số dư tài khoản (bao gồm giao dịch chờ xử lý/giao dịch sau ngày sao kê) và số dư sao kê (không bao gồm các giao dịch sau đó), rồi đảm bảo tính chính xác của sổ sách kế toán bằng cách xử lý đúng phần chênh lệch đó thông qua bút toán hoặc điều chỉnh phù hợp

• Điều benchmark này cho thấy là hiện tượng LLM cứ “cố tạo ra đáp án đúng”, và vì thế sai số ngày càng tích lũy lớn hơn. Nếu phản biện theo hướng logic, có lẽ mô hình đang bị yêu cầu trả lời trong khi không có đủ chi tiết? Có vẻ hiệu năng tháng 1–2 vẫn ổn nhờ thông tin ngầm ẩn trong dữ liệu giao dịch quá khứ. Kết luận của tôi là, khi scale trong môi trường enterprise, điều cốt lõi là phải biến toàn bộ thông tin ngầm thành thông tin tường minh

• Chúng ta vốn đã có thói quen không chú ý đến chi tiết, và AI còn làm điều đó trầm trọng hơn. Phần mềm phi quyết định khi được áp vào các bài toán thực tế cần yêu cầu cực kỳ chính xác thì rất nguy hiểm. Doanh nghiệp có thể chấp nhận chatbot bị 5–20% khách hàng đánh giá là tệ, nhưng SEC, DOJ và cổ đông sẽ tuyệt đối không chấp nhận việc kế toán sai 20% hoặc cây cầu bị thiếu 5 inch chiều dài

  • Kế toán viên con người trên thực tế cũng thường khá phi quyết định. Trong các hệ thống kế toán đủ phức tạp, luôn sẽ có một mức độ không chính xác nhất định. Câu hỏi cốt lõi là “mức không chính xác đó có thực sự trọng yếu (= material) hay không”. Tôi thấy bài viết rất ấn tượng, và kỳ vọng rằng nếu được nâng cấp thêm một bậc nữa thì nó có thể tiến gần đến mức độ chính xác của kế toán viên con người

  • Nếu những “yêu cầu cực kỳ chính xác” đó có thể được tự động xác minh với chi phí rẻ, thì AI cũng có thể lặp đi lặp lại việc tạo spam cho đến khi vượt qua mọi bài kiểm tra