Праз 2 тыдні пасля выхаду ChatGPT першае, што мне захацелася паспрабаваць, гэта выцягнуць мадэллю суму з плацёжнага дакумента. Я хацеў убачыць, як выглядае памылка ўнутры канвеера, бо там адказы ніхто не чытае і бачаць іх толькі праверкі. API ў ChatGPT пакуль няма. Яго токенаў я не бачу. Таму я ўзяў Flan-T5, мадэль Google, якую можна запусціць на сваёй машыне.
Стэнд наўмысна нудны. Мадэль абгорнутая маленькім HTTP-серверам, які вяртае адказ у полі generated_text, як Hugging Face Inference API. Код 500 ён вяртае, толькі калі ў Python узнікла выключэнне. Мой кліент адпраўляе дакумент і пытанне, а ў канцы радок “Answer with the amount only”. Потым правярае тое, што я праверыў бы ў любога ўнутранага сэрвісу: статус 200, цела гэта JSON, адказ разбіраецца як сума. Гэтыя 3 праверкі я напісаў першымі, не задумваючыся. Толькі потым зразумеў, што няправільны лік праходзіць усе 3.
Версіі, бо ад іх залежаць лічбы: Python 3.9, torch 1.13.1 на CPU, transformers 4.25.1, прагнае дэкадаванне. У Flan-T5 base 250M параметраў, у large 780M, вагі ў абедзвюх апублікаваныя 21 кастрычніка. Дакументаў 600, яны сінтэтычныя і згенераваныя скрыптам з фіксаваным seed, так што правільны адказ я ведаю для кожнага. Відаў 6, па 100 кожнага. Гэта рахунак, рахунак з неаплачанай папярэдняй запазычанасцю, пацвярджэнне пераказу, чэк, ліст пра вяртанне грошай і напамін пра аплату. Палова дакументаў піша лікі як PLN 1,284.50, палова па-еўрапейску, 1 284,50 PLN.
Дашборд
Base зрабіла 2000 выклікаў. Кожны дакумент атрымаў асноўнае пытанне і тое ж пытанне іншымі словамі. 4 віды дакументаў атрымалі яшчэ па 2 пытанні пра іншыя палі, яны патрэбныя для адной праверкі ніжэй. Усе 2000 выклікаў вярнулі 200, кожны адказ удалося разабраць. Панэль у Grafana для такога сэрвісу паказала б 0 памылак.
Няправільнай аказалася 161 сума з 600.
Першым няправільным адказам, які я адкрыў, быў чэк з TOTAL 437,78 EUR, а мадэль адказала 43778 EUR. Спачатку я вырашыў, што коску з’еў мой парсер, потым, што яе губляе токенізатар пры дэкадаванні. Праверыў і тое і другое, перш чым паверыў, што гэта мадэль. Токенізатар разбівае ўваход на ▁4, 37, ,, 78, ▁EUR, а мадэль згенеравала ▁4, 37, 78, ▁EUR. Коска на гэтым кроку была ў яе другім варыянтам, з імавернасцю 0,12 супраць 0,79 у 78. У выніку сума становіцца ў 100 разоў большай. Так здарылася 52 разы на правільным ліку і яшчэ 10 разоў на іншым ліку з дакумента. Усе 52 выпадкі ў запісе з дзесятковай коскай.
Большы клас памылак заўважыць цяжэй. 68 няправільных адказаў гэта іншыя сумы з таго ж дакумента, запісаныя як звычайныя сумы, проста не тая, пра якую я пытаўся. У напаміне напісана “Invoice 52081 dated 2022-05-02 for PLN 2,501.80 is overdue. We received PLN 500.36 from you on 2022-09-21. The remaining PLN 2,001.44 is due…” Base адказала зыходнай сумай рахунку ў 73 напамінах з 100, прычым у 10 з іх яшчэ і згубіла коску. Яшчэ ў 1 напаміне яна памылілася па-іншаму. Я думаў, што яна проста бярэ першую суму. Але ў рахунку з папярэдняй запазычанасцю сума да аплаты стаіць апошнім радком. Там base адказала правільна 87 разоў з 100. Так што я не ведаю, ад чаго гэта залежыць. 27 адказаў гэта кавалкі тэксту, скапіяваныя з дакумента, часцей за ўсё радкі чэка, з якіх мой парсер узяў першы лік. У апошніх 4 лічбы сапсаваныя неяк інакш.
Праверкі, якія можна дадаць без разметкі
Да прагону я запісаў, чаго чакаю, каб потым не падганяць пад вынік. Я чакаў, што праверка “ці ёсць гэтая сума ў дакуменце” зловіць менш за палову няправільных адказаў. Яшчэ я чакаў, што пытанне, зададзенае двойчы рознымі словамі, зловіць больш. Абедзве ідэі не мае. Узгодненасць адказаў выкарыстоўвалі Wang et al. у сакавіку, а ў ліпені Kadavath et al. вывучалі, наколькі мадэль ведае, калі яна мае рацыю.
У азначэнні маёй першай праверкі па дакуменце была памылка. Яна параўноўвала з любым ланцужком лічбаў, таму колькасць тавару з радка чэка праходзіла. Злавіла яна 66 з 161. Калі я пакінуў толькі сумы з 2 знакамі пасля падзельніка, яна злавіла 91, больш за палову, так што для base маё чаканне не спраўдзілася. Ілжывай трывогі гэтая праверка даць не можа, бо правільны адказ заўсёды ёсць у дакуменце. Строгая праверка фармату патрабуе адзін лік з групамі па 3 лічбы і роўна 2 знакі пасля падзельніка. Яна ловіць амаль тыя ж адказы, 91 з 161, пры 2 ілжывых трывогах на 439 правільных.
Двайное пытанне спрацавала горш, чым я чакаў. Яно злавіла 53 няправільныя адказы і пазначыла 105 правільных з 439. Base часта дае 2 розныя адказы, адзін з якіх правільны. Уласная ўпэўненасць мадэлі справілася лепш, але не настолькі, каб спадзявацца толькі на яе. Я ўзяў сярэднюю лагарыфмічную імавернасць токенаў адказу і пазначыў 20% найменш упэўненых адказаў. Пазначанымі аказаліся 67 няправільных і 53 правільныя. AUROC роўны 0,76, гэта значыць выпадковы няправільны адказ менш упэўнены, чым выпадковы правільны, прыкладна ў 3 выпадках з 4.
Арыфметыка спачатку выглядала пераможцай. У 4 відах дакументаў палі складваюцца: сума без ПДВ (subtotal) плюс ПДВ (VAT) дае выніковую суму, сума рахунку плюс папярэдняя запазычанасць дае суму да аплаты, вяртанне плюс утрыманы збор дае зыходнае спісанне, аплачанае плюс рэшта да аплаты дае суму рахунку. Я пытаю ў мадэлі значэнні 2 іншых палёў і складваю. Там, дзе гэта дастасавальна, праверка злавіла 103 няправільныя сумы з 103 і пазначыла 130 правільных з 297. Потым я паглядзеў на рахункі. На пытанне пра VAT base ні разу не дала правільнага ліку і 67 разоў вярнула subtotal, так што на рахунках праверка пазначае ўсё запар. Без рахункаў яна злавіла 87 няправільных сум з 87 пры 46 ілжывых трывогах на 213 правільных.
Большая мадэль
Large значна лепшая, але ў 3 разы павольнейшая. На 4 ядрах віртуальнай машыны з AMD EPYC 7713 у яе 1,6 секунды на выклік супраць 0,5. Яна памылілася ў 35 сумах з 600. Зноў усе выклікі вярнулі 200 OK. Усе адказы ўдалося разабраць. Я чакаў менш памылак, але не чакаў, што танныя праверкі амаль перастануць працаваць. Праверка па дакуменце злавіла 7 з 35, строгі фармат 8. Двайное пытанне таксама 7, пры 41 ілжывай трывозе. 20% найменш упэўненых злавілі 14 пры 106 ілжывых. 28 няправільных адказаў з 35 гэта іншыя сумы з дакумента. Выглядаюць яны дакладна як правільныя.
Арыфметыка там, дзе дастасавальная, працуе і тут: 21 з 21 пры 8 ілжывых трывогах на 379, бо large правільна адказала на 791 пытанне пра палі з 800. Разам з арыфметыкай праверка па дакуменце і строгі фармат ловяць 25 з 35.
Астатнія 10 гэта адна і тая ж памылка. Base яе ні разу не рабіла. У пацвярджэнні пераказу large адказвала сумай з радка “Balance after transfer”, гэта значыць астаткам на рахунку пасля пераказу, а не сумай. Так было 11 разоў, строгая праверка адкінула толькі 1 з іх. У base на пераказах таксама было 5 памылак, але гэта згубленыя коскі і сапсаваныя лічбы, іх праверкі бачаць. У маім шаблоне пераказу няма астатку да пераказу, таму ніякая сума не звязвае суму пераказу з іншымі лікамі. Двайное пытанне пазначыла 5 з 10, упэўненасць 2. Для астатніх патрэбна другая крыніца, напрыклад уласны запіс банка пра аперацыю.
Чаго я не правяраў
- ChatGPT і
text-davinci-003. Я мераў толькі 2 невялікія адкрытыя мадэлі і не ведаю, ці губляе коскі значна большая мадэль. Думаю, што не. Але правільны лік не з таго радка гэта памылка, якая, як я чакаю, застанецца. - Сапраўдныя дакументы. Мае 6 шаблонаў кароткія і чыстыя, таму доля памылак па шаблоне кажа пра мае шаблоны. Тое, што base памылілася ў 74 напамінах з 100, хутчэй кажа пра тое, як я напісаў напамін, чым пра мадэль.
- Промпты. Адна фармулёўка інструкцыі і адзін перафраз кожнага пытання. Іншая інструкцыя магла б моцна змяніць вынік на напамінах.
- Паўторы. Толькі прагнае дэкадаванне. Усе вынікі тут з аднаго прагону. Я перазапусціў 2 дакументы па-за серверам і атрымаў тыя ж токены, але ўвесь прагон не паўтараў.