Pexon Consulting | 11 Min. Lesezeit | 27.05.2026
TL;DR
MarkItDown RAG bezeichnet die Konvertierung heterogener Unternehmensdokumente in strukturiertes Markdown vor Embedding und Retrieval. Pexon Consulting (80 Mitarbeitende, Deutschland, Azure/AWS/GCP, Microsoft Partner) nutzt MarkItDown als leichten Ingestion-Schritt in produktiven Pipelines — ergänzt durch Azure Document Intelligence bei Scan-PDFs. In Projekten verbessert sauberes Preprocessing die Context Precision spürbar, bevor teurere Modelle oder Reranker ins Spiel kommen.
Warum die Dokumentenbasis über Ihr RAG entscheidet
67 Prozent der produktiven KI-Anwendungen in Unternehmen nutzen laut einer aktuellen McKinsey-Erhebung Retrieval — nicht reines Prompting. Das Problem liegt selten am Modell. Es liegt in den Chunks.
Wenn Sie gerade ein internes Wissensportal oder einen Fach-Chatbot evaluieren, kennen Sie das Muster: Die Demo antwortet überzeugend auf drei Handbücher. Dann kommen Legacy-PDFs, Excel-Kalkulationen aus dem Einkauf und PowerPoint-Folien aus dem Vertrieb — und die Antwortqualität bricht ein. Nicht weil GPT-4o „schwächer“ wurde, sondern weil der Retriever Tabellenzeilen, Fußnoten und Folientitel nicht sauber trennt.
Unsere klare Empfehlung: Investieren Sie zuerst in Ingestion und Chunking, nicht in ein größeres Modell. In Benchmarks für Enterprise-RAG-Pipelines liegen die größten Sprünge bei semantischem Chunking plus Metadaten — nicht beim Wechsel von 8k auf 128k Context Window. Wer den Reifegrad der Datenbasis vor dem Rollout absichern will, kann das in einem AI Readiness Assessment gegen konkrete Dokumenttypen spiegeln — ohne gleich ein neues Modell zu kaufen.
In Fertigung und Versicherung sehen wir parallel dieselbe Engstelle: technische Handbücher liegen in Word, Schadensmeldungen als Scan-PDF, KPIs in Excel. Ein einheitlicher Markdown-Eingang verhindert, dass jede Fachabteilung einen eigenen Sonderparser pflegt. Referenzen aus vergleichbaren Rollouts finden Sie in unseren Case Studies.
MarkItDown RAG im Architekturbild
MarkItDown ist eine MIT-lizenzierte Python-Bibliothek aus dem Microsoft-Ökosystem (AutoGen-Umfeld), explizit für LLM- und RAG-Pipelines gebaut. Stand Mai 2026 zählt das GitHub-Repository über 125.000 Stars — ein Signal, dass Teams das Formatproblem ernst nehmen, nicht nur Hype.
Die kurze Antwort auf „Was macht es anders als textract oder Pandoc?“: MarkItDown optimiert auf strukturierten Markdown für Maschinen, nicht auf druckfertiges Layout. Überschriften, Listen, Tabellen und Links bleiben erhalten — genau die Marker, die Chunking-Algorithmen und Embeddings brauchen.
from markitdown import MarkItDown
md = MarkItDown()
result = md.convert_local("wartungsanleitung.docx")
markdown_text = result.text_content
# Optional: Bildbeschreibung per LLM (nur wenn nötig — kostet Tokens)
from openai import AzureOpenAI
client = AzureOpenAI(
api_key="...",
api_version="2024-10-21",
azure_endpoint="https://<resource>.openai.azure.com/",
)
md_llm = MarkItDown(llm_client=client, llm_model="gpt-4o")
rich = md_llm.convert_local("schaltplan_mit_foto.pptx")
Für Batch-Läufe in CI/CD reicht oft die CLI — ein Zeiler pro Datei, stdout direkt in den Object Store:
pip install 'markitdown[all]'
markitdown vertragswerk.pdf > vertragswerk.md
az storage blob upload
--account-name "$STORAGE"
--container-name "rag-ingest"
--name "contracts/vertragswerk.md"
--file vertragswerk.md
--overwrite
Sicherheit: In Server-Umgebungen nicht blind convert() auf User-Pfaden nutzen. Microsoft empfiehlt die engste API — für lokale Dateien convert_local(), für kontrollierte Downloads erst requests.get() und dann convert_response(). Details stehen in der MarkItDown-Dokumentation auf GitHub.
Spätestens bei solchen Betriebsfragen zeigt sich, dass MarkItDown nur den Ingestion-Schritt abdeckt. Unsere Anleitung vom PDF-Stapel zum produktiven RAG-System: Vorgehen und Kosten beschreibt die Schritte danach.
Welche Formate sich lohnen — und wo wir aufhören würden
MarkItDown deckt die Formate ab, die in deutschen Mittelständlern 80 Prozent des RAG-Volumens ausmachen: PDF, Word, PowerPoint, Excel, HTML, CSV/JSON/XML, ZIP-Rekursion, Bilder mit EXIF, Audio mit Transkription, YouTube-URLs, EPUB.
Wir raten davon ab, MarkItDown als alleinige Wahrheit für gescannte Versicherungs- oder Logistik-PDFs zu setzen. Ohne OCR liefern Sie dem Retriever leere oder fragmentierte Chunks — und das LLM halluziniert trotzdem selbstbewusst. Für regulierte Branchen kombinieren wir MarkItDown mit Azure Document Intelligence und schreiben Confidence-Werte in die Metadaten. Alles unter Schwellwert geht in Human Review, nicht in den Vektorindex.
Von Markdown zu messbarem Retrieval
Markdown allein rettet kein RAG. Es ist der normierte Eingang für die nächsten Schritte: Metadaten anreichern, strukturaware chunken, hybrid suchen, reranken.
In unseren Projekten sehen wir nach sauberer Konvertierung typischerweise:
- 15–25 Prozentpunkte bessere Context Precision, wenn Überschriften als Chunk-Grenzen dienen (statt Fixed-Size-512 blind durch PDF-Text zu schneiden).
- 20–40 Prozent höheren Recall, wenn zusätzlich BM25 neben Vektorsuche läuft — Fachbegriffe aus Handbüchern werden so wieder auffindbar.
- Deutlich weniger Token pro Chunk, weil HTML-Wrapper und wiederholte Header verschwinden.
# Strukturaware Chunking nach Markdown-Überschriften
def chunk_by_headings(md_text: str, max_tokens: int = 512) -> list[dict]:
import re
sections = re.split(r'(?m)^(#{1,3})s+(.+)$', md_text)
chunks = []
current_heading = "root"
buffer = []
for part in sections:
if part.startswith("#"):
if buffer:
chunks.append({
"content": "n".join(buffer).strip(),
"heading": current_heading,
})
buffer = []
current_heading = part.strip("# ").strip()
else:
buffer.append(part)
if buffer:
chunks.append({"content": "n".join(buffer).strip(), "heading": current_heading})
# Optional: zu große Abschnitte mit Overlap splitten
return [c for c in chunks if c["content"]]
Unsere Empfehlung für den Rollout: Erst 200–500 repräsentative Dokumente konvertieren, mit RAGAS Faithfulness und Context Precision messen, dann skalieren. Wer 50.000 Dateien blind indexiert, optimiert am falschen Ende.
Integration in Azure-RAG-Pipelines
Ein pragmatischer Produktionspfad sieht bei uns so aus:
- Landing Zone: Blob Storage mit Mandant, Dokumenttyp, Version.
- Konvertierung: MarkItDown RAG für Office/HTML; Document Intelligence für Scans.
- Qualitätsgate: Mindestlänge, Sprache, OCR-Confidence, Duplikaterkennung.
- Chunk + Embed: Azure OpenAI Embeddings, Search Index mit Hybridprofil.
- Evaluation: Wöchentlicher RAGAS-Lauf — 5 Prozent Recall-Verlust blockiert Release.
Für Teams mit bestehender Document Intelligence-Strecke ist MarkItDown oft der schnelle Pfad für „gute“ Office-Dateien, während Scans im gleichen Bus ohne zweites Tool-Ökosystem bleiben. Das senkt Betriebskosten gegenüber fünf Einzelparsern. Auf Azure-Seite lohnt sich die Abstimmung mit Landing Zone, Private Endpoints und Kostenbudget — dafür ist Azure Consulting der passende Anker, wenn Security-Teams früh mit am Tisch sitzen.
Soft-CTA im Fluss: Wer noch keine belastbare Evaluationsbasis hat, startet mit einem strukturierten Review der Wissensquellen — nicht mit Modell-Tuning. Ein passender erster Schritt ist unser 6-Wochen-Pilot für Generative AI, in dem Ingestion und Messung vor dem Rollout stehen.
Was MarkItDown RAG nicht ersetzt
Ehrliche Grenzen spart Budget. MarkItDown ist kein Ersatz für:
- Rechtssichere Langzeitarchivierung — Markdown ist ein Verarbeitungsformat, kein Originalnachweis.
- Komplexe Layout-PDFs mit mehrspaltigen Tabellen — hier lohnt sich Document Intelligence oder manuelle Vorverarbeitung.
- Feingranulare Zugriffskontrolle — die kommt aus IAM, nicht aus dem Converter.
Wir empfehlen außerdem: LLM-gestützte Bildbeschreibung in MarkItDown nur dort aktivieren, wo OCR nicht reicht. Jede Folie mit GPT-4o-Beschreibung zu versehen, ist in großen Archiven schnell teurer als ein gezieltes Vision-Modell auf Ausnahmen.
Häufig gestellte Fragen
Was kostet MarkItDown RAG in der Praxis?
Die Bibliothek selbst ist Open Source (MIT). Kosten entstehen durch Compute, Storage, Embeddings und optional Azure Document Intelligence oder LLM-Aufrufe für Bilder. In Mittelstandsprojekten rechnen wir für eine stabile Ingestion-Strecke mit 15.000–45.000 EUR einmalig plus 2.000–8.000 EUR monatlich Betrieb — stark abhängig von Dokumentvolumen und Review-Anteil.
MarkItDown RAG vs. nur Azure Document Intelligence — was ist besser?
Kein Entweder-oder. Document Intelligence ist stärker bei Scans, Tabellen und Formularen mit Confidence-Scores. MarkItDown RAG ist schneller und einfacher für native Office- und Webformate. Unsere Praxis: beides im gleichen Bus, Routing per Dateityp und OCR-Erkennung.
Reicht Markdown-Konvertierung, um Halluzinationen zu stoppen?
Nein. Sie verbessert Retrieval — die häufigste Fehlerquelle. Faithfulness brauchen Sie zusätzlich durch Reranking, klare System-Prompts und Evaluation (z. B. RAGAS). Ohne Messung wissen Sie nicht, ob das Problem Ingestion oder Generation ist.
Wie lange dauert die Einführung für bestehende Dokumentenarchive?
Für einen repräsentativen Pilot (3–5 Dokumenttypen, 500–2.000 Dateien) planen wir 6–10 Wochen inklusive Evaluations-Set und Metadaten-Schema. Vollständige Migration großer Archive läuft oft parallel zum Betrieb über Monate — Batch-Jobs nachts, Qualitätsgates tagsüber.
Kann MarkItDown on-premise ohne Cloud-LLM laufen?
Ja für die Basis-Konvertierung. OCR, Audio-Transkription und LLM-Bildbeschreibung ziehen zusätzliche Abhängigkeiten nach sich. In air-gapped Umgebungen setzen wir lokale OCR-Plugins und verzichten auf Cloud-LLM in der Ingestion — Generation bleibt dann im geschützten Azure- oder Private-AI-Tenant.
Nächster Schritt
Wenn Ihre RAG-Antworten bei Office- und PDF-Mix inkonsistent werden, liegt die Ursache fast immer vor dem Modell. Lassen Sie uns in einem kompakten Workshop Ihre Top-3-Dokumenttypen durchspielen: Konvertierung, Chunking, Messung — mit klarem Go/No-Go für Produktion.
Verwandte Themen
→Document Intelligence und RAG-Dokumentensuche
→OCR KI ERP: PDFs in saubere Stammdaten



