Thị giác máy tính 4 — OCR & Document AI
Thị giác máy tính 4 — OCR & Document AI
Một ngày điển hình ở back-office ngân hàng: hàng nghìn tấm ảnh CCCD, hộ chiếu, hoá đơn, sao kê, hồ sơ vay được chụp/quét và đổ vào hệ thống. Ai đó — hoặc cái gì đó — phải đọc chúng, lấy ra họ tên, số giấy tờ, ngày sinh, số tiền, số tài khoản, rồi nhập vào core banking. Làm tay thì chậm, đắt và sai. Đây chính là địa hạt của OCR và Document AI.
Nhiều người dùng hai từ này thay nhau, nhưng chúng KHÁC nhau về tham vọng. OCR chỉ trả lời câu hỏi "trên ảnh có những chữ gì?". Document AI (hay IDP — Intelligent Document Processing, xử lý tài liệu thông minh) trả lời câu hỏi khó hơn nhiều: "tài liệu này là loại gì, cấu trúc ra sao, và trường thông tin tôi cần nằm ở đâu, giá trị bằng bao nhiêu?". Bài này đi từ OCR thô lên IDP, đặt trọng tâm vào chứng từ ngân hàng và những cạm bẫy thực chiến.
Đây là danh mục AI. Các đoạn code trong bài là pseudocode/JSON minh hoạ để bạn thấy hình dạng luồng xử lý và dữ liệu, không phải SQL/Python sandbox chạy được.
1. OCR là gì và pipeline OCR
OCR (Optical Character Recognition — nhận dạng ký tự quang học) là việc chuyển ảnh chứa chữ thành text máy đọc được. Đầu vào là điểm ảnh; đầu ra là chuỗi Unicode. Nghe đơn giản, nhưng một OCR nghiêm túc không phải một bước mà là một pipeline ba khâu:
- Tiền xử lý (pre-processing): ảnh chụp bằng điện thoại thường nghiêng, mờ, loá, bóng. Các bước như deskew (nắn nghiêng), denoise (khử nhiễu), binarization (nhị phân hoá đen/trắng), tăng tương phản làm chữ nổi bật. Chất lượng tiền xử lý quyết định phần lớn độ chính xác cuối — "rác vào, rác ra".
- Text detection (phát hiện vùng chữ): tìm ở đâu trên ảnh có chữ, trả về các bounding box hoặc polygon bao quanh dòng/từ. Đây thực chất là bài toán object detection chuyên biệt (xem Phân loại & Phát hiện); các mô hình phổ biến: EAST, DBNet, CRAFT.
- Text recognition (nhận dạng chữ): với mỗi vùng đã cắt, đọc chữ gì. Kiến trúc kinh điển là CRNN (CNN trích đặc trưng thị giác + RNN/LSTM mô hình chuỗi + lớp CTC để căn chỉnh chuỗi ký tự với chuỗi đặc trưng); các mô hình mới dùng cơ chế attention/transformer (xem Transformers).
- Hậu xử lý (post-processing): sửa lỗi bằng từ điển, regex, ràng buộc định dạng (số CCCD 12 chữ số, ngày
dd/mm/yyyy), chuẩn hoá (bỏ khoảng trắng thừa, hợp nhất dòng).
Kết quả OCR tốt không chỉ là text mà là text kèm toạ độ và điểm tin cậy (confidence) cho từng từ — thông tin này cực kỳ quan trọng cho các bước IDP phía sau.
2. Tiếng Việt: vì sao khó hơn
Tiếng Anh 26 chữ cái không dấu. Tiếng Việt có dấu thanh (sắc, huyền, hỏi, ngã, nặng) chồng lên dấu phụ (â, ê, ô, ơ, ư, ă, đ), tạo ra rất nhiều tổ hợp ký tự chỉ khác nhau ở vài điểm ảnh nhỏ phía trên/dưới. a, à, á, ả, ã, ạ, â, ấ, ầ... — model phải phân biệt được tất cả. Hệ quả:
- Nhầm dấu là lỗi phổ biến nhất:
Nguyễn→Nguyên,Hoà→Hoa,Đặng→Dang. Với ngân hàng, sai một dấu ở tên có thể khiến đối chiếu định danh thất bại. - OCR không hỗ trợ tiếng Việt (chỉ train tiếng Anh) sẽ bỏ hết dấu hoặc đọc bậy — không dùng được cho giấy tờ Việt Nam.
- Vấn đề Unicode dựng sẵn vs tổ hợp (NFC vs NFD): cùng chữ
ếcó thể được mã hoá hai kiểu; cần chuẩn hoá về NFC ở hậu xử lý để đối chiếu chuỗi không bị lệch.
Lựa chọn model hỗ trợ tiếng Việt trong thực tế:
| Giải pháp | Bản chất | Điểm mạnh | Lưu ý |
|---|---|---|---|
| VietOCR | Model recognition mã nguồn mở train riêng cho tiếng Việt (kiến trúc transformer/seq2seq) | Đọc dấu tốt, cộng đồng VN | Cần ghép với một detector; tự vận hành |
Tesseract + vie | Engine OCR cổ điển với gói ngôn ngữ tiếng Việt | Miễn phí, chạy offline, on-premise | Độ chính xác kém với ảnh khó/ font lạ; cần tiền xử lý kỹ |
| Dịch vụ cloud | API Document AI của nhà cung cấp lớn | Chính xác cao, ít phải bảo trì | Chi phí theo lượt; dữ liệu rời hạ tầng ngân hàng → cân nhắc compliance |
Với hồ sơ ngân hàng, thực tế thường là fine-tune (huấn luyện tinh chỉnh) một model tiếng Việt trên chính bộ giấy tờ của mình (CCCD mẫu mới, sao kê từng ngân hàng...) để đạt độ chính xác cần thiết.
3. Từ OCR thô lên Document AI / IDP
OCR cho bạn một đống text. Nhưng nghiệp vụ cần thông tin có cấu trúc: trường họ_tên = "Nguyễn Văn A", số_CCCD = "012345678901", ngày_cấp = "2021-05-10". Khoảng cách giữa "text thô" và "trường có nghĩa" chính là phần Document AI / IDP giải quyết. Bốn năng lực cốt lõi:
- Layout analysis (phân tích bố cục): hiểu cấu trúc không gian — đâu là tiêu đề, đoạn văn, bảng, form, con dấu, chân dung. Vị trí mang nghĩa: số nằm ngay dưới nhãn "Số CCCD" nhiều khả năng là số CCCD.
- Key-value extraction (trích cặp khoá–giá trị): ghép nhãn với giá trị. Trên tài liệu có ô "Họ và tên: ______", model gắn giá trị vào đúng khoá
full_name. Đây là trái tim của việc điền form tự động. - Table extraction (trích bảng): nhận diện hàng/cột và ô, phục dựng bảng thành dữ liệu có cấu trúc — quan trọng với sao kê giao dịch, bảng lương, danh mục hoá đơn.
- Document classification (phân loại tài liệu): một hồ sơ vay có thể gồm CCCD + sao kê + hợp đồng lao động + giấy tờ nhà. Trước khi trích, phải biết mỗi trang là loại gì để áp đúng "khuôn" trích xuất.
Mô hình hiện đại: multimodal
Điểm đột phá là model kết hợp ba nguồn tín hiệu: text (nội dung chữ), layout (toạ độ 2D của từng từ) và visual (đặc trưng thị giác của ảnh). Đây gọi là multimodal document transformer:
- LayoutLM / LayoutLMv3: transformer nhúng thêm toạ độ (x, y) của từng token và đặc trưng ảnh vào cùng model, học được rằng "từ nằm ở vị trí này, cạnh nhãn kia, trên nền như vậy → là trường số tiền". Rất mạnh cho form và key-value.
- Donut (Document Understanding Transformer): hướng OCR-free — bỏ qua bước OCR riêng, đọc thẳng từ ảnh và sinh ra output có cấu trúc (ví dụ JSON) bằng decoder. Gọn pipeline, tránh lỗi lan truyền từ OCR, nhưng cần nhiều dữ liệu huấn luyện.
Ý tưởng chung: vị trí + hình ảnh cũng là thông tin, không chỉ chữ. Đó là điều phân biệt Document AI với OCR + regex thuần tuý.
4. Quy trình xử lý tài liệu tự động (end-to-end)
Ghép mọi thứ lại, một pipeline IDP trong ngân hàng trông như sau:
Diễn giải từng khâu:
- Chụp/quét: thu ảnh từ app khách hàng (eKYC) hoặc scanner tại quầy. Kiểm chất lượng đầu vào ngay (mờ, thiếu góc, loá) → yêu cầu chụp lại sớm, rẻ hơn nhiều so với xử lý ảnh rác.
- Phân loại: xác định CCCD / hộ chiếu / sao kê / hợp đồng để chọn khuôn trích phù hợp.
- OCR: phát hiện + đọc chữ, giữ toạ độ và confidence.
- Trích trường: áp model IDP hoặc luật để lấy ra các trường nghiệp vụ.
- Validation: áp rule (định dạng số CCCD, checksum, ngày hợp lệ, tổng cột bảng khớp) và đối chiếu chéo (tên trên CCCD khớp tên khai; số tài khoản tồn tại trong hệ thống). Đây là hàng rào chống lỗi và gian lận đầu tiên (liên quan Fraud & FRAML).
- Human-in-the-loop: trường nào confidence thấp hoặc rớt validation thì đẩy cho người duyệt — chỉ duyệt phần nghi ngờ, không duyệt lại toàn bộ. Đây là chìa khoá để vừa nhanh vừa an toàn.
- Nhập hệ thống: ghi trường đã xác nhận vào core/CRM.
- Vòng phản hồi: những chỗ người sửa được lưu làm nhãn để retrain model — model càng dùng càng tốt lên (liên hệ Pipeline MLOps).
5. Confidence & xử lý lỗi
Confidence (độ tin cậy) là điểm số 0–1 model gán cho mỗi ký tự/trường, ước lượng "tôi chắc chắn đến đâu". Đây là công cụ vận hành quan trọng nhất trong IDP, vì nó cho phép định tuyến (routing) theo ngưỡng:
- Confidence cao + qua validation → tự động (STP — Straight-Through Processing): vào thẳng hệ thống, không cần người.
- Confidence trung bình hoặc rớt một rule → human review: người duyệt/sửa trường nghi ngờ.
- Confidence rất thấp / phân loại không rõ → trả lại: yêu cầu chụp lại hoặc chuyển xử lý thủ công.
Ví dụ cấu hình ngưỡng (minh hoạ, KHÔNG phải chuẩn cố định):
# Minh hoạ chính sách routing theo confidence
field_thresholds:
so_cccd: { auto_accept: 0.98, review_below: 0.98 } # trường nhạy cảm, ngưỡng cao
ho_ten: { auto_accept: 0.95, review_below: 0.95 }
so_tien: { auto_accept: 0.99, review_below: 0.99 } # sai tiền = rủi ro lớn
dia_chi: { auto_accept: 0.90, review_below: 0.90 }
validation:
- so_cccd matches ^\d{12}$
- ngay_sinh is valid date and age >= 18
Lưu ý quan trọng: confidence của model có thể sai (model "tự tin nhưng nhầm"). Vì vậy phải chặn thêm bằng validation nghiệp vụ độc lập, không chỉ tin mỗi điểm số. Với trường tiền tệ và định danh, đặt ngưỡng cao và ưu tiên để người xác nhận.
6. Ứng dụng ngân hàng
Đây là nơi OCR/IDP tạo giá trị rõ nhất:
| Bài toán | Tài liệu | Trường trích chính |
|---|---|---|
| eKYC / định danh | CMND, CCCD (chip), hộ chiếu | Họ tên, số giấy tờ, ngày sinh, ngày cấp, nơi cấp, giới tính, quốc tịch |
| Mở tài khoản / vay | Đơn đăng ký, hợp đồng lao động | Thông tin cá nhân, thu nhập, mục đích vay |
| Hoá đơn / chứng từ | Hoá đơn VAT, uỷ nhiệm chi | Số HĐ, ngày, người bán/mua, MST, tiền trước/sau thuế |
| Séc | Séc giấy | Số tiền bằng số & bằng chữ (đối chiếu chéo), số séc, mã ngân hàng, chữ ký |
| Sao kê | Sao kê tài khoản/thẻ | Bảng giao dịch: ngày, diễn giải, số tiền, số dư (table extraction) |
Một vài lưu ý thực chiến theo tài liệu:
- CCCD gắn chip: phần lớn thông tin có thể đọc qua NFC/QR chính xác hơn OCR mặt ảnh; nên ưu tiên chip/QR, dùng OCR để đối chiếu và xử lý giấy tờ cũ.
- Séc: kỹ thuật đọc số tiền dùng cả nhánh chữ số in/viết tay (gần với bài toán MNIST kinh điển) và đối chiếu số ↔ chữ — hai giá trị phải khớp mới hợp lệ.
- Sao kê: giá trị nằm ở table extraction đúng; sai lệch cột số tiền/số dư có thể kiểm tra bằng ràng buộc
số_dư_sau = số_dư_trước ± giao_dịch. - eKYC: OCR chỉ là một mảnh; còn cần đối sánh khuôn mặt và chống giả mạo — xem bài tiếp Nhận diện khuôn mặt & eKYC.
Dữ liệu trích được thường lưu về bảng để nghiệp vụ dùng tiếp. Ví dụ, sau khi trích và ghi vào hệ thống, ta có thể tổng hợp khách theo thành phố:
-- ▶ Chạy được
SELECT city, COUNT(*) AS so_khach
FROM customers
GROUP BY city
ORDER BY so_khach DESC;
7. Đánh giá chất lượng
Không đo thì không cải thiện được. Các chỉ số cốt lõi:
- CER (Character Error Rate — tỷ lệ lỗi ký tự) và WER (Word Error Rate — tỷ lệ lỗi từ): tính bằng khoảng cách chỉnh sửa (Levenshtein — số lần chèn/xoá/thay) giữa text OCR và text chuẩn, chia cho tổng ký tự/từ. CER thấp là tốt. Đây là chỉ số ở tầng OCR thô.
- Field-level accuracy (độ chính xác theo trường): với IDP, cái nghiệp vụ quan tâm là trích đúng trường hay không. Đo exact-match cho từng trường (số CCCD đúng 100% hay không), rồi tính precision/recall/F1 cho việc trích. Một OCR CER thấp vẫn có thể sai trường nếu ghép key-value sai.
- STP rate (tỷ lệ tự động hoàn toàn): bao nhiêu % hồ sơ đi thẳng không cần người — chỉ số kinh tế quan trọng nhất.
- Chi phí review: thời gian/nhân lực duyệt thủ công còn lại.
Quan trọng: luôn đo trên tập chuẩn (ground truth) đại diện thực tế — đủ ảnh mờ, nghiêng, font lạ, giấy tờ cũ — chứ không chỉ ảnh đẹp. Và đo theo từng loại tài liệu và từng trường, vì lỗi thường dồn vào vài trường/loại khó.
8. Build vs Buy
Câu hỏi kinh điển: tự xây hay mua dịch vụ?
| Tiêu chí | Buy (dịch vụ cloud Document AI) | Build (tự xây on-premise) |
|---|---|---|
| Tốc độ triển khai | Nhanh, API sẵn | Chậm, cần đội ML |
| Độ chính xác ban đầu | Cao, đã train sẵn | Phụ thuộc dữ liệu & công sức |
| Tuỳ biến tiếng Việt/giấy tờ VN | Hạn chế nếu chưa hỗ trợ sẵn | Toàn quyền fine-tune |
| Chi phí | Theo lượt (biến phí), tăng theo volume | Đầu tư trước + hạ tầng (định phí) |
| Chủ quyền dữ liệu / compliance | Dữ liệu rời hạ tầng → rủi ro | Dữ liệu ở trong nhà |
| Bảo trì | Nhà cung cấp lo | Tự lo, gánh nặng dài hạn |
Với ngân hàng, yếu tố compliance và chủ quyền dữ liệu thường mang tính quyết định: ảnh CCCD, khuôn mặt, sao kê là dữ liệu cá nhân nhạy cảm (xem Quyền riêng tư & Tuân thủ). Nhiều tổ chức chọn lai (hybrid): dùng dịch vụ cloud cho loại tài liệu phổ thông ít nhạy cảm, và xử lý on-premise cho định danh/eKYC. Một chiến lược thực tế là "buy để chạy nhanh, rồi build dần" cho các loại tài liệu khối lượng lớn để tối ưu chi phí và kiểm soát.
Use case thực tế
Bối cảnh: NCB triển khai IDP cho luồng mở tài khoản online. Mỗi ngày ~2.000 hồ sơ, mỗi hồ sơ gồm ảnh CCCD hai mặt và một sao kê. Trước đây 100% nhập tay: mỗi hồ sơ ~4 phút, cần đội 12 người, sai sót nhập liệu ~3%.
Giải pháp IDP triển khai theo pipeline mục 4:
- Phân loại + OCR + trích trường CCCD (họ tên, số CCCD, ngày sinh, ngày cấp, địa chỉ) bằng model tiếng Việt fine-tune trên mẫu CCCD chip.
- Validation:
số CCCD ^\d{12}$+ checksum;ngày sinhhợp lệ và tuổi ≥ 18; tên trên CCCD khớp tên khách khai (chuẩn hoá NFC, bỏ dấu để so mờ). - Routing theo confidence: trường
số CCCD/số tiềnngưỡng 0.98–0.99; dưới ngưỡng hoặc rớt validation → human review.
Kết quả sau 3 tháng (minh hoạ mục tiêu vận hành):
- Field-level accuracy các trường CCCD đạt ~98.5%; STP rate ~72% (72% hồ sơ tự động, không người chạm).
- Thời gian xử lý trung bình mỗi hồ sơ giảm từ 4 phút xuống ~50 giây (tính cả phần review 28% còn lại).
- Đội nhập liệu giảm từ 12 xuống 4 người, chuyển sang chỉ duyệt trường confidence thấp.
- Các trường người duyệt sửa được gom lại, mỗi tháng retrain một lần → CER giảm dần, STP rate tăng.
Bài học: giá trị lớn nhất không đến từ "OCR chính xác 100%" (bất khả) mà từ định tuyến thông minh theo confidence + validation nghiệp vụ + human-in-the-loop. Tự động hoá phần chắc chắn, để con người tập trung vào phần khó — đó là công thức vừa nhanh, vừa an toàn, vừa cải thiện liên tục.
Ghi nhớ
- OCR ≠ Document AI. OCR: ảnh chữ → text. IDP/Document AI: hiểu cấu trúc và trích trường có nghĩa (key-value, table, layout, phân loại).
- Pipeline OCR 3 khâu: tiền xử lý → text detection (vùng chữ) → text recognition (đọc chữ) → hậu xử lý. Giữ toạ độ + confidence, không chỉ text.
- Tiếng Việt khó vì dấu. Bắt buộc dùng model hỗ trợ tiếng Việt (VietOCR, Tesseract+
vie, cloud); chuẩn hoá Unicode NFC; thường phải fine-tune trên giấy tờ VN. - Model hiện đại là multimodal (text + layout + visual): LayoutLM (nhúng toạ độ), Donut (OCR-free, sinh JSON trực tiếp).
- Quy trình tự động: chụp → phân loại → OCR → trích trường → validation (rule + đối chiếu) → human-in-the-loop cho confidence thấp → nhập hệ thống → vòng retrain.
- Confidence + validation là công cụ vận hành cốt lõi: định tuyến STP/review/từ chối theo ngưỡng; nhưng confidence có thể sai → phải có rule nghiệp vụ độc lập.
- Ngân hàng: eKYC (CCCD/hộ chiếu — ưu tiên chip/QR), mở tài khoản/vay, hoá đơn, séc (đối chiếu số ↔ chữ), sao kê (table extraction).
- Đo lường: CER/WER (tầng OCR), field-level accuracy/F1 và STP rate (tầng nghiệp vụ); đo trên tập chuẩn đại diện gồm cả ảnh xấu.
- Build vs Buy: cân nhắc tốc độ, tuỳ biến tiếng Việt và chủ quyền dữ liệu/compliance; ngân hàng thường chọn hybrid, nhạy cảm thì on-premise.
Bài viết liên quan
Phân biệt AI/ML/DL, các kiểu học máy, quy trình ML end-to-end và thuật ngữ nền tảng.
Chất lượng dữ liệu, xử lý thiếu/ngoại lai, mã hoá, chuẩn hoá, tạo đặc trưng và tránh data leakage.
Mô hình ngôn ngữ lớn hoạt động ra sao, token, context window, tham số sinh, và kỹ thuật viết prompt.
Retrieval-Augmented Generation, vector database, tool calling, agent và MCP để xây ứng dụng LLM thực tế.