Kontekstas ir dokumentų apdorojimo istorija
Andrzej Kinastowski (AK): Konnichiwa, sveiki atvykę į Office Samurai tinklalaidę, kur neefektyvumą naikiname taip tiksliai, kaip EDO laikotarpio lankininkas. Šį kartą kalbėsime apie intelektualų dokumentų apdorojimą (IDP), tai yra skaitmenizuotą sąskaitų faktūrų, pirkimo užsakymų, sąskaitų išrašų, valstybinių asmens dokumentų, muitinės dokumentų – visų popierinių ir „be popieriaus“ popierių – apdorojimą. Aš esu jūsų vedėjas Andrzej Kinastowski, vienas iš Office Samurai įkūrėjų – įmonės, kuri tiki, kad jūsų verslas neturėtų būti įkaitas prasto nuskaityto dokumento. Tad paimkite savo mėgstamą kataną arba tą netikėtai aštrų laiškų atidarytuvą, kurį išlaisvinote iš apskaitos skyriaus, ir kibkime į darbą.
Beveik prieš 20 metų, kai pradėjau savo karjerą korporacijose, buvau pasamdytas į BPO, o mano pirmasis darbas buvo registruoti sąskaitas faktūras – tuo metu įprastas pradinio lygio darbas. Kasdien gaudavau paketą tikrų popierinių sąskaitų ir jas ranka suvesdavau į kompiuterį. Atsimenu, kad tuo metu galvojau, jog tai gana beprotiška – juk gyvename XXI amžiuje, o didelės tarptautinės įmonės vis dar siunčia viena kitai popieriaus lapus, popieriaus lapus, kuriuos žmonės turi suvesti į kompiuterį. Tai atrodė keista. Kai kurie kiti to BPO klientai naudojo OCR (optinį simbolių atpažinimą), ir aš jiems labai pavydėjau.
Po kelerių metų, kai perėjau prie nuolatinio tobulinimo ir pradėjau vykdyti „Lean“ valdymo projektus, pamačiau, kad kai kurios komandos iš tikrųjų praleisdavo daugiau laiko taisydamos OCR klaidas, nei būtų prireikę, jei jos tiesiog ranka suvestų tas sąskaitas. Tai buvo savotiški senosios mokyklos OCR’ai, kai kiekvienai naujai sąskaitai reikėdavo sukurti vadinamąją „kaukę“. Jei pasikeisdavo sąskaitos šablonas, reikėdavo keisti ir kaukę. Kaukė nurodydavo įrankiui, kad šio tipo sąskaitoje banko sąskaitos numerio reikia tikėtis šioje puslapio dalyje, o bendros sumos – kitoje. Taigi, tai reikalavo daug priežiūros ir nebuvo labai efektyvu. Šiandien mes čia tam, kad pakalbėtume, kaip šie dalykai daromi dabar.
Šiandien su manimi yra Tomasz Wierzbicki. Jis yra vienas iš „Office Samurai“ konsultantų. Tomaszas yra daugelio dalykų ekspertas – dirba su Intelligent Document Processing, Communication Mining, GenAI Agents ir kitomis sritimis. Tomaszai, sveikas atvykęs į tinklalaidę.
Tomasz Wierzbicki (TW): Sveiki, labai džiaugiuosi galėdamas čia būti.
AK: Pasakyk, kodėl tu čia (turiu omenyje – kodėl būtent su tavimi kalbu apie Intelligent Document Processing)?
TW: Aš dirbu su Intelligent Document Processing, o pastaruoju metu vis labiau linkstu į klasikinį mašininį mokymąsi ir Communication Mining (kas iš esmės yra NLP – Natural Language Processing). Viskas prasidėjo maždaug prieš dvejus metus. Atsimenu, mūsų technikos vadovas Konradas darė keletą eksperimentų su Document Understanding, aš tai išbandžiau ir labai greitai tuo susidomėjau. Labai įdomu derinti tai, ką paprastai darome (RPA ar automatizavimą), su trupučiu dirbtinio intelekto. Šiandien, kai technologijos taip sparčiai vystosi, tai labai įdomus metas ir sritis būti. Jaučiu, kad mokausi kiekvieną dieną, o dalykai šiais laikais labai greitai pasensta.
Evoliucija: nuo klasikinio OCR iki išdėstymo nepriklausomo IDP
AK: Kalbant apie senosios mokyklos OCR’us, kuriuos naudojome prieš 20 metų BPO įmonėje, kuo šiandieniniai įrankiai skiriasi? Nes tai, ką mačiau prieš 20 metų, nebuvo labai įspūdinga.
TW: Tik trumpas paaiškinimas – man tai veikiau buvo prieš 10–15 metų (prieš 20 metų dar buvau vidurinės mokyklos moksleivis). Tada man teko susidurti su ta klasikinio tipo technologija. Kiek pamenu, tuo metu viskas priklausė nuo to, ar tai iš tiesų atsiperka, nes naudoti tuos OCR’us buvo beprotiškai brangu, o pati technologija dar nebuvo tokia brandi kaip dabar. Mūsų technikos vadovas Konradas yra pasakęs, kad šiandien OCR’ai jau pasiekia savo efektyvumo ribas, todėl technologija yra labai subrendusi ir šiuo metu tobulinama pasitelkiant giluminį mokymąsi ir, tikėtina, didelius kalbos modelius.
Vis dar būdavo daug klaidų, todėl apimtys, kurias norėjai apdoroti naudojant OCR, turėjo būti pakankamai didelės, kad sprendimas ilgainiui atsipirktų. Vis tiek reikėdavo taisyti daugybę klaidų – dažna problema buvo ta, kad „1“ atrodydavo kaip „L“, o nuliai – kaip raidės „O“ ir panašiai. Dėl to OCR tekstui reikėdavo atlikti daug papildomo apdorojimo.
Klasikinis požiūris buvo toks, kad nors egzistavo OCR, jis negalėjo padaryti daug daugiau nei tiesiog nuskaityti ir atpažinti tekstą. Dabar, naudojant IDP (Intelligent Document Processing), taip pat atliekamas tam tikrų raštų atpažinimas, todėl įrankis tampa nepriklausomas nuo dokumento išdėstymo.
Dokumentų struktūros kategorizavimas
TW: Kai turime dokumentą, jis greičiausiai turės tam tikrą struktūrą. Galėtume suskirstyti tokius dokumentus į kategorijas:
- Visiškai be struktūros: jei paimtume vieną sutartį ar kokį nors sertifikatą, jis gali visiškai skirtis nuo kito.
- Dalies struktūros (pusiau struktūruoti): įprasti tipai, tokie kaip sąskaitos faktūros ar pirkimo užsakymai, kuriuose galima tikėtis tam tikros informacijos. Pagal Lenkijos teisės aktus privaloma įtraukti tam tikrą informaciją į sąskaitą faktūrą. Taigi galima tikėtis ne tik tam tikrų duomenų buvimo, bet ir tam tikros struktūros (pavyzdžiui, antraštės, kartojamos per kelis puslapius).
- Pilnos struktūros: mūsų garsioji mokesčių forma PIT arba senasis banko pavedimų būdas pašte.
Šiuo metu dėmesys sutelkiamas ne tik į teksto gavimą, bet ir į vietos nustatymą, tikėtina, dokumento pasvirimo kampą bei įvairius kitus parametrus. Trumpai tariant, svarbu ne tik išgauti tekstą, bet ir atpažinti struktūrą – tai labiau primena vaizdų atpažinimą, o ne vien teksto nuskaitymą.
AK: Tai yra kažkas, kas žmogui labai paprasta. Atsimenu, kai mane mokė skaityti tas sąskaitas – parodė kelias, paaiškino, kokios informacijos ieškoti – ir žmogui labai lengva atpažinti tokius raštus. Tačiau kompiuteriui tai visada buvo labai sunku padaryti.
IDP darbo eiga: klasifikacija, požymių išskyrimas ir duomenų išvedimas
AK: Kaip tai veikia taip, kad įkeliame skaitmenizuotą sąskaitą faktūrą, o išvestyje gauname visą informaciją gražiai surikiuotą „Excel“ lentelėje?
TW: Remiantis projektais, kuriuos esu atlikęs, įprastas procesas apima kelis esminius žingsnius, kuriuos visada reikia atlikti.
1 žingsnis: skaitmeninimas ir požymių išskyrimas
TW: Ne kiekvienas dokumentas, kurį turite, bus natyvus (pavyzdžiui, PDF failas, kuriame galima pažymėti tekstą). Kartais jis būna plokščias arba net nuskenuotas, todėl įrankiai turi atlikti OCR arba tiesiog išgauti tekstą. Pirmasis žingsnis būtų skaitmeninimas, ir čia atsiveria visa OCR tyrimų sritis.
Iš esmės mums reikia gauti tekstą, tačiau be paties teksto taip pat išgauname požymius. Tai įgauna didelio objekto formą (programavimo prasme), kuriame yra įvairiausių parametrų. Tai gali būti žodžiai, jų vietos, galbūt artimiausia aplinka, tokie duomenys kaip dokumento pasvirimo laipsnis ir įvairūs svoriai bei šališkumai, kurių galima tikėtis. Šis dokumento objektų modelis tada perduodamas tam tikram mašininio mokymosi algoritmui.
Klasikiniame požiūryje tai greičiausiai būtų giliųjų neuroninių tinklų derinys, skirtas vaizdui (struktūrinei daliai), ir konvoliuciniai neuroniniai tinklai. Teksto daliai greičiausiai būtų naudojami įterpiniai (embeddings). Tokie modeliai gali būti iš anksto apmokyti (tiekėjas gali pasiūlyti konkrečiai sąskaitoms ar kitiems dokumentų tipams pritaikytus modelius) arba juos reikėtų apmokyti pačiam.
2 žingsnis: dokumentų klasifikacija
TW: Pirmas dalykas, kurį reikia padaryti, yra klasifikacija. Jei negalite užtikrinti, kad gaunate tik vieno tipo dokumentus, reikės juos klasifikuoti. Algoritmas, be žmogaus įsikišimo, nustato, kokio tipo dokumentas tai yra (pavyzdžiui, sąskaita faktūra ar galbūt kredito sąskaita). Tai nebus paprastas klasifikatorius, paremtas raktiniais žodžiais, o mašininio mokymosi metodas.
AK: Taigi, jei algoritmas nėra tikras, kad tai būtent šio tipo dokumentas, jis kreiptųsi pagalbos į žmogų, o tada šiuos duomenis galėtume panaudoti modelio perkvalifikavimui, kad jis taptų tikslesnis ir labiau pasitikėtų savo sprendimais?
TW: Taip, būtent. Galima sukurti grįžtamojo ryšio ciklą – jei vis tiek reikia žmogaus patvirtinimui, kodėl to neišnaudoti ir nepanaudoti šių duomenų kaip papildomų mokymo pavyzdžių modeliui sustiprinti. Kai jau žinote, kokio tipo dokumentas tai yra, jį galima nukreipti į specializuotus modelius (pavyzdžiui, vieną modelį tik sąskaitoms faktūroms, kitą – užsakymams), taip dokumentas patenka būtent į tinkamą modelį.
3 žingsnis: duomenų išgavimas
TW: Antroji dalis, kurios dažniausiai tikimasi, yra išgavimas – tai yra svarbiausios informacijos ištraukim as iš dokumento. Pavyzdžiui, sąskaitose faktūrose tai būtų sąskaitos numeris, data, produktai ar paslaugos, už kurias mokama. Tikslas yra, kad algoritmas tiksliai paimtų šias konkrečias reikšmes, kad būtų galima gauti struktūruotą duomenų formatą, su kuriuo vėliau galima dirbti. Tokiu būdu nebereikia, kad žmogus viską ranka perrašinėtų ar net kopijuotų ir įklijuotų, kas taip pat yra monotoniška ir varginanti užduotis.
Įgyvendinimas ir žmogaus dalyvavimo cikle (HITL – Human in the Loop) būtinybė
AK: Taigi įrankis supranta, kokio tipo dokumentas tai yra, žino, kokius duomenis reikia iš jo gauti, ir tada juos išgauna iš dokumento. Kas vyksta toliau? Kaip tai susiejama su mūsų verslo procesais?
TW: Kadangi dabar turite struktūruotus duomenis, iš esmės galite daryti viską, kas įmanoma programiškai arba naudojant RPA. Kaip tai susiejama, priklauso nuo jūsų IDP sprendimo tiekėjo.
🔸 Tai gali būti bet kas – nuo paprasto API (tinka bet kuri programavimo kalba).
🔸 Naudojant sudėtingesnes platformas (pvz., UiPath), bus paruoštos sąsajos ar net RPA bibliotekos, kuriose rasite paruoštas veiklas – tereikia pasirinkti modelį ir dokumento kelią.
Jei neturite išteklių sudėtingam programavimui (ne RPA stiliaus, ne „low code“, o klasikiniam programavimui), reikia iš anksto pasidomėti integracijomis, nes tai gali gerokai padidinti įėjimo barjerą. Tokie sprendimai kaip Document Understanding siūlo viską paruošta „iš dėžutės“, ir patirtis yra tikrai labai gera net ir netechniniams vartotojams. Mokymosi sąsają aš dažnai vadinu „spalvinimo knygele“, nes verslo vartotojas tiesiog pažymi teksto ar duomenų fragmentus patogioje grafinėje sąsajoje.
Žmogaus dalyvavimo cikle (HITL) ir pasitikėjimo balo vaidmuo
AK: Su tais senosios mokyklos OCR’ais būdavo taip – jei modelis nesugebėdavo apdoroti tam tikro dokumento, jis būdavo perduodamas žmogui rankiniam apdorojimui. Jei nebuvo skiriama pakankamai dėmesio priežiūrai, modelis vis mažiau ir mažiau suprasdavo jūsų sąskaitas faktūras. Kaip tai veikia naudojant Intelligent Document Processing?
TW: Reikėtų ieškoti sprendimo, kuris apima vadinamąjį Human in the Loop principą. Procesas nėra nutraukiamas, tačiau jo viduryje įtraukiamas žmogus (ne robotas ar dirbtinis intelektas), kuris patikrina, ar duomenys yra teisingi. Taip pat galima paleisti kelis elementus lygiagrečiai, kad viskas nesustotų vien dėl to, jog reikia patvirtinti vieną dokumentą.
Patvirtinimo stotis yra grafinė vartotojo sąsaja, kurioje rodomas dokumentas kartu su atpažinto dokumento tipo reikšmėmis ir visais laukų duomenimis. Čia galima patikrinti, ar modelis veikė teisingai. Štai čia atsiranda svarbus pasitikėjimo balo (confidence score) aspektas. Reikia suprasti, kad tai nėra klasikinis RPA procesas. Neuroninis tinklas pateikia tam tikras reikšmes (dažniausiai nuo 0 iki 100 %), kurios parodo, kiek modelis pasitiki, jog konkreti reikšmė yra būtent ta, kurios ieškome. Tada galima nuspręsti, ar, tarkime, 85 % pasitikėjimo lygis yra pakankamas, kad būtų paleista kita automatizacijos dalis. Mūsų įprastas požiūris yra nebijoti heuristikos. Dirbtinis intelektas yra puikus, bet nereikėtų bijoti pasitikrinti duomenų ar susikurti atvaizdavimo lentelių (pavyzdžiui, pirmiausia surasti sąskaitos faktūros numerį sistemoje), o tik tada nuspręsti, ar rodyti patvirtinimo stotį žmogui.
Žmogaus ir mašinos tikslumo paradoksas
TW: Įrankis tikriausiai atliks apie 80% darbo, tačiau dar nesame pasiekę tokio lygio (nebent labai paprastais atvejais), kad viskas vyktų visiškai be žmogaus įsikišimo. Vis dar retas kuris svarbiuose procesuose palieka viską vien dirbtiniam intelektui.
AK: Reikia nepamiršti, kad DI neturi būti tobulas – bet juk ir žmonės nėra. Mūsų teisingumo KPI dažniausiai siekdavo apie 96 % sąskaitų registravimui. Tai reiškia, kad 4% sąskaitų, kurias apdorojo žmonės, vis tiek būdavo klaidų. Darbas tampa labai monotoniškas, todėl lengva susiklaidinti ar ką nors pamiršti. Suprantu, kodėl verslai atsargiai žiūri į nedeterminuotus modelius, bet juk ir žmonės šioje srityje nėra daug geresni.
TW: Žmonės netikrina taip kruopščiai. Parodyk man žmogų, kuris turėtų tiek kantrybės, kad tikrintų 30 puslapių PDF dokumentą eilutė po eilutės pagal MRP sistemą. Jei esi didelė įmonė, kasdien gauni tūkstančius ar net dešimtis tūkstančių sąskaitų faktūrų. Tiesiog neįmanoma reikalauti iš žmogaus, kad jis peržiūrėtų, tarkime, 10 000 puslapių ir juos palygintų su kokia nors duomenų baze. Reikia suprasti, kad tiek žmonės, tiek mašinos klys, todėl procesai turi būti sukurti taip, kad galėtų su tuo susitvarkyti.
Naudojimo atvejai: ne tik sąskaitoms faktūroms ir didelės apimties dokumentams
AK: Kai pradėjome nuo sąskaitų faktūrų, tai buvo tas atvejis, nuo kurio dauguma įmonių pradeda dirbdamos su Intelligent Document Processing, nes sąskaitas gauna visi, o kuo didesnė įmonė, tuo jų daugiau. Tačiau kokius kitus dokumentų tipus dar būtų prasminga apdoroti naudojant IDP technologiją?
TW: Aš siūlyčiau atsispirti nuo dviejų pagrindinių funkcijų – klasifikavimo ir išgavimo (tai yra suprasti, kokio tipo dokumentas tai yra, ir tada iš jo paimti duomenis) – ir tada pagalvoti, ką galima būtų nuveikti su šiomis dviem funkcijomis įvairiuose procesuose. Kiti pavyzdžiai, kuriuos esame įgyvendinę ir kurie yra įdomesni (nes vien klasifikavimas, išgavimas ir duomenų suvedimas kitur yra pats dažniausias scenarijus), buvo dokumente esančio parašo atpažinimas.
Naudojimo atvejis 1: parašo buvimo atpažinimas
TW: Vienam klientui visiškai nerūpėjo joks tekstas ar duomenys – jiems tereikėjo, kad trijuose laukuose tam tikruose pristatymo dokumentuose būtų nurodyta, ar visi trys yra „taip“. Ten buvo antspaudai ir ranka rašyti parašai. Tokiais atvejais verta pasitelkti labiau į vaizdų atpažinimą orientuotas sistemas, nes jos tam labiau pritaikytos. Laimei, mūsų naudojamas sprendimas palaiko specialų lauką parašams, ir jie gali būti tiesiog loginės reikšmės („taip“ arba „ne“). Panaudojome šią funkciją, ir maždaug 80–90 % atvejų sistema parašus atpažino teisingai.
Naudojimo atvejis 2: duomenų maskavimas (anonimizavimas)
TW: Kitas pavyzdys buvo su lietuviška įmone, kur tam tikros valstybinės institucijos pareikalavo iš įmonės pateikti tam tikrus dokumentus, ir jos turėjo teisę tai daryti. Tačiau kita vertus, reikėjo laikytis GDPR, todėl jos negalėjo tiesiogiai perduoti tų dokumentų. Reikėjo užmaskuoti (anonymize) darbuotojų asmeninius duomenis, nes greičiausiai tai buvo kažkokie HR ar sutartys. Sprendimas buvo pasinaudoti tuo išgavimu, bet ne išgauti duomenis, o nustatyti, kur tie asmeniniai duomenys yra, o tada pasitelkti trečiųjų šalių bibliotekas (we used Python), kurios tiesiog uždėdavo juodus stačiakampius ant tų vietų ir tuomet sulieti viską į failą, kurio neįmanoma atstatyti.
Naudojimo atvejis 3: HR dokumentų valdymas ir skaidymas
TW: Dar vienas įdomus atvejis, vėlgi didelės apimties ir sudėtingas – HR dokumentai. Jie turėjo daug HR dokumentų (sutartys, sporto klubų narystės kortelės, sveikatos priežiūros susitarimai). Jie norėjo juos skaitmeninti, bet tiesiog įdėjo popierių krūvas į skaitytuvą, dėl ko susidarė 100–150 puslapių sujungti PDF failai. Jei dokumentai sujungti, sunku suprasti, kur baigiasi dokumentas A ir prasideda dokumentas B. Šie įrankiai gali padėti ir čia, bandydami nustatyti, kad dokumentas tęsiasi nuo čia iki čia, ir padalinti jį į dalis. Bendras tikslas buvo vėliau patikrinti, ar darbuotojas (pvz., John Smith) turi pasirašytus tam tikrus dokumentus (pvz., šią sutartį ir dar šią, bet galbūt medicininės priežiūros dokumentų neturi).
AK: Taigi, suprantu, ką sakai – kartais pradėtume nuo paprastų dokumentų, labiau struktūruotų, didelės apimties, pavyzdžiui, sąskaitų faktūrų, pirkimo užsakymų, sąskaitų išrašų. Tada, kai kalbame apie HR administraciją, gauname daug popieriaus. Daugelis įmonių vis dar vykdo visų archyvų skaitmeninimo procesą. O tada turime tą „dėžę“ su keistesniais dalykais – kaip sakai, parašų atpažinimas ar duomenų maskavimas. Tai labiau kūrybiškas įrankio naudojimo būdas, kad būtų galima tvarkyti bet kokius dokumentus, kurie gali pasitaikyti.
Techninės iššūkiai ir „skaitmeninio popieriaus“ paradoksas
AK: Ir viena iš dalykų, kurie mane stebina, yra tai, kad naudojame PDF failus, tačiau PDF iš tikrųjų nėra pats tinkamiausias formatas duomenų apdorojimui. PDF vis dar yra nestruktūruoti duomenys (nebent turite kokius nors paslėptus sluoksnius su struktūra). Per tuos 20 metų (nuo tada, kai pradėjau rankiniu būdu tvarkyti sąskaitas faktūras) mes perėjome nuo popieriaus prie to, kas iš esmės yra skaitmeninis popierius, bet jis vis tiek lieka popierius, nes tai nėra struktūruoti duomenys. Mes nesame perėję prie CSV failų ar SQL lentelių – tiesiog perėjome nuo vieno popieriaus tipo prie kito.
TW: Žmonės dažnai pamiršta, kad PDF iš pradžių buvo sukurtas spausdinimui (pvz., marketingui, skaitmeninėms lankstinukams), tačiau greitai tapo populiariausiu formatu praktiškai bet kam. Tai buvo tarsi savęs nusižengimas – nesiekėme sukurti geresnių standartizuotų formatų. Šiandien šie įrankiai iš esmės padeda mums ištaisyti praeities klaidą. Jei viskas vyktų per API ar kokią nors EDI sistemą, šių DI įrankių nereikėtų duomenims atpažinti.
Centralizuota elektroninė sąskaitų faktūrų sistema ir IDP ateitis
AK: Tai būtų mano kitas klausimas – kai kuriose Europos šalyse jau veikia centralizuota sąskaitų faktūrų sistema. Lenkijoje su tuo vis dar kovojame; įgyvendinimas buvo kelis kartus atidėtas, bet galbūt kažkada tai įvyks. Kaip manai, kaip tai paveiks poreikį naudoti IDP technologijas?
TW: Šiuo metu, atsižvelgiant į turimą situaciją, sunku pasakyti. Kadangi sąskaitos faktūros yra pats populiariausias dokumentų tipas, bent jau verta apsvarstyti ir pasidomėti Europos Sąjungos ar vietos valdžios iniciatyvomis. Matau, kad vyriausybės vis labiau pereina prie skaitmeninimo. Todėl bent jau reikėtų atlikti tyrimą, kad netyčia nesukurtumėte sprendimo per pusę metų, o po pusmečio visi pereitų prie skaitmeninių sąskaitų faktūrų, ir tai taptų teisiškai privaloma.
AK: Tačiau tyrimas turi būti kruopštus, nes, kiek suprantu, dauguma tų sąskaitų faktūrų sistemų turi tik pagrindinius duomenis iš sąskaitos ir neturi lentelių su detalėmis. Taigi vis tiek reikia rasti būdą, kaip jas nuskaityti. Be to, tai tik sąskaitos faktūros, o mes vis dar apdorojame daug kitų dokumentų tipų.
TW: Technologijų pažanga ir jų įsisavinimo greitis – visiškai skirtingi dalykai. Stebime, kad IDP sprendimai buvo naujovė prieš 3–4 metus, tačiau žmonės vis dar ateina pas mus su tais pačiais senais dalykais, tais pačiais problemų ir tais pačiais PDF. Manau, kad tai dar ilgai išliks. Kažkas, kas jau veikia ir gali atnešti pelno, vis tiek bus geriau nei sekti svajonę ir nieko nepasiekti.
Tiekėjo pasirinkimas: kodėl UiPath Document Understanding
AK: Rinkoje yra keli pagrindiniai žaidėjai, o Office Samurai daugiausia naudojame UiPath Document Understanding. Ar gali pasakyti, kodėl mes tai darome, kodėl nenaudojame daugumos kitų tiekėjų?
TW: Manau, mūsų įpročiai čia atlieka svarbų vaidmenį – mes jau pažįstame šią technologiją. Tiekėjas yra žinomas dėl gero integravimo su visa kitų produktų portfeliu. Kitas privalumas – įgyvendinimas verslo vartotojams. Aš dažnai vadinu mokymosi sąsają „spalvinimo knygele“ – verslo vartotojas tiesiog pažymi teksto ar duomenų fragmentus. Jie siūlo iš anksto apmokytus modelius, kurie jau turi tam tikrą pradinį efektyvumo lygį. Daugumai dažniausiai naudojamų iš anksto apmokytų laukų sąskaitoms faktūroms galima tikėtis vidutinio pasitikėjimo balo 60–70 %. Jei jau naudojate šią programinę įrangą RPA, kito įrankio įdiegimas toje pačioje platformoje yra labai paprastas. Be to, jie dažnai minima kaip lyderiai šioje technologijoje.
Hibridinis požiūris: IDP ir dideli kalbos modeliai (LLM)
AK: Gauname klausimų apie didelius kalbos modelius (LLM). Daugelis įmonių galvoja: „Kodėl, vietoj intelektualaus dokumentų apdorojimo, negalime tiesiog įdėti dokumentų į ChatGPT?“ Koks tavo požiūris į tai?
TW: Pirmas dalykas, kurį visada pabrėžiu, yra pakartojamumas. Dirbant su didelėmis apimtimis reikia sukurti darbo eigą. Antra, transakcijoms skirtuose dokumentuose, pavyzdžiui, sąskaitose faktūrose, pats tekstas nėra labai turtingas. LLM skirti kalbos supratimui, o ne struktūrų supratimui. Čia specializuoti IDP sprendimai vis dar veikia geriau.
Labai įdomi sritis būtų hibridų kūrimas. Galite paimti IDP sprendimo išvestį ir tada paprašyti LLM ją, pavyzdžiui, patikrinti. Galima sukurti agentą, turintį prieigą prie jūsų ERP sistemos, kuris galėtų ieškoti duomenų ir juos patikrinti. Didelė sritis yra „fuzzy matching“ – galite paprašyti agento patikrinti, ar skirtingai suformuluotas produkto pavadinimas iš tikrųjų reiškia tą patį, tik išreikštą skirtingais žodžiais. Kita sritis, kur LLM galima naudoti, yra rankraštis. Mūsų technikos vadovas Konradas pateikė OCR tekstą kartu su vaizdu, kuriame buvo daug rankraščio, ir paprašė LLM ištaisyti kai kurias rankraščio klaidas. Gavome geriausią iš abiejų pasaulių.
Trečias faktorius yra pasitikėjimo lygis. LLM jums nesuteiks jokio tikimybės įvertinimo. Naudojant LLM visi yra girdėję apie „halucinacijas“. Kai modelis klysta, jis jums pasakys, kad tai „halucinacija“ su 100 % tikrumu. Dauguma vadovų šiuo metu tikrai nepaliktų visko DI be jokio žmogaus priežiūros. Taigi kol kas naudojame hibridinį požiūrį.
Kai automatizacija susiduria su kliūtimis: probleminiai dokumentai
AK: Ar susidūrėte su projektais ar dokumentų tipais, kur šioji technologija nepavyko arba neveikė taip, kaip tikėjomės?
TW: Rankraštis vis dar yra problema, todėl venkite rankraščių. Reikia tikėtis, kad sistema veiks gerai tik tada, kai rankraštis yra įskaitomas. Žemos kokybės skenavimai dabar pasitaiko retai; aš paklausčiau savęs, ar nebūtų pigiau tiesiog pakeisti įrangą. Parašai taip pat kelia problemų, ypač jei jie neįskaitomi. Mums tereikėjo patikrinti, ar jis yra, ar ne.
Tačiau pats problematiškiausias dalykas buvo įdėtos lentelės. Įrankis gali apibrėžti dvimatę X ir Y struktūrą, bet dažnai dokumentai linkę kurti vieną didelę lentelę, o vienoje stulpelio dalyje būtų kita lentelė. Modelio mokyti tokiam dalykui tampa sudėtinga. Reikėjo naudoti sprendimus „aplink“ ir atlikti duomenų postapdorojimą.
AK: Tai mūsų pranešimas visiems, kurie kuria sąskaitas faktūras ir kitus dokumentų tipus: jei norime pakeisti žmones, kurie tiesiog perrašo ar kopijuoja duomenis iš šių dokumentų
TW: leiskite nustoti daryti tas išmanias išdėstymo schemas. Iš tiesų automatizacijai geriau tiktų teksto failas, kuriame viskas būtų tiesiog išdėstyta eilutė po eilutės.
AK: Jokios įdėtų lentelių, prašau.
Paskutinės mintys: IDP ar apokalipsė
AK: Na, galbūt kažkada pasieksime pasaulį, kuriame intelektualaus dokumentų apdorojimo nebereikės, nes duomenis keisimės taip, kaip tai prasminga XXI amžiuje, o ne XX amžiuje. Tačiau tai užtruks ilgai.
TW: Jei pradedate nuo nulio kaip nauja įmonė ar startuolis, jau dabar pagalvokite, kaip gerai su tuo tvarkysitės. Jei galite įtraukti kokį nors skaitmeninį procesą, kur kompiuteriai tarpusavyje bendrauja per API arba standartizuotus formatus, tokius kaip XML ar JSON, tai vis tiek bus geriau nei tiesiog pakeisti popierių jo skaitmenine PDF versija.
AK: Manau, galime aiškiai matyti, kad yra daugybė būdų, kaip naudoti intelektualų dokumentų apdorojimą. Ir tai ne tik apie taupymą.
TW: Tai taip pat susiję su tuo, kad vis sunkiau rasti žmonių, kurie iš tikrųjų norėtų dirbti tokį darbą. Rasti žmones, kurie tai darytų pakankamai ilgai, kad būtų prasminga juos apmokyti, tampa tikrai sunku. Šios apimtys nesumažės; kiekvienam verslui reikia augti. Taigi matome dvi galimybes: arba įdiegti intelektualų dokumentų apdorojimą, arba tiesiog laukti apokalipsės.
AK: Šiuo optimistišku akcentu, Tomai, labai ačiū, kad pasidalinai savo patirtimi.
TW: Pirmiausia, pažiūrėkime, ką mums duoda tas pranešimas apie išmanių PDF vengimą. Tiems, kurie kuria dokumentus – prisiminkite, po penkerių metų mes tai patikrinsime. Paprastumas yra gražu. Ačiū visiems.
AK: Gerai, draugai, štai ir viskas – dar viena Office Samurai tinklalaidė supjaustyta, susmulkinta ir patiekta kaip jūsų mėgstamiausia sashimi lėkštė. Šią seriją paruošėme bendradarbiaudami su „UiPath“, mūsų pirmuoju pasirinkimu proceso automatizacijos platformose. Didelis ačiū jums, mūsų klausytojams, kad prisijungėte – nesvarbu, ar esate kelionėje, įstrigę susirinkime apsimetinėjantys rašantys pastabas, ar tiesiog slepiatės nuo savo pašto dėžutės. Mes jus vertiname ir pažadame dar neautomatizuoti. Didelis ačiū mūsų svečiui, Tomaszui Wierzbickiui, už tai, kad parodė kelią į pergalę prieš popierizmą. Kaip visada, plojimai Annai Cubal, mūsų prodiuserei, kuri valdo šias serijas tiksliau nei IDP modelis, skaitantis idealiai suformatuotą sąskaitą faktūrą. Viskas buvo įrašyta legendiniame „Wodzu Beats Studio“, kur kava stipri, bet mūsų neapykanta rankiniam duomenų įvedimui dar stipresnė. Jei jums patiko tai, ką girdėjote, pasakykite draugams, o jei nepatiko – tikrai pasakykite priešams. Nepamirškite užsiprenumeruoti ten, kur šiuo metu atidėliojate – Spotify, Apple arba to keisto tinklalaidžių programėlės, kurią rekomendavo jūsų pusbrolis. Ir jei jums patiko, nepatiko, turite pasiūlymų ateities epizodams ar tiesiog norite diskutuoti apie santrumpas, nedvejodami susisiekite. Siųskite mums savo atsiliepimus, klausimus ar net haiku apie automatizavimą. Mes čia, Samurajai, esame atviri. Iki kito karto – laikykite savo kardus aštrius, o procesus dar aštresnius.
