Ostatnimi czasy w kontekście AI w obszarze tworzenia oprogramowania mówi się najwięcej o narzędziach typu ChatGPT, które generują linijki kodu, ułatwiając prace milionom developerów na całym świecie. Innym dosyć popularnym podejściem jest integrowanie komponentów sztucznej inteligencji z już istniejącymi modelami software’owymi. Polega to na tym, że np. do smartfona dodajemy model AI, odpowiedzialny za rozpoznawanie twarzy, lub inne funkcje. Dziś podejdę do tego zagadnienia z trochę innego poziomu i przybliżę dwie metodologie wytwarzania oprogramowania – Software 1.0 i Software 2.0.
Software 1.0 is eating the world
Software 1.0 to najpopularniejszy paradygmat tworzenia oprogramowania. W jego ramach developerzy mają dostęp do pewnych narzędzi, takich jak język programowania, kompilator, linker, biblioteki i inne tego rodzaju narzędzia. Znając zasady ich używania, jesteśmy w stanie złożyć zbiór operacji dla procesora naszego hardware’u, co spowoduje, że zakodujemy ściśle określone instrukcje, przekładające się na konkretne działania. Większość oprogramowania działa w ten sposób, że budując jakiś konkretny symulator, np. dla autonomicznych pojazdów, sami tworzymy bardzo ścisłe reguły do zarządzania tym symulatorem. Idąc dalej przykładem pojazdów autonomicznych – jeśli wciśniemy pedał gazu, czyli wykonamy jakieś działanie, system wykona wcześniej zdefiniowane linijkami kodu instrukcje, związane z zasadami dynamiki czy fizyki. Istnieje określenie opisujące to podejście – Software 1.0 is eating the world. Oznacza to, że oprogramowanie zbiera informacje, które człowiek już wie na temat świata, konsumuje je i zamienia na instrukcje opisujące ten świat. Można to przełożyć na działanie każdego narzędzia wyposażonego w układ scalony, jakie znamy, np. samochodu, windy czy mikrofalówki.
Tutaj pojawia się jednak pewien problem. W większości przypadków, mimo że potrafimy opisać sterowanie samochodem w sposób w miarę autonomiczny, to nasz model, który buduje rzeczywistość, jest niezwykle złożony. Składa się z tysięcy równań matematycznych oraz wielu czynników i niepewności związanych z otoczeniem. Bardzo niewielka zmiana, np. w trakcji koła, powoduje zmianę założeń, bo zaczynają działać inne siły fizyczne czy też inna jest dynamika. Oczywiście, my jako programiści, jesteśmy w stanie wszystko to opisać kolejnymi działaniami matematycznymi, ale to zajęłoby ogromną ilość czasu. Dodatkowo, utrzymanie takiego kodu byłoby absurdalne. Chodzi tutaj przede wszystkim o błędy i ich naprawianie, które są wręcz nieuniknione przy tak złożonych projektach.
Software 2.0 is eating software
Za sprawą AI jesteśmy świadkami dużego skoku technologicznego. W dziedzinie tworzenia oprogramowania – być może wręcz ogromnego. Dzieje się tak za sprawą nowego podejścia Software 2.0, stworzonego przez Andreja Karpathy’ego, czyli jednego z założycieli OpenAI, gdzie obecnie ponownie jest dyrektorem AI, a wcześniej pełnił podobną funkcję w Tesli. Ideologia Software 2.0 polega na tym, że w opisywanym we wcześniejszym akapicie projekcie zamieniamy część kodu na elementy sztucznej inteligencji. Posługując się dalej przykładem utraty trakcji przez oponę samochodu, sieć neuronowa w naszym modelu AI będzie przyjmować dane środowiskowe z czujników czy kamer i aproksymować określoną czynność do wykonania. Innymi słowy, programiści zamiast sami wytwarzać równania matematyczne i implementować je do oprogramowania w podejściu Software 1.0, w modelu Software 2.0 mogą w sposób mocno przybliżony opisywać wszystkie zjawiska i pokrywać przy użyciu AI znacznie większe spektrum zdarzeń, zamiast robić to samodzielnie. Architektura AI rozwiąże nam 90% problemów, jakie opisalibyśmy za pomocą np. 100 równań matematycznych – i to tylko takich, odpowiadających za ruch i fizykę koła w kontakcie z podłożem. Do tego dochodzą też kwestie utrzymania kodu – z reguły najdroższej części procesu wytwarzania.
“Architektura AI rozwiąże nam 90% problemów, jakie opisalibyśmy za pomocą np. 100 równań matematycznych.”
Porównanie Software 1.0 z Software 2.0
Jeśli w podejściu 1.0 napisaliśmy np. oprogramowanie dla urządzenia i po jakimś czasie konieczne są zmiany, bo wymieniliśmy jeden z komponentów elektronicznych na inny, o innych parametrach, oznacza to, że wszystkie stworzone przez nas modele matematyczne związane z parametrami tego elementu są nieaktualne i musimy wyrzucić je do kosza. Jeśli przełożymy to na duży projekt, jakim jest zbudowanie pojazdu autonomicznego, takich elementów, mających wpływ na końcowy produkt są tysiące. Natomiast w podejściu 2.0 tak dużego problemu nie ma. Przebudowanie oprogramowania wiąże się z przetrenowaniem naszego modelu na nowych danych związanych z komponentem i wszczepieniem naszego nowego modelu w miejscu tego wcześniejszego. To dużo łatwiejsze, znacznie szybsze i przy okazji umożliwiające wyeliminowanie kwestii utrzymania kodu. Może się przy okazji okazać również korzystniejsze dla produktu końcowego, bo nowy komponent będzie miał np. lepsze parametry, które mogą nam otworzyć nowe możliwości. Przykładowo w naszym pojeździe montujemy nową kamerę o wyższej rozdzielczości, przez co nasza sieć neuronowa otrzymuje więcej dokładnych informacji ze środowiska i dokładniej je przetwarza.
Druga zaleta na korzyść Software 2.0 to optymalizacja kodu pod kątem wydajności, czego celem jest odciążenie pamięci procesora. W tym przypadku możemy np. wyciąć część parametrów z naszej sieci rekurencyjnej, co zmniejszy potrzebną ilość pamięci. Następnie przetrenujemy sieć, wykorzystując np. technologię knowledge distillation. Oczywiście zmniejszy się nieznacznie skuteczność naszego rozwiązania, ale nasz cel osiągniemy dość łatwo. Przy Software 1.0 taka optymalizacja to proces niezwykle czasochłonny i bardzo trudny, co pokazują co jakiś czas twórcy gier komputerowych, tworzący swoje produkty na zróżnicowane platformy. W erze Software 2.0, kiedy projektujemy aplikacje dla różnorodnych platform wspierających różne środowiska programistyczne, cały proces staje się bardziej efektywny. Nie musimy już detalicznie definiować, jak każdy mikrokontroler czy GPU ma przetwarzać dane. Naszym zadaniem jest zoptymalizowanie i wdrożenie naszych modeli sieci neuronowych, tak aby były kompatybilne z danym systemem operacyjnym i sprzętem. Nie musimy martwić się o niskopoziomową komunikację i interpretację przez CPU. Kluczem jest wdrożenie odpowiedniego frameworku Software 2.0 w odpowiednim czasie oraz zapewnienie, że procesor otrzyma odpowiednio przygotowane dane do obliczeń.
Ograniczenia Software 1.0, architektura Transformer i fine-tuning
Innym wyzwaniem, jakie występuje w przypadku podejścia Software 1.0, jest podatność na wprowadzanie dużych zmian w oprogramowaniu. Przyjmijmy, że mamy samochód autonomiczny, do którego napisaliśmy instrukcję, w jaki sposób pojazd ma jechać do przodu i zatrzymywać się samodzielnie. Nasz software dostosowany jest do wszystkich możliwych zmiennych (różnego rodzaju kamer, nawierzchni, warunków atmosferycznych, opon, wersji silnikowych, obciążenia itp.). Jeśli chcielibyśmy do naszego idealnego systemu dodać funkcję skręcania tylko w lewo, oznaczałoby to, że musimy przebudować cały nasz system, bo całkowicie zmienia się dynamika systemu. Musielibyśmy rozpatrzyć jeszcze więcej zmiennych, np. kąt skrętu koła, kąt wychylenia pedału gazu czy zmienną trakcji. Dynamika obliczeń rośnie w tempie wykładniczym! W takim przypadku łatwiej jest oczywiście wyrzucić cały kod i napisać go od nowa, zamiast modyfikować, ale to wydłuża czas realizacji projektu. Trzymając się branży automotive, nikogo nie dziwi, że wiele projektów trwa w niej nawet 15 lat! Oczywiście, w Software 2.0 działa to zupełnie odmiennie. Dzięki technologii, która pojawiła się stosunkowo niedawno – architekturze Transformer (wykorzystywanej przez ChatGPT), nie musimy tworzyć na nowo, a jedynie przetrenować model na świeżych danych, które mają wprowadzić nową funkcjonalność. Wracając już do naszego przykładu, będą to dane opisujące manewr skrętu w lewo, np. dane z kamer kierowców czy dane syntetyczne, stworzone przez nas. To samo możemy zrobić z każdą kolejna funkcją. Taki proces nazywa się fine-tuning i polega na uczeniu systemu nowej umiejętności. To dokładnie to, co możemy zaobserwować w przypadku ChatGPT. Polega na nauczeniu AI formułowania wypowiedzi tak, jak robią to konkretne osoby. W Software 2.0 uczymy nasz model AI w symulacji wykonania określonej czynności, dając mu sygnał zwrotny – zrobiłeś to źle lub dobrze. Możemy przekazywać mu tylko informację bardzo wysokopoziomową. W końcu nauczy się on wykonywać czynność perfekcyjnie, lepiej niż jakikolwiek człowiek. W Software 1.0 to my programujemy i uczymy wykonywania określonych zadań. Polega to jednak przede wszystkim na kodowaniu i opisywaniu matematycznym instrukcji.
“Dzięki technologii, która pojawiła się stosunkowo niedawno – architekturze Transformer (wykorzystywanej przez ChatGPT), nie musimy tworzyć na nowo, a jedynie przetrenować model na świeżych danych, które mają wprowadzić nową funkcjonalność.”
Software 2.0 – wyzwaniem cybersecurity
Software 2.0 zbudowany jest na sieciach neuronowych posiadających ileś parametrów. Skuteczność sieci neuronowych jest w pewnym stopniu mierzalna. Mogą jednak wystąpić pewne sytuacje, w których informacje zostaną zmanipulowane. Na przykład, jeśli zmienimy jeden piksel w obrazie kamery, z której dane analizuje AI, może się okazać, że system nie będzie rozpoznawał obrazu prawidłowo. W przypadku Software 1.0 ten problem nie wystąpi, bo obrazy, które system ma rozpoznawać, są opisane bardzo prosto i precyzyjnie. System więc zawsze odczyta go prawidłowo. W Software 2.0 tego rodzaju przypadki – głównie związane z incydentami cyberbezpieczeństwa nazywanymi adversarial – się zdarzają. Jest to niezwykle trudne do przetestowania i wychwycenia w trakcie. Przy okazji wymaga bardzo specyficznego oprogramowania, które będzie testować system przy każdej próbie. Rozwiązaniem są symulatory, dostarczające szumy do informacji przetwarzanych przez AI, aby wyuczyć system perfekcyjnego poruszania się w sytuacjach, gdy informacje odbiegają od idealnych. Jest to niezwykle skomplikowane i kosztowne do stworzenia, ale będzie rozwiązaniem większości problemów. Tą drogą podąża m.in. Tesla czy SpaceX.
Jak Billennium wprowadza Software 2.0
Software 2.0 to również kierunek, w jakim chce podążać Billennium. Oczywiście nie chodzi tylko o tworzenie nowych produktów czy rozwiązań dla naszych klientów. Sugerujemy też pomijanie pewnych mechanizmów w już istniejącym oprogramowaniu. Takim przykładem może być np. wybór ChatGPT i zastępowanie nim wyszukiwarek w aplikacjach czy systemach korporacyjnych. Pozwoli to na uzyskanie dokładniejszych odpowiedzi, w oparciu o znalezione korelacje i wytrenowanie modelu na danych otrzymanych, ale i oczekiwaniach użytkowników. Dodatkowo oferujemy naszym klientom modyfikacje w opracowanym przez nas oprogramowaniu, którym całym czas się opiekujemy. To przede wszystkim pozwala ułatwić i skrócić wiele czynności w przyszłości: utrzymywanie systemu, wprowadzanie zmian i dodawanie funkcji, integrację z nowymi produktami czy innymi systemami. Po modyfikacji systemu do postaci Software 2.0, kolejnym krokiem jest już tylko dostarczenie danych, na których prowadzimy procesy fine-tuningu.