Өнім міндеттері үшін өз деректеріңіздегі модельдерді бағалау

Неге бөтен бенчмарк сіздің өніміңізді көрсетпейді

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

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

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

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

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

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

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

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

Өнімнен қандай міндеттерді алу керек

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

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

Одан кейін мысалдарды жұмыс түріне қарай бөліңіз. Әдетте төрт топ жеткілікті:

• білім базасынан немесе құжаттан факт іздеу
• ұзын мәтінді қысқаша қорытындылау
• өтінішті немесе ниетті жіктеу
• жауап, хат немесе ішкі жазба генерациялау

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

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

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

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

Тексеру үшін деректер жиынын қалай құрастыру керек

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

Алдымен негізгі жүктемені беретін 5-10 сценарийді таңдаңыз. Әдетте бұл — қате қымбатқа түсетін сұраулар: уақыт, ақша немесе пайдаланушы үшін тәуекел жағынан. Егер өнім банк, телеком немесе мемлекеттік секторда жұмыс істесе, PII маскалау, міндетті AI-контент белгісі немесе қатаң жауап құрылымы бар жағдайларды өткізіп алмаңыз.

Жиынтыққа жиі сұрауларды, қатесі қымбатқа түсетін сирек жағдайларды, орфографиялық қателері мен үзілген контексті бар хабарламаларды, екі тілдегі сұрауларды және модель детальдарды ұстап тұруы керек ұзын диалогтарды қосқан дұрыс. Әр сценарий үшін кемінде 30 мысал жинаңыз. Егер 70-100-ге жеткізсеңіз, салыстыру модельдің кездейсоқ сәттілігіне азырақ тәуелді болады.

Дерек көзі соншалық маңызды емес, маңыздысы — жинақтың адалдығы. Ішкі ережелер бойынша тазартылған нақты өтініштер, логтар, хаттар, чаттар немесе формалар жарайды.

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

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

Нұсқаны қалай бекіту керек

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

Эталондар мен жауап ережелерін қалай дайындау керек

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

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

Жақсы ереже қарапайым әрі тексерілетін болып естіледі. Әдетте мына нәрселерді бекіту жеткілікті:

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

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

Қандай критерийлерді есептеу керек

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

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

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

• толықтық
• фактілік дәлдік
• формат, соның ішінде үн мен ұзындық
• қауіпсіздік
• пайдалық

Мұндай тексеруді 0-1 немесе 0-2 шкаласында жасау ыңғайлы. Рубрика неғұрлым қарапайым болса, дау да азаяды. Егер тексерушілер бағада жиі келіспесе, кестені күрделендірудің қажеті жоқ. Ережені қайта жазған дұрыс.

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

Қауіпті қателерді бөлек метрикаға шығарған жөн. Орташа балл қалыпты көрінуі мүмкін, тіпті модель жағдайлардың 3%-ында қайтарым шартын ойдан шығарып, медициналық шектеулерді шатастырып немесе клиентті қате жерге жіберсе де. Критикалық қателердің үлесін бірінші болып қараған дұрыс.

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

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

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

Қолдау қызметі тапсырмасындағы мысал

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

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

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

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

Бір сұрауды бірнеше модельге беруге болады: "Тапсырысымды 9 күн күттім, ешкім жауап бермейді, қайтарым мен өтемақы керек". Жақсы жауап қысқа, сабырлы және нақты болады. Ол қайтару ережесіне сүйенеді, ойдан шығарылған өтемақыны қоспайды және жүйеде жоқ мерзімді уәде етпейді. Нашар жауап сенімді естіледі, бірақ "әдетте ақшаны 3 күнде қайтарамыз" сияқты ойдан шығарылған ерекшеліктерді қосады, егер ондай ереже болмаса.

Жақсы жауап деген не

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

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

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

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

Тағы бір қате метрикаларға байланысты. Команда орташа баллға қарап, оннан бір-екі ұпай айырмаға қуанады. Бірақ орташа мән көбіне қымбат сәтсіздіктерді жасырады. Егер модель 100 жағдайдың 95-інде қалыпты жауап беріп, қалған 5-інде сома, өтінім статусы немесе эскалация ережесін шатастырса, бұл бизнес үшін елеулі мәселе. Мұндай қателерді бөлек іздеу керек: қималар бойынша, тапсырма түрлері бойынша және ең тәуекелі жоғары сценарийлерде.

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

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

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

Салыстыру алдындағы жылдам тексеріс

Тест жинағы асығыс құрастырылса, модельдерді салыстыру басынан-ақ бұзылады. Өнімнен нақты сценарийлерді алып, бірден олардың үлесін белгілеңіз. Егер сұраулардың 50%-ы — қолдауға арналған қысқа сұрақтар, 30%-ы — база арқылы іздеу, ал 20%-ы — бірнеше шарты бар күрделі өтініштер болса, тест жинағы да осы көріністі қайталауы керек.

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

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

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

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

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

Алғашқы тесттен кейін не істеу керек

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

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

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

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

Егер сіз көп провайдерді салыстырсаңыз, артық қол еңбегі команда уақытын тез жейді. Ондайда бір OpenAI-үйлесімді эндпоинт арқылы бірдей сұрауларды өткізу ыңғайлы. Деректерді Қазақстан ішінде сақтау, аудит-логтар, PII маскалау және әртүрлі модельдерге бір ортақ қол жеткізу контуры маңызды командалар үшін airouter.kz бағалау процесін, тек продакшенге қосуды ғана емес, едәуір жеңілдете алады.

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