Wzlot i upadek systemów ekspertowych: zimy AI

Systemy ekspertowe były pierwszą dużą falą komercyjnej sztucznej inteligencji. W latach 70. i 80. programy oparte na bazach wiedzy doradzały w chemii, medycynie, geologii i konfiguracji komputerów. Firmy inwestowały w zespoły „inżynierów wiedzy”, dedykowane maszyny Lisp i ogromne zbiory reguł. Potem rynek gwałtownie osłabł, a AI weszła w okres nazywany zimą.

Ta historia jest szczególnie aktualna w epoce LLM. Wtedy sądzono, że zebranie wystarczającej liczby reguł przybliży maszynę do ogólnego rozumowania. Dziś podobną nadzieję wiąże się ze skalą parametrów i danych. Technologie są różne, lecz ryzyko pozostaje: kompetencję w dobrze ograniczonym zadaniu łatwo pomylić z niezawodnością poza nim.

Czym był system ekspertowy

Klasyczny system ekspertowy rozdzielał trzy elementy:

bazę wiedzy zawierającą fakty, reguły i heurystyki domenowe;
mechanizm wnioskowania, który dopasowywał reguły do faktów i wyprowadzał wnioski;
interfejs i moduł wyjaśnień, przez który użytkownik podawał dane i mógł zapytać, dlaczego system rekomenduje decyzję.

Reguła mogła mieć postać: „jeśli spełnione są przesłanki A i B, zwiększ przekonanie do hipotezy C”. Wnioskowanie w przód zaczyna od znanych faktów i uruchamia pasujące reguły. Wnioskowanie wstecz zaczyna od hipotezy i szuka przesłanek potrzebnych do jej potwierdzenia. System nie uczył się automatycznie z milionów rekordów. Jego jakość zależała od tego, czy eksperci i inżynierowie potrafili wydobyć, zapisać i utrzymać wiedzę.

To dawało czytelność. Można było zobaczyć ścieżkę reguł. Jednocześnie powstawał wąskie gardło pozyskiwania wiedzy: eksperci często podejmują decyzje na podstawie doświadczenia, którego nie potrafią wyczerpująco zwerbalizować.

DENDRAL: wiedza domenowa zamiast uniwersalnego mózgu

Projekt DENDRAL rozpoczął się w Stanfordzie w 1965 roku pod kierunkiem Edwarda Feigenbauma i Joshuy Lederberga. Jego zadaniem było wnioskowanie o strukturze cząsteczek na podstawie danych spektrometrii mas. Program generował możliwe struktury, odrzucał te sprzeczne z ograniczeniami chemicznymi i porównywał przewidywane konsekwencje z obserwacjami.

DENDRAL nie „odkrywał chemii od zera”. Korzystał z heurystyk dostarczonych przez specjalistów. To właśnie było przełomem: wcześniejsze projekty szukały ogólnej procedury rozwiązywania problemów, a DENDRAL pokazał, że specjalistyczna wiedza może być ważniejsza niż uniwersalny algorytm. Stanford nazywa go pierwszym systemem ekspertowym.

Meta-DENDRAL poszedł krok dalej i próbował indukować reguły z przykładów. Był wczesnym pomostem między ręcznie kodowaną wiedzą a uczeniem maszynowym.

MYCIN: reguły, niepewność i odpowiedzialność

MYCIN, rozwijany w Stanfordzie w latach 70., miał wspierać diagnozę infekcji bakteryjnych i dobór terapii. Zadawał pytania o pacjenta, stosował reguły oraz współczynniki pewności, a następnie przedstawiał rekomendacje. System potrafił wyjaśnić, które reguły uruchomił.

Technicznie projekt był ważny z trzech powodów. Po pierwsze, pokazał wnioskowanie na niepełnych danych. Po drugie, oddzielił mechanizm wnioskujący od wiedzy, co doprowadziło do powstania „powłok” systemów ekspertowych. Po trzecie, ujawnił, że dobry wynik laboratoryjny nie rozwiązuje problemu wdrożenia. W medycynie liczą się walidacja, integracja z procesem, aktualność wiedzy, odpowiedzialność i akceptacja użytkowników.

MYCIN nie stał się rutynowym klinicznym produktem. Nie oznacza to porażki badań. Pokazuje, że bezpieczny system decyzyjny to więcej niż trafny algorytm—ta sama prawda dotyczy dziś asystentów AI w sektorach regulowanych.

XCON i komercyjny szczyt

Jednym z najbardziej znanych wdrożeń był XCON (pierwotnie R1) używany przez Digital Equipment Corporation do konfigurowania zamówień na systemy VAX. Złożony produkt miał wiele komponentów i ograniczeń kompatybilności; błędna konfiguracja oznaczała kosztowne poprawki. Reguły systemu pomagały dobierać elementy i wykrywać sprzeczności.

Sukcesy takie jak XCON uruchomiły boom. Powstawały komercyjne shelle, konsultanci i dedykowany sprzęt Lisp. Organizacje zakładały, że wiedzę ekspercką można zamknąć w bazie, kopiować bez kosztu i zachować mimo odejścia pracownika. W wąskich, stabilnych domenach miało to sens. Problem zaczynał się, gdy baza rosła.

Dlaczego bazy reguł stawały się kruche

Każda nowa reguła mogła wejść w konflikt z istniejącą. Wyjątek wymagał kolejnych warunków, a zmiana produktu lub procedury uruchamiała lawinę aktualizacji. Trudno było udowodnić kompletność bazy i przewidzieć zachowanie wszystkich kombinacji. Wiedza była rozproszona między ekspertem, dokumentacją i interpretacją inżyniera.

To techniczny dług podobny do dzisiejszych złożonych promptów. Setki wyjątków w system prompt nie tworzą solidnej granicy bezpieczeństwa. Model lub silnik reguł może wykonać instrukcję zgodnie z lokalnym dopasowaniem, ale nie rozumie całego celu organizacji. Krytyczne polityki powinny być egzekwowane w kodzie, kontroli dostępu i procesie zatwierdzania.

Pierwsza zima AI i raport Lighthilla

Pierwsza zima AI wiąże się z latami 70., choć nie ma jednej daty początku. Wczesne programy działały w mikroświatach o ograniczonej liczbie obiektów i reguł, ale gorzej w nieuporządkowanym świecie. Maszynowe tłumaczenie, robotyka i rozumienie języka nie spełniły ambitnych terminów.

Raport Jamesa Lighthilla przygotowany dla brytyjskiej Science Research Council w 1973 roku krytykował brak realizacji wielkich obietnic i problem eksplozji kombinatorycznej. Wpłynął na finansowanie badań w Wielkiej Brytanii. Nie „udowodnił”, że AI jest niemożliwa; celnie opisał przepaść między demonstracją a skalowalnym systemem.

Równolegle w USA ograniczano wybrane programy, gdy wyniki nie odpowiadały oczekiwaniom sponsorów. Termin „zima” opisuje spadek entuzjazmu i pieniędzy, nie całkowite zatrzymanie pracy.

Druga zima: ekonomia łamie obietnicę

Druga zima AI jest zwykle łączona z końcem lat 80. i początkiem 90. Systemy ekspertowe wymagały kosztownego utrzymania, a dedykowane maszyny Lisp przegrały cenowo z szybko rozwijającymi się stacjami ogólnego przeznaczenia. Firmy odkryły, że demonstracja z kilkuset reguł i system produkcyjny z tysiącami zależności to dwa różne projekty.

Do tego doszły wysokie oczekiwania wobec japońskiego programu komputerów piątej generacji. Jego cele obejmowały przetwarzanie wiedzy i równoległe wnioskowanie logiczne. Program dostarczył badania i technologie, ale nie spełnił narracji o szybkim przeskoku do maszyn inteligentnych. Gdy rynek i sponsorzy stracili cierpliwość, etykieta „AI” stała się dla części firm obciążeniem.

Czy systemy ekspertowe naprawdę zniknęły

Nie. Reguły biznesowe, systemy konfiguracji, silniki decyzyjne, detekcje SIEM i polityki bezpieczeństwa są ich potomkami. Różnica polega na tym, że rzadziej sprzedaje się je jako drogę do inteligencji ogólnej. W stabilnym procesie jawna reguła może być lepsza od modelu: jest deterministyczna, testowalna i łatwa do audytu.

Najsilniejsze architektury są często hybrydowe. Model rozpoznaje nieustrukturyzowany sygnał, wyszukiwarka dostarcza źródła, a reguła i system uprawnień ograniczają akcję. W bezpiecznym wdrożeniu LLM generatywna elastyczność nie powinna zastępować kontroli dostępu.

System ekspertowy a LLM

Cecha	System ekspertowy	Duży model językowy
Źródło zachowania	Jawne reguły i fakty	Parametry wyuczone z dużego korpusu
Wyjaśnialność	Możliwa ścieżka reguł	Uzasadnienie generowane nie musi odzwierciedlać przyczyny
Aktualizacja	Edycja bazy wiedzy	RAG, dostrajanie lub nowy trening
Determinizm	Zwykle wysoki	Wynik probabilistyczny i zależny od kontekstu
Zakres	Wąski i jawny	Szeroki, lecz trudny do precyzyjnego ograniczenia
Typowa awaria	Brak reguły lub konflikt	Halucynacja, prompt injection, błędne użycie narzędzia

LLM rozwiązuje część problemu pozyskiwania wiedzy, bo uczy się wzorców z danych, ale płaci za to mniejszą przejrzystością i kontrolą. RAG może dostarczyć aktualne dokumenty, lecz nie gwarantuje wiernego użycia źródła. Ewaluacja LLM musi więc mierzyć nie tylko płynność, ale poprawność, oparcie w źródłach i skutki działania.

Siedem lekcji dla obecnej fali AI

Wąski sukces nie dowodzi ogólności. Zdefiniuj granice zadania i przypadki poza zakresem.
Utrzymanie jest częścią kosztu. Model, prompt, RAG i integracje starzeją się tak jak baza reguł.
Wyjaśnienie interfejsu nie jest dowodem przyczynowym. Płynne uzasadnienie może być konfabulacją.
Wiedza bez procesu nie daje wdrożenia. Odpowiedzialność, zatwierdzanie i reakcja na incydent są obowiązkowe.
Krytyczne granice muszą być deterministyczne. Model nie powinien sam przyznawać sobie uprawnień.
Test laboratoryjny nie zastępuje monitoringu produkcji. Zmiana danych zmienia ryzyko.
Obietnica potrzebuje falsyfikowalnego kryterium. Zanim kupisz AI, ustal, po czym poznasz, że nie działa.

W praktyce te zasady prowadzą do AI red teamingu, rejestrowania wywołań narzędzi i ograniczania ich uprawnień.

Warto dodać jeszcze jedną praktyczną konsekwencję. System ekspertowy miał jawnego właściciela reguły; przy modelu bazowym odpowiedzialność bywa rozmyta między dostawcę, zespół aplikacyjny i właściciela danych. Firma powinna prowadzić rejestr modeli AI, przypisać właściciela każdemu przypadkowi użycia i ustalić termin ponownej walidacji. Gdy model lub źródła RAG się zmieniają, wcześniejsza akceptacja nie jest automatycznie aktualna. To odpowiednik kontroli wersji bazy wiedzy, której brak pogrążał dawne wdrożenia.

FAQ

Czy system ekspertowy uczył się sam?

Zwykle nie. Wiedza była pozyskiwana od ekspertów i kodowana jako reguły. Istniały projekty uczące reguły, jak Meta-DENDRAL, ale klasyczny system ekspertowy opierał się na ręcznie przygotowanej bazie.

Dlaczego MYCIN nie trafił do codziennego użycia w szpitalach?

Dobry wynik eksperymentalny nie wystarczał. Pozostawały kwestie walidacji klinicznej, odpowiedzialności, integracji, aktualizacji wiedzy i akceptacji. To przykład bariery systemowej, nie prosty dowód słabej jakości algorytmu.

Ile było zim AI?

Najczęściej wyróżnia się dwie: w latach 70. oraz na przełomie lat 80. i 90. Granice są umowne, a wpływ różnił się między krajami i dziedzinami.

Czy obecny boom AI może skończyć się zimą?

Historia nie pozwala przewidzieć terminu. Pokazuje jednak, że finansowanie spada, gdy koszt i niezawodność nie odpowiadają obietnicom. Produkcyjne zastosowania mogą nadal rosnąć nawet wtedy, gdy marketingowe oczekiwania opadną.

Źródła

Chcesz połączyć elastyczność LLM z twardymi regułami bezpieczeństwa? Porozmawiaj z Breachroad o architekturze, testach i kontroli agentów AI.