OCR to skrót od angielskiego Optical Character Recognition (po polsku zazwyczaj mówi się po prostu o rozpoznawaniu tekstu). To informatyczny proces, który polega na analizie grafiki (np. skanu lub zdjęcia tekstu), którego efektem ma być rozpoznanie tekstu i zapisanie go w formie pozwalającej np. na skopiowanie.
Zastosowanie OCR pozwala np. na zamienienie zeskanowanego PDFa w plik z możliwością wyszukiwania lub na edycję tekstu. Zasadniczo z dokumentu papierowego możemy uzyskać tekst w komputerze.
Ale czy ta technologia sprawdza się w każdej sytuacji?
Struktury danych
Weźmy na przykład wydrukowaną fakturę. Skanujemy, wrzucamy w program OCR i mamy wszystkie dane w niej zawarte. Prawda? No nie do końca. O ile rozpoznanie tekstu, gdy chodzi o treść w postaci zdań jest dobrą metodą na ograniczenie pracy, o tyle rozpoznanie tekstu w druku faktury nie niesie ze sobą zbyt wielkich korzyści. Dlaczego? Bo faktury są dokumentem o pewnej strukturze – są w nich dane sprzedającego i kupującego, poszczególne pozycje, wartości netto, brutto itd. Jest to dokument mający według przepisów zawierać pewien zestaw danych, ale niestety przepisy te nie określają konkretnych miejsc dokumentu, w których mają się znajdować. Tym samym nie można zastosować jednego szablonu do rozpoznawania faktury (np. nie można powiedzieć, że dane sprzedawcy są w 100% przypadków po lewej stronie nagłówka, czy że są umieszczone w konkretnej kolejności).
Żeby zastosować technologię OCR do nie tylko rozpoznania tekstu (który nic nie będzie znaczył), ale do wyłuskania z faktury konkretnych danych, nadających się do późniejszej obróbki, potrzebny jest bardzo duży nakład pracy. I nie chodzi tutaj o trudność w zastosowaniu samego procesu OCR. Nakład pracy jest potrzebny do tego, aby „nauczyć” system jak wyglądają faktury od różnych wystawców. Można nawet doprowadzić w ten sposób do sprawnie działającego systemu. O ile oczywiście firma, której fakturę już mamy opisaną, nie zdecyduje się jej zmienić w ramach „nowego, uproszczonego wyglądu”…
A może sztuczna inteligencja?
Tak, z pewnością można tutaj zastosować sztuczną inteligencję. Tylko też trzeba ją nauczyć, jak wyglądają faktury. Rozwój sztucznej inteligencji nie pozostaje obojętny dla potrzebnych mocy obliczeniowych – im bardziej skomplikowane zadania zostaną jej zlecone, tym więcej mocy obliczeniowej, a tym samym mocy wyrażonej w watach („prądu”) zużyje. Do tego użycie metod AI do rozpoznawania danych z faktur wydaje się trochę tym co strzelanie z armaty do muchy.
No to ani OCR, ani AI. Czyli co?
Od wielu, wielu lat organizacje zarówno krajowe jak i międzynarodowe starają się o wypracowanie pewnych standardów. Czasem mowa o standardzie ISO – np. dzięki konkretnym ISO wszyscy ludzie na świecie wiedzą, że gdy mowa o walucie z kodem PLN to chodzi o polskiego złotego. Innym razem standard to stosowana technologia. Najbardziej powszechnym standardem jest chyba przykład USB. Pamiętacie czasy przesyłania danych w komputerach sprzed USB (jak nie – wystarczy poszukać zdjęcia złączy na naprawdę starych laptopach – tutaj przykład starej stacji dokującej). Albo lepiej – ładowarki do telefonów komórkowych sprzed wprowadzenia w nich USB (o iPhone’ach nie wspominam, chociaż coraz bardziej wygląda na to, że „piekło zamarznie”).
Tym czym jest ISO lub właśnie upowszechnione standardy w technologiach (o Bluetooth już nie będę wspominał) w świecie nie-programistów, tym w świecie ludzi programujących są struktury danych możliwe do przesłania np. w postaci XML (ang. Extensible Markup Language – rozszerzalny język znaczników).
Jak to się ma do faktur? Prosto – zamiast mieć plik PDF, który ktoś wydrukuje i będzie go trzeba skanować, rozpoznawać, analizować wystarczy przesłać pakiet ustrukturyzowanych danych.
Upraszczając do bólu, fragment opisu faktury mógłby w takim pliku wyglądać tak:
<faktura>
<numer_faktury>1/06/2023</numer_faktury>
<wystawca>
<nazwa>Arkon</nazwa>
<nip>mój nip</nip>
<adres>
<kraj>PL</kraj>
<kod_pocztowy>00-002</kod_pocztowy>
<miejscowosc>Warszawa</miejscowosc>
<ulica>Koszykowa</ulica>
<numer_budynku>30</numer_budynku>
</adres>
</wystawca>
<odbiorca>
…
</odbiorca>
<pozycje>
<pozycja>
<lp>1</lp>
<nazwa>zestaw do odbioru telewizji satelitarnej</nazwa>
I tak dalej. I tak dalej.
Ale co to daje?
Wbrew pozorom podstawową zaletą takiego rozwiązania jest prostota. Narzucony schemat danych pozwala na ich wymianę między dowolnymi systemami informatycznymi. Nie ma konieczności „uczenia” systemu opisu każdej kolejnej faktury. Problem zmiany wyglądu faktury po prostu przestaje istnieć.
Analiza tego typu pliku jest nieporównywalnie mniej zasobożerna (a tym samym prądożerna) niż rozpoznawanie tekstu, o zastosowaniu metod sztucznej inteligencji już nie wspominając.
Nie napisałem wcześniej, że OCR może być niedoskonały? Że oprogramowanie zamiast „ł”, może przeczytać „t”? No cóż. Może. I nic na to nie poradzisz. W przypadku ustrukturyzowanego pliku jest w nim czysty tekst. „ł” to zawsze „ł”, a „I” (duża samogłoska „i”) nigdy nie stanie się „l” (mała spółgłoska „L”).
Z punktu widzenia informatycznego – same plusy.
Przeczytane, ale w sumie po co?
Siadałem do tego tekstu ze względu na potyczki z OCR w projekcie, który aktualnie realizuję. Musi być w nim wykorzystana ta technologia.
Ostatecznie chciałbym abyś wzięła/wziął pod uwagę dwie rzeczy:
- Jeżeli będziesz pisał/a projekt, w którym chcesz użyć OCR „bo tak” – dwa razy się zastanów. Sam proces nie jest trudny do implementacji, ale zyski z jego wprowadzenia w wielu przypadkach mogą być mizerne w stosunku do nakładu pracy (i nie chodzi o pracę firmy przygotowującej system, ale o Twoją lub Twoich pracowników, którzy będą później musieli „uczyć” system).
- Żebyś poznał/a skrót KSeF (Krajowy System e-Faktur). Prace nad nim nabierają tempa i należy się spodziewać, że od połowy przyszłego roku wszystkie faktury VAT będą musiały być wystawiane z jego użyciem. A chodzi w nim właśnie o ustrukturyzowane dane. Trochę o aktualnej sytuacji można znaleźć na https://www.gov.pl/web/finanse/rzad-przyjal-projekt-krajowego-systemu-e-faktur-ksef