A.I. – wariacja na temat

Zawsze byłem sceptycznie nastawiony do tak zwanej ‘sztucznej inteligencji’. Nie chodzi tu bynajmniej o stosunkowo proste algorytmy klasyfikowane dość swobodnie i niezbyt formalnie jako AI, a wykorzystywane chociażby w programowaniu gier: wyszukiwanie najkrótszej drogi, zachowanie się postaci typu NPC, itp. Mam raczej na myśli takie konstrukcje (zarówno programy, jak i urządzenia, a najczęściej połączenie jednych i drugich), które starają się być znacznie bardziej uniwersalne i sprawiać wrażenie inteligentnych w jakimkolwiek z spośród licznych i niezbyt jasnych znaczeń tego słowa.
Mój “problem” polegał mniej więcej na tym, że jakoś ciężko było mi uwierzyć w to, że kiedyś – nawet niekoniecznie w przewidywalnej przyszłości – maszyny będą rzeczywiście myślały. Można to uznać za swego rodzaju zawodowe zboczenie. Wiedząc, że komputery działają zawsze w oparciu o określony, niezmienny i ściśle zdefiniowany algorytm, trudno jest uwierzyć, że wystarczy tylko odpowiedni wzrost mocy obliczeniowej, by nagle zyskały one jakieś nieprzewidziane zdolności. W takim podejściu tkwi jednak pewne dość wątpliwe, a kluczowe założenie, o istnieniu którego zdałem sobie sprawę dopiero niedawno…

Kismet – robot “z uczuciami”
© Jared C. Benedict, MIT

Zasadniczo z maszynami, które mają być w jakimś aspekcie podobne do ludzi lub innych istot żywych, wiążą się dwa zasadnicze problemy. Pierwszym jest różnica między właściwościami, jakie faktycznie posiadają, a tymi, które tylko wydają się posiadać. Nietrudno na przykład zauważyć, że spsiały robot Aibo całkiem dobrze naśladuje zachowanie prawdziwego zwierzęcia. Równie szybko można jednak zdać sobie sprawę, że tak naprawdę nie zrobi on niczego, do czego nie został wcześniej zaprogramowany. Nawet jeśli ktokolwiek przypisuje mu więc jakiekolwiek psie cechy, nie czyni go to jeszcze sztucznym psem.
Drugim i znacznie poważniejszym problemem jest to, że konstruując tego rodzaju maszyny, ludzie starają się naśladować coś, o czym tak naprawdę wiedzą niewiele. Wciąż nie mamy dobrych (czyli weryfikowalnych) definicji na takie pojęcia jak ‘życie’, ‘inteligencja’ czy ‘świadomość’. Zwłaszcza ten ostatni termin jest kłopotliwy, gdyż stuprocentowo pewną odpowiedź pozytywną na pytanie “Czy coś jest świadome?” możemy udzielić tylko wtedy, gdy chodzi o… nas samych.

I chociaż filozofia jak zwykle nie dostarcza żadnych konkretnych odpowiedzi, nie przeszkadza to badaczom dociekać, jak świadomość może powstawać – ze szczególnym uwzględnieniem ludzkiej, która musiała przecież wykształcić się w toku ewolucji. Do niedawna najlepszym “wyjaśnieniem”, o jakim słyszałem, była emergencja, czyli powstawanie złożonych zjawisk na kanwie prostych “klocków”. Innymi słowy jest to twierdzenie, że całość jest czymś więcej niż tylko sumą części. W odniesieniu do świadomości oznacza to, że w dostatecznie dużym zbiorze neuronów (albo odpowiednio zaawansowanym komputerze czy też sieci tychże) wyłoni się ona samoistnie. Raczej mało przekonujące, nieprawdaż?
Znacznie ciekawszym przypuszczeniem jest hipoteza, że ludzie są samoświadomi, gdyż używają w stosunku do swojej osoby pewnych modeli, które są wykorzystywane przez mózg w odniesieniu do innych ludzi. Zakładamy na przykład, że inni ludzie też myślą, mają uczucia i że w swoim postępowaniu kierują się jakimiś zasadami. Często takie założenia i oparte na nich modele zachowań bywają trafne, więc przez pokolenia były udoskonalane, bo miały po prostu ewolucyjne uzasadnienie. Ciekawie zaczyna się robić wtedy, kiedy odkrywa się, że z pomocą tzw. neuronów lustrzanych ludzki mózg może budować modele swego posiadacza. Właśnie taki model może być jeśli nie samoświadomością, to przynajmniej jej solidną podstawą.

Uff, to było wyczerpująca dygresja ;-) A jakie są praktyczne wnioski dla sztucznej inteligencji? Otóż jeśli świadomość rzeczywiście tak “działa”, to można nią obdarzyć dowolny byt w relatywnie łatwy sposób. Wystarczy, że będzie on posiadał jakiś mechanizm, umożliwiający mu rozpoznawanie innych bytów, a następnie zastosuje go w stosunku do siebie.
Proponuję teraz zejść wreszcie z tych niebotycznych wyżyn abstrakcji – i to od razu na sam dół: do kodu. Napiszmy po prostu klasę obiektów, które będą świadome w powyższym sensie:

Tak, to już jest to. To chyba najbardziej prymitywny sposób realizacji całego pomysłu, ale zawiera wszystkie niezbędne elementy. Mamy tutaj metodę perceive, za pomocą której nasz obiekt może “postrzegać” jakiś inny obiekt – co tutaj oznacza po prostu wypisanie jego tekstowej reprezentacji wraz z nazwą jego klasy. Przejawem samoświadomości jest z kolei metoda introspect, która to pozwala obiektowi “postrzegać” w ten sposób siebie. Robi to podobnie jak we wszystkich pozostałych przypadkach, acz nieco inaczej, gdyż wie (tak jak ludzie), że teraz “patrzy” do swojego wnętrza. Mechanizm jest jednak podobny.
A przykładowe wyniki są następujące:

`42` is a(n) <type ‘int’>
`Ala ma kota` is a(n) <type ‘str’>
`<Foo instance at 0x014BDA08>` is a(n) Foo
I am a(n) ConciousObject

To oczywiście tylko żart, ale jeśli wspomniana teoria samoświadomości zdobędzie solidne dowody, to kto wie – może na analogicznej zasadzie będą w przyszłości konstruowane maszyny, które nie tylko myślą, ale też wiedzą, że myślą. Jeżeli bowiem świadomość jest tylko złudzeniem, to być może da się ten artefakt funkcjonowania mózgu zaimplementować także u maszyn.
W każdym razie mam nieodparte wrażenie, że zanim prawdziwego rozpędu nabierze rozwój sztucznej inteligencji, ja zdołam wyprodukować jeszcze sporą ilość podobnych “naturalnych głupot” ;-)

Niemal standardowe nazwy klas

Model-View-Controller (MVC),
bardzo modny ostatnio ‘wzorzec’

Wzorce projektowe (design patterns) to w założeniu ogólne modele związków pomiędzy klasami (i samych klas), jakie mogą pojawiać się w projektach. Każdy taki wzorzec jest przeznaczony do dość ściśle określonych okoliczności, dokładnie opisany i, przede wszystkim, nazwany. Na pewno każdy średnio zaawansowany programista miał okazję spotkać się z takimi terminami jak Iterator, Fabryka czy Singleton. Są one już na tyle długo używane, że w większości przypadków nie ma problemów ze zrozumieniem tego, co w danej sytuacji oznaczają.

Wzorce nie są oczywiście doskonałe. Ze względu na względnie dużą ścisłość nie mogą opisywać wszystkich rozwiązań, jakie mogą być konieczne, jeśli myślimy o zaprojektowaniu dowolnego programu. Nie jest więc tak, że każda klasa, jaka przyjdzie nam głowy, może być od razu wpasowana w jakiś gotowy szablon.
Przeglądając gotowe kody i różnego rodzaju dokumentacje stwierdziłem jednak, że często powtarzają się w nich różnego rodzaju “pseudowzorce”. Objawiają się one głównie używaniem pewnych słów w nazwach klas, dzięki którym można mniej więcej domyślić się, jaka jest rola poszczególnych typów, do czego służą, jak – z grubsza – działają oraz jakie wykazują zależności z innymi klasami. Naturalnie mogą występować spore różnice pomiędzy poszczególnymi bibliotekami i językami, ale przynajmniej dla dwóch największych zbiorów klas, jakie są obecnie w powszechnym użyciu (czyli .NET Framework i JDK), rozbieżności nie są zbyt duże. Co więcej, ponieważ wielu programistów używa któregoś z tych dwóch narzędzi, często przejmują oni te wzorce nazewnictwa (świadomie lub nie) i stosują je we własnych kodach. Kto wie, może dzięki temu przeciętna czytelność kodu produkowanego przez statystycznego programistę (jeśli w ogóle istnieje ktoś taki :]) ma szansę choć odrobinę wzrosnąć?…

Jakie są więc te nieformalne “wzorce”? Otóż znalazłem kilka następujących:

• Manager to egzemplarz występujący bardzo często i niestety chyba najmniej jednoznaczny z nich wszystkich. W dosłownym tłumaczeniu jest to ‘zarządca’ czegoś i właściwie niewiele więcej można o nim powiedzieć. Nazywanie wszystkiego ‘menedżerem’ jest popularne zwłaszcza wśród programistów gier: mamy więc menedżery zasobów, tekstur, stanów, czcionek – i tak dalej. Zastanawiam się tylko, skąd to upodobanie to tego akurat terminu. Czyżby programiści z sentymentem wspominali w ten sposób Menedżera Programów, czyli sławetną “powłokę” systemu Windows w archaicznych wersjach 3.x? :)
• Handler (ew. listener) jest już znacznie precyzyjniejszym pojęciem. Zazwyczaj jest to bowiem obiekt, który ma wykonywać jakieś działanie w reakcji na określenie zdarzenie – czyli ma je ‘obsługiwać’. Najczęściej oznacza to, że typ handlera jest tylko abstrakcyjną klasą bazową lub interfejsem, po którym powinniśmy dziedziczyć, a następnie zaimplementować jego metody i wreszcie “podpiąć” powstały obiekt pod mechanizm obsługi zdarzeń. Typowym zastosowaniem takiego rozwiązania jest reakcja na zdarzenia interfejsu użytkownika (klikanie w przyciski, wciśnięcia klawiszy, itd.) albo powiadamianie o przebiegu operacji asynchronicznych (np. komunikacji sieciowej).
• Provider jest z kolei obiektem, który ma ‘dostarczać'(lub ‘zapewniać’) jakąś funkcjonalność. Od strony technicznej często działa on tak samo jak handler (czyli w oparciu o polimorfizm metod wirtualnych), tyle że jego przeznaczenie i sposób użycia są nieco inne. Takiego providera podajemy w funkcji lub w obiekcie, dzięki czemu może ona wykonać przy jego pomocy jakieś czynności. Prostym przykładem jest chociażby sortowanie, któremu podajemy obiekt komparatora, odpowiedzialny za dokonywanie porównań. Tak naprawdę jest to więc po prostu wzorzec Strategia (Polityka – policy), któremu ktoś z niewiadomych powodów nadał bardziej “profesjonalną” nazwę.
• Context oznacza najczęściej taki obiekt, który definiuje jakieś ‘środowisko’, w którym działają inne obiekty. Są one zależne od obiektu reprezentującego kontekst, ale nie można powiedzieć, aby ten się z nich składał (może on nawet “nie wiedzieć”, że jest przez nie wykorzystywany). Po prostu dzięki niemu obiekty “potomne” mogą wykonywać swoje czynności.

Prawdopodobnie dałoby się wyróżnić jeszcze kilka pozycji (chociaż część byłaby dokładnym odpowiednikiem klasycznych wzorców projektowych), ale, jak widać, w sumie chyba nie jest ich zbyt dużo. To w gruncie rzeczy całkiem dobra wiadomość, gdyż nietrudno zauważyć, że wszystkie te nazwy są raczej “magiczne” i na pierwszy rzut nie przywołują jakichś natychmiastowych skojarzeń – zwłaszcza, jeśli nie jesteśmy do nich przyzwyczajeni. Ale taki już urok projektowania zorientowanego obiektowo, polegającego na tworzeniu dziwnych bytów i jeszcze dziwniejszych zależności między nimi :)