> Táblázatok RAG-ban: miért töri szét őket a darabolás, pdfplumber, Camelot, Docling és felhős kinyerők, mit nem lát a TEDS, szerializálás és SQL-irányítás.
>
> Web page: https://balazscsorba.com/hu/blog/table-extraction-rag · Language: Magyar · Also available in: [English](https://balazscsorba.com/blog/table-extraction-rag.md) · [Deutsch](https://balazscsorba.com/de/blog/table-extraction-rag.md)
> Author: Balázs Csorba · Published: 2026-09-29 · Updated: 2026-10-16 · Keywords: table extraction for RAG, tables in RAG pipelines, pdfplumber vs Camelot, Table Transformer PubTables-1M, Docling table mode TableFormer, Azure Document Intelligence tables, TEDS metric limitations, markdown vs HTML table for LLM, text-to-SQL for table questions, LlamaParse table extraction

[Blog](https://balazscsorba.com/hu/blog)/Retrieval és keresés

# Táblázatkinyerés RAG-hoz: kinyerési rétegek, szerializálás és megbízható lekérdezések

Táblázatok RAG-ban: miért töri szét őket a darabolás, pdfplumber, Camelot, Docling és felhős kinyerők, mit nem lát a TEDS, szerializálás és SQL-irányítás.

[Balázs Csorba](https://balazscsorba.com/hu/about)·2026\. szeptember 29.·frissítve 2026\. október 16.·8 perc olvasás

-   RAG
-   Tables
-   Document parsing
-   Evaluation
-   Text-to-SQL

![Egy oldalon lévő táblázatból különálló sorcsíkok lesznek, mindegyiken fejlécfüllel.](https://balazscsorba.com/images/blog/table-extraction-rag/cover.webp?v=f01f64155f)

## A lényeg röviden

-   A fix méretű darabolás elválasztja a sorokat a fejléctől, így egy táblázatos kérdés csak szerencsével válaszolható meg; egy 2026-os tanulmány szerint az egyik sűrű modell súlyosan elbukott a táblázatból származó kérdéseken.
-   A kinyerők különböző formát adnak: a pdfplumber és a Camelot szöveges PDF-eket olvas, a Docling TableFormere és a Table Transformer szerkezetet ismer fel, az Azure Layout és a Textract tipizált cellarácsot ad fejlécekkel.
-   A publikált elemzőpontszámok ritkán jósolják meg a saját korpuszt: egy 2026-os tanulmányban a TEDS és a GriTS r = 0,68 és 0,70 korrelációt mutatott az emberi ítélettel, egy LLM-bíró 0,93-at.
-   Minden táblázatot tartson egy egységként, plusz soronkénti gyermekegységekkel, amelyek megismétlik az oszlopneveket, és a szöveges változat mellett tartson tipizált rácsot a hivatkozásokhoz és az SQL-hez.
-   A kikeresési kérdéseket a visszakereséshez, az összesítő kérdéseket, például összegeket, darabszámokat és maximumokat SQL-hez vagy dataframe-hez irányítsa, mert a vektoros hasonlóság nem ismeri az összeget és a maximumot.

Ezen az oldalon

1.  [Miért töri szét a táblázat a darabolásra épülő RAG-ot](https://balazscsorba.com/#why-tables-break-chunk-based-rag)
2.  [A kinyerési rétegek, és mit adnak vissza](https://balazscsorba.com/#the-extraction-layers)
3.  [Mit mérnek valójában a benchmarkok](https://balazscsorba.com/#what-the-benchmarks-actually-measure)
4.  [Szerializálás: Markdown, HTML, JSON vagy folyószöveg](https://balazscsorba.com/#serialization-choices)
5.  [Táblázat darabolása szétszedés nélkül](https://balazscsorba.com/#chunking-a-table-without-breaking-it)
6.  [Kérdéseket irányítson, ne csak dokumentumokat](https://balazscsorba.com/#routing-questions-not-documents)
7.  [Mikor nem éri meg táblázatfolyamatot építeni](https://balazscsorba.com/#when-not-to-write-a-table-pipeline)
8.  [Ellenőrzőlista a folyamathoz](https://balazscsorba.com/#pipeline-checklist)
9.  [Források](https://balazscsorba.com/#sources)

Cikk meghallgatása

0:000:00

A **táblázatkinyerés RAG-hoz** a dokumentumbetöltés azon része, ahol a legtöbb folyamat észrevétlenül pontosságot veszít. A táblázat kétdimenziós szerkezet, amelynek számai csak a sor- és oszlopfejlécekkel együtt jelentenek valamit, a szokásos RAG-recept pedig, amely fix méretű darabokra vágja a szöveget, pontosan ezt a kapcsolatot rombolja szét. A visszakereső ezután olyan töredékeket ad vissza, mint „12,5 | 40 | igen”, a modellnek pedig találgatnia kell, melyik oszlop melyik volt.

Ez a cikk a táblázatokat önálló objektumként kezeli: melyik kinyerési réteget használja, és mit ad vissza, mit mérnek valójában a benchmarkok, hogyan szerializáljon és daraboljon egy táblázatot, hogyan irányítsa a számítást igénylő kérdéseket, és mikor nem éri meg külön táblázatfolyamatot építeni. A teljes dokumentumok elemzését, az OCR-t és az elrendezési modelleket a [PDF- és dokumentumelemzés RAG-hoz](https://balazscsorba.com/hu/blog/pdf-document-parsing-for-rag) című cikk tárgyalja; itt feltételezünk egy elemzőt, és az általa talált táblázatra koncentrálunk.

## Miért töri szét a táblázat a darabolásra épülő RAG-ot

A táblázat azért töri szét a darabolásra épülő RAG-ot, mert a darabolás azt feltételezi, hogy a jelentés egy szövegsor mentén halad, a táblázatban viszont két tengely mentén. Egy fix méretű ablak elvágja a sorokat a fejléctől, leválasztja a sort a feliratáról, és a széles sorokat több darabra osztja. Egy olyan kikeresési kérdés, mint „mekkora az X200-as modell maximális terhelése”, így csak akkor válaszolható meg, ha a megfelelő sor és a fejléc véletlenül ugyanabba a darabba kerül.

A hatás mérhető. Egy 2026-os, kontrollált faktoriális tanulmány három elemzőt, három darabolási stratégiát és öt sűrű beágyazó modellt, valamint a BM25-öt hasonlította össze szabályozási dokumentumokon, összesen 72 000 eredménysoron. Azt találta, hogy az elemző és a daraboló választása jelentősen kölcsönhat, és hogy az egyik sűrű modell, az MPNet-base „súlyos hibamódot mutatott a táblázatból származó kérdéseken” ([faktoriális tanulmány](https://arxiv.org/abs/2609.31660)). A szöveg több mint 98 százaléka megmaradt a betöltéskor, vagyis a veszteség abból fakadt, ahogyan a táblázatokat feldarabolták és rangsorolták, nem hiányzó szövegből.

![Fix méretű darabok kontra egy táblázategység Két oszlop ugyanarról a széles táblázatról. Bal oldalt fix méretű darabok: az 1. darab a fejlécet és az 1–2. sort tartalmazza; a 2. darab a 3–5. sort fejléc nélkül; a 3. darab a 6. sor közepén kezdődik. Egy 4. sorra vonatkozó kérdés oszlopnevek nélküli számokat ad vissza. Jobb oldalt egy táblázategység: egy szülőegység felirattal, fejléccel és az összes sorral; soronkénti gyermekegységek, amelyek megismétlik az oszlopneveket, például Modell: X200; Feszültség: 24 V; Max. terhelés: 40 kg. Ugyanez a kérdés olyan sort talál, amely maga hordozza a jelentését.](https://balazscsorba.com/images/blog/table-extraction-rag/diagram-5.webp?v=1eb319b038)

A fix méretű darabok elválasztják a sorokat a fejléceiktől; a soronkénti gyermekegységekkel rendelkező táblázategység minden sort önmagában is értelmezhetővé tesz.

## A kinyerési rétegek, és mit adnak vissza

Öt réteg van, az olcsó és szó szerinti megoldásoktól a drága és értelmezőkig, és különböző formát adnak vissza. Az első a PDF-geometria: a pdfplumber megtalálja a kifejezett vonalakat és a szavak igazításából adódó vonalakat, kiszámítja a metszéspontjaikat, és a keletkező cellákat táblázatokká csoportosítja, olyan stratégiákkal, mint a `lines`, a `text` és az `explicit`. A README egyértelműen leírja, hogy gépi előállítású PDF-eken működik a legjobban, OCR-t pedig nem kezel ([pdfplumber](https://github.com/jsvine/pdfplumber)).

A szabályalapú elemzők alkotják a második réteget. A Camelot 2.0 `stream`, `lattice`, `network` és `hybrid` változatot kínál, valamint egy opcionális `ml` változatot, amely a Table Transformer családot futtatja, de a cellaszöveget a PDF saját szövegrétegéből tölti ki, „így nem tud értéket kitalálni vagy megváltoztatni”; minden táblázathoz elemzési jelentés és megbízhatósági pontszám tartozik, és csak szöveges PDF-ekkel működik ([Camelot](https://camelot-py.readthedocs.io/en/latest/)). A harmadik a tanult szerkezetfelismerés: a Microsoft Table Transformere, amelyet a 947 642 annotált táblázatot tartalmazó PubTables-1M-en tanítottak, felismeri a sorokat, oszlopokat és fejléccellákat, de külön szövegkinyerést igényel, a repóját pedig 2026 szeptemberében csak olvashatóként archiválták ([Table Transformer](https://github.com/microsoft/table-transformer)).

A Docling ezt a harmadik réteget saját modellel, a TableFormerrel csomagolja, amely a szerkezetet jósolja meg, a cellatartalmat pedig a PDF szövegrétegéből veszi; a PubTabNeten a TEDS-t egyszerű táblázatoknál 91-ről 98,5 százalékra, bonyolultaknál 88,7-ről 95 százalékra emelte ([TableFormer](https://arxiv.org/abs/2203.01017)). A Doclingban a `TableFormerMode.ACCURATE` vagy `FAST` módot választhatja, és kikapcsolhatja a `do_cell_matching` beállítást, ha oszlopok olvadnak össze ([Docling](https://docling-project.github.io/docling/usage/advanced_options/)). A negyedik réteg a felhős elrendezés-API-k, az ötödik a látás–nyelvi elemzők, például a LlamaParse ágensalapú szintjei, kreditalapú árazással: 1000 kredit 1,25 dollár ([LlamaIndex](https://www.llamaindex.ai/pricing)).

Eszköz

Módszer

Kimeneti forma

Szkennek

Költség / licenc

pdfplumber

PDF-geometria

karakterlánc-sorok listája

nem

MIT

Camelot 2.0

szabályok, opcionális ML

táblázatok elemzési jelentéssel

nem

MIT

Docling (TableFormer)

tanult szerkezet

cellarács összevonásokkal

OCR-rel

MIT, saját üzemeltetés

Azure Layout

felhős elrendezés-API

cellák sorral, oszloppal, típussal, összevonással

igen

10 $ / 1000 oldal

Textract TABLES

felhős elrendezés-API

cellablokkok, összevont cellák, fejlécek

igen

15 $ / 1000 oldal (us-east-1)

LlamaParse

LLM- vagy VLM-elemzés

Markdown, JSON, HTML-táblázatok

igen

kredit, oldalanként kb. 1-től

A felhős lehetőségek adják a leggazdagabb formát. Az Azure Document Intelligence `prebuilt-layout` modellje minden táblázathoz sor- és oszlopszámot ad, a cellákhoz pedig `kind` típust, például `columnHeader`, sor- és oszlopindexet, összevonásokat és befoglaló területeket, és közvetlenül Markdownt is kiadhat ([Azure](https://learn.microsoft.com/en-us/azure/ai-services/document-intelligence/prebuilt/layout)); a Textract TABLES funkciója összevont cellákat, oszlopfejléceket, címeket, lábléceket és összesítő cellákat ad vissza ([AWS](https://docs.aws.amazon.com/textract/latest/dg/how-it-works-tables.html)). Az árak 2026 októberi állapotot tükröznek, a szolgáltatók árlistáiból, West Europe, illetve us-east-1 régióra.

## Mit mérnek valójában a benchmarkok

A legtöbb publikált táblázatos szám két mérőszám egyikét használja. A TEDS a 568 000 táblázatképet tartalmazó PubTabNet-tanulmányból származik: a táblázatokat HTML-fává alakítja, és a fa szerkesztési távolságát méri ([PubTabNet](https://arxiv.org/abs/1911.10683)); egyes ranglisták TEDS-Structot közölnek, amely figyelmen kívül hagyja a cellaszöveget. A GriTS közvetlenül mátrixként értékeli a táblázatot, és egyetlen keretben pontozza a topológiát, a cellák helyét és tartalmát ([GriTS](https://arxiv.org/abs/2203.12555)). Mindkettő hasznos, ha ugyanazon a benchmarkon hasonlít össze modelleket.

A saját korpuszt rosszabbul jósolják meg, mint amit a számok sugallnak. Egy 2026-os validálási tanulmány több mint 1500 emberi minőségi ítéletet gyűjtött 21 elemző által kinyert táblázatokról, és azt találta, hogy a TEDS r = 0,68, a GriTS r = 0,70 korrelációt mutat az emberi ítélettel, míg egy LLM-bírós folyamat r = 0,93-at ért el; a szerzők szerint a szabályalapú mérőszámok a szerkezetet megragadják, de „a táblázat tartalmának szemantikai egyenértékűségét nem” ([validálási tanulmány](https://arxiv.org/abs/2603.18652)). A gyakorlati következtetés: állítson össze egy kis, értékelt készletet a saját táblázataiból, és ehhez mérje a jelölteket.

**Egy elemző-ranglista nem az Ön korpusza**

A termékadatlapok, árlisták és szabályozási mellékletek egyáltalán nem hasonlítanak a PubTabNet vagy a PubTables-1M tudományos táblázataira. Húsz-ötven saját táblázat, egyszer cellánként ellenőrizve, többet elárul arról, melyik kinyerőt használja, mint bármely publikált TEDS-pontszám, és ezek lesznek a regressziós teszt minden későbbi elemző- vagy promptváltásnál.

## Szerializálás: Markdown, HTML, JSON vagy folyószöveg

Az, hogy egy táblázat milyen formában kerül az indexbe, megváltoztatja, mit tud vele kezdeni a modell. A Markdown tömör és olvasható, de nem tud összevont cellákat vagy többszintű fejléceket kifejezni; a HTML igen, magasabb tokenköltséggel; a JSON-rekordok megőrzik a típusokat, és minden sort önleíróvá tesznek. A „Table Meets LLM” tanulmány kimutatta, hogy a modellek pontossága olyan szerkezeti feladatokon, mint a cellakeresés és a sorlekérés, a bemeneti formátummal, a tartalom sorrendjével, a szerepalapú promptolással és az elválasztójelekkel változik ([Table Meets LLM](https://zmy.io/files/wsdm24-SUC.pdf)), ezért a választást tesztelni kell, nem feltételezni.

A negyedik lehetőség a táblázatok folyószöveggé írása. A 2026-os D-RAC folyamat oldalakat renderel, egyetlen multimodális menetben visszakeresésre szabott Markdownná alakítja őket, a táblázatokat pedig „önálló, folyószöveges állításokként” írja át a determinisztikus darabolás előtt ([D-RAC](https://arxiv.org/abs/2609.24220)). Ez kis, leíró táblázatoknál jól működik, nagy, számszerű táblázatoknál viszont pontosságot veszít. Bármelyik szöveges formát indexeli, mellette tartsa meg az eredeti tipizált rácsot, hogy a válaszok a pontos cellára hivatkozhassanak, a számítás pedig valódi számokon futhasson.

## Táblázat darabolása szétszedés nélkül

Egy táblázatot kezeljen egy visszakereshető szülőegységként, és adjon hozzá soronként egy gyermekegységet, amely megismétli az oszlopneveket, így egy olyan sor, mint „Modell: X200; Feszültség: 24 V; Max. terhelés: 40 kg”, önmagában is érthető. Soha ne válassza el a fejlécet a törzstől, csatolja a feliratot és a fejezetútvonalat, és tárolja az oldalt és a táblázatazonosítót, hogy a válasz hivatkozhasson rájuk. A nagy táblázatok sorcsoportokra bonthatók, de minden csoport újra hordozza a fejlécet.

```
# One table -> one parent unit + one child per row that repeats the header names
def table_units(table, doc_id, page, caption, section_path):
    header = [c.strip() for c in table.header]
    parent = {
        "id": f"{doc_id}:p{page}:t{table.index}",
        "text": f"{section_path} > {caption}\n" + table.to_markdown(),
        "kind": "table", "page": page,
    }
    children = []
    for r, row in enumerate(table.rows):
        pairs = "; ".join(f"{h}: {v}" for h, v in zip(header, row) if v not in ("", None))
        children.append({
            "id": f"{parent['id']}:r{r}",
            "text": f"{caption}. {pairs}",          # each row is readable on its own
            "kind": "table_row", "parent": parent["id"], "page": page,
        })
    return parent, children   # also write table.rows as typed records to a table store
```

A szülőegység a táblázat egészére vonatkozó kérdésekre válaszol, a sorgyermekek a kikeresésekre, a táblázattár tipizált rekordjai pedig a számításokra. A saját Nuxt-oldalamon, ahol LLM-funkciókat futtatok, kisebb léptékben ugyanez a szabály tartja megbízhatóan a válaszokat: amire hivatkozni fogunk, az az indexelés pillanatától a metaadataiban hordozza a forrásának helyét.

## Kérdéseket irányítson, ne csak dokumentumokat

A kikeresési és a számítási kérdésekhez más eszközök kellenek. Az „mennyi az X200 üzemi hőmérséklete” kikeresés, amelyre a sorgyermekek fölötti hibrid visszakeresés jól válaszol. A „melyik modellnek legnagyobb a teherbírása 30 V alatt” vagy a „hány változat támogatja az IP67-et” viszont összesítés, a vektoros hasonlóság pedig nem ismeri a maximumot, a darabszámot vagy az összeget. Ezekből a kérdésekből lekérdezésnek kell lennie a tipizált táblázattár fölött.

A kutatás a munka szétválasztását támasztja alá. A TableRAG szerint a teljes táblázatok modellkontextusba töltése nem skálázódik, ezért generálás előtt a sémát és a releváns cellákat keresi vissza ([TableRAG](https://arxiv.org/abs/2410.04739)); a Chain-of-Table azt mutatja, hogy a táblázatos következtetés jobban működik a táblázatot átalakító műveletek sorozataként, mint egyetlen válaszként ([Chain-of-Table](https://arxiv.org/abs/2401.04398)); a TableBench pedig arról számol be, hogy ipari jellegű táblázatos kérdéseken még a GPT-4 is csak mérsékelten teljesít az emberekhez képest ([TableBench](https://arxiv.org/abs/2408.09174)). A generált SQL biztonsági oldalát a [text-to-SQL LLM-védőkorlátokkal](https://balazscsorba.com/hu/blog/text-to-sql-llm-guardrails) című cikk tárgyalja.

![Táblázatfolyamat RAG-hoz Öt lépés balról jobbra: egy PDF vagy szkennelt dokumentum egy kinyerési rétegbe kerül, a PDF-geometriától a szabályalapú elemzőkön és a tanult szerkezetfelismerésen át a felhős elrendezés-API-kig vagy látásmodellekig; az eredmény egy táblázatobjektum cellákkal, összevonásokkal, felirattal és oldalszámmal; egy ellenőrző kapu vizsgálja a sor- és oszlopszámot és a számtípusokat; a táblázat kétszer tárolódik, fejléckontextusos szövegként a visszakereséshez és tipizált rácsként; a kérdések pedig vagy hibrid visszakereséshez (kikeresés), vagy SQL-hez (összesítés) kerülnek, oldalszintű hivatkozással megválaszolva.](https://balazscsorba.com/images/blog/table-extraction-rag/diagram-26.webp?v=14f2cfee3b)

A táblázat a kinyeréstől a válaszig táblázat marad: egy szöveges forma a visszakereséshez, egy tipizált forma a számításhoz és a hivatkozáshoz.

Maga az irányító lehet egyszerű. Egy kis osztályozó prompt vagy néhány szabály dönti el, hogy a kérdés értékre, listára, darabszámra, szélsőértékre vagy összehasonlításra vonatkozik-e; az utolsó három a lekérdezési útra kerül. A visszakeresés mindkét úton elsőként fut, mert ez találja meg, melyik táblázatról és mely oszlopokról szól a kérdés. A lekérdezési út ezután SQL-t vagy dataframe-kódot generál erre a sémára, homokozóban futtatja, és az eredményt a felhasznált sorokkal együtt adja vissza, hogy a válasz hivatkozhasson rájuk.

## Mikor nem éri meg táblázatfolyamatot építeni

Hagyja ki a külön folyamatot, ha a táblázatok ritka illusztrációk, és nem azok az adatok, amelyekre rákérdeznek, ha egyetlen táblázatséma sem ismétlődik a dokumentumok között, így egy táblázattárat soha nem kérdeznének le, vagy ha nincs oldalszintű kiértékelése, és egy regressziót amúgy sem látna. Ilyenkor a meglévő elemző Markdown-kimenete, darabonként egy táblázat a feliratával és fölötte egy reranker észszerű első változat. Az általános particionálás eszközszintű kompromisszumait az [Unstructured ismertetője](https://balazscsorba.com/hu/blog/unstructured) tárgyalja.

A költség is befolyásolja a választást. 2026 októberében az Azure elrendezési modellje West Europe régióban 1000 oldalanként 10 dollár, a Textract TABLES funkciója us-east-1-ben havonta az első millió oldalig 1000 oldalanként 15 dollár, míg a saját CPU-n futó Docling vagy Camelot csak számítási kapacitásba kerül. Néhány ezer adatlapos katalógusnál ez így is, úgy is kis egyszeri számla; ha viszont milliónyi oldalt kell minden elemzőváltásnál újrafeldolgozni, a kinyerő saját üzemeltetése számítani kezd.

## Ellenőrzőlista a folyamathoz

1.  Ismerje fel a táblázatokat, és sorolja be minden PDF-et szövegesnek vagy szkenneltnek.
2.  Elsőként a szövegrétegből nyerjen ki; OCR-t vagy felhős elrendezés-API-t csak szkenneknél használjon.
3.  Ellenőrizze a sor- és oszlopszámot, az üres cellákat és a számtípusokat.
4.  Minden táblázathoz tároljon szöveges formát és tipizált rácsot.
5.  Daraboljon egy szülőegységre és fejlécet ismétlő sorgyermekekre.
6.  Az összesítő kérdéseket SQL-hez vagy dataframe-hez, a kikereséseket a visszakereséshez irányítsa.
7.  Minden válaszban hivatkozzon az oldalra és a táblázatazonosítóra.
8.  Minden elemző- vagy promptváltás után teszteljen újra a saját táblázatainak értékelt készletén.

Ha a RAG-rendszerének adatlapokból, árlistákból vagy szabályozási táblázatokból kell válaszolnia, és azt szeretné, hogy ezek a válaszok megállják a helyüket, nézze meg a [MI-mérnöki munkámat](https://balazscsorba.com/hu/expertise/ai-engineer).

## Források

1.  [Factorial study of parsers, chunkers and retrievers (arXiv 2609.31660)](https://arxiv.org/abs/2609.31660)
2.  [pdfplumber on GitHub](https://github.com/jsvine/pdfplumber)
3.  [Camelot documentation](https://camelot-py.readthedocs.io/en/latest/)
4.  [Microsoft Table Transformer (archived)](https://github.com/microsoft/table-transformer)
5.  [PubTabNet and TEDS (arXiv 1911.10683)](https://arxiv.org/abs/1911.10683)
6.  [Semantic evaluation of table extraction (arXiv 2603.18652)](https://arxiv.org/abs/2603.18652)
7.  [TableFormer (arXiv 2203.01017)](https://arxiv.org/abs/2203.01017)
8.  [Docling docs: advanced options](https://docling-project.github.io/docling/usage/advanced_options/)
9.  [Azure Document Intelligence: layout model](https://learn.microsoft.com/en-us/azure/ai-services/document-intelligence/prebuilt/layout)
10.  [Table Meets LLM (WSDM 2024)](https://zmy.io/files/wsdm24-SUC.pdf)
11.  [TableRAG (arXiv 2410.04739)](https://arxiv.org/abs/2410.04739)
12.  [Chain-of-Table (arXiv 2401.04398)](https://arxiv.org/abs/2401.04398)

## Gyakori kérdések

Miért törik szét a táblázatok a RAG-folyamatokat?

A táblázat kétdimenziós szerkezet, amelynek jelentése a fejlécektől függ. A fix méretű darabolás elválasztja a sorokat a fejléctől, és a számokat folyószöveggé lapítja, így a visszakereső olyan töredékeket talál, mint „12,5 | 40 | igen”, oszlopnevek nélkül. A modellnek ezután találgatnia kell, mit jelentenek a számok.

Milyen eszközzel nyerjem ki a táblázatokat PDF-ekből?

Szöveges PDF-eknél kezdjen a pdfplumberrel vagy a Camelot-val, amelyek a PDF saját szövegrétegét olvassák. Bonyolult szerkezetekhez a Docling a TableFormerrel felismeri a sorokat, oszlopokat és az összevont cellákat. Szkenneknél vagy vegyes dokumentumoknál a felhős elrendezés-API-k, például az Azure Document Intelligence vagy az Amazon Textract tipizált cellarácsot adnak. Kettőt teszteljen a saját táblázatain.

Markdownként vagy HTML-ként tároljam a táblázatokat egy LLM-nek?

A Markdown tömör, és egyszerű táblázatokhoz elég; a HTML megőrzi az összevont cellákat és a többszintű fejléceket. Az olyan kutatások, mint a Table Meets LLM, azt mutatják, hogy a pontosság a formátummal és a sorrenddel változik, ezért mindkettőt tesztelje a saját kérdésein. Bármelyik szöveges formát indexeli, mellette tartson tipizált rácsot.

Hogyan válaszoljak táblázatokon olyan kérdésekre, mint „melyik terméknek legmagasabb az ára”?

Irányítsa őket a vektoros keresés mellett. Az összesítő, számláló, rangsoroló és összehasonlító kérdésekhez SQL vagy dataframe kell egy táblázattár fölött. A visszakeresés megtalálhatja a megfelelő táblázatot és sémáját, de a számításnak lekérdezésként kell futnia, a generált SQL-re vonatkozó szokásos védőkorlátokkal.

Hogyan értékeljem a táblázatkinyerés minőségét?

Állítson össze egy kis, értékelt készletet a saját táblázataiból, és ehhez mérje a kinyerést, a cellatartalommal együtt, ne csak a szerkezetet. A publikált TEDS- és GriTS-számok benchmarkkorpuszokat mérnek; egy 2026-os tanulmány szerint csak mérsékelten korrelálnak az emberi ítélettel, egy LLM-bíró viszont jóval jobban.

Írta: Csorba Balázs

Senior fullstack és AI mérnök Stájerországban – több mint 10 év Vue, Nuxt, Node.js és PHP, ma AI-ügynököknek építek eszközöket.

[AI fejlesztés és MCP szerverek →](https://balazscsorba.com/hu/expertise/ai-engineer)[Rólam →](https://balazscsorba.com/hu/about)

## További cikkek

-   [Embedding-modell választása 2026-ban: ranglisták, költségek és összehasonlító teszt a saját adatokon](https://balazscsorba.com/hu/blog/embedding-model-selection-2026)
-   [Kontextuális visszakeresés és késleltetett chunkolás: a RAG-chunkok visszakapják a kontextusukat](https://balazscsorba.com/hu/blog/contextual-retrieval-late-chunking)
-   [Hozzáférés-kezelés RAG-hoz: jogosultságtudatos visszakeresés dokumentumszivárgás nélkül](https://balazscsorba.com/hu/blog/rag-access-control-permissions)
-   [RAG termékkatalógusra: PIM-adatokból megbízható válaszok](https://balazscsorba.com/hu/blog/rag-product-catalog-pim-data)

## Pont erre van szükséged?

Írj a projektedről vagy a pozícióról – szívesen hallok felőled.

[Lépj velem kapcsolatba](mailto:contact@balazscsorba.com) [Kapcsolódjunk LinkedInen](https://www.linkedin.com/in/balazs-csorba)