OCR dài tài liệu: nhìn cache trước benchmark

OCR dài tài liệu: nhìn cache trước benchmark

Unlimited OCR đáng chú ý không vì thêm một model OCR mới, mà vì nhắc builder đo đúng nút nghẽn: KV cache, layout, confidence và tiêu chí dừng pilot.

Có một kiểu demo OCR làm mình vừa buồn cười vừa muốn đạp phanh: upload PDF 3 trang, model trả Markdown đẹp như brochure, cả team vỗ tay. Tuần sau đem vào hồ sơ vay vốn 80 trang, bảng bị lệch cột, chữ ký thành tiêu đề, GPU thì thở như xe leo đèo.

Điểm đáng bàn ở Baidu Unlimited OCR không phải là “lại thêm một model OCR mới”. Cái đáng bàn là nó chạm đúng một nút nghẽn mà nhiều team chỉ phát hiện khi đã vào production: đọc tài liệu dài không chết vì nhận diện chữ, mà chết vì bộ nhớ và độ trễ tăng theo output.

Nói thẳng ra thì: với OCR dài tài liệu, benchmark đẹp chỉ là biển báo. Người cầm vô lăng vẫn phải nhìn điểm mù của hệ thống.

Sơ đồ minh họa cho bài OCR dài tài liệu: nhìn cache trước benchmark

Sơ đồ tóm tắt ý chính của bài viết.

Cú rẽ thật sự: giữ KV cache phẳng

Unlimited OCR là model 3B tham số theo kiến trúc Mixture-of-Experts, nghĩa là tổng model lớn nhưng mỗi lần inference chỉ kích hoạt một phần; nguồn cho biết khoảng 500M tham số active. Nó được Baidu open-source và xây tiếp từ DeepSeek OCR bằng continue-training, không phải train lại từ đầu.

Chi tiết đáng giữ nằm ở Reference Sliding Window Attention hay R-SWA: cơ chế attention giúp KV cache — bộ nhớ lưu key/value của các token trước đó để model sinh tiếp — không phình mãi theo độ dài output.

Trong decoder kiểu thường, mỗi token sinh ra lại thêm dữ liệu vào cache. Tài liệu càng dài, output càng dài, cache càng to, latency càng ì. Unlimited OCR đổi cách decoder nhìn ngữ cảnh: token mới vẫn attention tới reference tokens, tức visual tokens và prompt, nhưng với output cũ thì chỉ nhìn một cửa sổ gần nhất, mặc định n = 128 token. Những phần quá cũ được loại khỏi cache động.

Điều này không làm OCR “thông minh vô hạn”. Nó chỉ xử lý một bài toán rất vận hành: memory slope — độ dốc tăng bộ nhớ theo số token sinh ra. Nếu slope này không được kiểm soát, tài liệu dài sẽ biến từ bài toán AI thành bài toán hạ tầng.

Nguồn cũng nêu model parse hàng chục trang trong một forward pass dưới giới hạn 32K, đạt 93.23 trên OmniDocBench v1.5 và hơn baseline DeepSeek OCR 6.22 điểm. Con số đáng chú ý, nhưng với builder, câu hỏi không phải “cao hơn bao nhiêu”, mà là: nó cao hơn ở loại tài liệu nào, dưới chi phí nào, và lỗi còn lại có sửa được bằng pipeline không?

Mổ xe đúng chỗ: OCR không chỉ là chữ

Nếu bạn đang build hệ thống đọc PDF cho ngân hàng, bảo hiểm, logistics, pháp lý, hoặc nội bộ doanh nghiệp Việt Nam, OCR “đọc đúng chữ” mới là nửa đường.

Nửa còn lại gồm:

Ở đây, Unlimited OCR và Mistral OCR 4 gợi ra hai hướng khác nhau. Unlimited OCR nhấn vào đường dài: giữ cache phẳng để đọc tài liệu dài ổn hơn. Mistral OCR 4 nhấn vào cấu trúc tài liệu: nhận diện block, vị trí, vai trò, confidence score, hỗ trợ nhiều ngôn ngữ và có API với mức giá công bố 4 USD mỗi 1.000 trang, hoặc 2 USD ở batch mode.

Ví dụ cụ thể: team bạn cần ingest 50.000 trang hợp đồng cũ để phục vụ search nội bộ. Nếu bottleneck là “job chạy qua đêm hay OOM giữa chừng”, Unlimited OCR đáng thử. Nếu bottleneck là “bảng điều khoản bị tách sai khiến RAG trả lời sai”, OCR có layout và confidence rõ ràng có thể quan trọng hơn.

Đừng chuyển làn chỉ vì model mới có đèn pha sáng hơn. Hãy xem làn bạn đang kẹt là memory, layout, hay review cost.

Framework 4 đèn tín hiệu cho team builder

Trước khi thay OCR stack, mình sẽ chấm từng ứng viên qua 4 đèn tín hiệu này.

| Đèn tín hiệu | Câu hỏi cần đo | Vì sao quan trọng |
|---|---|---|
| Memory slope | RAM/VRAM tăng thế nào khi output dài hơn? | Tài liệu dài thường làm chi phí tăng âm thầm trước khi hệ thống sập |
| Layout fidelity | Bảng, tiêu đề, chữ ký, công thức có giữ đúng vai trò không? | RAG sai thường bắt đầu từ chunk sai, không phải model chat sai |
| Confidence routing | Có điểm tự tin đủ dùng để route sang human review không? | Không có confidence thì mọi lỗi đều lọt hoặc mọi thứ đều phải duyệt tay |
| Serving fit | Chạy batch, API, hay self-host hợp với tải thật không? | Model tốt nhưng serving lệch tải thì vẫn đắt và chậm |

Framework này cũng giúp bạn không bị cuốn vào cuộc đua “model nào thắng benchmark”. Benchmark giống tốc độ tối đa trên brochure xe; production là giờ tan tầm, đường ngập, khách thúc SLA.

Một điểm thú vị: các nguồn liên quan về DFlash và DSpark đều không nói về OCR trực tiếp, nhưng cùng chỉ về một xu hướng: tối ưu serving quan trọng ngang model weight. DFlash dùng block diffusion model để draft cả block token song song trong speculative decoding — kỹ thuật cho model nhỏ đề xuất token, model lớn xác nhận. DSpark cũng là serving optimization cho DeepSeek-V4, không phải model mới, với draft module, confidence head và load-aware scheduler.

Thông điệp cho OCR rất rõ: nếu pipeline của bạn đang nghẽn ở inference, đừng chỉ hỏi “model nào mạnh hơn”. Hỏi thêm: cơ chế sinh output có làm GPU nhàn rỗi, cache phình, hay verify lãng phí không?

Pilot trong một buổi: đủ để biết nên đi tiếp hay dừng

Bạn không cần mở dự án 6 tuần để biết Unlimited OCR có đáng đưa vào backlog không. Một buổi nghiêm túc là đủ để loại bỏ ảo tưởng.

Chọn một tập nhỏ nhưng khó, ví dụ:

Sau đó chạy cùng một pipeline đánh giá:

ocr_pilot:
  input_set: 25 tài liệu khó, lấy từ dữ liệu thật đã được phép dùng
  compare:
    - OCR hiện tại của team
    - Unlimited OCR nếu có thể chạy phù hợp môi trường
    - một OCR có layout/confidence nếu team đang cần cấu trúc
  measure:
    - thời gian xử lý mỗi trang
    - peak RAM/VRAM
    - lỗi bảng và thứ tự đọc
    - lỗi mất trang hoặc lặp nội dung
    - tỷ lệ block cần human review
  stop_if:
    - không chạy ổn với tài liệu dài đại diện
    - không xuất được cấu trúc đủ dùng cho downstream
    - chi phí vận hành cao hơn lợi ích giảm review tay

Hình dung thế này: nếu OCR mới nhanh hơn nhưng làm mất ranh giới bảng, team RAG phía sau sẽ phải vá bằng prompt, regex, rồi manual cleanup. Đó không phải tối ưu; đó là dời ổ gà từ đầu đường sang cuối đường.

Ngược lại, nếu Unlimited OCR giữ memory ổn trên tài liệu dài, output đủ nhất quán để chunk, và lỗi còn lại có thể route bằng confidence hoặc rule đơn giản, lúc đó mới đáng scale pilot lên vài nghìn trang.

Những thứ nên bỏ qua khi đọc release

Có ba thứ mình sẽ không để nó lái quyết định.

Thứ nhất, tham số model. 3B nghe vừa phải, 500M active nghe hiệu quả, nhưng con số tham số không thay thế được latency thật trên tài liệu của bạn.

Thứ hai, điểm benchmark đơn lẻ. OmniDocBench hữu ích để định vị, nhưng tài liệu Việt Nam có hóa đơn scan, dấu đỏ, bảng ghép ô, ảnh chụp từ điện thoại, font cũ. Nếu benchmark không phản ánh data nhà bạn, nó chỉ là tín hiệu ban đầu.

Thứ ba, tuyên bố “lossless” ở các tối ưu decoding. Với speculative decoding như DFlash hoặc DSpark, lossless nghĩa là phân phối đầu ra của target model được giữ trong cơ chế xác nhận. Nó không có nghĩa toàn bộ ứng dụng của bạn không lỗi. Nếu OCR upstream sai layout, downstream vẫn có thể trả lời sai rất tự tin.

Cũng nên nhìn bài MirrorCode như một lời nhắc về inference budget. Một benchmark coding có task chạy 19 ngày và tốn 2.600 USD cho một lần chạy là ví dụ cực đoan, nhưng nó nhắc mình rằng “AI làm được” và “AI đáng vận hành” là hai câu khác nhau.

Quyết định nên đổi sau khi đọc bài này

Sau bài này, điều mình muốn bạn đổi không phải là “hãy dùng Unlimited OCR”. Quyết định đúng hơn là: đừng chọn OCR theo model release; hãy chọn theo bottleneck của pipeline.

Nếu bottleneck của bạn là tài liệu dài làm cache và latency phình, hãy ưu tiên thử các thiết kế như R-SWA. Nếu bottleneck là cấu trúc trang và review workflow, hãy ưu tiên layout parsing và confidence score. Nếu bottleneck là tải production, hãy nhìn cả serving optimization, scheduler, batch mode và chi phí peak.

Model mới là xe mới. Nhưng production vẫn hỏi cùng một câu cũ: đường của bạn đang kẹt ở đâu, và có cần chuyển làn thật không?

---
Bụi Wire — nghiện đọc release notes lúc 2 giờ sáng

Nguồn tham khảo