Бір салалық деректер жиынына арналған модель түрін таңдау

Неге модельдің бренді таңдауға кедергі болады

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

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

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

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

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

Салалық жиынға не қосу керек

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

Жайлысы — тірі ағыннан алынған деректерді пайдалану: тикеттер, хаттар, өтінімдер, чат үзінділері, инцидент карточкалары. Сонда таңдау күнде команда көретін нәрсеге сүйенеді, әдемі демо-үлгіге емес.

Жақсы жиын әдетте бірнеше қабаттан тұрады: жиі кездесетін қалыпты жағдайлар; мағынасы бір, бірақ сөзі басқа сирек тіркестер; қате терілген, артық детальдары бар және сөйлемі үзіліп кеткен шуылы көп мәтіндер; тіпті адамға 10–20 секунд керек болатын даулы мысалдар.

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

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

Күтілетін жауап та қарапайым болғаны дұрыс. Ақпаратты бөліп алу үшін бұл — бір өріс немесе тұрақты өрістер жиыны. Жіктеу үшін — жабық тізімнен бір ғана белгі. Қысқаша мазмұндау үшін — 2-3 фактіден тұратын қысқа анықтама. Чат үшін — чек-лист арқылы тексеруге болатын ережелермен берілген жауап.

Әділ прогонды қалай өткізу керек

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

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

Сосын барлық нұсқаны бір жиында іске қосыңыз. Мәтіндерді "сезіммен" бөлмеңіз және күрделі кейстерді тек чатқа, ал жеңілдерін тек жіктеуге бермеңіз. Біртұтас кесінді алыңыз: мысалы, қысқа, орташа және шуылы бар 300 салалық жазба. Егер команда модельдерді бір OpenAI-үйлесімді шлюз арқылы тексерсе, бір SDK мен бір кодты қалдырып, тек модель мен параметрлерді ауыстыру жеңіл болады.

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

Тек сонда ғана толық көрініс шығады. Кейде модель нәтиже жағынан 2% жақсы, бірақ 6 есе қымбат тұрады және екі есе баяу жауап береді. Өнімдік сценарий үшін бұл көбіне тиімсіз айырбас.

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

Қай жерде қысқаша мазмұндау ұтады

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

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

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

Тым ұқыпты қорытындыларды бөлек белгілеу де пайдалы. Кейде модель қайталануды және шуды алып тастайды, бірақ сонымен бірге себеп-салдар байланысын да шығарып тастайды. Деректе былай болған: құжат жоқ, сондықтан мерзім жылжыды, содан кейін іс қолмен тексеруге жіберілді. Әлсіз summary-де тек кешігу туралы сөйлем қалады да, адам контексті жоғалтады.

Тағы бір жиі қате — ойдан қосылған детальдар. Егер модель уәде етілген мерзімді, бас тарту себебін немесе келісім мәртебесін мәтінде жоқ болса да қосып жіберсе, бұл қате.

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

Қай жерде ақпаратты бөліп алу ұтады

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

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

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

Қателерді түрлері бойынша талдаған пайдалы. Әдетте төртеу болады: мәтінде мән бар, бірақ өріс бос; схемаға кірмейтін артық өріс; қате формат; форматы дұрыс болғанымен, мәні қате.

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

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

Қай кезде жіктеу жақсы жұмыс істейді

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

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

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

• "Картаны бұғаттау" — "картам ұрланды, операцияларды шұғыл тоқтатыңыз"
• "Даулы операция" — "мына төлемді танымаймын"
• "Лимитті өзгерту" — "аударым лимитін ұлғайтыңыз"
• "Техникалық қате" — "қосымша жеке кабинетке кіргізбей жатыр"

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

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

Тек дәлдікке қарау аздық етеді. Егер модель 94% дұрыс белгі берсе, бірақ басқа модельден бес есе қымбат болса, таңдау онша анық емес. Бір шешімнің бағасына, кідірісіне және ұқсас кластардағы қателерге қараңыз.

Чат қашан пайдалырақ

Чат адам тапсырманы әңгіме барысында нақтылайтын жерде керек. Ол қатаң шаблондағы жауап үшін емес, сұрау әуелі бұлыңғыр болып, кейін тарылатын жағдайға ыңғайлы: "Шарттарды көрсет", "Ал егер клиент ЖК болса?", "Тек жаңа келісімшарттар үшін". Мұндай жұмыста қысқаша мазмұндау мен жіктеу бір ғана қадамда тоқтап қалады.

Әдемі алғашқы жауапқа емес, қатарынан 2-3 қадамға қараңыз. Модель алдыңғы хабарламалардағы шектеулерді есте сақтауы, мәндерді жоғалтпауы және диалог ортасында терминді ауыстырмауы керек. Егер екінші қадамда-ақ өнімді, тарифті немесе клиент мәртебесін шатастырса, оған сенуге әлі ерте.

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

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

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

Сондықтан чат тек диалог нәтижені шынымен өзгертетін жерде қалуы керек. Қалған жағдайда алдымен қатаңырақ формат мәселені шеше ме — соны тексерген дұрыс.

Банктегі қолдау қызметінен қарапайым мысал

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

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

Осы мәтінді өзгеріссіз алсақ, шығатын нәтижелердің мәні әртүрлі болады. Қысқаша мазмұндау хабарламаны 1-2 сөйлемге сығады: карта бойынша даулы операция, клиент бұрын ашылған өтінімге жауап күтіп отыр. Ақпаратты бөліп алу өрістерді шығарады: 48 900 теңге, 12 мамыр, "қосымша" арнасы, 18427 өтінім нөмірі. Жіктеу істі жалпы қолдау желісіне емес, даулы транзакциялар кезегіне жібереді. Чат детальдарды болжауға тырыспай, бір нақты сұрақ қояды, мысалы: "Сіз картаны және кодтарды үшінші тұлғаларға бермегеніңізді растайсыз ба?"

Айырмашылық бірден көрінеді. Қысқаша мазмұндау операторға мәнді тез түсінуге және мәтінді екі рет оқымауға көмектеседі. Ақпаратты бөліп алу CRM, антифрод немесе тексеру формасына өрістерді жіберу керек жерде қажет. Жіктеу маршрутизацияға кететін уақытты үнемдейді. Чат бір жауапсыз алға жылжу мүмкін болмағанда пайдалы.

Тәжірибеде командалар жиі бір чат-модель бәрін бірден жабады деп күтеді. Әдетте олай болмайды. Чат шағымды әдемілеп қайталап береді, бірақ соманы өткізіп жіберуі немесе операция арнасын шатастыруы мүмкін. Ал ақпаратты бөліп алу құрылымды жақсы ұстайды, бірақ операторға контекст түсіндіріп бере алмайды.

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

Командалар қай жерде қателеседі

Тест көбіне алғашқы нәтиже шықпай тұрып-ақ бұзылады. Команда бірдей құжаттар жиынын алады да, қысқаша мазмұндауға ұзын промпт, ақпаратты бөліп алуға қысқа промпт жазады, ал чатқа қосымша нұсқаулар мен мысалдар қосады. Содан кейін модель ұтты сияқты көрінеді, ал шын мәнінде тест шарттары ұтқан болады.

Сондықтан салыстыру тек модельдер арасында ғана емес, жұмыс режимі бойынша да жүруі керек: бір нұсқаулық шаблоны, бірдей контекст, жауап ұзындығына бірдей шектеу және бір бағалау схемасы.

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

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

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

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

Соңғы қате зиянсыз көрінеді: команда тек орташа балға қарайды. Орташа көрсеткіш қымбат сәтсіздіктерді жасырады. Егер жіктеу 94% дәлдік берсе, бірақ 100 жағдайдың 3-інде алаяқтық шағымын жай сұрақпен шатастырса, сол шеті әдемі жалпы саннан маңыздырақ.

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

Таңдар алдында жылдам тексеріс

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

Әдетте 10–20 мысал жетеді, егер команда оларды өзі қарап шығып, қай жауап жақсы, қайсысы даулы, қайсысы нашар екенін келісе алса. Мұндай қолмен шолу көбіне контекстсіз әдемі орташа метрикадан пайдалырақ.

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

Қысқа тексеріс

• Барлық прогонға бір жиын
• Әр модельге түзетілмейтін бір нұсқаулық мәтіні
• Бір жауап форматы: JSON, класс меткасы немесе қысқа қорытынды
• Баға мен кідірісті бөлек белгілеу
• Командамен 10–20 жауапты қолмен тексеру

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

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

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

Бір түсінікті бизнес-тәртіптен бастаңыз. "Барлық сценарийді бірден тексереміз" деген ойдан емес, бір процестегі шағын мысалдар жиынынан бастаған дұрыс. 80–150 нақты жағдай жетеді, онда команда жауаптың жақсы не жаман екенін тез айта алады. Сонда таңдау брендке емес, фактіге сүйенеді.

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

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

Интеграция әр прогонда өзгермесе, салыстыру да тазарақ болады. Командаларға airouter.kz арқылы тест жасау ыңғайлы болуының практикалық себептерінің бірі осы: model мен provider-ді ауыстырсаңыз да, SDK, код және промптты қайта жазудың қажеті жоқ. Осындай режимде жауапты, бағаны және тұрақтылықты салыстыру оңайырақ, ал айналма құрылымды емес.

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