Modele LLM w przemyśle: jak budować prywatnego asystenta dla dokumentacji i serwisu

Po co prywatny asystent LLM w przemyśle i kiedy ma sens

Realne problemy na hali produkcyjnej

W zakładach przemysłowych informacje techniczne są zwykle rozproszone między szafami z segregatorami, dyskami sieciowymi, systemem CMMS, a przede wszystkim – głowami doświadczonych techników. Gdy pojawia się awaria, liczy się każda minuta, a dostęp do wiedzy bywa kluczową barierą. Nawet jeśli dokumentacja istnieje, to:

• szukanie odpowiedniej strony w DTR-ce trwa zbyt długo,
• opis alarmu jest niejasny lub rozrzucony po kilku dokumentach,
• procedura była kiedyś opisana w mailu lub raporcie serwisowym i nikt już nie wie gdzie,
• ekspert od danej maszyny jest na innym wydziale albo na urlopie.

W efekcie diagnoza się wydłuża, rośnie presja na utrzymanie ruchu, a zespół serwisowy musi w kółko odpowiadać na te same pytania. LLM jako prywatny asystent serwisowy ma sens dokładnie tam, gdzie wąskim gardłem jest czas dotarcia do wiedzy, a nie brak samej wiedzy.

Gadżet AI kontra narzędzie operacyjne

LLM w przemyśle łatwo zamienić w efektowny „gadżet AI”, który raz na jakiś czas pokaże się na prezentacji, ale nie będzie realnie używany na produkcji. Różnica między gadżetem a narzędziem operacyjnym sprowadza się do kilku kryteriów:

• Czas reakcji – odpowiedź musi pojawić się w kilkanaście sekund, nie minutę czy dwie. Technik w okularach ochronnych przy hałaśliwej linii nie będzie czekał długo.
• Jakość odpowiedzi – liczy się precyzja, oparcie na dokumentach zakładowych i możliwość zweryfikowania źródła (linki do fragmentów DTR, schematów).
• Integracja z procesem – asystent serwisowy jest użyteczny, gdy wpisuje się w istniejący obieg pracy: raporty w CMMS, zgłoszenia serwisowe, procedury BHP.
• Stabilność – „czasem działa, czasem nie” dyskwalifikuje rozwiązanie w oczach produkcji; system musi być przewidywalny.

Jeśli LLM ma wspierać utrzymanie ruchu i serwis, to jego rolą nie jest generowanie „sprytnych odpowiedzi”, tylko skracanie ścieżki: pytanie → właściwy fragment dokumentacji → zrozumiała instrukcja działania.

Typowe scenariusze użycia w zakładzie

Prywatny asystent LLM dla dokumentacji i serwisu w przemyśle ma kilka powtarzalnych zastosowań, które zwykle da się wdrożyć krok po kroku:

• Szybkie Q&A z dokumentacji technicznej – technik wpisuje kod alarmu lub opis objawu, a asystent zwraca najważniejszą część instrukcji: możliwe przyczyny, kroki diagnostyczne, ostrzeżenia BHP, wymagane narzędzia.
• Wsparcie zdalnego serwisu – serwisant zewnętrzny lub wewnętrzny korzysta z asystenta jako „drugiego mózgu” podczas połączenia wideo, aby szybciej znaleźć parametry, sekwencje kalibracji lub ustawienia.
• Wsparcie projektowania i modernizacji – konstruktor lub inżynier procesu zadaje pytania o istniejące rozwiązania, standardy firmowe, listy części, wcześniejsze modyfikacje podobnych linii.
• Tworzenie i uzupełnianie raportów serwisowych – po zakończonej interwencji technik opisuje ustnie lub w krótkiej notatce przebieg prac, a asystent generuje bardziej szczegółowy raport zgodny z szablonem CMMS.

Każdy z tych scenariuszy wymaga nieco innej architektury i innego zakresu integracji, ale rdzeń pozostaje ten sam: połączenie modeli LLM z firmową bazą dokumentów technicznych.

Kiedy LLM faktycznie pomaga, a kiedy wystarczy zwykłe wyszukiwanie

Prywatny asystent LLM w przemyśle nie jest panaceum. Jeśli dokumentacja jest dobrze uporządkowana, a liczba maszyn niewielka, prosty system wyszukiwania pełnotekstowego w PDF-ach bywa całkowicie wystarczający. LLM ma przewagę, gdy:

• pytania są złożone („Co zrobić, jeśli przy starcie linii pojawia się alarm X, ale tylko przy recepturze Y?”),
• informacje są rozproszone po wielu plikach i trzeba je zebrać w jedną odpowiedź,
• użytkownicy zadają pytania językiem potocznym, a nie kodami błędów i numerami stron,
• część dokumentów to skany, notatki, maile – klasyczne wyszukiwanie radzi sobie z tym słabo.

Klasyczny FAQ lub wyszukiwarka po słowach kluczowych wystarczą, gdy pytań jest mało, treść jest prosta, a struktura dokumentacji jasna. Im bardziej rośnie złożoność, objętość i różnorodność danych, tym większy sens ma inwestycja w LLM i RAG dla dokumentacji.

Przybliżone progi skali, od których inwestycja jest opłacalna

Opłacalność zależy od kilku parametrów: liczby maszyn, złożoności linii, rotacji personelu, kosztu przestojów. Jako orientacyjne punkty odniesienia:

• kilka prostych maszyn, pełna DTR w jednym pliku, niewielka liczba awarii – wystarczy dobrze zorganizowana przestrzeń na serwerze i porządne nazwy plików;
• kilka linii złożonych, dokumentacja liczona w dziesiątkach tysięcy stron, wielu dostawców – asystent LLM zaczyna mieć sens jako narzędzie skracające czas szukania informacji;
• kilkanaście–kilkadziesiąt linii, rozbudowany park maszyn, rozproszony serwis, kilka lokalizacji – bez asystenta serwisowego LLM utrzymanie spójnej wiedzy staje się trudne i drogie.

Dodatkowo, im większy udział zewnętrznych serwisów, tym większą przewagę daje wewnętrzny prywatny asystent serwisowy: ogranicza „polowanie na eksperta” i zmniejsza zależność od pojedynczych osób.

Krótkie uporządkowanie pojęć: LLM, RAG, chatbot i agent

Czym jest LLM w praktyce i co potrafi bez firmowej dokumentacji

LLM (Large Language Model) to model językowy uczony na ogromnych zbiorach tekstu z internetu, książek, dokumentów publicznych. Potrafi:

• rozumieć i generować tekst w wielu językach,
• wyjaśniać pojęcia techniczne w zrozumiały sposób,
• tworzyć streszczenia, listy kroków, instrukcje na podstawie ogólnej wiedzy,
• tłumaczyć między językami (np. dokumentacja EN → opis PL).

Bez dostępu do dokumentacji firmowej nie zna jednak:

• konkretnych maszyn w danym zakładzie,
• ustawień parametrów, numerów części zamiennych, lokalnych oznaczeń,
• procedur wewnętrznych, standardów firmowych, specyficznych modyfikacji linii.

Aby model LLM stał się prywatnym asystentem serwisowym dla danej fabryki, trzeba go „podłączyć” do wewnętrznej bazy wiedzy technicznej – tu wchodzą w grę RAG i wyszukiwanie wektorowe.

„Czysty” LLM vs system RAG oparty na dokumentach zakładowych

„Czysty” LLM to model, który generuje odpowiedzi wyłącznie na podstawie swojej wbudowanej wiedzy. Przy pytaniach o specyfikę danej linii może „halucynować”, czyli wymyślać brakujące informacje, bo nie ma do nich dostępu. System RAG (Retrieval Augmented Generation) działa inaczej:

1. Na podstawie pytania użytkownika wyszukuje w bazie dokumentów najbardziej pasujące fragmenty.
2. Przekazuje te fragmenty do LLM jako kontekst.
3. LLM generuje odpowiedź, odwołując się do tych konkretnych dokumentów.

RAG dla dokumentacji oznacza więc połączenie dwóch elementów:

• wyszukiwania wektorowego – mechanizmu, który znajduje sensownie powiązane fragmenty dokumentów, nawet jeśli użytkownik użył innych słów niż w DTR;
• generowania odpowiedzi przez LLM – tak, aby wynik był zrozumiały, zwięzły i dopasowany do kontekstu pytania.

W przemysłowych zastosowaniach LLM niemal zawsze mówimy właśnie o RAG, a nie o „trenowaniu własnego modelu od zera”. Trenowanie to duży, kosztowny projekt, a RAG pozwala wykorzystać gotowe modele i połączyć je z firmową wiedzą.

Chatbot a agent serwisowy: prosta rozmowa kontra wykonywanie działań

Chatbot to głównie interfejs konwersacyjny: okienko, w którym użytkownik zadaje pytania i dostaje odpowiedzi. Może być bardzo użyteczny, jeśli dobrze podpięty do bazy dokumentów. Jednak w pracy serwisu i utrzymania ruchu przyda się coś więcej – agent serwisowy.

Agent to system, który oprócz rozmowy potrafi wykonywać konkretne kroki, np.:

• zadawać użytkownikowi dodatkowe pytania diagnostyczne na podstawie procedury,
• automatycznie przeszukać kilka różnych źródeł: DTR, bazę błędów, historię awarii w CMMS,
• wygenerować szkic raportu serwisowego na bazie dialogu,
• zasugerować listę części zamiennych i sprawdzić ich dostępność (jeśli jest integracja z magazynem).

Chatbot koncentruje się na rozmowie; agent łączy rozmowę z działaniem w systemach firmowych. Wdrożenie agenta serwisowego zwykle wymaga integracji z systemami CMMS, ERP lub rozwiązaniami do monitoringu maszyn, ale efekt może znacząco odciążyć doświadczonych specjalistów.

Dlaczego kluczowe jest połączenie LLM z wyszukiwaniem wektorowym

Dokumentacja techniczna jest rozbudowana, różnorodna i często niestandardowa. Klasyczne wyszukiwanie po słowach kluczowych nie radzi sobie z:

• różnymi sformułowaniami tego samego problemu („maszyna się zatrzymuje po starcie”, „przestój po inicjalizacji”),
• synonimami i skrótami stosowanymi w firmie,
• pytaniami opisowymi („ramię robota zatrzymuje się w połowie ruchu i świeci dioda X”).

Wyszukiwanie wektorowe opiera się na embeddingach – numerycznej reprezentacji znaczenia tekstu. Każdy fragment dokumentu (kilka zdań, akapit, sekcja) zamieniany jest na wektor liczb. Pytanie użytkownika też zamieniane jest na wektor i porównywane z tymi zapisanymi w bazie. Dzięki temu system znajduje fragmenty, które są „bliskie znaczeniowo”, nawet jeśli nie zawierają tych samych słów.

W praktyce oznacza to, że prywatny asystent serwisowy potrafi powiązać opis objawu podany przez technika z właściwą sekcją dokumentacji, mimo różnic w słownictwie. Bez wyszukiwania wektorowego LLM będzie skazany na kłopotliwe „zgadywanie” na podstawie ogólnej wiedzy.

Kluczowe pojęcia: kontekst, tokeny, embeddingi, baza wektorowa

W kontekście asystenta dla dokumentacji technicznej pojawia się kilka pojęć technicznych, które dobrze uporządkować:

• Kontekst – fragment tekstu (zwykle kilka–kilkanaście stron DTR lub kilka akapitów), który jest przekazywany do modelu LLM razem z pytaniem. Im dłuższy kontekst obsługuje model, tym więcej fragmentów może wziąć „na raz” do odpowiedzi.
• Tokeny – minimalne jednostki tekstu, na których operuje model (fragmenty słów, znaki). Ograniczenie liczby tokenów określa, jak duży może być jednorazowy kontekst.
• Embeddingi – reprezentacja tekstu jako wektora liczb w przestrzeni wielowymiarowej; służą do podobieństwa semantycznego.
• Baza wektorowa – specjalny typ bazy danych, która przechowuje embeddingi i pozwala szybko znaleźć najbardziej podobne do siebie wektory (czyli powiązane znaczeniowo fragmenty tekstu).

W praktyce: dokumenty techniczne są dzielone na mniejsze fragmenty, każdy fragment dostaje embedding, embeddingi trafiają do bazy wektorowej. Gdy użytkownik zada pytanie, powstaje embedding tego pytania, a baza zwraca najbliższe fragmenty dokumentacji do podania w kontekście LLM.

Identyfikacja potrzeb: dla kogo budowany jest asystent i jakie problemy ma rozwiązywać

Segmentacja użytkowników w zakładzie przemysłowym

Prywatny asystent LLM w przemyśle będzie inaczej używany przez utrzymanie ruchu na zmianie nocnej, inaczej przez biuro konstrukcyjne, a jeszcze inaczej przez dział BHP. Pierwszy krok to jasne określenie grup użytkowników:

• Utrzymanie ruchu – technicy, brygadziści, liderzy linii; potrzebują szybkich odpowiedzi na pytania „co zrobić tu i teraz”.
• Serwis zewnętrzny – firmy serwisowe dostawców; zwykle ograniczony czas na miejscu i ograniczony dostęp do wewnętrznej dokumentacji.
• Konstruktorzy i inżynierowie procesu – pytania o wcześniejsze modyfikacje, standardy firmowe, integrację nowych maszyn.
• Planowanie produkcji i logistyka – zainteresowani wpływem awarii i czasem napraw na plan, czasem również analizą powtarzalnych błędów.
• BHP i jakość – dostęp do instrukcji bezpiecznego wykonywania prac, analiz powypadkowych, procedur jakościowych.

Typowe scenariusze użycia dla poszczególnych ról

Gdy zidentyfikowane są grupy użytkowników, kolejnym krokiem jest przełożenie tego na konkretne scenariusze. Dobrze opisany scenariusz zawiera: kto korzysta, w jakiej sytuacji, z jakim celem i jak mierzymy, że było to pomocne.

• Technik utrzymania ruchu na zmianie – zgłoszenie: „Maszyna X zatrzymała się, błąd F04, reset nie pomaga”. Asystent prowadzi przez kroki diagnostyczne z DTR, podsuwa listę możliwych przyczyn z historii awarii oraz generuje notatkę do zgłoszenia w CMMS.
• Inżynier procesu – pytanie: „Jakie były ostatnie trzy modyfikacje programu robota na gnieździe 3 i kto je zatwierdzał?”. Asystent łączy informacje z repozytorium wersji, dokumentacji zmian i bazy uprawnień.
• BHP – zadanie: przygotowanie instruktażu z bezpiecznego czyszczenia konkretnej linii. Asystent łączy wytyczne BHP, instrukcję producenta i wewnętrzne standardy lockout/tagout.

Jeśli na tym etapie scenariusze są ogólne („szybszy dostęp do wiedzy”), projekt będzie dryfował. Pomaga krótka lista kryteriów:

• czy scenariusz dotyczy realnego, powtarzalnego problemu,
• czy można go zmierzyć (czas reakcji, liczba eskalacji, czas wyszukania informacji),
• czy są dostępne dane, aby asystent miał z czego „korzystać”,
• czy użytkownicy mają narzędzia (tablet, komputer przy linii, telefon), aby faktycznie używać asystenta.

Priorytetyzacja funkcji: co na start, a co później

Zakres funkcji asystenta łatwo „rozjechać” – od prostego Q&A po system, który integruje pół fabryki. Rozsądne podejście to podział na cztery koszyki:

• MVP (must have) – funkcje konieczne, aby asystent był realnie używalny: wyszukiwanie po dokumentacji DTR, instrukcjach wewnętrznych i bazie usterek; generowanie odpowiedzi z odniesieniem do źródła.
• Quick wins – elementy, które szybko zwiększą akceptację użytkowników: generowanie streszczeń długich procedur, podpowiedzi kolejnych pytań, szablony raportów serwisowych.
• Integracje krytyczne – powiązania z systemami, od których zależy codzienna praca: CMMS (historia awarii), system zgłoszeń, repozytorium dokumentacji technicznej.
• Rozszerzenia – funkcje, które można dołożyć, gdy podstawy działają: powiadomienia proaktywne, rekomendacje części na bazie danych magazynowych, analiza trendów usterek.

Jeśli pierwsze wdrożenie skupi się na jednym–dwóch dobrze opisanych scenariuszach, łatwiej o akceptację użytkowników i szybki zwrot z inwestycji. Rozbudowę funkcji można prowadzić iteracyjnie, reagując na realne potrzeby zamiast założeń z etapu koncepcji.

Mierzalne cele biznesowe i techniczne

Określenie celów tylko w kategoriach „poprawa efektywności” prowadzi do rozczarowania. Lepiej powiązać asystenta z konkretnymi wskaźnikami:

• czas wyszukania kluczowych informacji – np. skrócenie średniego czasu znalezienia właściwej procedury o określony procent,
• liczba eskalacji do „guru zakładowego” – spadek zapytań kierowanych do jednej–dwóch osób, które do tej pory „trzymały” wiedzę,
• czas przywrócenia pracy (MTTR) – na wybranych typach awarii, gdzie dokumentacja jest kluczowa,
• liczba powtarzających się błędów operacyjnych – np. błędnie wykonane przezbrojenie, niewłaściwa sekwencja startu linii.

Po stronie technicznej sensowne są miary typu: odsetek odpowiedzi oznaczonych przez użytkowników jako pomocne, liczba pytań bez dobrego dopasowania w bazie, czas indeksacji nowej dokumentacji. Te dane później determinują, w co inwestować: lepszą jakość danych, dodatkowe integracje czy zmianę konfiguracji RAG.

Jakie dane i dokumenty są potrzebne, aby asystent miał sens

Mapa źródeł wiedzy technicznej

W większości zakładów wiedza techniczna jest rozproszona. Zanim pojawi się pierwsza linijka kodu, trzeba zidentyfikować główne źródła:

• DTR i instrukcje producentów – często w PDF, czasem skany, bywa, że w kilku wersjach językowych i z różnym poziomem aktualności.
• Instrukcje stanowiskowe i procedury wewnętrzne – dokumenty Word, PDF, pliki na dyskach sieciowych, w SharePoint lub systemach DMS.
• Raporty z awarii i przeglądów – dane z CMMS, systemów ticketowych, arkuszy Excel, czasem notatki w mailach.
• Bazy błędów i „FAQ serwisowe” – nieformalne zbiory wiedzy, często w formie notatek techników, plików „tip&tricks” lub postów na wewnętrznych forach.
• Dane z systemów nadzoru i monitoringu – logi PLC, systemy SCADA, rejestry alarmów, historię sygnałów.

Celem nie jest wciągnięcie wszystkiego naraz, tylko stworzenie mapy: skąd co pochodzi, kto odpowiada za aktualność, jaki jest format i jakość danych oraz jakie ograniczenia prawne lub licencyjne mogą wystąpić (np. dokumentacja dostawców).

Jakość dokumentacji: kompletność, aktualność, struktura

Nawet najlepszy model nie „naprawi” dziurawej lub nieaktualnej dokumentacji. Trzeba uczciwie odpowiedzieć na kilka pytań:

• czy do kluczowych maszyn i linii są kompletne DTR w ostatniej wersji,
• czy instrukcje wewnętrzne i procedury są spójne z bieżącym stanem parku maszynowego,
• czy są zdefiniowane standardy nazewnictwa (oznaczenia linii, urządzeń, numerów części).

W praktyce wdrożenie asystenta bywa impulsem do uporządkowania dokumentacji. Typowy przykład: przy pierwszym indeksowaniu wychodzi na jaw, że dla tej samej maszyny istnieją trzy różne instrukcje, podpisane różnymi datami, ale bez jasnej informacji, która jest obowiązująca. Jeśli zespół nie wskaże wersji referencyjnej, asystent będzie mieszał treści.

Formaty plików i ich „przyjazność” dla LLM

Modele i system RAG operują na tekście, więc każdy dokument musi zostać z niego „wyciągnięty”. Decyduje o tym format i jakość:

• PDF tekstowy – najlepszy przypadek, tekst można odczytać automatycznie, układ nagłówków często jest rozpoznawalny.
• PDF będący skanem – wymaga OCR. Jeśli oryginał jest słabej jakości, pojawiają się błędy w tekście (błędne cyfry, znaki specjalne).
• Obrazy, zrzuty paneli HMI, schematy – w wielu przypadkach przydaje się OCR + ręczne dodanie opisów, albo pozostawienie ich jako załączników, do których asystent odsyła użytkownika.
• Pliki CAD, schematy elektryczne – same w sobie trudne dla LLM; tu istotne są opisy, legendy, spisy złącz i sygnałów, które można przekształcić w tekst.

Jeśli zdecydowana większość dokumentacji to skany bez OCR, projekt powinien uwzględnić etap masowego rozpoznawania tekstu i kontroli jakości. Bez tego odpowiedzi asystenta będą pełne artefaktów lub pomijać kluczowe informacje.

Strukturyzacja treści: podział na fragmenty i metadane

RAG nie operuje na „całej instrukcji” jako jednym blokiem, tylko na mniejszych fragmentach. Sposób dzielenia dokumentów ma znaczenie dla jakości odpowiedzi:

• Podział logiczny – fragmenty oparte o sekcje i podsekcje dokumentu (Rozdział 4 – Diagnostyka, 4.1 – Alarmy, 4.1.1 – Kod błędu F04).
• Podział techniczny – np. co kilka akapitów lub co określoną liczbę znaków, gdy dokument nie ma wyraźnej struktury.

Do każdego fragmentu warto dodać metadane:

• identyfikator maszyny lub linii,
• producenta,
• wersję dokumentu i datę obowiązywania,
• język,
• typ dokumentu (DTR, instrukcja stanowiskowa, raport z awarii).

Metadane pozwalają ograniczyć wyszukiwanie do właściwego zakresu (np. tylko dla konkretnej linii lub tylko dokumentów po polsku), co znacząco zmniejsza ryzyko „przemycenia” nieaktualnych informacji w odpowiedziach.

Dane wrażliwe i zakres dostępów

W środowisku przemysłowym część dokumentacji ma ograniczony dostęp: informacje o bezpieczeństwie, receptury, parametry krytyczne procesów, dane klientów. Projektując asystenta, trzeba określić:

• jakie typy dokumentów w ogóle nie powinny być indeksowane,
• które mogą być indeksowane, ale z kontrolą dostępu na poziomie użytkownika lub grupy,
• czy asystent ma „wiedzieć”, że istnieje dokument, do którego użytkownik nie ma dostępu (i odpowiednio to komunikować),
• jak logowane są pytania i odpowiedzi – czy nie za