Hala produkcyjna, godzina druga w nocy. Doświadczony technik przeszukuje 3 400-stronicowy instrukcję obsługi urządzenia, szukając informacji, jaki typ i ilość smaru zaleca producent dla łożyska przy temperaturze powyżej 80 °C. PDF ma niespójną numerację stron, tabela z wartościami jest zeskanowana jako obraz, a norma, do której odsyła instrukcja, znajduje się w osobnym pliku. Po 40 minutach znajduje to, czego szukał. Ta sama sytuacja powtarza się dziesiątki razy na zmianę, w całym zakładzie.
Dokładnie ten problem rozwiązują LLM nad dokumentacją przemysłową. To nie jest buzzword — to konkretny, weryfikowalny use-case, w którym prawidłowo wdrożony system oszczędza mierzalne godziny na operatora miesięcznie. Ten artykuł daje odpowiedź: co działa, gdzie naiwne podejście zawodzi i co musicie rozwiązać, zanim zaczynacie.
Co tak właściwie chcecie osiągnąć
Zanim przejdziecie do architektury, wyjaśnijcie sobie, czego oczekujecie od systemu. W praktyce widzimy trzy różne use-casy, które wyglądają podobnie, ale mają odmienne wymagania:
1. Wyszukiwanie i Q&A dla techników — technik zadaje pytanie w naturalnym języku, system odpowiada z odniesieniem do konkretnej sekcji instrukcji lub normy. Nie przepisanie tekstu, lecz odpowiedź z cytatem: „Zgodnie z sekcją 7.3.2 instrukcji urządzenia XY zalecanym smarem jest ISO VG 220, stosować co 2 000 godzin pracy."
2. Nawigacja po SOP i asystencja krok po kroku — operator pracuje według procedury i potrzebuje wyjaśnienia kroku, alternatywy przy niedostępnym narzędziu albo szybkiego potwierdzenia, czy robi właściwą rzecz. System musi być deterministyczny i precyzyjny — błędna odpowiedź przy procedurze produkcyjnej ma bezpośrednie koszty.
3. Zgodność normatywna i wsparcie audytowe — inżynier musi szybko ustalić, które fragmenty dokumentacji pokrywają wymagania konkretnej normy (np. ISO 9001, IEC 62443, ATEX), albo zidentyfikować luki. Wymaga to zrozumienia zarówno struktury normy, jak i dokumentacji wewnętrznej.
Każdy z tych use-casów ma inne wymagania dotyczące dokładności, latencji i sposobu ewaluacji. Mieszanie ich w jednym pilocie to powszechny błąd.
Dlaczego naiwny RAG na dokumentach przemysłowych nie działa
RAG — skrót od retrieval-augmented generation — to podstawowa architektura: dzielisz dokumenty na fragmenty (chunki), zapisujesz je w bazie wektorowej, przy pytaniu wyszukujesz relewantne fragmenty i przekazujesz je modelowi. Na zwykłych dokumentach działa dobrze. Na dokumentach przemysłowych napotkacie cztery problemy, które trzeba aktywnie rozwiązać.
Problem 1: Naiwny chunking rozcina tabele
Instrukcja urządzenia zawiera tabelę z 30 wierszami i 8 kolumnami: typ urządzenia, temperatura robocza, typ smaru, interwał, ilość, norma, uwaga, wysokość nad poziomem morza. Naiwny chunking według liczby znaków rozetnie tę tabelę na 4 fragmenty. Każdy fragment traci kontekst kolumn, które znajdowały się na poprzedniej stronie.
Rozwiązanie: parser dokumentów, który rozpoznaje tabele i zachowuje je jako całość, ewentualnie konwertuje do postaci strukturalnej (JSON, tabela Markdown). Narzędzia takie jak LlamaIndex mają wyspecjalizowane parsery do takich przypadków. Modele multimodalne (np. Qwen2.5-VL) potrafią ekstrahować tabele nawet ze zeskanowanych PDF — co jest częste w starszych instrukcjach.
Problem 2: Rysunki i schematy są niewidoczne dla RAG opartego wyłącznie na tekście
Schematy elektryczne, diagramy hydrauliczne, P&ID (piping and instrumentation diagrams) — to kluczowe elementy dokumentacji technicznej, które pipeline text-only po prostu pomija. Jeśli technik pyta „gdzie jest umieszczony zawór V-12 na schemacie hydraulicznym linii L2", RAG oparty na tekście odpowie „informacja nie znajduje się w dokumentach" albo będzie halucynować.
Rozwiązanie zależy od dostępnych zasobów. Łatwiejsza ścieżka: dla kluczowych rysunków tworzyć ustrukturyzowane opisy tekstowe (jednorazowo, ręcznie lub z pomocą VLM), które są indeksowane razem z pozostałym tekstem. Trudniejsza ścieżka: w pełni multimodalny pipeline, w którym VLM generuje opis obrazu bezpośrednio podczas indeksowania — działa, ale wymaga obliczeniowo kosztownego modelu przy każdym dodaniu dokumentu.
Problem 3: Wersje norm i cross-referencje
Dokumentacja przemysłowa jest pełna odwołań: „postępować zgodnie z ISO 14119:2013, załącznik D" albo „patrz rysunek D-04-7812-rev3". Naiwny RAG nie rozwiąże tych referencji — załaduje fragment, w którym wzmiankowana jest norma, ale nie ma dostępu do samej jej treści, jeśli nie ma jej w indeksie. Wynik: odpowiedź, która cytuje odesłanie, ale nie zawiera rzeczywistej informacji.
Rozwiązanie: rzetelne zarządzanie źródłami. Przed wdrożeniem należy jawnie zdecydować, które normy i ich wersje są częścią indeksu, i wdrożyć proces aktualizacji przy rewizjach. To problem organizacyjny w równym stopniu co techniczny.
Problem 4: Okno kontekstowe nie jest nieograniczone
Nawet okno kontekstowe o pojemności 1M tokenów u frontierowych modeli nie jest rozwiązaniem dla 5 000-stronicowej instrukcji. Uwaga modelu przy ekstremalnie długich wejściach rozprasza się — zjawisko to jest wielokrotnie potwierdzane w badaniach. RAG pozostaje istotne także przy modelach z długim kontekstem, ponieważ selektywnie ładuje tylko relewantne fragmenty zamiast całego dokumentu.
Jak zbudować niezawodny pipeline
Dojrzały pipeline dla dokumentacji przemysłowej ma kilka warstw ponad bazowym RAG.
Przygotowanie dokumentów (ingestion)
To najdłuższy krok i najbardziej niedoceniany. Przed indeksowaniem:
- Rozróżnić typy treści: czysty tekst, tabele, obrazy, rysunki. Każdy typ wymaga osobnego przetwarzania.
- Zeskanowane dokumenty przez OCR — nie stary
Tesseractdla złożonych dokumentów technicznych, lecz wyspecjalizowany VLM lub document intelligence API, który rozumie kontekst strony (liczba w prawym rogu = numer strony, ta sama liczba w tabeli = wartość krytyczna). Więcej o tej warstwie w artykule OCR i document intelligence dla przemysłu. - Metadane: dla każdego chunku zapisać dokument źródłowy, numer strony, sekcję, wersję dokumentu, datę ważności. Bez metadanych cytowania nie są możliwe.
- Struktura hierarchiczna: rozdział → podrozdział → tabela/procedura.
LlamaIndexma natywne wsparcie dla hierarchicznego chunkowania.
Retrieval — więcej niż samo wyszukiwanie wektorowe
Samo wyszukiwanie wektorowe ma słabości: uchwyci semantycznie podobne fragmenty, ale może przeoczyć dokładne dopasowanie słowa kluczowego (numer części, kod alarmu, oznaczenie urządzenia). Hybrid search — kombinacja BM25 (słowa kluczowe) i wektorów — jest w kontekście przemysłowym ważniejszy niż w zastosowaniach ogólnych. Zapoznajcie się z artykułem hybrid search z BM25 i wektorami, gdzie temat jest rozwinięty szczegółowo.
Nad wyszukiwaniem hybrydowym dodajcie reranker — model, który sortuje wyniki według relewantności do pytania. BGE reranker (dostępny bezpłatnie) lub API (np. Cohere Rerank) znacząco poprawi precyzję przy długich dokumentach z powtarzającymi się frazami.
Generowanie z cytatami
To kluczowa różnica w stosunku do zwykłego chatbota: każda odpowiedź musi zawierać odniesienie do konkretnego źródła. Prompt musi jawnie wymagać: - Jakiego dokumentu, sekcji, strony. - Dosłownego cytowania wartości krytycznej zamiast parafrazowania. - Wyraźnego stwierdzenia, jeśli informacja nie znajduje się w dostępnych dokumentach.
Ten ostatni punkt jest decydujący. Odpowiedź „nie znajduję tej informacji w dostępnych instrukcjach" jest znacznie lepsza niż pewna siebie halucynowana wartość. Konfiguracja systemowego promptu, który nakłania model do wyraźnego wyrażania niepewności, jest ważniejsza niż wybór modelu. Więcej o cytatach i groundingu w RAG znajdziecie w artykule cytaty i grounding w RAG.
Ewaluacja przed wdrożeniem
Nie wystawiajcie techników na system, który nie był testowany na realnych pytaniach. Podstawowy zestaw ewaluacyjny:
- 50–100 pytań z rzeczywistych sytuacji, z którymi technicy faktycznie mają do czynienia
- Dla każdego pytania zweryfikowana odpowiedź z odniesieniem do źródła (gold standard)
- Pomiar: faithfulness (czy odpowiedź jest zgodna ze źródłem?), answer relevance (czy odpowiada na pytanie?), wskaźnik halucynacji
Systemy produkcyjne stawiają sobie cele: faithfulness ≥ 95 %, wskaźnik halucynacji ≤ 2 %. Prawidłowo zaimplementowany RAG redukuje halucynacje o 60–71 % w porównaniu z czystym LLM bez groundingu — ale ich nie eliminuje całkowicie.
Wybór modelu: cloud vs. on-prem
Dla dokumentów przemysłowych obowiązuje inna logika niż przy wdrożeniach publicznych. Dokumentacja techniczna często zawiera wewnętrzne know-how, parametry konstrukcyjne, procedury bezpieczeństwa. Wiele firm, zwłaszcza w branżach regulowanych, nie chce, aby te dane opuszczały ich infrastrukturę.
Modele open-weight on-prem są w 2026 roku realnym wyborem:
- Rodzina
Qwen 2.5iQwen 3(licencja Apache 2.0, odpowiednia do zastosowań komercyjnych) — silna w document understanding, w tym warianty multimodalne. Mistral Small(~22B) — dobry stosunek wydajności do wymagań sprzętowych.DeepSeek R1/V3(licencja MIT) — silny reasoning, odpowiedni do bardziej złożonych pytań o normy i ich interpretację.
Orientacyjne wymagania: do modelu 7B wystarczy karta z 12–14 GB VRAM (inferencja QLoRA/skwantyzowana), do modelu 22B potrzebujecie 24 GB+ lub kilku GPU. Więcej o doborze sprzętu w artykule custom PC dla lokalnych LLM.
Firmy bez danych wrażliwych lub z jasną polityką data governance mogą korzystać z frontierowych modeli (Claude Sonnet, klasa GPT-4o), które są wyraźnie lepsze w złożonym reasoningu nad dokumentami strukturalnymi — za cenę kosztów API i data egressu.
Uwarunkowania organizacyjne, których technologia nie rozwiąże
Na podstawie dziesiątek wdrożeń systemów RAG nad dokumentacją widzimy, że część techniczna jest zwykle mniejszym problemem niż organizacyjna.
Zarządzanie wersjami dokumentów. Jeśli instrukcja istnieje w pięciu wersjach na różnych dyskach współdzielonych bez jednoznacznego oznaczenia aktualnej — indeksujecie chaos. Przed wdrożeniem AI musi istnieć single source of truth — jedno miarodajne źródło aktualnej dokumentacji. To nie jest problem AI, lecz zarządzania dokumentami.
Odpowiedzialność za aktualizację indeksu. Kto i kiedy doda nową instrukcję? Kto unieważni starą wersję normy? Bez zdefiniowanego procesu system po 6 miesiącach pracuje na nieaktualnych danych, a technicy przestają mu ufać.
Realistyczne oczekiwania od techników. System, który nie odpowiada na 10 % pytań i mówi „nie wiem", jest prawidłowo skonfigurowanym systemem. Jeśli technicy oczekują 100 % pokrycia, pierwsze „nie wiem" zostanie zinterpretowane jako awaria. Onboarding jest częścią projektu.
Gdzie system zawodzi — i co z tym zrobić
Nawet dobrze zbudowany system ma swoje granice. Uczciwe zdefiniowanie tych granic przed uruchomieniem chroni projekt przed rozczarowaniem.
Bezpieczeństwo proceduralne: System nigdy nie powinien być jedynym źródłem prawdy przy procedurze pracy pod napięciem, pracy w strefie ATEX ani innych operacjach krytycznych pod względem bezpieczeństwa. Artykuł RAG vs. fine-tuning dla wdrożeń przemysłowych omawia, kiedy fine-tuning jest lepszy niż RAG właśnie w takich przypadkach — ale ani model fine-tunowany nie zastępuje certyfikowanego szkolenia i przeglądu przez osobę odpowiedzialną.
Nowe urządzenia bez dokumentacji: Jeśli urządzenie nie ma swojej dokumentacji w indeksie, system nie odpowie. To jest cecha, nie błąd — gorsze byłoby, gdyby halucynował dokumentację, która nie istnieje.
Złożona diagnostyka: Pytania w stylu „dlaczego moje urządzenie wibruje bardziej niż zwykle" wykraczają poza Q&A oparty na dokumentach. Tu jest miejsce dla analityki predykcyjnej i danych z czujników, a nie dla RAG nad instrukcjami.
Najczęstsze pytania
Czy potrzebujemy fine-tuningu, czy wystarczy RAG?
W przypadku większości use-casów nad dokumentacją wystarczy RAG — nie wymaga przygotowania datasetu, trenowania ani ryzyka degradacji modelu. Fine-tuning wnosi wartość, jeśli chcecie, aby model rozumiał specyficzną terminologię Waszej firmy lub odpowiadał w konkretnym formacie. Ramy decyzyjne znajdziecie w artykule RAG vs. fine-tuning.
Jak zapewnimy, że system nie będzie halucynować wartości technicznych?
Kombinacja trzech środków: (1) prompt, który jawnie zabrania odpowiadania poza dostępnymi źródłami i wymaga cytatu, (2) reranker, który poprawi jakość pobranego kontekstu, (3) zestaw ewaluacyjny z regularnymi testami. Wskaźnik halucynacji poniżej 2–3 % osiągniecie przy rzetelnej implementacji — zera nigdy.
Czy system obsłuży dokumenty w języku niemieckim, angielskim i polskim?
Tak, nowoczesne modele embeddingów (np. BGE-M3) są wielojęzyczne i działają dobrze między językami. Pytania i odpowiedzi mogą być w innym języku niż dokument źródłowy. W praktyce zalecamy indeksowanie dokumentów w ich oryginalnym języku i pozostawienie modelowi tłumaczenia w odpowiedzi — zachowuje to precyzję terminologii.
Jak długo trwa wdrożenie pilotu?
Pilotażowy system dla jednego typu dokumentacji (np. instrukcje do jednego urządzenia) z zestawem ewaluacyjnym i podstawowym UI mieści się w 4–8 tygodniach. Więcej czasu zabiera przygotowanie danych (OCR, czyszczenie, zarządzanie wersjami) niż sama implementacja techniczna. Pełnowartościowy system produkcyjny z wieloma typami dokumentacji i integracją z istniejącymi systemami: 3–6 miesięcy.
Czy działa to również dla norm ISO i dokumentów regulacyjnych?
Tak, ale z ważnym zastrzeżeniem: normy podlegają prawu autorskiemu (ISO, EN, PN). Nie można po prostu wgrać zakupionej normy do wewnętrznego systemu — należy zweryfikować warunki licencji. W praktyce firmy indeksują wewnętrzne dokumenty implementujące normę (przepisy techniczne, listy kontrolne) i odwołują się do konkretnych numerów wymagań zamiast dosłownie cytować tekst normatywny.
*Jeśli zastanawiacie się, jak w konkretnych warunkach Waszej dokumentacji zrobić pierwsze kroki — weryfikacja use-case, ocena dostępnych danych, projekt architektury — jesteśmy do dyspozycji w ramach konsultacji. MP Industrial Solutions wdraża RAG nad dokumentacją przemysłową od przygotowania danych po produkcyjne uruchomienie.*