Anthropic выяснила, что Claude на разных языках ведет себя не просто «по-разному», а по четырем измеримым осям: от теплоты до строгости, от осторожности до почтительности, от глубины до краткости и от прямоты до исполнительности. Для русскоязычной IT-аудитории это не академическое упражнение, а вполне прикладная история: язык запроса может влиять на то, какой ответ увидит команда, сколько токенов она сожжет и насколько безопасным окажется сценарий работы с моделью.
Об этом, со ссылкой на исследование Anthropic, сообщает The Register. По данным компании, эти четыре оси объясняют около 15% различий в том, какие «ценности» модель выражает в ответах на разных языках. Речь, впрочем, не о том, что модель что-то «исповедует» в человеческом смысле. Исследователи отдельно оговаривают: под ценностями они понимают нормативные признаки в поведении и формулировках Claude, например честность, осторожность или дружелюбие, а не некий внутренний набор убеждений.
Главная находка выглядит просто и от этого неприятно практично. Если общаться с Claude на английском, модель чаще уходит в строгость, точность и более развернутые объяснения. Если на арабском или хинди, в ответах сильнее проявляются теплота и мягкость. На оси «теплота против строгости» максимальный сдвиг, по словам Anthropic, как раз и наблюдается между арабским и хинди с одной стороны и английским с русским с другой. На оси «глубина против краткости» арабский дает более лаконичные ответы, а английский, наоборот, тяготеет к нюансам и деталям. Для тех, кто строит многоязычные продукты, это уже не вопрос стилистики интерфейса, а фактор, который меняет пользовательский опыт.
Есть и более любопытные детали. На оси «прямота против исполнительности» нидерландский, как пишет The Register, чаще дает тон, который пользователи считывают как более скромный и честный в оценке ограничений. Индонезийский, наоборот, чаще связан с уверенной и отполированной подачей. Если перевести это с языка исследовательских формулировок на язык продуктовых рисков, картина получается неприятная: два пользователя могут показать модели один и тот же бизнес-план и получить не просто разный стиль ответа, а разное впечатление о качестве самого документа. Один увидит аккуратную, почти поддерживающую обратную связь, другой — более холодную и критичную. Формально модель отвечает на один и тот же запрос. По факту она подталкивает к разным выводам.
Для Anthropic эта тема не новая. Компания уже отмечала различия между версиями собственных моделей: Sonnet 4.6 описывается как более почтительная и эмоционально теплая, тогда как Opus 4.7 сильнее тяготеет к точности, аккуратности формулировок и защите от злоупотреблений. Но если раньше разговор шел о различиях между моделями, теперь акцент сместился на различия внутри одной модели в зависимости от языка. Это важный сдвиг. Он означает, что поведение LLM определяется не только архитектурой, дообучением и системным промптом, но и свойствами языковых данных, на которых модель училась и с которыми она статистически соотносит «правильный» ответ.
Отдельный слой проблемы — экономика и безопасность. Краткость коррелирует с расходом токенов: чем короче ответ, тем ниже стоимость. Если Claude на разных языках системно отвечает короче в одних языках и длиннее в других, бизнес может получить разный юнит-экономический профиль для одних и тех же сценариев в разных странах. Еще чувствительнее история с безопасностью. The Register напоминает, что в системной карте Claude Opus 4.7 доля отказов на безобидные запросы заметно ниже в английском, чем в других языках. Плюс у отрасли уже есть наблюдение, что джейлбрейки работают с разной эффективностью в зависимости от языка. Из этого вытекает очень неприятный, но логичный вопрос: если в каком-то языке модель более уступчива или менее склонна к отказам, не становится ли этот язык более удобной оболочкой для обхода политик и генерации нежелательного контента?
Для разработчиков это означает, что локализация LLM-продукта нельзя закрыть переводом интерфейса и беглой проверкой промптов. Нужны отдельные тесты на тон, полноту, склонность к отказам и устойчивость к обходам хотя бы на ключевых языках. Для продактов — что A/B-метрики и пользовательская удовлетворенность в многоязычном сервисе могут зависеть не только от рынка, но и от характерных поведенческих сдвигов самой модели. Для HR и внутренних AI-инструментов — что ассистент, который на одном языке звучит как аккуратный reviewer, на другом может оказаться слишком мягким или, наоборот, чересчур резким. А для стартапов, продающих «единый AI-опыт по всему миру», новость особенно неприятна: единого опыта, похоже, нет даже до того, как в дело вступают разные культуры, регуляторы и сценарии использования.
Следующий большой вопрос для отрасли звучит уже не как «почему модель так делает», а как «что с этим считать нормой». Разные языки действительно несут разные речевые ожидания, но когда эти различия начинают влиять на безопасность, стоимость и деловые решения, их уже трудно списать на лингвистическую специфику. Похоже, в ближайшие месяцы разработчикам LLM-сервисов придется отдельно решать, где языковая вариативность полезна, а где она превращается в скрытый баг продукта.