A/B-тест промпт па, әлде модель ме: қайсысы нәтиже бергенін қалай түсінуге болады

Неге A/B-тест жиі өтірік айтады

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

Ең жиі қате өте қарапайым. A нұсқасында ескі промпт пен ескі модель болды, ал B нұсқасында жаңа промпт пен жаңа модель болды. Егер нәтиже жақсарса, нақты не әсер еткенін білмейсіз. Кейде жаңа промпт көмектеседі, ал модель керісінше сапаны төмендетеді. Кейде бәрі керісінше болады.

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

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

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

Орташа мәннің өзі көп жағдайда алдайды. Егер жеңіл сұраулардың 80%-ы 3%-ға жақсарса, ал күрделі сұраулардың 20%-ы екі есе жиі құлдырай бастаса, жалпы нәтиже қалыпты көрінуі мүмкін. Бизнес үшін бұл — жаман айырбас. Пайдаланушы орташа өсімді емес, маңызды сценарийдегі өрескел қателікті есте сақтайды.

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

Алдымен тест сұрағын нақтылаңыз

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

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

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

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

Іске қосар алдында мына төрт нәрсені бекіткен пайдалы:

• бұл тестте нақты не өзгереді;
• қандай сапа метрикасы шешім қабылдайды;
• баға мен кідіріс бойынша қандай шек сізге жарайды;
• қандай нәтиже жеңіс саналады.

Тұжырым қарапайым әрі тексерілетін болсын. Мысалы: "Жаңа промпт жеңеді, егер дәлдік кемінде 5%-ға өссе, орташа құн 10%-дан артық артпаса және жауаптардың 95%-ы 2 секундтан тез келсе".

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

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

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

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

Сосын генерация параметрлерін бекітіңіз. Temperature, top_p, шығатын токен лимиті және stop-последовательдіктер жауаптың стилі мен толықтығын ойлағаннан да қатты өзгертеді. Жиі кездесетін қате өте бейкүнә көрінеді: команда промптты жаңартады да, үстіне max_tokens-ті көбейтеді, кейін жаңа нұсқа "ақылдырақ" деп шешеді. Іс жүзінде оған тек жауапқа көбірек орын берілді.

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

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

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

Промпт, модель және маршрут әсерін қалай бөлуге болады

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

Жұмыс тәртібі әдетте мынадай:

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

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

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

Тестті қалай өткізу керек

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

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

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

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

Жауаптарды барлық іске қосуда бір шкаламен бағалаған дұрыс. 1-ден 5-ке дейінгі жүйе жарайды немесе егер критерийлер қатаң болса, жай ғана "өтті / өтпеді" деуге болады. Маңыздысы — барлық нұсқаға бірдей шкала қолдану.

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

Практикадан мысал

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

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

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

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

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

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

Қандай метрикаларды бөлек қарау керек

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

Сондықтан метрикаларды бөлек бағандарға шығарған жөн:

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

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

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

Ең жиі жіберілетін қателер

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

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

Үшінші қателік — жұмыс сұрауларының орнына ыңғайлы сұрауларды тесттеу. Команда қысқа, таза мысалдарды, қате терулерсіз, артық контекстсіз және оғаш тұжырымдарсыз алады. Бірақ шынайы жұмыста пайдаланушылар басқаша жазады: ұзын хабарламалар жібереді, тілдерді араластырады, сұрақты қайталайды және қатаң форматта жауап сұрайды.

Тағы бір тұзақ — орташа балға соқыр сену. Айталық, орташа баға 4,1-ден 4,3-ке өсті. Жақсы сияқты. Бірақ жаңа нұсқа JSON-ды жиірек бұзса, өрістерді шатастырса немесе сирек сценарийлерде қауіпті жауап берсе, орташа көрсеткіш мұны жасырады.

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

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

Тесттен кейін не істеу керек

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

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

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

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

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

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