Русский промпт может отключить веб-поиск у AI-агента: как ставить задачи, чтобы он не пропускал решение

В эксперименте автора проекта worklore русскоязычные задачи в среднем решались почти так же, как англоязычные: без подсказки успешными были 54,4% прогонов против 62,6%. Но Codex и Kimi K3.1 Pro в части русских запросов переставали искать информацию в интернете — и на задачах с ответом только на форуме это превращало оценку 5 из 5 в 0 из 5.

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

Почему проблема не в русском языке, а в пропущенном шаге поиска

Автор проверила шесть задач в девяти конфигурациях агентов, сделав по пять повторов для каждой комбинации языка задачи и наличия заметки с подсказкой. Основной массив составил 1050 прогонов, затем к нему добавили две модели Kimi и ещё 300 запусков. Всего в исследовании — 1350 прогонов.

Без заметки англоязычные задачи прошли в 169 случаях из 270, а русскоязычные — в 147 из 270. Это разница в 8 процентных пунктов; приведённый в исследовании 95-процентный интервал лежит от минус 16 до нуля. Автор оценивает результат как пограничный со случайным эффектом.

Почти всю разницу создали не все модели, а три конфигурации: Codex GPT-6-Sol medium, Codex GPT-6-Sol low и Kimi K3.1 Pro. У Claude Opus 5.5 результат совпал на обоих языках — 27 успешных прогонов из 30. Gemini 3.8 Flash также показал одинаковый результат: 17 из 30.

Ключевая деталь — не качество русского ответа и не перевод терминов. Claude, Codex, Gemini и Kimi отвечали на русском, сохраняя английские имена переменных и технические термины. GPT-OSS 120B, наоборот, отвечал по-английски независимо от языка задачи. Проблема появилась в поведении инструментального агента: часть конфигураций перестала запускать поиск.

Сначала определите: агенту хватает репозитория или нужен внешний факт

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

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

На четырёх задачах с недостающим фактом картина была другой. Без заметки успешность составила 47% для английских задач и 35% для русских. С заметкой показатель вырос до 94% и 92% соответственно. Это не доказывает, что любая заранее написанная инструкция исправит любую задачу, но показывает практичную вещь: известный контекст заметно ценнее надежды на самостоятельный поиск агента.

Перед запуском полезно ответить на четыре вопроса:

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

Добавьте в русскую задачу обязательный протокол исследования

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

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

Задача: [кратко опишите симптом и ожидаемое поведение].

1. Сначала изучи локальный код, конфигурацию и логи, относящиеся к проблеме.
2. Если причина не подтверждается локальными данными или зависит от внешнего сервиса,
   выполни веб-поиск по названию продукта, версии, тексту ошибки и ключевым идентификаторам.
3. Проверь официальную документацию, issue-трекеры и технические обсуждения.
4. Перед изменением кода перечисли:
   - какие гипотезы проверены;
   - какие источники или страницы были найдены;
   - какой факт подтверждает выбранное решение.
5. Затем внеси минимальное исправление и запусти подходящую проверку.
6. Если веб-поиск недоступен, явно сообщи об этом и не выдавай догадку за подтверждённую причину.

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

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

Не переводите техническую заметку ради агента без необходимости

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

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

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

Контекст, который уже проверен командой:

- Ошибка возникает после второго вызова записи в DynamoDB.
- В логах есть [точный текст ошибки].
- Аналогичный случай обсуждался для [название продукта или компонента].
- Не меняй схему данных, пока не проверишь, связано ли поведение с [конкретный факт].
- Используй идентификаторы, пути и тексты ошибок в исходном написании.

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

Где ломается: агент может выглядеть уверенным и ничего не искать

Самый неприятный сценарий из эксперимента — не плохой поиск, а его полное отсутствие. Codex выполнял поиск примерно в трети прогонов с англоязычной задачей и не делал этого ни в одном прогоне с русской. На задаче, где решение находилось только на форуме, оценка упала с 5 из 5 до 0 из 5.

Kimi K3.1 Pro показала аналогичный паттерн на второй форумной задаче: при русской формулировке поиск не запускался, а оценка также снизилась с 5 из 5 до 0 из 5. Добавление заметки с нужным фактом вернуло успешное решение в приведённом случае с Codex.

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

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

1. Возьмите одну реальную русскоязычную задачу, где команда уже знает внешний источник правильного решения.
2. Запустите агента в двух вариантах: со свободной формулировкой и с обязательным протоколом поиска.
3. Сравните не только патч, но и логи инструментов, список источников и число неподтверждённых гипотез.
4. Если поиск не был выполнен, добавьте короткую заметку с известным фактом и повторите запуск.

FAQ

Нужно ли всегда писать промпты агентам на английском?

Нет. В эксперименте общий разрыв между английскими и русскими задачами без заметки составил 8 процентных пунктов и был на грани случайного. Большинство протестированных конфигураций почти не изменили результат.

Какие агенты просели на русскоязычных задачах?

Наиболее заметное снижение показали Codex GPT-6-Sol medium, Codex GPT-6-Sol low и Kimi K3.1 Pro. В исследовании это было связано с тем, что они реже или вовсе не запускали веб-поиск.

Стоит ли переводить на русский технические заметки для агента?

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

Как понять, что агент действительно провёл исследование?

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

Источники

• Habr AI: Я написала промпт по‑русски. Два агента перестали искать решение в интернете