Món khai vị bị quên của pipeline AI

Món khai vị bị quên của pipeline AI

Parser không hào nhoáng như model mới, nhưng nó quyết định RAG ăn được hay nghẹn. LiteParse v2 là dịp tốt để nhìn lại tầng nhập liệu.

9 giờ 12 phút sáng, Minh — tech lead của một team fintech 7 người — mở dashboard RAG và thấy câu trả lời của chatbot nội bộ sai ngay ở dòng đầu tiên. Không phải vì model dở. Không phải vì embedding kém. Cũng không phải vì prompt thiếu lễ phép.

File PDF báo cáo tài chính bị parse lệch bảng. Cột “nợ ngắn hạn” chui sang “tài sản lưu động”, còn footnote thì được kéo lên giữa thân bài như khách gọi món chính nhưng bếp mang nhầm tráng miệng.

Minh nhắn trong Slack: “Có khi mình đang tối ưu món chính, còn khai vị thì sống dở chết dở.”

Và đó là điểm mình muốn bóc hôm nay: trong hệ thống AI production, document parsing không phải bước phụ. Nó là điểm vào của sự thật. LiteParse v2 của LlamaIndex đáng chú ý không chỉ vì dòng “up to 100x fast parsing”, mà vì nó nhắc builder một chuyện rất thực tế: nếu dữ liệu vào đã méo, phần còn lại của pipeline chỉ đang méo nhanh hơn.

Minh họa cho bài Món khai vị bị quên của pipeline AI

Minh họa tóm tắt ý chính của bài viết.

Chuyện đang diễn ra: parser bắt đầu được đối xử như hạ tầng

LiteParse ban đầu được định vị như một PDF extractor chạy được ở nhiều môi trường. Nó trích xuất text có cấu trúc từ PDF và office documents mà không dùng LLM. Sang v2, điểm thay đổi lớn là chuyển sang Rust, nhằm giảm latency và bớt rắc rối khi phân phối so với gói Node/TypeScript trước đó.

Dịch sang tiếng người: thay vì mỗi lần đọc tài liệu lại gọi model để “nhìn và đoán”, LiteParse cố gắng đọc layout, text, cấu trúc tài liệu bằng engine nhẹ hơn, có thể nhúng vào nhiều runtime hơn.

Với builder, đây không phải câu chuyện “tool này nhanh hơn tool kia” đơn thuần. Đây là dấu hiệu một lớp trong AI stack đang trưởng thành: parse layer — tầng biến tài liệu thô thành dữ liệu có thể index, chunk, search và đưa vào model.

Trong nhiều team Việt Nam, tầng này hay bị xem như phần hậu cần: cứ lấy pdfplumber, pypdf, một API OCR nào đó, hoặc quăng thẳng file vào model rồi tính tiếp. Làm demo thì được. Nhưng khi tài liệu có bảng, header/footer, nhiều cột, scan lẫn digital text, hoặc policy dài vài trăm trang, parser bắt đầu quyết định chất lượng hệ thống nhiều hơn bạn tưởng.

Ví dụ cụ thể: một chatbot hỗ trợ compliance trả lời sai điều khoản không nhất thiết vì model hallucination — bịa thông tin nhưng nói rất tự tin. Có thể vì parser đã cắt mất tiêu đề mục, khiến chunk “ngoại lệ” bị tách khỏi điều kiện áp dụng. Model chỉ ăn phần được dọn ra trước mặt nó.

Va chạm của Minh: chọn parser không giống chọn model

Minh có ba lựa chọn cho pipeline tài liệu của team:

  1. LLM-based parsing: dùng model để đọc tài liệu phức tạp, đặc biệt khi layout khó hoặc cần hiểu ngữ nghĩa.
  2. LLM-free parsing: dùng parser truyền thống hoặc engine tối ưu để trích text và layout, như hướng LiteParse theo đuổi.
  3. Hybrid parsing: parser nhẹ xử lý mặc định, chỉ gọi LLM cho trang khó, bảng rối, hoặc tài liệu ngoại lệ.

Nếu chọn theo độ ồn ào trên mạng, Minh dễ nghiêng về LLM-based vì trông “thông minh” hơn. Nhưng trong production, câu hỏi đúng không phải “cách nào hiện đại nhất?”, mà là: loại tài liệu nào xứng đáng trả tiền và latency cho LLM?

Đây là bảng Minh tự vẽ cho team:

| Cách tiếp cận | Hợp khi nào | Điểm mạnh | Điểm đau |
|---|---|---|---|
| LLM-free parser | Tài liệu nhiều, format tương đối ổn định | Rẻ hơn, nhanh hơn, dễ chạy cục bộ | Có thể hụt khi layout quá dị |
| LLM-based parser | Tài liệu ít nhưng phức tạp, cần hiểu ngữ cảnh | Linh hoạt, xử lý case khó tốt hơn | Tốn chi phí, latency cao, khó kiểm soát |
| Hybrid | Production có nhiều loại file khác nhau | Cân bằng chi phí và chất lượng | Cần routing và monitoring kỹ |

Điểm mới ở LiteParse v2 là nó làm phương án LLM-free hấp dẫn hơn cho nhiều workload: Rust giúp câu chuyện đóng gói, chạy đa môi trường và giảm độ trễ có cơ sở kỹ thuật hơn. Rust ở đây không phải bùa hiệu năng; nó quan trọng vì parser là món cần chạy lặp đi lặp lại, gần dữ liệu, đôi khi trong edge runtime, serverless, hoặc pipeline ingest có tải cao.

Nếu mỗi file PDF là một đơn gọi món, parser chậm giống bếp đứng hình lúc khách bắt đầu đông. Model phía sau có xịn mấy cũng phải chờ nguyên liệu sơ chế.

Mổ xẻ lớp parse: nhanh chỉ là một phần của thực đơn

Dòng “up to 100x” dễ làm mắt mình sáng lên, nhất là lúc 2 giờ sáng đọc release note với ly cà phê nguội. Nhưng builder không nên bê con số đó vào roadmap như một lời hứa tuyệt đối. Benchmark luôn phụ thuộc file, môi trường chạy, loại tài liệu và pipeline bao quanh.

Thứ đáng giữ không phải con số tối đa, mà là ba tiêu chí vận hành:

Một: latency tại điểm ingest. Latency là độ trễ xử lý. Nếu hệ thống của bạn phải ingest hàng loạt hợp đồng, invoice, báo cáo kỹ thuật, parser nhanh hơn có thể làm giảm thời gian chờ trước khi tài liệu searchable. Nhưng nếu bottleneck thật nằm ở embedding hoặc reranking, đổi parser chưa chắc làm người dùng cuối thấy nhanh hơn.

Hai: distribution surface. Đây là bề mặt triển khai: parser có chạy được ở đâu, đóng gói ra sao, có kéo theo runtime cồng kềnh không. Một gói Node/TypeScript tiện cho web stack, nhưng không phải team nào cũng muốn đưa Node vào mọi service. Rust mở ra khả năng build binary gọn hơn, nhúng vào nhiều môi trường hơn, và giảm một số ma sát khi deploy.

Ba: layout fidelity. Đây là mức độ giữ đúng cấu trúc tài liệu. Với RAG — retrieval-augmented generation, tức lấy tài liệu liên quan rồi đưa cho model trả lời — layout fidelity nhiều khi quan trọng hơn tốc độ. Một parser nhanh nhưng làm hỏng bảng thì giống phục vụ mang món ra rất nhanh nhưng đặt sai bàn.

Vậy LiteParse v2 đáng để thử ở đâu? Theo mình, không phải mọi nơi. Nó đáng thử ở các pipeline có nhiều PDF/office docs, cần parse nhanh, không muốn gọi LLM ở tầng đầu vào, và tài liệu có layout đủ quan trọng để cần text được “project” theo bố cục.

Framework cho builder: chấm parser bằng lỗi, không bằng lời giới thiệu

Minh cuối cùng không hỏi “tool nào tốt nhất?”. Bạn ấy chuyển sang hỏi: “Lỗi nào mình chấp nhận được?”. Đây là framework mình thấy đáng dùng lại.

1. Lập bộ tài liệu xấu nhất, không phải đẹp nhất

Chọn 20-50 file đại diện cho phần đau nhất trong hệ thống. Không cần số lượng hoành tráng. Cần đúng loại tài liệu hay làm pipeline té:

Đừng benchmark bằng brochure sạch bóng. Production không tử tế vậy đâu.

2. Chấm theo downstream task

Parser không tồn tại để khoe text đẹp. Nó tồn tại để phục vụ việc sau nó. Vì vậy, hãy chấm bằng câu hỏi thực tế:

Lỗi im lặng là loại nguy hiểm nhất. Hệ thống không crash, dashboard vẫn xanh, nhưng người dùng nhận câu trả lời sai.

3. Định tuyến trước khi tối ưu

Nếu tài liệu có nhiều loại, đừng ép một parser làm tất cả. Bạn có thể thiết kế routing đơn giản:

Nếu PDF digital, layout rõ -> LLM-free parser
Nếu scan hoặc bảng phức tạp -> OCR/LLM-based parser
Nếu parser confidence thấp -> đưa vào hàng review hoặc fallback

“Confidence” ở đây không nhất thiết phải là một trường có sẵn từ tool. Bạn có thể tự tính bằng tín hiệu thô: số ký tự quá thấp, tỷ lệ ký tự lạ cao, số trang mất text, bảng bị vỡ dòng bất thường, hoặc chunk quá ngắn/quá dài.

4. Gắn parser vào monitoring

Team thường monitor model response, token cost, latency API. Nhưng parse layer cũng cần log riêng:

Khi LiteParse v2 hoặc bất kỳ parser nào được nâng cấp, bạn không nên chỉ chạy unit test. Hãy replay lại bộ tài liệu xấu nhất và so sánh output. Parser upgrade có thể làm nhanh hơn, nhưng cũng có thể đổi cách xuống dòng khiến chunking thay đổi.

Điều nên giữ, và thứ nên bỏ qua

Giữ lại: tư duy parser là hạ tầng production, không phải đoạn script phụ. LiteParse v2 làm nổi bật một hướng đáng cân nhắc: parser LLM-free, nhẹ, nhanh, phân phối tốt hơn, đặc biệt khi bạn cần ingest nhiều tài liệu và không muốn mọi bước đều phụ thuộc model.

Bỏ qua: cuộc đua lấy con số “nhanh hơn bao nhiêu lần” làm tiêu chí duy nhất. Với hệ thống AI, nhanh hơn mà sai cấu trúc thì chỉ giúp bạn đưa lỗi vào index sớm hơn.

Nếu là mình, mình sẽ không thay parser hiện tại chỉ vì một release mới. Mình sẽ làm một nhánh thử nghiệm trong một buổi chiều:

  1. lấy bộ tài liệu xấu nhất của team;
  2. chạy parser hiện tại và LiteParse v2 song song;
  3. so diff text, bảng, heading;
  4. chạy lại 20 câu hỏi RAG quan trọng;
  5. đo latency ingest và tỷ lệ lỗi im lặng;
  6. quyết định dùng full, dùng fallback, hay chưa đụng tới.

Sau bài này, điều mình muốn bạn nghĩ khác là: đừng xem parser như bước tiền xử lý vô danh. Hãy xem nó như quyết định kiến trúc đầu tiên của pipeline tri thức.

Model là phần chính trên menu, đúng. Nhưng nếu khai vị đã lẫn sạn, đừng ngạc nhiên khi cả bữa ăn bị mất vui.

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

Nguồn tham khảo