A Lexunit már a kezdetek idején célként fogalmazta meg, hogy mesterséges intelligencia-téren meghatározó szereplő szeretne lenni Magyarországon. Ádám és István azóta fejlesztik AI-téren a szaktudásukat, amióta egyáltalán látszani kezdtek a terület lehetőségei a korszerű informatikában.

A saját PacMan, illetve Pong-klónok kipipálása után nekiláttunk egy valódi probléma keresésének. Ha az ember nyitott szemmel jár, nem nehéz olyan lehetőségeket találni, amiben a mesterséges intelligencia a segítségünkre lehet. Nem is kellett sokáig várni az első ötlet felmerülésére.

Az első mesterséges intelligencia ötletünk

Ekkoriban éppen egy felhőalapú rendszert fejlesztettünk könyvelő vállalkozásoknak, amelybe be tudnak csatlakozni az ügyfeleik is, fizetési modullal és mindenféle hasznos beépített eszközzel. Innen jött az ötlet: készítsünk ehhez a csomaghoz egy számlaértelmező rendszert!

Az volt a teóriánk ugyanis, hogy a könyvelők munkaidejének nagy részét felemészti az a nagyon monoton feladat, hogy a vegyes formátumban begyűjtött számlák adatait felviszik a saját rendszerükbe, vagyis a leírt adatokat gyakorlatilag begépelik újra. Ha meg tudnánk oldani, hogy szkennelés, illetve digitális képelemzés során a szoftverünk szépen felismerje az összes adattípust, és ezeket a megfelelő kategóriákba rögzítse, akkor sokkal gördülékenyebbé tehetnénk a munkájukat.

Egy számlán tipikusan ilyen adatok szerepelnek:

● Számla sorszáma (pl. SA2019-01)
● Kiállítás dátuma (pl. 2019.02.15)
● Teljesítés dátuma (pl. 2019.02.15)
● Fizetési határidő (pl. 2019.02.23)
● Pénznem (pl. Ft, Euro)
● Fizetési mód (pl. készpénz, átutalás)
● Eladó adószáma (pl. 25926585-2-42)
● Nettó összeg (pl. 100 000 000 Ft)
● ÁFA mértéke (pl. 27 %)
● Teljes ÁFA (pl. 27 000 000 Ft)
● Bruttó összeg (pl. 127 000 000 Ft)
● Cég név (pl. Lexunit Group Kft)

Gyakorlás és tesztelés a szoftverfejlesztésben

A célunk ekkor még a gyakorlás, a problémamegoldási metódusok tesztelése volt, ezért fogalmunk sem volt arról, mennyire betaláltunk ezzel a koncepcióval.

Egy házi, online kérdőíves kutatásunkra beérkezett nagyjából harminc válasz vállalkozó könyvelőktől, és elképesztő számokat láttunk - a könyvelőknél nem ritka a havi többezer, akár tízezer számla feldolgozása, és a munkaidejük akár felét elviszi az adminisztráció! Persze, lehet gyakornokot felvenni és egyéb félmegoldásokkal élni, de mi van a magas terhelésű időszakokkal, mint amilyen az adóbevallási határidők környéke, vagy egyszerűen a kiemelten fontos projektekkel, ahol inkább minden adatért személyes felelősséget akar vállalni a könyvelő?

A gyakorlatban a megoldás a digitális számlaképek feldolgozása elektronikus számlák esetén, a nyomtatottaknál pedig először ipari szkennelésre van szükség. A folyamat során létrejön egy képfájl, ezt kell betölteni a szoftverünkbe, ami feldolgozza azt, a megfelelő adatokat a megfelelő kategóriába sorolja. Ezt a könyvelő ellenőrzi, és helyesbíti, ahol szükséges - mert valamennyi hiba mindig lesz, ez a mesterséges intelligencián alapuló NLP technológiával jár, ahogy arra később még kitérünk.

Persze, miért van erre egyáltalán szükség? A számlák feldolgozása lehetne egy szimpla programozói feladat - egy olyan elképzelt, ideális világban, ahol a számlák formátuma tökéletesen standardizálva van, vagyis ahol minden hivatalos dokumentum tökéletesen egyformán néz ki, csak az adattartalma különbözik - minden rubrika ugyanott, ugyanaz a betűtípus, ugyanolyan színek, és így tovább. Ekkor egy “if/else” megoldással ki lehetne szedni az adatot, alig különbözne ez attól, mint amikor “Ctrl-F”-et nyomunk egy online szövegen.

A valóságban azonban egy átlagos könyvelő kezein átmenő számlaköteg egy sztochasztikus saláta. Nagyjából lehet tudni, hogy milyen, de valójában szinte bármilyen.

Ilyen forrásanyagot azért jobb mesterséges intelligenciával feldolgozni, mert bár, mint említettük, lesz benne hiba, de hosszabb távon be fog állni egy olyan állapot, hogy kevesebb lesz a hiba, mintha ember csinálná.

És közben természetesen ott van a járulékos haszon, amiért az egészet elkezdtük: a számlák rögzítésének szintidejét a negyedére-ötödére csökkentettük a szoftverünk használatával, beleértve minden lépést, tehát az ellenőrzést és a szükséges javításokat is.

Mivel lehet a folyamatot pontosítani, hogyan lesz egyre ritkább a hiba?

Itt jön be a tanítás, amikor “átsúlyozzuk a neurális háló éleit”. (Ilyen csodálatos metaforákra képes egy szoftvermérnök, ha elég sok időt tölt a Fekete Doboz közelében)

De kezdjük az alapoktól. Egy hétköznapi számla adattartalmát nem csupán a rajta lévő számok és betűk adják, hanem ezek mérete és elhelyezkedése is, mivel ezek a dimenziók is hordoznak olyan információt, amiből következtetni tud a szoftver arra, hogy hová kellene az adott adatot sorolnia.

Több infó:
Chargrid: Towards Understanding 2D Documents
https://medium.com/sap-machine-learning-research/chargrid-77aa75e6d605

Scaling up machine learning algorithm for form recognition
https://medium.com/tradeshift-engineering/scaling-up-machine-learning-algorithm-for-form-recognition-bd09b319e14a

Régebben erre volt az egyik megoldási irány a heurisztika: szabályokat próbáltak gyűjteni, mint amilyen a szavak és számok egymáshoz viszonyított pozíciója, vagy az, hogy ha van olyan szám, amelyik bármely más, korábban rögzített számok összege, akkor az valószínűleg végösszeg. Ezzel az a probléma, hogy több millió ilyen szabályt is hozhatunk, sosem fog a folyamat automatikussá válni, és roppant körülményes karbantartani.

A lényeg, hogy azonosítási lehetőségeket keresünk: ez egy valós szám, vagy egy egész szám? Ez a számsor egy dátum formátumának megfelel -e, vagy sem? Hol helyezkedik el ez a szó? Magában áll, vagy több szó követi? Ezeket nevezzük “Feature”-nek, az adott adategység jellegzetességeinek.

A feature-adatokból szekvenciákat állítunk elő, amelyet a machine learning modell dolgoz fel, ennek a modellnek a központi eleme a neurális háló. A modell minden egyes szóra ad egy valószínűségi eloszlást, hogy vajon melyik adattípusnak felelhet meg? Adószám vagy végösszeg? ÁFA vagy sorszám?

A végeredményt természetesen szerkesztheti a könyvelő, mielőtt elfogadja, és ebben a módszerben az is nagyszerű, hogy ez újabb tanítóadat a rendszer számára. Minden ilyen manuális szerkesztés növeli a következő következtetés pontosságát.

A predikció sikere

A predikció sikerességének egyik kulcsa az adatok tisztasága, és ez mindig ad lehetőséget némi fejtörésre, a munka háromnegyede azzal telik, hogy biztosítani próbáljuk azt, hogy a bemeneti adat minél jobb minőségű legyen. Említettük, hogy egy elképzelt világban talán minden egyes számlának tökéletesen azonos a formátuma, ugyanúgy néznek ki: mondjuk induljunk ki a szamlazz.hu alap számlaformátumából. Ha minden számla ilyen lenne, akkor elég gyorsan el lehetne jutni a 100%-os felismerési pontosságig, hiszen a bemeneti adatokba nem szűrődik be semmilyen zaj, nincs variancia. De ha csak szamlazz.hu számlákkal tanítanánk a rendszerünket, akkor azt nagyon ügyesen fel fogja ismerni ugyan, de a Billingósokat mind el fogja rontani.

A példa kedvéért tegyük fel, hogy járműveket fotóról felismerő rendszert fejlesztünk. Ha 1000 képet mutatunk neki a tanítás során, amiből 950 kép autókat ábrázol, majd ezek után teszteljük 10 darab képpel, amelyekből 8 darabon helikopter van, akkor a rendszer gyengén fog teljesíteni. Ha 8 autót és 2 helikoptert mutatunk, akkor akár 80 százalékos pontosságot is elérhetünk, ami hamis eredmény, hiszen a helikoptereket mind elrontotta, csak az autókat ismerte fel. Ezért kell megfelelő eloszlásban tanítani.

(Később volt is olyan projektünk, ahol a szoftverünknek autók fotóit kellett automatikusan értelmeznie, biztosítási kárfelmérés céljából. Erről itt lehet bővebben olvasni.)

Felmerül a kérdés: honnan tudunk szerezni a tanítási folyamathoz megfelelő számlákat, a lehető legkülönbözőbb formátumokban? A valódi számlák, amikre szert tudtunk tenni, nem tűntek elégségesnek: 50 különböző típust találtunk, márpedig a tanításhoz 10 ezres nagyságrendet éreztünk optimálisnak.

Ezért az 50-féle számlából sablonokat gyártottunk, és randomizált cégadatokkal újabbakat állítottunk elő, így sokszorosára tudtuk növelni a tanításhoz szükséges alapanyagot.

Mint említettük a cikk elején, az eredmények igen biztatóak voltak, a jelek szerint a szoftverünk az elvárható szinten kezelte a problémát, és ennél csak tovább fejlődik a pontossága, rendszeres használat mellett.

De mit tudunk ezzel kezdeni? A szoftverfejlesztésben ugyanis csak egy állomás a probléma megoldása, valahogy ebből terméket is kell fejleszteni. A rendszerünk végfelhasználója a könyvelő ugyan, de a célközönsége az lehet, aki a könyvelők számára fejleszt szoftvert. Emellé kellene megfelelő marketing és sales, majd pedig folyamatosan iterálni kell, hogy optimálisan illeszkedjen a már létező könyvelői szoftverekbe ez a funkció. Vagyis innentől kezdődne egy folyamatos karbantartási és UX feladat, ami már nem a Lexunit fő profilja - mi mérnöki problémákra keresünk digitális megoldásokat. Az alábbi lehetőségek álltak előttünk:

1. Nyílt forráskódúvá tesszük a megoldást és bízunk benne, hogy elterjed, a bolygó távoli pontjaira is továbbítva a Lexunit nevét

2. Esettanulmányként és élőben, a weboldalunkon kipróbálható demóként tesszük elérhetővé

Az utóbbi mellett döntöttünk. A szoftver, ha végleges termék lenne, még számos egyéb logikus funkcióval bővülhetne, például az adószámot valós időben ellenőrizni is lehet online adatbázisokkal összevetve, illetve matematikai ellenőrzéseket lehet beiktatni - ezeket mi már “post processing” funkcióknak tekintjük, mivel a program elsődleges feladata a mi szempontunkból az volt, hogy demonstrálja a neurális háló gyakorlati képességeit. Ezt meg is teszi, az már más kérdés, hogy ezekkel az eredményekkel mit lehet még kezdeni.

A fő üzenet itt csupán az, hogy a könyvelőknek rengeteg értékes emberi erőforrásra elmegy egy alacsony tudásigényű feladatra: az adatrögzítésre. Az ilyen szoftveres megoldásokkal, mint a miénk, egy csomó extra energia felszabadítható, csökken a költség, növekszik a bevétel: a teljes folyamaton, összevetve a teljesen emberi adatrögzítéssel, kétharmadnyi időt lehet megtakarítani.

A másik kulcstanulság, hogy ez természetesen nem csak számlákkal működhet: orvosi dokumentumok, szállítólevelek, CV-k, kárbejelentő lapok… minden olyan eset, ahol hasonló formátumú nyomtatott vagy szkennelt dokumentumok tömegéből kell adatot kinyerni, hasznos lehet ez a technológia.

A  “Proof of Concept” időszak

Ezért aztán az egyik dolog, amivel megpróbálkoztunk, az az volt, hogy olyan cégekkel vettük fel a kapcsolatot, akik az álláshirdetéseikben megjelölték az NLP-t, mint szükséges szaktudást - ebből látszik, hogy ilyen jellegű problémájuk lehet. És találtunk is egy céget, akik webes tartalmakat töltenek le és a cikkeket kategorizálják cím, dátum, tartalomtípus, és egyéb paraméterek alapján… jobb híján manuálisan. Az ő szolgáltatásuk ugyanis valamit kezd ezzel a rengeteg tartalommal, de nem volt eszközük a tartalom megbízhatóan kategorizált begyűjtésére.

Náluk van a kincses térkép, de nálunk van a ládához a kulcs.

Mivel mi a SzamlAI-val már bejártuk az ilyen Feature-ök (mint cím, dátum stb) kapcsán bejárható összes zsákutcát, ezért eléggé magabiztosak voltunk abban, hogy tudunk nekik segíteni.

De garanciánk persze nincsen rá. Ennek az iparágnak az egyik sajátossága, hogy senki nem tudhatja, hogy az innovatív megoldás működni fog-e… Csak azt lehet megígérni, hogy szakszerűen tudjuk megvizsgálni a problémát.

Hogyan lehet így üzletet kötni? Erre találták ki a “Proof of Concept” időszakát. Az ígéret itt annyi, hogy dolgozunk az ügyön, és bizonyos időközönként bemutatjuk, hogy állunk, mit csináltunk - az ügyfél pedig bármelyik ilyen prezentáció után leállíthatja az együttműködést.

Vízió és nyitott üzletvezetési szemlélet a mesterséges intelligenciáról

Egy olyan csapatnak, mint a Lexunit, ez nem rossz megoldás, mert számunkra általában annak a megindokolása okoz nehézséget, hogy miért kéne minket beengedni az ajtón. Amikor már bent vagyunk, a munka általában magáért beszél és meggyőző, csak előzőleg nehéz érvelni mellett, hiszen annyira experimentális. Egy csomó cégben természetesen ahhoz sincs meg a tudás, hogy egyáltalán azt nyomon tudják követni, hogy ez a projekt most jól halad-e vagy sem, hogy tényleg erre van-e a cégnek szüksége.

A bemutatók során nagy hangsúlyt helyezünk arra, hogy a helyes döntések meghozatalát segítő tudást is igyekezzünk  átadni. Az NLP egy olyan eszköz, ami a megfelelő környezetben már bizonyított, kipróbált, de ettől még a mesterséges intelligencia felhasználási területeinek feltérképezése még korai státuszban van, tehát a lehetőségek egyelőre korlátlanok. Ezért sokszor kell a vízió, a nyitott üzletvezetési szemlélet, amelynek segítségével egy ügyfél fel tudja mérni saját szakmai határait, és képes bizonyos kontrollált kockázatot vállalni annak érdekében, hogy értékre tegyen szert ezekkel az innovatív megoldásokkal.

Indítana egy hasonló projektet, de lenne lenne kérdése ezzel kapcsolatban?
Éljen az ingyenes konzultáció lehetőségével és lépjen belünk kapcsolatba már ma! Kattintson ide.

Következő cikk:

Biztosítási kár bejelentésének folyamatát automatizáltuk gépi tanulás- és gépi látás- megoldásokkal