Sztuczna inteligencja ma na celu przewidywanie i naprawianie błędów w kodowaniu programistów przed wystąpieniem katastrofy

Zdaniem CTO Dynatrace, generatywną sztuczną inteligencję można połączyć z bardziej tradycyjnymi formami sztucznej inteligencji, aby przewidzieć, w jaki sposób systemy komputerowe mogą ulec awarii, zanim aplikacje zostaną wprowadzone do środowiska produkcyjnego.

Generatywna sztuczna inteligencja jest łączona z systemami DevOps, które mogą zarówno wskazywać przyczyny awarii aplikacji, jak i przewidywać awarie.

Jest za wcześnie, aby zaufać rozwiązaniu GitHub Copilot firmy Microsoft w zakresie automatycznego naprawiania kodu programistycznego. Sam Microsoft stwierdził, że program, sprzedawany jako dodatek do GitHuba za 10 dolarów miesięcznie, „nie pisze doskonałego kodu” i „może zawierać niepewne wzorce kodowania, błędy lub odniesienia do przestarzałych interfejsów API lub idiomów”.

Marzenie o automatyzacji sugeruje jednak, że pewnego dnia sztuczna inteligencja przewidzi błąd w programie, który może zepsuć funkcjonalność lub spowodować awarię systemu, i nie tylko ostrzeże programistę przed wejściem kodu do produkcji, ale także powie mu, jak zmienić kod, aby uniknąć problemu. Sztuczna inteligencja może nawet być w stanie dotrzeć do kodu aplikacji i automatycznie naprawić go dla programisty, oszczędzając mu znacznego wysiłku.

Zasługi na taką przyszłość można dostrzec w dzisiejszych narzędziach DevOps i obserwowalności. Producent narzędzi DevOps, firma Dynatrace, od wielu lat tworzy tak zwaną „przyczynową sztuczną inteligencję” i „predykcyjną sztuczną inteligencję”, aby określić przyczyny awarii programów i przewidzieć, w jaki sposób zawiodą.

Następnym etapem jest owinięcie generatywnej sztucznej inteligencji wokół narzędzi obserwowalności, aby dać programistom sugestie dotyczące tego, w jaki sposób ich kod może napotkać problemy i jak temu zaradzić.

„Typową prośbą CIO jest naprawienie mojego systemu, zanim rzeczywiście ulegnie awarii” - mówi Bernd Greifeneder, dyrektor ds. technologii w Dynatrace.

„Typowa prośba CIO brzmi: napraw mój system, zanim faktycznie ulegnie awarii” - powiedział Bernd Greifeneder, dyrektor ds. technologii i współzałożyciel Dynatrace, w wywiadzie dla ZDNET. Dynatrace to komercyjny dostawca oprogramowania na rynku DevOps i Observability, oferujący narzędzia do zarządzania cyklem życia aplikacji.

Rozważ codzienną pułapkę systemową: brak miejsca na dysku w AWS firmy Amazon.

„To całkowicie ironiczne” - zauważył Greifeneder. „Nawet w czasach bardzo zaawansowanej technologii problemem jest to, że na dyskach w chmurze gdzieś w AWS brakuje miejsca i musimy uruchamiać wywołania API, aby zmienić ich rozmiar. Nie chcemy zmieniać ich [the dysków] z góry, ponieważ jest to kosztowne, dlatego chcemy zoptymalizować to, czego używamy, ale wzorce użycia mogą się zmieniać w zależności od liczby klientów w naszych klastrach itd.”.

Konieczne jest utworzenie kodu, który zacznie działać, gdy błąd braku dysku będzie prawdopodobny, co wynika z wcześniejszej wydajności.

Aby rozwiązać ten problem, firma najpierw identyfikuje „pierwotną przyczynę” awarii dysku, łącząc sztuczną inteligencję przyczynową i predykcyjną. Te dwa narzędzia nie są oparte na dużych modelach językowych i innej generatywnej sztucznej inteligencji. Zamiast tego polegają na starszych, bardziej ugruntowanych formach sztucznej inteligencji, na których można polegać, że dadzą rygorystyczne, spójne wyniki.

W przypadku przyczynowej sztucznej inteligencji program wykorzystuje kilka algorytmów, w tym regresję kwantylową, szacowanie gęstości i tak zwany model losowego surfowania. W przeciwieństwie do sieci neuronowych, które są szkolone na statycznym zestawie danych w celu wykrycia korelacji między punktami danych, programy przyczynowe służą do przeglądania wykresu przedstawiającego elementy systemu informatycznego firmy i ich powiązania.

„Typowe modele statystyczne lub modele uczenia się typu sieci neuronowej nie sprawdzają się w przypadku dynamicznych systemów informatycznych w większym zakresie” - stwierdził Greifeneder, ponieważ zmienne zmieniają się zbyt mocno. „Nasi klienci mogą mieć od dziesiątek do setek tysięcy podów, a wiele z nich jest ze sobą połączonych i zmienia się w miarę kierowania ruchu, skalowania, istnieją różne wersje itp.”.

Aby zbudować to, co Greifeneder nazywa „zapisanym w pamięci modelem czasu rzeczywistego” całego systemu informatycznego klienta, programy przyczynowe AI konstruują „wielowymiarowy model, który ma przyczynową, ukierunkowaną zależność, coś w rodzaju wielowymiarowego wykresu” wszystkie elementy — od tego, jaka to usługa w chmurze, przez używaną wersję Kubernetes, po uruchomioną aplikację. Model ten, zwany Smartscape, jest konsultowany za każdym razem, gdy pojawia się problem systemowy, który wywołuje alarm, „wnioskując o pierwotną przyczynę na podstawie przeglądania modelu Smartscape”.

Ten model przyczynowy nie przewiduje jednak zmian w biznesie. „Zna podstawową przyczynę” sytuacji, „ale nie wie, jaki jest schemat Twojej działalności” - powiedział Greifeneder, mając na myśli takie rzeczy, jak: „W poniedziałek rano o 8:00 masz duży skok w użyciu z jakiegokolwiek powodu.”

W przypadku takich aberracji „potrzebna jest jakaś forma uczenia się w oparciu o historię” - stwierdził Greifeneder.

Aby osiągnąć takie uczenie się historyczne, predykcyjny komponent sztucznej inteligencji wykorzystuje inny zestaw dobrze opracowanych narzędzi, takich jak zintegrowana średnia krocząca z autoregresją, która jest algorytmem szczególnie dostosowanym do łączenia wzorców występujących w danych w czasie.

Swobodna i predykcyjna sztuczna inteligencja Dynatrace wykorzystuje różnorodne, sprawdzone podejścia algorytmiczne do analizowania sygnałów tego, co dzieje się w aplikacji produkcyjnej.

Co najważniejsze, predykcyjna sztuczna inteligencja nie uwzględnia tylko systemów zaplecza, takich jak serwer. Odbiera także sygnały z punktów końcowych w sieci, na przykład informujące o opóźnieniach lub przerwach w świadczeniu usług przez użytkownika końcowego.

„Same przyglądanie się systemom po stronie serwera nie wystarczy” - powiedział Greifeneder. „Na przykład monitorowanie rzeczywistych użytkowników lub monitorowanie usług API jest ważnym aspektem zrozumienia zależności”.

Chociaż CIO najbardziej troszczy się o systemy, problemy użytkowników mogą pojawić się nawet wtedy, gdy serwery działają prawidłowo, dlatego należy zmierzyć i porównać zarówno doświadczenie użytkownika, jak i zaplecze.

„Czasami spotykamy osobę zajmującą się wyłącznie informatyką, która troszczy się tylko o swoje serwery - „Och, mój serwer nie działa” - ale tak naprawdę użytkownicy są sfrustrowani” - powiedział. „Istnieje coś przeciwnego: to, że jeden z tych procesorów przestaje działać, nie oznacza, że ma to wpływ na użytkownika końcowego”.

Wracając do przykładu miejsca na dysku, sztuczna inteligencja przyczynowa i predykcyjna może przewidzieć przyszłe problemy z dyskiem. „Możemy ekstrapolować dane z ostatnich dni i tygodni użytkowania klastra i stwierdzić: «Och, istnieje ryzyko, że za tydzień może nam zabraknąć miejsca na dysku»” - powiedział Greifeneder.

Stanowi to impuls do podjęcia proaktywnych kroków, takich jak: „Uruchommy teraz akcję przepływu pracy z silnika automatyzacji Dynatrace, aby wywołać interfejs API w AWS w celu zmiany rozmiaru dysku i w ten sposób automatycznie zapobiec awariom, które mieliśmy z tego powodu w przeszłości”.

To tutaj generatywna sztuczna inteligencja zostaje włączona w proces. Do programu parasolowego Dynatrace, Davis AI, dodano w tym roku komponent o nazwie Davis CoPilot, który opiera się na systemach przyczynowych i predykcyjnych.

Użytkownik może wpisać do CoPilota: „utwórz mi automatyzację, która faktycznie zapobiegnie temu [proaktywnie przestojowi dysku]”. CoPilot może wysłać zapytanie do sztucznej inteligencji przyczynowej i predykcyjnej, aby zapytać, o jakich dyskach mowa w tym monicie. W odpowiedzi program Davis wykorzystuje Smartscape i informacje predykcyjne do utworzenia podpowiedzi zawierającej wszystkie szczegóły kontekstowe wymagane do zrozumienia systemu informatycznego w jego bieżącym stanie.

Podpowiedź jest następnie wysyłana do CoPilota, który po podaniu szczegółów „zwróci szablon przepływu pracy w celu zautomatyzowania” zmiany rozmiaru dysku, wyjaśnił Greifeneder. „Da Ci, jako użytkownikowi, możliwość sprawdzenia i powiedzenia: OK, mniej więcej się to zgadza, dziękuję, pomogłeś mi osiągnąć 90% sukcesu”, co może zaoszczędzić czas inżyniera systemowego w porównaniu z tworzeniem przepływu pracy od zera.

Następnym krokiem jest przekazanie przez program AI Davisa wszystkich tych obserwacji programiście w momencie, gdy po raz pierwszy koduje aplikację. Świętym Graalem tworzenia aplikacji jest zapobieganie kodowaniu powodującemu błędy przed wprowadzeniem aplikacji do środowiska produkcyjnego, zamiast konieczności późniejszego naprawiania błędów.

Jednym z podejść jest to, co Dynatrace nazywa opiekunem. Osoba DevOps może poprosić CoPilota w języku naturalnym o utworzenie opiekuna, który będzie czuwał nad konkretnym celem wydajności aplikacji, zanim aplikacja zostanie wdrożona w środowisku produkcyjnym. Firma określa to mianem „definiowania celu jakościowego w kodzie”. Elementy przyczynowe i predykcyjne są następnie wykorzystywane do sprawdzenia, czy kod spełni określone cele.

Oczywiście, jeśli sztuczna inteligencja Davisa zauważy potencjalnie problematyczny kod, problem polega na tym, jak go naprawić. Możliwe jest, że Davis CoPilot doradzi programiście w sprawie możliwych poprawek kodu, chociaż jest to wciąż nowy obszar.

„Za pomocą tego rozwiązania Davis CoPilot zastanawiamy się nad przedstawieniem zaleceń dotyczących sposobu zidentyfikowania tej luki w zabezpieczeniach w środowisku produkcyjnym na podstawie stosu technologii, a Davis CoPilot zapewnia zalecenia, które należy sprawdzić i naprawić w swoim kodzie” - powiedział ZDNET Greifeneder.

Wciąż jest na wczesnym etapie stosowania generatywnej sztucznej inteligencji w przypadku tego rodzaju zaleceń dotyczących poprawek kodu, powiedział Greifeneder. Chociaż sztuczną inteligencję przyczynowo-przewidywalną zaprojektowano tak, aby była niezawodna, algorytmy generatywne nadal cierpią z powodu zjawiska „halucynacji”, co oznacza, że program z całą pewnością potwierdza niedokładne informacje.

„Niezawodne jest to, co pochodzi z przyczynowej sztucznej inteligencji, ponieważ jest to dokładny stan systemu” - powiedział. „Wiemy więc dokładnie, co tam jest; niepewne jest potencjalne zalecenie dotyczące zmiany kodu, ponieważ pochodzi ono z publicznych modeli GPT-4”.

Dlatego sugestie dotyczące kodu dotyczące naprawy mogą zaczynać się od prawidłowego założenia, ale napotykają ten sam problem, co drugi pilot GitHub: brak naprawdę rygorystycznego wyczucia, który kod jest odpowiedni. Istnieje potrzeba ściślejszej integracji dużych modeli językowych z narzędziami udostępnianymi przez Dynatrace i inne firmy, aby zapewnić pewne podstawy dla sugestii generatywnej sztucznej inteligencji.

Formalne badania GPT-4 i im podobnych wskazują na bardzo zróżnicowane wyniki w znajdowaniu i naprawianiu luk w kodzie. Dokument techniczny opublikowany przez OpenAI wraz z wprowadzeniem GPT-4 w marcu przestrzegał przed poleganiem na programie. Stwierdzono, że GPT-4 „[…] słabo radził sobie z tworzeniem exploitów dla zidentyfikowanych luk”.

Przeprowadzone w lutym badanie poprzednika GPT-4, GPT-3, przeprowadzone przez badacza z Uniwersytetu Pensylwanii, Chrisa Kocha, było zachęcające. Pokazało, że GPT-3 znalazł 213 luk w zbiorze plików repozytorium GitHub wybranych pod kątem znanych luk. Liczba ta znacznie przewyższała 99 błędów wykrytych przez popularne narzędzie do oceny kodu o nazwie Snyk, będące formą „statycznego testowania bezpieczeństwa aplikacji” (SAST), powszechnie używanego do testowania luk w oprogramowaniu.

Jednak, jak zauważył Koch, zarówno GPT-3, jak i Snyk pominęły wiele luk w zabezpieczeniach - miały wiele „fałszywie negatywnych wyników”, jak je nazywano.

Kolejne badanie przeprowadzone przez firmę PeopleTec zajmujące się bezpieczeństwem cybernetycznym, oparte na pracy Kocha, testowało zaktualizowany GPT-4 wydany w sierpniu. Okazało się, że GPT-4 odkrył cztery razy więcej luk w tych samych plikach.

Jednak w obu badaniach GPT-4 testowano na plikach zawierających łącznie nieco ponad 2000 linii kodu. To niewiele w porównaniu z pełnymi aplikacjami produkcyjnymi, które mogą zawierać od setek tysięcy do milionów wierszy kodu w wielu połączonych plikach. Nie jest jasne, czy sukcesy w rozwiązywaniu problemów z zabawkami w plikach GitHub osiągną taką złożoność.

Trwa wyścig mający na celu wzmocnienie modeli językowych do tego ważniejszego zadania. Oprócz Dynatrace prywatna firma Snyk Ltd. z Wielkiej Brytanii, która sprzedaje komercyjną wersję narzędzia typu open source, oferuje tak zwaną „DeepCode AI”. Technologia ta, twierdzi Snyk, może uniknąć potknięć związanych z generatywną sztuczną inteligencją, integrując ją z innymi narzędziami. „Hybrydowe podejście DeepCode AI wykorzystuje wiele modeli i zestawów szkoleniowych specyficznych dla bezpieczeństwa w jednym celu - aby zabezpieczyć aplikacje” - stwierdziła firma.

Oczywiste jest, że generatywna sztuczna inteligencja ma wiele możliwości, aby rozwiązać nawet proste rodzaje debugowania i naprawiania programów, pomijając złożoność działającego produkcyjnego środowiska IT. Wielka zmiana pozostawiona przez sztuczną inteligencję jeszcze nie nadeszła.

Dzięki Davis Copilot i podobnym wysiłkom na horyzoncie widać wykorzystanie generatywnej sztucznej inteligencji jako nowego interfejsu, który pomoże programistom w bardziej agresywnym badaniu własnego kodu zarówno przed wysłaniem kodu, jak i po jego wysłaniu.