Chcąc napisać inteligentny system komunikacji użytkowników z dowolną bazą wiedzy wymaga użycia gotowego bądź napisania własnego systemu analizy reguł oraz faktów Napisanie systemu wnioskowania na podstawie bazy faktów nie jest prostym zadaniem. Należy zadbać o takie rzeczy jak kojarzenie faktów (proste i głębokie), stosowanie zasad na odpowiednich faktach, automatyczne wykrywanie podmiotów i opisów w fakcie. Dodatkowo trzeba uważać na niuanse językowe takie jak polskie litery czy odmiana rzeczowników przez przypadki lub czasowników przez osoby. Dodatkowo należy stworzyć generator odpowiednich zapytań do bazy wiedzy na podstawie otrzymanych faktów. Dzięki wykorzystaniu faktów i reguł możemy dać użytkownikowi wrażenie inteligentnej rozmowy oraz kontroli nad systemem.
If you want to write an intelligent communication system between users and any base of knowledge requires the ready to use or write its own rules and analysis of the fact. To write system of the request on the basis of the facts is not a simple task. Care should be taken for such things as bringing together the facts (simple and compound), the application of the principles of the relevant facts, automatic detection of actors and descriptions in fact. In addition, you must consider the nuances of language such as Polish letters it may nouns or verbs cases by the person. In addition, there should be a generator of relevant questions to the knowledge base on the basis of the facts. By using facts and rules can give you an impression of intelligent conversations and control over the system.
Celem zadania było napisanie modułu do wygodnej komunikacji pomiędzy klientem firmy produkcyjnej a systemem CRM tejże firmy. System CRM jest bazą wiedzy na temat klientów, niestety wiedza ta nie jest (i nie powinna być w całości) udostępniana w prosty sposób „na zewnątrz” firmy. System CRM potrafi odpowiadać na zapytania SQLowe od użytkowników posiadających odpowiednie prawa (w tym od serwerów www). Dodatkowym założeniem jest, to że klient, oczywiście, nie zna struktury języka SQL, potrafi natomiast stwierdzać fakty dotyczące jego firmy i tego o co chce się zapytać.
Moduł na podstawie faktów wprowadzonych przez klienta, powinien jasno i precyzyjnie odpowiadać na żądania użytkownika. Głównym celem zadania było skonstruowanie systemu wnioskującego na podstawie faktów oraz reguł i tworzenie na podstawie wyciąganych wniosków zapytania SQLowych zrozumiałych dla systemu CRM.
Moduł komunikacyjny składa się z dwóch części – systemu wnioskującego oraz sytemu tworzenia zapytania SQL:
Część wnioskująca ma za zadanie stworzenie, na podstawie listy podmiotów, listy zasad oraz listy faktów, jasnej i czytelnej informacji. Dodatkowo informacja taka powinna być czytelna dla kolejnej części systemu – generatora zapytań.
Działanie tej części opiera się o mechanizm tablic. Kojarzenie faktów odbywa się poprzez zamianę wszystkich informacji na dane zebrane w tablicy. W kolejnym kroku następuje wyodrębnienie podmiotu (na podstawie listy podmiotów) oraz opisu, dzięki czemu potrafimy zebrać kilka faktów dot. tego samego podmiotu i stworzyć jeden fakt „zbiorczy” – wygodny i łatwy w użyciu:
Fakt „zbiorczy” jest złączeniem odpowiednich faktów spójnikiem logicznym „i”. Część wnioskowania korzysta z listy specjalnie przygotowanych reguł. Reguła składa się z dwóch części - warunku oraz wyniku. Jeśli któryś z faktów zawiera wszystkie słowa zawarte w warunku, wtedy do bazy faktów zostanie dodany fakt „wynik”. Cała sekwencja – tzn. kojarzenie i wnioskowanie przebiega w pętli tak długo, aż kolejne dwa przebiegi nie dadzą zmiany na liście faktów. Generator zapytań tworzy zapytanie na podstawie listy faktów oraz listy podmiotów. Zapytanie jest tworzone zgodnie z algorytmem:
SELECT * FROM $tablica WHERE $temat; Wyniki zapytań zapisywane są do listy faktów, a dodatkowo mogą odpalać odpowiednie „akcje” – np. wyświetlenie dodatkowych okien/formularzy.
Prosty system do komunikacji został napisany w języku PHP z wykorzystanie HTML/CSS/JavaScrip oraz technologii AJAX. Technologia AJAX ta pozwala na pobieranie danych z serwera bez konieczności irytującego przeładowania strony www. Oczywiście można było skorzystać z gotowego środowiska programowania systemów regałowych – CLIPS – jednak po dokładniejszej analizie oraz rozważaniach nad sensem przydatności w moim projekcie, porzuciłem ideę użycia tego środowiska w moim projekcie. W przykładowej aplikacji napisałem klasy Faktu, oraz Zasad (Rule), dodatkowo napisałem klasę Zasady odpalającej jakąś funkcję – jeśli warunki są spełnione, zostanie uruchomiona odpowiednia funkcja. Większość operacji jaka jest przeprowadzana w aplikacji opiera się na wygodnym dzieleniu faktów (stringów) na części dzięki użyciu funkcji „explode”. Wszystkie fakty (jako napisy oraz dodatkowo jako obiekty) przetrzymywane są w danych „sesyjnych” co pozwala nam na dostęp do nich z każdego miejsca i każdego skryptu naszej aplikacji.
Aplikacja było testowana tylko pod systemem Widnows XP z przeglądarką Fire-Fox. Po uruchomieniu aplikacji, najpierw należy zidentyfikować się jako klient – podając odpowiednie dane. Logika jest „od ogółu do szczegółu”, tzn. najpierw podajemy dane ogólne (takie jak miasto, kod) a później schodzimy w szczegóły (numer klienta/numer ostatniej faktury). Po uwierzytelnieniu się jako klient możemy zapytać system o status realizacji zamówienia i czas realizacji, lub poprosić o przygotowanie oferty handlowej wraz z aktualnymi promocjami. Po każdej operacji dodajemy do listy jeden fakt, dalej przetwarzana jest cała lista zgodnie z przedstawionym algorytmem i wykonywane jest zapytanie SQL do systemu CRM, jeśli wynik jest pozytywny następuje wygenerowanie nowego faktu. Listę faktów możemy obserwować w środkowej części aplikacji, w prawej części możemy obserwować przetworzone fakty oraz zapytania SQL.
Uruchamiamy aplikację poprzez wpisanie w przeglądarkę internetową http://localhost/xxx gdzie xxx to nazwa katalogu z aplikacją. W okienku klienta wpisujemy po kolei (od ogółu do szczegółu – zgodnie z wcześniej podaną definicją) – miasto: Wroclaw (bez polskich liter), system zacznie przeszukiwać CRM w poszukiwaniu klienta z Wroclawia (jednego) – znalazł kilka – trzeba doprecyzować (zawęzić krąg) poszukiwania – np. poprzez wpisanie kodu 54-100 Klient został zidentyfikowany (można to zobaczyć np. na liście faktów) i może odpytywać system o stopień realizacji zamówienia oraz poprosić o przygotowaną dla niego ofertę handlową.
Krótkie testy tego typu komunikacji przeprowadzili prawdziwi pracownicy klientów firmy produkcyjnej. Ten sposób komunikacji wydał się bardziej inteligentny i elastyczny od „suchego” wprowadzania danych, dodatkowo okazał się szybszy i wygodniejszy (poprzez zastosowanie technologii AJAX). Klientom udało się uzyskać informacje których szukali, jednak przydałoby się rozszerzenie funkcjonalności aplikacji poprzez zwiększenie ilości pól (faktów). Dodatkowo podczas testów okazało się, że w przypadku pomyłki trzeba wszystkie dane wprowadzać od początku.
Napisanie wszechstronnego środowiska do modelowania faktów nie jest rzeczą łatwą. W swoim algorytmie niestety nie uwzględniłem takich rzeczy jak: automatyczne wykrywanie podmiotów (musimy podać stricte listę podmiotów), „głębokiego kojarzenia” – tzn. „Wojtek jest Tomka brat” + „Mama Wojtek imię Danuta” = „Tomek mama imię Danuta” – podejrzewam, że takie kojarzenie możliwe byłoby do zrobienia na drzewach bądź grafach, jednak takie rozważania mogą być tematem kolejnej pracy. Dodatkową wadą jest wprowadzania faktów i pisanie słów w przypadku mianownika – zamiast „Tomka brata dzieci” – „Tomek brat dzieci” – co może prowadzić do błędów w logice działania środowiska.