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

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 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). 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.

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).

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). 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).

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). 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). 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).

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); a Textract TABLES funkciója összevont cellákat, oszlopfejléceket, címeket, lábléceket és összesítő cellákat ad vissza (AWS). 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); 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). 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). 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.

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), 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). 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); 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); 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). A generált SQL biztonsági oldalát a text-to-SQL LLM-védőkorlátokkal című cikk tárgyalja.

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 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.

Források

1. Factorial study of parsers, chunkers and retrievers (arXiv 2609.31660)
2. pdfplumber on GitHub
3. Camelot documentation
4. Microsoft Table Transformer (archived)
5. PubTabNet and TEDS (arXiv 1911.10683)
6. Semantic evaluation of table extraction (arXiv 2603.18652)
7. TableFormer (arXiv 2203.01017)
8. Docling docs: advanced options
9. Azure Document Intelligence: layout model
10. Table Meets LLM (WSDM 2024)
11. TableRAG (arXiv 2410.04739)
12. Chain-of-Table (arXiv 2401.04398)