Бенчмарк для казахского языка из реальных сценариев

Почему красивые демо ломают оценку

Красивое демо почти всегда собирает сама команда. Поэтому запросы в нем аккуратные: без опечаток, без обрывков мысли, без местного жаргона и без тех странных формулировок, которые люди пишут на ходу. На таком наборе модель почти всегда выглядит умнее, чем в реальной работе.

С казахским это заметно особенно сильно. В живом чате человек легко смешивает казахский и русский в одном сообщении, вставляет транслит, сокращения и куски из голосового ввода. Если в тесте только чистые фразы вроде "Напиши вежливый ответ клиенту", вы не проверяете реальную языковую среду.

Обычный рабочий запрос может выглядеть так: "Салем, кеше заказ бергем, акша 2 рет кетип калды, енди не истейм?" Человек поймет смысл сразу. Для модели это уже проверка на смешанную речь, орфографический шум и контекст поддержки. Именно на таких сообщениях и видны слабые места.

Короткие и удобные запросы тоже обманывают. Они не требуют держать длинный контекст, не проверяют переписку из нескольких сообщений и не показывают, что произойдет при двусмысленной формулировке. В демо модель отвечает гладко просто потому, что задача слишком удобная.

Есть и другая ловушка - один удачный ответ. Если модель хорошо справилась с одним примером, это ничего не доказывает. В продакшене важна повторяемость: как она ведет себя на 20 похожих обращениях, на разных вариантах одного вопроса, после смены модели или провайдера.

Хороший набор включает не только "чистые" примеры, но и сообщения с опечатками, разговорной формой, смешением казахского и русского, длинные цепочки с потерянным контекстом и похожие запросы, где нужен стабильный ответ.

Если набор похож на подборку красивых скриншотов для презентации, он почти бесполезен. Полезный набор немного неудобный, местами шумный и очень похожий на то, что реально пишут клиенты, операторы и сотрудники внутри компании.

Какие задачи брать в набор

Начинать лучше не с редких кейсов и не с эффектных примеров. Берите то, что люди делают каждый день. Если ошибка в ответе ведет к лишнему звонку, возврату заявки или потере продажи, такую задачу стоит тестировать первой.

Обычно достаточно пяти типов задач. Они простые по форме, но быстро показывают, понимает ли модель живой язык, а не только аккуратный промпт.

Повседневные вопросы в поддержке почти всегда входят в первый набор: статус заказа, возврат, лимит по карте, условия тарифа, сроки доставки. Люди задают их коротко, с ошибками и часто вперемешку на казахском и русском.

Хорошо работают и задачи поиска по каталогу. Пользователь пишет не так, как товар назван в базе. Он может ввести "ак койлек", "ақ көйлек" или "белая рубашка", а система должна найти близкий результат.

Отдельный тип задач - заполнение и проверка форм. Здесь модель извлекает ИИН, номер договора, дату, сумму, замечает пустые или неверные поля и не путает похожие значения.

Еще один полезный сценарий - краткий пересказ длинных текстов: письма клиента, заявки, внутренней инструкции или чата с оператором. Важно, чтобы модель сжала текст без потери смысла и не добавила то, чего не было.

Наконец, стоит проверять разбор обращения по теме и срочности. Вопрос про остаток на счете и жалоба на двойное списание требуют разной реакции, хотя оба могут выглядеть как короткое сообщение в чате.

Берите задачи, где есть языковая неровность. Для казахского это особенно важно: разные формы слов, разговорные варианты, опечатки, латиница вместо кириллицы, смешанные запросы. Если тест состоит только из аккуратных фраз вроде "қайтару шарттары қандай", модель покажет результат лучше, чем в реальной работе. А потом начнутся промахи на фразах вроде "затты кайтарсам бола ма".

Есть простой фильтр: оставляйте только те задания, где ответ можно проверить. Если даже эксперт спорит, кто прав, такой пример пока рано класть в набор. Для первого прохода лучше брать кейсы с ясным исходом: найден нужный товар или нет, верно заполнены поля или нет, правильно определена срочность или нет.

На старте достаточно 30-50 примеров на каждый тип задачи. Такой набор уже покажет, где модель держится уверенно, а где сыпется на обычных запросах.

Где взять живые примеры

Для набора не нужны придуманные вопросы. Лучше всего работают следы реальной работы: чаты с поддержкой, письма клиентов, заявки в форме, комментарии операторов, короткие запросы в поиске по сайту или приложению. Такой материал быстро показывает, как модель ведет себя вне демо, когда люди пишут сумбурно, спешат и путают слова.

Если вы собираете датасет для казахского языка, не пытайтесь сначала "почистить" его до учебного стандарта. Оставьте опечатки, разговорные формы, русско-казахское смешение, местные сокращения и кривые формулировки. Пользователь не пишет как редактор. Если убрать этот шум, вы проверите не реальный продукт, а аккуратную витрину.

Хороший старт часто выглядит так: 100-200 обезличенных диалогов из поддержки, 50-100 писем или заявок с длинным описанием проблемы, поисковые запросы с сайта или из приложения, несколько десятков дорогих ошибок и отдельная подборка редких, но неприятных случаев.

Редкие случаи лучше хранить отдельно. Они встречаются не каждый день, но бьют больнее всего: неверная сумма, пропущенное отрицание, путаница в адресе доставки, неверный статус заявки, опасный совет в теме здоровья. Один такой пример полезнее десяти гладких FAQ-вопросов. В банке, ритейле или телекоме такие ошибки обычно уже видны в жалобах, ручных эскалациях и спорных ответах операторов.

До разметки уберите все, что не должно попасть в датасет: ФИО, телефоны, почту, ИИН, номера договоров, внутренние ID и служебные пометки. Делайте это сразу. Иначе личные данные быстро расползутся по таблицам, обсуждениям и подсказкам для разметчиков. Для команд из Казахстана это просто практичный шаг: требования к хранению и обработке данных лучше учитывать в начале, а не чинить позже.

Полезно сохранять рядом короткий контекст. Не только сам вопрос, но и то, откуда он пришел, что хотел сделать человек и чем закончился разговор. Пара строк часто помогает понять, почему один и тот же текст в жизни считается правильным ответом, а в тесте вдруг выглядит спорным.

Как договориться о правильном ответе

Споры о качестве обычно начинаются не с модели, а с эталона. Если команда по-разному понимает, что считать хорошим ответом, набор быстро превращается в коллекцию случайных мнений.

Начните с простого правила: один пример проверяет одну задачу. Не смешивайте в одном кейсе поиск факта, вежливый тон, перевод и форматирование. Если пользователь спрашивает на казахском, как восстановить доступ к кабинету, этот пример должен проверять именно инструкцию по восстановлению.

Для каждого кейса зафиксируйте две вещи: что считается верным и что точно не подходит. Верный ответ может быть коротким, если задача простая. Неверным стоит считать не только фактическую ошибку, но и лишние выдумки, уход от вопроса, смену языка без причины и сломанный формат.

В оценке LLM на казахском это особенно важно. Один и тот же смысл часто можно выразить несколькими нормальными способами. Если ответ сохраняет смысл, тон и нужное действие, не стоит наказывать модель только за другую формулировку.

Что фиксировать для каждого примера

• цель ответа одним предложением
• допустимые варианты смысла
• жесткие ошибки
• язык ответа
• нужный формат

Например, запрос "Төлем түбіртегін қайдан жүктеймін?" можно считать закрытым, если модель отвечает на казахском, дает понятный путь в интерфейсе и не добавляет вымышленных разделов. Если она отвечает по-русски или советует кнопку, которой нет, это промах.

Отдельно отмечайте формат. Нужен ли один абзац, список шагов, JSON или короткий шаблон для оператора? Без этого разметчики быстро начнут спорить о стиле, хотя вы хотели проверить полезность ответа.

Разметчикам хватит короткой инструкции на одну страницу. В ней обычно достаточно описать цель набора, правила для языков, как отмечать частично верный ответ, и дать 3-4 примера с разбором. Если правило нельзя объяснить одной фразой, оно, скорее всего, слишком сложное для первого набора.

Хороший эталон не пытается охватить все нюансы языка сразу. Он помогает команде одинаково смотреть на ответ и быстро замечать, где модель правда помогает, а где только звучит уверенно.

Как собрать первый набор по шагам

Не пытайтесь сразу собрать идеальный набор. Для первого прогона хватит одного сценария и 50-100 примеров. Если взять меньше, случайные удачи и промахи слишком сильно повлияют на итог. Если взять больше, команда устанет размечать и начнет спорить о мелочах.

Сразу разложите примеры по сложности: простые, средние и сложные. Простые проверяют базовое понимание запроса. Средние добавляют контекст, ограничения или разговорный язык. Сложные включают смешение русского и казахского, опечатки, неполные данные или конфликтующие инструкции. Такая разбивка быстро показывает, где модель сыпется, а где держится уверенно.

Потом возьмите 2-3 модели и прогоните их с одним и тем же промптом и одинаковыми настройками. Не правьте текст запроса под каждую модель, иначе сравнение потеряет смысл. Если одна модель получила более удобную формулировку, вы уже сравниваете не модели, а разные условия.

После прогона не смотрите только на общий результат. Откройте провальные ответы руками и прочитайте их подряд. Обычно именно в этот момент видно, чего не хватает набору: живых формулировок, коротких сообщений, смешанного языка, региональных слов или неочевидных ограничений. Такие случаи и нужно добавлять в следующую версию.

Полезно отмечать не только факт ошибки, но и ее тип. Например, модель перепутала смысл, ответила слишком общо, проигнорировала запрет на выдумывание или не поняла казахскую формулировку. Через 20-30 таких просмотров картина обычно становится очень ясной.

Когда набор уже похож на реальную работу, заморозьте его версию перед сравнением. Дайте ей имя, сохраните отдельным файлом и не меняйте, пока не закончите тест. Иначе первая модель будет проверяться на одном наборе, а следующая уже на другом.

Хороший первый набор не обязан быть красивым. Он должен ловить ошибки, которые потом бьют по поддержке, продажам или внутренним процессам. Если после такого прогона команда понимает, что править в промпте, правилах ответа или маршрутизации модели, набор уже работает.

Как считать результат без сложной науки

Для прикладной проверки не нужен один "умный" балл. Нужны простые метрики, которые команда может проверить руками и повторить через месяц. Если метрика не помогает выбрать модель или найти слабое место, ее лучше не считать.

Когда ответ легко проверить, ставьте pass/fail. Это хорошо работает там, где модель должна вернуть факт, а не красивую формулировку: номер договора, сумму, дату, статус заявки, ответ "да" или "нет" по правилу. Либо модель попала, либо нет.

Для поиска и извлечения данных полезнее смотреть не на весь ответ сразу, а на отдельные поля. Если модель достала имя клиента верно, но ошиблась в сумме и дате, вы уже видите, где именно она ломается. Обычно достаточно считать долю верных значений по каждому полю и отдельно отмечать ошибки формата, если поле должно быть в строгом виде.

Нужны и две прикладные метрики, о которых часто забывают: задержка и цена за успешный ответ. Дешевая модель, которая часто ошибается, в реальной работе может выйти дороже. Простая формула быстро отрезвляет: общую стоимость прогона делите на число успешных ответов. Так сравнение получается честнее.

Если вы гоняете модели через единый шлюз вроде AI Router, такие цифры проще собирать в одном месте. У этого подхода есть еще один плюс: можно менять base_url на api.airouter.kz и прогонять разные модели через один OpenAI-совместимый эндпоинт без переписывания SDK, кода и промптов. Но сама логика не зависит от инструмента: успех, цена и время ответа должны жить рядом, а не в разных таблицах.

Общий процент по всему набору почти всегда прячет проблему. Делайте срезы по опечаткам, по смешанному языку, по длине входа и по типу задачи.

Такой разрез быстро показывает реальную картину. Модель может давать 85% на коротких чистых запросах и падать до 52% на длинных обращениях с разговорной орфографией. Для службы поддержки это не мелочь, а обычный рабочий день.

Вместо одной итоговой цифры лучше держать короткую таблицу по задачам: извлечение полей, классификация, ответ по базе знаний, перефразирование. У каждой строки свои метрики. Тогда видно, где модель подходит сразу, а где ей нужен другой промпт, роутинг на другую модель или ручная проверка.

Пример набора для службы поддержки

Для первого прогона хватит 200 обращений интернет-магазина на казахском. Это уже дает живую картину: где модель понимает клиента, а где путает смысл, язык ответа или тон. Такой набор полезнее, чем десяток аккуратных демо-фраз.

Берите не только "чистые" запросы. В реальной поддержке люди пишут коротко, с ошибками, на эмоциях и иногда смешивают казахский и русский. Один клиент напишет "Тапсырыс қайда?", другой отправит длинную жалобу на семь строк с датами, суммами и угрозой отказаться от покупки.

В выборке стоит покрыть темы, которые команда видит каждый день: доставка и сроки, отмена заказа, возврат товара или денег, бонусы и скидки, а также спорные случаи с оплатой или повторным списанием.

Эти темы полезны не ради разнообразия. Они по-разному проверяют модель. Доставка требует точного понимания статуса. Возврат и отмена быстро показывают, не придумывает ли модель правила магазина. Бонусы часто ломаются на мелочах: срок действия, условия начисления, исключения.

Добавьте в набор обращения разной формы. Примерно половина может быть очень короткой, в духе "Жеткізу қашан болады?" или "Бонустарым көрінбей тұр". Остальные пусть будут длиннее: с историей заказа, недовольством, лишними деталями и несколькими вопросами сразу. Именно на таких сообщениях видна настоящая проверка качества AI-ассистента.

Что проверять в каждом ответе

Смотрите не только на фактическую точность. У ответа службы поддержки есть еще несколько простых слоев проверки:

• модель правильно поняла вопрос клиента
• ответ дан на том языке, на котором обратился клиент
• тон спокойный и вежливый
• текст не обещает того, чего магазин не делает
• ответ не пропускает важную деталь, например номер заказа или срок возврата

Отдельно помечайте ошибки, которые стоят денег. Если модель неверно пообещала возврат, перепутала условия отмены или дала скидку, которой нет, это уже не обычный промах. Это риск для выручки и для команды, которой потом придется разбирать конфликт вручную.

На практике удобно ввести простой флаг "денежный риск". Тогда вы быстро увидите разницу между неловким ответом и ошибкой, после которой магазин теряет деньги, клиента или оба сразу.

Где команды чаще всего промахиваются

Первая ошибка проста: в набор попадает только аккуратный, литературный казахский. В жизни так почти никто не пишет. Пользователь смешивает казахский с русскими словами, пропускает буквы, пишет с телефона и не ставит диакритику. Если тестировать модель только на фразах вроде "Төлем жүргізілмеді", она покажет красивый результат и провалится на сообщении "tolem otpedi" или "картадан акша шыгып кетті".

Вторая ошибка рядом. Команда слишком усердно чистит данные. Убирают опечатки, нормализуют пунктуацию, переписывают короткие жалобы в ровный текст. Так набор становится удобным для проверки, но перестает быть похожим на реальный поток. Для оценки LLM на казахском лучше оставить часть шума. Иначе вы меряете не работу ассистента, а работу редактора.

Часто картину ломает и общий счет для разных задач. Чат, поиск по базе знаний и заполнение формы требуют разного поведения. В чате модель может уточнить вопрос. В поиске она должна не выдумывать и опираться на найденный текст. В форме важна точность полей и формат ответа.

Хотя бы минимально разделяйте сценарии: диалоговые запросы, вопросы с поиском по документам и задачи на извлечение или заполнение полей.

Еще один частый промах - команда меняет промпт по ходу сравнения. Одна модель тестируется на старой инструкции, другая на новой, третьей уже добавили пару примеров. После этого цифры теряют смысл. Сначала зафиксируйте промпт, формат ответа и параметры. Потом сравнивайте модели.

И последнее: многие смотрят только на качество ответа и забывают про задержку. Это дорогая ошибка. Для внутреннего помощника разница между 2 и 8 секундами иногда важнее, чем 3% точности. Если бот поддержки отвечает медленно, люди все равно уходят к оператору.

Быстрая проверка перед прогоном

Перед запуском стоит пройтись по набору как редактор, а не как исследователь. Хороший набор часто ломается не на модели, а на мелочах: дубликатах, мутной разметке и случаях, которые никто не сможет воспроизвести через неделю.

Начните с контраста. Внутри должны быть и простые запросы, и неприятные. Если у вас только аккуратные фразы вроде "Құжатты қайдан жүктеймін?", модель покажет слишком красивый результат. Добавьте шум: смешение казахского с русским, опечатки, короткие голосовые расшифровки, просьбы без контекста, резкие формулировки.

Потом уберите повторы. Если десять примеров отличаются только именем города или номером заказа, вы не расширяете набор, а просто раздуваете его. Лучше оставить один хороший пример на паттерн и добавить другой тип ошибки.

Перед прогоном проверьте пять вещей:

• в наборе есть и легкие, и неприятные случаи
• примеры не повторяют один и тот же сценарий под разными именами
• любой коллега понимает разметку без звонка и устных пояснений
• у вас есть отдельный список критичных ошибок
• команда может через неделю запустить тот же прогон тем же способом

С разметкой стоит быть строгими. Если один человек пишет "частично верно", а другой не понимает, чем это отличается от "верно, но грубо", спор начнется раньше оценки. Дайте короткое правило на каждый ярлык и один пример. Этого обычно хватает.

Список критичных ошибок держите отдельно от общей оценки. Для службы поддержки это может быть выдуманный тариф, пропуск запрета, неверный адрес, опасный совет или ответ не на том языке. Даже если модель набрала высокий средний балл, один такой промах может сделать результат непригодным.

Последняя проверка простая: откройте инструкцию и представьте, что завтра прогон запускает другой человек. Если ему нужно писать вам в чат с вопросом "а тут что считать ошибкой?", набор еще сырой. Когда правила читаются с первого раза, вы получите цифры, которым можно верить.

Что делать после первой версии

Первая версия набора почти всегда слабее, чем кажется. Это нормально. Польза начинается не в день сборки, а когда команда прогоняет тесты после каждого заметного изменения: нового промпта, другой модели, смены провайдера, правок в retrieval, фильтрах или постобработке.

Если этого не делать регулярно, бенчмарк для казахского языка быстро превращается в архив. Он вроде есть, но уже не показывает, что реально сломалось вчера. Намного полезнее короткий живой набор на 80 сценариев, который вы запускаете каждую неделю, чем папка с 800 примерами, к которой никто не возвращается.

Самый хороший источник новых кейсов - ошибки из продакшена. Пользователь спросил на смешанном казахско-русском, модель неверно поняла намерение, перепутала форму обращения или придумала факт - такой пример стоит сразу добавлять в набор. Не ждите квартального пересмотра. Поймали сбой, обезличили данные, записали ожидаемый ответ и включили кейс в следующий прогон.

Сравнивайте модели не по общему впечатлению, а по одной и той же версии набора, одному промпту и одинаковым правилам подсчета. Только так видно, стала система лучше или просто удачнее ответила на удобных примерах.

Если набор помогает ловить ошибки до релиза, значит он уже приносит пользу. Этого достаточно для хорошего старта.