Unlimited OCR — Mô hình phân tích tài liệu dài one-shot của Baidu
(github.com/baidu)- Mô hình OCR E2E dựa trên DeepSeek OCR, thay thế toàn bộ attention của decoder để chép lại tài liệu dài hàng chục trang chỉ bằng một lần forward pass
- Cốt lõi là Reference Sliding Window Attention (R-SWA), giúp giữ KV cache ở mức hằng số ngay cả khi độ dài giải mã tăng lên, từ đó chặn đà tăng của chi phí bộ nhớ và tính toán
- Mô phỏng working memory của con người khi chép sách: dần quên những đầu ra ở xa và chỉ tham chiếu ngữ cảnh lân cận
- Trên OmniDocBench v1.5 đạt 93%, cao hơn DeepSeek OCR 6%; trên v1.6 đạt 93.92%, xác lập SOTA end-to-end
- R-SWA là cơ chế attention phân tích tổng quát, có thể áp dụng không chỉ cho OCR mà còn cho các tác vụ tham chiếu tài liệu dài như ASR và dịch thuật
Bối cảnh và bài toán
- Con người có thể thực hiện các tác vụ dài như chép lại hàng trăm trang hay dịch nhiều giờ âm thanh mà hiệu suất không suy giảm, nhưng các mô hình OCR hiện tại thậm chí không thể phân tích 10 trang trong một lần forward pass
- Các mô hình hiện nay xử lý theo từng trang bằng cách lặp for-loop, và khởi tạo lại bộ nhớ ở mỗi bước
- Cách này chỉ là một mẹo kỹ thuật chia nhỏ tiến trình dài nhất quán thành các tác vụ ngắn hạn tách biệt, chứ không phải tiến bộ hướng tới trí tuệ kiểu AGI
- Khi dùng LLM làm decoder, mô hình có thể tận dụng phân phối tiên nghiệm của ngôn ngữ để cải thiện hiệu năng, nhưng khi đầu ra dài hơn, KV cache tích lũy sẽ làm tăng tiêu thụ bộ nhớ và dần làm chậm tốc độ sinh
- Hành vi chép lại của con người không giống full attention tiêu chuẩn cũng không giống linear attention
- Không rà lại toàn bộ văn bản đã viết, mà chỉ tham chiếu ngữ cảnh lân cận để giữ đúng hướng
- Các token thị giác/tham chiếu không trải qua cập nhật trạng thái hồi tiếp — nếu cập nhật, đặc trưng thị giác sẽ dần mờ đi và làm giảm độ chính xác nhận dạng
Reference Sliding Window Attention (R-SWA)
- Mỗi token có thể truy cập mọi token tham chiếu (token thị giác + prompt), trong khi attention đầu ra chỉ bị giới hạn trong n token ngay trước đó (mặc định 128)
- Nhờ vậy, mỗi token vẫn nhận biết toàn bộ hình ảnh nhưng tự theo dõi tiến độ OCR thông qua chuyển trạng thái trong cửa sổ trượt nhân quả
- Trong suy luận, KV cache được giữ hằng số, giúp giảm áp lực bộ nhớ và chi phí tính toán
- Attention bị giới hạn vào cửa sổ 2 đoạn có kích thước m+n
- m là cửa sổ prefix gồm token thị giác và prompt; nó cố định trong một lần suy luận duy nhất, chỉ phụ thuộc vào số trang và độ phân giải, không phụ thuộc vào độ dài giải mã
- n là cửa sổ của vùng giải mã, có kích thước cố định và trượt theo cơ chế nhân quả
-
Quản lý KV cache
- Baseline DeepSeek OCR dùng MHA tiêu chuẩn nên kích thước KV cache tăng vô hạn theo Lm + T
- R-SWA giữ nguyên toàn bộ prefix cache Lm, nhưng với phần sinh ra chỉ lưu n token gần nhất, nên kích thước cache là Lm + min(n,T) ≤ Lm + n và có chặn trên hằng số
- Khi độ dài đầu ra đủ lớn, tỷ lệ cache ρ(T) hội tụ về 0 → biến mức tăng tuyến tính thành hằng số
-
Phân tích kernel
- Đo trên kernel Flash Attention v3 cho thấy MHA tiêu chuẩn của DeepSeek OCR tăng độ trễ theo từng bước giải mã, trong khi Unlimited OCR giữ thời gian ổn định nhờ R-SWA
- Với DeepSeek OCR, khi độ dài KV cache vượt qua một số ranh giới căn chỉnh nhất định sẽ xuất hiện spike do hiệu suất truyền dữ liệu giảm mạnh; hiện tượng này không xảy ra với R-SWA
- Bộ nhớ GPU khi suy luận cũng tăng tuyến tính ở mô hình gốc, còn Unlimited OCR giữ cố định — sự ổn định đồng thời về tính toán và bộ nhớ này là yếu tố giúp phân tích tài liệu dài khả thi
Kiến trúc mô hình
- Dùng DeepSeek OCR làm baseline, kết hợp DeepEncoder và decoder MoE (tổng 3B, tham số kích hoạt 500M)
- Thay MHA hiện có bằng R-SWA, cộng thêm buffer KV đầu ra dung lượng cố định n vào KV cache tham chiếu m để thực hiện phân tích tài liệu dài
- KV cache được cài đặt như hàng đợi dung lượng m+n; mỗi khi sinh token mới, KV của token thứ (m+1) bị đẩy ra, bảo đảm chi phí và bộ nhớ không tăng
-
DeepEncoder
- Ghép tầng SAM-ViT và CLIP-ViT, áp dụng nén token 16 lần ở bridge — nửa đầu xử lý token ảnh gốc bằng window attention, còn global attention chỉ dành cho token đã nén
- Giữ activation thấp khi mã hóa ảnh độ phân giải cao để tiết kiệm bộ nhớ GPU, nén ảnh PDF 1024×1024 xuống chỉ 256 token
- Dùng hai chế độ: "Base" cho đa trang (1024×1024) và "Gundam" cho trang đơn (độ phân giải động)
- Token thị giác được mã hóa một lần và giữ tĩnh trong suốt tiến trình, không trải qua chuyển trạng thái cùng đầu ra
Thiết lập huấn luyện
- Huấn luyện trên khoảng 2 triệu mẫu dữ liệu OCR tài liệu, với tỷ lệ trang đơn so với đa trang là 9:1
- PDF một trang được gán nhãn bằng Paddle OCR; tọa độ và nội dung của từng khối được nối lại để tạo ground truth, với tọa độ được chuẩn hóa về khoảng 0–1000
- Dữ liệu đa trang được tổng hợp bằng cách nối các trang đơn, khoảng 200.000 mẫu (2–50 trang), dùng dấu phân cách
<page>và đóng gói thành chuỗi 32K token
- Huấn luyện thêm 4.000 bước từ checkpoint DeepSeek OCR, global batch 256, chuỗi tối đa 32K, dùng 8×16 A800 GPU
- Trong quá trình huấn luyện, DeepEncoder bị đóng băng và chỉ huấn luyện các tham số LLM
- Dùng optimizer AdamW, scheduler cosine annealing, learning rate khởi tạo 1e-4, DeepEP (EP=4), dựa trên framework Megatron-LM
- Khi suy luận, thư viện Transformers được bổ sung cơ chế quản lý KV cache cho R-SWA, còn engine SGLang được hỗ trợ tối ưu hóa — cả hai framework đều chạy với TPS và bộ nhớ GPU hằng số
Kết quả đánh giá
- Benchmark chính là OmniDocBench (v1.5/v1.6), đánh giá năng lực phân tích đa chiều như văn bản, công thức, cấu trúc bảng và thứ tự đọc
- v1.6 là phiên bản mới hơn, bổ sung 296 ảnh kiểm thử so với v1.5; còn v1.5 cung cấp so sánh với các mô hình kinh điển gồm cả DeepSeek OCR
- Nhóm nghiên cứu cũng xây dựng test set riêng cho OCR tài liệu dài, phân loại tiểu thuyết, tài liệu và bài báo khoa học theo các mức 2/5/10/20/40+ trang (mỗi nhóm hơn 10 cuốn)
-
Hiệu năng chính
- Chỉ với 2M dữ liệu huấn luyện bổ sung đã đạt SOTA end-to-end; trên v1.5, khoảng cách chỉnh sửa văn bản giảm 0.035, còn TEDS của bảng tăng 5.96%
- Trên v1.6, chỉ số tổng hợp đạt 93.92%, xác lập SOTA end-to-end — cho thấy thay toàn bộ attention tiêu chuẩn bằng R-SWA độ rộng 128 vẫn hiệu quả và không mất mát
- Với 0.5B tham số MoE kích hoạt, suy luận đạt hiệu quả cao; ở chế độ "Base" đạt 5580 TPS (nhanh hơn 12.7% so với 4951 TPS của DeepSeek OCR)
-
Phân tích theo hạng mục
- So với DeepSeek OCR, mô hình cải thiện nhất quán trên mọi chỉ số, ở mức gần như một "bữa trưa miễn phí"
- So với DeepSeek OCR 2, mô hình vượt trội trên 7/9 hạng mục về khoảng cách chỉnh sửa văn bản và thứ tự đọc
- Không thua kém trong các bố cục phức tạp như PPT, báo, tạp chí và ghi chú
-
Phân tích tài liệu dài
- Nhờ R-SWA, mô hình có thể prefill hàng chục đến hàng trăm trang trong một pass duy nhất, phân tích liên tục từ trang đầu đến trang cuối trong khi độ trễ đầu ra vẫn ổn định nhờ KV cache cố định
- Ngay cả khi nhập đồng thời 20 trang, kết quả vẫn vững; ở 40+ trang vẫn giữ khoảng cách chỉnh sửa dưới 0.11 và Distinct-35 ở mức 97%
- Lỗi lặp chủ yếu đến từ việc chế độ đa trang "Base" (1024×1024) khó nhận diện chữ nhỏ, chứ không phải do R-SWA bị mất phương hướng
Phân tích hiệu quả
- So sánh TPS đầu ra trong điều kiện song song lý tưởng (cố định độ dài prefill là 10)
- Ở 256 token, tốc độ suy luận của hai mô hình gần như tương đương
- Khi độ dài đầu ra tăng, TPS của DeepSeek OCR giảm đều, và ở 6.000 token chậm hơn Unlimited OCR 35%
- Điều này một lần nữa xác nhận rằng tốc độ sinh ổn định là yêu cầu cốt lõi của các tác vụ OCR tài liệu dài
Hạn chế và hướng tiếp theo
- Với độ dài ngữ cảnh hữu hạn (ví dụ 32K), vẫn chưa thể phân tích thực sự không giới hạn do bị ràng buộc bởi độ dài prefill — dù DeepEncoder có tỷ lệ nén cao, prefill vẫn dài ra khi số trang tích lũy tăng
- Trong ngắn hạn, nhóm dự định huấn luyện các mô hình ngữ cảnh dài hơn như 128K để hỗ trợ prefill nhiều trang hơn
- Về dài hạn, mục tiêu là xây dựng prefill pool, huấn luyện mô hình tự động fetch các chunk KV của prefill để mô phỏng cách con người lật trang, qua đó đạt OCR thực sự không giới hạn
- Cũng có kế hoạch mở rộng R-SWA sang các tác vụ tham chiếu như ASR và dịch thuật
- Mô hình được cung cấp trên Hugging Face và ModelScope, bài báo được công bố trên arXiv
1 bình luận
Ý kiến trên Hacker News
Khá thú vị. Theo cách tôi hiểu thì nhóm nghiên cứu dường như đã tìm ra một mẹo kiến trúc để AI không phải tiếp tục chất thêm bộ nhớ khi đọc tài liệu dài
Thông thường, khi AI chép lại một file PDF 100 trang, nó cố ghi nhớ mọi từ đã đọc, và phần trí nhớ ngắn hạn này là KV cache tăng tuyến tính theo O(N), khiến VRAM cạn kiệt hoặc chạm giới hạn. Vì vậy, các lập trình viên phải viết những đoạn mã khá chắp vá để tách PDF ra xử lý theo từng trang rồi ghép lại
Unlimited OCR dùng Reference Sliding Window Attention (R-SWA) để chia sự tập trung thành hai đường. Một là tham chiếu toàn cục, nơi nhìn toàn bộ ảnh tài liệu gốc, và đường còn lại là phần sinh cục bộ, nơi bộ nhớ văn bản do chính mô hình tạo ra bị giới hạn trong một cửa sổ trượt hẹp như 128 từ gần nhất. Có vẻ khá thú vị cho AI chạy cục bộ, và tôi mong chờ xem cộng đồng sẽ xây dựng và mở rộng thêm những gì
Ngược lại, những chi tiết rất nhỏ như sáng nay ai đó ăn gì có thể hữu ích ở thời điểm hiện tại, nhưng về lâu dài thì ngoài các xu hướng chung ra gần như không còn nhiều ý nghĩa. Để tái cấu trúc cuộc trò chuyện, cần tìm được sự cân bằng phù hợp mà không phải lôi toàn bộ mọi thứ đã thảo luận cho tới lúc này vào, nên cách làm này có vẻ đáng để xem xét thêm
Gần đây tôi mua một chiếc máy tính bảng để xem bản nhạc, chủ yếu nhằm thay thế tập Jazz Real Book trong các buổi jam session. Bản quét bằng camera điện thoại thì tạm ổn, nhưng kích thước bị cố định và có nhiều tạp nhiễu
Sẽ rất tốt nếu có thể chuyển tông tức thì cho nhạc cụ Bb hoặc Eb, nhưng vì là bản quét nên đương nhiên là không thể. Khi tìm hiểu tình trạng nhận dạng ký âm quang học, tôi đi đến kết luận rằng âm nhạc gần như vẫn là vùng đất chưa được khai phá dưới góc nhìn AI. Nhận dạng ký âm quang học khá tệ, và mức độ hiểu lý thuyết âm nhạc của AI cũng rất kém khi bước vào lĩnh vực đọc bản nhạc thực tế. LLM làm tương đối ổn với các mô tả bằng văn bản về những khái niệm lý thuyết mà có lẽ đã xuất hiện trong dữ liệu huấn luyện là văn bản trực tuyến
Có vẻ vấn đề là chúng ta vẫn thiếu một định dạng số có thể mã hóa đúng các dấu chấm trên giấy mà nhạc công thực sự đọc. Ký pháp âm nhạc khá phong phú. MIDI chủ yếu được tạo ra để chứa các khía cạnh cần cho phát lại hoặc biểu diễn, nên không mang hết mọi thứ cần cho sự hiểu biết mang tính ký hiệu. MusicXML có vẻ là định dạng số gần nhất với loại thông tin mà nhạc công muốn có, nhưng lại thiếu các kho ngữ liệu huấn luyện tốt để nối biểu diễn MusicXML với hình ảnh bản nhạc hoặc âm thanh. Có lẽ vì chỉ riêng MusicXML vẫn chưa đủ thông tin cần cho việc dàn trang bản nhạc
Các công cụ như MuseScore phải theo dõi rất nhiều thông tin bố cục mà MusicXML không thể biểu diễn. Định dạng LilyPond bớt dài dòng hơn MusicXML và chứa thêm đôi chút thông tin hữu ích cho người làm bản nhạc, nhưng đa số mọi người không tạo bản nhạc bằng LilyPond. Nói thêm thì do tình trạng font jazz, LilyPond cũng khá đáng tiếc. Tôi không thích nhìn bản nhạc “kiểu cổ điển” trong ngữ cảnh jazz. Mỗi khi thấy OCR có một cải tiến tăng dần trông khá ổn, tôi lại nhớ đến sự thảm hại của OMR
verovio có thể dàn trang sang định dạng SVG trong khi giữ lại tối đa thông tin từ bản nhạc MEI gốc, nên có thể trích xuất đủ metadata để tạo dataset dò tìm thực tế cho các mô hình deep learning. Cũng có một script hack sơ sài để tạo dataset COCO từ tập bản nhạc được dàn bằng verovio: https://github.com/kwon-young/music/blob/main/svg2pl.py
Tôi cũng đã công khai dataset bản nhạc tổng hợp tạo ở đây: https://www.kaggle.com/datasets/kwonyoungchoi/trompa-coco/da... ai muốn thử huấn luyện bộ dò tìm trên đó đều được chào đón. Lý do OMR bị bỏ mặc như vậy phần lớn là vì hầu hết mọi người đều đánh giá thấp một cách nghiêm trọng độ khó của công việc này. Đây là một bài toán đặc thù pha trộn giữa hình thức cực kỳ đa dạng và ngữ pháp đồ họa rất phức tạp
Làm vậy rồi mới thấy rõ đến đau lòng rằng âm nhạc chưa từng được xem là phần quan trọng trong bất kỳ dataset huấn luyện AI nào. Gần đây khả năng hiểu và giải thích lý thuyết âm nhạc của Opus 4.8 khá đáng kinh ngạc, nhưng nếu bảo nó chép lại bản nhạc hoặc làm OCR/OMR, nó sẽ rất tự tin xuất ra phiên bản MusicXML/LilyPond kiểu “2 + 2 = con ngựa”. Tôi hy vọng lĩnh vực bị lãng quên này cũng sẽ được cuốn theo làn sóng AI đang lớn lên, nhưng hiện tại nó vẫn bị đánh giá thấp một cách vô lý
Tất nhiên nó không cung cấp mọi thông tin bổ sung cần cho dàn trang hay biểu diễn toàn bộ âm nhạc, nhưng có những dataset nghiên cứu như https://github.com/smashub/choco. Với tác vụ phân tích, tôi cũng từng dùng dataset https://github.com/MarkGotham/When-in-Rome, nhưng nó cũng không khớp 100% với thứ bạn đang tìm. Nếu mục đích là thay thế jazz standard và chuyển tông trên máy tính bảng, bạn có thể sẽ thích ứng dụng “iReal Pro”. Với trường hợp sử dụng đó thì nó tốt hơn khá nhiều so với quét bằng camera
Việc viết “Xin cảm ơn các mô hình và ý tưởng giá trị từ Deepseek-OCR, Deepseek-OCR-2 và PaddleOCR” là một thái độ đàng hoàng
Nhân tiện, “Unlimited OCR Works” là một trò nhại theo Unlimited Blade Works của Fate/stay night. Trong nguyên tác, Unlimited Blade Works là ma thuật sao chép vũ khí do người khác tạo ra
Bài báo có ở https://arxiv.org/abs/2606.23050
Nhân tiện, tôi đang làm OCR cục bộ cho một RAG nhỏ dùng với các trích dẫn đọc từ sách, và tôi cũng chia đầu vào thành các chunk để tiết kiệm RAM, nên thật thú vị khi thấy cách tiếp cận tự nhiên như vậy cũng hoạt động với mô hình streaming
Trông có vẻ hứa hẹn hơn thứ Mistral vừa phát hành. Trùng hợp ư? Tôi nghĩ là không
Cách tiếp cận này dường như cũng có thể dùng theo một số tổ hợp nào đó cho tạo ảnh. Có vẻ khả thi nếu đọc hoặc xem ảnh trước, rồi bắt đầu vẽ bằng các công cụ như Illustrator/Inkscape hoặc SVG, sau đó điền những phần còn thiếu về sau
Tôi tò mò nó so sánh ra sao với infinty parser 2, thứ từng có vẻ áp đảo các công cụ OCR khác: https://huggingface.co/datasets/allenai/olmOCR-bench
Nói công bằng thì không có benchmark OCR nào có một kẻ chiến thắng duy nhất, và công cụ này vẫn chưa xuất hiện ở đâu cả
Có thể tôi nghe như người không rành chuyện đời, nhưng lý do thực sự khiến các công ty công bố phần mềm thật sự tốt dưới dạng mã nguồn mở là gì?
Nếu là Baidu hay Google, chẳng phải họ nên giữ riêng để đối thủ không thể bắt chước và tự khai thác giá trị sao?
Công ty có được danh tiếng, điều này giúp ích cho phễu tuyển dụng. Đôi khi họ cũng có thể làm lung lay đối thủ một cách chiến lược, như việc Meta công bố Ollama
Mọi lần tôi thử làm OCR bằng AI đều bị lẫn kết quả bịa ra, nên rất khó dùng trong production. Tôi muốn biết liệu cái này có gặp vấn đề đó không
Một ví dụ đơn giản là những từ đáng lẽ phải được giữ nguyên ở ngôn ngữ khác lại tự động bị dịch sang tiếng Anh, làm hỏng hiệu quả
Trong phiên âm/chép lại, tôi gần như muốn kết quả chắc chắn, hoặc một dấu hiệu rõ ràng rằng nó thực sự không đọc được. Có thể đoán từ ngữ cảnh, nhưng với một số hệ OCR, cần biết liệu nó đoán chỉ dựa trên việc các ký tự ghép lại thành một từ theo thứ tự hay còn dựa trên cơ sở nào khác.
Ví dụ, trong các tài liệu điều tra dân số trên familysearch.com, người chép lại đã “sửa” một cái tên thành Joseph, nhưng chữ thật trong tài liệu viết tay là Josepth, và đó thực sự là một biến thể chính tả tại địa phương. Ở tài liệu khác, người viết dùng “Joh” như một dạng viết tắt, và có lẽ người chép tay đã ghi thành John; dù đó là khả năng cao nhất, nó vẫn sai với bản gốc. Có lúc việc đó chỉ là phỏng đoán là điều quan trọng, còn có lúc chỉ cần phỏng đoán tốt nhất có thể
Nếu dùng toàn bộ phần còn lại của tài liệu, chỉ trừ trang hoặc đoạn đang muốn kiểm thử, thì có thể tránh việc tái tạo nguyên xi cụm từ cần kiểm tra từ các artifact của ảnh. Sau khi tái tạo, chỉ cần làm phép so sánh quang học để đối chiếu các ký tự lệch nhau, tìm lỗi rồi lặp lại. Sẽ tốn kém, nhưng có thể bảo đảm nhận dạng 100%
Đầu ra giữ nguyên kanji/hiragana và tiếng Anh ở những chỗ cần thiết, không cố dịch chúng. Tôi đã chuyển được khoảng 200 trang mỗi giờ
Tôi không rõ Reducto giờ ra sao. Khoảng 12–15 tháng trước nó trông khá hứa hẹn