Как LLM находит нужный код в репозитории, который не помещается в контекст

Если вы когда‑нибудь открывали большой репозиторий в поисках бага, вы знаете это ощущение: сотни файлов, куча неочевидных связей, а issue обычно вообще никак не описаны. Для LLM проблема та же, только жёстче: она физически не может держать в контексте весь проект. Поэтому современные агенты по разработке ПО вынуждены работать итеративно — читать кусочки документации и кода, делать выводы, вызывать инструменты, снова читать и так далее.

Авторы работы One Tool Is Enough предлагают находить нужные файлы и функции, агенту не нужен набор разрозненных инструментов поиска. Достаточно одного — но правильно выбранного.

Следование логике исполнения

Большинство RAG-решений строятся вокруг retrieval нужных классов, методов и импортов. Выглядит разумно, но есть скрытая проблема: такой набор инструментов плохо совпадает с тем, как код реально исполняется. В runtime не существует «поиска класса» — существуют вызовы, ссылки и переходы к определениям. А ещё каждый дополнительный инструмент — это новый формат вызова, новые ошибки в параметрах и больше шансов, что агент где‑то собьётся.

RepoNavigator делает ставку на единственное действие: jump. Это переход к месту определения классов, методов и переменных. Инструмент реализован через языковой сервер (в статье используется Pyright), который статически разбирает код, учитывает области видимости, импорты и даже вывод типов, чтобы вернуть правильное определение.

Задача проще, чем починить баг, но практичнее, чем кажется

Авторы сознательно не учат модель сразу чинить баги. Это дорого и трудно проверять: один issue может иметь много корректных патчей, а надёжная оценка требует запускать тесты в Docker для каждого репозитория. Вместо этого они берут этап, который почти всегда является узким горлышком: issue localization — определить, какие файлы и функции действительно относятся к проблеме.

Идея прагматичная: если локализация точная, последующая доработка (другим агентом или человеком) становится на порядок проще, потому что пространство поиска резко сужается.

Как агент учится ходить по коду

RepoNavigator обучается не через дистиляцию от закрытых моделей, а напрямую: берут предобученную модель (в экспериментах Qwen2.5 разных размеров) и дообучают её с подкреплением по схеме RLVR, используя вариант оптимизации GRPO. Награда устроена так, чтобы агенту было выгодно не только попасть в правильные файлы/функции (через метрику Dice/IoU), но и корректно вызывать инструмент. Это важная деталь: агент, который знает ответ, но постоянно нарушает формат вызова, в реальном пайплайне бесполезен.

Абляции показывают, что гибридная награда (качество локализации + успех tool-calling) обучает заметно лучше, чем награда только за конечный результат.

Что получилось на бенчмарках

На SWE-bench-Verified RepoNavigator после RL показывает сильный скачок качества: по ключевым метрикам (Sample-F1 и IoU) 7B-версия обходит бейзлайны на 14B, 14B — конкурентов на 32B, а 32B в ряде сравнений выглядит лучше закрытых моделей.

Отдельно проверяют обобщение на SWE-bench-Pro (датасет опубликован позже релиза Qwen2.5, что снижает риск утечки). Картина сохраняется: подход устойчив, а RL снова помогает.

Интересное наблюдение — чем больше разрешено шагов с вызовами jump, тем стабильнее растёт качество и до RL, и после него.

Почему один инструмент иногда сильнее набора инструментов

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

Объяснение приземлённое. Во‑первых, цепочки вызовов ломаются вероятностно: если каждый вызов успешен с вероятностью p, то несколько шагов подряд быстро снижают общую надёжность. Во‑вторых, jump естественным образом ограничивает «область доступа»: агент движется по реальным зависимостям и путям исполнения, а не сканирует весь репозиторий. Это повышает шанс пересечься с тем самым кусочком кода, который и нужен.

Что это меняет

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