Rok akademicki 200 /200 - Politechnika Warszawska

Transkrypt

Rok akademicki 2011/2012
Politechnika Warszawska
Wydział Elektroniki i Technik Informacyjnych
Instytut Informatyki
PRACA DYPLOMOWA MAGISTERSKA
Grzegorz Paweł Gaszewski
Zastosowanie systemów wieloagentowych w systemach
zarządzania relacjami z klientem (CRM)
Opiekun pracy
Dr inż Dominik Ryżko
Ocena: .....................................................
.................................................................
Podpis Przewodniczącego
Komisji Egzaminu Dyplomowego
Specjalność:
Inżynieria Systemów Informatycznych
Data urodzenia:
1987.04.06
Data rozpoczęcia studiów:
2007.02.21
Życiorys:
Nazywam się Grzegorz Paweł Gaszewski. Urodziłem się 6 kwietnia 1987 roku w Mławie. Po
ukończeniu szkoły podstawowej i gimnazjum w 2003 roku rozpocząłem edukację w I Liceum
Ogólnokształcącym im. Stanisława Wyspiańskiego w Mławie. W szkole średniej uczęszczałem
do klasy o profilu matematyczno-fizyczno-informatycznym. W lutym 2007 roku rozpocząłem
studia na Wydziale Elektroniki i Technik Informacyjnych Politechniki Warszawskie na kierunku
Informatyka. W lutym 2011 roku ukończyłem z wynikiem bardzo dobrym studia inżynierskie po
czym kontynuowałem naukę na studiach magisterskich.
.......................................................
Podpis studenta
EGZAMIN DYPLOMOWY
Złożył egzamin dyplomowy w dniu ...................................................................................2012r
z wynikiem ...................................................................................................................................
Ogólny wynik studiów: ................................................................................................................
Dodatkowe wnioski i uwagi Komisji: ..........................................................................................
.......................................................................................................................................................
.......................................................................................................................................................
STRESZCZENIE
Praca zawiera opis rozbudowy systemu wieloagentowego zintegrowanego z systemem CRM o
funkcjonalności społecznościowe oraz o maszynę wnioskującą i proces uczenia oparte na języku
PROLOG. W pierwszym rozdziale opisany jest cel pracy. Drugi rozdział opisuje podstawy
język PROLOG. W kolejnym znajduje się opis standardowych mechanizmów komunikacji w
systemach wieloagentowych. Czwarty rozdział opisuje analizę skupień używaną do budowy
sieci agentów. Następny rozdział przedstawia zaimplementowane funkcjonalności. Kolejny
rozdział opisuje proces testowania systemu. W siódmym rozdziale opisane są wyciągnięte
wnioski oraz podsumowanie całego projektu.
Słowa kluczowe: PROLOG, nauka, komunikacja, system wieloagentowy, CRM, analiza skupień
Application of multi-agent systems in customer relationship management systems.
Thesis contains description of implementation of social skills, and PROLOG based learning
process and decision making, in multi-agent system integrated with CRM system. First chapter
describes purpose of this thesis. Second chapter describes basis of programming in PROLOG
language. Next one contains description of communication mechanisms in multi-agent systems.
Fourth chapter describes cluster analysis on which building agent network is based. Next one
presents implemented functionalities. Following chapter describes testing process. Seventh
chapter contains conclusions and a summary of whole project.
Keywords: PROLOG, learning, communication, multi-agent system, CRM, cluster analysis
Spis treści
Spis treści.......................................................................................................................................4
1. Wstęp.........................................................................................................................................6
2. Maszyna wnioskująca oparta o język PROLOG.......................................................................8
2.1 Rachunek predykatów pierwszego rzędu..............................................................................8
2.2 Język PROLOG..................................................................................................................10
2.3 Zapis faktów i reguł w języku PROLOG............................................................................11
2.4 Implementacja języka PROLOG: SWI-Prolog...................................................................13
3. Mechanizmy interakcji w systemach wieloagentowych..........................................................15
3.1 Systemy wieloagentowe .....................................................................................................15
3.2 Aukcje.................................................................................................................................16
3.3 Negocjacje...........................................................................................................................17
3.4 Systemy tablicowe..............................................................................................................19
3.5 Mechanizmy komunikacji między agentami w JADE........................................................20
4. Klasyfikacja danych jako narzędzie budowy sieci agentów....................................................22
4.1 Klasyfikacja........................................................................................................................22
4.2 Klasyfikacja w systemach rozproszonych..........................................................................24
5. Rozbudowa systemu wieloagentowego...................................................................................27
5.1 Funkcjonalności systemu MASforCRM powstałego podczas pracowni dyplomowej
inżynierskiej..............................................................................................................................27
5.2 Narzędzia wykorzystane podczas pracy.............................................................................29
5.3 Budowa sieci agentów na podstawie analizy skupień........................................................30
5.3.1 Projekt sieci agentów................................................................................................30
5.3.2 WEKA – Oprogramowanie do eksploracja danych w języku JAVA.......................31
4/68
5.3.3 Implementacja analizy skupień.................................................................................32
5.4 Model zachowania agenta podczas analizy klienta............................................................37
5.4.1 Graficzny model przepływu sterowania....................................................................37
5.4.2 Zapis reguł oraz wnioskowanie oparte o SWI-PROLOG.........................................40
5.4.3 Klasa Rule oraz RuleBuilder.....................................................................................45
5.4.4 Rozesłanie zapytania na temat reguł oraz analiza takiego zapytania........................46
5.4.5 Analiza odpowiedzi i zapis nowej wiedzy................................................................50
5.4.6 „Zapamiętywanie” i „zapominanie” wiedzy – klasa Supervisor...............................51
5.5 Problemy podczas projektowania i implementacji.............................................................53
6. Testowanie oraz wyniki działania systemu.............................................................................55
6.1 Testowanie mechanizmu analizy skupień...........................................................................55
6.2 Testowanie zachowania agenta...........................................................................................59
6.3 Testowanie jakości pozyskanej wiedzy..............................................................................62
7. Wnioski....................................................................................................................................63
7.1 Zaimplementowany mechanizm odkrywania wiedzy.........................................................63
7.2 Możliwości rozwoju systemu.............................................................................................63
7.3 Podsumowanie....................................................................................................................64
9. Bibliografia..............................................................................................................................66
5/68
1. Wstęp
Niniejsza praca jest kontynuacją pracy inżynierskiej pod tytułem "Zastosowanie
systemów wieloagentowych w systemach zarządzania relacjami z klientem". Celem od samego
początku było zbudowanie systemu, który byłby podstawą do stworzenia systemu zarządzania
doświadczeniem klienta (z ang. Customer Experience Management, w skrócie CEM).
Idea zarządzanie doświadczeniem klienta idzie o krok dalej niż CRM. Stawia ona na
indywidualne podejście do klienta i branie pod uwagę nie tylko transakcji ale także odczuć
klienta względem firmy oferującej usługę. Potrzebne jest przez to całkowicie nowe podejście
podczas realizacji systemu mającego wspierać ten proces.
Jednym z możliwych sposobów, zbliżenia się do CEM jest zaproponowane przeze mnie
zintegrowanie tradycyjnego systemu zarządzania relacjami z klientem z systemem
wieloagentowym. Każdemu z klientów przydzielony został odpowiedzialny za niego agenta,
który analizował jego poczynanie. Wewnątrz każdego z agentów realizowane było proste
wnioskowanie, które miało na celu podjęcie decyzji o zaproponowaniu (lub nie)
odpowiedniego produktu. System powstał w dwóch wersjach. Jedna z nich realizowała
wnioskowanie z użyciem wnioskowania pierwszego rzędu. Druga oparta była o drzewo
decyzyjne.
Integracja została zbudowana z wykorzystaniem systemu vTiger CRM. Jest to
rozpowszechniany na zasadach Open Source, popularny darmowy system CRM. Środowisko
wieloagentowe powstało w oparciu o framework Java Agent DEvelopment Framework.
Głównym celem pracowni inżynierskiej była integracja obu środowisk. System, który
był efektem pracy był dlatego jedynie podstawą do stworzenia rzeczywistego systemu CEM.
Posiadał on bardzo wiele istotnych ograniczeń. Dwa największe z nich to:
1. Agenty nie były w stanie dostrzec istnienia innych agentów. Przez to gdy agentowi
brakowało informacji nie był on w stanie w żaden sposób ich uzyskać – jedynie poprzez
dostarczenie ich przez użytkownika.
6/68
2. Silnik wnioskujący oparty był o The Java Embedded Object Production System, który
wymagał wcześniejszego skompilowania reguł, co sprawiało że raz wpisane reguły
działały od uruchomienia systemu aż do samego końca (nawet jeżeli ich skuteczność
byłą bardzo niska).
W czasie pracowni dyplomowej magisterskiej moim celem było wyeliminowanie tych
ograniczeń. Pierwsze miało zostać wyeliminowane, poprzez zaimplementowanie mechanizmu
powstawania sieci agentów. Każdy agent powinien być w stanie znaleźć podobnych do niego
agentów (z wykorzystaniem mechanizmu klasyfikacji) i w wypadku braku jakiś informacji
postarać się je uzyskać.
Ponieważ rozwój systemu był przewidziany podczas tworzenia pierwotnej wersji,
charakteryzuje się on modularnością. Dzięki temu możliwa była wymiana systemu
wnioskowania. Aby system miał możliwość modyfikacji reguł, postanowiłem skorzystać z
jednej z najpopularniejszych implementacji języka Prolog – SWI Prolog.
Wynikiem pracowni jest działający system oraz niniejszy dokument. Ponieważ niniejsza
praca jest kontynuacją pracowni dyplomowej inżynierskiej część zagadnień teoretycznych
została pominięta,
7/68
2. Maszyna wnioskująca oparta o język PROLOG
2.1 Rachunek predykatów pierwszego rzędu
Obecnie istnieje bardzo wiele rodzajów zapisu wiedzy. Jedną z nich jest rachunek zdań.
Jest on częścią logiki formalnej, zajmująca się formami wnioskowania zbudowanymi wyłącznie
ze
zmiennych
zdaniowych
(zdań)
oraz
funktorów
prawdziwościowych
(spójników
zdaniowych). Początki rachunku zdań sięgają czasów starożytnych (III wiek p.n.e.). Jednym z
najwybitniejszych matematyków tamtej epoki był Chryzyp (jako pierwszy przyjął założenie, że
zdania mogą przyjmować jedynie dwie wartości logiczne - prawdę lub fałsz, stworzył pojęcie
dysjunkcji).. Właściwy rozwój rozpoczął się jednak dopiero w połowie XIX wieku. Za twórcę
logiki matematycznej uznaje się angielskiego matematyka Georga Boole'a (od którego
nazwiska pochodzi Algebra Boole'a).
Podstawowymi elementami rachunku zdań są zmienne zdaniowe (zapisywane
tradycyjnie jako p, q, r, s, itd.) [13]. Z pomocą funktorów możemy z nich tworzyć nowe zdania
i funkcje zdaniowe takie jak:
•
p i q, (koniunkcja oznaczana symbolem ∧)
•
p lub q, (alternatywa oznaczana symbolem ∨)
•
jeśli p, to q, (implikacja oznaczana symbolem ⇒)
•
p wtedy i tylko wtedy, gdy q, (równoważność oznaczana symbolem ⇔)
•
nie p (negacja oznaczana symbolem ~).
Ważnym pojęciem w rachunku zdań są również tautologie. Są to zdania złożone, które
są zawsze prawdziwe bez względu na wartości logiczne zdań, z których zostały zbudowane.
Tautologie mogą być zarówno proste i dotyczyć jednego zdania (jak na przykład: prawo
tożsamości dla implikacji: p ⇒ p lub prawo podwójnego przeczenia: p ⇔ ~(~p)) lub złożone
(ma przykład prawa De Morgana: ~(p ∨ q) ⇔ (~p ∧ ~q) oraz ~(p ∧ q) ⇔ (~p ∨ ~q)).
8/68
Podstawowy
rachunek
zdań
może
być
rozszerzony
poprzez
wprowadzenie
kwantyfikatorów. W matematyce kwantyfikatorem nazywamy wyrażenie "dla każdego
elementu" (kwantyfikator ogólny) lub "istnieje taki element" (kwantyfikator szczegółowy).
Rachunek predykatów pierwszego rzędu – (ang. first order predicate calculus), zwany
także rachunkiem kwantyfikatorów, to system logiczny, w którym zmienna, na której oparty
jest kwantyfikator, może być elementem pewnej wybranej dziedziny (zbioru), nie może
natomiast być zbiorem takich elementów []. Podobnie ja w przypadku rachunku zdań możemy
tu wyróżnić tautologie.
Na rachunku predykatów pierwszego rzędu, ograniczonym do klauzuli Horna (klauzula,
w której co najwyżej jeden element jest niezanegowany), oparty jest język programowania
logicznego – Prolog.
9/68
2.2 Język PROLOG
Język PROLOG jest należącym do klasy języków deklaratywnych, językiem
programowania opartym na prostych mechanizmach takich jak dopasowywanie do wzorca lub
drzewiastych strukturach danych. Jest on bardzo dobrze dostosowany do opisywania relacji
między
obiektami.
Dzięki
temu,
stał
się
jednym
z
popularniejszych
języków
wykorzystywanych w kontekście sztucznej inteligencji. Jego dodatkowym atutem, jest bardzo
prosty zapis programu, co w porównaniu z innymi – czasami bardzo skomplikowanymi –
językami przetwarzania symbolicznego sprawia, że Prolog jest bardzo popularny i bardzo
chętnie wykorzystywany.
PROLOG (nazwa pochodzi od "Programming in logic", z ang. programowanie w
logice) zaczął powstawać w latach 70. kiedy postanowiono używać logiki jako języka
programowania. Naukowcy, którzy mieli największy wpływ na kształtowanie to Robert
Kowalski (od strony teoretycznej), Maarten van Emden (prezentacja eksperymentalna) oraz
Alain Colmerauer (implementacja). Kolejnym przełomowym momentem w historii języka było
powstanie CLP (constraint logic programming). W 1996 roku opublikowany został standard
ISO dotyczący języka Prolog.
Programowanie w języku PROLOG możemy podzielić na 3 etapy [13]:
1. Deklarowania Faktów dotyczących obiektów i związków między nimi.
2. Definiowania Reguł dotyczących obiektów i związków między nimi.
3. Zadawania pytań o obiekty i związki między nimi.
10/68
2.3 Zapis faktów i reguł w języku PROLOG
Podstawowym atomem zapisu wiedzy w języku Prolog jest fakt. Przykładowo faktem
zapisanym w języku prolog może być zdanie: „Jest niedziela”. Ten zapis wygląda następująco:
niedziela.
Jest to najprostszy możliwy zapis w PROLOGu. Istnieją również fakty wieloargumentowe
zapisywane jako relacja(< argument1 >,< argument2 >,....,< argumentN >), gdzie słowo relacja
trzeba zastąpić nazwą pełnionej przez predykat czynności. Przykładem wieloargumentowego
faktu w języku PROLOG jest zapis zdania: „Andrzej lubi jabłka”:
lubi(andrzej, jabłka).
Zapytania w języku PROLOG są składane w identyczny sposób jak zapis faktów. Aby uniknąć
nieporozumień zazwyczaj przy ich zapisie dodawany jest charakterystyczny dla języka
PROLOG promt powłoki: „?-”. Zapis pytania czy Andrzej lubi wygląda identycznie jak zapis
faktu, poprzedzony przez „?-”. Na to pytanie otrzymamy odpowiedź yes, gdyż PROLOG
znajdzie dopasowanie w bazie faktów. W przypadku gdy zapytamy czy Michał lubi jabłka
odpowiedzią będzie no - ponieważ PROLOG nie ma żadnej informacji na temat Michała.
Zadając pytania nie musimy mieć ukonkretnionej wiedzy na temat wszystkich
argumentów. Jesteśmy w stanie zadać pytanie: Kto lubi jabłka? W tym przypadku musimy
zastosować zmienną. Zmienne w języku PROLOG charakteryzują się nazwą rozpoczynającą
się od wielkiej litery. Zapis wcześniej przytoczonego pytania będzie więc wyglądał:
?- lubi(Kto, jabłka).
11/68
W przypadku większej ilości faktów i wielu dopasowań, PROLOG jest w stanie zwrócić nam
wszystkie osoby, które lubią jabłka.
Aby zapisać bardziej złożone relacje konieczne jest skorzystanie z reguł. Zdanie
„Wszystkie jabłka to owoce” zapisane za pomocą reguły będzie wyglądało następująco:
owoc(X) :- jabłko(X).
Zdanie to można odczytać jako „X jest owocem jeśli X jest jabłkiem”. Jeżeli po tej regule
zamieścimy fakt mówiący o tym, że Renata to rodzaj jabłek, będziemy w stanie zadać
PROLOGowi pytanie o to czy Renata to owoc. Otrzymamy odpowiedź twierdzącą.
W zapisie reguł można też zastosować operator AND. Jest to wykonywane przy użyciu
przecinka. Reguła mówiąca: „Coś jest smaczne jeżeli jest owocem i jest słodkie” może być
zapisana:
smaczne(X) :- owoc(X), słodki(X).
Operator logiczny lub nie posiada swojego odpowiednika. Możliwe jest jednak zapisanie
dwóch reguł na ten sam temat. Przykładowo jeżli chcielibyśmy zapisać regułę mówiącą: „Coś
jest smaczne jeżeli jest owocem i jest słodkie lub jeśli jest czekoladowe” należy to zrobić
dopisując poniżej poprzedniej reguły drugą:
smaczne(X) :- owoc(X), słodki(X).
smaczny(X) :- czekoladowy(X).
W napisanym w ten sposób programie mamy więc dwie drogi do udowodnienia, że coś jest
smaczne. Należy pamiętać że wewnątrz jednej reguły tak samo nazwane zmienne będą
traktowane jako jedna zmienna. W obrębie dwóch reguła tak samo nazwane zmienne
traktowane są jako oddzielne zmienne.
12/68
2.4 Implementacja języka PROLOG: SWI-Prolog
SWI-Prolog jest udostępnianą na zasadzie wolnego oprogramowania implementacją
języka PROLOG. SWI-Prolog powstał i jest wciąż rozwijany od 1987 roku. Jego głównym
autorem jest Jan Wielemaker. Nazwa SWI pochodzi z języka holenderskiego i jest skrótem od
Sociaal-Wetenschappelijke Informatica ("Społeczno naukowa informatyka"). Jest to nazwa
koła naukowego na uniwersytecie w Amsterdamie, do którego należał autor. Obecnie
implementacja została już przygotowana na wszystkie wiodące systemy operacyjne.
Główną zaletą SWI-Prolog jest duża ilość zaimplementowanych dodatków. Są to
między innymi interfejs graficzny, biblioteki wspomagające
CPL, wielowątkowość,
wbudowany edytor skryptów zaznaczający składnie języka PROLOG (PceEmacs) oraz co
bardzo ważne w mojej pracy dwukierunkowy interfejs pomiędzy PROLOG'iem i językiem
JAVA.
Ilustracja 1: Interfejs gaczny SWI-Prolog
13/68
JPL (A Java Interface to Prolog) jest zbiorem klas napisanych w języku Java oraz
funkcji napisanych w języku C, które umożliwiają obustronną komunikację. JPL wykorzystuje
macierzysty interfejs programistyczny dla języka Java (Java Native Interface - JNI) aby
połączyć się z maszyną wnioskującą języka PROLOG poprzez Prolog Foreign Language
Interface (FLI), który jest ustandaryzowany dla różnych implementacji języka PROLOG.
Ilustracja 2: Edytor graficzny domyślnie instalowany wraz z SWI-PROLOG
14/68
3. Mechanizmy interakcji w systemach
wieloagentowych
3.1 Systemy wieloagentowe
Agenty egzystują w bardzo zróżnicowanych środowiskach, mogą być one zamknięte lub
otwarte, mogą zawierać inne agenty lub nie. Istnieją sytuacje w których agent może działać
sam, jednak zwiększone rozproszenie sieci i wszechobecność połączeń internetowych czyni
taką sytuację rzadkością a interakcja między agentami stała się czymś normalnym.
Systemy
w
których
współpracuje
wiele
agentów
są
nazywane
systemami
wieloagentowymi [12]. Charakteryzują je następujące cechy:
1. Środowiska wieloagentowe zapewniają infrastrukturę pozwalającą na komunikację i
interakcję między agentami
2. Środowiska wieloagentowe są zazwyczaj otwarte (nie jest to warunek konieczny)
3. Środowiska wieloagentowe zawierają agenty autonomiczne i rozproszone, które mogą
być zarówno nastawione na wypełnianie własnych celów jak i na kooperacje.
Agenty w systemach wieloagentowych mogą wchodzić w interakcje na wiele różnych
sposobów
–
zazwyczaj
według
ustalonego
przez
programistę
protokołu.
Dwoma
charakterystycznymi rodzajami takich protokołów są aukcje i negocjacje. Agenty mogą się
komunikować bezpośrednio za pomocą wiadomości lub też przy wykorzystaniu tablicy.
15/68
3.2 Aukcje
W XXI wieku, niezbyt popularne to tej pory aukcje zdominowały sprzedaż towarów w
internecie (allegro, ebay). Jedną z przyczyn tego stanu rzeczy, jest prosty scenariusz interakcji
podczas aukcji. Oznacza to także, że w łatwy sposób można zautomatyzować i wykorzystać w
środowisku wieloagentowym [14].
Aukcja odbywa się pomiędzy jednym agentem – licytatorem – a grupą agentów –
oferentami. Celem licytatora jest dostarczenie towaru z maksymalnym zyskiem, natomiast
oferentów uzyskanie towaru z jak najmniejszym kosztem. Oczywiście aukcja przebiega według
wcześniej ustalonych reguł.
Mimo niezbyt skomplikowanego modelu podczas projektowania aukcji pod uwagę
należy wziąć wiele czynników, takich jak na przykład: kto zwycięża aukcje i za ile zostaje
sprzedany dany towar, czy uczestniczący w aukcji oferenci znają oferty swoich konkurentów
oraz sam proces zgłaszania ofert. Możemy wyróżnić cztery podstawowe rodzaje aukcji:
1. Aukcje angielskie – są to tradycyjne aukcje kiedy licytator podaje początkową cenę za
przedmiot a oferenci kolejno składają coraz wyższe oferty. Jeżeli żaden z oferetnów nie
postanowi zaoferować więcej niż obecne maksimum, towar zostaje sprzedany
ostatniemu oferentowi który złożył ofertę za cenę, którą zaoferował.
2. Aukcje holenderskie – licytator podaje maksymalną cenę za przedmiot, zazwyczaj
bardzo wysoką. Następnie stopniowo obniża cenę, aż znajdzie się oferent skłonny
złożyć ofertę. Towar sprzedawany jest natychmiast po złożeniu pierwszej oferty.
3. Aukcje jednorazowe – jest to aukcja, w której mamy do czynienia tylko z jedną rundą
licytacji. Oferenci proponują cenę po czym przedmiot jest sprzedawany temu kto
zaproponował najwięcej.
16/68
4. Aukcja w systemieVickrey'a – oferenci w jednej rundzie składają oferty. Przedmiot jest
sprzedawany temu kto zaoferował najwięcej, ale za cenę którą zaproponował drugi w
kolejności oferent.
3.3 Negocjacje
Aukcje są bardzo przydatną techniką alokacji towarów i zasobów przez agentów, jednak
w wielu przypadkach są zbyt uproszczone aby korzystać z nich w innych przypadkach.
Bardziej złożonym mechanizmem interakcji między agentami, które posiadają różne cele są
negocjacje [14].
Poprzez negocjacje należy rozumieć interakcje między dwoma lub większą ilością
agentów, podczas której agenty przedstawiają swoje cele, a następnie wspólnie opracowują
strategię działania, dzięki której będą w stanie uzyskać jak największy zysk. Przy projektowa
negocjacji trzeba więc wziąć pod uwagę: język jakim porozumiewają się agenty, protokół
negocjacji oraz sposób podejmowania decyzji. Należy też pamiętać, że negocjacje nie mogą
zachwiać działania całego systemu, dlatego powinny być:
•
Wydajne: agenty nie powinny marnować zasobów na dojście do porozumienia.
•
Stabilne: żaden agent nie powinien mieć motywacji do odejścia od uzgodnionej
strategii.
•
Proste: mechanizm negocjacyjny powinien mieć niskie zapotrzebowanie obliczeniowe
•
Rozdystrybuowane: mechanizm nie powinien posiadać centralnego decydenta.
17/68
•
Symetryczne: mechanizm nie powinien być stronniczy wobec żadnego agenta z
żadnych przyczyn.
Negocjacje składają się z 4 podstawowych czynników:
1. Zbiór możliwości jakie może zaproponować agent
2. Protokół określający legalność propozycji
3. Zbiór strategi według których może postępować agent
4. Reguły stwierdzające czy obie strony są w stanie zgodzić się na propozycje
Duża ilość kombinacji tych czterech parametrów powodują że negocjacje stają się
bardzo skomplikowanym procesem.
W systemach wieloagentowych możemy wydzielić dwie grupy negocjacji. Pierwszą z
nich są negocjacje zorientowane na cel. Agenty starają się wtedy wspólnie osiągnąć założone
cele. Drugą grupą negocjacji są negocjacje zorientowane na wartość. Agenty dążą tu do
osiągnięcia jak największej wartości, co nie musi być jednoznaczne z osiągnięciem celu.
18/68
3.4 Systemy tablicowe
Używanie tablicy bardzo często obrazowane jest poprzez metaforę, w której grupa
specjalistów rozwiązuje problem z użyciem tradycyjnej tablicy [12]. Specjaliści zamieszczają
problemy na tablicy, a gdy któryś z nich zauważy, że posiada wystarczającą ilość informacji do
rozwiązania problemu lub jego części - robi to. Dzięki temu na tablicy pojawiają się wciąż
nowe informacje i proces może być kontynuowany. Dzieje się tak do momentu, gdy wszystkie
problemy zostaną rozwiązane.
Ilustracja 3: Urproszczony schemat działania tablicy
Ta metafora w bardzo dobry sposób reprezentuje kilka ważnych cech systemów
wykorzystujących tablicę. Po pierwsze agenty muszą działać niezależnie. Muszą też
porozumiewać się wspólnym językiem, dzięki czemu każdy zrozumie problem innych agentów.
Można również zauważyć że akcje wykonywane przez agentów są wyzwalane przez inne
zdarzenia. Oczywiście w tym przypadku konieczny jest także jakiś system kontroli decydujący
o tym, które informacje ponownie znajdą się na tablicy. Jak można
łatwo zauważyć
rozwiązania problemów z wykorzystaniem tablicy powstają inkrementalnie.
19/68
3.5 Mechanizmy komunikacji między agentami w JADE
Jedną z najważniejszych cech JADE jest zaimplementowana możliwość komunikacji
między agentami. Jest ona zrealizowana za pomocą asynchronicznych wiadomości. Każdy
agent posiada własny bufor wiadomości (w postaci kolejki) gdzie środowisko JADE umieszcza
wiadomości przesłane przez innych agentów. Za każdym razem gdy wiadomość jest
umieszczana w kolejce agent-odbiorca jest o tym informowany. Kiedy agent ma pobrać
wiadomość z kolejki i w jaki sposób ma ją przetworzyć zależy już od programisty.
Ilustracja 4: Schemat obsługi asynchronicznych wiadomości w JADE
Wiadomości wykorzystywane przez agentów w JADE mają format określony przez
język ACL, zdefiniowany przez FIPA (Foundation for Intelligent Physical Agents – organizacja
zajmująca się opracowywaniem standardów dla programowania agentowego). Standard
określa, że wiadomość składa się z niezwiązanych ze sobą pól, między innymi:
•
Nadawca wiadomości
•
Lista odbiorców wiadomości
20/68
•
Intencje wysyłanej wiadomości wskazującą co nadawca chce osiągnąć poprzez wysłanie
wiadomości. Intencjami mogą być na przykład:
◦ REQUEST – gdy nadawca chce aby odbiorca wykonał jakąś akcje,
◦ INFORM – gdy nadawca wysyła informacje,
◦ CFP (call for proposal), PROPOSE, ACCEPT_PROPOSAL, REJECT_PROPOSAL
– jeżli nadawca i odbiorca zaangażowani są w negocjacje,
•
Zawartość wiadomości
•
Składnie zawartości (nadawca i odbiorca muszą być w stanie przeprowadzić parsowanie
wiadomość)
•
Ontologie
Wiadomość w JADE jest zaimplementowana jako obiekt przygotowanej wcześniej
klasy jade.lang.acl.ACLMessage, która zapewnia obsługę zestawu metod get i set, służących do
obsługi wszystkich pól zawartych w wiadomości.
Obsługa tablicy (często zwanej żółtymi stronami) jest w JADE zrealizowana poprzez
agenta DF (Directory Facilitator). Każda uruchomiona platforma JADE zawiera domyślnego
agenta DF.
21/68
4. Klasyfikacja danych jako narzędzie budowy
sieci agentów
4.1 Klasyfikacja
Klasyfikacja (zwana też analizą skupień, z ang. Cluster analysis), polega na przypisaniu
obiektów ze zbioru do grup (skupień, klastrów), tak aby obiekty w tym samym klastrze były do
siebie jak najbardziej podobne i jak najbardziej różniły się od elementów z innych klastrów.
Możemy wyróżnić kilka podstawowych rodzajów klasyfikacji:
Ilustracja 5: Reprezentacja klasyfikacji hierarchicznej
•
Klasyfikacja hierarchiczna – grupa metod polegających na zbudowaniu hierarchii
klastrów, zaczynając od grup składających się z pojedynczego elementu a kończąc na
grupie złożonej ze wszystkich elementów. Możemy wyróżnić dwie podgrupy
klasyfikacji hierarchicznej: aglomeracyjne gdzie zaczynamy od pojedynczych
22/68
elementów i łączymy je w większe grupy, oraz deglomeracyjne gdzie zaczynamy od
grupy złożonej ze wszystkich elementów i dzielimy ją na mniejsze podgrupy. Podział
na klastry w algorytmach hierarchicznych jest zazwyczaj podziałem zachłannym
(dokonuje decyzji)
•
Klasyfikacja metodą k-środków – populacja obiektów jest dzielona są na k grup a
następnie są przenoszone między nimi aby uzyskać jak najmniejszą wariancję wewnątrz
uzyskanych klas. Wynik działania algorytmu jest zazwyczaj przedstawiany w postaci
diagramu Woronoja. Złożoność klasyfikacji tą metodą jest problemem np. trudnym.
Wadą tej metody jest dążenie algorytmów do utworzenia klastrów tej samej wielkości
przez co często obiekty są przyporządkowywane do niewłaściwych klastrów.
Ilustracja 6: Diagram przedstawiający wynik metody k-środków
23/68
•
Klasyfikacja rozmyta – specyficzna metoda podobna do metody k-środków z tą różnicą
że jeden element może być przydzielony do więcej niż jednej grupy.
Klasyfikacja jest bardzo popularną metodą eksploracji danych. Znajduje też zastosowanie w
uczeniu się maszyn, rozpoznawaniu wzorców lub analizie obrazu.
4.2 Klasyfikacja w systemach rozproszonych
Analiza skupień w systemach rozproszonych jest możliwa – ale jest zdecydowanie
trudniejsza. Wciąż trwają prace nad znalezieniem najbardziej wydajnej strategii dla środowisk
rozproszonych. Zdecydowanie częstszym wyborem podczas implementacji takich algorytmów
jest podejście hierarchiczne.
W systemach rozproszonych możemy wyróżnić dwa podstawowe problemy. Jednym z
nich jest analiza skupień dla rozproszonych danych, a druga to grupowanie węzłów w grafie
przedstawiający sam system.
Przykładowym algorytmem klasyfikacji danych w systemie rozproszonym jest
zaproponowany przez naukowców algorytm RACHET []. Autorzy twierdzą że algorytm jest
wydajną metodą analizy skupień dla danych rozproszonych horyzontalnie. Podczas działania
RACHET, tworzone są lokalne dendrogramy dla każdego zbioru danych, z wykorzystaniem
tradycyjnego podejścia hierarchicznego. Powstaje też seria statystyk i opis, które mają na celu
jak najdokładniejsze scharakteryzowanie grup w dendrogramie. Aby zmniejszyć koszt
wymiany informacji przesyłany jest jedynie opis, który jest zdecydowanie mniejszy niż
całkowity klaster. Następnie lokalne dendrogramy są łączone na podstawie opisów w globalny
opis wszystkich rozproszonych informacji. Jakość tworzonych przez algorytm klastrów jest
około 30% gorsze niż w przypadku gdyby te same dane zostały przeanalizowane w centralny
sposób, ale zostało to wykonane 40% szybciej.
Drugim problemem rozproszonej klasyfikacji jest grupowanie węzłów grafu. W []
zaproponowany został algorytm DMAC (skrót od Distributed Mobility-Adaptive Clustering).
Został on przygotowany do analizy grafu w którym każdy węzeł dodatkowo ma swoją wagę.
24/68
Wprowadza on pojęcie clusterhead (przewodniczący grupy – węzeł w grupie z największą
wagą) i dzieli graf według następujących założeń:
1. Każdy węzeł ma przynajmniej jednego przewodniczącego jako sąsiada,
2. Każdy zwykły węzeł komunikuje się z sąsiadującym przewodniczącym o największej
wadze,
3. Żadnych dwóch przewodniczących nie może być sąsiadami
Przedstawiony algorytm jest algorytmem rozproszonym – jest wykonywany n każdym
węźle oddzielnie. Jego działanie w uproszczeniu wygląda następująco: każdy węzeł wysyła do
sąsiadów swoją wartość, jeżeli nie ma sąsiada o większej wartości zostaje przewodniczącym,
jeżeli ma sąsiadów o większej wartości dołącza do grupy tego, który ma większą wartość.
Klasyfikacja w systemach rozproszonych jest wciąż tematem otwartym. Przytoczone
tutaj algorytmy są tylko jednymi z wielu zaproponowanych. Wciąż trwają eksperymenty
mające na celu znalezienie optymalnych algorytmów analizy skupień.
25/68
Ilustracja 7: Wynik działania algorytmu DMAC gdzie jako kwadraty oznaczeni
zostali przewodniczący grup
26/68
5. Rozbudowa systemu wieloagentowego
5.1 Funkcjonalności systemu MASforCRM powstałego podczas
pracowni dyplomowej inżynierskiej
Podczas pracowni dyplomowej inżynierskiej opracowany został system nazwany
MASforCRM oparty o platformę JADE oraz system vTiger CRM. Integracja między
systemami zrealizowana została z pomocą PHP/Java Bridge.
Ilustracja 8: Podstawowe okno aplikacji
W systemie zaimplementowane zostały następujące funkcjonalności:
•
Tworzenie nowych agentów dla klientów obecnych w systemie CRM podczas
uruchamiana aplikacji.
•
Przeprowadzenie prostego wnioskowania w oparciu o silnik wnioskujący JEOPS (skrót
od The Java Embedded Object Production System) lub drzewo decyzyjne, oraz
przedstawienie wyników końcowemu użytkownikowi.
27/68
•
Reakcja systemu na podstawowe bodźce takie jak:
◦ Powstanie nowego klienta – system tworzył nowego agenta oraz przeprowadza
wnioskowaniem.
◦ Powstanie nowego produktu – system przeprowadzał wnioskowanie dla produktu.
◦ Zmiana danych na temat produktu – agenty ponownie przeprowadzały
wnioskowanie na temat produktu.
◦ Zmiana danych na temat klienta – agent odpowiedzialny za klienta ponownie
przeprowadzał wnioskowanie dla wszystkich produktów.
Ilustracja 9: Okno z wynikiem wnoiskowania wyświetlane
użytkownikowi
28/68
•
Wygenerowanie oferty sprzedażowej na podstawie wnioskowania przeprowadzonego
przez agenta.
Wszystkie zaimplementowane podczas tworzenia pracy inżynierskiej funkcjonalności są
wykorzystywane w nowszej wersji systemu. Z punktu widzenia użytkownika końcowego
systemu CRM nie zostały wprowadzone żadne zmiany.
5.2 Narzędzia wykorzystane podczas pracy
System został zbudowany w oparciu o:
•
System vTiger CRM - wersja 5.2.0
•
Framework JADE - wersja 4.2.0
•
PHP/Java Bridge – protokół umożliwiający dwukierunkową komunikację między
językiem PHP a językiem a wirtualną maszyną JAVA.
•
SWI-PROLOG – wersja 5.4.7
Jako środowisko programistyczne wykorzystane zostało narzędzie NetBeans IDE w
wersji 7.1.2. Jako narzędzia wspierające wykorzystywane były edytory PceEmacs oraz
Notepad++.
System powstał na wirtualnej maszynie zarządzanej przez system operacyjny
Windows XP. Wirtualizacja wykorzystywała narzędzie Oracle VirtualBox w wersji 4.0.2
r69518.
29/68
5.3 Budowa sieci agentów na podstawie analizy skupień
5.3.1 Projekt sieci agentów
Systemy agentowe należy ogólnie traktować jako systemy rozproszone, jednak z uwagi
że powstały system, czerpie informacje z jednej bazy danych, wydajniejsze jest potraktowanie
danych jako system centralny. Agenty, były dzielone na klastry na podstawie informacji na
temat klienta:
Podczas analizy pod uwagę brane są następujące właściwości klienta:
•
industry (Branża) – wartość tekstowa wybierana z listy podczas tworzenia nowego
klienta w systemie vTiger CRM. Wartość jest brana pod uwagę ponieważ w różnych
branżach użytkownikom potrzebne są zróżnicowane produkty.
•
annual_revenue (roczny dochód) – wartość liczbowa, klienci o zbliżonych dochodach
zazwyczaj będą zachowywali się podobny sposób.
•
employees (ilość pracowników) – wartość liczbowa, brana pod uwagę aby wykluczyć
elementy, gdy po powstaniu nowego klienta o liczbie pracowników np. 50, nie
proponować mu produktów odpowiednich dla firmy z tej samej branży ale o 1000
pracowników (np. pakietu 500 użytkowników CRM)
•
bill_country (pańtwo) – wartość tekstowa, brana pod uwagę ponieważ firmy z tych
samych krajów mogą kierować się lokalnymi trendami.
30/68
Jako metoda analizy skupień wybrana została metoda hierarchiczna. Motywacją tego
wyboru jest możliwość łatwiejszego przeniesienia tej metody na system rozproszony – gdyby
powstał system opierający się na kilku instancjach CRM.
5.3.2 WEKA – Oprogramowanie do eksploracja danych w języku JAVA
Weka (Waikato Enviroment for Knowledge Analysis) jest aplikacją stworzoną przez
grupą zajmującą się uczeniem maszyn na Uniwersytecie Waikato w Nowej Zelandii. Jest to
kolekcja zaimplementowanych algorytmów służących eksploracji danych. Mogą być one
zastosowane bezpośrednio dla zbiorów danych (dzięki zaimplementowanemu interfejsowi
graficznemu) lub mogą być wywołane z poziomu języka JAVA.
Ilustracja 10: GUI aplikacji WEKA
Weka posiada narzędzia do wstępnej analizy danych, klasyfikacji, regresji, analizy
skupień, asocjacji oraz wizualnego przedstawiania wyników. Udostępniana jest jako wolne
oprogramowanie na zasadzie licencji: GNU General Public License.
31/68
Hierarchiczna analiza skupień jest w Weka realizowana przy pomocy obiektu klasy
HierarchicalClusterer.
Posiada
ona
wiele
konfigurowalnych
parametrów
z
których
najważniejszymi są: docelowa liczba klastrów, typ połączeń między elementami, funkcja
odległości.
Ilustracja 11: WEKA - Moduł służący do eksploracji danych.
5.3.3 Implementacja analizy skupień
W celu ułatwienia prowadzenia analizy skupień w bazie danych została dodana tabela
zbierająca wszystkie dane, które są analizowane oraz unikatowy numer agenta (równoznaczny
32/68
z numerem klienta), oraz informację na temat grupy, do której przyporządkowany został agent.
Tabela została nazwana agent_client_info.
Ilustracja 12: Przykładowe dane z tabeli agent_client_info
Podczas tworzenia agenta odpowiedzialnego za klienta, agent na samym początku
pobiera z bazy danych informacje na temat swojego klienta (przy powstaniu w kolumnie
Cluster wpisywana jest wartość „-1” mówiąca o tym, że agent nie został jeszcze przypisany do
żadnej grupy) a następnie przesyła informację o swoim powstaniu do agenta odpowiedzialnego
za analizę skupień. Jest to agent zaimplementowany wyłącznie do przeprowadzania analizy
skupień o nazwie Clusterer. Agent w momencie gdy otrzyma informację od o powstaniu agenta
klienckiego, lub o aktualizacji danych na temat jednego z klientów, pobiera dane z tabeli
agent_client_info, przeprowadza analizę a następnie uaktualnia w tej samej tabeli kolumnę
Cluster dla każdego agenta.
Aby uniknąć zbyt dużych różnic między dochodami oraz liczbą pracowników
(praktycznie nie będzie dwóch klientów o podobnych atrybutach) system przed przystąpieniem
do analizy przypisuje wartości do przedziałów. Funkcjonalność ta została wprowadzona
podczas testowania analizy skupień i motywacja jej powstania zostanie dokładnie opisana w
dalszej części. Wartości są przypisywane do przedziałów w następujący sposób:
33/68
Przypisanie dochodów do przedziału:
Wartość dochodu
Przypisana wartość
>= 1000000
V1
<1000000 oraz >= 700000
V2
<700000 oraz >= 500000
V3
<500000 oraz >= 300000
V4
<300000
V5
.
Przypisanie pracowników do przedziału:
Ilość pracowników
Przypisana wartość
>= 1500
E1
<1500 oraz >= 1000
E2
<1000 oraz >= 800
E3
<800 oraz >= 400
E4
<400 oraz >= 100
E5
<100
E6
34/68
Mechanizm został wprowadzony aby przy mniejszej ilości danych klientów możliwa
była analiza skupień. Bez tego mechanizmu mechanizm klastrujący dane miał tendencję to
tworzenia jednego lub dwóch klastrów (w tym przypadku 99% klientów zostawała przypisana
do jednego klastra). Mechanizm został zbudowany poprzez użycie w zapytaniu do bazy danych
funkcji CASE.
Wprowadzanie wyniku analizy skupień bezpośrednio do bazy danych powoduje że
agenty klienckie tak naprawdę nie są świadome kto jest ich sąsiadem aż do momentu gdy
próbują nawiązać z nimi kontakt (opisane szczegółowo w dalszych rozdziałach).
Ilustracja 13: Zapytanie generujące przedziały do analizy skupień
Podczas przeprowadzania analizy skupienia wykorzystywane są następujące ustawienia
dla obiektu HierarchicalClusterer:
•
Nieograniczona liczba powstających klastrów
•
Odległość euklidesowa jako miara odległości między elementami
•
Połączenie pełne (każdy element może znaleźć się w grupie z każdym)
35/68
Agent Cluster wszystkie swoje zachowania zapisuje w pliku logu. Zapisuje on ilu agentów jest
obecnie analizowanych oraz do jakiej grupy został aktualnie przypisany dany agent.
Przykładowy fragment logu wygląda Clusterer wygląda następująco:
2012/09/10 14:40:44 Starting Clustering Process
2012/09/10 14:40:46 Number of analyzed agent: 18
2012/09/10 14:40:46 Number of clusters created: 2
2012/09/10 14:40:46 Agent: 10. Atrybuty: Apparel, 100000.0, Italy, 0.0. Cluster: 0
2012/09/10 14:40:46 Agent: 12. Atrybuty: Energy, 100000.0, USA, 0.0. Cluster: 0
2012/09/10 14:40:47 Agent: 125. Atrybuty: --None--, 1.0E7, Poland, 0.0. Cluster: 0
2012/09/10 14:40:47 Agent: 126. Atrybuty: --None--, 1.0E7, France, 0.0. Cluster: 0
2012/09/10 14:40:47 Agent: 127. Atrybuty: --None--, 1.0E7, USA, 0.0. Cluster: 0
2012/09/10 14:40:47 Agent: 134. Atrybuty: Chemicals, 5436630.0, Germany, 123.0.
Cluster: 1
Cluster: 1
Cluster: 1
36/68
Ilustracja 14: Wizualizacja procesu analizy skupień
5.4 Model zachowania agenta podczas analizy klienta
5.4.1 Graficzny model przepływu sterowania
Cykl życia systemu rozpoczyna się od utworzenia nowych agentów (po jednym dla
każdego klienta w systemie CRM). Całe działanie systemu opiera się jednak na poczynaniach
poszczególnych autonomicznych agentów. Agenty w systemie są agentami reaktywnymi
37/68
(czekają na bodziec z zewnątrz zanim rozpoczną działanie). Rozpoczynają analizę w momencie
gdy dociera do nich informacja na temat:
1. Zmiany danych klienta (w tym przypadku uaktywnia się jeden odpowiedzialny za niego
agent)
2. Zmiany danych produktu (uaktywniają się wszyscy agenci i przeprowadzają analizę dla
tego jednego produktu).
W kolejnych rozdziałach pracy kolejno opisane zostaną wszystkie kroki dokonywane
przez agenta, w tym od powstania do przeprowadzenia analizy zakończonej zaproponowaniem
(lub nie klientowi danego produktu). Ponieważ w tworzonym systemie najważniejsza jest
koncepcja funkcjonalności zostaną omówione na tym poziomie, tylko w koniecznych
przypadkach odwołując się do poziomu klas i metod.
38/68
Ilustracja 15: Schemat działania Agenta podczas wnioskowania
39/68
5.4.2 Zapis reguł oraz wnioskowanie oparte o SWI-PROLOG
Każdy z agentów odpowiedzialnych za klienta posiada własny plik z zapisem reguł,
według których podejmuje decyzje na temat swojego klienta (nazwa pliku tworzona jest
według schematu: AGENTXXXXX.pl gdzie XXXXX to numer klienta, za którego
odpowiedzialny jest agent natomiast .pl to domyślne rozszerzenie plików napisanych w języku
PROLOG). Podczas tworzenia nowego agenta, plik ten jest tworzony jako kopia pliku z
bazowymi regułami. Sprawia to że na początku reguły dla wszystkich agentów są takie same i
dopiero po utworzeniu nowych reguł przez agentów może się rozpocząć wymiana informacji.
System podczas tworzenia agentów sprawdza czy plik reguł dla danego agenta już istnieje.
Pozwala to nie tracić nabytej lub utworzonej wiedzy w wyniku awarii lub restartu systemu.
Podczas wnioskowania użyte są te same parametry co w przypadku analizy skupień – z
wyłączeniem branży. Dodatkową informację jest cena produktu, który chcemy zaoferować
klientowi. Podczas zadawania zapytań z poziomu aplikacji cena podawana jest liczbowo.
Wśród bazowych reguł zapisany jest zbiór za przyporządkowanie wartości do odpowiednich
przedziałów:
expensive(X) :- X>9999.
normal_price(X) :- X>999 , X<10000.
cheap(X) :- X < 1000.
Podane literały są następnie wykorzystywane w regułach dotyczących czy oferta na
produkt ma być złożona czy też nie.
W podobny sposób opisane są dwie kolejne wartości liczbowe brane pod uwagę
podczas analizy czyli roczny dochód klienta oraz liczba pracowników:
Dochód:
rich(X) :- X > 999999.
medium(X) :- X >199999 , X < 1000000.
poor(X) :- X < 200000.
40/68
Liczba pracowników:
big_company(X) :- X > 999.
medium_company(X) :- X < 1000 , X > 99.
small_company(X) :- X < 100.
W podobny sposób realizowany jest przypisanie krajów do stref regionalnych, w
podziale na Europę Wschodnią, Europę Zachodnią, Azję, Amerykę np.:
strefa(asia, japan).
strefa(e_europe, poland).
strefa(w_europe, poland).
Po przeprowadzeniu wnioskowania na temat klienta system analizuje czy danemu
klientowi zaproponować dostępny w asortymencie produkt. Aplikacja w tym procesie korzysta
z trzech typów reguł:
1. Reguła „offer” - jest to reguła, która mówi o tym że dany produkt, którego dotyczy
zapytanie powinien być zaoferowany klientowi.
2. Reguła „no_offer” - reguła mówiąca o tym że dany produkt, którego dotyczy zapytanie
nie powinien być oferowany klientowi.
3. Reguła „new_offer” - jest to reguła, zasadniczo spełniająca tę samą funkcję co regułą
„offer”. Różnicą jest że ta oferta została stworzona przez agenta, lub otrzymał ją od
znajdującego się w tym samym klastrze innego agenta. Reguły te zostały wyróżnione,
ponieważ jeżeli agent sam stworzy wiedzę i jej nie przetestuje, to nie powinien ją
propagować innym agentom. Reguły tego typu nie istnieją w bazowym pliku reguł.
41/68
W systemie nie znalazła się reguła new_no_offer. Jest to spowodowane niemożliwością
przetestowania tej reguły (jeżeli nie zaproponujemy klientowi produkty to nigdy nie będziemy
w stanie stwierdzić czy klient odrzuci czy zaakceptuje).
Wszystkie zapisane w systemie reguły posiadają cztery argumenty, zapisane według
ustalonego wcześniej założenia, przez co konieczne jest również składanie zapytań w
odpowiednim formacie:
offer(X, Y, Z, W)
gdzie:
•
X – cena produktu,
•
Y – ilość pracowników firmy,
•
Z – roczny dochód firmy,
•
W – region z którego pochodzi firma.
Jest to wymuszone aby SWI-PROLOG był w stanie dopasować do naszego zapytania,
któryś ze wzorców znajdujących się w bazowym pliku reguł. Co za tym idzie argumenty w
regułach muszą być zapisane w identycznej kolejności. Przykładowe reguły wyglądają więc
następująco:
offer(X, Y, Z, W) :- espensive(X) , big_company(Y) , rich(Z) , strefa(asia, W).
offer(X, Y, Z, W) :- espensive(X) , medium_company(Y) , rich(Z) , strefa(w_europe, W).
offer(X, Y, Z, W) :- cheap(X) , small_company(Y) , medium(Z) , strefa(e_europe, W).
no_offer(X, Y, Z, W) :- espensive(X) , small_company(Y) , medium(Z) , strefa(na, W).
no_offer(X, Y, Z, W) :- espensive(X) , big_company(Y) , poor(Z) , strefa(sa, W).
no_offer(X, Y, Z, W) :- normal_price(X) , small_company(Y) , poor(Z) , strefa(asia, W).
Sam proces wnioskowania zachodzi trójfazowo. W pierwszy kroku system zadaje
maszynie wnioskującej zapytanie typu offer, następnie reguły no_offer a w ostatnim kroku
42/68
new_offer. Po uzyskaniu odpowiedzi z systemu PROLOG dane na temat ofert są wstawiane do
tabeli predictionsv001 zawierającej informacje na temat sugerowanych ofert (analogicznie jak
w poprzedniej wersji systemu).
Ilustracja 16: Tabela ze wstawionymi
elementami, które według agenta powinny być
zaproponowane
Podczas tworzenia zapytań z poziomu aplikacji do języka PROLOG wykorzystywany są trzy
obiekty z biblioteki jpl:
1. jpl.Query – obiekt służący do przesyłania zapytań do bazy wiedzy zapisanej w języku
PROLOG i obsługiwanej przez SWI-PROLOG
2. jpl.Term – abstrakcyjna klasa reprezentujące elementy takie jak zmienne, atomy,
wartości liczbowe itp.
3. jpl.Atom – najprostsze bezuargumentowe zdanie języka PROLOG
43/68
Podczas przeprowadzenia wnioskowania, konieczne są dwa odwołania do środowiska
SWI-PROLOG. Pierwsze z nich wskazuję na plik będzie stanowił bazę wiedzy we
wnioskowaniu i wygląda następująco:
Drugie odwołanie jest już za właściwy proces zapytania do bazy wiedzy. Na początku
konieczne jest złożenie z atrybutów klienta i produktu odpowiedniej tablicy którą będzie można
wykorzystać przy tworzeniu obiektu Query. Jest za to odpowiedzialna funkcja termBuilder,
która jako atrybuty przyjmuje ID klienta oraz ID agenta, a zwraca potrzebną tablicę i zapisuje
ją do zainicjowane zmiennej Term[] attributes. Wewnątrz funkcji pobierane są konieczne
wartości z odpowiednich tabel w bazie danych i dodawane do tablicy obiektów Term.
Następnie zwrócona przez funkcję tablica wykorzystywana jest kolejno w trzech zapytaniach.
Wszystkie trzy zapytania wykonywane są po kolei (w przypadku gdy, któraś ze
wcześniejszych reguł zwróci odpowiedź twierdzącą, dalszy proces jest przerywany) i w
zależności od uzyskanego wyniku:
•
w przypadku odpowiedzi pozytywnej na pierwsze zapytanie składa ofertę
•
w przypadku odpowiedzi pozytywnej na drugie pytanie nie składa oferty
44/68
•
w przypadku odpowiedzi pozytywnej na trzecie zapytanie składa ofertę
•
w przypadku uzyskania trzech odpowiedzi negatywnych rozsyła do sąsiadów
wiadomość z prośbą o pomoc
W odróżnieniu od wersji systemu powstałej podczas pracy inżynierskiej nie możemy tu
mówić o jakimkolwiek scenariuszu wnioskowania ponieważ reguły są generowane w trakcie
działania systemu.
Podczas testowania wykorzystane różne podstawowe pliki zawierające różne zbiory
wiedzy. Pozwoliło to obserwować proces powstawania i odkrywania nowej wiedzy.
5.4.3 Klasa Rule oraz RuleBuilder.
System poza plikami reguł przechowuje wiedzę również w pamięci. Przyśpiesza to
analizę podczas zapytania na temat reguł przez innych agentów. W tym procesie
wykorzystywane są dwie specjalnie w tym celu stworzone klasy: Rule – klasa która
reprezentuje regułę oraz klasa RuleBuilder, która jest odzwierciedleniem całego pliku reguł.
Klasa Rule jest klasą bardzo prostą. Posiada ona pola odpowiedzialne za zapis typu
reguły (pole RuleName) oraz zapisane w jednym obiekcie typu String wszystkie zdania ,
których suma daje odpowiedź tak na zapytanie, podzielone literałem ' , '. Zarówno przed i po
przecinku oddzielającym kolejne zdania znajduje się znak spacji. Jest to konwencja którą
przyjąłem ponieważ, zdecydowanie ułatwia to parsowanie zdań i pozwala uniknąć błędów, gdy
na przykład przecinek oddzielający zmienne w zdaniu. Poza typowymi funkcjami get i set,
klasa Rule posiada wyłącznie jedną metodę odpowiedzialną za parsowani. Zwraca ona tablice
obiektów typu String w której znajdują się pojedyncze zdania.
Klasa RuleBuilder odpowiada za reprezentacje całej wiedzy którą posiada agent. Jej
głównym elementem jest lista obiektów typu Rule. Zbiór reguł tworzony jest na podstawie
45/68
pliku tekstowego (opisanego w poprzednim rozdziale). Agent przed stworzeniem zbioru reguł,
wczytuje cały plik z wiedzą do jednego ciągu znaków, który jest parsowany podczas tworzenia
obiektu. Zachodzi to w dwóch etapach:
1. Na początku plik dzielony jest na poszczególne reguły. Jest to realizowane poprzez
podzielenie ciągu, podanego jako argument konstruktora, w miejscach w których
znajduje się znak '.' (kropka). Jest to znak charakterystyczny dla języka PROLOG –
zawsze kończy on zdanie lub regułę.
2. Każda reguła jest dzielona w miejscu wystąpienia ciągu znaków ' :- '. Jest to
charakterystyczny operator języka PROLOG. Pozwala on wyodrębnić typ reguł od zdań
których spełnienie świadczy o jej prawdziwości. Każda powstała w ten sposób reguła
dodawana jest do zbioru reguł agenta.
Obiekt RuleBuilder odpowiedzialny jest także za przeszukiwanie zbioru reguł gdy agent
zostanie otrzyma zapytanie od sąsiada – proces ten zostanie opisany w dalszym rozdziale.
5.4.4 Rozesłanie zapytania na temat reguł oraz analiza takiego zapytania
W przypadku uzyskanie odpowiedzi negatywnych podczas analizy wszystkich trzech
typów reguł, agent rozsyła zapytanie do wszystkich agentów znajdujących się w tym samym
klastrze z prośbą o pomoc. Zapytanie to zawiera ID produktu, który jest w danej chwili
analizowany oraz wszystkie dane na temat swojego klienta. Agent potrzebujący wiedzy,
najpierw sprawdza kto jest jego sąsiadem oraz zapamiętuje liczbę wysłanych zapytań (dopiero
po otrzymaniu wszystkich odpowiedzi przechodzi do dalszego działania).
46/68
Ilustracja 17: Działanie agenta w przypadku braku wiedzy
Cała komunikacja pomiędzy agentami realizowana jest w wykorzystaniem klasy
ACLmesage. Głównym nośnikiem informacji jest pole Content. Możliwy jest tam zapisy
wyłącznie jednego ciągu znaków, jednak w przypadku zaimplementowanego systemu,
wiadomości są proste a ich zawartość łatwa do parsowania.
Agent posiada dwie zmienne liczbowe, w których zapamiętuje liczbę sąsiadów oraz
liczbę otrzymanych odpowiedzi. Agent sygnalizuje swoje oczekiwanie na odpowiedzi
ustawieniem specjalnej flagi o nazwie „waiting” na wartość „Prawda”. Jest to bardzo ważne
ponieważ zapobiega utracie pozostałych wiadomości, które mógł otrzymać agent w okresie
oczekiwania. Ponieważ w JADE, wszystkie wiadomości są kolejkowane na zasadzie FIFO
(first in first out – oznacza to że wiadomość, która pierwsza znalazła się w kolejce pierwszą ją
opuści), agent w stanie oczekiwania mógłby zignorować wiadomości, które nie są
odpowiedziami od innych agentów. Framework nie posiada metody realizującej ponowne
wstawienie wiadomości do kolejki, dlatego agent ponownie wysyła wiadomość sam do siebie.
47/68
Agent, który otrzymał zapytanie o regułę natychmiast rozpoczyna analizę swojej
wiedzy. Służy do tego wcześniej wspomniana metoda klasy RuleBuilder i zaimplementowana
w nim metoda matchRule. Po kolei porównuje ona zdania o które padło zapytanie, ze swoją
bazy wiedzy i zwraca indeks znalezionej reguły, oraz wskaźnik pokrywających się zdań.
Wskaźnik ten jest to wartość z przedziału <0;1>obliczana jako (ilość zdań wspólnych dla obu
reguł)/(ilość zdań w regule, o którą byłą pytanie). Został on wprowadzony aby agenty mogły
rozpropagować regułę nie tylko gdy jest ona całkowicie identyczna jak zapytanie ale gdy jest
także w jakimś stopniu podobna. Podczas testowania wskaźnik ten został ustawiony na 60%.
Samo porównanie dwóch reguł odbywa się z pominięciem maszyny wnioskującej,
dlatego agent sam musi przyporządkować dane liczbowe do poszczególnych grup. Jest to
wykonywane dwustopniowo. W pierwszym kroku agent sam musi sięgnąć do bazy danych aby
sprawdzić cenę analizowanego produktu. Następnie przyporządkowuje wartości do
odpowiednich przedziałów i rozpoczyna analizę.
48/68
Ilustracja 18: Przygotowanie informacji przed porównaniem reguł
Agent swoją odpowiedź buduje w następujący sposób:
•
Jeżeli nie została znaleziona reguła spełniająca warunki zapytania wyślij wiadomość
której treścią będzie wyłącznie słowo „NO”.
•
W przeciwnym przypadku zbuduj odpowiedź według schematu: YES:XXX:DECISION
gdzie:
◦ XXX – zrzutowana na obiekt klasy String wartość wskaźnika pokrywających się
zdań
◦ DECISION: zrzutowana na String wartość 1 lub 0 gdzie 1 oznacza, że reguła
znaleziona podczas przeszukiwania wiedzy jest regułą typu „offer” lub 0 w
przypadku reguły typu „no_offer”
Ilustracja 19: Metoda odpowiedzialna za utworzenie odpowiedzi na zapytanie
49/68
5.4.5 Analiza odpowiedzi i zapis nowej wiedzy
Każdy agent kliencki posiada wewnątrz siebie listę odpowiedzi na swoją wiadomość. W
momencie gdy rozsyłane jest zapytanie, lista jest czyszczona oraz ustawiane są wspomniane
wcześniej liczba sąsiadów oraz liczba już otrzymanych odpowiedzi. Wraz z przyjściem każdej
wiadomości, oznaczonej jako odpowiedź, jej treść jest dodawana na listę odpowiedzi a
odpowiedni licznik zwiększany.
W momencie kiedy agent uzyska odpowiedzi od wszystkich sąsiadów uruchamiany jest
proces który ma za zadanie wyboru z listy odpowiedzi najlepszą z nich. Wykonuje to według
następującego algorytmu:
•
ustaw dwie zmienne pomocnicze bestMatch = 0 i bestRule = 0
•
dla każdej odpowiedzi
◦
podziel regułę według symbolu „:” dzięki czemu uzyskane zostaną
rozdzielne atrybuty
◦
sprawdź czy wartość pierwszego jest równa YES
▪
jeżeli tak sprawdź czy wartość drugiego atrybutu jest większa od
ostatniej zapamiętanej wartości zmiennej bestMatch
▪
•
zwróć
•
jeżeli tak zapamiętaj indeks reguły w zmiennej bestRule
•
jeżeli nie kontynuuj pętle
jeżeli nie kontynuuj pętle
zmienną
bestRule
zawierającą
indeks
reguły
o
największym
wskaźniku pokrywających się zdań
Następnie z dla tej reguły, na podstawie wartości 0 lub 1 przesłanej przez sąsiada
stwierdzamy czy odpowiedź jest pozytywna (powinniśmy złożyć ofertę) czy negatywna (nie
składamy oferty) decydujemy o typie reguły, jaka ma być zapisana w pliku ze zbiorem wiedzy.
Agent wywołuje po tym metodę addNewRuleToRuleSet, która jako parametry przyjmuje
wartości wszystkich atrybutów agenta używanych we wnioskowaniu oraz wartość boolowską
50/68
mówiącą o typie oferty. Reguła składa z atrybutów regułę według ustalonego schematu i
zapisuje ją w pliku.
Po zapisaniu do pliku konieczne jest również ponowne załadowanie informacji z pliku
do pamięci obiektu RuleBuilder – jest to konieczne aby agent mógł dzielić się nowo odkrytą
wiedzą.
5.4.6 „Zapamiętywanie” i „zapominanie” wiedzy – klasa Supervisor
Aby ułatwić analizę, podczas gdy oferty są oznaczane w systemie CRM jako
zaakceptowane lub odrzucone, dane na ten temat są wstawiane do specjalnie stworzonej w tym
celu tabeli: agent_offer_info. Zawiera ona wyłącznie ID klienta, ID produktu oraz zmienną
logiczną mówiącą czy ten klient zaakceptował tę ofertę czy też nie.
Jest to realizowane poprzez wyzwalacz zaimplementowany w bazie danych wyzwalacz,
który w przed zmianą danych w tabeli vtiger_salesorder, która przechowuje informacje o
złożonych ofertach (w momencie gdy status oferty zmienia się na zaakceptowaną lub
odrzuconą), wstawia odpowiednie informacje do przygotowanej wcześniej tabeli.
Ilustracja 20: Tabela agent_offer_info z
przykładowymi danymi
51/68
Za nadzorowanie nauki agenta odpowiedzialny jest posiadany przez każdego agenta
obiekt klasy Supervisor. Jest on odpowiedzialny za sprawdzanie czy poprzednie propozycje
wyznaczone przez agenta zostały zaakceptowane czy też odrzucone przez klienta i na ich
podstawie uaktualnia wiedzę. Podstawowe funkcjonalności realizowane przez Supervisora to:
1. W przypadku gdy reguła jest oznaczona jako nowa i klient przyjął zaproponowaną na
jej podstawie ofertę reguła jest oznaczana jako sprawdzona (typ reguły jest zmieniany z
„new_offer” na „offer”).
2. W przypadku gdy reguła jest oznaczona jako nowa i klient odrzucił zaproponowaną na
jej podstawie ofertę reguła jest usuwana z bazy wiedzy.
3. W przypadku gdy reguła jest oznaczona jako reguła typu „offer” a klient odrzucił
większość zaproponowanych na jej podstawie obiektów regułą jest usuwana z pliku.
4. W przypadku gdy reguła jest oznaczona jako reguła typu „no_offer” a klient
zaakceptował
ofertę
(stworzoną
przez
użytkownika
bez
udziału
systemu
wieloagentowego) , która pasuje do reguły reguła jest usuwana z pliku.
Obiekt typu Supervisor rozpoczyna działanie przed rozpoczęciem właściwego
wnioskowania. Pobiera on z tabli agent_offer_info wszystkie oderty które przyjął lub odrzucił
klient za któego odpowiedzialny jest jego agent. Następnie idąc po kolei po wszystkich ofertach
sprawdza, czy obecnie analizowana oferta może być wynikiem działania jednej z reguł (jest za
to odpowiedzialna funkcja przyjmująca jako atrybut obiekt klasy RuleBuilder).
W drugim kroku Supervisor sprawdza czy obecnie testowana reguła jest typu
new_offer. Dla reguł tego typu możliwe jest przyporządkowanie tylko jednej oferty – ponieważ
powstała ona przed złożeniem tej jednej konkretnej oferty. W przypadku jeżeli reakcja klienta
jest zgodna z wnioskiem, reguła zostaje oznaczona jako sprawdzona – tworzona jest nowa
reguła typu „offer” z analogicznymi argumentami a reguła „new_offer” usuwana jest z pliku.
52/68
W przypadku reguł typo „offer” i „no_offer” analiza jest bardziej skomplikowana.
Ponieważ dla tych reguł możliwych jest wiele stworzonych ofert, Supervisor oblicza specjalny
współczynnik poprawności reguł. Jest on obliczany jako:
Wprowadzony został tu współczynnik korygujące równy 0.61. jest to spowodowane
faktem, że w momencie gdy reguła osiągnie współczynnik poprawności <= 0.3 zostanie uznana
za nieprzydatną i usunięta z pliku. Współczynnik ten jest ważny w momencie gdy tworzony jest
nowy agent, który rozpoczyna wnioskowanie od bazowego pliku reguł. Powoduje on, że
pierwsze nieudane wnioskowanie, nie powoduje jeszcze usunięcia reguły (ponieważ: 0.61 / 2 =
0.305 co jest większe od wcześniej założonego progu).
Klasa Supervisor spełnia bardzo ważną rolę w działaniu systemu ponieważ nadzoruje
naukę agenta. Sprawdza czy tworzona przez niego wiedza ma odpowiedź w rzeczywistym
zachowaniu klienta. Zapobiega on również posiadaniu przez agenta wiedzy bezużytecznej,
która blokuje jego ciągły rozwój.
5.5 Problemy podczas projektowania i implementacji
Największym
wyzwaniem
podczas
tworzenia
systemu
było
odpowiednie
zaprojektowanie i zaimplementowanie mechanizmu dostępu do plików reguł. Dużym
problemem okazało się być brak dostępnego na zasadzie wolnego oprogramowania parsera
języka PROLOG. Aby system mógł porównywać wczytywane z pliku reguły konieczne jest
parsowanie zapisów (czy też podczas wczytywania czy już podczas analizy). Spowodowało to
że reguły w pliku muszą być zapisane w specyficzny sposób:
53/68
Każda reguła musi być zapisana w jednej linii i pomiędzy zdaniami musi być
charakterystyczny symbol ' , '. Powoduje to że zapis reguł różni się od konwencjonalnego
zapisu w języku PROLOG. System zawsze zapisuje reguły w odpowiedni sposób, jednak plik
bazowy tworzony jest przez człowieka, który może popełnić błąd co uniemożliwi agentom
prawidłowe wnioskowanie.
Zapis reguły w systemie:
offer(X, Y, Z, W) :- espensive(X) , big_company(Y) , rich(Z) , strefa(asia, W).
Konwencjonalny zapis w języku prolog:
offer(X, Y, Z, W) :espensive(X),
big_company(Y),
rich(Z),
strefa(asia, W).
54/68
6. Testowanie oraz wyniki działania systemu
6.1 Testowanie mechanizmu analizy skupień
Proces testowania systemu jest procesem trudnym. Jest to spowodowane brakiem
możliwości odwzorowania rzeczywistych zachowań klientów w warunkach laboratoryjnych.
Część danych został wygenerowana losowo z wykorzystaniem generatora losowych danych
dostępnego w internecie - http://www.generatedata.com/.
Pierwszym testowanym modułem był moduł przeprowadzający analizę skupień. Na jego
potrzeby wygenerowane zostały dane na temat klientów. Założenia podczas generowania
danych klientów wyglądały następująco:
•
Indutry – losowa wartość tekstowa z grupy: Insurance, Hospitality, Healthcare,
Government, Food & Beverage, Finance
•
revenue – losowa wartość liczbowa z grupy 100000, 300000, 600000, 900000, 1500000
•
country - losowa wartość tekstowa z grupy: Japan, China, Poland, Germany, Italy,
France, USA, Canada, Brazil, Mexico
•
employees losowa wartość liczbowa z przedziału 15 – 2000
Przeprowadzonych zostało kilka testów – przy niezadowalających wynikach
modyfikowane były parametry algorytmu analizy skupień. Przykładowy fragment arkusza z
losowo wygenerowanymi danymi wygląda następująco:
55/68
industry
Government
Healthcare
Food & Beverage
Healthcare
Insurance
Healthcare
Government
Hospitality
Hospitality
Hospitality
Insurance
Hospitality
Hospitality
Healthcare
Insurance
Hospitality
Government
Healthcare
Government
Government
Government
Food & Beverage
Healthcare
Insurance
Government
Healthcare
Government
Insurance
Government
Government
Hospitality
Food & Beverage
Government
Healthcare
Food & Beverage
Healthcare
Finance
Healthcare
Hospitality
Hospitality
Government
Hospitality
Insurance
Finance
Hospitality
Healthcare
Insurance
Hospitality
Food & Beverage
revenue
region
100000 Brazil
300000 Mexico
100000 Canad
900000 Canad
1500000 Brazil
900000 Japan
300000 Germany
100000 China
600000 Brazil
10000 Germany
1500000 Italy
10000 Germany
100000 France
600000 Japan
1500000 France
900000 USA
100000 Poland
600000 USA
900000 Italy
100000 Japan
1500000 Italy
900000 Canad
300000 Canad
1500000 Japan
100000 Germany
300000 Germany
900000 Japan
100000 USA
900000 Canad
10000 France
100000 Canad
10000 Mexico
1500000 Canad
300000 Germany
300000 Mexico
10000 Canad
10000 Canad
1500000 Canad
1500000 USA
100000 Canad
900000 Canad
100000 USA
900000 Germany
300000 Germany
100000 Germany
300000 Poland
100000 Italy
10000 France
300000 France
employees
674
1909
786
1648
463
220
346
1191
1955
585
1127
617
1234
67
553
397
421
1892
446
520
1233
779
209
1700
185
1059
1408
972
669
805
677
1613
1229
207
87
1395
71
1037
1241
1417
609
1469
34
418
1022
1798
1553
1391
1265
56/68
Analiza skupień testowana była głównie pod kątem dwóch parametrów – wielkości
próby oraz sposobu obliczania odległości między obserwacjami. Każdy test przeprowadzany
był 5 razy (dane za każdym razem generowane były od nowa). W tabeli wyników
przedstawiona jesy średnia ilość otrzymanych grup zaokrąglona do najbliższej liczby
całkowitej.
Tabela z opisem testów:
LP. Zastosowana miara odległości
Wielkość próby
1 Odległość euklidesowa
100
2 Kwadratowa odległość euklidesowa
100
300
300
500
500
1000
1000
1500
1500
Wynik testów:
LP
Liczba grup
1 2
2 4
3 5
4 9
5 9
6 13
7 16
8 20
9 22
10 31
57/68
Podczas testowania analizy skupień wprowadzony został mechanizm przydzielania
wartości kolumn revenue i employees do przedziałów. Zostało to spowodowane dwoma usilnie
zauważalnymi trendami:
1. Podczas analizy tworzone były dwie grupy z czego 95% obserwacji przypisywanych
było do jednej a pozostałe 5% do drugiej.
2. Stworzenie liczby grup bliskiej liczbie obserwacji i przyporządkowanie 95% osobników
do grup składających się z jednego osobnika (w tym przypadku możliwe było
wprowadzenie maksymalnej liczby wygenerowanych grup, jednak wtedy wyniki nie
byłyby zgodne z oczekiwaniem).
Jest to prawdopodobnie spowodowane rozkładem danych. W rzeczywistości jesteśmy w
stanie zauważyć pewne prawidłowości w danych. Przy danych wygenerowanych z użyciem
losowego generatora nie ma tego. Analiza skupień jest jedną z metod odkrywania wiedzy – w
danych wygenerowanych losowo tej wiedzy nie ma. Obserwacje były w równym stopniu
odległe co podobne do siebie Aby przeciwdziałać wprowadzony został wymieniony wcześniej
mechanizm.
Drugim sposobem przeciwdziałania temu zjawisku była zmiana miary odległości
między obserwacjami. Testowane były następujące miary odległości dostępne w bibliotece
WEKA:
•
Odległość euklidesowa
•
Kwadratowa odległość euklidesowa
•
Odległość Czebyszewa
•
Odległość Manhattan
58/68
W porównaniu z bazową odległością (euklidesową) zdecydowaną poprawę procesu
klasyfikacji dała tylko kwadratowa odległość euklidesowa. Jest to prawdopodobnie
spowodowane zwiększeniem odległości między obserwacjami przez co zwiększona została
także ich różnorodność.
6.2 Testowanie zachowania agenta
Ponieważ tworzony podczas pracowni dyplomowej magisterskiej system, był
rozwinięciem działającego już systemu, konieczne było jedynie przeprowadzenie testów
nowych funkcjonalności. Przykładowe testy, które zostały wykonane w celu sprawdzenia
poprawności nowych funkcjonalności.:
Test 1 – Wnioskowanie na podstawie reguł zapisanych w pliku bazowym
Oczekiwany efekt: Zaproponowanie lub nie klientowi produktu
Kroki testu:
1. Utworzenie w systemie nowego klienta o ustalonych parametrach
2. Utworzenie w systemie nowego produktu o ustalonych parametrach
3. Podłączenie do SWI-PROLOG
4. Otrzymanie odpowiedzi true dla wybranej reguły
Status testu: Zaliczony
59/68
Test 2 – Zapytanie innych agentów o wiedzę
Oczekiwany efekt: Rozesłanie do innych agentów zapytania i oczekiwanie na odpowiedź
Kroki testu:
1. Utworzenie 5 klientów w systemie CRM.
2. Ustawienie parametrów 3 klientów aby znaleźli się w jednej grupie
3. Przeprowadzenie grupowania
4. Podłączenie do SWI-PROLOG
5. Otrzymanie odpowiedzi false dla wszystkich reguły
6. Pobranie z bazy danych informacji o sąsiadach
7. Wysłanie wiadomości do sąsiadów
8. Otrzymanie ilości odpowiedzi równej ilości wysłanych zapytań
Test 3 – Otrzymanie zapytania o wiedzę
Oczekiwany efekt: Odesłanie odpowiedzi z regułą lub negatywnej
Kroki testu:
1. Otrzymanie zapytania
2. Sprawdzenie czy istnieje reguła dla otrzymanych atrybutów
3a. Jeżeli nie odesłanie odpowiedzi negatywnej
3b. Sprawdzenie czy reguła ta jest regułą „offer” lub „no_offer”
4a. Jeżeli reguła jest typu „no_offer” odesłanie odpowiedzi negatywnej
5 Obliczenie wskaźnika pokrywających się zdań
6a. Jeżeli wskaźnik spełnia warunek wysłania odeślij odpowiedź
twierdzącą
6. Jeżeli wskaźnik nie spełnia warunku wysłania odeślij odpowiedź
negatywną
Test 4 – Analiza odpowiedzi na zapytanie z których chociaż jedna jest pozytywna
Oczekiwany efekt: Decyzja o stworzeniu nowej reguły na podstawie odpowiedzi
Kroki testu:
1. Wybranie spośród odpowiedzi tę o najwyższym wskaźnika
pokrywających się zdań
2. Sprawdzenie czy reguła powinna być typu „offer” czy typu „no_offer”
3. Stworzenie nowej reguły
4. Przeprowadzenie wnioskowania
60/68
Test 5 – Analiza odpowiedzi na zapytanie z których chociaż jedna jest pozytywna
Oczekiwany efekt: Decyzja o stworzeniu nowej reguły
Kroki testu:
1. Stworzenie nowej reguły typu „offer”
2. Przeprowadzenie wnioskowania
Test 6 – Sprawdzenie pokrycia reguł dla reguł „offer” w przypadku niskiej skuteczności
reguły
Oczekiwany efekt: Ewentualne usunięcie reguły i rozesłanie zapytań o nową wiedzę
Kroki testu:
1. Uzupełnienie bazy ofert aby otrzymać odpowiednie warunki
początkowe
2. Pobranie z bazy danych wyników ofert pasujących do reguły przez
obiekt Supervisor
3. Obliczenie współczynnik poprawności reguł
4. Usunięcie reguły z pliku
5. Rozesłanie zapytania o nową wiedzę
Test 7 – Sprawdzenie pokrycia reguł dla reguł „new_offer”
Oczekiwany efekt: Ewentualne usunięcie reguły i rozesłanie zapytań o nową wiedzę
Kroki testu:
2. Pobranie z bazy danych wyników ofert pasujących do reguły przez
obiekt Supervisor
3. Obliczenie współczynnik poprawności reguł
4a. W przypadku stwierdzenia poprawności reguł zmiana jej typu na
„offer”
4b. W przypadku niepoprawności reguły usunięcie reguły z pliku
61/68
6.3 Testowanie jakości pozyskanej wiedzy
Testowanie jakości wnioskowania podczas pracowni dyplomowej inżynierskiej było
procesem stosunkowo łatwym. Była tam dostępna tylko jedna ścieżka prawidłowego uzyskania
wyniku dla każdego agenta. W obecnie powstałym systemie przeprowadzenie testu jest
zdecydowanie trudniejsze. Każdy agent posiada własną bazę wiedzy która dla innego agenta
opiekującego się bardzo podobnym klientem może być całkowicie nieprawdziwa.
Dodatkowym mechanizmem utrudniającym odpowiednie testowanie jest szybki
dynamizm zmiany reguł. Pomiędzy jednym i drugim wnioskowaniem możliwa jest zmiana
praktycznie wszystkich reguł.
Ostatnią rzeczą, która praktycznie uniemożliwia sprawdzenie wiedzy jest brak
możliwości zasymulowania zachowania dużej ilości klientów w warunkach laboratoryjnych.
Sprawiało to że nauka zawsze była sterowana przez użytkownika. Aby sprawdzić jakość
tworzonej wiedzy należy by przeprowadzić wnioskowanie dla dużej ilości archiwalnych,
rzeczywistych danych a następnie porównać wynik z rzeczywistością.
62/68
7. Wnioski
7.1 Zaimplementowany mechanizm odkrywania wiedzy
Jednym z głównych celów pracowni było stworzenie prostego mechanizmu nauki
agenta. Cel został w pełni zrealizowany. Agent jest w stanie pozyskać wiedzę na dwa sposoby.
Pierwszym z nich jest wysłanie do podobny agentów zapytania, z prośbą o udostępnienie
swojej wiedzy, drugim poczynienie pewnego założenia z którego później można się wycofać.
Zaimplementowana forma nauki jest prosta, jednak w przypadku systemów zarządzania
relacjami z klientem wystarczająca. Są to zazwyczaj systemy o małej dynamice zmian dlatego
też proste wnioskowanie jest wystarczające.
Jakość uzyskanej wiedzy jest ciężka do oceny – z powodu niemożliwości
zasymulowania faktycznego zachowania klientów – jednak najważniejszym faktem jest jej
powstawanie oraz możliwość wykorzystania.
7.2 Możliwości rozwoju systemu
System powstały podczas pracowni dyplomowej magisterskiej jest rozszerzeniem
istniejącego już systemu. Nie oznacza to jednak, że jest on już systemem kompletnym. Jedną z
przeszkód, których nie udało się ominąć jest brak dostępnego parsera PROLOG.
Zaimplementowany przeze mnie parser jest prymitywny i ogranicza się tylko do kilu
specyficznych przypadków – tych wykorzystywanych w regułach. PROLOG jest narzędziem
bardzo potężnym językiem przetwarzania symbolicznego, a zaimplementowany system
wykorzystuje wyłącznie najprostsze z nich.
Aby w pełni wykorzystać integracje z językiem PROLOG konieczne jest stworzenie
lepszego modelu analitycznego. W systemie cała analiza (zarówno analiza skupień i
wnioskowanie) oparte jest na kilku prostych parametrach. Opracowanie natomiast bardziej
63/68
odpowiadające rzeczywistości modelu biznesowego mogłoby mieć tutaj kluczowe znaczenie.
Duży potencjał w budowie takiego modelu mogłoby mieć zastosowanie, innych niż tylko
analiza skupień, metod odkrywania wiedzy.
Powiązanym z tym elementem jest przyjęte przeze mnie założenie że parametry są od
siebie niezależne. Uwidocznić się to może w branym pod uwagę przy wnioskowaniu polu
region oraz dochód. Bez ryzyka można stwierdzić że w krajach wysoko rozwiniętych poziom,
od którego można uznać firmę za bogatą będzie się znajdował zdecydowanie wyżej niż w
p[przypadku krajów rozwijających się.
Kolejnym obszarem, w którym szukać możemy możliwości do rozwoju są systemy
rozproszone. Zaimplementowany system działa w środowisku które jest traktowane jako
centralne, jednak wykorzystane programowanie agentowe pozwala na bardzo łatwe
przeniesienie go w środowisko rozproszone.
7.3 Podsumowanie
Projekt „Integracja systemu wieloagentowego z systemem zarządzania relacjami z
klientem (CRM)” trwał 3 lata. Jego celem było stworzenie rozwinięcie systemu klasy CRM i
stworzenie podstawy dla systemów zarządzania doświadczeniem klienta (Customer Experience
Management – w skrócie CEM).
Projekt miał dwie zasadnicze fazy:
1. Realizowana podczas pracowni dyplomowej magisterskiej faza mająca na celu
zintegrowanie systemu CRM z systemem wieloagentowy oraz zaimplementowanie
prostego wnioskowania na podstawie wcześniej założonych schematów.
2. Realizowana podczas pracowni dyplomowej magisterskiej faza mająca na celu
stworzenie
prostego
systemu
uczenia
się
agentów
oraz
zaimplementowanie
mechanizmu wymiany informacji między agentami.
64/68
Obie fazy zakończyły się sukcesem. Czy możemy więc nazwać finalną wersję systemu,
prawdziwym systemem do zarządzania doświadczeniem klienta? Główna różnica między
strategiami CRM i CEM to podmiot na którym skupia się system. W przypadku CRM jest to
produkt, w przypadku CEM klient [1]. Jednym z założeń strategi zarządzania doświadczeniem
klienta jest traktowanie każdego nabywcy indywidualnie i zwracanie uwagi na wszystkie jego
odczucia związane z kontaktami z naszym przedsiębiorstwem (doświadczenia).
Integrowanie systemów wieloagentowych z CRM może być dobrym kierunkiem, w
którym należy iść aby uzyskać końcowy efekt. Wymagana są jednak do tego zdecydowanie
większe zmiany w samych systemach CRM. Zastosowany w moim przypadku system vTiger
CRM (wersja 5), jest systemem zdecydowanie zorientowanym na produkt. Aby być w stanie
umieścić w systemie dane, które faktycznie przedstawią nam obraz klienta jako rzeczywistej
osoby, trzeba by w bardzo dużym stopniu rozbudować cały system. Wymagane byłoby też
wprowadzenie większego nacisku na firmę, która korzysta z CRM, aby można w odpowiedni
sposób analizować jak na klientów wpływają zmiany w wizerunku. Sytuacje jest podobna w
większości obecnie najpopularniejszych systemów CRM.
Kolejną zasadniczą różnicą między CEM i CRM jest podejście do wewnętrznej
organizacji firmy. Doświadczenia pracowników, związane z naszą firmą, jest również istotne
jak doświadczenie klienta ponieważ to oni mają największy wpływ na kontakt z nabywcami
oraz na to, jak firma jest postrzegana. Aby klienta spotykały jedynie pozytywne doświadczenia,
pracownicy muszą być odpowiednio zmotywowani, kompetentni i myśleć w innowacyjny
sposób.
Programowanie wieloagentowe jako nowy paradygmat programowania jest bardzo
ciekawym podejściem, które przy obecnie coraz większym rozproszeniu systemów
komputerowych może odgrywać coraz większą rolę w budowie systemów informatycznych –
co zresztą widać po wzroście ilości narzędzi, dostępności informacji a także samej popularności
tego typu programowania. Programowanie wieloagentowe może być też bardzo ważnym
elementem rozwoju sztucznej inteligencji i uczenia się maszyn - jedna z definicji agenta brzmi
przecież: „Agent jest systemem komputerowym, który jest umieszczony w pewnym
środowisku i jest w stanie podejmować samodzielne działania w tym środowisku w celu
osiągnięcia ustalonego celu” [12].
65/68
9. Bibliografia
[1] Customer experience management: a revolutionary approach to connecting with your
client, Bernd H. Schmitt, fragmenty dostępne na http://books.google.pl/
[2] http://en.wikipedia.org/wiki/Customer_relationship management [data weryfikacji:
06.08.2012 r.]
[3] http://en.wikipedia.org/wiki/Multi-agent_system [data weryfikacji 19.08.2011r.]
[4] http://jade.tilab.com/ [data weryfikacji: 11.09.2012 r.]
[5] http://php-java-bridge.sourceforge.net/pjb/ [data weryfikacji: 15.09.2012 r.]
[6] http://pl.wikipedia.org/wiki/Agent_(programowanie) [data weryfikacji: 15.09.2012 r.]
[7] http://wiki.vtiger.com/index.php/Main_Page [data weryfikacji: 15.09.2012 r. ]
[8] http://www.crmreview.pl/ [data weryfikacji 12.09.2012 r.]
[9] http://www.iro.umontreal.ca/~dift6802/jade/doc/api/overview-summary.html [data
weryfikacji 15.09.2012 r. ]
[10] http://www.iro.umontreal.ca/~vaucher/Agents/Jade/JadePrimer.html [data weryfikacji:
15.09.2012 r.]
[11] http://www.manageability.org/blog/stuff/rule_engines [data weryfikacji 15.09.2012 r.]
[12] Multiagent Systems – A Modern Approach to Distributed Artificial Intelligence, pod
red. Gerhard Weiss [dystrybucja cyfrowa]
[13] Prolog programming for artifical intelligence (Third edition), Ivan Bratko, Essex, 2001
66/68
[14] An Introduction to MultiAgent Systems, Michael Wooldridge, Liverpool, 2002
[15] http://en.wikipedia.org/wiki/Cluster_analysis [data weryfikacji 15.09.2012 r.]
[16] http://en.wikipedia.org/wiki/Hierarchical_clustering [data weryfikacji 15.09.2012 r.]
[17] http://www.swi-prolog.org/ [data weryfikacji 03.09..2012 r.]
[18] http://www.cs.waikato.ac.nz/ml/weka/ [data weryfikacji 1.09.2012 r.]
[19] Todman Ch., Projektowanie hurtowni danych. Zarządzanie kontaktami z klientem
(CRM), Warszawa 2005.
67/68
Indeks ilustracji
Ilustracja 1: Interfejs gaczny SWI-Prolog...................................................................................13
Ilustracja 2: Edytor graficzny domyślnie instalowany wraz z SWI-PROLOG...........................14
Ilustracja 3: Urproszczony schemat działania tablicy.................................................................19
Ilustracja 4: Schemat obsługi asynchronicznych wiadomości w JADE .....................................20
Ilustracja 5: Reprezentacja klasyfikacji hierarchicznej...............................................................22
Ilustracja 6: Diagram przedstawiający wynik metody k-środków..............................................23
Ilustracja 7: Wynik działania algorytmu DMAC gdzie jako kwadraty oznaczeni zostali
przewodniczący grup...................................................................................................................26
Ilustracja 8: Podstawowe okno aplikacji.....................................................................................27
Ilustracja 9: Okno z wynikiem wnoiskowania wyświetlane użytkownikowi .............................28
Ilustracja 10: GUI aplikacji WEKA............................................................................................31
Ilustracja 11: WEKA - Moduł służący do eksploracji danych....................................................32
Ilustracja 12: Przykładowe dane z tabeli agent_client_info........................................................33
Ilustracja 13: Zapytanie generujące przedziały do analizy skupień............................................35
Ilustracja 14: Wizualizacja procesu analizy skupień...................................................................37
Ilustracja 15: Schemat działania Agenta podczas wnioskowania................................................39
Ilustracja 16: Tabela ze wstawionymi elementami, które według agenta powinny być
zaproponowane............................................................................................................................43
Ilustracja 17: Działanie agenta w przypadku braku wiedzy........................................................47
Ilustracja 18: Przygotowanie informacji przed porównaniem reguł...........................................49
Ilustracja 19: Metoda odpowiedzialna za utworzenie odpowiedzi na zapytanie.........................49
Ilustracja 20: Tabela agent_offer_info z przykładowymi danymi...............................................51
68/68

Rok akademicki 200 /200 - Politechnika Warszawska

Transkrypt

Podobne dokumenty

Akwizytor

OKAZJA CENOWA !! Do sprzedania dom zlokalizowany w Nędzy o

Kawalerka wynajem Cena podlega negocjacji. Polecamy i

Zadanie IV Zadanie IV

Krotoszyn, 2013-01-21 IR.271.3.6.2013 ................................................

Zadanie 3

Aneks do umowy agencyjnej

ANEKS DO UMOWY AGENCYJNEJ nr 111012013 ,lórlweł.?

Agent, skarbnica wiedzy