Sztuczna inteligencja kiedyś i dziś: od perceptronu do boomu na modele generatywne

Po co wracać do historii sztucznej inteligencji

Sztuczna inteligencja kiedyś i dziś wygląda jak dwa różne światy: od prostego perceptronu Rosenblatta do gigantycznych modeli generatywnych liczących miliardy parametrów. Ciągłość między tymi etapami ujawnia się dopiero wtedy, gdy spojrzy się na całą historię – razem z jej modami, rozczarowaniami i „zimami AI”. Dla kogoś, kto dziś ma podejmować decyzje o inwestycjach w AI, znajomość tej ścieżki to nie ciekawostka, ale bardzo praktyczne narzędzie do oceny ryzyka i opłacalności.

Powtarzają się te same wzorce: nadmierne obietnice, entuzjazm, gwałtowny napływ pieniędzy, a potem korekta i cięcia. Różne epoki – perceptron, systemy eksperckie, klasyczne uczenie maszynowe, deep learning i modele generatywne – różni technologia, ale podobne są błędy decydentów. Świadomość tych mechanizmów pomaga nie przepalać budżetu na efektowne, ale niekoniecznie efektywne projekty AI.

Skąd się wzięła sztuczna inteligencja: korzenie idei i pierwsze definicje

Marzenia o maszynach myślących przed komputerami

Myśl o „sztucznej inteligencji” pojawiła się na długo przed tym, jak ktokolwiek zbudował komputer. Już w XIX wieku Charles Babbage projektował maszynę analityczną, a Ada Lovelace zastanawiała się, czy maszyna może robić coś więcej niż tylko liczyć. W filozofii od dawna istniały pytania o naturę myślenia, świadomości i możliwość ich mechanicznego odtworzenia.

Ważnym krokiem były automaty i maszyny liczące. Mechaniczne „zabawki” udające ludzi – jak słynny „Turek” – pokazywały, jak mocno pociąga wyobraźnię wizja inteligentnej maszyny. Później, w pierwszej połowie XX wieku, logicy tacy jak Kurt Gödel czy Alonzo Church badając naturę dowodzenia matematycznego, zbliżali się do pytania: co właściwie mogą zrobić formalne systemy i procedury obliczeniowe?

Przełomowym momentem był artykuł Alana Turinga z 1950 roku „Computing Machinery and Intelligence”, w którym zaproponował on test Turinga. Zamiast abstrakcyjnie pytać, czy maszyna może myśleć, proponował praktyczne kryterium: jeśli w rozmowie tekstowej człowiek nie jest w stanie odróżnić maszyny od człowieka, można mówić o inteligentnym zachowaniu. To myślenie nastawione na obserwowalne efekty, a nie na metafizykę, mocno wpłynęło na późniejszą sztuczną inteligencję.

Automatyka a sztuczna inteligencja w latach 50.

W latach 40. i 50. rozwijała się intensywnie automatyka: systemy sterowania, sprzężenia zwrotne, regulatory. Maszyny umiały już coś „robić same”: utrzymywać temperaturę, stabilizować lot, sterować produkcją. Jednak to wciąż było traktowane jako zaawansowana inżynieria, a nie inteligencja.

Różnica polegała na stopniu elastyczności i ogólności. Automatyka była projektowana do bardzo konkretnego zadania i działała na bazie z góry znanych parametrów. Sztuczna inteligencja miała ambicję pójść dalej: tworzyć systemy zdolne do:

• uczenia się na nowych danych, zamiast ręcznego programowania każdego przypadku,
• wyciągania wniosków i uogólnień,
• radzenia sobie z niepewnością i niekompletnością informacji,
• rozwiązywania problemów z różnych dziedzin, nie tylko jednego wąskiego zastosowania.

W praktyce możliwości techniczne były bardzo ograniczone. Komputery były ogromne, drogie, z minimalną pamięcią i mocą obliczeniową według dzisiejszych standardów. Mimo to grupa naukowców uznała, że czas przestać mówić tylko o teoretycznych możliwościach maszyn i spróbować faktycznie budować systemy „inteligentne”.

Konferencja w Dartmouth i narodziny terminu „AI”

Latem 1956 roku na Dartmouth College w USA odbyło się spotkanie, które często uważa się za symboliczny start dziedziny sztucznej inteligencji. John McCarthy, Marvin Minsky, Nathaniel Rochester i Claude Shannon zorganizowali dwumiesięczny projekt badawczy, na który zaprosili kilkunastu badaczy. To tam po raz pierwszy oficjalnie użyto terminu „artificial intelligence”.

Plan był ambitny. W propozycji projektu zapisano, że postęp w badaniach nad inteligencją maszynową może doprowadzić do tego, że „każdy aspekt uczenia się czy jakiejkolwiek innej cechy inteligencji można zasadniczo opisać tak precyzyjnie, że maszynę będzie można programuć, aby go symulowała”. Uczestnicy byli przekonani, że kilkanaście lat intensywnych prac wystarczy, by osiągnąć bardzo wysoki poziom automatyzacji rozumowania.

Pierwsze definicje AI miały charakter mocno symboliczny. Inteligencja była postrzegana jako manipulacja symbolami – faktami, regułami, twierdzeniami – zgodnie z zasadami logiki. W tym myśleniu dominowały:

• logika formalna jako narzędzie wnioskowania,
• reprezentacje wiedzy w postaci symboli i reguł,
• rozwiązywanie problemów przez przeszukiwanie przestrzeni stanów.

Trzeba jednak pamiętać o kontekście technologicznym. Komputery były wtedy dobrami luksusowymi – dostęp do nich mieli tylko nieliczni badacze w ośrodkach akademickich i wojskowych. Każda godzina obliczeniowa kosztowała równie dużo, co dziś wielodniowa praca chmury obliczeniowej. Przy takim tle entuzjazm i przekonanie, że „za chwilę” zbudujemy maszyny myślące tak jak ludzie, miały w sobie sporo naiwności, ale też odwagi.

Epoka perceptronu: prosty model, wielkie nadzieje

Jak działał perceptron i co obiecywał

W końcówce lat 50. Frank Rosenblatt zaproponował model, który do dziś pojawia się w pierwszych rozdziałach podręczników uczenia maszynowego: perceptron. Idea była zaskakująco prosta. Perceptron to pojedynczy „neuron” obliczający ważoną sumę wejść, a następnie stosujący prostą funkcję progową, która decyduje o wyjściu (0 lub 1).

Niezwykłe było to, że perceptron można było uczyć. Wagi przy wejściach nie były z góry ustalone, ale modyfikowane na podstawie błędów popełnianych na przykładach treningowych. Jeśli perceptron się mylił, wagi korygowano w stronę poprawnego wyniku. Ten mechanizm wydawał się pierwszym praktycznym sposobem, by maszyna „uczyła się z doświadczenia”, zamiast być ręcznie programowana przypadek po przypadku.

Rosenblatt pracował m.in. nad rozpoznawaniem prostych wzorców na obrazach. Perceptron miał rozpoznawać np. czy na obrazie znajduje się pewien rodzaj figury. Jak na możliwości sprzętowe epoki, działanie było imponujące. Szybko pojawiły się nagłówki prasowe sugerujące, że perceptron to początek maszyn rozpoznających mowę, obrazy, a nawet podejmujących złożone decyzje. Oczekiwania zaczęły rosnąć szybciej niż możliwość realnych wdrożeń.

Głośne obietnice i chłodna rzeczywistość

Perceptron był przełomowy z kilku powodów:

• używał danych zamiast ręcznie pisanych reguł,
• był w miarę prosty matematycznie,
• dawał spektakularne jak na swoje czasy demonstracje rozpoznawania wzorców.

To wystarczyło, by media i niektórzy naukowcy zaczęli prognozować szybki marsz w stronę ogólnej inteligencji maszyn. Problem w tym, że perceptron miał poważne ograniczenia. Matematycznie potrafił rozdzielać tylko liniowo separowalne dane. Jeśli granica między klasami nie dawała się opisać jedną linią (hiperpłaszczyzną), perceptron nie był w stanie zbudować poprawnego klasyfikatora, niezależnie od ilości danych treningowych.

Dobrym symbolem tych ograniczeń stał się problem XOR – funkcji logicznej, której perceptron nie potrafi się nauczyć, ponieważ wymaga nieliniowego rozdzielenia przestrzeni wejść. Dziś to szkolny przykład, ale w tamtym czasie uderzyło to w sam fundament optymizmu związanego z perceptronami. Obietnice dotyczyły ogólnych zdolności rozpoznawczych, a okazało się, że nawet względnie proste zależności mogą być dla tego modelu nieosiągalne.

Do tego dochodził koszt. Sprzęt był drogi, dostępność komputerów ograniczona, a budowa fizycznych perceptronów (Rosenblatt tworzył także wersje sprzętowe) pochłaniała znaczne zasoby. Gdy pierwsze zachwyty minęły, inwestorzy zaczęli pytać o twarde wyniki: dokładność, skalowalność, porównanie z innymi rozwiązaniami. Tu perceptron przegrywał z bardziej tradycyjnymi, symbolicznymi metodami dla wielu typów problemów.

Minsky, Papert i pierwszy poważny zgrzyt

W 1969 roku Marvin Minsky i Seymour Papert opublikowali książkę „Perceptrons”, w której szczegółowo przeanalizowali matematyczne ograniczenia perceptronów. Wykazali, że jednopoziomowe sieci tego typu nie są w stanie rozwiązać wielu istotnych problemów, jeśli dane nie dają się liniowo oddzielić. Co więcej, zasugerowali, że dodawanie kolejnych warstw nie jest wcale oczywistą drogą do sukcesu – brakowało wtedy skutecznych algorytmów ich trenowania.

Książka była rzetelna naukowo, ale jej odbiór społeczny poszedł dalej niż intencje autorów. W środowisku i w oczach decydentów finansujących badania zaczęło dominować przekonanie, że sieci neuronowe to ślepa uliczka. W efekcie wiele projektów bazujących na perceptronach i pokrewnych ideach zaczęło tracić finansowanie. Uwaga przeniosła się z powrotem w stronę logiki, reguł i rozumowania symbolicznego.

Z dzisiejszej perspektywy widać, że problem nie leżał w koncepcji sieci neuronowych jako takich, tylko w:

• braku wystarczająco głębokich sieci,
• niewystarczającej mocy obliczeniowej,
• niedojrzałych jeszcze algorytmach uczenia.

To jednak niewiele pomagało tym, którzy w latach 60. i na początku 70. musieli uzasadniać wydatki na badania. Przekaz był prosty: „sieci neuronowe nie dowiozły, wracamy do metod symbolicznych”. Pierwszy raz na dużą skalę okazało się, że hype wokół konkretnej technologii AI może bardzo szybko zamienić się w chłód i cięcia budżetowe, gdy wyniki nie nadążają za obietnicami.

Koszt kontra efekt – pierwsze ostrzeżenie dla inwestorów

Historia perceptronu pokazuje klasyczny błąd decyzyjny: inwestowanie w technologię głównie dlatego, że jest „nowa i obiecująca”, bez chłodnej kalkulacji stosunku efektów do ponoszonych kosztów. W epoce perceptronu wiele projektów badawczych było finansowanych bardziej na fali entuzjazmu niż na bazie twardych wskaźników.

Patrząc na to z dzisiejszej perspektywy, można wyciągnąć kilka praktycznych wniosków przy planowaniu współczesnych projektów opartych na AI:

• najpierw dowody na małej skali (prototyp, pilotaż), dopiero potem większe inwestycje,
• realistyczne porównywanie z prostszymi alternatywami – czasem klasyczne statystyki dają 90% efektu za 10% kosztu,
• unikanie wiązania całej strategii firmy z jedną technologią, o której skuteczności decyduje jeszcze wiele niewiadomych.

Ten sam wzorzec przesadnego optymizmu widać później w systemach eksperckich, a obecnie w części narracji wokół dużych modeli językowych i generatywnych. Świadomość, jak skończyły wcześniejsze fale entuzjazmu, pomaga twardo negocjować zakres i tempo wdrażania AI we własnej organizacji.

Symboliczne AI i pierwsza „zima AI”: od euforii do cięć budżetowych

Systemy eksperckie jako gwiazda lat 70. i 80.

Gdy sieci neuronowe straciły na atrakcyjności, centrum uwagi zajęły podejścia symboliczne – zwłaszcza systemy eksperckie. Ich idea była intuicyjnie zrozumiała dla menedżerów: zamiast uczyć model na danych, „wlewamy” do systemu wiedzę ekspertów w postaci reguł „jeśli–to”. System ma później zachowywać się podobnie jak człowiek-specjalista w danej dziedzinie.

Przykłady z tamtego okresu:

• systemy diagnozujące choroby na podstawie objawów (medycyna),
• narzędzia wspierające diagnozę usterek w złożonych urządzeniach (diagnostyka techniczna),
• systemy pomagające w interpretacji przepisów czy doradztwie podatkowym (prawo, finanse).

W praktyce budowa systemu eksperckiego wyglądała tak, że zespół tzw. inżynierów wiedzy przez miesiące, a czasem lata, „wyciągał” z ekspertów ich wiedzę i przekładał ją na formalne reguły. Powstawały ogromne bazy tysiąca i więcej reguł, które silnik wnioskowania łączył i wykorzystywał do diagnoz czy rekomendacji.

Systemy eksperckie dawały efektowny efekt „wow”: komputer odpowiadał na pytania jak lekarz czy inżynier. Dla części organizacji był to również realny zysk – na przykład tam, gdzie ekspertów było mało, a potrzeba wiedzy szeroka (diagnostyka w rozproszonych zakładach przemysłowych). Jednak szybko wyszły na jaw koszty i problemy skalowalności.

Ograniczenia: kruchość i wysokie koszty utrzymania

Dlaczego reguły nie wystarczyły

Systemy eksperckie ujawniły fundamentalny problem: świat rzadko mieści się w prostych regułach. Działy świetnie tam, gdzie dało się zapisać wiedzę w miarę stabilnie, np. diagnostyka konkretnych usterek w maszynach o znanej konstrukcji. Gdy jednak rzeczywistość się zmieniała – pojawiały się nowe choroby, modyfikacje sprzętu, nowe przepisy – reguły trzeba było ciągle aktualizować.

Każda zmiana pociągała za sobą efekt domina. Dodanie jednej reguły potrafiło wywołać nieoczekiwane konsekwencje w innym miejscu systemu. Pojawiały się sprzeczności, które trudno było zlokalizować. W dużych instalacjach samo utrzymanie spójności bazy wiedzy stawało się projektem na pełen etat dla kilku osób.

Do tego dochodziła kruchość zachowania. Systemy eksperckie były dobre w wąskich, dobrze zdefiniowanych zakresach. Gdy użytkownik zadawał pytanie „z boku” – wykraczające poza przewidziane reguły – odpowiedzi bywały absurdalne albo system po prostu zwracał błąd. Ludzkiego eksperta można zapytać o analogię, poprosić o intuicyjne wyjaśnienie; system ekspercki nie miał takiej elastyczności.

Ekonomia systemów eksperckich: kiedy to się opłacało

Z perspektywy budżetu systemy eksperckie były sensowne tylko w kilku scenariuszach:

• gdy koszt błędu był wysoki (np. błędna diagnoza w energetyce) i nawet częściowa automatyzacja dawała realne oszczędności,
• gdy ekspertów było bardzo mało, a organizacja miała wiele lokalizacji (np. utrzymanie specjalistycznych linii produkcyjnych),
• gdy dziedzina zmieniała się wolno, więc raz zebrana i zakodowana wiedza wystarczała na lata.

W każdym innym przypadku rachunek ekonomiczny był surowy. Lata pracy inżynierów wiedzy, długie wywiady z ekspertami, testy, poprawki – to wszystko sprawiało, że pełnowartościowy system ekspercki kosztował tyle, co zespół dobrych specjalistów przez dłuższy czas. Jeśli dodatkowo trzeba było potem zatrudniać kolejnych ludzi tylko po to, by system konserwować, entuzjazm działu finansów gasł.

Dzisiejszym odpowiednikiem tego błędu jest próba „zaprogramowania” dużych modeli za pomocą ogromnych promptów i ręcznie tworzonych reguł na warstwie aplikacji. Często taniej i szybciej jest ograniczyć zakres problemu albo połączyć prostsze modele z procedurami biznesowymi, niż budować jeden „wszechwiedzący” system.

Pierwsza „zima AI”: gdy oczekiwania zderzyły się z budżetem

Na przełomie lat 80. i 90. było już jasne, że obietnice AI – zarówno sieci neuronowych, jak i systemów eksperckich – nie przekładają się na szerokie zastosowania przemysłowe. Raporty rządowe i wewnętrzne audyty w firmach wykazywały podobny wzorzec: koszty wdrożeń rosną, korzyści są lokalne i ograniczone. Pojawiły się krytyczne publikacje wskazujące, że pojęcie „sztucznej inteligencji” stało się marketingową etykietą, pod którą kryją się zwykłe programy z dodatkowymi warstwami złożoności.

Efekt był przewidywalny: budżety zaczęły topnieć. Mniej grantów badawczych, mniej dużych programów narodowych, mniejsze zainteresowanie przemysłu. Terminem, który zrobił karierę, była właśnie „zima AI” – okres chłodu inwestycyjnego i wstrzemięźliwości wobec spektakularnych zapowiedzi.

Dla praktyków z tamtego okresu była to lekcja, że sama etykieta „AI” nie chroni przed cięciami. Projekty bronią się jak każde inne: wskaźnikami, prostotą utrzymania i przewidywalnością rezultatów. Podobny mechanizm można dziś obserwować przy projektach generatywnych: po fali pilotaży przychodzi etap porównań z tańszymi rozwiązaniami i krytycznych przeglądów portfela inicjatyw.

Od perceptronu do wielowarstwowych sieci: rewolucja w uczeniu reprezentacji

Pierwsze sygnały, że głębia ma znaczenie

W cieniu systemów eksperckich i pierwszej zimy AI powstawały prace, które później okażą się fundamentem dzisiejszego boomu. Kluczowa idea była prosta, ale trudna do zrealizowania: zamiast jednego poziomu perceptronów, użyjmy wielu warstw. Każda z nich ma przekształcać dane w coraz bardziej abstrakcyjne reprezentacje.

Intuicyjnie można to porównać do rozpoznawania obrazu: najpierw wykrywamy krawędzie, potem proste kształty, później części obiektów, a na końcu całe obiekty. Pojedynczy perceptron nie umie tego zrobić; wielowarstwowa sieć – potencjalnie tak. Problem polegał na tym, jak taką sieć skutecznie uczyć, by błędy z wyjścia wpływały na wszystkie warstwy pośrednie.

Algorytm wstecznej propagacji błędu

Przełomem teoretyczno-praktycznym okazał się algorytm backpropagation (wstecznej propagacji błędu), popularyzowany w latach 80. m.in. przez Davida Rumelharta, Geoffreya Hintona i Ronalda Williamsa. Idea: błąd na wyjściu sieci jest „rozprowadzany wstecz” przez poszczególne warstwy, a każda waga jest korygowana proporcjonalnie do swojego udziału w tym błędzie.

Matematycznie opiera się to na regule łańcuchowej z rachunku różniczkowego, ale z punktu widzenia praktyka kluczowe były inne fakty:

• dało się uczyć wiele warstw naraz,
• uczenie wciąż było kosztowne, ale skalowało się lepiej niż ręczne projektowanie cech,
• siec mogła się uczyć z danych złożonych, nieliniowych zależności, z którymi perceptron sobie nie radził.

Pierwsze demonstracje pokazywały np. rozpoznawanie mowy na małych słownikach, proste zadania wizji komputerowej czy prognozowanie szeregów czasowych. Nadal były to zabawki w porównaniu z potrzebami przemysłu, ale potencjał był wyraźny: zamiast projektować cechy ręcznie, można pozwolić sieci samej je „wynajdywać” w danych.

Uczenie reprezentacji kontra ręczne cechy

W latach 80. i 90. duża część pracy nad AI polegała na wymyślaniu dobrych reprezentacji problemu: który zestaw wskaźników opisuje klienta, jaka transformacja obrazu ułatwia rozpoznanie, jakie cechy dźwięku są najbardziej informatywne. Nawet w statystyce klasycznej wybór zmiennych i inżynieria cech pochłaniały większość czasu.

Wielowarstwowe sieci neuronowe zmieniły to podejście. Celem stało się uczenie reprezentacji: takie ustawienie wag, żeby pośrednie warstwy automatycznie wydobywały z danych informację potrzebną do zadania. Dla organizacji oznaczało to teoretycznie mniej pracy ręcznej i większą skalowalność – jeśli tylko dało się znieść koszt trenowania i ryzyko przeuczenia.

W praktyce długo brakowało warunków, by ta wizja się upowszechniła. Komputery były zbyt wolne, a zbiory danych zbyt małe, by głębokie sieci pokazały przewagę nad sprytnie zaprojektowanymi modelami płytkimi. Wiele zespołów wracało więc do prostszych metod, bo dawały one lepszy stosunek jakości do kosztu obliczeń.

Sieci konwolucyjne, rekurencyjne i pierwsze „głębokie” sukcesy

Mimo ograniczeń sprzętowych pojawiały się projekty, które pokazywały, jak ogromny potencjał ma odpowiednia architektura sieci:

• sieci konwolucyjne (CNN), rozwijane m.in. przez Yanna LeCuna, sprawdzały się świetnie w rozpoznawaniu ręcznie pisanych cyfr (systemy czytania czeków, kodów pocztowych),
• sieci rekurencyjne (RNN), a później ich warianty takie jak LSTM, zaczęto stosować do analizy sekwencji: tekstu, mowy, szeregów czasowych.

Te zastosowania były jednak wąskie, często pilotowe, a ich wdrożenia wymagały zespołów z silnym zapleczem akademickim. Dla przeciętnej firmy pozostawały raczej ciekawostką niż realną opcją – za wysokie koszty wejścia, za mało gotowych narzędzi.

W większości biznesowych projektów dominowały prostsze algorytmy: regresja logistyczna, drzewa decyzyjne, SVM. Były tańsze w trenowaniu, łatwiejsze do interpretacji i wystarczająco dobre dla wielu zastosowań predykcyjnych. Głębokie sieci pozostawały w niszy, czekając na swój moment.

Druga „zima” i ciche przygotowania do przełomu: dane, GPU i Internet

Rozczarowanie latami 90.: AI jako zwykłe oprogramowanie

Po pierwszej zimie AI nastąpił okres, gdy termin „sztuczna inteligencja” bywał wręcz unikany w dokumentach projektowych. Łatwiej było przeforsować budżet na „zaawansowaną analitykę” czy „system wspomagania decyzji” niż na „AI”, kojarzącą się z niedotrzymanymi obietnicami.

Badania nad sieciami neuronowymi trwały, ale zainteresowanie mediów i inwestorów przeszło gdzie indziej: do Internetu, baz danych, ERP, systemów CRM. W tych obszarach można było pokazać szybkie, namacalne efekty: lepsza logistyka, automatyzacja faktur, szybsza komunikacja. AI wydawała się przy tym zbyt ryzykowna.

Druga „zima” nie była tak głęboka jak pierwsza, ale miała podobny charakter: mało głośnych wdrożeń, ograniczone finansowanie, nacisk na praktyczne, wąskie rozwiązania. Z perspektywy późniejszych przełomów był to jednak czas cichego gromadzenia trzech zasobów, bez których dzisiejsze modele generatywne nie miałyby szans.

Eksplozja danych: od braków do przesytu

W latach 60. czy 70. brakowało nie tylko mocy obliczeniowej, ale i danych. Zebranie tysięcy oznaczonych przykładów było drogim projektem samym w sobie. Z czasem sytuacja odwróciła się radykalnie. Masowe komputery osobiste, systemy transakcyjne, a potem Internet i smartfony sprawiły, że dane zaczęły powstawać przy okazji zwykłych operacji biznesowych.

Rejestracje użytkowników, logi kliknięć, dane z czujników, historia zamówień – wszystko to gromadzono najpierw jako „produkt uboczny”, głównie ze względów księgowych i compliance. Dopiero później zaczęło się pojawiać pytanie: co z tym zrobić, żeby zarobić więcej lub zaoszczędzić.

To właśnie te masywne zbiory danych otworzyły drzwi dla głębokiego uczenia. Modele, które wcześniej przeuczały się na małych zestawach, nagle miały do dyspozycji miliony przykładów. Dla wielu zadań problemem przestał być brak danych – stało się nim sensowne ich wykorzystanie i opłacalny proces trenowania modeli.

GPU: sprzęt od gier, który zmienił AI

Drugi kluczowy czynnik to grafiki GPU. Początkowo powstawały po to, by przyspieszać renderowanie grafiki 3D w grach i aplikacjach multimedialnych. W pewnym momencie badacze zauważyli, że architektura GPU – ogromna liczba prostych jednostek wykonujących podobne operacje równolegle – idealnie pasuje do obliczeń w sieciach neuronowych.

Mnożenia macierzy, które na CPU trwałyby wieki, na GPU mogły być wykonywane tysiące razy szybciej. To właśnie umożliwiło trenowanie głębokich sieci na realistycznych zbiorach danych w rozsądnym czasie. Co ważne z perspektywy budżetu, GPU były rozwijane na masową skalę dla rynku gier, więc ich cena za jednostkę mocy obliczeniowej spadała znacznie szybciej niż w sprzęcie niszowym.

Dla firm oznaczało to nowy dylemat: inwestować w specjalistyczny sprzęt GPU czy czekać na usługi chmurowe, które pozwolą „wynająć” moc na godziny. Wiele organizacji, które zbyt wcześnie kupiły drogie klastry, doświadczyło szybkiej dewaluacji inwestycji, gdy usługi chmurowe stały się tańsze i elastyczniejsze. Z kolei ci, którzy zbyt długo czekali, tracili przewagę konkurencyjną na polu personalizacji ofert czy automatyzacji procesów.

Internet jako dostawca treści i użytkowników

Trzecim składnikiem nadchodzącej rewolucji był Internet jako źródło treści i interakcji. Strony WWW, fora, maile, portale informacyjne, później media społecznościowe – to wszystko stało się gigantycznym zbiorem tekstów, obrazów, dźwięków i filmów.

Modele językowe i wizji komputerowej potrzebują nie tylko ilości, ale też różnorodności danych. Internet dostarczył obu: tekstów pisanych przez ludzi o różnym stylu, obrazów z najróżniejszych kontekstów, nagrań mowy w wielu językach i akcentach. Co ważne, wiele z tych danych powstawało z naturalnych interakcji użytkowników, a nie w sztucznych warunkach laboratoryjnych.

To przygotowało grunt pod dzisiejsze modele generatywne, które uczą się na masowych korpusach tekstu, kodu i mediów. Dla firm praktyczne pytanie nie brzmiało już „czy mamy jakieś dane?”, ale „jak je oczyścić, oznaczyć i wykorzystać tak, żeby nie złamać prawa i jednocześnie maksymalizować zwrot z inwestycji”.

Cicha ewolucja narzędzi: od bibliotek akademickich do frameworków produkcyjnych

Od Matlabów do Pythona: dojrzewanie ekosystemu

Na przełomie wieków wiele rozwiązań AI powstawało w środowiskach typowo akademickich: Matlab, specjalistyczne biblioteki w C/C++, własne skrypty pisane pod konkretny eksperyment. Każdy zespół miał swój „warsztat”, często mało przenośny i słabo udokumentowany. Przeniesienie takiego kodu z laboratorium do produkcji bywało droższe niż ponowne napisanie systemu.

Kluczową zmianą było ujednolicenie stosu technologicznego. Python, dzięki prostocie i bogatemu ekosystemowi (NumPy, SciPy, później Pandas), stał się wspólnym językiem dla badaczy i inżynierów. Zamiast pisać prototyp w Matlabie, a wersję produkcyjną w Javie czy C++, coraz częściej robiło się wszystko w jednym środowisku.

To obniżyło koszty integracji: mniej mostków między systemami, mniej konwersji formatów, mniej „tajemnej wiedzy” zamkniętej w głowach pojedynczych badaczy. Kto znał Pythona i podstawy statystyki, mógł w rozsądnym czasie przejść od notatnika Jupyter do prostego API udostępniającego model.

Frameworki głębokiego uczenia: od własnych implementacji do gotowych narzędzi

Kolejnym krokiem były wyspecjalizowane frameworki do sieci neuronowych. Wcześniej wiele zespołów implementowało backpropagation samodzielnie. Błędy numeryczne, nieoptymalne wykorzystanie pamięci GPU czy brak wsparcia dla różnych architektur powodowały, że nawet proste eksperymenty były czasochłonne.

Pojawienie się bibliotek takich jak Theano, a potem TensorFlow, PyTorch czy Keras, zmieniło zasady gry. Nagle kluczowe operacje – od mnożenia macierzy po automatyczne wyliczanie gradientów – zostały zamknięte w zoptymalizowanych prymitywach. Zamiast debugować równania na tablicy, można było skoncentrować się na:

• doborze architektury,
• strategii przygotowania danych,
• kontroli procesu trenowania i walidacji.

Dla firm oznaczało to spadek bariery wejścia. Zamiast budować całe zaplecze techniczne od zera, wystarczyło skorzystać z gotowego frameworka i ewentualnie napisać kilka warstw specyficznych dla domeny. Koszt pierwszego prototypu spadł z miesięcy pracy do tygodni, a czasem dni.

Jednocześnie pojawił się nowy problem: nadmierne zaufanie do „magicznych” bibliotek. Łatwo było zbudować model, który działa na walidacji, ale kompletnie zawodzi po wdrożeniu. Brak zrozumienia, jak framework zarządza pamięcią, jak implementuje optymalizatory czy jak radzi sobie z niestabilnościami numerycznymi, generował trudne do zdiagnozowania błędy produkcyjne.

MLOps zanim stało się modne

Zanim powstało modne hasło „MLOps”, firmy zmagające się z pierwszymi produkcyjnymi wdrożeniami uczenia maszynowego musiały rozwiązać bardzo przyziemne problemy:

• jak wersjonować modele i zbiory danych,
• jak monitorować ich działanie w czasie,
• jak powtarzalnie trenować i wdrażać nową wersję bez ręcznej orkiestracji.

Najtańszym rozwiązaniem często okazywała się adaptacja istniejących procesów DevOps: Git do wersjonowania, Jenkins lub inny system CI/CD do budowania pipeline’ów, proste logowanie metryk do relacyjnej bazy lub systemu typu Prometheus. Zamiast od razu inwestować w drogie platformy „end-to-end AI”, rozsądniej było zbudować kilka lekkich narzędzi sklejonych skryptami.

Prosty, ale realny scenariusz: zespół analityczny trenował model rekomendacji raz w tygodniu, a zestaw skryptów w Cronie pobierał dane, uruchamiał trening na GPU, zapisywał wynikowy model na serwerze plików i aktualizował endpoint w API. Działało to daleko od idealnego standardu „enterprise”, lecz kosztowało ułamek ceny komercyjnej platformy i wystarczało, dopóki wolumeny użytkowników nie urosły.

Głębokie uczenie wychodzi z niszy: ImageNet i przełom jakości

Kumulacja danych, mocy obliczeniowej i dojrzewającego ekosystemu narzędzi doprowadziła do pierwszych głośnych sukcesów głębokiego uczenia na dużą skalę. Symbolem był konkurs ImageNet – ogromny zbiór obrazów oznaczonych etykietami klas.

Gdy w 2012 roku zespół Alexa Krizhevsky’ego, Ilyi Sutskevera i Geoffa Hinton’a użył głębokiej sieci konwolucyjnej na GPU, wyniki przebiły dotychczasowe podejścia o zauważalny margines. To nie była już subtelna poprawa o promil, ale skok jakości, który ciężko było zignorować.

Dla praktyków ważne było coś jeszcze: architektura była publicznie opisana, kod – przynajmniej w zarysie – dostępny, a sprzęt, choć nie tani, mieścił się w budżecie średniej firmy technologicznej. Nagle stało się jasne, że nie mówimy o zabawkach z laboratoriów, lecz o technice, którą można przenieść do realnych zadań:

• automatyczne kategoryzowanie zdjęć produktów,
• wykrywanie wad na liniach produkcyjnych,
• analiza dokumentów skanowanych (faktury, umowy).

Jednocześnie pojawiła się presja: skoro „wszyscy” zaczynają coś robić z deep learningiem, to brak przynajmniej eksperymentów zaczynał wyglądać jak zaniedbanie. Firmy musiały jednak znaleźć balans między wyścigiem zbrojeń a zdrowym rachunkiem kosztów – nie każdy problem opłacało się rozwiązywać najcięższym działałem.

Sukcesy w mowie i tłumaczeniu: sygnał, że tekst też jest do ruszenia

Wizja komputerowa była pierwszą dziedziną, w której głębokie sieci spektakularnie przebiły klasyczne metody. Kolejna była mowa. Modele akustyczne oparte na DNN zaczęły zastępować układy GMM-HMM, a jakość rozpoznawania mowy w systemach komercyjnych (asystenci głosowi, call center, dyktowanie tekstu) zauważalnie się poprawiła.

Tu również przewagę dawała skala. Duże firmy technologiczne dysponowały ogromnymi zbiorami nagrań rozmów i transkrypcji. Małe organizacje, które nie miały własnych danych, sięgały po gotowe API do rozpoznawania mowy zamiast trenować własne modele. Ekonomicznie często było to rozsądniejsze: płaciło się za użycie, bez inwestycji w dane i infrastrukturę.

W tłumaczeniu maszynowym najpierw modele oparte na RNN i LSTM, a później architektury z mechanizmem uwagi (attention), znacząco przewyższyły klasyczne systemy statystyczne. Koszt eksperymentów spadał, bo dostępne były otwarte korpusy równoległe (np. teksty UE, dokumentacja open source), a hardware stawał się coraz tańszy w chmurze.

Na tym tle zaczęło być widać, że tekst jako taki – nie tylko w roli wejścia do systemu tłumaczeń – może być modelowany na dużo wyższym poziomie niż dotychczasowe n-gramy czy klasyczne modele językowe. To otwierało drogę do kolejnego etapu: modeli, które nie tylko klasyfikują lub tłumaczą, ale generują treść.

Od modeli dyskryminacyjnych do generatywnych: zmiana paradygmatu

Modele, które tylko klasyfikują, kontra modele, które tworzą

Przez długi czas większość praktycznych zastosowań uczenia maszynowego miała charakter dyskryminacyjny: dany jest opis, a zadaniem modelu jest przypisanie etykiety lub liczby. Czy klient kliknie reklamę? Czy transakcja jest fraudem? Jaką kategorię ma produkt?

Modele generatywne działają inaczej. Uczą się rozkładu danych: tego, jakie konfiguracje są „typowe”, a jakie nietypowe. Dzięki temu potrafią nie tylko klasyfikować, ale również tworzyć nowe przykłady, które wyglądają jak pochodzące z tego samego świata. W praktyce oznacza to:

• generowanie realistycznych obrazów,
• pisanie tekstów w danym stylu,
• tworzenie nowych próbek muzyki czy mowy.

Różnica z punktu widzenia biznesu jest zasadnicza. W klasycznych projektach pytanie brzmiało: „czy model poprawi wskaźnik X o kilka punktów procentowych?”. W przypadku modeli generatywnych pojawiła się możliwość całkowicie nowych produktów: kreatorów treści, automatycznych asystentów, systemów projektujących warianty produktów czy kampanii.

Autoenkodery i wariacyjne autoenkodery: pierwsze kroki w stronę generowania

Przed rozkwitem dzisiejszych modeli generatywnych istotną rolę odegrały autoenkodery. To sieci, które uczą się kompresować dane do wewnętrznej, zwięzłej reprezentacji, a następnie odtwarzać je z powrotem. Początkowo używano ich głównie do redukcji wymiarowości i detekcji anomalii.

Kiedy pojawiły się wariacyjne autoenkodery (VAE), kompresja przestała być tylko narzędziem do analiz. Zmienna ukryta, z której odtwarzano dane, miała określony rozkład probabilistyczny. Można było z niej losować i generować nowe próbki – obrazy, dźwięki, inne dane.

VAE były atrakcyjne z kilku powodów praktycznych:

• miały stosunkowo stabilne trenowanie w porównaniu z pierwszymi GAN-ami,
• umożliwiały „przemieszczanie się” po przestrzeni cech (np. płynne przejście między dwoma obrazami),
• dobrze nadawały się do małych i średnich projektów badawczych.

Dla wielu zespołów stanowiły tanią piaskownicę: można było na nich zrozumieć, jak działa reprezentacja ukryta i generowanie danych, bez konieczności inwestowania w ogromne klastry GPU. Sprawdzały się w zadaniach takich jak generowanie wariantów projektów graficznych, augmentacja danych czy kompresja sygnału.

Generative Adversarial Networks (GAN): kreatywna rywalizacja sieci

Pojawienie się GAN-ów było kolejnym krokiem. Idea rywalizacji dwóch sieci – generatora i dyskryminatora – pozwoliła osiągnąć zaskakująco dobre efekty w generowaniu obrazów i innych danych. Obrazy tworzone przez dobrze wytrenowane GAN-y zaczęły przypominać fotografie, a nie tylko rozmyte szkice.

Z perspektywy organizacji kluczowe były dwie rzeczy:

• możliwość generowania syntetycznych danych dla zadań, w których pozyskanie realnych przykładów było kosztowne (np. rzadkie defekty, rzadkie choroby),
• zastosowania kreatywne: style transfer w marketingu, generowanie wariantów projektów, prototypowanie.

Trenowanie GAN-ów było niestabilne i wymagało sporej wiedzy eksperckiej. W wielu firmach taniej było skorzystać z gotowych pretrenowanych modeli i narzędzi niż próbować budować własne od zera. Projekty, w których upierano się przy pełnej własności IP i samodzielnym trenowaniu bez wystarczonego budżetu, często kończyły się rozczarowaniem.

Transformery: mechanizm uwagi, który zmienił wszystko

Przełomem, który bezpośrednio doprowadził do dzisiejszego boomu na modele generatywne, były transformery. Kluczową ideą było zastąpienie rekurencji mechanizmem uwagi (self-attention). Zamiast przetwarzać sekwencję krok po kroku, model mógł jednocześnie „patrzeć” na wiele pozycji i uczyć się ich zależności.

To miało kilka krytycznych konsekwencji:

• łatwiejszą równoległość obliczeń (lepsze wykorzystanie GPU),
• zdolność modelowania długich zależności w tekście,
• skalowalność – zwiększanie rozmiaru modelu i zbioru danych przynosiło przewidywalne korzyści jakościowe.

Początkowo transformery wykorzystywano głównie w tłumaczeniu maszynowym. Szybko jednak stało się jasne, że ten sam mechanizm można zastosować do dowolnych sekwencji: tekstu ogólnego, kodu źródłowego, a nawet sygnałów i zdarzeń w czasie.

Modele językowe nowej generacji: od BERT do GPT

Na bazie architektury transformer powstały kolejne kamienie milowe:

• BERT i modele pokrewne – trenowane w trybie „maskowanego języka”, świetnie sprawdzały się w zadaniach rozumienia tekstu: klasyfikacji, wyszukiwaniu, ekstrakcji informacji.
• GPT i dalsze generatywne modele autoregresyjne – uczyły się przewidywać kolejne tokeny w sekwencji, co naturalnie przekładało się na generowanie tekstu.

BERT był szczególnie atrakcyjny dla organizacji, które chciały poprawić wyszukiwanie informacji, analizę dokumentów czy klasyfikację treści. Często wystarczało „dostroić” pretrenowany model na własnym, stosunkowo niewielkim zbiorze danych, zamiast trenować go od zera. To radykalnie obniżało koszt wejścia.

Z kolei rodzina GPT pokazała, że ten sam model może wykonywać różne zadania na podstawie samej instrukcji w języku naturalnym, bez osobnego procesu uczenia dla każdej funkcji. To przesunęło ciężar z budowania wielu wąskich modeli na jeden, uniwersalny model, którego zachowanie steruje się za pomocą promptów.

Boom na modele generatywne: szanse, koszty i pułapki

Duże modele, duże rachunki