Dlaczego „stara” sztuczna inteligencja różni się od tej modnej dzisiaj
Kontrast: laboratoryjna ciekawostka kontra masowy produkt chmurowy
Sztuczna inteligencja, zanim stała się modnym hasłem sprzedażowym i fundamentem usług chmurowych, była niszową dziedziną kilku laboratoriów, finansowaną głównie z grantów wojskowych i akademickich. Nie było pitch decków dla funduszy VC, nie było kampanii „AI first”. Było kilku upartych matematyków, inżynierów i logików, którzy chcieli przekonać nieprzekonanych, że komputer może robić coś więcej niż mnożyć macierze czy liczyć trajektorię pocisku.
Dzisiejsze podejście do AI jest w dużej mierze produktowe: modele mają działać szybko, skalować się w chmurze, obsługiwać miliony użytkowników i służyć konkretnym wskaźnikom biznesowym – konwersji, retencji, oszczędności czasu. W latach 50., 60. i 70. stawką była głównie demonstracja możliwości: że maszyna potrafi udowodnić twierdzenie matematyczne, zagrać w uproszczone szachy czy rozwiązać równanie. Te programy nie musiały zarabiać; miały udowodnić, że koncepcja ma sens.
Różnica klimatu jest kluczowa, jeśli myślisz dziś o AI pragmatycznie: dawni badacze mogli poświęcać miesiące na miniaturowe demonstratory, bo rozliczano ich z publikacji naukowych, a nie z MRR czy czasu działania API. Dzisiaj ten luksus ma tylko część zespołów R&D; reszta musi liczyć koszt GPU na godzinę i czas wdrożenia do produkcji.
Stare cele: ogólna inteligencja i rozumowanie, nie tylko predykcja
Klasyczna, „stara” sztuczna inteligencja była w dużej mierze poszukiwaniem sztucznej inteligencji ogólnej (AGI), choć wtedy takiego skrótu jeszcze nie używano. Główny cel: stworzyć maszynę, która potrafi rozumować, wyciągać wnioski, planować, tłumaczyć swoje decyzje i przenosić wiedzę między zadaniami. Liczyło się modelowanie samego procesu myślenia, a nie tylko wynik.
Dzisiejsze popularne systemy AI – od rekomendacji treści po rozpoznawanie obrazów – są skoncentrowane na predykcji i optymalizacji. Model nie musi „rozumieć” zdjęcia psa; wystarczy, że z rozsądną dokładnością przewidzi etykietę „pies”, „kot” czy „samochód”. W efekcie współczesne AI jest zazwyczaj wąsko wyspecjalizowane, za to bardzo skuteczne w konkretnych zadaniach.
Dla praktyka różnica przekłada się na strategię projektu: jeśli próbujesz dzisiaj „od zera” zbudować system, który rozumuje jak człowiek, najprawdopodobniej zderzysz się z tymi samymi ścianami, na które wpadali pionierzy AI dekady temu. Bardziej opłacalne bywa rozbicie problemu na szereg wąskich, dobrze zdefiniowanych zadań, które można obsłużyć wyspecjalizowanymi modelami, a dopiero potem łączyć je warstwą logiki lub workflow.
Ograniczenia sprzętu i danych wymuszające inne podejście
W erze początków sztucznej inteligencji komputer był zasobem ekstremalnie drogim i deficytowym. Mowa o maszynach wielkości szafy, rezerwowanych na minuty lub godziny, z pamięcią liczona w kilobajtach, nie gigabajtach. Nie istniały ani tanie dyski, ani Internet, ani publiczne zbiory danych. Wszelkie „dataset-y” trzeba było tworzyć ręcznie, zapisując je często na kartach perforowanych.
W takich warunkach uruchomienie dzisiejszego prostego modelu klasyfikacji byłoby niewyobrażalnie drogie i długotrwałe. Dlatego podejście symboliczne – oparte na regułach i logice – wydawało się bardziej naturalne: nie wymagało uczenia na dużych zbiorach danych, tylko ręcznego zakodowania wiedzy. Matematycy i logicy czuli się jak ryba w wodzie: zamiast milionów próbek wystarczyło wymyślić odpowiednią formalizację.
Efektem ubocznym tych ograniczeń było powstanie wielu oszczędnych algorytmów, które dzisiaj są cenną inspiracją, gdy trzeba działać na słabszym sprzęcie (np. wbudowane urządzenia IoT, mikrokontrolery) albo w trudnych warunkach (misje kosmiczne, systemy wbudowane w pojazdach, gdzie liczy się niezawodność i zużycie energii).
Dlaczego znajomość dawnych prób pomaga oszczędzać czas i budżet
Historia początków sztucznej inteligencji to w praktyce długa lista eksperymentów, które się nie skalowały, oraz kilku rozwiązań, które zadziałały zaskakująco dobrze, choć w wąskich obszarach. Dla kogoś, kto dziś planuje wdrożenia AI, jest to darmowa skarbnica „case studies” pokazujących:
jakie typy problemów źle znoszą wyłącznie podejście oparte na regułach;
gdzie brak danych może zostać częściowo zastąpiony wiedzą ekspercką;
jakie błędne założenia prowadzą do nierealistycznych obietnic (i cięć w finansowaniu);
jak projektować systemy, żeby były odporne na zmianę zakresu problemu.
Kto rozumie, dlaczego pierwsze fale AI kończyły się „zimami sztucznej inteligencji”, ten z większą ostrożnością traktuje marketing wokół nowych modeli, rozsądniej dobiera cele projektów i lepiej komunikuje je interesariuszom biznesowym. To bezpośrednio przekłada się na niższe ryzyko przepalania budżetu na modne, ale nietrafione wdrożenia.
Pierwsze idee: zanim powstało słowo „sztuczna inteligencja”
Maszyny liczące Babbage’a i wizja Lovelace
Źródeł sztucznej inteligencji szuka się często w maszynach liczących z XIX wieku. Charles Babbage zaprojektował maszynę analityczną, która, choć nigdy w pełni nie powstała, miała cechy przypominające architekturę współczesnych komputerów: jednostkę pamięci, jednostkę obliczeniową i mechanizm sterowania.
Ada Lovelace, współpracująca z Babbage’em, stworzyła pierwsze opisy algorytmów przeznaczonych dla tej maszyny i wysunęła śmiałą tezę, że maszyny mogą manipuluje nie tylko liczbami, ale też symbolami, a więc w zasadzie mogą operować na dowolnych strukturach, które da się formalnie zapisać. To właśnie ten sposób myślenia jest fundamentem późniejszej symbolicznej sztucznej inteligencji.
Choć w tamtym okresie nikt nie mówił jeszcze o „myślących” maszynach, sama idea, że urządzenie mechaniczne może wykonywać z góry określony, złożony program, otworzyła drogę do późniejszych rozważań o automatycznym rozwiązywaniu problemów i zastępowaniu pracy umysłowej.
Alan Turing: pytanie „czy maszyny mogą myśleć?”
W pierwszej połowie XX wieku Alan Turing wprowadził pojęcie maszyny Turinga – abstrakcyjnego modelu obliczeń, który pozwalał formalnie opisać, co to znaczy „algorytm”. Dla historii AI kluczowe są dwa elementy jego dorobku.
Po pierwsze, Turing wykazał, że relatywnie prosty mechanizm potrafi symulować każdy algorytmiczny proces obliczeniowy. To zasugerowało, że jeśli myślenie można traktować jako pewien typ obliczeń, to teoretycznie maszynę da się zaprogramować tak, by naśladowała ludzki umysł.
Po drugie, Turing zaproponował test Turinga – eksperyment myślowy, w którym sędzia prowadzi rozmowę (pierwotnie tekstową) z dwiema „istotami”: człowiekiem i maszyną. Jeśli sędzia nie jest w stanie odróżnić maszyny od człowieka, mówi się, że maszyna „myśli” w sensie praktycznym. To przesunęło dyskusję z filozoficznych rozważań „czy maszyna ma świadomość” na praktyczne pytanie „czy potrafi zachowywać się jakby myślała”.
Logika matematyczna i filozofia umysłu
Równolegle do rozwoju sprzętu rosła rola logiki matematycznej. Prace Fregego, Russella, Whiteheada i późniejszych logików pokazały, że wnioskowanie można formalizować za pomocą reguł symbolicznych. To właśnie na tej bazie zrodziła się myśl, że rozumowanie można oddać w formie automatów manipulujących symbolami według ściśle określonych zasad.
Filozofowie umysłu rozważali, czy świadomość i myślenie są czymś „ponad” procesy fizyczne, czy też można je w całości sprowadzić do działania materii. Dla wielu informatyków i matematyków atrakcyjna była wizja funkcjonalizmu: liczy się struktura i funkcja systemu, niekoniecznie jego fizyczna natura. Innymi słowy, jeśli pewien system zachowuje się jak umysł, to jest to wystarczająco dobra definicja „umysłu” dla nauk ścisłych.
Wojna, kryptografia i narodziny automatycznego przetwarzania informacji
II wojna światowa była ogromnym katalizatorem rozwoju komputerów i idei, które później złożyły się na sztuczną inteligencję. W Bletchley Park Turing i jego zespół tworzyli elektromechaniczne i elektroniczne maszyny do łamania szyfrów Enigmy. Projekt Colossus – jeden z pierwszych elektronicznych komputerów cyfrowych – służył właśnie temu celowi.
Kluczową lekcją z tamtego okresu było to, że maszyna może wykonywać złożone zadania analityczne szybciej i bardziej niezawodnie niż człowiek, pod warunkiem że problem da się odpowiednio sformalizować. Łamanie szyfrów, analiza przechwyconych danych, planowanie logistyczne – wszystko to wymagało nowych metod przetwarzania informacji.
Wielu późniejszych pionierów AI pracowało w czasie wojny nad kryptografią, radarami czy balistyką. Po wojnie przenieśli swoje doświadczenia na grunt pokojowy, zabierając ze sobą przekonanie, że „inteligentne” przetwarzanie informacji można delegować na maszyny. To właśnie z tego połączenia teorii obliczeń, logiki i wojennej praktyki narodziła się potrzeba sformalizowania nowej dziedziny badań – sztucznej inteligencji.
Źródło: Pexels | Autor: Matheus Bertelli
Narodziny AI jako dziedziny: konferencja Dartmouth 1956 i jej tło
Kontekst lat 50.: zimna wojna i wyścig technologiczny
Lata 50. XX wieku były okresem intensywnego wyścigu technologicznego między Stanami Zjednoczonymi a Związkiem Radzieckim. Komputery stały się narzędziem strategicznym: wykorzystywano je do obliczeń nuklearnych, projektowania broni, analizy danych wywiadowczych. Rządy były gotowe finansować śmiałe projekty, jeśli tylko istniała szansa, że zapewnią przewagę nad przeciwnikiem.
W tym klimacie każde obietnice dotyczące „myślących maszyn” brzmiały atrakcyjnie. Taka maszyna mogłaby teoretycznie planować działania wojskowe, analizować gigantyczne ilości danych, optymalizować systemy obronne. Nic dziwnego, że badacze, którzy chcieli eksplorować te idee, mogli liczyć na granty – o ile potrafili je dobrze sprzedać.
Projekt Dartmouth: ambitny wniosek grantowy
W 1956 roku John McCarthy, Marvin Minsky, Nathaniel Rochester i Claude Shannon przygotowali propozycję letniego projektu badawczego w Dartmouth College. To właśnie tam po raz pierwszy użyto terminu „artificial intelligence” – sztuczna inteligencja – jako nazwy nowej dziedziny.
Wniosek był z dzisiejszej perspektywy niezwykle odważny. Zakładano, że grupa badaczy, pracując wspólnie przez jedno lato, może istotnie posunąć się naprzód w rozwiązywaniu problemów takich jak:
automatyczne tłumaczenie języków naturalnych,
nauka maszynowa,
abstrakcyjne rozumowanie,
tworzenie maszyn zdolnych do samodoskonalenia.
Autorzy uważali, że każdy aspekt uczenia się lub inteligencji można w zasadzie tak precyzyjnie opisać, by można go było symulować maszyną. Tego rodzaju stwierdzenia brzmiały wtedy jak śmiały optymizm, dziś wiemy, że były też źródłem późniejszych rozczarowań i pierwszych „zim AI”.
Pionierzy: McCarthy, Minsky, Rochester, Shannon
John McCarthy był matematykiem i informatykiem, który nie tylko ukuł termin „sztuczna inteligencja”, ale też stworzył język programowania LISP – przez dziesięciolecia podstawowe narzędzie pracy badaczy AI. Jego wizja kładła nacisk na logikę, reprezentację wiedzy i programy potrafiące samodzielnie rozwiązywać problemy.
Marvin Minsky, współtwórca MIT AI Lab, łączył zainteresowania matematyką, psychologią i neuronauką. Interesował się zarówno sieciami neuronowymi, jak i symboliką; później współodpowiadał za krytyczną ocenę perceptronów, która na lata zahamowała badania nad głębszymi sieciami.
Nathaniel Rochester reprezentował IBM, wnosił wiedzę o ówczesnych komputerach i o tym, jak potencjalne pomysły AI można implementować na realnym sprzęcie. Claude Shannon, twórca teorii informacji, już wcześniej badał gry (szachy) i problem strategicznego myślenia maszyn.
Założenia projektu i pierwsze programy
Projekt Dartmouth był w praktyce nie tyle pojedynczym eksperymentem, ile punktem zapalnym sieci badaczy. W jego bezpośrednim i pośrednim otoczeniu powstały pierwsze programy, które dziś uznaje się za klasyczne przykłady wczesnej AI:
Logic Theorist (Newell i Simon) – program potrafiący dowodzić twierdzenia z „Principia Mathematica”,
General Problem Solver (GPS) – próba stworzenia uniwersalnego rozwiązywacza problemów,
Od wielkich obietnic do pierwszych ograniczeń
Optymizm lat 50. był napędzany tym, że pierwsze programy faktycznie robiły rzeczy, które dotąd kojarzyły się z „prawdziwą” inteligencją: rozwiązywały łamigłówki, udowadniały twierdzenia matematyczne, grały w gry logiczne. Jednocześnie szybko okazało się, że każde z tych rozwiązań ma wbudowane ograniczenia, a ich „inteligencja” działa głównie w warunkach laboratoryjnych.
Logic Theorist świetnie radził sobie w formalnym, precyzyjnie zdefiniowanym świecie „Principia Mathematica”, ale przeniesienie tego podejścia na zwykły język czy nieuporządkowane problemy było poza zasięgiem dostępnych wtedy metod i mocy obliczeniowych. General Problem Solver potrafił rozwiązywać zadania z podręcznikowych przykładów, lecz w prawdziwych, większych problemach tonął w eksplozji kombinatorycznej – liczbie możliwych stanów, której żaden ówczesny komputer nie był w stanie obsłużyć.
To napięcie między efektownymi demonstracjami a praktycznym użyciem będzie wracać w historii AI jak bumerang. Już wtedy pojawił się wzorzec: krótki okres entuzjazmu, szybkie prototypy, a zaraz potem zderzenie z kosztami obliczeń, brakiem danych i ograniczeniami funduszy.
Symboliczna AI: kiedy inteligencja była zbiorem reguł i symboli
Fizyczny system symboliczny: myślenie jako manipulacja symbolami
Dla pierwszych badaczy AI kluczowe było przekonanie, że inteligencja to w dużej mierze manipulacja symbolami. Allen Newell i Herbert Simon zaproponowali koncepcję physical symbol system: system, który operuje na symbolach zgodnie z regułami, może – przynajmniej w zasadzie – zrealizować dowolny proces inteligentny.
W praktyce oznaczało to reprezentowanie wiedzy jako zbioru faktów i reguł typu: „jeśli X, to Y”. Fakty były zapisane w strukturach danych, a reguły w kodzie programu. Maszyna analizowała te struktury krok po kroku, wyciągając konsekwencje logiczne. Dla ówczesnych twórców naturalne było, że skoro w logice matematycznej da się udowadniać twierdzenia, to podobnie można obsługiwać codzienne rozumowanie.
Logika pierwszego rzędu, predykaty i drzewka dowodowe
Podstawą symbolicznej AI była logika predykatów pierwszego rzędu. Fakty typu „Jan lubi kawę” zapisywano w postaci predykatów, np. Lubi(Jan, Kawa). Reguły miały postać ogólnych zdań: „dla każdego X, jeśli X jest człowiekiem, to X jest śmiertelny”.
Komputery zaczęły traktować takie zdania jak dane wejściowe do algorytmów dowodzących twierdzenia.
Programy budowały drzewa dowodowe, próbując krok po kroku znaleźć sekwencję zastosowań reguł, która doprowadzi do wniosku. Działało to znakomicie na małych przykładach i w ściśle zdefiniowanych dziedzinach. Szybko jednak wychodziły na jaw dwie rzeczy:
liczba możliwych ścieżek dowodu rosła lawinowo przy większej liczbie faktów,
wiedzę o świecie trudno zapisać w sposób kompletny i bezsprzeczny.
Informatycy próbowali „przeciąć” ten problem heurystykami – sprytnymi skrótami myślowymi, które podpowiadały, które gałęzie drzewa warto rozwijać najpierw. Taki kompromis między dokładnością a kosztami obliczeń przewija się przez całą historię AI aż do dzisiejszych systemów.
Ramy, sieci semantyczne i pierwsze bazy wiedzy
Wraz z coraz większymi projektami pojawiła się potrzeba lepszej organizacji wiedzy. Zwykłe listy reguł stawały się nieczytelne i trudne w utrzymaniu. W odpowiedzi powstały takie koncepcje jak:
sieci semantyczne – grafy, w których węzły reprezentowały pojęcia (np. „pies”, „zwierzę”), a krawędzie relacje („jest podtypem”, „ma część”),
ramy (frames) – struktury opisujące typowe obiekty lub sytuacje wraz z atrybutami i domyślnymi wartościami, np. „spotkanie”, „pokój”, „samochód”.
Te techniki umożliwiały budowanie pierwszych baz wiedzy, które można było przeszukiwać i aktualizować. Zamiast kodować wszystko „na sztywno” w logice, badacze tworzyli bardziej elastyczne reprezentacje, które przypominały współczesne obiekty w programowaniu czy proste grafy wiedzy. To była raczej inżynieria niż magia – dużo ręcznego modelowania, przycinania szczegółów i szukania balansu między dokładnością a kosztem wdrożenia.
Wczesne programy AI, które naprawdę działały (na miarę swoich czasów)
Programy do gier: szachy i warcaby jako poligon doświadczalny
Gry planszowe były naturalnym polem testowym – zasady są jasno zdefiniowane, a sukces łatwo zmierzyć. Już na początku lat 50. Alan Turing opisał algorytm gry w szachy, który wykonywał „ręcznie”, bo nie miał jeszcze komputera o odpowiedniej mocy.
W kolejnych latach pojawiły się pierwsze działające programy szachowe i warcabowe. Nie grały na poziomie mistrzów, ale potrafiły:
analizować kilka ruchów naprzód,
oceniać pozycję za pomocą funkcji heurystycznej (np. „figury są warte X punktów, kontrola centrum Y”),
wybierać ruch maksymalizujący szanse wygranej według przyjętych kryteriów.
Te programy wprowadziły schemat przeszukiwania drzewa stanów (np. algorytm minimax z przycinaniem alfa-beta), który do dziś jest fundamentem wielu algorytmów decyzyjnych. Z perspektywy praktyka HPC czy inżyniera optymalizacji – to bardzo podobne do dzisiejszego przeszukiwania przestrzeni rozwiązań w logistyce czy planowaniu produkcji.
ELIZA: terapeuta na taśmę perforowaną
Jednym z najsłynniejszych wczesnych programów AI był ELIZA, stworzona przez Josepha Weizenbauma w latach 60. Program udawał terapeutę w stylu szkoły Rogeriańskiej, głównie poprzez:
rozpoznawanie słów kluczowych w wypowiedzi użytkownika,
proste przekształcanie zdań („Opowiedz mi więcej o…”),
odbijanie pytań z powrotem („Dlaczego tak sądzisz?”).
Technicznie rzecz biorąc, ELIZA nie miała „głębokiego” rozumienia. Operowała na dopasowaniach wzorców i prostych regułach tekstowych. A jednak wiele osób traktowało rozmowę z programem bardzo poważnie, co dla samego Weizenbauma było wręcz niepokojące. ELIZA pokazała, że nawet płytka, ale dobrze zaprojektowana interakcja może sprawiać wrażenie inteligencji – i że ludzie są skłonni nadawać maszynom więcej „umysłu”, niż faktycznie tam jest.
SHRDLU: mały świat, duża iluzja zrozumienia
Inny klasyczny projekt, SHRDLU Terry’ego Winograda, zajmował się rozumieniem języka naturalnego w bardzo ograniczonej „dziedzinie bloków”: wirtualnym świecie z kilkoma klockami różnej wielkości i kolorów. Użytkownik mógł pisać komendy typu „Przenieś czerwony klocek na niebieski sześcian”, a SHRDLU:
parsował zdanie na strukturę składniową,
mapował słowa na obiekty i relacje w swoim małym świecie,
planował sekwencję działań pozwalających spełnić polecenie.
W ramach tej zamkniętej domeny program robił wrażenie „rozumiejącego” język lepiej niż wiele późniejszych chatbotów. Problem w tym, że każde rozszerzenie zakresu wymagało ogromnej pracy ręcznej: nowej wiedzy o świecie, nowych reguł, wyjątków i poprawek. Ekonomicznie to było bardzo kosztowne – dodanie kolejnego typu obiektu czy sytuacji często wymagało tyle samo pracy co zbudowanie całego systemu od zera.
DENDRAL i MYCIN: AI jako narzędzie dla ekspertów
W latach 60. i 70. zaczęły powstawać programy celowane w konkretne, wąskie dziedziny, gdzie zwrot z inwestycji był bardziej realny niż w „ogólnej inteligencji”. Dwa przełomowe przykłady to:
DENDRAL – system wspierający chemików w analizie widm masowych związków organicznych,
MYCIN – system pomagający w diagnozie i doborze antybiotyków przy infekcjach bakteryjnych.
Oba programy wykorzystywały bogate zbiory reguł, zbudowane we współpracy z ekspertami. W testach na odpowiednio dobranych przypadkach MYCIN bywał porównywalny lub lepszy od lekarzy ogólnych. Dla szpitala czy laboratorium, które miało odpowiednią infrastrukturę, taki system mógł realnie oszczędzić czas i obniżyć koszt błędnych decyzji. Z drugiej strony, wdrożenie wymagało:
długotrwałego pozyskiwania wiedzy od specjalistów,
ciągłej aktualizacji reguł wraz z rozwojem dziedziny,
integracji z istniejącymi procedurami – co w praktyce bywało trudniejsze niż sama technologia.
Źródło: Pexels | Autor: Google DeepMind
Systemy ekspertowe: złota era „reguł” przed pierwszą zimą AI
Jak budowano systemy ekspertowe
Systemy ekspertowe stały się w latach 70. i 80. najbardziej dojrzałą technicznie i biznesowo częścią AI. Ich architektura była dość powtarzalna:
baza wiedzy – zestaw reguł typu „jeśli objaw A i wynik testu B, rozważ diagnozę C”,
mechanizm wnioskowania – silnik, który dopasowywał reguły do danych wejściowych i wyciągał wnioski,
moduł wyjaśniający – element szczególnie ważny dla użytkowników, pokazujący, dlaczego system podjął daną decyzję.
W teorii można było wziąć „pusty” silnik wnioskowania i zdefiniować na nim dowolną dziedzinę, dokładając tylko nowe reguły. Praktyka pokazała, że to „tylko” było najdroższą częścią projektu. Pozyskiwanie wiedzy od ekspertów wymagało dziesiątek godzin rozmów, iteracji, weryfikacji na realnych przypadkach. Co gorsza, każda zmiana w dziedzinie (nowe leki, procedury, przepisy) oznaczała kolejne rundy prac.
Przemysłowe wdrożenia i realne korzyści
Mimo wysokich kosztów, wąsko wyspecjalizowane systemy ekspertowe potrafiły dać wymierne oszczędności. Firmy używały ich m.in. do:
konfiguracji złożonych produktów (np. duże systemy komputerowe w DEC),
diagnozy usterek w sprzęcie przemysłowym,
planowania procesów technologicznych i harmonogramów.
Konfiguratory oparte na regułach pozwalały sprzedawcom składać poprawne technicznie zestawy sprzętu bez angażowania wysoko opłacanych inżynierów przy każdym zamówieniu. Z punktu widzenia firmy:
koszt jednorazowego zbudowania i utrzymania bazy reguł rozkładał się na setki czy tysiące transakcji,
redukowano liczbę błędnych konfiguracji, które później generowały reklamacje i serwis.
To już nie były zabawki akademickie, lecz narzędzia, które miały wymierny wpływ na bilans finansowy. Jednocześnie wymagały stabilnego środowiska – tam, gdzie procesy często się zmieniały, biznesowy sens takiej inwestycji szybko się rozmywał.
Granice podejścia opartego na regułach
Choć systemy ekspertowe odnosiły sukcesy, zaczęły też ujawniać fundamentalne problemy:
kruchość – system radził sobie dobrze w typowych przypadkach, ale mylił się dramatycznie przy sytuacjach nietypowych, których nie przewidziano w regułach,
skalowalność – dodawanie nowych zasad często powodowało nieprzewidziane interakcje z istniejącymi, co wymagało żmudnego testowania,
koszt utrzymania – w dynamicznych branżach aktualizacja bazy wiedzy pochłaniała coraz więcej zasobów.
Dla wielu organizacji rachunek był prosty: dopóki domena jest stosunkowo stabilna i dobrze zrozumiana, reguły AI się opłacają. Gdy zmienność rośnie, bardziej elastyczne – nawet jeśli mniej „inteligentne” – rozwiązania mogą mieć lepszy stosunek efektu do nakładu pracy.
Pierwsze podejścia do uczenia maszynowego: przed „rewolucją deep learning”
Perceptron: obietnica i rozczarowanie prostych sieci neuronowych
Równolegle do symbolicznej AI rozwijały się pierwsze próby uczenia maszynowego. Frank Rosenblatt zaproponował w latach 50. perceptron – prosty model „neuronu” uczący się klasyfikacji na podstawie przykładów. System:
otrzymywał wejścia (np. piksele obrazu lub cechy numeryczne),
mnożył je przez wagi, sumował i przepuszczał przez funkcję progową,
aktualizował wagi na podstawie błędnych klasyfikacji.
Uczenie z danych przed erą wielkich modeli
Perceptron wpisywał się w szerszy ruch: próby budowania systemów, które zamiast ręcznie kodowanej wiedzy potrafią uczyć się z przykładów. Już w latach 60. i 70. pojawiały się pytania bardzo podobne do dzisiejszych: ile danych potrzeba, jak uniknąć „przeuczenia” i jak sprawić, by model nie był tylko sprytną tabelką dopasowaną do historii.
Problem – jak zwykle – tkwił w kompromisach. Symboliczna AI dawała wyjaśnialność i kontrolę, ale była droga w utrzymaniu i źle skalowała się na zmienne środowisko. Wczesne metody uczenia maszynowego obiecywały automatyzację uczenia, lecz brakowało im mocy obliczeniowej, danych i teorii, która spinałaby to w solidny warsztat inżynierski. W efekcie wiele pomysłów trafiło do szuflady na dwie dekady, by wrócić dopiero w erze GPU i chmury.
Regresja, drzewa decyzyjne i inne „nudne” klasyki
Wiele współczesnych kursów AI zaczyna od regresji liniowej, logistycznej czy prostych drzew decyzyjnych. W latach 70. i 80. te metody nie były „AI”, tylko po prostu statystyką stosowaną lub analizą danych. Granica między AI a statystyką była ostra głównie w głowach badaczy i w nazwach katedr, nie w kodzie.
Praktycznie rzecz biorąc, w wielu zastosowaniach biznesowych ta „nudna” klasyka dawała lepszy stosunek efektu do wysiłku niż ówczesne projekty AI:
model regresyjny można było wytrenować na kalkulatorze lub prostym mainframe’ie,
procedury statystyczne miały solidne zaplecze teoretyczne,
koszt wyjaśnienia wyniku (np. wpływu danej zmiennej) był niski.
Dla inżyniera IT piszącego system scoringowy w banku czy model prognozy sprzedaży, użycie metod statystycznych było po prostu tańsze i bezpieczniejsze niż wchodzenie w „prawdziwą AI”. To też jeden z powodów, dla których wiele firm długo uważało AI za ciekawostkę akademicką, a nie narzędzie operacyjne.
Backpropagation: od „teoretycznego triku” do standardu
Jedną z kluczowych barier dla sieci neuronowych było efektywne uczenie sieci wielowarstwowych. Pojedynczy perceptron był ograniczony – Minsky i Papert formalnie pokazali, że nie rozwiąże np. problemu XOR. Samo to nie przekreślało sieci neuronowych, ale bez praktycznego algorytmu uczenia głębszych architektur nie było czego wdrażać.
Przełom teoretyczny przyniosła metoda wstecznej propagacji błędu (backpropagation), rozwijana od lat 70., a szeroko spopularyzowana przez Rumelharta, Hintona i Williamsa w latach 80. Idea była oszczędna obliczeniowo:
liczysz błąd na wyjściu sieci,
„cofasz” ten błąd przez kolejne warstwy,
aktualizujesz wagi proporcjonalnie do wkładu każdej z nich w błąd.
Z perspektywy inżyniera to przypomina sprytne wykorzystanie reguły łańcuchowej z analizy matematycznej: zamiast liczyć osobno pochodną po każdym parametrze, robisz to w jednym, zgrabnym przebiegu. Koszt obliczeniowy rośnie liniowo z liczbą wag, a nie kwadratowo czy gorzej – więc przy ówczesnym sprzęcie w ogóle istniała szansa, żeby coś sensownego policzyć.
Problem polegał na tym, że:
dane były małe i drogie (brak masowych, tanich sensorów i internetu),
sprzęt był wolny, a czas procesora kosztował realne pieniądze,
sieci o kilku warstwach szybko wpadały w problemy znikających gradientów.
W efekcie backpropagation stał się standardowym narzędziem w laboratoriach, ale rzadko prowadził do rozwiązań, które wygrywałyby z prostszymi metodami na produkcji. Z dzisiejszej perspektywy można powiedzieć, że teoria wyprzedziła infrastrukturę o dobre dwie dekady.
Uczenie ze wzmocnieniem zanim stało się modne
Jeszcze przed sukcesami systemów typu AlphaGo, istniała cała gałąź badań nad uczeniem ze wzmocnieniem (reinforcement learning). Kluczowy model był prosty i zaskakująco praktyczny: agent wykonuje akcje w środowisku, dostaje nagrody lub kary i ma maksymalizować zysk w dłuższej perspektywie.
Wczesne metody, takie jak dynamiczne programowanie Bellmana czy późniejsze algorytmy typu Q-learning, były zaskakująco przydatne do problemów, które dzisiaj wrzucilibyśmy do worka „operational research”:
planowanie tras i harmonogramów przy niepewnych czasach dostaw,
proste polityki sterowania zapasami („kiedy domawiać i ile”).
Choć w literaturze funkcjonowały jako narzędzia matematyki stosowanej lub badań operacyjnych, koncepcyjnie były to bardzo „AI-owe” przepisanie problemu: zamiast sztywnego planu, polityka reagująca na stan systemu. Przeszkodą we wdrożeniach znów był koszt:
pełne dynamiczne programowanie wymagało przeszukiwania dużych przestrzeni stanów,
symulacje uczące policyjne (policies) były czasochłonne na ówczesnych maszynach,
firmy wolały proste reguły „jeśli-then” lub polityki (s, S) z podręcznika logistycznego, bo były zrozumiałe dla menedżerów.
Rezultat: idea „agenta uczącego się przez interakcję” istniała długo przed tym, jak sprzęt i gry komputerowe dostarczyły jej idealnego poligonu doświadczalnego.
Uczenie symboliczne i indukcja reguł
Równolegle do sieci neuronowych rozwijało się uczenie symboliczne, które dziś bywa prawie zapomniane, a dla ówczesnej AI było kluczowe. Zamiast uczyć się ciągłych wag, systemy te próbowały indukować:
reguły logiczne („jeśli X i Y, to Z”),
drzewa decyzyjne opisujące klasy obiektów,
programy w prostych językach jako hipotezy wyjaśniające dane.
Przykładem są algorytmy typu ID3/C4.5, które z danych treningowych generowały drzewo pytań – w praktyce bardzo bliskie temu, co robiłby ludzki ekspert przy diagnozie. Z punktu widzenia biznesu takie podejście miało kilka zalet w stosunku do sieci neuronowych:
łatwo było przełożyć wynik na „procedurę pracy”,
można było ręcznie korygować gałęzie drzewa,
audyt i odpowiedzialność były prostsze: dało się pokazać, który warunek zadecydował.
Dla działów jakości czy compliance to był konkretny argument. Sieć neuronowa działała jak czarna skrzynka, którą trudno obronić podczas kontroli. Drzewo decyzji czy zbiór reguł dało się wydrukować, omówić na spotkaniu i poprawić ołówkiem.
Algorytmy genetyczne: optymalizacja zamiast „inteligencji”
Na przełomie lat 70. i 80. pojawił się kolejny nurt inspirowany biologicznie: algorytmy genetyczne i szerzej – ewolucyjne metody optymalizacji. Zamiast szukać „inteligencji” wprost, skupiano się na mechanizmie:
kodujemy rozwiązanie jako „chromosom” (ciąg bitów lub parametrów),
tworzymy populację losowych rozwiązań,
oceniamy ich jakość funkcją celu,
rekombinujemy i mutujemy, zachowując lepsze osobniki.
To było kuszące dla inżynierów, którzy mieli trudne problemy optymalizacyjne (projektowanie anten, szukanie parametrów sterowników, planowanie produkcji) i słabe pojęcie o pochodnych, ale za to gotową funkcję „sprawdź, jak dobre jest to rozwiązanie”.
Z punktu widzenia kosztów, algorytmy genetyczne miały dwie twarze:
małe nakłady na start – nie trzeba było modelować procesu fizycznego równaniami różniczkowymi, wystarczał symulator lub nawet realny eksperyment,
duży koszt obliczeń – każda ocena osobnika to często droga symulacja; przy dziesiątkach tysięcy ewaluacji robi się drogo.
Dlatego realne wdrożenia pojawiały się głównie tam, gdzie:
koszt pojedynczego eksperymentu był i tak ogromny (np. projektowanie elementów lotniczych), więc dodatkowe godziny CPU nie robiły różnicy,
lub gdzie można było reużyć istniejący symulator bez angażowania dodatkowych specjalistów od matematycznego modelowania.
Dzisiejsze wykorzystanie heurystyk ewolucyjnych w optymalizacji portfeli, tuningowaniu hiperparametrów czy planowaniu tras ma swoje korzenie właśnie w tej „pragmatycznej” epoce: mniej filozofii, więcej kombinowania, jak wycisnąć coś więcej z posiadanego kodu i sprzętu.
Statystyczne modele języka przed transformerami
Zanim duże modele językowe zaczęły generować kod i eseje, istniała cała tradycja statystycznego modelowania języka. W latach 80. i 90. rozwijały się modele n-gramowe, w których prawdopodobieństwo słowa zależało od kilku poprzednich słów. Taka konstrukcja była banalna w porównaniu z dzisiejszymi architekturami, ale miała kilka praktycznych zalet:
dało się ją zaimplementować na ograniczonej pamięci i mocy obliczeniowej,
trenowanie sprowadzało się głównie do liczenia częstości,
łatwo było adaptować model do nowej dziedziny, licząc statystyki na świeżym korpusie.
Modele n-gramowe napędzały pierwsze praktycznie działające systemy rozpoznawania mowy i prostego tłumaczenia maszynowego. W call center czy w systemach dyktowania tekstu zastosowanie ich było tańsze niż rozwijanie kolejnych, ręcznie modelowanych gramatyk i reguł semantycznych. Ograniczenia były oczywiste:
model nie rozumiał składni ani znaczenia,
pamięć długoterminowa była bardzo krótka (kilka słów),
kombinatoryka liczby możliwych n-gramów rosła lawinowo.
Mimo to z perspektywy firm telekomunikacyjnych czy producentów oprogramowania biurowego balans wychodził na plus: dało się uzyskać zauważalną poprawę wygody użytkownika bez wchodzenia w koszty pełnoskalowych projektów „rozumienia języka”.
Dlaczego „stare” ML nie zrobiło takiej kariery jak dzisiejsze AI
Patrząc wstecz, wczesne podejścia do uczenia maszynowego miały większość koncepcyjnych składników dzisiejszej AI: sieci neuronowe, uczenie ze wzmocnieniem, modele generatywne, optymalizację heurystyczną. Brakowały trzy rzeczy, które dzisiaj traktuje się jak powietrze:
tanie i masowe dane – bez internetu, tanich sensorów i logów z każdej interakcji użytkownika trudno było zebrać miliony przykładów,
moc obliczeniowa na żądanie – czas procesora na mainframe potrafił kosztować tyle, co dzisiaj miesięczny budżet na chmurę,
dojrzały ekosystem narzędzi – brakowało bibliotek, wizualizacji, gotowych pipeline’ów; wiele rzeczy trzeba było pisać od zera.
Efekt był taki, że w wielu projektach prostsze metody wygrywały ekonomicznie, nawet jeśli teoretycznie dawały gorsze maksimum jakości. Dla szpitala, fabryki czy banku lepszy był model, który:
da się wdrożyć w kilka miesięcy,
nie wymaga kupna nowego mainframe’a,
i można go wyjaśnić przy audycie,
niż elegancka sieć neuronowa, która zjada cały budżet obliczeniowy i wymaga zespołu doktorów do utrzymania.
Z tego powodu wiele idei AI przez lata pozostawało w fazie demonstratorów i prototypów. Dopiero gdy koszt danych, mocy i narzędzi spadł o rząd wielkości, a internet dostarczył masowych zastosowań, zasoby i wymagania wreszcie się zgrały. Warto o tym pamiętać, planując dzisiejsze projekty: moda na AI przychodzi i odchodzi, ale rachunek kosztów i efektów zawsze wraca na stół.
Najważniejsze wnioski
„Stara” AI była eksperymentem laboratoryjnym rozliczanym z publikacji, a nie z przychodu czy SLA; dzisiejsza AI to głównie produkt chmurowy, który musi skalować się tanio i przewidywalnie działać w biznesie.
Historyczne projekty AI celowały w ogólną inteligencję i wyjaśnialne rozumowanie, podczas gdy współczesne systemy skupiają się na wąskich modelach predykcyjnych zoptymalizowanych pod konkretne KPI (np. konwersję, oszczędność czasu zespołu).
Ostre ograniczenia sprzętu i danych wymusiły kiedyś podejście symboliczne (reguły, logika) zamiast uczenia na dużych zbiorach; dziś te „oszczędne” algorytmy nadal są opłacalne na słabszym sprzęcie, np. w IoT czy systemach pokładowych.
Dzisiejsze próby budowania „rozumującej jak człowiek” AI od zera często powtarzają stare błędy; bardziej realistyczny i tańszy jest podział problemu na szereg wąskich zadań i spięcie ich prostą warstwą logiki lub workflow.
Znajomość dawnych porażek (np. projektów opartych wyłącznie na regułach, które się nie skalowały) pomaga wcześniej rozpoznać nierealistyczne obietnice, a tym samym ochronić budżet przed modnymi, ale chybionymi wdrożeniami.
Historia AI pokazuje, kiedy brak danych można częściowo zastąpić wiedzą ekspercką zakodowaną w regułach i kiedy takie podejście generuje tylko dług techniczny i kosztowne przebudowy przy zmianie zakresu problemu.
