RAG do dokumentacji technicznej: jak AI korzysta z DTR i instrukcji maszyn

Czas czytania: ok. 7 minut

Krótka odpowiedź: RAG (retrieval-augmented generation) to sposób, w którym AI odpowiada na podstawie Waszych dokumentów, a nie z pamięci modelu. Gdy pada pytanie, system najpierw wyszukuje pasujące fragmenty w Waszej dokumentacji technicznej (DTR, instrukcje, karty serwisowe), a dopiero potem układa odpowiedź opartą na tych fragmentach, z możliwością wskazania źródła. Dzięki temu można wykorzystać wiedzę firmy bez trenowania własnego modelu i z dużo mniejszym ryzykiem zmyślania. To najkrótsza droga od „mamy tony dokumentacji, której nikt nie czyta" do „technik pyta i dostaje trafną odpowiedź z cytatem".

RAG to wyszukiwanie, nie nauczenie modelu

Najczęstsze nieporozumienie brzmi tak: „musimy nauczyć AI naszych maszyn". W praktyce sensowne wdrożenia nie trenują modelu na Waszych danych. Model zostaje jaki jest, a Wasza dokumentacja trafia do osobnej bazy, w której system szuka. Kolejność jest zawsze taka sama: pytanie, wyszukanie pasujących fragmentów, odpowiedź oparta na tych fragmentach.

Ma to dwie praktyczne konsekwencje. Po pierwsze, dodanie nowej wiedzy jest tanie: nowa instrukcja albo nowa seria zgłoszeń to po prostu dorzucenie dokumentu do bazy, a nie przetrenowanie modelu od zera. Po drugie, jakość odpowiedzi zależy nie od inteligencji modelu, tylko od tego, czy właściwy fragment da się w ogóle odnaleźć. To przesuwa środek ciężkości z technologii na jakość i przygotowanie dokumentacji.

Dlaczego RAG dobrze pasuje do produkcji

Dokumentacja techniczna ma cechę, która czyni ją idealnym materiałem dla RAG: jest obszerna, rozproszona i rzadko czytana w całości, a jednocześnie zawiera konkretne odpowiedzi na konkretne pytania. Nikt nie zna na pamięć całej DTR trzydziestu maszyn. Ale odpowiedź na pytanie „jaki moment dokręcenia dla tego węzła" albo „jak zresetować ten alarm" tam jest, tylko trzeba ją znaleźć w odpowiednim akapicie odpowiedniego dokumentu.

RAG robi dokładnie to. Zamiast kazać technikowi przekopywać się przez pięćset stron, wyławia właściwy fragment i podaje go z odniesieniem do źródła. To zamienia martwą dokumentację w coś, z czego realnie się korzysta.

Cztery warstwy dokumentacji i ich trudność

Nie każdy dokument jest równie łatwy do wykorzystania. W praktyce macie zwykle cztery warstwy:

• Dokumentacja producenta (DTR, instrukcje, schematy). Ustrukturyzowana, ale często w formie skanów PDF, z tabelami i rysunkami. Wymaga porządnego rozczytania (OCR) i podziału na sensowne fragmenty.
• Historia zgłoszeń serwisowych. Najcenniejsza warstwa, bo opisuje realne awarie i realne naprawy. Zwykle zapisana skrótowo i niespójnie, więc trudniejsza dla wyszukiwania.
• Karty i procedury wewnętrzne. Wasze własne standardy, często najbardziej aktualne, jeśli są utrzymywane.
• Wiedza rozproszona (maile, notatki, zdjęcia). Chaotyczna, ale bywa jedynym zapisem nietypowego przypadku.

Wdrożenie zaczyna się od uczciwej inwentaryzacji tych warstw. Jeśli ją pominiecie, łatwo zbudować system, który świetnie cytuje instrukcję producenta i nic nie wie o awariach z ostatnich pięciu lat.

Co realnie decyduje o jakości na dokumentach technicznych

Kilka rzeczy, które w dokumentacji technicznej sprawiają więcej trudności niż w zwykłym tekście:

• Skany i PDF. Dużo DTR to zeskanowane papiery. Bez dobrego rozczytania tekstu (OCR) system nie zobaczy zawartości. To pierwszy realny koszt przygotowania.
• Tabele i rysunki. Parametry techniczne żyją w tabelach, a te łatwo się rozsypują przy nieuważnym przetwarzaniu. Rysunki i schematy wymagają osobnego podejścia albo opisu.
• Wersje i aktualność. Ta sama maszyna po modernizacji ma inną procedurę. Bez oznaczania wersji system będzie mieszał starą prawdę z nową.
• Podział na fragmenty. Zbyt duże fragmenty rozmywają trafność, zbyt małe gubią kontekst. Ten temat rozwijam osobno w notatce o chunkingu i jakości retrievalu.

Cytowanie źródła to nie ozdoba

W dokumentacji technicznej pewna, ale błędna odpowiedź jest groźniejsza niż brak odpowiedzi, bo technik może na jej podstawie coś zrobić. Dlatego dwie zasady są tu obowiązkowe:

• Każda odpowiedź wskazuje źródło. Z którego dokumentu i której sekcji pochodzi. Technik od razu widzi, czy odpowiedź ma realne oparcie, czy tylko ładnie brzmi.
• „Nie znalazłem podstawy" to poprawna odpowiedź. System, który przyznaje brak podstawy, jest bezpieczniejszy niż taki, który zawsze coś sklei. Puste pole to sygnał, że trzeba uzupełnić dokumentację, a nie wada narzędzia.

Utrzymanie: dokumentacja żyje

RAG nie jest wdrożeniem raz na zawsze. Dokumentacja się starzeje, dochodzą nowe maszyny, zmieniają się procedury. Warto od początku ustawić trzy rzeczy: proces dodawania nowych dokumentów, oznaczanie treści nieaktualnych i przegląd pytań, na które system nie umiał odpowiedzieć. To ostatnie jest gotową mapą luk w Waszej wiedzy.

Czego ten post nie pokrywa

Nie wchodzę tu w techniczne szczegóły tego, jak dzielić dokumenty i jak mierzyć trafność wyszukiwania, bo to osobny, bardziej techniczny temat. Nie rozstrzygam też, czy model ma stać u Was, czy w chmurze. Tu chodziło o obraz całości: co to jest RAG na dokumentacji technicznej, dlaczego pasuje do produkcji i od czego zależy, czy zadziała.

Powiązane notatki

• RAG bez halucynacji: chunking, retrieval i co decyduje o jakości odpowiedzi
• AI do zarządzania wiedzą serwisową: jak zasilić system i gdzie są granice