LLM-ден кейін күндерді, валюталарды және сандарды шатастырмай қалыпқа келтіру

Форматтардағы ала-құлалық қайдан шығады

LLM сіздің жүйеде бір ғана рұқсат етілген формат барын білмейді, егер оны ашық көрсетпесеңіз. Модель үшін 01/02/24, 2024-02-01 және 1 ақпан 2024 көбіне бір мағынаны білдіреді.

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

Ақшамен де дәл солай болады. Бір ғана сома 1,200.50, 1 200,50 немесе 1200.50 тг түрінде келуі мүмкін. Адамға айырмасы аз. Ал код үшін бұл — үш түрлі жол.

Әдетте ала-құлалық төрт себептен пайда болады:

• prompt дерек шығаруды сұрайды, бірақ нақты шығару үлгісін бермейді
• модель хаттан, шоттан немесе PDF-тен жазуды көшіріп алады
• локальдар нүктені, үтірді және бос орынды әртүрлі қолданады
• әртүрлі модельдер бір мағынаны әртүрлі формада қайтарады

Егер команда бір сұрауды бірнеше модель арқылы өткізсе, айырмашылық одан әрі көбейеді. Бұл әсіресе LLM шлюздерінде байқалады, мұнда жауаптар әртүрлі провайдерлерден келеді: бір модель күнді мәтінмен қайтарады, екіншісі санмен, үшіншісі валютаны жолдың соңына қосады.

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

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

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

Нені бір пішінге келтіру керек

Егер модель хаттарды, шоттарды, формаларды және чаттарды оқыса, ол деректерді көбіне аралас күйде қайтарады. Бір дереккөз 03.04.2025 деп жазады, екіншісі April 3, 2025, үшіншісі жай ғана кеше дейді. Солай-ақ сомалармен, пайыздармен және бос өрістермен де болады. Мұны бір пішінге келтірмесеңіз, кейін код не айтылғанын өзі болжай бастайды.

Әдетте төрт топ жеткілікті: күн мен уақыт, сома мен валюта коды, қарапайым сандар мен пайыздар, сондай-ақ бос мәндер мен көрсетілмеген сияқты қызметтік сөздер.

Күндерде бір ішкі форматты бірден сақтау дұрыс. Күн үшін бұл YYYY-MM-DD, уақыт үшін HH:MM:SS, ал timestamp үшін уақыт белдеуі бар ISO 8601 болуы мүмкін. Әйтпесе 05/06/24 бір командада 5 маусым, ал екіншісінде 6 мамыр болып шығады. Егер дереккөз ертең немесе өткен жұма десе, мұндай мәнді нақты емес, салыстырмалы деп белгілеңіз.

Соманы көбіне екі бөлікке бөлу керек: сан және валюта. Егер әрі қарай сүзгілер, есептеулер немесе салыстыру қажет болса, 1 250 000 тг дегенді бір жол ретінде сақтамаңыз. Оның орнына amount: 1250000 және currency: KZT болғаны дұрыс. Сонда таңбаны жоғалту, теңгені рубльмен шатастыру немесе модель бір жауапта $1,200, ал екіншісінде 1 200 USD деп жазғанда есепті бұзу оңай болмайды.

Қарапайым сандар да тәртіпті қажет етеді. Бір ондық бөлгішті таңдаңыз, артық бос орындарды алып тастаңыз, ал өлшем бірліктерін бөлек сақтаңыз. Пайыздарда да бір тәсіл керек: не 12.5% жол ретінде, не 0.125 сан ретінде. 10-15 немесе 10-нан 15-ке дейін сияқты аралықтарды min және max болып бөлген ыңғайлы.

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

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

Әуелі канонды бекітіңіз

Егер ішкі бір формат болмаса, қалыпқа келтіру тез арада жамау-жасқауға айналады. Модель 01.02.2024, 2024/02/01 немесе 1 Feb 2024 қайтаруы мүмкін, ал бұл үшеуі адам үшін ғана бірдей.

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

Күндер үшін көбіне ISO 8601 жақсы жұмыс істейді: 2024-02-01. Бұл формат ықшам, бірмәнді және дерекқор, API мен кестелер арқылы оңай өтеді. Егер деректе уақыт болса, оны бірден шешіп алыңыз: UTC-де, жергілікті уақыт белдеуінде немесе ығысуымен бірге, мысалы 2024-02-01T14:30:00+05:00.

Ақшаға қатысты ереже қарапайым: сома мен валюта бір өрісте тұрмауы керек. Санды бөлек, валюта кодын бөлек сақтаңыз, мысалы 15000.50 және KZT. Әйтпесе 15 000 тг, $15,000 немесе 15.000,00 сияқты жолдар талдауды да, есептеуді де бұза бастайды.

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

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

• дата форматы: YYYY-MM-DD
• уақытқа қатысты ереже: UTC, жергілікті уақыт немесе ығысуымен уақыт
• ақша өрісі: сан бөлек, валюта коды бөлек
• бос орынсыз және мыңдық бөлгішсіз бір сан форматы
• белгісіз және күмәнді мәндерге арналған бөлек статус

Соңғы пункт жиі бағаланбайды. Егер модель сенімді болмаса, жүйені болжауға мәжбүрлемеңіз. unknown, missing немесе ambiguous сияқты статус сақтаған дұрыс, әйтпесе қате дата не валютаны қойып, кейін бүкіл тізбекті түзетесіз.

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

Модель жауабынан кейін өңдеуді қалай құру керек

Сенімді қалыпқа келтіру парсерден емес, модель жауабының пішімінен басталады. Егер еркін мәтінді қалдырсаңыз, бірден форматтардың араласуын көресіз: 01/02/24, 1 ақпан 2024, 1,250.00 және 1 250,00 бір ағынның ішінде жүреді.

Жұмыс істейтін схема қарапайым.

Алдымен JSON сұраңыз. Модель түсінікті атаулары бар өрістерді қайтаруы керек: invoice_date, amount, currency, raw_text. Осылайша деректі артық сөздерден бөлек ұстайсыз да, төлем сомасы сияқты тіркестерді талдауға уақыт жоғалтпайсыз.

Содан кейін процесті екі қадамға бөліңіз. Әуелі мәнді шығару, сосын оны сіздің форматқа келтіру. Бұл маңызды. Модель 03/04/2025 жолын дұрыс бөліп алуы мүмкін, бірақ оны ISO күнге түрлендіруді енді сіздің кодыңыз анық ережемен жасауы керек.

Локальді бір ғана символға қарап емес, контекст бойынша анықтаңыз. Бір үтір ештеңені дәлелдемейді. Хаттың тілін, контрагент елін, валюта кодын, басқа өрістердің пішімін, құжаттың қолтаңбасын қараңыз. Егер хатта теңге немесе KZT бар болса, ал сома 1,250.50 деп жазылса, басқа белгілерсіз мұны американдық формат деп асықпаңыз.

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

Түпнұсқа үзіндіні нормаланған мәнмен қатар сақтаңыз. Мысалы, raw_amount: "1 250 000,50 ₸" және бөлек amount: 1250000.50, currency: "KZT" болсын. Сонда команда модель қай жерде қателескенін, қай жерде сіздің нормализаторыңыз қателескенін тез түсінеді.

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

Күндер көбіне қай жерде бұзылады

Ең көп қате адамға таныс, ал кодқа қауіпті көрінетін күндерден шығады. 03/04/2024 жолы 3 сәуірді де, 4 наурызды да білдіруі мүмкін. Хат тілі, жіберуші ел немесе дереккөз форматы анық болмайынша, мұндай датаны түсініксіз деп санаған дұрыс.

LLM жауабынан кейін бұл жиі кездеседі. Модель пішімді хаттан, кестеден немесе пайдаланушы мәтінінен алып кетуі мүмкін. Бір жерде ол 2024-04-03 жазады, басқа жерде 03.04.24, ал қасына Apr 3, 2024 қосады. Егер парсер бір нұсқаны үндемей таңдап алса, қате дерекқорға кетеді де, кейін қымбатқа түседі.

Күндермен мына ережелер пайдалы:

• бастапқы жолды нормаланған мәннен бөлек сақтаңыз
• 03/04/2024 мәнін ел немесе тіл контекстісіз талдамаңыз
• егер тек ай мен жыл болса, күнді өзіңізден қоспаңыз
• уақыт пен уақыт белдеуін күннің өзінен бөлек өңдеңіз
• бүгін, кеше, ертең сөздерін тек тірек дата болса ғана нақты күнге айналдырыңыз

Жиі болатын тұзақ — толық емес дата. Егер модель ақпан 2024 қайтарса, бұл 2024-02-01 деген сөз емес. Бұл — күні көрсетілмеген ай мен жыл. Дәл сол нақтылықты сақтаңыз. Әйтпесе есеп немесе төлем мерзімі ай басына жылжып кетеді, ал дереккөз ондайды айтпаған.

Ай атауларында да тәртіп керек. Адамдар ақпан, ақп., Feb, February, 02 деп жазады. Бәрін бір сөздікке жинап, қысқартулар мен атауларды бір формаға түсірген дұрыс. Сонда қазақша да, ағылшынша да мәтін бір схема арқылы өтеді.

Уақыт та бөлек тақырып. 03.04.2024 10:00 уақыт белдеусіз және 2024-04-03T10:00+05:00 бірдей мән емес. Банк, колл-орталық немесе жеткізу үшін бірнеше сағат айырмашылықтың өзі оқиғалардың ретін өзгертеді. Егер зона көрсетілмесе, солай белгілеңіз: уақыт бар, зона белгісіз.

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

Валюталар мен сандар: қайда белгі мен масштаб жоғалады

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

$ таңбасының өзі ештеңеге кепіл емес. Бұл USD, CAD, AUD және тағы басқалар болуы мүмкін. Егер модель $ 1,200 қайтарса, валютаны белгіден болжауға тырыспаңыз. Жанындағы валюта кодын, құжат елін, хат тілін, сатушы шотын немесе currency: "USD" сияқты нақты өрісті іздеңіз. Мұндай белгі болмаса, мәнді күмәнді деп белгілеу жақсы.

Бөлгіштермен де солай. 1,234 бір құжатта мың екі жүз отыз төрт дегенді білдірсе, басқа жерде 1.234 болуы мүмкін. Бос орын да маңызды: 1 234,56 және 1 234.56 ұқсас көрінеді, бірақ жазу әдеті басқа. Парсерге анық тексеру реті керек. Әйтпесе ол болжай бастайды.

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

Теріс сомалар тек -1000 түрінде емес, жасырынуы мүмкін. Бухгалтерлік құжаттар (1 000,50) форматын жақсы көреді, ал кейбір модельдер кәдімгі - орнына − таңбасын қайтарады. Бір ғана нұсқаны тексерсеңіз, жүйе шығынды кіріс деп қате түсіндіруі мүмкін.

Масштаб одан да жиі бұзылады. 1.2 млн, 1,2m және 1200000 бір контекстте бір санға айналуы керек. Бірақ m әрдайым million деген сөз емес: техникалық деректерде бұл meter болуы мүмкін, ал қаржыда кейде миллион үшін MM қолданылады. Сондықтан бастапқы жолды әрдайым сақтаған дұрыс.

Пайыздарда да релизге дейін бір ережені бекіту керек. Егер модель 12,5% деп жазса, жүйе оны әрдайым не 12.5-ке, не 0.125-ке айналдыруы тиіс. Екеуі де жарайды. Жаман нәрсе — бір кестеде екеуінің де қатар өмір сүруі.

Егер жауаптарды бірнеше модель арқылы өткізсеңіз, жазудағы айырмашылық жиірек кездеседі. Бір модель KZT 1 200 000 қайтарады, екіншісі 1.2 млн тг, үшіншісі 1200000 саны бар JSON береді. Белгі, валюта және масштабқа ортақ ережелер болмайынша, мұндай жауаптарды шынайы салыстыруға да, есепке жіберуге де болмайды.

Шоттар мен хаттардан алынған мысал

Бір ғана жеткізуші бір апта ішінде де әртүрлі жаза алады. Шотта 15.03 дейін төлеу керек делінеді, менеджер хатта March 15 деп жазады, ал чатта 15/03/24 пайда болады. Модель мағынаны түсінеді, бірақ есеп үшін бұл жеткіліксіз. Бухгалтерияға бір ғана формат қажет.

Сомаларда да жағдай сондай. Бір хабарламада 125 000 ₸, екіншісінде $3,500.00, үшіншісінде 1.250,00 EUR, ал кейде валюта коды мүлде көрсетілмейді. Сол күйі қалдырсаңыз, есептер айырмашылық бере бастайды: бір жерде сан 1250, басқа жерде 1.25 болып оқылады.

Қарапайым ағын мынадай. Модель шотты, хатты және жеткізуші чатындағы хабарламаны оқиды да, үш өрісті шығарады: төлеу мерзімі, сома және валюта.

Кірісте ол мынаны көруі мүмкін:

• 15.03 дейін төлеңіз, сома 125 000 ₸
• Invoice total: $3,500.00, due March 15
• Төлемге 1.250,00 EUR, мерзімі 15/03/24

Нормализациядан кейін жүйе мұны бір қалыпқа келтіреді:

• дата: 2024-03-15
• сома: 125000.00, 3500.00, 1250.00
• валюта: KZT, USD, EUR

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

Кейін бәрі жеңілдей түседі. Бухгалтерия деректерді қолмен түзетусіз жүктейді, аналитика әр дереккөзге жеке ереже жазбай есеп құрады, ал құжаттарды іздеу де тұрақтырақ жұмыс істейді. Барлық жазба YYYY-MM-DD, бірдей сан форматы және ISO бойынша валюта кодын қолданғанда, жеткізуші не айтқысы келгені туралы дау жоғалады.

Нәтижені бұзатын қателер

Ең жиі қате қарапайым: команда қатаң prompt-тың өзі форматты ұстап тұрады деп сенеді. Іс жүзінде модель бірде 01.02.2025, кейін 2025-02-01, ал келесі жауапта 1 Feb 2025 қайтаруы мүмкін. Содан кейін жолды сол күйі сақтасаңыз, ала-құлалық сөзсіз.

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

Валютада дерек көбіне одан да ертерек бұзылады. Команда ₸, $ немесе € символын алып тастап, кейін валюта кодын сан мен контекст бойынша болжауға тырысады. Бұны керісінше жасаған дұрыс. Әуелі валютаны жеке өріс ретінде анықтаңыз: KZT, USD, EUR. Сосын ғана соманы талдауға тазалаңыз. Әйтпесе $ 5,000 және 5 000 тг екеуі де 5000 жолына айналып кетеді, ал бұл мүлде бөлек ақша.

Тағы бір жиі болатын ақау — бөлгіштерді соқыр ауыстыру. Әзірлеуші қарапайым ереже жазады: барлық үтірді нүктеге ауыстыр, бос орындарды алып таста, болды. Бірақ 1.234,56 жолы мұндай тазалаудан кейін 1.234.56 болып кетуі мүмкін, бұл енді жай ғана қоқыс. Әуелі локальді түсіну керек немесе кемінде сол жолда қай символ ондық бөлгіш екенін тексеру қажет.

Мұнда қысқа ережелер жиыны көмектеседі:

• бастапқы мәнді нормаланғанымен қатар сақтаңыз
• дата, сан және валюта кодын бөлек валидтеңіз
• күмәнді жағдайларды болжау емес, флагпен белгілеңіз
• әртүрлі локальдардан алынған мысалдармен тест жүргізіңіз

Бастапқы мәнді ерте жоюға болмайды. Ол парсинг сәтсіз болғанда, қолданушы соңғы сомаға қарсы шыққанда және бір аптадан кейін ережені түзеткенде керек болады. Қарапайым схема мынадай: raw_value, parsed_value, currency_code, parse_status, error_reason.

Пайплайн көбіне осындай ұсақ нәрселерден бұзылады. Негізгі мәселе көбіне модельде емес. Ол бәрін түсіндім деп тым тез шешім шығаратын кодта.

Релиз алдындағы тексеріс

Жіберер алдында тек prompt-ты емес, шығыс ережелерін де тексеріңіз. Егер даталар, сомалар және пайыздар үшін бір формат болмаса, шатасу алғашқы аптада-ақ шығады: бір модель 03/04/2025 береді, екіншісі 2025-04-03, үшіншісі 3 Apr 2025 деп жазады.

Продакшен үшін сақтау форматы біреу болуы керек. Дата, сома және пайыз пайдаланушы немесе модель әртүрлі жазса да, бірыңғай түрде тұруы тиіс. Даталар үшін көбіне YYYY-MM-DD жеткілікті. Ақша үшін сан формасы ғана емес, бөлек валюта өрісі де қажет. Пайызда әуелі шешіп алыңыз: сіз 12.5 мәнін 12.5% ретінде сақтайсыз ба, әлде 0.125 ретінде ме.

Релиз алдында мына қысқа тізімді қарап шығу пайдалы:

• әр датаның бір сақтау форматы және уақыт белдеуі бойынша бір ережесі бар
• әр сомада сан, валюта және белгі бар, ал USD 1,200 сияқты бір жол емес
• тесттер екіұшты даталарды бөлек ұстайды: 04/05/2025, 05/04/2025 және ұқсас жағдайлар
• бос және жартылай мәндер қалыпты сияқты жасырылмайды
• жүйе бастапқы жолды сақтап, жазба неге тексеруден өтпегенін логқа жазады

Жартылай деректер әсіресе жиі бұзылады. Модель тек ай мен жылды, валютасыз соманы немесе белгісіз пайызды қайтаруы мүмкін. Оның орнын өзіңіз толтырмаңыз. 05/2025 мәнін жасырын түрде 2025-05-01-ге айналдырғаннан гөрі partial статусын сақтау дұрыс, әйтпесе бухгалтериямен не заңгерлермен дауласып қаласыз.

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

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

Жақсы релиз тесті қызықсыз көрінеді, бұл қалыпты. Шоттардан, хаттардан және формалардан алынған 30-50 нақты жолды алып, парсерден өткізіп, күмәнді жағдайларды қолмен тексеріңіз. Осы жиында бәрі анық болса, әрі қарай тыныш болады.

Продакшнда әрі қарай не істеу керек

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

Үлкен архитектурадан емес, тірі мысалдар жиынынан бастаңыз. Нақты шоттардан, хаттардан, өтінімдерден және кестелерден 30-50 үзінді алыңыз. Таза мысалдарға қоса қиындарын да араластырыңыз: 03/04/25 сияқты даталар, бос орынмен, үтірмен және валюта белгісімен жазылған сомалар, жақша ішіндегі теріс сандар, мың. және млн сияқты қысқартулар.

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

Алғашқы спринт үшін әдетте төрт нәрсе жеткілікті:

• нақты құжаттардан шағын golden set жинау
• дата, валюта және сандар үшін бір форматты бекіту
• нормализациядан кейін схема тексеруін қосу
• қысқа қате кодтарын енгізіп, бастапқы үзіндіні логтау

Қате кодтары түсінікті болғаны жақсы: DATE_AMBIGUOUS, CURRENCY_UNKNOWN, NUMBER_SCALE_CONFLICT, SCHEMA_MISSING_FIELD. Сонда әзірлеуші бірден нені түзету керегін көреді, ал аналитик неге жазба қолмен тексеруге кеткенін түсінеді.

Бұл логиканы әртүрлі сервиске шашыратып жібермеңіз. Бір сервис күнді тазартады, екіншісі соманы, үшіншісі валютаны қайта жазады — бір айдан кейін ережелер бір-бірінен алыстап кетеді. Нормализацияны бір жерде ұстаңыз: барлық модель жауабы өтетін бөлек модульде, кітапханада немесе сервисе.

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

Тағы бір жиі кейінге қалдырылатын нәрсе: golden set-ті CI-ға қосыңыз. Егер парсерді түзеткеннен кейін 05.06.2025 күні мамырдың орнына маусым болып кетсе, тест оны релизге дейін ұстап қалады. Мұндай міндеттер үшін бұл — сән емес, қарапайым сақтандыру.