Számlák, szerződések, kimutatások, beadványok, belső összefoglalók. Valakinek el kell olvasnia őket, ki kell keresnie belőlük a lényeges számokat, be kell gépelnie azokat egy rendszerbe, ellenőriznie kell, hogy semmi nem mond ellent semminek, majd mindebből össze kell raknia még egy dokumentumot. Kézzel. Minden egyes alkalommal. Ezt a kört gyakorlatilag minden vállalat ismeri, mert dokumentum gyakorlatilag mindegyikhez érkezik.
A McKinsey szerint a tudásmunkások munkaidejük akár 19%-át is információk keresésével és összegyűjtésével töltik. Ez heti egy nap, amikor egy könyvelő, egy jogász vagy egy compliance-felelős olyasmit csinál, amit egy gép is el tudna végezni. És ez még csak a számla látható fele. A kézi átgépelés hibákat termel, azokat pedig szintén meg kell találnia és ki kell javítania valakinek.
A rise.sk-nál szisztematikusan látunk neki. Olyan platformot fejlesztünk, amely a dokumentumokat nemcsak elolvassa, hanem meg is érti, a bennük talált információkat összekapcsolja egymással, és a végén emberi közbeavatkozás nélkül állítja elő a kimenetet.
A platform végigkíséri a dokumentum teljes útját, attól a pillanattól, hogy megérkezik, addig, amíg valami új nem születik belőle.
Érkezhet bármilyen formátumban. PDF, szkennelt kép, e-mail-melléklet, Word, Excel. Az MI elolvassa, kitalálja, milyen típusú dokumentumról van szó, és kiemeli belőle a lényeget, vagyis az összegeket, a dátumokat, a feleket, a cégazonosítókat és a szerződésszámokat. Ezeket az értékeket a rendszer ezután összeveti a már meglévő nyilvántartásaival, így egy számla magától megtalálja a saját szállítóját, a saját keretszerződését és a saját kapcsolattartóját. Ugyanezekből az adatokból tölti ki a sablont, állítja össze a kimutatást vagy készíti el az összefoglalót.
Ez nem egy chatbot, amely a dokumentummal kapcsolatos kérdésekre válaszol. Ez egy folyamat (pipeline), amely naponta több száz dokumentumot rág át anélkül, hogy bárki egyenként megnyitná őket.
Először a megértés jön. Megérkezik egy dokumentum, és a modell besorolja. Számla, szerződés, szállítólevél, belső jelentés? Minden típus máshogy van felépítve, és mindegyikben más adat lapul.
Utána következik a kinyerés. A szkennelt anyagokon az OCR (Optical Character Recognition) dolgozik, a digitális szövegeken az NLP (Natural Language Processing), és ketten együtt pontosan azt emelik ki, amit Ön kért. A számlából az összegeket, a fizetési határidőket, a szállító és a vevő azonosítóit és a rendelésszámokat. A szerződésből a feleket, a tárgyat, a teljesítési határidőket és a szankciókat.
A lényeg az, hogy a rendszer mire támaszkodik. Nem merev sablonokat magol, hanem olyan nyelvi modelleket használ, amelyek olvassák a kontextust. Ha egy szállító áttervezi a számláját, a helyes mezők akkor is előkerülnek, mert a modell tudja, mi az a fizetési határidő. Hogy pontosan hol áll az oldalon, mellékes.
A kinyerés önmagában is hasznos. Igazán értékessé az teszi, ami utána jön. Minden értéket, amit a rendszer kiemel, összeveti az adatbázisában már meglévő entitásokkal.
Vegyünk egy számlát az ABC Kft.-től. A rendszer kiolvassa a cégazonosítót, megtalálja vele a meglévő nyilvántartást, a számlát hozzákapcsolja az érvényes keretszerződéshez, felismeri a kapcsolattartót, és a megfelelő projekthez sorolja. Közben senki nem kattintott.
Visszafelé is ugyanígy működik. Megnyit egy ügyfélkartont, és ott van előtte minden, ami hozzá tartozik. Szerződések, számlák, szállítólevelek, levelezés. Nem azért, mert valaki kézzel rendezte, hanem mert a rendszer ismeri a dokumentumok közötti összefüggéseket.
Két technika végzi a munkát. A pontos egyeztetés a cégazonosítókat és a szerződésszámokat fedi le, vagyis azokat a helyeket, ahol a majdnem jó ugyanannyit ér, mint a rossz. A fuzzy egyeztetés a cégneveket és a címeket fedi le, amelyeket minden dokumentumban kicsit másképp írnak. Az eredmény egy kapcsolati gráf, amely minden áthaladó dokumentummal sűrűbb lesz.
A lánc utolsó szeme a kimenet. Ha az adatok ki vannak nyerve és az entitások össze vannak kapcsolva, a dokumentumok igény szerint előállíthatók.
A sablont egyszer kell leírni. Egy szerződést, egy árajánlatot, egy átadási jegyzőkönyvet, egy űrlapot, mindegyiket változókkal, és a rendszer onnantól a helyes értékekkel tölti ki. A rendszeres kimutatások hasonlóan készülnek, csak előtte az adatok egy időszakra összesítve lesznek. Így születnek a havi áttekintések, a negyedéves jelentések és a compliance-dokumentáció. Harmadikként pedig az összefoglaló jelentések, vagyis a projektenkénti számlázás, a szerződéses kötelezettségek teljesítésének állapota vagy a követelések korosodási (aging) kimutatása.
A sablonok az Önéi maradnak. Az Ön formátuma, az Ön mezői, az Ön logikája. A rendszer csak következetesen alkalmazza őket, elgépelés nélkül és naprakész adatokkal.
Olyan szervezeteknek építjük, ahol a dokumentumok nem a kivételt jelentik, hanem magát a munkát.
A könyvelőcégek és a pénzügyi részlegek számlafeldolgozást, a megrendelésekkel való egyeztetést és pénzügyi kimutatásokat kapnak belőle. Számlát már senki nem visz be kézzel, az MI feldolgozza és jóváhagyásra előkészíti.
Az ügyvédi irodáknak szerződéseket elemez, kiemeli belőlük a lényeges feltételeket és figyeli a határidőket. A standard szerződéseket utána abból az ügyféladatból állítja elő, ami már megvan.
Az államigazgatásban beadványokról van szó, arról, hogy tényleg teljes-e a dokumentáció, és határozatok meg értesítések megfogalmazásáról. Az ügyintézőnek nem kell mellékletek között kutatnia, hogy lássa, mi hiányzik.
A bonyolult dokumentációval dolgozó nagyvállalatok pedig compliance-jelentésekre, belső ellenőrzésre és beszállítói kapcsolatokra használják. Ott térül meg leginkább az összekapcsolás, mert éppen az osztályok közötti résekben vész el ma az információ.
Az architektúra öt komponensen nyugszik.
A Document Ingestion Layer mindenhonnan átveszi a dokumentumokat, ahonnan azok Önhöz érkeznek. E-mailből, API-n át, feltöltésből, figyelt mappákból. Egységesíti a formátumokat, és feldolgozásra kész állapotba hozza mindegyiket.
Az AI Processing Pipeline a mag. Egyesít egy OCR-motort a szkennelt anyagokhoz, egy nyelvi modellt a besoroláshoz és a kinyeréshez, valamint egy entitásfelismerő modult, amely az entitásokat észreveszi és összedrótozza. Modulárisra építettük, így bármelyik darabja cserélhető vagy fejleszthető anélkül, hogy a többihez hozzá kellene nyúlni.
Az Entity Graph gráfadatbázis, amely a kapcsolatokat tartja. Egy céghez szerződések tartoznak, a szerződésekhez számlák, a számlákhoz tételek, a tételek pedig megrendelésekre mutatnak vissza. Minden új dokumentum hozzátesz néhány élt.
A Template Engine állítja elő a dokumentumokat, és kezeli a feltételes blokkokat, a számításokat és a formázást. A sablonokat szándékosan hagytuk egyszerű formátumban, hogy az is tudja szerkeszteni őket, aki nem programoz.
A Validation & Review Layer a minőségre ügyel. Ami alacsony megbízhatósági pontszámot (confidence score) kap, emberhez kerül ahelyett, hogy továbbmenne. Minél több dokumentum halad át, annál pontosabb lesz.
Egy közepes méretű gyártó havonta több mint 500 szállítói számlát kap. Eddig egy könyvelő mindegyiket megnyitotta, begépelte a könyvelési rendszerbe, és egyeztette egy megrendeléssel.
Most a számlák e-mailben érkeznek egy dedikált címre, és maguktól feldolgozódnak. A rendszer kiemeli a szállítót, az összeget, az áfát, a fizetési határidőt és a rendelésszámot, megkeresi a hozzá tartozó megrendelést az ERP-ben, és összeveti a kettőt. Ha egyeznek, a számla egyenesen a felelős vezetőhöz megy jóváhagyásra. Ha az összeg nem stimmel vagy a szállító ismeretlen, félrekerül egy embernek.
Az 500 számla 80%-a automatikusan átfut. A könyvelő most fél napot tölt a számlákkal három helyett, és csak azokkal, amelyek kilógtak a sorból.
Egy pénzintézetnek negyedévente szabályozói jelentéseket kell benyújtania. Az ehhez szükséges adat több tucat belső dokumentumban szóródik szét, szerződésekben, tranzakciós nyilvántartásokban, ügyféllevelezésben és belső döntésekben.
Ha a releváns entitások már össze vannak kapcsolva, a rendszer negyedév végén magától összerakja ezeket az adatokat. Összesíti őket, kitölti a szabályozói űrlapot, és előállítja a mellékleteket. A compliance-felelős kész jelentést kap ellenőrzésre egy halom nyers adat helyett, amit össze kellene állítania.
Két hét munkából két nap lesz.
Egy ügyvédi iroda havonta több tucat standard szerződést állít ki. Bérleti, vállalkozási, adásvételi. Mindegyikbe kézzel kell bevinni az ügyfél adatait, az ingatlan adatait és a feltételeket.
Ehelyett az ügyvéd kiválaszt egy szerződéstípust és egy ügyfelet, a rendszer pedig az adatbázis aktuális nyilvántartásaiból tölti ki a sablont. A felek azonosító adatai, címek, a szerződés tárgya, az árajánlatból az árfeltételek. Kijön egy tervezet, amelyet az ügyvéd átnéz és igazít rajta.
Egy standard szerződés megírása 45 percről 5-re csökken. Az elgépelések és az ellentmondások eltűnnek, mert már senki nem gépel át semmit.
Nem mi vagyunk az egyetlenek, akik dokumentumautomatizálással foglalkoznak. A különbség az, ami mögöttünk van.
Az MI-t éles üzembe visszük, nem értékesítési prezentációba. Nem kutatócsapat vagyunk, amely tanulmányokat ír, hanem mérnökök, akik éles környezetbe telepítenek. Tudjuk, mi mutat jól egy dián, és mi bírja ki a találkozást valódi adatokkal. Ez két különböző dolog.
Ismerjük a szlovák dokumentumokat. A számlaformátumokat, a szlovák jog szerinti szerződésszerkezeteket, a cég- és adóazonosítók formátumait, a közigazgatás szokásait. Ez nem egy külföldről lefordítva behozott általános termék, és azoknál a dokumentumoknál, amelyek alakját törvény írja elő, ez a különbség a működő és a majdnem működő között.
Nem nagyban kezdünk. Egy dokumentumtípus, egy folyamat, megmutatjuk az értékét, aztán bővítünk. Minden lépés mérhető, és minden lépésnek ki kell fizetődnie.
Végül pedig a biztonság. A dokumentumok érzékeny adatokat tartalmaznak, ezért a platform védett környezetben fut, az adatok nyugalmi állapotban és átvitel közben egyaránt titkosítva vannak, a hozzáféréseket pedig kezeljük és naplózzuk. A legszigorúbb követelményekkel rendelkező ügyfelek helyben (on-premise) is üzemeltethetik.
Ha az Ön vállalata naponta órákat éget el a dokumentumok kézi feldolgozásával, keressen minket. Pilot programot nyitunk néhány szervezet számára. Fogunk egy konkrét dokumentumfolyamatot, ráállítjuk a platformot, és mérhető eredményeket mutatunk.
Elemzéssel indul. Feltérképezzük, hogyan kezeli ma a dokumentumokat, és hová megy el valójában az idő. Utána a platformot beállítjuk az Ön dokumentumtípusaira és munkafolyamatára. A tesztelés valós adatokon zajlik, az eredményeket pedig a kézi feldolgozáshoz mérjük. A végén megmérjük az időmegtakarítást, a hibaarányt és a megbízhatóságot, és a számok döntik el a következő lépéseket.
A dokumentumok az üzlet alapját képezik. Ideje, hogy intelligensen kezeljük őket. Vegye fel velünk a kapcsolatot, és egyeztetünk egy első beszélgetést arról, mit változtathatna meg az MI abban, ahogyan a vállalata a dokumentumokkal dolgozik.
A Rise.sk alapítója és műszaki vezetője. Webalkalmazásokat, adatrendszereket és automatizálást tervez és szállít; szoftverdöntésekről, AI-ról és digitális szolgáltatásokról ír.
A kínai modellek ma már csak hónapokkal, nem évekkel maradnak el az amerikai élvonaltól, mégpedig a költség töredékéért. Egy európai cég számára a valódi kérdés nem az, ki nyeri a versenyt, hanem az, hogy érdemes-e használni őket, és hogyan.
Az OpenAI szerint a GPT-5.6 Sol a költség harmadáért veri a Claude Fable 5-öt kódolásban. Az Anthropic szerint a Fable 5 vezet a nyers képességben. Mindkettőnek igaza van. Íme, melyik modell melyik feladatot nyeri.
Az API-tokenek kevesebbe kerülhetnek egy fejlesztői óránál, de nem képezik a teljes projekt költségét. Gyakorlati összehasonlítás a modellhasználatról, az átnézésről, a tesztelésről és az üzemeltetési költségekről.
Az Ön helyzete határozza meg a választ
