Модели для ассистента на русском и казахском: как выбрать

Почему одна модель часто срывается на двух языках

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

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

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

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

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

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

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

Какие задачи ассистент должен закрывать

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

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

Лучше взять 5-7 задач прямо из реальной работы команды. Например: ответить на вопрос клиента про лимит, тариф или статус заявки; продолжить переписку после нескольких уточнений; собрать ответ по утвержденному шаблону без лишних фраз; кратко пересказать длинный диалог оператору; найти правило во внутренней базе и объяснить его простыми словами.

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

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

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

Что проверять на смешанных запросах

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

Дайте ей фразу, где язык меняется в середине: "Проверь статус заявки по договору 1542, жауапты қазақша бер, клиентке бүгін сағат 15:00 дейін керек". Хороший ответ сохранит весь смысл: что нужно проверить, на каком языке ответить и какой срок нельзя пропустить. Слабая модель часто цепляется только за последнюю часть фразы и забывает остальное.

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

Достаточно короткого набора проверок:

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

Отдельно проверьте неаккуратный ввод. Люди пишут "schet faktura", "otvet kazakhsha", "zhaloba", путают раскладку, пропускают буквы и сокращают слова. Нормальная модель восстанавливает смысл без лишней фантазии. Плохая додумывает детали, которых в вопросе не было.

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

Как проверить переключение между языками

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

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

Практичный тест

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

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

Обычно достаточно смотреть на четыре вещи:

• отвечает ли модель на языке последнего сообщения клиента;
• сохраняет ли цитаты, названия тарифов и фразы из документов без самовольного перевода;
• помнит ли выбранный язык после 8-10 реплик;
• как часто без причины возвращается на русский.

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

Результат лучше считать по долям, а не по впечатлению. Например, из 100 диалоговых ходов модель 92 раза ответила на нужном языке, 6 раз смешала языки и 2 раза сама ушла в русский. Для бизнеса это понятнее, чем общая оценка вроде "ответы выглядят нормально".

Если команда прогоняет такие тесты через AI Router, удобно проверять один и тот же набор диалогов на нескольких моделях через один OpenAI-совместимый endpoint на api.airouter.kz и не менять код. Так проще увидеть не только качество текста, но и то, какая модель реже срывается на переключении языков в одинаковых условиях.

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

Где важен местный контекст

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

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

Хороший тестовый набор обычно включает такие запросы:

• "Проверьте статус договора по БИН компании и скажите, в какой филиал обратиться в Астане";
• "Менде ИИН бар, бірақ шарт нөмірін ұмытып қалдым, не істеуім керек?";
• "Сколько будет 250 000 тенге в рассрочку на 6 месяцев без комиссии?";
• "Найдите ближайший филиал на улице Кунаева и напишите ответ на казахском".

На таких примерах сразу видно, понимает ли модель смешанный ввод и местные сущности. Она должна нормально читать названия городов, улиц и компаний на двух языках, не коверкать "Алматы", "Астана", "Шымкент", "Кызылорда", "Кунаева", "Толе би" и похожие формы. Частая проблема в том, что модель уверенно исправляет написание, хотя пользователь ввел все верно.

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

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

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

Как провести сравнение по шагам

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

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

Дальше лучше идти по простому плану.

1. Разделите запросы на три группы: простой диалог, смешанный язык и фразы с местным контекстом. В последнюю группу добавьте слова вроде "ЭЦП", "тенге", "БИН", "Kaspi", названия госуслуг и типовые формулировки из бизнеса Казахстана.
2. Дайте всем моделям один и тот же промпт. Не меняйте температуру, max tokens, системную инструкцию и формат ответа. Иначе вы сравните не модели, а случайные настройки.
3. Оценивайте ответы по простой шкале, например от 1 до 5. Смотрите на точность, язык ответа, понимание намерения и то, не придумывает ли модель факты.
4. Сохраняйте не только баллы, но и промахи. Один плохой пример часто полезнее среднего числа.
5. Повторите тот же тест через неделю. Если результат сильно прыгает, такую модель опасно ставить в продакшен без дополнительного контроля.

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

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

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

Представьте поддержку интернет-магазина в Казахстане. Клиент сначала пишет по-русски: "Хочу вернуть товар, если упаковка открыта?" Через минуту он уточняет по-казахски: "Егер чек болса, акшаны неше кунде кайтарасыздар?" На этом месте слабая модель часто ломается: отвечает снова по-русски, путает срок возврата со сроком перевода денег или начинает писать слишком общо, будто это выдержка из правил.

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

Как выглядит проверка

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

Проверка обычно сводится к четырем вопросам:

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

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

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

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

Ошибки при выборе модели

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

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

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

Чаще всего отбор ломается в четырех местах:

• берут 20 красивых примеров и забывают про короткие, грязные и неполные сообщения;
• смотрят на цену за токен, но не считают число повторных обращений;
• проверяют только первый ответ, а не 6-8 ходов подряд;
• не дают модели старый контекст: номер заявки, прошлый ответ, смену языка по ходу диалога.

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

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

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

Быстрая проверка перед запуском

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

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

Отдельно проверьте факты, которые нельзя искажать. Ассистент может писать гладко и при этом терять цифры. Для бизнеса это хуже, чем неловкий стиль. Возьмите реальные примеры: счет на 128 450 тенге, дата доставки 12 мая, номер договора, название филиала в Астане или Шымкенте. Модель должна сохранить их без потерь и без "творчества".

Короткий прогон можно собрать из пяти шагов:

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

Смешанный запрос не должен вызывать лишний допрос. Если пользователь пишет: "Заказ 5489 кешігіп тұр, скажите новую дату доставки", нормальная модель понимает задачу сразу. Плохая начинает переспрашивать язык ответа или теряет часть смысла.

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

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

Что делать после выбора

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

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

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

Отдельно следите за тремя метриками и не сводите их в одну среднюю оценку:

• цена на типовой сценарий или на 1000 обращений;
• скорость первого ответа и полного ответа;
• доля ошибок по русским, казахским и смешанным запросам.

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

Когда нужно быстро прогнать один набор тестов через разные модели, нет смысла каждый раз переписывать интеграцию. В AI Router можно использовать один OpenAI-совместимый endpoint, менять только модель и оставлять те же SDK, код и промпты. Это особенно удобно для команд, которым нужно честно сравнить несколько вариантов и понять, где разница идет от самой модели, а не от обвязки.

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