Výrobná hala, dve hodiny ráno. Skúsený technik hľadá v 3 400-stranovom manuáli zariadenia, aký typ a množstvo maziva predpisuje výrobca pre ložisko pri teplote nad 80 °C. PDF má nekonzistentné číslovanie strán, tabuľka s hodnotami je naskenovaná ako obrázok a norma, na ktorú manuál odkazuje, je v samostatnom súbore. Po 40 minútach nájde, čo hľadal. Tá istá situácia sa opakuje desiatky ráz za zmenu, naprieč celým závodom.
Presne tento problém riešia LLM nad priemyselnou dokumentáciou. Nejde o buzzword — ide o konkrétny, overiteľný use-case, kde správne nasadený systém ušetrí merateľné hodiny na operátora mesačne. Tento článok rozhoduje: čo funguje, kde naivný prístup zlyhá, a čo musíte vyriešiť skôr, ako začnete.
Čo vlastne chcete dosiahnuť
Pred architektúrou si ujasnite, čo od systému očakávate. V praxi vídame tri rôzne use-cases, ktoré sa podobajú, ale majú odlišné požiadavky:
1. Vyhľadávanie a Q&A pre technikov — technik sa pýta prirodzenou otázkou, systém odpovedá s odkazom na konkrétnu časť manuálu alebo normy. Nie prepis textu, ale odpoveď s citáciou: „Podľa sekcie 7.3.2 manuálu zariadenia XY je predpísané mazivo ISO VG 220, aplikovať každých 2 000 prevádzkových hodín."
2. SOP navigácia a krok-za-krokom asistencia — operátor pracuje podľa postupu a potrebuje vysvetlenie kroku, alternatívu pri nedostupnom nástrojí, alebo rýchle overenie, či robí správnu vec. Systém musí byť deterministický a presný — chybná odpoveď pri výrobnom postupe má priame náklady.
3. Normatívna zhoda a auditná podpora — inžinier potrebuje rýchlo zistiť, ktoré časti dokumentácie pokrývajú požiadavky konkrétnej normy (napr. ISO 9001, IEC 62443, ATEX), alebo identifikovať medzery. Vyžaduje pochopenie štruktúry normy aj internej dokumentácie.
Každý z týchto use-casov má iné požiadavky na presnos, latenciu a spôsob evaluácie. Miešať ich v jednom pilote je bežná chyba.
Prečo naivný RAG na priemyselných dokumentoch nefunguje
RAG — skratka pre retrieval-augmented generation — je základná architektúra: rozdeliš dokumenty na časti (chunky), uložíš ich do vektorovej databázy, pri otázke nájdeš relevantné časti a predložíš ich modelu. Na bežných dokumentoch funguje dobre. Na priemyselných dokumentoch narazíte na štyri problémy, ktoré treba aktívne riešiť.
Problém 1: Tabuľky rozseká naivný chunking
Manuál k zariadeniu obsahuje tabuľku s 30 riadkami a 8 stĺpcami: typ zariadenia, pracovná teplota, typ maziva, interval, množstvo, norma, poznámka, nadmorská výška. Naivný chunking podľa počtu znakov rozseká túto tabuľku na 4 fragmenty. Každý fragment stráca kontext stĺpcov, ktoré boli na predchádzajúcej strane.
Riešenie: dokumentový parser, ktorý rozpoznáva tabuľky a zachováva ich ako celok, prípadne konvertuje do štruktúrovanej formy (JSON, Markdown tabuľka). Nástroje ako LlamaIndex majú špecializované parsery pre tieto prípady. Multimodálne modely (napr. Qwen2.5-VL) vedia tabuľky extrahovať aj z naskenovaných PDF — čo je časté v starších manuáloch.
Problém 2: Výkresy a schémy sú pre text-only RAG neviditeľné
Elektrické schémy, hydraulické diagramy, P&ID (piping and instrumentation diagrams) — to sú kľúčové časti technickej dokumentácie, ktoré text-only pipeline jednoducho preskočí. Ak technik pýta „kde je umiestnený ventil V-12 na hydraulickej schéme linky L2", text-only RAG odpovie „informácia sa v dokumentoch nenachádza" alebo halucinuje.
Riešenie závisí od dostupnosti zdrojov. Ľahšia cesta: pre kľúčové výkresy vytvoriť štruktúrované textové popisy (raz, manuálne alebo s pomocou VLM), ktoré sa indexujú spolu s ostatným textom. Náročnejšia cesta: plnohodnotný multimodálny pipeline, kde VLM generuje popis obrázka priamo pri indexácii — funguje, ale vyžaduje výpočtovo nákladný model pri každom pridaní dokumentu.
Problém 3: Verzie noriem a cross-referencie
Priemyselná dokumentácia je plná odkazov: „postupujte podľa ISO 14119:2013, príloha D" alebo „pozri výkres D-04-7812-rev3". Naivný RAG tieto referencie nevyrieši — načíta fragment, kde je zmienka o norme, ale nemá prístup k samotnému obsahu normy, ak nie je v indexe. Výsledok: odpoveď, ktorá odcituje odkaz, ale neobsahuje skutočnú informáciu.
Riešenie: dôsledná správa zdrojov. Pred nasadením je nutné explicitne rozhodnúť, ktoré normy a ich verzie sú súčasťou indexu, a zaviesť proces aktualizácie pri revíziách. Toto je organizačný problém rovnako ako technický.
Problém 4: Context window nie je neobmedzený
Aj 1M-tokenové kontextové okno frontiérnych modelov nie je riešenie pre 5 000-stránkový manuál. Pozornosť modelu sa pri extrémne dlhých vstupoch rozptyľuje — jav, ktorý výskum opakovane potvrdzuje. RAG zostáva relevantné aj pri modeloch s dlhým kontextom, pretože selektívne načíta len relevantné časti namiesto celého dokumentu.
Ako postaviť spoľahlivý pipeline
Skúsený pipeline pre priemyselnú dokumentáciu má niekoľko vrstiev nad základným RAG.
Dokumentová príprava (ingestion)
Toto je najdlhší krok a najviac podceňovaný. Pred indexáciou:
- Rozlíšiť typy obsahu: čistý text, tabuľky, obrázky, výkresy. Každý typ zaslúži iné spracovanie.
- Naskenované dokumenty cez OCR — nie starý
Tesseractpre komplexné technické dokumenty, ale špecializovaný VLM alebo document intelligence API, ktorý rozumie kontextu strany (číslo v pravom rohu = číslo stránky, to isté číslo v tabuľke = kritická hodnota). Viac o tejto vrstve v článku OCR a document intelligence pre priemysel. - Metadata: pre každý chunk uložiť zdrojový dokument, číslo strany, sekciu, verziu dokumentu, dátum platnosti. Bez metadát nie sú možné citácie.
- Hierarchická štruktúra: kapitola → podkapitola → tabuľka/postup.
LlamaIndexmá natívnu podporu pre hierarchické chunkovanie.
Retrieval — viac ako len vektorové vyhľadávanie
Samotné vektorové vyhľadávanie má slabiny: zachytí sémanticky podobné časti, ale môže minúť presnú zhodu kľúčového slova (číslo dielu, kód alarmu, označenie zariadenia). Hybrid search — kombinácia BM25 (kľúčové slová) a vektorov — je v priemyselnom kontexte dôležitejší ako v bežnom. Pozrite sa na hybrid search s BM25 a vektormi, kde je to rozvedené do detailov.
Nad hybridným vyhľadávaním pridajte reranker — model, ktorý zoradí výsledky podľa relevancie otázke. BGE reranker (voľne dostupný) alebo API (napr. Cohere Rerank) výrazne zlepší presnosť pri dlhých dokumentoch s opakujúcimi sa frázami.
Generovanie s citáciami
Toto je kľúčový rozdiel od bežného chatbota: každá odpoveď musí obsahovať odkaz na konkrétny zdroj. Prompt musí explicitne požadovať: - Ktorý dokument, sekcia, strana. - Doslové citovanie kritickej hodnoty namiesto parafrázovanie. - Explicitné vyjadrenie, ak informácia v dostupných dokumentoch nie je.
Posledný bod je rozhodujúci. Odpoveď „v dostupných manuáloch túto informáciu nenachádzam" je výrazne lepšia ako sebavedomá halucinovaná hodnota. Nastavenie systémového promptu, ktorý model nabáda k explicitnému vyjadreniu neistoty, je dôležitejšie ako výber modelu. Viac o citáciách a groundingu v RAG nájdete v článku citácie a grounding v RAG.
Evaluácia pred nasadením
Nevystavujte technikov systému, ktorý ste netestovali na reálnych otázkach. Základný evaluačný set:
- 50–100 otázok z reálnych situácií, ktoré technici skutočne riešia
- Pre každú otázku overená odpoveď s odkazom na zdroj (gold standard)
- Meranie: faithfulness (je odpoveď v súlade so zdrojom?), answer relevance (odpovedá na otázku?), miera halucinácií
Produkčné systémy si kladú ciele: faithfulness ≥ 95 %, halucinačná miera ≤ 2 %. Správne implementovaný RAG znižuje halucinovanie o 60–71 % oproti čistému LLM bez grounding — ale neodstraňuje ho úplne.
Výber modelu: cloud vs. on-prem
Pre priemyselné dokumenty platí iná logika ako pre verejné nasadenia. Technická dokumentácia často obsahuje interné know-how, konštrukčné parametre, bezpečnostné postupy. Mnohé firmy, najmä v regulovaných odvetviach, nechcú tieto dáta mimo svojej infraštruktúry.
On-prem open-weight modely sú v 2026 reálnou voľbou:
Qwen 2.5aQwen 3rodina (licencia Apache 2.0, vhodná pre komerčné nasadenie) — silné pri document understanding vrátane multimodálnych variantov.Mistral Small(~22B) — dobrý pomer výkonu a nárokov na HW.DeepSeek R1/V3(MIT licencia) — silný reasoning, vhodný pre zložitejšie otázky o normách a ich interpretácii.
Orientačné nároky: pre 7B model stačí karta s 12–14 GB VRAM (QLoRA/quantized inference), pre 22B model potrebujete 24 GB+ alebo viac GPU. Viac o výbere HW v článku custom PC pre lokálne LLM.
Pre firmy bez citlivých dát alebo s jasnou data governance politikou sú frontiérne modely (Claude Sonnet, GPT-4o trieda) výrazne lepšie v komplexnom reasoningu nad štruktúrovanými dokumentmi — za cenu API nákladov a dátového egressu.
Organizačné predpoklady, ktoré technológia nevyrieši
Z desiatok nasadení RAG systémov nad dokumentáciou sme videli, že technická časť je zvyčajne menší problém ako organizačná.
Správa verzií dokumentov. Ak manuál existuje v piatich verziách na rôznych zdieľaných diskoch bez jasného označenia aktuálnej, indexujete chaos. Pred nasadením AI musí existovať single source of truth — jeden autoritatívny zdroj aktuálnej dokumentácie. Toto nie je problém AI, ale document management.
Zodpovednosť za aktualizáciu indexu. Kto a kedy pridá nový manuál? Kto zneplatní starú verziu normy? Bez definovaného procesu systém po 6 mesiacoch pracuje s neaktuálnymi dátami a technici mu prestanú veriť.
Primerané očakávania od technikov. Systém, ktorý neodpovedá na 10 % otázok a hovorí „neviem", je správne nakonfigurovaný systém. Ak technici očakávajú 100 % pokrytie, prvé „neviem" bude interpretované ako zlyhanie. Onboarding je súčasť projektu.
Kde systém zlyhá — a čo s tým
Aj dobre postavený systém má hranice. Poctivé zadefinovanie týchto hraníc pred spustením chráni projekt pred sklamaním.
Procedurálna bezpečnosť: Systém by nikdy nemal byť jediným zdrojom pravdy pre postup pri práci pod napätím, prácu v ATEX zóne alebo iné bezpečnostne kritické operácie. RAG vs. fine-tuning pre priemyselné nasadenia rozoberá, kedy je fine-tuning lepší ako RAG práve pre tieto prípady — ale ani fine-tuned model nenahrádza certifikovaný tréning a revíziu zodpovednou osobou.
Nové zariadenia bez dokumentácie: Ak zariadenie nie je v indexe, systém neodpovie. Toto je feature, nie bug — horšie je, ak by halucinoval dokumentáciu, ktorá neexistuje.
Komplexná diagnostika: Otázky typu „prečo moje zariadenie vibruje viac ako zvyčajne" presahujú dokumentovú Q&A. Tu je miesto pre prediktívnu analytiku a senzorové dáta, nie pre RAG nad manuálmi.
Časté otázky
Potrebujeme fine-tuning, alebo stačí RAG?
Pre väčšinu use-casov nad dokumentáciou stačí RAG — nevyžaduje prípravu datasetu, tréning ani riziko degradácie modelu. Fine-tuning pridá hodnotu, ak chcete, aby model rozumel špecifickej terminológii vašej firmy alebo odpovedal v konkrétnom formáte. Rozhodovací rámec je v článku RAG vs. fine-tuning.
Ako zabezpečíme, že systém nebude halucinovať technické hodnoty?
Kombinácia troch opatrení: (1) prompt, ktorý explicitne zakazuje odpovedať mimo dostupných zdrojov a vyžaduje citáciu, (2) reranker, ktorý zlepší kvalitu retrieved kontextu, (3) evaluačný set s pravidelnými testmi. Halucinačnú mieru pod 2–3 % dosiahnete pri dôslednej implementácii — nulu nikdy.
Zvládne systém dokumenty v nemčine, angličtine aj slovenčine?
Áno, moderné embedding modely (napr. BGE-M3) sú multilingválne a fungujú dobre naprieč jazykmi. Otázky aj odpovede môžu byť v inom jazyku ako zdrojový dokument. V praxi odporúčame indexovať dokumenty v ich originálnom jazyku a nechať model prekladať v odpovedi — zachováva sa presnosť terminológie.
Koľko trvá implementácia pilotu?
Pilotný systém pre jeden typ dokumentácie (napr. manuály k jednému zariadeniu) s evaluačným setom a základným UI je v rozsahu 4–8 týždňov. Dlhší čas zaberá príprava dát (OCR, čistenie, správa verzií) ako samotná technická implementácia. Plnohodnotný produkčný systém s viacerými typmi dokumentácie a integráciou do existujúcich systémov: 3–6 mesiacov.
Funguje to aj pre ISO normy a regulačné dokumenty?
Áno, ale s dôležitou výhradou: normy sú podrobené autorskému právu (ISO, EN, STN). Nemôžete len tak nahrať zakúpenú normu do interného systému — overte licenčné podmienky. V praxi firmy indexujú interné dokumenty, ktoré normu implementujú (technické predpisy, kontrolné listy), a odkazujú na konkrétne čísla požiadaviek namiesto doslova citovaného normatívneho textu.
*Ak zvažujete, ako v konkrétnych podmienkach vašej dokumentácie spraviť prvé kroky — overenie use-case, posúdenie dostupných dát, návrh architektúry — sme k dispozícii na konzultáciu. MP Industrial Solutions implementuje RAG nad priemyselnou dokumentáciou od začiatku prípravy dát po produkčné nasadenie.*