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 zawierają wrażliwych treści, które trafią do logów systemu LLM.

Jeśli asystent ma wspierać również zewnętrzny serwis, zakres danych dla takich użytkowników powinien być dodatkowo ograniczony i przejrzysty. Nie chodzi tylko o bezpieczeństwo, ale też o ryzyko nieporozumień – dostawca widzi wtedy wyłącznie informacje, za które jest faktycznie odpowiedzialny.

Częstotliwość zmian i proces aktualizacji

Dokumentacja techniczna, szczególnie w zakładach z intensywną modernizacją, zmienia się często. Warto z góry ustalić:

• jak szybko nowe dokumenty lub wersje mają się pojawiać w asystencie (np. w ciągu 24 godzin od publikacji),
• kto odpowiada za oznaczanie dokumentów jako „nieaktualne” i usuwanie ich z indeksu,
• czy proces publikacji dokumentów (np. w DMS) będzie zautomatyzowany tak, aby automatycznie uruchamiał indeksację.

Technicznie jest to kwestia integracji, ale organizacyjnie – kwestia dyscypliny. Bez jasnego procesu aktualizacji asystent będzie powielał stare instrukcje, co może być groźne w kontekście BHP lub jakości.

Architektury rozwiązań: od prostego Q&A po zaawansowanego agenta serwisowego

Najprostszy wariant: wewnętrzny „Google” z warstwą LLM

Na początek wiele firm wybiera prosty wariant:

• baza dokumentów technicznych (np. DTR, instrukcje wewnętrzne) jest zindeksowana wektorowo,
• użytkownik wpisuje pytanie w przeglądarce,
• system wyszukuje kilka najbardziej pasujących fragmentów i przekazuje je do LLM,
• LLM generuje odpowiedź, wskazując źródła (linki do fragmentów dokumentów).

To rozwiązanie nie ingeruje w istniejące systemy produkcyjne ani CMMS, więc jest stosunkowo łatwe do wdrożenia. Sprawdza się jako pilotaż w jednej fabryce lub nawet na jednej linii. Ograniczeniem jest to, że asystent nie zna historii awarii, bieżącego stanu maszyn ani kontekstu użytkownika poza tym, co ten wpisze w pytaniu.

Rozszerzony Q&A: personalizacja i kontekst użytkownika

Kolejny krok to dodanie informacji o użytkowniku i jego otoczeniu. System może:

• rozpoznawać, z jakiej linii lub strefy loguje się użytkownik (np. na podstawie terminala lub konta),
• automatycznie uwzględniać w wyszukiwaniu tylko dokumenty związane z tą linią,
• pamiętać historię rozmowy w ramach jednego zgłoszenia.

Przykład: technik loguje się przy terminalu linii A i wpisuje „błąd F04 na prasie”. Asystent rozumie, że chodzi o konkretną prasę na linii A, nie o dowolną maszynę w zakładzie. Ogranicza więc wyszukiwanie do tej maszyny, a jeśli pojawiają się podobne błędy na innych liniach, może to zasugerować dodatkowo.

Integracja z CMMS: asystent jako „front” do historii awarii

Gdy podstawowy Q&A działa stabilnie, naturalnym rozszerzeniem jest integracja z systemem CMMS. Architektura obejmuje wówczas:

• moduł do odczytu zgłoszeń, historii awarii, planów przeglądów,
• warstwę, która zamienia te dane na tekst nadający się do indeksowania i przeszukiwania wektorowego,
• mechanizmy anonimizacji, jeśli w CMMS pojawiają się dane osobowe.

Asystent może wtedy:

• podpowiadać najbardziej prawdopodobne przyczyny błędu na podstawie historii podobnych awarii,
• proponować działania prewencyjne, które wcześniej rozwiązały podobny problem,
• spinać bieżący dialog z tworzeniem lub uzupełnianiem zgłoszenia w CMMS.

Połączenie z systemami OT i monitoringiem: kontekst czasu rzeczywistego

Gdy asystent ma faktycznie pomagać w serwisie, sama dokumentacja i historia awarii przestają wystarczać. Kluczowy staje się dostęp do bieżących danych z warstwy OT:

• systemów SCADA i DCS,
• logów z PLC i paneli HMI,
• systemów monitoringu kondycji (vibracja, temperatura, prądy),
• systemów zbierania danych procesowych (historians).

Architektonicznie lepszym rozwiązaniem jest warstwa pośrednia (API), która udostępnia LLM „przetrawione” dane, a nie bezpośredni dostęp do każdego systemu. Taka warstwa może np. zbudować krótkie podsumowanie:

• jakie alarmy i kody błędów wystąpiły na danej maszynie w ostatniej godzinie,
• jakie były kluczowe parametry procesu w momencie wystąpienia błędu,
• czy w tym samym czasie pojawiły się podobne symptomy na innych maszynach tej linii.

LLM nie musi widzieć pełnego zrzutu z SCADA. Zwykle wystarczy zwięzły opis, np. „Alarm F04: przeciążenie osi X, temperatura silnika 88°C (norma do 75°C), prąd silnika powyżej progu od 12 min”. Na tej podstawie model może połączyć bieżące dane z wpisami w historii awarii oraz fragmentami DTR i zaproponować kierunek działania.

Bezpieczeństwo integracji z systemami produkcyjnymi

Każde połączenie asystenta z systemami OT i produkcyjnymi podnosi poprzeczkę w obszarze cyberbezpieczeństwa. Kluczowe są trzy aspekty:

1. Rozdzielenie stref – asystent nie łączy się bezpośrednio z siecią sterowania, tylko przez strefę pośrednią (DMZ, serwery aplikacyjne). Dane są wyciągane jednokierunkowo z systemów OT, bez możliwości sterowania.
2. Kontrola zakresu akcji – jeśli agent może wykonywać jakieś operacje (np. tworzyć zgłoszenia, zmieniać statusy), to powinno być to jasno ograniczone i logowane. W środowisku produkcyjnym agent nie powinien mieć żadnej ścieżki do zmiany nastaw procesowych.
3. Autoryzacja na poziomie użytkownika – asystent działa „w imieniu” zalogowanej osoby. Zakres widocznych danych i możliwych działań jest dziedziczony z uprawnień użytkownika w systemach źródłowych.

W praktyce rozsądne jest założenie, że moduł LLM jest traktowany jak zewnętrzny system, nawet jeśli działa lokalnie. Zapobiega to niekontrolowanemu dzieleniu się danymi i wymusza przemyślane interfejsy.

Agent serwisowy: od podpowiedzi do prowadzenia całego procesu

Zaawansowany agent serwisowy nie tylko odpowiada na pojedyncze pytania, ale prowadzi użytkownika przez cały cykl obsługi problemu – od zgłoszenia, przez diagnozę, po zamknięcie. W praktyce obejmuje to kilka klas funkcji:

• Asystowanie przy zgłoszeniu – agent pomaga poprawnie opisać problem, dopytuje o brakujące informacje („jaka dokładnie maszyna?”, „jaki numer alarmu na HMI?”) i automatycznie tworzy zgłoszenie w CMMS z dobrze ustrukturyzowanymi polami.
• Diagnoza wieloźródłowa – agent łączy dane z DTR, historii awarii, bieżących alarmów i np. raportów z audytów, aby zasugerować najbardziej prawdopodobne scenariusze.
• Przebieg krok po kroku – zamiast jednorazowej odpowiedzi „zrób A, B, C”, agent prowadzi dialog: po wykonaniu kroku użytkownik potwierdza efekt, a agent proponuje kolejne działania, modyfikując ścieżkę.
• Automatyczne uzupełnianie dokumentacji – po zakończeniu naprawy agent na podstawie rozmowy i danych z systemów źródłowych generuje wstępny raport z awarii do akceptacji technika.

Taki agent wymaga już nie tylko RAG, ale także warstwy planowania i orkiestracji akcji, często określanej jako „agentic” – model podejmuje decyzję, które narzędzia (API) wywołać, w jakiej kolejności i kiedy poprosić człowieka o weryfikację.

Projektowanie narzędzi (tools) dla agenta

Aby agent mógł wykraczać poza czyste Q&A, potrzebuje zestawu dobrze zdefiniowanych narzędzi. Typowy zestaw obejmuje:

• narzędzie do wyszukiwania w dokumentacji (wektorowe + filtrowanie metadanych),
• narzędzie do pobierania danych z CMMS (konkretne zgłoszenie, listy awarii dla maszyny),
• narzędzie do tworzenia / aktualizacji zgłoszeń,
• narzędzie do pobierania bieżących danych z systemów OT w postaci zagregowanej,
• narzędzie do odczytu listy procedur serwisowych i instrukcji krok po kroku.

Każde narzędzie musi mieć jasny kontrakt:

• jakie parametry przyjmuje (np. identyfikator maszyny, zakres czasu),
• co dokładnie zwraca (struktura odpowiedzi, jednostki),
• jakie ograniczenia obowiązują (np. maksymalny zakres danych historycznych).

Jeśli narzędzia są zbyt ogólne („daj wszystko, co masz o linii X”), model zaczyna się gubić i generować hałaśliwe odpowiedzi. Precyzyjne, wąskie narzędzia wymuszają na agencie dokładniejsze formułowanie zapytań i poprawiają przewidywalność zachowania.

Nadzór człowieka: kiedy agent może działać samodzielnie, a kiedy nie

Prywatny asystent w przemyśle niemal zawsze musi działać w trybie „człowiek w pętli”. Granice autonomii można z grubsza podzielić:

• Pełna autonomia – bezpieczna przy działaniach czysto informacyjnych: wyszukiwanie, streszczenia, porównania dokumentów, propozycje tekstów zgłoszeń czy raportów.
• Autonomia z potwierdzeniem – agent przygotowuje akcję (utworzenie zgłoszenia, zaproponowanie zmiany priorytetu, wysłanie powiadomienia), ale wykonanie następuje dopiero po jednoznacznym potwierdzeniu użytkownika.
• Brak autonomii – obszary, gdzie agent może wyłącznie sugerować, nigdy nie podejmować akcji: zmiana parametrów procesu, odblokowanie zabezpieczeń, modyfikacja krytycznych danych w systemach produkcyjnych.

Granice te powinny być zapisane nie tylko w dokumentacji technicznej, ale także w politykach bezpieczeństwa i instrukcjach dla użytkowników. Przy audycie bezpieczeństwa lub certyfikacji linii będzie to jeden z pierwszych obszarów, które trafią pod lupę.

Warianty wdrożenia: od pojedynczej linii do globalnej platformy

Sposób zbudowania architektury asystenta zależy od skali i zróżnicowania zakładów. W praktyce pojawiają się trzy główne scenariusze:

1. Pilotaż na jednej linii lub fabryce
   Asystent jest wdrożony lokalnie, często z minimalną integracją (dokumentacja + prosty dostęp do CMMS). Celem jest sprawdzenie jakości odpowiedzi, akceptacji przez użytkowników i wychwycenie braków w dokumentacji. Architekturę można uprościć, a integracje zbudować „na skróty”, byle z jasną ścieżką późniejszej refaktoryzacji.
2. Platforma fabryczna
   Jeden asystent obsługuje kilka linii w tej samej lokalizacji. Wchodzi temat segmentacji danych (linie, strefy, wydziały), integracji z istniejącą infrastrukturą sieciową i katalogiem użytkowników (AD/LDAP) oraz wyrównywania standardów dokumentacji między liniami.
3. Platforma globalna (multi-site)
   Asystent jest wspólny dla kilku lub kilkunastu zakładów. Pojawiają się kwestie:
   • różnic językowych (wielojęzyczna dokumentacja, zespoły w różnych krajach),
   • różnych wersji tej samej linii/modele maszyn w poszczególnych fabrykach,
   • separacji danych między spółkami lub krajami ze względu na regulacje.

   Architektura zwykle opiera się na centralnej platformie LLM z lokalnymi „adapterami” do systemów OT i CMMS w poszczególnych zakładach.

Wybór i rozmieszczenie komponentów LLM: chmura, on-premise, edge

Decyzja, gdzie fizycznie działa model, ma wpływ na architekturę, bezpieczeństwo i koszty. Możliwe konfiguracje:

• Chmura publiczna – najszybszy start, bogaty ekosystem narzędzi. Ograniczeniem są jednak wymagania dotyczące danych wrażliwych, lokalizacji przetwarzania oraz opóźnienia sieciowe (szczególnie przy integracji z systemami OT).
• Data center / chmura prywatna – dobry kompromis między kontrolą nad danymi a skalowalnością. Model jest uruchomiony w środowisku kontrolowanym przez organizację, zwykle blisko innych systemów biznesowych (ERP, CMMS).
• Edge / on-premise w zakładzie – przydatne, gdy polityki bezpieczeństwa zabraniają wynoszenia danych poza zakład albo gdy wymagane są bardzo niskie opóźnienia i odporność na przerwy w łączności. Zwykle wymaga to mniejszych, zoptymalizowanych modeli (fine-tuning, quantization).

Często stosuje się architekturę hybrydową: lokalny, mniejszy model obsługuje zapytania wymagające danych wrażliwych lub integracji z OT, a większy model w chmurze jest używany do bardziej ogólnych zadań (np. generowanie szablonów procedur, tłumaczenia, analizy trendów na zanonimizowanych danych).

Skalowanie i koszt: jak nie „przepalić” budżetu

Architektura powinna od początku uwzględniać sposób rozliczania kosztów:

• koszt sprzętu (GPU/CPU) lub subskrypcji modeli w chmurze,
• koszt indeksacji i przechowywania wektorów (szczególnie przy rosnącej ilości dokumentów),
• koszt utrzymania integracji (CMMS, SCADA, DMS).

Kilka praktycznych reguł:

• Dwupoziomowe modele – mniejszy, tańszy model obsługuje większość prostych pytań; większy, droższy jest używany tylko dla trudnych przypadków (np. gdy pewność odpowiedzi jest niska).
• Cache odpowiedzi – wiele pytań się powtarza („jak skasować alarm F04 na prasie X?”). Warstwa cache potrafi znacząco obniżyć koszty wywołań LLM.
• Ograniczanie kontekstu – dobre strategie chunkowania i filtrowania metadanymi redukują liczbę fragmentów przekazywanych do LLM, co zmniejsza koszt pojedynczego zapytania.

Przy skalowaniu z jednego pilotażu do wielu zakładów sensowne jest wprowadzenie mechanizmów raportowania: ile zapytań, przez kogo, do jakich obszarów dokumentacji, z jakim stopniem satysfakcji użytkowników. Taki monitoring pomaga rozsądnie planować rozbudowę infrastruktury.

Wersjonowanie wiedzy i „pamięć organizacyjna”

Asystent serwisowy zaczyna z dokumentacją i historią awarii, ale z czasem sam staje się nośnikiem wiedzy. Pojawiają się pytania:

• jak utrwalać sprawdzone „patenty” i obejścia, które do tej pory żyły w pamięci doświadczonych techników,
• jak odróżnić rozwiązania tymczasowe od docelowych (zatwierdzonych przez inżynierię procesu lub producenta maszyny),
• jak usuwać z indeksu rozwiązania, które okazały się błędne albo niezgodne z BHP.

Jednym ze sprawdzonych podejść jest oddzielenie:

• wiedzy „oficjalnej” – pochodzi z zatwierdzonej dokumentacji, jest wersjonowana i ma jasno określonych właścicieli,
• wiedzy „operacyjnej” – wpisy tworzone przez użytkowników (np. „gdy pojawia się F04 przy niskiej temperaturze otoczenia, sprawdź dodatkowo X”), oznaczone jako sugestie, do formalnej akceptacji.

Agent może proponować utrwalenie takich obserwacji w formie notatki lub poprawki do instrukcji, ale akceptacja powinna pozostawać po stronie odpowiedzialnego inżyniera. W przeciwnym razie do indeksu trafi z czasem zbiór anegdot, z których część będzie sprzeczna z obowiązującymi standardami.

Rola standaryzacji: identyfikatory, słowniki, taksonomie

Jakość odpowiedzi asystenta w dużej mierze zależy od tego, jak dobrze ujednolicone są:

• identyfikatory maszyn, linii, stref i urządzeń,
• nazwy komponentów i podzespołów (słowniki części),
• kategorie awarii i przyczyn (taksonomie w CMMS).

Jeśli w jednym zakładzie ten sam typ maszyny ma trzy różne nazwy, a kody błędów są zapisywane raz jako „F04”, raz jako „F-4”, raz jako „F4”, to nawet najlepszy system RAG będzie tracił trafność. Warto zbudować prostą warstwę normalizacji:

• mapowanie lokalnych nazw na standardowy słownik,
• reguły rozpoznawania i ujednolicania kodów błędów,
• mapę skrótów i synonimów używanych przez techników („prasa mała”, „prasa stara” → konkretny identyfikator).

Najczęściej zadawane pytania (FAQ)

Kiedy w zakładzie przemysłowym naprawdę opłaca się wdrożyć asystenta LLM do dokumentacji i serwisu?

Asystent LLM zaczyna mieć sens, gdy wąskim gardłem jest czas dotarcia do wiedzy, a nie jej brak. Typowa sytuacja: dokumentacja istnieje, ale jest rozproszona po segregatorach, dyskach sieciowych, CMMS i mailach, a technicy tracą minuty na szukanie właściwej strony w DTR-ce lub polowanie na eksperta.

Opłacalność rośnie wraz ze skalą i złożonością: przy kilku prostych maszynach zwykle wystarczy dobrze uporządkowana struktura plików i wyszukiwanie po PDF-ach. Gdy masz kilka złożonych linii, dziesiątki tysięcy stron dokumentacji i wielu dostawców, LLM realnie skraca czas diagnozy. Przy kilkunastu–kilkudziesięciu liniach w kilku lokalizacjach bez takiego asystenta utrzymanie spójnej wiedzy staje się bardzo kosztowne.

Jaka jest różnica między „zwykłym” wyszukiwaniem w dokumentacji a prywatnym asystentem LLM?

Klasyczne wyszukiwanie pełnotekstowe działa po słowach kluczowych – sprawdza się, jeśli dokumentacja jest dobrze uporządkowana, pytań jest mało, a użytkownicy znają dokładne nazwy elementów czy kody błędów. Przy prostym parku maszyn często to w zupełności wystarcza.

Asystent LLM ma przewagę, gdy pytania są złożone, informacje są porozrzucane po wielu plikach, a użytkownicy opisują problem potocznie („szarpie przy rozruchu na recepturze X, pojawia się alarm Y”). LLM potrafi wtedy:

• zebrać potrzebne fragmenty z wielu dokumentów i złożyć je w jedną odpowiedź,
• „przetłumaczyć” język potoczny na techniczny,
• uwzględnić skany, raporty serwisowe, maile, z którymi zwykła wyszukiwarka radzi sobie słabo.

Jakie konkretne zastosowania prywatnego asystenta LLM mają największy sens na hali produkcyjnej?

Najczęściej zaczyna się od szybkiego Q&A z dokumentacji technicznej: technik wpisuje kod alarmu lub opis objawu, a asystent zwraca wycinek instrukcji z możliwymi przyczynami, krokami diagnostycznymi, ostrzeżeniami BHP i listą wymaganych narzędzi. To skraca drogę od pytania do właściwej strony DTR-ki.

Kolejne typowe scenariusze to:

• wspieranie zdalnego serwisu – podczas połączenia wideo asystent działa jak „drugi mózg” i podsuwa procedury, parametry, sekwencje kalibracji,
• wspomaganie projektowania i modernizacji – szybki dostęp do wcześniejszych modyfikacji, standardów firmowych czy list części,
• tworzenie raportów serwisowych – technik dyktuje lub wpisuje krótką notatkę, a system uzupełnia ją do pełnego raportu zgodnego z szablonem CMMS.

Dzięki temu LLM wchodzi w realny obieg pracy, a nie pozostaje jedynie „pokazowym chatbotem”.

Na co zwrócić uwagę, żeby asystent LLM nie był tylko gadżetem, ale realnym narzędziem operacyjnym?

Kluczowe są cztery kryteria. Po pierwsze czas reakcji – odpowiedź musi pojawić się w kilkanaście sekund; jeśli technik w okularach ochronnych stoi przy hałaśliwej linii, nie będzie czekał minuty czy dwóch. Po drugie jakość odpowiedzi: precyzja, oparcie na dokumentach zakładowych i jasne wskazanie źródeł (linki do fragmentów DTR, schematów).

Po trzecie integracja z procesem – asystent powinien wspierać istniejące narzędzia (CMMS, system zgłoszeń, procedury BHP), a nie tworzyć osobną „wyspę”. Po czwarte stabilność: rozwiązanie, które „czasem działa, czasem nie”, bardzo szybko traci zaufanie produkcji. Jeśli te warunki nie są spełnione, system pozostanie ciekawostką na prezentacjach, a nie wsparciem utrzymania ruchu.

Czym różni się „czysty” LLM od systemu RAG podpiętego do dokumentów zakładowych?

„Czysty” LLM korzysta wyłącznie z ogólnej wiedzy, na której był uczony (internet, książki, dokumenty publiczne). Potrafi tłumaczyć, wyjaśniać pojęcia, tworzyć streszczenia, ale nie zna konkretnej fabryki: nie ma dostępu do numerów części, lokalnych oznaczeń, parametrów maszyn czy wewnętrznych procedur.

System RAG (Retrieval Augmented Generation) łączy LLM z bazą firmowych dokumentów. Najpierw wyszukuje w dokumentacji najbardziej pasujące fragmenty (przez wyszukiwanie wektorowe), a następnie przekazuje je do LLM, który tworzy odpowiedź na ich podstawie. W praktyce w zastosowaniach przemysłowych prawie zawsze chodzi właśnie o RAG, a nie trenowanie własnego modelu od zera – to znacznie tańsze i szybsze podejście.

Czy w przemysłowym zastosowaniu potrzebuję chatbota, czy od razu „agenta serwisowego” opartego na LLM?

Chatbot to interfejs do rozmowy – użytkownik zadaje pytanie i dostaje odpowiedź. W wielu zakładach to już duży krok naprzód, jeśli chatbot jest solidnie podpięty do dokumentacji (RAG) i potrafi wskazać konkretne fragmenty DTR czy schematów. Dobrze sprawdza się przy typowym Q&A i prostych scenariuszach wsparcia.

Agent serwisowy idzie dalej – oprócz rozmowy może wykonywać działania w innych systemach, np. dopytać użytkownika o brakujące parametry, zasugerować otwarcie zgłoszenia w CMMS z uzupełnionymi polami, pomóc w wygenerowaniu raportu po zakończonej interwencji. Jeśli celem jest tylko szybszy dostęp do wiedzy, wystarczy chatbot. Jeśli LLM ma wejść głębiej w proces utrzymania ruchu, wtedy warto myśleć o agencie.

Najważniejsze wnioski

• Prywatny asystent LLM ma sens tam, gdzie wąskim gardłem jest szybki dostęp do istniejącej wiedzy (rozproszone DTR-ki, maile, raporty, „wiedza w głowach”), a nie sam brak dokumentacji.
• Różnica między „gadżetem AI” a narzędziem operacyjnym to przede wszystkim krótki czas odpowiedzi, wysoka jakość oparta na dokumentach zakładowych, integracja z CMMS/BHP oraz stabilne działanie.
• Kluczowa rola LLM w serwisie to skrócenie ścieżki: od pytania technika do konkretnego fragmentu dokumentacji i jasnej instrukcji działania, zamiast „sprytnych”, ale niezweryfikowanych podpowiedzi.
• Najczęstsze zastosowania to: szybkie Q&A z dokumentacji, wsparcie zdalnego serwisu „na słuchawkach”, pomoc w projektowaniu i modernizacjach oraz automatyczne uzupełnianie raportów serwisowych zgodnie z szablonem CMMS.
• Zwykłe wyszukiwanie pełnotekstowe wystarcza przy małej liczbie prostych maszyn i dobrze uporządkowanej dokumentacji; LLM z RAG zyskuje przewagę, gdy pytania są złożone, dane rozproszone, a użytkownicy korzystają z języka potocznego.
• Inwestycja w LLM opłaca się wraz ze skalą: od wielu linii i tysięcy stron dokumentacji w górę, przy rozproszonym serwisie i wysokim koszcie przestojów utrzymanie spójnej wiedzy bez takiego asystenta staje się trudne.
• Sam LLM bez firmowej bazy dokumentów zna tylko wiedzę ogólną; dopiero połączenie go z wewnętrzną dokumentacją techniczną (RAG) daje realną wartość dla konkretnego zakładu i konkretnych maszyn.