Қолдау тикеттерінен бенчмарк: тірі жиынтықты қалай құрастыруға болады

Неліктен оқу мысалдары қолдауға ұқсамайды

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

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

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

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

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

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

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

Жиынтыққа қандай тикеттерді алу керек

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

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

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

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

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

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

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

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

Деректерді қалай анонимдеп, мағынаны сақтауға болады

Шикі қолдау диалогтарында дербес деректер әрдайым болады. Әдетте бұл — аты, телефоны, ЖСН, мекенжайы, тапсырыс нөмірі, e-mail, кейде карта нөмірі немесе құжаттың соңғы цифрлары. Бастаған кезде мәтінді түгел тазалаудан гөрі, алдымен мәндер түрін табу дұрыс. Сол кезде хат соңындағы қолтаңба немесе тикет тақырыбындағы тапсырыс нөмірі сияқты ұсақ нәрселерді өткізіп алмау оңайырақ.

Ереже қарапайым: жеке деректерді бір типтегі түсінікті белгілермен ауыстырыңыз. Егер диалогта телефон болса, ол барлық жерде [PHONE] болуы керек, бір жерде [TEL], басқа жерде [NUMBER] емес. Клиенттің атын [NAME_1], тапсырыс нөмірін [ORDER_1], мекенжайды [ADDRESS_1] деп ауыстырған дұрыс. Сонда мәтін оқуға жеңіл болып қалады, ал модель кездейсоқ жұлдызшалардан емес, шынайы өтініш құрылымын көреді.

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

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

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

Қысқа мысал: "Менің атым Айдос, тапсырыс 548921, курьер 12 мамырда келмеді" дегенді "Менің атым [NAME_1], тапсырыс [ORDER_1], курьер 12 мамырда келмеді" деп өзгерткен дұрыс. Жеке деректер алынып тасталады, бірақ шағым себебі түсінікті болып қалады.

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

Жиынтық тірі болып қалуы үшін тапсырмаларды қалай белгілеу керек

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

Алдымен әр өтінішке клиенттің ниетін білдіретін қысқа белгі беріңіз. 40 тармақтан тұратын күрделі таксономияның қажеті жоқ. Басында 8–12 белгі жеткілікті: "тапсырыс статусы", "қайтарым", "мекенжайды өзгерту", "шағым", "төлем ақауы", "аккаунтқа кіру". Егер оператор белгі таңдауға 15 секунд жұмсаса, схема тым ауыр болып кеткен.

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

Разметкада не сақтау керек

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

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

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

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

Қадамдап: алғашқы жиынтықты 10 күнде жинау

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

1–3 күндер

Алдымен 3–5 жиі сценарийді таңдаңыз. Әдетте бұлар — тапсырыс статусы, қайтарым, төлем ақауы, жеке кабинетке кіру, тарифті ауыстыру немесе қызметтен бас тарту. Сирек және экзотикалық жағдайларды әзірге алмаңыз. Олар шу қосады да, алғашқы прогонда онша көмектеспейді.

Содан кейін әр сценарийге 50–100 диалогтан шығарыңыз. Жақсысы — соңғы 2–3 ай сияқты жаңа кезеңді алу. Тек финал жауапты емес, әңгіменің бүкіл барысын да шығарыңыз: клиенттің бірінші хабарламасы, нақтылаулар, үзілістер, оператор қателері, басқа қызметкерге ауыстыру.

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

4–10 күндер

Келесі қадамда анонимдеуден өткізіңіз. Аты, телефон, e-mail, мекенжай, тапсырыс нөмірі, ЖСН және карта деректерін [ИМЯ] немесе [НОМЕР_ЗАКАЗА] сияқты түсінікті белгілермен ауыстыру керек. Мағына сақталуы тиіс: модель клиенттің нақты тапсырыс бойынша қайтарым күтіп отырғанын түсінуі керек, толықтай обезличенный мәтінді емес.

Автоматтандыру жұмысты жылдамдатады, бірақ қолмен тексеріссіз ол қателеседі. Диалогтардың кем дегенде 10–15%-ын көзбен қарап шығыңыз. Көбіне маскалау еркін формадағы деректерді өткізіп алады: "менің нөмірім 8701-ден басталады", "жеткізу Абая 12-ге болды", "мен әйелімнің почтасынан жаздым".

Одан кейін пилот бөлігіне, шамамен 30–50 диалогқа, разметка жасаңыз. Барлығын бірден белгілеуге тырыспаңыз. Пилотта ережелердің қай жерде бұзылатыны тез көрінеді: оператор дұрыс жауап берді, бірақ дөрекі тонмен; клиент бір хабарламада екі сұрақ қойды; диалог шешімсіз аяқталды. Сол сәтте разметка схемасын түзету кейін бүкіл жиынтықты қайта жасағаннан жеңілірек.

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

Интернет-дүкенге арналған жиынтық үлгісі

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

Алғашқы жиынтыққа тон мен ақау түрі әртүрлі болса, 20–30 диалог жеткілікті. Қысқа және орташа перепискаларды алған дұрыс, онда факт те, эмоция да бар және модель қателесетін кемінде бір орын болады.

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

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

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

Оператор растау сұрайтын диалогтар да пайдалы: чек, қораптың фотосы немесе картаның соңғы 4 цифры. Мұндай мысалда модель артық жеке дерек сұрамай ма және келесі қадам үшін қандай растау жеткілікті екенін түсіне ме — соны тексеру ыңғайлы.

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

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

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

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

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

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

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

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

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

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

Жұмысқа лайық тәсіл ойлағаннан қарапайым: шуы бар диалогтарды алу, 3–6 реплика контекстті сақтау, дәлдік пен тонға бөлек бағалар қою, жаңа отложенная выборканы ұстап тұру және әр прогонға разметка ережелерін бекіту. Сонда жиынтық, ол ұнай ма, ұнамай ма, шындықты көрсете бастайды.

Алғашқы прогон алдындағы жылдам тексеріс

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

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

Іске қоспас бұрын бірнеше кесіндімен тез танысып шығу пайдалы. Диалог ұзақтығын қараңыз: жиынтықта қысқа сұраулар, әдеттегі жұмыс тізбектері және клиент тақырыпты өзгертіп, деталь жіберіп, бір күннен кейін қайта оралатын ұзақ тарихтар болуы керек. Сценарийлер бойынша теңсіздікті тексеріңіз. Егер жиынтықтың 60%-ын "тапсырысым қайда" сияқты бір жиі жағдай алып жатса, сіз бүкіл қолдау сапасын емес, бір ғана сценарийді өлшеп отырсыз.

Бір үлгіде екі адамның разметкасын салыстырыңыз. 30–50 кейс те командада дұрыс жауап, эскалация және бас тарту туралы көзқарас сәйкес келе ме, соны түсінуге жеткілікті. Егер разметчиктер жиі келіспесе, мәселе көбіне адамдарда емес, ережелерде. Демек, критерийлер тым жалпы: жауап қашан толық саналады, қашан нақтылау сұрау керек, қашан сұрақты операторға беру қажет — бұл түсініксіз.

Анонимделген диалогтарды ашып, негізгі бөлшектерді тексеріңіз. Күндер, сомалар, жеткізу мерзімі және тапсырыс нөмірлері оқуға жеңіл әрі шынайы болып қалуы тиіс, әйтпесе тапсырманың мәні жоғалады. Анонимдеуде де қателеседі: команда бәрін бірдей маскалап, контекстті кездейсоқ өлтіріп алады. "18452 тапсырыс, 03.11 күні, 12 990 тг" дегенді "[номер] [дата] [сома]" түріне айналдыруға болмайды. Қолдау деректері бойынша модельді бағалауда маңыздысы — жеке деректердің өзі емес, фактілердің құрылымы.

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

Тіпті жиынтықты PII маскалау және аудит-логтары бар шлюз арқылы өткізсеңіз де, қолмен тексеріс бәрібір керек. Мысалы, AI Router ішінде мұны әртүрлі модельдерге арналған бірыңғай OpenAI-үйлесімді қолжетімділікпен біріктіруге болады, бірақ датасет соның арқасында өздігінен таза болып кетпейді. Кемінде 15–20 кейсті көзбен ашып, жиынтық әлі де операторлардың шынайы жұмысына ұқсайтынына, ал тазартылған оқу мысалына айналып кетпегеніне көз жеткізіңіз.

Осы жиынтықпен кейін не істеу керек

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

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

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

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

Егер көп модель салыстырсаңыз, оларды бір OpenAI-үйлесімді эндпоинт арқылы өткізген ыңғайлы. Бұл сценарийде AI Router ыңғайлы қабат бола алады: команда base_url-ды api.airouter.kz-ке ауыстырып, сол SDK, код және промпттарды қайта жасамай-ақ қолдана береді. Бұл бір жиынтықта салыстыруды жеңілдетеді.

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

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