IBM: Dialog Systems - Location D4 – High-Fidelity prototyp A4M39NUR – ZS-2016 – Marek Timr, Jan Vrátník
1 Úvod V této závěrečné části semestrální práce se budeme věnovat testování highfidelity prototypu dialogového systému, který má sloužit k nalezení uživatelovo polohy v budově E areálu ČVUT na Karlovo náměstí v Praze. Uživatel má ovládat systém pomocí hlasové komunikace. V případě testování našeho prototypu nás bude zajímat především to, jak uživatel komunikuje se systémem, zda ví, jak odpovědět na pokládané otázky, zda dokáže reagovat a řešit problematické situace nebo zda se bez problémů orientuje ve námi vytvořeném uživatelském rozhraní. Testování probíhalo v areálu ČVUT na Karlovo náměstí dne 7.1.2016.
2 Prototyp Prototyp jsme vytvořili jako desktopovou aplikaci v jazyce Java. Podobu této aplikace jsme přizpůsobili tomu, jak by vypadala na mobilních zařízení. Ukázku obrazovek lze vidět na obrázcích Náhled aplikace 1 a Náhled aplikace 2.
2.1 Ovládání Program v průběhu dialogu komunikuje se službami IBM Bluemix, proto pro správné fungování je třeba, aby zařízení bylo připojené k internetu. Po spuštění dialogu je důležité, aby uživatel nechal domluvit systém. Stisknutím a držením (toto je velmi důležité) tlačítka ’Push to talk’ může uživatel zahájit odpovídání systému. Prototyp je schopný reagovat na různé formulace očekávaných odpovědí, to ovšem neznamená, že bude rozumět úplně všemu. Když chce například uživatel odpovědět na otázku "What floor are you on?" (Na jakém jsi patře?), může říct "I’m on the second floor.", "second floor", "I think I am on second floor." a jiné podobné formulace, tak mu bude systém korektně rozumět. To proto, že v souboru dialog.xml je definované, aby systém 1
rozpoznal větu obsahující slovo second (nebo first apod.). Pokud ale třeba uživatel odpoví two místo second, tak systém nebude rozumět, protože tato alternativa není definovaná. To je jeden z problémů, kterému se věnujeme v pozdějších kapitolách. Pokud uživatel nezná odpověď, může odpovědět i negativně na způsob "I don’t know.", "I can’t see anything." a podobně. Je možné vrátit se i k předchozí otázce pomocí formulací typu "I want to repeat last question.", "That’s not correct.", "Answer again.".
2.2 Funkcionalita Vzhledem k tomu, že naše aplikace je ovládaná z velké části právě hlasem, je uživatelské rozhraní velmi minimalistické. Obsahuje pouze ovládací prvky pro zahájení/ukončení dialogu a pro mluvení. Kromě toho vizuálně znázorňuje průběh dialogu pomocí textových bublin, podobně jako je tomu u většiny SMS a jiných chatovacích programů. Aplikace je závislá na službách Dialog, Speech-to-Text a Text-to-Speech, které poskytuje systém IBM Bluemix. Workflow prototypu je znázorněn na Sekvenčním diagramu 1. Prototyp se dotazuje služby Dialog na stav aplikace, podle toho ví, co by měl systém říct. Celá tato komunikace probíhá v textové podobě, proto pokud program chce uživateli text přečíst, musí zavolat službu Text-to-Speech, která na text vrátí audio soubor. Stejně tak když aplikace chce vyhodnotit, co uživatel řekl, je potřeba hlas nejprve převést na text a až poté odpověď poslat službě Dialog v textové podobě, aby se rozhodla, kudy vést dialog dál.
2
Obrázek 1: Sekvenční diagram komunikace se systémem IBM Bluemix Služba Dialog udržuje stav dialogu a rozhoduje na základě specifikovaných pravidel, jak mezi jednotlivými stavy přecházet. Závisí na odpovědích uživatele, které se z hlasu převedou do textu pomocí služby Speech-to-Text. Poslední službu, Text-to-Speech, používáme proto, abychom mohli otázky definované v dialogu převést z textu na hlas. Od minulé iterace jsme dialogy předělali do anglického jazyka, protože IBM Watson podporuje tento jazyk nejlépe. Na nějaké změny došlo i v našem stavovém diagramu, který řídí celou konverzaci. Detailně je možné si ho prohlédnout na obrázku Stavového diagramu dialogu.
3
Obrázek 3: obr. 2
Obrázek 2: obr. 1
4
5
Obrázek 4: Stavový diagram dialogu
2.3 Použité technologie Níže je uveden seznam použitých technologií při tvorbě našeho prototypu: • IBM Bluemix – Dialog - Služba, která udržuje stav dialogu a na základě vstupu od uživatele vyhodnocuje přechod do dalšího stavu. – Speech-to-Text - Převádí audio soubor do textové podoby. – Text-to-Speech - Převádí text na hlas. Bohužel zatím nepodporuje český jazyk. • Java 1.8 • Swing - Framework pro tvorbu grafického rozhraní pro jazyk Java
3 Uživatelské testování 3.1 Cíl testování Náš prototyp neobsahuje rozsáhlé grafické rozhraní a mnoho ovládacích prvků. Proto předpokládáme, že většina uživatelů aplikace nebude mít problémy aplikaci ovládat. Na druhou stranu jsme v rámci návrhu pouze hádali, jak bude uživatel formulovat své vstupy do aplikace. Naším cílem testování je tedy zjistit, zda uživatel vždy ví, jak formulovat hlasový vstup. Dále objevit, zda uživatel formuluje vstup námi neočekávaným způsobem.
3.2 Setup High-Fidelity prototyp byl vytvořen jako desktopová aplikace. V rámci testování jsme se chtěli co nejvíce přiblížit cílové mobilní platformě. Proto jsme využili aplikaci Vzdálená plocha Chrome. Tato aplikace je umožňuje zobrazit na display mobilního telefonu výřez obrazu z počítače. Dále je také možné dotykem simulovat klikání myší. Bohužel nebylo možné přenášet zvuk z počítače do mobilu a uživatelův hlas z mobilu do počítače. Improvizovaně jsme to vyřešili tak, že jeden z moderátorů testu držel v ruce notebook, jehož obraz byl promítán na display mobilního telefonu. Notebook dále fungoval jako mikrofon a reproduktor. Výsledek je zachycen na fotografii
6
Obrázek 5: Fotografie obrazu přenášeného na smartphone
3.3 Participanti Pro naše testování jsme potřebovali získat dva participanty. Zajímali nás studenti Elektrotechnické fakulty ČVUT. Tentokrát jsme nerozlišovali, zda se jedná o studenty, kteří se orientují, či neorientují v budově E na Karlově 7
náměstí. Dalším požadavkem byla alespoň základní znalost platformy Android nebo iOS. Vybrali jsme dva participanty. Jednu studentku a jednoho studenta.
3.4 Úkoly Zajímalo nás otestovat dva případy užití. Sestavili jsme tedy dva úkoly. V prvním úkolu je uživatel postaven ke kantýně. Nevidí tedy žádnou místost, který by jinak okamžitě identifikovala jeho pozici. Musí proto odpovědět na 4 otázky v rámci dialogu. Od tohoto úkolu očekáváme, že se obohatíme o nové formulace vstupů. V druhém úkolu modelujeme připad, kdy se uživatelův stav změní během dialogu. Uživatel tedy musí opravit vložená data. Nemusí být jasné, jak se opravit, protože se na to prototyp implicitně neptá. Následují zadání předložená participantům
3.4.1 Úkol 1 - Dlouhý dialog Máš před sebou mobilní aplikaci, která umí nalézt tvou pozici kdekoliv v budově E na Karlově náměstí. Jedná se o dialogový systém. Tedy aplikace na tebe bude mluvit a ty ji budeš ovládat hlasem. Aplikace ti bude pokládat otázky. Odpovídej jí po pravdě podle toho, kde zrovna stojíš. Tvým úkolem je tedy pomoci aplikaci, aby úspěšně zjistila tvoji pozici.
3.4.2 Úkol 2 - Oprava vložených dat Druhý úkol je podobný předchozímu. Opět je tvým úkolem pomoci aplikaci zjistit tvoji pozici. Postupuj podle následujího návodu: 1. Odpověz na otázku v jakém patře se nacházíš 2. Zatímco ti bude aplikace pokládat další otázku, přejdi do vyššího patra 3. Nyní aplikace o tobě ví neplatnou informaci. Musí se dozvědět, že nejsi na stejném podlaží jako před chvilkou 4. Oprav svojí vloženou odpověď ohledně aktuálního podlaží, na kterém se nacházíš 5. Pokračuj v dialogu
8
3.5 Data získaná při testování 3.5.1 Úkol 1 - Dlouhý dialog • Participant 1 ignoruje text "Push to talk"a tlačítko stiskne krátce. • Participant 2 ignoruje text "Push to talk"a tlačítko stiskne krátce. • Participant 1 odpovídá jednoslovně. • Participant 1 odpoví "no"na otázku ohledně katedry. Prototyp neuměl zareagovat • Participant 2 se snaží formulovat co nejdelší odpovědi. • Vstup participanta 1 je několikrát neúspěšně rozpoznán. Participant se snaží odpovědět kratší formulací své odpovědi • Participant 1 je po několika neúspěšných vstupech netrpělivý, protože si musí opakovaně vyslechnout zdlouhavou otázku • Vstup participanta 2 je několikrát neúspěšně rozpoznán. Participant je netrpělivý.
3.5.2 Úkol 2 - Oprava vložených dat • Participant 2 zopakoval předchozí vloženou hodnotu ("I would like to answer again because I’m not on the first floor") • Participant 1 váhá, protože neví, jak formulovat vstup, aby opravil předchozí odpověď • Napověděli jsme participantovi 1, jak opravit předchozí odpověď. Participant úspěšně opravuje odpověď • Participant 2 formuluje číslo místnosti po číslicích. Nulu označuje jako "o", které je špatně rozpoznáno systémem jako zaváhání. Musíme poradit, aby řekl "zero".
9
3.6 Nálezy a doporučení 3.6.1 Tlačítko Push to talk Oba participanti nečekali, že tlačítko funguje podobně jako tlačítko u vysílačky. Chování si spletli opakovaně. Tlačítko tedy musí reagovat na krátké stisknutí. Hlasový vstup se ukončí dalším krátkým stisknutím.
3.6.2 Rozdílná délka odpovědí Participanti našeho testu přistupovali k formulování vstupů různě. Participant 1 se snažil své odpovědi co nejvíce zkracovat, aby zamezil chybě v rozpoznání hlasu. Naopak participant 2 se snažil vložit do odpovědi co nejvíce kontextu, protože očekával, že aplikace lépe porozumí jeho odpovědi. Naše doporučení je počítat jak s minimalistickými, tak s dlouhými odpovědmi. Dlouhé odpovědi doporučujeme rozlišit podle jednoho či dvou obsažených klíčových slov. Např. nedefinovat možnou odpověď: "I would like to return back to the previous question", nýbrž reagovat na slova return a back.
3.6.3 Netrpělivost participantů Participanti začali být netrpěliví, když museli opakovaně vyslechnout otázku vícekrát. Zvlášť, když byla otázka delší, museli počkat, až ji aplikace celou vysloví. Řešením by bylo formulovat kratší otázky a mít připraveno více tvarů pro každou otázku. Dále by si uživatel mohl sám nastavit požadované tempo řeči, které mu vyhovuje.
3.6.4 Bohatší výběr odpovědí V prototypu dialogu jsme definovali pouze malou množinu možných odpovědí, ale během testování jsme rychle zjistili, že co člověk, to naprosto odlišný způsob odpovídání. Níže naleznete sadu doporučení pro rozšíření možností dialogu: • Čísla pater uživatel neoznačuje pouze jako "first, second,...", ale také "one, two,...". • Canteen lze označit také jako "buffet"nebo "snack bar". • Uživatel se snaží vrátit na předchozí otázku také pomocí klíčových slov "return"a "back". 10
4 Specifikace pro vývojáře 4.1 Zadání Naimplementujte aplikaci, která nalezne pozici uživatele v budově E areálu ČVUT na Karlově náměstí na základě informací, které uživatel aplikaci předloží. Aplikace povede s uživatelem hlasový dialog. Vyjděte z high-fidelity návrhu viz. 2
4.2 Funkční a systémové požadavky V této sekci se pokusíme shromáždit veškeré požadavky na funkčnost a podobu reálné aplikace. Následující seznam požadavků bude seřazený podle priority. Seznam také obsahuje méně exaktní požadavky, které se týkají uživatelovo subjektivního vnímání apliakce. Předkládáme požadavky, u kterých se domníváme, že zvýší spokojenost s užíváním aplikace.
4.2.1
P01 - Aplikace poběží na mobilních zařízeních
Aplikace by měla být snadno a rychle přístupná. Mobilní platforma je proto určená. Aby aplikaci mohlo používat co nejvíce uživatelů, bude implementovaná pro operační systém Android a iOS.
4.2.2
P02 - Aplikace bude ovládána hlasem
Kromě nejzákladnější orientace v aplikaci veškerý vstup uživatele bude pomocí hlasu. Bude tak dosaženo využitím tzv. Watson Services vyvinutých společností IBM. Konkrétně se bude jednat o služby Speech to Text, Text to Speech a Dialog.
4.2.3 P03 - Vstup a výstup aplikace bude vizuálně podpořen Dialog uživatele s aplikací bude primárně hlasový. O každém vstupu a výstupu musí být uživatel informován i vizuálně. Uživatel bude vidět každý výstup aplikace a každý vstup, který do aplikace vložil. Uživatel bude umět rozlišit tyto dvě skupiny informací. Informace o vstupu a výstupu budou barevně a pozičně rozlišitelné. V našem prototypu jsme navrhli uživatelské rozhraní, připomínající instant messaging komunikaci (viz. ukázka návrhu), které splňuje tyto požadavky. 11
4.2.4 P04 - Tlačítko hlasového vstupu bude reagovat na dvě kliknutí V rámci prototypování jsme navrhli tlačítko, které bude naslouchat uživatelovu vstupu po dobu tisknutí tlačítka. Během uživatelského testování jsme zjistili, že to není chování, které uživatelé od tlačítka intuitivně očekávají. Tlačítko po prvním stisknutí začne naslouchat uživatelovu vstupu. Po druhém stisknutí se vstup ukončí. Tlačítko při stisknutí změní svoji podobu, aby uživatel poznal, že aplikace naslouchá.
4.2.5 P05 - Tlačítko hlasového vstupu určuje, která strana právě mluví Tlačítko bude plnit roli moderátora dialogu. Vždy může mluvit pouze jedna strana. Ve chvíli, kdy aplikace mluví na uživatele, tlačítko bude deaktivované a uživatel nemůže vkládat žádný vstup. Uživatel vizuálně pozná, že tlačítko není aktivní. Po ukončení výstupu se tlačítko aktivuje a dá tak prostor uživateli.
4.2.6 P06 - Dialogový systém se nebude ptát na potvrzení uživatelových vstupů Každý úspěšně rozpoznaný vstup uživatele bude aplikace považovat za validní a nebude se dotazovat uživatele na správnost. Dialog bude proto méně zdlouhavý. Během prototypování a testování jsme zjistili, že nenastává situace, kdy systém špatně porozumí uživateli a bude to považovat za validní vstup. Není tedy potřeba dále ověřovat správnost vstupu.
4.2.7 P07 - Uživatel bude moci změnit své odpovědi Aktuální pozice uživatele se může měnit během dialogu. Uživatel musí mít možnost opravit své vstupy na základě své nové pozice či zdůvodu milného zadání neplatné hodnoty. Tato funkcionalita je zachycena v navrženém stavovém diagramu dialogu (viz. diagram)
4.2.8 P08 - Aplikace bude pokládat co nejuzavřenější otázky Uživateli nebude poskytnut žádný protokol pro interakci s aplikací. Po položení otázky bude uživateli jasné, jak má formulovat odpověď. 12
4.2.9 P09 - Uživatel bude informován o stavu aplikace Protože aplikace bude výrazně komunikovat se vzdálenými servery, uživatel musí vědět, že aplikace pracuje a není "zaseknutá". Při čekání bude uživateli zobrazena animovaná ikona symbolizující práci aplikace.
4.2.10 P10 - Otázky dialogu budou pokládané semi-náhodně Pro každou otázku bude existovat více formulací. Pokud je uživatelův vstup opakovaně špatně rozpoznán, musí několikrát vyslechnout tu samou otázku. Poslouchání stejné otázky stále dokola není pohodlné. Domníváme se ale, že je vhodné otázku vždy zopakovat po každém špatně rozpoznaném vstupu.
4.2.11 P11 - Uživatel bude moci nastavit tempo řeči Ze zpětné vazby od participantů jsme se dozvěděli, že by rádi měli možnost změnit tempo mluvené řeči.
4.3 Implementační doporučení IBM nabízí pro své služby SDK v jazyce Java. Jedná se o knihovnu, která výrazně usnadňuje připojení se k dané službě a posílání požadavků. V našem prototypu jsme ji použili a rapidně jsme tím zrychlili jeho vývoj. Nicméně ji pro použití v reálně aplikaci nedoporučujeme. Podle stavu repozitáře kódu se zdá, že na ní pracuje z velké části jen jeden člověk. Podle našeho subjektivního názoru se nám zdá, že knihovnu nenavrhuje vždy správně. Logika nabízeného kódu například nikdy neuvažuje, že se požadavek na vzdálený server nemusí vydařit. To vede k nečekaným pádům našeho prototypu. Proto doporučuje používat REST API nabízené ke každé službě. Vývojář tím získá výhodu, že bude znát HTTP status code požadavku, který se snaží vykonat.
4.3.1 Zabezpečení V našem protypu jsme neřešili, jak přistupovat k samotným službám. Pro vykonání požadavku je třeba se prokázat pomocí Basic Authentization. Toto řešení nelze použít, pokud mají být požadavky prováděny z klientského zařízení. Při dekompilaci aplikace by útočník mohl snadno získat přístupové údaje a sám používat placené služby IBM. Proto musí vzniknout back-end aplikace, která bude plnit roli proxy ke službám.
13
4.3.2 Zpoždění Aplikace výrazně závisí na internetovém připojení. Každá uživatelova interakce vyžaduje několik požadavků na služby IBM. To způsobuje znatelně nízkou reakční dobu programu. Doporučujeme ukládat do cache převody textu do mluvené podoby. Pokud by logika dialogu nebyla často měněna, není vůbec potřeba používat službu pro převod textu do psané podoby. Místo toho by byla aplikace vybavena zvukovými soubory odpovídajícími všem možnostem výstupu dialogu.
5 Závěr Během testování jsme narazili hned na několik problémů s designem i samotnou implementací aplikace. Jednalo se především o problémy s tlačítkem Push to Talk, neočekávané vstupy od uživatele, na které dialogový systém nebyl připraven, nebo třeba také o rychlost mluvení systému. Tyto problémy lze vyřešit vylepšením implementovaného prototypu a dialogového schéma. Někteří uživatelé se také setkali s problémem, kdy jim systém některé odpovědi převáděl na neodpovídající text, takový problém pak ale leží na straně služeb poskytovaných systémem IBM Bluemix, především Speech-to-Text, který nedokážeme naším řešením nijak výrazně ovlivnit (pokud bychom nechtěli sáhnout po jiném systému na převod řeči).
14
