Hậu xử lý OCR là bước biến chữ máy đọc thô thành văn bản dùng được: đưa Unicode về một dạng thống nhất, ghép các dòng bị ngắt thành đoạn, bỏ gạch nối cuối dòng và tiêu đề lặp đầu trang, rồi sửa những lỗi có quy luật như mất dấu, nhầm ơ với o, đ với d. Phần lớn việc này làm được bằng quy tắc đơn giản. Phần còn lại, như chọn giữa "nghỉ" và "nghĩ", cần ngữ cảnh, và đây là chỗ mô hình ngôn ngữ giúp được nhưng cũng dễ bịa nhất.
Thứ tự các bước quan trọng không kém bản thân các bước. Sửa chính tả trước khi ghép dòng sẽ hỏng ở những chữ bị cắt đôi; nhờ AI sửa trước khi chuẩn hoá Unicode thì cùng một chữ có thể bị coi là hai. Bài này đi theo đúng thứ tự nên làm, chỉ ra các loại lỗi điển hình của chữ Việt, và cách giữ để mọi thay đổi đều kiểm lại được.
Bản đồ lỗi: những gì OCR chữ Việt hay làm sai
Trước khi sửa, cần biết mình đang sửa gì. Bảng dưới gom các nhóm lỗi gặp nhiều trong kết quả OCR tiếng Việt; ví dụ là minh hoạ, không trích từ công cụ cụ thể nào.
| Nhóm lỗi | Ví dụ | Nguyên nhân thường gặp | Cách sửa hợp lý |
|---|---|---|---|
| Mất dấu thanh | "mặt" thành "mat" | Ảnh thấp, dấu nặng quá nhỏ | Ngữ cảnh, từ điển; tốt nhất là chụp lại |
| Nhầm dấu thanh | "nghĩ" thành "nghỉ" | Dấu hỏi và ngã giống nhau khi mờ | Chỉ sửa bằng ngữ cảnh, phải duyệt |
| Mất dấu phụ | "ơ" thành "o", "ư" thành "u", "đ" thành "d" | Móc, gạch quá mảnh | Kiểm âm tiết hợp lệ, ngữ cảnh |
| Nhầm khung chữ | "rn" thành "m", "l" thành "1", "O" thành "0" | Phông lạ, chữ dính | Quy tắc theo vị trí: chữ giữa số, số giữa chữ |
| Ngắt dòng | Câu bị cắt thành hai dòng | Máy giữ nguyên dòng vật lý | Ghép dòng theo luật dấu câu |
| Gạch nối cuối dòng | "quốc-" ở cuối dòng, "ngữ" ở dòng sau | Sách báo cũ ngắt chữ bằng gạch | Ghép, nhưng cẩn thận với gạch nối thật |
| Rác bố cục | Số trang, tên sách lặp mỗi trang | Đầu trang, chân trang | Nhận diện chuỗi lặp ở vị trí cố định |
| Sai thứ tự | Cột trái chen cột phải | Phân tích bố cục sai | Sửa ở bước phân vùng, không sửa trên chữ |
Nhìn bảng sẽ thấy một điều: hai nhóm lỗi cuối không nên sửa trên văn bản chữ mà nên sửa ở bước trước, khi máy còn biết toạ độ từng dòng. Cố ghép lại cột bị trộn từ chuỗi chữ thuần gần như luôn tốn công hơn là chạy lại phân vùng trang.
Bước một: chuẩn hoá Unicode và xử lý bảng mã cũ
Một chữ "ế" trong máy tính có thể được lưu theo hai cách: dạng dựng sẵn, một ký tự duy nhất; hoặc dạng tổ hợp, gồm chữ "e" cộng dấu mũ cộng dấu sắc, ba ký tự xếp chồng. Hai dạng trông giống hệt nhau trên màn hình nhưng máy so chuỗi coi là khác. Nếu kết quả OCR trộn cả hai, việc tìm kiếm sẽ trượt, từ điển sẽ báo sai và phép đếm lỗi bị lệch. Bước đầu tiên luôn là đưa toàn bộ văn bản về một dạng; với tiếng Việt, dạng dựng sẵn (NFC) được dùng phổ biến nhất.
Cùng nhóm vấn đề là văn bản cũ soạn bằng các bảng mã trước Unicode, như TCVN3 (thường đi với phông có tên bắt đầu bằng ".Vn") hay VNI. Nếu dự án trộn kết quả OCR với văn bản số có sẵn từ thời đó, phần văn bản cũ cần được chuyển mã sang Unicode trước, bằng các công cụ chuyển mã quen thuộc như chức năng chuyển mã của bộ gõ Unikey. Không chuyển mã, những đoạn này hiện ra thành chuỗi ký tự lạ, và mọi bước sau đều vô nghĩa.
Cũng ở bước này, thống nhất các ký tự "na ná": ngoặc kép thẳng và cong, các loại gạch ngang, khoảng trắng không ngắt dòng, ký tự tab. Mỗi quyết định nên được ghi lại trong một tệp quy ước để lần chạy sau làm giống hệt.
Bước hai: ghép dòng thành đoạn mà không làm hỏng cấu trúc
Dòng kết thúc bằng dấu chấm, chấm hỏi, chấm than, hai chấm thường là hết câu và có thể hết đoạn. Nếu dòng tiếp theo thụt đầu dòng hoặc bắt đầu bằng chữ hoa, khả năng hết đoạn càng cao. Ngược lại, dòng kết thúc giữa câu, không dấu câu, và dòng sau bắt đầu bằng chữ thường, gần như chắc là một câu bị ngắt, cần nối bằng một khoảng trắng.
Gạch nối cuối dòng cần xử lý riêng. Sách báo quốc ngữ cũ hay viết từ ghép có gạch nối, như "quốc-ngữ" hay "Việt-Nam", và cũng có khi ngắt âm tiết ở cuối dòng. Nếu xoá mọi gạch nối cuối dòng, ta mất gạch nối thật của chính tả cũ; nếu giữ hết, văn bản lổn nhổn. Một luật dung hoà: ghép hai mảnh lại, giữ gạch nối, và đánh dấu để người soát quyết định theo quy ước của dự án.
Danh sách, bảng, thơ không được ghép như văn xuôi. Câu thơ lục bát, các dòng của một bảng hay danh sách đánh số đều là ngắt dòng có chủ ý. Cách an toàn là để bước phân tích bố cục gắn nhãn vùng (đoạn văn, bảng, danh sách, thơ, chú thích) và chỉ áp luật ghép dòng cho vùng đoạn văn.
Đầu trang, chân trang và số trang nên được loại trước khi ghép, nếu không chúng sẽ chen vào giữa câu ở chỗ chuyển trang. Dấu hiệu nhận ra: chuỗi giống nhau lặp lại ở cùng vị trí trên nhiều trang, hoặc dòng chỉ gồm một con số nằm sát mép trang. Giữ lại thông tin số trang ở dạng siêu dữ liệu để còn trích dẫn được.
Bước ba: sửa lỗi bằng quy tắc và từ điển âm tiết
Tiếng Việt có một lợi thế hiếm có cho việc sửa lỗi: đơn vị viết là âm tiết, và số âm tiết thực sự dùng chỉ ở mức vài nghìn. Âm tiết lại có cấu trúc chặt: phụ âm đầu, vần, thanh, với những tổ hợp không bao giờ xuất hiện. Không có âm tiết nào kết thúc bằng "x" hay bắt đầu bằng "pr" trong từ thuần Việt; vần "-ăp" không đi với dấu huyền hay dấu hỏi vì âm tiết tắc chỉ mang thanh sắc hoặc nặng. Một bộ lọc dựa trên cấu trúc âm tiết và danh sách âm tiết thực có bắt được nhiều chữ chắc chắn sai, như "nguòi", "đuợc", "truờng".
Từ những âm tiết không hợp lệ đó, máy có thể đề xuất các ứng viên gần nhất: thêm móc cho "o", "u", đổi dấu, thêm gạch cho "d". Nhưng có một giới hạn quan trọng: lỗi biến chữ đúng thành một chữ đúng khác thì bộ lọc âm tiết bó tay. "Mặt" đọc thành "mắt" vẫn hợp lệ; "nghĩ" thành "nghỉ" cũng vậy. Đây là nhóm lỗi nguy hiểm nhất vì vượt qua mọi kiểm tra tự động.
Với nhóm đó, cần xét đến cặp từ, tức nhìn âm tiết đứng trước và sau. "Suy nghỉ" hiếm hơn rất nhiều so với "suy nghĩ"; "nghỉ ngơi" thì ngược lại. Thống kê tần suất cặp từ từ một kho văn bản tiếng Việt sạch cho phép đề xuất sửa với mức tin cậy, nhưng đề xuất vẫn chỉ là đề xuất: tên riêng, từ địa phương và văn phong cũ thường có tổ hợp hiếm mà đúng.
Bước bốn: nhờ mô hình ngôn ngữ sửa, nhưng trói tay nó lại
Mô hình ngôn ngữ lớn rất giỏi đoán chữ đúng từ ngữ cảnh, kể cả với lỗi dấu mà quy tắc không bắt được. Vấn đề là nó cũng giỏi viết lại: thay từ cổ bằng từ hiện đại, chỉnh câu cho trơn, thêm dấu câu, thậm chí bỏ một câu khó hiểu. Với số hoá, mọi thay đổi ngoài sửa lỗi nhận dạng đều là làm sai bản gốc.
Cách giảm rủi ro là ràng buộc rõ trong câu lệnh và kiểm bằng máy sau đó. Ví dụ một câu lệnh mẫu: "Dưới đây là văn bản tiếng Việt do máy nhận dạng từ ảnh, có lỗi dấu và lỗi ký tự. Chỉ sửa lỗi nhận dạng rõ ràng. Không đổi từ ngữ, không đổi chính tả cổ, không thêm bớt câu, không sửa văn phong. Giữ nguyên ngắt dòng. Với mỗi chỗ sửa, liệt kê chữ cũ, chữ mới và lý do ngắn. Chỗ nào không chắc, giữ nguyên và đánh dấu bằng hai dấu hỏi."
Sau đó, so bản trước và sau theo từng âm tiết. Nếu tỷ lệ âm tiết bị thay vượt quá mức lỗi bạn đã đo được ở bước đánh giá, đó là dấu hiệu mô hình đang viết lại chứ không chỉ sửa. Những thay đổi làm đổi số âm tiết, thêm hoặc bớt cả từ, nên bị gắn cờ cho người duyệt. Và nếu tài liệu chứa thông tin cá nhân, đừng gửi lên dịch vụ trực tuyến khi chưa che các trường đó hoặc chưa có thoả thuận xử lý dữ liệu phù hợp.
Quy trình hậu xử lý gọn cho một dự án nhỏ
Ghép các bước trên thành một dây chuyền có thể lặp lại. Mỗi bước sinh ra một tệp riêng, không ghi đè bước trước.
- Lưu kết quả OCR thô kèm toạ độ dòng và độ tin cậy nếu công cụ cung cấp.
- Chuẩn hoá Unicode về NFC, chuyển mã phần văn bản cũ, thống nhất ký tự na ná.
- Gắn nhãn vùng, loại đầu trang, chân trang, tách bảng và thơ khỏi đoạn văn.
- Ghép dòng trong vùng đoạn văn, xử lý gạch nối theo quy ước dự án.
- Chạy bộ lọc âm tiết, sửa tự động những lỗi chỉ có một ứng viên hợp lý, gắn cờ phần còn lại.
- Nếu dùng mô hình ngôn ngữ, chỉ cho nó xử lý đoạn đã gắn cờ, với câu lệnh ràng buộc như trên.
- Người duyệt xem các chỗ gắn cờ cạnh ảnh gốc, ưu tiên tên riêng, số liệu, ngày tháng.
- Đo lại CER trên bộ trang chuẩn để biết hậu xử lý đã giảm lỗi bao nhiêu, và có tạo lỗi mới không.
Bước cuối hay bị bỏ qua nhưng quan trọng: hậu xử lý có thể làm hại. Một quy tắc ghép dòng quá hăng có thể dán hai đoạn vào nhau; một mô hình quá nhiệt tình có thể "hiện đại hoá" cả trang. Chỉ có phép đo trên bản chuẩn mới cho biết điều đó.
Giữ dấu vết: mọi chỗ sửa đều phải truy ngược được
Văn bản số hoá thường được dùng lại nhiều năm, bởi những người không tham gia dự án. Họ cần biết đoạn nào là máy đọc, đoạn nào người đã soát, chữ nào đã bị sửa và ai sửa. Cách đơn giản nhất là lưu song song bản thô, bản đã sửa và một tệp ghi các thay đổi, thay vì chỉ giữ bản cuối.
Với dự án lớn hơn, các định dạng như hOCR hay ALTO lưu được chữ cùng toạ độ trên ảnh và độ tin cậy, nên có thể hiện chữ đè lên ảnh để người đọc tự đối chiếu. Đây cũng là nền để tạo PDF có lớp chữ tìm kiếm được, nơi người dùng bôi đen một đoạn sẽ thấy đúng vị trí trên trang gốc.
Thói quen này còn giúp cải tiến chính công cụ: những cặp lỗi và sửa đã được người duyệt xác nhận là dữ liệu quý để tinh chỉnh bộ nhận dạng hoặc bộ sửa lỗi cho đúng loại tài liệu của bạn, miễn là bạn có quyền dùng tài liệu đó cho mục đích này.
Câu hỏi thường gặp
Có nên để AI sửa toàn bộ kết quả OCR một lượt cho nhanh?
Với tài liệu để đọc tham khảo cá nhân thì có thể, nhưng với tài liệu cần trích dẫn hoặc lưu trữ thì không nên. Mô hình có xu hướng làm mượt câu chữ, thay từ cổ và đôi khi bỏ đoạn khó. Cách an toàn là sửa bằng quy tắc trước, chỉ đưa các đoạn bị gắn cờ cho mô hình, và luôn so trước sau.
Vì sao văn bản trông đúng nhưng tìm kiếm không ra từ có dấu?
Nguyên nhân hay gặp nhất là văn bản trộn hai dạng Unicode: dựng sẵn và tổ hợp. Trên màn hình chúng giống nhau nhưng máy so chuỗi coi là khác. Đưa toàn bộ văn bản và cả chỉ mục tìm kiếm về cùng dạng NFC thường giải quyết được.
Làm sao phân biệt gạch nối ngắt dòng với gạch nối chính tả cũ?
Không có luật nào đúng tuyệt đối. Nếu hai mảnh ghép lại thành một âm tiết hợp lệ, đó thường là ngắt âm tiết và nên ghép liền. Nếu mỗi mảnh đã là một âm tiết trọn vẹn, có thể là từ ghép viết gạch nối theo lối cũ. Dự án nên chọn một quy ước, ghi lại và đánh dấu các trường hợp nghi ngờ.
Bộ lọc âm tiết có bắt được lỗi nhầm hỏi ngã không?
Thường là không, vì cả hai dạng đều là âm tiết hợp lệ. Muốn bắt cần xét ngữ cảnh: thống kê cặp từ hoặc mô hình ngôn ngữ. Ngay cả khi đó, đề xuất sửa vẫn cần người duyệt với tên riêng, từ địa phương và văn bản cũ, nơi tổ hợp hiếm vẫn có thể đúng.
Nên lưu kết quả cuối ở định dạng nào?
Tuỳ mục đích. Văn bản thuần mã hoá UTF-8 tiện cho tìm kiếm và xử lý ngôn ngữ. Nếu cần giữ liên kết với ảnh gốc, nên lưu thêm hOCR hoặc ALTO kèm toạ độ, và PDF có lớp chữ cho người đọc. Dù chọn gì, giữ bản thô và nhật ký sửa để còn kiểm lại.
Hậu xử lý có thay được việc chụp lại ảnh tốt hơn không?
Chỉ một phần. Hậu xử lý sửa được lỗi có quy luật, nhưng khi ảnh mất hẳn dấu, máy chỉ còn đoán. Nếu đo thấy lỗi dấu chiếm phần lớn và tài liệu gốc vẫn còn, chụp hoặc quét lại ở độ phân giải cao hơn thường rẻ và đáng tin hơn mọi bước sửa.