anydoc 深度評測：Firecrawl 用 Rust 打造的萬用文件轉 Markdown 工具

TL;DR：給大模型餵文件時，格式轉換品質直接決定 RAG 效果——表格丟了、標題亂了、公式沒了，資訊就丟了。Firecrawl 團隊用 Rust 從零打造了 anydoc，一個函式庫覆蓋 14 種辦公格式（Word/PPT/Excel/PDF/EPUB/RTF/CSV/OpenDocument），中位轉換速度僅 4.4 毫秒，品質評分全面輾壓 Pandoc、Markitdown、Docling 等競品。GitHub 上線不到三週已斬獲 17,000+ Star。本文從架構原理到部署實戰，帶你徹底搞懂這個 2026 年最熱的文件預處理工具。

一、anydoc 是什麼？Firecrawl 團隊的「文件預處理引擎」

anydoc 是 Firecrawl 團隊於 2026 年 8 月初開源的 Rust 函式庫，專門解決一個問題：把各種辦公文件格式統一轉換成乾淨的 GitHub-Flavored Markdown。

Firecrawl 本身是一個知名的網頁抓取與解析 API 服務（Y Combinator 支援的專案），他們在做文件解析時遇到了一個普遍痛點：市面上沒有一個函式庫能可靠地處理所有常見文件格式。開發者不得不拼湊四五個工具——每個工具有自己的相依性、輸出格式和失敗模式。於是他們決定自己造輪子，而且一造就是兩個：

• pdf-inspector：專攻 PDF，13k Star，負責判斷每頁是文字還是掃描件，決定是否需要 OCR
• anydoc：處理其他所有格式（Word/PPT/Excel/EPUB/RTF/CSV/OpenDocument），同時內建 pdf-inspector 處理文字型 PDF

兩個函式庫，同一套設計哲學：純 Rust、本機執行、無 API Key、無系統相依、Markdown 輸出。

文件位元組
  │
  ├─► 格式偵測          → 基於內容標記，不依賴副檔名
  │
  ├─► 格式解析器         → 每種格式一個解析器（doc/docx/ppt/pptx/xls/
  │                        xlsx/odt/ods/odp/rtf/epub/csv）
  │         │
  │         └─► Document → 共用文件模型：塊、行內、表格、腳註、資源
  │               │
  │               └─► GFM 序列化器 → Markdown
  │
  └─► PDF → pdf-inspector → 直接輸出 Markdown

關鍵設計：所有格式都匯入同一個文件模型和序列化器。這意味著修一個格式的 bug（例如表格轉義），其他所有格式自動受益。

截至 2026 年 8 月 21 日，anydoc 的 GitHub 資料：

二、為什麼文件轉換對 RAG 至關重要？

在 RAG（檢索增強生成）架構中，大模型的知識來源不僅是訓練資料，還包括你餵給它的私有文件。這些文件可能是：

• 客戶上傳的 Word 合約
• 財務部門匯出的 Excel 報表
• 產品經理做的 PPT 簡報
• 技術團隊寫的 PDF 白皮書
• 歷史遺留的 .doc 檔案（2003 年之前的格式）

格式丟失 = 資訊丟失。如果你的轉換工具把表格拍平成純文字、把標題層級搞亂、把公式變成亂碼，大模型拿到的就是殘缺的資訊。RAG 的效果直接打折。

舉個具體例子：一份 Word 文件裡有張銷售資料表，包含地區、季度、銷售額三欄。劣質轉換工具可能輸出：

地區 季度 銷售額
華東 Q1 100萬
華東 Q2 150萬

表格結構丟了，大模型無法理解「地區」和「季度」是欄名，「100萬」是「華東 Q1」的銷售額。而 anydoc 輸出標準 Markdown 表格：

| 地區 | 季度 | 銷售額 |
|------|------|--------|
| 華東 | Q1   | 100萬  |
| 華東 | Q2   | 150萬  |

結構完整，大模型能準確理解每個欄位的語意。

這就是為什麼文件轉換品質直接影響 RAG 效果。anydoc 的設計目標就是：無論輸入什麼格式，輸出都是結構完整、語意清晰的 Markdown。

三、支援的 14 種格式詳解

anydoc 覆蓋 14 種常見辦公格式，是目前唯一做到「全格式覆蓋」的開源函式庫：

3.1 格式偵測：不依賴副檔名

anydoc 的格式偵測基於檔案內容標記，而不是副檔名。這意味著即使檔案被錯誤命名（例如 report.pdf 實際上是個 Word 文件），anydoc 也能正確識別並轉換。

// Rust
Format::from_bytes(&bytes); // Some(Format::Docx), or None when nothing matches
Format::from_extension("pptm"); // Some(Format::Pptx)
Format::from_path(Path::new("report.odt")); // Some(Format::Odt)

# Python
import anydoc
anydoc.format_from_bytes(data)  # <Format.DOCX: ...>
anydoc.format_from_extension("pptm")  # <Format.PPTX: ...>

偵測原理： - PDF：讀取 PDF 標頭標記 %PDF- - RTF：讀取 RTF 開放群組 {\rtf - OLE 格式（.doc/.ppt/.xls）：讀取 OLE 串流名稱 - ZIP 封裝格式（.docx/.pptx/.xlsx/.odt 等）：讀取 ZIP 封裝的 mimetype 和內容類型 - CSV：無內容標記，依賴副檔名或顯式指定

3.2 轉換品質：保留完整文件結構

anydoc 不僅提取文字，還保留完整的文件結構：

• 標題層級：H1-H6 帶錨點
• 文字樣式：粗體、斜體、刪除線、行內程式碼
• 程式碼區塊：帶語法標記
• 清單：有序、無序、巢狀、任務清單（保留原始編號）
• 表格：合併儲存格、表頭行
• 引用區塊：blockquote
• 腳註和尾註
• 公式：Word/PowerPoint 的 OMML、OpenDocument/EPUB 的 MathML、RTF 公式都轉換為 GitHub 風格的 LaTeX 數學標記（$...$ 行內，$$...$$ 區塊級）
• 嵌入資源：圖片和嵌入物件在 Markdown 中渲染為 alt 文字，原始位元組保留在文件模型中（帶媒體類型標記）

四、技術架構：Rust 實作，4.4ms 中位速度的秘密

anydoc 的效能來自三個核心設計決策：

4.1 純 Rust 實作，無外部相依

anydoc 從零用 Rust 編寫，不依賴 LibreOffice、Python 函式庫或其他外部服務。Rust 的零成本抽象和記憶體安全特性讓 anydoc 能在毫秒級完成轉換，同時避免記憶體洩漏和段錯誤。

4.2 共用文件模型 + 單一系列化器

所有格式的解析器都輸出同一個 Document 結構：

pub struct Document {
    pub blocks: Vec<Block>,      // 段落、標題、清單、表格等
    pub inlines: Vec<Inline>,    // 粗體、斜體、連結等
    pub tables: Vec<Table>,      // 表格
    pub footnotes: Vec<Footnote>, // 腳註
    pub assets: Vec<Asset>,      // 圖片、嵌入物件
}

然後由一個 GFM（GitHub-Flavored Markdown）序列化器統一渲染。這意味著： - 一致性：無論輸入是 .docx 還是 .rtf，輸出的 Markdown 格式完全一致 - 可維護性：修一個 bug，所有格式受益 - 可擴充性：新增格式只需實作解析器，序列化邏輯複用

4.3 無 ML 模型，純規則解析

anydoc 不使用機器學習模型，而是基於格式規範的規則解析。這使得： - 速度快：中位轉換時間 4.4ms（在 Ryzen 9 9950X3D 上測試） - 可預測：沒有模型推論的不確定性 - 資源佔用低：不需要 GPU，CPU 即可執行

對於掃描件 PDF，anydoc 會標記為「需要 OCR」，交給外部視覺管道處理（例如 Firecrawl 的 Fire-PDF 服務）。

4.4 綁定設計：不阻塞主執行緒

• Node.js：轉換在 libuv 執行緒池執行，不阻塞事件迴圈
• Python：釋放 GIL，其他執行緒繼續執行
• TypeScript 類型和 Python stub：隨套件提供，IDE 自動補全友好

五、與 Pandoc / Markitdown / Docling 對比

anydoc 不是唯一的文件轉換工具。讓我們看看它與主流競品的對比：

5.1 功能覆蓋對比

關鍵差異： - Pandoc 支援格式最多（40+），但輸出品質不如 anydoc（見下文基準測試），且 Haskell 相依讓整合複雜 - Markitdown 是 Python 函式庫，只支援 6 種格式，速度較慢（134.8ms vs 4.4ms） - Docling 專注 PDF 和圖像文件，需要 PyTorch，只支援 4 種格式 - LibreOffice 是完整的辦公套件，體積龐大（數百 MB），轉換速度慢（1129.5ms） - Mammoth 只支援 docx，但品質不錯（70 分）

5.2 官方基準測試

Firecrawl 團隊在 100 份真實文件上測試了各工具的效能和品質（使用 Claude Sonnet 5 作為 LLM 評審）：

關鍵發現： - 速度：anydoc 比最快的競品（mammoth）快 12 倍，比最慢的（libreoffice）快 256 倍 - 品質：anydoc 在所有測試格式上都獲得最高分 - 覆蓋：anydoc 是唯一支援全部 14 種格式的工具

5.3 分格式品質對比

注意：mammoth 的 70 分僅基於 docx 一種格式，而 anydoc 的 81 分跨越全部 14 種格式。分格式對比才是公平的。

5.4 選擇建議

• 選 anydoc：需要處理多種格式、追求速度和品質、希望零相依
• 選 Pandoc：需要格式轉換（如 Markdown → PDF）、不介意 Haskell 相依
• 選 Markitdown：已有 Python 生態、只需基礎格式支援
• 選 Docling：專注 PDF 和圖像文件、有 GPU 資源
• 選 LibreOffice：需要完整的辦公套件功能、不介意體積和速度

六、本機部署實戰：三種方式任選

anydoc 提供三種部署方式，適應不同場景：

6.1 CLI 工具：最快上手

# 使用 npx 臨時執行（首次執行會下載預編譯二進位）
npx @firecrawl/anydoc report.docx               # 輸出到 stdout
npx @firecrawl/anydoc slides.pptx -o slides.md  # 輸出到檔案
npx @firecrawl/anydoc - --format csv < data.csv # 從 stdin 讀取

# 全域安裝
npm install -g @firecrawl/anydoc
anydoc report.docx -o report.md

適用場景：快速測試、腳本整合、CI/CD 管道。

6.2 Python SDK：RAG 管道首選

pip install firecrawl-anydoc

import anydoc

# 從檔案路徑轉換
markdown = anydoc.to_markdown("contract.docx")
print(markdown)

# 從位元組轉換（自動偵測格式）
with open("report.pdf", "rb") as f:
    data = f.read()
markdown = anydoc.to_markdown_bytes(data)

# 顯式指定格式（CSV 需要）
markdown = anydoc.to_markdown_bytes(csv_data, "csv")

# 取得完整文件模型（包含嵌入資源）
document = anydoc.to_document("presentation.pptx")
print(document.blocks)  # 存取文件結構
print(document.assets)  # 存取嵌入的圖片

適用場景：Python RAG 管道、批次處理、與 LangChain/LlamaIndex 整合。

6.3 Node.js SDK：Web 應用整合

npm install @firecrawl/anydoc

import { toMarkdown, toDocument } from '@firecrawl/anydoc';

// 從檔案路徑轉換
const markdown = await toMarkdown('contract.docx');

// 從位元組轉換
const buffer = fs.readFileSync('report.pdf');
const markdown = await toMarkdownBytes(buffer);

// 取得完整文件模型
const document = await toDocument(buffer);
console.log(document.blocks);

適用場景：Node.js Web 應用、Express/Fastify 後端、即時文件預覽。

6.4 WebAssembly：瀏覽器端執行

anydoc 甚至可以編譯為 WebAssembly，在瀏覽器中本機執行，檔案不會上傳到伺服器：

npm install @firecrawl/anydoc-wasm

import init, { toMarkdownBytes } from '@firecrawl/anydoc-wasm';

await init();

const file = document.getElementById('file-input').files[0];
const buffer = await file.arrayBuffer();
const markdown = toMarkdownBytes(new Uint8Array(buffer));

適用場景：隱私敏感場景、離線應用、減少伺服器負載。

6.5 Docker 部署

anydoc 沒有官方 Docker 映像，但可以自己建構：

FROM node:20-alpine

RUN npm install -g @firecrawl/anydoc

WORKDIR /app
CMD ["anydoc"]

docker build -t anydoc .
docker run -v $(pwd):/app anydoc report.docx -o report.md

適用場景：容器化部署、Kubernetes 叢集、微服務架構。

七、實戰：搭建文件預處理 Pipeline（anydoc + RAG）

讓我們搭建一個完整的 RAG 管道，處理使用者上傳的各種文件：

7.1 架構設計

使用者上傳文件 → anydoc 轉換 → 文字分塊 → Embedding → 向量資料庫 → 檢索 → LLM 生成

7.2 Python 實作

import anydoc
import os
from pathlib import Path
from langchain.text_splitter import RecursiveCharacterTextSplitter
from langchain.embeddings import OpenAIEmbeddings
from langchain.vectorstores import Chroma

# 1. 文件轉換
def convert_document(file_path: str) -> str:
    """將任意格式文件轉換為 Markdown"""
    try:
        markdown = anydoc.to_markdown(file_path)
        return markdown
    except anydoc.ConvertError as e:
        print(f"轉換失敗: {e}")
        return None

# 2. 文字分塊
def chunk_text(text: str, chunk_size: int = 1000, overlap: int = 200):
    """將長文字分割成小塊"""
    splitter = RecursiveCharacterTextSplitter(
        chunk_size=chunk_size,
        chunk_overlap=overlap,
        separators=["\n## ", "\n### ", "\n\n", "\n", " ", ""]
    )
    return splitter.split_text(text)

# 3. 建構向量資料庫
def build_vector_store(chunks: list, collection_name: str = "documents"):
    """將文字塊轉換為向量並儲存"""
    embeddings = OpenAIEmbeddings()
    vectorstore = Chroma.from_texts(
        texts=chunks,
        embedding=embeddings,
        collection_name=collection_name
    )
    return vectorstore

# 4. 完整管道
def process_document_pipeline(file_path: str):
    """完整的文件處理管道"""
    # 轉換
    print(f"正在轉換: {file_path}")
    markdown = convert_document(file_path)
    if not markdown:
        return None

    # 儲存 Markdown（可選）
    output_path = Path(file_path).with_suffix('.md')
    output_path.write_text(markdown, encoding='utf-8')
    print(f"已儲存 Markdown: {output_path}")

    # 分塊
    chunks = chunk_text(markdown)
    print(f"分割為 {len(chunks)} 個塊")

    # 建構向量庫
    vectorstore = build_vector_store(chunks)
    print("向量資料庫建構完成")

    return vectorstore

# 5. 批次處理
def batch_process(directory: str):
    """批次處理目錄中的所有文件"""
    supported_extensions = {
        '.doc', '.docx', '.docm',
        '.ppt', '.pptx', '.pptm',
        '.xls', '.xlsx', '.xlsm',
        '.odt', '.ods', '.odp',
        '.rtf', '.epub', '.csv', '.pdf'
    }

    for file_path in Path(directory).rglob('*'):
        if file_path.suffix.lower() in supported_extensions:
            print(f"\n處理: {file_path}")
            process_document_pipeline(str(file_path))

# 使用範例
if __name__ == "__main__":
    # 單檔處理
    vectorstore = process_document_pipeline("contract.docx")

    # 批次處理
    # batch_process("./documents")

7.3 與 LangChain 整合

from langchain.document_loaders import BaseLoader
from langchain.schema import Document
import anydoc

class AnyDocLoader(BaseLoader):
    """anydoc 文件載入器"""

    def __init__(self, file_path: str):
        self.file_path = file_path

    def load(self) -> list[Document]:
        """載入並轉換文件"""
        markdown = anydoc.to_markdown(self.file_path)
        metadata = {"source": self.file_path}
        return [Document(page_content=markdown, metadata=metadata)]

# 使用
loader = AnyDocLoader("report.pdf")
docs = loader.load()

# 與 LangChain 管道整合
from langchain.chains import RetrievalQA
from langchain.llms import OpenAI

qa = RetrievalQA.from_chain_type(
    llm=OpenAI(),
    chain_type="stuff",
    retriever=vectorstore.as_retriever()
)

result = qa.run("這份報告的主要發現是什麼？")
print(result)

7.4 錯誤處理

anydoc 的錯誤類型：

import anydoc

try:
    markdown = anydoc.to_markdown("document.pdf")
except anydoc.ConvertError as e:
    if isinstance(e, anydoc.EncryptedError):
        print("文件已加密")
    elif isinstance(e, anydoc.UnsupportedError):
        print("不支援的格式")
    elif isinstance(e, anydoc.MalformedError):
        print("文件結構損壞")
    elif isinstance(e, anydoc.ResourceLimitError):
        print("超出資源限制")
    else:
        print(f"轉換錯誤: {e}")
except OSError as e:
    print(f"檔案讀取錯誤: {e}")

八、效能基準實測

為了驗證 anydoc 的實際效能，我們在不同場景下進行了測試：

8.1 測試環境

• CPU: AMD Ryzen 9 7950X
• 記憶體: 64GB DDR5
• 作業系統: Ubuntu 22.04
• Python: 3.11
• anydoc: 最新版

8.2 單檔轉換速度

結論：絕大多數文件在 10ms 內完成轉換，符合官方宣稱的「單位數毫秒」效能。

8.3 批次處理效能

處理 100 份混合格式文件：

8.4 與競品實測對比

我們選取了 10 份典型文件，對比各工具的轉換時間和品質：

anydoc 在速度上領先一個數量級，品質評分也最高，記憶體佔用最低。

九、局限性與注意事項

儘管 anydoc 表現出色，但仍有一些局限需要注意：

9.1 不支援的格式

• 圖片型 PDF：掃描件 PDF 需要外部 OCR 服務（如 Tesseract、Firecrawl Fire-PDF）
• 加密文件：密碼保護的文件無法轉換，會拋出 Encrypted 錯誤
• 舊版 Mac 格式：.pages、.numbers、.key 不支援
• 圖片格式：.jpg、.png 等圖片檔案不直接支援（需先 OCR）

9.2 已知限制

• 複雜排版：多欄版面配置、文字環繞圖片等複雜排版可能丟失
• 嵌入物件：Excel 圖表、Word 嵌入的 OLE 物件僅保留 alt 文字
• 巨集和腳本：VBA 巨集、JavaScript 腳本不轉換
• 超大檔案：超過資源限制的文件會拋出 ResourceLimit 錯誤

9.3 版本相容性

• 舊版 Office：.doc/.ppt/.xls（Office 97-2003）支援，但品質不如 .docx/.pptx/.xlsx
• WPS 格式：WPS 生成的文件通常相容，但未官方測試
• Google Docs：匯出為 .docx 後轉換效果最佳

9.4 生產環境建議

1. 錯誤處理：始終捕獲 ConvertError，記錄失敗檔案
2. 資源限制：大檔案設定逾時，避免阻塞
3. 格式驗證：轉換後檢查輸出品質，必要時人工審核
4. 備份原始檔案：轉換前保留原始文件
5. 監控效能：記錄轉換時間，發現異常及時排查

十、常見問題 FAQ

1. anydoc 和 pdf-inspector 有什麼區別？

pdf-inspector 專注於 PDF，負責判斷每頁是文字還是掃描件，決定是否需要 OCR。anydoc 處理其他所有格式（Word/PPT/Excel/EPUB/RTF/CSV/OpenDocument），同時內建 pdf-inspector 處理文字型 PDF。兩者配合覆蓋所有常見文件格式。

2. anydoc 需要 API Key 嗎？

不需要。anydoc 是完全本機執行的開源函式庫，無需 API Key、無需網路連線、無需外部服務。所有轉換在本機完成。

3. anydoc 支援中文文件嗎？

支援。anydoc 基於 Unicode，完美支援中文、日文、韓文等多語言文件。轉換後的 Markdown 保留原始語言和編碼。

4. 如何處理掃描件 PDF？

anydoc 只能處理文字型 PDF。對於掃描件，需要： 1. 使用 anydoc 偵測哪些頁面需要 OCR 2. 將掃描件頁面交給 OCR 服務（如 Tesseract、Firecrawl Fire-PDF） 3. 合併結果

範例程式碼：

import anydoc

try:
    markdown = anydoc.to_markdown("scanned.pdf")
except anydoc.UnsupportedError:
    # 呼叫 OCR 服務
    ocr_result = call_ocr_service("scanned.pdf")
    markdown = ocr_result.text

5. anydoc 可以商業使用嗎？

可以。anydoc 採用 MIT 授權證，允許商業使用、修改、散佈，無需支付費用。

十一、總結評價

優點

✅ 格式覆蓋全面：14 種格式，唯一做到全覆蓋的開源函式庫
✅ 效能卓越：中位速度 4.4ms，比競品快 12-256 倍
✅ 品質最高：LLM 評審打分 81，全面領先
✅ 零相依：純 Rust 實作，無需外部服務
✅ 多語言綁定：Rust/Node.js/Python/WebAssembly
✅ 開源免費：MIT 授權證，可商用

缺點

❌ 不支援掃描件 PDF：需要外部 OCR 服務
❌ 不支援加密文件：密碼保護的檔案無法轉換
❌ 複雜排版丟失：多欄版面配置、文字環繞等可能丟失
❌ 專案較新：2026 年 8 月才發布，生態還在建設中

適用場景

• ✅ RAG 管道文件預處理
• ✅ 知識庫建構
• ✅ 文件搜尋引擎
• ✅ AI 助手文件理解
• ✅ 企業文件遷移
• ✅ 內容管理系統

不適用場景

• ❌ 掃描件 OCR（需要專業 OCR 工具）
• ❌ 複雜排版保留（需要專業排版工具）
• ❌ 格式轉換（如 Markdown → PDF，需要 Pandoc）

最終評分

推薦指數：⭐⭐⭐⭐⭐（強烈推薦）

anydoc 是目前最優秀的開源文件轉 Markdown 工具，特別適合需要處理多種格式、追求速度和品質的生產環境。如果你正在建構 RAG 管道或知識庫系統，anydoc 應該是您的首選。

參考連結： - GitHub 儲存庫：https://github.com/firecrawl/anydoc - Firecrawl 官方部落格：https://www.firecrawl.dev/blog/anydoc-and-pdf-inspector - 線上展示（WebAssembly）：https://firecrawl.github.io/anydoc/ - Firecrawl Parse API（託管服務）：https://firecrawl.dev/parse