OCR thương mại phổ biến sai 25-30% dấu thanh tiếng Việt, khiến AI Chatbot dạng RAG trả lời sai hoặc báo không tìm thấy thông tin. VAON fine-tune engine OCR 132MB CPU-only trên 500.000 mẫu ký tự thật, thay vì dùng LLM sửa lỗi, đưa độ chính xác từ 70% lên mức không còn lỗi trên tập tài liệu đã kiểm thử, giảm 80% chi phí hạ tầng.
Mục lục
- Vì sao OCR tiếng Việt cho AI Chatbot RAG thường thất bại?
- Dùng LLM sửa lỗi OCR: giải pháp tưởng hợp lý nhưng là cái bẫy
- Cách VAON đưa độ chính xác từ 70% lên mức không còn lỗi: 4 bước
- Kết quả đo được từ dự án thực tế
- Khi nào cách tiếp cận này chưa đủ
- Câu hỏi thường gặp
Vì sao OCR tiếng Việt cho AI Chatbot RAG thường thất bại?
Tiếng Việt có hệ thống thanh điệu phức tạp (sắc, huyền, hỏi, ngã, nặng) cùng các nguyên âm biến thể như ă, ơ, ư. Đây là phần OCR thông thường xử lý kém nhất.
Con số cụ thể: khi kiểm thử các engine OCR thương mại phổ biến, kể cả API của các nhà cung cấp cloud lớn, tỷ lệ lỗi dấu thanh và ký tự trên văn bản tiếng Việt đạt 25-30%. Engine liên tục đọc "thanh toán" thành "thanh toan", hoặc biến "ký hợp đồng" thành chuỗi ký tự vô nghĩa.
Lỗi này không dừng ở tầng đọc văn bản. Khi OCR sai, hệ thống RAG (Retrieval-Augmented Generation) phía sau không ghép đúng ngữ cảnh vector. AI Chatbot vì vậy trả lời sai hoặc báo "không tìm thấy thông tin" cho các câu hỏi nghiệp vụ quan trọng, ví dụ điều khoản hợp đồng hay số tiền trên hoá đơn.
Vấn đề càng rõ hơn với tài liệu thực tế. Phần lớn hoá đơn, hợp đồng và văn bản pháp lý trong vận hành thật là ảnh chụp bằng điện thoại: nghiêng góc, mờ nét, nhăn giấy, hoặc hoá đơn nhiệt phai chữ. Benchmark OCR công bố sẵn thường đo trên ảnh scan sạch, không phản ánh đúng điều kiện này.
Dùng LLM sửa lỗi OCR: giải pháp tưởng hợp lý nhưng là cái bẫy
Cách xử lý phổ biến khi OCR đọc sai là đẩy văn bản lỗi qua một LLM (như GPT-4) để sửa chính tả. Cách này có 3 vấn đề trong bối cảnh doanh nghiệp.
Rủi ro bịa số liệu tài chính. Khi LLM cố "đoán" ký tự bị mất, nó có thể tự đoán sai số tiền hoặc ngày hợp đồng. Với dữ liệu kế toán, đây là rủi ro không chấp nhận được.
Chi phí và độ trễ tăng vọt. Đẩy hàng triệu dòng văn bản lỗi qua LLM chỉ để sửa chính tả làm chi phí API tăng 300-500%, độ trễ mỗi trang tăng từ 0,5 giây lên 5-10 giây.
Rủi ro bảo mật dữ liệu. Gửi dữ liệu hoá đơn chứa thông tin cá nhân qua API bên thứ ba vi phạm các tiêu chuẩn như APPI (Nhật Bản) và GDPR.
Kết luận rút ra: không thể sửa một tầng ingestion hỏng (OCR) bằng cách vá ở tầng output (LLM). Phải can thiệp đúng vào gốc của vấn đề.
Cách VAON đưa độ chính xác từ 70% lên mức không còn lỗi: 4 bước
Trong một dự án thực tế cho khách hàng tài chính - bán lẻ, VAON nhận nhiệm vụ trích xuất tri thức từ hơn 50.000 hoá đơn, hợp đồng và văn bản pháp lý tiếng Việt để nạp vào một AI Chatbot dạng RAG. Bài toán không giải quyết được bằng cách đổi engine OCR khác hay thêm LLM sửa lỗi. VAON xử lý bằng 4 bước sau.
-
Tiền xử lý ảnh chuyên sâu. Xây pipeline lọc nhiễu (denoise), nắn thẳng góc nghiêng (dewarping) và cân bằng tương phản cục bộ (adaptive thresholding) trước khi đưa vào model nhận dạng, làm rõ chữ mờ, ảnh nghiêng và hoá đơn nhiệt phai màu.
-
Fine-tune engine OCR trên đúng dữ liệu nghiệp vụ. Thay vì dùng thẳng model đa ngôn ngữ có sẵn, VAON fine-tune engine OCR 132MB CPU-only độc quyền trên hơn 500.000 mẫu ký tự tiếng Việt thực tế (phông hành chính, hoá đơn bán hàng, biến thể dấu thanh theo vùng miền). Lý do chọn fine-tune riêng: model đa ngôn ngữ tối ưu trung bình cho nhiều ngôn ngữ nên xử lý dấu thanh tiếng Việt kém. Dữ liệu hoá đơn, hợp đồng thật mới bám sát đúng font chữ và bối cảnh nghiệp vụ.
-
Thêm tầng từ điển nghiệp vụ thay vì LLM. VAON xây một tầng lọc dùng thuật toán khoảng cách Levenshtein kết hợp từ điển thuật ngữ tài chính - bán lẻ, tự động sửa từ không hợp lệ theo ngữ cảnh xung quanh. Chọn rule-based thay vì LLM vì rule không bịa số liệu, và mọi lần sửa đều truy được lý do.
-
Khép kín vào pipeline RAG trên hạ tầng CPU. Văn bản đã làm sạch được đưa thẳng vào pipeline RAG để tạo vector embedding chính xác. Toàn bộ hệ thống, từ OCR tới RAG, chạy trên máy chủ CPU tiêu chuẩn, không cần GPU.
Kết quả đo được từ dự án thực tế
Số liệu dưới đây đo trên tập hoá đơn, hợp đồng đã đối soát trong quá trình triển khai dự án (2026), không phải benchmark công bố sẵn của nhà sản xuất model. Không hệ thống OCR hay AI nào đúng tuyệt đối trong mọi trường hợp; đây là kết quả trên một tập dữ liệu cụ thể đã kiểm thử.
| Chỉ số | Trước | Sau | Thay đổi |
|---|---|---|---|
| Độ chính xác trích xuất tri thức | 70% | Không còn lỗi trên tập kiểm thử | Cải thiện rõ rệt |
| Tỷ lệ lỗi dấu thanh/ký tự (baseline commercial OCR) | 25-30% | Đã khắc phục bằng fine-tune + lexicon filter | - |
| Chi phí hạ tầng | Máy chủ GPU | Máy chủ CPU tiêu chuẩn | -80% |
| Xử lý dữ liệu | Có gọi Cloud API bên thứ ba | 100% on-premise | Đáp ứng APPI, GDPR |
Ba giá trị kinh doanh trực tiếp từ kết quả này:
- AI Chatbot trả lời đúng câu hỏi nghiệp vụ phức tạp từ hợp đồng, chính sách và dữ liệu hoá đơn, thay vì báo "không tìm thấy thông tin".
- Mở đường cho ngành có yêu cầu tuân thủ cao như ngân hàng, y tế, nhờ xử lý 100% on-premise.
- Mở hướng OEM/white-label cho agency, SIer muốn đóng gói năng lực xử lý tiếng Việt, tiếng Nhật dưới thương hiệu riêng.
Khi nào cách tiếp cận này chưa đủ
Ba giới hạn cần biết trước khi áp dụng cách làm này cho dự án khác:
Từ điển nghiệp vụ phải xây riêng theo ngành. Tầng lexicon filter ở trên xây cho từ vựng tài chính - bán lẻ. Triển khai sang ngân hàng, y tế cần bổ sung từ điển thuật ngữ riêng trước khi đạt độ chính xác tương đương.
Dữ liệu fine-tune cần bám đúng loại tài liệu thật sẽ gặp. Kết quả trên đo trên phông hành chính, hoá đơn bán hàng, ảnh chụp điện thoại phổ biến trong dự án. Tài liệu ngoài phạm vi này, ví dụ chữ viết tay tự do, chưa được kiểm chứng.
Triển khai on-premise cần hạ tầng CPU nội bộ, không phải gọi thẳng một API cloud có sẵn. Thời gian triển khai ban đầu vì vậy dài hơn tích hợp một API OCR thông thường.
Câu hỏi thường gặp
OCR tiếng Việt sai nhiều hơn tiếng Anh, tiếng Nhật bao nhiêu? Khi kiểm thử engine OCR thương mại phổ biến, tỷ lệ lỗi dấu thanh và ký tự tiếng Việt đạt 25-30%, trong khi tiếng Anh và tiếng Nhật không gặp vấn đề tương tự với cùng engine. Nguyên nhân là hệ thống thanh điệu và nguyên âm biến thể riêng của tiếng Việt.
Vì sao không dùng LLM sửa lỗi OCR cho tiện? Vì LLM có thể tự đoán sai số tiền hoặc ngày hợp đồng khi cố lấp ký tự bị mất, đồng thời làm chi phí API tăng 300-500% và độ trễ mỗi trang tăng lên 5-10 giây. Với dữ liệu tài chính, rủi ro này không chấp nhận được.
Độ chính xác cao hơn có làm tăng chi phí hạ tầng không? Không. Trong dự án này, engine OCR 132MB chạy hoàn toàn trên CPU tiêu chuẩn, không cần GPU, nên chi phí hạ tầng giảm 80% so với phương án dùng GPU cho khối lượng tương đương.
Cách này áp dụng được ngoài ngành tài chính - bán lẻ không? Kiến trúc 4 bước áp dụng được cho ngành khác, nhưng tầng từ điển nghiệp vụ cần xây lại theo thuật ngữ ngành đó (ví dụ ngân hàng, y tế) trước khi đạt độ chính xác tương đương.
Dữ liệu khách hàng có an toàn khi xử lý theo cách này không? Có. Toàn bộ pipeline xử lý 100% on-premise, không gửi dữ liệu ra ngoài qua Cloud API bên thứ ba, đáp ứng các tiêu chuẩn bảo mật như APPI (Nhật Bản) và GDPR.
Kết luận
- OCR thương mại phổ biến sai 25-30% dấu thanh tiếng Việt, khiến AI Chatbot RAG trả lời sai hoặc báo không tìm thấy thông tin.
- Dùng LLM sửa lỗi OCR không phải giải pháp đúng: tốn thêm 300-500% chi phí, tăng độ trễ, và có rủi ro bịa số liệu tài chính.
- VAON xử lý bằng 4 bước ở tầng OCR: tiền xử lý ảnh, fine-tune engine trên dữ liệu thật, tầng từ điển nghiệp vụ, khép kín vào RAG trên hạ tầng CPU. Kết quả: độ chính xác từ 70% lên mức không còn lỗi trên tập kiểm thử, chi phí hạ tầng giảm 80%.
- Cách tiếp cận này cần xây lại từ điển nghiệp vụ khi đổi ngành, và cần hạ tầng CPU nội bộ thay vì gọi thẳng một API cloud có sẵn.
Nếu bạn đang gặp bài toán tương tự với dữ liệu tiếng Việt hoặc tiếng Nhật cho AI Chatbot, RAG, hay OCR tài liệu, đăng ký buổi tư vấn với VAON. Chúng tôi chia sẻ đúng cách đã làm, kể cả những giới hạn hiện tại.