-
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 treści
1. Wstęp............................................................................................................................................... 6
1.1. Cele pracy .............................................................................................................................. 6
1.2. Zawartość pracy..................................................................................................................... 7
2. Przetwarzanie sygnałów w chmurze ............................................................................................ 8
2.1. Modele usług chmury obliczeniowej..................................................................................... 8
2.2. Podłoż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. Przegląd usług ASR............................................................................................................... 14
2.3.1. Rozwiązania komercyjne ........................................................................................... 14
2.3.2. Rozwiązania darmowe ............................................................................................... 14
3. Projekt systemu .............................................................................................................................. 16
3.1. Architektura rozwiązania....................................................................................................... 16
3.2. Podsumowanie....................................................................................................................... 19
4. Implementacja systemu ................................................................................................................. 20
4.1. Wykorzystane narzędzia oraz biblioteki................................................................................ 20
4.2. Opis implementacji................................................................................................................ 24
5. Testowanie i Ewaluacja Sarmata REST API .............................................................................. 27
5.1. Przykład użycia API .............................................................................................................. 27
5.2. Środowisko testowe ............................................................................................................... 29
5.3. Dane testowe.......................................................................................................................... 29
5.4. Badanie aspektów jakościowych serwisu.............................................................................. 31
5.4.1. Badanie systemu ASR................................................................................................ 31
5.4.2. Testy wydajnościowe ................................................................................................. 33
5.5. Podsumowanie....................................................................................................................... 54
6. Podsumowanie ................................................................................................................................ 55
6.1. Osiągnięte cele....................................................................................................................... 55
4
-
SPIS TREŚCI 5
6.2. Perspektywy dalszych prac nad rozwojem systemu.............................................................. 56
-
1. Wstęp
Rozpoznawanie mowy jest technologią pozwalającą komputerowi interpretować mowę ludzką na
przykład do celów transkrypcji lub jako alternatywną metodę interakcji. Początki badań nad rozpozna-
waniem mowy datuje się na lata trzydzieste XX wieku. Powstanie pierwszych systemów komputerowych
zdolnych rozpoznawać mowę datuje się na lata pięćdziesiąte XX wieku. Mogły one rozpoznać jedynie
kilka słów. Czterdzieści lat później liczbę słów rozpoznawanych przez komputery szacuje się na około
20 tysięcy. Powiększenie słowników systemów rozpoznających mowę związane było z ogromnym po-
stępem technologicznym oraz nieustannym zainteresowaniem tą tematyką naukowców z całego świata.
Wzrost mocy obliczeniowych komputerów przybliżał ludzkość do opracowania systemu zdolnego roz-
poznawać mowę w czasie rzeczywistym. Obecnie istnieje wiele rozwiązań pozwalających na realizację
wspomnianych zadań np. asystent osobisty Amazon Alexa. W dzisiejszych czasach niemal każdy tele-
fon komórkowy jest przystosowany do komunikacji z użytkownikiem za pomocą interfejsu głosowego.
Pojawia się coraz więcej rozwiązań, które bazują 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 postępu jakościowego syste-
mów automatycznego rozpoznawania mowy ASR (ang. Automatic Speech Recognition). Modele stają się
coraz szybsze i bardziej skuteczne. W ramach niniejszej pracy magisterskiej zaimplementowano serwis
internetowy umożliwiający rozpoznawanie mowy. Usługa udostępnia publicznie API systemu Sarmata
2.0 umożliwiającego automatyczne rozpoznawanie mowy polskiej korzystając z wybranej gramatyki
[1]. Silnik Sarmaty został w całoś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 umożliwiającej udostępnianie
funkcjonalności silnika rozpoznawania mowy polskiej Sarmata 2.0 poprzez protokół HTTP. Rozwiązanie
powinno zostać przetestowane a testy przeanalizowane. Dokładny zakres pracy obejmuje:
1. Przedstawienie teorii związanej z tematyką chmurową, podstawami rozpoznawania mowy oraz
usługami do rozpoznawania mowy.
2. Zaprojektowanie oraz implementacja usługi internetowej udostępniającej funkcjonalności systemu
rozpoznawania mowy polskiej Sarmata 2.0
6
-
1.2. Zawartość pracy 7
3. Opracowanie oraz wykonanie automatycznych testów funkcjonalnych integracyjnych oraz syste-
mowych rozwiązania.
4. Opracowanie oraz wykonanie automatycznych testów niefunkcjonalnych takich jak:
• testy wydajnościowe,• testy przeciążeniowe,• testy stresowe.
5. Konfiguracja i wdrożenie modułu umożliwiającego monitorowanie działania zaimplementowa-
nego API.
6. Zaprojektowanie oraz implementacja testów automatycznych serwisu.
1.2. Zawartość pracy
W rozdziale Chmura obliczeniowa w kontekście usług związanych z przetwarzaniem sygna-łów przybliżono tematykę usług chmurowych, podstawy teoretyczne związane z automatycznym roz-poznawaniem mowy oraz omówiono istniejące rozwiązania z zakresu ASR. Kolejny rozdział zawiera
rozważania na temat projektu serwisu internetowego wykonanego w ramach niniejszej pracy, jego ar-
chitektury, rozważanych rozwiązań architektonicznych oraz technologicznych. Sekcja Implementacjasystemu omawia użyte biblioteki i narzędzia. Rozdział pod tytułem Testowanie i Ewaluacja SarmataREST API skupia się na badaniu usługi pod kątem funkcjonalnym oraz wydajnościowym przy użyciuróżnych gramatyk oraz konfiguracji silnika Sarmata.
-
2. Przetwarzanie sygnałów w chmurze
Na przestrzeni ostatnich lat, paradygmat przetwarzania danych w chmurze stał się bardzo popularny
zarówno w środowiskach akademickich jak również komercyjnych. Chmura jest bardzo dogodnym roz-
wiązaniem dla dostarczycieli usług (platformy). Stała się bardzo popularna z uwagi na olbrzymią skalo-
walność rozwiązań opartych na chmurze obliczeniowej. Praktycznie nieograniczona moc obliczeniowa
oraz przestrzeń dyskowa sprzyja centralizacji rozwiązań związanych np. z multimediami. Szybkość prze-
twarzania multimediów (w ogólnym przypadku danych) jest niezależna od stacji klienckiej, zależy głów-
nie od możliwości serwera [2]. Dodatkowym faktem, który zachęca do przeniesienia usług IT do chmury
jest znaczna redukcja kosztów, szacowana średnio na 10-20% [3]. W tym rozdziale przybliżono tema-
tykę architektury oraz rozwiązań chmurowych ze szczególnym naciskiem na aspekty, które są szczegól-
nie użyteczne w przypadku systemów rozpoznawania mowy lub w ogólności – systemów bazują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 wygląda następująco [4]:
Def:
Przetwarzanie w chmurze jest modelem ogólnodostępnego, wygodnego udostępniania zasobów informa-
tycznych takich jak zasoby obliczeniowe, przepustowość sieci, magazyny danych, aplikacje etc. Model
charakteryzuje się funkcjami takimi jak:
• samoobsługa na żądanie• duża elastyczność• taryfikacja usług (ang. pay-as-you-use)• szeroki dostęp do sieci• implementacja puli zasobów
8
-
2.1. Modele usług chmury obliczeniowej 9
Przez ostatnie dekady umacniał się pogląd, iż przetwarzanie informacji (danych) może być realizo-
wane bardziej efektywnie przez scentralizowane zasoby, a następnie udostępniane przez Internet. Postęp
technologiczny w dziedzinie przesyłu danych jest odpowiedzialny za popularyzację najpierw modelu
grid computing (wczesne lata 90) a następnie cloud computing (początek XX wieku)[5]. Model chmu-
rowy jest obecnie stosowany przez największe firmy z branży IT takie jak Amazon, Apple, Google etc.
W niniejszym rozdziale zostanie przybliżona tematyka chmury obliczniowej (ang. cloud, cloud compu-
ting). Rozróżniamy trzy modele usług chmurowych serwowanych przez dostawców opisywanych usług.
Są to Software as a Service (SaaS), Platform as a Service (PaaS), Infrastructure as a Service (IaaS). Ze
względu na dostępność, możemy je podzielić z kolei na publiczne, prywatne, wspólnotowe (community)
oraz hybrydowe. Wspomnianą systematykę 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 sprzętowej. Może to być przestrzeń na wirtualnym
dysku internetowym przeznaczona do przechowywania danych albo też miejsce na serwerze wydzier-
żawione w celu wgrania tam własnego systemu operacyjnego. Do IaaS zalicza się także korzystanie z
mocy obliczeniowej procesorów [6]. Cechą charakterystyczną tego modelu jest optymalizacja kosztów
– konsument jest zobowiązany zapłacić za faktycznie zużytą moc serwerów [4].
Platforma jako usługaKolejną formą udostępniania chmury obliczeniowej jest model "Platforma jako usługa"(ang. Platform
as a Service). Model ten różni się od poprzedniego tym, iż oprócz elastycznej infrastruktury sprzętowej
udostępniana jest, także platforma aplikacyjna tj. np. System operacyjny, platforma programistyczna etc.
Podobnie jak w przypadku IaaS opłaty są proporcjonalne do zuż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 udostępniana za pomocą interfejsów klienckich takich jak przeglądarki internetowe
lub interfejsu programistycznego [4]. Usługi tego typu udostępniane są zwykle za pomocą internetu, na
życzenie [7]. W ramach tego modelu serwowane będą funkcje silnika ASR Sarmata 2.0, omawianego w
niniejszej pozycji.
-
2.2. Podłoże teoretyczne przetwarzania mowy 11
2.2. Podłoże teoretyczne przetwarzania mowy
Niniejszy rozdział opisuje teorię przydatną do zrozumienia zasady działania chmurowego serwisu
rozpoznającego mowę. W sekcji Automatyczne rozpoznawanie mowy (ang. Automatic Speech Reco-gnition, ASR) zawarto podstawowe zagadnienia związane z ASR takie jak modele akustyczne, modele
językowe, dekodowanie mowy oraz ewaluację systemów ASR.
2.2.1. Automatyczne rozpoznawanie mowy
Działanie systemów do rozpoznawania mowy można opisać jako wybór najbardziej prawdopodobnej
sekwencji Ŵ , biorąc pod uwagę zaobserwowane dowody akustyczne A [8]. Tak więc rozpoznawanie
mowy można opisać jako:
Ŵ = argW
maxP (W |A) (2.1)
Gdzie:
• Ŵ - najbardziej prawdopodobna sekwencja wyrazów• W - sekwencja wyrazów• A - sekwencja obserwacji• P (W |A) - funkcja prawdopodobieństwa warunkowego, określa najbardziej prawdopodobną se-
kwencję W przy założeniu wystąpienia obserwacji A
Z uwagi na fakt, iż bezpośrednie wyznaczenie prawdopodobieństwa P (W |A) jest niemożliwe, należyskorzystać z teorii prawdopodobieństwa Bayesa. Korzystając z ustaleń wspomnianej teorii, wzór 2.1
może być zapisany również jak we wzorze 2.2
Ŵ = argW
maxP (A|W ) ∗ P (W )
P (A)(2.2)
Gdzie:
• Ŵ - najbardziej prawdopodobna sekwencja wyrazów• W - sekwencja wyrazów• A - zbiór obserwacji• P (W ) - prawdopodobieństwo wystąpienia sekwencji W• P (A) - prawdopodobieństwo wystąpienia obserwacji A• P (W |A) - funkcja prawdopodobieństwa warunkowego, określa najbardziej prawdopodobną se-
kwencję W przy założeniu wystąpienia obserwacji A
Prawdopodobieństwo P (A|W ) jest nazywane modelem akustycznym oraz prawdopodobieństwoP (W ) mianuje się określeniem modelu językowego. Tym samym otrzymano równanie w którym po-
łączono zależnością modele akustyczny oraz językowy. Oba wymienione prawdopodobieństwa zostaną
dokładniej opisane w sekcjach Modele akustyczne oraz Modele językowe.
Modele akustyczne
Zadaniem modeli akustycznych P (A|W ) jest uwzględnienie wszystkich możliwych warunków aku-stycznych, takich jak np. wymowa, pogłos, warunki w kanale transmisyjnym czy hałas tła dla wszystkich
-
2.2. Podłoże teoretyczne przetwarzania mowy 12
możliwych powiązań W oraz A. Istnieje wiele różnych koncepcji modelowania akustycznego. Najczę-
ściej są 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
łańcuchem ukrytych modeli Markowa każdego słowa, które należy do rozpoznawanego słownictwa. Mo-
dele akustyczne słów są z kolei związkami modeli akustycznych bloków składowych słów np. fonemów.
W ogólności modele akustyczne są statystycznym odbiciem sygnału mowy na fonemy.
Modele językowe
Modele językowe P (W ) odgrywają ogromną rolę w rozpoznawaniu mowy - pozwalają określić
prawdopodobieństwo wystąpienia słowa lub sekwencji słów w1, . . . , wn [11]. Model językowy może
być opisany wzorem 2.3 [12]
P (W ) = P (w1, . . . , wn) =n∏
i=1
P (wi|w1, . . . , wi−1) (2.3)
Gdzie:
• P(W) - prawdopobieństwo wystąpenia sekwencji W• n - długość sekwencji wyrazów W• P (wi|w1, . . . , wi−1) - prawdopobieństwo wystąpienia i-tego wyrazu, przy założeniu wcześniej-
szego wystąpienia określonej sekwencji wyrazów w1, . . . , wi−1 o długości i-1.
Dobry model językowy powinien spełniać następujące wymagania [13]:
• musi pozwalać na stwierdzenie, czy dana sekwencja słów jest elementem wykorzystywanego ję-zyka, czy nie,
• uwzględniać wszystkie możliwe konstrukcje, które występują w języku (np. szyk słów),• wspierać w wyborze hipotezy nawet w przypadku, gdy model akustyczny nie daje całkowicie
prawidłowego rozpoznania jednostek akustycznych,
• powinien on skutkować możliwie najmniejszą złożonością obliczeniową procedur poszukiwaw-czych,
• model powinien mieć możliwość podejmowania decyzji w oparciu o ograniczony kontekst.
Współcześnie coraz większe znaczenie w rozpoznawaniu mowy zyskują głębokie sieci neuronowe
(ang. deep neural networks) [14]. Zarówno modele akustyczne oraz językowe, zrealizowane są za po-
mocą techniki głębokich sieci neuronowych. Granica pomiędzy modelami jest coraz mniej dostrzegalna,
czyli coraz trudniej oddzielić model akustyczny od językowego.
-
2.2. Podłoże teoretyczne przetwarzania mowy 13
2.2.2. Dekodowanie mowy
Dekodowanie mowy jest procesem odnajdywania najbardziej prawdopodobnej sekwencji wyrazów
Ŵ zgodnie ze wzorem 2.2. Jednym z algorytmów uż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 podejście do dekodowania zapewnia ograniczoną konsumpcję
pamięci operacyjnej.
2.2.3. Ewaluacja działania systemów ASR
Najbardziej powszechną metryką używaną do ewaluacji systemów ASR jest metryka WER (ang.
Word error rate). Określa ona procent błę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 zastąpionych względem frazy referencyjnej• D jest liczbą słów pominiętych względem frazy referencyjnej• I jest liczbą słów dodanych względem frazy referencyjnej• N jest liczbą słów w frazie referencyjnej
Drugą najczęściej używaną metryką określaną jako stosunek liczby poprawnie rozkodowanych zdań
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 zdań do całkowitej liczby testowanych hipotez• B jest liczbą błędnie rozpoznanych zdań• N jest liczbą wszystkich zdań
Inną metryką służącą pozwalającą ocenić systemy do rozpoznawania mowy jest metryka RTF (ang.
Real Time Factor), pozwalająca określić szybkość działania dekodera. RTF jest definiowany jako sto-
sunek potrzebnego do zdekodowania nagrania R, przez badany system, do czasu trwania nagrania R.
Można go opisać 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. Przegląd usług ASR 14
2.3. Przeglą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]. Rozwiązania dostarczane
przez AT&T, Microsoft, Amazon oraz Google są rozwiązaniami komercyjnymi. Przykładem darmowego
oprogramowania tego typu jest np. Sphinx-4 [16] oraz pakiet Kaldi. Poniżej przedstawiono opis wybra-
nych rozwiązań z zakresu rozpoznawania mowy dostępnych na rynku.
2.3.1. Rozwiązania komercyjne
Google Speech API
Rozwiązanie oferowane przez firmę Google opiera swoje działanie na głębokich sieciach neurono-
wych. Między innymi dzięki zastosowaniu tego rozwiązania w roku 2015 osiągnięto stopę błędu na
poziomie 8% [16]. Google Speech API wspiera 89 języków oraz ich dialektów. Umożliwia między in-
nymi rozpoznawanie fraz w czasie rzeczywistym oraz transkrypcję plików audio. Platforma udostępnia
funkcjonalności przez protokoły HTTP (REST) oraz RPC (gRPC).
Microsoft Cognitive Services
Microsoft rozwija rozwiązania z zakresu przetwarzania sygnału mowy od 1993 roku. Usługi po-
znawcze dostępne są poprzez chmurę Microsoft Azure. Obecnie firma udostępnia szereg usług służącym
przetwarzaniu ję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ównież trenowanie własnych modeli językowych oraz akustycznych (ang. Custom
Speech Service). Rozwiązanie umożliwia transkrypcję nagrań nie dłuższych niż 10 minut. Platforma
udostępnia funkcjonalność za pomocą API kompatybilnego z protokołami HTTP oraz WebSocket. Do-
datkowo dostępne są, także biblioteki umożliwiające implementację rozwiązań opartych o Speech API
na platformy .NET, Android oraz iOS.
2.3.2. Rozwiązania darmowe
CloudASR
CloudASR jest publiczną platformą programistyczną oraz serwisem internetowym umożliwiającym
rozpoznawanie mowy. Rozwiązanie opracowane zostało przez naukowców z Charles University w Cze-
chach.
Wedle autorów mocnymi stronami platformy są:
• skalowalność,• duże możliwości dostosowania do indywidualnych potrzeb,• łatwa przenośność rozwiązania.
CloudASR umożliwia transkrypcje całych nagrań (ang. batch speech recognizing) jak również trans-
krypcję strumieniowanych danych. Domyślnym zestawem narzędziowym wykorzystywanym przez opi-
-
2.3. Przegląd usług ASR 15
sywany produkt jest PyKaldi, czyli pakiet Kaldi zintegrowany z językiem python [17]. Należy jednak
zaznaczyć, że system jest dostosowany do kooperacji z dowolnym zestawem narzędziowym.
HTK
HTK jest zestawem narzędziowym umożliwiającym budowanie oraz modyfikację ukrytymi mode-
lami Markowa. W 1999 roku technologia została wykupiona przez firmę Microsoft a kod źródłowy został
częściowo zlicencjonowany - użytkownicy mogą używać HTK do trenowania modeli, jednak dekoder
(HDecoder) zaimplementowany w ramach pakietu jest udostępniany tylko do celów badawczych [18].
HTK składa się z zestawu modułów, które dostarczają rozwiązań ułatwiających analizę mowy, trenowa-
nie źródeł Markowa a także testowanie oraz analizę rezultatów [19]. Jest znany także pod nazwą 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 języku Java. Architektura rozwiązania dzieli bibliotekę na trzy części: frontend, de-
koder oraz część lingwistyczną [16]. Udostępniony przez instytucję kod zawiera implementacje oparte
na ekstrakcji cech MFCC (ang. Mel Frequency Cepstrum Coefficients), PLP (ang. Perceptual Linear
prediction) czy LPC (ang. Linear Predictive Codes ). Część lingwistyczna zawiera implementacje m.in.
modeli CFG (ang. Context-Free Grammar), FST (ang. Finite-State Transducers), N-gramowego etc.
[16]. Dostępny również w wersji przeznaczonej na platformy mobilne - PocketSphinx [20].
Kaldi
Kaldi jest darmowym zestawem narzędziowym umożliwiającym rozpoznawanie mowy. Jest on w
całości zaimplementowany w języku C++, jego kod źródłowy jest publiczny, dostępny w systemie za-
rządzania projektami typu Open Source. Framework Kaldi jest kompatybilny ze środowiskami UNIX-
owymi oraz Windows. Istnieje wiele nakładek integrujących Kaldi z innymi językami jak np. PyKaldi
[21], co znacznie poszerza grono użytkowników pakietu. System ten opiera się na teorii automatów
skończonych. Istnieją rozwiązania chmurowe oparte o pakiet Kaldi takie jak np. Kaldi GStreamer server,
będący publicznym serwerem zaimplementowanym w języku python, który umożliwia rozpoznawanie
mowy w czasie rzeczywistym lub opisany wyżej CloudASR.
-
3. Projekt systemu
W niniejszym rozdziale zostanie przedstawiony projekt aplikacji umożliwiającej rozpoznawanie
mowy polskiej z wykorzystaniem wybranej gramatyki.
3.1. Architektura rozwiązania
W inżynierii oprogramowania termin architektura oprogramowania oznacza abstrakcyjną reprezen-
tację systemu opisaną jako zbiór połączonych komponentów z pominięciem szczegółów implementacji
[22]. System może składać się z wielu poziomów abstrakcji i wielu faz działania, z których każda posiada
własną architekturę oprogramowania [23]. W dzisiejszych czasach powszechnym sposobem wymiany
danych są usługi internetowe (Web services). Najbardziej powszechnymi stylami architektonicznymi
są REST (Representational State Transfer Protocol ) oraz SOAP Simple Object Access Protocol [24].
Każdy z wymienionych stylów ma swoje mocne i słabe strony, tak więc istotnym zadaniem jest wybra-
nie odpowiedniego stylu, spełniającego wymagania projektowe w jak największym stopniu [25]. Można
w tym celu skorzystać z powszechnie przyjętych metryk ewaluacji oprogramowania. Wspomniane me-
tryki dzielą się na bezpośrednie, mierzalne metryki takie jak ilość błędów, kosztowność implementacji
oraz niemierzalne takie jak kompleksowość, prostota utrzymania etc. Najpopularniejsze rodzaje metryk
przedstawiono w tebeli 3.1.
Bezpośrednie Niebezpośrednie(mierzalne) (niemierzalne)
koszt dotyczy przodków (tj. rodziców danego węzła oraz
funkcjonalność)
wysiłek wykonawczy jakość
ilość linii kodu kompleksowość
szybkość działania efektywność
zapotrzebowanie na pamięć niezawodność
błędy prostota utrzymania
Tabela 3.1: Kategorie metryk oceny oprogramowania [26]
16
-
3.1. Architektura rozwiązania 17
REST (Representational State Transfer Protocol) jest to wzorzec architektury oprogramowania opi-sujący zasady, właściwości oraz ograniczenia, którymi należy się kierować przy projektowaniu nowo-
czesnych serwisów internetowych. Transmisja danych realizowana jest za pomocą protokołu HTTP. Nie
istnieją ograniczenia dotyczące formatu przesyłanych danych, jednak najczęściej są to JSON lub XML.
Serwisy internetowe oparte o omawianą architekturę wydają się być lekką alternatywą dla topornych
serwisów SOAP-owych [25]. Komunikację 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 są HTTP, SMTP, etc. Dane przesyłane są w formacie XML [28]. Ilość danych
przesyłanych serwisami opartymi o omawiany styl może powodować problemy wydajnościowe, ponie-
waż podczas formowania wiadomości dodawane są do niej dodatkowe nagłówki oraz metadane umiesz-
czane w ciele wiadomości. W odróżnieniu od standardu REST, protokół SOAP posiada zdefiniowany
model bezpieczeństwa [28]. Standard ten został opracowany i ustandaryzowany przez organizacje takie
jak W3C oraz OASIS [25].
Nawiązując do powyższego opisu stylów architektonicznych REST oraz SOAP, dokonano ich oceny
względem metryk ewaluacji oprogramowania przedstawionych w tabeli 3.1. Poniżej rezultaty rozważań:
• koszt: REST wykorzystuje prostą infrastrukturę technologiczną. Fakt ten implikuje redukcję kosz-tów potrzebnych do osiągnięcia tych samych efektów co przy użyciu SOAP [29]. Co więcej w
przypadku rozwiązań REST-owych istnieje możliwość kooperacji klienta z tworzonym serwisem
już we wczesnej fazie implementacji np. przy użyciu przeglądarki lub innych prostych aplikacji
klienckich jak np. Postman [30],
• wysiłek wykonawczy: W celu szeroko pojętej redukcji kosztów związanych z implementacją orazutrzymaniem serwisu zaleca się wybór rozwiązań REST-owych [26],
• ilość linii kodu: Porównując oba podejścia pod względem obszerności kodu gwarantującego tesame funkcjonalności, korzystniej prezentują się rozwiązania oparte na protokole SOAP [26],
• szybkość działania: Rozwiązania REST-owe prezentują się dużo lepiej w kontekście szybkościdziałania (mniejsze czasy odpowiedzi oraz większa przepustowość danych [25]. Rysunek 3.1
-
3.1. Architektura rozwiązania 18
Rys. 3.1: Czasy odpowiedzi dla serwisu internetowego wykonanego według stylu architektonicznegoREST oraz SOAP (źródło [27])
• zapotrzebowanie na pamięć: tworzenie żądania SOAP trwa nawet 10 razy dłużej oraz potrzebuje 8razy więcej pamięci w porównaniu z natywnym żądaniem HTTP [31] Jest to powiązane z mniej-
szym narzutem obliczeniowym po stronie REST wynikającym z braku konieczności dodatkowego
opakowania zleceń (koperta SOAP) oraz przetwarzania dokumentów XML [32],
• błędy: SOAP posiada wbudowany mechanizm obsługi błędów [25]. Tak więc pod tym względemprezentuje się lepiej,
• funkcjonalność: REST jest bardziej odpowiednim wzorcem w przypadku komunikacji punkt-punkt (point-to-point) [25],
• efektywność: protokół HTTP opisuje mechanizmy buforowania (ang. caching) oraz równoważeniaobciążenia (ang. load balancing). Co więcej REST używa formatu JSON (lub nawet prostego
tekstu ang. plain text), który zajmuje mniej miejsca niż XML. Oba przytoczone fakty sprawiają, iż
serwisy internetowe bazujące na standardzie REST, jako oparte bezpośrednio na protokole HTTP
są bardziej efektywne [25],
• prostota utrzymania: Łatwiej utrzymywać rozwiązania REST-owe [26].
-
3.2. Podsumowanie 19
Podsumowując rozważania na temat stylów architektonicznych REST oraz SOAP należy stwierdzić, iż:
RESTJest bardziej odpowiednim wyborem w sytuacji, gdy nacisk położony jest zwłaszcza na wydajność
aplikacji, szybkość jej działania oraz oszczędność zasobów.
SOAPJest lepszym rozwiązaniem, gdy realizowany projekt wymaga większego bezpieczeństwa, mniej-
szej ilości błędów. Dodatkową zaletą protokołu SOAP jest łatwa w utrzymaniu strona kliencka (w
razie zmian interface’u użytkownika wystarczy plik WSDL, aby wygenerować kod kliencki) [25].
Mając na uwadze powyż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 być aplikacja serwerowa umożliwiająca rozpoznawanie
mowy polskiej w czasie rzeczywistym. Powinna istnieć również możliwość wyboru dogodnej grama-
tyki zapisanej w bazie danych oraz dodawania nowych gramatyk. Wszystkie funkcjonalności powinny
zostać opisane w stosownej dokumentacji [33]. Rozwiązanie wykonane będzie w języku Java z wyko-
rzystaniem wielowarstwowego szkieletu aplikacji Spring. Głównym powodem, dla którego dokonano
wyboru tej technologii, są bardzo dobre właściwości wydajnościowe, dojrzałość technologii oraz testo-
walność kodu. Zagadnienie testowalności kodu jest kluczowe z punktu widzenia poprawności działania
systemu, ale także satysfakcji klienta końcowego. Odpowiednia struktura aplikacji znacznie ułatwia au-
tomatyczne testowanie, zmniejszając ilość błędów i pozwalając na szybszą reakcję na zmianę wymagań
[34].
-
4. Implementacja systemu
4.1. Wykorzystane narzędzia oraz biblioteki
Swagger (OpenAPI Specification) jest to framework służący do opisu, tworzenia, wizualizacji oraztestowania serwisów internetowych opartych o styl architektoniczny REST. Nadrzędnym celem pro-
gramu jest zapewnienie synchronizacji dokumentacji systemu oraz samego systemu. Jest to możliwe
z uwagi na fakt, iż dokumentacja metod, parametrów oraz modeli może być zintegrowana z kodem
aplikacji. Dużą zaletą narzędzia jest zdolność do generacji kodu klienckiego oraz serwera w oparciu o
stworzoną dokumentację i zawarte w niej kontrakty [35].
Apache JMeter jest aplikacją napisaną w języku Java, stworzoną w celu przeprowadzania testówobciążeniowych oraz mierzenia wydajności aplikacji bazodanowych, internetowych oraz wykorzystują-
cych protokoły wymiany danych takie jak TCP, FTP, SMTP etc. [36]. JMeter umożliwia dużą parame-
tryzację testów, walidowanie odpowiedzi serwisów (aplikacji) oraz szeroką gamę możliwych do wyge-
nerowania raportów z przebiegu badań wydajnościowych. Narzędzie zostało użyte do badania jakości
zaimplementowanego serwisu internetowego. W rozdziale Testowanie i Ewaluacja Sarmata RESTAPI zawarto kilka raportów z przebiegu badań [36]. Aplikacja wykorzystana została do generowaniaruchu internetowego, generowania raportów oraz wykresów ilustrujących responsywność oraz skutecz-
ność działania systemu. Podczas wykonywania testów wykorzystano następujące grupy komponentów
Jmeter:
• Miscellaneous Features - grupa komponentów służą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 środowiska testowego.
• Samplers - grupa komponentów zawierające obiekty pozwalające na definiowanie żądań klienc-kich oraz pośrednio ich walidację
• Listeners - komponenty umożliwiające obserwacje, zapis oraz odczyt rezultatów testów. Częśćkomponentów udostępnia mechanizmy walidacji oraz agregacji zwalidowanych wyników ewalu-
acji.
• Configuration elements - komponenty umożliwiające konfigurację zapytań. Podczas testów apli-kacji bardzo użyteczne okazały się elementy HTTP Cookie Manager, HTTP Header Manager,
Random Variable, Counter.
• Assertions - elementy pozwalające na dowolnie określone walidowanie odpowiedzi serwera. W
20
-
4.1. Wykorzystane narzędzia oraz biblioteki 21
przypadku popełnionych testów użyto dodatku JSON Path Assertion m.in. do weryfikowania po-
prawności odpowiedzi na podstawie zawartości odpowiedzi
• Times komponenty z tej grupy są procesowane każdorazowo przed wysyłką określonych żądań. Napotrzeby testów użyto elementu Gaussian Random Timer w celu dokładniejszego odwzorowania
naturalnego środowiska użytkowego dla implementowanego serwisu
• Pre Processors elementy używane do modyfikacji żądań. Szczególnie użytecznym obiektem tejgrupy okazał się BeanShell PreProcessor, który umożliwia definiowanie własnych skryptów mo-
dyfikują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 pozwalające na parsowanie odebranych odpowiedzi. Podczas ewaluacjiaplikacji wykorzystano obiekty JSON Extractor oraz BeanShell PostProcessor należące do tej
grupy, w celu ekstrakcji informacji na temat prawdopodobieństwa poprawności rozpoznanych fraz
oraz ich zapisu do pliku.
Ngnix jest serwerem HTTP wydanym na licencji BSD cechującym się bardzo wysoką wydajnością[37]. Jest również 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 rozwiązanie,
co plasuje nginx na trzecim miejscu w rankingu wykorzystywania serwerów WWW [38]. W omawia-
nym systemie serwer nginx wykorzystywany jest do równoważenia obciążenia węzłów REST API. W
tym kontekście zostanie bardziej szczegółowo opisany. Równoważenie obciążenia w systemach złożo-
nych z wielu instancji aplikacji jest powszechnie używaną techniką optymalizującą m.in. wykorzystanie
zasobów, maksymalizację przepustowości oraz ograniczenie opóźnienia. Nginx obsługuje następujące
metody równoważenia [39]:
• Round-robin - żądania serwerów aplikacji są rozprowadzane w zgodnie z algorytmem karuzelo-wym
• Least-connected - kolejne żądania są przekazywane do instancji z najmniejszą liczbą aktywnychpołączeń
• Ip-hash - funkcja skrótu używana jest do określenia, jaki serwer powinien być wybrany dla na-stępnego żądania. Funkcja skrótu jest wyliczana na podstawie adresu IP klienta.
Domyślna konfiguracja serwera dla potrzeb równoważenia obciążenia wygląda jak na listingu 4.1. W
ramach niniejszej pracy przebadano wpływ algorytmu równoważenia obciążenia na jakość serwowanych
usług. Wyniki zostały przedstawione w kolejnym rozdziale.
-
4.1. Wykorzystane narzędzia oraz biblioteki 22
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: Domyślna konfiguracja ’load-balancera’ nginx
Spring Framework jest wszechstronnym szkieletem wydanym na licencji Apache 2.0 license [40]mającym na celu uproszczenie rozwoju aplikacji typu Enterptise. Oprogramowanie realizuje ten cel
dzięki relatywnie prostemu oraz konsystentnemu API opakowując w warstwę abstrakcji kompleksowy
kod niezbędny do tworzenia aplikacji typu Enterprise. Projekt rozwijany jest od 2002 roku [41]. Spring
cechuje się modularną architekturą, w której moduły podzielone są na grupy wyższego rzędu, dalej
zwane strefami funkcjonalnymi. Istnieje 8 podstawowych stref funkcjonalnych tj. [42]:
• Core Container - dostarcza podstawowych funkcjonalności szkieletu. Kontener jest odpowie-dzialny m.in. za takie funkcjonalności Spring’a jak odwrócenie sterowania (ang. Inversion of Con-
trol, IoC) wstrzykiwanie zależności (ang. Dependency Injection, DI) czy kontekst aplikacji (ang.
application context).
• Aspect-Oriented Programming (AOP) oraz Aspects - strefy te zawierają zestaw rozwiązań wspie-rających paradygmat programowania aspektowego tj. separację zagadnień oraz możliwość zmiany
zachowania istniejącego kodu źródłowego bez jego modyfikacji. Aspekty okazały się bardzo po-
mocne na etapie diagnozy i usuwania błędów aplikacji (ang. debugging). AOP usprawniło, także
proces dodania warstwy rejestracji zdarzeń w systemie (ang. logging) przydatnej następnie na eta-
pie ewaluacji systemu.
• Messaging - dostarcza warstwę abstrakcji dla aplikacji typu message-based• Data Access/Integration - jest to warstwa dostarczająca rozwiązań z zakresu mapowania
obiektowo-relacyjnego, integracji z bazami danych oraz z systemami umożliwiającymi asynchro-
niczne przesyłanie komunikatów
• Web - zawiera implementację modułów służących np. do budowania aplikacji oraz serwisów in-ternetowych opartych o architekturę model-view-controler (MVC) oraz REST
• Instrumentation - zawiera implementacje infrastruktury ładującej używane biblioteki (ang. clas-sloader)
• Test - dostarcza rozwiązania usprawniające testy jednostkowe oraz integracyjne tworzonych kom-ponentów
Wspomniany podział ilustruje rysunek 4.1
-
4.1. Wykorzystane narzędzia oraz biblioteki 23
Rys. 4.1: Diagram blokowy ilustrujący podział na strefy funkcjonalne szkieletu aplikacji Spring (źródło[42]).
SQLite jest to wbudowana, relacyjna bazą danych. Produkt wraz z kodem źródłowy jest udostęp-niany w ramach licencji Public domain [43]. Cechą charakterystyczną bazy SQLite jest jej kompakto-
wość - baza (tj. sama aplikacja, nie wliczając zgromadzonych danych) przechowywana jest w jednym
pliku, którego rozmiar nie przekracza 0,5MB [44]. Do najważniejszych właściwości bazy należą:
• mobilność między-platformowa - można bazę danych (tj. plik) przenieść pomiędzy architekturamifizycznymi (np. architektura 32 oraz 64 bitowa) oraz logicznymi (np. big-endian oraz little-endian)
bez żadnej straty informacji,
• kompaktowość - jeden plik, małych rozmiarów,• łatwość użycia - nie jest wymagana żadna konfiguracja SQLite,• niezawodność - gwarantuje własności ACID [45] dla transakcji, nawet w przypadku awarii sys-
temu na którym baza się znajduje.
Baza SQLite wykorzystywana jest przez np. Apple iTunes, Android [46]. Opisywana baza została wy-
brana jako baza docelowa ze względu na niewielkie rozmiary, przenośność oraz brak konieczności kon-
figurowania.
Redis (ang. REmote DIctionary Server) jest to nierelacyjna baza danych rezydująca natywnie wpamięci RAM (ang. in-memory database). Kod źródłowy aplikacji udostępniony jest na licencji BSD
(Berkeley Software Distribution License). Redis jest magazynem rekordów typu klucz-wartość używa-
nym jako baza danych, cache oraz broker wiadomości [47]. Należy jednak zaznaczyć, że wartościami
słownikowymi mogą tutaj być kompleksowe obiekty w postaci ciągu bajtów. Dodatkowo, struktura bazy
danych może być tworzona przy użyciu struktur danych takich jak:
• lista (ang. list) czyli sekwencje uporządkowanych wartości. Możliwe jest dodawanie elementówna początku i koń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 użyt-kownika. Zdefiniowana grama-tyka zostanie zapisana w pa-mięci trwałej i jest przypisana dokonkretnego uż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 umożliwiająca przypisywanie danych słownikowych (klucz-wartość)jako wartość wyższego klucza,
• krotka (ang. set) czyli sekwencja unikalnych wartości. Przy pomocy ktorek możliwe jest tworzenieunii, iloczynów kartezjańskich etc.. Istnieją dwie postaci krotki tj. posortowana (ang. sorted set)
oraz nieuporządkowana [48].
Baza danych Redis została wykorzystana w implementowanym systemie jako magazyn sesji klienckich.
Oprócz wyszczególnionych wyżej rozwiązań, podczas realizacji celów określonych na początku
pracy magisterskiej skorzystano także z biblioteki RestAssured oraz cURL. Obie biblioteki posłużyły do
badania serwisu internetowego. Dodatkowo w celach badawczych zaimplementowano aplikację kliencką
w języku python, umożliwiającą testowanie usługi Sarmata REST API.
4.2. Opis implementacji
Opisywany serwis rozszerza funkcjonalność serwowaną przez silnik Sarmata o kolejny interface. Do
chwili obecnej komunikacja z silnikiem odbywała się w ramach interfejsu gRPC, który jest szczególnym
wariantem protokołu RPC udostępnionym przez firmę Google [49]. Porównanie interface gRPC oraz
REST silnika Sarmata przedstawiono w tabeli 4.1.
Aplikacja serwerowa Moduł napisany w całości od podstaw w architekturze MVC (Model-View-Controller) z wykorzystaniem szkieletu aplikacyjnego Spring. Aplikacja udostępnia trzy rodzaje punk-
tów końcowych tj. grammar, init, recognize, które odpowiadają wszystkim publicznie udostępnionym
metodom silnika Sarmata. Implementując program starano się zachować wszelkie zasady określane mia-
nem dobrych praktyk programistycznych. Aplikacja wykorzystuje szablony takie jak szablon dostępu
danych, autoryzacji i uwierzytelniania oraz obsługi testowania. Opisywany moduł posiada zaimplemen-
towany prosty mechanizm równoważenia obciążenia. Zrezygnowano równocześnie z zastosowania do
tych celów dedykowanego rozwiązania takiego jak aplikacja nginx. Z uwagi na fakt, iż udostępniona
na potrzeby realizacji projektu wersja serwera Sarmata pozwala na równoczesne połączenie 5 klientów,
dodatkowe rozwiązania nie są wymagane. Należy zaznaczyć, że pomimo ograniczonej ilości klientów
-
4.2. Opis implementacji 25
można dowolnie modyfikować ilość uruchomionych instancji serwera przez co rozwiązanie staje się
skalowalne. W ramach realizacji niniejszej pracy opracowano, także mechanizm zdalnego przydzielania
zasobów - w tym przypadku instancji silnika Sarmata.
Klient gRPC Komunikacja pomiędzy opisaną w poprzednim paragrafie aplikacją a silnikiem ASRodbywa się za pośrednictwem protokołu gRPC. Diagram 4.2 ilustruje sekwencje zdarzeń powielanych
podczas obsługi klienta. Klient gRPC określony jest jako REST Serwer.
Rys. 4.2: Diagram sekwencji ilustrujący sposób komunikacji asynchronicznej w opracowanym systemie[50]
Klient REST Do celów testowych opracowano również aplikacje kliencką, która umożliwia wery-fikacje poprawnego działania serwisu. Aplikacje zaimplementowana jest w technologiach python oraz
Java.
Podczas opracowywania rozwiązania bardzo dużą rolę odegrały, także nie wspomniane wcześniej
narzędzia takie jak Wireshark oraz JProfiler, które pozwoliły na relatywnie szybkie znalezienie powodów
występujących usterek. Rysunek 4.3 przedstawia wymianę wiadomości zaimplementowanego serwera z
serwerem Sarmata. Warto zwrócić uwagę, iż komunikacja następuje poprzez protokół HTTP/2.0 a nie
HTTP/1.1 w odróżnieniu do większości przypadków [51].
-
4.2. Opis implementacji 26
Rys. 4.3: Przykładowy zrzut ekranu ilustrujący wymianę wiadomości pomiędzy zaimplementowanąfasadą a silnikiem ASR
-
5. Testowanie i Ewaluacja Sarmata REST API
Celem projektu było stworzenie systemu umożliwiającego rozpoznawanie mowy polskiej w cza-
sie rzeczywistym. Na implementowany system ASR składa się kilka elementów tj. klient internetowy,
fasada REST-owa oraz silnik ASR Sarmata. Przeprowadzone testy rozwiązania miały charakter czarno-
skrzynkowy (ang. black box tests) z uwagi na fakt, iż nie odnosiły się do wewnętrznej struktury systemu.
W poprzedzających rozdziałach przybliżone zostały podstawy teoretyczne użyteczne podczas imple-
mentowania systemu. Niniejszy rozdział zawiera opis przeprowadzonych działań pozwalających doko-
nać ewaluacji stworzonego rozwiązania. Zostały w nim zawarte, także wyniki przeprowadzonych testów
aplikacji.
5.1. Przykład użycia API
Zaimplementowany system jest systemem czasu rzeczywistego (ang. Real Time System, RTS). Sys-
tem czasu rzeczywistego to system w którym obliczenia prowadzone są równolegle z przebiegiem ze-
wnętrznego procesu [52]. API wspiera dwa tryby kooperacji z systemem
• tryb wsadowy (ang. batch mode)• tryb czasu rzeczywistegoW trybie wsadowym użytkownicy komunikują się z systemem za pomocą metody POST protokołu
HTTP. Odpowiedzią na zapytanie są dane w notacji JSON zawierające wynik transkrypcji. Pełna komu-
nikacja w tym trybie wymaga wysłania dwóch zapytań typu POST. Pierwsze zapytanie służy definicji
używanej gramatyki. Kolejne zapytanie zawiera treść przewidzianą do transkrypcji. Interface zaimple-
mentowanego serwisu wzorowany jest na rozwią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 użyciu biblioteki sieciowej curl
27
-
5.1. Przykład użycia API 28
Przykładową odpowiedź 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 odpowiedź serwisu
API udostępnia także tryb czasu rzeczywistego. W trybie tym użytkownicy wysyłają dźwięku w
wielu kawałkach za pośrednictwem metody POST protokołu HTTP. Z uwagi na fakt, iż 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 dotyczące użycia systemu znajdują się na stronie [33] gdzie znajduje się
oficjalna dokumentacja systemu.
-
5.2. Środowisko testowe 29
System operacyjny Ubuntu 5.4.0, 64bitProcesor Intel Xeon E5-2650 (2.0 GHz, 8 rdzenie, 64bit)Pamięć 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 środowiska testowego
System operacyjny Windows 7 Enterprice, 64bitProcesor Intel i7-6820HQ (2.7 GHz, 8 rdzenie, 64bit)Pamięć 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 środowiska testowego
5.2. Środowisko testowe
Testy zrealizowanego projektu zostały przeprowadzone w środowisku heterogenicznym złożonym z
dwóch maszyn fizycznych. Specyfikację obu wymienionych środowisk przedstawiają tabele 5.1 oraz 5.2.
Instancje silnika Sarmata są uruchomione na zdalnej maszynie phoneme. Na maszynie lokalnej znaj-
dują się pozostałe elementy infrastruktury testowej wymienione poniżej:
• Klient HTTP - aplikacja umożliwiająca wykonywanie oraz walidację zapytań oraz odpowiedziserwisu
• Fasada REST-owa udostępniająca usługi poprzez protokół HTTP.• Moduł gRPC umożliwiający komunikację pomiędzy fasadą a silnikiem Sarmata
5.3. Dane testowe
Na potrzeby testów wykorzystano próbki nagrań oraz gramatyki udostę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 dźwiękowe próbkowane
z częstotliwością 16000 Hz zapisane w formacie .wav. Do celów testowych wykorzystano nagrania z
grupy o roboczych nazwach AGHdigits oraz AGHstreets. Grupy zawierają kolejno 93 oraz 2003 różne
nagrania. Średni rozmiar dla plików z zestawów AGHstreets oraz AGHdigits to kolejno 81 KB oraz 138
KB z czego wynika, iż średni czas trwania próbek z wymienionych zestawów to 2.54 s oraz 4.32 s.
Średnie czasy trwania nagrań oszacowano przy użyciu wzoru 5.1. Dane podsumowuje tabela 5.3.
Podczas testowania aplikacji z całościowym wykorzystaniem dostarczonych zestawów nagrań użyto
tej samej konfiguracji silnika ASR. Parametry wspomnianej konfiguracji przedstawiono w tabeli 5.4.
-
5.3. Dane testowe 30
Nazwa zestawu AGHstreets AGHdigits
Ilość nagrań testowych 2003 93Format danych w nagraniach wav wavCzęstotliwość próbkowania [Hz] 16000 16000Liczba bitów przypadająca 16 16na próbkęSposób zapisu mono monoŚredni rozmiar pliku [KB] 81 138Średni czas trwania próbki [s] 2.539 4.32
Tabela 5.3: Dane dotyczące użytych podczas ewaluacji zestawów testowych
Nazwa Parametru Wartość
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 użyte do konfiguracji silnika ASR
Scenariusze testowe
Dla każ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
uż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 użytkownik
przesyła kawałki binarne o wielkościach 2048 bajtów dodając równocześnie opóźnienie wraz z dewia-
cją pomiędzy wysyłką kolejnych pakietów. Miało to na celu bardziej dokładne odwzorowanie działania
systemu w środowisku produkcyjnym (tj. symulacja opóźnień transmisji etc.). Wartości opóźnienia oraz
dewiacji zostały ustalone pośrednio przy użyciu wzoru 5.1 oraz biorąc pod uwagę, iż dane binarne wy-
syłane są w kawałkach o wielkości 2048 bajtów, częstotliwość próbkowania nagrań wynosi 16000 Hz,
ilość bitów przypadających na próbkę sygnału wynosi 16.
BR = SR ∗BD ∗ CH (5.1)
Gdzie:
• BR - ilość bitów w jednostce czasu, podawany w kilobitach na sekundę (ang. kilobit per second,kbps)
• SR - częstotliwość próbkowania sygnału, podawany w Hz• BD - ilość bitów przypadająca na jedną próbkę sygnału
-
5.4. Badanie aspektów jakościowych serwisu 31
• CH - ilość kanałów
Podstawiając dane do wzoru otrzymano informację, iż 1 sekunda nagrania ma rozmiar 32 KB. Stąd
nagrywając dźwięk i strumieniując go w czasie rzeczywistym paczka 2048 bajtów jest wysyłana w przy-
bliżeniu co 62 ms.
Badania zachowania systemu przeprowadzono w konfiguracjach testowych przedstawionych w tabeli
5.5. W dalszej części pracy zostaną zaprezentowane wybrane wyniki badań.
Ilość Ramp-up time [s] Dewiacja [ms] Stałeużytkowników opóź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 dotyczące użytych podczas ewaluacji zestawów testowych
Osobnym scenariuszem testowym było badanie zachowania samego silnika Sarmata za pośrednic-
twem fasady REST-owej. W tym celu przeprowadzono test obciążeniowy uwzględniający relatywnie
niewielką liczbę użytkowników przy wykorzystaniu wyselekcjonowanych nagrań. W tym przypadku
zmianie podlegały parametry testowe użyte do konfiguracji silnika ASR. Badano nie tylko wpływ konfi-
guracji na szybkość działania serwisu, ale również na pewność rozpoznania transkrybowanych fraz.
Każdy z opisanych w niniejszym paragrafie przypadków testowych został przeprowadzony kilku-
krotnie, w takich samych warunkach. Zaprezentowane w dalszej części pracy wyniki, są wynikami su-
marycznymi.
5.4. Badanie aspektów jakościowych serwisu
5.4.1. Badanie systemu ASR
W niniejszym rozdziale przedstawione zostaną opracowane wyniki badań systemu ASR. Są to staty-
stycznie ujęte wyniki testów funkcjonalnych systemu. Wyniki badań oparte są na 100 iteracjach testów.
Dane testowe zostały opisane wyżej. Rezultaty badań przedstawiono w tabeli 5.6.
-
5.4. Badanie aspektów jakościowych serwisu 32
Zestaw nagrań AGHdigits AGHstreets
Maksymalna pewność 77,1 81,9rozpoznania [%]
Uśredniona pewność 61,9 65,6rozpoznania [%]
Mediana pewności 65,2 67,4rozpoznania [%]
Brak rozpoznania [%] 17,6 6
Tabela 5.6: Uśrednione rezultaty transkrypcji nagrań testowych
Przedstawione powyżej wyniki wskazują na dobrą skuteczność rozpoznawania systemu. Niepoko-
jące może wydawać się wysoki wskaźnik przypadków, w których operacja transkrypcji zwróciła brak
rezultatów, dla zestawu nagrań AGHdigits. Brak jednak informacji na temat nominalnej skuteczności
systemu Sarmata w kontekście testowanych nagrań. Najlepiej rozpoznawaną sekwencją wyrazów z ze-
stawy nagrań AGHstreets jest sekwencja "Michała Lenartowicza". Pewność rozpoznania fraz wynosi w
tym przypadku niespełna 81,9 %. W przypadku zestawu danych AGHdigits, najbardziej rozpoznawalną
cyfrą jest "0". Pewność rozpoznawania cyfry "0"wynosi średnio 77,1 %.
-
5.4. Badanie aspektów jakościowych serwisu 33
5.4.2. Testy wydajnościowe
Niniejszy rozdział przedstawia wyniki testów obciążeniowych systemu. Uwzględnione w niniejszej
pracy przypadki testowe zostały tak dobrane, aby móc przeprowadzić testy badające możliwie szeroko
jakość działania systemu. Przypadki testowe o numerach 1, 2, 3, 4, oraz 7 można zaliczyć do kategorii
systemów stresowych (ang. stress test) [53]. Przypadek testowy numer 8 pozwala na przeprwadzenie
testów typu Soak. Są to testy, w których system poddawany jest zakładanemu, typowemu w warunkach
produkcyjnych obciążeniu przez dłuższy okres czasu [54]. Pozostałe przypadki tj. przypadek numer 5
oraz 6 są testami obciążeniowymi typu (ang. load testing). Statystyczne opracowanie wyników testów
zawiera następujące metryki:
• średni czas transkrypcji,• maksymalny czas transkrypcji,• mediana czasu transkrypcji,• metryka 90% - określa czas przetwarzania nagrań, który nie przekracza 90% wysyłanych żądań
transkrypcji,
• metryka 95% - określa czas przetwarzania nagrań, który nie przekracza 95% wysyłanych żądańtranskrypcji,
• błąd przetwarzania - procentowy udział błędów transkrypcji (w tym brak rozpoznania żadnej frazyoraz błędy serwera).
Zestaw 1 - AGHstreets
W poniższej tabeli 5.8 zaprezentowano statystyczne wyniki testów przeprowadzonych dla zestawu
nagrań numer 1.
Przypadkitestowe
1 2 3 4 5 6 7 8
Ś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łąd przetwarzania [%] 10 34 26 16 7,74 5,6 72,4 -
Tabela 5.8: Statystycznie wyliczone wartości czasów transkrypcji dla poszczególnych przypadków te-stowych dla zestawu danych AGHstreets.
-
5.4. Badanie aspektów jakościowych serwisu 34
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
Ś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łąd przetwarzania [%] 15 46 26 49 67,33 29 91,6 46,79
Tabela 5.10: Statystycznie wyliczone wartości czasów transkrypcji dla poszczególnych przypadkówtestowych dla zestawu danych AGHdigits.
Rysunki 5.1 oraz 5.2 są zbiorczymi wynikami testów przeprowadzonych przy użyciu narzędzia Jme-
ter. Analizując rysunek 5.2 można dostrzec, iż responsywność serwisu jest największa na początku
trwania testu - sekwencyjne uruchamianie kolejnych użytkowników niepowoduje drastycznego wzro-
stu czasu procesowania żądań. Wskazuje na to rysunek 5.3 a dokładniej część wykresu ilustrująca, iż
dla 20 klientów pracujących jednocześnie czasy transkrypcji wynoszą około 3 sekund. Czasy proce-
sowania dla mniejszej ilości wątków są nawet 3 krotnie wyższe niż dla większej ilości wątków. Fakt
ten może wskazywać, na problemy wydajnościowe (lub/i logiczne) algorytmu równoważenia obciążenia
oraz przydzielania zasobów serwera. Współczynnik RTF, opisany we wstępie teoretycznym, wynosi w
tym przypadku RTF = 2, 91 co jest wartością 3 krotnie wyższą w porównaniu do wartości pożądanej.
Mediana oraz średni czas transkrypcji nagrań są równe kolejno 7,4 s. oraz 7,3 s
Rys. 5.1: Zagregowane czasy realizacji operacji transkrypcji dla 20 użytkowników uruchomionych wczasie 1 sekundy. Zestaw testowy AGHdigits. Przypadek testowy 1.
-
5.4. Badanie aspektów jakościowych serwisu 35
Rys. 5.2: Wykres ilustrujący zależność czasu odpowiedzi od ilości aktywnych użytkowników serwisu.Zestaw testowy AGHdigits. Przypadek testowy 1.
Badanie zachowania systemu dla 50 użytkowników uruchomionych w ciągu 5 sekund pozwala wy-
snuć podobne wnioski co w przypadku testowym numer 1. Algorytm równoważenia obciążenia pracuje
niestabilnie - stąd wahania czasów odpowiedzi na żą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 wątki zostały wystartowane a część z nich zakończyła już swoje działanie. Szczytowe
obciążenie aplikacji to 41 równoległych użytkowników. Mediana oraz średni czas transkrypcji nagrań są
równe kolejno 8,6 s oraz 7,3 s.
Rys. 5.3: Wykres ilustrujący zależność czasu trwania transkrypcji od czasu. Zestaw danych AGHdigits.Przypadek testowy 2.
-
5.4. Badanie aspektów jakościowych serwisu 36
Rys. 5.4: Zagregowane czasy realizacji operacji transkrypcji dla 50 użytkowników uruchomionych wczasie 5 sekund. Zestaw testowy AGHdigits. Przypadek testowy 2.
Rys. 5.5: Wykres ilustrujący zależność czasu odpowiedzi od ilości aktywnych użytkowników serwisu.Zestaw testowy AGHdigits. Przypadek testowy 2.
Z wykresu 5.6 wynika, iż czas oczekiwania na transkrypcje w teście dla przypadku testowego numer
3 wzrasta w początkowej fazie testów. Na podstawie rysunku 5.8 można stwierdzić, iż maksymalne
obciążenie serwera to 27 równoczesnych sesji klienckich. Średni czas realizacji żądań klienckich dla
tego przypadku testowego wynosi w przybliżeniu 6,5 sekundy. Uwzględniając średnią długość nagrań
użytych podczas testów można określić współczynnik RTF . Wynosi on w tym przypadku 2.5. Wynik
podano z dokładnością do jednego miejsca po przecinku.
-
5.4. Badanie aspektów jakościowych serwisu 37
Rys. 5.6: Wykres ilustrujący zależność czasu trwania transkrypcji od czasu. Zestaw danych AGHdigits.Przypadek testowy 3
Rys. 5.7: Zagregowane czasy realizacji operacji transkrypcji dla 100 użytkowników uruchomionych wczasie 20 sekund. Zestaw testowy AGHdigits. Przypadek testowy 3.
-
5.4. Badanie aspektów jakościowych serwisu 38
Rys. 5.8: Wykres ilustrujący zależność czasu odpowiedzi od ilości aktywnych użytkowników serwisu.Zestaw testowy AGHdigits. Przypadek testowy 3.
Zilustrowane rezultaty przypadku testowego numer 4 przedstawiono na rysunkach 5.9, 5.10. Ana-
lizowany przypadek pozwala przeanalizować zachowanie systemu w sytuacji kilkusekundowego obcią-
żenia kilkudziesięcioma użytkownikami. W 50 sekundzie testu czasy przetwarzania żądań drastycznie
wzrastają. Możne to sugerować osiągnięcie pewnej wartości progowej ilości użytkowników. Powyżej tej
wartości responsywność maleje ponad czterokrotnie. Średni czas przetwarzania żądań oraz ich mediana
w tym przypadku wynoszą w przybliżeniu 7,9 sekundy oraz 10,1 s.
Rys. 5.9: Wykres ilustrujący zależność czasu trwania transkrypcji od czasu. Zestaw danych AGHdigits.Przypadek testowy 4.
-
5.4. Badanie aspektów jakościowych serwisu 39
Rys. 5.10: Zagregowane czasy realizacji operacji transkrypcji dla 150 użytkowników uruchomionych wczasie 40 sekund. Zestaw testowy AGHdigits. Przypadek testowy 4.
Poniżej znajdują się trzy wykresy przedstawiające zachowanie się systemu dla ruchu generowanego
przez 150 użytkowników w warunkach zbliżonych do produkcyjnych. Średni czas realizacji operacji
transkrypcji nagrania wynosi w tym przypadku 2.8 sekundy, co sprawia, iż 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 obciążenia systemu. Analizując wy-
kres ?? oraz biorąc pod uwagę specyfikę omawianego przypadku testowego (150 użytkowników urucho-mionych w czasie 90 sekund) można spekulować, iż w przypadku równomiernego obciążenia systemu,
ilością klientów nie większą niż 10, system jest w stanie przetwarzać żądania o transkrypcję w czasie
niemal rzeczywistym. Z tabeli 5.10 można odczytać, iż błąd przetwarzania dla omawianego przypadku
testowego (numer 5) wynosi 7,74 %.
Rys. 5.11: Wykres ilustrujący zależność czasu trwania transkrypcji od czasu. Zestaw danych AGHdigits.Przypadek testowy 5.
-
5.4. Badanie aspektów jakościowych serwisu 40
Rys. 5.12: Zagregowane czasy realizacji operacji transkrypcji dla 150 użytkowników uruchomionych wczasie 90 sekund. Zestaw testowy AGHdigits. Przypadek testowy 5.
Rys. 5.13: Wykres ilustrujący zależność czasu odpowiedzi od ilości aktywnych użytkowników serwisu.Zestaw testowy AGHdigits. Przypadek testowy 5.
Przypadek testowy testowy numer 6 został celowo pominięty w rozważaniach, z uwagi na znaczne
podobieństwo charakterystyk wykresów do charakterystyk z przypadku testowego numer 5.
Rys. 5.14: Zagregowane czasy realizacji operacji transkrypcji dla 250 użytkowników uruchomionych wczasie 150 sekund. Zestaw testowy AGHdigits. Przypadek testowy 6.
-
5.4. Badanie aspektów jakościowych serwisu 41
Dla przypadku testowego numer 7 zanotowano średni czas realizacji transkrypcji wynoszący 8,6 se-
kundy. Współczynnik RTF dla tego scenariusza wynosi w przybliżeniu 3,3. Czas odpowiedzi na żądania
klienckie w czasie całego testu ilustruje rysunek 5.15.
Rys. 5.15: Wykres ilustrujący zależność czasu trwania transkrypcji od czasu. Zestaw danych AGHdigits.Przypadek testowy 7
Rys. 5.16: Zagregowane czasy realizacji operacji transkrypcji dla 500 użytkowników uruchomionych wczasie 120 sekund. Zestaw testowy AGHdigits. Przypadek testowy 7.
-
5.4. Badanie aspektów jakościowych serwisu 42
Rys. 5.17: Wykres ilustrujący zależność czasu odpowiedzi od ilości aktywnych użytkowników serwisu.Zestaw testowy AGHdigits. Przypadek testowy 7.
Przeprowadzenie testów aplikacji dla przypadku testowego numer 8 uwidacznia problemy z zarzą-
dzaniem zasobami. Skutkiem wnikliwej analizy biało-skrzynkowej analizowanego przypadku jest wy-
krycie błędu w zwalnianiu zasobów. Kanały transportowe tworzone w celu przeprowadzenia wymiany
danych z serwerem gRPC silnika Sarmata nie są każdorazowo, po obsłużeniu klienta, niszczone. Błąd
zlokalizowany jest w części kodu odpowiedzialnej za zarządzanie zasobami serwerowymi. Powoduje
on powstawanie różnic pomiędzy informacjami na temat stanu zajętych zasobów na zdalnej lokalizacji
a stanem faktycznym. Jednym z pomysłów na rozwiązanie problemu jest zaimplementowanie po stro-
nie serwerowej (w silniku ASR, z wystawionym interface gRPC) mechanizmu pozwalającego zapytać
o ilość wolnych kanałów klienckich danej instancji. Zaimplementowany po stronie serwerowej mecha-
nizm, pozwoliłby uprościć logikę modułu zarządzającego zasobami. System odpytywałby instancję (lub
wiele instancji) serwera ASR o ilość wolnych kanałów bezpośrednio przed stworzeniem kolejnego. Tym
samym potrzeba rejestrowania stworzonych kanałów transportowych nie byłaby konieczna.
-
5.4. Badanie aspektów jakościowych serwisu 43
Rys. 5.18: Wykres ilustrujący zależność czasu trwania transkrypcji od czasu. Zestaw danych AGHdigits.Przypadek testowy 8.
Rys. 5.19: Wykres ilustrujący zależność czasu odpowiedzi od ilości aktywnych użytkowników serwisu.Zestaw testowy AGHdigits. Przypadek testowy 8.
Rysunki 5.20 oraz 5.21 wyglądają bardzo podobnie do analogicznych rysunków dla zestawu da-
nych AGHdigits. Operacja rozpoznawania mowy dla zestawu danych AGHstreets trwa w tym przypadku
średnio 2,3 sekundy krócej niż ma to miejsce dla zestawu AGHdigits.
Analiza porównawcza wyników działania serwisu wykazuje podobieństwo w działaniu serwisu dla
analogicznych przypadków z obu zestawów. Jedynym czynnikiem różniącym w tym przypadku jest za-
stosowanie innych danych wejściowych. Pozwala to zrozumieć, dlaczego charakterystyki wygenerowane
dla obu scenariuszy są podobne. System poddany jest podobnemu obciążeniu i reaguje analogicznie.
Podkreślić należy fakt, iż dla większości przypadków, rozpoznawanie fraz przebiega szybciej dla nagrań
-
5.4. Badanie aspektów jakościowych serwisu 44
z zestawu AGHstreets. Dłuższe czasy rozpoznawania mowy dla przypadków z zestawu AGHdigits może
być skutkiem użycia nieadekwatnej konfiguracji systemu ASR. Podczas testów nagrań z obu zestawów
użyto tych samych parametrów konfiguracyjnych silniku Sarmata.
Rys. 5.20: Zagregowane czasy realizacji operacji transkrypcji dla 20 użytkowników uruchomionych wczasie 1 sekundy. Zestaw testowy AGHstreets. Przypadek testowy 1.
Rys. 5.21: Wykres ilustrujący zależność czasu odpowiedzi od ilości aktywnych użytkowników serwisu.Zestaw testowy AGHstreets. Przypadek testowy 1.
-
5.4. Badanie aspektów jakościowych serwisu 45
Rys. 5.22: Wykres ilustrujący zależność czasu trwania transkrypcji od czasu. Zestaw danych AGHstreets.Przypadek testowy 2.
Rys. 5.23: Zagregowane czasy realizacji operacji transkrypcji dla 50 użytkowników uruchomionych wczasie 5 sekund. Zestaw testowy AGHstreets. Przypadek testowy 2.
-
5.4. Badanie aspektów jakościowych serwisu 46
Rys. 5.24: Wykres ilustrujący zależność czasu odpowiedzi od ilości aktywnych użytkowników serwisu.Zestaw testowy AGHstreets. Przypadek testowy 2.
Wykres 5.25 ilustruje niemal liniowy wzrost czasów realizacji żądania transkrypcji w czasie. Średni
czas rozpoznawania frazy w nagraniu wynosi 5,4 sekundy, co powoduje, iż współczynnik RTF dla tego
przypadku przyjmuje przybliżoną wartość wynoszącą 1,25. Jest to wartość zadowalająca, zwłaszcza bio-
rąc pod uwagę, iż omawiany przypadek testowy zakłada obciążenie systemu stoma sesjami klienckimi.
Rys. 5.25: Wykres ilustrujący zależność czasu trwania transkrypcji od czasu. Zestaw danych AGHstreets.Przypadek testowy 3.
-
5.4. Badanie aspektów jakościowych serwisu 47
Rys. 5.26: Zagregowane czasy realizacji operacji transkrypcji dla 100 użytkowników uruchomionych wczasie 30 sekund. Zestaw testowy AGHstreets. Przypadek testowy 3.
Rys. 5.27: Wykres ilustrujący zależność czasu odpowiedzi od ilości aktywnych użytkowników serwisu.Zestaw testowy AGHstreets. Przypadek testowy 3.
-
5.4. Badanie aspektów jakościowych serwisu 48
Rys. 5.28: Wykres ilustrujący zależność czasu trwania transkrypcji od czasu. Zestaw danych AGHstreets.Przypadek testowy 4.
Rys. 5.29: Zagregowane czasy realizacji operacji transkrypcji dla 150 użytkowników uruchomionych wczasie 40 sekund. Zestaw testowy AGHstreets. Przypadek testowy 4.
-
5.4. Badanie aspektów jakościowych serwisu 49
Rys. 5.30: Wykres ilustrujący zależność czasu odpowiedzi od ilości aktywnych użytkowników serwisu.Zestaw testowy AGHstreets. Przypadek testowy 4.
Rys. 5.31: Wykres ilustrujący zależność czasu trwania transkrypcji od czasu. Zestaw danych AGHstreets.Przypadek testowy 6.
-
5.4. Badanie aspektów jakościowych serwisu 50
Rys. 5.32: Zagregowane czasy realizacji operacji transkrypcji dla 250 użytkowników uruchomionych wczasie 150 sekund. Zestaw testowy AGHstreets. Przypadek testowy 6.
Rys. 5.33: Wykres ilustrujący zależność czasu odpowiedzi od ilości aktywnych użytkowników serwisu.Zestaw testowy AGHstreets. Przypadek testowy 6.
-
5.4. Badanie aspektów jakościowych serwisu 51
Rys. 5.34: Wykres ilustrujący zależność czasu trwania transkrypcji od czasu. Zestaw danych AGHstreets.Przypadek testowy 7.
Rys. 5.35: Zagregowane czasy realizacji operacji transkrypcji dla 500 użytkowników uruchomionych wczasie 120 sekund. Zestaw testowy AGHstreets. Przypadek testowy 7.
-
5.4. Badanie aspektów jakościowych serwisu 52
Rys. 5.36: Wykres ilustrujący zależność czasu odpowiedzi od ilości aktywnych użytkowników serwisu.Zestaw testowy AGHstreets. Przypadek testowy 7.
Podsumowanie testów
W tabelach 5.10 oraz 5.8 zawarto zagregowane dane na temat czasu trwania przetwarzania żądań
klienckich oraz niezawodności serwisu. Zawartość obu tabel wskazuje na dużo wyższą skuteczność oraz
responsywność serwisu w przypadku gdy użytkownik żąda transkrypcji nazw ulic, niż liczb. Tezę tą
potwierdzają wyniki działania systemu dla przypadków testowych 1,4,5 oraz 6, potęgowane dodatkowo
przez fakt, iż nagrania pochodzące ze zbioru nagrań AGHdigits są nagraniami trwającymi krócej. Przy-
padki testowe 2, 3 oraz 8 prezentują zbliżone rezultaty. Ciężki do uzasadnienia jest blisko czterokrotnie
dłuższy czas rozpoznawania wyrazów dla zestawu nagrań AGHdigits w przypadku testowym numer 5.
Wykresy przedstawione w niniejszym rozdziale, wykazują również, że w przypadku użycia jako danych
wejściowych nagrań z zestawu AGHstreets, system pracuje w bardziej liniowy sposób. Poniższe wykresy
przedstawiają porównanie czasów realizacji żądań klienckich przez badany system.
-
5.4. Badanie aspektów jakościowych serwisu 53
Rys. 5.37: Porównanie średnich czasów przetwarzania żądania transkrypcji dla zestawów nagrań AGH-streets oraz AGHdigits.
Rys. 5.38: Porównanie maksymalnych czasów przetwarzania żądania transkrypcji dla zestawów nagrańAGHstreets oraz AGHdigits.
-
5.5. Podsumowanie 54
5.5. Podsumowanie
Stworzona fasada jest produktem umożliwiającym rozpoznawanie mowy polskiej wykorzystując do
tego celu protokół HTTP. W przypadku niewielkiego, krótkotrwałego obciążenia serwisu, usługa działa
poprawnie dla ponad 90 % żądań. W przypadku większej ilości użytkowników występują problemy
z poprawną obsługą klientów. Zaobserwowano relatywnie dużą rozbieżność w czasach rozpoznawania
fraz dla nagrań pochodzących z różnych zestawów (tj. AGHdigits oraz AGHstreets). Może to być jednak
związane z nieodpowiednim ustawieniem silnika ASR Sarmata 2.0.
-
6. Podsumowanie
Opracowany system autorski jest dowodem, iż koncepcja dodania interface HTTP do silnika Sarmata
jest możliwa do realizacji ang. Proof Of Concept. Projektowanie, implementacja, konfiguracja środowi-
ska oraz testy rozwiązania zostały zrealizowane w ramach jednoosobowego zespołu. Biorąc pod uwagę
tę okoliczność, uzyskane w wyniku testów rezultaty można uznać za zadowalające. Zaimplementowane
rozwiązanie jest w pełni skalowalne i jest w stanie obsługiwać w warunkach zbliżonych do produkcyj-
nych nawet do 150 użytkowników jednocześnie. Niestety jakość działania serwisu definiowana przez
czynniki takie jak responsywność, obsługa sytuacji wyjątkowych oraz błędów, dostępność czy bezawa-
ryjny czas działania zależy silnie od czasu działania serwisu. W obecnej postaci system nie jest gotowy
na pracę w ś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ównoważenia obciążenia sieciowego• brak obsługi niektórych błędówStworzony system może być jednak potraktowany jako podstawa do dalszych prac nad interface
REST dla silnika ASR Sarmata.
6.1. Osiągnięte cele
W ramach realizacji niniejszej pracy udało się ukończyć następujące zadania:
1. opracowanie teorii związanej z tematyką chmurową (zarządzanie zasobami serwerowymi), pod-
stawami rozpoznawania mowy, usługami rozpoznawania mowy oraz sposobu ich ewaluacji
2. zaprojektowanie oraz implementacja usługi internetowej udostępniającej funkcjonalności systemu
rozpoznawania mowy polskiej Sarmata 2.0
3. zaprojektowanie oraz realizacja testów rozwią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 zaliczyć należy malejącą, wraz z czasem trwania pracy
systemu, responsywność. Wynika to najprawdopodobniej z niedoskonałości algorytmu równoważenia
obciążenia oraz powiązanym z nim algorytmem zarządzania ilością instancji serwera ASR. Poniższej
wyartykułowano zadania, które w ocenie autora pozwolą na poprawę jakości świadczonych przez serwis
usług:
1. eliminacja problemu malejącej, wraz z czasem pracy systemu, responsywności
2. przygotowanie mechanizmu udostępniającego usługę typu Health Check pozwalającego spraw-
dzać ilość wolnych sesji klienckich jaką zdolna jest obsłużyć instancja serwera ASR
3. obsługa wyjątków w module transportowym gRPC po stronie zaimplementowanej fasady
4. dodanie mechanizmów bezpieczeń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 (źródło [27]) . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
4.1 Diagram blokowy ilustrujący podział na strefy funkcjonalne szkieletu aplikacji Spring
(źródło [42]). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
4.2 Diagram sekwencji ilustrujący sposób komunikacji asynchronicznej w opracowanym
systemie [50] . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
4.3 Przykładowy zrzut ekranu ilustrujący wymianę wiadomości pomiędzy zaimplemento-
waną fasadą a silnikiem ASR . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
5.1 Zagregowane czasy realizacji operacji transkrypcji dla 20 użytkowników uruchomionych
w czasie 1 sekundy. Zestaw testowy AGHdigits. Przypadek testowy 1. . . . . . . . . . . 34
5.2 Wykres ilustrujący zależność czasu odpowiedzi od ilości aktywnych użytkowników ser-
wisu. Zestaw testowy AGHdigits. Przypadek testowy 1. . . . . . . . . . . . . . . . . . . 35
5.3 Wykres ilustrujący zależność czasu trwania transkrypcji od czasu. Zestaw danych AGH-
digits. Przypadek testowy 2. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
5.4 Zagregowane czasy realizacji operacji transkrypcji dla 50 użytkowników uruchomionych
w czasie 5 sekund. Zestaw testowy AGHdigits. Przypadek testowy 2. . . . . . . . . . . . 36
5.5 Wykres ilustrujący zależność czasu odpowiedzi od ilości aktywnych użytkowników ser-
wisu. Zestaw testowy AGHdigits. Przypadek testowy 2. . . . . . . . . . . . . . . . . . . 36
5.6 Wykres ilustrujący zależność czasu trwania transkrypcji od czasu. Zestaw danych AGH-
digits. Przypadek testowy 3 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
5.7 Zagregowane czasy realizacji operacji transkrypcji dla 100 użytkowników uruchomio-
nych w czasie 20 sekund. Zestaw testowy AGHdigits. Przypadek testowy 3. . . . . . . . 37
5.8 Wykres ilustrujący zależność czasu odpowiedzi od ilości aktywnych użytkowników ser-
wisu. Zestaw testowy AGHdigits. Przypadek testowy 3. . . . . . . . . . . . . . . . . . . 38
5.9 Wykres ilustrujący zależność czasu trwania transkrypcji od czasu. Zestaw danych AGH-
digits. Przypadek testowy 4. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
5.10 Zagregowane czasy realizacji operacji transkrypcji dla 150 użytkowników uruchomio-
nych w czasie 40 sekund. Zestaw testowy AGHdigits. Przypadek testowy 4. . . . . . . . 39
57
-
SPIS RYSUNKÓW 58
5.11 Wykres ilustrujący zależność czasu trwania transkrypcji od czasu. Zestaw danych AGH-
digits. Przypadek testowy 5. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
5.12 Zagregowane czasy realizacji operacji transkrypcji dla 150 użytkowników uruchomio-
nych w czasie 90 sekund. Zestaw testowy AGHdigits. Przypadek testowy 5. . . . . . . . 40
5.13 Wykres ilustrujący zależność czasu odpowiedzi od ilości aktywnych użytkowników ser-
wisu. Zestaw testowy AGHdigits. Przypadek testowy 5. . . . . . . . . . . . . . . . . . . 40
5.14 Zagregowane czasy realizacji operacji transkrypcji dla 250 użytkowników uruchomio-
nych w czasie 150 sekund. Zestaw testowy AGHdigits. Przypadek testowy 6. . . . . . . 40
5.15 Wykres ilustrujący zależność czasu trwania transkrypcji od czasu. Zestaw danych AGH-
digits. Przypadek testowy 7 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
5.16 Zagregowane czasy realizacji operacji transkrypcji dla 500 użytkowników uruchomio-
nych w czasie 120 sekund. Zestaw testowy AGHdigits. Przypadek testowy 7. . . . . . . 41
5.17 Wykres ilustrujący zależność czasu odpowiedzi od ilości aktywnych użytkowników ser-
wisu. Zestaw testowy AGHdigits. Przypadek