Ужо 2 тыдні, як выйшаў ChatGPT. З таго часу ў маёй стужцы поўна скрыншотаў, дзе чалавек устаўляе туды дакумент і атрымлівае назад палі. Банкаўская выпіска тут класічны выпадак. Кожны банк выгружае яе па-свойму. Звычайны адказ на гэта парсер з рэгуляркай для кожнага банка, які ламаецца ў той дзень, калі банк мяняе выгрузку. Я ні разу не мераў, як мадэль выглядае побач з такім парсерам. Я лічыў, што дату мадэль хаця б скапіюе правільна. Таму пытанне для мяне было толькі ў тым, як часта яна памыляецца ў суме.
Як я мераў
Я ўзяў 4 фарматы выпіскі і згенераваў скрыптам па 150 аперацый у кожным, seed 2022, так што кожны правільны адказ вядомы. Кожная аперацыя павінна ператварыцца ў 3 палі: дату, суму са знакам (спісанне з мінусам) і контрагента. Фарматы выглядаюць так:
A 14.06.2022 CARD PAYMENT MEDIA EXPERT 7734 GDANSK -248,22 18 848,37
B Date: 2022-06-20 Description: Transfer to Piotr Wisniewski, title: gift Amount: -2,327.19 PLN Balance: -5,575.15 PLN
C 12 Jun 2022 CARD PAYMENT BOOKING.COM 33.40 EUR 157.32 DR 25,180.67 CR
D 15/06/2022 Card payment 4.55 53,361.89
AUCHAN 5293 GDANSKАпошні лік у кожным радку гэта рэшта на рахунку пасля аперацыі. У аплат карткай за мяжой у апісанні ёсць яшчэ сума ў валюце пакупкі. Парсер на рэгулярках я напісаў толькі для A і B, 34 радкі на Python. Напісаў да таго, як паглядзеў на C і D. C і D гуляюць ролю банка, які змяніў выгрузку.
Мадэль гэта Flan-T5 ад Google, base (250 млн параметраў) і large (780 млн), якія выйшлі ў кастрычніку. Яна працуе ў мяне на машыне: 4 ядры віртуалкі на AMD EPYC, Python 3.9, torch 1.13, transformers 4.25.1, прагнае дэкадаванне. На кожную аперацыю 4 пытанні: дата, сума, кірунак грошай і хто другі бок. У промпце ёсць яшчэ радок выпіскі з першым і апошнім днём перыяду. На сапраўднай старонцы ён ёсць і з яго відаць, у якім фармаце банк піша даты. Абодва спосабы атрымліваюць аперацыі ўжо нарэзанымі на блокі, так што разбіццё старонкі тут не мераецца.
Аперацыя лічыцца правільнай, толькі калі правільныя ўсе 3 палі. Няправільны вынік гучны, калі ён не разбіраецца. Гэта значыць, што рэгулярка не знайшла супадзення або мадэль дала дату, якая не дата. Ціхі, калі разбіраецца і няправільны.
Рэгуляркі
На A і B парсер даў 293 правільныя аперацыі з 300. 7 няправільных на маім сумленні. У радку пераводу фармату A імя і прызначэнне плацяжу ідуць запар, без раздзяляльніка, вялікімі літарамі: TRANSFER FROM JAN KOWALSKI LOAN BACK. Я браў за імя першыя 2 словы. Для заробку ад SOFTHOUSE SP. Z O.O. гэта дае SOFTHOUSE SP., без аніякай памылкі. Гэтае правіла я пісаў, не думаючы пра кампаніі.
На C і D парсер не разабраў ніводнага радка, 300 з 300 гучна. Гэтага я і чакаў. Гэта ж звычайны довад на карысць мадэлі.
Мадэль
Flan-T5 large дала 91 правільную аперацыю з 600. Base дала 107, так што большая мадэль лепшай не была.
Я чакаў памылак у суме, але першай зламалася дата. Я нейкі час думаў, што зламаны мой разбор дат, пакуль не паглядзеў на сырыя адказы. З радком перыяду ў промпце large у 360 аперацыях з 600 адказала першым днём перыяду. Для плацяжу ад 14 чэрвеня яна давала 01.06.2022. Тады я прыбраў радок перыяду і спытаў яшчэ раз. Large назвала дату правільна ў 291 аперацыі з 600, base у 567. Часта адказ large гэта не дата з радка: 01.10.2022 замест 10.01.2022, 01/26/2022 у амерыканскім парадку замест 26/01/2022. Часам год быў 2020. 148 з 150 яна набрала толькі ў фармаце B, дзе дата ўжо была запісана як 2022-06-20. Калі я папрасіў скапіяваць дату дакладна так, як яна напісана, яна зрабіла гэта ў 162 выпадках з 600. 143 з іх прыпалі на B.
На кожны ўваходны пераклад large адказвала “out”, акрамя фармату D, дзе ў радку словамі напісана Incoming transfer. “in” яна адказала на 33 уваходныя пераводы з 129, усе 33 у D. На радках без мінуса і на радках з CR large усё роўна адказвала “out”. Я падумаў, што вінаваты парадак варыянтаў у маім пытанні. Таму спытаў яшчэ раз з “in or out” замест “out or in”. Large не змяніла ніводнага адказу. Base ад парадку залежала. Калі першым стаяў “out”, яна адказвала “out” ва ўсіх 600 аперацыях, а калі першым стаяў “in”, адказвала “in” у 583 з 600.
Сума без знака была правільнай у 423 аперацыях з 600. У 114 няправільных мадэль вярнула рэшту, апошні лік у радку. У 22 вярнула суму ў еўра ці доларах з апісання. За контрагента large часта вяртала больш за адно імя, напрыклад SPOTIFY INTERNET. 61 раз яна вярнула толькі горад. Калі прымаць любы адказ, у якім ёсць правільнае імя, выходзіць 526 з 600. З такім нястрогім параўнаннем у large было б 160 правільных аперацый замест 91.
Амаль усе гэтыя памылкі ціхія, бо рэшта разбіраецца як сума гэтак жа добра, як сама сума. З 509 няправільных аперацый large гучнымі былі 32.
Спачатку рэгулярка, мадэль там, дзе рэгулярка не спрацавала
Менавіта такую схему я б і пабудаваў: парсер для знаёмых фарматаў і мадэль толькі для радкоў, якія ён не пазнаў. Яна дала 335 правільных з 600, больш, чым кожны з двух спосабаў паасобку. Але 256 аперацый выйшлі няправільнымі без аніякай памылкі. Акрамя маіх 7 радкоў з заробкам, усе яны прыйшлі з C і D, тых 300 радкоў, на якіх раней была гучная памылка.
Потым я зрабіў тое, што зрабіў бы ў любым выпадку, калі банк мяняе выгрузку: напісаў рэгуляркі для C і D. Гэта яшчэ 29 радкоў. Парсер даў 582 правільныя з 600 і ніводнай гучнай памылкі. 18 няправільных гэта тая ж памылка з заробкам, якую я разам з астатнім кодам перанёс у фармат C. Парсеру трэба каля 6 мікрасекунд на аперацыю. Large трэба ў медыяне 1,2 секунды на пытанне, гэта значыць каля 5 секунд на аперацыю.
Чаго я не правяраў
Гэта адна маленькая мадэль, якую я магу запусціць сам. Гэта не GPT-3 з API OpenAI і не ChatGPT, у якога API пакуль няма. Нічога большага я не правяраў. Я даваў па адным промпце на поле без прыкладаў і нічога не данавучваў. Прымусіць мадэль выдаць усе палі адразу ў JSON я таксама не спрабаваў. Выпіскі сінтэтычныя, у выглядзе чыстага тэксту, без PDF і OCR.
Пакуль я пакідаю рэгулярку для кожнага банка. Мадэль я б выкарыстаў толькі як падказку разбору для радка, які парсер не ведае. Падказку правярае чалавек, перш чым яна некуды пойдзе.