Parsování PDF pro RAG 2026: Docling vs LlamaParse vs Unstructured vs Marker

Detailní srovnání čtyř PDF parserů pro RAG pipeline v roce 2026: Docling, LlamaParse, Unstructured a Marker. Python kód, benchmarky přesnosti tabulek a rozhodovací strom pro výběr parseru podle objemu a typu dokumentů.

PDF parser pro RAG 2026: Docling vs LlamaParse

Aktualizováno: 28. června 2026

Nejlepší PDF parser pro RAG pipeline v roce 2026 je Docling od IBM, pokud chcete běžet na vlastní infrastruktuře a potřebujete přesnou extrakci tabulek (97,9 % přesnost), LlamaParse, pokud preferujete managed API a používáte LlamaIndex, Unstructured pro mix 30+ formátů, a Marker pro akademické články s GPU. Volba závisí na třech faktorech: jak rozbité jsou vaše dokumenty, jestli musíte data udržet on-prem, a jakou máte propustnost stránek měsíčně. V tomhle srovnání projdu všechny čtyři parsery s běžícím Python kódem, benchmarky a konkrétními pravidly, kdy který nasadit.

  • Docling 2.x s Granite-Docling-258M VLM modelem (Apache 2.0) dominuje opendataloader-bench se skórem 0,877 a je nejlepší open-source volbou pro on-prem RAG.
  • LlamaParse stojí 0,01–0,05 USD za stránku, parsuje dokument konzistentně za zhruba 6 sekund, ale nelze ho self-hostovat (data musí jít do LlamaCloud).
  • Unstructured podporuje 30+ formátů (PDF, DOCX, HTML, e-maily) a vrací sémanticky označené elementy, ideální pro pipeline s heterogenními vstupy.
  • Marker je nejrychlejší s GPU, vyniká na akademických článcích a referencích, ale na komplexních tabulkách zaostává za Doclingem.
  • Self-hosted parsery (Docling, Marker, Unstructured) mají lepší ekonomiku od zhruba 50 000 stránek měsíčně. Pod tím tlačí LlamaParse na konvenienci.
  • Kvalita parseru určuje strop přesnosti celého RAG systému. Žádný reranker ani lepší LLM neopraví zkomolený text.

Dva přístupy: VLM agentní parsery vs. heuristické layout enginy

V roce 2026 se trh PDF parserů pro RAG dělí na dvě paradigmata. První skupinu tvoří vision-language modely (VLM) a agentní parsery, které se na vykreslenou stránku dívají podobně jako člověk. Sem patří LlamaParse a nový Granite-Docling-258M od IBM. Druhou skupinu představují heuristické layout enginy, které strukturu detekují pomocí natrénovaných modelů a pravidel, typicky Unstructured nebo původní pipeline Docling s DocLayNet a TableFormer.

Z mojí praxe (chrlím přes čtvrt milionu stránek měsíčně do Qdrant a pgvector) je tenhle split zásadní z dvou důvodů. VLM přístupy vidí celou stránku najednou, takže lépe zvládnou víceslepované tabulky, ručně psané poznámky a layouty s odsazením podle pozice. Platí za to ale tím, že potřebují GPU nebo cloudové API a halucinují, když je dokument moc dlouhý na jeden kontext. Heuristické enginy jsou rychlejší, deterministické, ale zalomí se na ručně psaném contentu a netriviálních tabulkách.

Tahle volba není akademická. V pokročilých RAG pipeline architekturách nastavuje parser strop přesnosti celého systému. Žádný hybridní retrieval, reranker ani prompt engineering nezachrání tabulku, jejíž buňky jste promíchali už v kroku ingestion. Z toho důvodu doporučuju parser benchmarkovat dřív, než budete řešit volbu vektorové databáze.

Srovnávací tabulka: Docling vs LlamaParse vs Unstructured vs Marker

Pro rychlou orientaci jsem dimenze, podle kterých skutečně volíte parser, shrnul do tabulky. Skóre na opendataloader-bench používá standardizovaných 200 PDF s mixem tabulek, vícesloupcových layoutů, rovnic a obrázků.

VlastnostDoclingLlamaParseUnstructuredMarker
LicenceApache 2.0Komerční APIApache 2.0 + EnterpriseGPL-3.0
Self-hostedAno (CPU/GPU)NeAnoAno (GPU doporučeno)
opendataloader-bench0,877nepublikovánonepublikováno0,861
Přesnost komplexních tabulek97,9 %~92 %~75 %~88 %
Podporované formátyPDF, DOCX, PPTX, XLSX, HTML, audioPDF, DOCX, PPTX30+ formátůPDF, EPUB
Cena (per page)Zdarma + infra$0,01–0,05Zdarma / $0,01+Zdarma + GPU
Rychlost (10str. PDF)~12 s (CPU)~6 s~8 s~3 s (GPU)
Vrací bounding boxyNeČástečněAnoNe
Native LangChain / LlamaIndexOběLlamaIndexOběŽádné

Docling: open-source standard pro on-prem RAG pipeline

Docling vyvíjí IBM Research a od ledna 2026 je projekt hostován pod LF AI & Data Foundation. Má přes 37 000 hvězd na GitHubu a Red Hat ho označil za "číslo jedna open source repozitář pro document intelligence". V lednu 2026 vyšel Granite-Docling-258M, kompaktní VLM model pod Apache 2.0, který parsuje a konvertuje dokumenty jedním průchodem přes proprietární DocTags formát navržený pro RAG.

Co Docling odlišuje od ostatních open-source parserů, je kombinace specializovaných modelů: DocLayNet pro detekci layoutu a TableFormer pro rekonstrukci struktury tabulek. V evaluaci na komplexních sustainability reportech dosáhl 97,9 % přesnosti na tabulkách, což je číslo, které z mojí zkušenosti drží i na finančních výkazech a technické dokumentaci. Slabinou je absence per-element bounding boxů a confidence scores, takže nemáte jak označit nejisté extrakce pro lidský review.

Instalace a základní parsování

pip install docling docling-core[chunking]
from docling.document_converter import DocumentConverter

converter = DocumentConverter()
result = converter.convert("invoice.pdf")

# Markdown výstup vhodný pro LLM
markdown = result.document.export_to_markdown()
print(markdown)

# JSON s plnou strukturou (tabulky, layout, metadata)
doc_dict = result.document.export_to_dict()

Hierarchické chunkování pro RAG

Docling vrací DoclingDocument s plnou hierarchií: sekce, podsekce, tabulky, seznamy. HierarchicalChunker z toho vytvoří chunky respektující strukturu, takže neutíkáte v půlce odstavce a tabulky zůstanou v jednom kuse.

from docling.document_converter import DocumentConverter
from docling_core.transforms.chunker import HierarchicalChunker

converter = DocumentConverter()
result = converter.convert("technical_report.pdf")

chunker = HierarchicalChunker()
chunks = list(chunker.chunk(result.document))

for i, chunk in enumerate(chunks[:3]):
    print(f"--- Chunk {i} ---")
    print(f"Headings: {chunk.meta.headings}")
    print(f"Text: {chunk.text[:200]}...")

Integrace do LangChain pipeline

from langchain_docling import DoclingLoader
from langchain_docling.loader import ExportType
from langchain_huggingface import HuggingFaceEmbeddings
from langchain_milvus import Milvus

loader = DoclingLoader(
    file_path=["./docs/whitepaper.pdf"],
    export_type=ExportType.DOC_CHUNKS,
)
documents = loader.load()

embeddings = HuggingFaceEmbeddings(
    model_name="sentence-transformers/all-MiniLM-L6-v2"
)
vectorstore = Milvus.from_documents(
    documents=documents,
    embedding=embeddings,
    connection_args={"uri": "./milvus.db"},
)
retriever = vectorstore.as_retriever(search_kwargs={"k": 5})

LlamaParse: managed API s rychlostí 6 sekund na dokument

LlamaParse od LlamaIndex zaujme okamžitě dvěma věcmi: minimální setup (API key plus tři řádky kódu) a konzistentní rychlost zhruba 6 sekund nezávisle na velikosti dokumentu. Druhá vlastnost je v praxi nedoceněná. Pokud parsujete dávky tisíců faktur nebo smluv, predikovatelná latence vám umožní postavit jednoduchou frontu bez exponenciálního backoff a timeoutů.

Hlavní omezení jsou dvě. Za prvé, LlamaParse je API-only a dokumenty musí jít do LlamaCloud, takže pro zdravotnické záznamy, právní spisy nebo cokoli pod GDPR data residency požadavky padá. Za druhé, na vícesloupcových layoutech (typicky vědecké články ve dvou sloupcích) se text z přilehlých sloupců občas prokládá, což rozbije retrieval. Pro běžné business dokumenty (PDF faktury, smlouvy, finanční zprávy) je výkon výborný.

Setup a parsování

pip install llama-parse llama-index llama-index-vector-stores-qdrant
import os
from llama_parse import LlamaParse
from llama_index.core import VectorStoreIndex, Settings
from llama_index.embeddings.huggingface import HuggingFaceEmbedding
from llama_index.vector_stores.qdrant import QdrantVectorStore
import qdrant_client

os.environ["LLAMA_CLOUD_API_KEY"] = "llx-..."

# Markdown výstup je nejvhodnější pro RAG
parser = LlamaParse(
    result_type="markdown",
    parsing_instruction=(
        "Toto je finanční report. Zachovej všechny tabulky "
        "a měnové hodnoty přesně."
    ),
    num_workers=4,
)

documents = parser.load_data("./reports/q4_2025.pdf")

Settings.embed_model = HuggingFaceEmbedding(
    model_name="BAAI/bge-small-en-v1.5"
)
client = qdrant_client.QdrantClient(path="./qdrant_db")
vector_store = QdrantVectorStore(
    client=client, collection_name="reports"
)
index = VectorStoreIndex.from_documents(
    documents, vector_store=vector_store
)

Klíčový parametr je parsing_instruction, kterým předáte LLM instrukci, jak s dokumentem zacházet. U finančních dokumentů, kde jeden zaokrouhlený sloupec znamená rozdíl 100 000 dolarů, je to jediný způsob, jak zabezpečit konzistenci. Pro odhad ceny počítejte 0,01–0,05 USD za stránku podle objemu. Měsíční 100 000 stránek vás vyjde na zhruba 3 000 USD oproti několika desítkám dolarů za EC2 GPU instanci s Doclingem.

Unstructured: parser pro 30+ formátů a sémantické chunkování

Unstructured je nejvšestrannější open-source nástroj. Podporuje přes 30 formátů včetně DOCX, HTML, EML (e-maily), MSG (Outlook), MD, EPUB a samozřejmě PDF. Vrací dokument jako seznam elementů se sémantickým typem (Title, NarrativeText, ListItem, Table, Image), což vám umožní stavět vlastní chunking strategie na úrovni struktury, ne jen znaků.

Pro RAG pipeline, kde ingestujete heterogenní vstupy (PDF reporty plus Confluence HTML exporty plus Outlook e-maily plus Markdown wikiny), je Unstructured nejmenší společný jmenovatel. Skóre na komplexních tabulkách (75 %) zaostává za Doclingem i LlamaParsem, takže pro tabulkově náročné domény (finance, regulatorní dokumenty) doporučuju Unstructured kombinovat s Doclingem nebo specializovaným table extractorem. Z poslední pipeline (insurtech ingestion z pěti zdrojů) tohle dělení ušetřilo zhruba 40 % chyb v retrievalu.

pip install "unstructured[pdf]" unstructured-client
from unstructured.partition.pdf import partition_pdf
from unstructured.chunking.title import chunk_by_title

# hi_res režim používá detection model pro layout
elements = partition_pdf(
    filename="./contract.pdf",
    strategy="hi_res",
    infer_table_structure=True,
    extract_image_block_types=["Image", "Table"],
)

# Sémantické chunkování podle nadpisů
chunks = chunk_by_title(
    elements,
    max_characters=1500,
    new_after_n_chars=1200,
    combine_text_under_n_chars=200,
)

for chunk in chunks[:3]:
    print(f"Type: {type(chunk).__name__}")
    print(f"Category: {chunk.metadata.category_depth}")
    print(f"Text: {str(chunk)[:200]}\n")

Strategie hi_res používá detection model. Pomalejší, ale s kvalitními výsledky na komplexních layoutech. Pro batch processing přes desítky tisíc dokumentů přepněte na fast nebo auto. Unstructured také nabízí managed API se SOC 2 Type II compliance, což je relevantní, pokud řešíte enterprise sales cyklus a IT security review.

Marker: nejrychlejší volba pro akademické články

Marker (původně Marker-PDF od Vik Paruchuriho) je zaměřený na rychlost s GPU a vyniká na akademických článcích, knihách a dokumentech s pevně formátovanými referencemi. Na opendataloader-bench dosáhl 0,861, jen lehce za Doclingem. Pro batch konverzi tisíců PDF do Markdownu na NVIDIA A10/A100 je Marker zhruba 3–4× rychlejší než Docling. Zdrojový kód a model najdete v oficiálním GitHub repozitáři.

Hybridní LLM pass v Markeru (volitelně přes Claude nebo GPT) přidává druhý průchod pro nejistá místa, typicky tabulky bez ohraničení, sloučené buňky nebo matematické rovnice. To zvedá přesnost z cca 0,861 na 0,92 na opendataloader-bench, ale vrací vás zpět k API nákladům a latenci podobné LlamaParseu.

pip install marker-pdf
from marker.converters.pdf import PdfConverter
from marker.models import create_model_dict
from marker.output import text_from_rendered

converter = PdfConverter(
    artifact_dict=create_model_dict(),
)
rendered = converter("./paper.pdf")
text, _, images = text_from_rendered(rendered)

print(text[:500])
print(f"Extrahováno {len(images)} obrázků")

Jak vybrat správný PDF parser pro RAG pipeline

Po roce nasazování těchle čtyř nástrojů v různých kontextech (insurtech, legal tech, akademie) jsem došel k jednoduchému rozhodovacímu stromu. Použijte ho jako výchozí bod, ale finální volbu vždy validujte na svých vlastních dokumentech (viz benchmark sekce).

  1. Musí data zůstat on-prem? Pokud ano (zdravotnictví, finance pod regulací, GDPR sensitive data), jste odkázáni na Docling, Unstructured nebo Marker. LlamaParse vypadává.
  2. Je víc než 50 % vašich dokumentů tabulkově náročných? Pokud ano (finanční zprávy, technická dokumentace, normy), volte Docling. TableFormer mu dává reálnou výhodu.
  3. Parsujete primárně akademické články s GPU k dispozici? Marker je nejrychlejší a zachová strukturu referencí.
  4. Ingestujete víc než jen PDF (e-maily, HTML, DOCX)? Unstructured. Sjednocený interface pro 30+ formátů ušetří měsíce vývoje.
  5. Zbytek (běžné business PDF, méně než 1 000 str./den)? LlamaParse. Nejnižší tření, predikovatelná latence.

U větších objemů (50 000+ stránek měsíčně) převažuje ekonomika self-hostingu. Měsíční účet za LlamaParse u 100 000 stránek snadno přesáhne 2 500 USD, zatímco g5.xlarge EC2 instance s Doclingem a Markerem zvládne stejný objem za zlomek ceny. Navíc získáte plnou kontrolu nad latencí a verzemi modelů. Po nastavení vám zbývá řešit už jen observabilitu LLM pipeline a evaluaci výstupů.

Benchmark na vlastních 50 nejhorších dokumentech

Veřejné benchmarky jako opendataloader-bench jsou užitečné pro hrubou orientaci, ale nikdy je nenahrazujte za měření na vlastních datech. Doménově specifické dokumenty (regulatorní formuláře v ČR, faktury z konkrétního ERP, soudní rozhodnutí) mají vzory layoutu, které veřejné korpusy nezachycují. Eval-first přístup, který doporučuju ve všech RAG projektech, začíná tady, na úrovni parseru, ne až u retrievalu.

Můj postup: vyberte 50 nejhorších dokumentů, ne průměr, ale ty s nejhustšími tabulkami, ručně psanými poznámkami, otočenými stránkami a špatným OCR. Pro každý vytvořte ground truth (Markdown nebo JSON) ručně. Pak prožeňte všechny čtyři parsery a měřte tři metriky: Levenshteinova vzdálenost na textu, F1 score na extrahovaných buňkách tabulky a downstream RAG accuracy (klíčové, ale drahé. Odpovídá parser na otázky z vašeho test setu po retrievalu?).

from pathlib import Path
import Levenshtein
from docling.document_converter import DocumentConverter
from marker.converters.pdf import PdfConverter
from marker.models import create_model_dict
from marker.output import text_from_rendered

GOLD_DIR = Path("./gold_truth")
PDF_DIR = Path("./test_pdfs")

docling_converter = DocumentConverter()
marker_converter = PdfConverter(artifact_dict=create_model_dict())

results = {}
for pdf_path in PDF_DIR.glob("*.pdf"):
    gold = (GOLD_DIR / f"{pdf_path.stem}.md").read_text()

    docling_md = docling_converter.convert(pdf_path) \
        .document.export_to_markdown()
    marker_md, _, _ = text_from_rendered(
        marker_converter(str(pdf_path))
    )

    results[pdf_path.name] = {
        "docling": Levenshtein.ratio(gold, docling_md),
        "marker": Levenshtein.ratio(gold, marker_md),
    }

# Vyhodnocení
import statistics
for parser in ["docling", "marker"]:
    scores = [r[parser] for r in results.values()]
    print(f"{parser}: median={statistics.median(scores):.3f}, "
          f"min={min(scores):.3f}")

Honestly, výsledky na vlastních datech se od veřejných benchmarků liší o 10–20 procentních bodů, někdy ve prospěch dražšího API, ale překvapivě často proti. Než commitnete celou ingestion pipeline, investujte den do tohohle srovnání. Návratnost je obrovská: parser-level chyby se v RAG pipeline kumulují přes embedding, retrieval i generování a v produkci je už nikdy nedoženete bez kompletního reingestu vašeho korpusu. A ten u vektorové databáze s desítkami milionů embeddingů znamená dny downtime nebo paralelního provozu (sám jsem ten reingest během jednoho víkendu projel a nepřeju to nikomu). Pro orientaci v dimenzích, podle kterých vybrat úložiště pro výstup parseru, mám detailní srovnání vektorových databází pro RAG.

Často kladené otázky

Jaký je nejlepší PDF parser pro RAG v roce 2026?

Pro self-hosted RAG pipeline je nejlepší volbou Docling od IBM, díky skóre 0,877 na opendataloader-bench a 97,9 % přesnosti na komplexních tabulkách. Pro managed API se spuštěním za minuty volte LlamaParse, pro 30+ formátů Unstructured, a pro nejrychlejší batch processing akademických článků Marker s GPU.

Funguje Docling offline a bez internetu?

Ano, Docling po prvním stažení váh modelů (cca 2 GB) běží plně offline. Pro produkci doporučuju modely předbalit do Docker image nebo namountovat přes volume, jinak vás každý cold start kontejneru stojí 30+ sekund navíc. Granite-Docling-258M je rovněž k dispozici lokálně přes Hugging Face Hub.

Kolik stojí LlamaParse pro RAG pipeline?

LlamaParse stojí 0,01–0,05 USD za stránku podle objemu a zvoleného režimu (Fast/Balanced/Premium). Free tier obsahuje 1 000 stránek denně. Pro 100 000 stránek měsíčně počítejte zhruba 2 500–4 000 USD, což je obvykle bod, kdy self-hosted Docling nebo Marker dávají lepší ekonomický smysl.

Jak parsovat skenované PDF (OCR) pro RAG?

Pro čistě skenované dokumenty se vyplatí Mistral OCR nebo Azure Document Intelligence, které mají specializované modely na OCR s vysokou přesností. Docling i Unstructured umí přepnout do OCR režimu (Tesseract / EasyOCR backend), ale na nečitelných skenech zaostávají. Pokud máte mix vektorových i skenovaných PDF, použijte detekci typu stránky a routujte do dvou pipeline.

Čím se Marker liší od Doclingu pro PDF parsování?

Marker je 3–4× rychlejší na GPU a vyniká na akademických článcích s referencemi a rovnicemi. Docling má lepší skóre na komplexních tabulkách (97,9 % vs 88 %) a nabízí permisivnější Apache 2.0 licenci (Marker je GPL-3.0). Pro RAG nad sustainability reporty, finančními výkazy nebo regulatorními dokumenty volte Docling, pro vědeckou literaturu Marker.

Lze Docling, Marker a Unstructured kombinovat v jedné pipeline?

Ano, a v praxi to často je správná volba. Typický pattern je router, který podle metadat dokumentu (typ, počet stran, obsah tabulek) směřuje vstup na specializovaný parser: Marker pro akademickou literaturu, Docling pro tabulkově náročné reporty, Unstructured pro e-maily a HTML, případně Mistral OCR pro skeny. Sjednocujete je na úrovni výstupního formátu (Markdown nebo JSON s elementy).

Nikhil Verma
O Autorovi Nikhil Verma

AI automation engineer chaining LLMs into workflows that actually work. Bullish on tool use; bearish on prompt theatre.