Integracja narzędzi opartych na sztucznej inteligencji z systemami, których firma już używa, jest trudniejsza niż samo uruchomienie takiego narzędzia. Model językowy uruchomiony osobno, w przeglądarce, jest ciekawostką: pomaga napisać tekst, ale nie zna danych firmy i niczego nie zmienia w jej systemach. Wartość pojawia się dopiero wtedy, gdy narzędzie sięga po dane z programu księgowego, systemu magazynowego czy bazy zgłoszeń, a wynik wraca tam, gdzie pracownicy naprawdę pracują. Ten tekst opisuje, jak podchodzimy do takich integracji, co sprawdzamy zanim cokolwiek podłączymy i w jakich sytuacjach odradzamy ten kierunek.
Zanim wybierzemy rozwiązanie techniczne, ustalamy, w którą stronę mają płynąć dane i czy potrzebna jest natychmiastowość. Od tego zależy cała reszta.
Najprostszy i najbezpieczniejszy wariant. Narzędzie pobiera dane z systemu, przetwarza je i przedstawia wynik człowiekowi: podsumowanie, zestawienie, wskazanie nietypowych pozycji. System źródłowy nie jest w żaden sposób modyfikowany, więc ryzyko ograniczone jest do błędnej interpretacji. Od tego wariantu zwykle zaczynamy, bo pozwala sprawdzić jakość danych bez konsekwencji.
Narzędzie przygotowuje propozycję: uzupełnia opis pozycji, przypisuje kategorię, tworzy szkic odpowiedzi, sugeruje dekretację dokumentu. Człowiek zatwierdza lub poprawia, dopiero potem dane trafiają do systemu. Ten model sprawdza się w większości zastosowań biurowych i to on najczęściej jest właściwym punktem docelowym, a nie etapem przejściowym.
Narzędzie samo zapisuje dane albo uruchamia akcje w systemie. Dopuszczamy to tylko tam, gdzie decyzja jest jednoznaczna, skutek odwracalny i istnieje kontrola po fakcie. Przy operacjach dotyczących rozliczeń, wysyłki czy zobowiązań wobec klientów odradzamy pełną automatyzację, dopóki rozwiązanie nie przepracowało długiego okresu w trybie z zatwierdzaniem.
Przegląd techniczny zaczynamy od tego, w jaki sposób dane w ogóle dają się wydostać z istniejących systemów. Kolejność jest zwykle następująca.
Jeżeli jedyną drogą jest ręczne wyklikanie eksportu przez pracownika, integracja pozostanie krucha i trzeba to powiedzieć na wstępie. Czasem sensowniejszym rozwiązaniem jest rozmowa z dostawcą systemu o udostępnieniu interfejsu niż budowanie obejścia, które przestanie działać po najbliższej aktualizacji.
Częstym błędem jest łączenie każdego narzędzia bezpośrednio z każdym systemem. Przy trzech elementach wygląda to niewinnie, przy sześciu powstaje plątanina, w której nikt nie potrafi wskazać, skąd pochodzi dana liczba. Dlatego projektujemy warstwę pośrednią: jedno miejsce, przez które przechodzą dane, z jednoznacznie zdefiniowanym formatem.
Taka warstwa daje kilka praktycznych korzyści. Zmiana w systemie źródłowym wymaga poprawki w jednym miejscu, a nie w pięciu. Da się zapisać historię przepływu danych. Da się dodać kontrole jakości i odrzucać rekordy niepoprawne, zanim trafią dalej. Wreszcie, jeśli firma zdecyduje się wymienić jedno z narzędzi, reszta układanki zostaje nienaruszona.
Osobnym zadaniem jest dostarczenie modelowi informacji o firmie. Model nie zna oferty, cennika ani wewnętrznych zasad, dopóki mu ich nie przekażemy. W praktyce budujemy zbiór dokumentów i danych, z którego wybierane są fragmenty potrzebne do konkretnego zapytania. Kluczowe jest ograniczenie zakresu: im węższy i lepiej dobrany materiał, tym trafniejsza odpowiedź. Podawanie modelowi całej dokumentacji firmy przy każdym pytaniu pogarsza wynik i podnosi koszt.
Integracja obnaża wszystkie niespójności, które w codziennej pracy są maskowane przez ludzi. Pracownik wie, że dwa podobne wpisy dotyczą tego samego kontrahenta. Automat tego nie wie. Dlatego zanim połączymy systemy, ustalamy, czym jest identyfikator, który łączy dane po obu stronach.
Typowe problemy, na które trafiamy: brak wspólnego klucza między systemami, różne definicje tego samego pojęcia w dwóch działach, dane historyczne zapisane według dawnych zasad, pola opisowe używane niezgodnie z przeznaczeniem, wartości puste traktowane raz jako zero, raz jako brak informacji. Każdy z tych przypadków wymaga decyzji biznesowej, a nie technicznej. Nasza rola polega na wskazaniu problemu i przygotowaniu wariantów, decyzja należy do firmy.
Nie wszystkie. Odradzamy podłączanie danych, których nikt nie używa do podejmowania decyzji, oraz danych, o których wiadomo, że są nieaktualne. Integracja nie poprawia jakości danych, tylko rozprowadza ją szerzej. Jeśli zestawienie w systemie jest błędne, po integracji błąd pojawi się w kilku miejscach naraz i trudniej będzie go wychwycić.
Integracja oznacza, że powstają nowe drogi dostępu do danych firmowych, często omijające dotychczasowe kontrole. Traktujemy to poważnie i ustalamy zasady przed uruchomieniem.
Osobno rozważamy ryzyko charakterystyczne dla modeli językowych: treść pochodząca z zewnątrz, na przykład wiadomość od klienta czy zawartość dokumentu, może zawierać polecenia próbujące skłonić model do niepożądanego działania. Dlatego nie pozwalamy, by model samodzielnie wykonywał operacje zapisu na podstawie treści, nad którą firma nie ma kontroli. Między modelem a systemem zawsze stoi warstwa reguł, która sprawdza, czy żądana operacja mieści się w dozwolonym zakresie.
Integracja ma inny profil kosztowy niż pojedyncze narzędzie. Praca wstępna jest większa, bo wymaga analizy systemów i uzgodnień, ale efekt jest trwalszy i obejmuje wiele procesów naraz. Na koszt składają się: analiza i projekt, budowa połączeń, opłaty za korzystanie z modeli zależne od liczby przetwarzanych danych, infrastruktura oraz utrzymanie.
Opłacalność oceniamy najpierw dla jednego, dobrze wybranego zastosowania. Jeśli pierwsze połączenie nie daje wyraźnej korzyści, rozbudowa go nie uratuje. Odradzamy projekty integracyjne prowadzone „na zapas", bez konkretnego zastosowania na starcie. Firma płaci wtedy za możliwości, z których nikt nie korzysta, a utrzymanie trwa tak samo długo jak przy rozwiązaniu używanym codziennie.
Warto pamiętać, że przy rozwiązaniach opartych na modelach część kosztów rośnie wraz z użyciem. Przy dużej liczbie dokumentów albo częstym odpytywaniu rachunek potrafi rosnąć szybciej, niż zakładano. Ograniczamy to przez rozsądny dobór wielkości przekazywanego kontekstu, buforowanie powtarzalnych wyników i kierowanie prostych zadań do prostszych mechanizmów. Nie każde zadanie wymaga modelu językowego, a zwykła reguła działa szybciej, taniej i przewidywalnie.
Integracja jest elementem żywym. Systemy po obu stronach zmieniają się niezależnie od siebie, a modele udostępniane przez dostawców są wycofywane i zastępowane nowszymi wersjami, które zachowują się nieco inaczej. Dlatego planujemy utrzymanie od początku.
W praktyce prowadzimy monitoring poprawności, a nie tylko dostępności. Sprawdzanie, czy połączenie odpowiada, nie wystarczy. Potrzebne są kontrole treści: czy liczba przetworzonych rekordów mieści się w oczekiwanym zakresie, czy nie pojawiła się nagle duża liczba pustych wyników, czy sumy zgadzają się z systemem źródłowym. Takie kontrole wychwytują ciche awarie, które są w tego typu rozwiązaniach najgroźniejsze, bo przez tygodnie nikt ich nie zauważa.
Utrzymujemy też zestaw przykładów testowych z oczekiwanymi wynikami. Po każdej zmianie wersji modelu albo konfiguracji uruchamiamy je i porównujemy. To jedyny praktyczny sposób, żeby stwierdzić, czy aktualizacja czegoś nie zepsuła.
Zazwyczaj nie. Punktem wyjścia jest to, co firma ma, a wymianę rozważamy tylko wtedy, gdy dany system nie pozwala w żaden sposób wydostać danych. Nawet wtedy zaczynamy od rozmowy z jego dostawcą, bo część ograniczeń jest kwestią licencji, a nie techniki.
Nie zawsze. Część zadań da się wykonać lokalnie, na sprzęcie firmy, kosztem wydajności i jakości wyników. W wielu wdrożeniach stosujemy podejście mieszane: dane wrażliwe przetwarzamy na miejscu, a na zewnątrz wysyłamy wyłącznie treści pozbawione danych identyfikujących. Decyzja powinna zapaść na etapie projektu, bo później zmiana jest kosztowna.
Odpowiedzialność zostaje po stronie firmy, dlatego projektujemy rozwiązania tak, by przy decyzjach istotnych ostatnie słowo miał człowiek. Zapisujemy również, na podstawie jakich danych powstał wynik, żeby dało się prześledzić, skąd wzięła się konkretna rekomendacja.
Pierwsze połączenie obejmujące jeden system i jedno zastosowanie to zwykle kilka tygodni, z czego znaczna część przypada na analizę i uzgodnienia. Projekty obejmujące wiele systemów rozkładamy na etapy, uruchamiając kolejne dopiero po ustabilizowaniu poprzednich.
Trzeba przejść na nowszą wersję i sprawdzić, czy wyniki się nie zmieniły. Dlatego budujemy rozwiązania tak, by wymiana modelu nie wymagała przebudowy całości, i utrzymujemy zestaw testów porównawczych. To normalny element utrzymania, który warto uwzględnić w budżecie na starcie.
Tak i zwykle to zalecamy. Jedno zastosowanie, jeden system, tryb z zatwierdzaniem przez człowieka. Po kilku tygodniach widać, czy dane są wystarczająco dobre i czy pracownicy faktycznie korzystają z rozwiązania. Dopiero na tej podstawie warto decydować o rozbudowie.
Kontakt: 22 390 56 49 — telefon czynny całą dobę, siedem dni w tygodniu. Obsługujemy Grodzisk Mazowiecki i okolice.
Arrived compass prepare an on as. Reasonable particular on my it in sympathize. Size now easy eat hand how. Unwilling he departure elsewhere dejection at. Heart large seems may purse means few blind.
Address