Sztuczna Inteligencja - studia zaoczne

Informacje wstępne

Przedmiot poświęcony jest podstawowym technikom sztucznej inteligencji. W ramach zajęć laboratoryjnych studenci poznają zasady budowy systemów regułowych. Bieżące informacje dotyczące zajęć: http://www.cs.put.poznan.pl/jpotoniec/?cat=4

Wykład prowadzi dr Artur Michalski, laboratoria prowadzi również dr Tomasz Łukaszewski.

Organizacja zajęć

Zajęcia odbywają się zgodnie z harmonogramem podanym na stronie Wydziału. Obecność na zajęciach, zgodnie z regulaminem studiów, jest obowiązkowa i kontrolowana.

Harmonogram zajęć

  1. Organizacja przedmiotu. Wprowadzenie do systemu CLIPS.
  2. Ćwiczenia z systemu CLIPS, zgłaszanie tematów projektów.
  3. Konsultacje realizacji projektów.
  4. Obrony projektów.

Sposób oceniania

Podstawą oceny jest realizowany w parach projekt, za który można zdobyć 100 punktów. Punkty na oceny przeliczane są zgodnie z poniższymi kryteriami. Nieprzekraczalnym terminem oddania projektu, żeby zaliczyć przedmiot w I terminie, jest 04.07.201413.07.2014. Ocenę w terminie poprawkowym można zdobyć oddając projekt do końca jesiennej sesji egzaminacyjnej (26.09.2014).

LICZBA PUNKTÓW OCENA
[0;50] 2,0
(50;60] 3,0
(60;70] 3,5
(70;80] 4,0
(80;90] 4,5
(90;∞) 5,0

Punkty

Punkty (max 100) Opis
25 0,5 punkt za każdą regułę, max 25 punktów
50 5 punkt za każde pytanie uwzględniające kontekst, max 10 punktów
25 Interfejs użytkownika
-25 Nieuzasadnione stosowanie faktów sterujących.
-25 Niechlujny kod, niekonsekwentny projekt systemu, niespójna reprezentacja danych
-50 Rozwiązania reprezentowane jako fakty zamiast jako reguły.
-50 Brak separacji między wiedzą i danymi przedmiotowymi a interfejsem użytkownika

Szczegółowy opis wymagań

W ramach projektu zaliczeniowego powstać ma system ekspercki wykorzystujący do reprezentacji wiedzy i wnioskowania środowisko CLIPS, natomiast warstwę prezentacji realizujący w Java. Do komunikacji pomiędzy CLIPSem, a Javą użyta powinna zostać biblioteka CLIPSJNI. Przykłady z lat ubiegłych.

Poniższy opis opracowany na podstawie materiałów dr-a A. Michalskiego.

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