Онлайн және офлайн сапаны бағалау: қашан қайсысына сену керек

Қай жерде шатасу пайда болады

Шатасу команда екі бөлек нәрсені араластырғанда басталады: жауаптың сапасы және business-әсер. Модель ұқыпты жазуы мүмкін, ашық қателер жібермеуі мүмкін, бірақ конверсияны қозғамауы мүмкін. Кейде керісінше болады: product-метрикалар өседі, ал жауап әлсіз әрі кейде қауіпті болып қала береді.

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

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

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

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

Әдетте дау екі сұраққа тіреледі:

• Жауап адамға нақты тапсырмада пайдалы ма?
• Қате қымбатқа түсетін жерде жауап қателесе ме?

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

Онлайн-метрикалар нені көрсетеді

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

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

Мұндай сигналдар жол қысқа әрі мақсат бірден көрінетін жерде жақсы жұмыс істейді. Knowledge base бойынша іздеу, формадағы кеңестер, support-тағы жауаптар, сұраныстарды маршрутизациялау, жеке кабинеттегі қарапайым self-service — мұнда модель жауабы мен әрекет арасындағы байланыс әдетте тікелей.

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

Тек оң метрикаларды ғана емес, үйкеліс іздерін де бақылау пайдалы. Олар көбіне конверсия түскенге дейін мәселені көрсетеді:

• диалогтан кейінгі шағымдар
• операторға эскалациялар
• басталып кеткен әрекеттің тоқтатылуы
• сол тақырып бойынша қайталанған өтініштер
• мәселені шешуге кететін уақыттың өсуі

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

Офлайн-тексеру не береді

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

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

Сараптамалық тексеру product-метрикалардан жиі көрінбейтін нәрсені ұстайды. Пайдаланушы «пайдалы» деп басуы мүмкін, өйткені жауап сенімді естіледі, ал ішінде ойдан шығарылған тариф, ережеге қате сілтеме немесе түсіп қалған шектеу бар. Сарапшы мұндай ақауды бірден байқайды. Ол модельдің қай жерде факт ойлап тапқанын, қай жерде қадамдарды шатастырғанын және қай жерде қауіпті кеңесті тым сенімді үнмен бергенін көреді.

Офлайн-бағалауды төрт бөлікке бөлу ыңғайлы:

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

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

Офлайн-тексерудің тағы бір плюсы — қайталанғыштық. Бір наборды модельді, prompt-ты немесе base_url-ды ауыстырмас бұрын да, кейін де бірдей өткізіп, маусым, traffic және жарнама кампанияларынан келген шудысыз салыстыруға болады. Егер команда AI Router сияқты бірыңғай gateway қолданып, провайдерлерді немесе модельдерді жиі ауыстырса, мұндай test әсіресе пайдалы: ол жаңа конфигурацияның қай жерде нашарлағанын демода емес, нақты тапсырмаларда тез көрсетеді.

Онлайн қашан жаңылыстырады

Онлайн және офлайн бағалау жиі сәйкес келмей қалады, және бұл қалыпты. Click, конверсия және session depth адамдардың product ішіндегі мінез-құлқын көрсетеді, ал жауаптың таза сапасын емес. Қасында контекст өзгерсе, цифрлар команданы оңай басқа жаққа бұрып жібереді.

Ең жиі болатын ақау — акциялар мен маусымдылық. Банктегі ассистентті елестетіңіз: әдетте ол карталар мен аударымдарға көмектеседі, ал кейін банк refinancing акциясын іске қосады. Кеңестердегі click-тер мен өтінімдер өседі, бірақ бұл модель жақсырақ жауап бере бастады деген сөз емес. Адамдар онсыз да қызметті рәсімдеуге ниетті болып келген.

Маусымдық шарықтауларда да солай болады. Желтоқсанда пайдаланушылар жылдам шешімдерге жиі келіседі, ал ай басында balance пен лимиттерді белсендірек тексереді. Осы кезде ассистенттің екі нұсқасын тек конверсия бойынша салыстырсаңыз, қате модельді мақтап жіберуіңіз мүмкін.

Кейде мәселе жауаптың өзінде емес, экранда болады. Команда интерфейсті өзгертеді: батырманы көзге түсетіндей қылады, recommendation блогын жоғары жылжытады немесе артық бір қадамды алып тастайды. Содан кейін ассистент кеңесіне кликтер өседі. Бірақ өсім мәтін сапасында емес, әрекеттің көрінгіштігінде. Жаңа экран модельдің өзінен де қаттырақ user journey-ді өзгертеді.

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

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

Егер traffic акция немесе маусым салдарынан күрт өзгерсе, сол кезеңде экран немесе funnel жаңарса, test тым аз диалог жинаса, не конверсия шағымдармен, эскалациялармен және бас тартулармен бірге өссе, сақ болу керек.

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

Офлайн да қашан қателеседі

Белгіленген набор пайдалы, бірақ ол real жұмыспен байланысын тез жоғалтады. Команда оны жиі бір рет жинап, кейін айлар бойы сол бойынша жаңа модель нұсқаларын салыстыра береді. Осы уақытта сұраулардың формулировкасы, product-тар, ережелер және тіпті пайдаланушының үні өзгереді. Test әлі де ұқыпты көрінеді, ал prod-қа мүлде басқа сұрақтар келіп жатады.

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

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

Тіпті fresh набор да әрдайым құтқармайды. Сарапшылар көбіне бір ғана мінсіз жауап жоқ жерде дауласады. Біреуі жауапты пайдалы деп санайды, өйткені ол дәл. Екіншісі төмен баға қояды, өйткені tone тым құрғақ немесе нақтылау қадамы жетіспейді. Мұндай келіспеушіліктер біреудің қателескенін білдірмейді. Олар бағалау шкаласының өзі тым бұлыңғыр екенін көрсетеді.

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

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

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

Бағалауды қадамдап қалай құру керек

Онлайн және офлайн бағалау команда бір нақты сұраққа жауап бергенде жұмыс істейді, бәрін бірден өлшеуге тырысқанда емес. «Модель жақсарды ма?» дегеннен гөрі, «Ассистент операторға ережені қайта тексеруге жиі жібере ме?» немесе «Жауап типтік сұранысты эскалациясыз жабуға көмектесе ме?» деп сұраған дұрысырақ. Бір сценарий тексеруді бірден адал қылады.

1. Бір сценарий үшін бір жұмыс сұрағын тұжырымдаңыз. Қайтарымдарды, knowledge base бойынша іздеуді және құжат тексеруді бір test-ке араластырмаңыз. Әр жағдайға өз критерийі керек.
2. Метрикалардың жұбын таңдаңыз. Біреуі жұмыстағы әсерді көрсетуі керек: шешілген өтініштер үлесі, өңдеу уақытының орташа мәні немесе қайталанған байланыстар саны. Екіншісі traffic-тан тыс сапаны өлшеуі керек: рубрика бойынша дәлдік, жауаптың толықтығы, фактологиялық дұрыстық, саясатты сақтау, PII leakage-тің болмауы.
3. Нақты өтініштерден fresh набор жинаңыз. Команда үйреніп қалған ескі мысалдардан гөрі, соңғы апталардағы диалогтарды алған жақсы. Қалыпты жағдайларды да, қиындарын да қосыңыз: толық емес контекст, екіұшты сұрақ, қайшы ережелер. Даулы мысалдарды сараптамалық тексеруге беріңіз. Дәл сол жерде рубриканың әлсіздігі де, модель қатесі де көрінеді.
4. Трафиктің шағын бөлігінде A/B-test іске қосыңыз. Сонда команда мәселелерді арзанырақ ұстайды және бүкіл traffic-ті бірден тәуекелге тікпейді. Тек click пен конверсияны емес, шағымдарды, эскалацияларды, қолмен түзетулерді және сирек, бірақ қымбат қателерді де бақылаңыз.
5. Test-тен кейін барлық жаңа промахтарды наборға қайтарыңыз. Егер модель жаңа сұрау түрінде құласа, бұл мысал келесі релизге дейін офлайн-тексеруге кіруі тиіс. Сонда набор қатып қалмайды және жүйенің нақты жұмысын көрсетеді.

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

Мысал: банктегі support ассистенті

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

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

Офлайн

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

Кейде офлайн-test онлайнда кеш байқалатын мәселені бірден ұстайды. Мысалы, модель клиенттен «тағы бір сағат күте тұрыңыз» деп сенімді сұрайды, ал регламент бойынша мұндайда оператор керек. Жауапқа click оң болуы мүмкін, бірақ кеңестің өзі бәрібір қате.

Онлайн

Офлайннан кейін банк traffic-тің бір бөлігінде test бастайды. Мұнда клиент операторсыз жапқан өтініштер үлесі және тірі қызметкерге ауысу үлесі қаралады. Егер click пен конверсия өссе, бірақ сонымен бірге эскалациялар көбейсе, test-ті сәтті деуге болмайды. Әдетте бұл ассистенттің сенімді сөйлеп, бірақ мәселені толық шешпегенін білдіреді.

10–30 минуттан кейін сол тақырып бойынша қайталанған сұрауларды да қарау пайдалы. Клиент «пайдалы» деп басып, кейін карта немесе аударым туралы сол сұрақпен қайта келуі мүмкін. Support үшін бұл жаман сигнал.

Test-тен кейін даулы диалогтарды архивке жібермеу керек. Оларды белгіленген наборға қайтарып, дау себебінің белгілерін қосып, келесі model-ді сол жағдайлардан өткізу жақсы. Бірнеше итерациядан кейін дәл сол диалогтар қай model клиентке шын көмектесетінін, ал қайсысы тек көбірек click жинайтынын жақсы көрсетеді.

Релиз алдындағы қысқа чек-лист

Жаңа жауапты, prompt-ты немесе модельді іске қоспас бұрын команда жиі асығып, бәріне бірдей қарайды. Сонда цифрлардың ішінде тұншығып, қарапайым нәрсені өткізіп алу оңай: test бір ғана анық жауап беруі керек — жақсарды ма, жоқ па.

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

• Бұл test үшін бір басты метриканы таңдаңыз. Егер ассистент support-та жауап берсе, ол операторға ауыспай жабылған диалогтар үлесі болуы мүмкін. Қалған сандарды көмекші ретінде қалдырыңыз.
• Офлайн-набор соңғы апталардағы fresh сұраулардан жиналғанын тексеріңіз. Ескі набор жаңа формулировкаларды, маусымдық тақырыптарды және пайдаланушылардың жаңа қателерін жиі ұстамайды.
• Сарапшыларға бір нұсқаулық және бірдей талданған бірнеше мысал беріңіз. Әйтпесе бір адам сақ tone үшін бағаны түсіреді, ал екіншісі оны норма деп санайды.
• Experiment-ті traffic-тың бірқалыпты учаскесінде іске қосыңыз. Егер сол күндері акция, көрші сервистегі ақау немесе жаңа пайдаланушылардың күрт көбеюі болса, click пен конверсия шуылдайды.
• Стартқа дейін тоқтату шартын жазыңыз. Test мерзімі, ең аз traffic көлемі және experiment-ті тоқтататын немесе релизді шығаратын түсінікті шек керек.

Бұл әсіресе модельді бірнеше минутта ауыстыруға болатын жерде маңызды, мысалы LLM қолданбасында бірыңғай API gateway арқылы. Егер test ортасында команда prompt, лимиттер немесе басқа провайдерге маршрутты өзгертсе, comparison бұзылады. Сосын бәрі графиктер жөнінде дауласады, бірақ шын мәнінде бірдей нұсқаны салыстырмаған болады.

Жақсы жылдам test жалықтыратын сияқты естіледі, бұл қалыпты. Мақсат біреу, набор fresh, сарапшылар бірдей бағалайды, traffic тегіс, тоқтату ережесі алдын ала жазылған. Осындай режимде релизді аз талқылап, тезірек шешеді.

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

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

Жақсы бастама — бәрін бірден қамтуға тырыспау. Business үшін қатесі көрінетін бір сценарий алыңыз: мысалы, банктегі support ассистентінің өтінім status-ы туралы жауаптары. Ол үшін бір белгіленген набор және бір нақты мақсатты онлайн-test жинаңыз, мысалы операторға ауыспай жабылған өтініштер үлесі.

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

• model немесе prompt-та айқын өзгеріс болар алдында офлайн-test өткізіңіз
• релизден кейін limited traffic-та онлайн-метрикаларды қараңыз
• офлайн мен онлайн әртүрлі сигнал берген жағдайларды талдаңыз
• команданың шешімін және оған неге сенетініңізді тіркеңіз

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

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

Prod командалары үшін бұл model-дерді интеграцияны қайта жазбай-ақ тез ауыстыруға болатын кезде әсіресе ыңғайлы. AI Router-да бұл үшін бір OpenAI-үйлесімді endpoint қолданылады, ал audit-log-тар кейін қай model, баптау немесе маршрут нақты диалогта қате бергенін тексеруге көмектеседі.

Әдетте бастау үшін осының өзі жеткілікті: бір сценарий, бір набор, бір онлайн-test. Бірнеше циклдан кейін команданың өз сенім картасы пайда болады: қай офлайн-сигналдарға бірден сенуге болады, ал қай метрикаларды тек live traffic-та растау керек.