Как выжать максимум смысла из тысяч строк кода

LLM для кодинга уже умеют дополнять, объяснять и чинить код, но в реальных проектах им приходится читать тысячи строк. Большие окна контекста помогают, но бьют по времени и цене, а ещё парадоксально ухудшают точность: модель начинает теряться в деталях и упускает скрытые зависимости между файлами и функциями. Обычные текстовые компрессоры отбрасывают фразы и токены, не учитывая структуру кода. RAG по схожести ловит поверхностные совпадения и часто промахивается мимо неявных связей — например, где именно берутся параметры из конфигурации.

Идея: сжимаем, не ломая смысл

Авторы LongCodeZip предлагают простой, но точный рецепт: оставить в контексте только то, что действительно помогает ответить на текущий промт. Фреймворк training-free и не требует дообучения модели. Он работает в два шага. Сначала грубо отбирает функции и классы, которые сильнее всего снижают неопределённость модели относительно запроса. Затем внутри выбранных функций аккуратно режет код на смысловые блоки и оптимально раскладывает их в заданный бюджет токенов. Получается компактный, но информативный ввод: структура сохраняется, мусор исчезает.

Как это устроено изнутри

Что значит полезный фрагмент? Исследователи измеряют, насколько наличие куска кода уменьшает перплексию на тексте запроса — по сути, насколько проще модели предсказывать слова промта, когда она видит этот код. Это приближённая взаимная информация: чем больше падение перплексии, тем выше вклад фрагмента.

Дальше — два уровня компрессии.

• Грубый отбор. Репозиторий режется по границам функций и классов. Каждую часть ранжируют по условной перплексии относительно промта и берут верхние кандидаты под предварительный бюджет. Остальные заменяются короткими заглушками, чтобы не поломать общую структуру.

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

Что показали эксперименты

Тесты шли на трёх типах задач: автодополнение, суммаризация модулей и вопросы по репозиторию. Модели — как открытые (DeepSeek‑Coder‑6.7B, Qwen2.5‑Coder‑7B, Seed‑Coder‑8B), так и закрытые (GPT‑4o, Claude‑3.7‑Sonnet).

Главный итог: до 5.6× сжатия без падения качества, а порой и с ростом — шум уходит, сигнал остаётся. На автодополнении Qwen2.5‑Coder‑7B получил 57.55 ES и 32.40 EM при 4.3×, что выше RAG по функциям при меньшем бюджете. DeepSeek‑Coder‑6.7B на тех же данных стал лучше, чем без сжатия, при 5.3×. Seed‑Coder‑8B — максимум 5.6× с лучшим качеством среди методов. На RepoQA точность поднималась до 87–91 при 4.5–5.3×, включая закрытые модели. Суммаризация осталась на уровне без компрессии или слегка улучшилась при 1.7–3.5×.

По времени и стоимости выгода ощутимая. Пример для Qwen2.5‑Coder‑7B на автодополнении: вместо 15.7 секунд без сжатия генерация заняла 6.6 секунды после компрессии; затраты на входные токены снизились примерно на 77%. Сама компрессия — около 2.6 секунды и мало памяти. Её можно ускорить ещё сильнее, если выполнять на маленькой 0.5B‑модели: качество почти не проседает, а ресурсы экономятся.

Что важнее всего в дизайне

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

Где это пригодится на практике

• Автодополнение на уровне нескольких файлов, когда окно модели не вмещает весь проект.

• Ответы на вопросы в репозитории: найти нужную реализацию, проследить цепочку вызовов, не загружая всё подряд.

• Суммаризация больших модулей и подготовка контекста для ревью.

Интересно, что LongCodeZip не зависит от конкретной LLM и не требует обучения — его можно вставить перед любой моделью как прозрачный фильтр. Это ценно там, где модель закрытая или её нельзя дообучить.

Ограничения и что дальше

Оценка релевантности строится на перплексии, значит, требуется доступ к логитам. Впрочем, авторы показывают, что даже крохотная компрессорная модель справляется.

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

📜 Полная статья

💾 Код

***

Если вам интересна тема ИИ, подписывайтесь на мой Telegram‑канал — там я регулярно делюсь инсайтами по внедрению ИИ в бизнес, запуску ИИ-стартапов и объясняю, как работают все эти ИИ-чудеса.

Источник: habr.com