Zadanie 2: Regułowa baza wiedzy

Informatyka, studia dzienne, inż. I st.
semestr VI
Sztuczna inteligencja i systemy ekspertowe 2010/2011
Prowadzący: mgr inż. Jacek Pintera
piątek, 11:15
Data oddania:
Ocena:
Sebastian Drabiński
Paweł Tarasiuk
150856
151021
Zadanie 2: Regułowa baza wiedzy∗
1. Cel
Celem ćwiczenia laboratoryjnego było stworzenie prostego systemu ekspertowego, który w oparciu o regułową bazę wiedzy rozwiązuje praktyczny problem, prowadząc przy tym interakcję z użytkownikiem. Zagadnieniem
pośrednim było opanowanie składni narzędzia CLIPS, w której przygotowywane były listy faktów początkowych oraz reguły wnioskowania. Aby po
prostu korzystać ze stworzonej bazy, jednocześnie czyniąc pracę nieco bardzo
zaawansowaną, stworzyliśmy „od zera” w języku Python własne narzędzie
emulujące składnię CLIPSa i dokonujące wnioskowań. Narzędzie jest ograniczone do potrzebnego nam podzbioru składni CLIPSa, ale nie jest to wcale
podzbiór skrajnie ubogi (zawarte jest w nim na przykład definiowanie własnych funkcji).
2. Wprowadzenie
Przygotowana baza wiedzy zawiera informacje o kilku wybranych, najpopularniejszych programach pełniących określone funkcje potrzebne użytkownikom komputerów domowych / laptopów działających pod kontrolą systemów klasy GNU/Linux. Problemem, który jest rozwiązywany przez system
ekspertowy jest wybór zestawu potrzebnych programów w zależności od preferencji użytkownika. Użytkownik wskazuje, jakie rodzaje programów są mu
∗
SVN:
clips@2180
https://serce.ics.p.lodz.pl/svn/labs/sise/jp_pt1115/SebPab/
1
potrzebne, a następnie jest odpytywany o znaczenie jakie mają dla niego
poszczególne cechy rozważanych programów. Brane pod uwagę są te cechy,
które w jakiś sposób wyróżniają któryś z programów branych pod rozwagę.
Istotą tego pomysłu jest to, że jedna cecha może być w różnym stopniu spełniana przez różne programy, w szczególności - programy z różnych kategorii.
Najistotniejsza część wnioskowania, opisana przez kilkanaście reguł tworzących, następuje po uzyskaniu odpowiedzi na pytania. Wówczas brane są
pod uwagę elementy rozumowania takie jak promocja programów korzystających z tych samych technologii i najlepsze dopasowanie programów do preferencji użytkownika wywnioskowanych z dialogu z nim.
Stworzona baza wiedzy stanowi formalizację własnych doświadczeń (obaj
autorzy korzystają na co dzień z systemów GNU/Linuksowych na komputerach domowych oraz laptopach), oraz recenzji i porównań z serwisów tematycznych. Istotne dla nas było uwzględnienie tych programów, które są
popularne, rozwijają się już co najmniej od dwóch lat i są stosowane jako
domyślne w pewnych dystrybucjach Linuksa. Aby wyeliminować subiektywizm z naszej bazy wiedzy, w przypadkach w których tylko to było możliwe,
potwierdzaliśmy zawarte w bazie wiedzy cechy programów w oparciu o informacje ze stron głównych opisywanych projektów. Część własności programów
zmienia się z wersji na wersję - staraliśmy się opisać wersje dostępne w chwili
tworzenia bazy wiedzy w repozytoriach dystrybucji Arch Linux - ze względu na model tworzenia tej dystrybucji, są to wersje najnowsze bądź bardzo
bliskie najnowszym.
3. Opis implementacji
Stworzona przez nas baza wiedzy zapisana jest w składni języka CLIPS.
Naszym celem było stworzenie zupełnie niezależnego narzędzia obsługującego
tę składnię. Narzędzie zostało napisane w języku Python. Najistotniejszym
elementem, który zmieniliśmy w stosunku do CLIPSa (bo nie zgadzamy się
ze sposobem, na jaki został on zaimplementowany w oryginalnym CLIPSie)
jest sposób przekazywania list jako argumentów do samodzielnie zdefiniowanych funkcji. W CLIPSie tylko jeden, ostatni argument własnej funkcji
może być listą i elementy tej listy przekazywane są w dokładnie taki sam
sposób, co argumenty będące poprzednikami listy. Tworząc własny interpretator języka reguł wnioskujących, uznaliśmy za stosowne obudowywanie
przykazywanych list nawiasami - umożliwia to na przykład zdefiniowanie
własnej funkcji przyjmującej pośród argumentów kilka list. Drugą i ostatnią
różnicą między składnią naszego narzędzia a składnią CLIPSa jest zwracanie
wartości przez zdefiniowane samodzielnie funkcje - tutaj także uznaliśmy za
intuicyjne i zgodne z resztą składni języka wymaganie umieszczenia zwracanego wyrażenia w nawisach.
Pomimo drobnych różnic w składni, nadal korzystamy z wygody jaką daje
nam zgodność naszego narzędzia z CLIPSem. Różnice te wymagają zmian
2
w zaledwie trzech liniach naszego pliku z bazą wiedzy i regułami, który ma
w sumie ponad 580 linii.
Stworzone przez nas narzędzie także stanowi powłokę, która przyjmuje
polecenia wpisywane przez użytkownika. Obsługujemy polecenie load tak
samo jak oryginalny CLIPS - zatem przebieg uruchomienia systemu wnioskującego jest u nas taki sam jak w CLIPSie - load, reset, run. Dodaliśmy
własne polecenie reexec, które pozwala uruchomić nasze narzędzie zupełnie
od nowa - było to dla nas bardzo wygodne, gdy stopniowo tworzyliśmy kod
naszego narzędzia - nasze polecenie od razu uruchamiało nową wersję skryptu
w Pythonie.
Wybór języka Python jest nieprzypadkowy - bardzo istotną dla nas cechą języka są dostępne w tym języku od ręki operacje na łańcuchach znaków,
oraz listy pozwalające na przechowywanie elementów różnych typów (np. list
obok łańcuchów znaków). Pozwala to w bardzo naturalny sposób dokonać
przekształcenia napisu z kodem w składni CLIPSa do postaci w której łatwo
jest przeglądać elementy poszczególnych nawiasów - robimy to za pomocą
zaimplementowanego przez siebie automatu skończonego.
Nasze narzędzie zajmuje mniej niż 1000 linii, co jest pewnym osiągnięciem. Należy jednak zauważyć, że nie implementujemy całej składni CLIPSa,
ani nawet nie próbujemy tego robić - po prostu obsługujemy część składni
która pozwala nam uruchomić nasze rozwiązanie zagadki o kocie wabiącym
się „Tuńczyk” oraz głównej bazy wiedzy. Często jednak rozszerzanie podzbioru obsługiwanej składni było dla nas łatwiejsze, niż upraszczanie zapisu CLIPSowych reguł. Obsługujemy kilkadziesiąt różnych poleceń, obejmujących proste wnioskowanie, elementy arytmetyki, obsługę szablonów wraz
z multislotami, oraz definiowanie własnych funkcji.
Sama baza wiedzy zawiera opisy zastosowań rozważanych programów,
technologii i bibliotek w jakich są one wykonane, oraz nazwanych semantycznie cech jakie posiadają te programy, wraz ze stopniami w jaki cechy te
są spełniane (jeżeli np. kryterium wiele-formatow-dokumentow jest szczególnie słabą cechą danego programu, notowana jest dla niego wartość ujemna
stopnia spełniania tej cechy).
Poza oceną, w jakim stopniu dany program spełnia kryteria wskazane
przez użytkownika jako ważne, oceniane są związki między programami. Jeżeli jakaś technologia inna niż natywna (przez „technologię natywną” rozumiane jest tutaj to, że program w zdecydowanej większości oparty jest
o skompilowane, binarne pliki uruchamialne oraz biblioteki - technologia nienatywną może być np. maszyna wirtualna / interpretator skryptów) jest
używana przez więcej niż jeden program, punkty karne za korzystanie z niej
maleją. Ponadto, jeżeli dwa programy korzystają z tych samych bibliotek
(im więcej bibliotek się zgadza, tym lepiej), rośnie szansa że zostaną one
wybrane razem, gdyż prawdopodobnie dobrze będą się ze sobą integrować
3
lub po prostu będą estetycznie wyglądać używane razem.
Wydajność naszego narzędzia jest istotnie słabsza od wydajności oryginalnego CLIPSa. Wynika to częściowo z różnic zastosowanej technologii, ale
przede wszystkim z lat pracy twórców CLIPSa poświęconych jego optymalizacji. Założeniem naszego projektu od początku nie było bicie rekordów
czasu, a raczej po prostu prowadzenie prawidłowych wnioskowań w czasie na
tyle krótkim, aby przeprowadzenie odpowiedniej liczby testów było możliwe.
Wnioskowanie prowadzone za pomocą naszego narzędzia trwa na naszych
komputerach do kilkudziesięciu sekund, w zależności od udzielanych odpowiedzi. Główny narzut wynika z tego, że wiele danych przechowujemy w pamięci
po prostu jako napisy - dotyczy to także reguł i własnych funkcji, które są
interpretowane ponownie przy każdej potrzebie. Zastosowanie specyficznych
struktur danych oraz czegoś w rodzaju kodu pośredniego dla reguł i funkcji
mogłoby znacznie zredukować czas działania naszego narzędzia. Innym polem do optymalizacji mogłoby być ulepszenie podejścia do wyszukiwania faktów - o ile brak jest ogólnych reguł pozwalających zoptymalizować wszystkie
przypadki przeszukiwania faktów, to w części przypadków sortowanie faktów
i wybór pasujących faktów według prefiksu (przy wykorzystaniu wyszukiwania binarnego) mógłby pomóc.
4. Materiały i metody
Wielokrotnie uruchamialiśmy dialog z użytkownikiem służący wnioskowaniu, zarówno w oryginalnym CLIPSie jak i w naszym narzędziu. Testy
przeprowadzane poprzez wpisywanie naszych prawdziwych preferencji, różnorodnych zmyślonych wartości, oraz preferencji naszych znajomych pozwoliły wyeliminować błędy w działaniu systemu, potwierdzić zgodność między
naszym narzędziem a CLIPSem, oraz porównać otrzymane wyniki wnioskowań z naszą intuicją. Stan do jakiego doprowadziliśmy nasz projekt jest dla
nas satysfakcjonujący we wszystkich tych kwestiach.
5. Wnioski
Wnioskowanie w przód pozwala na przeprowadzanie nietrywialnych dla
człowieka, dowolnie głębokich „rozumowań”, w stopniu na jaki pozwala zapisany zbiór reguł. Za pomocą odpowiednich warunków da się wymusić kolejność rozumowania (możliwe jest nawet naśladowanie postępowań imperatywnych), jednak sam zapis reguł wnioskujących jest bardzo intuicyjny.
Dzięki temu błędy przy formułowaniu reguł wnioskujących są rzadsze niż na
przykład przy programowaniu imperatywnym.
O ile sformułowanie odpowiednich reguł wymaga przeprowadzenia w głowie pewnych symulacji, ogarnięcie dużej bazy wiedzy jest dla człowieka problematyczne (przeważnie wymaga po prostu poświęcenia danej tematyce dużej ilości czasu). Systemy ekspertowe oparte o zbiór reguł wnioskujących pozwalają na wielokrotne wyciąganie wniosków z raz zdefiniowanej bazy wiedzy,
4
która może być nawet bardzo duża.
Jeżeli zbiór faktów potraktujemy jako zbiór napisów w określonej, bardzo deterministycznej składni (przez determinizm rozumiemy tutaj to, że
znaczenie faktu powinno jednoznacznie określać, jak będzie wyglądał reprezentujący go napis), implementacja systemu ze składnią reguł wnioskujących
podobną do CLIPSa okazuje się zadaniem wykonalnym w ramach ćwiczenia
laboratoryjnego. Jakkolwiek wydajność nie jest najmocniejszą stroną stworzonej przez nas implementacji, dokonuje ona prawidłowego wnioskowania w
przód i obsługuje ciekawy podzbiór składni języka CLIPS (zawiera się w tym
definiowanie własnych funkcji).
Literatura
— http://en.wikipedia.org/wiki/Forward_chaining
— http://clipsrules.sourceforge.net/OnlineDocs.html
— http://iweb.tntech.edu/bhuguenard/ds6530/ClipsTutorial/tableOfContents.
htm
— http://docs.python.org/release/3.0.1/
— http://en.wikipedia.org/wiki/Comparison_of_web_browsers
— http://www.technozeast.com/top-10-browsers.html
— http://en.wikipedia.org/wiki/Comparison_of_audio_player_software
— http://en.wikipedia.org/wiki/Comparison_of_video_player_software
— http://www.dedoimedo.com/computers/media-players.html
— http://9oe.me/blog/?p=745
— http://en.wikipedia.org/wiki/Office_suites
— http://www.linuxcommunity.pl/strona/2566/pakiety-biurowe.html
5