Document parsing tự host — lớp nền mà nhiều team đang bỏ quên

LlamaIndex mở mã nguồn liteparse-server. Mình bóc tách xem self-host parsing đã sẵn sàng cho pipeline production chưa, và khi nào nên bỏ qua.

"Pipeline RAG chạy ngon trên 200 trang PDF tiếng Anh, nhưng đẩy hợp đồng scan tiếng Việt vào là output ra rác. Có cách nào fix mà không trả per-page cho cloud API không?"

Câu hỏi này một tech lead ở Sài Gòn hỏi mình tuần trước — và gần như trùng timing với release mới từ LlamaIndex: liteparse-server, một server parsing tài liệu self-host, mã nguồn mở, chạy local không cần GPU. Mình bóc ra xem tín hiệu thật nằm ở đâu.

Chuyện gì đang diễn ra với document parsing

Hầu hết AI workflow xử lý tài liệu đều đụng cùng một bức tường: lấy text sạch từ PDF, Word, ảnh scan. Thư viện cơ bản như pypdf cho output mất layout — bảng biến thành text nối đuôi, heading lẫn vào body. Cloud API (LlamaParse, Azure Document Intelligence) giải quyết accuracy nhưng kéo theo ba vấn đề: latency mạng, chi phí per-page tăng tuyến tính theo volume, và dữ liệu rời khỏi infra của bạn.

liteparse-server là lựa chọn ở giữa: chạy trên máy bạn, expose REST API chuẩn, hỗ trợ OCR, trả về markdown có cấu trúc. Ba endpoint chính:

• POST /parse — chuyển file thành markdown hoặc plain text
• POST /extract — trích xuất structured data theo schema bạn define
• POST /screenshots — render từng trang thành ảnh, feed thẳng vào vision model

Đây không phải bản miễn phí của LlamaParse cloud. Đây là engine khác — nhẹ hơn, local-first, không yêu cầu GPU.

Bóc từng lớp — cơ chế bên trong

Trong hội họa, bức tranh sống hay chết ở lớp nền: nếu lớp gesso (lót canvas) không đều, mọi lớp sơn phía trên đều bong. Document parsing đóng vai trò tương tự trong pipeline RAG — nếu text extraction sai, embedding sai, retrieval sai, model trả lời sai. Chuỗi domino bắt đầu từ đây.

liteparse-server xử lý lớp nền này qua ba bước:

1. Layout detection (nhận diện bố cục) — phát hiện cột, bảng, header/footer trước khi extract text. Đây là điểm mà pypdf thua hoàn toàn: nó đọc text theo stream order trong PDF, không quan tâm vị trí trên trang.

2. OCR fallback — khi phát hiện trang là ảnh scan hoặc không có text layer, tự động chuyển sang OCR pipeline. Không cần bạn viết logic routing riêng.

3. Schema-based extraction — bạn gửi kèm JSON schema mô tả cấu trúc mong muốn, server trả data khớp schema thay vì dump raw text. Dịch sang ngôn ngữ workflow: bạn nói "tôi cần trường hợp đồng, ngày ký, số tiền" — server trả đúng ba trường đó.

Trong bối cảnh rộng hơn, tuần này còn thấy Claude Platform on AWS ra mắt GA — cho phép dùng Claude API qua IAM credential mà không cần account Anthropic riêng. Tín hiệu chung: hệ sinh thái đang dịch chuyển về phía infrastructure gần hơn với team vận hành, bớt phụ thuộc vào vendor riêng lẻ.

Điều đáng giữ — hai kịch bản thật

Kịch bản 1: Giả sử team fintech 6 người ở Hà Nội xây hệ thống đọc hợp đồng tín dụng. Mỗi ngày xử lý vài trăm trang PDF digital (không phải scan). Với cloud parsing, chi phí tỷ lệ thuận với volume — tháng nào business tăng, bill parsing tăng theo. Self-host trên một VPS 8GB RAM cắt hoàn toàn khoản biến phí đó. File không rời server nội bộ — compliance team không cần review thêm DPA với vendor.

Kịch bản 2: Team product 4 người build RAG nội bộ cho tài liệu kỹ thuật — sơ đồ kiến trúc, bảng spec, text lẫn Anh-Việt. Endpoint /screenshots cho phép gửi ảnh trang thẳng vào vision model (GPT-4o, Gemini) để xử lý phần mà OCR thuần không cover: sơ đồ, biểu đồ, annotation viết tay. Kết hợp /parse cho text + /screenshots cho visual = pipeline hybrid mà không cần hai tool riêng biệt.

Ba thứ thực sự đáng giữ:

• Privacy by default — tài liệu nhạy cảm không rời infra
• Chi phí dự đoán được — không bill bất ngờ khi volume spike
• Tích hợp đơn giản — REST API chuẩn, dễ cắm vào bất kỳ orchestration nào đang chạy

Nếu bạn muốn thử trong một buổi chiều: pull Docker image, mount thư mục chứa PDF, gọi /parse rồi so sánh output với pypdf trên cùng file. Nếu markdown giữ đúng cấu trúc bảng — green light để đi sâu hơn. Nếu output vỡ layout — file đó thuộc nhóm cần cloud parser hoặc vision model.

Điều nên bỏ qua — ít nhất là bây giờ

Đừng kỳ vọng liteparse-server thay thế mọi use case của cloud parsing:

• Scan chất lượng thấp — ảnh chụp nghiêng, fax cũ, watermark đè text — accuracy sẽ tụt rõ rệt so với cloud parser có model chuyên biệt cho từng loại tài liệu
• Scale hàng chục nghìn page/giờ — bạn tự lo horizontal scaling, queue management, retry logic. Không có sẵn managed layer
• Extraction ngữ nghĩa phức tạp — muốn hiểu "dòng nào trong bảng là tổng cộng" thì vẫn cần LLM layer phía sau, liteparse-server chỉ cho bạn raw structure

Một bẫy mình thấy lặp lại: team chạy thử trên 30 file PDF digital sạch đẹp, kết quả xuất sắc, rồi deploy production gặp đống scan 10 năm tuổi từ phòng kế toán. Pipeline trả rác, mất tuần debug. Đừng phác thảo trên giấy mịn rồi kỳ vọng cùng nét cọ đó hoạt động trên tường bê tông.

Gợi ý thực tế: Hybrid routing. Dùng liteparse-server cho batch tài liệu digital (PDF có text layer, Word, slide). Chuyển sang cloud API chỉ cho file scan khó hoặc layout đặc biệt. Cách này giữ chi phí thấp mà không hy sinh accuracy ở edge case. Viết một hàm router đơn giản: check xem file có text layer không — có thì local, không thì cloud.

---

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