à INFORMATYKI, ELEKTRONIKI I TELEKOMUNIKACJIdydaktyka:pracamagisterska... · 2017. 10. 18. ·...

WYDZIAŁ INFORMATYKI, ELEKTRONIKI I TELEKOMUNIKACJI

KATEDRA TELEKOMUNIKACJI

PRACA DYPLOMOWA MAGISTERSKA

Realizacja usługi rozpoznawania mowy polskiej w chmurze

obliczeniowej

Implementation of the Polish speech recognition cloud service

Autor: Paweł Tarsa

Kierunek studiów: Elektronika i Telekomunikacja

Opiekun pracy: dr inż. Jakub Gałka

Kraków, 2017

Uprzedzony o odpowiedzialności karnej na podstawie art. 115 ust. 1 i 2 ustawy z dnia 4

lutego 1994 r. o prawie autorskim i prawach pokrewnych (t.j. Dz.U. z 2006 r. Nr 90, poz. 631

z późn. zm.): „ Kto przywłaszcza sobie autorstwo albo wprowadza w błąd co do autorstwa

całości lub części cudzego utworu albo artystycznego wykonania, podlega grzywnie, karze

ograniczenia wolności albo pozbawienia wolności do lat 3. Tej samej karze podlega, kto

rozpowszechnia bez podania nazwiska lub pseudonimu twórcy cudzy utwór w wersji

oryginalnej albo w postaci opracowania, artystyczne wykonanie albo publicznie zniekształca

taki utwór, artystyczne wykonanie, fonogram, wideogram lub nadanie.”, a także uprzedzony o

odpowiedzialności dyscyplinarnej na podstawie art. 211 ust. 1 ustawy z dnia 27 lipca 2005 r.

Prawo o szkolnictwie wyższym (t.j. Dz. U. z 2012 r. poz. 572, z późn. zm.) „Za naruszenie

przepisów obowiązujących w uczelni oraz za czyny uchybiające godności studenta student

ponosi odpowiedzialność dyscyplinarną przed komisją dyscyplinarną albo przed sądem

koleżeńskim samorządu studenckiego, zwanym dalej „sądem koleżeńskim”, oświadczam, że

niniejszą pracę dyplomową wykonałem(-am) osobiście i samodzielnie i że nie korzystałem(-

am) ze źródeł innych niż wymienione w pracy.

.......................................................

Spis treści

1. Wstęp............................................................................................................................................... 6

1.1. Cele pracy .............................................................................................................................. 6

1.2. Zawartość pracy..................................................................................................................... 7

2. Przetwarzanie sygnałów w chmurze ............................................................................................ 8

2.1. Modele usług chmury obliczeniowej..................................................................................... 8

2.2. Podłoże teoretyczne przetwarzania mowy............................................................................. 11

2.2.1. Automatyczne rozpoznawanie mowy ........................................................................ 11

2.2.2. Dekodowanie mowy................................................................................................... 13

2.2.3. Ewaluacja działania systemów ASR.......................................................................... 13

2.3. Przegląd usług ASR............................................................................................................... 14

2.3.1. Rozwiązania komercyjne ........................................................................................... 14

2.3.2. Rozwiązania darmowe ............................................................................................... 14

3. Projekt systemu .............................................................................................................................. 16

3.1. Architektura rozwiązania....................................................................................................... 16

3.2. Podsumowanie....................................................................................................................... 19

4. Implementacja systemu ................................................................................................................. 20

4.1. Wykorzystane narzędzia oraz biblioteki................................................................................ 20

4.2. Opis implementacji................................................................................................................ 24

5. Testowanie i Ewaluacja Sarmata REST API .............................................................................. 27

5.1. Przykład użycia API .............................................................................................................. 27

5.2. Środowisko testowe ............................................................................................................... 29

5.3. Dane testowe.......................................................................................................................... 29

5.4. Badanie aspektów jakościowych serwisu.............................................................................. 31

5.4.1. Badanie systemu ASR................................................................................................ 31

5.4.2. Testy wydajnościowe ................................................................................................. 33

5.5. Podsumowanie....................................................................................................................... 54

6. Podsumowanie ................................................................................................................................ 55

6.1. Osiągnięte cele....................................................................................................................... 55

4

SPIS TREŚCI 5

6.2. Perspektywy dalszych prac nad rozwojem systemu.............................................................. 56

1. Wstęp

Rozpoznawanie mowy jest technologią pozwalającą komputerowi interpretować mowę ludzką na

przykład do celów transkrypcji lub jako alternatywną metodę interakcji. Początki badań nad rozpozna-

waniem mowy datuje się na lata trzydzieste XX wieku. Powstanie pierwszych systemów komputerowych

zdolnych rozpoznawać mowę datuje się na lata pięćdziesiąte XX wieku. Mogły one rozpoznać jedynie

kilka słów. Czterdzieści lat później liczbę słów rozpoznawanych przez komputery szacuje się na około

20 tysięcy. Powiększenie słowników systemów rozpoznających mowę związane było z ogromnym po-

stępem technologicznym oraz nieustannym zainteresowaniem tą tematyką naukowców z całego świata.

Wzrost mocy obliczeniowych komputerów przybliżał ludzkość do opracowania systemu zdolnego roz-

poznawać mowę w czasie rzeczywistym. Obecnie istnieje wiele rozwiązań pozwalających na realizację

wspomnianych zadań np. asystent osobisty Amazon Alexa. W dzisiejszych czasach niemal każdy tele-

fon komórkowy jest przystosowany do komunikacji z użytkownikiem za pomocą interfejsu głosowego.

Pojawia się coraz więcej rozwiązań, które bazują na sterowaniu głosowym np. inteligentne domy, sa-

mochody, a nawet zegarki elektroniczne. Zastosowanie algorytmów uczenia maszynowego do celów

doskonalenia systemów rozpoznawania mowy jest powodem olbrzymiego postępu jakościowego syste-

mów automatycznego rozpoznawania mowy ASR (ang. Automatic Speech Recognition). Modele stają się

coraz szybsze i bardziej skuteczne. W ramach niniejszej pracy magisterskiej zaimplementowano serwis

internetowy umożliwiający rozpoznawanie mowy. Usługa udostępnia publicznie API systemu Sarmata

2.0 umożliwiającego automatyczne rozpoznawanie mowy polskiej korzystając z wybranej gramatyki

[1]. Silnik Sarmaty został w całości opracowany oraz zaimplementowany przez naukowców z zespołu

przetwarzania sygnałów Katedry Elektroniki, AGH.

1.1. Cele pracy

Celem niniejszej pracy jest wykonanie aplikacji typu proof-of-concept umożliwiającej udostępnianie

funkcjonalności silnika rozpoznawania mowy polskiej Sarmata 2.0 poprzez protokół HTTP. Rozwiązanie

powinno zostać przetestowane a testy przeanalizowane. Dokładny zakres pracy obejmuje:

1. Przedstawienie teorii związanej z tematyką chmurową, podstawami rozpoznawania mowy oraz

usługami do rozpoznawania mowy.

2. Zaprojektowanie oraz implementacja usługi internetowej udostępniającej funkcjonalności systemu

rozpoznawania mowy polskiej Sarmata 2.0

6

1.2. Zawartość pracy 7

3. Opracowanie oraz wykonanie automatycznych testów funkcjonalnych integracyjnych oraz syste-

mowych rozwiązania.

4. Opracowanie oraz wykonanie automatycznych testów niefunkcjonalnych takich jak:

• testy wydajnościowe,• testy przeciążeniowe,• testy stresowe.

5. Konfiguracja i wdrożenie modułu umożliwiającego monitorowanie działania zaimplementowa-

nego API.

6. Zaprojektowanie oraz implementacja testów automatycznych serwisu.

1.2. Zawartość pracy

W rozdziale Chmura obliczeniowa w kontekście usług związanych z przetwarzaniem sygna-łów przybliżono tematykę usług chmurowych, podstawy teoretyczne związane z automatycznym roz-poznawaniem mowy oraz omówiono istniejące rozwiązania z zakresu ASR. Kolejny rozdział zawiera

rozważania na temat projektu serwisu internetowego wykonanego w ramach niniejszej pracy, jego ar-

chitektury, rozważanych rozwiązań architektonicznych oraz technologicznych. Sekcja Implementacjasystemu omawia użyte biblioteki i narzędzia. Rozdział pod tytułem Testowanie i Ewaluacja SarmataREST API skupia się na badaniu usługi pod kątem funkcjonalnym oraz wydajnościowym przy użyciuróżnych gramatyk oraz konfiguracji silnika Sarmata.

2. Przetwarzanie sygnałów w chmurze

Na przestrzeni ostatnich lat, paradygmat przetwarzania danych w chmurze stał się bardzo popularny

zarówno w środowiskach akademickich jak również komercyjnych. Chmura jest bardzo dogodnym roz-

wiązaniem dla dostarczycieli usług (platformy). Stała się bardzo popularna z uwagi na olbrzymią skalo-

walność rozwiązań opartych na chmurze obliczeniowej. Praktycznie nieograniczona moc obliczeniowa

oraz przestrzeń dyskowa sprzyja centralizacji rozwiązań związanych np. z multimediami. Szybkość prze-

twarzania multimediów (w ogólnym przypadku danych) jest niezależna od stacji klienckiej, zależy głów-

nie od możliwości serwera [2]. Dodatkowym faktem, który zachęca do przeniesienia usług IT do chmury

jest znaczna redukcja kosztów, szacowana średnio na 10-20% [3]. W tym rozdziale przybliżono tema-

tykę architektury oraz rozwiązań chmurowych ze szczególnym naciskiem na aspekty, które są szczegól-

nie użyteczne w przypadku systemów rozpoznawania mowy lub w ogólności – systemów bazujących na

uczeniu maszynowym i statystyce.

2.1. Modele usług chmury obliczeniowej

Formalna definicja przetwarzania w chmurze (ang. cloud computing) została zaproponowana przez

Narodowy Instytut Standaryzacji i Technologii NIST (ang. National Institute of Standards and Techno-

logy, NIST) i wygląda następująco [4]:

Def:

Przetwarzanie w chmurze jest modelem ogólnodostępnego, wygodnego udostępniania zasobów informa-

tycznych takich jak zasoby obliczeniowe, przepustowość sieci, magazyny danych, aplikacje etc. Model

charakteryzuje się funkcjami takimi jak:

• samoobsługa na żądanie• duża elastyczność• taryfikacja usług (ang. pay-as-you-use)• szeroki dostęp do sieci• implementacja puli zasobów

8

2.1. Modele usług chmury obliczeniowej 9

Przez ostatnie dekady umacniał się pogląd, iż przetwarzanie informacji (danych) może być realizo-

wane bardziej efektywnie przez scentralizowane zasoby, a następnie udostępniane przez Internet. Postęp

technologiczny w dziedzinie przesyłu danych jest odpowiedzialny za popularyzację najpierw modelu

grid computing (wczesne lata 90) a następnie cloud computing (początek XX wieku)[5]. Model chmu-

rowy jest obecnie stosowany przez największe firmy z branży IT takie jak Amazon, Apple, Google etc.

W niniejszym rozdziale zostanie przybliżona tematyka chmury obliczniowej (ang. cloud, cloud compu-

ting). Rozróżniamy trzy modele usług chmurowych serwowanych przez dostawców opisywanych usług.

Są to Software as a Service (SaaS), Platform as a Service (PaaS), Infrastructure as a Service (IaaS). Ze

względu na dostępność, możemy je podzielić z kolei na publiczne, prywatne, wspólnotowe (community)

oraz hybrydowe. Wspomnianą systematykę ilustruje rys. 2.1.

Rys. 2.1: Systematyka serwisów chmurowych [5]

2.1. Modele usług chmury obliczeniowej 10

Infrastruktura jako serwisW modelu nazwanym "Infrastruktura jako serwis"(ang. Infrastructure as a Service) dostawca usługi do-

starcza klientowi zasoby w postaci infrastruktury sprzętowej. Może to być przestrzeń na wirtualnym

dysku internetowym przeznaczona do przechowywania danych albo też miejsce na serwerze wydzier-

żawione w celu wgrania tam własnego systemu operacyjnego. Do IaaS zalicza się także korzystanie z

mocy obliczeniowej procesorów [6]. Cechą charakterystyczną tego modelu jest optymalizacja kosztów

– konsument jest zobowiązany zapłacić za faktycznie zużytą moc serwerów [4].

Platforma jako usługaKolejną formą udostępniania chmury obliczeniowej jest model "Platforma jako usługa"(ang. Platform

as a Service). Model ten różni się od poprzedniego tym, iż oprócz elastycznej infrastruktury sprzętowej

udostępniana jest, także platforma aplikacyjna tj. np. System operacyjny, platforma programistyczna etc.

Podobnie jak w przypadku IaaS opłaty są proporcjonalne do zużycia zasobów (miejsce na dysku, transfer

danych, czas procesora) [4].

Oprogramowanie jako usługaNajbardziej kompleksowym modelem usług chmurowych jest model typu ”Oprogramowanie jako

usługa” (ang. Software as a Service), czyli korzystanie z aplikacji, która jest uruchomiona w chmu-

rze. Aplikacja jest udostępniana za pomocą interfejsów klienckich takich jak przeglądarki internetowe

lub interfejsu programistycznego [4]. Usługi tego typu udostępniane są zwykle za pomocą internetu, na

życzenie [7]. W ramach tego modelu serwowane będą funkcje silnika ASR Sarmata 2.0, omawianego w

niniejszej pozycji.

2.2. Podłoże teoretyczne przetwarzania mowy 11

2.2. Podłoże teoretyczne przetwarzania mowy

Niniejszy rozdział opisuje teorię przydatną do zrozumienia zasady działania chmurowego serwisu

rozpoznającego mowę. W sekcji Automatyczne rozpoznawanie mowy (ang. Automatic Speech Reco-gnition, ASR) zawarto podstawowe zagadnienia związane z ASR takie jak modele akustyczne, modele

językowe, dekodowanie mowy oraz ewaluację systemów ASR.

2.2.1. Automatyczne rozpoznawanie mowy

Działanie systemów do rozpoznawania mowy można opisać jako wybór najbardziej prawdopodobnej

sekwencji Ŵ , biorąc pod uwagę zaobserwowane dowody akustyczne A [8]. Tak więc rozpoznawanie

mowy można opisać jako:

Ŵ = argW

maxP (W |A) (2.1)

Gdzie:

• Ŵ - najbardziej prawdopodobna sekwencja wyrazów• W - sekwencja wyrazów• A - sekwencja obserwacji• P (W |A) - funkcja prawdopodobieństwa warunkowego, określa najbardziej prawdopodobną se-

kwencję W przy założeniu wystąpienia obserwacji A

Z uwagi na fakt, iż bezpośrednie wyznaczenie prawdopodobieństwa P (W |A) jest niemożliwe, należyskorzystać z teorii prawdopodobieństwa Bayesa. Korzystając z ustaleń wspomnianej teorii, wzór 2.1

może być zapisany również jak we wzorze 2.2

Ŵ = argW

maxP (A|W ) ∗ P (W )

P (A)(2.2)

Gdzie:

• Ŵ - najbardziej prawdopodobna sekwencja wyrazów• W - sekwencja wyrazów• A - zbiór obserwacji• P (W ) - prawdopodobieństwo wystąpienia sekwencji W• P (A) - prawdopodobieństwo wystąpienia obserwacji A• P (W |A) - funkcja prawdopodobieństwa warunkowego, określa najbardziej prawdopodobną se-

kwencję W przy założeniu wystąpienia obserwacji A

Prawdopodobieństwo P (A|W ) jest nazywane modelem akustycznym oraz prawdopodobieństwoP (W ) mianuje się określeniem modelu językowego. Tym samym otrzymano równanie w którym po-

łączono zależnością modele akustyczny oraz językowy. Oba wymienione prawdopodobieństwa zostaną

dokładniej opisane w sekcjach Modele akustyczne oraz Modele językowe.

Modele akustyczne

Zadaniem modeli akustycznych P (A|W ) jest uwzględnienie wszystkich możliwych warunków aku-stycznych, takich jak np. wymowa, pogłos, warunki w kanale transmisyjnym czy hałas tła dla wszystkich


możliwych powiązań W oraz A. Istnieje wiele różnych koncepcji modelowania akustycznego. Najczę-

ściej są one oparte na ukrytych modelach Markowa (Hidden Markov Model, HMM), sztucznych sieciach

neuronowych [9] lub dynamicznym dopasowaniu czasowym [10]. Model akustyczny sekwencji słów jest

łańcuchem ukrytych modeli Markowa każdego słowa, które należy do rozpoznawanego słownictwa. Mo-

dele akustyczne słów są z kolei związkami modeli akustycznych bloków składowych słów np. fonemów.

W ogólności modele akustyczne są statystycznym odbiciem sygnału mowy na fonemy.

Modele językowe

Modele językowe P (W ) odgrywają ogromną rolę w rozpoznawaniu mowy - pozwalają określić

prawdopodobieństwo wystąpienia słowa lub sekwencji słów w1, . . . , wn [11]. Model językowy może

być opisany wzorem 2.3 [12]

P (W ) = P (w1, . . . , wn) =n∏

i=1

P (wi|w1, . . . , wi−1) (2.3)

Gdzie:

• P(W) - prawdopobieństwo wystąpenia sekwencji W• n - długość sekwencji wyrazów W• P (wi|w1, . . . , wi−1) - prawdopobieństwo wystąpienia i-tego wyrazu, przy założeniu wcześniej-

szego wystąpienia określonej sekwencji wyrazów w1, . . . , wi−1 o długości i-1.

Dobry model językowy powinien spełniać następujące wymagania [13]:

• musi pozwalać na stwierdzenie, czy dana sekwencja słów jest elementem wykorzystywanego ję-zyka, czy nie,

• uwzględniać wszystkie możliwe konstrukcje, które występują w języku (np. szyk słów),• wspierać w wyborze hipotezy nawet w przypadku, gdy model akustyczny nie daje całkowicie

prawidłowego rozpoznania jednostek akustycznych,

• powinien on skutkować możliwie najmniejszą złożonością obliczeniową procedur poszukiwaw-czych,

• model powinien mieć możliwość podejmowania decyzji w oparciu o ograniczony kontekst.

Współcześnie coraz większe znaczenie w rozpoznawaniu mowy zyskują głębokie sieci neuronowe

(ang. deep neural networks) [14]. Zarówno modele akustyczne oraz językowe, zrealizowane są za po-

mocą techniki głębokich sieci neuronowych. Granica pomiędzy modelami jest coraz mniej dostrzegalna,

czyli coraz trudniej oddzielić model akustyczny od językowego.


2.2.2. Dekodowanie mowy

Dekodowanie mowy jest procesem odnajdywania najbardziej prawdopodobnej sekwencji wyrazów

Ŵ zgodnie ze wzorem 2.2. Jednym z algorytmów używanych do dekodowania mowy jest algorytm

Viterbiego [15]. Jest to dynamiczny algorytm do znajdywania najbardziej prawdopodobnych sekwencji

stanów w ukrytych modelach Markowa. Podczas analizy kolejnych momentów czasowych wypowiedzi

odrzucanych zostaje wiele hipotez. Takie podejście do dekodowania zapewnia ograniczoną konsumpcję

pamięci operacyjnej.

2.2.3. Ewaluacja działania systemów ASR

Najbardziej powszechną metryką używaną do ewaluacji systemów ASR jest metryka WER (ang.

Word error rate). Określa ona procent błędnych słów w porównaniu do wypowiedzi referencyjnej. WER

opiera swoje działanie na regule edycyjnej Levenshteina dla słów

WER =S +D + I

N(2.4)

Gdzie:

• S jest to liczba słów zastąpionych względem frazy referencyjnej• D jest liczbą słów pominiętych względem frazy referencyjnej• I jest liczbą słów dodanych względem frazy referencyjnej• N jest liczbą słów w frazie referencyjnej

Drugą najczęściej używaną metryką określaną jako stosunek liczby poprawnie rozkodowanych zdań

do całkowitej liczby testowanych hipotez jest metryka SER (ang. Sentence Error Rate) opisana jako:

SER =B

N(2.5)

Gdzie:

• SER - stosunek liczby poprawnie rozkodowanych zdań do całkowitej liczby testowanych hipotez• B jest liczbą błędnie rozpoznanych zdań• N jest liczbą wszystkich zdań

Inną metryką służącą pozwalającą ocenić systemy do rozpoznawania mowy jest metryka RTF (ang.

Real Time Factor), pozwalająca określić szybkość działania dekodera. RTF jest definiowany jako sto-

sunek potrzebnego do zdekodowania nagrania R, przez badany system, do czasu trwania nagrania R.

Można go opisać jako 2.6:

RTF =decode_time(R)

length(R)(2.6)

Gdzie:

• R - nagranie,• decode_time(R) - czas potrzebny na zdekodowanie nagrania R,• lenght(R) - czas trwania nagrania R.

2.3. Przegląd usług ASR 14

2.3. Przegląd usług ASR

Istnieje wiele komercyjnych oraz darmowych systemów rozpoznawania mowy jak np. AT&T Wat-

son, Microsoft Speech API, Google Speech API, Amazon Alexa API etc. [16]. Rozwiązania dostarczane

przez AT&T, Microsoft, Amazon oraz Google są rozwiązaniami komercyjnymi. Przykładem darmowego

oprogramowania tego typu jest np. Sphinx-4 [16] oraz pakiet Kaldi. Poniżej przedstawiono opis wybra-

nych rozwiązań z zakresu rozpoznawania mowy dostępnych na rynku.

2.3.1. Rozwiązania komercyjne

Google Speech API

Rozwiązanie oferowane przez firmę Google opiera swoje działanie na głębokich sieciach neurono-

wych. Między innymi dzięki zastosowaniu tego rozwiązania w roku 2015 osiągnięto stopę błędu na

poziomie 8% [16]. Google Speech API wspiera 89 języków oraz ich dialektów. Umożliwia między in-

nymi rozpoznawanie fraz w czasie rzeczywistym oraz transkrypcję plików audio. Platforma udostępnia

funkcjonalności przez protokoły HTTP (REST) oraz RPC (gRPC).

Microsoft Cognitive Services

Microsoft rozwija rozwiązania z zakresu przetwarzania sygnału mowy od 1993 roku. Usługi po-

znawcze dostępne są poprzez chmurę Microsoft Azure. Obecnie firma udostępnia szereg usług służącym

przetwarzaniu języka mówionego takich jak transkrypcja w czasie rzeczywistym (ang. API Speech Inter-

face), synteza mowy, rozpoznawanie mówcy (ang. Speech Recognition API), translacja (ang. Translator

Speech API) jak również trenowanie własnych modeli językowych oraz akustycznych (ang. Custom

Speech Service). Rozwiązanie umożliwia transkrypcję nagrań nie dłuższych niż 10 minut. Platforma

udostępnia funkcjonalność za pomocą API kompatybilnego z protokołami HTTP oraz WebSocket. Do-

datkowo dostępne są, także biblioteki umożliwiające implementację rozwiązań opartych o Speech API

na platformy .NET, Android oraz iOS.

2.3.2. Rozwiązania darmowe

CloudASR

CloudASR jest publiczną platformą programistyczną oraz serwisem internetowym umożliwiającym

rozpoznawanie mowy. Rozwiązanie opracowane zostało przez naukowców z Charles University w Cze-

chach.

Wedle autorów mocnymi stronami platformy są:

• skalowalność,• duże możliwości dostosowania do indywidualnych potrzeb,• łatwa przenośność rozwiązania.

CloudASR umożliwia transkrypcje całych nagrań (ang. batch speech recognizing) jak również trans-

krypcję strumieniowanych danych. Domyślnym zestawem narzędziowym wykorzystywanym przez opi-

2.3. Przegląd usług ASR 15

sywany produkt jest PyKaldi, czyli pakiet Kaldi zintegrowany z językiem python [17]. Należy jednak

zaznaczyć, że system jest dostosowany do kooperacji z dowolnym zestawem narzędziowym.

HTK

HTK jest zestawem narzędziowym umożliwiającym budowanie oraz modyfikację ukrytymi mode-

lami Markowa. W 1999 roku technologia została wykupiona przez firmę Microsoft a kod źródłowy został

częściowo zlicencjonowany - użytkownicy mogą używać HTK do trenowania modeli, jednak dekoder

(HDecoder) zaimplementowany w ramach pakietu jest udostępniany tylko do celów badawczych [18].

HTK składa się z zestawu modułów, które dostarczają rozwiązań ułatwiających analizę mowy, trenowa-

nie źródeł Markowa a także testowanie oraz analizę rezultatów [19]. Jest znany także pod nazwą HMM

Toolkit.

CMU Sphinx

System Sphinx został opracowany przez Uniwersytet Carnegie Mellon (Carnegie Mellon Univer-

sity, CMU). Jest to projekty typu Open Source. Istnieje kilka wariantów omawianego pakietu takich jak

Sphinx-2, Sphinx-3, Sphinx-4 oraz PocketSphinx. Omawiany w niniejszej sekcji Sphinx-4 jest produk-

tem napisanym w języku Java. Architektura rozwiązania dzieli bibliotekę na trzy części: frontend, de-

koder oraz część lingwistyczną [16]. Udostępniony przez instytucję kod zawiera implementacje oparte

na ekstrakcji cech MFCC (ang. Mel Frequency Cepstrum Coefficients), PLP (ang. Perceptual Linear

prediction) czy LPC (ang. Linear Predictive Codes ). Część lingwistyczna zawiera implementacje m.in.

modeli CFG (ang. Context-Free Grammar), FST (ang. Finite-State Transducers), N-gramowego etc.

[16]. Dostępny również w wersji przeznaczonej na platformy mobilne - PocketSphinx [20].

Kaldi

Kaldi jest darmowym zestawem narzędziowym umożliwiającym rozpoznawanie mowy. Jest on w

całości zaimplementowany w języku C++, jego kod źródłowy jest publiczny, dostępny w systemie za-

rządzania projektami typu Open Source. Framework Kaldi jest kompatybilny ze środowiskami UNIX-

owymi oraz Windows. Istnieje wiele nakładek integrujących Kaldi z innymi językami jak np. PyKaldi

[21], co znacznie poszerza grono użytkowników pakietu. System ten opiera się na teorii automatów

skończonych. Istnieją rozwiązania chmurowe oparte o pakiet Kaldi takie jak np. Kaldi GStreamer server,

będący publicznym serwerem zaimplementowanym w języku python, który umożliwia rozpoznawanie

mowy w czasie rzeczywistym lub opisany wyżej CloudASR.

3. Projekt systemu

W niniejszym rozdziale zostanie przedstawiony projekt aplikacji umożliwiającej rozpoznawanie

mowy polskiej z wykorzystaniem wybranej gramatyki.

3.1. Architektura rozwiązania

W inżynierii oprogramowania termin architektura oprogramowania oznacza abstrakcyjną reprezen-

tację systemu opisaną jako zbiór połączonych komponentów z pominięciem szczegółów implementacji

[22]. System może składać się z wielu poziomów abstrakcji i wielu faz działania, z których każda posiada

własną architekturę oprogramowania [23]. W dzisiejszych czasach powszechnym sposobem wymiany

danych są usługi internetowe (Web services). Najbardziej powszechnymi stylami architektonicznymi

są REST (Representational State Transfer Protocol ) oraz SOAP Simple Object Access Protocol [24].

Każdy z wymienionych stylów ma swoje mocne i słabe strony, tak więc istotnym zadaniem jest wybra-

nie odpowiedniego stylu, spełniającego wymagania projektowe w jak największym stopniu [25]. Można

w tym celu skorzystać z powszechnie przyjętych metryk ewaluacji oprogramowania. Wspomniane me-

tryki dzielą się na bezpośrednie, mierzalne metryki takie jak ilość błędów, kosztowność implementacji

oraz niemierzalne takie jak kompleksowość, prostota utrzymania etc. Najpopularniejsze rodzaje metryk

przedstawiono w tebeli 3.1.

Bezpośrednie Niebezpośrednie(mierzalne) (niemierzalne)

koszt dotyczy przodków (tj. rodziców danego węzła oraz

funkcjonalność)

wysiłek wykonawczy jakość

ilość linii kodu kompleksowość

szybkość działania efektywność

zapotrzebowanie na pamięć niezawodność

błędy prostota utrzymania

Tabela 3.1: Kategorie metryk oceny oprogramowania [26]

16

3.1. Architektura rozwiązania 17

REST (Representational State Transfer Protocol) jest to wzorzec architektury oprogramowania opi-sujący zasady, właściwości oraz ograniczenia, którymi należy się kierować przy projektowaniu nowo-

czesnych serwisów internetowych. Transmisja danych realizowana jest za pomocą protokołu HTTP. Nie

istnieją ograniczenia dotyczące formatu przesyłanych danych, jednak najczęściej są to JSON lub XML.

Serwisy internetowe oparte o omawianą architekturę wydają się być lekką alternatywą dla topornych

serwisów SOAP-owych [25]. Komunikację z serwerem ułatwia wykorzystywanie standardowych typów

operacji w protokole HTTP takich jak GET, PUT, POST, DELETE etc. [27].

SOAP (Simple Object Access Protocol) jest protokołem, który został stworzony jako alternatywadla standardu CORBA (Common Object Request Broker Architecture). Protokołami transportowymi, z

których korzysta SOAP są HTTP, SMTP, etc. Dane przesyłane są w formacie XML [28]. Ilość danych

przesyłanych serwisami opartymi o omawiany styl może powodować problemy wydajnościowe, ponie-

waż podczas formowania wiadomości dodawane są do niej dodatkowe nagłówki oraz metadane umiesz-

czane w ciele wiadomości. W odróżnieniu od standardu REST, protokół SOAP posiada zdefiniowany

model bezpieczeństwa [28]. Standard ten został opracowany i ustandaryzowany przez organizacje takie

jak W3C oraz OASIS [25].

Nawiązując do powyższego opisu stylów architektonicznych REST oraz SOAP, dokonano ich oceny

względem metryk ewaluacji oprogramowania przedstawionych w tabeli 3.1. Poniżej rezultaty rozważań:

• koszt: REST wykorzystuje prostą infrastrukturę technologiczną. Fakt ten implikuje redukcję kosz-tów potrzebnych do osiągnięcia tych samych efektów co przy użyciu SOAP [29]. Co więcej w

przypadku rozwiązań REST-owych istnieje możliwość kooperacji klienta z tworzonym serwisem

już we wczesnej fazie implementacji np. przy użyciu przeglądarki lub innych prostych aplikacji

klienckich jak np. Postman [30],

• wysiłek wykonawczy: W celu szeroko pojętej redukcji kosztów związanych z implementacją orazutrzymaniem serwisu zaleca się wybór rozwiązań REST-owych [26],

• ilość linii kodu: Porównując oba podejścia pod względem obszerności kodu gwarantującego tesame funkcjonalności, korzystniej prezentują się rozwiązania oparte na protokole SOAP [26],

• szybkość działania: Rozwiązania REST-owe prezentują się dużo lepiej w kontekście szybkościdziałania (mniejsze czasy odpowiedzi oraz większa przepustowość danych [25]. Rysunek 3.1

3.1. Architektura rozwiązania 18

Rys. 3.1: Czasy odpowiedzi dla serwisu internetowego wykonanego według stylu architektonicznegoREST oraz SOAP (źródło [27])

• zapotrzebowanie na pamięć: tworzenie żądania SOAP trwa nawet 10 razy dłużej oraz potrzebuje 8razy więcej pamięci w porównaniu z natywnym żądaniem HTTP [31] Jest to powiązane z mniej-

szym narzutem obliczeniowym po stronie REST wynikającym z braku konieczności dodatkowego

opakowania zleceń (koperta SOAP) oraz przetwarzania dokumentów XML [32],

• błędy: SOAP posiada wbudowany mechanizm obsługi błędów [25]. Tak więc pod tym względemprezentuje się lepiej,

• funkcjonalność: REST jest bardziej odpowiednim wzorcem w przypadku komunikacji punkt-punkt (point-to-point) [25],

• efektywność: protokół HTTP opisuje mechanizmy buforowania (ang. caching) oraz równoważeniaobciążenia (ang. load balancing). Co więcej REST używa formatu JSON (lub nawet prostego

tekstu ang. plain text), który zajmuje mniej miejsca niż XML. Oba przytoczone fakty sprawiają, iż

serwisy internetowe bazujące na standardzie REST, jako oparte bezpośrednio na protokole HTTP

są bardziej efektywne [25],

• prostota utrzymania: Łatwiej utrzymywać rozwiązania REST-owe [26].

3.2. Podsumowanie 19

Podsumowując rozważania na temat stylów architektonicznych REST oraz SOAP należy stwierdzić, iż:

RESTJest bardziej odpowiednim wyborem w sytuacji, gdy nacisk położony jest zwłaszcza na wydajność

aplikacji, szybkość jej działania oraz oszczędność zasobów.

SOAPJest lepszym rozwiązaniem, gdy realizowany projekt wymaga większego bezpieczeństwa, mniej-

szej ilości błędów. Dodatkową zaletą protokołu SOAP jest łatwa w utrzymaniu strona kliencka (w

razie zmian interface’u użytkownika wystarczy plik WSDL, aby wygenerować kod kliencki) [25].

Mając na uwadze powyższe wnioski, omawiany w niniejszej pracy serwis internetowy zostanie wy-

konany zgodnie ze wzorcem architektonicznym REST, który lepiej odpowiada wymaganiom projekto-

wym systemu do rozpoznawania mowy.

3.2. Podsumowanie

Wynikiem pracy magisterskiej powinna być aplikacja serwerowa umożliwiająca rozpoznawanie

mowy polskiej w czasie rzeczywistym. Powinna istnieć również możliwość wyboru dogodnej grama-

tyki zapisanej w bazie danych oraz dodawania nowych gramatyk. Wszystkie funkcjonalności powinny

zostać opisane w stosownej dokumentacji [33]. Rozwiązanie wykonane będzie w języku Java z wyko-

rzystaniem wielowarstwowego szkieletu aplikacji Spring. Głównym powodem, dla którego dokonano

wyboru tej technologii, są bardzo dobre właściwości wydajnościowe, dojrzałość technologii oraz testo-

walność kodu. Zagadnienie testowalności kodu jest kluczowe z punktu widzenia poprawności działania

systemu, ale także satysfakcji klienta końcowego. Odpowiednia struktura aplikacji znacznie ułatwia au-

tomatyczne testowanie, zmniejszając ilość błędów i pozwalając na szybszą reakcję na zmianę wymagań

[34].

4. Implementacja systemu

4.1. Wykorzystane narzędzia oraz biblioteki

Swagger (OpenAPI Specification) jest to framework służący do opisu, tworzenia, wizualizacji oraztestowania serwisów internetowych opartych o styl architektoniczny REST. Nadrzędnym celem pro-

gramu jest zapewnienie synchronizacji dokumentacji systemu oraz samego systemu. Jest to możliwe

z uwagi na fakt, iż dokumentacja metod, parametrów oraz modeli może być zintegrowana z kodem

aplikacji. Dużą zaletą narzędzia jest zdolność do generacji kodu klienckiego oraz serwera w oparciu o

stworzoną dokumentację i zawarte w niej kontrakty [35].

Apache JMeter jest aplikacją napisaną w języku Java, stworzoną w celu przeprowadzania testówobciążeniowych oraz mierzenia wydajności aplikacji bazodanowych, internetowych oraz wykorzystują-

cych protokoły wymiany danych takie jak TCP, FTP, SMTP etc. [36]. JMeter umożliwia dużą parame-

tryzację testów, walidowanie odpowiedzi serwisów (aplikacji) oraz szeroką gamę możliwych do wyge-

nerowania raportów z przebiegu badań wydajnościowych. Narzędzie zostało użyte do badania jakości

zaimplementowanego serwisu internetowego. W rozdziale Testowanie i Ewaluacja Sarmata RESTAPI zawarto kilka raportów z przebiegu badań [36]. Aplikacja wykorzystana została do generowaniaruchu internetowego, generowania raportów oraz wykresów ilustrujących responsywność oraz skutecz-

ność działania systemu. Podczas wykonywania testów wykorzystano następujące grupy komponentów

Jmeter:

• Miscellaneous Features - grupa komponentów służących do kompozycji testów. Zawiera m.in.elementy Test Plan, Thread Group, setUp Thread Group, tearDown Thread Group wymagane do

stworzenia test planu oraz przygotowania środowiska testowego.

• Samplers - grupa komponentów zawierające obiekty pozwalające na definiowanie żądań klienc-kich oraz pośrednio ich walidację

• Listeners - komponenty umożliwiające obserwacje, zapis oraz odczyt rezultatów testów. Częśćkomponentów udostępnia mechanizmy walidacji oraz agregacji zwalidowanych wyników ewalu-

acji.

• Configuration elements - komponenty umożliwiające konfigurację zapytań. Podczas testów apli-kacji bardzo użyteczne okazały się elementy HTTP Cookie Manager, HTTP Header Manager,

Random Variable, Counter.

• Assertions - elementy pozwalające na dowolnie określone walidowanie odpowiedzi serwera. W

20

4.1. Wykorzystane narzędzia oraz biblioteki 21

przypadku popełnionych testów użyto dodatku JSON Path Assertion m.in. do weryfikowania po-

prawności odpowiedzi na podstawie zawartości odpowiedzi

• Times komponenty z tej grupy są procesowane każdorazowo przed wysyłką określonych żądań. Napotrzeby testów użyto elementu Gaussian Random Timer w celu dokładniejszego odwzorowania

naturalnego środowiska użytkowego dla implementowanego serwisu

• Pre Processors elementy używane do modyfikacji żądań. Szczególnie użytecznym obiektem tejgrupy okazał się BeanShell PreProcessor, który umożliwia definiowanie własnych skryptów mo-

dyfikujących zapytania. W przypadku popełnionych testów komponent ten dzielił próbki PCM na

mniejsze kawałki binarne w celu odwzorowania transmisji sygnału w czasie rzeczywistym

• Post-Processors - elementy pozwalające na parsowanie odebranych odpowiedzi. Podczas ewaluacjiaplikacji wykorzystano obiekty JSON Extractor oraz BeanShell PostProcessor należące do tej

grupy, w celu ekstrakcji informacji na temat prawdopodobieństwa poprawności rozpoznanych fraz

oraz ich zapisu do pliku.

Ngnix jest serwerem HTTP wydanym na licencji BSD cechującym się bardzo wysoką wydajnością[37]. Jest również powszechnie wykorzystywany jako serwer proxy dla HTTP oraz IMAP/POP3. Według

raportu firmy Netcraft z 2016 roku ponad 169 milionów domen wykorzystuje omawiane rozwiązanie,

co plasuje nginx na trzecim miejscu w rankingu wykorzystywania serwerów WWW [38]. W omawia-

nym systemie serwer nginx wykorzystywany jest do równoważenia obciążenia węzłów REST API. W

tym kontekście zostanie bardziej szczegółowo opisany. Równoważenie obciążenia w systemach złożo-

nych z wielu instancji aplikacji jest powszechnie używaną techniką optymalizującą m.in. wykorzystanie

zasobów, maksymalizację przepustowości oraz ograniczenie opóźnienia. Nginx obsługuje następujące

metody równoważenia [39]:

• Round-robin - żądania serwerów aplikacji są rozprowadzane w zgodnie z algorytmem karuzelo-wym

• Least-connected - kolejne żądania są przekazywane do instancji z najmniejszą liczbą aktywnychpołączeń

• Ip-hash - funkcja skrótu używana jest do określenia, jaki serwer powinien być wybrany dla na-stępnego żądania. Funkcja skrótu jest wyliczana na podstawie adresu IP klienta.

Domyślna konfiguracja serwera dla potrzeb równoważenia obciążenia wygląda jak na listingu 4.1. W

ramach niniejszej pracy przebadano wpływ algorytmu równoważenia obciążenia na jakość serwowanych

usług. Wyniki zostały przedstawione w kolejnym rozdziale.


http {upstream myapp1 {

server srv1.example.com;server srv2.example.com;server srv3.example.com;

}

server {listen 80;

location / {proxy_pass http://myapp1;

}}

}

Listing 4.1: Domyślna konfiguracja ’load-balancera’ nginx

Spring Framework jest wszechstronnym szkieletem wydanym na licencji Apache 2.0 license [40]mającym na celu uproszczenie rozwoju aplikacji typu Enterptise. Oprogramowanie realizuje ten cel

dzięki relatywnie prostemu oraz konsystentnemu API opakowując w warstwę abstrakcji kompleksowy

kod niezbędny do tworzenia aplikacji typu Enterprise. Projekt rozwijany jest od 2002 roku [41]. Spring

cechuje się modularną architekturą, w której moduły podzielone są na grupy wyższego rzędu, dalej

zwane strefami funkcjonalnymi. Istnieje 8 podstawowych stref funkcjonalnych tj. [42]:

• Core Container - dostarcza podstawowych funkcjonalności szkieletu. Kontener jest odpowie-dzialny m.in. za takie funkcjonalności Spring’a jak odwrócenie sterowania (ang. Inversion of Con-

trol, IoC) wstrzykiwanie zależności (ang. Dependency Injection, DI) czy kontekst aplikacji (ang.

application context).

• Aspect-Oriented Programming (AOP) oraz Aspects - strefy te zawierają zestaw rozwiązań wspie-rających paradygmat programowania aspektowego tj. separację zagadnień oraz możliwość zmiany

zachowania istniejącego kodu źródłowego bez jego modyfikacji. Aspekty okazały się bardzo po-

mocne na etapie diagnozy i usuwania błędów aplikacji (ang. debugging). AOP usprawniło, także

proces dodania warstwy rejestracji zdarzeń w systemie (ang. logging) przydatnej następnie na eta-

pie ewaluacji systemu.

• Messaging - dostarcza warstwę abstrakcji dla aplikacji typu message-based• Data Access/Integration - jest to warstwa dostarczająca rozwiązań z zakresu mapowania

obiektowo-relacyjnego, integracji z bazami danych oraz z systemami umożliwiającymi asynchro-

niczne przesyłanie komunikatów

• Web - zawiera implementację modułów służących np. do budowania aplikacji oraz serwisów in-ternetowych opartych o architekturę model-view-controler (MVC) oraz REST

• Instrumentation - zawiera implementacje infrastruktury ładującej używane biblioteki (ang. clas-sloader)

• Test - dostarcza rozwiązania usprawniające testy jednostkowe oraz integracyjne tworzonych kom-ponentów

Wspomniany podział ilustruje rysunek 4.1


Rys. 4.1: Diagram blokowy ilustrujący podział na strefy funkcjonalne szkieletu aplikacji Spring (źródło[42]).

SQLite jest to wbudowana, relacyjna bazą danych. Produkt wraz z kodem źródłowy jest udostęp-niany w ramach licencji Public domain [43]. Cechą charakterystyczną bazy SQLite jest jej kompakto-

wość - baza (tj. sama aplikacja, nie wliczając zgromadzonych danych) przechowywana jest w jednym

pliku, którego rozmiar nie przekracza 0,5MB [44]. Do najważniejszych właściwości bazy należą:

• mobilność między-platformowa - można bazę danych (tj. plik) przenieść pomiędzy architekturamifizycznymi (np. architektura 32 oraz 64 bitowa) oraz logicznymi (np. big-endian oraz little-endian)

bez żadnej straty informacji,

• kompaktowość - jeden plik, małych rozmiarów,• łatwość użycia - nie jest wymagana żadna konfiguracja SQLite,• niezawodność - gwarantuje własności ACID [45] dla transakcji, nawet w przypadku awarii sys-

temu na którym baza się znajduje.

Baza SQLite wykorzystywana jest przez np. Apple iTunes, Android [46]. Opisywana baza została wy-

brana jako baza docelowa ze względu na niewielkie rozmiary, przenośność oraz brak konieczności kon-

figurowania.

Redis (ang. REmote DIctionary Server) jest to nierelacyjna baza danych rezydująca natywnie wpamięci RAM (ang. in-memory database). Kod źródłowy aplikacji udostępniony jest na licencji BSD

(Berkeley Software Distribution License). Redis jest magazynem rekordów typu klucz-wartość używa-

nym jako baza danych, cache oraz broker wiadomości [47]. Należy jednak zaznaczyć, że wartościami

słownikowymi mogą tutaj być kompleksowe obiekty w postaci ciągu bajtów. Dodatkowo, struktura bazy

danych może być tworzona przy użyciu struktur danych takich jak:

• lista (ang. list) czyli sekwencje uporządkowanych wartości. Możliwe jest dodawanie elementówna początku i końcu listy oraz usuwanie elementów z poza wyznaczonych indeksów,

4.2. Opis implementacji 24

gRPC REST API Opisrpc DefineGram-mar(DefineGrammarRequest)returns (DefineGrammarRe-spone)

http:///grammar definicja gramatyki dla użyt-kownika. Zdefiniowana grama-tyka zostanie zapisana w pa-mięci trwałej i jest przypisana dokonkretnego użytkownika

rpc Recognize(stream Recogni-zeRequest) returns (stream Re-cognizeResponse)

http:///recognize,http:///init

inicjalizacja sesji ASR oraz re-alizacja operacji rozpoznawania.Operacje przeprowadzane w jed-nej metodzie w ramach proto-kołu gRPC zostały rozdzialonew nowopowstałym REST API

Tabela 4.1: Modyfikacja dotychczasowego interface.

• hasz (ang. hash) struktura umożliwiająca przypisywanie danych słownikowych (klucz-wartość)jako wartość wyższego klucza,

• krotka (ang. set) czyli sekwencja unikalnych wartości. Przy pomocy ktorek możliwe jest tworzenieunii, iloczynów kartezjańskich etc.. Istnieją dwie postaci krotki tj. posortowana (ang. sorted set)

oraz nieuporządkowana [48].

Baza danych Redis została wykorzystana w implementowanym systemie jako magazyn sesji klienckich.

Oprócz wyszczególnionych wyżej rozwiązań, podczas realizacji celów określonych na początku

pracy magisterskiej skorzystano także z biblioteki RestAssured oraz cURL. Obie biblioteki posłużyły do

badania serwisu internetowego. Dodatkowo w celach badawczych zaimplementowano aplikację kliencką

w języku python, umożliwiającą testowanie usługi Sarmata REST API.

4.2. Opis implementacji

Opisywany serwis rozszerza funkcjonalność serwowaną przez silnik Sarmata o kolejny interface. Do

chwili obecnej komunikacja z silnikiem odbywała się w ramach interfejsu gRPC, który jest szczególnym

wariantem protokołu RPC udostępnionym przez firmę Google [49]. Porównanie interface gRPC oraz

REST silnika Sarmata przedstawiono w tabeli 4.1.

Aplikacja serwerowa Moduł napisany w całości od podstaw w architekturze MVC (Model-View-Controller) z wykorzystaniem szkieletu aplikacyjnego Spring. Aplikacja udostępnia trzy rodzaje punk-

tów końcowych tj. grammar, init, recognize, które odpowiadają wszystkim publicznie udostępnionym

metodom silnika Sarmata. Implementując program starano się zachować wszelkie zasady określane mia-

nem dobrych praktyk programistycznych. Aplikacja wykorzystuje szablony takie jak szablon dostępu

danych, autoryzacji i uwierzytelniania oraz obsługi testowania. Opisywany moduł posiada zaimplemen-

towany prosty mechanizm równoważenia obciążenia. Zrezygnowano równocześnie z zastosowania do

tych celów dedykowanego rozwiązania takiego jak aplikacja nginx. Z uwagi na fakt, iż udostępniona

na potrzeby realizacji projektu wersja serwera Sarmata pozwala na równoczesne połączenie 5 klientów,

dodatkowe rozwiązania nie są wymagane. Należy zaznaczyć, że pomimo ograniczonej ilości klientów


można dowolnie modyfikować ilość uruchomionych instancji serwera przez co rozwiązanie staje się

skalowalne. W ramach realizacji niniejszej pracy opracowano, także mechanizm zdalnego przydzielania

zasobów - w tym przypadku instancji silnika Sarmata.

Klient gRPC Komunikacja pomiędzy opisaną w poprzednim paragrafie aplikacją a silnikiem ASRodbywa się za pośrednictwem protokołu gRPC. Diagram 4.2 ilustruje sekwencje zdarzeń powielanych

podczas obsługi klienta. Klient gRPC określony jest jako REST Serwer.

Rys. 4.2: Diagram sekwencji ilustrujący sposób komunikacji asynchronicznej w opracowanym systemie[50]

Klient REST Do celów testowych opracowano również aplikacje kliencką, która umożliwia wery-fikacje poprawnego działania serwisu. Aplikacje zaimplementowana jest w technologiach python oraz

Java.

Podczas opracowywania rozwiązania bardzo dużą rolę odegrały, także nie wspomniane wcześniej

narzędzia takie jak Wireshark oraz JProfiler, które pozwoliły na relatywnie szybkie znalezienie powodów

występujących usterek. Rysunek 4.3 przedstawia wymianę wiadomości zaimplementowanego serwera z

serwerem Sarmata. Warto zwrócić uwagę, iż komunikacja następuje poprzez protokół HTTP/2.0 a nie

HTTP/1.1 w odróżnieniu do większości przypadków [51].


Rys. 4.3: Przykładowy zrzut ekranu ilustrujący wymianę wiadomości pomiędzy zaimplementowanąfasadą a silnikiem ASR

5. Testowanie i Ewaluacja Sarmata REST API

Celem projektu było stworzenie systemu umożliwiającego rozpoznawanie mowy polskiej w cza-

sie rzeczywistym. Na implementowany system ASR składa się kilka elementów tj. klient internetowy,

fasada REST-owa oraz silnik ASR Sarmata. Przeprowadzone testy rozwiązania miały charakter czarno-

skrzynkowy (ang. black box tests) z uwagi na fakt, iż nie odnosiły się do wewnętrznej struktury systemu.

W poprzedzających rozdziałach przybliżone zostały podstawy teoretyczne użyteczne podczas imple-

mentowania systemu. Niniejszy rozdział zawiera opis przeprowadzonych działań pozwalających doko-

nać ewaluacji stworzonego rozwiązania. Zostały w nim zawarte, także wyniki przeprowadzonych testów

aplikacji.

5.1. Przykład użycia API

Zaimplementowany system jest systemem czasu rzeczywistego (ang. Real Time System, RTS). Sys-

tem czasu rzeczywistego to system w którym obliczenia prowadzone są równolegle z przebiegiem ze-

wnętrznego procesu [52]. API wspiera dwa tryby kooperacji z systemem

• tryb wsadowy (ang. batch mode)• tryb czasu rzeczywistegoW trybie wsadowym użytkownicy komunikują się z systemem za pomocą metody POST protokołu

HTTP. Odpowiedzią na zapytanie są dane w notacji JSON zawierające wynik transkrypcji. Pełna komu-

nikacja w tym trybie wymaga wysłania dwóch zapytań typu POST. Pierwsze zapytanie służy definicji

używanej gramatyki. Kolejne zapytanie zawiera treść przewidzianą do transkrypcji. Interface zaimple-

mentowanego serwisu wzorowany jest na rozwiązaniu zastosowanym w usłudze Google Speech API.

Przykładowe zapytanie w trybie wsadowym ilustruje listing 5.1.

curl -X POST --data-binary @bohaterow_westerplatte.wav -H ’Content-Type:application/json’ -H ’sampling-rate:16000’ -H ’complete-timeout: 1000’-H ’incomplete-timeout: 3000’ -H ’no-input-timeout: 10000’ -H’no-rec-timeout: 10000’ -H ’no-match-th: 0.5’http://api.sarmata.com/recognize

Listing 5.1: Przykładowe zapytanie do Sarmata REST API przy użyciu biblioteki sieciowej curl

27

5.1. Przykład użycia API 28

Przykładową odpowiedź systemu ilustruje listing 5.2:

{"responseStatus": "SUCCESS","error": null,"warning": null,"eventTime": 3920,"results": [{"words": [{"transcript": "BOHATERÓW","confidence": 0.7183573842048645,"start": 1710,"end": 2210,"logprob": 11.909333229064941

},{"transcript": "WESTERPLATTE","confidence": 0.6491934061050415,"start": 2210,"end": 3040,"logprob": 8.808754920959473

}],"confidence": 0.9221178293228149,"correct": false,"semantics_interpretation": ""

}]

}

Listing 5.2: Przykładowa odpowiedź serwisu

API udostępnia także tryb czasu rzeczywistego. W trybie tym użytkownicy wysyłają dźwięku w

wielu kawałkach za pośrednictwem metody POST protokołu HTTP. Z uwagi na fakt, iż notacja JSON

nie wspiera enkodowania danych binarnych, koniecznym jest kodowanie kawałków danych PCM (ang.

Pulse-Code modulation). Oficjalnie wspieranym przez API algorytmem kodowania danych jest algorytm

Base64. Dodatkowe informacje dotyczące użycia systemu znajdują się na stronie [33] gdzie znajduje się

oficjalna dokumentacja systemu.

5.2. Środowisko testowe 29

System operacyjny Ubuntu 5.4.0, 64bitProcesor Intel Xeon E5-2650 (2.0 GHz, 8 rdzenie, 64bit)Pamięć RAM 125GBRodzaj dysku 3TBJava VM Oracle JDK 1.9.0, 64bitPython VM Python 2.7.12, GCC 5.4.0Baza danych SQLite, 3.20.1, 64bit

Tabela 5.1: Specyfikacja maszyny phoneme tj. zdalnego środowiska testowego

System operacyjny Windows 7 Enterprice, 64bitProcesor Intel i7-6820HQ (2.7 GHz, 8 rdzenie, 64bit)Pamięć RAM 16GB DDR3Rodzaj dysku Intel SSDSC2KF360H6, 360GBJava VM Oracle JDK 1.8.0_102, 64bitPython VM Python 2.7.10, GCC 5.4.0Baza danych SQLite, 3.20.1, 64bit, Redis 4.0.1, 64bit

Tabela 5.2: Specyfikacja lokalnego środowiska testowego

5.2. Środowisko testowe

Testy zrealizowanego projektu zostały przeprowadzone w środowisku heterogenicznym złożonym z

dwóch maszyn fizycznych. Specyfikację obu wymienionych środowisk przedstawiają tabele 5.1 oraz 5.2.

Instancje silnika Sarmata są uruchomione na zdalnej maszynie phoneme. Na maszynie lokalnej znaj-

dują się pozostałe elementy infrastruktury testowej wymienione poniżej:

• Klient HTTP - aplikacja umożliwiająca wykonywanie oraz walidację zapytań oraz odpowiedziserwisu

• Fasada REST-owa udostępniająca usługi poprzez protokół HTTP.• Moduł gRPC umożliwiający komunikację pomiędzy fasadą a silnikiem Sarmata

5.3. Dane testowe

Na potrzeby testów wykorzystano próbki nagrań oraz gramatyki udostępnione przez naukowców z

zespołu Przetwarzania Sygnałów Cyfrowych (ang. Digital Signal Processing, DSP) z katedry Elektroniki

Akademii Górniczo-Hutniczej AGH. Wszystkie próbki to monofoniczne pliki dźwiękowe próbkowane

z częstotliwością 16000 Hz zapisane w formacie .wav. Do celów testowych wykorzystano nagrania z

grupy o roboczych nazwach AGHdigits oraz AGHstreets. Grupy zawierają kolejno 93 oraz 2003 różne

nagrania. Średni rozmiar dla plików z zestawów AGHstreets oraz AGHdigits to kolejno 81 KB oraz 138

KB z czego wynika, iż średni czas trwania próbek z wymienionych zestawów to 2.54 s oraz 4.32 s.

Średnie czasy trwania nagrań oszacowano przy użyciu wzoru 5.1. Dane podsumowuje tabela 5.3.

Podczas testowania aplikacji z całościowym wykorzystaniem dostarczonych zestawów nagrań użyto

tej samej konfiguracji silnika ASR. Parametry wspomnianej konfiguracji przedstawiono w tabeli 5.4.

5.3. Dane testowe 30

Nazwa zestawu AGHstreets AGHdigits

Ilość nagrań testowych 2003 93Format danych w nagraniach wav wavCzęstotliwość próbkowania [Hz] 16000 16000Liczba bitów przypadająca 16 16na próbkęSposób zapisu mono monoŚredni rozmiar pliku [KB] 81 138Średni czas trwania próbki [s] 2.539 4.32

Tabela 5.3: Dane dotyczące użytych podczas ewaluacji zestawów testowych

Nazwa Parametru Wartość

sampling-rate 16000

complete-timeout 10000

incomplete-timeout 30000

no-input-timeout 10000

no-rec-timeout 10000

no-match-th 0.5

Tabela 5.4: Parametry testowe użyte do konfiguracji silnika ASR

Scenariusze testowe

Dla każdego z wymienionych w poprzedniej sekcji zestawów przeprowadzono analogiczne scena-

riusze testowe. Przygotowana aplikacja została przetestowana dla obu wariantów działania to jest gdy

użytkownik korzysta z trybu wsadowego (po definicji gramatyki, przesyła cały plik audio) oraz trybu

transmisji rzeczywistej. W trybie transmisji rzeczywistej zreprodukowano sytuacje w której użytkownik

przesyła kawałki binarne o wielkościach 2048 bajtów dodając równocześnie opóźnienie wraz z dewia-

cją pomiędzy wysyłką kolejnych pakietów. Miało to na celu bardziej dokładne odwzorowanie działania

systemu w środowisku produkcyjnym (tj. symulacja opóźnień transmisji etc.). Wartości opóźnienia oraz

dewiacji zostały ustalone pośrednio przy użyciu wzoru 5.1 oraz biorąc pod uwagę, iż dane binarne wy-

syłane są w kawałkach o wielkości 2048 bajtów, częstotliwość próbkowania nagrań wynosi 16000 Hz,

ilość bitów przypadających na próbkę sygnału wynosi 16.

BR = SR ∗BD ∗ CH (5.1)

Gdzie:

• BR - ilość bitów w jednostce czasu, podawany w kilobitach na sekundę (ang. kilobit per second,kbps)

• SR - częstotliwość próbkowania sygnału, podawany w Hz• BD - ilość bitów przypadająca na jedną próbkę sygnału

5.4. Badanie aspektów jakościowych serwisu 31

• CH - ilość kanałów

Podstawiając dane do wzoru otrzymano informację, iż 1 sekunda nagrania ma rozmiar 32 KB. Stąd

nagrywając dźwięk i strumieniując go w czasie rzeczywistym paczka 2048 bajtów jest wysyłana w przy-

bliżeniu co 62 ms.

Badania zachowania systemu przeprowadzono w konfiguracjach testowych przedstawionych w tabeli

5.5. W dalszej części pracy zostaną zaprezentowane wybrane wyniki badań.

Ilość Ramp-up time [s] Dewiacja [ms] Stałeużytkowników opóźnienie [ms]

Przypadek 1 20 1 30 60

Przypadek 2 50 5 30 60

Przypadek 3 100 30 30 60

Przypadek 4 150 40 30 60

Przypadek 5 150 90 30 60

Przypadek 6 250 150 30 60

Przypadek 7 500 120 30 60

Przypadek 8 8000 7200 30 60

Tabela 5.5: Dane dotyczące użytych podczas ewaluacji zestawów testowych

Osobnym scenariuszem testowym było badanie zachowania samego silnika Sarmata za pośrednic-

twem fasady REST-owej. W tym celu przeprowadzono test obciążeniowy uwzględniający relatywnie

niewielką liczbę użytkowników przy wykorzystaniu wyselekcjonowanych nagrań. W tym przypadku

zmianie podlegały parametry testowe użyte do konfiguracji silnika ASR. Badano nie tylko wpływ konfi-

guracji na szybkość działania serwisu, ale również na pewność rozpoznania transkrybowanych fraz.

Każdy z opisanych w niniejszym paragrafie przypadków testowych został przeprowadzony kilku-

krotnie, w takich samych warunkach. Zaprezentowane w dalszej części pracy wyniki, są wynikami su-

marycznymi.

5.4. Badanie aspektów jakościowych serwisu

5.4.1. Badanie systemu ASR

W niniejszym rozdziale przedstawione zostaną opracowane wyniki badań systemu ASR. Są to staty-

stycznie ujęte wyniki testów funkcjonalnych systemu. Wyniki badań oparte są na 100 iteracjach testów.

Dane testowe zostały opisane wyżej. Rezultaty badań przedstawiono w tabeli 5.6.


Zestaw nagrań AGHdigits AGHstreets

Maksymalna pewność 77,1 81,9rozpoznania [%]

Uśredniona pewność 61,9 65,6rozpoznania [%]

Mediana pewności 65,2 67,4rozpoznania [%]

Brak rozpoznania [%] 17,6 6

Tabela 5.6: Uśrednione rezultaty transkrypcji nagrań testowych

Przedstawione powyżej wyniki wskazują na dobrą skuteczność rozpoznawania systemu. Niepoko-

jące może wydawać się wysoki wskaźnik przypadków, w których operacja transkrypcji zwróciła brak

rezultatów, dla zestawu nagrań AGHdigits. Brak jednak informacji na temat nominalnej skuteczności

systemu Sarmata w kontekście testowanych nagrań. Najlepiej rozpoznawaną sekwencją wyrazów z ze-

stawy nagrań AGHstreets jest sekwencja "Michała Lenartowicza". Pewność rozpoznania fraz wynosi w

tym przypadku niespełna 81,9 %. W przypadku zestawu danych AGHdigits, najbardziej rozpoznawalną

cyfrą jest "0". Pewność rozpoznawania cyfry "0"wynosi średnio 77,1 %.


5.4.2. Testy wydajnościowe

Niniejszy rozdział przedstawia wyniki testów obciążeniowych systemu. Uwzględnione w niniejszej

pracy przypadki testowe zostały tak dobrane, aby móc przeprowadzić testy badające możliwie szeroko

jakość działania systemu. Przypadki testowe o numerach 1, 2, 3, 4, oraz 7 można zaliczyć do kategorii

systemów stresowych (ang. stress test) [53]. Przypadek testowy numer 8 pozwala na przeprwadzenie

testów typu Soak. Są to testy, w których system poddawany jest zakładanemu, typowemu w warunkach

produkcyjnych obciążeniu przez dłuższy okres czasu [54]. Pozostałe przypadki tj. przypadek numer 5

oraz 6 są testami obciążeniowymi typu (ang. load testing). Statystyczne opracowanie wyników testów

zawiera następujące metryki:

• średni czas transkrypcji,• maksymalny czas transkrypcji,• mediana czasu transkrypcji,• metryka 90% - określa czas przetwarzania nagrań, który nie przekracza 90% wysyłanych żądań

transkrypcji,

• metryka 95% - określa czas przetwarzania nagrań, który nie przekracza 95% wysyłanych żądańtranskrypcji,

• błąd przetwarzania - procentowy udział błędów transkrypcji (w tym brak rozpoznania żadnej frazyoraz błędy serwera).

Zestaw 1 - AGHstreets

W poniższej tabeli 5.8 zaprezentowano statystyczne wyniki testów przeprowadzonych dla zestawu

nagrań numer 1.

Przypadkitestowe

1 2 3 4 5 6 7 8

Średni czastranskrypcji [ms]

5006 7663 5397 3436 2159 2155 7519 -

Maksymalnyczas transkrypcji [ms]

8653 10616 10369 10557 7939 7021 10850 -

Mediana czasutranskrypcji [ms]

5013 8158 4016 2370 1935 1993 9400 -

Metryka 90% [ms] 6611 10237 10162 8109 3093 3100 10255 -

Metryka 95% [ms] 8621 10422 10173 10158 3958 3754 10337 -

Błąd przetwarzania [%] 10 34 26 16 7,74 5,6 72,4 -

Tabela 5.8: Statystycznie wyliczone wartości czasów transkrypcji dla poszczególnych przypadków te-stowych dla zestawu danych AGHstreets.


Zestaw 2 - AGHdigits

Tabela 5.10 zawiera statystyczne dane na temat rezultatów przeprowadzonych testów.

Przypadkitestowe

1 2 3 4 5 6 7 8

Średni czastranskrypcji [ms]

7350 7327 5397 6548 7916 2756 8587 4934

Maksymalnyczas transkrypcji [ms]

10208 10558 10369 10369 10537 10256 10795 71539

Mediana czasutranskrypcji [ms]

7267 8592 4016 6816 10149 2282 10173 1991

Metryka 90% [ms] 10171 10271 10162 10180 10248 4647 10351 10333

Metryka 95% [ms] 10180 10319 10173 10236 10289 8802 10404 13267

Błąd przetwarzania [%] 15 46 26 49 67,33 29 91,6 46,79

Tabela 5.10: Statystycznie wyliczone wartości czasów transkrypcji dla poszczególnych przypadkówtestowych dla zestawu danych AGHdigits.

Rysunki 5.1 oraz 5.2 są zbiorczymi wynikami testów przeprowadzonych przy użyciu narzędzia Jme-

ter. Analizując rysunek 5.2 można dostrzec, iż responsywność serwisu jest największa na początku

trwania testu - sekwencyjne uruchamianie kolejnych użytkowników niepowoduje drastycznego wzro-

stu czasu procesowania żądań. Wskazuje na to rysunek 5.3 a dokładniej część wykresu ilustrująca, iż

dla 20 klientów pracujących jednocześnie czasy transkrypcji wynoszą około 3 sekund. Czasy proce-

sowania dla mniejszej ilości wątków są nawet 3 krotnie wyższe niż dla większej ilości wątków. Fakt

ten może wskazywać, na problemy wydajnościowe (lub/i logiczne) algorytmu równoważenia obciążenia

oraz przydzielania zasobów serwera. Współczynnik RTF, opisany we wstępie teoretycznym, wynosi w

tym przypadku RTF = 2, 91 co jest wartością 3 krotnie wyższą w porównaniu do wartości pożądanej.

Mediana oraz średni czas transkrypcji nagrań są równe kolejno 7,4 s. oraz 7,3 s

Rys. 5.1: Zagregowane czasy realizacji operacji transkrypcji dla 20 użytkowników uruchomionych wczasie 1 sekundy. Zestaw testowy AGHdigits. Przypadek testowy 1.


Rys. 5.2: Wykres ilustrujący zależność czasu odpowiedzi od ilości aktywnych użytkowników serwisu.Zestaw testowy AGHdigits. Przypadek testowy 1.

Badanie zachowania systemu dla 50 użytkowników uruchomionych w ciągu 5 sekund pozwala wy-

snuć podobne wnioski co w przypadku testowym numer 1. Algorytm równoważenia obciążenia pracuje

niestabilnie - stąd wahania czasów odpowiedzi na żądania klienckie. Rysunek 5.3 wskazuje na liniowy

wzrost czasów odpowiedzi podczas pierwszych 10 sekund ruchu klienckiego. Po upływie pierwszych 10

sekund wszystkie wątki zostały wystartowane a część z nich zakończyła już swoje działanie. Szczytowe

obciążenie aplikacji to 41 równoległych użytkowników. Mediana oraz średni czas transkrypcji nagrań są

równe kolejno 8,6 s oraz 7,3 s.

Rys. 5.3: Wykres ilustrujący zależność czasu trwania transkrypcji od czasu. Zestaw danych AGHdigits.Przypadek testowy 2.


Rys. 5.4: Zagregowane czasy realizacji operacji transkrypcji dla 50 użytkowników uruchomionych wczasie 5 sekund. Zestaw testowy AGHdigits. Przypadek testowy 2.


Z wykresu 5.6 wynika, iż czas oczekiwania na transkrypcje w teście dla przypadku testowego numer

3 wzrasta w początkowej fazie testów. Na podstawie rysunku 5.8 można stwierdzić, iż maksymalne

obciążenie serwera to 27 równoczesnych sesji klienckich. Średni czas realizacji żądań klienckich dla

tego przypadku testowego wynosi w przybliżeniu 6,5 sekundy. Uwzględniając średnią długość nagrań

użytych podczas testów można określić współczynnik RTF . Wynosi on w tym przypadku 2.5. Wynik

podano z dokładnością do jednego miejsca po przecinku.


Rys. 5.6: Wykres ilustrujący zależność czasu trwania transkrypcji od czasu. Zestaw danych AGHdigits.Przypadek testowy 3




Zilustrowane rezultaty przypadku testowego numer 4 przedstawiono na rysunkach 5.9, 5.10. Ana-

lizowany przypadek pozwala przeanalizować zachowanie systemu w sytuacji kilkusekundowego obcią-

żenia kilkudziesięcioma użytkownikami. W 50 sekundzie testu czasy przetwarzania żądań drastycznie

wzrastają. Możne to sugerować osiągnięcie pewnej wartości progowej ilości użytkowników. Powyżej tej

wartości responsywność maleje ponad czterokrotnie. Średni czas przetwarzania żądań oraz ich mediana

w tym przypadku wynoszą w przybliżeniu 7,9 sekundy oraz 10,1 s.




Poniżej znajdują się trzy wykresy przedstawiające zachowanie się systemu dla ruchu generowanego

przez 150 użytkowników w warunkach zbliżonych do produkcyjnych. Średni czas realizacji operacji

transkrypcji nagrania wynosi w tym przypadku 2.8 sekundy, co sprawia, iż operacja jest realizowana

niemal w czasie rzeczywistym. Współczynnik RTF wynosi w tym przypadku 1,1. Wykres 5.11 posiada

bardziej płaskie zbocza, co wynika m.in. z bardziej równomiernego obciążenia systemu. Analizując wy-

kres ?? oraz biorąc pod uwagę specyfikę omawianego przypadku testowego (150 użytkowników urucho-mionych w czasie 90 sekund) można spekulować, iż w przypadku równomiernego obciążenia systemu,

ilością klientów nie większą niż 10, system jest w stanie przetwarzać żądania o transkrypcję w czasie

niemal rzeczywistym. Z tabeli 5.10 można odczytać, iż błąd przetwarzania dla omawianego przypadku

testowego (numer 5) wynosi 7,74 %.





Przypadek testowy testowy numer 6 został celowo pominięty w rozważaniach, z uwagi na znaczne

podobieństwo charakterystyk wykresów do charakterystyk z przypadku testowego numer 5.



Dla przypadku testowego numer 7 zanotowano średni czas realizacji transkrypcji wynoszący 8,6 se-

kundy. Współczynnik RTF dla tego scenariusza wynosi w przybliżeniu 3,3. Czas odpowiedzi na żądania

klienckie w czasie całego testu ilustruje rysunek 5.15.

Rys. 5.15: Wykres ilustrujący zależność czasu trwania transkrypcji od czasu. Zestaw danych AGHdigits.Przypadek testowy 7




Przeprowadzenie testów aplikacji dla przypadku testowego numer 8 uwidacznia problemy z zarzą-

dzaniem zasobami. Skutkiem wnikliwej analizy biało-skrzynkowej analizowanego przypadku jest wy-

krycie błędu w zwalnianiu zasobów. Kanały transportowe tworzone w celu przeprowadzenia wymiany

danych z serwerem gRPC silnika Sarmata nie są każdorazowo, po obsłużeniu klienta, niszczone. Błąd

zlokalizowany jest w części kodu odpowiedzialnej za zarządzanie zasobami serwerowymi. Powoduje

on powstawanie różnic pomiędzy informacjami na temat stanu zajętych zasobów na zdalnej lokalizacji

a stanem faktycznym. Jednym z pomysłów na rozwiązanie problemu jest zaimplementowanie po stro-

nie serwerowej (w silniku ASR, z wystawionym interface gRPC) mechanizmu pozwalającego zapytać

o ilość wolnych kanałów klienckich danej instancji. Zaimplementowany po stronie serwerowej mecha-

nizm, pozwoliłby uprościć logikę modułu zarządzającego zasobami. System odpytywałby instancję (lub

wiele instancji) serwera ASR o ilość wolnych kanałów bezpośrednio przed stworzeniem kolejnego. Tym

samym potrzeba rejestrowania stworzonych kanałów transportowych nie byłaby konieczna.




Rysunki 5.20 oraz 5.21 wyglądają bardzo podobnie do analogicznych rysunków dla zestawu da-

nych AGHdigits. Operacja rozpoznawania mowy dla zestawu danych AGHstreets trwa w tym przypadku

średnio 2,3 sekundy krócej niż ma to miejsce dla zestawu AGHdigits.

Analiza porównawcza wyników działania serwisu wykazuje podobieństwo w działaniu serwisu dla

analogicznych przypadków z obu zestawów. Jedynym czynnikiem różniącym w tym przypadku jest za-

stosowanie innych danych wejściowych. Pozwala to zrozumieć, dlaczego charakterystyki wygenerowane

dla obu scenariuszy są podobne. System poddany jest podobnemu obciążeniu i reaguje analogicznie.

Podkreślić należy fakt, iż dla większości przypadków, rozpoznawanie fraz przebiega szybciej dla nagrań


z zestawu AGHstreets. Dłuższe czasy rozpoznawania mowy dla przypadków z zestawu AGHdigits może

być skutkiem użycia nieadekwatnej konfiguracji systemu ASR. Podczas testów nagrań z obu zestawów

użyto tych samych parametrów konfiguracyjnych silniku Sarmata.

Rys. 5.20: Zagregowane czasy realizacji operacji transkrypcji dla 20 użytkowników uruchomionych wczasie 1 sekundy. Zestaw testowy AGHstreets. Przypadek testowy 1.

Rys. 5.21: Wykres ilustrujący zależność czasu odpowiedzi od ilości aktywnych użytkowników serwisu.Zestaw testowy AGHstreets. Przypadek testowy 1.


Rys. 5.22: Wykres ilustrujący zależność czasu trwania transkrypcji od czasu. Zestaw danych AGHstreets.Przypadek testowy 2.

Rys. 5.23: Zagregowane czasy realizacji operacji transkrypcji dla 50 użytkowników uruchomionych wczasie 5 sekund. Zestaw testowy AGHstreets. Przypadek testowy 2.



Wykres 5.25 ilustruje niemal liniowy wzrost czasów realizacji żądania transkrypcji w czasie. Średni

czas rozpoznawania frazy w nagraniu wynosi 5,4 sekundy, co powoduje, iż współczynnik RTF dla tego

przypadku przyjmuje przybliżoną wartość wynoszącą 1,25. Jest to wartość zadowalająca, zwłaszcza bio-

rąc pod uwagę, iż omawiany przypadek testowy zakłada obciążenie systemu stoma sesjami klienckimi.




Podsumowanie testów

W tabelach 5.10 oraz 5.8 zawarto zagregowane dane na temat czasu trwania przetwarzania żądań

klienckich oraz niezawodności serwisu. Zawartość obu tabel wskazuje na dużo wyższą skuteczność oraz

responsywność serwisu w przypadku gdy użytkownik żąda transkrypcji nazw ulic, niż liczb. Tezę tą

potwierdzają wyniki działania systemu dla przypadków testowych 1,4,5 oraz 6, potęgowane dodatkowo

przez fakt, iż nagrania pochodzące ze zbioru nagrań AGHdigits są nagraniami trwającymi krócej. Przy-

padki testowe 2, 3 oraz 8 prezentują zbliżone rezultaty. Ciężki do uzasadnienia jest blisko czterokrotnie

dłuższy czas rozpoznawania wyrazów dla zestawu nagrań AGHdigits w przypadku testowym numer 5.

Wykresy przedstawione w niniejszym rozdziale, wykazują również, że w przypadku użycia jako danych

wejściowych nagrań z zestawu AGHstreets, system pracuje w bardziej liniowy sposób. Poniższe wykresy

przedstawiają porównanie czasów realizacji żądań klienckich przez badany system.


Rys. 5.37: Porównanie średnich czasów przetwarzania żądania transkrypcji dla zestawów nagrań AGH-streets oraz AGHdigits.

Rys. 5.38: Porównanie maksymalnych czasów przetwarzania żądania transkrypcji dla zestawów nagrańAGHstreets oraz AGHdigits.

5.5. Podsumowanie 54

5.5. Podsumowanie

Stworzona fasada jest produktem umożliwiającym rozpoznawanie mowy polskiej wykorzystując do

tego celu protokół HTTP. W przypadku niewielkiego, krótkotrwałego obciążenia serwisu, usługa działa

poprawnie dla ponad 90 % żądań. W przypadku większej ilości użytkowników występują problemy

z poprawną obsługą klientów. Zaobserwowano relatywnie dużą rozbieżność w czasach rozpoznawania

fraz dla nagrań pochodzących z różnych zestawów (tj. AGHdigits oraz AGHstreets). Może to być jednak

związane z nieodpowiednim ustawieniem silnika ASR Sarmata 2.0.

6. Podsumowanie

Opracowany system autorski jest dowodem, iż koncepcja dodania interface HTTP do silnika Sarmata

jest możliwa do realizacji ang. Proof Of Concept. Projektowanie, implementacja, konfiguracja środowi-

ska oraz testy rozwiązania zostały zrealizowane w ramach jednoosobowego zespołu. Biorąc pod uwagę

tę okoliczność, uzyskane w wyniku testów rezultaty można uznać za zadowalające. Zaimplementowane

rozwiązanie jest w pełni skalowalne i jest w stanie obsługiwać w warunkach zbliżonych do produkcyj-

nych nawet do 150 użytkowników jednocześnie. Niestety jakość działania serwisu definiowana przez

czynniki takie jak responsywność, obsługa sytuacji wyjątkowych oraz błędów, dostępność czy bezawa-

ryjny czas działania zależy silnie od czasu działania serwisu. W obecnej postaci system nie jest gotowy

na pracę w środowisku produkcyjnym z uwagi na szereg faktów:

• brak zaimplementowanego szyfrowania danych• brak zaimplementowanych mechanizmów obrony przed atakami na systemy komputerowe np.

odmiany ataków DoS

• niedoskonały algorytm równoważenia obciążenia sieciowego• brak obsługi niektórych błędówStworzony system może być jednak potraktowany jako podstawa do dalszych prac nad interface

REST dla silnika ASR Sarmata.

6.1. Osiągnięte cele

W ramach realizacji niniejszej pracy udało się ukończyć następujące zadania:

1. opracowanie teorii związanej z tematyką chmurową (zarządzanie zasobami serwerowymi), pod-

stawami rozpoznawania mowy, usługami rozpoznawania mowy oraz sposobu ich ewaluacji

2. zaprojektowanie oraz implementacja usługi internetowej udostępniającej funkcjonalności systemu

rozpoznawania mowy polskiej Sarmata 2.0

3. zaprojektowanie oraz realizacja testów rozwiązania

55

6.2. Perspektywy dalszych prac nad rozwojem systemu 56

6.2. Perspektywy dalszych prac nad rozwojem systemu

W chwili obecnej do głównych wad systemu zaliczyć należy malejącą, wraz z czasem trwania pracy

systemu, responsywność. Wynika to najprawdopodobniej z niedoskonałości algorytmu równoważenia

obciążenia oraz powiązanym z nim algorytmem zarządzania ilością instancji serwera ASR. Poniższej

wyartykułowano zadania, które w ocenie autora pozwolą na poprawę jakości świadczonych przez serwis

usług:

1. eliminacja problemu malejącej, wraz z czasem pracy systemu, responsywności

2. przygotowanie mechanizmu udostępniającego usługę typu Health Check pozwalającego spraw-

dzać ilość wolnych sesji klienckich jaką zdolna jest obsłużyć instancja serwera ASR

3. obsługa wyjątków w module transportowym gRPC po stronie zaimplementowanej fasady

4. dodanie mechanizmów bezpieczeństwa fasady

Spis rysunków

2.1 Systematyka serwisów chmurowych [5] . . . . . . . . . . . . . . . . . . . . . . . . . . 9

3.1 Czasy odpowiedzi dla serwisu internetowego wykonanego według stylu architektonicz-

nego REST oraz SOAP (źródło [27]) . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18

4.1 Diagram blokowy ilustrujący podział na strefy funkcjonalne szkieletu aplikacji Spring

(źródło [42]). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23

4.2 Diagram sekwencji ilustrujący sposób komunikacji asynchronicznej w opracowanym

systemie [50] . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25

4.3 Przykładowy zrzut ekranu ilustrujący wymianę wiadomości pomiędzy zaimplemento-

waną fasadą a silnikiem ASR . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26

5.1 Zagregowane czasy realizacji operacji transkrypcji dla 20 użytkowników uruchomionych

w czasie 1 sekundy. Zestaw testowy AGHdigits. Przypadek testowy 1. . . . . . . . . . . 34

5.2 Wykres ilustrujący zależność czasu odpowiedzi od ilości aktywnych użytkowników ser-

wisu. Zestaw testowy AGHdigits. Przypadek testowy 1. . . . . . . . . . . . . . . . . . . 35

5.3 Wykres ilustrujący zależność czasu trwania transkrypcji od czasu. Zestaw danych AGH-

digits. Przypadek testowy 2. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35

5.4 Zagregowane czasy realizacji operacji transkrypcji dla 50 użytkowników uruchomionych

w czasie 5 sekund. Zestaw testowy AGHdigits. Przypadek testowy 2. . . . . . . . . . . . 36




digits. Przypadek testowy 3 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37

5.7 Zagregowane czasy realizacji operacji transkrypcji dla 100 użytkowników uruchomio-

nych w czasie 20 sekund. Zestaw testowy AGHdigits. Przypadek testowy 3. . . . . . . . 37







57

SPIS RYSUNKÓW 58








nych w czasie 150 sekund. Zestaw testowy AGHdigits. Przypadek testowy 6. . . . . . . 40


digits. Przypadek testowy 7 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41


nych w czasie 120 sekund. Zestaw testowy AGHdigits. Przypadek testowy 7. . . . . . . 41


wisu. Zestaw testowy AGHdigits. Przypadek

à INFORMATYKI, ELEKTRONIKI I TELEKOMUNIKACJIdydaktyka:pracamagisterska... · 2017. 10. 18. ·...

Documents

Transcript of à INFORMATYKI, ELEKTRONIKI I TELEKOMUNIKACJIdydaktyka:pracamagisterska... · 2017. 10. 18. ·...