Reprezentacja wiedzy

decy-zje s ˛a dopasowywane do prawych stron reguł produkcyjnych, aby na ko ´ncu dało si˛e stwierdzi´c, czy istniej ˛a dane pozwalaj ˛ace na wygenerowanie danego ci ˛agu ak-cji (rozumowanie w tył). Przykładem systemu rozumuj ˛acego w przód jest R1 -program który konfiguruje komputery VAX. Przykładem systemu rozumuj ˛acego w tył jest MYCIN - program który diagnozuje infekcje krwi.

7.3.6. Meta-reguły

Ciało ka˙zdej reguły produkcyjnej powinno by´c skonstruowane w ten sposób, aby nie wywoływała ona bezpo´srednio ˙zadnej innej reguły inaczej ni˙z poprzez wprowadzenie odpowiednich zmian do pami˛eci operacyjnej. Bywaj ˛a jednak sy-tuacje, w których programista chciałby odpowiednio ukierunkowa´c proces roz-wi ˛azywania danego problemu bez konieczno´sci ingerencji w baz˛e wiedzy. Narz˛e-dziem, które mu na to pozwala, s ˛a meta-reguły. Od zwykłych reguł ró˙zni ˛a si˛e tym, ˙ze zamiast rozwi ˛azywa´c dany problem decyzyjny faworyzuj ˛a one pewne reguły produkcyjne, zmuszaj ˛ac system do rozumowania w okre´slony sposób. Przykła-dem meta-reguł s ˛a strategie rozwi ˛azywania konfliktów opisane w podrozdziale 7.3.4.

7.4. Reprezentacja wiedzy

W przedstawionym systemie wykorzystano reguły produkcyjne, które z kolei bazowały na prymitywnych typach danych. Nie zawsze jest to rozwi ˛azanie opty-malne. Mo˙zna zauwa˙zy´c, ˙ze wnioskowanie mo˙zna przyspieszy´c poprzez zdefi-niowanie odpowiedniej struktury danych. Termin obiekty ustrukturyzowane od-nosi si˛e do dowolnej reprezentacji wiedzy, której bloki składowe s ˛a analogiczne do łuków i wierzchołków grafu. Obiekty ustrukturyzowane pełni ˛a bardzo wa˙zn ˛a rol˛e w grupowaniu informacji. Poni˙zej omówiono sposób ich wykorzystania w systemach decyzyjnych.

7.4.1. Teoria grafów

Teoria grafów znalazła szerokie pole zastosowa ´n w opisie abstrakcyjnych ty-pów danych stosowanych w implementacjach algorytmów sztucznej inteligen-cji. Podstaw ˛a tej teorii jest zało˙zenie o istnieniu prostych obiektów nazywanych wierzchołkami i łukami. Łuki ł ˛acz ˛a wierzchołki w pary i mog ˛a przyjmowa´c pewne warto´sci, cz˛esto uto˙zsamiane z kosztem przej´scia z jednego wierzchołka na drugi. Je˙zeli zbiór wierzchołków oznaczymy N, to ka˙zdy podzbiór N xN jest grafem. Je-˙zeli kolejno´s´c w parach N xN ma znaczenie, to graf jest skierowany. JeJe-˙zeli graf nie zawiera p˛etli, ani kraw˛edzi wielokrotnych, to nazywany jest grafem prostym. Je-˙zeli graf dodatkowo nie zawiera ˙zadnych cykli, to jest lasem. JeJe-˙zeli G jest prostym grafem o n wierzchołkach i n − 1 kraw˛edziach bez cykli, to G jest drzewem. Ta-kie drzewo G nazywa si˛e grafem spójnym, je˙zeli dla ka˙zdego wierzchołka istnieje droga do ka˙zdego innego wierzchołka.

W teorii grafów sie´c jest skierowanym grafem prostym, zawieraj ˛acym pewne warto´sci numeryczne skojarzone z kraw˛edziami, które uto˙zsamia si˛e z kosztem przej´scia lub odległo´sci ˛a. W kontek´scie sztucznej inteligencji graf mo˙ze by´c czymkolwiek, to znaczy mo˙ze reprezentowa´c dowolnie przyj˛ete relacje mi˛edzy wierzchołkami. Daje to mo˙zliwo´s´c modelowania zło˙zonych abstrakcyjnych ty-pów danych. Współcze´snie istnieje wiele ró˙znego rodzaju algorytmów działaj ˛ a-cych na grafach, dzi˛eki czemu wiedza przechowywana w takiej formie mo˙ze by´c efektywnie przetwarzana.

7.4.2. Sieci asocjacyjne

Wiedz˛e zacz˛eto reprezentowa´c za pomoc ˛a sieci w ko ´ncu lat sze´s´cdziesi ˛atych ubiegłego wieku przy okazji prac nad semantyk ˛a j˛ezyków naturalnych. Postulo-wano, ˙ze kluczem do zrozumienia danego j˛ezyka mo˙ze by´c pewien zbiór prostych reguł. Zaowocowało to powstaniem ró˙znych koncepcji co do sposobu przecho-wywania znaczenia zda ´n w pami˛eci komputera, umo˙zliwiaj ˛acego ich przetwa-rzanie i wykorzystanie na wzór tego, jak to czyni człowiek. Celem było zapisanie danych w takiej formie, aby nie zajmowały one zbyt wiele miejsca w pami˛eci oraz były zrozumiałe zarówno dla maszyny, jak i dla człowieka (jego osi ˛agni˛ecie do dzisiaj okazuje si˛e sporym problemem).

Szczególnym przypadkiem grafowego modelu danych jest sie´c semantyczna (ang. semantic net), cho´c mo˙ze nazwa sie´c asocjacyjna lepiej oddaje jego istot˛e. W sieci asocjacyjnej ka˙zdy wierzchołek okre´slany jest jako koncept, czyli pewien abstrakcyjny typ, a ka˙zda kraw˛ed´z reprezentuje zwi ˛azek mi˛edzy odpowiednimi konceptami. Jest to twór podobny do słownika, w którym ka˙zdy termin zdefinio-wany jest za pomoc ˛a innych, a˙z dochodzi si˛e do terminów uznawanych za nie-wymagaj ˛ace dalszych definicji. Innymi słowy, budowana jest pewna hierarchia, w której koncepty le˙z ˛ace ni˙zej definiowane s ˛a za pomoc ˛a konceptów le˙z ˛acych bli˙zej szczytu.

Dla przykładu maszyn˛e mo˙zna zdefiniowa´c jako zło˙zenie pewnych kompo-nentów, umo˙zliwiaj ˛ace przekształcenie siły w pewn ˛a prac˛e. Wymaga to dodania do grafu takich konceptów jak komponent, zło˙zenie itd. oraz zamodelowania ł ˛ a-cz ˛acych je zwi ˛azków. Ponadto do tworzonego grafu mo˙zna doda´c takie koncepty, jak samochód i lodówka, uzupełniaj ˛ac graf zwi ˛azkami dzi˛eki którym b˛edzie wia-domo, ˙ze samochód jest typem maszyny, tak samo jak lodówka. Ciekaw ˛a wła-sno´sci ˛a, nazywan ˛a czasami gospodark ˛a poznawcz ˛a (ang. cognitive economy), jest fakt, ˙ze skoro samochód zdefiniowany jest jako typ maszyny, a maszyna zdefinio-wana jest jako zło˙zenie pewnych komponentów, to samochód równie˙z jest ta-kim zło˙zeniem [4]. Zastosowanie takiego mechanizmu wyeliminowało koniecz-no´s´c uzupełniania grafu kraw˛edziami reprezentuj ˛acymi powtarzaj ˛ace si˛e zwi ˛azki dla ka˙zde konceptu w hierarchii. Pozwoliło to na znacz ˛ace obni˙zenie zapotrze-bowania na pami˛e´c, zwłaszcza w du˙zych bazach danych, kosztem zwi˛ekszenia zło˙zono´sci obliczeniowej impementowanych algorytmów. Konwencja ta dzisiaj jest znana jako dziedziczenie i jest szeroko stosowana w ró˙znych dziedzinach (np. w sztucznej inteligencji, programowaniu i modelowaniu).

7.4. Reprezentacja wiedzy

7.4.3. Przeszukiwanie intersekcyjne

Podstawow ˛a procedur ˛a pozwalaj ˛ac ˛a stwierdzi´c, czy dany koncept jest w od-powiedniej relacji z innym konceptem, jest przeszukiwanie intersekcyjne (ang.

intersection search). Polega ono na jednoczesnym aktywowaniu takich samych

procedur dla obu porównywanych ze sob ˛a wierzchołków grafu i propagacji ob-licze ´n we wszystkich kierunkach. Je˙zeli w pewnym momencie obie procedury „spotkaj ˛a si˛e”, oznacza to ˙ze dana relacja istotnie ma miejsce. Du˙z ˛a wad ˛a tego podej´scia jest znaczne zwi˛ekszanie si˛e czasu oblicze ´n wraz ze wzrostem roz-miaru i stopnia skomplikowania grafu. Ponadto dla przypadków negatywnych konieczne jest przegl ˛adni˛ecie całego grafu, co w istocie jest niczym innym, jak przegl ˛adem zupełnym danego problemu.

7.4.4. Ramki

Z reprezentacj ˛a wiedzy za pomoc ˛a grafów wi ˛a˙ze si˛e kilka problemów. Jednym z nich jest prawdopodobie ´nstwo pojawienia si˛e ró˙znych interpretacji dla danej relacji mi˛edzy konceptami. Na przykład definiuj ˛ac lodówka → maszyna trudno oceni´c, czy projektant (bazy wiedzy) chciał zaznaczy´c, ˙ze lodówka jest pewnym rodzajem maszyny, czy jak ˛a´s konkretnie zdefiniowan ˛a maszyn ˛a, czy by´c mo˙ze konkretn ˛a instancj ˛a lodówki. W literaturze tego typu nie´scisło´sci okre´sla si˛e mia-nem logicznej nieprawidłowo´sci (ang. logical inadequacy). Innym, problemem jest brak odpowiednich mechanizmów heurystycznych w algorytmach przeszu-kiwania. Człowiek, który staraj ˛ac si˛e odpowiedzie´c na pytanie dotycz ˛ace typu danego obiektu nie przegl ˛ada całej dost˛epnej mu wiedzy o ´swiecie, a raczej bie-rze pod uwag˛e jedynie fakty potencjalnie zwi ˛azane z dan ˛a kategori ˛a. Podobne zachowanie powinno charakteryzowa´c heurystyczne algorytmy przeszukiwania grafów.

Ramki s ˛a pewnym sposobem reprezentacji wiedzy w postaci grafu. Pozwalaj ˛a na unikanie nie´scisło´sci oraz problemów zwi ˛azanych z przeszukiwaniem. Poje-dyncza ramka odpowiada wierzchołkowi, w którym przechowywane s ˛a informa-cje o nazwie danego abstrakcyjnego typu danych oraz jego wła´sciwo´sciach. Intu-icja podpowiada, ˙ze ludzki umysł nie stara si˛e definiowa´c konceptów zbyt szcze-gółowo i aby dany obiekt mógł przynale˙ze´c do danej klasy, nie musi wcale speł-nia´c ´sci´sle wszystkich zało˙ze ´n. Prowadzi to do definicji klas uogólnionych, na-zywanych prototypami lub klasami prototypowymi. Obrazuj ˛ac to na przykładzie klasa ptaków, posiadaj ˛aca wła´sciwo´s´c umie lata´c jest klas ˛a uogólnion ˛a. Mog ˛a do niej nale˙ze´c ptaki, które nie lataj ˛a. W ten sposób zarówno jastrz ˛ab, jak i emu mog ˛a by´c reprezentantami klasy ptaki (z tym, ˙ze jastrz ˛ab wydawa´c si˛e b˛edzie lepszym przykładem ptaka).

Systemy oparte na ramkach staraj ˛a si˛e okre´sli´c wła´sciwo´sci pewnych obiek-tów korzystaj ˛ac z prototypowych klas, co sprawdza si˛e w wi˛ekszo´sci przypadków. Czasami konieczne jest wprowadzenie pewnych modyfikacji w obiekcie dziedzi-cz ˛acym po danej klasie.

7.4.5. Przykłady zastosowania ramek

Istot˛e programowania w oparciu o ramki zilustrowa´c mo˙zna nast˛epuj ˛acym przykładem. Niech dana b˛edzie struktura danych (dla kompatybilno´sci z tego typu j˛ezykami programowania zastosowano angielskie nazwy zmiennych): [ PER SON is a kind of THING with

AGE HEIG HT WEIG HT ]

[ P R O P E R T Y is a kind of THING with UNITS RANGE ] [ AGE is a P R O P E R T Y with UNITS : YEARS RANGE : 0 -120] [ HEI GHT is a P R O P E R T Y with UNITS : ME TERS RANGE : 0 -240] [ WEI GHT is a P R O P E R T Y with UNITS : kg RANGE : 0 -200]

[ SCH OOl G R A D U A T E is a kind of P ERSON with AGE : 19]

[ PETER is a PE RSON with AGE : 36

HEIG HT : 180 WEIG HT : 80]

[ JOHN is a SC HOOL G R A D U A T E with HEIG HT : 170 WEIG HT : 75] [ C A R O L I N E is a SC HOOL G R A D U A T E with AGE : 18 HIGHT : 160 WEIG HT : 55]

Klas ˛a podstawow ˛a dla wszystkich konceptów jest tutaj klasa Thing, która po-winna by´c interpretowana jako najprostszy byt. KlasaPersonjest jakim´s rodza-jem klasyThing(programista C++ mógłby powiedzie´c, ˙ze jest to klasa pochodna klasyThing), tak samo jakProperty. Nast˛epnie klasyAge,Height,Weight defi-niowane s ˛a jako poszczególne instancje klasyProperty, ze ´sci´sle zdefiniowanymi polamiUnitsorazRange. Wida´c wyra´znie, ˙ze u˙zytkownik ma tutaj do czynie-nia z dwoma typami relacji: is a kind of (ako), oraz is a (isa). Szukaj ˛ac analogii w teorii zbiorów mo˙zna zauwa˙zy´c, ˙ze relacja ako odpowiada podzbiorowi klasy nadrz˛ednej, a relacja isa odpowiada relacji przynale˙zno´sci do zbioru. Id ˛ac dalej, relacja ako odpowiada deklaracji klasy dziedzicz ˛acej po klasie podstawowej w j˛e-zyku C++, natomiast relacj˛e isa mo˙zna porówna´c do zdeklarowania obiektu danej klasy, to znaczy do powołania jej instancji.

7.4. Reprezentacja wiedzy Ciekawym jest, ˙ze instancje klas pochodnych wcale nie musz ˛a posiada´c ta-kich samych atrybutów, co ich klasy prototypowe. W przykładzie powy˙zej ist-nieje klasaSchool Graduate, która modeluje abstrakcyjnego ucznia ko ´ncz ˛acego szkoł˛e ´sredni ˛a przypisuj ˛ac mu parametrAge: 19. Zabieg ten ma swoje uzasad-nienie, poniewa˙z wi˛ekszo´s´c uczniów ko ´nczy szkoł˛e ´sredni ˛a w wieku 19 lat, cho´c zdarzaj ˛a si˛e uczniowie starsi lub młodsi. W tym wypadku instancja klasySchool Graduateo nazwieCarolinejest przykładem osoby ko ´ncz ˛acej szkoł˛e w wieku lat 18, wi˛ec parametrAgezostaje nadpisany. Dozwolenie takich operacji otwiera sze-reg mo˙zliwo´sci dla programistów posługuj ˛acych si˛e ramkami i pozwala na bardzo dokładne i intuicyjne modelowanie rzeczywisto´sci.

7.4.6. Problemy z systemami zorientowanymi obiektowo

Okazuje si˛e, ˙ze mnogo´s´c mo˙zliwo´sci jak ˛a daje mechanizm dziedziczenia z jed-nej strony pozwala na bardzo dokładne i elastyczne modelowanie rzeczywisto-´sci, z drugiej strony jednak bardzo łatwo mo˙ze prowadzi´c do nie´scisło´sci i pro-blemów z interpretacj ˛a. Wielokrotne dziedziczenie wymusza na programi´scie skonstruowanie pewnych prymitywnych typów, na których mogłyby bazowa´c inne, bardziej skonkretyzowane koncepty. Te podstawowe klasy obiektów mog ˛a jednak by´c dobrane na ró˙zne sposoby. Przykładowo dla jednej grupy ludzi

Pojazd jest wystarczaj ˛aco ogóln ˛a klas ˛a, po której dziedziczy´c powinien obiekt

Samochód, podczas gdy inni uwa˙zaj ˛a, ˙zeSamochódpowinien by´c raczej rodza-jem klasy´_{Srodek transportu}. Ponadto samochody mog ˛a by´c spalinowe/elek-tryczne, osobowe/ci˛e˙zarowe/sportowe i niekoniecznie musz ˛a pełni´c rol˛e trans-portow ˛a w najbardziej podstawowym tego słowa znaczeniu.

Id ˛ac dalej, nale˙zy zauwa˙zy´c, ˙ze typ bazowy obiektu, na którym pracujemy, po-winien czasami zale˙ze´c od czynno´sci na nim przeprowadzanych. Je˙zeli z samo-chodu korzysta kierowca, interesuj ˛a go przede wszystkim takie parametry, jak: poło˙zenie, pr˛edko´s´c, przyspieszenie oraz ewentualny interfejs słu˙z ˛acy do stero-wania. Je˙zeli natomiast samochód b˛edzie „wykorzystywany” przez zgniatark˛e ´smieci, istotnymi jego parametrami b˛ed ˛a: masa, twardo´s´c, skład chemiczny. Do podobnej sytuacji dochodzi, gdy trzeba danemu pojazdowi wyda´c rozkaz „Jed´z!”. Znaczenie tego rozkazu jest takie samo dla samochodu, motocykla, czołgu czy motorówki (z grubsza), jednak jego wykonanie zale˙zy ´sci´sle od typu konkretnej maszyny.

Wspomniane wła´sciwo´sci nazywane s ˛a polimorfizmem i z pewnymi ograni-czeniami zastosowane zostały ju˙z w wielu obiektowych j˛ezykach programowania (C++, Java). Niestety, ze wzgl˛edów technicznych jeszcze nigdzie nie zaimplemen-towano pełnej gamy wła´sciwo´sci charakteryzuj ˛acych obiekty ustrukturyzowane. J˛ezyki deklaratywne dedykowane dla ekspertowych systemów decyzyjnych, takie jak KRL czy FLAVORS, pozwalaj ˛a na korzystanie z wielu (lecz nie ze wszystkich) wymienionych mo˙zliwo´sci na raz. Warto w tym miejscu zwróci´c uwag˛e na j˛e-zyk systemu produkcji CLIPS, który dzi˛eki zaimplementowanemu interpreterowi COOL (ang. CLIPS Object Oriented Language) wspiera wszystkie elementy para-dygmatu programowania obiektowego.