RAG na dokumentacji serwisowej: szybsza diagnoza w serwisie maszyn
RAG na dokumentacji serwisowej nie diagnozuje maszyny za serwisanta i nie zamyka zgłoszenia „sam". Robi jedną rzecz, która realnie skraca proces: dla nowego zgłoszenia zawęża kontekst do właściwej maszyny, przeszukuje historię waszych napraw i instrukcje serwisowe, i podaje serwisantowi listę prawdopodobnych przyczyn z odnośnikami do konkretnych protokołów. Najwięcej czasu odzyskujecie nie na samej naprawie, tylko na ustaleniu, co jest zepsute, i na tym, że powtarzalna usterka przestaje być diagnozowana od zera na każdej maszynie osobno. Warunek: macie uporządkowaną dokumentację serwisową i historię zgłoszeń, a wynik modelu zawsze weryfikuje serwisant przy maszynie.
Dla kogo: kierownicy i dyspozytorzy serwisu, serwisanci maszyn, szefowie działów posprzedażowych u producentów maszyn i linii, właściciele firm rozważający AI w serwisie.
Kontekst
Producenci maszyn i linii produkcyjnych coraz częściej zarabiają nie na samej sprzedaży urządzenia, ale na serwisie posprzedażowym: umowach utrzymaniowych, częściach, czasie reakcji. To znaczy, że dział serwisu obsługuje park maszyn w wielu wersjach, u wielu klientów, z których każda ma własną konfigurację i własną historię. Wiedza potrzebna do szybkiej naprawy jest w firmie, ale rozsypana: w instrukcjach serwisowych, w protokołach z poprzednich wyjazdów, w biuletynach technicznych i w głowach kilku najstarszych serwisantów. Ta strona opisuje jeden konkretny workflow w tej rzeczywistości: jak RAG oparty na własnej dokumentacji serwisowej skraca drogę od zgłoszenia usterki do trafnej hipotezy diagnostycznej, bez odbierania decyzji serwisantowi.
Problem
Dokumentacja serwisowa istnieje, ale w praktyce nie pracuje. Instrukcja serwisowa opisuje, jak maszyna ma działać i jak ją rozłożyć, a nie jak realnie psuje się egzemplarz z 2019 roku po modernizacji sterowania. Ta druga wiedza siedzi w protokołach z poprzednich napraw, których przy zgłoszeniu i tak nikt nie otwiera, bo szybciej zadzwonić do kolegi. Trzy rzeczy bolą najbardziej. Po pierwsze, ten sam objaw wraca na różnych maszynach, a serwisant za każdym razem diagnozuje go od nowa, bo nie wie, że rok temu ktoś już to rozgryzł. Po drugie, czas reakcji jest zapisany w umowie serwisowej, a najwięcej czasu zjada nie sama naprawa, tylko ustalenie, co właściwie jest zepsute. Po trzecie, gdy odchodzi doświadczony serwisant, wychodzą razem z nim rozwiązania, których nigdzie porządnie nie opisano, a park maszyn u klientów zostaje.
Rozwiązanie
Zamiast kolejnego portalu z instrukcjami do przeklikania, AI dostaje jedno zadanie: zamienić dokumentację serwisową i historię zamkniętych zgłoszeń w źródło podpowiedzi dla zgłoszenia bieżącego. Model korzysta z retrieval-augmented generation (RAG) nad własnym korpusem: instrukcjami serwisowymi, protokołami z napraw, biuletynami technicznymi i kartami konfiguracji maszyn. Dla nowego zgłoszenia robi trzy rzeczy: zawęża kontekst do właściwej maszyny i jej wersji, wyławia podobne, zamknięte przypadki wraz z tym, co wtedy zadziałało, i podaje serwisantowi listę prawdopodobnych przyczyn z odnośnikami do konkretnych protokołów i sekcji instrukcji. Zasada jest ta sama, którą powtarzamy w każdym sensownym wdrożeniu: AI zawęża, człowiek rozstrzyga. Model nie zamyka zgłoszenia, nie wystawia protokołu i nie decyduje, którą część wymienić. Skraca tylko drogę do pierwszej dobrej hipotezy i pilnuje, żeby wiedza z poprzednich napraw nie została zapomniana. O jakości odpowiedzi decyduje tu retrieval, a nie sam model: jeśli właściwy fragment jest opisany trzema słowami bez kontekstu, żaden model go nie wyłowi. Jak dobrać granulację i uniknąć zmyśleń, rozłożyliśmy w nocie [RAG bez halucynacji](/k/rag/rag-bez-halucynacji-chunking-retrieval-jakosc).
Jak to działa (workflow)
1. **Wpływa zgłoszenie serwisowe.** Z hotline, portalu klienta albo od serwisanta w terenie: opis objawu, maszyna, ewentualne kody błędów. AI czyta zgłoszenie i identyfikuje, o którą maszynę i którą wersję chodzi. 2. **Zawężenie kontekstu do maszyny.** Model ogranicza przeszukiwanie do dokumentacji i historii tej konkretnej konfiguracji, a nie całego katalogu. To pierwszy krok, który odcina odpowiedzi „z innej maszyny". 3. **Retrieval podobnych napraw i procedur.** System wyciąga z archiwum najbardziej pokrewne zamknięte zgłoszenia (co było objawem, co okazało się przyczyną, co wymieniono) oraz właściwe sekcje instrukcji serwisowej i biuletynów. 4. **Propozycja dla serwisanta.** Model podaje listę prawdopodobnych przyczyn z odnośnikami do konkretnych protokołów i stron instrukcji oraz szkic kroków diagnostycznych. To wejście do diagnozy, nie jej zamknięcie. 5. **Człowiek rozstrzyga.** Serwisant weryfikuje hipotezy na maszynie, odrzuca fałszywe tropy i decyduje o naprawie. Decyzja i odpowiedzialność zostają po stronie człowieka. 6. **Zamknięcie zasila bazę.** Protokół z naprawy wraca do korpusu, z którego korzysta model, więc następne podobne zgłoszenie startuje z lepszą podpowiedzią. Pętla się domyka.
Dlaczego akurat serwis posprzedażowy maszyn
Bo tu jest i presja czasu, i dane. Umowa serwisowa narzuca czas reakcji, a każda zamknięta naprawa zostawia ślad: objaw, maszyna, wersja, przyczyna, wymieniona część. Po latach powstaje archiwum opisanych w powtarzalnym schemacie przypadków, a to jest dokładnie materiał, na którym retrieval działa dobrze. Paradoks polega na tym, że im dłużej firma serwisuje, tym cenniejsze archiwum buduje i tym rzadziej do niego zagląda, bo przy zgłoszeniu szybciej zapytać kolegę niż przekopać protokoły.
To odróżnia dokumentację serwisową od dokumentacji technicznej maszyny. Instrukcja producenta mówi, jak urządzenie ma działać. Dokumentacja serwisowa, czyli protokoły napraw i biuletyny, mówi, jak ono realnie się psuje w polu. Jak AI korzysta z tej pierwszej warstwy, rozłożyliśmy osobno w RAG do dokumentacji technicznej. Ta strona jest o warstwie drugiej.
Co RAG tu realnie robi
Zawęża. Zanim cokolwiek podpowie, ogranicza przeszukiwanie do właściwej maszyny i jej wersji. Bez tego kroku podpowiedź „z innej konfiguracji" brzmi wiarygodnie i prowadzi na manowce.
Przypomina. Do nowego zgłoszenia dokłada konkretne, historyczne naprawy z ustaloną wtedy przyczyną i wymienioną częścią. Serwisant nie zaczyna od pustej kartki, tylko od „w trzech podobnych przypadkach było to i to, sprawdź najpierw tam".
Cytuje. Każda podpowiedź wskazuje, z którego protokołu albo której strony instrukcji pochodzi. Dzięki temu serwisant od razu widzi, czy odpowiedź ma realne oparcie, czy tylko dobrze brzmi. Cytowanie źródła to nie ozdoba, to warunek zaufania do narzędzia.
Czego RAG tu nie robi (i nie powinien)
Nie stawia diagnozy. Podaje kandydatów, werdykt należy do serwisanta. Model potrafi zaproponować przyczynę, która pasuje do słów w zgłoszeniu, a nie do fizyki maszyny, i zrobi to tym samym pewnym tonem co trafną hipotezę. Dlatego jego wynik to lista do sprawdzenia, nie decyzja o wymianie części.
Nie zna tego, czego nie ma w danych. Jeśli prawdziwą przyczyną jest przeróbka wykonana u klienta poza wiedzą serwisu i nieopisana w żadnym protokole, model jej nie wskaże. Uczy się tylko z tego, co zapisano.
Nie zastępuje wyjścia do maszyny i pomiaru. Diagnoza z samego archiwum, bez oględzin i danych z urządzenia, to zgadywanie w lepszej oprawie. RAG skraca analizę historii, nie zdejmuje obowiązku weryfikacji na miejscu.
Warunki wstępne
Dwa, bez których nie ma o czym rozmawiać. Pierwszy to dostęp do dokumentacji serwisowej i historii zgłoszeń w formie, którą model odczyta, i w miarę spójnej: protokoły zamykane realnym opisem naprawy, a nie „naprawiono, ok". Drugi to proces, w którym każda podpowiedź modelu przechodzi przez serwisanta przed decyzją o naprawie. To ten sam fundament, który opisaliśmy przy zarządzaniu wiedzą serwisową: bez uporządkowanego źródła żadne narzędzie nie zadziała sensownie. Ta strona pokazuje, jak wygląda sama ścieżka od zgłoszenia do diagnozy; tamta nota mówi, jak zadbać o jakość i właściciela bazy, żeby ta ścieżka miała z czego korzystać.
Jak zacząć wąsko
Nie od „AI do całego serwisu", tylko od jednej rodziny maszyn albo jednej grupy powtarzalnych usterek, która wraca najczęściej i najbardziej boli. Wtedy korpus do przeszukania jest mniejszy i bardziej spójny, a efekt widać na najbliższych kilku zgłoszeniach. W praktyce z RAG na dokumentacji produkcyjnej wąski, dobrze opisany zakres zawsze wypada lepiej niż szeroki i rozmyty. Dopiero gdy jedna rodzina działa, warto dokładać kolejne.
Czego ta strona nie pokrywa
To jest opis jednego workflow i jego granic, nie instrukcja wdrożenia ani porównanie narzędzi. Nie wchodzimy w konkretne produkty, formaty plików ani wymagania sprzętowe. Nie rozstrzygamy tu on-prem kontra chmura, choć w serwisie dane bywają wrażliwe, a wybór architektury ma znaczenie kosztowe; rozłożyliśmy go osobno w porównaniu AI on-prem czy chmura dla fabryki. Nie podajemy liczb typu „o ile krócej" ani kwot oszczędności, bo zależą od waszego punktu wyjścia. Nie jest to też poradnik zarządzania wiedzą jako procesem; od strony higieny i własności bazy temat prowadzi osobna nota.
Powiązane
- RAG bez halucynacji: chunking, retrieval i co decyduje o jakości odpowiedzi
- RAG do dokumentacji technicznej: jak AI korzysta z DTR i instrukcji maszyn
- AI do zarządzania wiedzą serwisową: jak zasilić system i gdzie są granice
- Asystent serwisowy AI: dlaczego średnia firma produkcyjna to dobry kandydat
- AI on-prem czy chmura dla fabryki: co wybrać i kiedy