Мультиязычный ИИ-агент: как настроить работу на разных языках

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

Из чего складывается язык ответа

Язык, на котором отвечает агент, определяется не одной настройкой, а цепочкой. На каждом звене можно потерять язык пользователя.

• Системный промпт. Если он написан по-английски и не содержит инструкции про язык, модель тяготеет к английскому или к языку последнего сообщения.
• Определение языка входящего сообщения. Короткие фразы («ок», «спасибо», emoji) детектятся плохо — язык лучше фиксировать по первому содержательному сообщению или профилю пользователя.
• База знаний и RAG¹. Если документы только на русском, а вопрос на испанском, агент либо переведёт фрагмент на лету (с потерями), либо честно не найдёт ответ.
• Инструменты и их ответы. Внешний API может вернуть данные на английском (названия статусов, ошибки), и модель вставит их в русский ответ как есть.

Базовая инструкция в системном промпте

Самый дешёвый и надёжный приём — явно зафиксировать правило языка в системном промпте, а не надеяться на «здравый смысл» модели. Рабочая формулировка выглядит примерно так: «Отвечай на том языке, на котором написано последнее сообщение пользователя. Если язык определить не удалось, используй русский. Не меняй язык в середине диалога без явной просьбы».

Это закрывает 80% случаев для крупных моделей вроде GPT-4o, Claude 3.5 Sonnet и Gemini 1.5, которые уверенно работают с десятками языков. Проблемы начинаются на редких языках и на смеси языков в одном сообщении.

Модель, которая «знает» язык, и агент, который стабильно на нём отвечает, — это разные вещи. Первое даёт вендор, второе настраиваете вы.

Три подхода к мультиязычности

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

1. Один промпт на все языки

Один системный промпт, инструкция «отвечай на языке пользователя», база знаний на одном языке с переводом на лету. Быстро внедрить, дёшево поддерживать. Минус — качество плавает: тон и терминология на неосновных языках получаются такими, какими их видит модель, а не вы.

2. Промпт и база под каждый язык

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

3. Пайплайн с переводом

Входящее сообщение переводится на «рабочий» язык агента (например, английский), агент работает на нём, ответ переводится обратно. Так делают, когда основная логика и база завязаны на один язык, а входящих языков много. Минус — двойной перевод копит ошибки и добавляет задержку.

Пошаговая настройка

1. Определите список языков. Отделите языки, которые нужно поддерживать на уровне бренда, от тех, где хватит «понятного ответа».
2. Зафиксируйте язык в промпте. Явное правило про язык ответа и про запрет переключаться посреди диалога.
3. Определяйте язык надёжно. Берите первое содержательное сообщение или язык из профиля пользователя, а не каждое короткое «ок».
4. Проверьте RAG. Убедитесь, что поиск по базе знаний находит релевантные документы независимо от языка запроса — иначе агент замолчит на неосновных языках.
5. Обработайте ответы инструментов. Статусы, коды ошибок и названия из внешних API нужно либо локализовать, либо инструктировать модель их переводить.
6. Протестируйте на смеси языков. Сообщения вида «нужен refund за заказ 123» ломают детекцию — проверьте их отдельно.

Кому это пригодится и кому нет

Пригодится:

• Поддержке в e-commerce с клиентами из СНГ и дальнего зарубежья — один агент вместо отдельных ботов на каждый язык.
• SaaS-продуктам с международной аудиторией, где документация уже на нескольких языках.
• Внутренним ассистентам в компаниях, где сотрудники пишут на смеси русского и английского.

Скорее не пригодится:

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

¹ RAG (Retrieval-Augmented Generation) — подход, при котором модель перед ответом ищет релевантные фрагменты в вашей базе знаний и опирается на них, а не только на то, что «помнит» из обучения. Для мультиязычности важно, чтобы поиск находил документы даже когда язык запроса не совпадает с языком документов.