Chcąc nauczyć się pisać proste systemy ekspertowe na samym początku przeanalizujemy przykład z książki „PROLOG PROGRAMMING IN DEPTH” napisanej przez Michael A. Covington, Donald Nute i Andre Vellino.
System ekspertowy służy do pomocy przy rozwiązywaniu konkretnego problemu, np. dlaczego drukarka nie drukuje, dlaczego samochód nie odpalił, itp. System zadaje pytania, my udzielamy odpowiedzi twierdzących bądź przeczących, na podstawie których wywnioskowana zostaje odpowiedź programu.
Aby program mógł działać poprawie, musi składać się z dodatkowego programu, który odpowiadać będzie za interpretacje podawanych przez nas odpowiedzi yes/no – program pobiera wpisaną przez nas literkę (w analizowanym przez nas przykładzie występują odpowiedzi yes/no) y/Y lub n/N, którą widzi jako kod ASCII, a następnie kod ASCII interpretuje na yes lub no i wynik zostanie pobrany przez właściwy program.
Nasz właściwy system składa się z:
-
bazy wiedzy diagnostycznej;
-
bazy wiedzy o przypadkach;
-
pytań do użytkownika;
-
treści tłumaczącej każdą diagnozę.
Analizowany przez nas przykład rozpoczyna się od załadowania dodatkowego programu getyesno.pl – użycie tego programu będzie możliwe tylko wtedy, gdy będzie znajdował się on wraz z systemem w folderze Prologu bin.
Następnie nasz system rozpocznie się od wpisania słowa start, wtedy zostaną wyświetlone w oknie kompilatora informacje, czego dotyczy nasz program i zostanie uruchomiona procedura pokazująca nam pierwsze pytanie.
Predykant write wypisuje term znajdujący się w pojedynczym cudzysłowie, a nl przenosi do nowej linii.
W dalszej części programu występuje baza wiedzy diagnostycznej składająca się z reguł, co może być usterką, jeżeli użytkownik na zadane pytania odpowie yes albo no. Baza wiedzy diagnostycznej nie musi być ułożona w żadne „drzewo logiczne” czy schemat blokowy. Diagnozy nie wykluczają się wzajemnie.
defect_may_be dotyczy tego, co może być usterką, w nawiasie znajduje się term, który potem użyty będzie w wyjaśnieniach dotyczących diagnoz
user_says przypisuje pytaniom odpowiedzi; pierwszy term w nawiasie dotyczy zadanego pytania, a drugi odpowiedzi yes/no na zadane pytanie.
W defect_may_be znajduje się baza wiedzy diagnostycznej, a w stored_answer baza wiedzy o przypadkach – klauzule potwierdzane są podczas uruchamiania programu. Predykat explain wyświetla sposób rozwiązania usterki, a ask_question zawiera treść pytań.
ask_queastion służy do zadawania pytania, w nawiasie znajduje się term, który użyty był przy user_says – w tym miejscu musimy opisać wszystkie pytania, których potrzebujemy do postawienia diagnozy
Na końcu znajdują się treść diagnoz.
explain dotyczy wytłumaczenia diagnoz, których użyliśmy przy defect_may_be – używamy w tych dwóch miejscach tych samych term.
Gdy zechcemy utworzyć własny system ekspertowy, wystarczy, że na podstawie powyższego przykładu wpiszemy własną bazę diagnostyczną, pytania do użytkownika i wyjaśnienia dotyczące diagnoz.
W celu lepszego zrozumienia pisania systemu ekspertowego, spróbujemy napisać bardzo prosty i krótki program dotyczący nie działającego telefonu komórkowego.
Zaczynamy od wymyślenia trzech usterek:
-
zepsuty ekran;
-
nie naładowany telefon;
-
wolno działający telefon przez nadmiar włączonych procesów;
-
oddać telefon do naprawy, bo nie można zdiagnozować problemu.
Następnie wymyślamy pytania, na które można odpowiedzieć yes/no i tworzymy bazę diagnostyczną.
Czy telefon się włącza? – tak, zadajemy dalej pytania, nie – oznacza, że telefon jest nienaładowany.
Czy ekran reaguje na dotyk? – tak, zadajemy dalej pytanie, nie – oznacza, że ekran jest zepsuty.
Czy telefon działa wolniej niż zwykle? – tak – oznacza, że należy wyczyścić procesy, nie – oznacza, że trzeba oddać telefon do naprawy.
Ostatnią częścią jest stworzenie treści tłumaczącej każdą diagnozę:
-
zepsuty ekran – trzeba wymienić ekran;
-
nie naładowany telefon – trzeba go naładować;
-
wolno działający telefon – trzeba wyczyścić procesy;
-
oddać telefon do naprawy – trzeba oddać go do serwisu.
