# LlamaIndex giới thiệu OCR thông minh: Giải pháp cân bằng chi phí và độ chính xác cho tài liệu

- Nguồn: LlamaIndex: Sản phẩm, kỹ thuật và đánh giá
- Thời gian phát hành: 2026-09-10 23:00 (giờ Việt Nam)
- Điểm AI: 65/100
- Nhãn AIHOT: Tinh chọn
- Link AIHOT.vn: https://aihot.vn/items/b19ebd188d74d380
- Nguồn dữ liệu AI HOT: https://aihot.news/items/cmtym2c3q0003rob0w6kxvnn3
- Link gốc: https://www.llamaindex.ai/blog/just-in-time-agentic-ocr

## Lý do tinh chọn

Giải pháp thực tế, giải quyết trực tiếp bài toán chi phí cao khi xử lý tài liệu bằng AI, rất hữu ích cho các kỹ sư và doanh nghiệp.

## Tóm tắt AI

LlamaIndex đề xuất quy trình OCR hai bước: dùng công cụ miễn phí để quét sơ bộ, sau đó chỉ dùng mô hình thị giác (VLM) cho các trang quan trọng nhằm tối ưu chi phí và hiệu suất.

## Thân bài

![Just-in-Time Agentic OCR](https://cdn.sanity.io/images/7m9jw85w/production/ea387c2dea1784964c37c92fa5306f49aa52771e-1200x630.png)

Xu hướng RAG mới nhất mà tôi quan sát được trong các bộ khung (harness) tác nhân hiện nay (Claude Cowork, Codex) là thực hiện hai lượt xử lý tài liệu để giải quyết một tác vụ tri thức trên một kho dữ liệu tài liệu:

Tôi bắt đầu gọi đây là "Agentic OCR tức thời" (just-in-time Agentic OCR). Vấn đề khi chỉ sử dụng OCR dựa trên VLM cho một tệp dữ liệu khách hàng ngẫu nhiên là nó chậm và đắt đỏ. Việc thực hiện lượt VLM tức thời cho phép tác nhân lọc dữ liệu với chi phí thấp, nhưng vẫn đảm bảo độ chính xác cho ngữ cảnh thực sự cần thiết cho tác vụ. Các bộ khung này thực hiện điều này theo mặc định với các công cụ có sẵn, và trong vài tháng qua, nhiều đội ngũ xây dựng tác nhân tài liệu đã mô tả cùng một thiết lập này với chúng tôi mà không cần gợi ý.

Cần làm rõ rằng, mô hình này dành cho thiết lập "kho dữ liệu" (data room) ngẫu nhiên, nơi người dùng tải lên khoảng 10-100 tài liệu và muốn đặt câu hỏi về chúng. Đây không phải là điều tôi khuyến nghị cho một quy trình dữ liệu ngoại tuyến (offline data pipeline) với hơn 1.000 đến 1 triệu tài liệu (chi tiết hơn ở bên dưới). Bài viết này sẽ đi sâu vào mô hình trên một kho dữ liệu thực tế, khi nào nên sử dụng nó so với OCR dựa trên VLM ngay từ đầu, và những gì còn thiếu trong các công cụ có sẵn.

### Hai lượt xử lý

![](https://cdn.sanity.io/images/7m9jw85w/production/5044eff2d64c8771c308350563dbd1358b9b96ef-3520x1560.png)

Lượt 1 (lướt qua): Tác nhân chạy một trình trích xuất văn bản giá rẻ, không cần mô hình trên mọi tệp được tải lên. Đầu ra không hoàn hảo, nhưng đủ tốt để thực hiện lệnh grep và xây dựng một chỉ mục ngữ nghĩa nhẹ bên trên.

Truy xuất: Tác nhân tìm kiếm văn bản đã lướt qua (grep, tìm kiếm ngữ nghĩa) để tìm các tệp và trang ứng viên.

Lượt 2 (phóng to): Đối với các trang liên quan, tác nhân nhận được kết quả đọc chất lượng VLM, bằng cách chụp ảnh màn hình trang đó và gọi VLM của riêng nó (Opus 5 trong trường hợp của Cowork) hoặc bằng cách gọi một trình phân tích tài liệu thực hiện việc đó. Có hai cách để giữ cho lượt này có chi phí thấp:

### Một ví dụ thực tế: 84 hồ sơ SEC

FinanceBench là bộ tiêu chuẩn QA tài chính mở của Patronus AI. Phần mã nguồn mở có 150 câu hỏi trên 84 hồ sơ công khai (10-K, 10-Q, 8-K và báo cáo thu nhập), tổng cộng là 12.013 trang. Đây là một kho dữ liệu khá thực tế cho một tác vụ thẩm định.

Đây là một trong những câu hỏi:

Đây là những gì vòng lặp hai lượt thực hiện với nó (các con số là từ việc chạy thử trên máy tính xách tay của tôi).

![](https://cdn.sanity.io/images/7m9jw85w/production/e893eee6324a5933a596093e876762e67f65b895-1445x1192.png)

![](https://cdn.sanity.io/images/7m9jw85w/production/7004f289847250e6df5fb4900fc88f7f3f5454e7-1445x1532.png)

Tổng cộng, tác nhân đã chạy VLM-OCR trên 2 trong số 12.013 trang, và bước đó chỉ mất vài giây.

Bạn cũng có thể xác định một cách rẻ tiền những trang nào cần lượt VLM ngay từ đầu. LiteParse có lệnh `lit is-complex` in ra phán quyết `needs_ocr` cho mỗi trang cùng với lý do (đã quét, không có văn bản, văn bản thưa thớt, hình ảnh nhúng, bị lỗi). Nó cũng xác định các trang có khả năng chứa bảng, văn bản nhiều cột, v.v. Trên 84 hồ sơ, nó đã gắn cờ 2.605 trong số 12.013 trang (21,7%), hầu hết là văn bản thưa thớt (bảng dày đặc với độ bao phủ văn bản thấp), cộng với 253 trang có hình ảnh nhúng và 75 trang không có lớp văn bản nào cả.

LlamaParse cung cấp ý tưởng tương tự dưới dạng công cụ MCP `estimateFileComplexity` giúp ánh xạ mỗi trang vào một cấp độ phân tích. Trên tệp 3M 10-K, nó đã điều hướng khoảng hai phần ba số trang sang LiteParse và khoảng 35% còn lại sang cấp độ VLM.

### Tại sao cách này hiệu quả với kho dữ liệu nhưng không hiệu quả với quy trình ngoại tuyến

Lý do cách hai lượt hoạt động trong thiết lập kho dữ liệu quy mô trung bình là bạn có thể vượt qua các vấn đề truy xuất bằng cách tận dụng tất cả các lệnh hệ thống tệp và chạy thêm các vòng lặp tác nhân.

Nếu lượt 1 làm hỏng bảng hoặc bỏ qua một trang đã quét, việc truy xuất có thể bỏ lỡ nó. Nhưng với 84 tài liệu thì điều này không sao cả. Nếu tác nhân thực sự muốn tìm một mẩu thông tin, nó không chỉ phải sử dụng grep — nó có thể quét mọi tài liệu trong tập dữ liệu. Điều này làm tăng độ trễ, nhưng cho phép tác nhân tìm kiếm toàn diện mọi tài liệu, tương tự như những gì tôi đã mô tả trong "Files Are All You Need", nơi các tác nhân xen kẽ việc tìm kiếm với các thao tác `Read ` theo cách con người vẫn làm.

Bạn không thể làm điều này một cách hiệu quả với 1 triệu tài liệu. Ở quy mô đó, tác nhân chỉ thấy những gì truy xuất trả về, vì vậy việc truy xuất (ngữ nghĩa hoặc từ khóa) phải chính xác, và truy xuất chỉ tốt khi dựa trên biểu diễn văn bản mà nó được xây dựng trên đó. Đối với các trường hợp sử dụng ngoại tuyến, việc có thể để VLM đọc bất kỳ tài liệu nào — đã quét/số hóa, biểu mẫu, chữ viết tay, biểu đồ — là rất quan trọng đối với độ chính xác của truy xuất.

Vì vậy, quy tắc ngón tay cái mà tôi sử dụng là:

### Khi nào nên sử dụng OCR dựa trên VLM ngay từ đầu

Có hai trường hợp chính mà tôi sẽ bỏ qua thiết lập hai lượt và chỉ chạy OCR dựa trên VLM cho mọi thứ ngay từ đầu:

Xử lý hàng loạt ngoại tuyến quy mô lớn cho các trường hợp sử dụng RAG. Nếu bạn đang lập chỉ mục hơn 1.000-1 triệu tài liệu mà các tác nhân sẽ truy vấn lặp đi lặp lại, bạn muốn văn bản chất lượng VLM cho mọi trang (đã quét, số hóa, biểu mẫu, chữ viết tay, biểu đồ), vì độ chính xác của truy xuất phụ thuộc trực tiếp vào đó. Chi phí phân tích cũng được khấu hao qua mọi truy vấn trong tương lai.

Xử lý hàng loạt cho các trường hợp sử dụng trích xuất tài liệu, nơi độ chính xác cực kỳ quan trọng. Hãy nghĩ đến: trích xuất hóa đơn, tiếp nhận yêu cầu bồi thường, KYC, bất cứ thứ gì mà bạn đang trích xuất các trường vào một hệ thống lưu trữ. Một ô bị đọc sai sẽ trở thành một con số sai ở hạ nguồn, và bạn muốn có các hộp giới hạn (bounding boxes) và điểm tin cậy trên mọi trường để con người có thể kiểm toán. Không có khái niệm "phóng to sau" ở đây vì bạn cần xử lý từng tài liệu một.

Trong cả hai trường hợp, toán học về chi phí là khác nhau. Bạn đang trả khoảng 1 xu/trang một lần, cho thứ gì đó được sử dụng lại hàng nghìn lần hoặc cho thứ gì đó phải đúng ngay từ lần đầu tiên.

### Các vấn đề với thiết lập có sẵn

Quay lại thiết lập kho dữ liệu, các bộ khung tác nhân thực hiện xử lý tài liệu hai lượt theo mặc định bằng cách sử dụng các công cụ có sẵn: `pdftotext` cho lượt đầu tiên và mô hình của chính bộ khung (Opus 5 trong trường hợp của Cowork) cho lượt thứ hai. Các vấn đề chính với xử lý tài liệu "có sẵn" này là:

Opus 5 không phải là VLM tốt nhất cho OCR, và nó quá đắt ở quy mô lớn: Các mô hình tiên phong (frontier models) được huấn luyện sau để suy luận, toán học và lập trình. OCR tài liệu không phải là tiêu chuẩn mà bất kỳ phòng thí nghiệm nào cũng tối ưu hóa, như tôi đã viết gần đây.

Trên ParseBench (2.078 trang doanh nghiệp được con người xác minh, 169 nghìn quy tắc kiểm tra trên bảng, biểu đồ, độ trung thực của nội dung, định dạng ngữ nghĩa và căn cứ thị giác), mô hình tiên phong tốt nhất mà chúng tôi đã thử nghiệm là Fable 5.1 với 78,9 điểm tổng thể, nhưng ở mức 16 xu/trang. Opus 4.8 đạt 63,7 với 7,3 xu, GPT-5.5 đạt 67,8 với 13 xu, và Gemini 3.1 Pro đạt 69,1 với 8,5 xu. LlamaParse agentic đạt 87,0 với 1,25 xu. (Chúng tôi chưa chạy Opus 5 trên ParseBench).

Vấn đề lớn hơn là căn cứ (grounding). Opus 4.8 đạt 18,7 điểm về căn cứ thị giác, và các mô hình không suy nghĩ như Haiku 4.5 và GPT-5 Mini đạt dưới 7, so với 84 của LlamaParse. Nếu không có hộp giới hạn và điểm tin cậy, không có cách nào để kiểm toán đầu ra, và nếu tác nhân đọc sai một ô bảng, lỗi đó sẽ lan truyền qua phần còn lại của quy trình làm việc.

Các công cụ OSS như `pypdf` và `pdftotext` không đủ linh hoạt cho lượt đầu tiên: Chúng chỉ lấy lớp văn bản nhúng ra khỏi các tệp PDF kỹ thuật số và không làm được gì nhiều hơn. Các trang đã quét sẽ trả về trống. Bố cục nhiều cột bị xen kẽ, vì lớp văn bản lưu trữ thứ tự văn bản được vẽ thay vì thứ tự đọc. Các bảng bị đổ ra theo từng cột, giống như trang 3M ở trên.

Một tệp dữ liệu khách hàng thực tế cũng có thể chỉ có một nửa là PDF; phần còn lại là Word, PowerPoint, Excel và các tệp xuất email mà các công cụ này hoàn toàn không xử lý được.

Tác nhân viết rất nhiều mã dùng một lần để xây dựng lại những thứ mà một công cụ OCR sẽ cung cấp sẵn: hiển thị trang thành hình ảnh, cắt hình, tái tạo bảng trong pandas, đoán ranh giới ô. Xử lý biểu đồ, hộp giới hạn và điểm tin cậy đều là những thứ mà một trình phân tích thực sự trả về trong một lần gọi, thay vào đó tác nhân lại tự suy luận chúng bằng Python dùng một lần trong mỗi phiên, điều này tốn cả token và thời gian. Nó hoạt động thường xuyên hơn bạn nghĩ, nhưng không có gì trong số đó có thể tái sử dụng hoặc tái lập.

### Các công cụ cho cả hai lượt

Chúng tôi có tất cả các công cụ trong LlamaIndex để giúp bất kỳ tác nhân nào thực hiện xử lý tài liệu hai lượt với độ chính xác cao hơn và chi phí thấp hơn.

LiteParse cho lượt đầu tiên. LiteParse là một trình phân tích miễn phí/OSS được viết bằng Rust (Apache 2.0, hơn 12 nghìn sao) thực hiện trích xuất văn bản không gian với các hộp giới hạn, tái tạo các tiêu đề và bảng markdown, và hỗ trợ hơn 50 loại tài liệu bao gồm cả các định dạng Office. Đó là những gì tôi đã sử dụng cho con số 32 giây ở trên. Nó cũng có `lit is-complex`, cho tác nhân biết trang nào thực sự cần lượt VLM. Có một kỹ năng tác nhân nếu bạn muốn sử dụng nó từ Claude Code hoặc Cowork ngay hôm nay.

Để làm rõ vị trí của nó: LiteParse rất tuyệt vời cho lượt đầu tiên trong thiết lập kho dữ liệu, nhưng nó không phải là thứ tôi sẽ sử dụng làm bước đầu tiên của quy trình ngoại tuyến trên hơn 1.000 tài liệu, vì những lý do trên.