Markdown không cứu pipeline tài liệu

Markdown không cứu pipeline tài liệu

LiteParse có PDF-to-Markdown nhanh và open-source, nhưng quyết định thật không phải “có Markdown chưa” mà là parser có khớp downstream của bạn không.

“Có output Markdown chưa?” là câu mình thấy xuất hiện đều như tiếng máy khoan sáng thứ Hai trong nhiều team đang làm RAG trên tài liệu.

Nghe rất hợp lý. PDF thô thì bẩn, text plain thì mất cấu trúc, còn Markdown nhìn sạch sẽ: heading ra heading, bảng ra bảng, list ra list. Vậy khi LiteParse v2.1 nói họ có pipeline PDF-to-Markdown nhanh, open-source, và model-free — tức không dựa vào model AI để parse — phản xạ đầu tiên của nhiều builder sẽ là: “À, thế là thay parser thôi, xong.”

Mình muốn phản biện nhẹ nhưng dứt khoát: Markdown không phải đích đến. Markdown chỉ là dạng gỗ đã được bào phẳng hơn để bạn đóng tiếp thành hệ thống. Nếu mộng gỗ phía sau lệch, cái khung RAG vẫn ọp ẹp.

Điểm đáng bàn của LiteParse lần này không nằm ở chữ “Markdown” cho đẹp mắt, mà nằm ở một quyết định kiến trúc: bạn có muốn một lớp parse nhanh, deterministic hơn, dễ self-host hơn, để kiểm soát đầu vào của indexing hay không?

Sơ đồ minh họa cho bài Markdown không cứu pipeline tài liệu

Sơ đồ tóm tắt ý chính của bài viết.

Chuyện đang diễn ra: parser đang bị kéo ra khỏi bóng tối

Trong nhiều pipeline AI, parser là phần bị coi như việc phụ. Team thường bàn model nào, vector database nào, embedding nào, agent gọi tool ra sao. Còn bước “PDF thành text” thì bị nhét vào một dòng config.

Nhưng ai từng debug tài liệu thật sẽ biết: parser sai thì mọi thứ sau đó đều sai có tổ chức.

LiteParse v2.1 xuất hiện đúng vào chỗ đau này: trước đó LiteParse 2.0 được giới thiệu như công cụ chuyển PDF sang text rất nhanh; câu hỏi người dùng hỏi lại là “benchmark đâu?” và “có Markdown không?”. Bản 2.1 trả lời bằng hướng open-source, model-free, PDF-to-Markdown.

Dịch sang tiếng người: thay vì dùng model để “đoán” cấu trúc tài liệu, parser cố gắng trích xuất theo pipeline không phụ thuộc LLM. Điều này không làm nó tự động đúng hơn trong mọi case, nhưng làm hành vi dễ quan sát, dễ lặp lại, và dễ đưa vào CI hơn.

Với builder, đó mới là phần đáng giữ.

Mổ xẻ: đừng hỏi “Markdown đẹp không”, hãy hỏi “Markdown dùng để làm gì”

Markdown có hai vai trò rất khác nhau.

Vai trò thứ nhất là định dạng dễ đọc. Bạn mở file lên, thấy # Heading, - bullet, bảng bằng pipe, nhìn đã mắt hơn text trần. Vai trò này hữu ích cho review thủ công.

Vai trò thứ hai quan trọng hơn: interface trung gian giữa parse và index. Interface ở đây nghĩa là hợp đồng dữ liệu: downstream sẽ dựa vào heading, đoạn, bảng, list để chunk, gắn metadata, chạy retrieval, hoặc render citation.

Nếu team bạn chỉ cần search toàn văn sơ sơ, Markdown đẹp chưa chắc đáng đổi. Nhưng nếu bạn đang làm:

thì cấu trúc Markdown có thể giúp bạn giữ lại “xương sống” của tài liệu.

Ví dụ cụ thể: một PDF hướng dẫn kỹ thuật có section “Safety Requirements”, bên dưới là bảng gồm “Condition”, “Limit”, “Action”. Nếu parser chỉ nhả text liền tù tì, chunker có thể cắt “Limit” sang chunk khác. Khi user hỏi “trường hợp nhiệt độ vượt ngưỡng thì làm gì?”, retrieval có thể kéo về nửa bảng. Markdown không đảm bảo hết lỗi, nhưng nếu bảng và heading được giữ tương đối ổn, bạn có thêm điểm tựa để chunk theo section thay vì chặt bừa theo số token.

Ở đây, Markdown giống như tấm ván đã được kẻ đường: không tự biến thành cái tủ đẹp, nhưng giúp người thợ biết chỗ nào nên cắt, chỗ nào nên giữ nguyên.

Framework nhỏ: 4 câu hỏi trước khi thay parser

Mình sẽ không khuyên “cứ dùng LiteParse” hay “cứ ở lại parser cũ”. Với team builder, quyết định nên đi qua 4 câu hỏi này.

1. Tài liệu của bạn cần giữ cấu trúc nào?

Đừng nói chung chung “PDF phức tạp”. Hãy liệt kê cụ thể:

Nếu tài liệu chủ yếu là văn bản tuyến tính, Markdown output có thể chỉ là tiện nghi. Nếu tài liệu đầy bảng và section, Markdown trở thành đầu vào quan trọng cho chunking.

2. Bạn ưu tiên latency hay fidelity?

Latency là độ trễ xử lý; fidelity là mức giữ đúng cấu trúc gốc. Parser nhanh rất hấp dẫn khi ingest hàng loạt hoặc chạy gần real-time. Nhưng nếu nhanh mà làm hỏng bảng trọng yếu, downstream sẽ trả giá bằng câu trả lời sai.

LiteParse nhấn mạnh hướng nhanh và model-free. Đây là lợi thế nếu bạn muốn pipeline nhẹ, có thể chạy ổn định, ít phụ thuộc API model. Nhưng bạn vẫn cần tự kiểm với tài liệu của mình, vì parser PDF luôn va vào đủ kiểu layout kỳ quặc.

3. Bạn có cần deterministic behavior không?

Deterministic behavior nghĩa là cùng một input thì output lặp lại ổn định. Với pipeline production, đặc biệt khi cần audit, deterministic đáng giá hơn cảm giác “thông minh”.

Parser model-free thường dễ snapshot, diff, test regression hơn. Bạn có thể lưu output Markdown, so sánh phiên bản parser mới với phiên bản cũ, và phát hiện khi bảng bị parse khác đi.

Nếu parser dựa nhiều vào LLM, đôi khi output mềm dẻo hơn, nhưng cũng khó khóa hành vi hơn. Không xấu, chỉ là tradeoff.

4. Bạn có đo parser bằng metric downstream không?

Đây là chỗ nhiều team trượt tay. Họ benchmark parser bằng mắt: file Markdown nhìn sạch là duyệt.

Sai nhẹ thôi nhưng đau lâu.

Hãy đo bằng thứ downstream cần:

Nếu parser mới làm Markdown đẹp hơn nhưng answer quality không tăng, hoặc ingestion cost phình ra vì bạn phải sửa hậu kỳ nhiều hơn, thì đó chỉ là lớp sơn bóng.

Điều đáng giữ: open-source và model-free là quyền kiểm soát

Phần mình thấy có giá trị nhất ở LiteParse v2.1 không phải là “giờ có Markdown”, mà là tổ hợp ba thứ: open-source, model-free, và nhắm vào PDF-to-Markdown pipeline.

Open-source giúp team soi được cách công cụ xử lý, tự chạy thử, và nếu cần thì vá quanh workflow của mình. Với dữ liệu nhạy cảm, đây là điểm thực dụng: không phải tài liệu nào cũng tiện đẩy qua dịch vụ bên ngoài.

Model-free giúp giảm một lớp bất định. Bạn không cần gọi LLM chỉ để biến PDF thành text có cấu trúc. Trong nhiều hệ thống, LLM nên được dùng ở bước cần suy luận, không phải bước cơ khí lặp đi lặp lại của ingestion.

PDF-to-Markdown giúp chuẩn hóa đầu vào cho indexing. Không phải chuẩn hoàn hảo, nhưng đủ phổ biến để dễ đọc, dễ diff, dễ review, dễ đưa vào pipeline.

Hình dung thế này: team bạn đang có 10.000 PDF nội bộ. Giả sử đây là ví dụ minh họa, không phải số liệu benchmark. Nếu mỗi lần đổi parser bạn chỉ nhìn vài file mẫu, bạn sẽ bỏ sót lỗi ở nhóm tài liệu cũ, scan xấu, hoặc bảng nhiều trang. Nhưng nếu output là Markdown có thể lưu lại, bạn có thể chọn 100 file đại diện, chạy parser cũ và mới, rồi diff các vùng quan trọng: heading, bảng, thứ tự đoạn. Đó là cách builder kiểm soát pipeline, không phải cầu may.

Điều nên bỏ qua: cuộc đua “parser nhanh nhất” nếu bạn chưa có bộ test

Mình không phủ nhận tốc độ quan trọng. Ingestion chậm có thể làm nghẽn cả sản phẩm, nhất là khi người dùng upload tài liệu và chờ kết quả. Nhưng “nhanh nhất” là nhãn chỉ có nghĩa khi đặt cạnh workload thật của bạn.

Bạn cần tự tạo một bộ test nhỏ trước khi thay parser:

/doc-fixtures
  /easy
    policy_text_only.pdf
  /tables
    invoice_multi_page.pdf
    pricing_matrix.pdf
  /layout
    two_column_manual.pdf
  /noisy
    scanned_contract.pdf
  expected_notes.md

Trong expected_notes.md, đừng viết kỳ vọng quá học thuật. Chỉ cần ghi những điều không được vỡ:

- pricing_matrix.pdf: bảng giá phải giữ đủ cột Plan, Limit, Overage.
- two_column_manual.pdf: thứ tự đọc phải đi hết cột trái rồi cột phải theo section.
- invoice_multi_page.pdf: header/footer lặp lại không được thành nội dung chính.
- scanned_contract.pdf: nếu không hỗ trợ tốt, phải fail rõ thay vì trả text rác.

Sau đó chạy parser mới, đưa Markdown vào cùng chunker và retriever hiện tại. Đừng thay cả parser, chunker, embedding cùng lúc, vì lúc hỏng bạn sẽ không biết vết nứt nằm ở đâu. Làm mộc mà vừa đổi gỗ, đổi cưa, đổi thước trong một buổi thì đừng trách cái khung bị lệch.

Một checklist gọn cho một buổi chiều:

  1. Chọn 20–50 PDF đại diện, có cả file xấu.
  2. Parse bằng pipeline hiện tại và LiteParse v2.1.
  3. Lưu output Markdown vào repo test, không chỉ xem trên màn hình.
  4. So sánh các vùng có cấu trúc: heading, bảng, list, thứ tự đoạn.
  5. Chạy lại 20 câu hỏi retrieval cũ, đo bằng pass/fail thủ công trước.
  6. Nếu ổn, mới tính chuyện benchmark throughput và chi phí vận hành.

Cách nghĩ mới: parser là hợp đồng, không phải phụ kiện

Sau bài này, thứ mình muốn bạn nghĩ khác rất cụ thể: đừng chọn parser vì output trông hiện đại hơn; hãy chọn parser vì nó tạo ra hợp đồng dữ liệu tốt hơn cho downstream.

LiteParse v2.1 đáng để builder để mắt vì nó đưa Markdown vào một pipeline nhanh, open-source, model-free. Nhưng quyết định đúng không nằm ở trang launch. Nó nằm ở bộ tài liệu thật, bộ test parse thật, và câu hỏi: output này có giúp retrieval, citation, audit, và vận hành ổn hơn không?

Markdown là vật liệu tốt. Còn đóng được cái bàn chắc hay không, vẫn là tay nghề pipeline của bạn.

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

Nguồn tham khảo