Oprogramowanie - zaklinacze maszyn

Zamiast instalować kosztowne pakiety do zarządzania, klienci tego start-upa uruchamiali przez Internet aplikację Salesforce, płacąc jedynie opłatę abonamentową, która zazwyczaj stanowiła ułamek kosztów stosowania rozwiązań takich firm, jak SAP, PeopleSoft czy Siebel Systems.

Aplikacje Salesforce.com są wciąż jednak oprogramowaniem. W gruncie rzeczy nie chodziło więc o żaden koniec, lecz o zmianę modelu korzystania z produktów programistycznych. Padające obecnie tu i ówdzie hasła "końca oprogramowania" wydają się być bardziej radykalne. Czy jednak ludzkość na obecnym etapie rozwoju technicznego może obejść się bez kodu i programowania? Wątpliwe.

Od dziesięcioleci dość powszechną tendencją w projektowaniu wszelkiego rodzaju systemów jest zwiększanie wagi, jaką przywiązuje się do programowania w stosunku do budowy i konfiguracji sprzętu. Podążają za tym proporcje składów zespołów roboczych. W naszym świecie technologicznym praktycznie nic nie istnieje dziś bez jakiejś formy software'u. Nierzadko zdarza się, że w projekcie technicznym stosunek zasobów ludzkich i innych pomiędzy programowaniem a inżynierami sprzętu wynosi 10:1. Niektórzy obrazowo włączają oprogramowanie do listy podstawowych żywiołów świata - do ognia, wody, ziemi i powietrza dodają więc kod.

John von Neumann i wczesny komputer z 1952 r.

Architektura von Neumanna kosztuje, ale działa

Każda aplikacja i każdy system są zaprojektowane tak, aby rozwiązywać problemy. Zasadniczo służą do tego algorytm oraz dane. Zadaniem algorytmu jest po prostu znaleźć odpowiedź wśród danych - tak efektywnie, jak to tylko możliwe. Działanie algorytmu ma dwa aspekty: miękki, czyli program (software), i twardy, czyli sprzęt (hardware). Jeśli algorytm jest wystarczająco prosty, można pominąć warstwę oprogramowania. Wiele algorytmów da się więc zaimplementować bezpośrednio w sprzęcie, który przetwarza dane i odnajduje rozwiązanie bez konieczności stosowania oprogramowania. Podejście to wykorzystywali przed kilkoma dekadami twórcy oryginalnych ręcznych kalkulatorów, wczesnych zręcznościowych gier wideo i wielu innych urządzeń elektronicznych. Jeśli maszyna nie ma nic bardziej skomplikowanego do roboty niż proste działania, wystarczą układy scalone TTL, stosowane już w latach 60.

Problem z implementacją algorytmów bezpośrednio w sprzęcie polega jednak na tym, że złożoność wymaganej strony sprzętowej rośnie szybko wraz ze złożonością algorytmu. Każde kolejne obliczenie lub pętla logiczna wymaga wzrostu liczby fizycznych bram logicznych. Konwencjonalna architektura procesora von Neumanna wykorzystuje zakodowane w niej samej oprogramowanie, które umożliwia obsługę dowolnie złożonych algorytmów bez zwiększania złożoności urządzeń. Możemy zaprojektować jeden standardowy sprzęt - procesor, za pomocą którego da się wykonać dowolną liczbę dowolnie skomplikowanych algorytmów.

Ów wygodny uniwersalizm to doskonały wynalazek, ale jak każda dobra rzecz ma swoją cenę. W porównaniu z oprogramowaniem na konwencjonalnym procesorze algorytmy mogłyby działać od 100 do 10 tys. razy szybciej, gdyby zostały zaimplementowane na odpowiednio zoptymalizowanym sprzęcie. Obciążenie uniwersalnych procesorów - jeśli dodać liczniki programów i instrukcje pobierania - staje się kosztowne, gdy zestawimy to wszystko z efektywnością. Ze względu na sekwencyjny charakter oprogramowania maszyny von Neumanna z trudem radzą sobie z wielością zadań.

Koszty wydajnościowe architektury von Neumanna są ogromne, jednak jak do tej pory nie przeważyły korzyści, jakie z niej płyną. Algorytm da się w niej zaimplementować w ciągu kilku godzin. Jego opracowanie i optymalizacja sprzętowa, jeśli w ogóle jest możliwa, trwać może miesiące. Swoisty kompromis, który zawarliśmy pomiędzy sprzętem a oprogramowaniem, wydaje się na tyle atrakcyjny, że świat korzysta z niego już ponad pół wieku, nie zmieniając niczego w sposób zasadniczy - ograniczając się do optymalizacji.

Wnioskowanie z galimatiasu

Prawo Moore'a dotyczyło eksplozji sprzętu. Liczba komponentów, z których składają się układy scalone, zwiększyła się od 1965 r. o około osiem rzędów wielkości. Oprogramowanie, choć jego złożoność również rosła, zmieniało się według innych zasad, które trudno opisać w krótkim artykule, ale w pewnością postęp w tej dziedzinie nie polega na powiększaniu liczby linijek kodu. A jeśli w miarę rozwoju systemów tak się właśnie dzieje, to ilość wcale nie oznacza jakości.

Okładka książki "Engineering a Safer World: Systems Thinking Applied to Safety"

Oprogramowanie jest czymś zupełnie innym niż stare, dobre systemy mechaniczne i elektromechaniczne, nad którymi człowiek z łatwością panował za pomocą prostych instrukcji i własnego doświadczenia. W świecie programów niewielka edycja tekstu w pliku sprawia, że ta sama porcja krzemu może zmienić się z autopilota w samolocie na system kontroli zapasów w magazynie.

Owa elastyczność stanowi cudowną cechę oprogramowania i zarazem jego przekleństwo. Niskie koszty zmian prowadzą do tego, że oprogramowanie jest stale zmieniane, a z czasem programy mają tendencję do rozrastania się bez ograniczeń.

"Problemem" - pisała Nancy Leveson, profesor aeronautyki i astronautyki w Massachusetts Institute of Technology w swojej książce "Engineering a Safer World: Systems Thinking Applied to Safety" - "jest to, że budujemy systemy, które wykraczają poza ludzkie zdolności ogarnięcia ich umysłem".

Tradycyjnie programiści pisali oprogramowanie jako serię twardych reguł - w przypadku wystąpienia X należy wykonać Y. Człowiek instruuje maszynę krok po kroku, co ma robić. Gdy jednak kod zaczyna się komplikować, a potem nawarstwiać przez kolejne poprawki i uzupełnienia kolejnych autorów, którzy niekoniecznie się ze sobą kontaktują, pojawiają się problemy. Ostatecznie działania maszyny stają się niejako wypadkową wszystkich instrukcji w kodzie, jej samodzielnym wnioskiem z tego programistycznego galimatiasu. A wnioskowanie maszyny może nie mieć nic wspólnego z ludzkimi intencjami, stąd awarie systemów, wyłączenia albo wypadki, czasem nawet śmiertelne.

Niech maszyny same programują

Kres tradycyjnie rozumianego programowania, w którym to człowiek wszystko stara się przewidzieć i zaprojektować, oznaczają m.in. systemy sztucznej inteligencji. W przypadku technik uczenia maszynowego co do zasady omijany jest etap programowania. Chodzi o to, aby sieć neuronowa sama wytworzyła algorytm.

W odniesieniu do tradycyjnego, pisanego przez ludzi kodu od razu widać, jak ów algorytm funkcjonuje. Tymczasem w większości przypadków nie wiemy tak naprawdę, jak działa algorytm maszynowy, stworzony przez sztuczną inteligencję. Pod wieloma względami czynności neuronalne systemu AI są dla nas niczym skrzynka o nieznanej zawartości. System patrzy np. na tysiące obrazów twarzy i wskazuje, które osoby kłamią, ale nie wiemy, czy AI zgaduje to z układu brwi, ilości potu na skórze, grymasu warg czy wydymania nozdrzy. Jednak po sprawdzeniu, widzimy, że system ocenia trafnie.

Zamiast więc tradycyjnego programowania, w którym programista zapisuje instrukcje mówiące komputerowi krok po kroku, co ma robić, programiści szkolą maszyny, aby rozpoznawały sytuacje i reagowały tak, jak sobie tego życzymy. Łatwo zauważyć, że rozwój sztucznej inteligencji zakłada zgodę na samodzielność maszyny i rezygnację z próby przewidzenia wszystkiego, co było immanentną cechą starego myślenia programistycznego. Nie próbujemy systemu trzymać cały czas za rękę, lecz szkolimy go na kolejnych przykładach. Samochody uczymy autonomicznej jazdy. Komputery - rozpoznawania twarzy na zdjęciach. Smartfony - identyfikacji pisma ręcznego. Program odpowiadający za działanie tych systemów jest tworzony przez maszynę.

I tu dochodzimy do sedna rzeczy.

W efekcie takiego postępowania znikają problemy wywołane skomplikowanym kodem. Maszyna bowiem bez wątpienia rozumie algorytm, który sama stworzyła. My czuwamy tylko, aby wynik działania tego algorytmu był zgodny z naszymi intencjami. Programiści zaś, w przyszłym świecie AI, zamiast pisać kod, staną się menedżerami czy też kuratorami danych, a zarazem, ma się rozumieć, opiekunami i zaklinaczami maszyn.