Ten sam kod, różne maszyny: jak przygotować wspólny raport
Analityk zbiera komunikaty z różnych urządzeń i widzi wiele wpisów z tym samym kodem. Wspólna etykieta wygląda wygodnie, ale może łączyć zupełnie różne znaczenia. Raport powinien uwzględniać, z jakiej maszyny pochodzi komunikat. Znane kody można przypisać do kategorii przez tabelę powiązań. Model AI warto sprawdzić przy swobodnych opisach i skrótach, których tabela nie rozpoznaje.
Syntalith
Dlaczego sam kod E17 nie wystarczy
W tym fikcyjnym przykładzie porównamy rodziny urządzeń A i B. Znaczenia kodów również przyjęto na potrzeby przykładu. W dokumentacji rodziny A kod E17 oznacza komunikat dotyczący łączności. W dokumentacji rodziny B ten sam kod dotyczy czujnika temperatury.
Zestawienie wszystkich wpisów E17 w jednej grupie ukryłoby tę różnicę. Przydatny raport pokazuje osobno komunikaty dotyczące łączności z rodziny A i komunikaty dotyczące czujnika temperatury z rodziny B. Analityk może przejść do oryginalnych zapisów, zobaczyć urządzenie i sprawdzić dokumentację, według której przypisano kategorię.
Jeżeli zapis zawiera tylko E17 i nie da się ustalić rodziny urządzenia, pozostaje do wyjaśnienia. Częstsze występowanie jednego znaczenia w archiwum nie daje podstawy do przypisania go temu wpisowi. Brakujący kontekst trzeba odzyskać ze źródła lub rejestru urządzeń.
Znane znaczenie można odczytać ze słownika
Gdy rodzina urządzenia i znaczenie kodu są ustalone, zwykła tabela powiązań wystarczy do przypisania kategorii. W przykładzie połączenie rodziny A z E17 zawsze prowadzi do wskazanego w jej dokumentacji komunikatu o łączności. Uczenie modelu tego samego przypisania wprowadzałoby dodatkową pracę bez rozwiązania nowego problemu.
Przed zamówieniem modelu warto więc sprawdzić, jakie informacje docierają do raportu. Być może eksport pomija nazwę urządzenia albo systemy używają różnych oznaczeń tej samej rodziny. Uporządkowanie tych powiązań pozwala korzystać ze znanego znaczenia kodów. Jeśli dokumentacja rozróżnia wersje urządzenia, raport musi zachować również tę informację.
Osoba odpowiedzialna za dokumentację potwierdza, które znaczenia można zebrać pod wspólną nazwą. W tej pracy klasyfikujemy treść komunikatu. Sama kategoria nie ustala fizycznej przyczyny zdarzenia, jego pilności ani sposobu postępowania z urządzeniem.
Gdzie model może pomóc
Nie każdy system przekazuje czytelny kod w osobnym polu. Informacja może pojawiać się w różnie napisanych opisach, skrótach albo komunikatach z kolejnych generacji urządzeń. Przy znanym pochodzeniu wpisu model może pomóc przypisać takie sformułowania do uzgodnionych kategorii raportu.
To inna praca niż odczyt z tabeli. Model musi rozpoznać, do którego znanego znaczenia odnosi się tekst, mimo że zapis różni się od nazwy używanej w raporcie. Kontekst urządzenia nadal jest potrzebny. Dostosowanie modelu nie zastępuje brakującej informacji o rodzinie w samotnym wpisie E17.
Warto zacząć od gotowego modelu z wyjaśnionymi kategoriami i właściwym kontekstem. Google opisuje nadzorowane dostosowanie modeli do określonych zadań, w tym klasyfikacji. Wskazuje także, że model ogólny może wystarczyć, gdy instrukcje dają spójne wyniki. Dalsze uczenie zasługuje na próbę dopiero przy powtarzalnych pomyłkach, które zespół potrafi wskazać.
Fine-tuning, czyli dalsze uczenie istniejącego modelu na poprawnie ocenionych przykładach, może służyć rozpoznawaniu takich zmiennych opisów. Zespół wnosi znajomość dokumentacji i poprawki do błędnych przypisań. Nowe znaczenie kodu w kolejnej rodzinie należy najpierw ustalić w źródłach, zanim zacznie być używane w raporcie.
Czy wynik nadaje się do wspólnego przeglądu
Próbę warto przeprowadzić na wiadomościach i rodzinach urządzeń niewykorzystanych podczas adaptacji, z dostępną właściwą dokumentacją i ustalonym kontekstem. Analityk sprawdza, które przypisania wymagają poprawy i ile wpisów nadal trzeba wyjaśniać. Wynik porównuje z tabelą powiązań oraz gotowym modelem tam, gdzie każda z tych metod ma zastosowanie.
Analityk potrzebuje liczby błędnych przypisań obok liczby wpisów pozostawionych do wyjaśnienia. Obie pokazują pracę do wykonania, ale błędna kategoria wymaga również poprawienia pozornie gotowej części raportu.
Jeśli natomiast porządkujecie swobodne notatki techników o obserwacjach i wykonanych pracach, pomocny będzie artykuł o fine-tuningu do opisu zdarzeń utrzymania ruchu.
Raport dla urządzeń z różnych systemów
Syntalith proponuje aplikację do raportowania komunikatów, która łączy wpisy z informacją o urządzeniu i zachowuje oryginalne zapisy. Analityk widzi kategorię, jej podstawę i wpisy wymagające wyjaśnienia, a po korekcie może korzystać z zestawienia podczas przeglądu.
Pracę zaczynamy od powiązań między urządzeniami, dokumentacją i komunikatami. Zespół klienta potwierdza znaczenia oraz wskazuje dotychczasowe pomyłki. Ustalamy, które przypisania obsłuży słownik, a przy zmiennych opisach porównujemy gotowy model z adaptacją. Zakres obejmuje także doprowadzenie wyniku do miejsca, w którym zespół dziś przygotowuje raport.
Opisz jeden kod lub komunikat, który w obecnym zestawieniu łączy różne sprawy. Powiedz, skąd trafiają wpisy i kto potrafi sprawdzić ich znaczenie. To wystarczy do rozpoczęcia rozmowy o zakresie; informacje o współpracy są w cenniku Syntalith.
Dobierzmy model do wymagań Twojego zadania
Opisz wynik, którego obecne AI nie daje wystarczająco dobrze. Porównamy możliwości dostosowania modelu, wymagania dotyczące danych i koszty dalszego działania.
Prywatne modele LLM i fine-tuning