Проблема контекстного бюджета
Кодовые AI-агенты (coding agents) сталкиваются с критическим ограничением: контекстное окно быстро заполняется. Большинство токенов уходит на этап извлечения информации (retrieval). Существует два основных подхода к поиску релевантного кода:
- Лексический поиск (grep): Универсален, работает мгновенно, не требует настройки. Однако он «шумный» — не различает определения функций, вызовы и комментарии, возвращая много лишнего текста.
- Семантический поиск (LSP): Использует Language Server Protocol. Обеспечивает точность и типизацию, но требует запущенного сервера с индексацией и платит за каждый запрос к символу (round-trip).
Главный инсайт исследования
В индустрии повсеместно утверждается, что LSP более эффективен по количеству токенов. Однако авторы статьи arXiv:2608.13568 отмечают, что это утверждение почти нигде не измеряется. Они разработали методологию для изоляции разницы в потреблении токенов между LSP и grep при равных условиях задачи агента.
Сравнительные характеристики методов
Исследование выделяет ключевые различия в подходах, которые влияют на архитектуру агента:
| Критерий | Лексический поиск (grep) | Семантический поиск (LSP) |
|---|---|---|
| Точность | Низкая (шумный вывод) | Высокая (типизированные данные) |
| Скорость | Мгновенная | Зависит от индекса и сети |
| Настройка | Zero-setup | Требуется запущенный сервер |
| Стоимость токенов | Высокая (много лишнего контекста) | Переменная (зависит от глубины запроса) |
Почему это важно?
Результаты предварительного исследования показывают, что слепое переключение на LSP не всегда гарантирует экономию токенов. Для разработчиков AI-агентов это означает необходимость тщательного профилирования: в некоторых сценариях «шумный» grep может оказаться дешевле или быстрее, чем сложный семантический запрос, особенно если стоимость round-trip к LSP высока. Статья предлагает новый стандарт для оценки эффективности retrieval-механизмов в LLM-приложениях.
Источник: arXiv cs.CL ↗