Newer
Older
% arara: pdflatex
% arara: pdflatex
% arara: pdflatex
% options:
% thesis=B bachelor's thesis
% thesis=M master's thesis
% czech thesis in Czech language
% slovak thesis in Slovak language
% english thesis in English language
% hidelinks remove colour boxes around hyperlinks
\documentclass[thesis=B,czech]{FITthesis}[2019/03/06]
\usepackage[utf8]{inputenc} % LaTeX source encoded as UTF-8
\usepackage{enumerate}
\usepackage{float}
\usepackage{amsmath}
\usepackage{hyperref}
% \usepackage{amssymb} %additional math symbols
\usepackage{dirtree} %directory tree visualisation
% % list of acronyms
% \usepackage[acronym,nonumberlist,toc,numberedsection=autolabel]{glossaries}
% \iflanguage{czech}{\renewcommand*{\acronymname}{Seznam pou{\v z}it{\' y}ch zkratek}}{}
% \makeglossaries
\newcommand{\tg}{\mathop{\mathrm{tg}}} %cesky tangens
\newcommand{\cotg}{\mathop{\mathrm{cotg}}} %cesky cotangens
% % % % % % % % % % % % % % % % % % % % % % % % % % % % % %
% ODTUD DAL VSE ZMENTE++
% % % % % % % % % % % % % % % % % % % % % % % % % % % % % %
\department{Katedra softwarového inženýrství}
\title{Aplikace pro doporučování na základě finančních akcí}
\authorGN{Radek} %(křestní) jméno (jména) autora
\authorFN{Puš} %příjmení autora
\authorWithDegrees{Radek Puš} %jméno autora včetně současných akademických titulů
\author{Radek Puš} %jméno autora bez akademických titulů
\acknowledgements{Děkuji společnosti Trask Solutions a.s., zejména pak Ing. Petru Hnízdilovi a Ing. Pavlu Svobodovi, za veškeré konzultace a datové podklady k práci. Dále děkuji své přítelkyni Mariyi Tsanko, za dodání doplňujících dat ze svých bankovních účtů, PaeDr. Jiřině Mališové za korekturu anglicky psaného abstraktu a svým rodičům, za veškerou podporu při psaní práce.}
{V bakalářské práci je řešen problém předpovídání budoucích výdajů klientovi, na základě jeho uplynulé finanční historie. Cílem práce je implementovat toto předpovídání zejména pomocí umělé inteligence a vytvořit webové rozhraní, které by zobrazovalo výsledky předpovědí. Celá aplikace je vytvořena pomocí třívrstvé architektury, kde frontend je tvořen frameworkem Angular, backend pomocí .NET Core frameworku a databáze je založená na Microsoft SQL.
Umělá inteligence je implementována jako několik po sobě jdoucích vrstev neuronů, přičemž vrstvy jsou uspořádány tak, že množství neuronů se v každé další vrstvě postupně snižuje na jeden jediný, který dává informaci, zda se bude transakce opakovat, či nikoli. Aby se posléze dalo vyhodnotit, zda se transakce opravdu opakovala, byly porovnávány velikosti transakcí po jednotlivých týdnech, a ty, částkou si nejvíce podobné, byly označeny za opakující se.
Toto předpovídání bylo dále doplněno o předpovídání na základě průměrů a~porovnávání velikosti jednotlivých částek, z uživatelem nahrané transakční historie.
In the bachelor thesis is solved the problem of forecasting future transactions to the client, based on his past financial history. The aim of this work is to implement this prediction especially using artificial intelligence and to create a web interface that would display the results of predictions. The whole application is created using a three-tier architecture, where the frontend consists of the Angular framework, the backend is using the .NET Core framework and the database is based on Microsoft SQL.
Artificial intelligence is implemented as several successive layers of neurons, the layers being arranged such that the amount of neurons in each additional layer is gradually reduced to one, which gives information whether the transaction will repeat or not. Then, in order to evaluate whether the transaction was actually repeating, the size of the transactions was compared on a~week-by-week basis, and those with the most similar amount were identified as recurring.
This prediction was further supplemented by averaging based on a comparison of the size of individual amounts from the user's imported transaction history.
\placeForDeclarationOfAuthenticity{V~Praze}
\declarationOfAuthenticityOption{4} %volba Prohlášení (číslo 1-6)
\keywordsCS{webový portál, předpovídání finančních transakcí, analýza finančních transakcí, umělá inteligence, .NET Core, Entity Framework, Angular}
\keywordsEN{web portal, anticipating financial transactions, financial transaction analysis, artificial intelligence, .NET Core, Entity Framework, Angular}
\website{https://gitlab.fit.cvut.cz/pusradek/bakalarka} %volitelná URL práce, objeví se v tiráži - úplně odstraňte, nemáte-li URL práce
\begin{document}
% \newacronym{CVUT}{{\v C}VUT}{{\v C}esk{\' e} vysok{\' e} u{\v c}en{\' i} technick{\' e} v Praze}
% \newacronym{FIT}{FIT}{Fakulta informa{\v c}n{\' i}ch technologi{\' i}}
\begin{introduction}
%sem napište úvod Vaší práce ( 1 - 1,5 strany)
% - možná přidat něco jako "aktuálnost tématu"
% - možná - čím se nezabývám
% - nepatří se podnadpisy!
Ve své práci řeším problém předpovídání finančních transakcí. Při výběru tématu jsem využil zájmu jedné bankovní instituce o odkoupení výsledného produktu. Banka by nabídla svým klientům možnost zobrazit si své pravděpodobné transakce a získat tak komplexnější přehled o výdajích. Na základě toho by klienti dostali možnost například vyloučit nebo omezit některé transakce a tím ušetřit své finanční prostředky. Bankovní instituce tím navýší komfort klientů na svém webu, což by mělo přispět k jejich větší celkové spokojenosti.
V průběhu tvorby této práce jsem si zároveň prohloubil znalosti v oboru umělé inteligence, která dokáže předpovídat chování uživatelů na základě předem získaných dat. Vývoj v této oblasti mne vždy zajímal a to bylo také mou motivací při výběru tématu.
Technologie, které jsem využil pro svou práci, jsem si vybral na základě svého současného zaměstnání. Skrze společnost Trask Solutions a.s. pracuji jako externista a software developer ve společnosti ČSOB Leasing a podílím se na vývoji aplikace právě v jazyce C\# a frameworku ASP.NET. Pro účely práce jsem zvolil .NET Core ve spojení s~Entity Frameworkem, což je nová a navazující technologie na ASP.NET. Pro frontend jsem využil framework Angular. S~těmito technologiemi navíc pracuje tým, se kterým v práci spolupracuji na rozvoji aplikace. Zkušenosti nabyté při tvorbě bakalářské práce, bych rád využil ke zvýšení své kvalifikace v~oboru.
Práci jsem rozčlenil do pěti kapitol. V první jsem analyzoval problém a~zkoumal, jestli již byl řešen dříve. Ve druhé kapitole, realizaci, popisuji, jak jsem vše řešil. Ať už web, umělou inteligenci nebo databázi. V následující kapitole popisuji výsledné uživatelské rozhraní, poté, v kapitole testování, zkoumám, jestli se aplikace chová korektně. V poslední kapitole jsem se pak zabýval, jakým způsobem by šlo aplikaci rozšířit.
Celkovým cílem je vytvoření webové aplikace, která bude registrovaným uživa-telům poskytovat službu předpovídání finančních transakcí na základě jimi nahraného výpisu z účtu. Tohoto cíle je dosaženo splněním dvou dílčích částí: rešeršní a praktické.
Cílem teoretické části práce je nastudování frameworku Angular, Typescriptu, Entity Frameworku Core / .NET Core a analýza funkčních i nefunkčních požadavků aplikace. Dále je třeba analyzovat možnosti autentizace a zabe-zpečení uživatelských dat a stejně tak ukládání a obohacování dat uživatelem nahrané finanční historie. Také je nutné získat přehled existujících řešení a zjistit možnosti využití umělé inteligence, která bude muset alespoň zčásti před-povědět chování uživatelů. Tato umělá inteligence bude předpovídat chování uživatelů právě na základě předem získaných a obohacených dat jejich finanční historie.
Cílem praktické části je implementovat tuto webovou aplikaci, včetně zabezpečení, a pokusit se implementovat a integrovat umělou inteligenci, která bude vytěžovat údaje z uživatelem nahraných dat.
\section{Přínos práce}
Přínosem práce je aplikace, která je schopna zpracovat uživatelskou finanční historii, data obohatit, odhadnout, jaké budou mít uživatelé v blízké budoucnosti výdaje, a tyto odhady uživatelům zobrazit.
Projekt je webová aplikace. Musí se proto skládat ze dvou částí: frontendu a backendu. Frontend je webovým rozhraním a backend zpracovává údaje uživatele a dodává webovému rozhraní data.
\section{Analýza požadavků}
Aplikace musí splňovat jisté požadavky. Ty se dají rozdělit na požadavky funkční a nefunkční:
\begin{enumerate}[a)]
\item Funkční požadavky
\item registrace a přihlašování uživatelů,
\item změna hesla,
\item smazání účtu,
\item nahrávání finanční historie ve formátu csv,
\item zobrazení historie plateb,
\item odhad budoucích výdajů (z finanční historie) neuronovou sítí,
\item odhad budoucích výdajů průměrováním historických výdajů,
\item odhad budoucích výdajů porovnáváním částek historických výdajů.
\item .NET Core 2.2,
\item Microsoft SQL Server 2019,
\item http-server,
\item šifrování hesel.
Produkční verzi aplikace bude možné alternativně spustit pomocí Dockeru, který jednotlivé nástroje pro běh bude zastřešovat v nadefinovaném kontejneru.
Pro webové rozhraní se nabízejí dvě možná řešení. Single page website a multiple page website. Každé má své pro a proti.
\subsection{Single page website}
Jak už název napovídá, je to web, skládající se z jediné stránky. Stránka obvykle neobsahuje příliš mnoho informací a je založena zejména na dynamičnosti prvků. Velmi často jsou to doprovodné stránky nebo krátké informativní stránky, s jejichž pomocí se subjekty na webu prezentují.
Tyto weby, vývojově starší, obsahují zpravidla hodně informací. Obsahují nějakou formu směrování - ať už složitější, dynamickou, či jednodušší, statickou. Uživateli podávají poměrně velké množství informací. Jsou to zpravidla nejrůznější blogy, e-shopy, fóra. Jejich implementace je často snazší (zejména u statických webů), jsou schopny, často přehledněji, zprostředkovat uživateli více informací a jsou (i z historických důvodů) běžnější.
V aplikaci bude nutné zabezpečit komunikaci se serverem tak, aby každý uživatel měl přístup pouze ke svým datům. To je možné učinit pomocí Session anebo pomocí, novějšího, JWT tokenu. Tyto dva přístupy se v zásadě liší způsobem ukládání informace o autentifikaci uživatele. Session tuto informaci ukládá do databáze, kdežto JWT tokeny jsou uloženy u uživatele.
Ukládání u uživatele má tu výhodu, že se nemusí ukládat na serveru tolik dat do mezipaměti. Ukládání na serveru, v případě několika uživatelů, není nijak náročné, avšak u většího množství to přináší podstatně vyšší nároky na výkon.\cite{JWTvsSessionPerformance} Navíc JWT tokeny jsou imunní vůči CSRF útoku\cite{JWTvsSessionCSRF}.
Výhodou ukládání na server je zase fakt, že je mnohem snazší znevalidnit uživatelské přihlášení - stačí odebrat záznam z databáze. U JWT je nutné vyčkat na vypršení tokenu anebo vytvořit nějakou formu blacklistu (seznam neplatných tokenů).
\section{Existující řešení}
Na českém trhu je, co se týče předpovídání transakcí, velmi pravděpodobně zatím jediné finanční bankovnictví České spořitelny, zvané \uv{\textit{George}}~a její doplněk \uv{\textit{Moje zdravé finance}.}\cite{George} Aplikace je přístupná pouze klientům České spořitelny a zobrazuje pouze příjmy a výdaje. V části \uv{\textit{Moje zdravé finance}}~lze pak vidět, jak dlouho mi vystačí současné úspory nebo například odhadnout výši mého budoucího důchodu. Je ale schopna předpovědět některé mé budoucí transakce, tedy funkci, kterou mám za úkol implementovat. Aplikace byla spuštěna v průběhu května 2018\cite{vznikGeorge_Investujeme},\cite{vznikGeorge_Mesec} (ačkoli přesné datum jsem nebyl schopen dohledat), tedy chvíli po schválení zadání mé bakalářské práce. To tedy dokazuje, že o téma je v praxi zájem, ale bohužel také to, že v mezičase mého vypracovávání, byl problém zpracován jinde.
Na zahraničním trhu pak existují aplikace, které umožňují klientům sledovat např. jejich měsíční útratu a na základě výpočtu jim poskytnout informaci, jestli a jak moc, překročili průměrné výdaje v tom kterém měsíci.\cite{zahranicni_aplikace}.
\begin{figure}\centering
\includegraphics[width=0.75\textwidth]{img/Moje_zdrave_finance_anonymized.png}
\caption[Moje zdravé finance]{Moje zdravé finance - předpovídání transakcí České spořitelny}\label{fig:float}
\end{figure}
\subsection{Existující implementace neuronové sítě}
Existuje mnoho externích knihoven, které implementují neuronové sítě. Většina je však placená a nenabízí rozhraní pro C\#, často se také omezují pouze na Python, případně C++. Příkladem může být Opennn\cite{OpenNN}, PyTorch\cite{PyTorch}, Keras\cite{Keras}, Tensorflow\cite{TensorFlow} či Machine Learning od AWS (dceřiná společnost Amazonu)\cite{AmazonML}.
Umělá inteligence určená pro C\# je vyvíjena hlavně společností Microsoft. Ta vyvinula dva frameworky CNTK a ML.NET.
CNTK je framework zaměřený na neuronové sítě\cite{CNTK}. Zpočátku obsahoval jen Python API, ale později byl rozšířen i o C\# API. V současné době dochází ještě k tvorbě Java API.\cite{CNTK_API}
ML.NET je zaměřen na .NET vývojáře\cite{MLNET}. Zároveň se snaží být více multifunkční (obsahuje i algoritmy jako K-Means\cite{MLNET_Iris}). Také umožňuje základní generování kódu pro veřejnost (pomocí AutoML\cite{MLNET_AutoML}), která se nezabývá detailní funkčností umělé inteligence.
V době rozhodování o formě implementace neuronové sítě došlo i k pokusu o jeho implementaci pomocí CNTK. V té době však ještě nebyla plně dokončena dokumentace C\# API, což způsobovalo značné problémy s porozuměním tomuto frameworku. U frameworku ML.NET bylo první preview vydáno v září 2019\cite{MLNET_preview}, tedy v době, kdy už bylo nutné bakalářskou práci vyvíjet. Z těchto důvodů došlo k přiklonění se k vytvoření vlastní implementace neuronové sítě.
\section{Obohacení dat}\label{ObohaceniDat}
Pro obohacení dat by bylo možné teoreticky využít veřejně dostupnou databázi MFČR - ARES (Adminstrativní registr ekonomických subjektů), resp. veřejně dostupnou odnož databáze \uv{VREO} (elektronický opis Veřejného rejstříku), na kterou se služba odkazuje.\cite{ARES_zip}. Bohužel data v této databázi nejsou ukládána jednotným způsobem. Je sice zadefinována základní struktura dokumentu\cite{ARES_struktura}, avšak data v ní nejsou nijak strukturována. Živnosti jsou zadány naprosto nahodile a není využito žádného oficiálního klíče. Nedefinované hodnoty obsahují výrazy jako: \uv{0}, \uv{null}, \uv{NULL}, \uv{prázdné}, \uv{nic}, \uv{není}, \uv{nedefinováno}~apod. Jako nejlepší příklad záznamu v databázi by pak mohla dobře posloužit Komerční banka. Ta nemá dokonce definováno vůbec nic, až na popis, který obsahuje necelých 8000 znaků (snímek dat z databáze pro Komerční banku v příloze \uv{\textit{KB\textunderscore VREO.xml}}). Lze tedy usoudit, že využití tohoto zdroje je téměř nemožné a pro obohacení se nehodí.
Další možnost, která by se nabízela, je využití bankovních symbolů. Variabilní a specifické symboly opět neobsahují žádné informace. Někdy do nich bývá zadáváno IČO, které by se dalo napojit na VREO, ale jak už je zmíněno výše, toto napojení nepřipadá v úvahu.
Zbývají tedy už jen konstantní symboly. Ty se bohužel využívají pouze v rámci České Republiky, ale mají alespoň částečně definovanou strukturu. A~ačkoli její použití již není povinné, ve výpisech z účtů, které byly pro tuto práci získány, se vyskytují hojně a mohou o transakcích něco říci.
\section{Transakce}
Od uživatele je vyžadováno nahrání vlastní transakční historie, přičemž aby byly jednotlivé záznamy v ní obsažené platné, musí obsahovat jisté informace. Protože každá banka tvoří výpisy z účtu nepatrně jinak, došlo k omezení na tyto údaje:
\begin{enumerate}[1)]
\item datum,
\item částka,
\item konstantní symbol.
\end{enumerate}
Z data transakce lze snadno zjistit, o jaký den se jednalo, i jestli k transakci došlo o víkendu. Částka jednoduše označuje velikost transakce. Konstatní symbol pak pomáhá obohatit data o další vstupy, jak již bylo zmíněno v kapitole \ref{ObohaceniDat} Obohacení dat.
Transakční historie obvykle obsahuje ještě další údaje, ty se ale většinou v jednotlivých bankách liší. Příkladem zde může být Typ transakce, který je označen v každé bance jinak. Dále to mohu být doplňující data (např. aktuální kurz převodu měn), které do výpisu vložily pouze některé bankovní instituce. Protože ale nelze dopředu určit, jaká data to jsou a co přesně obsahují, nejsou ve výsledné aplikaci využita.
%TODO viz. příloha *.csv csas + csob + airbank
\section{Ukládání dat}
Aplikace bude muset umožňovat ukládat uživatelské účty a zároveň k nim i~transakční historii od uživatelů. Je tedy vhodné vytvořit nějakou formu databáze.
\subsection{Uživatel}
Za první část databáze by se dala považovat data o uživatelích, kteří budou do~aplikace přistupovat. Je nutné si pro ně pamatovat uživatelské jméno a heslo. Heslo samozřejmě musí být uloženo v šifrované podobě.
\subsection{Uživatelská data}
Druhá část, ukládání uživatelských dat, je náročnější. Je potřeba zvážit, jak je ukládat. Veškerá data totiž budou přístupná z csv souborů (\uv{\textit{Comma-Separated Values}}~-- čárkou oddělené hodnoty)\cite{csv_name}. Z toho důvodu se nabízí dvě možnosti:
\begin{enumerate}[a)]
\item Parsování transakcí do podoby nějakého relačního modelu a uložení v něm.
\end{enumerate}
Ukládáním ve formě NoSQL je myšleno ukládání dat, jak přijdou od uživa-tele s minimálními úpravami (as-is). Pro veškeré operace s uživatelskými daty by se využívala jedna \mbox{\uv{velká tabulka}~(super--entita).} Z transakcí samotných lze vyvodit nějakou jistou strukturu a v tom případě bude docházet k zbytečně velké redundanci dat.
Druhou možností je transakci rozdělit na několik částí (tabulek) a s těmi následně pracovat. Výhodou zde je práce s menšími daty i menší databází.
\subsection{Neuronová síť}
Neuronová síť je tvořena pomocí vrstev neuronů a vah vstupů. Ukládání těchto dat přímo vybízí k uložení ve strukturované databázi, rozdělené přímo na tyto samostatné celky.
Pro webové rozhraní byla zvolena single page website, doplněná o stránky s~registrací a přihlášením. Není potřeba uživateli předávat velké množství informací. V zásadě je nutné jen zobrazovat grafy a předpoklady. Nemusí se tedy vytvářet rozsáhlý web, ale jen jednoduché směrování. V případě malého množství stránek se navíc snadněji pracuje s responzivitou, protože ji stačí vyladit na jednu, resp. tři stránky webu. Jakákoli práce s responzivitou pro každou další stránku pak zvětšuje prostor na chyby.
%TODO highcharts, bootstrap, angularmaterial, interceptor,
V případě zabezpečení komunikace mezi backendem a frontendem (API) bylo využito JWT tokenu. Kromě výhod, uvedených v analýze, je tento přístup k~zabezpečení i novější (dle Wikipedie poprvé vydán 28.12.2010\cite{JWT_published} - v průběhu psaní práce starý necelých osm let), a umožní autorovi vyzkoušet si novou technologii.
K zabezpečení směrování na straně klienta bylo využito tzv. guardů, jež jsou součástí Angular frameworku. A konečně k zabezpečení uživatelských hesel se využilo hashovacího algoritmu RFC~2898/SHA512. Pro každé heslo se navíc generuje jiná sůl, a proto by nemělo být možné v databázi najít dvě stejná hesla se stejným hashem.
Aby bylo možné činit nějaké předpovědi, je nutné od uživatele získat určitá data. Toho bylo docíleno na základě nahrání vyexportované transakční historie z banky uživatele. Zároveň se předpokládá, že historie bude ve validním CSV formátu
Možnost importu souborů je přístupná z hlavní stránky (stránka po přihlášení uživatele). Zde uživatel vybere soubor a stiskne tlačítko \uv{nahrát}. To způsobí zahájení celého procesu parsování dokumentu a~jeho ukládání do databáze.
Interně celý proces probíhá tak, že dojde k zavolání nějaké funkce, která převezme daný soubor a přes API pošle na server. Při tomto požadavku se~pak automaticky (jako při každém volání API) zavolá tzv. \uv{Interceptor}. Ten vloží do hlavičky volání ještě údaj o JWT tokenu, aby server mohl rozpoznat, jestli je volání oprávněné či nikoli. JWT token navíc obsahuje údaje s informací, kterému uživateli tento požadavek náleží.
Po zpracování požadavku na frontendu, dojde ke zpracování požadavku na serveru. Ten ověří, jestli je uživatel přihlášen, soubor je v pořádku, a zároveň, zda již nebyl nahrán soubor se stejným jménem pro daného uživatele. Pokud ano, pošle soubor dále ke zpracování. V opačném případě vrátí HTTP status BadRequest a dál nepokračuje.
Pokud došlo k úspěšnému zpracování požadavku, dojde k parsování souboru. K tomuto procesu byla využita externí knihovna s názvem CsvHelper\cite{CsvHelper}.
Tato knihovna potřebuje k úspěšnému zpracování dokumentu nadefinovanou třídu, jež obsahuje veškeré položky, které mají být v dokumentu vybrány. Přestože by pro extrakci stačilo vybrat pouze částku, datum a KS, bylo načteno podstatně více údajů pro případné rozšíření aplikace. Veškeré načítané údaje jsou proto následující:
\begin{itemize}[--]
\item typ účtu,
\item číslo účtu (včetně kódu banky),
\item datum zaúčtování,
\item částka,
\item měna,
\item zůstatek,
\item číslo protiúčtu (včetně kódu banky),
\item konstantní, specifický, variabilní symbol,
\item typ operace,
\item ID transakce v bance,
\item poznámka.
\end{itemize}
K výše zmíněnému výčtu je však nutno zdůraznit, že ne všechny položky jsou povinné. V práci došlo na omezení se na pouze dvě povinné položky a totiž datum zaúčtování a částka. V případě chybějícího čísla účtu dochází k jeho nahrazení ID uživatele s kódem banky \uv{857368}. Tato hodnota je ekvivalentní textu \uv{UID}~(User ID - uživatelské ID) v ASCII tabulce (kódová tabulka pro znaky anglické abecedy).
%TODO ref csv soubory
Při realizaci bylo myšleno i na různá pojmenování napříč jednotlivými bankami, a k pokusu o vytvoření maximální univerzálnosti řešení. Proto se pro některé položky definovalo více názvů. Příkladem tak může být položka \uv{označení operace}, jak je pojmenována v ČSOB a \uv{typ transakce}, což je ekvivalent v České spořitelně.
Relativně překvapivým problémem je však parsování částky transakce. Při exportu dat totiž může být ve formátu \uv{1 234.56}~- s mezerou, oddělující řády. Také ale může obsahovat rozdílné oddělovače desetinných míst, př. \uv{12,35}. Problém mezery však lze snadno vyřešit povolením této skutečnosti při parsování pomocí metody, v .NET frameworku, System.Parse.
Problém desetinné čárky není o tolik těžší. Před parsováním stačí částku projít a nahradit znak ','~znakem '.'~. Tím dojde k unifikaci čísla.
Po parsování dokumentu dochází k ukládání pouze těch záznamů, které se podařilo úspěšně zpracovat. Všechny neúspěšné záznamy jsou přeskočeny. Tím dochází k založení záznamu o nahraném souboru. Ten obsahuje jen jméno souboru a identifikaci uživatele, který ho nahrál. K tomuto záznamu se posléze přiřadí veškeré transakce, které byly tímto souborem nahrány. Děje se tak z~důvodu, že by uživatel chtěl daný soubor smazat.
\subsection{Obohacení}\label{RealizaceObohaceni}
Protože data z VREO nelze smysluplně zpracovat, došlo k obohacení data na základě konstantních symbolů. Tento prvek sice nemusí být přítomen v~transakci, pro operace, jež má na starosti banka (karetní operace, výběry z bankomatu atp.), jsou však často přítomny.
Přidání závislostí na konstantních symbolech bylo založeno na číselníku MFČR. V práci pak byl konkrétně využit jeho souhrn ze serveru Finance.cz\cite{ConstantSymbolList}. Číselník byl zároveň rozdělen do následujících kategorií:
\begin{enumerate}[a)]
\item Druh
\begin{itemize} [--]
\item Označení druhu transakce.
\item Např. platby za zboží a služby, mzdové náklady.
\end{itemize}
\item Dle významu poslední číslice
\begin{itemize} [--]
\item Označení druhu platby.
\item Např. hotovost, dobropisy, přednostní platby.
\end{itemize}
\item Spravované MFČR
\begin{itemize} [--]
\item Popisují vztahy ke státnímu rozpočtu a rozpočtům místních samospráv.
\item Např. dotace, daně, cla, pokuty, penále.
\end{itemize}
\item Rezervované symboly
\begin{itemize} [--]
\item Symboly rezervované pro mezibankovní styk.
\item Např. platby kartou, šekem, platby na neexistující účet.
\end{itemize}
\end{enumerate}
Dále existuje ještě i sada zahraničních konstantních symbolů. Sada shrnuje různé druhy plateb do dvaceti různých kategorií. Vzhledem k faktu, že se pro práci nepodařilo zajistit žádné výpisy z účtu, jež by obsahovaly zahraniční platby, tato sada nebyla využita. Byla však definována pro případné pozdější rozšíření dat.
Pro předpovídání budoucích transakcí je využita neuronová síť. Tedy síť, na způsob lidského mozku, která obsahuje množství neuronů. Celá tato síť pak funguje tak, že pokud dojde k aktivaci nějakého neuronu, tak ten postupně ovlivní jeden či více dalších neuronů, a ty zase další. Míru aktivace pak ovlivňují tzv. váhy pro každý z předchozích neuronů (vstupů). Způsob jejího fungování velmi názorně ukazuje např. Grant Sanderson ve svém videu \uv{\textit{But what is a Neural Network?}}\cite{ANN_Understanding}
Aby tedy neuronová síť mohla fungovat, potřebuje nějaká data, která by aktivovala vstupní neurony. Tato data musí být přizpůsobena tak, aby vypadala jako výstup jiných neuronů - musí být \uv{normalizovaná}.
Dále potřebuje nějaká data, za pomoci kterých by si mohla nadefinovat, nakolik budou jednotlivé neurony ovlivňovat ty ostatní. Jinými slovy data, podle kterých se bude síť učit předpovídat. To jsou v této aplikaci veškeré transakce, jež se opakují.
Lze tedy pozorovat, že implementace předpovídání transakcí je poměrně rozsáhlá. Proto byla rozdělena do několika konzolových aplikací. Každou z~těch-to částí je tak možné nezávisle implementovat i testovat. V případě potřeby je možné takto i jeden modul reimplementovat a nedojde k ovlivnění dalších. Ve výsledku byla proto umělá inteligence rozdělena následovně:
\newpage
\begin{enumerate}
\item Datafeeder
\begin{enumerate}[--]
\item Část aplikace, která slouží k~postupnému čtení dat z databáze a k~předání dalším objektům (částem aplikace).
\item tato část má na starost zároveň i normalizaci dat.
\end{enumerate}
\item Komparátor
\begin{enumerate}[--]
\item Udává, které transakce se opakovaly a které nikoli.
\end{enumerate}
\item Neuronová síť
\begin{enumerate}[--]
\item Na základě vstupních dat se pokusí předpovědět výsledek.
\end{enumerate}
\end{enumerate}
\subsection{Implementace základní části neuronové sítě}
Samotná neuronová síť je stále velký celek, který bylo potřeba rozdělit na~podobjekty. Bylo tak tedy učiněno dle logických celků - nejdříve se dělí na jednotlivé vrstvy. Vrstvy mohou být:
\begin{enumerate}[a)]
\item Vstupní vrstva
\begin{enumerate}[--]
\item Prochází přes ni veškeré vstupy do neuronové sítě.
\item Svůj výstup předává vnitřním vrstvám.
\item Je první a zároveň, v rámci sítě, unikátní vrstvou.
\end{enumerate}
\item Vnitřní/skrytá vrstva (vstupně-výstupní)
\begin{enumerate}[--]
\item Přijímá vstup z předchozí vrstvy, zpracovává jej a předává dál.
\item Vstup může být buď přijímán ze vstupní vrstvy nebo z jiné vnitřní vrstvy.
\item Výstup je předán buď opět do další, vnitřní vrstvy, anebo konečné, výstupní.
\end{enumerate}
\item Výstupní
\begin{enumerate}[--]
\item Stejně jako vstupní vrstva je unikátní.
\item Přijímá vstupy z poslední vnitřní vrstvy a vyhodnocuje je.
Každá z těchto vrstev následně obsahuje sadu neuronů a každý neuron obsahuje právě jednu sadu vah. Tato sada je složena z desetinných čísel, jejichž počet je ekvivalentní množství neuronů v předchozí vrstvě. Jedinou výjimkou je vrstva vstupní. Ta má neurony nahrazeny sadou vstupů (jeden vstup je ekvivalentem jednoho neuronu).
\begin{figure}[h]
\includegraphics[width=0.75\textwidth]{img/artificial-neural-network.png}
\centering
\caption[Struktura neuronové sítě]{Struktura neuronové sítě\cite{ANN_structure}}
\end{figure}
\subsubsection{Učení}
Aby síť měla nějakou vypovídací hodnotu, musí se nejdříve naučit, co má předpovídat. Prvotní předpovědi jsou čistě náhodné. Děje se tak proto, že při inicializaci jsou váhy v jednotlivých neuronech čistě náhodné. Je tedy nutné provést korekci vah a tím síť učit. Tomuto procesu se říká zpětná propagace (\uv{backpropagation}). Nutnou podmínkou pro takové učení je pak samozřejmé, že je známý korektní výstup pro daný vstup.
Korekce probíhá tak, že síť nejdříve vyhodnotí nějaký vstup. Poté jí je řečeno, jaký byl očekávaný výsledek. Na základě rozdílu očekávaného výsledku a skutečného výsledku se vyhodnotí chyba pro výstup. Ta se následně musí propagovat napříč celou sítí. Musí se ale také brát v úvahu, že ne každý neuron přispěl stejnou měrou k výsledné chybě. Je nutné najít přesnou chybu pro každý z neuronů.
K tomuto výpočtu se dá využít vzorec:
\begin{figure}[H]
\[ \gamma = error \cdot (1 - output^2) \]
\end{figure}
Přičemž \textit{error} je chyba neuronu, \textit{output} výstup neuronu po průchodu aktivační funkcí a $\gamma$ by se dala pochopit jako chyba vstupu současného neuronu. Chybu jednotlivých vah lze najít vynásobením vstupů do neuronu (vektorem) a vypočítané, skalární, hodnoty $\gamma$, díky čemuž vznikne nový vektor. Tento vektor už poté stačí jen přičíst ke korespondující váze, čímž dojde k její opravě.
Je však stále třeba zjistit chybu každého celého neuronu ve vnitřní vrstvě, aby bylo možné využít výše zmíněný vzorec. Ve výstupní vrstvě je toho dosaženo, již zmíněným odečtením referenčního výsledku od předpokládaného. Pro vnitřní vrstvy tento způsob ale použít nelze. Zde toho je dosaženo tak, že se v každé vrstvě násobí vypočtená hodnota $\gamma$ ~s korespondujícími váhami neuronu a vektorově se tyto hodnoty sečtou. Výsledný vektor se vždy předá předcházející vrstvě jako seznam chyb každého z neuronů. Celý proces předá-vání vektoru chyb funguje na obdobném principu jako předchozí vyhodnocování pravděpodobnosti. V tomto případě je ale postup opačný, a vyhodnocuje se postupně od výstupní vrstvy ke vstupní.
Detailní odvození vzorce (ačkoli pro odlišnou implementaci neuronové sítě) přehledně vysvětluje uživatel, vystupující pod přezdívkou \textit{The One} na svém videu o tvorbě neuronových stí.\cite{ANN_BackPropagation}
Jedním z problémů při učení neuronové sítě mohou být také vstupy samotné. Pokud se síť bude učit po samostatných vstupech a tyto vstupy budou rozděleny na samostatné celky, může se síť naučit nejdříve jeden, a~později přeučit na druhý.
Pokud se naopak využijí všechny vstupy najednou, může u velkých datasetů dojít ke značným problémům s mezipamětí. To může způsobit načítání vstupních dat samotných, ale mnohem pravděpodobněji alokaci prostředků ve~vnitřních strukturách každého neuronu. Konkrétně jde o ukládání, vypočí-taných korekcí jednotlivých vah, v generické kolekci \textit{List}. Ta se při dosažení maxima svého objemu automaticky realokuje na násobek současného. Tím vzniknou několikanásobky velikosti původního setu dat. Navíc se zjistilo, že tento přístup není ani příliš efektivní z hlediska učení.\cite{minibatchVsFullBatch} Pro učení je tedy využit přístup, který rozděluje data do několika, ne nutně stejně velkých, ale relativně malých celků (\uv{minibatch}). Tento celek se nejdříve celý vyhodnotí a váhy jsou upraveny na základě průměru všech korekcí v něm.
Tento přístup uspoří paměť, je schopen se lépe učit a zároveň tím lze eliminovat problém, kdy chodí data jednoho druhu a posléze jiného (nemají uniformní rozdělení). Síť by se totiž připravila jen na jeden druh dat. Což je zároveň problém, ke kterému došlo kvůli porovnávání transakcí (detailně rozebráno v sekci \ref{komparator}).
\subsubsection{Předpovídání}\label{predvidani}
Při předpovídání výsledku se do počáteční (vstupní) vrstvy vloží vstupy. Tato vrstva je pošle do vrstvy vnitřní. V této vnitřní vrstvě se v každém neuronu všechny vstupy vynásobí s korespondujícími váhami a následně se sečtou. Výsledné číslo projde přes příslušnou formu aktivační funkce, která sníží velikost hodnoty na číslo v intervalu \textless -1;1 \textgreater . Tato funkce bývá též nazývána \uv{squashing function}, z angl. zmáčknout/slisovat.
Vzhledem k náročnosti na pochopení výroku výše, je pro lepší ilustraci přiložen obrázek č. \ref{single-neuron}. Na obrázku jsou pomocí znaků X1 - X3 znázorněny jednotlivé vstupy neuronu (kompletní sada vstupů vrstvy). Znaky W1 - W3 označují váhy, kterými se vstupy násobí. Váhy směřují do aktivační funkce, která udržuje hodnotu výstupu v daném intervalu. Písmeno Y označuje výstup-ní hodnotu neuronu.
\begin{figure}[h]
\includegraphics[width=0.75\textwidth]{img/neural-network-single-neuron.png}
\centering
\caption[Průchod neuronem]{Průchod neuronem\cite{ANN_neuron}}
Výstup jednotlivých neuronů vytváří sadu dalších vstupů pro další jednu vrstvu v pořadí. Tímto způsobem se postupně prochází veškeré vrstvy, až po vrstvu výstupní. Výstupní vrstva se liší od všech ostatních pouze tím, že obsahuje jeden neuron. Výstup toho neuronu lze uvažovat jako pravděpodobnost, nakolik je něco pravda či nikoli. V kontextu současné práce to znamená, jestli se daná transakce opakovala, či nikoli.
Příkladem by se dalo uvést následující: Pokud získám ze sítě hodnotu blízkou -1, transakce se pravděpodobně nebude opakovat. Analogicky pokud získám hodnotu blízkou 1, transakce by se měla opakovat. Zároveň platí, že čím více je výsledná hodnota blíže 0, tím menší je pravděpodobnost správné předpovědi.
Při bližším pohledu na fungovaní algoritmu si lze všimnout, že při násobení a sčítání vah platí následující vztah:
\begin{figure}[h]
\[ \begin{bmatrix} x_{1} \\ x_{2} \\ x_{3} \\ \vdots \\ x_{n} \end{bmatrix} \cdot
\begin{bmatrix} w_{1}, w_{2}, w_{3} \dots w_{n} \end{bmatrix} =
S
\]
\end{figure}
kde 'x' značí vstupy a 'w' váhy. 'S' je výsledek před vstupem do aktivační funkce.
Právě z tohoto důvodu jsou v řešení uvažovány váhy i vstupy jako vektory, které se navzájem násobí. K násobení vektorů je využito externí knihovny Math.NET Numerics (dostupné z \url{https://numerics.mathdotnet.com/}). Aktivační funkcí je hyperbolický tangens z integrované knihovny Math.Tangh()
\subsection{Export, import sítě}\label{ANNexportImport}
Aby bylo možné využít už jednou natrénovanou síť, je nutné si ji nějakým způsobem zapamatovat. Pro síť jsou důležité pouze dvě věci a totiž váhy neuronů společně s tvarem sítě. Tvarem sítě se rozumí množství vrstev a počet neuronů v nich obsažených.
Pro řešení uložení sítě si ji lze představit jako 3D objekt. Prvním rozměrem jsou vrstvy, druhým počet neuronů v každé vrstvě, a třetí jsou váhy v každém neuronu. Stejným způsobem se proto ukládají, resp. načítají do/z databáze.
\subsection{Testování funkčnosti neuronové sítě}
Pro zjištění funkčnosti sítě byly určeny nějaké dva primitivní problémy, které mají ověřit, že síť opravdu funguje. Prvním problémem/testem bylo předpovídání sudých a lichých čísel, druhým testování operátoru XOR pro dvě čísla.
Dále bylo třeba zjistit, zda při exportu sítě a následném importu nedojde k porušení struktury sítě, a bude fungovat i nadále.
\subsubsection{Sudá a lichá čísla}
Prvním bylo rozhodování se, jestli je číslo mezi nulou a sedmi sudé nebo liché. Čísla 0-7 byla zvolena, protože je lze v binární soustavě zapsat pomocí tří cifer. Jediný rozdíl byl, že se číslice 0 zapisovala jako -1. To je z důvodu, že nula způsobí vynulování, a tím pádem by nedocházelo ke správnému vyhodnocování vah. Využití číslic -1 a 1 bylo doporučeno i na konferenci Microsoftu \textit{Build 2013 - Developing Neural Networks using Visual Studio}\cite{MicrosoftBuild2013}. Při testování se podařilo síti předpovědět, jestli je číslo sudé či liché na 100\% (viz. obr. č. \ref{OddEvenTest}). Síť byla ve formě 3 - 3 - 3 - 1 s velikostí trénovací množiny 1000 a~minibatchem o~velikosti 100. Vzhledem k jednoduchosti testu (výsledek závisí jen a pouze na~jednom vstupu - ostatní jsou nepodstatné), změny na tvaru sítě neměly žádný větší vliv.
\begin{figure}[h]
\includegraphics[width=0.75\textwidth]{img/Odd_Even_Test_Evaluation.png}
\centering
\caption[Test sudých a lichých čísel]{Test sudých a lichých čísel}
\label{OddEvenTest}
\end{figure}
Druhým problémem byl operátor XOR. Tento operátor označuje množinovou operaci která je pravdou pouze pokud jedno z čísel má nulovou, resp. zápornou (-1), hodnotu a druhé kladnou (1). Jak už bylo naznačeno, pro test byla nulová hodnota nahrazena zápornou ze stejných důvodů, jako v předchozím testu.
První test probíhal na síti ve tvaru 2 - 3 - 3 - 1 (vstupem jsou dvě čísla) s velikostí trénovací množiny 1000 a~minibatchem o velikosti 100. Zde první číslo (2) značí vstupy a poslední (1) značí výstupy. Výsledek testování dosáhl úspěšnosti 67.1\% (viz. obr. č. \ref{XORTest}).
\begin{figure}[h]
\includegraphics[width=0.7\textwidth]{img/XOR_Test_Evaluation.png}
\centering
\caption[Test XOR operátoru s málo neurony]{Test XOR operátoru s málo neurony}
Bylo by možné tedy uvažovat, že téměř 3/4 vstupu byly odhadnuty správně, výsledek je proto lepší než čistý odhad, a lze jej považovat za dostatečný. Problém ale je, že síti byly poskytnuty veškeré možné vstupy a tudíž musí předpovědět 100\%.\cite{XORProblem} Řešením tedy je přidat větší množství neuronů a dat pro učení. Byl proto zvolen tvar 2-3-4-2-1 s velikostí trénovací množiny 10 000 a minibatchem opět o velikosti 100. Tentokrát bylo dosaženo lepšího výsledku (obr. č. \ref{XORTestSuccess}).
\begin{figure}[h]
\includegraphics[width=0.75\textwidth]{img/XOR_Test_EvaluationSuccess.png}
\centering
\caption[Test XOR operátoru s doplněnými neurony]{Test XOR operátoru s doplněnými neurony}
\label{XORTestSuccess}
\end{figure}
Zároveň na zmíněném testu lze i vidět, že tvar a velikost sítě mají vliv na~její výstup.
Export a import sítě lze ověřit snad jen jediným způsobem. A totiž exportováním již natrénované sítě a jejím následným naimportováním zpět. Pokud došlo ke korektnímu importu, síť bude nadále správně předpovídat testovaná data.
Bylo tedy implementováno simulované exportování a importování sítě a~ověřeno, jestli se předpovědi nezměnily. Výsledek opět dosáhl 100\%, proto lze předpokládat, že funkčnost je bezchybná (viz obr. č. \ref{ImportExportTest}).
\includegraphics[width=0.75\textwidth]{img/test_export_import.png}
\centering
\caption[Test exportu a importu sítě]{Test exportu a importu sítě}
\label{ImportExportTest}
\end{figure}
\subsection{Komparátor} \label{komparator}
Aby neuronová síť mohla vyhodnocovat, jestli se daná transakce opakuje, je nutné z dat nejdříve určit, které transakce se konkrétně opakovaly. Tento úkol bohužel není jednoznačný.
První myšlenka, která mnoho lidí napadne, je porovnávání výše transakce. Ne vždy platí, že pokud jsou dvě transakce stejně velké, automaticky se opakují. Lze ilustrovat na jednoduchém příkladu: Řekněme, že nějaký člověk, říkejme mu třeba Karel, si chodí ráno před prací kupovat snídani. Pokaždé si v obchodě koupí čerstvou bagetu. Problém ale nastává, pokud se bageta zlevní či zdraží, což je situace, která nastává relativně často. Bageta může být také někdy vyprodaná. Karel si stejně tak může každé ráno kupovat třeba pomeranče. To je položka, která nemá nikdy stejnou hodnotu a případné změny v ceně ještě zvyšují amplitudu. Navíc pomeranče mohou být ve špatném stavu, což ho bude nutit měnit potravinu, kterou kupuje. Tudíž není možné se rozhodovat podle identické ceny.
Druhá, související myšlenka, pak bývá: Pokud se nelze orientovat podle ceny, tak je možné se orientovat dle místa, potažmo čísla účtu. Tento případ opět není možný. Budeme-li dále používat Karla jako příklad, řekněme, že si kupuje ráno kávu. Pokud je venku pěkně, jde si ji koupit do stánku, kde se prodává káva levná a dobrá. Musí se ale posadit třeba na lavičku v parku. Pokud ale hezky není, jde si kávu koupit do kavárny, tedy úplně jiného podniku s úplně jiným číslem účtu. Stejně tak mohl zaspat a kávu si koupí až v~práci, třebaže mu příliš nechutná. V tom případě si koupil kávu za úplně jinou cenu a~ještě na jiném místě, s úplně jiným číslem účtu. Všechno to však lze považovat za opakující se transakci.
Jako možné řešení, které bylo implementováno, tedy je srovnávat transakce ze dvou různých časových úseků. Pro účely této práce byl zvolen rozsah jednoho týdne.
Jeden den je příliš malý rozsah, kdy se může stát, že dokonce nedošlo k~žádné transakci. Pokud by se porovnával měsíc, transakcí je poměrně mnoho. Běžný člověk má navíc obvykle při opakující se činnosti zažité určité rituály. Nejrozšířenější opakující se činnost bývá chození do práce či školy přes týden. Opakující se rituál potom může být pití kávy po příchodu do práce. Takové činnosti se opakují právě v rámci týdnů a porovnávání by tedy mělo být také v rámci násobků týdnů.
V praxi se rozlišují i aktivity na sudé a liché týdny (cvičení ve škole, pravidelné schůzky v práci, jež se konají ob jeden týden). Ideální by tedy bylo porovnávání transakcí po dvou týdnech. Z důvodu nedostatečného objemu obdržených dat, byl nakonec zvolen rozsah jednoho týdne.
Pokud tedy budou uvažovány transakce ze dvou různých týdnů, měla by se opakující se transakce vyskytovat v každém týdnu právě jednou. V jednom z týdnů ale bývá z pravidla transakcí více. Proto by se dalo optimistickým přístupem (člověk po většinu času opakuje činnost) říci, že opakujících se transakcí je právě minimum z počtu transakcí v těchto dvou týdnech. Zároveň jsou v relaci 1:1, tj. každá opakující se transakce v prvním týdnu má pravě jednu opakující se transakci v týdnu druhém. Zbylé transakce se neopakují.
Pro přiřazování do párů se transakce procházejí v cyklu, a ke každé transakci se vybere ta, která je ji hodnotou nejblíže. V každém průchodu cyklu se pro každou transakci z menší množiny hledá transakce z množiny větší taková, že rozdíl v jejich částce je nejmenší (tzv. vzdálenost musí být nejkratší). Při hledání těchto dvojic může dojít k duplicitnímu propojení (dvě a více transakcí z jedné množiny, považují jednu transakci z druhé množiny za nejbližší). V tom případě se vezmou dvě nejkratší vzdálenosti z tohoto vztahu. Celý cyklus se opakuje, dokud nejsou přiřazeny všechny transakce z menší množiny k~množině větší.
\subsubsection{Porovnávání vzdálenosti}
S touto implementací však vyvstává jeden problém. Toto \uv{optimistické} při-řazování transakcí ve skutečnosti říká, že týden s menší aktivitou je pod-množinou týdne s aktivitou větší. Jinými slovy - všechny platby jednoho z~týdnů jsou bezezbytku obsaženy v druhém. To zcela jistě není správně. Opakující se transakce jsou spíše průnikem těchto dvou týdnů (ne všechny se opakují). Je tedy opět třeba se zamyslet, jakým způsobem toto vyřešit.
První možností by bylo omezit počet opakování v cyklu, kdy se párují transakce. Ať už říci, že se cyklus nesmí procházet např. více než třikrát anebo musí zůstat alespoň pět nerozhodnutých transakcí. Při využití těchto přístupů ale není žádná kontrola nad samotnými transakcemi. Mohou zbýt transakce, které si jsou částkou blízké - to nastává třeba v případě, že dotyčný člověk jednoduše nenakupoval nic navíc a částky jsou si opravdu podmnožinou. Tak je možné, že mezi jednotlivými týdny nebyl finančně příliš aktivní a plateb je málo - všechny by se mohly vyfiltrovat jako neopakující se. To tedy nepoukazuje na dobré řešení.
Za mnohem korektnější přístup, by se dalo považovat porovnávání ještě podle relativní vzdálenosti jednotlivých částek. Tím je míněno, že hodnoty 10~Kč a 110~Kč se od sebe liší více, než například 5~000~Kč a 5~100~Kč. Obě hodnoty se v absolutním měřítku sice liší jen o sto korun, ale částky samotné se pohybují ve zcela jiných řádech. Avšak porovnávání řádů s hodnotou je poměrně abstraktní a jednoduché porovnání řádů s rozdílem částek nejde příliš jednoduše implementovat.
Za řešení lze považovat pohled z hlediska poměrů. Pokud se zůstane u~před-chozích částek, daly by se uvést do poměrů 110~:~10 a 5~100~:~5~000. Poměr pro první zmíněnou částku je roven 11, kdežto pro druhou 1.02. Zde už lze zřetelně vidět, jak moc se od sebe částky relativně liší.
Za povšimnutí však ještě stojí, že je třeba poměřovat vždy částku větší vůči menší, případně naopak. Je však nutné dodržovat pořadí velikostí. Po samotném přiřazení párů navíc není garantováno, která z částek je větší. Mohlo by tedy dojít k tomu, že by se porovnávala čísla normalizovaná do velikosti menší než jedna, s čísly většími než jedna. Takové porovnávání by dávalo zcela nesmyslné výsledky.
Ačkoli komparátor je poměrně složitý, jeho výstup už tak složitý není. Vše lze snadno porovnat z výpisu. Příklad vygenerovaného výpisu, s daty z poskytnuté transakční historie, je na obr. č. \ref{ComparatorTest}.
\begin{figure}[h]
\includegraphics[width=0.75\textwidth]{img/ComparatorTest.png}
\centering
\caption[Test komparátoru]{Test komparátoru}
\label{ComparatorTest}
\end{figure}
Lze zde pozorovat, jak se jednotlivé částky na sebe namapovaly (označeno šipkou) a jak jsou od sebe vzdáleny (v závorce). Transakce, které se nepodařilo přiřadit, jsou vypsány v části \uv{Major}. Ty jsou tedy označeny za neopakující se.
Část, v práci pojmenovaná jako Datafeeder, vychází z anglických slov \textit{\uv{data}} a \textit{\uv{feeder}} -- v doslovném překladu \uv{data-krmítko}. Tato funkcionalita slouží pro načítání dat do neuronové sítě. Je také poměrně jednoduchá. Jako vstupní parametry dostane uživatele, jehož data má načítat, a počet \uv{\textit{epoch}}, které má projít. Epochou se rozumí určité časové období. Z výše zmíněných důvodů byla pro účely této práce jedna epocha definována jako týden.
Po načtení vstupních parametrů, se vytvoří dotaz do databáze, který načte dvě epochy a pomocí komparátoru doplní označení o opakujících se transakcích (viz. sekce \ref{komparator} Komparátor). Dále data normalizuje a předá neuronové síti, jež tyto transakce postupně po jedné zpracuje.
\subsection{Normalizace dat}\label{normalization}
Pro vyhodnocování neuronovou sítí je důležité mít data v rozmezí nějakého konstantního intervalu. Zde byl konkrétně zvolen ve velikosti \textless -1,1\textgreater . Interval je definován z toho důvodu, že pokud by došlo k jeho překročení některými ze vstupních dat, mohlo by to způsobit \uv{přebíjení}~ostatních vah v neuronu. Jinými slovy, výše aktivace neuronu by závisela na několika vstupních datech a ostatní by se ignorovala.
První položkou, která se normalizuje, je datum transakce. Datum samo o~sobě není příliš vypovídající, proto by se tato akce dala považovat i za lehké obohacení dat. Pro normalizaci je totiž využito skutečnosti, že týden se dělí do sedmi dnů (pondělí -- pátek). Z data transakce se tedy zjistí, v který den v~týdnu transakce proběhla, a zároveň se vytvoří sedm neuronů. Každý z~nich bude mít hodnotu 1 nebo -1 (krajní body intervalu) podle toho, který den transakce proběhla.
Kupříkladu na vstupu přijde transakce, která proběhla v pondělí. Po normalizaci vznikne šest neuronů, s hodnotou -1, jež jsou obrazem všech dnů v~týdnu mimo pondělí a jeden, zobrazující pondělí, jež má hodnotu 1.
Je třeba poznamenat, že hodnota 0 není zvolena záměrně. Uvnitř sítě se jednotlivé vstupy násobí s jednotlivými váhami. Nula není z hlediska násobení neutrální prvek, a zároveň při násobení nulou vždy vznikne nula. Tím by došlo k znehodnocení vah, a proto je místo nuly zvoleno -1.
Další položkou jsou Konstantní symboly. Konstantní symbol je, obdobně jako datum, číselně další neurčitou položkou. V sekci \ref{ObohaceniDat} Obohacení dat je však rozdělen do jednotlivých kategorií. Ty jsou definovány jako samostatné položky v několika tabulkách databáze. Z toho vychází i způsob implementace - jsou definovány jako výše zmíněný datum. Tedy pro každou položku je vytvořen neuron s hodnotou -1, kromě položek, pod který konstantní symbol spadá. Těm je přiřazena hodnota 1.
\newline
Poslední položka k normalizaci je výška transakce. Správnou hodnotu není lehké určit. Není totiž možné určit maximální velikost transakce. Úvaha pro normalizace byla tedy založena na základě výše škody, dle trestního práva. Z~hlediska trestního práva jsou částky rozděleny následovně:
\item Škoda nikoli nepatrná – nejméně 5 000 Kč,
\item Škoda nikoli malá – nejméně 25 000 Kč,
\item Větší škoda – nejméně 50 000 Kč,
\item Značná škoda – nejméně 500 000 Kč,
\item Škoda velkého rozsahu – nejméně 5 000 000 Kč.\cite{velikostSkody}
\end{enumerate}
K rozdělení byla přidána ještě jedna částka 500 Kč. Ta vychází z limitu pro bezkontaktní platby kartou, kdy není třeba zadávat kód PIN.\cite{wirelessLimit}.
Tímto principem zároveň došlo k rozdělení přesně na šest druhů transakcí. Číslo šest je sudé, a vzhledem k tomu, že je částky potřeba normalizovat do intervalu \textless -1,1\textgreater , přímo se vybízí rozdělit tyto kategorie na dvě části. Konkrétně 0~--~25~000~Kč v intervalu \textless -1;0), a vše od 25~000~Kč výše v~intervalu (0;1\textgreater .
Částky jsou však stále vysoké. Aby je bylo možné využít, bylo třeba vytvořit nějakou funkci, která by je rozprostřela do jednotlivých úsekových intervalů. K tomu se výborně hodí obdoba aktivační funkce (squashing function) ze sekce \ref{predvidani} Předpovídání. Ta částku snižuje na~velikost v intervalu (0,1).
Aby byly částky rozděleny do zmíněných šesti kategorií, stačí funkci rozdělit na šestiny, s aktivační funkcí přizpůsobenou jednotlivým částkám. Pro aktivační funkci byl zvolen tanh a částky roztaženy na celý interval pomocí \uv{magických konstant}. Tyto konstanty byly voleny tak, že se pro každý úsek postupně zkoušela náhodná čísla tak, aby poslední číslo intervalu bylo co nejblíže začátku intervalu navazujícího. Výsledkem měla být co možná nejvíce souvislá funkce. Výpočet pro jednotlivé úseky vznikl následující:
505
506
507
508
509
510
511
512
513
514
515
516
517
518
519
520
521
522
523
524
525
526
527
528
529
530
531
532
533
534
\begin{enumerate}[1)]
\item 0 -- 500 Kč
\begin{enumerate}[]
\item $ \frac{tanh(\frac{x}{189})}{3}-1 $
\end{enumerate}
\item 500 -- 5 000 Kč
\begin{enumerate}[]
\item $ \frac{tanh(\frac{x-500}{1889})+1}{3}-1 $
\end{enumerate}
\item 5 000 -- 25 000 Kč
\begin{enumerate}[]
\item $ \frac{tanh(\frac{x-5000}{9446})+2}{3}-1 $
\end{enumerate}
\item 25 000 -- 50 000 Kč
\begin{enumerate}[]
\item $ \frac{tanh(\frac{x-25000}{18892})}{3} $
\end{enumerate}
\item 50 000 -- 500 000 Kč
\begin{enumerate}[]
\item $ \frac{tanh(\frac{x-50000}{188918})+1}{3} $
\end{enumerate}
\item 500 000 -- 5 000 000+ Kč
\begin{enumerate}[]
\item $ \frac{tanh(\frac{x-500000}{1889180})+2}{3} $
\end{enumerate}
\end{enumerate}
Detailní rozložení lze též pozorovat na obr. č. \ref{ExpenseNormalization} Normalizace částky
\begin{figure}
\includegraphics[width=1\textwidth]{img/normalization0-25000.pdf}
\includegraphics[width=1\textwidth]{img/normalization25000+.pdf}
\includegraphics[width=1\textwidth]{img/normalizationAll.pdf}
\centering
\caption[Normalizace částky]{Normalizace částky}
\label{ExpenseNormalization}
\end{figure}
Jednotlivé předpovědi byly ještě rozšířeny o předpovědi bez strojového učení. Ty prochází data a pokouší se z nich získat další závislosti.
\subsection{Předpovídání na základě velikostí transakce}
Pro tuto předpověď bylo využito komparátoru ze sekce \ref{komparator}. Načtou se data za poslední týden a porovná se jejich částka s týdnem předchozím. Na základě dříve popsaných poměrů rozdílu v počtu transakcí se pak rozhodne, jestli došlo k opakování transakce, či nikoli.
Z transakcí určených jako opakující se, se určí kategorie na základě hodnot konstantních symbolů, jimiž byla data obohacena. Konkrétně se využívá jednotlivých tříd (třetí cifry v konstantním symbolu). Pokud tato třída není k dispozici nebo se konstantní symbol řadí mezi tzv. \uv{rezervované symboly}, kategorie se označí jako \uv{nerozhodnutá}.
Další kategorií je pak rozdělení dle velikosti jako takové. Rozdělení se v~tomto případě řídí velikostmi ze sekce \ref{normalization} Normalizace. Názvy pak byly zvoleny následovně:
\item do 500 Kč = Drobné,
\item 500 -- 5 000 Kč = Malé,
\item 5 000 -- 25 000 Kč = Střední,
\item 25 000 -- 50 000 Kč = Velké,
\item 50 000 -- 500 000 Kč = Velmi velké,
\item nad 500 000 Kč = Značně velké.
\subsection{Předpovídání na základě průměru}
Při předpovídání na základě průměru byla data rozdělena do tří dimenzí. První dimenzí je rok. Ten byl rozdělen do po sobě jdoucích, čtyřtýdenních celků, reprezentujících měsíce. Každý týden byl následně rozdělen na jednotlivé dny (pondělí -- neděle). Tedy každý rok má třináct čtyřtýdenních celků, rozdělených dále na dny v týdnu.
Průměrování probíhá po jednotlivých dnech mezi zmíněnými čtyřtýdenními celky. Např. hodnoty z pondělí z prvního týdne daného celku se zprůměrují s~hodnotami jednotlivých pondělí pro veškeré první týdny a pro veškeré roky.
Tímto průměrováním se získá průměrná velikost a počet transakcí pro následující čtyři týdny. Uživateli je pak zobrazen pravděpodobný průběh útraty za tuto dobu a zároveň odhadová útrata na každý den v týdnu.
Databáze by se dala rozdělit na čtyři samostatné celky. Každý celek je ale strukturovaný a propojený s ostatními. Níže jsou všechny popsány i s doprovodnými výřezy diagramu. Kompletní diagram databáze je však příliš rozsáhlý pro vložení do textu. Je proto přiložen mezi externími přílohami typu \ref{DBdiagram} jako obrázek s názvem \textit{DB\textunderscore diagram.png}.
První částí je ukládání dat o uživateli. Pomyslnou hlavní tabulkou je \uv{User}. Obsahuje uživatelská jména registrovaných uživatelů a heslo, které je zahashované a propojené se solí.
Pro každého uživatele si též v tabulce \uv{Files} ukládá informace, jaké soubory nahrál, resp. jejich jméno a obsah. Je zde ale vystaveno omezení na~uklá-dání souborů tak, aby bylo jejich jméno, v rámci uživatele, unikátní. Omezení bylo vytvořeno z důvodu zabránění nahrávání duplicitních souborů, které je těžké odhalit. Uživatel sice může stále upravit jméno a soubor nahrát, tímto způsobem je ale upozorněn, že už systém data pravděpodobně obsahuje.
Další výhoda této tabulky tkví v tom, že pokud si uživatel přeje smazat nahraný soubor, jsou známy transakce, které jsou k danému souboru navázány.
\begin{figure}[H]
\includegraphics[width=0.55\textwidth]{img/model-user.jpg}
\centering
\caption[Model databáze - uživatel]{Model databáze - uživatel}
\label{ModelUser}
\end{figure}
\subsection{Transakce}
Další položka databáze jsou jednotlivé transakce. Ty představují pomyslné centrum databáze, protože jsou hlavní informací, od které se veškerá činnost odvíjí. Obsahuje načtená data transakce - datum transakce, částku, poznámku, symboly, účty příjemce i plátce a případný typ transakce.
Dále jsou zde napojeny odkazy na tabulky se záznamy, o~jaký typ transakce se jednalo, i jaké byly účty příjemce a plátce.
\centerline{\includegraphics[width=1.05\textwidth]{img/model-transactions.png}}
\caption[Model databáze - transakce]{Model databáze - transakce}
\label{ModelTransaction}
\end{figure}
\subsection{Konstantní symbol}
Konstantní symboly v databázi jsou hlavně číselníkem. Slouží k obohacení transakcí, a jaký mají význam, již bylo zmíněno v sekci \ref{RealizaceObohaceni} Obohacení.
Tato část obsahuje tabulku \uv{\textit{ConstantSymbol}}, což je entita, na kterou je odkazováno z \uv{\textit{Transactions}}. Definuje, jestli případný konstantní symbol, který uživatel vložil, je validní. Pokud ano, naváže na sebe jednotlivé číselníky, pro které je symbol definován. Těmito číselníky se rozumí \textit{\uv{Kind}} (druh transakce), \textit{\uv{LastNumber}} (význam poslední číslice), \textit{\uv{MinistryPredefined}} (Předdefinované třídy MFČR) a \textit{\uv{ReservedSymbol}} (Rezervované symboly).
Poslední tabulkou je \textit{\uv{ForeignPayment}}, jež slouží k odlišení zahraničních transakcí.
\begin{figure}[h]
\includegraphics[width=0.55\textwidth]{img/model-KS.png}
\centering
\caption[Model databáze - konstantní symbol]{Model databáze - konstantní symbol}
\label{ModelKS}
\end{figure}
\subsection{Neuronová síť}
Poslední částí databáze je neuronová síť. Slouží k ukládání vypočítaných nastavení, aby natrénovanou síť bylo možné později znovu použít. Systém ukládání funguje dle logiky zmíněné v sekci \ref{ANNexportImport} Export, Import sítě.
V databázi je seznam sítí (\textit{\uv{Network}}). Každá se potom dělí na další podseznamy -- vrstvy (\textit{\uv{Layer}}), a ty dále na neurony (\textit{\uv{Neuron}}). Jako poslední seznam je seznam vah (\textit{\uv{Weights}}) ke korespondujícím neuronům.
\begin{figure}[h]
\includegraphics[width=0.55\textwidth]{img/model-ann.png}
\centering
\caption[Model databáze - neuronová síť]{Model databáze - neuronová síť}
\label{ModelANN}
\end{figure}
%TODO maybe student má takové výsledky, důchodce makové výsledky
\chapter{Výsledné uživatelské rozhraní}
Výsledné uživatelské rozhraní má dohromady tři obrazovky. Přihlašovací, kterou uživatel vidí jako první při načtení aplikace. Druhou obrazovkou je registrační formulář, aby uživatel mohl aplikaci použít. Poslední obrazovka, tvořící hlavní část aplikace, je dostupná po přihlášení. Obsahuje grafy, které ukazují, jak se pravděpodobně uživatel bude chovat po finanční stránce v následujících dnech.
Přihlašovací obrazovka obsahuje formulář pro zadání uživatelského jména a~he-sla. Dále obsahuje odkaz na stránku pro registraci, pro uživatele, kteří se do aplikace ještě nezaregistrovali.
\includegraphics[width=0.9\textwidth]{img/screen_login.png}
\centering
\caption[Uživatelské rozhraní - přihlašovací obrazovka]{Uživatelské rozhraní - přihlašovací obrazovka}
\label{ScreenLogin}
\end{figure}
\section{Registrační obrazovka}
Registrační obrazovka vychází z obrazovky přihlašovací. Obsahuje formulář pro vytvoření uživatelského jména, hesla a odkaz zpět na přihlašovací obrazovku pro uživatele, jež klikli omylem na odkaz pro registraci.
\includegraphics[width=0.9\textwidth]{img/screen_registration.png}
\centering
\caption[Uživatelské rozhraní - registrační obrazovka]{Uživatelské rozhraní - registrační obrazovka}
\label{ScreenRegistration}
\end{figure}
\section{Hlavní obrazovka}
Hlavní obrazovka je nejsložitější. V záhlaví obsahuje dropdown menu, jenž po rozkliknutí nabídne odhlášení, změnu hesla a zrušení účtu. V případě, že dojde k výběru odhlášení, uživatel je automaticky přesměrován na hlavní obrazovku. Pokud ale naopak vybere možnost pro změnu hesla nebo zrušení účtu, zobrazí se dialog pro potvrzení a zadání hesla.
\begin{figure}[h]
%\hspace{1.7cm}
$\vcenter{\hbox{\includegraphics[width=1\textwidth]{img/screen_menu.png}}}$
\vspace{.3cm}
$\vcenter{\hbox{\includegraphics[width=0.4\textwidth]{img/screen_delete_account.png}}}$
\hspace*{.2in}
$\vcenter{\hbox{\includegraphics[width=0.32\textwidth]{img/screen_change_password.png}}}$
\centering
\caption[Uživatelské rozhraní - menu a účet]{Uživatelské rozhraní - menu a účet}
\label{ScreenMenuAccount}
\end{figure}
Pod záhlavím je obrazovka rozdělena na dalších pět částí. První z nich je část pro nahrání souboru obsahující výpis z účtu a pod ním je seznam všech úspěšně nahraných souborů. V tomto seznamu je zároveň tlačítko, které umožňuje uživateli libovolný soubor snadno odstranit.
Druhou částí jsou čtyři grafy, zobrazující jaké měl uživatel doposud výdaje. První z nich, sloupcový, ukazuje souhrnnou velikost transakcí za poslední čtyři týdny. Další tři jsou koláčové. První zobrazuje poměr velikostí transakcí (rozdělené na drobné, malé, střední, velké atd.). Druhý i třetí graf pak využívají konstantní symboly k zobrazení, jakého druhu transakce pravděpodobně byly.
\includegraphics[width=1\textwidth]{img/screen_history.png}
\centering
\caption[Uživatelské rozhraní - uživatelská historie]{Uživatelské rozhraní - uživatelská historie}
\label{ScreenUserHistory}
\end{figure}
Zbylé části obrazovky tvoří samotné předpovědi. Nejdříve se zobrazuje předpověď základě umělé inteligence. Tu tvoří seznam pravděpodobných plateb na týden od nahrání historie, doplněný o typ plateb (odhadnutý z hodnot konstantních symbolů) a koláčový graf, který tyto transakce dává do poměru stejným způsobem, jako předešlý graf historie.
\begin{figure}[h]
\includegraphics[width=1\textwidth]{img/screen_ann.png}
\centering
\caption[Uživatelské rozhraní - předpověď neuronovou sítí]{Uživatelské rozhraní - předpověď neuronovou sítí}
\label{ScreenANN}
\end{figure}
Druhá předpověď, založená na průměru všech transakcí, zobrazuje čárový graf s odhadovanými výdaji na další čtyři týdny a koláčový graf pro předpovědi na jednotlivé dny v týdnu.
Poslední předpověď, tvořící zároveň poslední sekci obrazovky, je předpovídání na základě porovnávání částek. Z této předpovědi vychází seznam pravděpodob-ných transakcí na další týden (strukturovaný stejně jako seznam pro předpovídání neuronovou sítí), koláčové grafy s druhem transakcí, vycházejících z konstantních symbolů a poměrnou velikostí transakcí.
\includegraphics[width=1\textwidth]{img/screen_average_amount.png}
\centering
\caption[Uživatelské rozhraní - předpověď průměrem a hodnotou]{Uživatelské rozhraní - předpověď průměrem a hodnotou}
\label{ScreenANN}
\end{figure}
Aby se zjistilo, jestli aplikace funguje správně, je nutné ji nejdříve řádně otestovat. K tomu bylo využito zejména manuálního testování.
Při manuálním testování se kontrolovalo, jestli veškeré funkcionality pracují správně a jestli se změny projevily i v databázi. Výsledky na webu byly poté zachyceny a vloženy do práce.
Když uživatel vybírá soubory s transakční historií, v základním nastavení jsou mu nabízeny soubory s příponou *.csv. Pokud vybere jiný anebo se pokusí koncovku souboru podvrhnout, aplikace soubor odmítne. Totéž se stane v~případě, že se pokusí nahrát soubor se stejným názvem, který již dříve nahrál.
Pokud ale dojde k nahrávání platného souboru, je zobrazena hláška o~nahrá-vání a po dokončení je uživatel informován, jestli byl soubor v pořádku nahrán, či nikoli.
$\vcenter{\hbox{\includegraphics[width=0.5\textwidth]{img/import_error.png}}}$
\hspace*{0.1cm}
$\vcenter{\hbox{\includegraphics[width=0.48\textwidth]{img/import_loading.png}}}$
\vspace{0.5cm}
$\vcenter{\hbox{\includegraphics[width=0.5\textwidth]{img/import_succesful.png}}}$
\caption[Jednotlivé stavy nahrávání souborů]{Jednotlivé stavy nahrávání souborů
\newline
\textit{Stav vlevo nahoře zobrazuje oznámení o neúspěšném nahrání souboru (chybu), vpravo nahoře je zobrazeno probíhající nahrávání souboru. Poslední možný stav (dole) zobrazuje oznámení o úspěšném nahrání souboru.}
}
\label{fileUpload}
\end{figure}
Další možností, jak může uživatel změnit data, je změna hesla. Aby toho však dosáhnul, musí nejdříve vyplnit formulář, do kterého je třeba vložit jednou staré heslo, nové heslo a kontrolní heslo. Všechna pole se ve formuláři validují. Pokud se nové a kontrolní heslo neshodují, není dovoleno uživateli formulář odeslat. Obdobně pokud zadá nesprávně své staré heslo, změna mu~není povolena.
\begin{figure}[h]
$\vcenter{\hbox{\includegraphics[width=0.3\textwidth]{img/changePassword_validation.png}}}$
\hspace*{.2in}
$\vcenter{\hbox{\includegraphics[width=0.3\textwidth]{img/changePassword_compare.png}}}$
\hspace*{.2in}
$\vcenter{\hbox{\includegraphics[width=0.3\textwidth]{img/changePassword_wrongPassword.png}}}$
\centering
\caption[Validace formuláře na změnu hesla]{Validace formuláře na změnu hesla
\newline
\textit{Vlevo nahoře stav, kdy uživatel nevyplnil žádné pole, vpravo nahoře zadal do formuláře dvě různá hesla. Poslední stav (dole) ukazuje situaci, kdy uživatel zadal špatné původní heslo.}
}
\label{changePasswordValidation}
\end{figure}
Se změnou hesla do jisté míry souvisí i smazání celého uživatele. Aby mohl svůj účet smazat, musí se také nejdříve autentizovat svým starým heslem. Pokud ho zadá špatně, není dovoleno mu účet smazat. Pokud ale heslo zadá správně, je jeho účet smazán i se všemi nahranými soubory a transakcemi, je odhlášen a přesměrován na přihlašovací obrazovku.
Aplikace má na starost i správu uživatelských účtů. V případě, že se uživatel pokusí přihlásit neplatným heslem, zobrazí se mu chybová hláška a~systém ho nepustí dále. Obdobně, pokud se pokusí registrovat s uživatelským jménem, které již je použito, zobrazí se mu chyba, informující o této skutečnosti.
\begin{figure}[h]
$\vcenter{\hbox{\includegraphics[height=0.35\textwidth]{img/login_wrongPassword.png}}}$
\hspace*{.2in}
$\vcenter{\hbox{\includegraphics[height=0.4\textwidth]{img/registration_alreadyExist.png}}}$
\centering
\caption[Validace přihlašovacích údajů]{Validace přihlašovacích údajů
\newline
\textit{Vlevo přihlašovací obrazovka, kde uživatel zadal neplatné přihlašovací údaje, vpravo registrační obrazovka, kde se uživatel pokusit registrovat pomocí uživatelského jména, které již byl dříve použito.}}
Při přihlašování i registraci jsou zároveň validovány formuláře samotné. Pokud tedy uživatel vynechá jedno z povinných polí, zobrazí se mu k~danému poli upozornění. Navíc, pokud formulář obsahuje chybu, uživatel nemá možnost jej odeslat (tlačítko je neaktivní).
\begin{figure}[h]
$\vcenter{\hbox{\includegraphics[height=0.5\textwidth]{img/login_emptyError.png}}}$
\hspace*{.2in}
$\vcenter{\hbox{\includegraphics[height=0.5\textwidth]{img/registration_emptyError.png}}}$
\centering
\caption[Validace polí na formuláři]{Validace polí na formuláři
\newline
\textit{Přihlašovací formulář (vlevo) a registrační formulář (vpravo), když uživatel nevyplní žádné z polí}}
\label{formEmptyError}
\end{figure}
Pokud se uživatel pokusí přejít na stránku pro registrované uživatele, aplikace to zaznamená, a pokud není přihlášen, vrátí jej zpět na přihlašovací obrazovku. Pokud se ale uživatel neodhlásil a nevypršela mu doba trvání přihlášení, aplikace jej na zabezpečenou stránku pustí a zobrazí mu jeho data.
\subsection{Uživatel bez JavaScriptu}
Existuje i možnost, že na stránku přistoupí uživatel, který nemá zapnutý JavaScript. To je jazyk, ve kterém je napsán celý Angular framework a tím pádem bez ní aplikace nebude fungovat. Pokud však uživatel bez zapnutého JavaScriptu na stránku přistoupí, zobrazí se mu chybová hláška, že je třeba mít povolen JavaScript.
\begin{figure}[h]
\includegraphics[width=0.55\textwidth]{img/JavaScript_error.png}
\centering
\caption[Nepovolený JavaScript v prohlížeči]{Nepovolený JavaScript v prohlížeči}
\label{JavaScriptError}
\end{figure}
\subsection{Responzivita}
Jednou z podmínek práce je, aby byla aplikace responsivní. Tedy, že web bere ohled na velikost prohlížeče uživatele. Toho bylo docíleno použitím tzv. breakpointů v CSS (značky, které definují vzhled obrazovky pro různě velká okna). Výsledek této operace se textově špatně demonstruje. Jako ukázka funkčnosti ale snad dobře poslouží pár obrázků níže.
\begin{figure}[h]
$\vcenter{\hbox{\includegraphics[width=0.7\textwidth]{img/responsivity_full.png}}}$
\hspace*{.2in}
$\vcenter{\hbox{\includegraphics[height=0.6\textwidth]{img/responsivity_min.png}}}$
\centering
\caption[Responzivita -- porovnání obrazovek]{Responzivita -- porovnání obrazovek}
\label{responsivityComparsion}
\end{figure}
Pro testování kvality aplikace bylo využito výpisu transakční historie z vlastní-ho účtu, která byla oříznuta o jeden měsíc a porovnána s historií původní. Tím vznikl obraz, nakolik jsou jednotlivé předpovědi přesné.
Vlastní historie byla vybrána v časovém úseku od 1.1.2019 do 31.8.2019 a~byla porovnávána s následujícími 28 dny. Navíc své vlastní transakce znám a to umožňuje lepší náhled na to, které předpovědi jsou špatně a které dobře. Daný úsek byl zase vybrán z toho důvodu, že jsem se v tu dobu choval podobně (náhlá změna chování by nepříznivě ovlivnila výsledky).
\subsection{Předpověď opakujících se transakcí}
Opakující se transakce jsou vyhodnocovány pomocí posledních dvou týdnů nahrané historie. Tyto týdny určí, jak se bude uživatel chovat později.
Vyhodnocení, které transakce se opakují a které nikoli, je velmi individuální. Pro testy byly vybrány ty částkou si blízké a jsou zobrazeny níže (spolu s tabulkou veškerých provedených transakcí)
\newpage
%\vspace{0.5cm}
\hspace{-0.9cm}
\scalebox{0.89}{
\multicolumn{4}{|c|}{Provedené transakce (v Kč)} \\\hline
1. týden & 2. týden & 3. týden & 4. týden \\\hline
15,00 & 15,00 & 15,00 & 15,00 \\\hline
100,00 & 43,00 & 25,20 & 15,00 \\\hline
118,00 & 70,30 & 88,00 & 15,00 \\\hline
123,00 & 86,00 & 90,00 & 80,00 \\\hline
180,00 & 113,00 & 95,00 & 120,00 \\\hline
248,00 & 119,00 & 140,00 & 120,00 \\\hline
250,00 & 124,00 & 159,00 & 135,00 \\\hline
280,00 & 250,00 & 159,90 & 135,00 \\\hline
465,00 & 347,60 & 180,00 & 154,00 \\\hline
500,00 & 857,70 & 250,00 & 239,00 \\\hline
580,00 & 1302,00 & 556,00 & 250,00 \\\hline
1146,00 & & 1000,00 & 500,00 \\\hline
1470,00 & & 1596,74 & \\\hline
\end{tabular}
\multicolumn{4}{|c|}{Transakce které se opakují (v Kč)} \\\hline
1. týden & 2. týden & 3. týden & 4. týden \\\hline
15 & 15 & 15 & 15 \\\hline
100 & 86 & 88 & 80 \\\hline
118 & 113 & 95 & 120 \\\hline
123 & 119 & 140 & 135 \\\hline
180 & 124 & 159 & 135 \\\hline
250 & 250 & 250 & 250 \\\hline
465 & 347,60 & 556 & 500 \\\hline
\end{tabular}
Pro tabulku předpovědí je však nutné dodat, že částka 250,00 Kč se začala objevovat až od 1.9.2019. Tato částka tvoří pomyslnou změnu chování uživatele a přestože je později v tabulkách s daty uvedena, nebyla uvažována jako špatná předpověď, vzhledem k tomu, že algoritmy neměly dostatečná data k jejím předpovězení.
Další informací, kterou je třeba zmínit, je, že aplikace nerozlišuje týden, na který se vydává předpověď. Pro první i čtvrtý týden je předpověď stejná. To je také důvodem, proč se pro vyhodnocení správnosti nepovažují transakce kolem jednoho tisíce korun, provedené v prvních třech týdnech, za opakující se. Čtvrtý už totiž obsahuje jen transakce do pěti set korun a tím označuje všechny transakce výrazně převyšující tuto částku na neopakující se.
\subsubsection{Předpověď neuronovou sítí}
Neuronová síť dokázala předpovědět čtyři transakce a dvě vynechala. To je ekvivalentem 66,7\%, tedy nadpoloviční většina.
\multicolumn{5}{|c|}{Predikce neuronovou sítí (v Kč)} \\\hline
1. týden & 2. týden & 3. týden & 4. týden & predikce \\\hline
15,00 & 15,00 & 15,00 & 15,00 & 19,00 \\\hline
100,00 & 86,00 & 88,00 & 80,00 & \\\hline
118,00 & 113,00 & 95,00 & 120,00 & 120,00 \\\hline
123,00 & 119,00 & 140,00 & 135,00 & \\\hline
180,00 & 124,00 & 159,00 & 135,00 & 148,50 \\\hline
250,00 & 250,00 & 250,00 & 250,00 & \\\hline
465,00 & 347,60 & 556,00 & 500,00 & 420,00 \\\hline
\end{tabular}
Nevyplněná pole v tabulce (sloupec predikce) označují, v kterých případech se neuronové síti nepodařilo předpovědět opakování transakcí. Naopak částky označují odhadovanou velikost.
\subsubsection{Předpověď porovnáním částky}
Předpovídání opakujících se transakcí na základě částky bylo méně úspěšné, než předpovídání neuronovou sítí. Tento algoritmus sice byl schopen předpovědět všechny opakující se transakce, avšak uvedl dalších pět transakcí, jež se zřejmě neopakovaly.
Celková úspěšnost předpovědi byla stanovena jen jako 16,67\%. Tato hodnota byla stanovena tak, že se každá špatná předpověď odečetla od předpovědi správné. Bylo šest opakujících se transakcí a pět špatně předpovězených. Výsledek proto byl spočten následovně: \mbox{6-5/6 = 0,1667}
\multicolumn{5}{|c|}{Předpověď porovnáním částky (v Kč)} \\\hline
1. týden & 2. týden & 3. týden & 4. týden & predikce \\\hline
15,00 & 15,00 & 15,00 & 15,00 & 15,00 \\\hline
& & & & 15,00 \\\hline
& & & & 15,00 \\\hline
& & & & 19,00 \\\hline
100,00 & 86,00 & 88,00 & 80,00 & 82,70 \\\hline
118,00 & 113,00 & 95,00 & 120,00 & 100,00 \\\hline
123,00 & 119,00 & 140,00 & 135,00 & 133,00 \\\hline
180,00 & 124,00 & 159,00 & 135,00 & 138,00 \\\hline
& & & & 146,90 \\\hline
& & & & 148,50 \\\hline
250,00 & 250,00 & 250,00 & 250,00 & \\\hline
465,00 & 347,60 & 556,00 & 500,00 & 420,00 \\\hline
\end{tabular}
V přiložené tabulce lze, obdobně jako v předcházející sekci, ve sloupci predikce vidět, jaké částky byly odhadovány. Řádky s nevyplněnými poli v jednotlivých týdnech potom ukazují, které hodnoty byly předpovídány jako opakují se, ač tomu tak nebylo.
\subsection{Předpověď velikosti výdajů}
Predikce výdajů představuje odhad kumulativní částky všech transakcí pro budoucí dny a to na základě průměru ze všech nahraných dat. Neuvažují tedy pouze opakující se transakce.
\subsubsection{Předpověď na následující čtyři týdny}
Odhad na následující čtyři týdny obsahuje 28 položek, přičemž každou položku lze považovat za samostatný text.
Úspěšnost vyhodnocení byla rozdělena na částku a množství transakcí. Odhad částky se povedl pouze u jedné čtvrtiny všech dnů, tedy rovných 25\%. Pro množství transakcí k danému dni byl výsledek lepší. V tomto případě se povedlo odhadnout jedenáct dnů správně, tzn. 39,29\%. Kumulativní úspěšnost předpovědi je pak rovna 32,14\%.
\newcommand{\breakcell}[2]{
\vbox{\setbox0\hbox{\strut #2}\hbox to\wd0{\hss\strut #1\hss}\copy0}
}
884
885
886
887
888
889
890
891
892
893
894
895
896
897
898
899
900
901
902
903
904
905
906
907
908
909
910
911
912
913
914
915
916
917
\begin{tabular}{|c |c |c |c |c |c |c |c|}
\hline
\multicolumn{7}{|c|}{Předpověď na následující čtyři týdny} \\\hline
\multirow{3}{*}{Den} & \multicolumn{2}{c|}{Test} & \multicolumn{2}{c|}{Odhad} & \multicolumn{2}{c|}{Správně} \\
& \breakcell{útrata}{(v Kč)} & \breakcell{počet}{transakcí} & \breakcell{útrata}{(v Kč)} & \breakcell{počet}{transakcí} & \raisebox{0.5em}{útrata} & \breakcell{počet}{transakcí}\\\hline
1 & 0,00 & 0 & 284,10 & 1,00 & ne & ne\\\hline
2 & 0,00 & 0 & 1381,16 & 1,67 & ne & ne\\\hline
3 & 1646,00 & 2 & 252,82 & 1,38 & ne & ano \\\hline
4 & 963,00 & 3 & 147,96 & 1,56 & ne & ne \\\hline
5 & 133,00 & 2 & 352,78 & 2,13 & ne & ano \\\hline
6 & 1930,00 & 3 & 373,97 & 2,40 & ne & ano \\\hline
7 & 803,00 & 3 & 476,00 & 1,20 & ne & ne \\\hline
8 & 347,60 & 1 & 312,00 & 2,17 & ano & ne \\\hline
9 & 2159,70 & 2 & 2559,11 & 2,20 & ano & ano \\\hline
10 & 70,30 & 1 & 688,84 & 2,40 & ne & ne \\\hline
11 & 503,00 & 4 & 194,21 & 2,13 & ne & ne \\\hline
12 & 113,00 & 1 & 481,39 & 2,00 & ne & ne \\\hline
13 & 134,00 & 2 & 352,55 & 2,50 & ne & ano \\\hline
14 & 0,00 & 0 & 274,36 & 2,17 & ne & ne\\\hline
15 & 646,00 & 2 & 162,80 & 2,80 & ne & ano \\\hline
16 & 1180,00 & 2 & 119,44 & 2,33 & ne & ano \\\hline
17 & 1596,74 & 1 & 286,05 & 1,00 & ne & ano \\\hline
18 & 409,90 & 2 & 288,41 & 2,00 & ano & ano \\\hline
19 & 95,00 & 1 & 231,05 & 3,00 & ne & ne \\\hline
20 & 299,00 & 2 & 276,09 & 2,86 & ano & ano \\\hline
21 & 128,20 & 3 & 225,56 & 3,00 & ano & ano \\\hline
22 & 610,00 & 4 & 192,30 & 2,00 & ne & ne \\\hline
23 & 0,00 & 0 & 512,50 & 2,67 & ne & ne\\\hline
24 & 393,00 & 2 & 542,50 & 1,00 & ano & ne \\\hline
25 & 370,00 & 2 & 183,05 & 3,67 & ne & ne \\\hline
26 & 150,00 & 2 & 553,63 & 4,00 & ne & ne \\\hline
27 & 135,00 & 1 & 140,68 & 3,20 & ano & ne \\\hline
28 & 120,00 & 1 & 3229,67 & 3,00 & ne & ne \\\hline
\end{tabular}
\newpage
\subsubsection{Předpověď na jednotlivé dny v týdnu}
Předpověď množství transakcí a jejich počtu vychází z průměru jednotlivých dnů. Tato předpověď byla postupně porovnána s následujícími třemi týdny. Celkovou výši transakcí i jejich počet lze vidět v tabulkách uvedených níže. Zároveň je zde uvedena tabulka, která ukazuje, který odhad byl považován ještě za správný a který nikoli.
\begin{tabular}{|c |c |c |c |c |c |c |c |c|}
\hline
\multicolumn{9}{|c|}{Předpověď na týden (v Kč)} \\\hline
\multirow{2}{*}{Den} & \multicolumn{2}{c|}{Odhad} & \multicolumn{2}{c|}{Test 1} & \multicolumn{2}{c|}{Test 2} & \multicolumn{2}{c|}{Test 3} \\
& částka & počet & částka & počet & částka & počet & částka & počet \\\hline
Po & 237,80 & 1,09 & 0,00 & 0 & 2 159,00 & 2 & 1 180,00 & 2 \\\hline
Út & 1 143,05 & 2,22 & 1 646,00 & 2 & 70,30 & 1 & 1596,74 & 1\\\hline
St & 442,55 & 1,44 & 963,00 & 3 & 503,00 & 4 & 409,90 & 2\\\hline
Čt & 203,41 & 2,34 & 133,00 & 2 & 113,00 & 1 & 95,00 & 1 \\\hline
Pá & 404,71 & 2,78 & 1 930,00 & 3 & 134,00 & 2 & 249,00 & 2 \\\hline
So & 298,32 & 2,74 & 803,00 & 3 & 0,00 & 0 & 128,00 & 3 \\\hline
Ne & 1 076,40 & 2,34 & 89,00 & 2 & 347,60 & 1 & 646,00 & 2 \\\hline
\end{tabular}
\begin{tabular}{|c |c |c |c |c |c |c|}
\hline
\multicolumn{7}{|c|}{Správnost předpovědi na týden} \\\hline
\multirow{2}{*}{Den} & \multicolumn{2}{c|}{Test 1} & \multicolumn{2}{c|}{Test 2} & \multicolumn{2}{c|}{Test 3} \\
& částka & počet & částka & počet & částka & počet \\\hline
Po & ne & ne & ne & ne & ne & ne \\\hline
Út & ano & ano & ne & ne & ano & ne \\\hline
St & ano & ne & ano & ne & ano & ano \\\hline
Čt & ano & ano & ano & ne & ne & ne \\\hline
Pá & ne & ano & ne & ano & ne & ano \\\hline
So & ne & ano & ne & ne & ne & ano \\\hline
Ne & ne & ano & ne & ne & ano & ano \\\hline
\end{tabular}
Z uvedených údajů lze vyčíst, že částku se podařilo správně odhadnout celkem osmkrát, tedy s úspěšností 38,1\%. Oproti tomu počet transakcí se podařilo odhadnout v deseti případech. Úspěšnost toho odhadu tedy dosahuje 47,62\%. Kumulativní úspěšnost všech předpovědí je proto 42,86\%.
\section{Testování laickým uživatelem}
Dalším testem bylo ohodnocení aplikace laickým uživatelem, který ale byl seznámen se zaměřením aplikace a byl mu stažen výpis z účtu a umístěn na plochu. Celý test pak tvořilo několik bodů, které má tento potencionální uživatel projít a vyhodnotit.
\subsection{Přihlášení se do aplikace}
Testující uživatel se pokoušel do aplikace přihlásit pomocí jména a hesla ke svému emailovému účtu. Ten bohužel aplikace neznala. Avšak uživatel byl schopen bez problémů pochopit, že zadal do aplikace nevalidní údaje a nedělalo mu problémy si později vytvořit vlastní účet.
\subsection{Nahrávání dat}
Obrazovky pro načtení dat si uživatel všiml okamžitě. Bez problémů pochopil jakým způsobem do aplikace nahrát data i jak je poté smazat. Jediný nedostatek však spočíval v tom, že uživatel byl nucen použít předem stažený výpis z účtu. Ze své bankovní aplikace si totiž bez cizí pomoci výpis z účtu nedokázal sám vyexportovat. Pokud by však došlo k integraci vytvořené aplikace do jiného systému, tento problém by se podařilo snadno odbourat. Pokud by k tomu ale nedošlo, mohlo by to znamenat vážný problém pro případné budoucí používání aplikace.
\subsection{Zobrazená data}
Uživatel bez větších potíží rozuměl výsledkům v aplikaci. Tvrdil však, že předpovědi jsou sice možné, ale nemyslí si, že se skutečně vyplní a očekává, že se bude chovat jinak, než mu aplikace prezentuje.
\subsection{Změna hesla a smazání účtu}
S tímto bodem neměl uživatel téměř žádný problém. Bez otálení si otevřel menu aplikace a provedl změnu hesla i smazání účtu. Nedělalo mu problém formulář pochopit.
Jediné úskalí aplikace bylo, že uživatel vzápětí zapomněl změněné heslo a obvinil aplikaci, že nefunguje správně. Testování v tomto kroku bylo ale naštěstí spuštěno na vývojové verzi, pro kterou nebylo potlačeno logování uživatelského jména a hesla před odesláním na server. Šlo tedy dohledat, že se uživatel pokoušel opravdu přihlásit do aplikace jiným heslem, než na které jej původně změnil.
Tento problém ale naráží na chybějí funkcionalitu pro změnu zapomenutého hesla. O tuto funkcionalitu by bylo dobré aplikaci, v závislosti na způsobu finálního nasazení, nějak doplnit.
Pro otestování validity kódu jsem chtěl aplikaci zkontrolovat pomocí W3C validátoru (dostupný z \url{https://validator.w3.org/}). Validátor bohužel nebere v úvahu syntaxe Angularu a generuje hlášení o nepovolených atributech. Z~tohoto důvodu ho není bohužel možné pro test využít.
\begin{figure}[h]
\includegraphics[width=1\textwidth]{img/W3C_error.png}
\centering
\caption[W3C -- nepovolené atributy]{W3C -- nepovolené atributy}
\label{W3CError}
\end{figure}
Možnosti rozšíření aplikace jsou velmi rozsáhlé. Může to zahrnovat zefektivnění výpočtů či doplnění webového rozhraní o další informace.
Pro serverovou část je jako další rozšíření vhodné implementovat nějakou formu cachování (ukládání si již jednou vypočtených informací). Data zobrazovaná na webu se bez změny transakční historie nemění. Implementace je ale provedena tak, že pro každé zobrazení se musí znovu vypočítat. Tento způsob není velmi efektivní a bylo by vhodné je nějakým způsobem ukládat třeba do databáze a měnit je jen v případě, že dojde ke změně transakční historie.
Dále by bylo vhodné získat mnohem větší množství neanonymizovaných dat. Data, jež jsou v současnosti k dispozici, nejsou bohužel příliš obsáhlá a~limituje to schopnost umělé inteligence se učit.
S tím by ale souviselo i zamyšlení se nad vícevláknovým (paralelním) zpracováním učení umělé inteligence, jež by mohlo celý proces výrazně urychlit. Za zmínku by určitě stálo oddělení maticového násobení a jeho zpracování na grafických kartách. Tím by došlo ke snížení zátěže na procesoru.\cite{matrixMultiplication}
Optimalizaci by ale mohlo pomoci přepsání umělé inteligence třeba do C/C++ a použití C/C++ knihoven. Díky menší abstrakci v kódu by tímto teoreticky mohlo být dosaženo rychlejšího zpracování.
Také by bylo možné přidat automatické učení pro nové figuranty na základě úspěšnosti učení. To by mohlo být realizováno nějakým rozhodovacím stromem. Např. naučit se na uživateli, jehož předpověď je horší než 50\% a této nové síti přiřadit veškeré uživatele, pro něž je předpověď této nově vycvičené sítě lepší.
Další možností by bylo využít Dockeru a celou aplikaci spouštět v něm. Popřípadě napsat UNIT testy, ať už pro lepší pochopení použití funkcí nebo testování jednotlivých částí jako takových.