Spis treści. Literatura... 23

Transkrypt

1 Spis treści 1 Zbieranie danych metodą Wizard of Oz Przygotowanie eksperymentu Typy interakcji człowieka z komputerem Technologie głosowego systemu dialogowego Realizacja Architektura systemu Przebieg eksperymentu Opis dialogu Wnioski Literatura

2

3 1 Zbieranie danych metodą Wizard of Oz W niniejszym rozdziale został opisany eksperyment mający na celu badanie sposobu komunikacji człowieka z automatycznym systemem dialogowym. Poprzednie rozdziały mówiły o anotacji dialogów człowiek-człowiek nagranych w infolinii ZTM. Chociaż takie dane są bardzo przydatne w pracach naukowych związanych z lingwistyką, nie są idealne do tworzenia komputerowego systemu dialogowego. W celu opracowania jak najlepiej działającego komputerowego systemu dialogowego, konieczne jest zebranie i przeanalizowanie danych zawierających dialogi człowiek-maszyna. Podstawowym tego powodem jest fakt, że sposób prowadzenia dialogu człowieka z maszyną jest w znacznym stopniu odmienny od dialogu z innym człowiekiem. Jak opisano w (Dahlbäck et al., 1993), rozmówcy ciągle dostosowują język do osoby z którą rozmawiają, tzn. w inny sposób będą mówili do dziecka, inaczej do dorosłych, a zupełnie inaczej do cudzoziemca. Metodą zdobycia tego typu danych, o ile nie dysponuje się działającym systemem dialogowym, jest przeprowadzenie symulacji znanej pod nazwą Wizard of Oz (WOZ). Nazwa wywodzi się z popularnej bajki Czarnoksiężnik z Krainy Oz (Baum, 1974) w której bohaterowie spotykają potężnego czarnoksiężnika, który okazuje się być tylko maszyną sterowaną z ukrycia przez zwykłego człowieka. Metoda ta również funkcjonuje pod nazwą PNAM- BIC, czyli Pay No Attention to the Man BehInd the Curtain (nie zwracaj uwagę na człowieka za zasłoną). Polega ona na opracowaniu systemu, który przez użytkownika jest postrzegany jako w pełni automatyczny, komputerowy system dialogowy. W rzeczywistości, tylko niektóre części systemu są zautomatyzowane. Wszelkie procesy wymagające rozumienia mowy, oraz ustalania poprawnej odpowiedzi (ale nie jej wypowiadanie) wykonywane są przez człowieka-operatora, zwanego czarnoksiężnikiem (ang. wizard) albo wspólnikiem (ang. accomplice). Dzięki zastosowaniu powyższej metody, nie tylko można uzyskać bezcenne dane potrzebne do modelowania systemu dialogowego, ale również przetestować różne koncepcje projektowe zanim się przystąpi do implementacji prawdziwego systemu. W trakcie eksperymentu WOZ uzyskuje się zwykle wiele

4 4 1 Zbieranie danych metodą Wizard of Oz zaskakujących informacji na temat samej dziedziny problemowej. Niektóre z takich wniosków opisano w końcowej części tego rozdziału. Dlatego też metoda ta jest powszechnie używana do projektowania systemów dialogowych. Jednak żeby jej zastosowanie przyniosło pożądane rezultaty, system ją realizujący musi spełniać następujące warunki (Fraser i Gilbert, 1991): 1. Symulacja systemu przy pomocy ludzkiego operatora musi być wykonalna. Przygotowując symulację systemu musimy być pewni, że operator będzie w stanie udzielić poprawnej odpowiedzi na zadane mu pytania. Musimy więc utworzyć odpowiednie narzędzia i interfejsy do wyszukiwania odpowiedzi. Na przykład, dla systemu do rezerwacji biletów lotniczych musimy przygotować odpowiednie mapy i bazy danych oraz interfejsy do rozkładów lotów i cenników biletów. W przypadku infolinii ZTM nie było tego problemu, gdyż zadanie polegało na zautomatyzowaniu istniejącej infolinii obsługiwanej przez konsultantów, którzy dysponowali wszelkimi niezbędnymi narzędziami potrzebnymi do udzielenia odpowiedzi. 2. System który chcemy symulować musi być wykonalny. Ponieważ chcemy na podstawie danych uzyskanych z symulacji opracować komputerowy system dialogowy, operacje wykonywane podczas symulacji muszą być również wykonalne przez program. Jeśli nie jesteśmy w stanie odtworzyć symulacji w sposób automatyczny, dane uzyskane w ten sposób będą bezużyteczne. W przypadku naszego badania, złożoność samej dziedziny znacznie ograniczyła możliwości symulacji. Gdybyśmy nie wprowadzili ograniczeń opisanych w póżniejszym rozdziale (1.2.3), nie bylibyśmy w stanie w sposób automatyczny skutecznie rozpoznawać obszernej ilości wyrazów. 3. Symulacja musi być przekonywująca. Ostatnim wymaganiem jest to, aby symulacja była przekonywująca dla osoby, która w niej uczestniczy. Tak jak wcześniej wspomniano, użytkownicy podświadomie dostosowują sposób mówienia do rozmówcy. Jeśli użytkownik nie będzie przekonany, że rozmawia z komputerem, uzyskane tą metodą dialogi nie będą użyteczne przy projektowaniu systemu dialogowego, gdyż sposób prowadzenia dialogu będzie się różnił od przyszłego zastosowania. W celu uzyskania przekonywującej symulacji należy podczas badania odtworzyć prawdziwe warunki w jakich będzie pracować końcowy system. Na przykład, robienie eksperymentu w laboratorium nie jest poprawne z punktu widzenia badania WOZ. Również jest bardzo ważne żeby użyć w badaniu prawdziwych użytkowników. Jeśli jednak nie jest to możliwe i musimy wykorzystać ochotników warto im pozwolić żeby sami wymyślali pytania. Ochotnikowi, który nie zna dziedziny albo ma już przygotowany scenariusz przypadku użycia nie będzie zależało na odpowiedzi tak samo jak prawdziwemu użytkownikowi i jego dialog odzwierciedli ten fakt.

5 1.1. Przygotowanie eksperymentu 1.1 Przygotowanie eksperymentu 5 W trakcie przygotowania symulacji systemu dialogowego zapoznano się najpierw z dziedziną problemową. W tym celu przesłuchano nagrania zebrane w trakcie przygotowywania korpusu dialogów człowiek-człowiek. Następnie przeprowadzono kilka wywiadów z operatorami, żeby poznać ich opinie na temat sposobu funkcjonowania systemu. Na podstawie uzyskanych informacji oraz uwzględniając ograniczenia techniczne wynikające z potrzeby szybkiego generowania wypowiedzi operatora zdecydowano się na nieco inny zestaw tematów zbieranych dialogów, niż te wyodrębnione w procesie tworzenia korpusu nagrań człowiek-człowiek. Do eksperymentu zbierania dialogów przy użyciu metody WOZ wybrano następujące tematy: informacje na temat przysługujących zniżek na przejazdy komunikacją miejską, informacje na temat czasów odjazdów autobusów i tramwajów z poszczególnych przystanków, informacje o wyborze tras i środków przejazdu na podstawie żądanego miejsca początkowego i docelowego, informacje o zgubionym bagażu w pojazdach transportu miejskiego, wszelkiego rodzaju skargi, inne informacje. Pytania o ulgi przysługujące na przejazdy padały dość często i wydawały się w miarę proste do zautomatyzowania. Ponieważ regulamin przysługujących zniżek zawierał ograniczoną liczbę pozycji, całe zadanie sprowadzało się do zaprojektowania prostego drzewa decyzyjnego, które umożliwiało zaklasyfikowanie osoby dzwoniącej do jednej z opisanych kategorii. Wtedy wystarczało poinformować użytkownika o należnej mu zniżce oraz ewentualnie dodatkowych wymaganiach z nią związanych, jak np. posiadanie odpowiednich dokumentów. Pytania na temat czasów odjazdów również nie wyglądały na skomplikowane do zautomatyzowania. Do uzyskania informacji wymagane były cztery podstawowe informacje: numer linii, identyfikacja przystanku, kierunek jazdy oraz przybliżony czas odjazdu jaki interesuje pasażera. Numer linii jest podstawowym identyfikatorem trasy przejazdu dla wybranego środka transportu. Przystanki są zazwyczaj nazywane według miejsca ich położenia, czyli według ulic i placów albo budynków i instytucji znajdujących się w pobliżu. Czasami jednak nie jest łatwo zidentyfikować, o który przystanek chodzi gdyż może być kilka nazwanych według tego samego miejsca, np przy Dworcu Centralnym jest wiele przystanków, których nazwa składa się z nazwy dworca oraz numeru przystanku. Kierunek jazdy jest potrzebny ponieważ prawie wszystkie trasy mają dwa kierunki jazdy. Ostatnią wymaganą informacją jest przybliżony czas odjazdu, bo w ciągu dnia może być nawet kilkadziesiąt odjazdów danej linii z wybranego przystanku. Pytanie o przybliżony czas odjazdu pozwala na ogra-

6 6 1 Zbieranie danych metodą Wizard of Oz niczenie odpowiedzi do godziny odjazdu bezpośrednio przed podanym czasem oraz kilku godzin odjazdów po podanym przez użytkownika czasie. Wyszukiwanie tras jest jedną z najbardziej popularnych oraz skomplikowanych usług infolinii. Zadanie polega na ustaleniu najbliższych przystanków, oraz wybraniu najlepszych środków transportu, tak żeby pasażer mógł dojechać z wybranego miejsca początkowego do celu w jak najkrótszym czasie. Chociaż istnieje w miarę skuteczny system do wyszukania najkrótszej trasy pomiędzy dwoma przystankami, niestety nie znajduje on najbliższych przystanków od dowolnie wybranego przez użytkownika miejsca w Warszawie. Od początku było wiadomo, że jest bardzo trudno skutecznie zautomatyzować odpowiedzi na takie pytania, jednak mimo to zdecydowaliśmy się na jej nagrywanie dialogów na ten temat, gdyby w przyszłości okazało się możliwe ich zautomatyzowanie. Zagubiony bagaż jest najrzadziej poruszaną kwestią przez osoby dzwoniące do infolinii ZTM. Jeśli osoba poda numer linii pojazdu oraz czas kiedy zgubiła bagaż zostanie poinformowana o numerze telefonicznym odpowiedniej zajezdni do której pojechał autobus i gdzie można dostać więcej informacji na temat zagubionego przedmiotu. Wszelkie inne informacje, które nie należały do powyższych pięciu kategorii, były przekierowywane do operatora. Chociaż powyższe kategorie obejmują większość tematów poruszanych w dialogach jest sporo innych problemów z którymi ludzie dzwonili do infolinii, np.: mandaty albo numery telefonów do innych działów. Ponieważ badanie było przeprowadzone w infolinii ZTM na prawdziwych użytkownikach, więc dodano taką opcję, aby dzwoniący mogli uzyskać odpowiedzi na wszelkie interesujące ich pytania Typy interakcji człowieka z komputerem W niniejszym rozdziale przedstawione są kryteria używane do opisu i oceny systemów interakcji człowieka z komputerem. Jedną z takich metod komunikacji, są systemy dialogowe. Kolejne zagadnienia dotyczące sposobów komunikacji, będą omawiane na przykładach systemów dialogowych, które różnią się pod względem możliwości i stopnia złożoności. Modalność W badaniach nad interakcją pomiędzy człowiekiem, a maszyną rozróżnia się kilka sposobów komunikacji. Najprostszy i najstarszy sposób komunikacji to interfejs tekstowy (ang. text-based). Polega on na wykorzystaniu klawiatury do wprowadzania zapytań oraz informacji tekstowej do komputera, a do odczytu odpowiedzi wykorzystywany jest monitor albo inne urządzenie wypisujące tekst. Powszechnie dzisiaj używane udoskonalenie takiej komunikacji to interfejsy graficzne (ang. graphic user interfaces). Dzięki nim, można w znacznym stopniu uprościć komunikację z maszyną, chociaż wciąż jest ona nienaturalna i dla wielu ludzi uciążliwa. Kolejnym udoskonaleniem to komunikacja

7 1.1 Przygotowanie eksperymentu 7 używająca mowy jako podstawowego narzędzia do porozumiewania się (ang. spoken dialog systems). Jest to najbardziej naturalny sposób do komunikacji międzyludzkiej i wydaje się również preferowany w komunikacji z komputerem. Należy zaznaczyć, że sposób ten również ma swoje wady i ograniczenia. Idealnym rozwiązaniem są zatem systemy multimodalne, które łączą w sobie cechy kilku różnych modalności i sposobów komunikacji (Minker et al., 2005). Niemniej jednak, w zależności od środowiska w jakim operujemy, niektóre modalności są mniej lub bardziej wygodne. W środowisku telefonicznym, na przykład, dostępne są tylko dwie metody przekazania informacji. Pierwsza i najbardziej pożyteczna to mowa. Drugi sposób to użycie klawiszy na klawiaturze telefonu. Ten sposób jest często używany ze względu na prostotę w realizacji, jednoznaczność i niezawodność, ale jest też bardzo nielubiany przez użytkowników ze względu na niewygodę w użyciu. Mowa jest dużo bardziej wygodna w tym zastosowaniu. W innych sytuacjach jednak nie musi być idealnym rozwiązaniem. Ponieważ w przypadku systemów głosowych informacja przekazywana jest w sposób sekwencyjny, nie można podać za dużo faktów naraz (więcej w Marasek et al. (2009)). W dodatku należy wziąć pod uwagę jej zawodność, gdyż często podlega zniekształceniu zarówno przez mówce jak i środowisko, w którym się znajduje. Łatwo zatem można popełnić błąd w zrozumieniu co użytkownik chciał powiedzieć. Styl Kolejnym aspektem, rozważanym przy projektowaniu systemu dialogowego jest styl dialogu czyli sposób pozyskiwania informacji. Komunikacja może przebiegać na podstawie poleceń (ang. command-driven). Jest to bardzo proste do zaimplementowania i niezawodne, ale wymaga dużego wysiłku ze strony użytkownika. Musi on znać dobrze wszystkie polecenia i jeśli jest ich dużo, musi często korzystać z dokumentacji opisującej wszystkie polecenia i ich składnię. Styl komunikacji oparty na menu (ang. menu-driven) nieco ułatwia porozumiewanie się. W każdym kroku mamy do wyboru kilka opcji zrozumiałych dla użytkownika i zazwyczaj nie jest potrzebna dodatkowa dokumentacja, żeby się posługiwać systemem. W porównaniu do systemu sterowanego poleceniami, komunikacja oparta na menu jest trochę wolniejsza i nieco bardziej skomplikowana do zaimplementowania. Szczególnie pod względem ergonomii. Ostatecznie, styl komunikacji może być oparty na języku naturalnym (ang. natural language-driven). Oznacza to, że się do maszyny możemy zwracać jak do człowieka. Z punktu widzenia użytkownika jest to bardzo wygodne, ale też i zawodne. Po pierwsze, język naturalny jest niezwykle skomplikowany i bardzo trudno zrobić poprawną automatyczną implementację. W dodatku, w języku naturalnym występuje wiele niejednoznaczności, a maszyna niestety nie posiada zdrowego rozsądku żeby sobie z nimi radzić.

8 8 1 Zbieranie danych metodą Wizard of Oz Polecenia Menu Język naturalny U Otwórz katalog zdjęcia. S Witaj w systemie. Opcje: S Witaj w systemie. S Otwieram. Użytkownicy, Hasła... W czym mogę pomóc? U Wyszukaj plik kwiat.jpg. U Hasła. U Chciałbym zarezerwować S Znalazłem. S Dostępne opcje to: bilet na Matrixa jutro o 20ej. U Wyświetl plik. zmień hasło, usuń hasło... S Rezerwuję bilet na film S Wyświetlam. U Zmień hasło. Matrix, jutro o godzinie... S Proszę podaj nowe hasło. 21:00. Czy dobrze?... U Tak. Tablica 1.1. Przykłady dialogów ze względu na styl. (U-użytkownik, S-system) Inicjatywa Kolejnym zagadnieniem wymagającym ustalenia przy projektowaniu systemu dialogowego jest strona posiadająca inicjatywę w prowadzeniu rozmowy, czyli zadająca pytania (Cohen et al., 2004). Gdy podczas dialogu rozmową kieruje system to jest to dialog z inicjatywą sytemu (ang. system-initative), a gdy kieruje użytkownik, to jest to dialog z inicjatywą użytkownika (ang. userinitative). Najlepsze systemy dialogowe mają tzw. mieszaną inicjatywę (ang. mixed-initative), gdzie zarówno użytkownik może przejąć inicjatywę (gdy chce sterować przebiegiem dialogu), jak i maszyna (gdy, np. potrzebuje dodatkowych informacji). Poniżej umieszczony jest przykład dialogu o mieszanej inicjatywie. Dialog zaczyna się od inicjatywy użytkownika, który po powitaniu przez system formułuje proste zlecenie. Jednak, w wyniku braku ważnej informacji system przejmuje inicjatywę i zadaje pytanie użytkownikowi. S Witam w systemie. W czym mogę pomóc? U Chciałbym zarezerwować bilet na jutro do Londynu. [inicjatywa użytkownika] S Z jakiego lotniska chce Pan wylecieć? [inicjatywa systemu] U Z Warszawy. S Rezerwuję bilet na jutro z Warszawy do Londynu. Czy dobrze? U Tak. Tablica 1.2. Przykład mieszanej inicjatywy. Dziedzina Dziedzina dialogu ma wpływ na wiele czynników decydujących o zawiłości końcowego rozwiązania. Im szersza dziedzina tym trudniej zaprojektować system dialogowy. Jednym z najważniejszych zadań w trakcie projektowania systemu dialogowego jest maksymalne zawężenie dziedziny dialogu, z zachowaniem wszelkich przewidywanych funkcji. Dodatkowo, jeśli dziedzina dialogu jest zbyt skomplikowana często trzeba w ramach kompromisu zrezygnować z

9 1.1 Przygotowanie eksperymentu 9 bardziej skomplikowanych modułów systemu takich jak analiza języku naturalnego albo rozpoznawania mowy. Niektóre przykładowe dziedziny, to: rezerwacja (biletów, hoteli, spotkania... ), udzielanie informacji (o produktach, usługach... ), wyszukiwanie informacji (książki telefoniczne, katalogi firm... ), bankowość, automatyka, sterowanie robotami, edukacja, medycyna, zabawa Technologie głosowego systemu dialogowego Niniejszy rozdział opisuje poszczególne technologie w głosowych systemach dialogowych (ang. Spoken Dialog Systems). Rozpoznawanie mowy Menadżer dialogu Synteza mowy Rysunek 1.1. Schemat głosowego systemu dialogowego. Jak pokazano na rysunku 1.1 podstawowy głosowy system dialogowy składa się z następujących elementów: systemu rozpoznawania mowy, syntezatora mowy oraz menadżera dialogu. Sygnał dźwiękowy generowany przez rozmówcę jest analizowany przez system rozpoznawania mowy, który rozpoznaje w wypowiedzi sekwencję wyrazów. Wyrazy te są interpretowane przez menadżera dialogu, który również podejmuje decyzję co należy wykonać i ewentualnie generuje odpowiedź tekstową, która jest przekazywana do syntezatora. Syntezator na podstawie otrzymanej informacji tekstowej generuje sygnał mowy słyszany przez rozmówce.

10 10 1 Zbieranie danych metodą Wizard of Oz Rozpoznawanie mowy Automatyczne rozpoznawanie mowy to proces, w trakcie którego sygnał mowy jest konwertowany na zapis tekstowy danej wypowiedzi. W przypadku telefonicznego systemu dialogowego sygnał mowy pochodzi z linii telefonicznej, którego jakość jest obniżona z powodu ograniczonej przepustowości kanału transmisyjnego. W dodatku, w takim sygnale może występować wiele zniekształceń i szumów, zarówno ze względu na otoczenie użytkownika telefonu (szczególnie użytkowników telefonów przenośnych) jak i przez liczne usterki i wady skomplikowanej sieci telefonicznej. Ponadto należy uwzględnić wiele specyficznych sposobów wymowy oraz drobne błędy popełniane w mowie. Wszystko to wpływa na brak pełnej, stuprocentowej skuteczności w rozpoznawaniu mowy przez komputer. Wejście (np. mikrofon) Sygnał Detekcja mowy i parametryzacja Cechy sygnału (MFCC, energia, delty) Model akustyczny Prawdopodobieństwo wystąpienia sekwencji fonemów (x ts a w... ) Wyszukiwanie Prawdopodobieństwo wystąpienia sekwencji wyrazów P (w t w t 1, w t 2,...) Hipoteza (chciałbym poprosić... ) Model języka Rysunek 1.2. Schemat procesu rozpoznawania mowy. Ze względu na złożoność problemu wynikającą z ilości wyrazów jakie muszą być rozpoznawane, cały proces jest podzielony na kilka kroków (rys. 1.2). Sygnał mowy jest w pierwszej kolejności analizowany za pomocą algorytmów przetwarzania sygnałów, żeby wyodrębnić zestaw cech dobrze opisujący zachodzące w sygnale zjawiska akustyczne. Najczęściej są to cechy wynikające z analizy spektralnej sygnału. Na podstawie tych cech budowany jest model akustyczny, który służy do wyszukiwania jednostek fonetycznych (np. fonemów, difonów, trifonów...) w analizowanym sygnale. Na podstawie rozkładu

11 1.1 Przygotowanie eksperymentu 11 prawdopodobieństwa jednostek fonetycznych w czasie, wyszukiwane są potencjalne sekwencje wyrazów. Sekwencje te są dodatkowo ważone przy pomocy modelu języka. Tworząc model języka ustala się prawdopodobieństwa pojawienia się sekwencji wyrazów o pewnej długości (sekwencje jednowyrazowe zwane są unigramami, pary wyrazów bigramami, trójki trigramami itd.). Proces wyszukiwania najbardziej prawdopodobnej sekwencji wyrazów nazywa się dekodowaniem. Każde potencjalne rozwiązanie rozpatrywane w procesie dekodowania nazywa się hipotezą. W celu porównywania hipotez bierze się pod uwagę ich całkowite prawdopodobieństwa wyliczone na podstawie modelu akustycznego oraz modelu języka. Czasami zamiast jednego najlepszego rozwiązania, system zwraca listę kilku najlepszych. Listy takie nazywają się listami n-najlepszych sekwencji (ang. n-best ) i szczególnie przydają się w sytuacjach gdy system błędnie rozpozna słowo. Wtedy, może podać użytkownikowi listę n-best żeby z niej wybrał poprawną wypowiedź. Sytuacje takie się często zdarzają kiedy system rozpoznaje wyrazy podobnie brzmiące i błędny wyraz zostaje rozpoznany jako najlepszy. Mimo niewłaściwego pierwszego wyboru, poprawny wyraz się najczęściej znajduje w kilku pierwszych hipotez na liście n-best. Synteza mowy Problem sztucznego generowania mowy jest tematem, który zajmuje ludzi od dawna. Najwcześniejsze znane urządzenia symulujące głos ludzki pochodzą jeszcze z XVIII wieku. Programy do syntezy mowy mają liczne zastosowania. Oprócz systemów dialogowych wykorzystywane są na przykład jako narzędzie rehabilitacyjne dla osób niemych lub niewidomych. Głównym problemem w przygotowaniu dobrego syntezatora jest osiągnięcie naturalnej wymowy. Z praktycznego punktu widzenia, dla wielu zastosowań wystarczająca jest zrozumiałość mowy, co się obecnie daje stosunkowo łatwo uzyskać. Projektując system dialogowy dla masowego odbiorcy należy jednak zwrócić uwagę na opracowanie (lub wykorzystanie istniejącego) syntezatora mowy o naturalnym głosie. Wiele osób może zostać zniechęconych do korzystania z informacji odczytywanych nienaturalnym, nieprzyjemnym dla człowieka głosem. Istnieje wiele metod syntezy mowy. Pierwsze, analogowe syntezatory starały się naśladować działanie organów mowy. Wiele z opracowanych wówczas metod później przeniesiono do systemów komputerowych, ale wyniki zawsze były niezadowalające. O wiele prostszą i efektywniejszą metodą syntezy okazała się synteza konkatenacyjna. Polega ona na sklejaniu nagranych fragmentów mowy w gotowe wypowiedzi. Pierwsze takie syntezatory polegały na sklejaniu krótkich jednostek fonetycznych difonów. Chociaż jest to rozwiązanie proste i bardzo oszczędne pod względem zasobów, bardzo trudno w nim osiągnąć naturalność. Okazuje się, że jeśli użyjemy dłuższych jednostek, np trifonów, synteza staje się o wiele bardziej naturalna. Niestety korzystanie z długich jednostek powoduje, że ilość potrzebnych danych bardzo wzrasta: wykładniczo wraz ze wzrostem długości jednostek.

12 12 1 Zbieranie danych metodą Wizard of Oz Z tego powodu, obecnie najbardziej popularną metodą syntezy jest tzw. synteza korpusowa, zwana po angielsku: non-uniform unit selection synthesis. Polega ona na nagraniu jak największego korpusu akustycznego (ograniczonego jedynie wymaganiami sprzętowymi docelowego rozwiązania). W trakcie syntezy wyszukiwane są w nim potrzebne fragmenty mowy i łączone w ostateczną wypowiedź. Opracowano wiele kryteriów wyboru tych fragmentów, ale podstawowym jest długość: im dłuższy fragment, tym lepszy będzie wynik. Ważnym kryterium jest też kontekst, bo na przykład fragment z końca zdania nie będzie brzmiał dobrze na początku zdania. Niektórych wyszukanych fragmentów nie można złączyć razem w naturalnie brzmiącą całość ze względu na różnice w wymowie (pitch, tempo mówienia, itp.). Do oceny jakości wybranego fragmentu wypowiedzi budowana jest specjalna funkcja kosztu (Szklanny, 2009), która ocenia jakość rozwiązania pod względem różnych kryteriów, jak te wspomniane wcześniej. Zadanie sprowadza się do wyszukania najlepszego rozwiązania spośród wszystkich możliwych. Menadżer dialogu Zasadniczym modułem każdego systemu dialogowego jest menadżer dialogu. W zależności od przeznaczenia systemu dialogowego, menadżer może spełniać wiele funkcji, a jego budowa jest zależna od stylu (patrz 1.1.1) dialogu. Najprościej zbudować menadżera dialogu dla systemu używającego poleceń albo menu. W przypadku poleceń wystarczy zrobić prosty interpreter dokładnie wyspecyfikowanych poleceń, natomiast w przypadku menu dodać do interpretera mechanizm stanów i przejść pomiędzy nimi. Jeśli jednak system dialogowy używa języka naturalnego do komunikacji to menadżer musi korzystać z modułu analizy i rozumienia mowy (Damnati et al., 2007) Realizacja W tym rozdziale opisane są szczegóły systemu jaki został użyty do nagrania korpusu przy użyciu metody WOZ w infolinii ZTM. System zbudowano na podstawie już funkcjonującej platformy telefonicznej używanej w Polsko-Japońskiej Wyższej Szkole Technik Komputerowych (PJWSTK) (Łukasz Brocki et al., 2008). Platforma ta posiada wszystkie komponenty systemu dialogowego. Niewielkie zmiany zostały dokonane w celu przystosowania do badania WOZ Architektura systemu Cały system jest zainstalowany na komputerze typu PC. Do połączenia komputera z siecią telefoniczną użyto specjalnej karty telefonicznej Dialogic. Karta ta posiada dedykowane procesory do przetwarzania sygnału, które niwelują

13 1.2 Realizacja 13 echo obecne często w analogowych liniach telefonicznych. Dodatkowo, karty te umożliwiają prowadzenie wielu równoległych rozmów. Jeśli chodzi o oprogramowanie, składa się ono z czterech podstawowych modułów(rys. 1.3): bramki telefonicznej, menadżera dialogu, rozpoznawania i syntezy mowy. Korzystają one z komunikacji sieciowej do przekazywania informacji. Oznacza to, że każdy moduł mógłby pracować na innym komputerze, gdyby moc jedynego komputera nie była wystarczająca. Rysunek 1.3. Architektura systemu dialogowego, za pomocą którego przeprowadzono eksperyment WOZ. Bramka telefoniczna Bramka (ang. gateway) to moduł służący do połączenia systemu ze światem zewnętrznym. W naszym przypadku jest to bramka telefoniczna, gdyż system komunikuje się z użytkownikiem wyłącznie przez telefon. Zadanie bramki jest bardzo proste: przekierowuje sygnał z linii telefonicznej do modułu rozpoznawania mowy lub z syntezatora mowy do linii telefonicznej. O tym, kiedy rozpoznawać, a kiedy syntezować mowę ostatecznie decyduje menadżer dialogu, ale sygnał dźwiękowy jest cały czas przekierowywany przez bramkę. Innym

14 14 1 Zbieranie danych metodą Wizard of Oz zadaniem bramki jest sterowanie samym połączeniem. Bramka decyduje kiedy odebrać rozmowę i jest w stanie, na zlecenie menadżera dialogu, przerwać albo przekierować rozmowę. Przekierowanie polega na wysłaniu specjalnych tonów (tzw. DTMF, Dual-Tone Multi-Frequency) do centrali telefonicznej. Wszystkie te rzeczy są wykonywane sprzętowo na samej karcie telefonicznej. Menadżer dialogu Menadżer dialogu jest głównym modułem zarządzającym przebiegiem dialogu. Do naszego badania wybraliśmy styl oparty na menu i budowa menadżera odzwierciedla tą decyzję. Schemat dialogu w menadżerze składa się z szeregu stanów, które są połączone w graf. W każdym stanie umieszczony jest skrypt, który zawiera proste polecenia typu: rozpoznaj wypowiedź, syntezuj odpowiedź, pobierz informacje z bazy danych, przejdź do innego stanu dialogu, czy przerwij rozmowę. Na rysunku 1.4 widać przykład takiego dialogu w specjalnie utworzonym do tego celu edytorze dialogu. Polecenia mogą być dodawane w zależności od wymagań opracowywanej aplikacji. Obecnie zaimplementowane są następujące rodzaje poleceń: kontrola przepływu dialogu wyrażenia warunkowe (if/else,switch) i zmiana stanów, manipulacja zmiennymi metody do zmiany zmiennych tekstowych oraz innych typów danych (np. konkatenacja ciągów znakowych, dodawanie liczb...) mowa rozpoznawanie i synteza, dane pobieranie danych z baz danych, internetu lub innych źródeł. Serwer ASR i aplikacja WOZ W automatycznym systemie dialogowym serwer do automatycznego rozpoznawanie mowy (ASR Automatic Speech Recognition) służy do rozpoznawania mowy z sygnału, który otrzymuje od bramki telefonicznej. Sam proces rozpoznawania mowy jest sterowany przez menadżera dialogu. Decyduje on, kiedy system ma rozpocząć rozpoznawanie, jakie wyrazy mają być rozpoznawane oraz inne opcje systemu rozpoznawania mowy, jak np. n-best (patrz ). Słownictwo jakie ma być rozpoznawane opisane jest w specjalnej gramatyce formalnej. Mówi ona jakie sekwencje wyrazów są poprawne a jakie nie, w danym kontekście. W trakcie projektowania, gramatyki są pisane w języku podobnym do wyrażeń regularnych, a potem konwertowane do postaci grafu o skończonej ilości stanów. Jeśli użytkownik powie coś co nie jest modelowane przez gramatykę, system najczęściej odpowie, że nie zrozumiał wypowiedzi i poprosi o powtórzenie. Do realizacji eksperymentu WOZ, wystarczyło zamienić serwer ASR na specjalną aplikację okienkową, która była sterowana przez operatora czarnoksiężnika. Tak samo jak w przypadku modułu ASR i gramatyk, aplikacja

15 1.2 Realizacja 15 Rysunek 1.4. Wygląd edytora dialogu. ta na wejściu dostawała listę wyrazów jakie są dozwolone w danym stanie dialogu. Zadaniem operatora było proste wybranie jednej opcji na podstawie tego co powiedział użytkownik. Dialog był tak zaprojektowany, by w każdej chwili było dostępnych od kilku do kilkunastu opcji. Na rysunku 1.5 widać jedno z okienek służących do wybrania odpowiedzi przez operatora. Wyświetlone są w nim opcję dotyczące pytania o zniżkę na bilet. Użytkownik może wybrać jedną z pięciu opcji (student, emeryt, rencista, uczeń, inna osoba), po której przejdzie do innego stanu dialogu. Jeśli powie coś spoza tych opcji, zostanie poproszony o powtórzenie. Po kilku nieudanych próbach zostanie przekierowany do operatora. Serwer TTS Serwer synteza mowy TTS (ang. Text-To-Speech) służy do generowania mowy słyszanej przez użytkownika systemu. Sygnał mowy może przychodzić z syntezatora lub z gotowych nagrań. Nagrań użyto wszędzie tam gdzie treści generowanej wypowiedzi się nie zmieniają. Przygotowano kilkadziesiąt takich nagranych wypowiedzi. Synteza wypowiedzi była użyta do czytania tylko zmieniających się informacji, jak np zmiany w przepisach w ulgach biletowych. W

16 16 1 Zbieranie danych metodą Wizard of Oz Rysunek 1.5. Aplikacja WOZ sterowana przez operatora. opracowanym systemie użyto komercyjnego narzędzia jakim jest syntezator korpusowy firmy Loquendo Przebieg eksperymentu Eksperyment nagrywania dialogów z wykorzystaniem metody WOZ został przeprowadzone w infolinii ZTM. W chwili wykonywania testu infolinia mieściła się w jednym pokoju i miała cztery stanowiska dla konsultantów. Infolinia pracuje 24 godziny na dobę, 7 dni w tygodniu, ale ilość operatorów się zmienia w zależności od pory dnia. Do przeprowadzenia badania, przygotowany system został zainstalowany na jednym z czterech stanowisk. Infolinia zwyczajnie pracuje w ten sposób, że gdy ktoś dzwoni aktywują się wszystkie włączone telefony. Pierwszy operator, który podniesie słuchawkę przyjmuje rozmowę. Telefony można wyłączyć w przypadku gdy jest mniej operatorów. System WOZ podłączono w taki sposób, żeby odbierał telefon po jednym dzwonku. W ten sposób inni operatorzy mieli chwile żeby zadecydować czy sami odbiorą rozmowę, czy zostanie obsłużona przez system i operatorów systemu WOZ. Gdy system zbierał dane wówczas przy stanowisku musiał siedzieć pracownik infolinii, który był w stanie podawać poprawne odpowiedzi na pytania. Oprócz pracownika infolinii, przy stanowisku siedział pracownik zespołu badawczego, który sterował systemem na zalecenia operatora. Stanowisko składało się z komputera PC z klawiaturą, myszą i monitorem. Komputer był podłączony bezpośrednio do centrali telefonicznej. Do komputera były podłączone dwa zestawy słuchawkowe umożliwiające podsłuch rozmowy

17 1.2 Realizacja 17 telefonicznej a po naciśnięciu przycisku przejście do tradycyjnego dialogu operatora z osobą dzwoniącą. Sieć telefoniczna Operator infolinii Operator systemu WOZ Rysunek 1.6. Schemat badania WOZ. Klient Opis dialogu Poniżej omówiony jest schemat prowadzenia konwersacji przy użyciu systemu WOZ. Po dodzwonieniu się do systemu użytkownik był witany przez system i informowany, że rozmowa jest nagrywana. Następnie był proszony o wybranie jednej z następujących opcji: Czasy odjazdu, Jak dojechać, Zniżki, Zgubiony bagaż, Skargi, Inne informacje. Jeśli osoba powiedziała coś czego nie ma na powyższej liście albo milczała to operator mógł wybrać opcję, żeby system przeczytał spis tematów jeszcze raz. W dowolnej chwili można było przełączyć rozmowę do konsultanta.

18 18 1 Zbieranie danych metodą Wizard of Oz Czasy odjazdu W trakcie projektowania dialogu wiedzieliśmy, że będzie to temat który na pewno będziemy w stanie zautomatyzować. Chociaż w prawdziwej realizacji musieliśmy dorobić kilka szczegółów (Łukasz Brocki et al., 2009), większość dialogu była prosta i zrozumiała. Zadanie polega na podaniu czasów odjazdu autobusu lub tramwaju z danego przystanku w danym kierunku. Na samym początku dialogu użytkownik jest informowany, że będzie musiał odpowiedzieć na cztery proste pytania. Jest to niezbędne, gdyż bez informacji o ilości pytań sporo osób było zniechęconych do odpowiadania na pytania i przerywało rozmowę. Pierwsze pytanie to numer linii, po tym nazwa przystanku, później kierunek jazdy i na samym końcu przybliżona godzina. Pytania te zostały już omówione w rozdziale 1.1. Po udzieleniu odpowiedzi na wszystkie cztery pytania użytkownik był przekierowywany do pracownika infolinii, który mu udzielał odpowiedzi. Postępowanie takie nie jest do końca zgodne z zasadą prowadzenia eksperymentu WOZ. Zdecydowano się na nie gdyż w przeciwnym wypadku trzeba byłoby opracować szybki sposób wprowadzania danych o czasie odjazdu autobusów i tramwajów z danego przystanku do modułu syntezy mowy. Dane te powinny być podawane w postaci tekstowej czyli np.: ósma piętnaście. Lepszym rozwiązaniem byłoby pobierania tych informacji bezpośrednio z bazy danych. Nie zostało to jednak zrealizowane ze względu na ograniczony czas przygotowania eksperymentu. Jak dojechać Tak jak już wspomniano we wcześniejszym rozdziale, temat ten jest bardzo trudny do zautomatyzowania. Po przeanalizowaniu zagadnienia postanowiono opracować bardzo prostą symulację komunikacji z użytkownikiem polegającą na zadaniu dwóch pytań o punkt początkowy i końcowy planowanej przez rozmówcę podróży. Tak jak w przypadku poprzedniej tematyki dialogu, odpowiedź była udzielana przez operatora, który wielokrotnie musiał zadawać dodatkowe pytania w celu ustalenia o jakie punkty faktycznie chodzi pytającemu. Trudności wynikały z braku precyzji wypowiedzi osoby dzwoniącej a czasami z braku wiedzy o topologii miasta, szczególnie w przypadku osób odwiedzających stolicę. Odpowiedź jest zwykle skomplikowana i składała się z opisu: przystanków, przesiadek oraz godzin odjazdu poszczególnych środków transportu. Wyjaśnianie tych kwestii jest niekiedy czasochłonne i zależy od skomplikowania połączenia (liczby przesiadek) oraz doświadczenia osoby dzwoniącej w korzystaniu z transportu publicznego Warszawy. Zniżki Pytania dotyczące zniżek przysługujących na przejazdy były jedynymi tematami rozmów, które udało się w pełni zautomatyzować. Dialog polegał na zadaniu kilku pytań (najwyżej czterech) typu czy jesteś studentem?, czy

19 1.2 Realizacja 19 jesteś emerytem? a po udzieleniu na nie odpowiedzi, użytkownik otrzymywał opis zniżki jaka mu przysługuje oraz ewentualne dodatkowe informacje związane z warunkami korzystania z niej. Na koniec istniała możliwość przesłuchania całego dialogu albo połączenia się z operatorem. W przypadku kilku osób uczestniczących w eksperymencie było to niezbędne, gdyż ich problemy wykraczały poza zagadnienia zaprojektowane w automatycznym dialogu. Zgubiony bagaż Po bliższym zapoznaniu się z przykładami dialogów dotyczących tego tematu zrezygnowano z jego automatyzacji. Liczba osób zgłaszających się z tym problemem do infolinii była niewielka, a każda rozmowa przebiegała według innego schematu. Wspólne dla wszystkich dialogów było jedynie uzyskanie informacji na temat czasu i miejsca zgubienia bagażu. Resztę szczegółów dotyczących zdarzenia musiał ustalać operator. Skargi Jest to opcja systemu, z której operatorzy infolinii korzystali bardzo chętnie. Zanim wprowadzono możliwość nagrywania skarg, zadaniem operatorów było ich spisywanie. Niezadowoleni pasażerowie bardzo chętnie korzystają z infolinii w celu zgłaszania wszelkich skarg, z których najliczniejsza grupa dotyczy opóźnień pojazdów. Spisywanie ich było nie tylko czasochłonne ale też nieprzyjemne dla operatorów, którzy niejednokrotnie musieli oni wysłuchiwać pretensji rozdrażnionych a nawet czasami agresywnych pasażerów, co w rezultacie miało ujemny wpływ na efektywność ich dalszej pracy. Zaproponowane rozwiązanie polega na zrobieniu prostego systemu nagrywającego. Na samym początku użytkownik jest informowany o tym, że jego skarga zostanie nagrana oraz jakie informacje musi podać. Po sygnale może mówić dowolnie długo, wypowiedź swoją kończąc przez naciśnięcie klawisza albo przez odwieszenie słuchawki. System ten okazał się bardzo skuteczny i wciąż jest używany przez infolinię. Skargi są przesłuchiwane codziennie przez jedną osobę. Nagrane pliki dźwiękowe są analizowane, a te które zawierają skargi na kierowców są wysyłane do odpowiednich firm przewozowych. Inne informacje W przypadku gdy osoba dzwoniąca ma pytanie na temat inny niż zaprojektowano w systemie, może ona wybrać opcję Inne informacje, co natychmiast przekierowuje rozmowę do operatora. Początkowo opcja ta była nazwana Połącz z operatorem, ale wówczas była nadużywana przez dzwoniących, którzy woleli rozmawiać z człowiekiem niż z systemem.

20 20 1 Zbieranie danych metodą Wizard of Oz 1.3. Wnioski Podczas eksperymentu, udało się uzyskać sporo cennych informacji jak powinien być zaprojektowany komputerowy system ułatwiający działanie infolinii. Zebrano również pierwsze doświadczenie w jaki sposób użytkownicy reagują na kontakt z systemem komputerowym. W trakcie badania, większość osób była zdziwiona obecnością automatycznego systemu. Objawiało się to w taki sposób, że osoba dzwoniąca albo milczała przez dłuższy czas, albo mówiła rzeczy niezwiązane z dziedziną. Spowodowane to było faktem, że wiele telefonów było od osób dzwoniących regularnie do infolinii spodziewających się człowieka-operatora. Dodatkowo w Polsce nie ma podobnych zautomatyzowanych infolinii, przez co ludzie nie są przyzwyczajeni do komunikacji głosowej z komputerem. Wiele osób czuło się nieswojo rozmawiając z systemem komputerowym, a niektórzy starali się usilnie połączyć z operatorem. Były sytuacje, gdy dzwoniący przez pomyłkę wybrał złą opcję, i nie potrafił się z niej wycofać. W takich przypadkach trzeba było przerywać eksperyment i przełączać użytkownika do konsultanta. Z drugiej strony, często się zdarzało, że mimo początkowej niechęci i zdziwienia, po uzyskaniu informacji, ludzie wyrażali zadowolenie z pracy systemu. Automat pozwalał na usystematyzowanie całego procesu i czasami nawet przyspieszał uzyskiwanie informacji. Pod koniec kilkutygodniowego okresu trwania eksperymentu, zauważyliśmy iż część osób znała system na tyle dobrze, że od razu mówili co potrzebują, nie czekając na instrukcje od systemu. Często osoby dzowniące kończyły dialog podziękowaniem za podanie informacji. W tym celu dodano podziękowanie od strony systemu na końcu zautomatyzowanego dialogu. Kilka decyzji projektowych zmieniono pierwszego dnia eksperymentu, żeby się dostosować do reakcji użytkowników. Dodano możliwość powtarzania wszystkich opcji gdyż ludzie w ogóle nie reagowali jak system pierwszy raz czytał polecenia. W przypadku tematu czasów odjazdów środków transportu, na początku poinformowano użytkownika o ilości pytań gdyż sama informacja o tym, że trzeba odpowiedzieć na pytania zniechęcała użytkowników do korzystania z systemu. Kategoria Ilość Procent Średnia Średnia rozmów rozmów długość (HM) długość (HH) Czasy odjazdu % Wyszukiwanie trasy % Zniżki 39 8% Zgubiony bagaż 11 2% N/A Skargi 57 12% N/A Tablica 1.3. Porównanie długości nagrań. HM człowiek-maszyna. HH człowiekczłowiek. Długości są w sekundach.

21 1.3 Wnioski 21 W tabeli 1.3 podano statystyki dotyczące danych zebranych w trakcie eksperymentu WOZ. Wynika z nich, że użytkownicy najczęściej dzwonili w celu znalezienia połączenia, kolejnymi najczęstszymi tematami rozmów były: czasy odjazdu i zniżki. W tabeli umieszczono porównanie średniej długości dialogu użytkownika infolinii z systemem WOZ ze średnią długością rozmowy z operatorem. Powodem dłuższych rozmów z systemem komputerowym jest przede wszystkim nieznajomość systemu, przez co większość klientów czekało i słuchało wszystkich instrukcji, które podawał system, często wielokrotnie. W trakcie eksperymentu, zauważono, że część osób się nauczyła korzystać z systemu i potrafiła dużo szybciej przejść przez cały dialog i uzyskać żądane informacje. Wnioski z przeprowadzonego badania oraz same nagrania użyto do zbudowania automatycznego systemu informacyjnego dla infolinii ZTM (Łukasz Brocki et al., 2009).

22

23 Literatura Baum, L. F. (1974). The Wonderful Wizard of Oz. Colins, London. Cohen, M. H., Giangola, J. P., i Balogh, J. (2004). Voice User Interface Design. Addison-Wesley Professional. Dahlbäck, N., Jönsson, A., i Ahrenberg, L. (1993). Wizard of oz studies: why and how. W: IUI, str Damnati, G., Béchet, F., i Mori, R. D. (2007). Spoken language understanding strategies on the france telecom 3000 voice agency corpus. W: International Conference on Acoustics, Speech, and Signal Processing. Fraser, N. N. i Gilbert, G. N. (1991). Simulating speech systems. Computer, Speech and Language, 5, Marasek, K., Łukasz Brocki, Koržinek, D., Szklanny, K., i Gubrynowicz, R. (2009). Aspects of Natural Language Processing: Essays Dedicated to Leonard Bolc on the Occasion of His 75th Birthday, chapter User Centered Design for a Voice Portal. Springer. Minker, W., Bühler, D., i Dybkjær, L. (2005). Spoken multimodal humancomputer dialogue in mobile environments. Springer. Szklanny, K. (2009). Cost function estimation in unit selection speech synthesis. Rozprawa doktorska, PJWSTK, Warsaw. Łukasz Brocki, Koržinek, D., i Marasek, K. (2008). Telephony based voice portal for a university. W: Speech Analysis, Synthesis and Recognition, Applications in Systems for Homeland Security. Łukasz Brocki, Koržinek, D., i Marasek, K. (2009). Voice portal for public city transportation. W: Interfejs użytkownika Kansei w praktyce. Wydawnictwo PJWSTK.