30 lipca 2026
RAG na DTR: 7 kontroli przed AI na hali
RAG na DTR ma skrócić drogę od pytania technika do właściwego, aktualnego fragmentu dokumentacji — ze wskazaniem numeru dokumentu, wersji i rozdziału. Nie steruje maszynami, nie przewiduje awarii i nie zastępuje decyzji osoby z uprawnieniami. To system informacyjny: wyszukuje, odpowiada ze źródła, a przy braku podstawy odmawia.
Na hali problemem rzadko jest całkowity brak instrukcji. Częściej istnieją trzy wersje DTR, skan bez OCR, dodatek producenta w innym folderze i lokalna procedura, która zmieniła kolejność prac. Sam model językowy nie rozstrzygnie, który dokument obowiązuje. Dlatego wdrożenie RAG dla produkcji zaczyna się od kontroli źródeł i odpowiedzialności, a nie od wyboru największego modelu.
Spis treści
- Co RAG może zrobić z DTR
- 1. Uprawnienia per rola
- 2. Wersja DTR i źródło obowiązujące
- 3. Cytowanie dokumentu, wersji i rozdziału
- 4. Odmowa przy braku podstawy
- 5. Golden set z realnych pytań
- 6. Akceptacja człowieka
- 7. Monitoring zmian
- Macierz ryzyko–kontrola–dowód
- Granica automatyzacji
- Jak zacząć od małego zakresu
- FAQ
Co RAG może zrobić z DTR
RAG może połączyć DTR, instrukcje serwisowe, procedury utrzymania ruchu, biuletyny producenta i dokumentację jakości w jedną warstwę wyszukiwania. Technik zadaje pytanie normalnym językiem, system odnajduje właściwy fragment i przygotowuje odpowiedź z cytowaniem. Zamiast listy dziesięciu PDF-ów dostaje punkt zaczepienia: identyfikator maszyny, dokument, rewizję, rozdział i fragment tekstu.
To nie jest „ChatGPT, który przeczytał katalog”. Produkcyjny RAG na dokumentach firmy musi wiedzieć, które źródło ma pierwszeństwo, kto może je zobaczyć oraz kiedy odpowiedź jest niedopuszczalna. Jeśli dokumentacja nie ma właściciela, wersji i reguł dostępu, model tylko szybciej poda chaos. Najpierw trzeba więc przejść checklistę gotowości danych do RAG.
1. Uprawnienia per rola
Odpowiedź nie może ujawnić dokumentu, którego użytkownik nie ma prawa przeczytać. Filtr dostępu musi zadziałać przed generowaniem odpowiedzi, a nie jako dopisek w promptcie. Rola technika utrzymania ruchu, automatyka, operatora, serwisu zewnętrznego i audytora jakości zwykle prowadzi do innych źródeł.
Każdy fragment indeksu powinien dziedziczyć metadane dostępu ze źródła. System retrieval filtruje dokumenty według tożsamości i roli pytającego, a log zapisuje, które uprawnienie dopuściło cytat. Test negatywny jest równie ważny jak pozytywny: serwisant maszyny A nie powinien odzyskać instrukcji objętej ograniczeniem dla linii B. Artefaktem odbiorowym jest macierz ról i źródeł oraz wynik testów prób nieuprawnionego dostępu.
2. Wersja DTR i źródło obowiązujące
RAG powinien preferować wersję obowiązującą, ale zachować historię potrzebną do wyjaśnienia decyzji. Sam znacznik czasu pliku nie wystarczy. Potrzebne są co najmniej: numer dokumentu, rewizja, data obowiązywania, status, model lub numer seryjny maszyny, właściciel i relacja „zastępuje”.
Przy ingestowaniu system może odrzucić duplikat, oznaczyć konflikt albo skierować go do właściciela dokumentacji. Nie powinien sam rozstrzygać, że nowszy plik jest ważniejszy, jeśli lokalna procedura zatwierdzona przez zakład ma pierwszeństwo przed ogólną instrukcją producenta. Reguła priorytetu jest decyzją organizacji. RAG ma ją wykonać i pokazać w logu.
3. Cytowanie dokumentu, wersji i rozdziału
Cytowanie musi pozwolić człowiekowi szybko sprawdzić odpowiedź w oryginale. Samo „źródło: manual.pdf” jest za słabe. Minimalny cytat dla DTR zawiera nazwę i identyfikator dokumentu, rewizję, rozdział lub stronę oraz link do fragmentu, jeśli system dokumentowy go obsługuje.
W odpowiedzi warto oddzielić treść znalezioną w źródle od krótkiego podsumowania modelu. Użytkownik powinien widzieć, czy dwa fragmenty są zgodne, czy istnieje konflikt między procedurą lokalną a instrukcją producenta. Przy konflikcie system nie wybiera wygodniejszej wersji — sygnalizuje rozjazd i kieruje sprawę do właściciela procesu.
4. Odmowa przy braku podstawy
„Nie znalazłem podstawy w zatwierdzonej dokumentacji” jest poprawnym wynikiem. RAG nie ma uzupełniać luk wiedzą ogólną modelu, doświadczeniem z innej maszyny ani prawdopodobną procedurą. Reguła odmowy powinna działać przy braku trafnego źródła, zbyt niskim wyniku retrieval, konflikcie wersji i pytaniu poza zakresem.
Dobra odmowa nie kończy pracy ślepą uliczką. Wskazuje, czego brakuje, podaje przeszukany zakres i proponuje eskalację: do lidera zmiany, inżyniera procesu lub właściciela dokumentacji. To zachowanie trzeba mierzyć osobno, bo system, który odpowiada na wszystko, może wyglądać pomocnie i jednocześnie zwiększać ryzyko.
5. Golden set z realnych pytań
Golden set ma odwzorować pytania i błędy, które rzeczywiście występują na hali. Zespół zbiera pytania od operatorów, techników i jakości, przypisuje oczekiwany fragment źródła oraz określa, kiedy poprawnym wynikiem jest odmowa. W próbie muszą znaleźć się stare oznaczenia maszyn, skróty zakładowe, literówki, konflikty wersji i pytania bez odpowiedzi.
Retrieval i generowanie mierzy się oddzielnie. Najpierw sprawdzamy, czy właściwy fragment znalazł się w top-k. Potem, czy odpowiedź wynika z tego fragmentu, czy cytowanie go potwierdza i czy system poprawnie odmówił. Szczegółowy scorecard i przykład decyzji opisujemy w artykule o ewaluacji RAG. Progi ustala się przed testem i zależnie od skutku błędu; nie są uniwersalnym benchmarkiem.
6. Akceptacja człowieka
RAG wspiera decyzję techniczną, ale jej nie przejmuje. Odpowiedź dotycząca czynności serwisowej, zabezpieczenia energii, dopuszczenia maszyny lub odstępstwa od procedury wymaga weryfikacji osoby z odpowiednimi uprawnieniami. Interfejs musi pokazać źródło i umożliwić odrzucenie odpowiedzi, a nie tylko przycisk „wykonaj”.
Human approval nie oznacza klikania wszystkiego bez namysłu. Organizacja ustala, które kategorie pytań są wyłącznie informacyjne, które wymagają potwierdzenia, a które mają zawsze kończyć się eskalacją. W logu zostaje osoba zatwierdzająca, wersja źródła i moment decyzji. To tworzy dowód operacyjny, a nie iluzję nadzoru.
7. Monitoring zmian
Jakość RAG starzeje się razem z dokumentacją. Nowa rewizja DTR, biuletyn bezpieczeństwa, aktualizacja procedury lub zmiana uprawnień powinny uruchomić kontrolowany ingest, test regresji i zapis wersji indeksu. Ciche podmienianie plików bez ponownej ewaluacji niszczy możliwość odtworzenia odpowiedzi.
Monitoring obejmuje nie tylko dostępność usługi. Trzeba obserwować odsetek odmów, źródła najczęściej cytowane, zapytania bez pokrycia, konflikty wersji, naruszenia filtrów dostępu i wyniki golden setu. Owner dokumentacji odpowiada za źródła, owner systemu za pipeline i ewaluacje, a owner procesu za decyzję, czy wynik jest wystarczający do użycia.
Macierz ryzyko–kontrola–dowód
Poniższa tabela jest samodzielnym minimum odbiorowym. Każda kontrola ma zostawić artefakt, który da się sprawdzić po incydencie lub zmianie.
| Ryzyko | Kontrola | Artefakt audytowy |
|---|---|---|
| Ujawnienie poufnej instrukcji | uprawnienia per rola przed retrieval | macierz ról, polityka filtra, testy negatywne i log dostępu |
| Odpowiedź ze starej DTR | wersja, status, data obowiązywania i relacja „zastępuje” | rejestr dokumentów, wynik detekcji konfliktu, wersja indeksu |
| Cytat nie potwierdza odpowiedzi | cytowanie dokumentu, rewizji i rozdziału | wynik testu poprawności cytowań per pytanie |
| Model zgaduje bez źródła | odmowa i eskalacja przy braku podstawy | przypadki out-of-scope, refusal rate, próbki błędów |
| Demo działa tylko na łatwych pytaniach | golden set z realnych pytań i wersji | wersjonowany zestaw, oczekiwane źródła, progi i wyniki |
| Odpowiedź użyta jako polecenie | human approval dla kategorii wysokiej stawki | reguły decyzji, osoba zatwierdzająca, log akceptacji |
| Zmiana dokumentu psuje odpowiedzi | monitoring zmian i test regresji | zdarzenie ingestu, raport różnic, decyzja go/no-go |
Granica automatyzacji
Ten zakres nie steruje maszynami i nie jest predictive maintenance. Nie wysyła komend do PLC, nie zmienia parametrów procesu, nie dopuszcza urządzenia do ruchu i nie przewiduje awarii z danych sensorycznych. Takie zastosowania wymagają odrębnej architektury, danych, walidacji, analizy bezpieczeństwa i odpowiedzialności. Dobre wyszukiwanie w DTR nie jest dowodem, że model może kontrolować proces.
mojApteczka jest tu wyłącznie analogią architektoniczną: pokazuje, dlaczego RAG, cytowania, ewaluacje i odmowa muszą działać razem w systemie wiedzy. Nie jest case’em z produkcji przemysłowej, a jej wyniki nie mówią nic o skuteczności RAG na DTR konkretnego zakładu. Ten brak first-party case’u produkcyjnego komunikujemy wprost.
Jak zacząć od małego zakresu
Najbezpieczniejszy PoC obejmuje jedną rodzinę maszyn, zatwierdzony zestaw DTR i procedur, kilka jasno opisanych ról oraz realny golden set. Przed ingestem należy usunąć dokumenty bez właściciela, oznaczyć obowiązujące wersje i ustalić zasady pierwszeństwa źródeł. Dopiero potem dobiera się chunking, model i interfejs.
Odbiór kończy się decyzją, nie demonstracją. Jeśli retrieval nie znajduje właściwych fragmentów, odmowa nie działa albo uprawnienia przeciekają, wynik to no-go lub dalszy tryb testowy. Jeśli bramki przechodzą, zakres można rozszerzać partiami. Taki proces ustalamy w audycie i wdrożeniu, z właścicielami, artefaktami i kosztami utrzymania od początku.
FAQ
Czy RAG zastąpi doświadczonego technika?
Nie. RAG skraca czas szukania i pokazuje źródło, ale interpretacja w kontekście maszyny, ocena ryzyka i decyzja należą do osoby z odpowiednimi kompetencjami.
Czy wystarczy wrzucić wszystkie PDF-y do jednego indeksu?
Nie. Bez wersji, statusu, właściciela, uprawnień i reguł pierwszeństwa indeks utrwali bałagan. Porządek w dokumentach jest warunkiem jakości odpowiedzi.
Co system powinien zrobić, gdy dwie instrukcje są sprzeczne?
Pokazać konflikt, zacytować oba źródła i skierować sprawę do właściciela procedury. Nie powinien sam wybierać wersji na podstawie prawdopodobieństwa.
Jak sprawdzić RAG przed wejściem na halę?
Na wersjonowanym golden secie z pytaniami odpowiedzialnymi i bez odpowiedzi, testami dostępu, cytowań, odmowy oraz scenariuszami konfliktu wersji. Progi i reguła błędu krytycznego muszą być zapisane przed testem.
Czy taki RAG podlega AI Act?
Klasyfikacja zależy od konkretnego zastosowania, roli systemu i skutku jego wyniku. Informacyjna baza wiedzy nie staje się automatycznie systemem wysokiego ryzyka, ale wymaga przejrzystości, właściwego nadzoru i analizy zakresu. Weryfikujemy to podczas audytu, a nie na podstawie samej etykiety „RAG”.