Kryterium projektowe bardzo istotnej dla systemów z bazą wiedzy. Oznacza między innymi, że dane przedmiotowe nie mogą znaleźć się w warstwie interfejsu aplikacji i obok – oczywistego w tym projekcie – założenia, iż baza wiedzy jest oddzielona także od sterowania, gwarantuje wyraźny podział systemu eksperckiego na trzy główne komponenty: interfejs, mechanizm wnioskowania, bazę danych i wiedzy. Oprócz tego wśród elementów systemu można wyróżnić dodatkowe pliki zasobowe takie jak obrazy graficzne, zbiory multimedialne czy dane niezbędne do uruchamiania aplikacji w różnych wersjach językowych.
Minimalny rozmiar bazy wiedzy powinien oscylować w granicach 50 reguł produkcji. Branę są pod uwagę tylko reguły, uczestniczące w procesie wnioskowania i dialogu z użytkownikiem. Te ostatnie tylko, jeżeli są kontekstowe. Inne reguły służące np. do wykrywania i korekty błędów nie są uwzględniane.
Stosowanie faktów sterujących jest uzasadnione tylko w pewnych sytuacjach. Przypadki nadużywania faktów sterujących (w istocie pozaprzedmiotowych) to przede wszystkim systemy, w których część „faktów” tworzona jest sztucznie jedynie w celu narzucenia bardzo ścisłej kontroli procesowi wnioskowania. Fakty takie w rzeczywistości nie zawierają żadnych danych z dziedziny, w której pracuje system. Niekiedy stosowanie takich faktów jest dopuszczalne, ale tylko tam gdzie twórca systemu zamierza wyróżnić pewne fazy/etapy w procesie wnioskowania (np. zbieranie kilku koniecznych na początku faktów o użytkowniku), a nie tam gdzie chce poddać wnioskowanie nadmiernej kontroli, ograniczając je tym sposobem najczęściej do wyłącznie jednej ścieżki wnioskowania.
Przebieg dialogu z użytkownikiem powinien odzwierciedlać naturę procesu wnioskowania, który opiera się na poszukiwaniu rozwiązania, a nie jego ewaluacji/wyliczaniu drogą znanego z góry algorytmu. W dialogu powinny być zatem zawsze uwzględniane dotychczas zgromadzone informacje (choć niekoniecznie wszystkie), gdyż właśnie w ten sposób w systemie regułowym realizujemy mechanizm rozwiązywania problemu, polegający na dochodzeniu do wniosków końcowych różnymi ścieżkami a nie sekwencyjnym wykonywaniu kroków pewnego ustalonego algorytmu.
Fakty zawierające dane przedmiotowe nie mogą w trakcie przetwarzania, przechowywania i komunikacji na styku Java-CLIPS zmieniać swej postaci czy też formy reprezentacji w sposób uniemożliwiających ich jednoznaczną identyfikację i właściwą interpretację, taką jak wynika z treści pytań stawianych użytkownikowi i wybieranych przez niego odpowiedzi. Założenie to wymaga zatem od twórcy systemu czytelnych nazw obiektów, pojawiających się w kodzie bazy wiedzy (zwłaszcza wartości opcji wyboru prezentowanych użytkownikowi) oraz zachowywania ich typu (oryginalne w danej dziedzinie wartości symboliczne pozostają w bazie wiedzy symbolicznymi, numeryczne – numerycznymi itd.) Jeżeli wykorzystywane są dodatkowe pliki z zasobami, zawierające pełną treść pytań i odpowiedzi prezentowanych użytkownikowi, to odpowiadające im wartości w bazie wiedzy mogą mieć skróconą formę. Powinna być ona jednak symboliczna i czytelna. Z takich plików zasobowych korzystać muszą wtedy zarówno warstwa interfejsu realizowana w Javie, jak i warstwa wnioskowania realizowana w CLIPSie.
Konkluzje, które otrzymujemy w momencie zakończenie procesu wnioskowania nie mogą być reprezentowane w bazie wiedzy w postaci faktów. Powinny mieć postać reguł produkcji lub też powinny być dopiero konstruowane w trakcie wnioskowania (jak np. w systemach planowania tras/działań). Do wniosków należy bowiem dojść na drodze poszukiwania rozwiązania w trakcie kontekstowego dialogu z użytkownikiem, a nie poprzez selekcję i projekcję pewnych grup faktów dobieranych na podstawie zbioru wartości atrybutów podanych przez użytkownika. Taki charakter rozwiązania oznaczałby, iż korzystamy z mechanizmów właściwych systemom baz danych, a to nie może być przedmiotem oceny aplikacji SI jaką jest system ekspercki.
Forma odpowiedzi udzielanych przez użytkownika w trakcie dialogu powinna wynikać z natury przedmiotu pytania a nie z ograniczeń narzuconych sztucznie przez założenia przyjęte (często wtedy błędnie) przy projektowaniu aplikacji. W interfejsie powinny być zatem obecne zarówno opcje jednokrotnego, jak i wielokrotnego wyboru, o ile wymaga tego charakter pytania (a właściwie charakter udzielanych na nie odpowiedzi). Należy unikać rozwijanych list, gdyż ich zastosowanie jest uzasadnione tylko w przypadku bardzo dużej liczby (rzędu kilkudziesięciu) możliwych wartości.
Linki do najciekawszych stron www poświęconych tematyce systemów eksperckich:
Strona systemu CLIPSOstatnia aktualizacja: 2011-04-06
Przez: Artur Michalski