Code-switching в чатах: что ломается в русско-казахском диалоге

Где теряется смысл при смене языка

При code-switching в чатах смысл ломается не на редких и сложных фразах, а на самых обычных репликах. Пользователь начинает сообщение по-русски, вставляет уточнение на казахском, меняет тон на более вежливый или, наоборот, более прямой, а модель цепляется только за отдельные слова.

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

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

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

Сбивается обращение и роль

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

В диалоге с банком это видно сразу. Клиент пишет: "Картам бұғатталып қалыпты, не істеймін?" Потом добавляет по-русски: "Я в командировке, срочно нужно снять ограничение". Если модель плохо держит контекст, она отвечает общей инструкцией по перевыпуску карты вместо помощи с разблокировкой.

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

Смысл теряется не на уровне словаря, а на уровне намерения, вежливости и очередности действий. Если модель один раз приняла "уточняю" за "подтверждаю", дальше она отвечает уже не на тот вопрос.

Что ломается чаще всего

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

Частая проблема - смешение названий услуг, продуктов и документов. Пользователь пишет по-русски про перевыпуск карты, а следом по-казахски уточняет про справку или доверенность. Модель склеивает это в один запрос и советует не тот набор шагов. В итоге человек спрашивал про услугу, а получил ответ про документ.

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

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

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

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

Чаще всего повторяются одни и те же поломки:

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

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

Какие сообщения дают больше всего сбоев

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

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

Много проблем дают жаргон, транслит и обычные опечатки. Пользователь может написать "perevod otmen bola ma", "каспига туспеди", "смс келмед" или смешать кириллицу с латиницей в одном слове. Для человека это мелочь. Для модели это уже несколько задач сразу: распознать язык, восстановить форму слова и не потерять намерение.

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

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

Вот несколько будничных примеров, на которых смысл часто сдвигается:

• "Мне нужен возврат, но товарды кеше алдым"
• "Адресим озгерди, можно без визита?"
• "SMS келген жок, номер тот же"
• "На Сейфуллина филиал ашык па сегодня?"

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

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

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

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

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

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

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

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

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

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

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

Как прогнать проверку до релиза

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

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

Хорошо работает простая таблица с четырьмя полями:

• тестовый диалог
• ожидаемый результат
• ответ модели
• пометка о сбое

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

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

Например, клиент пишет: "Картам бұғатталып қалды, но SMS не пришла". Ожидаемый результат тут простой: бот объясняет шаги разблокировки и не уводит разговор в тему перевыпуска карты. Если одна модель советует ждать SMS, а другая сразу предлагает перевыпуск, расхождение уже поймано до релиза.

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

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

Простой пример из поддержки банка

Клиент пишет в чат банка по-русски: "Какая комиссия за снятие наличных с кредитной карты?" Через пару сообщений он переключается на казахский: "Менде Gold карта, лимит канша?" Для живого диалога это обычная ситуация. Человек не думает о языке. Он просто уточняет вопрос так, как ему удобно.

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

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

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

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

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

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

Как оценивать ответ без сложной схемы

Для быстрой проверки не нужна таблица на двадцать пунктов. На практике хватает пяти коротких вопросов.

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

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

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

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

Простая шкала

Чтобы не спорить о каждом примере, удобно разделить ошибки на три уровня:

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

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

Ошибки команды перед запуском

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

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

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

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

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

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

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

Быстрый чек перед релизом

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

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

Что должно быть в чеке

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

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

Если хочется быстро проверить систему на одном примере, возьмите реплику: "Я вчера 15 000 тенге аудардым, но получатель не увидел деньги". Если модель потеряла сумму, язык ответа или смысл слова "вчера", в проде она ошибется и на более простых сообщениях.

Что делать дальше

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

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

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

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

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

Не ждите идеального набора. Для начала хватит короткой подборки, которую можно прогнать за 10-15 минут и быстро обсудить с поддержкой, продуктом и QA. Через месяц у команды появится не общее впечатление о том, как работает code-switching в чатах, а список конкретных сбоев, которые уже не должны пройти в релиз.