TL;DR
Parameter value language mismatch — ситуация, когда модель правильно понимает намерение и выбирает нужный инструмент, но копирует параметры на языке запроса вместо английского. Запрос "Какая погода в Москве?" → модель вызовет get_weather(location="Москва") вместо get_weather(location="Moscow"), и инструмент сломается. Функция правильная, намерение понято, но параметр на русском делает вызов неисполняемым.
Модели копируют токены из запроса напрямую в параметры. Если запрос на русском — параметры будут на русском. Если на хинди — на хинди. Это не ошибка понимания: модель знает что нужно, правильно выбрала функцию, но не переводит значения параметров на английский, потому что следует паттерну входного текста. Для высокоресурсных языков (китайский, хинди) копирование особенно сильно — модель уверенно переносит знакомые токены. Для низкоресурсных (игбо) проблема другая: там чаще ошибки понимания, модель не уверена в семантике.
Исследователи нашли три стратегии снижения проблемы: частичный перевод (ключевые данные в запросе оставляешь на английском, остальное на родном языке), явная инструкция (прямо пропиши "выводи параметры на английском"), пре-перевод (переведи запрос на английский перед отправкой). Ни одна не убирает проблему полностью, но частичный перевод работает лучше всего — модель видит английские значения в запросе и копирует их правильно.
Схема проблемы
ЗАПРОС (русский): "Узнай погоду в Москве на 7 дней"
ЧТО МОДЕЛЬ ПОНИМАЕТ:
✅ Намерение: узнать прогноз погоды
✅ Инструмент: get_weather()
✅ Параметры: location, days
ЧТО ГЕНЕРИРУЕТ:
❌ get_weather(location="Москва", days="7")
↳ Инструмент ожидает location="Moscow"
↳ Вызов не выполнится
ПРАВИЛЬНО БЫЛО БЫ:
✅ get_weather(location="Moscow", days="7")
Проблема не в понимании — в копировании токенов без перевода.
Пример применения
Задача: Ты настраиваешь AI-ассистента для клиентов, которые пишут на русском. Ассистент должен бронировать столики в ресторанах через API. API принимает только английские параметры: restaurant_name, cuisine_type, city. Клиент пишет: "Забронируй столик в итальянском ресторане в Санкт-Петербурге".
Промпт без mitigation (сломается):
У тебя есть функция book_table(restaurant_name, cuisine_type, city).
Запрос клиента: "Забронируй столик в итальянском ресторане в Санкт-Петербурге"
Результат: Модель вызовет book_table(cuisine_type="итальянском", city="Санкт-Петербурге") — API не поймёт кириллицу, запрос провалится.
Промпт с частичным переводом (работает лучше):
У тебя есть функция book_table(restaurant_name, cuisine_type, city).
Запрос клиента: "Забронируй столик в Italian ресторане в Saint Petersburg"
Важно: используй значения параметров точно как они указаны в запросе (Italian, Saint Petersburg).
Результат: Модель видит английские значения в запросе и копирует их правильно: book_table(cuisine_type="Italian", city="Saint Petersburg"). Вызов выполнится. Ты заранее подставляешь ключевые значения на английском в запрос клиента, но формулировку оставляешь естественной.
Промпт с явной инструкцией (работает частично):
У тебя есть функция book_table(restaurant_name, cuisine_type, city).
Запрос клиента: "Забронируй столик в итальянском ресторане в Санкт-Петербурге"
ВАЖНО: Все параметры функции должны быть на английском языке.
Переведи значения перед вызовом.
Результат: Модель попытается перевести, но не всегда стабильно. Может сработать: book_table(cuisine_type="Italian", city="Saint Petersburg"). Может и нет — зависит от модели и сложности запроса. Явная инструкция помогает, но не гарантирует 100% соблюдения.
Почему это работает
LLM копирует паттерны из входного текста. Если запрос содержит "Москва", модель воспринимает это как готовое значение параметра и переносит напрямую. Модель не "думает" что нужен перевод — она следует структуре запроса. Английский запрос → английские значения. Русский запрос → русские значения.
Модель хорошо умеет извлекать структуру — она понимает что "Москва" это location, "7 дней" это days. Семантика схвачена правильно. Но плохо умеет нормализовать язык параметров, потому что её не учили переводить значения внутри function calls — учили копировать и форматировать.
Частичный перевод эксплуатирует механику копирования. Ты подставляешь английские значения прямо в запрос: вместо "Москве" пишешь "в Moscow", вместо "итальянском" — "в Italian". Модель видит готовое английское значение и копирует его. Ты обходишь слабость (нет автоматического перевода) через сильную сторону (точное копирование токенов).
Явная инструкция работает слабее. "Переведи параметры на английский" — это meta-инструкция, которая конфликтует с базовым паттерном копирования. Модель должна одновременно извлечь значение (копирование) и трансформировать его (перевод). Это сложнее, чем просто скопировать готовое. Результат нестабильный.
Рычаги управления:
- Язык ключевых значений в запросе → подставь английский вместо русского для критических параметров (города, типы, имена) — резко снижаешь ошибки
- Явность инструкции → добавь "переведи значения на английский" — частично помогает, но не всегда срабатывает
- Пре-обработка запроса → если можешь перевести весь запрос на английский перед отправкой (например, через отдельный запрос к модели или Translation API) — это максимально надёжно, но требует дополнительного шага
- Формат вывода → если добавишь "сначала покажи extracted values с переводом, потом вызов функции" — увидишь где модель ошиблась, но это не исправит саму проблему
Шаблон промпта
Для частичного перевода (самый надёжный):
У тебя есть функция {название_функции}({параметр_1}, {параметр_2}, ...).
Запрос: "{запрос_с_английскими_значениями}"
Используй значения параметров точно как они указаны в запросе.
{запрос_с_английскими_значениями} — твой запрос на русском, но ключевые данные (города, названия, типы) заменены на английские эквиваленты. Пример: "Забронируй столик в Italian ресторане в Saint Petersburg" вместо "Забронируй столик в итальянском ресторане в Санкт-Петербурге".
Ты создаёшь гибридный запрос: естественная формулировка на родном языке + английские значения для параметров API. Модель копирует английские токены прямо в параметры.
Для явной инструкции (менее надёжно):
У тебя есть функция {название_функции}({параметр_1}, {параметр_2}, ...).
Запрос: "{запрос_полностью_на_русском}"
ВАЖНО: Все значения параметров должны быть на английском языке.
Переведи значения из запроса на английский перед вызовом функции.
Работает хуже, чем частичный перевод, но не требует модификации исходного запроса пользователя.
Ограничения
⚠️ Низкоресурсные языки: Для языков с малым представлением в обучающих данных (например, региональные языки, редкие диалекты) проблема копирования параметров меньше — модель реже копирует незнакомые токены. Зато чаще ошибается в понимании намерения: не может точно извлечь значения из запроса или путает параметры. Стратегии для высокоресурсных языков здесь не помогут.
⚠️ Неполное решение: Ни частичный перевод, ни явные инструкции не устраняют проблему полностью. Модели всё равно иногда копируют русские токены или вносят ошибки при переводе значений. Если критична 100% надёжность — используй пре-перевод всего запроса через отдельный шаг (например, сначала "переведи на английский", потом передай инструментам).
⚠️ Применимо только для function calling: Если ты не используешь tools/functions в ChatGPT или Claude, эта проблема тебя не касается. Инсайт актуален только при вызове внешних инструментов с жёсткими языковыми требованиями к параметрам.
⚠️ Смешанный контекст может запутать: Частичный перевод создаёт неестественный запрос ("Забронируй в Italian ресторане в Moscow"). Если модель должна ещё и генерировать текст для пользователя (не только вызов функции) — гибридный язык может повлиять на стиль ответа. Используй только когда фокус на вызове инструмента, не на коммуникации.
Как исследовали
Команда взяла английский бенчмарк для вызова инструментов (BFCL V4) и перевела запросы на китайский, хинди и игбо (низкоресурсный африканский язык). Важно: переводили только запросы пользователей, а интерфейс инструментов оставался на английском — как в реальной жизни. Проверили на 10+ моделях: GPT-5, DeepSeek V3.2, Llama 3.1, Qwen 3, Granite 4.
Создали три варианта запроса: - NT (Not Translated) — оригинал на английском (reference) - FT (Fully Translated) — весь запрос на целевом языке - PAR (Partially Translated) — запрос на целевом языке, но значения параметров остались на английском
Измеряли не просто точность, а типы ошибок. Разделили промахи на: синтаксические (модель вообще сломала формат), выбор неправильной функции, ошибки в ключах параметров, и главное — parameter value language mismatch (параметр семантически правильный, но на неправильном языке).
Результаты показали чёткий паттерн: FT резко увеличивает language mismatch ошибки (особенно для китайского и хинди), PAR почти полностью их устраняет. Модели понимают намерение правильно, но копируют русские/китайские токены в параметры. Удивительно: для игбо language mismatch почти нет — зато больше ошибок понимания. Модель не уверена в семантике низкоресурсного языка, поэтому не копирует токены, а пытается угадать или генерирует неправильные значения.
Проверили три стратегии mitigation: PT (явно попросить выводить на английском), PRE (перевести запрос на английский до вызова), POST (перевести параметры на английский после генерации). PRE работает лучше — устраняет большинство language mismatches. POST и PT помогают частично. Но даже PRE не даёт 100% английского уровня: перевод вносит семантический дрейф — слова меняются, появляются синонимы, строгое совпадение ломается.
Инсайт для практики: проблема не в понимании языка, а в копировании токенов. LLM схватывает намерение отлично, но не переводит значения автоматически. Если хочешь надёжности — давай английские значения прямо в запросе (PAR стратегия) или переводи весь запрос до вызова инструмента.
Ресурсы
Lost in Execution: On the Multilingual Robustness of Tool Calling in Large Language Models
Berkeley Function Calling Leaderboard (BFCL V4)
Zheng Luo (University of Southern California), Pranav Kutralingam, Ogochukwu N. Okoani, Wanpeng Xu, Hua Wei, Xiyang Hu (Arizona State University)