TL;DR
Исследователи проверили, куда смотрит LLM, когда чинит баг в коде — без доступа к внутренностям модели. Они по очереди вырезали куски из баг-репорта (описание проблемы, трейс ошибки, версию библиотеки, тестовый пример) и смотрели, насколько сильно меняется итоговый патч. Чем сильнее меняется результат после удаления куска — тем больше модель на него «смотрела».
Главная находка: когда LLM успешно чинит баг, её внимание распределено сразу на несколько частей — описание проблемы, трейс ошибки, тестовый пример. Когда чинит неудачно — внимание залипает на одном месте, чаще всего на версии библиотеки или окружения, а остальной текст как будто не читается. Это как человек, который зациклился на несущественной детали и упустил суть.
Есть ещё один слой: исследователи сравнили, куда смотрит модель, с тем, что реальные разработчики считают важным в этом же баг-репорте. Оказалось — чем больше внимание модели совпадает с приоритетами человека (описание + трейс, а не версия), тем выше шанс на правильный фикс. Отсюда практический вывод: если явно подсветить в запросе, что важно, а что — справочная информация, модель реже цепляется за мелочи.
Схема исследования
ШАГ 1: Взять баг-репорт → разбить на секции (описание, трейс, версия, тесты, репродукция)
ШАГ 2: По очереди убирать секцию → просить модель сгенерировать патч заново
ШАГ 3: Сравнить новый патч со старым → большая разница = модель "смотрела" на убранную секцию
ШАГ 4: Сопоставить паттерн внимания с успехом/неудачей фикса
ШАГ 5: Сравнить внимание модели с тем, что важным считают реальные разработчики
Пример применения
Задача: Вы копируете в Claude тикет из трекера (Jira/GitHub Issues) с описанием бага, стектрейсом, версиями библиотек, шагами воспроизведения — и просите исправить код.
Промпт (с учётом находки исследования):
Вот баг-репорт. Разбираю его по важности для тебя:
[ГЛАВНОЕ — фокусируйся здесь]
Описание проблемы: {текст описания}
Трейс ошибки: {стектрейс}
Тест, который падает: {тест-кейс}
[СПРАВОЧНО — не главное для диагностики]
Версия библиотеки: {версия}
Окружение: {ОС, зависимости}
Задача: найди причину ошибки, опираясь в первую очередь на описание, трейс и тест.
Версию и окружение используй только если без них решение невозможно.
Код функции: {код}
Результат: Модель с большей вероятностью будет учитывать описание проблемы и трейс ошибки одновременно, а не «залипнет» на версии библиотеки как единственном сигнале. Ответ придёт в виде анализа причины + патча кода, без лишнего фокуса на технических метаданных.
Почему это работает
LLM не «понимает» важность информации — она статистически распределяет внимание по тексту, ориентируясь на то, что выглядит конкретным и легко привязываемым к паттерну. Версия библиотеки — короткая, чёткая, легко «зацепиться». Суть проблемы обычно размазана в свободном тексте описания и требует связывания нескольких кусков — трейса, теста, описания.
Сильная сторона LLM — она хорошо реагирует на явные инструкции о приоритетах в тексте. Если явно пометить, что главное, а что вторично, модель охотнее распределяет внимание туда, куда нужно, а не туда, где «проще зацепиться».
Рычаги управления: - Явная разметка «главное / справочно» → снижает риск залипания на метаданных - Порядок информации в промпте → важное лучше ставить раньше, модели чаще уделяют больше внимания началу текста - Просьба «свяжи описание, трейс и тест перед тем как предлагать фикс» → провоцирует диффузное внимание вместо локального
Ограничения
⚠️ Домен исследования узкий: проверяли только исправление кода (Python/Java) с уже выделенной багованной функцией — не творческие или неоднозначные задачи.
⚠️ Это корреляция, не готовый рецепт: исследователи наблюдали паттерн внимания, но не тестировали, помогает ли явная разметка важности в промпте — это логичная экстраполяция, а не прямой результат эксперимента.
⚠️ Мало сложных случаев: в датасете почти нет by-design «hard» багов, поэтому выводы больше применимы к типовым, средним по сложности задачам.
Как исследовали
Команда взяла 319 реальных багов из Python и Java (из известных бенчмарков SWE-bench Verified и Multi-SWE-bench) и прогнала их через три модели — Claude, и две открытые (gpt-oss-20b, qwen3-32b). Вместо того чтобы лезть во внутренности модели (что часто невозможно для закрытых моделей вроде Claude), они использовали перестановочный анализ: вырезали кусок баг-репорта, смотрели, насколько изменился сгенерированный патч, и по силе изменения оценивали «внимание» модели к этому куску — через математику Shapley values (та же логика, что в объяснении решений нейросетей).
Дополнительно исследователи наняли четырёх разработчиков с опытом 5+ лет и попросили их вручную разметить 100 баг-репортов — какие секции важны, а какие нет. Это позволило сравнить, совпадает ли «взгляд» модели со взглядом человека.
Самое любопытное: даже когда модели давали ровно ту же самую информацию, паттерн внимания менялся от бага к багу — и именно разброс внимания по нескольким источникам, а не сосредоточенность на одном, оказался главным маркером успешного исправления.
Ресурсы
How Do LLMs Read Bug Reports? An Empirical Study of Attention in LLMs for Automated Program Repair — Ramtin Ehsani, Preetha Chatterjee (Drexel University), Irene Manotas, Saurabh Pujar, Luca Buratti (IBM Research).