Optical Character Recognition(OCR)

Một tệp PDF scan, với máy tính, chỉ là một bức ảnh. OCR là bước đọc bức ảnh đó ra chữ. Công nghệ này có từ lâu và đã khá ổn định. Trong nhóm AI thì đây cũng là thứ dễ chỉ ra tiền tiết kiệm nhất: số chứng từ nhân với số phút gõ tay, hết. Với điều kiện dùng đúng chỗ.

Câu hỏi đầu tiên trước mọi dự án OCR: dữ liệu này có tồn tại ở dạng có cấu trúc ở đâu đó không. Nếu có, đừng OCR.

Ba mức chất lượng đầu vào

Cùng gọi là OCR nhưng độ khó chênh nhau rất xa, và tiến độ dự án gần như phụ thuộc hết vào chỗ này:

Đưa cả ba mức vào cùng một phạm vi với cùng một cam kết chất lượng là cách chắc chắn để trượt tiến độ.

Ví dụ thực tế

Buổi làm rõ với phòng kế toán một công ty phân phối thiết bị điện. Trên bàn là chồng chứng từ tháng trước, 1.830 tờ, bài toán đặt gọn: "OCR hoá đơn để đỡ nhập tay".

Đúng buổi hôm đó, hơn nửa phạm vi bị cắt. Hoá đơn điện tử theo quy định hiện hành ở Việt Nam luôn kèm tệp XML đủ trường: mã số thuế bên bán, tên hàng, đơn giá, thuế suất, tổng tiền. Khoảng 1.310 chứng từ mỗi tháng thuộc loại này, và với chúng thì đọc XML là chuyện của một buổi lập trình, chính xác tuyệt đối. Có người trong cuộc họp hôm đó tưởng phải OCR bản PDF in ra từ chính tệp XML ấy.

Còn lại 520 chứng từ thật sự cần OCR: hoá đơn giấy của nhà cung cấp nhỏ, phiếu thu viết tay, chứng từ nhập khẩu bằng tiếng Anh và tiếng Trung, biên lai vận chuyển.

Với 520 chứng từ đó, thiết kế cuối cùng gồm bốn trường bắt buộc bóc ra — mã số thuế bên bán, ngày hoá đơn, tổng tiền trước thuế, tiền thuế — mỗi trường kèm một mức độ tin cậy. Trường nào dưới ngưỡng thì ô đó sáng lên trong màn hình duyệt, kế toán nhìn ảnh gốc cạnh bên rồi sửa. Thời gian xử lý một chứng từ từ khoảng 3 phút xuống dưới 1 phút, và không ai phải gõ lại 12 chữ số mã số thuế nữa.

Viết yêu cầu cho một tính năng OCR

Sáu điểm phải có trong tài liệu, và điểm số ba là điểm hay bị bỏ qua nhất:

1. Danh sách trường cần bóc, có phân loại quan trọng. Sai tên hàng thì phiền, sai số tiền thì hỏng sổ. Hai loại này không thể chung một ngưỡng.
2. Ngưỡng độ tin cậy và hành vi khi dưới ngưỡng. Viết cụ thể: dưới 0,9 thì bắt buộc người xác nhận, dưới 0,6 thì coi như không đọc được và chuyển sang nhập tay hoàn toàn.
3. Đối chiếu chéo với dữ liệu sẵn có. Mã số thuế phải khớp danh mục nhà cung cấp. Tổng tiền phải bằng tổng các dòng cộng thuế. Ngày hoá đơn không được nằm ngoài kỳ kế toán đang mở. Ba phép kiểm này bắt được phần lớn lỗi mà mô hình không tự biết.
4. Luôn giữ ảnh gốc và hiển thị cạnh dữ liệu đã bóc. Người duyệt cần nhìn thấy chỗ nó lấy số ra.
5. Đường thoát. Chứng từ nào cũng phải nhập tay được, không phụ thuộc mô hình.
6. Cách đo khi nghiệm thu. Đo theo trường quan trọng trên một bộ mẫu 300 chứng từ đại diện đủ ba mức chất lượng ảnh, không đo bằng tỉ lệ ký tự đúng trên toàn văn bản.

Lỗi hay gặp

Đo sai thước. Nhà cung cấp báo độ chính xác 98% trên toàn ký tự nghe rất đẹp, nhưng nếu 2% sai rơi vào chữ số tiền thì tính năng vô dụng. Luôn quy về trường nghiệp vụ.

Quên con dấu và chữ ký. Dấu tròn màu đỏ đè lên phần tổng tiền là chuyện phổ biến với chứng từ giấy ở Việt Nam, và đó là ca gãy kinh điển.

Không tính công người duyệt. Bài toán chỉ đúng khi thời gian máy đọc cộng thời gian người kiểm nhỏ hơn thời gian nhập tay. Người vẫn phải soi từng trường thì chưa tiết kiệm được gì.

Dùng mô hình ngôn ngữ để "đọc" chứng từ mà không ràng buộc. Mô hình đa phương thức đọc ảnh khá tốt, nhưng vẫn có thể điền một giá trị trông hợp lý vào ô nó không nhìn rõ. Với chứng từ tài chính, chỗ nào không đọc được phải trả về rỗng, và đó là một ràng buộc phải viết thẳng vào yêu cầu.