anydoc: Công cụ mã nguồn mở chuyển Word, PowerPoint, Excel và PDF sang Markdown

Đống tài liệu văn phòng thường là nút thắt trước khi đưa dữ liệu vào trợ lý AI: Word có tiêu đề và chú thích, PowerPoint có ghi chú người thuyết trình, Excel có bảng lớn, còn PDF có thể là văn bản thật hoặc chỉ là ảnh scan. anydoc là một thư viện mã nguồn mở của Firecrawl nhằm giải bài toán đó: chuyển nhiều định dạng tài liệu về một đầu ra GitHub-Flavored Markdown (GFM) có cấu trúc.

Đây không phải một “AI document parser” chạy mô hình ngôn ngữ. Lõi anydoc được viết bằng Rust, chuyển đổi cục bộ và không dùng mô hình ML. Chính vì vậy, cần phân biệt rõ: PDF có lớp văn bản có thể được xử lý tại máy; PDF scan hoặc trang chỉ có ảnh thì anydoc không tự OCR. Người dùng chỉ gửi tài liệu sang Firecrawl Parse khi chủ động bật OCR dạng hosted.

anydoc là gì và vì sao đáng chú ý?

Kho mã firecrawl/anydoc được tạo trên GitHub ngày 03/08/2026 theo timestamp API của GitHub. Tại thời điểm kiểm tra ngày 28/08/2026, repo có khoảng 18,9 nghìn sao; đây là chỉ dấu quan tâm cộng đồng thay đổi theo thời gian, không phải một thông số cố định của sản phẩm.

Điểm cốt lõi là “một tài liệu vào, Markdown ra”. Thay vì mỗi định dạng có một kiểu xuất riêng, anydoc đưa dữ liệu qua document model dùng chung rồi dùng một bộ dựng Markdown. Điều này hữu ích khi một quy trình phải nhận lẫn lộn tài liệu cũ và mới nhưng muốn đưa vào kho tri thức, tìm kiếm ngữ nghĩa hoặc agent theo một định dạng thống nhất.

Những loại tệp anydoc hỗ trợ

Nhóm	Phần mở rộng được README liệt kê
Word	.doc, .docx, .docm
PowerPoint	.ppt, .pps, .pot, .pptx, .pptm, .ppsx, .ppsm
Excel	.xls, .xlsx, .xlsm, .xlsb
OpenDocument	.odt, .ods, .odp
Khác	.rtf, .epub, .csv, .pdf

Với đa số định dạng, anydoc nhận dạng từ nội dung byte như PDF header, OLE stream hoặc ZIP package thay vì chỉ tin vào đuôi tệp. CSV là ngoại lệ: vì không có signature đặc trưng, người dùng cần giữ đúng phần mở rộng hoặc chỉ định format.

Markdown đầu ra giữ lại được những gì?

Theo README, đầu ra có thể giữ heading kèm anchor, định dạng cơ bản, liên kết và tham chiếu nội bộ, danh sách lồng nhau, task list, blockquote, footnote/endnote, speaker notes và bảng có hàng tiêu đề hoặc ô gộp. Công thức trong Word/PowerPoint, OpenDocument/EPUB hoặc RTF được chuyển sang cú pháp toán GFM/LaTeX dạng inline hoặc block.

Điều đó không có nghĩa Markdown sẽ tái hiện nguyên vẹn bố cục trang. Markdown là định dạng chữ có cấu trúc, không phải bản sao pixel-perfect của bản trình chiếu hay bảng tính. Với ảnh/đối tượng nhúng, README nêu Markdown xuất alt text; bytes gốc vẫn nằm ở document model để ứng dụng tích hợp tự xử lý khi cần.

PDF scan: giới hạn cần hiểu đúng trước khi dùng

Đây là ranh giới quan trọng nhất. AnyDoc xử lý PDF có text cục bộ thông qua pdf-inspector. Nếu PDF có trang scan hoặc image-only, quá trình local không tự nhận dạng chữ mà trả lỗi NeedsOcr, kèm thông tin các trang cần OCR.

Nếu chấp nhận dùng dịch vụ hosted, CLI có tùy chọn OCR hosted; Node dùng “ocr: ‘hosted’” và Python dùng “ocr=’hosted’”. Khi bật tùy chọn này, toàn bộ tài liệu cần OCR được gửi tới Firecrawl Parse vì Parse không có cơ chế chọn riêng từng trang. README nói không cần đăng ký ở hạn mức mặc định; API key Firecrawl dùng để tăng hạn mức. Rust crate không có tùy chọn OCR và không gọi mạng.

Vì thế, đừng gắn nhãn “hoàn toàn offline” cho mọi tình huống. Chuyển đổi local và demo WASM là local; hosted OCR là một luồng xử lý khác, cần được cân nhắc về dữ liệu và chính sách tổ chức trước khi bật.

Tốc độ 4,4 ms nói lên điều gì?

README hiện công bố benchmark trên 100 tài liệu thực tế thuộc 14 định dạng, so sánh với sáu công cụ khác. AnyDoc ghi nhận median 4,4 ms mỗi tài liệu trong phép đo đó. Tuy nhiên, đây là số liệu benchmark có điều kiện: chạy một lần warm conversion trên Ryzen 9 9950X3D, Windows 11 và 64 GB DDR5-6400.

Bộ benchmark không phân phối corpus; phần chất lượng dùng LLM judge và đối chiếu ảnh sáu trang đầu để chấm completeness, structure, formatting và cleanliness. Hơn nữa, benchmark PDF nằm ngoài scope của harness, còn việc tính process spawn không hoàn toàn giống nhau giữa anydoc/thư viện Python với các CLI. Vì vậy, hãy xem 4,4 ms là mô tả benchmark của dự án, không phải cam kết tốc độ cho mọi tệp, máy hoặc pipeline.

Cách cài anydoc: CLI, Node.js, Python, Rust và trình duyệt

Môi trường	Gói hoặc cách dùng chính thức	Lưu ý
CLI	npx @firecrawl/anydoc report.docx	Có thể cài global bằng npm install -g @firecrawl/anydoc
Node.js	npm install @firecrawl/anydoc	README yêu cầu Node 20 trở lên
Python	pip install firecrawl-anydoc	Import là anydoc; Python 3.10 trở lên
Rust	cargo add anydoc	Lõi local, không có OCR hosted option
Browser/WASM	npm install @firecrawl/anydoc-wasm	Nên dùng Web Worker để không nghẽn UI

Ví dụ CLI tối giản:

npx @firecrawl/anydoc report.docx

Lệnh sẽ in Markdown ra standard output, phù hợp để lưu vào file hoặc đưa tiếp vào một bước xử lý khác. Với tài liệu thật, hãy thử trước bằng một vài file đại diện để kiểm tra bảng, ghi chú, công thức và ảnh có phù hợp với nhu cầu downstream hay không.

Agent Skill: đưa tài liệu vào workflow agent

Repo phát hành skill “convert-documents-to-markdown”. Lệnh cài do README nêu là:

npx skills add firecrawl/anydoc

Skill hướng dẫn agent gọi CLI để chuyển tài liệu. README nêu Claude Code, Codex, Cursor, OpenCode và những agent tương thích Agent Skills. Đây là tích hợp theo chuẩn skill, không có nghĩa mọi agent sẽ tự động đọc mọi file mà không cần quyền truy cập file, môi trường chạy và cấu hình phù hợp.

Demo trên trình duyệt có thực sự không upload file?

Demo chính thức chạy gói WebAssembly của anydoc trong browser và trang này ghi rõ việc chuyển đổi diễn ra local, không upload tài liệu. Đây là cách an toàn để thử file không scan khi chưa muốn cài môi trường phát triển.

Khẳng định trên áp dụng cho demo/WASM local. Không nên suy rộng sang trường hợp bạn chủ động dùng hosted OCR hoặc tự tích hợp một ứng dụng có luồng mạng khác. Nếu tài liệu nhạy cảm, hãy luôn kiểm tra tuỳ chọn OCR, log mạng và chính sách dữ liệu của tổ chức.

anydoc phù hợp với ai?

Nhóm xây knowledge base hoặc RAG, cần chuẩn hóa nhiều loại tài liệu trước khi lập chỉ mục.
Người làm agent cần biến tệp văn phòng thành đầu vào chữ có cấu trúc, dễ kiểm tra và phiên bản hóa.
Lập trình viên muốn một thư viện Rust/Node/Python có đầu ra Markdown thống nhất.
Người cần thử nhanh tài liệu text-based PDF hoặc Office ngay trên browser qua demo WASM.

Nó sẽ không thay thế một OCR engine local cho tài liệu scan, cũng không phải công cụ dựng lại thiết kế PowerPoint/Word. Giá trị chính nằm ở chuẩn hóa nội dung và cấu trúc để máy, pipeline hoặc AI tiêu thụ dễ hơn.

Kết luận

AnyDoc đáng để theo dõi nếu “đầu vào lộn xộn” là điểm nghẽn trong workflow tài liệu. Dự án lựa chọn hướng rõ ràng: chuyển đổi local bằng Rust, Markdown thống nhất cho nhiều định dạng và chỉ mở đường sang Firecrawl Parse khi người dùng thật sự cần OCR hosted. Cách hiểu đúng giới hạn PDF scan và bối cảnh benchmark sẽ giúp bạn thử công cụ này đúng kỳ vọng.