Multimodalny RAG: dokumenty z tabelami, obrazami i schematami

Otrzymujesz dokumentację techniczną linii produkcyjnej: 1 200 stron PDF. Z tego mniej więcej jedna trzecia to tabele z parametrami, kolejna trzecia — schematy hydrauliczne i elektryczne, reszta to ciągły tekst. Konfigurujesz pipeline RAG, indeksujesz dokumenty, testujesz pierwsze dwadzieścia pytań — i trzy czwarte z nich otrzymuje błędne lub niekompletne odpowiedzi. Technik pyta o obciążenie prądowe konkretnego napędu z tabeli na stronie 847. Model odpowiada pewnie i błędnie, bo nigdy nie widział tej tabeli — naiwny pipeline sparsował ją jako rozsypany tekst i podczas kroku chunkowania odciął powiązanie między wartościami a kolumnami.

To nie jest problem teoretyczny. W środowisku przemysłowym — produkcja, energetyka, budowa maszyn — nawet 40–60 % wartości informacyjnej dokumentów jest powiązane z treściami nitetekstowymi: tabelami, rysunkami, schematami P&ID, schematami elektrycznymi, tolerancjami produkcyjnymi na wykresach. RAG pracujący wyłącznie na tekście systematycznie traci te informacje. Multimodalny RAG ten problem rozwiązuje — ale nie bezkosztowo i nie jednakowo dla każdego rodzaju treści. Ten artykuł rozstrzyga, kiedy warto po niego sięgnąć, jakich narzędzi użyć i gdzie leżą realne wyzwania.

Gdzie text-only RAG zawodzi i dlaczego

Zanim przejdziemy do rozwiązań, ważne jest dokładne zrozumienie, dlaczego naiwny pipeline zawodzi na treściach nitetekstowych. Istnieją trzy mechanizmy awarii:

Tabele: Klasyczny chunking według liczby tokenów tnie tabelę na fragmenty. Nagłówki kolumn trafiają do jednego chunka, wartości do kolejnego. Scalone komórki znikają. Efekt: retrieval znajduje fragment z liczbą, ale bez kontekstu mówiącego, co ta liczba oznacza. Model albo halucynuje, albo poprawnie stwierdza „nie wiem" — oba wyniki są w dokumentacji technicznej nieakceptowalne.

Obrazy i schematy: Parser PDF wyodrębnia tekst i obrazy osobno. Jeśli obraz nie jest opisany tekstem w otoczeniu, pipeline go ignoruje. Większość przemysłowych rysunków ma bardzo skąpy kontekst tekstowy — numery komponentów, legendę — a informację merytoryczną niesie układ wizualny. Tego model text-only nie widzi.

Zeskanowane dokumenty: Starszy dokument produkcyjny to zeskanowany obraz. OCR konwertuje go na tekst, ale traci dwuwymiarowy układ. Tabela w ciągłym tekście wygląda jak bezsensowna seria liczb. Rysunki pozostają jako obrazy bez tekstu, które pipeline ignoruje.

Trzy architektury multimodalnego RAG

Nie istnieje jedno rozwiązanie. W praktyce utrwaliły się trzy podejścia, każde z innym kompromisem między jakością, kosztem i złożonością.

1. Caption-and-index (opis i indeksacja)

Najprostsza droga do multimodalnego RAG. Podczas pipeline ingestion używasz vision-language model (VLM) — modelu rozumiejącego wejście obrazowe — do automatycznego generowania tekstowego opisu każdego obrazu i tabeli. Ten opis jest przechowywany razem z treścią tekstową strony i indeksowany za pomocą standardowego wektorowego retrieval.

Implementacja: Unstructured lub Docling wyodrębnia obrazy i tabele z PDF. Dla każdego obrazu wywołujesz VLM (np. GPT-4o, Gemini 2.5 Pro lub lokalnie Qwen2.5-VL) z promptem „opisz dokładnie, co widzisz na tym rysunku technicznym, uwzględniając wszystkie liczby, kody i etykiety". Wynikowy tekst trafia do indeksu.

Zalety: retrieval działa ze standardowym embeddingiem, pipeline jest prosty, wymagania dotyczące przechowywania są umiarkowane — rzędu dziesiątek GB na miliony stron. Wada: jakość zależy od tego, jak dobrze VLM opisze obraz. Złożone schematy P&ID z dziesiątkami komponentów i symboliką według ISA-5.1 mogą być opisane niedokładnie. Dla kluczowych dokumentów zalecamy human-in-the-loop review podczas generowania opisów.

2. Page-as-image z multi-vector retrieval (styl ColPali)

Zamiast wyodrębniania tekstu z PDF cała strona jest renderowana jako obraz i embedowana bezpośrednio przez vision-language embedding model — typowo modele z rodziny ColPali, aktualnie ColQwen2.5, który utrzymuje czołowe pozycje na leaderboardzie ViDoRe V2 dla wizualnego retrieval dokumentów.

Architektura ColPali generuje dla każdej strony dziesiątki wektorów patch (nie jeden wektor), co pozwala precyzyjniej uchwycić szczegóły. Podczas retrieval stosuje się late interaction — zapytanie jest porównywane z każdym wektorem patch osobno, a wyniki są agregowane (podobnie jak ColBERT dla tekstu). Efekt: wyraźnie wyższa precyzja na stronach z mieszaną zawartością tekst-tabela-obraz.

Wada jest jednoznaczna: storage. Tam gdzie caption-and-index potrzebuje 1 wektora na stronę, ColPali potrzebuje 100–1 000 wektorów. Na dużych korpusach (dziesiątki milionów stron) oznacza to jednostki terabajtów wektorowego przechowywania. Qdrant ma natywne wsparcie dla multi-vector retrieval i late interaction w stylu ColBERT, co upraszcza implementację. Dla większości przemysłowych korpusów (10 000–500 000 stron) ten narzut jest akceptowalny — bardzo duże wdrożenia muszą kalkulować koszty storage wprost.

3. Unified multimodal embeddings

Trzecie podejście: model embeddingowy, który natywnie przetwarza tekst i obrazy w jednej przestrzeni. Przykłady: Cohere Embed v4 (okno kontekstowe 128 000 tokenów, tekst + obrazy, enterprise API), voyage-multimodal-3.5 (Voyage AI, obsługuje klatki wideo). Cała strona jest embedowana bezpośrednio bez generowania tekstu, wynikiem jest jeden wektor na stronę.

Zalety: prostota, umiarkowane wymagania dotyczące przechowywania (porównywalne z single-vector text embeddingami), brak zależności od jakości opisów generowanych przez VLM. Wada: modele te są obecnie dostępne wyłącznie jako cloud API — nie nadają się do środowisk on-prem lub air-gapped. Precyzja retrieval jest niższa niż ColPali na najtrudniejszych dokumentach wizualnych, ale dla większości enterprise korpusów wystarczająca i wyraźnie lepsza niż text-only.

Parsing: Docling i Unstructured

O ile architektura embeddingowa decyduje o jakości retrieval, parsing decyduje o tym, co w ogóle trafia do indeksu. Dwie biblioteki open-source pokrywają większość potrzeb:

`Docling` (IBM, Apache 2.0) konwertuje PDF do ustrukturyzowanego JSON. Rozpoznaje tabele, zachowuje hierarchię dokumentu (rozdział → podrozdział → treść), wyodrębnia obrazy z odniesieniami do ich pozycji na stronie. Jest szybki nawet na CPU i nie wymaga GPU do obsługi typowych dokumentów tekstowych. Dla większości przemysłowych PDF z drukowanymi tabelami to narzędzie pierwszego wyboru.

`Unstructured` ma szerszy zakres: obsługuje więcej formatów (DOCX, PPTX, HTML, e-maile, tabele Excel), posiada tryb wnioskowania do klasyfikacji elementów za pomocą modelu. Dla zeskanowanych dokumentów użyj trybu hi_res, który włącza OCR i analizuje układ strony przez model wizualny. Wada: hi_res jest wolny bez GPU i tworzy zależność od obrazu Docker z modelami.

Dla przemysłowych rysunków (P&ID, schematy elektryczne) żadne z tych narzędzi nie zapewnia semantycznego zrozumienia — wyodrębniają piksele lub tekst, nie logikę połączeń. Jeśli potrzebujesz Q&A nad logiczną treścią rysunku (nie tylko nad etykietami), konieczny jest specjalistyczny prompt VLM z wiedzą domenową lub ręczne adnotacje. Temu zagadnieniu poświęcamy więcej miejsca w artykule LLM nad dokumentacją przemysłową.

Tabele: najczęstszy problem w praktyce

Tabele to szczególny przypadek zasługujący na osobną sekcję. W praktyce obserwujemy trzy typy tabel w dokumentach przemysłowych, każdy wymagający innego podejścia:

Tabele parametryczne (typy urządzeń × wartości) — dobrze przetwarzalne przez Docling lub parser tabel LlamaIndex. Przed indeksacją konwertuj do reprezentacji Markdown lub JSON. Zachowaj nagłówek jako część każdego wiersza podczas kroku chunkowania — parent-child chunking, gdzie parent = cała tabela, a child = wiersz z nagłówkiem, to sprawdzony wzorzec.

Zeskanowane tabele — wymagają VLM. Wyślij obraz tabeli do modelu z explicitnym promptem: „Wyodrębnij zawartość tej tabeli do formatu JSON, zachowaj nagłówki kolumn, wszystkie wartości wraz z jednostkami i przypisami." Weryfikuj wynik — VLM może mylić się przy wartościach pisanych ręcznie lub niestandardowych symbolach.

Tabele z cross-references (np. kod części odsyłający do rysunku) — tu podejście text-only nie wystarcza nawet z dobrym parserem. Potrzebne jest explicite powiązanie encji: id rekordu tabelarycznego ↔ id rysunku, przechowywane w metadanych. Podejście agentic RAG, gdzie agent potrafi wykonać drugie pobranie na podstawie znalezionego odesłania, wyraźnie poprawia tu jakość odpowiedzi. Więcej o agentic RAG w artykule Agentic RAG.

Kiedy naprawdę potrzebujesz multimodalnego RAG

Multimodalny RAG dodaje złożoność i koszty. Przed wdrożeniem odpowiedz sobie szczerze na te pytania:

• Jaki odsetek informacji, o które pytają Twoi użytkownicy, jest powiązany z tabelami lub obrazami? Jeśli poniżej 20 %, rozwiąż to punktowo (ręczne opisy kluczowych rysunków) i nie buduj całego multimodalnego pipeline.
• Czy Twoje dokumenty są przede wszystkim drukowane (cyfrowe PDF) czy zeskanowane? Zeskanowane wymagają GPU podczas ingestion, co zwiększa koszty indeksacji.
• Potrzebujesz on-prem, czy cloud API jest akceptowalne? Najsilniejsze unified multimodal embeddings są obecnie dostępne wyłącznie przez API.
• Jak często aktualizowany jest korpus dokumentów? Pipeline caption-and-index jest tańszy przy pierwszym uruchomieniu, ale przy każdej aktualizacji korpusu musisz regenerować opisy obrazów — wywołania VLM nie są darmowe.

Dla większości przemysłowych wdrożeń z typowymi podręcznikami technicznymi (drukowane, ustrukturyzowane tabele, rysunki z etykietami) caption-and-index z parserem `Docling`/`Unstructured` i silnym VLM jest wystarczający i znacznie tańszy niż ColPali.

ColPali lub unified multimodal embeddings opłacają się, gdy masz wizualnie bogate dokumenty, gdzie opis tekstowy nie wystarczy do uchwycenia informacji — na przykład złożone schematy hydrauliczne z wielopoziomowym rozgałęzieniem lub dokumenty, gdzie układ strony sam w sobie niesie informację.

Wyzwania, których żaden tutorial nie wspomina

Z dziesiątek wdrożeń wynikają problemy, na które natrafia prawie każdy:

Koszt ingestion: Jeśli masz 500 000 stron, a każda zawiera średnio 2 obrazy, generowanie opisów przez cloud VLM API może kosztować rzędu tysięcy euro za jednorazową indeksację. Policz to z góry. Lokalne VLM (np. Qwen2.5-VL 7B lub 72B) obniżają ten koszt do ceny godzin GPU, ale wymagają odpowiedniej VRAM — model 72B w 4-bitowej kwantyzacji potrzebuje rzędu 40+ GB VRAM.

Wersjonowanie dokumentów: Dokumentacja techniczna ma rewizje. Rysunek Rev3 może mieć inne wartości niż Rev1. Multimodalny pipeline musi zachowywać wersję jako metadane, a retrieval musi umieć filtrować według niej. Ma znaczenie, czy chcesz aktualną wersję czy konkretną rewizję.

Ślepa uliczka ewaluacji: Metryki RAGAS (Faithfulness, Context Recall, Answer Relevancy) sprawdzają się dobrze dla tekstu. Dla multimodalnego retrieval nie istnieje ustandaryzowany benchmark na Twoich własnych dokumentach. Musisz ręcznie zbudować gold dataset — 100–200 pytań ze zweryfikowanymi odpowiedziami — i mierzyć na nim. Bez tego nie ocenisz, czy zmiana architektury pomogła, czy zaszkodziła.

Halucynacje nadal istnieją: RAG wyraźnie redukuje halucynacje w porównaniu z czystym LLM, ale ich nie eliminuje. Jeśli VLM niedokładnie opisał tabelę podczas ingestion, model odpowie pewnie na podstawie błędnego opisu. Ważne: metryka faithfulness mierzy spójność odpowiedzi z dostarczonym kontekstem — nie faktyczną poprawność samego kontekstu. Jeśli opis obrazu jest zły, faithfulness będzie wysoka, a odpowiedź nadal błędna. Więcej o cytowaniach i groundingu w artykule cytowania i grounding w RAG.

Zalecana architektura dla przemysłowych PDF

Gdyby skondensować doświadczenia z wdrożeń w budowie maszyn i energetyce w konkretne zalecenie:

1. 1.Parsing: Docling dla drukowanych PDF, Unstructured hi_res dla zeskanowanych. Wyodrębnij tabele jako osobne encje, obrazy jako bloki z możliwością odwołania.
2. 2.Tabele: konwertuj do Markdown lub JSON, indeksuj z parent-child chunking. Nagłówek musi być częścią każdego child chunka.
3. 3.Obrazy i rysunki: dla typowych dokumentów caption-and-index z promptem VLM ukierunkowanym na domenę (przemysł, elektrotechnika, hydraulika). Dla wizualnie intensywnych dokumentów rozważ unified multimodal embeddings (Cohere Embed v4 lub Voyage) albo ColQwen2.5, jeśli storage jest akceptowalny.
4. 4.Embedding + retrieval: BGE-M3 pozostaje niezawodnym open-weight wyborem dla przemysłowych tekstów SK/CZ/PL — łączy dense, sparse i multi-vector w jednym modelu. Hybrid search (BM25 + dense) jest przy dokumentacji technicznej niemal obowiązkowy ze względu na precyzyjne dopasowanie kodów i oznaczeń urządzeń.
5. 5.Reranking: BGE-reranker-v2-m3 (self-hosted) lub Cohere Rerank API. Dodaje latencję, ale przy złożonej dokumentacji, gdzie ten sam termin pojawia się na setkach stron, jest kluczowy.
6. 6.Storage: Qdrant dla przypadków multi-vector, pgvector jeśli masz istniejącą infrastrukturę PostgreSQL i wolumen poniżej 50 milionów wektorów.
7. 7.Ewaluacja: gold dataset 100–200 pytań z realnych zapytań użytkowników, RAGAS dla metryk tekstowych, ręczna adnotacja dla odpowiedzi multimodalnych.

Najczęstsze pytania

Czy ColPali zawsze jest lepszy niż caption-and-index?

Nie. ColPali osiąga wyższy recall na wizualnie wymagających dokumentach, ale kosztem 100–1 000× większej liczby wektorów na stronę. Dla większości przemysłowych korpusów z drukowanymi tabelami i opisowymi rysunkami caption-and-index z dobrym promptem VLM jest wystarczający za ułamek kosztów storage. ColPali opłaca się tam, gdzie układ strony sam w sobie niesie informację, której opis tekstowy nie jest w stanie uchwycić.

Czy mogę używać lokalnych modeli VLM, czy muszę płacić za cloud API?

Lokalne VLM są w pełni funkcjonalną alternatywą. Qwen2.5-VL w wariancie 7B działa na consumer GPU z 16–24 GB VRAM, wariant 72B w 4-bitowej kwantyzacji potrzebuje rzędu 40+ GB VRAM. Dla pipeline caption-and-index, gdzie VLM działa podczas ingestion (nie przy każdym zapytaniu), lokalny model jest ekonomicznie korzystny przy większym korpusie. Wada: niższy throughput podczas indeksacji. Cloud API (GPT-4o, Gemini) oferuje wyższą jakość opisów, ale przy 500 000+ stronach koszt może być znaczący.

Jak obsługiwać dokumenty w wielu językach — polskim, angielskim, niemieckim?

Dla embeddingów zalecamy BGE-M3 lub Qwen3-Embedding-8B — oba modele obejmują język polski, czeski, słowacki, niemiecki i angielski w ramach treningu wielojęzycznego. Dla VLM captioning dokumentów przemysłowych angielski jest nadal zalecanym językiem opisów (modele są w nim wyraźnie silniejsze), ale retrieval działa też po polsku dzięki wielojęzycznym embeddingom.

Kiedy warto używać wektorowej bazy danych zamiast pgvector?

pgvector to legitymowany wybór produkcyjny do 50 milionów wektorów przy istniejącej infrastrukturze PostgreSQL. Dla multi-vector retrieval (styl ColPali) z dziesiątkami wektorów na stronę i milionem stron Qdrant z natywnym wsparciem ColBERT jest wyraźnie wydajniejszy. Porównanie baz danych znajdziesz w artykule bazy wektorowe — porównanie.

Jaki jest typowy czas i koszt indeksacji przemysłowego korpusu?

Zależy od podejścia. Caption-and-index na 100 000 stronach z mieszaniną tekstu, tabel i obrazów: przy cloud VLM API rzędu setek euro, przy lokalnym 7B VLM rzędu godzin GPU na jednym odpowiedniku A100. Architektura ColPali przyspiesza indeksację (nie trzeba generować opisów), ale infrastruktura retrieval (multi-vector storage) jest kosztowniejsza. Parsing text-only z Docling bez VLM to czyste obciążenie CPU i poradzi sobie z setkami tysięcy stron w ciągu kilku godzin na typowym serwerze.

*Multimodalny RAG to nie „efektowna funkcja" — to warunek konieczny niezawodnego systemu dla każdego korpusu, gdzie tabele i rysunki niosą kluczowe informacje. W przemyśle dotyczy to większości dokumentacji technicznej. Jeśli spotykasz się z podobnym problemem — masz dokumenty, gdzie pipeline text-only daje niezadowalające odpowiedzi — chętnie przyjrzymy się Twojemu konkretnemu przypadkowi i zaproponujemy architekturę dopasowaną do Twojego korpusu i wymagań infrastrukturalnych.*