OCR API là gì: cách tích hợp nhận dạng tài liệu vào hệ thống, hướng dẫn đầy đủ

OCR API là giao diện cho phép lập trình viên gửi ảnh hoặc tệp tài liệu theo đặc tả quy định, rồi nhận lại văn bản đã nhận dạng, vị trí và độ tin cậy của từng giá trị dưới dạng phản hồi có cấu trúc, và có thể kết nối trực tiếp với hệ thống của doanh nghiệp.

Vì sao cần OCR API

Chỉ hiển thị kết quả trên màn hình thì công việc không giảm đi.

Có những trường hợp sau khi đưa công cụ nhận dạng tài liệu vào, khối lượng việc của người phụ trách vẫn không đổi. Kết quả nhận dạng hiện trên một màn hình riêng, và người phụ trách phải xem luân phiên màn hình đó với hệ thống nghiệp vụ rồi nhập lại giá trị. Quy trình gốc là đọc ở một cửa sổ và nhập vào cửa sổ khác vẫn còn nguyên. Điều này gần như chỉ thêm một bước kiểm tra chứ không phải tự động hóa.

Để kết quả nhận dạng chảy được vào hệ thống hiện có, nó phải ở dạng chương trình có thể nhận, chứ không phải dạng người đọc. OCR API là kênh đó. Khi gửi tài liệu đi, các giá trị, vị trí và độ tin cậy được trả về dưới dạng dữ liệu có cấu trúc, và dữ liệu đó được chuyển thẳng sang hệ thống thẩm định hoặc hệ thống quản lý tài liệu.

Định nghĩa chính xác của OCR API: khác gì với triển khai nội bộ

Tích hợp API và triển khai nội bộ, ba trục khác biệt

Thứ nhất, đối tượng khác nhau. Tích hợp API chỉ nhắm vào chức năng nhận dạng. Chỉ cần khớp đặc tả yêu cầu và phản hồi, không quan tâm mô hình chạy ở đâu và như thế nào. Triển khai nội bộ nhắm vào mô hình, môi trường suy luận, kho lưu trữ và công cụ vận hành. Nó gần giống việc dựng một hệ thống hoàn chỉnh bên trong doanh nghiệp khách hàng.

Thứ hai, mục tiêu khác nhau. Mục tiêu của tích hợp API là kết nối nhanh và kiểm tra hiệu năng cùng mức độ phù hợp. Trong giai đoạn kiểm chứng ban đầu, chỉ cần vài ngày để gửi một số loại tài liệu và nhận kết quả. Mục tiêu của triển khai nội bộ là xử lý được khối lượng ở quy mô vận hành mà không đưa tài liệu gốc ra ngoài.

Thứ ba, chỉ số đánh giá khác nhau. Với tích hợp API, người ta xem độ chính xác của phản hồi, độ trễ và giới hạn thông lượng. Với triển khai nội bộ, ngoài các chỉ số đó còn xem thêm thông số GPU cần thiết, khả năng cài đặt trong mạng kín, quy trình cập nhật mô hình và yêu cầu nhật ký kiểm toán. Trong vận hành thực tế, đã có trường hợp xác nhận được độ chính xác nhận dạng của phương thức API, đồng thời đo được thời gian xử lý theo lô và thông lượng theo giờ.

Hai phương thức không thay thế nhau. Thông thường, kiểm chứng ban đầu được thực hiện nhanh bằng API, rồi chuyển sang triển khai nội bộ ở giai đoạn vận hành. Vì vậy, điều cần xác nhận ở giai đoạn đánh giá không chỉ là hiệu năng của API, mà còn là việc cùng một công cụ có được cung cấp dưới dạng triển khai nội bộ hay không.

Sáu điều kiện để đưa OCR API vào nghiệp vụ

Sáu điều kiện của OCR API khi tích hợp thực tế

Thứ nhất, lược đồ phản hồi phải được định nghĩa theo tiêu chuẩn nghiệp vụ. Phản hồi chỉ trả về một chuỗi văn bản lớn thì không thể tự động hóa việc nhập liệu vào hệ thống. Cần định nghĩa trước theo từng loại tài liệu: giá trị nào nằm ở khóa nào, để phía nhận có thể phát triển.

Thứ hai, giá trị phải đi kèm vị trí và độ tin cậy. Nếu mỗi giá trị có tọa độ trong bản gốc và mức độ chắc chắn đi kèm, có thể chỉ hiển thị các mục có độ tin cậy thấp lên màn hình kiểm tra. Nếu thiếu hai trường này, cuối cùng vẫn phải kiểm tra toàn bộ.

Thứ ba, định dạng hỗ trợ phải bao phủ tệp tiếp nhận thực tế. Tại hiện trường nghiệp vụ, không chỉ có PDF và ảnh. Tài liệu HWP, tài liệu văn phòng, bảng tính và ảnh quét cũng được tiếp nhận cùng lúc. Cần xác nhận danh sách hỗ trợ có bao gồm các định dạng này hay không.

Thứ tư, phải có đường xử lý khối lượng lớn. Nếu chỉ cung cấp lệnh gọi đồng bộ từng tài liệu thì không thể đáp ứng khối lượng dồn vào cuối tháng hoặc vào một khung giờ nhất định. Cần xác nhận có sẵn xử lý theo lô, truy vấn trạng thái công việc và callback thông báo khi hoàn tất hay không.

Thứ năm, phải có xác thực và quản lý quyền truy cập. Tài liệu chứa thông tin cá nhân nên cần cấp và thu hồi khóa, ghi lại lịch sử gọi và kiểm soát truy cập theo vai trò. Trong tài chính và khu vực công, nhật ký này được yêu cầu để đáp ứng kiểm toán.

Thứ sáu, phải kiểm tra việc có cung cấp song song phiên bản triển khai nội bộ hay không. Hiện tại API có thể đã đủ, nhưng khi yêu cầu bảo mật tăng hoặc khối lượng xử lý lớn lên, sẽ cần cài đặt nội bộ. Khi đó, tiêu chí quan trọng để quyết định là có thể không phải thay thế toàn bộ công cụ hay không.

Cách áp dụng OCR API trong thực tế

Xác định điểm tích hợp trước

Quyết định đầu tiên khi thiết kế là kết quả nhận dạng sẽ được đưa vào đâu. Tùy theo việc sẽ lưu cùng bản gốc vào hệ thống quản lý tài liệu, đưa thẳng vào các mục nhập của hệ thống thẩm định, hay chuyển qua công cụ tự động hóa đến hệ thống nghiệp vụ cốt lõi, mà định dạng phản hồi cần thiết sẽ khác nhau.

Trong cấu hình vận hành thực tế, luồng phổ biến là kết quả nhận dạng được lưu vào hệ thống quản lý tài liệu, rồi qua công cụ tự động hóa để đăng ký vào hệ thống nghiệp vụ cốt lõi. Nếu kết nối này không được thiết kế, nhân viên phụ trách sẽ phải nhập lại kết quả. Vì vậy, nên xác định điểm tích hợp trước khi kiểm chứng hiệu năng nhận dạng.

Thống nhất đặc tả yêu cầu và phản hồi

Cấu hình điển hình là kết hợp giữa yêu cầu tải tệp lên và phản hồi có cấu trúc. Khi gửi tài liệu, kết quả được tạo ra qua chuyển đổi định dạng, phân tích bố cục, nhận dạng ký tự và hậu xử lý, rồi văn bản, thông tin vị trí và độ tin cậy được trả về cùng nhau. Nên nhận kết quả theo từng mục đích. Nếu mục đích là đưa vào hệ thống thì nhận dữ liệu có cấu trúc với đường dẫn mục làm khóa; nếu là tài liệu để tìm kiếm và sinh nội dung thì nhận dạng đánh dấu có giữ nguyên cấu trúc.

Với xử lý khối lượng lớn, cách ổn định là đăng ký yêu cầu theo từng công việc và truy vấn trạng thái. Dùng thêm callback thông báo lúc hoàn tất sẽ giảm gánh nặng polling cho phía nhận.

OCR API trong bối cảnh Hàn Quốc

Nhiều tổ chức tài chính và khu vực công Hàn Quốc chịu sự điều chỉnh của quy định phân tách mạng. Vì không thể gọi API bên ngoài trong mạng nghiệp vụ, các giải pháp chỉ cung cấp dịch vụ API đám mây công cộng thường bị loại ngay từ đầu. Cần xác nhận trước khả năng dựng máy chủ API trong mạng nội bộ.

Điều kiện cũng có yếu tố riêng của Hàn Quốc về định dạng tài liệu. Cần xác nhận bằng tệp thực tế xem tài liệu HWP có nằm trong đối tượng xử lý thực tế không, và chất lượng phản hồi có được giữ với bản quét fax độ phân giải thấp tiếp nhận được hay không. Kết quả đo bằng tài liệu mẫu công khai khác với kết quả đo bằng tài liệu trong hộp tiếp nhận của chính doanh nghiệp.

Xác định cách xử lý lỗi và thử lại

Với tích hợp, phần xử lý thất bại tốn nhiều công sức hơn đường thành công. Trường hợp tệp không mở được, định dạng không được hỗ trợ, trang trống, hay quá thời gian xử lý, mỗi trường hợp đòi hỏi cách ứng phó khác nhau.

Khi thiết kế, cần quyết định ba điều. Trước hết, phân biệt lỗi nào có thể giải quyết bằng thử lại. Tài nguyên tạm thời thiếu thì gửi lại là được, nhưng định dạng không hỗ trợ thì gửi bao nhiêu lần cũng cho kết quả giống nhau. Tiếp theo, quyết định khoảng cách và số lần thử lại. Cuối cùng, quyết định nơi lưu các trường hợp không được giải quyết ngay cả khi đã thử lại. Nếu không có hàng đợi này, tài liệu thất bại sẽ lặng lẽ biến mất.

Cũng cần kiểm tra xem mã lỗi có được phân biệt theo nguyên nhân hay không. Nếu mọi thất bại đều trả về cùng một mã, phía nhận sẽ không có cách nào tách biệt cách ứng phó.

Tách môi trường kiểm chứng và môi trường vận hành

Nếu cùng một khóa xác thực được cấp để dùng cho cả kiểm chứng lẫn vận hành, sẽ phát sinh vấn đề. Tài liệu thử nghiệm gửi trong lúc kiểm chứng sẽ lẫn vào thống kê vận hành, và trong lúc sửa tích hợp, lệnh gọi vận hành có thể bị gián đoạn.

Tách khóa và phân tách địa chỉ đích gọi sẽ ngăn được các sự cố này. Ngoài ra, nên quy định trong môi trường kiểm chứng dùng mẫu đã được che thông tin thay cho tài liệu chứa thông tin cá nhân thực. Nhật ký ở giai đoạn kiểm chứng thường có kiểm soát truy cập lỏng lẻo hơn so với vận hành.

Cũng cần tách thời điểm triển khai. Nếu tiêu chí trích xuất hoặc lược đồ phản hồi thay đổi, hãy tạo luồng kiểm tra trước trong môi trường kiểm chứng, rồi đưa vào vận hành sau khi qua phê duyệt, để thay đổi không dẫn đến sự cố.

Kiểm tra giới hạn xử lý và đơn vị tính phí

Một mục thường bị bỏ sót khi đánh giá là giới hạn. Cần xác nhận có giới hạn về số lệnh gọi mỗi giây, số việc xử lý đồng thời, hay số trang trong một yêu cầu không. Với nghiệp vụ mà khối lượng dồn vào cuối tháng hoặc một khung giờ nhất định, giới hạn này quyết định tốc độ xử lý thực tế.

Cũng cần xem đơn vị tính phí. Tính phí theo số yêu cầu hay theo số trang khiến việc dự đoán chi phí khác nhau rất nhiều. Với nghiệp vụ thẩm định mà mỗi hồ sơ có mười lăm trang, sự khác biệt giữa hai cách tính có thể lên tới hơn mười lần.

Với phương thức triển khai nội bộ, giới hạn không do hợp đồng mà do phần cứng quyết định. Trong trường hợp này, nên kiểm tra trước quy mô bộ tăng tốc cần thiết và phương án mở rộng.