PDF-ті бет бойынша немесе тұтас тексеру: қайсысын таңдау керек

Неліктен ұзын PDF жиі қате береді

Ұзын PDF әдетте бірінші беттен соңғы бетке дейін бір ғана логикаға бағынбайды. Басында жинақы договор шаблоны болуы мүмкін, одан кейін қосымша, кейін скан, кірістірілген кесте немесе басқа форматтағы хат келеді. Парсер алдымен бір құрылымға үйренеді де, кейін мүлде басқа нәрсе алады.

Сондықтан бір өрістер әртүрлі жерден ізделеді. Компанияның реквизиттері кейде бірінші беттің шапкасында тұрады, кейде төменгі жағында ұсақ мәтінмен жазылады, ал кейде тіпті қол қоюлары бар қосымшаға көшіп кетеді. Егер жүйе ИИН, БИН, адрес немесе договор нөмірін тек бір блоктан күтсе, оларды басқа жерден тыныш қана өткізіп жібереді.

Құжат бірнеше файлдан жиналса, мәселе одан да байқалады. Бір бөлігі цифрлық әрі таза болуы мүмкін, ал соңғы 20 беті сұр фонды, мөрі бар, қисайған скан болады. Мұндай беттерде OCR таңбаларды шатастырып, бос орындарды жұтып, жолдарды бұзады. Нәтижесінде БИН ұқсас белгілер жиынына айналып кетеді, ал дата түпнұсқадағыдай оқылмайды.

Кестелерде қате әдетте одан да көп болады. Бір бетте баған атаулары бар, келесі бетте олар жоқ. Жол парақтың төменгі жағында басталып, тасымалдан кейін келесі бетте жалғасады, ал жоғары-төмен жағында колонтитулдар, бет нөмірлері және қызметтік белгілер тұрады. Парсер оларды кестенің бөлігі деп қабылдап, сома мен атауларды көрші бағандарға ығыстырып жібереді.

Сноскаларда жағдай одан да күрделі. Кестедегі сан түсінікті көрінеді, бірақ маңызды түсіндірме беттің төменгі жағында немесе қосымшаның соңында ұсақ шрифтпен жатады. Тек негізгі мәтінді оқысаңыз, санды ескертусіз алып кетесіз. Қаржылық құжаттар үшін бұл қате қорытындының жиі себебі.

Тағы бір көзге аз түсетін мәселе бар: ұзын құжат бірден тым көп контекст береді. Жүйе бүкіл файлды тұтас оқығанда, мағынасы жақын өрістер бір-біріне кедергі жасай бастайды. Қосымшадан алынған шот нөмірі, қосымша келісімнен келген дата және форманың ескі нұсқасындағы реквизиттер араласып кетуі мүмкін.

Әдеттегі мысал — 60 беттік договор. Алғашқы 8 бетте негізгі мәтін, кейін тарифтер кестесі, одан соң банк реквизиттері бар қосымша, ал ең соңында қол қойылған парақтың сканы тұрады. Егер бәрін бір өтіммен шығара салсаңыз, жүйе реквизиттерді финалдық бөліктен емес, басқа жерден алып, кестенің жалғасын жоғалтып, сома астындағы сносканы байқамай қалуы мүмкін. Сондықтан көпбеттік құжаттармен жұмыс істегенде тек мәтінді емес, құрылымды да тексеру маңызды.

Қай кезде бет бойынша талдау жақсырақ

Егер әр бет көршісіне онша тәуелді болмаса, бет-бетімен талдау ыңғайлы. Бұл дата, сома және нөмір бір парақта тұратын счеттар, актілер, өтініштер мен анкеталар үшін жиі кездеседі. Мұндай жағдайда PDF-ті беттері бойынша тексеру әдетте таза нәтиже береді және аз ереже қажет етеді.

Егер құжатта 80 бет болса, бірақ тек 12 беті пайдалы болса, бүкіл файлды бір ұзын мәтін ретінде оқудың қажеті жоқ. Алдымен беттерді қарап шығып, олардың түрін анықтап, бос парақтарды, бөлгіштерді, мұқабаларды және қызметтік кірістірулерді алып тастаған оңай. Мұндай сүзгі көбіне уақытты да, ақшаны да үнемдейді.

Бір файлда қарапайым мәтін мен скандар араласса, бет бойынша тәсіл де ыңғайлырақ. Мәтіні бар беттер үшін дайын мәтін қабатын қолдануға болады. Скандар үшін — OCR тек керек жерінде қосылады. Егер OCR-ды бүкіл құжатқа бірден іске қоссаңыз, ол цифрларды жиі шатастырады, бағандарды бұзады және қолтаңба, мөр, кездейсоқ белгі сияқты нәрселерді іліп алады.

Әсіресе бұл төрт жағдайда жақсы жұмыс істейді: бір PDF ішінде біртекті счеттар топтамасы болса, договорлар архиві бос беттер мен мұқабалармен араласса, әр беттен локал өрістерді іздеу керек болса және файл әртүрлі көзден жиналып, беттердің бір бөлігі мәтіндік, бір бөлігі скан болса.

Мұндай тәсіл PDF-тен локал реквизиттерді шығарып алғанда пайдалы, бүкіл құжатты бірден түсінуге тырысқанда емес. Шот нөмірі, дата, сома, ИИН немесе БИН әдетте бір-біріне жақын тұрады. Парсер бір тұтас парақты көргенде өрістерді аз шатастырады, ал қатар тұрған қырық бетті көрсе, қателесу оңай.

Тағы бір плюс бар: қателерді табу жеңілдейді. Егер бір бет нашар оқылса, ол бірден көрінеді. Оны бүкіл файлды қайта өткізбей-ақ жеке қайта өңдеуге болады.

25 акт пен 5 хат сканы жатқан PDF-ті елестетіңіз. Егер құжатты тұтас оқысаңыз, модель көршілес актілердің сомасы мен датасын араластырып жіберуі мүмкін. Беттер бойынша оқысаңыз, ол әр бланктен реквизиттерді бөлек алады, ал хаттар мен бос парақтарды басынан-ақ сүзгімен алып тастайсыз.

Қашан құжатты тұтас оқу керек

Әр бет өз алдына өмір сүрсе, бет бойынша талдау жақсы. Бірақ ұзын PDF көбіне басқаша құрылады: мағына жеке парақта емес, құжат бөліктерінің байланысында жатады. Модель тек бір үзіндіні көрсе, жиі шындыққа ұқсас, бірақ толық емес жауап береді.

Бұл реквизиттер файлдың әр жеріне шашылғанда айқын көрінеді. Компания атауы басында, БИН немесе ИИН — соңына қарай, банк деректері — қосымшада, ал тараптардың қолтаңбалары — басқа бетте тұруы мүмкін. Егер реквизиттерді бір жинақы объектке жинау керек болса, құжатты тұтас оқыған дұрыс. Сонда модель қай өрістер бір-біріне қатыстын түсінеді және әртүрлі тараптың деректерін аз араластырады.

Кестелерде мәселе тіпті айқынырақ. Кесте бір бетте басталып, келесісінде жалғасып, сноскамен кейін аяқталуы мүмкін. Беттер бойынша бөлгенде бірінші бөлігі толық емес кесте сияқты, ал келесісі жаңа кесте сияқты көрінеді. Соның салдарынан баған атаулары, өлшем бірліктері, қорытынды сомалар және беттер арасындағы жол байланысы жоғалады. Ұзын кестелер үшін тұтас контекст әдетте жақсырақ.

Ескертпелер де сирек жеке өмір сүреді. 18-беттегі сноска 12-бетте көрсетілген ставканы, соманы немесе мерзімді нақтылауы мүмкін. Тек бір бетті оқысаңыз, ескерту ауада қалып қояды. Бүкіл файлды оқысаңыз, модель бастапқы тармақты тауып, нақтылаумен байланыстырады, мағынасын өзі ойдан шығармайды.

Тұтас талдау нәтижеде бүкіл құжатқа арналған бір финалдық объект керек болса да пайдалы. Бұл договорлар, анкеталар, тендер пакеттері және есептер үшін жиі кездеседі. Онда бірдей өрістер қайталанады, қосымшаларда жаңартылады немесе соңында нақтыланады, ал бет бойынша жауаптарды жай ғана біріктіру тым көп ұсақ қате береді.

Әдетте бір өріс бірнеше бөлімнен жиналса, кесте бет үзілісінен өтсе, ескертпе бірнеше бет жоғарыдағы мәтіннің мағынасын өзгертсе немесе құжатты қолмен қоспай-ақ бір финалдық құрылымға жинау керек болса, тұтас оқуға көшкен дұрыс.

Бұл тәсілдің құны бар: өңдеу шығыны өседі, ал модельге бүкіл файлға бірден назарды ұстап тұру қиынырақ. Сондықтан бүкіл PDF-ті әрдайым жіберу керек емес. Бірақ егер бет бойынша талдау құжат бөліктерінің байланысын жоғалтып жатса, тұтас оқу көбіне тыныш өтетін жіберіп алуларды азайтады.

Бес қадаммен тәсілді қалай таңдау керек

Бір PDF-ті әртүрлі тәсілмен талдауға болады, ал таңдау қателігі сапаға тез әсер етеді. Қысқа файлдарда бұл онша байқалмайды, бірақ договорларда, актілерде және қосымшаларда айырмашылық үлкен болады: бір жерде реквизиттер жоғалады, бір жерде кестелер ығысады, бір жерде ескерту жолдың мағынасын өзгертіп жібереді.

Таңдауды әдетпен емес, қысқа тестпен жасаған дұрыс.

1. Алдымен файлдан нақты нені іздейтініңізді бекітіңіз. Құжаттан алынатын дерек деп жалпыламай, нақты өрістерді жазыңыз: договор нөмірі, дата, БИН, сома, валюта, кесте жолдары, жол астындағы ескертпелер. Егер өріс әдетте бір бетте тұрса, бет бойынша талдау жиі таза нәтиже береді.

2. Содан кейін макетті тексеріңіз. Бірнеше құжатты алып, құрылым бет сайын қайталанатынын қараңыз. Егер шапка, реквизит блоктары және кестелер шамамен бірдей орындарда тұрса, бет бойынша схема әдетте қарапайым әрі арзан. Егер құжат әртүрлі шаблондардан жиналса, бірден тұтас оқуды сынаған дұрыс.

3. Бөлек проблемалы беттерді санаңыз. Болжаудың қажеті жоқ, кесте неше бетте тасымалмен бөлінетінін, сноска төменге кететінін және ойдың жалғасы тек келесі бетте шығатынын белгілеңіз. Мұндай жерлер көп болса, жалпы контекстсіз модель жолдарды шатастырады, ұяшықтарды қайталайды немесе ескертпелерді жоғалтады.

4. Кейін нақты деректермен шағын прогон жасаңыз. 20-30 құжат алып, екі тәсілмен өткізіңіз: бет бойынша және тұтас. Егер бірнеше модельді салыстырсаңыз, бір үйлесімді қабат арқылы жасаған ыңғайлы. Мысалы, AI Router-да маршрутты және base_url-ды api.airouter.kz мекенжайына ауыстырып, SDK, код пен промпттарды әр провайдерге қайта жазбайсыз.

5. Соңында тек дәлдікті емес, тағы бірнеше нәрсені салыстырыңыз. Жүйе қанша өрісті жіберіп алды, бір құжатты өңдеу қанша тұрады және жауап қанша уақытта келеді — соны бірге қараңыз. Кейде тұтас оқу 2-3% жақсырақ нәтиже береді, бірақ кідіріс екі есе өседі. Ағынды енгізу үшін бұл онша жақсы айырбас емес.

Тәжірибеде шешім жиі аралас болады. Реквизиттер мен қысқа блоктарды бет бойынша алады, ал ұзын кестелер мен ескертпелерді тұтас немесе көршілес беттер байланысында тексереді. Қосымшасы бар договорлар үшін бұл көбіне ең тыныш нұсқа.

Реквизиттерді артық жіберіп алусыз қалай алу керек

Жіберіп алулардың көбі құжаттың ортасында емес, тыныш жерлерде болады: шапкада, қол қою бөлігінде және қосымшаларда. Договорда нөмір мен дата көбіне бірінші бетте тұрады, БИН мен банк деректері — соңында, ал заңды тұлғаның толық атауы немесе кезеңдік сома — қосымшада. Реквизиттерді бір ғана жерден іздесеңіз, кейбір өрістердің жоғалуы әбден мүмкін.

Жұмыс ережесі қарапайым: әр өріс үшін бірнеше іздеу аймағын белгілеңіз. Дата үшін бұл шапка мен қол қою бөлігі болуы мүмкін. Сома үшін — договор пәні, қосымша кестесі және акт. Компания реквизиттері үшін — "Тараптар" бөлімі, қолтаңбалар және банк деректері бар жеке қосымша.

Шығарғаннан кейін мәндерді бір түрге келтіріңіз. Әйтпесе жүйе мағынасы бір болса да, әртүрлі дерек деп ойлайды. 12.03.2025 және 2025-03-12 форматындағы даталарды бір шаблонға келтірген дұрыс. БИН мен ИИН-ді 12 цифрдан тұратын жол ретінде, бос орындарсыз және артық таңбасыз сақтаңыз. Сомалардағы аралық бос орындарды тазалап, валютаны бір белгіге, мысалы KZT немесе USD-қа келтірген пайдалы.

Нормализация бет бойынша талдау кезінде өте маңызды. Бір бетте модель 12 500 000 тг, басқа бетте 12500000 KZT қайтаруы мүмкін. Бір форматқа келтірмесеңіз, бұл бір сома екенін түсіну қиын.

Бір өрісті бірнеше жерде тексеріп, тек мәннің өзін емес, оны тапқан бетті де сақтаған пайдалы. Сонда қай сәйкестік сенімді, қайсысы даулы екені бірден көрінеді. Ұзын договорлар үшін әдетте төрт тексеріс жеткілікті: өрісті құжаттың кемінде екі бөлігінен іздеу, бет нөмірі мен қасындағы мәтінді сақтау, табылған нұсқаларды нормализациядан кейін салыстыру және айырмашылықтарды қолмен тексеруге жіберу.

Қолмен тексеру ойлағаннан жиірек қажет болады. Договор мәтінінде бір сома, ал түзетуден кейін қосымшада басқа сома тұруы мүмкін. Немесе қолтаңбадағы БИН дұрыс, ал шапкада шаблоннан қалған ескі нұсқа бар. Мұндайда дұрыс жауапты жорамалдамай, мәнді даулы деп белгілеу керек және операторға екі нұсқаны да көрсету керек.

Егер команда көпбеттік құжаттарды LLM-конвейер арқылы өткізсе, әр реквизит үшін confidence score мен page reference сақтаған пайдалы. Бұл қателерді талдауды қатты жеңілдетеді: тек нәтиже емес, әр өрістің қайдан шыққаны да көрінеді.

Кестелер мен сноскалармен не істеу керек

Кестелер мен сноскалар PDF талдауды қарапайым мәтіннен жиірек бұзады. Бұл әсіресе 30-50 беттік договорларда, актілерде және қосымшаларда байқалады, мұнда бір кесте бірнеше параққа созылады, ал сома не мерзімге қатысты түсіндірме беттің төменгі жағына ұсақ шрифтпен кетеді.

Егер кесте жаңа бетке өтсе, келесі парақтағы бірінші жолды автоматты түрде жаңа жазба деп санамаңыз. Алдымен жолдың алдыңғы бетте үзіліп қалмағанын тексеріңіз. Мұны әдетте бірінші бағанның бос болуы, жақтаудың қайталануы, позиция нөмірінің бірдейлігі немесе ұяшықтағы мәтіннің сөйлемнің ортасынан басталуы көрсетеді. Мұндай жағдайда жолдарды реквизиттерді іздеуге дейін біріктірген дұрыс.

Колонтитулдар дерлік әрдайым кедергі жасайды. Страница 12 из 48, құжат атауы, басып шығару күні және Кестенің жалғасы сияқты белгілерді бөлек баған немесе ұяшықтың бөлігі деп қабылдау оңай. Сондықтан оларды құрылымды талдауға дейін алып тастаған дұрыс. Әйтпесе парсер артық бағандарды көреді де, сома мен дата ығысып кетеді.

Практикалық реті мынадай: алдымен беттегі колонтитулдарды, нөмірлерді және қызметтік штамптарды тазарту, содан кейін кесте торын немесе кемінде тұрақты баған шекараларын табу, одан кейін жолдардың бет түйіскен жерінде үзілмегенін тексеру және тек содан кейін сноскаларды бүкіл бетке емес, нақты ұяшықтарға байлау.

Сноскалармен негізгі кесте мәтінінен бөлек жұмыс істеген жақсы. Егер ұяшықта *, 1 немесе кішкентай үстіңгі индекс тұрса, сол белгіні сақтап, оның түсіндірмесін беттің төменінен немесе кестеден кейін тауып алыңыз. Сосын түсіндірмені нақты ұяшықпен байланыстырыңыз. Әйтпесе ҚҚС-сыз деген ескерту бүкіл кестеге жабысып кетуі мүмкін, ал шын мәнінде ол бір ғана жолға қатысты болады.

Қызметтік белгілерді дерекпен араластырмау керек. Қолтаңба, М.О., кестенің соңы, келісім белгілері және ішкі кодтар жиі жанында тұрады, бірақ кесте мазмұнына жатпайды. Оларды бөлек сақтау немесе бірден шаблон бойынша сүзгіден өткізу дұрыс.

Егер құжат бет бойынша бөлшектелсе, кестелер үшін ерекшелік жасаған жөн: талдау терезесіне көрші бетті де қосыңыз. Сонда жолдың тасымалын ұстау және үзілістен кейін келген ескертпені жоғалтпау оңайырақ. Ұзын құжаттар үшін бұл әр бетті қатаң жеке талдаудан гөрі сенімдірек.

Қосымшалары бар договор мысалы

40-60 беттік әдеттегі договор бір PDF-ті неге кейде әртүрлі тәсілмен оқу керек екенін жақсы көрсетеді. Алғашқы 3-5 бетте әдетте ең маңызды реквизиттер тұрады: құжатқа кім қол қояды, договор нөмірі, дата, қолданылу мерзімі. Одан кейін көбіне қызметтер, көлемдер және сомалар кестелері бар қосымшалар келеді. Беттердің төменгі жағында немесе ұсақ шрифтпен сноскалардағы ерекшеліктер жасырынып тұрады.

Мұндай файлды тұтас тексеруге жіберсеңіз, модель кейде тараптардың рөлдерін араластырып немесе қосымшадан келген датаны договордың өз датасының орнына тартып алуы мүмкін. Ұзын құжаттарда бұл жиі болады. Шапкасы мен қолтаңбасы бар беттерді бөлек талдаған дұрыс, өйткені ол жерде қысқа өрістер жиыны бойынша дәл жауап керек.

Жұмыс сценарийі әдетте былай көрінеді. Алдымен алғашқы беттерді алып, модельден тек тараптарды, нөмірді, датаны және договор пәнін шығарып беруді сұрайсыз. Содан кейін бөлек қызметтер кестесі бар қосымшаны жібересіз. Ол жерде басқа сұраныс керек: жолдарды, бірліктерді, бағасын, сомасын және қорытындыны сақтау. Одан кейін сноскалар мен ескертпелерді қарайсыз. Олар жиі кестенің мағынасын өзгертеді: кейбір қызметтер базалық бағаға кірмеуі мүмкін, ал жеңілдік тек бір көлемде ғана жүруі мүмкін.

Нәтижені бір құжат карточкасына жинау ыңғайлы: договор нөмірі мен датасы, тапсырыс беруші мен орындаушы, қосымшадан алынған қызметтер тізімі, жолдар бойынша сомалар мен жалпы қорытынды, сондай-ақ шектеулер мен ерекше шарттар.

Қызмет көрсету туралы, 12 беттік қосымшасы бар договорды елестетіңіз. Екінші бетте ТОО Альфа және ТОО Бета, 17/24 нөмірі мен 15 наурыз күні көрсетілген. Қосымшада 18 қызметтен тұратын кесте бар. Үш беттің төменінде ескертпелер тұр: түнгі шығу бөлек есептеледі, шығын материалдары бағаға кірмейді, жеңілдік тек тоқсан сайын төлеу кезінде ғана жарайды. Тек кестені жинасаңыз, нәтиже ұқыпты, бірақ қате болады. Тек договор басын оқысаңыз, реквизит аласыз, бірақ ақша болмайды.

Сондықтан ең жақсы нәтиже көбіне бөліп жинап, соңында бір қорытынды жасау арқылы алынады. Соңғы тексеріс бір қарапайым сұраққа жауап беруі керек: негізгі мәтін, қосымша және сноскалар арасындағы реквизиттер, сомалар және шектеулер сәйкес келе ме?

Жиі жіберілетін қателер

Ең жиі қате өте қарапайым: ұзын PDF модельге бір тегіс мәтін сияқты жіберіледі. Қысқа счетта бұл кейде өтіп кетеді. 80 беттік договорда мұндай тәсіл құжат логикасын бұзады: реквизиттер қосымшалармен, сомалар айыппұлдармен, ал сноскалар негізгі мәтінмен араласып кетеді.

PDF-ті бет бойынша тексеруді таңдасаңыз да, қателер өзінен-өзі жоғалмайды. Олар тек түрін өзгертеді. Модель бір бетті жақсы көріп, бірақ көрші беттермен байланысын жоғалтуы мүмкін, әсіресе кесте жолы бір бетте басталып, келесісінде ғана аяқталса.

Көбіне талдау тіпті модельге жетпей, кіріс деректе бұзылады. Қисайған бет, боз скан, нашар OCR немесе орындары жылжыған мәтін блоктары реквизиттерді шығарар алдында-ақ нәтижені бүлдіреді.

Әдетте бұл былай көрінеді: жүйе бірінші кездескен соманы қорытынды деп алып қояды, ал оның жанында аванс, лимит немесе айыпақы көрсетілген; кесте бет шекарасында үзіледі де, жолдың жалғасы жаңа жазбаға түсіп кетеді; ескертпелер редактор комментарийлерімен, келісім штамптарымен немесе шеттегі белгілермен араласады; беттің 90 градусқа бұрылғаны оқу ретін өзгертіп, өрістердің орнын ауыстырады.

Ең қымбат қателердің бірі — санды контекстсіз шығарып алу. Егер құжатта Договор сомасы, ҚҚС сомасы және Төлеуге жалпы сома болса, бірінші табылған сан ешқашан сенімді жауап бермейді. Жанындағы мәтін, өріс атауы және кейде құжат бөлімі де керек.

Кестелерде де жағдай сол. Егер жол бір бетте басталып, келесісінде оның соңы жалғасса, қарапайым бет бойынша талдау көбіне екі жол жасайды. Содан кейін кесте сомасы сәйкес келмейді де, құжатты қолмен тексеруге тура келеді.

Ескертпелерге де бөлек қарау керек. Скандарда құжаттың авторлық ескертпесін заңгерлерден нақтылау керек сияқты ішкі комментариймен шатастыру оңай. Бизнес үшін бұл екі бөлек нәрсе. Біріншісі шарттарға әсер етуі мүмкін, екіншісі мүлде финалдық дерекке түспеуі тиіс.

Жақсы ереже біреу: бірінші сәйкестікке сенбеңіз. Өрісті бөлім атауымен, көрші жолдармен және бет түрімен салыстырыңыз. Бұл сәл ұзағырақ, бірақ жалған табылулар санын едәуір азайтады.

Іске қосар алдындағы қысқа тексеріс

PDF талдауды жұмыс ағынына қоспас бұрын, шағын, бірақ қиын тест жиынтығын жинаңыз. Тек таза файлдарды алмаңыз. Түрлі версткасы, скандары, колонтитулдары және мәтіні екі бағанға кеткен беттері бар договорлар, счеттар, актілер және қосымшалар керек.

Жақсы минимум — 20-30 құжат. Егер бәрі бір-біріне ұқсап тұрса, тесттің пайдасы аз. Мінсіз кестесі бар бір шаблон жүйенің реквизиттерді төменгі бөліктен тауып, ескертпені соңғы бетке шығарып жіберетін файлда қалай жұмыс істейтінін ештеңе айтпайды.

Іске қосар алдында қажет деректердің қайда жатқанын белгілеңіз. Қарапайым тексеру кестесі жеткілікті: реквизиттер қай бетте, кесте қай жерде басталып және аяқталады, сноскалар мен басқа беттегі жалғасы бар ма, қай өрістер міндетті, қайсысын өткізіп жіберуге болады.

Мұндай белгілеу әлсіз жерлерді тез көрсетеді. Мысалы, модель договор нөмірін дерлік әрдайым табады, ал ИИН немесе БИН-ді қосымша нөмірімен шатастырады. Немесе кестеден соманы алады, бірақ астындағы ұсақ ескертпені өткізіп жібереді.

Келесі қадамда әр өріс үшін жеке метрика қойыңыз. Бәрін бір санға жинамаңыз. Дата, сома, БИН, компания атауы және шот нөмірі үшін дәлдікті бөлек есептеген дұрыс, өйткені қателік құны әртүрлі. Егер өріс бизнес үшін критикалық болса, оған қатаңырақ шек қойыңыз.

Кестелер үшін тек шығарылғанын емес, құрылымын да қараңыз. Егер жүйе 10 жолдың 9-ын тапса, бұл толық сәйкестікпен бірдей емес. Ескертпелер үшін мәтіннің өзі табылды ма және оның нақты жолға не тармаққа байланысы сақталды ма — соны бөлек белгілеу пайдалы.

Даулы жерлерді кез келген бағамен автоматтандырудың қажеті жоқ. Файл сапасы төмен, кесте беттер арасында үзіліп кетсе немесе сноска сома мағынасын өзгертсе, сол жерлерде қолмен тексеруді қалдырыңыз. Басында бұл кейін есепке қате түзетуден арзанырақ. Егер мұндай тесттерді AI Router сияқты бір шлюз арқылы өткізсеңіз, модельдерді салыстыру оңайырақ: файлдар жиыны өзгермейді, ал нәтиже жалпы әсермен емес, нақты өрістер бойынша көрінеді.

Әрі қарай не істеу керек

Тәсілді көзбен таңдамаңыз. Бірдей 20-30 ұзын PDF файлын алып, оны екі режимде өткізіңіз: бет бойынша және тұтас. Тек жалпы сәттілік пайызын емес, реквизиттерді, кестелерді және ескертпелерді бөлек салыстырыңыз. Көбіне бірінші бетте жақсы көрінетін схема қосымша, сноска және негізгі кесте арасындағы байланыстарды нашар ұстайды.

Бастау үшін қарапайым ереже жеткілікті. Бет бойынша талдау әдетте бланктерге, счеттарға, актілерге және қайталанатын құрылымы бар басқа құжаттарға жақсырақ келеді. Тұтас талдау көбіне қосымшасы бар договорларда, есептерде, тендер пакеттерінде және мағынасы бір беттен екіншісіне өтетін құжаттарда ұтады.

Пилотты ұзартпау үшін қысқа жоспарды бекітіңіз: шынайы OCR қателері мен әртүрлі шаблондары бар шағын, бірақ өміршең жиынтық жинаңыз, реквизиттердің жіберілуі, кесте үзілімдері және жоғалған ескертпелер үшін бірдей метрикалар қойыңыз, әр прогоннан кейін промптты өзгертпеңіз және әр топтан кемінде 10 құжатты қолмен тексеріңіз.

Егер команда бірнеше LLM-ді салыстырса, әр модельге интеграцияны қайта жазбаған дұрыс. Бір үйлесімді API-қабатын ұстап, маршруттарды тез ауыстырған ыңғайлы. Бұл сценарийде AI Router практикалы көрінеді: base_url-ды api.airouter.kz-ке ауыстырып, бар кодты өзгертпей-ақ бір OpenAI-үйлесімді endpoint арқылы әртүрлі модельдерді тестілеуге болады.

Продакшенге жіберер алдында жақсы жұмыс істегеннің бәрін сақтап қойыңыз: промпттарды, бөлу ережелерін, өрістерді кейін өңдеу тәсілдерін, қате мысалдарын және жауаптың күтілетін форматын. Бұл қызықсыз бөлік, бірақ бір айдан кейін ағынға жаңа PDF түрі түскенде дәл осы нәрсе уақыт үнемдейді.

Егер тесттен кейін режимдер арасындағы айырмашылық аз болса, қолдауы жеңілірек нұсқаны таңдаңыз. Әдетте мұндай шешім ұзақ өмір сүреді және сирек бұзылады.