Technologia inteligentnych agentów

Transkrypt

Autor:
dr Jacek Jakieła
WYKŁAD ............................................................................................................. 3 Przykład realizacji systemu w środowisku Jason .................................................... 3 Czym jest Jason? .............................................................................................. 3 Praktyczna realizacja podstawowych elementów składowych agenta ......................... 3 Przekonania .................................................................................................. 3 Adnotacje (annotations) ................................................................................. 4 Silna negacja (Strong Negation) ...................................................................... 5 Reguły ......................................................................................................... 6 Cele ............................................................................................................. 7 Plany ........................................................................................................... 7 Przykład: Kompletny program agentowy ............................................................ 15 Charakterystyka dziedziny problemu .............................................................. 15 Uruchomienie systemu ................................................................................. 19 ĆWICZENIA ...................................................................................................... 21 Wskazówki techniczne ..................................................................................... 21 Zadanie 1 ...................................................................................................... 21 Zadanie 2 ...................................................................................................... 21 Zadanie 3 ...................................................................................................... 23 Zadanie 4 ...................................................................................................... 24 Zadanie 5 ...................................................................................................... 25 Zadanie 6 ...................................................................................................... 25 Zadanie 7 ...................................................................................................... 25 Zadanie 8 ...................................................................................................... 25 Materiały Distance Learning
© Wyższa Szkoła Informatyki i Zarządzania z siedzibą w Rzeszowie
2
WYKŁAD
Przykład realizacji systemu w środowisku Jason
Czym jest Jason?
System Jason jest szkieletem softwareowym, zawierającym interpreter w ramach którego
uruchamiany jest program agenta. Jason implementuje założenia architektury BDI w
formie Systemu Paktycznego Rozumowania (Practical Reasoning System). Agenci
programowani w środowisku Jason są reaktywnymi systemami planującymi (Reactive
Planning Systems), co oznacza, że w sposób ciągły monitorują środowisko i reagują na
pojawiające się w nim zdarzenia. Reakcja agenta polega na wykonaniu planów, które
pozwalają mu obsłużyć określone zdarzenie. Wykonywane przez agenta akcje zmieniają
środowisko w sposób pozwalający agentowi osiągnąć cele. Zmianą środowiska zarządza
komponent architektury, który wnosi do niego zmiany w zależności od wybranego przez
agenta sposobu działania. Architektura zarządza również aktualizacją „obrazu”
środowiska, który przechowuje agent.
Interpretacja programu agentowego ustala faktyczny cykl rozumowania agenta (Agent’s
Reasoning Cycle). Agent wykonuje kolejno następujące działania: monitoruje środowisko,
podejmuje decyzje odnośnie tego, jakie akcje wykonać, aby zrealizować cel i w końcu
realizuje akcje zmieniając w ten sposób środowisko. Część zachowania cyklicznego
odpowiedzialna za rozumowanie praktyczne jest realizowana w oparciu o plany, które
agent posiada w swojej bibliotece planów. Początkowo, biblioteka składa się z planów,
które przygotowuje projektant z wykorzystaniem języka AgentSpeak, którego
podstawowe konstrukcje zostały opisane w kolejnych sekcjach.
Praktyczna
agenta
realizacja
podstawowych
elementów
składowych
Przekonania
Jedną z pierwszych kwestii, jaką projektant korzystający ze środowiska Jason musi
poznać jest to, jak są reprezentowane przekonania agenta. Każdy agent jest wyposażony
w bazę przekonań, która w najprostszej postaci jest zbiorem formuł atomowych (patrz
Reprezentacja wiedzy agenta), przy czym nazwy predykatów oraz stałych rozpoczynają
się z małej litery a nazwy zmiennych z dużej.
Przykładowo, przekonanie o tym, że pewien obiekt o imieniu Jan z uniwersum dyskursu
agenta jest wysokim obiektem może być zapisane w formie wysoki(jan). Związek
zachodzący pomiędzy dwoma obiektami jest zapisywany z wykorzystaniem
odpowiedniego symbolu predykatu np. przekonanie, że Jan lubi muzykę może być
zapisane jako lubi(jan,muzyka).
Podstawową różnicą w porównaniu z reprezentacją wiedzy wykorzystaniem rachunku
predykatów jest to, że przy reprezentacji wiedzy agenta w formie przekonań mamy do
czynienia z tak zwanymi modalnościami prawdy (modalities of truth), w znaczeniu
podobnym do logik modalnych, a nie ze stwierdzeniami bezwarunkowo prawdziwymi.
Oznacza to, że gdy wyrażenie w postaci lubi(jan,muzyka)pojawia się w bazie
przekonań, agent zaczyna być przekonany (wierzy), że Jan lubi muzykę, co nie
koniecznie musi zgadzać się z rzeczywistością.
Podstawowe termy języka AgentSpeak są przedstawione na rysunku.
Materiały Distance Learning
3
Rysunek. Termy języka AgentSpeak.
Adnotacje (annotations)
Jedną z ważniejszych różnic pomiędzy notacją wykorzystywaną w programowaniu
logicznym a w systemie Jason są tak zwane adnotacje. Adnotacja jest strukturą opisującą
dodatkowe informacje związane z konkretnym przekonaniem. Adnotacje są zapisywane w
nawiasach kwadratowych zaraz za przekonaniem, którego dotyczą.
zajety(jan) [termin_do(jesien)]
Przedstawiony przykład oznacza, że agent jest przekonany, że Jan jest zajęty, ale od
pierwszego dnia jesieni to przekonanie zostanie porzucone przez agenta. Adnotacja daje
nam dodatkową informację na temat przekonania, w tym przypadku zajety(Jan).
Chociaż adnotacje nie zwiększają siły ekspresji języka, istnieją ważne powody ich
wykorzystania. Po pierwsze dzięki adnotacjom baza przekonań jest bardziej czytelna a
forma zapisu przekonań elegancka. Kolejną zaletą jest to, że taka forma reprezentacji
ułatwia zarządzanie bazą przekonań. Przykładowo adnotacja termin_do może wpływać
na okres przechowywania przekonania w bazie przekonań.
Warto zaznaczyć, że chociaż ta adnotacja nie ma znaczenia dla interpretera, programista
może w stosunkowo prosty sposób zmodyfikować działanie systemu tak, żeby usunięcie
konkretnego przekonania miało miejsce zaraz po tym jak w bazie pojawi się przekonanie
dotyczące rozpoczęcia się jesieni.
Są również inne typy adnotacji, które mają szczególne znaczenie dla interpretera. Taką
adnotacją jest adnotacja source, która jest wykorzystywana do zapisywania źródła
informacji prowadzącej do określonego przekonania. Istnieją trzy rodzaje źródła
informacji:
• Informacja sensoryczna (perceptual information) – agent zdobywa określone
przekonania, jako wynik ciągłej obserwacji środowiska, w którym działa (patrz cechy
agentów).
•
Komunikacja (Communication) – część przekonań, które agent posiada jest wynikiem
procesu komunikacji z innymi agentami (patrz Komunikacja w systemach
agentowych). Agent przechowuje informacje otrzymane od innych agentów oraz
informacje o tym, który agent ją przesłał.
•
Notatki mentalne (Mental notes) – czasami bardzo przydatne jest przechowywanie
informacji o tym, co miało miejsce w przeszłości, w związku z zadaniami, które agent
wykonał lub zobowiązaniami, które złożył. Agent sam dodaje przekonania tego typu
do swojej bazy przekonań w trakcie wykonywania planu, i wykorzystuje je później w
celu ułatwienia wykonywania planów które będą wybrane w przyszłości. Można
4
myśleć o przekonaniach tego typu jako o „notatkach pamięciowych”, które mogą
okazać się przydatne w przyszłości.
W środowisku Jason każde z omówionych przekonań jest oznaczane odpowiednimi
adnotacjami. Przekonania, których źródłem są sensory oznaczane są adnotacją
source(percept), stany mentalne adnotacją source(self). Każda inna adnotacja
będzie miała formę nazwy agenta, który dostarczył określoną informację. Na przykład
przekonanie lubi(jan,muzyka) może być oznaczone adnotacją [source(jan)] ponieważ
to agent o imieniu Jan dostarczył tę informację (co oznacza, że przynajmniej w
momencie dodania przekonania do bazy w społeczności istniał agent o imieniu Jan, który
lubił muzykę).
Silna negacja (Strong Negation)
Negacja jest źródłem wielu problemów w dziedzinie programowania logicznego.
Popularnym sposobem radzenia sobie z nimi jest tak zwane założenie zamkniętego świata
(Closed World Assumption).
Założenie zamkniętego świata mówi, że jeżeli nie wiemy, że coś jest
prawdziwe lub nie możemy tego dowieść w procesie logicznego wnioskowania
na podstawie znanych faktów wówczas jest to traktowane, jako fałszywe.
Istotę tego założenia pokazuje uproszczony przykład. Mamy skrócony rozkład jazdy
pociągów. Szukamy rannego pociągu do Krakowa. Sprawa jest prosta, jeśli znajdziemy w
rozkładzie taki pociąg. Gorzej, gdy rozkład takich pociągów nie zawiera. Logicznie rzecz
ujmując nie wynika z tego, ze nie ma takiego pociągu. Być może nie został uwzględniony
w skróconym rozkładzie. Tym niemniej może być rzeczą rozsądną przyjąć, że taki pociąg
nie istnieje. Do wyciągnięcia takiego wniosku uprawnia nas właśnie założenie
zamkniętego świata. Podobnie brak w książce telefonicznej danej osoby, nie pozwala,
logicznie rzecz biorąc, wnioskować, że nie ma ona telefonu. Praktycznie jednak wniosek
taki bywa użyteczny. Da sie go wyciągnąć zakładając regułę zamkniętego świata.
Założenie zamkniętego świata jest realizowane z wykorzystaniem operatora not.
Zastosowanie tego operatora oznacza, że negacja danej formuły jest prawdziwa tylko
wtedy, gdy system nie jest w stanie dowieść jej prawdziwości z wykorzystaniem
posiadanych faktów i reguł (reguły zostaną omówione w następnej sekcji).
Kolejny typ negacji jest opisywany przez operator tak zwanej silnej negacji "~". Jest on
wykorzystywany w sytuacji, gdy projektant chce jawnie zapisać, że agent jest
przekonany, co do tego, że dane stwierdzenie jest fałszywe.
Przykładowo zapis kolor(klocek1,bialy) oznacza, że agent jest przekonany, co tego,
że obiekt kolocek1 jest koloru białego. Z kolei zapis ~kolor(klocek1,bialy)oznacza, że
agent jest przekonany, że klocek1 nie jest biały.
Poniżej przedstawiono część bazy przekonań agenta o nazwie Maria.
(1)
kolor(klocek1,niebieski)[source(robert)].
(2)
~colour(klocek1,bialy)[source(jan)].
(3)
kolor(klocek1,czerwony)[source(percept)].
(4)
daltonista(robert)[source(self),degOfCert(0.7)].
(5)
klamca(robert)[source(self),degOfCert(0.2)].
5
Z przedstawionej bazy przekonań możemy odczytać następujące informacje:
Agent Maria był informowany przez agenta o nazwie Robert o tym, że konkretny obiekt o
nazwie klocek1 jest koloru niebieskiego (1) oraz przez agenta o nazwie Jan o tym, że
obiekt ten nie jest biały (2). Agent Maria dostrzegł później (np. za pomocą sensorów
wyposażonych w kamery), że klocek1 jest w rzeczywistości koloru czerwonego (3). W
normalnej sytuacji, gdy nie możemy założyć, że ktoś jest uczciwy wobec nas, to co
widzimy traktujemy z większym zaufaniem od tego co ktoś nam powiedział. Agent Maria
biorąc pod uwagę to, co „zobaczył” i to, o czym powiedział mu agent Robert, mógł dojść
do wniosku, że jest on albo daltonistą albo celowo próbował go oszukać i jest kłamcą.
Porównując stopnie pewności możemy się domyślić, że Maria wchodziła wcześniej
w interakcję z agentem Robertem i jest przekonana o jego uczciwości, co jest widoczne w
tym, że Maria jest bardziej pewna tego, że Robert jest daltonistą niż tego, że Robert ją
świadomie okłamał. Przekonania (4) i (5) zostały dodane samodzielnie przez agenta
Maria.
Reguły
Reguły pozwalają dochodzić do nowych konkluzji na podstawie znanych faktów.
Wprowadzenie reguł do bazy przekonań agenta może uprościć wiele zadań, jak np.
zapisywanie w zwięzły sposób warunków w planach agenta. Jednak pomimo szeregu
korzyści ze stosowania reguł zalecane jest, aby zrezygnować z nich w prostych
systemach. Przykładowe reguły zostały przedstawione poniżej.
prawd_kolor(C,B):kolor(C,B)[source(S)] & (S == self | S == percept).
prawd_kolor(C,B):kolor(C,B)[degOfCert(D1)] &
not (kolor(_,B)[degOfCert(D2)] & D2 > D1)&
not ~kolor(C,B).
Pierwsza reguła mówi, że najbardziej prawdopodobny kolor to ten, do którego agent
doszedł drogą wnioskowania lub ten, który pochodzi z sensorów. Jeżeli pierwsza reguła
zawiedzie wówczas, rozważana jest druga reguła, zgodnie z którą prawdopodobnym
kolorem jest ten, który ma przypisany najwyższy współczynnik pewności, pod
warunkiem, że nie ma żadnych mocnych dowodów na to, że to nie ten kolor.
Wnioskowanie realizowane z wykorzystaniem przedstawionych reguł jest tak zwanym
wnioskowaniem teoretycznym (Theoretical reasoning). Jak wiadomo, w architekturze BDI
agenci prowadzą wnioskowanie praktyczne (Practical Reasoning), które prowadzi do
określonych działań. W środowisku AgentSpeak jest to realizowane za pomocą planów
agenta, które zostały omówione w dalszej części.
Przy tworzeniu agenta w środowisku AgentSpeak wszystko, co musi być zdefiniowane to
początkowe przekonania i reguły (jeżeli takie są potrzebne). Przekonania, które są
zapisane w kodzie źródłowym agenta są traktowane jako notatki pamięciowe. Tak więc
jeżeli w kodzie źródłowym znajduje się przekonanie lubi(Jan,muzyka), to w bazie
przekonań zostanie ono zapisane jako lubi(Jan,muzyka)[source(self)].
W sytuacji, gdy projektantowi zależy, aby w bazie znalazło się przekonanie, które będzie
traktowane, jako pochodzące z sensorów wówczas należy to wyraźnie zdefiniować z
wykorzystaniem odpowiedniej adnotacji np. wysoki(jan)[source(percept)].
6
Cele
Pojęcie celu ma fundamentalne znaczenie dla projektowania systemów agentowych.
Podczas, gdy przekonania, w szczególności te pochodzące z sensorów opisują własności
środowiska, co do prawdziwości których agent jest przekonany, cele wyrażają stany
środowiska, które agent chce przez swoje działania uzyskać.
Zapisanie w programie agenta celu g oznacza, że agent jest zobowiązany do działania w
taki sposób, aby zmienić stan środowiska tak, że agent postrzegając to środowisko może
stwierdzić, że jest ono w stanie opisanym przez cel g. Cele definiowane przez projektanta
są tak zwanymi celami deklaratywnymi. W środowisku Jason są zdefiniowane dwa
rodzaje celów: cele do osiągnięcia (Achievement Goals) oraz cele testowe (Test Goals).
Cele
do
osiągnięcia
są
oznaczane
operatorem
”!”.
Przykładowo
zapis
!posiada(dom)oznacza, że agent posiada cel do osiągnięcia, którego realizacja związana
jest z doprowadzeniem do stanu, w którym agent będzie posiadał przekonanie
posiada(dom) co pozwala przypuszczać, że obecnie (przed realizacją celu) agent nie
posiada takiego przekonania. Podjęcie przez agenta realizacji nowego celu prowadzi do
wykonania planów, które opisują sposób działania pozwalający go osiągnąć.
Cele testowe są oznaczane operatorem ”?” i pozwalają sprawdzić, czy w bazie przekonań
są zawarte określone przekonania lub wydobyć informację z bazy przekonań.
Przykładowo cel zapisany w formie ?stan_konta_bankowego(BB) oznacza, że system
powinien podstawić pod zmienną logiczną BB wartość stanu konta, co do której agent
jest przekonany. Samo podstawienie może się odbywać z wykorzystaniem przekonania,
którego wartość zostanie podstawiona pod zmienną (BB→100).
Podobnie jak ma to miejsce z początkowymi przekonaniami, projektant może definiować
cele wstępne, których realizacją agent powinien zająć się zaraz po uruchomieniu.
Przykładowo agent może mieć zdefiniowany długoterminowy cel wstępny polegający na
całkowitym wysprzątaniu domu !posprzataj(dom).
Kolejną bardzo ważną w kontekście architektury BDI strukturą są plany.
Plany
Plan zdefiniowany w środowisku Jason ma trzy części: zdarzenie uruchamiające, kontekst
oraz ciało. Połączenie zdarzenia wywołującego i kontekstu jest nazywane głową planu.
Poszczególne elementy składowe planu są rozdzielone z wykorzystaniem symboli ”:” oraz
”<-” w sposób przedstawiony poniżej.
zdarzenie: kontekst <- ciało.
W kolejnych akapitach zostanie opisana istota każdego z elementów składowych planu, a
w kolejnej sekcji zostanie przedstawiony sposób ich wykorzystania w programie
agentowym.
Zdarzenie wywołujące (Triggering Event) – jak wiadomo z sekcji opisującej cechy
agenta istnieją dwie istotne kwestie związane z zachowaniem agenta. Są to reaktywność
i pro-aktywność. Posiadanie celów, które agent chce osiągnąć w dłuższym okresie czasu
związane jest z pro-aktywnością. Jednak podczas działania zmierzającego do realizacji
celów agent powinien bacznie obserwować zmiany w środowisku. Jest to bardzo istotne,
ponieważ zmiany te mogą wpływać na sprawność osiągania celów i w rezultacie na
skuteczność tego procesu. Zmiany w środowisku mogą oznaczać, że są nowe możliwości
realizacji pewnych działań oraz możliwości przyjęcia nowych celów lub porzucenia
obecnie przyjętych do realizacji.
7
Są dwa istotne typy zmian: zmiana przekonań oraz zmiana celów. Zmiany te są źródłem
zdarzeń, na które agent powinien odpowiednio zareagować. Każda z tych zmian może
polegać na dodaniu nowej wartości, lub usunięciu istniejącej. W wyniku pojawienia się
określonego zdarzenia agent realizuje odpowiedni plan. Część planu oznaczona jako
zdarzenie jest wykorzystywana do zdefiniowania dla każdego planu wzorca zdarzenia,
na które agent powinien zareagować wykonaniem danego planu. Jeżeli pojawiające się
zdarzenie może być dopasowane do wzorca wówczas rozpoczyna się realizacja planu,
przy założeniu, że spełnione są pewne dodatkowe warunki. Jeżeli część zdarzenie
określonego planu może być dopasowana do określonego zdarzenia wówczas plan jest
istotny (Relevant) dla danego zdarzenia.
Kontekst (Context) – podobnie jak pojęcie zdarzenia, kontekst również jest związany z
kwestią reaktywności agenta. To, co wiadomo do tej pory z przedstawionego opisu może
zostać podsumowane następująco: agenci mają cele a plany są wykorzystywane do ich
realizacji; w trakcie realizacji celu agenci powinni obserwować zmiany pojawiające się w
środowisku. Interakcja z dynamicznym środowiskiem jest często bardzo skomplikowana,
ponieważ zmiany, które w nim następują mogą oznaczać, że agent powinien nadal
działać bez zmian. Może się jednak zdarzyć, że zmiany spowodują zmiany w planach,
które wydawały się odpowiednie przy realizacji określonego celu.
Dlatego też w systemach reaktywnych zobowiązanie się do wykonania określonego planu
jest odkładane tak długo jak to tylko możliwe. Bardzo często agent posiada kilka planów
przeznaczonych do realizacji określonego celu. Kontekst jest wykorzystywany, aby
sprawdzić, czy w aktualnej sytuacji określony plan ma szansę się powieść (może obsłużyć
dane zdarzenie i zrealizować cel) biorąc pod uwagę aktualną informację na temat
środowiska. Dlatego też określony plan jest wybierany do wykonania tylko w sytuacji,
gdy jego kontekst jest logiczną konsekwencją przekonań agenta. Plan posiadający
kontekst, który jest oceniony, jako prawdziwy w kontekście aktualnych przekonań jest
planem stosowalnym w danym momencie i staje się kandydatem do wykonania.
Ciało planu (Plan Body) – istotę ciała planu zrozumieć jest najłatwiej. Jest to sekwencja
formuł określająca sposób działania agenta. Sekwencja powinna obsłużyć zdarzenie,
które uruchomiło plan i doprowadzić do realizacji celu.
Zdarzenia wywołujące
Jak wiadomo z poprzedniej sekcji każdy agent posiada przekonania i cele. Istnieją dwa
typy celu: cele do osiągnięcia oraz cele testowe. Zdarzenia reprezentują zmianę w
przekonaniach lub celach i mogą być związane z dodaniem lub usunięciem określonego
obiektu. W związku z tym można zdefiniować 6 różnych typów zdarzeń wywołujących dla
danego literału L.
Notacja
Nazwa
+l
Dodanie przekonania.
-l
Usunięcie przekonania.
+!l
Dodanie celu do osiągnięcia.
-!l
Usunięcie celu do osiągnięcia.
+?l
Dodanie celu testowego.
-?l
Usunięcie celu testowego.
Zdarzenia związane z dodaniem lub usunięciem przekonania występują w momencie, gdy
agent uaktualnia swoją bazę przekonań w związku z monitorowaniem środowiska, co ma
miejsce w każdym cyklu wnioskowania.
8
Zdarzenia związane z dodaniem nowych celów występują głównie, jako konsekwencja
wykonania innych planów, ale również, jako konsekwencja komunikacji. Wykonanie planu
może wymagać od agenta nowych celów/podcelów do osiągnięcia. Zdarzenie usunięcia
celu jest związane z obsługą niepowodzenia realizacji planów. Schemat na rysunku
pokazuje jak prosta formuła może być wykorzystana do tworzenia bardziej
skomplikowanych struktur.
W celu lepszego zrozumienia zdarzeń warto rozważyć następujący przykład. Należy
zaprojektować agenta, którego celem jest serwowanie obiadu. Cel może zostać uznany
za osiągnięty, gdy agent jest przekonany, że obiad został podany, co może być zapisane,
jako podany(obiad). Potrzebny jest plan, który agent zacznie wykonywać zaraz po tym
jak przyjmie cel prowadzący do stanu rzeczy, który jest opisany w formie przekonania.
Zdarzenie wywołujące, może być zapisane w postaci +!podany(obiad), lub w bardziej
ogólnej postaci, +!podany(Posilek). W takim układzie w sytuacji, gdy agent będzie miał
zrealizować cel !podaj(obiad) wówczas pod zmienną logiczną Posilek zostanie
podstawiona wartość obiad. Z kolei cele testowe są potrzebne do uzyskania prostej
informacji z bazy przekonań. Przykładowo, załóżmy że agent zwykle wie ile paczek
makaronu posiada w spiżarce, tak więc jeżeli potrzebuje takiej informacji wówczas po
prostu przywołuje ją z pamięci. Może się jednak zdarzyć, że nie pamięta i wtedy musi
podjąć działanie polegające na zapytaniu innego agenta lub musi sam udać się do
spiżarki. Dlatego też istnieją plany ze zdarzeniem wywołującym polegającym na dodaniu
celu testowego, chociaż określony problem mógłby być rozwiązany z wykorzystaniem
celów do osiągnięcia.
Rysunek. Typy formuł w środowisku AgentSpeak.
Kontekst
Jak wiadomo z poprzednich sekcji kontekst jest wykorzystywany w celu zdefiniowania,
kiedy określony plan powinien być uważany za stosowalny. Dodatkową kwestią wartą
przypomnienia jest to, że przy pisaniu systemu funkcjonującego w dynamicznym
środowisku, zobowiązanie do działania w określony sposób powinno być odkładane tak
długo jak to tylko możliwe. Tak, więc jeśli dochodzi do wybrania określonego planu, aby
osiągnąć cel, kontekst jest wykorzystywany do tego aby upewnić się, że wybierany plan
ma szansę na powodzenie.
9
Kontekst jest zapisywany z wykorzystaniem domyślnych literałów oraz wyrażeń
opisujących relacje. Literał jest predykatem opisującym określony stan świata agenta,
który może być zapisany z wykorzystaniem silnej negacji. Domyślny literał jest literałem,
który może być zapisany opcjonalnie z wykorzystaniem operatora not (operator negacji
domyślnej). Wyrażenia logiczne mogą pojawić się w definicji kontekstu jako formuły
złożone, które są połączeniem literałów z wykorzystaniem operatorów koniunkcji,
dysjunkcji oznaczanych odpowiednio z wykorzystaniem symboli ”&” (and), ”|” (or) oraz
not. Taka sama notacja może być wykorzystana przy definicji ciała reguł. Typy literałów,
które mogą się pojawić w definicji kontekstu przedstawia tabela.
Tabela. Typy literałów wykorzystywanych w definicji kontekstu planu.
Notacja
Nazwa
l
Agent jest przekonany, że l jest prawdą
~l
Agent jest przekonany, że l jest fałszem.
not l
Agent nie jest przekonany, że l jest prawdą.
not ~l
Agent nie jest przekonany, że l jest fałszem.
Kontekst planu jest zwykle zapisany, jako połączenie literałów tego typu.
Przykłady kontekstów planów zostały przedstawione poniżej.
+!przygotuj(Cos)
: liczba_osob(L) & stan_magazynowy(Cos,S) & S > L
<-....
...
+!kup(Cos)
: not ~legalne(Cos) & cena(Cos,C)& stan_konta(S) & S > C
<- ....
W pierwszym przypadku mamy do czynienia z sytuacją, gdzie agent podejmie realizację
celu przygotowania czegoś (do jedzenia) pod warunkiem, że ma na stanie wystarczającą
ilość tego czegoś biorąc pod uwagę liczbę osób, które będą jadły. Pierwszy plan może być
wykorzystany do realizacji celu.
W drugim przypadku jest opisana sytuacja, w której gdy przychodzi do podjęcia przez
agenta celu kupienia czegoś, plan będzie uznany za wykonalny, gdy agent nie ma
informacji, że kupno czegoś jest nielegalne i ma wystarczającą kwotę na koncie, aby
zrealizować zakup tego czegoś. Istotną kwestią, którą należy zapamiętać jest to, że
każdy literał, który pojawia się w definicji kontekstu jest sprawdzany w bazie przekonań
agenta.
Przykładowo,
jeżeli
w
bazie
przekonań
znajduje
się
stan_magazynowy(makaron,5)ocena literału stan_magazynowy(Cos,S)zwróci wartość
true przy założeniu, że zmienna Cos jest związana z wartością makaron a następnie
zmienna S zostanie związana z wartością 5. W ten sposób system sprawdza, czy cały
kontekst jest logiczną konsekwencją bazy przekonań.
10
Ciało planu
Ciało planu definiuje działania, które agent zacznie realizować w momencie, gdy
wystąpiło zdarzenie, które może być dopasowane do zdarzenia wywołującego planu i
kontekst jest prawdziwy w odniesieniu do aktualnej zawartości bazy przekonań agenta.
Przepis na działanie jest definiowany w formie sekwencji formuł rozdzielonych symbolem
”;”. Istnieje pięć rodzajów formuł, które mogą pojawić się w ciele planu.
Pierwszym rodzajem formuł, które pojawiają się w planach są akcje. Jak wiadomo agent
musi być zdolny do działania w swoim środowisku. Akcje opisują umiejętności agenta.
Jeżeli programowany jest robot wówczas jasno określa się działania, które powinien móc
wykonać za pośrednictwem określonego sprzętu. Każda z akcji musi mieć symboliczną
reprezentację, która pozwoli odwoływać się do nich w programie agenta, a cała
architektura agenta zostanie połączona z nimi poprzez odpowiednie interfejsy efektorów
agenta. Akcje są opisywane z wykorzystaniem symboli predykatów. Przed wykonaniem
akcji wszystkie zmienne występujące w predykacie muszą zostać związane z konkretnymi
wartościami. Interpreter odróżnia predykaty opisujące akcje od innych predykatów
(opisujących np. kontekst) analizując położenie symbolu predykatu.
Jeżeli symbol
predykatu jest umiejscowiony w ciele planu wówczas jest traktowany, jako akcja. Inne
typy formuł też wykorzystują symbole predykatów, ale stosowana jest specjalna notacja
pozwalająca stwierdzić, czy dany element planu jest, czy nie jest akcją zmieniającą
środowisko. Jest również szczególny przypadek akcji, tak zwana akcja wewnętrzna
(internal action), która jest wykonywana wewnątrz agenta i nie wpływa na zmianę
środowiska.
Jako prosty przykład rozważmy sytuację, w której pisany jest program dla robota, który
ma dwie ręce, lewą i prawą. Jedyną akcją, którą robot potrafi wykonać jest obrót rąk,
gdzie kąt obrotu musi być podany. W planach mogą być zapisane akcje w formie
obroc(lewa_reka,45) lub obroc_lewa_reke(90). To, która reprezentacja zostanie
wybrana jest kwestią gustu. Akcje są wykonywane przez efektory agenta, które nie są
częścią interpretera. W związku z tym rozsądnym rozwiązaniem jest wymaganie jakiegoś
sprzężenia zwrotnego, mówiącego czy akcja została wykonana, czy nie. Dopóki takie
logiczne sprzężenie zwrotne nie zostanie odebrane, plan który wymaga wykonania
określonej akcji musi być zawieszony aż do momentu, gdy będzie pewne, że akcja
została wykonana. Wykonanie akcji nie oznacza, że spodziewane zmiany zostały
wprowadzone – musi to zostać potwierdzone przez analizę środowiska i sprawdzenie
przekonań. Jeżeli akcja nie została wykonana wówczas plan zawodzi.
Cele do osiągnięcia
Posiadanie celów do osiągnięcia jest kolejną istotną charakterystyką agenta. Złożone
zachowanie to coś więcej niż proste sekwencje akcji do wykonania. Często, przed
podjęciem kolejnych akcji, muszą zostać osiągnięte określone cele. W związku z tym w
ramach ciała planu mogą być definiowane cele do osiągnięcia, które są zapisywane w
postaci literału oraz symbolu ”!”. Na przykład w ramach planu może być zdefiniowany cel
polegający na osiągnięciu stanu rzeczy, w którym klient jest zadowolony
!klient(zadowolony).
Jeżeli w ciało planu zostanie włączony cel do osiągnięcia wówczas dla tego celu musi być
wykonany plan i dopiero, gdy plan dla tego celu zostanie wykonany do końca może być
wykonana reszta akcji.
Przykładowo jeżeli ciało planu zawiera takie akcje jak ”a1; !g2; a3” agent wykona
najpierw akcję a1, następnie będzie musiał osiągnąć cel !g2, co może wymagać
wykonania planu dla tego celu i dopiero po tym jak !g2 zostanie osiągnięty zostanie
wykonana akcja a3. Czasami zachodzi potrzeba takiego zdefiniowania ciała planu, że
agent napotykając cel do osiągnięcia nie czeka aż zostanie on osiągnięty zanim wykona
resztę czynności w planie. W takiej sytuacji może być wykorzystany operator ”!!”, który
11
mówi interpreterowi, że nie powinien odkładać planu tylko przyjąć cel i zanim zostanie on
wykonany uruchomić pozostałe akcje z planu.
Notatki pamięciowe
Przygotowując program agenta należy być świadomym rzeczy, które agent potrafi
dostrzegać w swoim środowisku. Niektóre przekonania są nabywane na podstawie
danych sensorycznych i są automatycznie uaktualniane i w związku z tym projektant nie
musi tego robić programowo. Istnieją jednak sytuacje, w których przydatną funkcją jest
tworzenie przekonań podczas wykonywania planu. Przekonania tego typu noszą nazwę
notatek pamięciowych i są oznaczane adnotacją source(self). Agent może potrzebować
tego typu notatek, aby przypomnieć sobie o czymś, co zrobił w przeszłości, lub o czymś,
co zostało przerwane i powinno być wznowione, lub o obietnicy/zobowiązaniu. Np.
określony agent odpowiedzialny za opiekę nad trawnikiem powinien pamiętać kiedy
ostatnio trawnik był skoszony, co może być reprezentowane w ciele planu za pomocą
formuły +skoszony(trawnik,Dzisiaj); gdzie zmienna Dzisiaj została wcześniej
ukonkretniona określoną wartością. Jeżeli taka formuła pojawi się w ciele wykonywanego
planu wówczas formuła postaci skoszony(trawnik,data(2008,01,30)) zostanie
automatycznie dodana do bazy przekonań. Minusem takiego podejścia jest to, że
projektant musi zadbać o to, aby przekonanie, które nie jest dłużej potrzebne zostało
usunięte z bazy przekonań np. do_zrobienia(skosic(trawnik)). Do utrzymania
porządku w bazie przekonań służy operator ”-+”, który pozwala aktualizować na bieżąco
instancje przekonań. Operator najpierw wyszukuje w bazie określone przekonanie, usuwa
je, a następnie wprowadza nową instancję z aktualnymi wartościami. Próba usunięcia
przekonania, które nie istnieje nie prowadzi do niepowodzenia planu.
Jeżeli istnieje taka potrzeba można również zmienić przekonania pochodzące z innych
źródeł, ale należy to robić bardzo ostrożnie, ponieważ może to prowadzić do
nieoczekiwanych sytuacji.
Przykładowo projektant może zapisać -godny_zaufania(ag2)[source(ag1)] aby usunąć
przekonanie, którego źródłem jest ag1 mówiące o tym, że agent ag2 jest godny zaufania
lub +wlaczony(tv)[source(percept)] jeżeli projektant eksperymentuje z tym jak agent
postrzega środowisko.
Akcje wewnętrzne
Istotną cechą akcji jest to, że zmieniają one stan środowiska. Można o nich myśleć, jako
o akcjach wykonywanych poza „umysłem” agenta. Czasem przydatne okazują się akcje
wykonywane wewnątrz agenta. Takie akcje, określane terminem akcji wewnętrznych
mogą być wykorzystane przez projektanta do rozszerzenia języka o polecenia, które nie
są dostępne jak również do realizacji w języku Java (lub innym poprzez mechanizm JNI)
dostępu do systemów typu „legacy”.
Akcje wewnętrzne są oznaczane symbolem ”.”. Symbol ”.” jest również wykorzystywany
do oddzielenia nazwy biblioteki od nazwy akcji wewnętrznej zawartej w tej bibliotece.
Załóżmy, że projektant realizuje w środowisku Jason kontroler dla robota i korzysta z
biblioteki zawierającej akcje potrzebne do przetwarzania obrazów cyfrowych, które robot
pobiera za pomocą sensorów wizyjnych. Biblioteka nazywa się dip a w niej znajduje się
akcja wewnętrzna o nazwie ustal_sciezke pozwalająca określić ścieżkę przejazdu do
nowego położenia biorąc pod uwagę obecne położenie robota ustalone na podstawie
obrazu pochodzącego z kamery. Aby to zrealizować projektant umieści w ciele planu
akcję zapisaną w formie dip.ustal_sciezke(X,Y,P) zmienna P zostanie ukonkretniona
przez akcję wewnętrzną i związana ze ścieżką prowadzącą do położenie określonego
przez współrzędne (X,Y). Istnieje zbiór predefiniowanych standardowych akcji
wewnętrznych, z których projektant może korzystać. Akcje te implementują kluczowe
mechanizmy wymagane przez architekturę BDI. Korzystając ze standardowej akcji
wewnętrznej należy wpisać jej nazwę poprzedzoną symbolem ”.”. Przykładowo literał
12
.send uruchamia standardową akcję pozwalającą na komunikację międzyagentową.
Korzystanie z tej akcji wymaga dodatkowej wiedzy na temat języka komunikacji
międzyagentowej. Na razie można założyć, że uruchomienie tej akcji wymaga podania
trzech parametrów: nazwy agenta, który jest adresatem wiadomości, informacja na
temat intencji zapisana w formie performatywu (np. inform, request) oraz właściwa
zawartość wiadomości. Przykład przedstawiony poniżej zawiera elementy planu poznane
do tej pory.
+!opuscic(dom)
: not pada_deszcz & not ~pada_deszcz
<!polozenie(okno);
?typ_zaslon(Zaslony);
odsun(Zaslony); …
+!opuscic(dom)
: not pada_deszcz & not ~pada_deszcz
<.send(mama,askif,pada_deszcz); …
Pierwszy plan mówi, że jeżeli agent podejmuje nowy cel opuszczenia domu w warunkach,
w których nie jest pewien czy pada deszcz, czy nie pada – warto zauważyć, że kontekst
jest tak zdefiniowany, że plan może zostać użyty tylko w sytuacji, gdy agent nie jest
przekonany, że pada ale nie jest również przekonany, że nie pada - wówczas jedynym
możliwym działaniem jest podjęcie celu znalezienia się przy oknie (plan prowadzący do
realizacji celu może wymagać od agenta, aby ten się przemieszczał w środowisku, jeżeli
obecnie nie jest przy oknie), następnie agent pobierze z bazy przekonanie i ustali typ
zasłon, które agent teraz jest w stanie dostrzec a następnie je odsunie (można się
domyślać, że dla różnych typów zasłon istnieją różne akcje pozwalające je odsunąć).
Plan może być dalej realizowany poprzez przyjęcie celu sprawdzenia, czy agent powinien
zabrać ze sobą parasol. Ze względu na prostotę reszta planu została pominięta. Przed
dalszą realizacją planu, zaraz po akcji odsunięcia zasłon agent w cyklu wnioskowania
pobiera dane z sensorów i uaktualnia bazę przekonaniem związanym z sytuacją na
zewnątrz.
Drugi plan zawiera alternatywną ścieżkę działań dla tej samej sytuacji: agent posiada cel
opuszczenia domu nie będąc przekonanym, co do tego, czy pada, czy nie. Zamiast
podchodzić do okna i odsłaniać zasłony agent pyta agenta o nazwie mama, który zwykle
wie, jaka pogoda jest na zewnątrz. To, który plan zostanie wykonany zależy od agenta
(agent „nastolatek” będzie miał zdefiniowane oba plany, ale jest bardzo prawdopodobne,
że wybierze drugi głośno krzycząc matki z pytaniem). W praktyce wybór planu jest
realizowany przez tak zwaną funkcję wyboru.
Wyrażenia
Każda formuła w kontekście oraz ciele planu musi mieć wartość logiczną (włączając akcje
wewnętrzne). Przy specyfikacji kontekstu oraz ciała planu mogą być stosowane operatory
relacyjne, jak np. X >= Y*2, co oznacza, że jeżeli zostało to zapisane w kontekście plan
jest stosowalny, jeżeli ten warunek jest spełniony. W przypadku gdy taki warunek został
zapisany w ciele planu, plan się nie powiedzie, jeżeli warunek nie jest spełniony.
13
Etykiety planu
Każdy plan może zostać oznaczony etykietą, o której można myśleć, jako o nazwie planu.
W zasadzie wszystkie plany mają nazwy automatycznie generowane przez interpreter,
jeżeli tylko taka nazwa nie została przypisana przez projektanta. Jest to ważny
mechanizm, ponieważ czasem istnieje potrzeba odwoływania się do określonego planu w
trakcie działania agenta. Notacja dla etykiety dla planu jest przedstawiona poniżej.
@etykieta zdarzenie: kontekst <- ciało.
Etykieta nie musi być prostym termem takim jak ”etykieta”. Etykieta może być również
zapisana w formie predykatu, co oznacza, że również może mieć przypisane adnotacje
zawierające meta-informacje, które pozwalają interpreterowi wybrać określony plan ze
zbioru planów. Przykład bardziej złożonej etykiety przedstawiono poniżej.
@zakupy(1)
[szansa_powodzenia(0.7),
wazne_do(jesien)]
+potrzebuje(Cos)
: moze_sobie_pozwolic_na(Cos)
<- !kup(Cos).
zaplata(0.9),
source(ag1),
14
Przykład: Kompletny program agentowy
Charakterystyka dziedziny problemu
Celem domowego robota jest serwowanie piwa swojemu właścicielowi. Jego misja jest
prosta. Robot odbiera żądanie od użytkownika idź do lodówki, wyjmij piwo i je przynieś.
Oprócz przynoszenia piwa robot powinien również dbać o stan piwa w lodówce i jeżeli
stan spada poniżej pewnego minimalnego poziomu, powinien zamówić dodatkowe piwo
za pośrednictwem serwisu supermarketu o nazwie dowieź do domu. Dodatkowo, robot
ma reguły zakodowane przez departament zdrowia, które ustalają maksymalne dzienne
spożycie piwa. Na rysunku przedstawiono dodatkowe informacje na temat scenariusza z
wykorzystaniem notacji metodyki Prometheus.
stock(beer,N)
has(owner,beer)
sip(beer)
at(robot,Place)
open(fridge)
robot
owner
achieve: has(owner,beer)
get(beer)
tell: toomuch(beer)
close(fridge)
achieve: order(beer,N)
hand_in(beer)
tell: delivered(beer,N, OrderID)
move_towards(Place)
supermarket
deliver(beer,N)
Rysunek. Struktura systemu zapisana w notacji metodyki Prometheus.
System składa się z trzech agentów o nazwach robot, supermarket i owner (właściciel).
Możliwe spostrzeżenia agentów są następujące:
at(robot,Place) – dla uproszczenia przykładu tylko dwa miejsca są dostrzegane: fridge
(lodówka), gdy robot jest naprzeciwko lodówki i owner (właściciel) gdy robot jest obok
właściciela. W zależności od swojego położenia w domu, robot będzie odbierał dwa
spostrzeżenia at(robot,fridge), lub at(robot,owner), lub żadnego spostrzeżenia gdy
robot nie jest w żadnym z miejsc.
stock(beer,N) – gdy lodówka jest otwarta agent będzie w stanie określić ile jest piw w
lodówce (ilość piw jest reprezentowana przez zmienną N).
has(owner,beer) – jest to spostrzeżenie, które robot odbiera, gdy właściciel ma niepustą
butelkę z piwem.
Większość z akcji ma bardzo intuicyjne znaczenie. Akcja, którą należy szerzej wyjaśnić to
move_towards. Aby uprościć przykład droga, którą robot porusza się po domu jest mocno
uproszczona. Zakłada się, że gdy robot wykonuje akcję move_towards(fridge), jego
sprzęt lub jego symulator wykonuje jeden krok w stronę lodówki, tak że nie musi
„martwić się” o ścieżkę do lodówki.
Oprócz monitorowania środowiska i wykonywania akcji agenci przesyłają między sobą
komunikaty (są oznaczane przez koperty). Za każdym razem gdy agent owner chce nowe
piwo, przesyła komunikat do agenta robot. Performatyw wiadomości to achieve co
15
Techno
ologia inte
eligentnyc
ch agentów
w
oznacza
a, że gdy robot odbierze wiadomość
ć podejmiie realizac
cję noweg
go celu
has(own
ner,beer). Podobny komunikat jest przesy
yłany do ag
genta supermarket gd
dy agent
robot ch
hce zamów
wić więcej piwa. Agentt supermark
ket przesyła
a komunika
at o perform
matywie
tell do
o agenta ro
obota, gdy zrealizuje zamówienie. Wiadom
mości o perrformatywie
e tell są
(w tym prz
wykorzy
ystywane do
d zmiany przekonań
p
zypadku delivered(b
beer,N,Ord
derID)).
Rysunek przedsta
awia przyk
kładowe środowisko a w dalsze
ej części znajduje się kod
ególnych ag
gentów.
poszcze
Rysu
unek. Przyk
kładowe śro
odowisko dz
ziałania „ro
obota piwne
ego” zaimplementowa
ane w
j
języku
Java
a.
Agent Owner
!get(be
eer). // początkowy
p
y cel
/* Plan
ny */
@g
+!get(b
beer) : tr
rue
< .send(r
<robot,achi
ieve,has(o
owner,beer
r)).
@h1
+has(ow
wner,beer)
) : true
< !drink(
<(beer).
@h2
-has(ow
wner,beer)
) : true
< !get(be
<eer).
, piję je małymi łyczkami
// Gdy mam piwo,
@d1
+!drink
k(beer) : has(owner
r,beer)
< sip(bee
<er);
!
!drink(bee
er).
@d2
+!drink
k(beer) : not has(o
owner,beer)
< true.
<+msg(M)
)[source(A
Ag)] : tru
ue
< .print(
<("Message from ",Ag
g,": ",M);
;
-msg(M).
kowym cele
em agenta owner jes
st get(Beer
r). Dlatego
o też, gdy owner rozpoczyna
Początk
działaniie generow
wane jest zdarzenie +!get(bee
er), które uruchamia plan oznaczony
etykietą
ą @g. Plan po prostu wysyła wiadomość do
d agenta robot z pro
ośbą o osią
ągnięcie
celu ha
as(owner,b
beer). Gdy robot osią
ąga cel age
ent owner dostrzega to i do jego bazy
dodawa
ane jest prrzekonanie has(owner
r,beer)[source(per
rcept)]. Ta
a zmiana w bazie
© Wyższa
a Szkoła Inforrmatyki i Zarz
ządzania z sied
dzibą w Rzesz
zowie
16
przekonań generuje zdarzenie, które uruchamia plan @h1. Podczas realizacji planu @h1
tworzony jest podcel !drink(beer) i wówczas agent właściciel rozpoczyna picie piwa
rekursywnie wykonując plan @d1. Zdarzenie +!drink(beer) ma dwa istotne plany (@d1
i @d2) i każdy z nich jest wybierany w oparciu o swój kontekst: @d1 jest wybierany
kiedykolwiek agent owner ma trochę piwa w butelce a @d2 w przeciwnym razie. Po tym
jak piwo ulegnie wypiciu przekonanie has(owner,Beer) zostaje usunięte a zamiar picia
piwa również znika (rekursywne wykonywanie planu !drink(beer) zostaje zatrzymane).
Zdarzenie –has(owner,Beer) uruchamia plan @h2. Ten plan tworzy nowy podcel
(!get(beer)), który uruchamia od nowa określone zachowanie agenta owner. Ostatni
plan po prostu drukuje wiadomość odebraną od agenta oznaczonego jako Ag. Wiadomość
zostaje usunięta z bazy przekonań zaraz po wykonaniu wewnętrznej akcji .print. Jest to
konieczne ponieważ gdy taki komunikat jest odbierany zdarzenie jest generowane tylko
w przypadku gdy komunikatu niw ma już w bazie przekonań.
Agent Supermarket
last_order_id(1). // początkowe przekonanie
// Plan pozwalający osiągnąć cel "order" od agenta Ag
+!order(Product,Qtd)[source(Ag)] : true
<- ?last_order_id(N);
OrderId = N + 1;
-+last_order_id(OrderId);
deliver(Product,Qtd);
.send(Ag, tell, delivered(Product,Qtd,OrderId)).
Kod agenta supermarket jest prosty. Agent posiada początkowe przekonanie zawierające
informację na temat ostatniego numeru zamówienia i plan osiągnięcia celu przetwarzania
zamówienia dla pewnego agenta. Zdarzenie wywołujące ma trzy zmienne: nazwa
produktu, ilość i źródło celu do osiągnięcia (w tym przypadku nadawcę komunikatu z
performatywem achieve). Gdy plan jest wybrany do wykonania najpierw konsultowana
jest baza przekonań w celu sprawdzenia numeru ostatniego zamówienia
(?last_order_id(N)); numer zamówień jest zwiększany (OrderID = N+1); uaktualniana
jest
baza
przekonań
(-+last_order_id(OrderID));
dostarczany
produkt
z wykorzystaniem zewnętrznej akcji i w końcu przesyłany komunikat do klienta (agenta
robota w tym przypadku) przekazujący informację, że produkt został dostarczony.
Robot Agent
/* Początkowe przekonania */
// początkowo agent jest przekonany, że jest piwo w lodówce
available(beer,fridge).
// mój właściciel nie powinien pić więcej niż 10 piw dziennie :-)
limit(beer,10).
/* Reguły */
too_much(B) :.date(YY,MM,DD) &
.count(consumed(YY,MM,DD,_,_,_,B),QtdB) &
limit(B,Limit) &
QtdB > Limit.
/* Plany */
@h1
+!has(owner,beer)
: available(beer,fridge) & not too_much(beer)
<- !at(robot,fridge);
open(fridge);
get(beer);
close(fridge);
!at(robot,owner);
hand_in(beer);
// zapamiętaj, że kolejne piwo zostało wypite
17
.date(YY,MM,DD); .time(HH,NN,SS);
+consumed(YY,MM,DD,HH,NN,SS,beer).
@h2
+!has(owner,beer)
: not available(beer,fridge)
<- .send(supermarket, achieve, order(beer,5));
!at(robot,fridge). // podejdź do lodówki i zaczekaj.
@h3
+!has(owner,beer)
: too_much(beer) & limit(beer,L)
<- .concat("The Department of Health does not allow me ",
"to give you more than ", L,
" beers a day! I am very sorry about that!",M);
.send(owner,tell,msg(M)).
@m1
+!at(robot,P) : at(robot,P) <- true.
@m2
+!at(robot,P) : not at(robot,P)
<- move_towards(P);
!at(robot,P).
// gdy supermarket zrealizuje dostawę ponów realizację celu ’has’
@a1
+delivered(beer,Qtd,OrderId)[source(supermarket)] : true
<- +available(beer,fridge);
!has(owner,beer).
// when the fridge is openned, the beer stock is perceived
// and thus the available belief is updated
@a2
+stock(beer,0)
: available(beer,fridge)
<- -available(beer,fridge).
@a3
+stock(beer,N)
: N > 0 & not available(beer,fridge)
<- +available(beer,fridge).
Robot jest głównym agentem w przykładzie i w związku z tym jego kod jest trochę
bardziej złożony. Robot utrzymuje przekonanie dotyczące dostępności piwa w lodówce.
Początkowo posiada przekonanie available(beer,fridge). Dla robota istotne jest, aby
pamiętać czy w lodówce jest dostępne piwo niezależnie od położenia, w jakim się
znajduje w środowisku. Robot może dostrzec stan piwa tylko w sytuacji, gdy jest przed
lodówką i jest ona otwarta. W momencie, gdy robot zamknie lodówkę, spostrzeżenie
dotyczące zapasu piwa jest natychmiast usuwane. W związku z tym robot musi
zapamiętać, co „widział” w lodówce. Plany @a2 i @3 uaktualniają przekonanie dotyczące
dostępności piwa w stosownie do spostrzeżeń agenta.
Baza przekonań posiada również regułę określającą, czy właściciel wypił już dopuszczalną
dzienną liczbę butelek piwa. Weryfikacje ta bazuje na liczbie przekonań o nazwie
consumed. Za każdym razem, gdy robot przynosi piwo właścicielowi dodaje przekonanie,
aby
to
zapamiętać.
Przekonanie
ma
następującą
strukturę
+consumed(Year,Month,Day,Hour,Minute,Second,beer).
18
Bieżąca data jest pobierana za pomocą wewnętrznej akcji .date (koniec planu @h1).
Agent korzysta również z wewnętrznej akcji .count w celu obliczenia liczby przekonań
consumed znajdujących się w bazie (zmienna QtdB zostaje ukonkretniona ustaloną
wartością). Przekonanie too_much jest wykorzystywane w celu ograniczenia spożycia
piwa zgodnie z regułami ustalonymi przez departament zdrowia.
Głównym zadaniem agenta o nazwie robot jest osiągnięcie celu !has(owner,beer), który
został utworzony po odebraniu komunikatu z performatywem achieve przesłanego przez
agenta owner. Robot ma trzy plany pozwalające osiągnąć cel (@h1, @h2 i @h3).
Pierwszy plan jest wybierany w sytuacji, gdy dostępne jest piwo a właściciel nie wypił
zbyt dużo piwa (jest to zdefiniowane w kontekście planu).
Plan @h1 jest
1. Robot
2. Robot
3. Robot
4. Robot
5. Robot
6. Robot
realizowany następująco:
podchodzi do lodówki (podcel).
otwiera lodówkę (akcja zewnętrzna).
bierze piwo (akcja zewnętrzna).
zamyka lodówkę (akcja zewnętrzna).
wraca do właściciela (podcel).
daje piwo właścicielowi (akcja zewnętrzna).
Plan pozwalający zrealizować podcel !at wykorzystuje akcję zewnętrzną move_towards
dopóki agent nie zdobędzie przekonania, że znajduje się w miejscu przeznaczenia P.
Drugi plan jest wybierany, gdy nie ma więcej piwa w lodówce. W takim przypadku robot
zamawia 5 butelek piwa u agenta o nazwie supermarket, podchodzi do lodówki i czeka na
dostawę. Plan kończy się, gdy robot znajduje się przy lodówce. W momencie gdy piwo
jest ponownie dostępne w lodówce cel !has(owner,beer)powinien zostać wznowiony.
Jest za to odpowiedzialny plan @a1.
Trzeci plan jest wykonywany, gdy robot nie powinien (niestety) już przynosić
właścicielowi piwa. W takiej sytuacji wysyła on do właściciele odpowiedni komunikat z
wyjaśnieniem powodów swojego zachowania.
Uruchomienie systemu
Każdy system stworzony w środowisku Jason powinien mieć zdefiniowany plik opisujący
system wieloagentowy. W pliku tym definiowani są agenci, współdzielone środowisko
oraz dodatkowe parametry uruchomieniowe. Zawartość pliku przedstawiona poniżej
definiuje agentów oraz klasę Javy symulującą środowisko.
MAS domestic_robot {
environment: HouseEnv(gui)
agents: robot;
owner;
supermarket agentArchClass SupermarketArch;
}
Poniżej przedstawiony jest wycinek komunikatów pojawiających się w trakcie działania
systemu.
[robot] doing: move_towards(fridge)
[robot] doing: open(fridge)
[robot] doing: get(beer)
[robot] doing: close(fridge)
[robot] doing: move_towards(owner)
[robot] doing: move_towards(owner)
19
...
[robot] doing: hand_in(beer)
[owner] doing: sip(beer)
[owner] doing: sip(beer)
...
[supermarket] doing: deliver(beer,5) ...
[owner] saying: Message from robot: The Department of Health does not allow
me to give you more than 10 beers a day! I am very sorry about that!
20
ĆWICZENIA
Wskazówki techniczne
1. Przed rozpoczęciem realizacji zadań utwórz na dysku twardym folder Jason, skopiuj
do niego archiwum jason.zip, a następnie rozpakuj je i uruchom środowisko (plik
jason.exe). Okno środowiska jest przedstawione na rysunku. Do uruchomienia
środowiska potrzebny jest JDK 5.0.
Rysunek. Okno środowiska Jason.
2. W niektórych sytuacjach potrzebna będzie konfiguracja środowiska polegająca na
wskazaniu ścieżki do katalogu gdzie zainstalowany jest JDK. Jest to realizowane za
pomocą opcji Plugins -> Plugins Options -> Jason.
Zadanie 1
Narysuj diagram czynności dla opisania cyklu realizowanego przez architekturę Jason.
Zadanie 2
Zadanie polega na uruchomieniu prostego systemu wieloagentowego. Jest to klasyczny
przykład o nazwie sprzątające roboty. Środowisko jest reprezentowane przez siatkę
(rysunek). Jeden z robotów przeszukuje każdą z komórek środowiska (siatki) w celu
odnalezienia śmieci. Jeżeli znajdzie, bierze je i przynosi do robota znajdującego się na
środku, który zarządza piecem do spalania. Następnie wraca do miejsca gdzie znalazł
śmieci i kontynuuje dalsze poszukiwania z tego miejsca.
W
celu
uruchomienia
przykładu
należy
przejść
do
folderu
dysk:\Jason\examples\cleaning-robots, gdzie dysk to nazwa dysku, na którym został
utworzony katalog środowiska Jason.
Wszystkie projekty w systemie Jason mają plik konfiguracyjny o rozszerzeniu *.mas2j. W
związku z tym, aby uruchomić przykład trzeba otworzyć plik mars.mas2j. Plik
konfiguracyjny zawiera opis infrastruktury, która została wybrana dla projektu
(Centralised, Jade, Saci,…), nazwę klasy Javy, która implementuje środowisko (MarsEnv),
oraz agentów, którzy przynależą do aplikacji.
21
Techno
ologia inte
eligentnyc
ch agentów
w
Rysunek. Środow
wisko sprząttających ro
obotów.
Aby roz
zpocząć prracę system
mu należy wybrać przycisk
p
s
. Po uruchomieniu systemu
pojawia
ają się dwa
a okna. Jed
dno to GUI aplikacji,, natomiastt drugie to
o konsola systemu
s
wieloag
gentowego, która wyśw
wietla druk
kowane kom
munikaty.
Rysunek. Konsola
K
sys
stemu MAS.
Aby zak
kończyć pra
acę systemu należy wybrać przyc
cisk
© Wyższa
ządzania z sied
dzibą w Rzesz
zowie
.
22
Techno
ologia inte
eligentnyc
ch agentów
w
Zadan
nie 3
Zadanie
e polega na
n stworzen
niu od pod
dstaw bardzo prosteg
go systemu
u wieloagen
ntowego
(w zasa
adzie dwu-a
agentowego
o). System składa się z 2 agentó
ów o nazwa
ach robert i tomek.
Ich kole
ektywne dz
ziałanie pole
ega na prze
esyłaniu ko
omunikatu powitalnego
p
o.
i
1. W pierwszym
p
k
kroku
należ
ży utworzyć
ć nowy projjekt klikają
ąc w ikonę
wprrowadzając nazwę greeting. Okno
o tworzenia
a nowego projektu
p
prz
zedstawiono na
rysu
unku.
nek. Okno tworzenia
t
nowego
n
pro
ojektu.
Rysun
2. Następnie nale
eży dodać do
d projektu
u dwóch agentów o od
dpowiednich nazwach. W tym
celu
i wprowa
u należy klikając w przycisk
adzić nazw
wy. Nazwa agenta musi
m
być
term
mem języka
a, co oznacza, że mus
si się zaczyn
nać od małłej litery.
Rys
sunek. Okno
o dodawania nowego agenta.
3. Po dodaniu agenta systtem autom
matycznie generuje
g
jego szkiele
et. Agent nie ma
żadn
nych przek
konań, ale ma począttkowy cel o nazwie start
s
i pla
an pozwala
ający go
osią
ągnąć. Plan
n zawiera akcję wew
wnętrzną .print,
.
kttóra druku
uje łańcuch
h „Hello
Worrd”.
Kod agenta tomek musi zostać zmiieniony tak
k, aby plan wysyłał on
n do agenta
a robert
witanie o trreści hello. Wysyłanie
e komunikatu jest re
ealizowane za pomoc
cą akcji
pow
wew
wnętrznej send.
s
!sta
art.
+!st
tart : tru
ue <- .sen
nd(bob,tell,hello).
k
agen
nta robert należy
n
usun
nąć całą wygenerowan
ną zawartoś
ść.
W kodzie
© Wyższa
ządzania z sied
dzibą w Rzesz
zowie
23
Techno
ologia inte
eligentnyc
ch agentów
w
4. Po zdefiniowan
z
niu systemu i agentów można uruchomić
u
projekt. Ab
by zobaczy
yć wynik
proc
cesu komu
unikacji nalleży przejś
ść w tryb debugowania
i w pojawiając
cym się
oknie wybrać agenta
a
robe
ert. W oknie o nazwie
e Mind Inspector możn
na podglądn
nąć stan
men
ntalny agenta. Jak widać
w
na rysunku agent robert ma jedno przekonanie z
adnotacją wskazującą na nadawcę komunikatu
k
u.
unek. Okno inspektora
a stanu men
ntalnego.
Rysu
óżmy teraz
z, że agentt robert chce jakoś za
areagować na tę wiadomość. Ponieważ
5. Załó
odebranie wiad
domości zw
wiązane jestt z dodanie
em przekonania
g
generowane
e
jest
zdarrzenie
+he
ello [source
e(tomek)], które może
e uruchamia
ać plan prz
zedstawiony
y poniżej.
+hel
llo[source
e(A)] <- .print(“I
.
received
d a 'hello
o' from ",A).
ą, która zaw
wiera nazwę
ę nadawcy.. Po ponow
wnym uruchomieniu
W ww. planie A jest zmienną
oli pojawi się komunika
at.
systemu na konso
unikatem.
Rysunek. Konsola z wydrukowanym komu
ecznym age
entem, pow
winien odpo
owiedzieć po
ozdrowienie
em. W
6. Ponieważ robert jest grze
m celu należ
ży zmodyfik
kować jego plan do po
ostaci przed
dstawionej poniżej.
tym
+hel
llo[source
e(A)]
<- .pr
rint("I re
eceived a 'hello' from
f
",A);
;
.se
end(A,tell
l,hello).
W planie
p
agentta tomek ró
ównież wym
magane są następując
ce modyfika
acje.
!sta
art.
+!st
tart : tru
ue <- .sen
nd(bob,tell,hello).
+hel
llo[source
e(A)]
<- .print("
"I receive
e an hello from ",A);
.send(A,
,tell,hell
lo).
y zaobserwo
ować wprow
wadzone zm
miany należ
ży ponownie uruchomić system.
7. Aby
Zadan
nie 4
Wprowa
adź do systtemu kod przykładu
p
„rrobot piwny
y” i uruchom
m go.
© Wyższa
ządzania z sied
dzibą w Rzesz
zowie
24
Zadanie 5
Agent o nazwie robot (Z przykładu „robot piwny”) ma plany @h1-@h3, które są
uruchamiane, gdy agent podejmuje realizację celu has(owner,beer), niezależnie od
źródła tego celu (cel osobisty, cel delegowany). Jak należałoby zmienić plany aby były
uruchamiane tylko w sytuacji, gdy źródłem celu jest agent owner.
Zadanie 6
(Z przykładu „robot piwny”) Zmień kod agenta o nazwie supermarket tak, żeby mógł on
zarządzać poziomem zapasów. Załóżmy, że początkowo na stanie jest 100 butelek piwa i
wartość ta będzie stopniowo zmniejszana, w miarę jak będzie on dostarczał piwo
agentowi o nazwie robot. Piwo może być dostarczone w sytuacji, gdy jest wystarczająco
piwa w magazynie, w przeciwnym razie agent robot powinien być poinformowany, że nie
ma więcej piwa w magazynie.
Zadanie 7
(Z przykładu „robot piwny”) Agent robot zamawia piwo u agenta supermarket tylko
wtedy, gdy lodówka jest pusta (plany +stock). Zmodyfikuj kod robota tak, żeby był on
bardziej proaktywny i żeby zamawiał nowe piwo zanim się skończy. Wskazówki: (1)
zauważ, że zmiana nie będzie polegała tylko na zastąpieniu watości 0 wartością 1 w
planie @a2 ponieważ nawet z 1 piwem w lodówce piwo jest nadal dostępne i w związku z
tym przekonanie dotyczące dostępności piwa nie powinno być usuwane; (2) plan @h2
może być usunięty ponieważ robot jest teraz pro aktywny i piwo zawsze będzie dostępne
(co jest szczególnie istotne w gorące letnie dni); (3) gdy określone piwo zostaje
dostarczone (plan @a1) robot nie musi więcej osiągać celu has(owner,beer).
Zadanie 8
(Z przykładu „robot piwny”) W kodzie agenta o nazwie robot są dwa plany dla celu !at.
Co się stanie, jeśli zmieniona zostanie ich kolejność (m2 przed m1)? Co się stanie, jeśli
drugi plan nie będzie miał kontekstu tak jak w kodzie poniżej.
@m1 +!at(robot,P) : at(robot,P) <- true.
@m2 +!at(robot,P) : true
<- move_towards(P);
!at(robot,P).
Czy zachowanie robota będzie takie samo jak w oryginalnym rozwiązaniu?
25

Technologia inteligentnych agentów

Transkrypt

Podobne dokumenty

ZAŁĄCZNIK DO UMOWY AGENCYJNEJ SPRZEDAŻY

Mania-Perfum.pl

Opinia2 - AGENT.m6

Mania-Perfum.pl

Pobierz plik

Mania-Perfum.pl

Wykład X/XI