anydoc im Praxistest: 14 Formate zu Markdown, Median unter 5ms

Warum Sie anydoc beachten sollten

Beim Füttern von Dokumenten in große Sprachmodelle beeinflusst die Qualität der Formatkonvertierung direkt die RAG-Ergebnisse. Falsch ausgerichtete Tabellen in Word, verlorene Hierarchien in PPT, unterbrochene Absätze in PDF – jedes Formatproblem kann die Präzision der Vektorsuche erheblich beeinträchtigen. Bisher mussten wir mehrere Tools wie pandoc, python-docx und LibreOffice kombinieren, um überhaupt die gängigsten Office-Formate abzudecken – mit hohem Wartungsaufwand und inkonsistenten Ausgaben.

anydoc ist eine vom Firecrawl-Team von Grund auf in Rust entwickelte Dokumentenkonvertierungs-Bibliothek. Ein einziger API-Aufruf konvertiert 14 Formate mit einer medianen Konvertierungszeit von nur 4,4 Millisekunden. Das Projekt hat bereits über 12.000 Stars auf GitHub und entwickelt sich zum neuen Standard für die Dokumentenvorverarbeitung in RAG/LLM-Toolchains.

Unterstützte 14 Formate

anydoc bietet die breiteste Formatabdeckung aller Open-Source-Konvertierungstools:

Beachten Sie, dass sowohl .doc (älteres Binärformat) als auch .docx (neueres XML-Format) unterstützt werden – das ist bei vergleichbaren Tools sehr selten. Die meisten Tools unterstützen nur .docx und sind bei älteren .doc-Dateien hilflos.

Performance im Test: Das Geheimnis hinter 4,4ms

Der offizielle Benchmark von anydoc verglich 7 Tools (einschließlich sich selbst) mit 100 realen Dokumenten über alle 14 Formate:

Wichtige Erkenntnisse:

1. Geschwindigkeitsvorsprung: anydoc's 4,4ms sind 1/23 der Zeit von pandoc (102,1ms) und 1/257 der Zeit von LibreOffice (1129,5ms)
2. Höchste Qualität: Bei allen bewerteten Formaten erzielte anydoc die höchsten Scores
3. Vollständigste Abdeckung: Das einzige Tool, das alle 14 Formate unterstützt
4. Rust-Vorteil: Reine Rust-Implementierung, keine ML-Modellabhängigkeit, keine externen Service-Aufrufe

Der Qualitäts-Score wurde von Claude Sonnet 5 als LLM-Juror ermittelt, der zwei Ausgaben im Blindvergleich bewertete (basierend auf den ersten 6 Seiten, gerendert mit LibreOffice). Jedes Tool wurde für jedes Vergleichspaar zweimal bewertet, um Positionsverzerrungen auszuschließen – insgesamt 482 Bewertungen.

Format-für-Format-Vergleich: anydoc führend in allen Disziplinen

Die folgenden Daten zeigen den direkten Vergleich der Tools bei identischen Formaten (maximale Punktzahl 100):

mammoth erzielt bei .docx einen Score von 70, was zunächst gut aussieht – aber es unterstützt nur ein einziges Format. anydoc's 81 Punkte sind der Durchschnitt über alle 14 Formate, was eine völlig andere Aussagekraft hat.

Installation und Schnellstart

anydoc bietet einen Rust-Kern mit Node.js-/Python-/WebAssembly-Bindings sowie eine sofort einsatzbereite CLI.

CLI (keine Installation erforderlich)

# Direkt mit npx ausführen, beim ersten Mal werden vorkompilierte Binaries heruntergeladen
npx @firecrawl/anydoc report.docx               # Ausgabe auf stdout
npx @firecrawl/anydoc slides.pptx -o slides.md  # Ausgabe in Datei
npx @firecrawl/anydoc - --format csv < data.csv # Liest von stdin

Python-Integration

pip install firecrawl-anydoc

import anydoc

# Konvertierung von Dateipfad
markdown = anydoc.to_markdown("report.docx")
print(markdown)

# Konvertierung von Bytes (automatische Formaterkennung)
with open("report.docx", "rb") as f:
    data = f.read()
markdown = anydoc.to_markdown_bytes(data)

# Format angeben (erforderlich für Formate ohne Magic Bytes wie CSV)
markdown = anydoc.to_markdown_bytes(csv_data, "csv")

# Dokumentmodell abrufen (enthält eingebettete Bilder und andere Ressourcen)
document = anydoc.to_document(data)

Node.js-Integration

npm install @firecrawl/anydoc

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

// Von Dateipfad
const md = await toMarkdown('report.docx');

// Von Bytes
const mdFromBytes = await toMarkdownBytes(bytes);

// Dokumentmodell abrufen (mit eingebetteten Ressourcen)
const doc = await toDocument(bytes);

Native Rust-Nutzung

cargo add anydoc

// Von Dateipfad
let markdown = anydoc::to_markdown("report.docx")?;

// Von Bytes (automatische Formaterkennung)
let markdown = anydoc::to_markdown_bytes(&bytes, None)?;

// Format angeben
let markdown = anydoc::to_markdown_bytes(&bytes, anydoc::Format::Csv)?;

Praxis-Einsatz mit LangChain / LlamaIndex

In einer RAG-Pipeline wird anydoc typischerweise als vorgeschalteter Schritt zur Dokumentenladung eingesetzt, der verschiedene Formate einheitlich in Markdown umwandelt, bevor die Texte in Chunks aufgeteilt und vektorisiert werden.

Mit LangChain

import anydoc
from langchain.text_splitter import MarkdownTextSplitter
from langchain.embeddings import OpenAIEmbeddings
from langchain.vectorstores import FAISS

# 1. Einheitliche Markdown-Konvertierung mit anydoc
def load_documents(file_paths):
    docs = []
    for path in file_paths:
        md = anydoc.to_markdown(path)
        docs.append({"content": md, "source": path})
    return docs

# 2. Markdown-Chunking
splitter = MarkdownTextSplitter(chunk_size=1000, chunk_overlap=100)
raw_docs = load_documents(["report.docx", "slides.pptx", "data.xlsx"])

chunks = []
for doc in raw_docs:
    chunks.extend(splitter.split_text(doc["content"]))

# 3. Vektorisierung und Speicherung
embeddings = OpenAIEmbeddings()
db = FAISS.from_texts(chunks, embeddings)
db.save_local("./faiss_index")

Mit LlamaIndex

import anydoc
from llama_index.core import Document, VectorStoreIndex

# anydoc-Konvertierung
file_paths = ["contract.docx", "presentation.pptx", "budget.xlsx"]
documents = []
for path in file_paths:
    md = anydoc.to_markdown(path)
    documents.append(Document(text=md, metadata={"source": path}))

# LlamaIndex-Indexierung
index = VectorStoreIndex.from_documents(documents)
query_engine = index.as_query_engine()
response = query_engine.query("Was sind die Vertragsstrafe-Klauseln?")
print(response)

Best Practices für RAG-Szenarien

1. to_document() für eingebettete Ressourcen verwenden

Wenn Dokumente Bilder enthalten, bewahrt das von to_document() zurückgegebene Dokumentmodell die Byte-Daten und den Media-Type der Bilder. Sie können: - Alt-Text aus Bildern als Textinhalt extrahieren - Bilder separat an ein multimodales Modell (z.B. GPT-4V) für OCR senden - Bild-URL-Referenzen beibehalten (wenn Bilder externe Links haben)

2. Automatische Formaterkennung nutzen

anydoc erkennt das Format über die Magic Bytes im Dateiinhalt, nicht über die Dateierweiterung. Das bedeutet, dass anydoc auch dann korrekt erkennt und konvertiert, wenn eine Datei falsch benannt wurde (z.B. eine .pdf, die tatsächlich eine .docx ist).

# Format erkennen
fmt = anydoc.format_from_bytes(data)  # Gibt Format-Enum zurück
print(fmt)  # Format.DOCX

3. GIL bei Batch-Verarbeitung beachten

Die Python-Bindings geben die GIL frei, sodass die Batch-Konvertierung mit mehreren Threads sich nicht gegenseitig blockiert:

import concurrent.futures
import anydoc

def convert(path):
    return anydoc.to_markdown(path)

with concurrent.futures.ThreadPoolExecutor(max_workers=8) as executor:
    results = list(executor.map(convert, file_paths))

4. Verarbeitung von gescannten PDFs

anydoc integriert pdf-inspector, das automatisch erkennt, ob ein PDF textbasiert oder gescannt ist. Bei textbasierten PDFs wird direkt extrahiert; bei gescannten PDFs wird die Kombination mit Firecrawls Parse API (mit OCR-Funktion) empfohlen.

Einschränkungen und Hinweise

1. Begrenzte Fähigkeiten bei gescannten PDFs: anydoc führt selbst kein OCR durch. Für gescannte PDFs wird ein externer OCR-Dienst benötigt. Firecrawls Parse API kann dies ergänzen.
2. Komplexe Layouts können abweichen: Bei mehrspaltigen Layouts oder komplexen Dokumenten mit viel Bild-Text-Mischung können die Konvertierungsergebnisse weniger präzise sein als bei professionellen Layout-Tools. anydoc zielt auf strukturierten, für LLMs lesbaren Text ab, nicht auf pixelgenaue Reproduktion.
3. Älteres .doc-Format: Obwohl unterstützt, ist die Parsing-Komplexität von .doc (OLE2-Binärformat) höher als bei .docx, was zu leicht geringerer Konvertierungsqualität führen kann.
4. Kein ML-Enhancement: anydoc verzichtet bewusst auf ML-Modelle. Das bedeutet, dass es nicht wie docling oder marker Deep Learning für Layoutanalyse einsetzt. Der Vorteil: hohe Geschwindigkeit, keine GPU-Abhängigkeit. Der Nachteil: begrenzte Fähigkeit zum Verständnis komplexer Layouts.
5. Browser-WASM-Version: Die WebAssembly-Version läuft lokal im Browser, ohne dass Dateien das Gerät verlassen – ideal für datenschutzsensible Szenarien. Allerdings kann die Konvertierung großer Dateien durch den Browser-Speicher limitiert sein.

Fazit und Bewertung

anydoc löst ein sehr praxisnahes Problem: In RAG/LLM-Pipelines ersetzt es ein leichtgewichtiges, schnelles, alle Formate abdeckendes Tool die Arbeit, für die man früher vier oder fünf Bibliotheken kombinieren musste.

Vorteile: - Vollständige Abdeckung von 14 Formaten, einzigartig unter Open-Source-Tools - 4,4ms mediane Konvertierungsgeschwindigkeit, 23-mal schneller als der Zweitplatzierte - Führende Qualitäts-Scores mit hoher Ausgabekonsistenz - Reine Rust-Implementierung, keine externen Abhängigkeiten, keine GPU erforderlich - Bindings für Python/Node.js/Rust/WASM verfügbar

Geeignet für: - Entwickler, die RAG-Pipelines bauen und verschiedenste hochgeladene Dokumentformate verarbeiten müssen - Teams, die eine einheitliche Dokumentenausgabe benötigen - Echtzeitszenarien mit Anforderungen an die Konvertierungsgeschwindigkeit - Entwickler, die nicht mehrere Konvertierungs-Tool-Abhängigkeiten warten möchten

GitHub: firecrawl/anydoc (12.000+ Stars)

Häufig gestellte Fragen (FAQ)

F1: Was ist der Unterschied zwischen anydoc und pandoc? pandoc ist ein universelles Dokumentenkonvertierungstool, das extrem viele Ein- und Ausgabeformate unterstützt, aber bei jedem einzelnen Format nur begrenzte Tiefe bietet. anydoc konzentriert sich darauf, Office-Dokumente in LLM-freundliches Markdown umzuwandeln und bietet bei den 14 unterstützten Formaten höhere Konvertierungsqualität, 23-mal schnellere Verarbeitung und ist speziell für RAG-Szenarien optimiert.

F2: Benötigt anydoc eine GPU oder externe Dienste? Nein. anydoc ist eine reine Rust-Implementierung ohne ML-Modellabhängigkeit und ohne externe API-Aufrufe. Es läuft lokal mit einer medianen Konvertierungszeit von 4,4ms pro Datei.

F3: Kann anydoc gescannte PDFs verarbeiten? anydoc enthält einen integrierten pdf-inspector zur Verarbeitung textbasierter PDFs. Für gescannte PDFs (Bild-basiert) wird die Kombination mit Firecrawl Parse API (mit OCR-Funktion) empfohlen.

F4: Wie sieht das Ausgabeformat von anydoc aus? Die Ausgabe erfolgt einheitlich als GitHub Flavored Markdown (GFM) mit Überschriftenhierarchien, Tabellen, Listen, Codeblöcken, Links und anderen Strukturen. Alle 14 Formate erzeugen einen konsistenten Ausgabestil.

F5: Kann anydoc im Browser ausgeführt werden? Ja. anydoc bietet eine WebAssembly-Version (@firecrawl/anydoc-wasm). Dateien werden lokal im Browser konvertiert, ohne Upload zu einem Server – ideal für datenschutzsensible Szenarien.