Dlaczego struktura tabel ma większe znaczenie niż dokładność OCR w lokalnym RAG-u

Eva Wong jest Technicznym pisarzem i stałym majsterkowiczem w ZimaSpace. Całe życie geek z pasją do homelabów i oprogramowania open-source, specjalizuje się w tłumaczeniu skomplikowanych koncepcji technicznych na przystępne, praktyczne przewodniki. Eva wierzy, że samodzielne hostowanie powinno być zabawą, a nie czymś onieśmielającym. Poprzez swoje samouczki umożliwia społeczności rozwiewanie tajemnic konfiguracji sprzętu, od budowy pierwszego NAS po opanowanie kontenerów Docker.

Lokalny OCR może zasilać system RAG oparty na tabelach, ale to struktura tabeli — a nie sama dokładność rozpoznawania znaków — decyduje o tym, czy pobrana liczba nadal oznacza to samo, co w oryginalnym dokumencie.

Pipeline może poprawnie rozpoznać każdą widoczną wartość, a mimo to wygenerować błędną odpowiedź po spłaszczeniu tabeli. Jeśli „2026”, „$412” i „Gospodarstwo domowe A” przetrwają OCR, ale znikną relacje między wierszami i kolumnami, model językowy otrzyma poprawne tokeny przypisane do niewłaściwych danych źródłowych.

OCR rozpoznaje symbole, a rozumienie tabel odtwarza relacje

Zwykły OCR odpowiada na pytanie, jakie znaki występują na stronie i mniej więcej gdzie się znajdują. Parser tabel ma trudniejsze zadanie: musi zidentyfikować granice tabeli, wywnioskować wiersze i kolumny, przypisać nagłówki, rozpoznać scalone komórki, zachować kolejność odczytu oraz współrzędne łączące każdą wartość z jej miejscem na stronie.

Rozpoznawanie tabel Split, Embed and Merge wyraźnie oddziela wykrywanie siatki tabeli od scalania komórek i wykorzystuje zarówno cechy wizualne, jak i tekstowe do odtwarzania złożonej struktury. Jego struktura tabeli oparta na dzieleniu i scalaniu pokazuje, dlaczego rozpoznawanie znaków i odtwarzanie relacji między wierszami, kolumnami i komórkami to dwa różne problemy; w artykule podano wynik F1 na poziomie 97,11% dla zadania rozpoznawania struktury tabel w zbiorze SciTSR.

Ta granica ma szczególne znaczenie w przypadku faktur, rachunków za media, planów zajęć, tabel leków i sprawozdań finansowych, gdzie ta sama liczba może pojawiać się w kilku wierszach. Lokalne przetwarzanie chroni stronę przed opuszczeniem domu, ale lokalność sama w sobie nie sprawia, że spłaszczona reprezentacja jest bezpieczna pod względem znaczeniowym.

Nagłówki i zakresy niosą znaczenie, które RAG musi pobrać

Użyteczna jednostka indeksowania powinna odpowiadać nie tylko na pytanie „jaką wartość znaleziono?”, ale także „do którego oznaczenia wiersza, nagłówka kolumny, modułu i sekcji należy ta wartość?”. Wielopoziomowe nagłówki i scalone komórki tworzą dziedziczone relacje, które znikają, gdy parser konwertuje stronę do jednego wiersza tekstu.

W artykule PMLR z 2026 roku dotyczącym korekty układu tabel odnotowano lepsze wyniki ekstrakcji strukturalnej i odpowiadania na pytania w dalszych etapach po zastosowaniu jawnej korekty układu oraz konwersji do reprezentacji podobnych do Markdown/HTML. To silniejszy sygnał jakości RAG niż sama dokładność rozpoznawania znaków OCR, ponieważ sprawdza, czy struktura pozostaje użyteczna przy odpowiadaniu na pytania.

Powiązany artykuł ZimaSpace o relacjach w tabelach OCR omawia typowe wzorce błędów. W tym artykule AI Hub kluczowe jest rozróżnienie architektoniczne: struktura tabeli powinna stać się pełnoprawnym dowodem indeksowanym, a nie przypadkowym produktem ubocznym OCR.

Dzielenie tabeli na fragmenty jak zwykłej prozy może zaburzyć poprawną ekstrakcję

Nawet poprawnie odtworzona tabela może zawieść na późniejszym etapie, jeśli dzielenie na fragmenty oddzieli wartość od jej nagłówków albo rozdzieli powtarzający się nagłówek od wierszy, których dotyczy. RAG uwzględniający tabele często wymaga grup wierszy, propagowania nagłówków, stabilnych identyfikatorów tabel, współrzędnych stron oraz reprezentacji, którą można pobrać jako jeden logiczny obiekt.

Praca T2-RAGBench z 2026 roku ocenia RAG dla tekstu i tabel, zamiast traktować tabele jak zwykłą prozę. Istnienie osobnego benchmarku dla tekstu i tabel odzwierciedla podstawowy problem: jakość wyszukiwania zależy od zachowania uporządkowanych danych podczas pozyskiwania i budowania kontekstu, a nie tylko od wyodrębnienia słów ze strony.

Nie twórz małych embeddingów na poziomie pojedynczych komórek bez wspólnego kontekstu, chyba że warstwa wyszukiwania potrafi deterministycznie odtworzyć ścieżkę nagłówków. Komórka zawierająca „18,4” rzadko jest sama w sobie użyteczna. Indeks powinien móc zwrócić tę wartość wraz z wystarczającą ilością sąsiedniej struktury, aby ustalić, co oznacza 18,4, kogo dotyczy i jakiego okresu.

Sprawdzaj wierność strukturalną za pomocą pytań, a nie wyłącznie procentu poprawności OCR

Utwórz zestaw testowy na podstawie najtrudniejszych tabel w gospodarstwie domowym: złączonych nagłówków, wielostronicowych zestawień, obróconych skanów, bladych linii siatki, powtarzających się jednostek oraz wierszy z podobnymi liczbami. Oceniaj osobno dokładność tekstu w komórkach, przypisanie nagłówków, mapowanie wierszy i kolumn oraz końcową poprawność odpowiedzi na pytania, aby wysoki wynik OCR nie ukrył błędu strukturalnego.

Praktyczna analiza błędów ekstrakcji scalonych komórek pokazuje, jak scalone komórki i wielopoziomowe nagłówki mogą zaburzyć dalsze powiązania między wierszami i kolumnami, nawet gdy widoczny tekst zostanie rozpoznany. To dokładnie te błędy powinien ujawnić lokalny test RAG przed zindeksowaniem tysięcy domowych dokumentów.

Uznaj pipeline za gotowy dopiero wtedy, gdy pobrane odpowiedzi można prześledzić do właściwej tabeli, strony, wiersza, kolumny i ścieżki nagłówka. Jeśli model musi zgadywać, która etykieta należy do danej wartości, ulepsz odtwarzanie tabeli albo pobierz obraz strony do kontroli multimodalnej, zamiast akceptować myląco wysoki wynik dokładności OCR.

Centrum Technologii i Sztucznej Inteligencji

Więcej do przeczytania

Get More Builds Like This

Stay in the Loop

Get updates from Zima - new products, exclusive deals, and real builds from the community.

Stay in the Loop preferences

We respect your inbox. Unsubscribe anytime.