2025 ж. 13 жел.·6 мин

Келісімдер мен хаттардан деректерді шығару дәлдігін тексеру

Деректерді шығару дәлдігін тексеру: контрольдік жиын дайындау, precision/recall есептеу және жобаны бастауда ручной верификация ұйымдастыру бойынша нұсқаулық.

Келісімдер мен хаттардан деректерді шығару дәлдігін тексеру

Неліктен дәлдікті сезімге сенбей өлшеу керек

Келісімдер мен хаттардан деректерді шығару жүйесін іске қосқанда көбіне «шамамен жұмыс істейді» деген сезім пайда болады. Бірнеше дұрыс мысал адамды жұбатуы мүмкін, бірақ бұл қауіпті. Құжаттар өте әртүрлі, және қателер әдетте сіз тексермеген жерлерде шығады.

Көбінесе «бүкіл жүйе» бұзылмайды — проблема бөлшектерде: жүйе ұқсас реквизиттерді араластырады, мәтін бөлігін өткізіп жібереді, немесе әр түрлі жолдардан алынған мәндерді біріктіреді. Хаттарда қолтаңбалар, жауаптар тізбегі және цитаталар кедергі келтіреді. Келісімдерде — кестелер, жол бөлу және ерекше формулировкалар.

Ең қымбатқа түсетін қателер әдетте критикалық өрістерге қатысты: сомалар мен валюталар, даталар мен мерзімдер (әсіресе «кешіктірілмей» және «N күн ішінде» сияқты формулировкалар), тараптар мен реквизиттер (кім мердігер, кім тапсырыс беруші, БСН/БИН), шарттың предметі мен жеткізу шарттары, сонымен қатар қосымшалар мен спецификациялар, олардың ішінде жиі маңызды деректер «жасырылған» болады.

Кейде құжат өзінде әртүрлі мағынада жазылғандықтан екіұштылық пайда болады. Шарттар қосымшада немесе ескертпеде болуы мүмкін, немесе мөр арқылы жабылған сканда мәтіннің бір бөлігі оқылмай қалуы мүмкін. Хатта маңызды дата өткен хабарламадан алынған цитатада көрсетілген болуы мүмкін, ал актуалды дата — жоғарыда қысқа сөйлемде тұрған болады.

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

Метрикалар не бүлінетінін, қаншалықты жиі және бастапқыда қанша ручной тексеріс қажет екенін көрсетеді.

Алдымен «дұрыс» нәтижені қалай анықтайтыныңызға келісіңіз

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

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

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

Әр өріс үшін «дұрыс мәнді» анықтаңыз. Мысалы, сома үшін бұл сан және валюта, ал тарап үшін — ресми құқықтық атауы, хаттағы қысқартпа емес. Келісімде бір түрде жазылса, хатта басқа түрде, ал қолтаңбада үшінші түрде болуы мүмкін. Бір қайнар көз «басым» болатынын белгілеңіз немесе бірнеше нұсқаны дұрыс деп есептеуді келісіңіз.

Бұдан бөлек, біртұтас форматты анықтаңыз. Даталар үшін бәрін ДД.ММ.ГГГГ форматында сақтау немесе сақтамау, ақшалар үшін тиындарды сақтау, валюта белгілеу (KZT немесе тг), мыңдықтағы бос орындарды қалай өңдеу — барлығын алдын ала келісіңіз. ИИН/БИН және келісім нөмірлері үшін қос нүкте, дефис және «№» символына қалай қарайтыныңызды да анықтаңыз.

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

Жартылай сәйкестіктерді қалай санау керектігін анықтаңыз. Мысалы, «Иванов Иван» және «Иванов Иван Иванович» — қате ме әлде қабылданатын нұсқа ма? Келісім нөмірі префикссіз немесе жылсыз берілсе есептеледі ме? Мұндай ережелер тексерісті адал және қайталанатын етеді.

Precision пен recall (математикасыз түсінік)

Деректерді шығару сапасын бағалау кезінде шатасу оңай: жүйе «жеңіл-желпі орнында табады», бірақ маңызды фактілер жоғалып қалады. Сондықтан екі метрикаға қарайды.

Precision (дәлдік) — жүйе шығарған заттардың қанша пайызы дұрыс. Recall (толықтық) — шығарылуы керек заттардың қанша пайызы табылған. F1 — precision мен recall теңгерімін көрсететін жалпылама көрсеткіш.

Мысалы, «келісім нөмірі» өрісін алайық. 100 құжаттың 80-інде нөмір бар. Жүйе 50 құжаттан нөмір қайтарды. Сол 50-ден 45-і дұрыс, ал 5-і қате (мысалы, хаттың немесе шоттың нөмірін ұстаған).

  • Precision: 45/50 — жүйе нөмір шығарғанда көбіне дұрыс шығарады.
  • Recall: 45/80 — бірақ жүйе көптеген нөмірлерді өткізіп жіберген.

Осындай сценарий жиі кездеседі: precision жоғары, бірақ recall төмен. Бұл модель «ұқыптылық танытып», тек сенімді жерлерден ғана алады.

Бастапқыда не маңызды екенін тәуекелге қарай шешіңіз. Егер қате өткізіп жіберуден қауіптірақ (мысалы, төлем сомасы), алдымен precision-ды көтерген дұрыс. Егер өткізіп жіберу қауіптірек (мысалы, автопролонгацияланған келісімдерді бәрін табу керек), онда recall маңызды.

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

Қарастырмалы құжаттар жинау қалай жүргізіледі

Контрольдік жиын — сіздің нөлдік нүктеңіз. Ол шағын, бірақ әркелкі болуы керек: осылайша жүйе қай жерде қате істейтінін жылдам түсінесіз.

Бастапқы шынайы минимум

Бастапқы өлшеу үшін әдетте 30–50 құжат жеткілікті. Егер көптеген түрлері бар болса (келісімдер, хаттар, қосымшалар), 60–80 құжат алуға болады, бірақ бәрін бірден қамтуға тырыспаңыз. Әр негізгі тип кемінде 5–10 рет кездескені маңызды, әйтпесе метрикалар кездейсоқтыққа тәуелді болады.

Құжаттарды «әдемі» емес, «өмірдегі сияқты» принциппен таңдаңыз. Әрбір санаттан біраздан алу пайдалы: әр түрлі келісім шаблондары (стандартты және стандартты емес), түрлі жылдар, түрлі бөлімдер немесе филиалдар, әр түрлі көздер (кіріс және шығыс хаттар, контрагенттерден келісімдер), әр түрлі форматтар (DOCX, мәтіндік PDF, скан).

Қиын жағдайларды міндетті түрде қосыңыз

Егер «ауыр» файлдарды қоспасаңыз, тест жақсы нәтиже көрсетуі мүмкін, бірақ өндірісте ақаулар пайда болады. Қиын құжаттардың кемінде 20–30% болуын қадағалаңыз: бұлыңғыр скандар, телефоннан түсірілген фотолар, мөрлер мәтіннің үстінен тұрған жағдайлар, кестелер, қолмен жазбалар, төмендетілген сапа. Бұл жағымсыз, бірақ адал.

Қоржындарға бөлу және қайдан алынғанын сақтау

Үш қоржын жүргізу ыңғайлы. Бастапқы жинақ — бірінші өлшеуге және баптауға. Кеңейтілген — жаңа типтер мен сирек кездесетін жағдайларды қосу үшін. Регрессиялық — әр өзгерістен кейін іске қосылатын кішірек жинақ (10–20 құжат), бұрын жұмыс істеген нәрсені бұзбауға көмектеседі.

Кішкентай, бірақ маңызды әдет: әр файлдың қайдан алынғанын атауында немесе бөлек кестеде белгілеңіз. Міндетті минимум: тип (келісім, қосымша, хат), жыл, бөлім, формат (скан немесе мәтіндік PDF). Осылай қателер жиі қай жерде пайда болатынын тез анықтауға болады.

Эталондық разметка: ережелерді алдын ала бекітіңіз

Контур для регрессии и контроля
Спроектируем тестовый контур для регрессионных прогонов после обновлений OCR и правил.
Спроектировать контур

Бағалау даулы болмауы үшін эталондық разметка ережелерін алдын ала бекітіңіз. Эталон — бұл «идеал құжат» емес, өріс үшін қандай мәннің дұрыс екенін түсіндіретін келісілген жауап.

1–2 беттен тұратын қысқа нұсқаулық жасаңыз. Онда «не табу керек» қана емес, «әдетте қайда орналасады» (хаттың шапкасы, келісімнің преамбуласы, төлем бөлімі, қолтаңбалар) көрсетілгені маңызды. Бұл дауысты азайтады және жұмысты жеделдетеді.

Минимумға енгізіңіз:

  • Өріс форматы: даталарды қалай жазасыз (ДД.ММ.ГГГГ), сомаларды қалай (валюта бар немесе жоқ), нөмірлерді префикспен немесе префикссіз сақтау.
  • Даулы жағдайлар: бірнеше даталар (қол қою және күшіне ену даталары), бірнеше сомалар (ҚҚС-сыз және ҚҚС-пен), түзетулер немесе қосымшалар болғанда не істеу.
  • Шынайы дерек көзі: қайсысы басым — негізгі мәтін, кесте, қосымша, қолтаңба, мөр.
  • «Табылмады» мен «қолданылмайды» мәндері: өріс күтілсе, бірақ құжатта жоқ болғанда «табылмады» қою, ал түрінде жоқ болса «қолданылмайды» қою.

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

Эталонды кестеде сақтау ыңғайлы: қатар — құжат, бағандар — өрістер. Қажет болса «түсініктеме» бағанын қосып, ерекше жағдайларды жіктеңіз (мысалы: «сома қосымшада көрсетілген», «хатта сома тек сөзбен»). Бұл қайталанатын талқылаулардан сақтайды және жүйенің қателігін түсінуге көмектеседі.

Мысалы, келісімде «Келісім датасы» шапкада және «Қол қою датасы» қолтаңбалардың жанында болуы мүмкін. Хатта кіріс нөмірінің датасы мен іс-шараның датасы болуы мүмкін. Ережелер бекітілмесе, бір разметчик бірінші датаны, тағы бірі екіншісін алуы мүмкін — сонда метрикалар үнемі ауытқиды.

Қадам-қадам: бірінші сапа циклын қалай жүргізу керек

Бірінші цикл адал көрсеткіштер алу және қай жерде қателік шығатынын түсіну үшін қажет.

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

Бір циклдің 5 қадамы

  1. Құжаттарды нақты өмірдегі тәртіппен жіберіңіз: жүктеу, OCR (қажет болса), өрістерді шығару, нәтижені сақтау.
  2. Әр құжат үшін нәтижені эталонмен өріс-өріс салыстырыңыз. Құжатты түгел емес, әр өрісті бағалаңыз.
  3. Әр өріс үшін TP/FP/FN тіркеңіз: TP — дұрыс табылған, FP — табылған, бірақ қате, FN — табылмаған.
  4. Барлығын бір кестеге жинаңыз: қатарлар — өрістер, бағандар — TP/FP/FN, precision/recall және қысқа түсініктеме.
  5. Өзгерістерден кейін дәл сол жиынға қайта іске қосыңыз. Әйтпесе түзетулердің нақты әсерін көре алмайсыз.

Бірінші есептен кейін қателерді себеп бойынша талдаңыз — бұл пайыздан гөрі маңызды. Қай жерде жөндеу керектігін солан анықтайсыз.

Көбінесе себептер мынадай топтарға түседі: OCR проблемалары (цифрлардың дұрыс танылмауы, жолдардың секіруі, кириллица мен латиницаның араласып қалуы), шығару логикасының қателері (формулировкалардың вариациялары ескерілмеген), формат ерекшеліктері (кестелер, бағандар, сканның қисайғаны, түрлі шаблондар) және адам факторы (эталонда әр түрлі ереже бойынша разметка, эталондағы опечатка).

Практикалық мысал: хаттарда «Исх. No» кейде «Исх№» немесе жай «Исходящий» деп жазылса, бұл өріс бойынша FP және FN береді. Мұндай жағдайда есептеуді «жазылу вариациясы» деп белгілеген дұрыс, модельдің нашарлығын емес.

Бастапқыда ручная верификацияны қалай ұйымдастыру керек

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

Топ кішкентай болуы мүмкін, бірақ рөлдерді бөлу пайдалы: бір адам өрістерді құжатпен салыстырып бекіту қояды, процес иесі (юрист, қаржы, сатып алу) даулы жағдайлар бойынша шешім қабылдайды, техник немесе аналитик қателерді жинап, шаблондар мен есептерді жаңартады.

Тексеріс шексіз ағынға айналмауы үшін, батчпен жұмыс істеңіз. Мысалы, күнде 50–100 құжат, және дайын болу критерийі: «құжат тексерілді, критикалық өрістер расталды немесе жоқ деп белгіленді». Статустарды алдын ала анықтаңыз: «OK», «Түсініктеме керек», «Табылмады», «Күмән».

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

Екіқабат тексеруді тек қымбатқа түсетін жерлерге қалдырыңыз: сомалар, даталар, мерзімдер, БИН/ИИН, банк реквизиттері, келісім нөмірі. Қалған өрістерді таңдаулы түрде қадағалауға болады.

Жүктемені айтарлықтай түсіру үшін приоритизация жасаңыз. Бастапқыда негізгі өрістердің 100% тексерілетінін және қалғандарының 10–20% таңдамалы түрде тексерілетінін қолданыңыз. Қосымша «қызыл жалау» бар хаттар мен келісімдерді жоғарғы приоритетке қойыңыз: көп қосымшалары бар, сканы нашар, шаблоны стандарт емес, немесе бір хатта бірнеше контрагент бар.

Қай қателер метрикаларды адастырады

Интеграция с вашими системами
Свяжем обработку с СЭД, почтой и учетными системами через интеграцию GSE.
Заказать интеграцию

Метрикалар жақсы көрінуі мүмкін, бірақ қолданушылар үшін жағдай әлі ауыр болуы мүмкін. Көбіне мәселе — нәтиженің қалай бағаланатынында және тексеру материалдарының қалай жиналғанында.

Ең қауіпті қателік — нұсқалар мен дерек көздерін шатастыру. Тестке қолмен түзетілген файл түсіп, ал өндірісте сканнан келген нұсқа келеді. Формальды жағынан бұл «сол келісім», бірақ шығару үшін түрлі кірістер. Егер дерек көзін (пошта, ЭДО, скан, шаблон) тіркемесеңіз, метрикалар шындықтан оптимистік болады.

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

Үшінші мәселе — тек орташа нәтижеге қарау. Орташа 95% болғанымен, бір өріс (мысалы, БИН/ИИН немесе ҚҚС-пен сома) нашар болса, жүктеме жарамсыз болады. Өрістер мен құжат түрлері бойынша метрикаларды ұстап отыру пайдалы.

Precision-қа әдемі қарамастан, өткізіп жіберулерге (FN) назар аудармау — тағы бір қауіптілік. Жүйе тек сенімді жерден ғана шығарып, қателер аз, бірақ қажет өрістердің жартысы жоқ болуы мүмкін — өндірісте бұл көп ручной жұмыс пен кешігулерге әкеледі.

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

Пилотқа жіберер алдында қысқа чеклист

Пилотты бастамас бұрын бәрі бірдей бағаланып жатқанын тексеріңіз, яғни «алма мен апельсинді» шатастырмаңыз.

Алдымен команда бірдей түсінікке ие ме тексеріңіз: әр өріс үшін нақты формат пен мысал қажет: жай «келісім нөмірі» емес, «мысалы: KZ-2025/0145», жай «дата» емес — «ДД.ММ.ГГГГ».

Содан кейін базалық дайындықты тексеріңіз:

  • Өрістер тізімі бекітілген: формат, рұқсат етілген жазылу нұсқалары, мысал мәні.
  • Контрольдік жинақ дайын: типтік құжаттар және қиындық үлесуі (скандар, нашар сапа, стандарттан тыс шаблондар, ұзын хаттар).
  • Бос және қолданылмайтын мәндерге ереже келісілген.
  • Precision және recall негізгі өрістер бойынша есептелген.
  • Қателер журналы жүргізіледі: не қате, не себеп болған және не өзгертіледі.

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

Мысал сценарий: ұйымдағы келісімдер мен хаттар

Сервер под обработку документов
Подберем серверы GSE S200 под поток договоров, сканы, таблицы и пики загрузки.
Подобрать сервер

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

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

50–100 құжаттық бақылау жиынтығын шынайы өмірді көрсету үшін жинайды. Мысалы: 20–30 түрлі типті келісім (жеткізу, қызмет, қосымшалар), 15–25 хаттар (сома немесе мерзім мәтінде көрсетілген), 10–20 нашар скан немесе стандарттан тыс шаблондар және 5–10 құжат бірнеше сомалар немесе даталар бар жағдайлар (аванc, қорытынды, қосымшалар).

Ручная верификация 1–2 аптаға бөлінеді, адамдарды шамадан артық жүктемеу үшін. Жиі схема осылай болады: бір қызметкер бастапқы тексерісті жасайды, екінші — дау тудыратын жағдайларды рандом режимде бекітеді, процесс иесі екі күнде бір рет қысқа есепке қарап, қайсы қателерді бірінші түзету қажеттігін шешеді.

Бірінші есебінен кейін әдетте ұқсас қорытындылар шығады. Типтік келісімдерден даталар мен нөмірлер жақсы алынады, бірақ контрагенттің атауы рөлдерден («Орындаушы», «Жеткізуші») және септік өзгертулерінен шатаса береді. Сомалар кестелер мен бірнеше валюта бар құжаттарда жиі бұзылады, ал мерзімдер хаттарда «квартал соңына дейін» сияқты сөзбен жазылған кезде қиындық тудырады. Бұл байқаулар нақты жоспар береді: разметка ережелерін айқындау, қиын мысалдарды бақылау жиынына қосу және жоғары тәуекелді өрістерді міндетті ручной тексеріске қалдыру.

Келесі қадамдар: пилоттан тұрақты жұмысқа көшу

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

Критикалық өрістер (сома, ИИН/БИН, даталар, келісім нөмірі, мерзімдер, банк реквизиттері) үшін мақсатты сапа шектерін бекітіңіз. Кейбір жерде ешбір мән жіберілмеу маңызды — сонда recall жоғары болуы керек; басқа жерде жалған табулардың болмауы маңызды — сонда precision жоғары болуы керек. Шектер бизнестің түсінуінде болу тиіс, тек техникалық топ үшін емес.

Регрессиялық жиын құрыңыз: шағын, бірақ «қолайсыз» коллекция, типтік келісімдер, нашар скан, еркін формада хаттар, сирек шаблондар, түзетілген және қосымша жағдайлар. OCR, ережелер немесе модель өзгерген сайын осы жиынды іске қосып, сапаның төмендемеуін қадағалаңыз.

Мәселені екі қабатқа бөліңіз: мәтінді танудың сапасы (OCR) және өрістерді шығару сапасы. Егер OCR цифрларды жиі шатастырса, логиканы түзетсеңіз де нәтиже жақсармайды. Егер мәтін дұрыс танылса, бірақ «дата» өрісі қате жерден алынса, логиканы өзгерту тиімді.

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

Егер пилот пайдалы болса, келесі қадам — инфрақұрылым: өңдеуді қайда іске қосу, деректерді қалай сақтау, тұрақтылықты қалай қамтамасыз ету. Мұндай мәселелерде GSE.kz (gse.kz) сияқты жүйелік интегратор көмектесе алады: серверлер мен жұмыс станцияларын таңдау, құжаттарды өңдеу инфрақұрылымын құру және 24/7 қолдау ұйымдастыру, сонда шешім тек тест қорапшасында емес, нақты ағында сенімді түрде жұмыс істейді.