Пайдаланушы фидбегі eval үшін: скриншоттарды қалай жинап қалдырмау керек

Неге тек батырмалар жеткіліксіз

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

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

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

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

Скриншоттар да сирек көмектеседі. Олар тез чаттарға тарап кетеді, тредтерде жоғалады және іздеуге қиын. Скриншотта толық диалог, сұрау ID-сі және қай модель жауап бергені жиі болмайды. Хат алмасудағы дау үшін бұл әлі жетеді. LLM жақсарту кезегі үшін — жоқ.

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

Әрбір клип бойынша кемінде бес нәрсені сақтаған жөн: сұрау мәтіні мен алдыңғы 1–2 хабарлама, жауаптың дәл мәтіні, модель мен промпт нұсқасы, сұрау уақыты, түсінікті тізімнен қысқа себеп және қайталауларды көбейтпеу үшін кейс ID-сі. Сонда батырма ашу не реніш білдіру қимылынан шығып, тексеруге, топтастыруға және кейін бағалау кейстерінің жинағына қосуға болатын нақты белгіге айналады.

Кликпен бірге нені жазу керек

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

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

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

Әдетте бес дерек тобы жеткілікті: диалогтың өзі, сұрау маршруты, өнім контексті, клик себебі және қызметтік өрістер. Диалогта сұрау мәтіні, репликалар тарихы және модель жауабы болуы керек. Маршрутта — модель, провайдер, промпт нұсқасы және қажет болса температура мен жүйелік нұсқау. Өнім бөлігінде — экран, сценарий және пайдаланушы рөлі, мысалы «қолдау операторы» немесе «банк клиенті». Бөлек түрде уақыт, тіл, диалог нөмірі және сессия идентификаторы керек.

Қысқа себеп тегі көп уақыт үнемдейді. «Факті қате», «сұраққа жауап бермеді», «тым ұзын», «нашар тон», «дұрыс емес тіл» сияқты 6–8 түсінікті нұсқа жеткілікті. Пайдаланушы бір секундта біреуін таңдайды, ал команда кейін проблемалар түрі бойынша таңдауларды тез жинайды.

Кішкентай мысал. Банк клиенті чатта картаны қалай қайта шығару керегін сұрайды. Ол «қате» деп басады, өйткені жауап дөрекі емес, бірақ модель басқа өнімге арналған нұсқа берді. Егер сізде тек клик пен скриншот болса, талас шексіз жалғасады. Ал диалог мәтіні, тіл, пайдаланушы рөлі, модель, провайдер және промпт нұсқасы сақталса, мәселе анық: маршрутты тексеру, нұсқауды жаңарту және бұл кейсті eval-жинаққа қосу керек.

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

Нашар жауаптарды түрлерге қалай бөлуге болады

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

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

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

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

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

Қарапайым мысал бәрін орнына қояды. Пайдаланушы: «Қысқа жауап бер, 3 тармақпен және тек қайтару шарттары бойынша» деп сұрайды. Егер модель қайтару мерзімін ойдан шығарса, бұл — фактілік қате. Егер ол жеткізу мен жеңілдікке ауып кетсе, бұл — тапсырманы орындамау. Егер 3 тармақтың орнына ұзын мәтін берсе, бұл — формат бұзылысы. Егер тексеруді айналып өтуге кеңес берсе, бұл — тәуекелді жауап. Егер қатқыл жауап берсе, бұл — тон мәселесі.

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

Кликтен жұмыс кезегіне дейінгі жол

Кері байланыс скриншоттар папкасына айналмауы үшін әр клик бірден жеке кейс ретінде рәсімделуі керек. Пайдаланушы «қате» деп басты — жүйе click_id шығарады, оны сессиямен, хабарламамен, промпт нұсқасымен, модель маршрутымен және уақытпен байланыстырады. Содан кейін кейсті табуға, тексеруге және ұқсастарымен салыстыруға болады.

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

Карточкада әдетте даулы жауаптың айналасындағы диалог, техникалық контекст, ақаудың қысқа меткасы және статус, иесі мен шешімге арналған өрістер жеткілікті. Сонда командада «шағым» емес, жұмыс объектісі пайда болады. Бір кейс промпт түзетуге кетеді, екіншісі — модель ауыстыруға, үшіншісі — білім базасын тазалауға. Егер сұрау AI Router арқылы өтсе, қай провайдер мен қай модель арқылы өткенін бірден көру пайдалы.

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

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

Одан кейін кластер түзету кезегіне нақты тапсырма ретінде түседі. Тапсырманың иесі, мерзімі және түзету гипотезасы болуы керек. Мысалы: retrieval-ді тексеру, модель таңдау ережесін сұрау түрі бойынша бөлу немесе белгісіз лимиттерге бас тарту қосу. Егер гипотеза жоқ болса, карточканы «тағы 10 мысал керек» деп белгілеу жақсы, оны түсініксіз келесі қадамсыз ортақ тізімге тастамай.

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

Тірі фидбектен eval-набор қалай құруға болады

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

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

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

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

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

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

Жақсы eval-набор үлкен болуға міндетті емес. 400 скриншоттың орнына, себебі мен тексеруі анық 40 түсінікті кейс әлдеқайда пайдалы.

Мысал: банк қолдау чаты

Клиент мобильді банк чатында жазады: «Қолданбадағы аударым лимиті қандай?» Ол тәуліктік лимитті меңзеп тұр. Модель сенімді жауап береді, бірақ кезеңдерді шатастырып, күндік лимиттің орнына айлық лимитті айтады.

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

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

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

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

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

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

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

Бірінші жиі қате қарапайым: «пайдалы емес» деп басқаннан кейін команда ұзын түсініктеме сұрайды. Оны көп адам бермейді. Адам 20 секундта тапсырманы жапқысы келді, ал сіз одан шағын сауалнама сұрайсыз. Соның салдарынан минус көп, ал түсіндірме аз болады. Әдетте қысқа бірклик себептер мен ерікті комментарий өрісі жақсырақ жұмыс істейді.

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

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

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

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

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

Іске қосар алдындағы қысқа чек-лист

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

• Қателердің қысқа тегтері бар және саны аз. Әдетте 3–7 нұсқа жетеді.
• Журналда тек клик емес, сұрау, жауап, модель, промпт нұсқасы, уақыт, тіл, сессия ID-сі және негізгі метадеректер сақталады.
• Ұқсас кейстер біріктіріледі, ондайлар ондаған бірдей тикетке айналмайды.
• Eval-набор кездейсоқ емес, кесте бойынша жаңартылады.
• Процеске нақты бір адам жауап береді, «бәріміз аздап» емес.

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

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

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

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

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

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

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

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

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

Келесі аптада сол процесті қалдырып, бір артық тегті алып тастап, eval-наборға бір жаңа тест қосыңыз. Егер мұны тұрақты істей алсаңыз, жүйе жұмыс істеп тұр.