Đối chiếu số liệu: bạn chỉ nên nói “đã chạy đúng” khi số đã khớp với sổ sách của khách

Cuộc họp nghiệm thu thường đổ vỡ theo một kiểu quen thuộc. Bạn trình chiếu dashboard: agent đã đọc hết hoá đơn tháng Mười, pipeline không có lỗi nào, tổng doanh thu đã hiện lên màn hình. Kế toán trưởng của khách mở sổ cái ra, im lặng một lúc rồi hỏi tại sao con số lại lệch.

Từ lúc đó, dự án không còn là chuyện mô hình giỏi đến đâu. Câu hỏi duy nhất là bạn có giải thích được khoản chênh lệch hay không. Nếu bạn trả lời được ngay, khách sẽ tin bạn. Nếu bạn phải hẹn “để em kiểm tra lại”, cả hệ thống sẽ bị nghi ngờ.

Đối chiếu, hay reconciliation, là kỹ năng giúp bạn không rơi vào tình huống đó. Kế toán đã làm việc này từ lâu: đối chiếu tài khoản là so sổ sách nội bộ với chứng từ bên ngoài hoặc tài liệu hỗ trợ. Bài này chỉ cách mang kỷ luật ấy vào một dự án AI, để câu “đã chạy đúng” là một khẳng định bạn chứng minh được.

Đối chiếu là gì, nói cho dễ hiểu?

Tài liệu của Soda, một công cụ chất lượng dữ liệu, định nghĩa reconciliation check là phép kiểm tra xem một tập dữ liệu đích có khớp với một hay nhiều tập dữ liệu nguồn hay không. Phép kiểm tra có hai mức. Ở mức tổng hợp, bạn so các chỉ số như số dòng hay tổng tiền. Ở mức từng dòng, bạn so từng bản ghi một.

Với FDE, tập “đích” là thứ hệ thống của bạn tạo ra: bảng hoá đơn do agent trích xuất, dự báo tồn kho, hay dữ liệu đã được chuyển sang kho mới. Tập “nguồn” là thứ khách coi là sự thật, thường là sổ cái, hệ thống ERP hoặc file Excel mà phòng tài chính đã chốt.

Còn một khái niệm nhỏ nhưng quyết định mọi thứ là ngưỡng. Soda yêu cầu định nghĩa mức chênh lệch chấp nhận được bằng threshold, và mặc định của nó là 0. Mặc định đó rất đúng tinh thần kế toán: không có ngưỡng nào được ghi ra thì không có chênh lệch nào được coi là “chấp nhận được”.

Nên kiểm tra theo thứ tự nào?

So từng dòng trên toàn bộ dữ liệu vừa đắt vừa chậm. Soda khuyên làm theo thứ tự tiết kiệm hơn: kiểm tra ở mức tổng hợp trước (số dòng, tổng, trung bình), sau đó mới so từng dòng có chọn lọc trên các tập dữ liệu quan trọng nhất.

Chỉ đếm dòng thì chưa đủ. Một hướng dẫn kiểm thử migration của Xylity đề xuất tính SUM, MIN, MAX, AVG cho mọi cột số. Hai bảng có thể có cùng 4.812 dòng mà một bảng đã bị cắt cụt hoặc làm tròn. Đếm dòng không nhìn thấy những lỗi này, còn tổng và cực trị thì lộ ra ngay.

Cũng tài liệu đó gọi lệch múi giờ là lỗi phổ biến nhất với dữ liệu ngày tháng. Vì vậy, sau khi so tổng hợp, bước tiếp theo nên là chia chênh lệch theo ngày. Nếu khoản lệch dồn vào ngày đầu hoặc cuối kỳ, múi giờ thường là thứ đáng nghi đầu tiên.

Một ví dụ hoàn chỉnh

Ví dụ sau là giả định, kể cả các con số. Một nhà phân phối ở múi giờ UTC+7 nhờ bạn dựng agent đọc hoá đơn và ghi vào bảng ai_invoices. Agent lưu thời điểm xuất hoá đơn vào cột invoice_ts theo giờ UTC, còn phòng tài chính chốt sổ trong bảng ledger_invoices với cột invoice_date theo giờ địa phương.

Trước khi so bất cứ thứ gì, bạn và kế toán trưởng thống nhất bằng văn bản: số dòng phải lệch 0, tổng tiền được lệch tối đa 0,01 cho mỗi hoá đơn do quy tắc làm tròn.

Lần chạy đầu tiên dùng một câu truy vấn ở mức tổng hợp, lọc kỳ tháng Mười trên đúng cột mà mỗi bên đang lưu:

SELECT 'ai' AS src, COUNT(*) AS n, SUM(amount) AS total,
       MIN(amount) AS mn, MAX(amount) AS mx, AVG(amount) AS avg_amt
FROM ai_invoices WHERE invoice_ts >= '2026-10-01' AND invoice_ts < '2026-11-01'
UNION ALL
SELECT 'ledger', COUNT(*), SUM(amount), MIN(amount), MAX(amount), AVG(amount)
FROM ledger_invoices WHERE invoice_date >= '2026-10-01' AND invoice_date < '2026-11-01';

Giả sử cả hai bên đều có 4.812 dòng, nhưng tổng tiền phía agent cao hơn sổ cái 18.640,25. Đếm dòng khớp làm nhiều người yên tâm sớm, nhưng ở đây nó chỉ có nghĩa là các lỗi đang bù trừ nhau. Bạn chuyển sang chia theo ngày, lấy ngày phía agent bằng cách cắt invoice_ts về dạng DATE:

SELECT d, SUM(ai_amt) - SUM(ledger_amt) AS diff FROM (
  SELECT CAST(invoice_ts AS DATE) AS d, amount AS ai_amt, 0 AS ledger_amt FROM ai_invoices
  UNION ALL
  SELECT invoice_date, 0, amount FROM ledger_invoices
) t GROUP BY d HAVING SUM(ai_amt) - SUM(ledger_amt) <> 0 ORDER BY d;

Câu này cố ý không lọc theo kỳ. Nếu giữ điều kiện tháng Mười, bạn sẽ không thấy những hoá đơn đã bị đẩy sang tháng bên cạnh.

Chênh lệch dồn vào ngày 30/9, 1/10, 31/10 và 1/11. Đây là dấu hiệu của múi giờ. Vì invoice_ts theo UTC, một hoá đơn xuất lúc 6 giờ sáng 1/11 giờ địa phương trở thành 23 giờ ngày 31/10 và bị tính vào tháng Mười.

Cách sửa là quy đổi invoice_ts về múi giờ chốt sổ của khách trước khi lấy ngày và lọc theo kỳ, sau đó chạy lại. Trong ví dụ này, khoản lệch tổng tiền giảm từ 18.640,25 xuống còn 0,37.

Phần 0,37 còn lại mới là lúc cần so từng dòng, và chỉ trên tập hẹp: các hoá đơn có chênh lệch vượt ngưỡng 0,01.

Bạn tìm ra vài hoá đơn mà agent làm tròn thuế theo từng dòng hàng, trong khi kế toán làm tròn trên tổng. Lỗi làm tròn này chỉ lộ diện sau khi đã sửa múi giờ, vì trước đó nó nằm lẫn trong khoản lệch lớn.

Tự làm: từ ngưỡng sai lệch đến chữ ký

Việc cần làm trước cả khi viết SQL là hỏi khách đâu là nguồn chuẩn, kỳ chốt sổ theo múi giờ nào, và ngưỡng sai lệch cho từng chỉ số là bao nhiêu. Ghi tất cả ra một trang và gửi cho họ xác nhận. Nếu chưa có ngưỡng nào được thống nhất, coi như ngưỡng là 0.

Tiếp theo, dựng các lớp kiểm tra tự động. Mô hình của Xylity có năm lớp: ba lớp đầu tự động hoá và chạy lại sau mỗi vòng lặp, hai lớp cuối do con người xác nhận trước khi chuyển sang hệ thống mới (cutover).

Với một dự án AI, ba lớp tự động có thể là đếm dòng, tổng hợp từng cột số, và chênh lệch theo ngày. Hãy cho chúng chạy mỗi khi bạn đổi prompt, đổi model hay sửa pipeline.

Sau đó là hồ sơ bằng chứng. Hướng dẫn đối chiếu tài khoản của Solvexia yêu cầu ghi lại lời giải thích, cách tính và bằng chứng cho mọi tài khoản đã xem xét. Trong ví dụ trên, hồ sơ gồm câu truy vấn, kết quả trước và sau khi sửa múi giờ, danh sách các hoá đơn bị lệch do làm tròn kèm cách xử lý.

Bước cuối là chữ ký. Cũng theo Solvexia, kết quả đối chiếu phải được một bên độc lập duyệt trước khi chốt. Người duyệt không phải là bạn, vì bạn là người dựng hệ thống. Hãy đặt một cổng go/no-go rõ ràng như mô hình của Xylity: chỉ cutover khi tất cả các lớp đã đạt.

Những lỗi khiến bạn mất uy tín

Lỗi đầu tiên là để việc đối chiếu đến cuối dự án. Một bài trên blog kỹ thuật của Databricks nhận xét rằng những đội coi validation là việc tính sau cuối cùng tốn nhiều thời gian cho reconciliation hơn cả chính đợt migration. Khi ba lớp tự động chạy từ tuần đầu, mỗi lỗi bị phát hiện ngay lúc nó xuất hiện.

Lỗi thứ hai là dừng lại khi số dòng đã khớp. Như ví dụ trên cho thấy, số dòng có thể khớp trong khi hai lỗi khác nhau bù trừ cho nhau. Lỗi thứ ba là tự mình chọn ngưỡng sai lệch, chẳng hạn mặc nhiên coi chênh lệch dưới 0,1% là “chấp nhận được”. Con số đó phải do khách quyết định, không phải bạn.

Lỗi thứ tư là tự xác nhận hệ thống đã chạy đúng. Nếu bạn vừa viết pipeline vừa ký duyệt kết quả, bạn đã bỏ qua đúng nguyên tắc mà phòng tài chính của khách áp dụng mỗi tháng.

Kỹ năng này nên thể hiện thế nào khi đi xin việc?

Khi đọc JD, hãy để ý những cụm như “data migration”, “financial data” hay “production validation”. Những đội này cần người làm đối chiếu được. Trong CV, thay vì viết “đảm bảo chất lượng dữ liệu”, hãy ghi cụ thể bạn đã đối chiếu kết quả với nguồn nào, theo ngưỡng nào, và ai là người ký duyệt.

Trong phỏng vấn, bạn nên chuẩn bị sẵn câu trả lời cho một câu hỏi kiểu: “Kể về một lần số liệu hệ thống của bạn lệch với nguồn.

Bạn đã tìm ra nguyên nhân như thế nào?” Câu chuyện tốt đi theo bốn nhịp: khoản lệch là bao nhiêu và ai phát hiện; bạn kiểm tra theo thứ tự nào; nguyên nhân thật là gì; ai đã ký duyệt kết quả cuối cùng.

Một câu chuyện như vậy thường thuyết phục hơn mọi con số về độ chính xác của model. Lý do là phía khách hàng sẽ không chấm hệ thống của bạn bằng accuracy. Họ chấm bằng việc số của bạn có khớp với sổ sách của họ hay không.