Trao cho các Agent "Đôi mắt tại chỗ": Hướng dẫn thực tế về OCR trên trình duyệt với PP-OCRv6

Baidu Paddle gần đây đã chính thức phát hành thế hệ mô hình OCR tiếp theo, PP-OCRv6.

Nó giới thiệu ba kích thước mô hình—Tiny, Small và Medium—hỗ trợ hơn 50 ngôn ngữ và bao phủ mọi tình huống từ trình duyệt và thiết bị nhúng đến máy chủ.

Dữ liệu cốt lõi:

• Điểm số tác vụ phát hiện và nhận dạng văn bản: 86,2 và 83,2
• Đứng #1 toàn cầu về hiệu suất OCR toàn diện (phát hiện + nhận dạng), dẫn trước các mô hình ngôn ngữ-thị giác tổng quát như Qwen3-VL-235B, GPT-5.5 và Gemini-3.1-Pro
• Mô hình Tiny chỉ 1,5MB, với dự đoán một ảnh trong 97ms (CPU), có khả năng chạy trong môi trường trình duyệt
• Đã được tích hợp vào các công cụ như UmiOCR và MinerU, với hơn 82.200 Sao GitHub

Tôi đã thử nghiệm nó với ba hình ảnh "khó như địa ngục" để xem nó có thể đi xa đến đâu.

Điều gì xảy ra nếu tỷ lệ nhận dạng OCR của bạn chỉ là 68%?

Hãy tưởng tượng một tình huống:

Một hợp đồng tài chính với các điều khoản tiếng Trung và tiếng Anh đan xen, số tiền bằng số và thuật ngữ pháp lý.

Bạn chạy OCR bằng Tesseract và tỷ lệ nhận dạng là 68%.

Một phần ba nội dung bị sai.

Việc phân tích LLM, trích xuất rủi ro và lưu trữ tự động sau đó đều hoạt động mù quáng dựa trên dữ liệu không chính xác.

Đây không phải là vấn đề của bản thân Tesseract.

Đó là tình trạng khó khăn chung của OCR mã nguồn mở truyền thống: trong các bố cục phức tạp (công thức, bảng biểu, con dấu, đa ngôn ngữ), tỷ lệ nhận dạng văn bản thường giảm xuống dưới 70%. trích dẫn

Tệ hơn nữa, bạn có thể nghĩ: "Sao không dùng GPT-5.5 cho OCR?"

Với 235B tham số, mất 2 giây để nhận dạng một hình ảnh trên GPU hiệu suất cao, phải trả phí và độ chính xác chỉ ở mức trung bình.

PP-OCRv6 đã làm gì?

Mô hình Tiny chỉ 1,5MB và hoàn thành trong 97ms ở phía trình duyệt (CPU). Mô hình Medium có 34,5M tham số, độ chính xác nhận dạng OCR 90%+, và vượt qua GPT-5.5 cùng tất cả OCR mã nguồn mở truyền thống về phát hiện và nhận dạng văn bản.

Dữ liệu không biết nói dối:

Khoảng cách 10-20 điểm phần trăm này là sự khác biệt giữa "có thể dùng được" và "không thể dùng được."

Tôi đã thử nghiệm ba hình ảnh "khó như địa ngục"; đây là kết quả.

Thử nghiệm 1: Nền tối + Chữ nhỏ dày đặc

Đây là thử thách khó nhất của OCR.

Tôi lấy một poster phong cách công nghệ để thử nghiệm—nền neon tối, bảng dữ liệu phát sáng, hỗn hợp tiếng Trung-Anh dày đặc và nhiều cỡ chữ khác nhau lộn xộn.

Loại hình ảnh này là nơi nhiều OCR thất bại thảm hại.

Kết quả thử nghiệm:

✅ Tiêu đề chính "Mastering Codex", "Master 97% functions in 30 minutes" — Phông chữ phát sáng, không thiếu một ký tự nào

✅ Nhãn nhỏ "14 steps", "Skills", "MCP Connection" — Chữ nhỏ trên nền tối, tất cả đều được khôi phục

✅ Các số liệu thống kê "98%", "1200+", "85%" — Không thiếu cái nào

✅ Chi tiết dưới cùng như "Efficient Intelligent Data Processing Capability" — Ngay cả cỡ chữ nhỏ nhất cũng được nhận dạng

✅ Hỗn hợp tiếng Trung-Anh, hoàn thành trong một lần với một mô hình duy nhất

Tốc độ nhận dạng:

Nhận dạng trực tuyến mất khoảng 1-2 giây (bao gồm thời gian tải lên mạng)

Kết luận: Nền phức tạp + hiệu ứng phát sáng + chữ siêu nhỏ + hỗn hợp tiếng Trung-Anh; nó xử lý đồng thời cả bốn khó khăn. "Tầm nhìn" của nó thực sự đủ tốt để làm mắt cho một Agent.

Thử nghiệm 2: Hóa đơn tài chính

Đây là một tình huống kinh doanh thực tế.

Tiếp theo, tôi thử nghiệm một hóa đơn GTGT—yêu cầu OCR phổ biến nhất đối với doanh nghiệp và là tình huống mà dữ liệu chắc chắn không thể gửi ra ngoài.

Hiệu quả nhận dạng:

✅ Mã/Số hóa đơn 031002200711, 59905674 — Phông chữ siêu nhỏ, chính xác 100%

✅ Chuỗi số phức tạp 1+3-887•97•-9642-6-62967770 — Chuỗi dài với các ký hiệu đặc biệt, không một lỗi nào

✅ Các con số tiền tệ ¥535,00, ¥504,72, ¥30,28, Thuế suất 6% — Nhận dạng chính xác

✅ Chuỗi ký tự ngẫu nhiên dài trong khu vực mật khẩu — Được khôi phục hoàn toàn

✅ Tên người mua/người bán, mã số thuế, địa chỉ và số điện thoại — Tất cả đều đúng

✅ Văn bản bên trong con dấu đỏ cũng được nhận dạng (ngay cả với sự can thiệp của vòng tròn đỏ)

Điều đáng ngạc nhiên nhất:

Những cỡ chữ cực kỳ nhỏ trên hóa đơn (có lẽ chỉ 8-10 point), số dày đặc và ký hiệu đặc biệt (•, -, +) đều được PP-OCRv6 nhận dạng chính xác. Mức độ chính xác này không thể đạt được đối với OCR truyền thống.

Khám phá chính: Khả năng trích xuất cấu trúc

Nó có thể trả về vị trí tọa độ của từng trường, nghĩa là bạn có thể trực tiếp thực hiện trích xuất có cấu trúc:

1// Determine field type based on coordinate position
2results.forEach(item => {
3  if (item.box.y < 100) {
4    // Top area → Invoice code/number
5  } else if (item.text.includes('¥')) {
6    // Contains currency symbol → Amount field
7  }
8});

Khả năng này cho phép PP-OCRv6 không chỉ "nhìn thấy văn bản" mà còn "hiểu cấu trúc tài liệu." Đây là một bước quan trọng từ OCR đến Document AI.

Thử nghiệm 3: Ghi chú viết tay

Đến lúc kiểm tra căng thẳng.

Cuối cùng, tôi đã thử nghiệm một ghi chú viết tay—một thách thức OCR truyền thống. Chữ viết tay lộn xộn, các nét nối liền và các nếp gấp trên giấy.

Kết quả thử nghiệm:

✅ Nhận dạng ngày tháng "August 30, 2025" — Hoàn toàn chính xác

✅ Nội dung chính viết tay "Stayed at home all day today, missed dancing twice" — Ngay cả chữ "那" viết lộn xộn cũng được nhận dạng

✅ Danh sách cải tạo được nhận dạng đầy đủ:

• "Hard decoration 109k," "3 ACs: 26k," "3 Glass: 11.5k"
• "Appliances 180k," "Water heater: 3000"
• "Stove/Hood: 7000," "Washer/Dryer: 5000"
• "Fridge 3000" ✅ Các số phức tạp "Sent 44k today (including fridge)," "Current: 214.5k" — Số viết tay và số tiền đều được nhận dạng đúng

Đánh giá tỷ lệ nhận dạng:

• Chữ viết tay gọn gàng: ~90% tỷ lệ nhận dạng
• Thông tin chính (ngày tháng, tên dự án, số tiền): Gần như 100%
• Phần chữ thảo lộn xộn: Tỷ lệ nhận dạng ~70-80%, nhưng không ảnh hưởng đến hiểu biết tổng thể

Phát hiện bất ngờ:

Ngay cả với chữ viết tay, PP-OCRv6 có khả năng nhận dạng mạnh mẽ đối với thông tin có cấu trúc (ngày tháng, số tiền, danh sách). Điều này có nghĩa là nó có thể được sử dụng cho các biểu mẫu viết tay, hóa đơn và ghi chú cuộc họp—nó không cần phải chính xác 100% miễn là nó bắt được các trường chính.

Kết luận:

PP-OCRv6 không phải là vạn năng; chữ viết tay cực kỳ lộn xộn vẫn là một thách thức. Tuy nhiên, đối với chữ viết tay gọn gàng, văn bản in, ảnh chụp màn hình rõ ràng và bản scan, hiệu suất của nó đã đạt đến cấp độ thương mại.

Những tình huống nào phải được bản địa hóa?

Các tình huống ứng dụng của PP-OCRv6 bao gồm văn phòng doanh nghiệp, chăm sóc sức khỏe, giáo dục/nghiên cứu, công cụ dành cho nhà phát triển, lưu trữ chính phủ, thương mại điện tử và tài chính/bảo hiểm.

Dưới đây là một vài tình huống điển hình.

💼 Văn phòng doanh nghiệp: Hoàn trả chi phí tự động

Một công ty dược phẩm đã giảm thời gian hoàn trả chi phí đi lại từ 5,3 ngày xuống còn 4,2 giờ sau khi nhúng PP-OCR. trích dẫn

Quy trình:

Nhân viên tải lên hóa đơn → Trích xuất trường ở phía trình duyệt (số tiền, ngày tháng, người bán) → Xác thực quy tắc → Ngoại lệ gửi đến LLM → Nhập tự động.

Tại sao phải bản địa hóa?

Chứng từ tài chính chứa dữ liệu hoạt động như nhà cung cấp, giá cả và cấu trúc chi phí; tải lên API của bên thứ ba là một đường ranh giới đỏ về tuân thủ. Bản địa hóa giữ dữ liệu trong trình duyệt.

🏥 Chăm sóc sức khỏe: Hồ sơ y tế điện tử

Hồ sơ y tế chứa quyền riêng tư của bệnh nhân (tên, ID, tình trạng bệnh) và không thể tải lên đám mây công cộng.

So sánh giải pháp:

• Triển khai riêng tư truyền thống: Chi phí cao, bảo trì nặng nề
• PP-OCRv6 phía trình duyệt: Chạy trực tiếp, không tốn chi phí máy chủ

Quy trình:

Máy quét tải lên hình ảnh hồ sơ y tế → Nhận dạng OCR cục bộ → Dữ liệu được lưu trữ sau khi ẩn danh. Dữ liệu gốc không bao giờ rời khỏi máy tính của người vận hành.

⚖️ Hợp đồng pháp lý: Bảo vệ bí mật thương mại

Trợ lý AI của công ty luật cần trích xuất các điều khoản hợp đồng (các bên, số tiền, điều khoản, trách nhiệm). Nhưng hợp đồng là bí mật thương mại cốt lõi của khách hàng.

Quy trình bản địa hóa:

Tải lên bản scan hợp đồng → OCR phía trình duyệt trích xuất toàn bộ văn bản → LLM cục bộ thực hiện trích xuất điều khoản → Tạo báo cáo đánh giá. Dữ liệu không bao giờ rời khỏi máy trạm của luật sư, đáp ứng các thỏa thuận bảo mật luật sư-khách hàng.

Trong tình huống này, bản địa hóa là sự khác biệt giữa "có thể" và "không thể."

Phản hồi thực tế:

Một nhà phát triển công ty luật đã báo cáo sau khi nâng cấp lên PP-OCRv6: "Tốc độ và hiệu quả thực sự tốt hơn nhiều so với V5." Nó được sử dụng trực tiếp để làm sạch định dạng và ẩn danh các tệp vụ án. trích dẫn

💻 Công cụ dành cho nhà phát triển: Ảnh chụp màn hình thành văn bản

Các nhà phát triển thường cần trích xuất văn bản từ bản thiết kế, tài liệu hoặc nhật ký. API đám mây có độ trễ mạng (200-500ms), giới hạn cuộc gọi và các đoạn mã không phù hợp để truyền ra bên ngoài.

Trải nghiệm bản địa hóa:

Ảnh chụp màn hình → Phím tắt → Nhận dạng cục bộ → Dán. Toàn bộ quá trình mất 200ms mà không cần internet. OCR thay đổi từ "chờ API" thành "nhấn phím tắt," trở thành một phần của quy trình làm việc.

📚 Thêm nhiều tình huống

Giáo dục/Nghiên cứu: Hỗ trợ chấm điểm, số hóa tài liệu học thuật, sắp xếp ghi chú viết tay.

Lưu trữ Chính phủ: Số hóa tài liệu lịch sử, trích xuất thông tin CMND, luân chuyển tài liệu.

Thương mại điện tử: Nhập thông tin sản phẩm, nhận dạng tài liệu hậu cần, xác minh hóa đơn.

Tài chính/Bảo hiểm: Trích xuất thông tin chính sách, nhận dạng hóa đơn ngân hàng, xử lý tài liệu quản lý rủi ro.

Một Vòng lặp Agent bản địa hóa hoàn chỉnh

Giá trị của PP-OCRv6 không chỉ là "nhận dạng chính xác." Đó là "bước nhận dạng này không cần internet."

Chạy trong trình duyệt có nghĩa là bạn có thể xây dựng một vòng lặp dữ liệu không bao giờ rời khỏi cục bộ:

1Local Image/Screenshot
2   ↓
3PP-OCRv6 (Browser-side, 97ms)   ← Data does not leave this machine
4   ↓
5Structured Text
6   ↓
7Local LLM / Local Rule Processing
8   ↓
9Auto-categorization / Form Filling / Storage

Trong vòng lặp này, cả hình ảnh và kết quả nhận dạng đều ở trên thiết bị của người dùng. Đối với các tình huống liên quan đến chứng từ nhạy cảm, điều này không chỉ "tốt hơn," mà là sự khác biệt giữa "có thể" và "không thể."

Trước đây, các yêu cầu như vậy đòi hỏi triển khai riêng tư đắt đỏ; bây giờ, bạn chỉ cần mở trình duyệt và chạy nó.

Đây là ý nghĩa thực sự của việc "cho Agent đôi mắt cục bộ": Agent cuối cùng cũng có thể "nhìn thấy," và quá trình nhìn thấy không yêu cầu cho người khác mượn mắt của chúng.

Cách sử dụng? Ba phương pháp tích hợp

Phương pháp 1: Trải nghiệm trực tuyến (0 phút để bắt đầu)

Cách nhanh nhất là truy cập paddleocr.com và tải lên một hình ảnh để xem hiệu quả.

Phù hợp cho: Nhanh chóng xác minh khả năng, thử nghiệm hình ảnh cụ thể.

Hạn chế: Dữ liệu được tải lên máy chủ, không phù hợp cho nội dung nhạy cảm.

Phương pháp 2: Tích hợp phía trình duyệt (Được khuyến nghị)

Đối với các ứng dụng web yêu cầu bản địa hóa, hãy tích hợp trực tiếp PaddleOCR.js:

1// 1. Install
2npm install paddleocr-js
3
4// 2. Initialize model
5import { createOCR } from 'paddleocr-js';
6const ocr = await createOCR({
7  detPath: '/models/det_tiny.onnx', 
8  recPath: '/models/rec_tiny.onnx',
9  dictPath: '/models/dict.txt'
10});
11
12// 3. Recognize image
13const results = await ocr.recognize(imageElement);

Lợi ích chính:

• Các tệp mô hình tải một lần; nhận dạng tiếp theo không cần mạng.
• Nhận dạng một hình ảnh bắt đầu từ 97ms (CPU, dữ liệu chính thức).
• Hỗ trợ trả về tọa độ từng ký tự để khôi phục bố cục chi tiết.

Phù hợp cho: Tiện ích mở rộng trình duyệt, ứng dụng Web, ứng dụng desktop Electron. trích dẫn

Phương pháp 3: Triển khai Python cục bộ (Các tình huống độ chính xác cao)

Đối với các tình huống yêu cầu độ chính xác tối đa hoặc xử lý hàng loạt, hãy sử dụng Python SDK:

1# 1. Install
2pip install paddleocr paddlepaddle
3
4# 2. Use medium version for highest precision
5from paddleocr import PaddleOCR
6ocr = PaddleOCR(use_angle_cls=True, lang='ch')
7
8# 3. Batch recognition
9result = ocr.ocr('invoice.jpg', cls=True)

Cách chơi nâng cao:

• Kết hợp với các mô hình NER để trích xuất trường.
• Kết nối với các LLM cục bộ để xây dựng các Agent hiểu tài liệu hoàn chỉnh.
• Bọc bằng FastAPI như một API nội bộ để chia sẻ nhóm.

Phù hợp cho: Xử lý hàng loạt phía máy chủ, yêu cầu độ chính xác cao, phát triển thứ cấp. trích dẫn

Đi sâu kỹ thuật: Tại sao mô hình OCR 34,5M lại chính xác hơn mô hình tổng quát 235B?

Trong một kỷ nguyên mà các mô hình lớn có hàng trăm tỷ tham số, PP-OCRv6 đạt được độ chính xác cao hơn Qwen3-VL-235B, GPT-5.5 và Gemini-3.1-Pro chỉ với 34,5M tham số. Bằng cách nào?

Cơ sở hợp nhất: Một kiến trúc cho hai nhiệm vụ

Cải tiến cốt lõi của PP-OCRv6 là mạng xương sống LCNetV4, được sử dụng cho cả phát hiện và nhận dạng.

Sự khác biệt nằm ở cách xử lý:

• Phát hiện: Thay đổi kích thước hình ảnh bình thường để trích xuất đặc trưng và xác định vị trí văn bản.
• Nhận dạng: Nén chiều cao trong khi giữ nguyên chiều rộng, biến hình ảnh văn bản thành một chuỗi để đọc từng ký tự.

Cùng một mã kiến trúc phục vụ ba kích thước (Tiny/Small/Medium), giảm đáng kể chi phí phát triển và bảo trì.

Tại sao nó quan trọng: Thiết kế "cơ sở hợp nhất" này nhẹ hơn và mạnh hơn so với các mạng độc lập kép truyền thống.

Phát hiện chính xác hơn: Kim tự tháp đặc trưng trường nhận thức lớn

PP-OCRv6 sử dụng kim tự tháp đặc trưng trường nhận thức lớn, mở rộng "phạm vi xem" từ 3x3 lên 7x7.

Hiệu quả: Ít tham số hơn, nhưng cải thiện đáng kể việc phát hiện văn bản nhỏ và dày đặc.

Nhận dạng mạnh mẽ hơn: Chú ý nhẹ + 50 ngôn ngữ trong một mô hình

Phần nhận dạng thêm một mô-đun chú ý nhẹ để hiểu ngữ cảnh giữa các ký tự, trong khi từ điển được mở rộng thêm khoảng 200 ký tự có dấu.

Đột phá chính: Một mô hình duy nhất có thể nhận dạng tiếng Trung, tiếng Anh, tiếng Nhật và 46 ngôn ngữ dựa trên Latin—tổng cộng 50 ngôn ngữ—mà không cần chuyển đổi mô hình cho mỗi ngôn ngữ.

Tại sao nó quan trọng: Đó là một bước nhảy vọt về chất cho các tình huống đa ngôn ngữ hỗn hợp (như hợp đồng tiếng Anh với các điều khoản tiếng Trung).

Dữ liệu hiệu suất: Lợi thế của các mô hình chuyên biệt

PP-OCRv6_medium chỉ có 34,5M tham số, nhưng trong các thử nghiệm đa tình huống nội bộ của nhóm PaddleOCR, độ chính xác nhận dạng văn bản OCR của nó đã vượt qua Qwen3-VL-235B (235 tỷ tham số), GPT-5.5 và Gemini-3.1-Pro. trích dẫn

Tại sao? Các mô hình chuyên biệt vẫn hiệu quả hơn các mô hình lớn tổng quát cho các nhiệm vụ dọc. VLM phải cân bằng hiểu tài liệu, suy luận và tạo sinh; OCR chỉ là một nhiệm vụ phụ. PP-OCRv6 được tối ưu hóa từ kiến trúc đến huấn luyện dữ liệu chỉ để "nhìn thấy văn bản rõ ràng."

Dữ liệu chính:

• Độ chính xác nhận dạng 83,2%, tăng 5,1% so với thế hệ trước.
• Phát hiện Hmean 86,2%, tăng 4,6% so với thế hệ trước.
• Tốc độ suy luận GPU tăng gấp 2,37 lần.

Sai lầm chết người của VLM: Chỉnh sửa ảo giác

Các mô hình đa phương thức như VLM có một sai lầm chết người khi xử lý OCR: "chỉnh sửa ảo giác" dựa trên các ưu tiên ngôn ngữ.

Ví dụ: Nếu hình ảnh hiển thị "Welcme" (lỗi chính tả), GPT-5.5 có thể "thông minh" chỉnh sửa nó thành "Welcome."

Đối với các tình huống yêu cầu khôi phục từng ký tự (tài liệu pháp lý, ảnh chụp màn hình mã, số sê-ri sản phẩm), sự "thông minh" này là thảm họa.

So sánh dữ liệu:

• Tỷ lệ khớp chính xác PP-OCRv6: 93,2% — Trung thành khôi phục mọi ký tự trong hình ảnh.
• Tỷ lệ khớp chính xác Qwen3-VL-235B: 80,6% — Dễ "điền" văn bản không có trong hình ảnh.

Khoảng cách 12,6 điểm phần trăm này có nghĩa là các mô hình nhẹ chuyên biệt đáng tin cậy hơn các mô hình lớn tổng quát trong các tình huống yêu cầu khôi phục chính xác.

Triết lý thiết kế của PP-OCRv6 là "trung thành khôi phục nội dung thị giác" mà không đưa ra phỏng đoán dựa trên mô hình ngôn ngữ. Các so sánh chính thức cho thấy rằng khi xử lý các ký tự công nghiệp, văn bản ma trận điểm hoặc dấu lốp xe, VLM tạo ra ảo giác rõ ràng, trong khi PP-OCRv6 nhận dạng chính xác các ký tự gốc. trích dẫn

Lời khuyên lựa chọn cho ba mô hình

PP-OCRv6 cung cấp ba cấp độ bao phủ mọi thứ từ thiết bị biên đến máy chủ.

Lời khuyên lựa chọn: Agent phía trình duyệt nên bắt đầu với Tiny/Small (đủ dùng và tải nhanh); sử dụng Medium cho xử lý hàng loạt phụ trợ. trích dẫn

So sánh chi phí

API đám mây trả tiền theo mức sử dụng (khoảng 200-1500 RMB cho 100k hình ảnh/tháng), trong khi các mô hình bản địa hóa miễn phí, mã nguồn mở, không có chi phí vận hành, không có giới hạn đồng thời và hoạt động ngoại tuyến.

Cuối cùng

OCR đã cạnh tranh trong nhiều năm; độ chính xác không còn là hàng hóa khan hiếm. Điều khan hiếm là nhìn thấy văn bản rõ ràng mà không giao dữ liệu của bạn.

PP-OCRv6 biến điều này thành một cuộc gọi 97ms trong trình duyệt (mô hình Tiny, CPU). Đối với những người xây dựng Agent, điều này có nghĩa là khả năng "đọc hình ảnh" cuối cùng cũng có thể được đưa vào một sản phẩm hứa hẹn "không rò rỉ dữ liệu."

Cho Agent của bạn đôi mắt cục bộ có thể bắt đầu bằng việc thay thế một dòng gọi API OCR đám mây đó.

Tài nguyên liên quan

• Trang web chính thức của PaddleOCR: paddleocr.com
• GitHub: github.com/PaddlePaddle/PaddleOCR
• HuggingFace: huggingface.co/collections/PaddlePaddle/pp-ocrv6
• Trải nghiệm trực tuyến: paddleocr.com (Hỗ trợ tải lên hình ảnh trực tiếp để thử nghiệm)

Bài báo kỹ thuật: PP-OCRv6: Từ 1,5M đến 34,5M Tham số, Vượt qua VLM Quy mô Tỷ trên Các Tác vụ OCR (arXiv:2606.13108)

👉 Nếu bài viết này hữu ích, hãy like, chia sẻ và lưu lại!