TL;DR
CQ2-CARE — способ собрать контекст для агента, который чинит баг в коде. Модель дважды независимо отвечает на вопрос «какие файлы надо менять», и в контекст идут только файлы, названные в обоих ответах. Они идут целиком и дословно. Сверху добавляются короткие куски кода из других файлов, которые нашёл обычный текстовый поиск (grep): определения и места вызова.
Главная находка: при одинаковом числе токенов править код лучше выходит из целых файлов, чем из «умно сжатого» контекста. Сжималки выкидывают токены, и в коде пропадает то f перед строкой, то кавычка. Модель пишет правку для строки, которой в реальном файле нет, и патч не применяется. Поиск по похожести на описание бага ошибается иначе. Он набивает контекст тестами, шаблонами и документацией, которые просто повторяют слова из баг-репорта. Нужного файла в контексте нет вообще, причём на четверти задач и более.
Метод простой, из трёх шагов. Сначала модель называет файлы (дважды, берём пересечение). Потом она просит до четырёх точечных поисков, а в контекст попадают целые файлы и найденные куски. В конце модель пишет патч. Компрессор не нужен, а пересечение двух ответов повышает надёжность выбора.
Схема метода
ШАГ 1: Список путей файлов репо + описание бага → модель 2-3 раза независимо
отвечает «какие файлы менять» → ранжированный список путей
ШАГ 2: Берём файлы, названные в ответах 1 И 2 (без тестов и доков).
Если пересечение пусто → берём ответ 0
ШАГ 3: Модель читает баг + выбранные файлы → просит ≤4 поиска
(определение, вызовы, строка) → ищем grep'ом, добавляем ≤2 куска на поиск
ШАГ 4: Контекст = выбранные файлы целиком + найденные куски → модель пишет патч
Шаги 1–3 — отдельные запросы, шаг 4 — финальный.
Пример применения
Задача: Интернет-магазин на Django. Ошибка: при промокоде и оплате через ЮKassa скидка считается дважды, и клиент платит на 500 ₽ меньше. Репозиторий большой, в окно целиком не влезает. Вы работаете в Cursor или в обычном чате и хотите, чтобы модель починила баг с первого раза.
Промпт (шаг 1, запустить дважды в двух новых чатах):
Ниже описание бага и список путей файлов репозитория.
Ответь: какие файлы нужно изменить, чтобы исправить баг?
Верни ранжированный список путей, максимум 5, без пояснений.
Тесты и документацию не включай.
При оплате заказа с промокодом через ЮKassa скидка применяется дважды:
в корзине и повторно при создании платежа. Клиент платит на 500 ₽ меньше,
чем должен. Воспроизводится только когда промокод процентный.
shop/cart/models.py
shop/cart/services.py
shop/promo/models.py
shop/promo/discounts.py
shop/payments/yookassa_client.py
shop/payments/views.py
shop/orders/services.py
shop/templates/cart.html
tests/test_cart.py
...
Дальше сравниваете два ответа, берёте файлы, которые есть в обоих, и вставляете их целиком во второй запрос. Туда же добавляете куски из найденных поисков (например, все вызовы apply_discount) и просите патч.
Результат: Каждый чат вернёт короткий ранжированный список из нескольких путей. Скорее всего, пересечение окажется маленьким: один-два файла (например, discounts.py и yookassa_client.py). Эти файлы вы вставляете полностью, без ... и выжимок. Модель выдаст правку, строки которой совпадают с вашим кодом, и она применится без ручной подгонки.
Почему это работает
Слабость. Правка кода — это цитата. Модель должна воспроизвести строки, которые меняет, символ в символ. Сжатие вырезает «малозначимые» токены, и в коде они значимы: префикс f, кавычка, отступ. Поиск по сходству промахивается по другой причине: он ищет текст, похожий на описание бага, а файл с исправлением часто совсем на него не похож. Контролируемый тест показал, что одно удаление 20% токенов из тех же правильных файлов стоит около 10 пунктов решённых задач.
Сильная сторона. Модель хорошо понимает, где в проекте живёт проблема, если ей показать список путей и описание. Это умение рассуждать, а не искать по словам. Она также неплохо выбирает, что дочитать (определение, вызовы).
Как метод это использует. Бюджет токенов тратится не на сжатие, а на выбор нескольких нужных файлов, которые показываются целиком. Два независимых ответа с пересечением фильтруют случайные ошибки: если файл назвали оба раза, скорее всего, он нужен. Авторы отмечают, что сила метода в выборе единицы (файл целиком), а не в схеме с двумя выборками. Один ответ, обрезанный до такого же числа файлов, работает почти так же.
Рычаги управления: - Число независимых ответов (2 → 1 или 3) → меньше запросов и дешевле или надёжнее выбор файлов. - Лимит файлов в ответе (5 → 3) → короче контекст, выше риск пропустить нужный. - Число поисков (≤4) и число файлов-«свидетелей» (до 8) → шире контекст вокруг правки. - Исключение тестов и доков из выбора → не забивает контекст шумом, который повторяет слова бага. - Формат правки (diff или search/replace) → при search/replace цитаты из сжатого контекста часто не находят уникального места в реальном файле.
Шаблон промпта
Метод — это конвейер из нескольких запросов. Сохраняю его структуру:
=== ЗАПРОС 1: ЛОКАЛИЗАЦИЯ (запусти 2 раза в разных чатах: L1 и L2) ===
Ниже описание бага и список путей репозитория.
Какие файлы нужно изменить, чтобы исправить баг?
Верни ранжированный список путей, максимум {макс_файлов}, без пояснений.
Не включай тесты и документацию.
{описание_бага}
{список_путей_через_перенос_строки}
=== ВЫБОР (делаешь ты) ===
Файлы = то, что названо И в L1, И в L2 (без тестов и доков).
Если пересечение пустое → возьми список из третьего запуска L0.
=== ЗАПРОС 2: ПЛАН ПОИСКОВ ===
Вот баг и файлы, которые, скорее всего, нужно править.
Что ещё тебе нужно увидеть, чтобы написать правку?
Запроси не более 4 поисков. Для каждого укажи тип
(определение / вызовы / строка) и точную строку для поиска.
{описание_бага}
{файлы_целиком_с_путями}
=== ПОИСК (делаешь ты: grep/поиск по проекту) ===
Для каждого поиска возьми не больше 2 новых файлов,
вырежи определение или окно вокруг совпадения.
Всего не больше {макс_файлов_доказательств} файлов.
=== ЗАПРОС 3: ПАТЧ ===
Исправь баг. Верни правку в формате unified diff.
Цитируй строки в точности как в файлах ниже.
{описание_бага}
{файлы_целиком_дословно}
{найденные_куски_с_путями_и_номерами_строк}
Подставляйте: {описание_бага} — текст из трекера или своими словами; {список_путей} — вывод git ls-files (при огромном репозитории оставьте пути, чьи слова встречаются в описании); {макс_файлов} — 3–5.
🚀 Быстрый старт — вставь в чат:
Вот шаблон CQ2-CARE для исправления бага через целые файлы. Адаптируй под мою задачу: [твоя задача].
Задавай вопросы, чтобы заполнить поля.
[вставить шаблон выше]
LLM спросит про описание бага, структуру репозитория и формат правок. Это нужно, чтобы корректно заполнить
Ограничения
⚠️ Один заход, а не агентный цикл: метод проверяли на схеме «собрали контекст → один патч». Живой агент (Claude Code, Cursor) исследует репозиторий сам, итерациями. Перенос вывода на такой режим авторы не проверяли.
⚠️ Только Python и баги из реальных репозиториев: результаты получены на задачах по исправлению issue в Python-проектах. Для других языков и других задач (рефакторинг, новые фичи) вывод не доказан.
⚠️ Нужно, чтобы файлов было мало: в среднем выбирается около двух файлов. Если для правки нужно менять десять модулей, целые файлы перестанут помещаться, и метод теряет преимущество. Огромные файлы приходится обрезать.
⚠️ Выигрыш против обученного ретривера почти нулевой: SweRank, обученная модель ранжирования функций, отстаёт всего на 0,7–1,7 пункта. Главное преимущество метода — перед привычными сжималками и поиском по чанкам.
⚠️ Потолок остаётся: даже если дать модели «золотые» файлы, у GPT результат выше ещё на 5,7 пункта. Выбор файлов моделью не идеален.
⚠️ Часть анализа сделана задним числом: главные тесты шли по заранее написанному плану, но анализ причин и ряд проверок добавили после результатов. Против одного из сжимателей (LLMLingua-2 на Claude) преимущество статистически слабое.
Как исследовали
Идея была простой: честно сравнить способы собрать контекст при одинаковом бюджете токенов. Команда взяла 300 свежих задач из SWE-rebench: по одной на репозиторий, с января 2025 по май 2026. Свежие задачи нужны, чтобы модели не могли знать ответ по памяти. Для каждой задачи метод CQ2-CARE собирал контекст, и его размер становился бюджетом для всех остальных. Против него выставили три компрессора (LLMLingua-2, LongLLMLingua, LongCodeZip), три ретривера (BM25 по чанкам и по файлам, плотный поиск), а позже ещё два обученных метода: SWE-Pruner и SweRank. Каждая модель писала один патч, и его проверяли тестами самого репозитория. Патч, который не применился, считался провалом.
Результат: с GPT-5.6 CQ2-CARE решил 43,7% задач, с Claude Opus 5 — 46,7%. Лучший компрессор отстаёт на 6,3 пункта, лучший ретривер на 9,3–12,7 пункта. Самое интересное — причины. Ретриверы сохраняют текст, но на четверти и более задач не показывают ни одного нужного файла. Компрессоры оставляют нужные файлы, но искажают текст. У LLMLingua-2 дословно сохраняется лишь около 17% строк, и патчи применяются заметно реже.
Чтобы отделить эти причины, авторы поставили контролируемые тесты. Они вырезали 20% токенов из собственных контекстов с теми же файлами: патчи стали применяться в 79% случаев вместо 98%, а решённых задач стало на 9,7 пункта меньше. Затем они заставили компрессоры резать те же файлы, что выбрал CQ2-CARE. Компрессор, который режет целыми строками, догнал метод. Вывод: проигрыш — это либо потерянные файлы, либо испорченный текст, и каждая из причин стоит отдельно. Удивило, что схема с двумя ответами не главная: один ответ, обрезанный до такого же числа файлов, почти так же хорош.
Адаптации и экстраполяции
🔧 Техника: правило в файл инструкций агента → целиком, не обрывками
Это моя адаптация, авторы эту формулировку не тестировали, она следует из их вывода о цитировании:
# CLAUDE.md
- Перед правкой файла читай его целиком, а не фрагменты и не выжимки.
- Цитируй изменяемые строки дословно, как они есть в файле.
- Не опирайся на пересказ кода с «...» или сокращениями: если видишь многоточие вместо кода, открой файл.
- Не ищи файл для правки только по совпадению слов с описанием бага: сначала назови 1–3 файла, которые должны измениться, потом открывай их.
🔧 Техника: не пересказывай код в чате
Когда вставляете код в чат, не сокращайте его «для экономии» (..., удалённые комментарии, урезанные строки). Лучше вставьте меньше файлов, но целиком. Это следует из контролируемого теста: потеря текста сама по себе стоит около 10 пунктов.
Ресурсы
- Работа: Skip the Compressor: Coding Agents Fix More Issues When They Pick Whole Files
- Авторы: Xiaocong Yang, Rishit Chatterjee, Himanshu Udupi, Vikram Ramavarapu, ChengXiang Zhai — University of Illinois Urbana-Champaign
- Упоминаемые данные и методы: SWE-rebench (Badertdinov et al., 2025), SWE-bench (Jimenez et al., 2024), LLMLingua-2, LongLLMLingua, LongCodeZip, SWE-Pruner, SweRank, CodeRankEmbed, self-consistency (Wang et al., 2023)