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 předpovídání transakcí 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ů a svým rodičům, za veškerou podporu při psaní práce}
{V Bakalářské práci byl řešen problém předpovídání budoucích transakcí klientovi, na základě jeho uplynulé finanční historie. Cílem práce je pokusit se implementovat toto předvídání pomocí umělé inteligence spolu s vytvořením webového rozhraní. Toho bylo dosaženo pomocí Angularu, tvořícího klientskou aplikaci, frameworkem .NET Core, který tuto aplikaci obsluhuje ve spojení s databází Microsoft SQL. Zabezpečení využívá JWT tokenu a o šifrování uživatelských hesel se stará RFC~2898/SHA512. Umělá inteligence byla řešena jako lineární regrese.
Umělá inteligence je implementována jako několik po sobě jdoucích vrstev, jejichž počet neuronů se 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ředví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 was solved the problem of forecasting future transactions to the client, based on his past financial history. The aim of this work is to try to implement this prediction by using artificial intelligence together with creating a web interface. This was achieved by using Angular, a client application, with the .NET Core framework, which runs the application in conjunction with the Microsoft SQL database. Security uses the JWT token and RFC~2898/SHA512 takes care of user password encryption. Artificial intelligence was solved as linear regression.
I have implemented artificial intelligence as several consecutive layers, the number of neurons gradually decreasing to one, which gives me information whether the transaction will repeat or not. In order to assess whether the transaction was actually recurring, I compared the size of the transactions on a week-by-week basis and described the amount most similar 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ředví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 zpracování finančních transakcí. Při výběru jsem využil možného zájmu bankovní instituce o odkoupení výsledného produktu. Ta by mohla využít mou práci k zobrazování pravděpodobných transakcí vlastním uživatelům a lépe tak porozumět chování a potřebám klientů samotných. Tím by mohla mít produkty lépe cílené na zákazníky. Mě osobně navíc vždy zajímal vývoj v oblasti umělé inteligence a chtěl jsem si proto své znalosti prohloubit.
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 aplikaci právě v jazyce C\# a frameworku ASP.NET. Avšak framework jsem, pro účely této práce, použil novější (.NET Core ve spojení s~Entity Frameworkem). Pro Frontend jsem zvolil Angular, protože jsem se chtěl také naučit něco nového. Zkušenosti nabyté při tvorbě bakalářské práce, bych rád využil ke zvýšení své kvalifikace v~oboru. Navíc spolupracuji s týmem, který v tomto frameworku vyvíjí aplikace a v~případě potřeby mi mohou poradit.
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.
Cílem práce je vytvoření webové aplikace, která bude pro skupinu uživatelů poskytovat službu předvídání finančních transakcí na základě jimi nahraného výpisu z účtu.
Cílem teoretické části práce je nastudování Angular frameworku, Typescriptu a Entity Frameworku Core / .NET Core. Dále je třeba zjistit možnosti využití umělé inteligence, která bude muset alespoň zčásti předpovědět chování uživatelů. Tato umělá inteligence bude předpovídat chování uživatelů na~zá-kladě předem získaných (anonymizovaný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.
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
\begin{enumerate}[--]
\item C\#
\item TypeScript
\item Angular
\item .NET Core
\item JWT
\item Microsoft SQL Databáze
\item šifrování hesel
\end{enumerate}
\item Nefunkční požadavky
\begin{enumerate}[--]
\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 výdajů neuronovou sítí
\item odhad výdajů průměrováním výdajů
\item odhad výdajů porovnáváním výdajů
\end{enumerate}
\end{enumerate}
\section{Webové rozhraní}
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.
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 HTTP API. To je možné 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 straně serveru, v případě několika uživatelů, není nijak zásadní, avšak u většího množství to přináší podstatně vyšší nároky na server.\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ů).
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é "\textit{George}"~a její doplněk "\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 "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{Obdobné frameworky pro umělou inteligenci}
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.
\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ů)\cite{ARES_zip}. Bohužel data v ní 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: "0", "null", "NULL", "prázdné", "nic", "není", "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ů. 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 ARES, 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án jistý vstup. Pro ten je nutné definovat určité minimální informace. Protože každá banka tvoří výpisy z účtu nepatrně jinak, došlo k omezení na tyto informace:
\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ší, a proto je nelze použít. Příkladem zde může být Typ transakce, který je označen v každé bance jinak.
%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 dali považovat samotní uživatelé, 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ů ("\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 Ukládání ve formě NoSQL
\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{"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 chybu.
%TODO highcharts, bootstrap, angularmaterial, interceptor,
V případě zabezpečení komunikace mezi backendem a frotendem (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í 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. Ta musí být zároveň vyexportována ve formátu CSV.
Celý import začíná na webovém rozhraní. Zde uživatel vybere soubor a stiskne tlačítko "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. "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 "857368". Tato hodnota je ekvivalentní textu "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 "označení operace", jak je pojmenována v ČSOB a "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 "1 234.56"~- s mezerou, oddělující řády. Také ale může obsahovat rozdílné oddělovače desetinných míst, př. "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 ARES 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,...), 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 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 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 dotace, daně, cla, pokuty, penále,...
\end{itemize}
\item Rezervované symboly
\begin{itemize} [--]
\item symboly rezervované pro mezibankovní styk
\item 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 "\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 "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ředví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 buď ze vstupní vrstvy, popř. 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 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).
Tímto způsobem je vytvořen tzv. úplný k-partitní graf.
\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}
Při předví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 "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ýstupní 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í funkce je pouhá hyperbolická funkce tangens z integrované knihovny Math.Tangh()
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 ("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 \textit{\textgamma} 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 \textgamma, 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 \textgamma ~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ů ("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}).
\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ě musely být vytvořeny nějaké dva primitivní problé-my, na základě kterých by se dalo ověřit, že opravdu funguje. Bylo tedy zvoleno předvídání sudých a lichých čísel, společně s testováním 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 číslo 0 zapisovalo jako -1. To je z důvodu, že nula není neutrální číslo pro násobení, a tím pádem by nedocházelo ke správnému vyhodnocování vah. Využití čísel -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 1000 vstupy 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 s 1000 vstupy 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 10 000 vstupy 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.
\subsubsection{Export, Import}
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ředví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 "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 porovnat pouhým okem 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 "Major". Ty jsou tedy označeny za neopakující se.
Část, v práci pojmenovaná jako Datafeeder, vychází z anglických slov \textit{"data"} a \textit{"feeder"} -- v doslovném překladu "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 "\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 "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ě:
\begin{enumerate}[1)]
\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ředví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í "magických konstant"~následovně:
498
499
500
501
502
503
504
505
506
507
508
509
510
511
512
513
514
515
516
517
518
519
520
521
522
523
524
525
526
527
\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}
\section{Předvídání bez umělé inteligence}
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ředví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. "rezervované symboly", kategorie se označí jako "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ě:
\begin{enumerate}[1)]
\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é
\end{enumerate}
\subsection{Předvídání na základě průměru}
Při předví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}.
\subsection{Uživatel}
První částí je ukládání dat o uživateli. Pomyslnou hlavní tabulkou je "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 "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 "\textit{ConstantSymbol}", což je entita, na kterou je odkazováno z "\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{"Kind"} (druh transakce), \textit{"LastNumber"} (význam poslední číslice), \textit{"MinistryPredefined"} (Předdefinované třídy MFČR) a \textit{"ReservedSymbol"} (Rezervované symboly).
Poslední tabulkou je \textit{"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{"Network"}). Každá se potom dělí na další podseznamy -- vrstvy (\textit{"Layer"}), a ty dále na neurony (\textit{"Neuron"}). Jako poslední seznam je seznam vah (\textit{"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.
\begin{figure}[h]
\includegraphics[width=0.55\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.
\begin{figure}[h]
\includegraphics[width=0.55\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=0.7\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}
\newpage
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é,...). Druhý i třetí graf pak využívají konstantní symboly k zobrazení, jakého druhu transakce pravděpodobně byly.
\begin{figure}[h]
\includegraphics[width=0.55\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=0.55\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ěpodobný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í.
\begin{figure}[h]
\includegraphics[width=0.55\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.
\begin{figure}[h]
$\vcenter{\hbox{\includegraphics[width=0.4\textwidth]{img/import_error.png}}}$
\hspace*{.2in}
$\vcenter{\hbox{\includegraphics[width=0.4\textwidth]{img/import_loading.png}}}$
\hspace*{.2in}
$\vcenter{\hbox{\includegraphics[width=0.4\textwidth]{img/import_succesful.png}}}$
\centering
\caption[Jednotlivé stavy nahrávání souborů]{Jednotlivé stavy nahrávání souborů}
\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}
\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ů}
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}
\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. Výsledek této operace se textově špatně demonstruje. Jako důkaz tedy alespoň poslouží několik obrázků.
\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}
%TODO ============================================
\section{Testování kvality - TODO dodělat}
Pro testování kvality práce bylo využito výpisu transakční historie, 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é.
\subsection{Odhad neuronovou sítí}
\begin{enumerate}
\item tabulka: (5 vs 14, 1x špatně)
\end{enumerate}
\subsection{Odhad průměrem}
\begin{enumerate}
\item line:
\item dny:
\end{enumerate}
\subsection{Odhad částkou}
\end{enumerate}
%TODO druhý uživatel
\section{Testování nezávislým uživatelem}
Dalším testem bylo ohodnocení aplikace nezávislým člověkem. Dotyčný 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. Implementace všech těchto rozšíření ale objemem značně převyšuje rámec bakalářské práce.
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.
Webová část by mohla zcela jistě být rozšířena také o další funkcionality, ačkoli rozšíření funkcionalit na frontendu aplikace téměř vždy implikuje i rozšíření backendu.
Jednou z možností je například doporučování produktů na základě provedených transakcí. I když výstup by v tomto případě byl velmi jednoduchý (jeden textový box), následná implementace logiky by byla velmi rozsáhlá. Bylo by třeba implementovat zcela novou rekomandační umělou inteligenci, která by byla navázaná na výsledky, už implementované, umělé inteligence na předpovídání transakcí.
Další funkcionalitou by mohlo být označování transakcí uživatelem. Mohly by to být třeba kategorie (drogerie, potraviny). Uživatel by též mohl označovat transakce, které považuje za opakující se a které nikoliv. Tím mohl vylepšit výsledky předpovídání budoucích transakcí.
Další možností by mohlo být propojení s emailovým účtem - notifikace po určitém počtu špatných přihlášení, přihlášení na novém zařízení nebo obnova hesla emailem.
Nakonec by stálo za zmínku vytvořit formulář, do kterého by uživatel doplnil o sobě nějaká data. Mohlo by to být pohlaví, věk, velikost města, ve které bydlí,... To by byl další způsob, jak zvýšit množství vstupů a vylepšit tak předpovědi umělé inteligence.
Pro svou práci jsem si nastudoval syntaxi a použití jazyků, jmenovitě Typescriptu, Angularu a C\# ve spojení z Entity frameworkem, na kterém jsem založil webovou aplikaci jako takovou. Od firmy Trask Solutions a.s. jsem si zajistil data a ty obohatil o druhy konstantních symbolů. Následně jsem na nich učil umělou inteligenci. Předpovídání transakcí umělou inteligenci jsem ještě doplnil o předvídání na základě průměrů a porovnávání částek.
V práci se mi podařilo umělou umělou inteligenci vytrénovat do té míry, že je do určité míry schopna předpovědět chování uživatelů. Pro lešpí předpovědi by však bylo vhodné mít rozsáhlejší data.
Jako možná další zásadní rozšíření bych uvedl doporučování produktů na základě mnou implementované umělé inteligence. Na základě velikosti útraty, počtu transakcí za určité období a produktů ostatních uživatelů by mohla, např. pomocí kolaborativního filtrování, doporučovat uživatelům bankovní produkty.
\end{conclusion}
\bibliographystyle{csn690}
\bibliography{mybibliographyfile}
\appendix
%============= seznam zkratek disabled ===================
\chapter{Seznam použitých zkratek}
\begin{description}
\item [JSON] JavaScript Object Notation
\item [JWT] JSON Web Token
\item [SQL] Structured Query Language
\item [NoSQL] non SQL
\item [CSRF] Cross-site request forgery
\item [ARES] Administrativní registr ekonomických subjektů
\item [XOR] Exkluzivní disjunkce
\item [CSV] Comma-separated values
\item [KS] konstantní symbol
\item [VS] variabilní symbol
\item [SS] specifický symbol
\item [API] Application Programming Interface
\item [HTTP] Hypertext Transfer Protocol
\item [ID] identifikátor
\item [MFČR] Ministerstvo financí České Republiky
\chapter{Přiložené soubory}
\begin{description}
\item [KB\textunderscore ARES.xml] Výpis z ARES (Komerční banka)
\item [DB\textunderscore diagram.png] Kompletní diagram datového modelu\label{DBdiagram}
\item [CSAS.csv] Import České Spořitelny
\item [CSOB.csv] Import ČSOB
\item [AirBank.csv] Importní soubor Air Bank
\item [Trask.csv] Importní data dodaná firmou Trask Solutions
\item [Example.csv] Příklad ideálních dat
\chapter{Obsah přiloženého CD}
\begin{figure}
\dirtree{%
.1 readme.txt\DTcomment{stručný popis obsahu CD}.
.2 BP\textunderscore Radek\textunderscore Pus\textunderscore 2019.tex\DTcomment{zdrojová forma práce ve formátu \LaTeX{}}.
.1 publish\DTcomment{adresář se spustitelnou formou implementace}.
.2 BP\textunderscore Radek\textunderscore Pus\textunderscore 2019.pdf\DTcomment{text práce ve formátu PDF}.
.1 Přílohy\DTcomment{přiložené soubory (Příloha B)}.