PaddleOCR-VL-1.6: Khi model nhỏ đánh bại gã khổng lồ

Mình hay theo dõi các paper về OCR và document parsing vì đây là bài toán thực tế cực kỳ phổ biến trong các dự án enterprise từ xử lý hóa đơn, hợp đồng, đến scan tài liệu y tế. Tuần này team PaddleOCR vừa drop paper về phiên bản 1.6, và thật ra cái cách họ tiếp cận vấn đề mới là thứ đáng đọc, không phải con số benchmark.

96.33% với 0.9B params con số này ý nghĩa gì?

Nếu bạn đã từng làm việc với các VLM (Vision-Language Model) lớn như GPT-4V hay Gemini để parse document, bạn biết chi phí inference không hề rẻ. PaddleOCR-VL-1.6 chỉ có 0.9 tỷ parameters mà đạt state-of-the-art 96.33% trên OmniDocBench v1.6 benchmark khá chuẩn cho document parsing hiện tại.

Để so sánh cho dễ hình dung:

Cùng một kích thước model, nhưng 1.6 vượt hẳn 1.5. Câu hỏi thú vị là: họ làm gì để improve mà không phình to model?

Vấn đề thật sự của 1.5 là gì

Thay vì cứ nhồi thêm data vào train cách tiếp cận "brute force" mà nhiều team hay làm nhóm tác giả ngồi phân tích xem model 1.5 đang fail ở đâu. Họ tìm ra một pattern khá thú vị: các lỗi còn lại của 1.5 không phân bố đều, mà tập trung vào một số vùng cụ thể mà họ gọi là under-optimized regions.

Ba nguyên nhân chính dẫn đến các vùng này:

1. Model behavior không ổn định ở một số loại input tức là cùng một dạng document, đôi khi predict đúng, đôi khi sai, không nhất quán
2. Data coverage thưa training data thiếu các case edge, ví dụ bảng biểu phức tạp, text xoay nghiêng, watermark chồng lên text
3. Supervision signal không đáng tin label quality có vấn đề ở một số subset, model học sai từ đầu

Mình thấy cái insight này hay ở chỗ: thay vì hỏi "mình cần thêm bao nhiêu data", họ hỏi "data nào đang làm hại model". Đây là tư duy data-centric AI mà Andrew Ng hay nói đến, nhưng ít team thực sự làm được bài bản.

Under-Optimized Region Refinement kỹ thuật chính

Framework họ xây dựng gọi là region-aware data optimization, flow cơ bản như sau:

• Chạy model 1.5 trên một tập evaluation lớn, ghi lại tất cả các case fail
• Cluster các lỗi theo pattern để xác định "weak regions" ví dụ: bảng có merged cells, math formula, handwriting mixed với print text
• Với mỗi weak region: vừa augment thêm data targeted, vừa re-label hoặc filter lại supervision signal cho sạch
• Không touch các region model đã làm tốt tránh catastrophic forgetting

Cái này về mặt engineering khá giống với hard negative mining trong information retrieval, hoặc focal loss trong object detection bạn tập trung compute/data vào những case khó thay vì trải đều. Nhưng ở đây họ làm ở level data pipeline thay vì loss function.

Theo kinh nghiệm của mình khi fine-tune các model OCR cho dự án nội bộ, vấn đề supervision quality thường bị underestimate. Anh em hay nghĩ cứ có nhiều data là tốt, nhưng 10k sample sạch thường beat 100k sample noisy label. Paper này confirm điều đó ở scale lớn hơn.

Progressive Post-Training train theo giai đoạn

Sau khi có bộ data đã được curate kỹ, họ không train một lần mà dùng progressive post-training tức là train theo nhiều stage, mỗi stage có objective khác nhau.

Giai đoạn cuối cùng họ dùng reinforcement learning để tinh chỉnh thêm. Cụ thể hơn, thay vì chỉ dùng supervised learning với ground truth, họ dùng RL để model tự học từ reward signal ví dụ: output parse được document structure đúng thì reward cao, output lộn xộn thì penalize.

Cái này liên quan đến trend RLHF/RLAIF đang hot trong LLM space, nhưng apply vào document parsing là khá mới. Lợi thế là model có thể học được các preference khó encode thành label cứng ví dụ: khi có hai cách parse một bảng phức tạp, cái nào "tự nhiên" hơn với downstream task.

Progressive training cũng giúp tránh một vấn đề kinh điển: nếu bạn train tất cả objectives cùng lúc, các task khó nhau có thể conflict gradient và model không converge tốt. Chia stage ra thì mỗi giai đoạn model học một thứ trước khi chuyển sang thứ khó hơn.

Practical implications cho team làm document AI

Nếu bạn đang build pipeline xử lý document trong production, đây là vài điểm đáng lưu ý:

PaddleOCR vẫn là open-source và self-hostable. Với 0.9B params, bạn có thể chạy trên một GPU T4 hoặc A10 thoải mái, không cần cluster khủng. Chi phí inference so với gọi API GPT-4V giảm đáng kể mình ước tính khoảng 10-20x tùy throughput.

OmniDocBench là benchmark đáng để bạn test model của mình. Nếu team bạn đang evaluate các OCR/document parsing solution, đây là chuẩn khá toàn diện cover được nhiều loại document type, ngôn ngữ, và layout phức tạp hơn các benchmark cũ như FUNSD hay DocVQA.

Methodology của paper này áp dụng được cho fine-tuning use case riêng. Nếu bạn đang fine-tune một model OCR cho domain cụ thể (ví dụ: hóa đơn tiếng Việt, hợp đồng bảo hiểm), thay vì dump thêm data, hãy thử:

• Chạy model hiện tại trên validation set
• Cluster các lỗi theo type
• Targeted augment cho từng cluster
• Re-check label quality của các cluster đó

Anh em lưu ý là paper chưa release chi tiết về dataset curation pipeline, nên một số kỹ thuật cụ thể vẫn còn là black box. Nhưng code và model weights đã có trên GitHub PaddlePaddle/PaddleOCR, bạn có thể pull về test ngay.

Điểm còn băn khoăn

Mình đọc xong vẫn có một câu hỏi chưa được trả lời rõ: performance trên non-English document thế nào? OmniDocBench có cover đa ngôn ngữ nhưng benchmark score tổng hợp có thể che đi performance gap giữa các ngôn ngữ. Với anh em làm sản phẩm tiếng Việt, đây là điểm cần test riêng trước khi adopt.

Ngoài ra, RL training thường khó reproduce và sensitive với hyperparameter. Paper mô tả approach nhưng chưa có ablation study chi tiết về phần RL, nên nếu bạn muốn replicate methodology này cho model của mình thì cần expect một số trial and error.

Nhìn chung, PaddleOCR-VL-1.6 là một case study tốt về việc làm nhiều hơn với ít hơn không phải lúc nào cũng cần model to hơn hay data nhiều hơn. Đôi khi cần ngồi phân tích xem model đang fail ở đâu và tại sao, rồi fix đúng chỗ. Cái mindset đó mình nghĩ áp dụng được cho hầu hết bài toán ML production mà anh em đang làm.