mgr inż. Szymon Bobek Katedra Automatyki Akademia Górniczo-Hutnicza w Krakowie e-mail: szymon.bobek@agh.edu.pl mgr inż. Krzysztof Kaczor Katedra Automatyki Akademia Górniczo-Hutnicza w Krakowie e-mail: kk@agh.edu.pl mgr inż. Krzysztof Kluza Katedra Automatyki Akademia Górniczo-Hutnicza w Krakowie e-mail: kluza@agh.edu mgr inż. Weronika Adrian Katedra Automatyki Akademia Górniczo-Hutnicza w Krakowie e-mail: wta@agh.edu.pl Edycja i kontrola jakości wiedzy w systemach regułowych 1. Wprowadzenie Na przestrzeni ostatnich kilku lat nastąpił znaczny rozwój powłok (ang. shells ) do tworzenia systemów regułowych. Istniejące już od ponad dwudziestu lat powłoki takie jak Clips 1, czy Jess 2 nie potrafiły sprostać wymogom współczesnego projektanta systemów ekspertowych. Spore ograniczenia i przestarzałość wspomnianych narzędzi, spowodowały rozwój bardziej zaawansowanych pakietów oprogramowania do tworzenia i 1 clipsrules.sourceforge.net 2 www.jessrules.com
uruchamiania systemów regułowych, takich jak Drools 3, czy narzędzia HeKatE 4. Głównym kierunkiem rozwoju narzędzi wspomagających tworzenie systemów regułowych było udostępnienie mechanizmów modularyzacji bazy wiedzy i umożliwienie wizualnego projektowania bazy wiedzy, a także wprowadzenie zaawansowanych strategii wnioskowania. Pierwsze dwie kwestie związane są z problemem konstruowania dużych baz wiedzy, gdzie tradycyjne metody zawodzą na poziomie czytelności i wygody projektowania. Oprócz tego w chwili, kiedy systemy ekspertowe zaczęto wykorzystywać w oprogramowaniu, którego niezawodność działania w każdej sytuacji stała się kwestią krytyczną, pojawiła się potrzeba stworzenia mechanizmów kontroli jakości i weryfikacji bazy wiedzy 5. Pomimo znacznego zainteresowania rozwojem powłok do tworzenia systemów regułowych, w temacie tym istnieje wciąż duży obszar dotyczący metod edycji i reprezentacji wiedzy, oraz kontroli jakości tej wiedzy, wymagający badań. W niniejszej pracy został przedstawiony zestaw narzędzi, który umożliwia zaawansowane tworzenie systemów ekspertowych przy użyciu różnych metod reprezentacji wiedzy oraz weryfikację logiczną tych systemów. 3 Browne P, JBoss Drools Business Rules, Packt Publishing, 2009 4 Nalepa G.J., Ligęza A., HeKatE Methodology, Hybrid Engineering Of Intelligent Systems, International Journal of Applied Mathematics and Computer Science 2009, nr 3 5 Nazareth D. L., Issues in the Verification of Knowledge in Rule-Based System, International Journal of Man-Machine Studies,1989, nr 3
2. Motywacja Istniejące narzędzia, służące do tworzenia i uruchamiania systemów ekspertowych, takie jak Clips, Jess, czy Drools, posiadają dwa znaczące ograniczenia: 1. Oferują wyłącznie jeden format reprezentacji wiedzy (wyjątkiem jest tutaj Drools, umożliwiający zapis wiedzy zarówno za pomocą reguł jak i tablic decyzyjnych). 2. Z racji na brak formalnej definicji metody reprezentowania wiedzy, nie oferują mechanizmów pozwalających na formalną kontrolę jej jakości, rozumianą w kontekście poprawności logicznej. Ograniczenia wynikające ze stosowania wyłącznie reprezentacji regułowej na poziomie edycji bazy wiedzy mogą powodować utrudnienia w tworzeniu baz wiedzy opisujących dziedziny, w kontekście których używanie reguł explicite, jest zupełnie nienaturalne. Brak kontroli jakości baz wiedzy umożliwia tworzenie niekompletnych lub niespójnych systemów, co w przypadku oprogramowania którego niezawodne działanie jest kwestia krytyczną, może prowadzić do poważnych konsekwencji. W związku z powyższymi ograniczeniami zaproponowane zostało stworzenie zestawu narzędzi, które umożliwią: 1. Tworzenie baz wiedzy przy pomocy kilku schematów reprezentacji wiedzy 2. Formalną weryfikację poprawności baz wiedzy pod kątem zupełności i determinizmu. 3. Wizualizację zależności pomiędzy elementami reprezentowanej wiedzy.
Narzędzia opisywane w następnych rozdziałach są częścią projektu RE- BIT 6 - systemu zarządzania regułami biznesowymi i technologicznymi. 3. Reprezentacja wiedzy Reguły są jedną z najpopularniejszych metod reprezentacji wiedzy 7. Istnieją jednak inne formaty zapisu wiedzy, które użytkownikom nie będącym ekspertami w dziedzinie systemów regułowych mogą wydawać się bardziej naturalne do reprezentowania pewnych zagadnień (np. klasyfikacyjnych) i w konsekwencji ułatwiać tworzenie baz wiedzy. W tym celu, z punktu widzenia organizacji wiedzy, w opisywanych w tej pracy narzędziach dostępne są następujące metody reprezentacji wiedzy: 1. Tablice decyzyjne 2. Reguły 3. Siatki decyzyjne Z punktu widzenia fizycznej reprezentacji bazy wiedzy, opisywany system obsługuje dwa formaty: 1. Bazujący na języku XML 8 język REBIT, wykorzystywany przez edytor bazy wiedzy 2. Formalny język regułowy HMRL bazujący na logice atrybutowej 9, wykorzystywany przez weryfikator logiczny bazy wiedzy. Język ten 6 www.rebit.zarz.agh.edu.pl 7 Harmelen F., Vladimir Lifschitz, and Bruce Porter, Handbook of Know- ledge Representation. Elsevier Science, 2007. 8 W3C. Extensible markup language (xml) 1.0, w3c recommendation. Technical report, W3C, 1998. 9 Nalepa G.J., Ligęza A., HeKatE Methodology, Hybrid Engineering Of Intelligent Systems, International Journal of Applied Mathematics and Computer Science 2009, nr 3
stworzony został na podstawie języka HMR 10, będącego natywnym językiem silnika wnioskującego narzędzi HeKatE 11. Poniżej przedstawione zostały przykładowe reguły zapisane w języku REBIT i HMRL, które w zależności od wartości atrybutu day określają, czy dany dzień jest dniem roboczym. Przykład 1: Reguła w języku REBIT <Rule Id="TodayIsWorkDayRule"> <If> <Atom Operator="in"> <LeftHand> <Term Content="Variable"> <Variable IdRef="day"/> </Term> </LeftHand> <RightHand> <Term Content="Constant"> <Constant Multiplicity="MultipleUnordered"> <String>Monday</String> <String>Tuesday</String> <String>Wednesday</String> <String>Thursday</String> <String>Friday</String> </Constant> </Term> </RightHand> </Atom> </If> <Then> <Atom Operator="eq"> <LeftHand> <Term Content="Variable"> <Variable IdRef="today"/> </Term> </LeftHand> <RightHand> <Term Content="Constant"> <Constant Multiplicity="Single"> <String>Workday</String> </Constant> </Term> 10 https://ai.ia.agh.edu.pl/wiki/hekate:hmr 11 Nalepa G.J., Ligęza A., HeKatE Methodology, Hybrid Engineering Of Intelligent Systems, International Journal of Applied Mathematics and Computer Science 2009, nr 3
</RightHand> </Atom> </Then> </Rule> Poniżej została przedstawiona reguła z Przykładu 1, zapisana w języku HMRL Przykład 2: Reguła w języku HMRL schm1/'todayisworkdayrule': [day in ['Monday', 'Tuesday', 'Wednesday', 'Thursday', 'Friday']] ==> [today set 'Workday']) W celu umożliwienia weryfikacji logicznej bazy wiedzy, konieczna jest unifikacja sposobu w jaki wiedza ta jest reprezentowania w obrębie weryfikatora i edytora, tak aby możliwa była komunikacja pomiędzy nimi. Sposób wymiany danych pomiędzy edytorem a weryfikatorem przedstawiony został na Rysunku 1. Weryfikacja logiczna wymaga formalnego zapisu wiedzy. Taki wymóg spełnia język HMRL, będący językiem regułowym bazującym na logice atrybutowej. Wybór tego języka jako formatu wewnętrznej reprezentacji wiedzy w weryfikatorze logicznym był zatem naturalną konsekwencją wspomnianego wymogu. W obrębie edytora, wiedza reprezentowana jest za pomocą bazującego na języku XML, języka REBIT. Ponieważ system dopuszcza inne poza regułową reprezentacje wiedzy - takie jak siatki i tabele decyzyjne - konieczne było stworzenie mechanizmów mapowania tych reprezentacji do formatu regułowego (Patrz Rozdział 4). Dodatkowo konieczne było stworzenie programów mapujących regułową reprezentację REBIT do postaci HMRL.
Rysunek 1: Architektura systemu do edycji i weryfikacji wiedzy Cykl komunikacji pomiędzy edytorem wiedzy a weryfikatorem logicznym można opisać następującym algorytmem: 1. Użytkownik tworzy bazę wiedzy przy pomocy edytora, wykorzystując różne formaty reprezentacji wiedzy. 2. W celu weryfikacji wiedzy, edytor mapuje bazę wiedzy do postaci regułowej, zapisanej w języku REBIT i przekazuje do analizatora składniowego 3. Analizator składniowy bada poprawność składniową bazy wiedzy i parsuje bazę wiedzy w języku REBIT do formatu HMRL, grupując podobne reguły w tak zwane konteksty (w celu umożliwienia badania zupełności, czy sprzeczności)
4. Weryfikator logiczny przeprowadza weryfikację bazy wiedzy i przekazuje raport w z powrotem do edytora, który informuje użytkownika o ewentualnych błędach. 4. Edycja bazy wiedzy Edycja bazy wiedzy jest dokonywana przy pomocy stworzonego specjalnie do tego celu edytora. Edytor ma za zadanie umożliwienie użytkownikowi łatwej modyfikacji bazy wiedzy poprzez zastosowanie wizualnych komponentów ułatwiających posługiwanie się aplikacją. Edytor może łączyć w sobie funkcjonalność aplikacji pozwalającej na edycję bazy wiedzy jak też aplikacji dla użytkownika końcowego, który będzie używał jej do wnioskowania. W tym jednak przypadku zastosowano pierwsze podejście, gdzie aplikacja służy jedynie do edycji baz wiedzy. Edytor składa się z kilku modułów powstałych w wyniku zastosowania wzorca projektowego Model-View-Controller (MVC). MVC (zobacz rysunek 2.) jest informatycznym wzorcem projektowym, który na określonym poziomie abstrakcji architektury aplikacji wprowadza 3-warstwowy podział na: Warstwę modelu - odpowiadającą za wewnętrzną reprezentację danych które przetwarza aplikacja. Warstwę widoku - odpowiadająca za prezentację użytkownikowi danych przechowywanych w warstwie modelu. Warstwę kontrolera - pośredniczącą pomiędzy warstwami modelu i widoku w wymianie danych poprzez przesyłanie odpowiednich komunikatów lub poprzez obsługę zdarzeń generowanych w tych warstwach.
Rysunek 2: Wzorzec MVC. Podział aplikacji może być zrealizowany na różnych poziomach abstrakcji: Na poziomie kodu źródłowego, gdzie każdy plik zawierający kod źródłowy zostaje przydzielony do jednej warstwy. Na poziomie binariów które razem tworzą kompletny system. Dzięki takiej strukturze każda warstwa aplikacji/systemu może być tworzona niezależnie od innych. Co więcej, umożliwia ona łatwą podmianę warstwy na inną np. zmianę warstwy widoku która prezentuje dane użytkownikowi w sposób graficzny na taką która nadaję się do prezentacji w linii poleceń. Jedynym wymogiem które muszą spełniać wszystkie warstwy jest posiadanie spójnego, ujednoliconego interfejsu do komunikacji z pozostałymi warstwami. Typ, rodzaj interfejsu jest różny i zależy także od poziomu abstrakcji na którym zastosowano wzorzec:
Na poziomie kodu źródłowego, w zależności od języka programowania, interfejsem mogą być metody w klasach, odpowiednie funkcje globalne, itp. Na poziomie binarnym interfejs mogą stanowić różnego rodzaju technologie np. CORBA, COM+, DCOM, ActiveX, TCP/IP, Std I/O, SO dla systemów Unixowych, DLL dla Windows, itp. MVC jest obecnie szeroko stosowany przede wszystkim w różnego rodzaju frameworkach umożliwiających szybkie tworzenie aplikacji. Wśród najpopularniejszych można wymienić: GTK+, JAVA Swing, Qt since Qt4 release, Cocoa, ASP.NET MVC Framework. Bazując na opisanym wzorcu stworzona została architektura edytora której schemat jest pokazany na rysunku 3: Rysunek 3: Architektura edytora wiedzy. Główną warstwą edytora jest moduł modelu w którym są przechowywane dane w postaci wewnętrznej reprezentacji odpowiedniej dla edytora. Warstwa ta posiada dwa rodzaje interfejsu: Interfejs który służy od ekstrakcji danych z formatu XML. Przy jego pomocy dane zawarte w modelu są już wstępnie przetwarzane.
Interfejs przy pomocy którego komunikuje się z nadrzędną warstwą (warstwa prezentera). Warstwa prezentera jest odpowiedzialna za mapowanie danych pomiędzy formatami zrozumiałymi dla użytkownika (widoku) a zrozumiałymi dla edytora (wewnętrzna reprezentacja). Podobnie jak warstwa widoku posiada ona odpowiednie interfejsy służące do komunikacji z innymi warstwami. W szczególnych przypadkach (najczęściej trywialnych) warstwa ta jest pomijana na drodze komunikacji warstw widoku i modelu. Warstwa widoku jest odpowiedzialna za prezentację struktury bazy wiedzy użytkownikowi. Moduł ten jest głównie realizowany przez graficzny interfejs użytkownika zaprojektowany przy pomocy biblioteki Qt. Jednym z jego głównych zadań oprócz wyświetlania odpowiednich informacji jest także przechwytywanie zdarzeń i gestów generowanych przez użytkownika i odpowiednie ich interpretowanie (odpowiednia reakcja). Warstwa ta stanowi także warstwę widoku prezentującą dane w formacie akceptowalnym przez jądro systemu oraz jako plik w formacie Rebit. Mapowanie do/z tych formatów jest zawsze poprzedzone prostą weryfikacją składniową na podstawie definicji formatu w technologii XML Schema. Edytor, podobnie jak sam weryfikator także przeprowadza wstępną weryfikację formatu danych pobieranych z bazy wiedzy czy też z pliku. Edytor umożliwia użytkownikowi pełną edycję bazy wiedzy, a więc w szczególności: edycję reguł, typów, atrybutów a także siatek i tabel decyzyjnych. Podczas pracy z aplikacją wszystkie wprowadzane dane są monitorowane w sposób ciągły a wykryte nieprawidłowości i błędy natychmiast są sygnalizowane użytkownikowi. Zaletą takiego monitorowania danych jest to iż użytkownik od razu wie o zaistniałym incydencie i na-
tychmiast może podjąć kroki aby go naprawić. Typowe rozwiązania które wymagają ręcznego uruchomienia weryfikacji mają tą szczególną wadę że naprawienie jednej usterki może powodować pojawianie się kolejnych. Edytor posiada mechanizmy pozwalające na tworzenie i edytowanie siatek i tabel decyzyjnych. Jako że dedykowaną formą reprezentacji wiedzy w systemie REBIT jest reprezentacja regułowa, w edytorze zostały zaimplementowane dwa algorytmy translacji wiedzy zapisanej w postaci siatek i tabel decyzyjnych na postać regułową: Algorytm as-is generuje reguły wprost z siatek i tabel decyzyjnych bez żadnej optymalizacji. Często powstały w ten sposób zbiór reguł ma niską jakość. Algorytm ID3, który jest także używany do generowania reguł z siatek i tabel decyzyjnych. Za realizację tego algorytmu odpowiedzialny jest osobny moduł aplikacji, który znajduje się w warstwie kontrolera (prezentera). Zaletą tego algorytmu jest to że podczas działanie tworzy on minimalne drzewo decyzyjne które powoduje że powstały z niego zbiór reguł zawiera minimalną liczbę przesłanek i dlatego nie musi być on poddawany dalszej optymalizacji. Bardzo ważną kwestią dotyczącą edytora jest jego uniwersalność. To pojęcie jest tutaj rozumiane w kontekście możliwości jego użycia na wielu platformach programowo-sprzętowych. Z racji braku możliwości stworzenia aplikacji wykonywalnej na różnego rodzaju platformach, kod źródłowy edytora jest stworzony w taki sposób że bez żadnych modyfikacji można go skompilować na różnych platformach. Efekt ten został osiągnięty dzięki zastosowaniu biblioteki Qt. Obecnie biblioteka jest dostępna dla następujących platform: X11 (min. GNU/Linux, *BSD, Solaris), Windows, Mac OS X oraz dla urządzeń wbudowanych opartych na Linuksie
(Qt Extended), Windows CE, Windows Mobile, Symbian, Maemo. Bibliotek dostarcza swego rodzaju interfejsu programistycznego, który umożliwia tworzenie kodu który może być kompilowany na wyżej wymienionych platformach (zobacz rysunek 4). Rysunek 4: Poglądowa architektura biblioteki Qt. Edytor stanowi odrębną aplikację względem całego systemu. Dlatego też bardzo ważnym zagadnieniem jest sposób komunikacji z pozostałymi komponentami. Biorąc pod uwagę powyższe wymaganie niezależności platformowo-sprzętowej jedną z możliwych dróg komunikacji jest komunikacja sieciowa. Edytor komunikuje się z repozytorium bazy wiedzy za pomocą gniazd sieciowych wykorzystując przy tym specjalnie do tego celu stworzony protokół oparty na SOAP. Kwestie bezpieczeństwa komunikacji nie zostały jeszcze rozwiązane. Jest to temat do dalszych prac. Edytor posiada przyjazny, graficzny interfejs użytkownika. Za jego pomocą obsługiwana jest pełna funkcjonalność aplikacji. Przy pomocy interfejsu użytkownik ma możliwość: Pobrania bazy wiedzy z repozytorium wiedzy. Wysłania bazy wiedzy do repozytorium wiedzy. Otwarcia i edycji plików XML zawierających definicję elementów bazy wiedzy.
Tworzenia, edycji, usuwania typów danych. Tworzenia, edycji, usuwania atrybutów. Tworzenia, edycji, usuwania zestawów reguł. Tworzenia, edycji, usuwania reguł. Tworzenia, edycji, usuwania tabel decyzyjnych. Tworzenia, edycji, usuwania siatek decyzyjnych. Generowania reguł za pomocą algorytmów ID3 i as is przy użyciu siatek i tabel decyzyjnych. Wizualnego przedstawienia zależności pomiędzy regułami (tylko niektóre dialekty języka Rebit). Walidacji formatu wejściowego na poziomie składniowym za pomocą definicji w formacie XML schema (XSD). Formalnej walidacji wiedzy za pomocą zewnętrznych modułów do tego przeznaczonych. Definiowania zależności pomiędzy regułami. Uruchomienia wnioskowania i śledzenia wyników jego działania. 5. Weryfikacja bazy wiedzy Istotnym elementem projektowania systemów regułowych jest zagwarantowanie poprawności bazy wiedzy pod względem logicznym i składniowym, tak aby silnik wnioskujący mógł bez przeszkód przeprowadzać wnioskowanie na dostarczonych danych. Poprawność składniowa sprawdzana jest przez analizator składniowy, który nie wnikając w semantykę modelu sprawdza bazę wiedzy pod względem struktury i pewnych narzuconych przez gramatykę języka reprezentacji wiedzy ograniczeń. Rolą analizatorów logicznych jest natomiast zagwarantowanie wymaganej jakości oprogramowania. Przez jakość oprogramowania rozumie
się zespół cech systemu, wpływających na jego zdolność do spełniania określonych kryteriów. Wymaga się, by system charakteryzowały 12 : 1. Efektywność 2. Niezawodność 3. Funkcjonalność 4. Użyteczność 5. Przenaszalność 6. Pielęgnowalność 7. Bezpieczeństwo W systemach regułowych dla uzyskania wysokiej jakości należy szczególnie zatroszczyć się o 11 : 1. Niezawodność, 2. Bezpieczeństwo, 3. Efektywność. System regułowy musi działać zawsze zgodnie ze specyfikacja przy optymalnym wykorzystaniu dostępnych zasobów. Jednocześnie proces tworzenia systemu powinien być tak przeprowadzony, by już na etapie projektowania i implementacji eliminować możliwie wiele przyczyn potencjalnych nieprawidłowości. Niepoprawne działanie systemu regułowego to wynik wystąpienia anomalii w bazie wiedzy, będących następstwem niezapewnienia następujących własności: 1. Zupełności 2. Determinizmu 3. Minimalnej liczby reguł 12 Ligęza A. Logical Foundations for Rule-Based Systems. Uczelniane wydawnictwa Naukowo- Dydaktyczne AGH w Krakowie, 2005
Weryfikacja bazy wiedzy dokonywana przez weryfikator logiczny testuje wymienione własności. Całość weryfikacji można podzielić na dwie fazy: 1. Sprawdzenie poprawności syntaktycznej pliku XML i XSD (REBIT) stanowiące wejście dla weryfikatora przy pomocy narzędzia XML- Starlet. 2. Sprawdzenie poprawności logicznej bazy wiedzy przy pomocy weryfikatora logicznego Weryfikator logiczny zbudowany został na bazie weryfikatora HalVA 13, który z kolei był wtyczką dla regułowego silnika wnioskującego HeaRT 14. Weryfikator logiczny oferuje badanie własności bazy wiedzy wymienionych w kolejnych podrozdziałach. Determinizm W kwestii weryfikacji determinizmu systemu główna strategia to porównywanie par reguł. 15. Znane są podejścia do walidacji determinizmu poprzez konstrukcję odpowiednich testów. Testy takie w dużej części oparte są na konstrukcji tabel prawdy z wykorzystaniem rachunku zdań 16. 13 Ligęza A. Metody analizy wiedzy regułowej XTT 2 w języku Prolog, AGH -- University of Sience and Technology,2009 14 Nalepa G. J., Bobek S.,Gawędzki M., LigęzaA., HeaRT Hybrid XTT2 Rule Engine Design and Implementation, AGH University of Science and Technology, 2009 15 Ligęza A.. Logical Support for Design of Rule-Based Systems. Reliability and Quality Issues. ECAI 96 Workshop on Validation, Verification and Refinement of Knowledge-Based Systems, 1996. Nguyen T. A., Perkins, Laffey T. J., Pecora D. Checking an Expert Systems Knowledge Base for Consistency and Completeness. In IJCAI, 1985. SuwaM., Scott C. A., Shortliffe E. H.. Rule-Based Expert Systems, chapter Completeness and consistency in rule-based expert system, Addison-Wesley Publishing Company, 1985. 16 Andert C., Frasher E.P.. A verifiable, autonomous satellite control system. Aerospace Applications Conference, 1989
Jedną z przyczyn niedeterministyczności systemu jest występowanie sprzeczności w zbiorze reguł. Wykrycie sprzeczności w obrębie danego kontekstu następuje poprzez znalezienie stanu systemu, dla którego dwie (lub więcej) reguły są spełniane, przy czym produkują one sprzeczne konkluzje. W tym celu zbiór reguł należących do tego samego kontekstu jest przeszukiwany i wybierane są reguły, których obszary stanów jakie pokrywają mają niezerowe przecięcie oraz wartości atrybutów w częściach decyzyjnych mają ustawiane sprzeczne wartości. Poniżej przedstawiono przykład działania algorytmu weryfikującego zupełność. Poniższy kod jest wewnętrzna reprezentacją języka REBIT o nazwie HMRL, z której korzysta weryfikator. xrule kontekst1/1: [month in [1,2,12]] ==> [season set winter]. xrule kontekst1/2: [month in [3,2,5]] ==> [season set spring]. Zakładając, że atrybut month przyjmuje wartości z przedziału <1;12> po przeprowadzeniu weryfikacji, wygenerowany zostanie następujący raport: 'In kontekst1 rule: 1 conflicts with rule 2 for state: [[month, [2.0]]]' Zupełność
W literaturze 17 można znaleźć różne sposoby ujęcia problemu weryfikacji zupełności. Podstawowym jest podejście polegające na wyczerpującym przeszukiwaniu zbioru reguł i porównywaniu ich parami. Innym sposobem ujęcia tematu jest weryfikacja z wykorzystaniem logiki pierwszego rzędu. W przytaczanych pracach 18 stwierdza się, że dowód tego czy dany zbiór warunków jest tautologią (baza wiedzy jest zupełna), można przeprowadzić w oparciu rezolucję dualną. Obok weryfikacji podejmowane były również próby walidacji zupełności. W tym celu konstruowano testy, które sprawdzały działanie systemu dla ustalonego zbioru przypadków testowych 19. W niektórych sytuacjach lepszym rozwiązaniem jest skupienie wysiłków weryfikacji na eliminacji reguł niedeterministycznych. W celu określenia czy model systemu jest zupełny, wykonywane są następujące czynności: 17 Andert E. P.. Integrated Knowledge-Based System Design and Validation for Solving Problems in Uncertain Environments. International Journal of Man-Machine Studies, 36(2), 1992., Suwa M.,Scott C. A., and Shortliffe E. H.. Rule-Based Expert Systems, chapter Completeness and consistency in rule-based expert system. Addison-Wesley Publishing Company, 1985.Tepandi J.. Verification, testing, and validation of rulebased expert systems. Proceedings of the 11-th IFAC World Congress, 1990.A. Ligęza. Logical Foundations for Rule-Based Systems. Uczelniane wydawnictwa Naukowo- Dydaktyczne AGH w Krakowie, 2005.Nazareth D. L.. Issues in the Verification of Knowledge in Rule-Based Systems. International Journal of Man-Machine Studies, 30(3), 1989. 18 Andert E. P.. Integrated Knowledge-Based System Design and Validation for Solving Problems in Uncertain Environments. International Journal of Man-Machine Studies, 36(2), 1992., Suwa M.,Scott C. A., and Shortliffe E. H.. Rule-Based Expert Systems, chapter Completeness and consistency in rule-based expert system. Addison-Wesley Publishing Company, 1985.Tepandi J.. Verification, testing, and validation of rulebased expert systems. Proceedings of the 11-th IFAC World Congress, 1990.A. Ligęza. Logical Foundations for Rule-Based Systems. Uczelniane wydawnictwa Naukowo- Dydaktyczne AGH w Krakowie, 2005.Nazareth D. L.. Issues in the Verification of Knowledge in Rule-Based Systems. International Journal of Man-Machine Studies, 30(3), 1989. 19 Tepandi J.. Verification, testing, and validation of rule-based expert systems. Proceedings of the 11-th IFAC World Congress, 1990
Na podstawie części warunkowych reguł z danego kontekstu budowany jest zbiór stanów explicite pokrywanych przez reguły, Na podstawie zbioru wyodrębnionego zbioru z punktu 1. Generowane są kombinacje sanów potencjalnie niepokrytych, Na podstawie dziedzin atrybutów wchodzących w skład części decyzyjnych reguł obliczany jest zbiór stanów niepokrytych, poprzez odjęcie od zbiorów dziedzin zbiorów wyliczonych w punktach 1 oraz 2 i wygenerowanie kombinacji na podstawie tych różnic. Dla wszystkich kombinacji z punktów 1, 2 oraz 3 przeprowadzane są testy polegające na próbie uruchomienia reguł dla każdej z nich. W przypadku gdy znajdzie się stan niepokryty przez żadną regułę, jest on dodawany do zbioru określającego stany niepokryte, oraz generowany jest raport o niezupełności badanego zbioru reguł. Poniżej przedstawiono przykład działania algorytmu weryfikującego zupełność. Poniższy kod jest wewnętrzna reprezentacją języka REBIT o nazwie HMRL, z której korzysta weryfikator. xrule kontekst1/1: [month in [1,2,12]] ==> [season set winter]. xrule kontekst1/2: [month in [3,4,5]] ==> [season set spring]. Zakładając, że atrybut month przyjmuje wartości z przedziału <1;12> po przeprowadzeniu weryfikacji, wygenerowany zostanie następujący raport: In kontekst1 uncover state: (month) in ([6.0 to 11.0])
Minimalna ilość reguł W literaturze 20 opisany jest sposób eliminacji nadmiarowych reguł z wykorzystaniem dualnej rezolucji 21. Wyróżniono dwa schematy postępowania. Zakładamy, że zbiór reguł reprezentowany jest następująco: Niech prawdziwe będzie: oraz niech będzie dane k reguł, których przesłanki będą różnić się jedynie o warunki Wówczas można zastosować następujący schemat redukcji: Równanie 1 Drugi schemat redukcji polega na zastąpieniu szeregu reguł, regułą ogólniejszą. Jeśli: 20 Ligęza A. Logical Support for Design of Rule-Based Systems. Reliability and Quality Issues. ECAI 96 Workshop on Validation, Verification and Refinement of Knowledge-Based Systems, 1996. 21 Ligęza A. Logical Foundations for Rule-Based Systems. Uczelniane wydawnictwa Naukowo- Dydaktyczne AGH w Krakowie, 2005
wówczas: Równanie 2 Oba schematy mogą posłużyć jako formalny punkt wyjścia do weryfikacji bazy wiedzy. W celu zidentyfikowania nadmiarowości reguł można zredukować logikę pierwszego rzędu, opisującą reguły, i przedstawić ją za pomocą drzew opartych o logikę Boole a 22. Należy zauważyć że brak redundancji ma ścisły związek z deterministycznym zachowaniem systemu. Mianowicie determinizm zbioru reguł gwarantuje brak nadmiarowości. Dlatego w niektórych sytuacjach lepszym rozwiązaniem jest skupienie wysiłków weryfikacji na eliminacji reguł niedeterministycznych. Pochłanianie Dla wykrycia zjawiska pochłaniania między regułami zastosowany został algorytm, w którym parami porównuje się przesłanki oraz konkluzje reguł. W pierwszej kolejności wybierane są dwie różne reguły z danego kontekstu. Dla obu reguł następuje analiza części warunkowej oraz wynikowej. Warunek drugiej reguły (C2) dla danego atrybutu uznaje się 22 Andert C., Frasher E.P.. A verifiable, autonomous satellite control system. Aerospace Applications Conference., 1989
za pochłonięty przez odpowiedni warunek pierwszej reguły (C1), jeśli przy stanie systemu opisanym przez C2 warunek C1 jest spełniony. Jako wynik otrzymywany jest raport wskazujący reguły pochłaniając i pochłaniane. Poniżej przedstawiono przykład działania algorytmu weryfikującego zupełność. Prezentowany kod jest wewnętrzna reprezentacją języka REBIT o nazwie HMRL z której korzysta weryfikator. xrule kontekst1/1: [month in [1,2,12]] ==> [season set winter]. xrule kontekst1/2: [month in [2]] ==> [season set spring]. Po uruchomieniu testu na pochłanianie reguł, zostanie wygenerowany następujący komunikat: 2 'In kontekst1 rule: 1 subsumes rule 2' Redukcja Wyszukiwane są dwie reguły, których część decyzyjna jest taka sama. Dla wskazanych reguł następuje złączenie przesłanek. Polega ono na utworzeniu nowej przesłanki w postaci alternatywy warunków dla danego atrybutu według równania 2. Jako wynik działania algorytm zwraca numery reguł, które można połączyć ze sobą oraz propozycję nowej, uogólnionej reguły. Proponowana reguła może zastąpić dwie połączone reguły. Poniżej przedstawiono przykład działania algorytmu weryfikującego zupełność. Prezentowany kod jest wewnętrzna reprezentacją języka REBIT o nazwie HMRL, z której korzysta weryfikator.
xrule kontekst1/1: [month in [1,2,12]] ==> [season set winter]. xrule kontekst1/2: [month in [2]] ==> [season set spring]. Po uruchomieniu testu na pochłanianie reguł, zostanie wygenerowany następujący komunikat: 1 'In kontekst1 rule: 1 can be joined with rule 2' 2 'In kontekst1 rule: 2 can be joined with rule 1' 6. Podsumowanie Celem niniejszej pracy było przedstawienie zestawu narzędzi do edycji i weryfikacji baz wiedzy dla systemów ekspertowych. Gwarancja poprawności logicznej projektowanego systemu, jak również łatwość jego tworzenia stanowią bardzo istotne aspekty podczas wytwarzania systemów ekspertowych. Rozwiązania przedstawione w niniejszej pracy mogą być dobrym punktem wyjścia do szerszych prac w tym obszarze. W ramach rozbudowy systemu do edycji i weryfikacji baz wiedzy dla systemów regułowych, należy wymienić dwie kwestie: stworzenie wizualnego edytora dla edycji wiedzy oraz ulepszenie algorytmów badających zupełność wiedzy. Istniejące algorytmy, w przypadku rozbudowanych reguł powodują eksplozję kombinatoryczną stanów jakie reguły maja pokrywać. W konsekwencji czas wykonywania się algorytmu rośnie w przypadku rozbudowanych reguł nieliniowo.
Bibliografia Andert C., Frasher E.P.. A verifiable, autonomous satellite control system. Aerospace Applications Conference, 1989 Andert E. P.. Integrated Knowledge-Based System Design and Validation for Solving Problems in Uncertain Environments. International Journal of Man-Machine Studies, 36(2), 1992. Browne P, JBoss Drools Business Rules, Packt Publishing, 2009 Harmelen F., Lifschitz V., and Bruce Porter, Handbook of Knowledge Representation. Elsevier Science, 2007. Ligęza A. Logical Foundations for Rule-Based Systems. Uczelniane wydawnictwa Naukowo- Dydaktyczne AGH w Krakowie, 2005 Ligęza A. Metody analizy wiedzy regułowej XTT 2 w języku Prolog, AGH -- University of Sience and Technology,2009 Ligęza A.. Logical Support for Design of Rule-Based Systems. Reliability and Quality Issues. ECAI 96 Workshop on Validation, Verification and Refinement of Knowledge-Based Systems, 1996. Nalepa G. J., Bobek S.,Gawędzki M., LigęzaA., HeaRT Hybrid XTT2 Rule Engine Design and Implementation, AGH University of Science and Technology, 2009 Nalepa G.J., Ligęza A., HeKatE Methodology, Hybrid Engineering Of Intelligent Systems, International Journal of Applied Mathematics and Computer Science 2009, nr 3 Nazareth D. L., Issues in the Verification of Knowledge in Rule-Based System, International Journal of Man-Machine Studies,1989, nr 3 Nguyen T. A., Perkins, Laffey T. J., Pecora D. Checking an Expert Systems Knowledge Base for Consistency and Completeness. In IJCAI, 1985. Suwa M., Scott C. A., Shortliffe E. H.. Rule-Based Expert Systems, chapter Completeness and consistency in rule-based expert system, Addison-Wesley Publishing Company, 1985. Tepandi J.. Verification, testing, and validation of rule-based expert systems. Proceedings of the 11-th IFAC World Congress, 1990. Źródła internetowe geist.agh.edu.pl hekate.ia.agh.edu.pl
clipsrules.sourceforge.net www.jessrules.com www.rebit.zarz.agh.edu.pl www.w3c.org ai.ia.agh.edu.pl/wiki/hekate:hmr