PROHLÁŠENÍ
Předkládám tímto k posouzení a obhajobě bakalářskou práci práci zpracovanou na závěr studia na Fakultě aplikovaných věd Západočeské univerzity v Plzni.
Prohlašuji, že jsem bakalářskou práci vypracoval samostatně a výhradně s použitím odborné literatury a pramenů, jejichž úplný seznam je její součástí.
.........................
.........................
Rád bych na tomto místě poděkoval především svému vedoucímu bakalářské práce panu Ing. Janu Švecovi, jehož rady a připomínky mě donutily dívat se na věci z různých úhlů. Významnou měrou tak přispěl ke zdárnému dokončení této práce.
Anotace Práce se zabývá možnostmi automatického testování multimediálních zařízení jakožto kybernetické úlohy verifikace modelu pomocí dialogu. Zvláštní zřetel je kladen na řečová rozhraní. Obecně popisuje nejběžnější postupy automatického rozpoznávání a syntézy řeči a formuluje způsob jejich začlenění do vyvíjeného nástroje automatického testování.
Klíčová slova: Automatické testování, hlasové dialogové systémy, automatické rozpoznávání řeči, syntéza řeči, digitální rozpoznávání obrazu.
Abstract Bachelor thesis deals with automatic testing of multimedia devices, especially as a cybernetic problem of a model verification with use of dialogue. first, it focuses on speech interfaces.
At
In general, it describes practice of
an automatic speech recognition and speech synthesis and its usage in an automatic testing toolkit development.
Keywords:
Automatic testing, voice dialogue systems, automatic speech
recognition, speech synthesis, digital character recognition.
Obsah 1
Úvod
1
2
Teorie
3
3
2.1
Dialogové systémy
. . . . . . . . . . . . . . . . . . . . . . . .
3
2.2
Rozpoznávání řeči . . . . . . . . . . . . . . . . . . . . . . . . .
6
2.3
Syntéza řeči . . . . . . . . . . . . . . . . . . . . . . . . . . . .
8
2.4
Testování
. . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Motivace
13
3.1
Příklad zadání . . . . . . . . . . . . . . . . . . . . . . . . . . .
13
3.2
Způsob testování
15
3.2.1
. . . . . . . . . . . . . . . . . . . . . . . . .
Automatické testování s pomocí rozpoznávání a syntézy řeči . . . . . . . . . . . . . . . . . . . . . . . . . .
3.2.2
5
15
Automatické testování s pomocí rozpoznávání a syntézy řeči a rozpoznávání obrazu
4
10
. . . . . . . . . . . . .
16
Analýza
18
4.1
Programovací jazyk . . . . . . . . . . . . . . . . . . . . . . . .
20
4.2
Syntéza řeči . . . . . . . . . . . . . . . . . . . . . . . . . . . .
20
4.3
Rozpoznávání řeči . . . . . . . . . . . . . . . . . . . . . . . . .
21
4.4
Rozpoznávání obrazu . . . . . . . . . . . . . . . . . . . . . . .
22
4.5
Jednotný přístup k výsledkům . . . . . . . . . . . . . . . . . .
22
Implementace
24
5.1
Přístup k funkcím . . . . . . . . . . . . . . . . . . . . . . . . .
24
5.2
Funkce syntézy řeči . . . . . . . . . . . . . . . . . . . . . . . .
24
5.3
Funkce rozpoznávání řeči . . . . . . . . . . . . . . . . . . . . .
25
5.4
Funkce rozpoznávání obrazu . . . . . . . . . . . . . . . . . . .
28
5.5
Třída
5.6
Záznam (logování) během testu
Result
jako jednotný přístup k výsledkům
I
. . . . . . .
29
. . . . . . . . . . . . . . . . .
30
5.7
6
Příklady . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Závěr
31
36
II
1
Úvod
Obrovský rozvoj výpočetní techniky v několika posledních desetiletích nám umožnil řešit stále složitější a často i dříve jinak neřešitelné problémy. Denně, ať už vědomě či nikoliv, ke své práci ale i zábavě používáme různá zařízení počítače nejrůznějších druhů a velikostí. Jejich ovládání (je-li vůbec potřeba) je stále snadnější a komfortnější. To ale zároveň znamená enormní nárůst složitosti a s ním také náchylnost k chybám. Důležitou roli jejich vývoje snad více než kdy předtím - tedy hraje jejich testování. Začátkem Ledna roku 1999 vyslala NASA k Marsu družici Mars Polar Lander. Ta po jedenácti měsících skutečně k Marsu dorazila. Během přistávání však došlo k přerušení spojení a nepodařilo se ho již znovu obnovit. Závěry vyšetřování popisuje ve své knize jako motivační příklad [2].
Výsledkem byla katastrofa, ale její příčina byla mimořádně jednoduchá. Přistávací modul testovalo několik týmů. Jeden tým testoval mechanismus vysouvání nohy a jiný tým testoval přistávání od tohoto okamžiku dále. První tým se tedy nikdy nedíval, jestli se náhodou nenastavil bit odvozený od dotykového kontaktu to přece nebyla jejich práce - a druhý tým zase před zahájením testů vždy resetoval počítač a bit tím vymazal. Obě části fungovaly samy o sobě bezvadně, ale už ne poté, co byly vzájemně spojeny. Při vývoji a s ním spojeným testováním nového produktu se často naším schopným pomocníkem stávají
jednotkové testy
(angl.
unit tests )
[3]. Díky
nim můžeme snadno a rychle rozhodnout, jestli část na které zrovna pracujeme plní správně svoji úlohu - tedy jestli odpovídá
specifikaci produktu
[2].
Nic nám ale ze své podstaty neřeknou o tom, jak se bude chovat produkt jako celek. Tato informace však, jak dokazuje citace výše, může být stěžejní. Představme si například vývoj nového mobilního telefonu. Testování je náročné, nákladné a nepřináší snadno viditelné zisky. Mohli bychom snad vzít hotový přístroj, vhodným rozhraním ho připojit k počítači a ten pak za
1
nás nechat zkontrolovat správnou funkčnost? Můžeme potom říci, že je vše v pořádku, a s klidným svědomím pustit náš telefon na trh? Odpověď na tuto otázku není tak prostá, jak by se na první pohled mohlo zdát. Důležitou roli zde totiž bude hrát ekonomická stránka věci. Zcela zřejmě jsme při testování opomenuli fakt, že většina uživatelů bude k telefonu přistupovat přes jeho klávesnici či dotykovou obrazovku a mikrofon. Pokud jsme tedy udělali chybu ještě před místem, kde se oba signály z klávesnice a z počítače spojí a pokračují pak už stejně, zůstane neodhalena a narazí na ni až naši zákazníci. Na druhou stranu je ale dost dobře možné, že opravdu komplexní testování by bylo příliš pomalé či nákladné. Navíc ani takový postup nám zcela nezaručí, že k žádnému selhání nedojde. Můžeme pouze říci, že jsme chybu neobjevili, nikoliv, že tam není. I zde tedy, asi jako ve všem v životě, musí být naše rozhodnutí kompromisem.
2
2
Teorie
2.1
Dialogové systémy
Mluvíme-li o plnohodnotné komunikaci člověka s člověkem pomocí řeči, nazýváme ji obvykle
dialog
dialogem.
Stejně tak ale můžeme použít výraz
hlasový
pro komunikaci pomocí řeči člověka se strojem, či dokonce stroje se
strojem [7]. Dialog započne tím, že jeden z účastníků předá zvolené sdělení druhému. Ten k němu zaujme určité stanovisko, formuluje své sdělení a to předá zpět. Poté opět následuje tah prvního účastníka. Představme si nyní, že cílem prvního účastníka ve vzešlé diskuzi je přesvědčit druhého o pravdivosti svého předchozího tvrzení, které diskuzi vyvolalo. Sleduje odpovědi svého partnera (oponenta), porovnává je s tím, co sám považuje za správné a pravdivé a volí své další zásahy do diskuze tak, aby dosáhl vytyčeného cíle. Dvojice popsaná v předcházejícím odstavci ne náhodou nápadně připomíná systém tvořený regulátorem a regulovaným procesem. I v klasické regulaci, pokud ji diskretizujeme na jednotlivé kroky, totiž provádíme tyto činnosti. Změříme hodnotu regulované veličiny, což odpovídá vyslechnutí odpovědi (či námitek) našeho partnera (oponenta), porovnáme její hodnotu s požadovanou a na základě toho (a naší strategie) volíme další řízení - vstup regulovaného systému tak, abychom regulovaný proces přivedli do požadovaného stavu. Tedy - volněji řečeno - přinutili zaujmout námi zvolené stanovisko. Taková úloha zcela jistě spadá do oblasti zájmu kybernetiky. Na obrázku 1 vidíme model hlasového dialogového systému. Informace od uživatele prochází přes akustický kanál 1 (nechtěné zkreslení) přes moduly rozpoznávání a porozumění řeči. Modul řízení dialogu následně na základě svého stavu a strategie řízení za spoluúčasti modelu úlohy zvolí vhodné řízení. Modul generování odpovědi sestaví textovou reprezentaci, která je modulem syntézy řeči převedena do řečové reprezentace a přes akustický kanál 2 předána zpět uživateli.
3
Obrázek 1: Model hlasového dialogového systému [7]
Jedná se zjevně o komplexní kybernetický systém a návrh efektivního řízení dialogu bez znalosti ostatních modelů není možný. Pro návrh komponent můžeme použít v zásadě dva přístupy, a to
přístup
a
statistický přístup
znalostní
[7].
Znalostní přístup je historicky starší avšak velmi populární. Využívá znalostí a zkušeností člověka - experta. Ten své znalosti vkládá do systému za pomoci určitých heuristických pravidel. V tomto přístupu přímo neuvažujeme model uživatele ani konkrétní cíl řízení dialogu. Jsou však implicitně obsaženy v použitých pravidlech. Statistický přístup oproti tomu využívá explicitní pravidla jen minimálně. Většina je odvozena z trénovacích dat. To zároveň implikuje největší slabinu tohoto přístupu. Pro trénování je obvykle potřeba velký objem dat, který z různých důvodů nemusí být k dispozici. Tato data je navíc potřeba
vat
- doplnit o tzv.
informaci od učitele,
anoto-
aby systém věděl, jaká je správná
reakce na daný vstup a mohl se tak z dat učit. Anotaci obvykle provádí proškolená osoba nebo skupina osob, což podstatně zvyšuje naše náklady.
řízení dialogu řízení dialogu založené na rámcových struktu-
Pro řízení dialogu se obvykle používají dva přístupy, a to
s konečným počtem stavů a rách [7]. Obecně vzato je však možných přístupů více [1].
Řízení dialogu s konečným počtem stavů je velice oblíbeným přístupem, což vyústilo ve standardizaci programovacího jazyka VoiceXML [7, 8]. Tento
4
přístup se hodí téměř výlučně pouze pro implementaci systému s
hlasového agenta
iniciativou
[7], tedy dialogů, jejichž vedení je zcela v kompetenci řízení
dialogového systému a uživatel dostává pouze na výběr z daných možností. Model takového řízení dialogového systému v podstatě odpovídá modelu
nečného automatu.
ko-
Poznamenejme, že největší výhodou tohoto přístupu je
jednoduchost návrhu a testování. Dialogový systém využívající strukturu rámců nabízí uživateli větší volnost a tím pádem činí jeho dialog se systémem příjemnější. Jeho realizace a testování je však oproti řízení dialogu s konečným počtem stavů mnohem náročnější. Klade také vysoké nároky na modul rozpoznávání a porozumění řeči [7]. Rámce si lze představit jako v informatice často používané objekty. Každý rámec (objekt) má předem definovány sloty (vlastnosti). Rámec také může obsahovat určitou procedurální znalost (metody) navázané na jednotlivé sloty nebo obecně změny stavu rámce. Pomocí této procedurální znalosti lze například komunikovat s modelem úlohy (viz obr. 1) a dále ovlivňovat obsah slotů [7]. Sloty se mohou nacházet ve čtyřech následujících stavech:
nepotvrzený, potvrzený, nekonzistentní
nevyplněný,
[7]. Je-li rozpoznána promluva uživa-
tele, systém se na jejím základě pokusí co nejvíce slotů vyplnit. Následně položí uživateli doplňující dotaz, ve kterém jsou již vyplněné sloty implicitně zahrnuty a na základě odpovědi uživatele přechází buďto do stavu „potvrzený“, nebo do stavu „nekonzistentní“. Po potvrzení a vyřešení nekonzistence všech slotů, které systém pro vyřešení požadavku považuje za povinné, lze formulovat konečnou odpověď.
5
Příklad:
Systém : Dobrý den, dovolali jste se na automatický systém, poskytující informace o vlakových spojeních. Jak vám můžeme pomoci?
Uživatel : Systém :
Kdy jede nejbližší vlak do Prahy?
V jaké stanici chcete nastoupit na na nejbližší vlak do stanice
Praha hlavní nádraží?
Uživatel :
V Plzni.
Systém : Nejbližší vlak ze stanice Plzeň hlavní nádraží do stanice Praha hlavní nádraží jede dnes v 16:17.
2.2
Rozpoznávání řeči
Rozpoznávání řeči je velmi složitou úlohou umělé inteligence. Promluva je po cestě od řečníka k modulu rozpoznávání řeči mnohokrát zkreslena. Způsobuje to vliv prostředí, kterým se zvuk šíří, stejně jako vlastnosti mikrofonu nebo analogově-digitálního převodníku, použitého pro reprezentaci řeči v počítači. I když pomineme tyto faktory, stále zde zůstává veliký problém. Řeč každého člověka se totiž liší. Na základě toho můžeme v praxi systémy rozpoznávání řeči rozlišit na
systémy na řečníku závislé a systémy na řečníku nezávislé. Pro
účely dialogového systému, který má sloužit předem neznámému uživateli tedy přichází v úvahu pouze systémy na řečníku nezávislé [7, 1].
rozpoznávání souvislé řeči je enormní, obzvláště bereme-li v úvahu, jednat o řeč spontánní, ve které se často objevují různé neřečové
Složitost že se bude
události.
Za neřečové události zde můžeme považovat například různé pře-
řeky, nedořeky nebo váhání. Proto se často při rozpoznávání řeči omezujeme na
rozpoznáváním izolovaných slov
popřípadě sousloví.
Za nejjednodušší způsob rozpoznávání řeči můžeme považovat
vání se vzory.
porovná-
Takový modul má k dispozici sadu vzorů příslušejících po
6
skupinách nebo jednotlivě zvoleným třídám. Příchozí promluva se po úpravě (např. odstranění šumů) obvykle za pomoci klasifikace podle nejmenší vzdálenosti těmto třídám přiřazuje. Takový přístup lze jen stěží použít pro rozsáhlé slovníky, ovšem pro rozpoznávání několika málo promluv může být dostačující.
statistických metod. Jednotlivé promluvy se pak modelují pomocí skrytých Markovových modelů [7, 1], přičemž výsledný model se získá jejich zřetězením. Právě díky Oproti tomu samozřejmě existuje přístup využívající
možnosti řetězení lze na rozdíl od metody porovnávání se vzory rozpoznávat i promluvy, které nebyly ve trénovací množině obsaženy. Rozpoznávání řeči využívající statistických metod lze formulovat jako úlohu
[1, 7]. Je-
𝑂 posloupnost vektorů příznaků odvozených z řečové ˆ , která maximalizuje reprezentace promluvy, pak je cílem posloupnost slov 𝑊 podmíněnou pravděpodobnost 𝑃 (𝑊 |𝑂). Pomocí Bayesova pravidla a na základě faktu, že pravděpodobnost 𝑃 (𝑂) není funkcí 𝑊 můžeme psát li
𝑊
dekódování podle maximální aposteriorní pravděpodobnosti
posloupnost slov a
ˆ = arg max 𝑃 (𝑊 |𝑂) = arg max 𝑃 (𝑊 )𝑃 (𝑂|𝑊 ) 𝑊 𝑊
.
𝑊
Z rovnice vyplývá, že problém stanovení nejlepší posloupnosti slov řešit pomocí dvou oddělených pravděpodobností
𝑃 (𝑂|𝑊 )
a
𝑃 (𝑊 ),
ˆ 𝑊
lze
které lze
modelovat a trénovat nezávisle na sobě [1, 7]. Pravděpodobnost
kovým modelem.
𝑃 (𝑂|𝑊 )
nazveme
akustickým modelem
a
𝑃 (𝑊 ) jazy-
Parametry akustického modelu se odhadují v procesu tré-
nování využívajícím nejčastěji metodu odhadu parametrů podle
věrohodnosti.
maximální
Parametry jazykového modelu lze určit jak znalostním přístu-
pem, tak i statistickým přístupem na základě trénovacích dat [7]. V případě znalostního přístupu lze použít například
7
bezkontextové gramatiky.
Obrázek 2: Ukázka segmentace řečového signálu [1]
2.3
Syntéza řeči
Úlohou počítačové syntézy řeči je převod textu (eventuálně textu obohaceného o
prozodické informace ) na odpovídající řečovou reprezentaci. Přístupy
k syntéze řeči se nejčastěji dělí podle způsobu modelování použitého při vytváření výsledné řeči na tři typy:
syntézu
artikulační, formantovou
a
konkatenační
[1, 7].
V případě artikulační syntézy se snažíme vytvořit přímo fyzikální model produkce řeči odpovídající způsobu, jakým řeč vytváří člověk. Formantová syntéza je založena na
teorii zdroje a filtru. Těšila se oblibě především v mi-
nulosti, kdy se lidé snažili uměle tvořit řeč za pomoci mechanických, nebo elektrických zařízení. V současné době je však nejpoužívanější metodou konkatenační syntéza (konkatenace = zřetězení, spojování) [7, 1]. Během syntézy jsou z předem vytvořeného
inventáře řečových jednotek
[1]
jednotlivé prvky vybírány a zřetězeny tak, aby utvořily žádanou promluvu. Realizace řečových jednotek jsou ovšem v inventáři uloženy s různou prozódií. Proto se sestavený řetězec ještě dále upravuje, abychom dosáhli větší plynulosti a přirozenosti řeči. Nejmenší nároky na konečnou úpravu (vyhlazení) řetězců by samozřejmě kladlo řetězení celých slov. Tento přístup lze ovšem použít pouze v případě, že máme v úmyslu syntetizovat nepříliš rozsáhlou skupinu slov, které budeme předem znát. Takovou úlohu nazýváme
syntéza s omezeným slovníkem
[1].
Zahrnout do inventáře veškerá možná slova, která bude chtít uživatel eventu-
8
álně syntetizovat je vzhledem k jejich množství prakticky nemožné. Prohledávání tak rozsáhlé databáze by navíc bylo výpočetně velmi náročné. Přirozeně se tedy snažíme v případě
syntézy s neomezeným slovníkem
používat menší
subslovní jednotky (viz obr. 2) [1]. Použití slabik by se mohlo zdát přirozenou volbou potom, co jsme zamítli použití celých slov. Jedná se o přirozené řečové jednotky. Dělení slov na slabiky je ale provázeno určitou nejednoznačností, neboť některá slova lze slabikovat více způsoby. Navíc se ještě stále jedná o poměrně dlouhé jednotky, jejichž počet ve většině jazyků přesahuje
10000
[1].
Nejmenší přirozené jednotky řeči se nazývají
fonémy.
Jsou to jednotky
které při tvorbě řeči reálně vyslovujeme (slovo „oběd“ vyslovujeme jako „objet“). Mohlo by se zdát, že takové dělení je pro naše potřeby optimální. S jejich pomocí lze sestavit jakékoliv slovo daného jazyka a jejich počet je relativně nízký. V češtině používáme
40 fonémů, popř. 49 hlásek
a tento počet by tedy
stačil pro syntetizaci jakéhokoliv slova [1]. Ukazuje se však, že v závislosti na kontextu existuje velké množství realizací těchto jednotek a řeč z nich skládaná bez zřetele na kontext by byla nesrozumitelná. Namísto nich se proto používají jednotky srovnatelné velikosti, ovšem patří např.
kontextově závislé.
Mezi ty
difony.
Vraťme se nyní k obrázku 2. Oproti přirozenému dělení slova na fonémy nyní použijeme poněkud jiný postup. Místa, kde jsme dělení provedli v případě fonému přibližně o polovinu posuneme a získáme tak zcela jiné jednotky, které však bude možné stejně jako fonémy řetězit a získávat tak celá slova. Slovo vánoce rozdělíme na [#-v v-á á-n n-o o-c c-e e-#]. Každá jednotka (krom první a poslední) nyní obsahuje přibližně polovinu předcházejícího fonému, místo, kde se fonémy spojují a opět přibližně polovinu fonému následujícího. Rozdíl je zásadní. Tímto posunem jsme totiž dělení provedli
spektrálně relativně stabilního signálu. Přechody mezi hláskami tedy zachováváme a částečně tak postihujeme koartikulační jevy [1]. v oblasti
Skládá-li se fonetická abeceda z
𝑁
9
hlásek, existuje teoreticky
𝑁2
difonů.
Velké množství takových spojení se navíc v praxi nevyskytuje a pro češtinu tak obdržíme přibližně
1200 − 1400
jednotek. Inventář řečových jednotek ta-
kového rozsahu je realizovatelný a řetězením difonů lze oproti řetězení fonémů tvořit poměrně srozumitelnou řeč [1]. Postupem času se však ukázalo, že mnoho koartikulačních jevů postihuje spíše celou hlásku (obzvláště v případě samohlásek). Pro další zkvalitnění syntetizované řeči se difonové inventáře začali doplňovat dalšími jednotkami
trifony, demislabikami nebo rozšířené difonové inventáře [1]. (např.
2.4
i celými slabikami). Nazýváme je proto
Testování
Testování produktů již během jejich vývoje a samozřejmě i před uvedením na trh hraje v současné době důležitou roli, což neplatí pouze pro software. Mnohé z velkých softwarových společností jsou myšlence kvality natolik oddány, že na každého programátora mají zaměstnaného jednoho nebo i více testerů [2]. V souvislosti s tím v sobě samotné testování zahrnuje nepřeberné množství technik a přístupů, ať bereme v úvahu proces testování jako takový či následné vyhodnocení testů. S tím souvisí také celá řada publikací, které se problémem testování zabývají. Některé z těchto metod (především ty, které jsou v práci zmíněny) si zde přesto trochu přiblížíme. Ukazuje se, že nejvíce chyb vzniká kvůli chybné nebo nedostatečné
fikaci produktu
speci-
[2]. Z toho vyplývá jak důležité je plánování vývoje. Vývojáři
nemusí pochopit specifikaci (zadání) správně - nebo hůře - každý z nich ji pochopí trochu jinak. Druhým nejčastějším zdrojem chyb je
návrh
(tedy
konkrétní návrh realizace) a to ze stejného důvodu, jako v případě specifikace [2]. Uspěchaný nebo nedostatečně prodiskutovaný návrh vývoj zpomaluje a v horším případě i zanáší do systémů zbytečné a často těžko odhalitelné chyby. V terminologii testování se často setkáme s pojmy
skříňky
testování černé
a
bílé
[2]. Rozdíl je na snadě. Při testování černé skříňky máme k dispo-
10
zici pouze znalost vstupu a výstupu a o vnitřních pochodech zařízení (jeho stavu) nevíme nic. Oproti tomu při testování bílé skříňky (někdy též
průhledné skříňky
testování
[2]) máme možnost nahlédnout „dovnitř“, což nám může
pomoci odhalit rizikové oblasti, kde by mohlo docházet k chybám. Tento přístup však přináší i jisté riziko. Na základě znalosti vnitřních pochodů se totiž může stát, že jim naše testy až přespříliš přizpůsobíme a produkt nebude otestován opravdu objektivně [2]. Testování můžeme také dělit podle našeho přístupu na a
testy selháním
testy splněním
[2]. Analogií testů splněním v případě hlasových dialogových
systémů může být testování s použitím validních vstupů bez postranních šumů a s dobrou výslovností. Testy selháním si naopak můžeme představit jako použití vstupů, o kterých víme, že je systém nezná, popřípadě použijeme vstupy systému známé, ale záměrně je poškodíme různými hluky a šumy. Rozdílem tedy je, jestli testujeme chování zařízení v ideálních nebo běžných podmínkách, nebo se snažíme dostat až na hranici únosnosti. Dalším dělením v přístupu k testování mohou být
testy
invazivní
a
neinvazivní
[2]. V případě invazivních testů běží obvykle test na stejném zařízení
jako testovaná aplikace. Typickým příkladem jsou jednotkové testy. To ale často není možné, obzvláště testujeme-li celé multimediální zařízení, popřípadě nějakou vzdálenou hlasovou aplikaci. Takový případ, kdy je náš test spuštěn na vlastním hardwaru a k testovanému objektu je připojen pomocí vhodného rozhraní nazýváme neinvazivní testy. Testování a následné vyhodnocení testů hlasových dialogových systémů by vzhledem ke svému rozsahu mohlo být zvláštní kapitolou. Uveďme však jen několik málo pojmů. Prvním krokem v testování hlasového dialogového systému nejspíše bude testování jeho modulu rozpoznávání řeči. Nejjednodušším avšak užitečným testem je
testování přesnosti rozpoznávání izolovaných slov
[7]. V tomto pří-
padě aplikujeme na modul určitou množinu slov, které by měl správně rozpoznat a přesnost
𝐴𝑐𝑐𝑊
získáme jako poměr slov správně rozpoznaných vůči
11
kardinalitě celé množiny, kde větnou přesnost
𝐴𝑐𝑐𝑆
𝐴𝑐𝑐𝑊 ∈< 0; 1 >.
Obdobně můžeme definovat
[7].
Stejným způsobem můžeme testovat modul porozumění řeči v úloze
nosti porozumění přirozenému jazyku, sémantických konceptů
𝐶
přes-
kdy od modulu očekáváme přiřazení
daným slovům
𝑊.
Následně samozřejmě můžeme
testovat moduly rozpoznávání a porozumění řeči jako modul jeden. V tom případě sledujeme, zda modul přiřazuje správné sémantické koncepty ným akustickým signálům (příznakům akustického signálu)
𝑂
𝐶
da-
[7].
Po otestování jednotlivých modulů logicky následuje testování dialogového systému jako celku. Jak jsme již naznačili v kapitole 2.1 je testování dialogů s konečným počtem stavů poměrně snadné. Vzhledem ke konečnému počtu stavů lze totiž navrhnout test, který dialogový systém přiměje též v konečném čase všemi stavy projít. Oproti tomu testování dialogového systému s řízením založeným na rámcových strukturách již nemusí být triviální. Vzhledem ke konceptu řešení úlohy bude pravděpodobně vhodným postupem simulace reálného uživatele. Nelze však již zaručit, že dojde k otestování systému ve všech jeho možných stavech.
12
3
Motivace
Mluvíme-li o testování multimediálního zařízení (popř. hlasové aplikace), nemáme tím na mysli nic jiného, než ověření, že jeho chování odpovídá specifikaci. V podstatě se tedy jedná o úlohu, ve které na základě specifikace produktu sestavíme model chování zařízení a s pomocí vhodného dialogového systému provedeme ověření jeho platnosti. Snažíme-li se o automatizaci takového procesu, jde tedy (jak jsme ukázali již v kapitole 2.1) o úlohu spadající především do oblasti kybernetiky.
3.1
Příklad zadání
Představme si nyní situaci, kdy dostaneme za úkol otestovat určitou telefonní aplikaci. Řekněme, že se jedná o systém, který má po telefonu zpřístupnit odjezdy a příjezdy vlaků. Vezmeme si tedy k ruce jeho specifikaci, abychom věděli, jaké chování máme považovat za správné, a jízdní řády, se kterými budeme odpovědi systému též konfrontovat. Pak už nám zbývá jen vzít telefon, vytočit číslo, na kterém je aplikace k dispozici, a začít klást všemožné všetečné otázky. Začneme
testy splněním
[2], a proto vždy po několika dotazech
zavěsíme a zavoláme znovu, abychom co nejlépe simulovali reálný provoz. Navíc by pro opravdu komplexní otestování bylo dobré, abychom si vždy někam poznamenali náš dotaz a jak na něj aplikace odpověděla, nebo přinejmenším zda odpověděla správně. Jak vidíme, už teď začíná být takovéto „manuální“ testování poměrně náročné. Je také velmi pravděpodobné, že by naše aplikace měla zvládnout obsloužit v jednu chvíli více než jednoho volajícího. Museli bychom tedy najmout odpovídající počet lidí, abychom mohli takové zatížení testovat. To vše by samozřejmě bylo velice náročné a nákladné. Zcela
automatického testování [2, 3]. předchozí postup a začneme testem selhá-
přirozeně tak přichází na scénu myšlenka Obrátíme teď poněkud náš
ním [2], protože se jeho automatizace jeví jako nejjednodušší. Prvním krokem by tedy mohlo být sestavení našich požadavků jako nahrávek zvuku. S pomocí
13
vhodně zvoleného softwaru bychom pak s aplikací navázali potřebný počet spojení, použili nahrávky a ověřili, že aplikace takovou zátěž zvládne. Takový
test s opakováním [2]. Tím, že použijeme větší počet provádíme i zátěžový test [2]. Stále však před námi leží
test se obvykle nazývá „uživatelů“ zároveň
nelehký úkol. Každou sekvenci povelů, kterou budeme chtít otestovat, bude třeba předem nahrát. Pro opravdové zatížení aplikace by bylo lépe používat směs různých požadavků, což už nejspíše bude pouze za pomoci nahrávek náročné. Zde nám pomůže Ze
specifikace produktu
syntéza řeči (TTS - Text To Speech)
[1].
víme, jaké povely dokáže aplikace zpracovat. Při-
pravíme tedy generátor jejich textové reprezentace, provedeme
syntézu
do
řeči a necháme naše „uživatele“, aby je aplikaci předkládali. Ta tedy bude zatěžována různorodou směsí povelů od celé řady „uživatelů“, což už můžeme považovat za dobrý zátěžový test. Ověření stability a případné nalezení chyby by tedy při vhodném záznamu testů neměl být problém. Stále však nevíme, zda aplikace na naše povely odpovídá správně. Bude tedy potřeba začlenit do našich testů technologii, která je nejspíše i „srdcem“ testované aplikace.
Automatické rozpoznávání řeči (ASR - Automatic Speech Recognition)
[1].
Zcela správnou námitkou by na tomto místě mohlo být, že ASR použité k testování by muselo být výrazně kvalitnější, než to v testované aplikaci. To by pro nás jistě bylo ideálním řešením. Na druhou stranu ale není možné se na to spoléhat. V náš prospěch však hrají dva důležité fakty. Prvním z nich je, že výpočetní výkon hardwaru, na kterém aplikace běží je omezený. Aby bylo možné aplikaci reálně používat, musí být schopna reagovat na povely s určitým maximálním zpožděním. Uživatel by jistě nebyl příliš nadšený, pokud by na každou odpověď musel čekat např. minutu [7]. My na druhou stranu nejsme takto přímo omezeni. Druhým a možná ještě důležitějším faktem je rozdíl ve velikosti
dávaných prostorů
prohle-
[1]. Aplikace dopředu neví jistě, na co se jí chceme ze-
ptat, a musí proto zkontrolovat celou množinu přípustných řešení, než bude schopna náš dotaz určit. Náš testovací „uživatel“ ovšem ví přesně, na co ze-
14
Obrázek 3: Schéma komunikace - Tester v1
ptal a ví také díky specifikaci produktu (modelu testované aplikace), jak má vypadat správná odpověď. Množina přípustných řešení, kterou musí prohledat, bude jistě mnohem méně rozsáhlá a on tak může ve stejném čase provést výrazně přesnější porovnání. I při použití ASR srovnatelných úrovní by tedy měl náš test vykazovat lepší výsledky.
3.2 3.2.1
Způsob testování Automatické testování s pomocí rozpoznávání a syntézy řeči
Co do rozsahu a složitosti použitých technologií jsme v tomto místě dospěli do úrovně reálné aplikace, kterou jsme již dříve sestavili a použili pro testování multimediálního zařízení. Testy probíhali za pomoci ASR a TTS. Aplikaci jsme pro naše interní účely nazvali
Tester v1. Testované zařízení samozřejmě
neumožňovalo, abychom testy spustili přímo na něm. Byl proto použit neinvazivní přístup (viz kapitola 2.4). Pro syntézu řeči byla použita technologie
SpeechTech TTS
[4] verze 2.6.
Tato verze oproti verzím 2.9 a 2.10 nedosahuje takové kvality syntetizované řeči. Je však rychlejší a klade menší nároky na hardware a co do kvality se ukázala dostačující. Pro rozpoznávání řeči byla použita technologie
SpeechTech ASR
[4]. Po-
užívané hlasové povely nebyly nijak složité, a proto jsme se spokojili s
znáváním klíčových slov (KWS -
angl.
15
KeyWord Spotting).
rozpo-
Struktura testů
Obrázek 4: Diagram testování v aplikaci Tester v1
je na obr. 4, schéma komunikace s testovaným zařízením na obr. 3.
3.2.2
Automatické testování s pomocí rozpoznávání a syntézy řeči a rozpoznávání obrazu
Probrali jsme již, jaké jsou možnosti automatického testování ryze řečových aplikací. Multimediální zařízení ovšem obvykle dává uživateli na výběr jak komunikaci akustickou, tak i vizuální. Použitím rozpoznávání obrazu je tedy možné výrazně zvýšit kvalitu (přesnost) testování. Proto jsme se jej rozhodli
16
Obrázek 5: Schéma komunikace - Tester v2
začlenit do vyvíjené aplikace a uvažované schéma komunikace se tak oproti Testeru v1 rozšířilo (viz obr. 5). Pro rozpoznávání obrazu se obecně vžilo označení
Character Recognition
OCR
(angl.
Optical
- optické rozpoznávání znaků). Poznamenejme ovšem,
že toto označení není v našem případě přesné. OCR v sobě už z logiky svého názvu ukrývá technologii převodu obrazu do digitální podoby. Tento převod aplikace přímo neřeší a namísto toho předpokládá, že se stejně jako v případě akustického kanálu 2 o digitalizaci přijímané informace postará nějaké externí zařízení (na obr. 5 „ukryté“ ve vizuálním kanálu) a my již dále budeme zpracovávat pouze tuto digitální reprezentaci. Méně rozšířené, avšak mnohem přesnější by tedy v našem případě bylo označením
tal Character Recognition - Digitální rozpoznávání znaků.
17
DCR
jako
Digi-
4
Analýza
Shrňme nyní, co je vlastně naším úkolem. Máme-li testovat nějaké blíže nespecifikované multimediální zařízení, je třeba vhodným způsobem sestavit jeho model. K němu následně vytvoříme odpovídající tester - regulátor a s jeho pomocí ověříme platnost tohoto modelu. Ocitáme se teď ovšem ve slepé uličce, protože o modelech zařízení, které budeme chtít v budoucnu testovat nemáme téměř žádnou informaci. V podstatě jediným platným předpokladem, ze kterého můžeme vycházet je, že se bude jednat o multimediální zařízení (resp. hlasovou aplikaci) schopné komunikovat podle schéma na obr. 5 (resp. obr. 3). Jedinou naší možností je tedy navrhnout a sestavit vhodné metody - formalismy, s jejichž pomocí bude možné po obeznámení s modelem testovaného zařízení aplikaci vhodně doplnit (konkretizovat) a sestavit tak dialogový systém schopný provést automaticky ověření platnosti daného modelu. Vznikne tak komplexní systém, jehož schéma vidíme na obr. 6.
18
Obrázek 6: Schéma Tester v2 - testované zařízeni
19
Obrázek 7: Struktura modulů v aplikaci Tester v2
4.1
Programovací jazyk
Python je moderní programovací jazyk vyšší úrovně. Snadný na pochopení a příjemný na užívání. Jak se můžeme dočíst v [6], ukazuje se navíc jako ideální jazyk pro výuku základů programování. V kombinaci s našimi vlastními zkušenostmi s ním se tedy jevil jako ideální kandidát a byl také použit jako nejvyšší jazyk implementace. Právě v něm jsou napsány ukázkové testy využívající vytvořenou knihovnu funkcí, kterou budeme pro naše účely nazývat
Tester v2. Kód je psán primárně pro Python v2.5, ale je možné použít i další vyšší verze řady 2.
4.2
Syntéza řeči
V Testeru v2 je použita syntéza řeči
SpeechTech TTS
[4] verze 2.6, stejně
jako v Testeru v1. Jak již bylo zmíněno dříve, tato verze je oproti novějším implementacím rychlejší, ovšem méně kvalitní. Pro naše účely se však nejedná o nijak závažnou vadu, a proto jsme se rozhodli u této verze zůstat. Funkce DLL knihovny TTS jsou do Pythonu namapovány za pomoci modulu
ctypes.
Následně je ještě použit obalový modul
ttsframework.
struktura nám umožňuje zachovat přehlednost programu, kdy modul
20
Tato
tts
Algoritmus 1 Příklad použití modulu from
ttsframework
import
ttsframework
TTSFramework
t t s _ f r a m e w o r k = TTSFramework ( ) tts_framework . speak ( " asynchronní
promluva " )
t t s _ f r a m e w o r k . speakAndWait ( " s y n c h r o n n í
(v obr. 7 vlevo dole značen
„tts (dll)“)
promluva " )
zůstává v podstatě pouze přístu-
povou vrstvou k DLL knihovně a další potřebné úpravy jsou provedeny až v
ttsframework
(viz obr. 7).
Ve výpisu zdrojového kódu označeném jako algoritmus 1 vidíme reálné použití modulu
ttsframework,
respektive jeho jediné třídy
TTSFramework.
Bezprostředně po inicializaci jsou použity obě metody označené jako veřejné (public). Jak napovídá samotný příklad, metoda
speak
provádí asynchronní
syntézu řeči. Provede syntézu předaného textu a spustí její přehrávání. Pak okamžitě předá řízení programu zpět, lhostejno, zdali již došlo k vyslovení celé promluvy, nebo přehrávání ještě probíhá. Je zřejmé, že tuto metodu využijeme pouze v případě, že chceme testovanému zařízení něco oznámit, ale nezajímá nás jeho reakce. Ve většině případu během testování používáme metodu
speakAndWait,
která předává řízení zpět až ve chvíli, kdy je celá
promluva vyslovena a mnohem lépe se tak hodí pro vedení dialogu, jímž v podstatě tento způsob testování také je.
4.3
Rozpoznávání řeči
SpeechTech ASR [4], rozpoznávajícím fráze popsané jak pomocí KWS (KeyWord Spotting - rozpoznávání klíčových slov ), tak i pomocí ESGF gramatik [9] (dále značeno Rozpoznávání řeči je v Tester v2 řešeno pomocí
GRM). Můžeme tedy rozpoznávat jak jednotlivá klíčová slova, tak i složité fráze popsané gramatikami. Po zpřístupnění DLL knihovny ASR modulem
pyasr4ivr
dochází (jako v případě TTS) k obalení dalším modulem.
21
Tentokrát
4.4
asrframework
(viz obr. 7).
Rozpoznávání obrazu
Jak jsme již dříve poznamenali, je při testování multimediálních zařízení rozpoznávání obrazu vhodným doplňkem, který může testy značně zkvalitnit. Náš modul rozpoznávání obrazu (DCR) předpokládá obraz ve formě digitálního obrázku (např. PNG) i informace o rozložení textu. Dále dochází k odstranění pozadí a rozřezání obrazovky na jednotlivé oblasti, kde se podle předané informace mají nacházet slova, která chceme rozpoznat. Slova se pak dále dělí na jednotlivé znaky, které se na základě znalosti používaných fontů porovnávají se vzory. Rozpoznávání tak probíhá klasifikací podle nejmenší vzdálenosti (viz kapitola 2.2, kde jsme tuto metodu krátce popsali pro případ rozpoznávání řeči).
4.5
Jednotný přístup k výsledkům
result ocrframework
Poslední součástí druhé úrovně (v obr. 7 druhý řádek) je modul (resp. třída
Result).
Při použití modulů
asrframework
a
přímo by uživatel obdržel výsledky rozpoznávání vždy v příslušné třídě (in-
asrframework dokonce na dvou různých místech i v rámci protože výsledky rozpoznávání podle KWS a GRM přicházejí oddě-
stanci). V případě této třídy, leně.
Řešení přináší právě třída stance třídy
Result
(značena
Result. V každém testu je zpřístupněna injako result), do které jsou všechny obdržené
výsledky automaticky přeposílány. Uživatel tak nemusí procházet jednotlivé instance. Má jednoduchý a především jednotný přístup ke všem výsledkům. Algoritmus 2 je příkladem typického použití instance
result
v testu. Nej-
prve se ptáme, zdali bylo rozpoznáno klíčové slovo „praha“. V dalším řádku se zase dotazujeme, zdali byla v promluvě rozpoznána fráze „odbočte doprava“ popsaná gramatikou (GRM). Strukturu dat v instanci
22
result za předpokladu,
Algoritmus 2 Příklad použití instance if
" praha " print
if
in
print
v testech
r e s u l t . s o u r c e (KWS) :
" Slovo
" odbočte
result
’ praha ’
doprava "
in
" Rozpoznána
source item_id KWS 1 GRM 2
bylo
rozpoznáno . "
r e s u l t . s o u r c e (GRM) :
direktiva
’ odbočte
phrase praha odbočte doprava
Obrázek 8: Obsah instance
doprava ’ . "
confidence 0.7 1
result
že obě dotazované fráze byly rozpoznány ukazuje tabulka na obr. 8.
23
5
Implementace
5.1
Přístup k funkcím
Podívejme se nyní, jak vypadá použití aplikace
Tester v2
již bylo dříve řečeno, aplikace je určena primárně pro jazyk
v praxi. Jak
Python 2.5
a v tomto jazyku předpokládá i test předaný k provedení. Stejně dobře však lze použít i libovolnou vyšší verzi jazyka řady 2 (např.
Python 2.7). Hotový test test.py $python exec_test.py test.py
Python 2.6
nebo
je možné spustit příkazem:
Díky tomu, že je test spouštěn přes jiný program (exec_test.py), může být uživateli přístup k funkcím knihovny maximálně zjednodušen. Není dokonce ani potřeba provádět pro
Python
import. Veškeré funkce jsou k dis(built-in) funkce (např. print()).
typický
pozici přímo, tak jako jiné vestavěné
Projděme si teď jednotlivé funkce, které má uživatel k dispozici a povězme si něco o jejich použití.
5.2
Funkce syntézy řeči
Z instance třídy
TTSFramework
(z modulu
ttsframework)
jsou jako funkce
zpřístupněny metody:
speak
jako
speak
speakAndWait
jako
speakAndWait
Obě metody předpokládají předání jednoho argumentu a to libovolného ře-
unicode. Typ unicode zaručuje správné zpracování české diakritiky. Funkce speak provádí asynchronní přehrávání. Syntetizovaná promluva tězce typu
je tedy předána k přehrávání a bez čekání je řízení předáno zpět programu. Naopak funkce
speakAndWait
pracuje synchronně, tedy před předáním ří-
zení zpět počká na konec přehrávání. Příklad použití ukazuje algoritmus 3.
24
Algoritmus 3 Příklad použití funkcí syntézy řeči
s p e a k ( " Tato
věta
bude
speakAndWait ( " Tato
přehrána
věta
bude
asynchronně . " )
přehrána
synchronně . " )
Je na něm též (oproti algoritmu 1) vidět rozdílný přístup k funkcím zmíněný v kapitole 5.1. V tomto příkladu je nejprve volána funkce
speak.
K přehrání obou vět
tedy (v závislosti na výpočetním výkonu hardwaru) dojde téměř v tu samou chvíli.
5.3
Funkce rozpoznávání řeči
ASRFramework
Z instance třídy
(z modulu
asrframework)
jsou jako funkce
zpřístupněny metody:
register start stop
jako
jako
jako
register
startASR
stopASR
waitForResponse
jako
waitForASRResponse
Dále jsou zpřístupněny konstanty:
KWS GRM
register(source, value, permanent=False). S její pomocí říkáme instanci třídy ASRFramework jaké fráze chceme rozpoznávat. Můžeme registrovat klíčová slova (KWS), nebo gramatiky (GRM) a to
První funkce má deklaraci
trvale, nebo s platností pouze pro první následující blok rozpoznávání. První argument funkce (source) udává typ fráze, kterou chceme rozpoznávat. Uvedeme-li na jeho místě konstantu
25
KWS,
dáváme tím najevo, že
Algoritmus 4 Příklad použití funkce
register
r e g i s t e r (KWS,
u" praha " )
r e g i s t e r (GRM,
u" seznam_prikazu . e s g f " )
chceme registrovat klíčové slovo a funkce tedy bude očekávat na místě dru-
value řetězec typu unicode. Naopak použijeme-li konstantu registrovat soubor gramatiky a na místě argumentu value by
hého argumentu
GRM,
chceme
se tedy měla objevit cesta k danému souboru. Jakékoliv rozpoznávání řeči vždy probíhá v bloku mezi příkazy a
startASR()
stopASR(). Třetí parametr permanent nám umožňuje definovat jak dlouho
má námi registrovaná fráze platit. Pokud parametr vynecháme (což je možné,
False), nebo pokud explicitně zadáme jeho hodnotu jako False (popřípadě permanent=False), bude námi registrované fráze platit pouze v prvním následujícím bloku příkazů startASR() a stopASR(). To je užitečné především pro fráze platné pouze po jednu iteraci
protože má nastavenou implicitní hodnotu
testu. Pokud naopak máme některé fráze, které budeme používat v každé ite-
permanent=True. Ačkoliv je možné vynechat jméno parametru a předat pouze hodnotu True, vřele doporaci testu, má smysl registrovat je s parametrem
ručujeme používat kvůli čitelnosti dříve uvedený způsob. Takto registrovaná fráze bude platná v každém následujícím bloku rozpoznávání řeči. V případě několika málo klíčových slov nebude nejspíše rozdíl patrný. V případě rozsáhlé gramatiky však jistě oceníme její zpracování pouze jednou v záhlaví testu a nikoliv v každé z tisíce následujících iterací. V algoritmech a 5 je použita instance
result. K té se ještě vrátíme poz-
ději. Pro tuto chvíli je důležité vědět pouze, že má přístup ke všem výsledkům
source vrací seznam výsledků odpovídajících zawaitForASRResponse taktéž probereme později. Ta,
rozpoznávání a její metoda danému zdroji. Funkci
jednoduše řečeno, čeká na odpověď testovaného zařízení. Algoritmus 4 ukazuje typické použití funkce, algoritmus 5 vliv použití parametru
26
permanent.
Algoritmus 5 Příklad použití parametru
r e g i s t e r (KWS,
" praha " )
r e g i s t e r (KWS,
" plzeň " ,
permanent
funkce
register
p e r m a n e n t=True )
startASR ( ) waitForASRResponse ( ) stopASR ( ) if
" praha "
if
" plzeň "
print
print
in
r e s u l t . s o u r c e (KWS) :
" Klíčové in
slovo
’ praha ’
rozpoznáno . "
r e s u l t . s o u r c e (KWS) :
" Klíčové
slovo
’ plzeň ’
rozpoznáno . "
startASR ( ) waitForASRResponse ( ) stopASR ( ) if
" praha " print
if
" plzeň " print
in
r e s u l t . s o u r c e (KWS) :
" Klíčové in
slovo
’ praha ’
# Dotaz nemá smysl ! rozpoznáno . "
r e s u l t . s o u r c e (KWS) :
" Klíčové
slovo
’ plzeň ’
27
rozpoznáno . "
startASR a stopASR. Jejich smysl odpovídá přesně za úkol nic jiného než spustit (startASR) a následně
Již jsme zmínili funkce jejich názvům. Nemají
ukončit (stopASR) rozpoznávání řeči. Je třeba pouze poznamenat, že funkce
startASR
vždy vymaže z instance
result
všechny dříve získané výsledky.
Pokud je i přesto chceme používat, je třeba si pořídit před voláním
startASR
jejich kopii. Poslední funkcí poskytovanou třídou
ASRFramework,
o které jsme ještě
waitForASRResponse. Je deklarována jako waitForASRResponse(min_speech_duration=0.3, min_silence_duration=0.4, time_step=0.1) Její název opět odpovídá jenemluvili, je
jímu smyslu. Jakmile je zavolána, čeká, dokud nezaznamená promluvu. Fakticky čeká na sekvenci signálů ticho - zvuk - ticho. Všechny parametry mají nastaveny implicitní hodnoty a je možné ji volat jako
waitForASRResponse().
Pro jemnější nastavení v případě potřeby jsou ovšem k dispozici parametry:
min_speech_duration
jako minimální délka zvuku, který bude pova-
žován za odpověď
min_silence_duration
jako minimální délka ticha, která bude pova-
žována za konec odpovědi
time_step
jako délka čekacího kroku
Předpokládá se, že parametry a
min_speech_duration
min_silence_duration budou celočíselné násobky parametru time_step.
Všechny hodnoty jsou uvedeny v sekundách.
5.4 Třída
Funkce rozpoznávání obrazu
OCRFramework (z modulu ocrframework) dává uživateli přístup ke dvěma
stěžejním funkcím, a to:
waitForScreenChange()
28
doOCR()
waitForScreenChange
Funkce
je obdobou funkce
waitForASRResponse.
Po
svém zavolání tedy bude čekat, dokud nedojde k překreslení (změně) obrazovky - sleduje změny vizuálního kanálu (viz obr. 6).
doOCR následně sejme obrazovku, provede analýzu snímku a předá výsledky instanci result. Tato funkce však předpokládá přístup k zařízení označenému na obr. 7 jako grabber. Jde vlastně o již dříve zmiňované externí Funkce
zařízení „ukryté“ na obr. 5 a 6 ve vizuálním kanálu. Při volání je nutné specifikovat o kterou již dříve v konfiguračním souboru definovanou obrazovku (angl.
5.5
screen
- druh rozložení textu) jde.
Třída Result jako jednotný přístup k výsledkům
Pro přístup k výsledkům rozpoznávání byla použita samostatná třída (resp.
Result (resp. result). Kdekoliv v testu může uživatel přistuinstanci result, která obsahuje veškeré výsledky získané v bezpro-
instance třídy) povat k
středně předcházejícím bloku rozpoznávání. Veškeré výsledky jsou instanci
result
předávány automaticky bezprostředně po jejich získání. Její metody
jsou:
containsPhrase(phrase) source(source) confidence(confidence) Metoda
containsPhrase(phrase)
vrací hodnoty
toho, zda je v instanci (eventuálně v použitém je také odvozena konstrukce Metodu
source
True,
nebo
False
podle
filtru ) fráze k dispozici. Od ní
phrase in result.
jsme si již rámcově představili dříve. Pokud je zavo-
lána, projde systematicky všechny možné výsledky a vrátí opět instanci třídy
Result
ovšem pouze s výsledky, které odpovídají zadanému zdroji. Volání
29
Algoritmus 6 Příklad použití instance
result
# Je mezi v ý s l e d k y f r á z e " praha "? " praha "
in
result
# Nebo j i n a k :
r e s u l t . c o n t a i n s P h r a s e ( " praha " )
# Je mezi rozpoznanými k l í č o v ý m i s l o v y " praha "? " praha "
in
r e s u l t . s o u r c e (KWS)
" praha "
in
r e s u l t . s o u r c e (KWS) . c o n f i d e n c e ( 0 . 6 )
# Je mezi rozpoznanými k l í č o v ý m i s l o v y s d ů v ě r y h o d n o s t í # v ě t š í nebo rovnou 0 . 6 s l o v o " praha "?
result.source(GRM)
tedy vrátí instanci třídy
Result,
která bude obsaho-
vat pouze rozpoznané gramatiky. Tato metoda je typickým příkladem výše zmíněného filtru. Metoda
confidence(confidence) je opět filtrem. Každý výsledek rozpo-
znávání má přiřazenu určitou hodnotu důvěryhodnosti - confidence. Voláním tohoto filtru tedy obdržíme nazpět opět instanci třídy
Result
ovšem pouze
s výsledky, které mají stejnou nebo vyšší hodnotu důvěryhodnosti, než zadaná
5.6
confidence. Záznam (logování) během testu
Je velmi pravděpodobné, že uživatel bude chtít své testy nějak ladit, popřípadě během testu nechat vypisovat chybové nebo informační hlášky. Z toho důvodu jsou také jako funkce k dispozici metody instance třídy kolik potřebných konstant z modulu
logging:
DEBUG INFO WARNING ERROR 30
Logger a ně-
CRITICAL setLoggingLevel() debug() info() warning() error() critical() Konstanty jsou psány velkými písmeny a představují různé úrovně logování.
DEBUG je nejnižší a po nastavení příkazem setLoggingLevel(DEBUG) budou vypisovat všechny hlášky. Oproti tomu je úroveň CRITICAL nej-
Úroveň se
vyšší a je-li nastavena, budou vypisovány pouze hlášky této úrovně (tedy volání funkce
critical(message)).
Funkce
setLoggingLevel()
tedy oče-
kává jednu z dostupných konstant úrovně logování. Všechny ostatní funkce logování očekávají jako parametr řetězec typu
5.7
unicode.
Příklady
Na obr. 9 vidíme diagram, jak by mohla vypadat struktura jednoduchého testu s použitím funkcí TTS a ASR. Příklad vlastně odpovídá manuálnímu testování telefonní aplikace, zmíněnému v kapitole 3.1. Uveďme si teď příklad více konkrétní. Pro jednoduchost uvažujme zařízení bez obrazovky pouze se zvukovým vstupem a výstupem, jehož úkolem bude zopakovat slovo, které „uslyší“. Můžeme mu říkat např. „ozvěna“. Obě zařízení propojíme vhodným rozhraním (kanály). Potom již příkazem
python exec_test.py test.py test spustíme a Obsah souboru test.py zobrazuje algoritmus 7.
31
můžeme sledovat výsledky.
Obrázek 9: Příklad jednoduchého testu s použitím
32
TTS
a
ASR
Algoritmus 7 Skript testu pro zařízení „ozvěna“.
# f i l e n a m e : t e s t . py znama_slova =
[ " karel " ,
" jarmila " ,
" franta " ,
" pepa " ]
s e t L o g g i n g L e v e l ( INFO ) for
slovo
in
znama_slova :
r e g i s t e r (KWS,
slovo )
startASR ( ) speakAndWait ( s l o v o ) waitForASRResponse ( ) stopASR ( ) if
slovo
in
result :
i n f o ( " Slovo
bylo
rozpoznáno
správně ! " )
else :
warning ( " Slovo
’% s ’
nebylo
rozpoznáno ! " % s l o v o )
Podívejme se nyní na skript v algoritmu 7 podrobněji. Začíná definicí listu
znama_slova. To jsou slova, která by mělo zařízení v pořádku rozeznat.
V obr. 9 odpovídá list pojmu „testovací data“. Následuje nastavení hlášek na úroveň
INFO (setLoggingLevel(INFO)). Následně proběhne registrace právě
testovaného slova a spustí se rozpoznávání. Předáme povel (slovo) testovanému zařízení, počkáme na odpověď, ukončíme rozpoznávání a provedeme záznam obdrženého výsledku. V tomto případě pouze vypíšeme, jestli bylo slovo rozeznáno správně, či nikoliv. Správné rozpoznání slova jistě očekáváme, a proto je použita funkce
info.
Oproti tomu selhání je stav, který by
měl upoutat naši pozornost. V tomto případě je tedy použita funkce s vyšší úrovní (warning). Provedli jsme testy splněním. Nyní pro změnu provedeme na zařízení „ozvěna“ několik testů selháním. Ze specifikace víme, že obdrží-li zařízení vstup, který nezná, mělo by namísto zopakování říci: „Takové slovo neznám.“ Tato fráze už je poněkud složitější, a proto namísto odstranění mezer (stažení do jediného slova) a použití rozpo-
33
Algoritmus 8 Příklad ESGF gramatiky pro test zařízení „ozvěna“
# filename :
gramatika1 . e s g f
#ESGF V1 . 0 grammar
gramatika1 ;
= ; <end> = <END_GRAMMAR>; p u b l i c = Takové
slovo
neznám <end >;
znávání klíčových slov využijeme gramatiku. Příklad ESGF gramatiky s touto jedinou frází je v algoritmu 8. Skript testu potom najdeme v algoritmu 9. Test bychom spustili příkazem:
python exec_test.py test_selhanim.py.
Podívejme se na tento příklad opět podrobněji. Slova, která zařízení zná jsme nahradili slovy (jmény), které by podle specifikace znát nemělo (list
neznama_slova)
chybova_hlaska. Oproti předchozímu příkladu jsme ale nastavili úroveň logování na WARNING. Vzhledem k tomu, že normální (správné) chování je hlášeno funkcí info(), obdržíme během testu pouze hlášky o selhání. Funkce info() bude ignoroa mělo by zareagovat chybovou hláškou
vána. Zásadním rozdílem oproti předcházejícímu příkladu je také umístění funkce
register().
Tentokrát je totiž volána ještě před započetím testů.
Není to ale nic překvapivého. Ve všech testech se přeci dotazujeme na existenci jediné a stále stejné fráze: „Takové slovo neznám“. Bylo by tedy zbytečné registrovat ji v každé iteraci testu. Mnohem lepším postupem je zaregistrovat ji hned na začátku s parametrem
permanent=True.
34
Algoritmus 9 Test zařízení „ozvěna“ - selháním
# f i l e n a m e : t e s t _ s e l h a n i m . py znama_slova =
[ " karel " ,
neznama_slova =
" jarmila " ,
[ " máša " ,
c h y b o v a _ h l a s k a = " Takové
" jan " , slovo
" franta " ,
" lenka " ,
" pepa " ]
" david " ]
neznám "
s e t L o g g i n g L e v e l (WARNING) r e g i s t e r (GRM, for
slovo
in
" gramatika1 . e s g f " ,
p e r m a n e n t=True )
neznama_slova :
startASR ( ) speakAndWait ( s l o v o ) waitForASRResponse ( ) stopASR ( ) if
chybova_hlaska info (" Zarizeni
in
result :
zareagovalo
spravne ! " )
else :
warning ( " Z a r i z e n i
zareagovalo
35
chybne ! " )
6
Závěr
V práci jsme se seznámili se základy počítačového rozpoznávání a syntézy řeči. Načrtli jsme též možnost jejich doplnění o rozpoznávání obrazu (znaků) a uvedli automatické testování s využitím dialogového systému jako prakticky jediný možný postup komplexního testování multimediálních zařízení a řečových aplikací. V kapitole 2.4 jsme uvedli několik možných přístupů k vyhodnocení výsledků testování modulů rozpoznávání a porozumění řeči. Testování multimediálních zařízení a řečových aplikací jsme následně uvedli jako kybernetickou úlohu ověření planosti modelu zařízení (aplikace). Úspěšně jsme analyzovali a sestavili systém umožňující uživateli psát jednoduchým způsobem automatické testy využívající funkcionalitu modulů rozpoznávání a syntézy řeči. Jinými slovy navrhovat vnitřní modely dialogových systémů, umožňující kromě testování jednotlivých modulů testovaného zařízení i ověření platnosti jeho uvažovaného modelu. Funkčnost systémů byla ověřena na několika jednoduchých modelových úlohách, z nichž některé jsme zmínili v kapitole 5.7. V těchto případech obvykle nahradil testované zařízení člověk, který se choval a odpovídal na dotazy systému podle předem daného scénáře - modelu testované úlohy. Systém byl též úspěšně použit v praktické úloze testování multimediálního zařízení s navigační jednotkou, které je určeno pro osobní automobil.
36
Reference [1] Josef Psutka, Luděk Müller, Jindřich Matoušek, Vlasta Radová:
Mluvíme
s počítačem česky. Academia, Praha, 2006. ISBN 80-200-1309-1. [2] Ron Patton:
Testování softwaru.
Computer Press, Praha, 2002. ISBN
80-7226-636-5. [3] Michael C. Feathers:
Údržba kódu převzatých programů. Computer Press,
a.s., Brno 2009. ISBN 978-80-251-2127-6. [4] SpeechTech s.r.o. http://www.speechtech.cz/ [5] Python Programming Language. http://python.org/ [6] Jeffrey Elkner: Using Python in a High School Computer Science Program. Yorktown High School, Arlington, Virginia. http://www.python.org/workshops/2000-01/proceedings/papers/ elkner/pyYHS.html [7] Jan Švec: [8] W3C:
Hlasové dialogové systémy. Plzeň, 2009.
Voice eXtensible Markup Language (VoiceXML).
http://www.w3.org/TR/voicexml/ http://www.w3.org/ [9]
Eris Speech Grammar Format (ESGF). http://voice.zcu.cz/
37
