Обновить

Какой тул лучше собирает контекст для AI-агента? Сравниваем 21 подход от ripgrep до RAG и LSP

Время на прочтение8 мин
Охват и читатели8.9K
Всего голосов 9: ↑9 и ↓0+9
Комментарии5

Комментарии 5

Я пробовал разные варианты repo context: grep/ripgrep, индексы, tree-sitter, LSP-подобные подходы. Устойчиво лучше дефолтного Claude Code у меня не получилось.Мне кажется, тут важно сначала разделить тип задач. Если это работа по папке с документами/knowledge base — тогда логичнее строить RAG/индекс и оценивать качество поиска. Если это coding agent в репозитории — он работает иначе: ищет, сужает контекст, читает постепенно и может запускать сабагентов.Почти любой нормальный agent harness уже позволяет попросить модель запустить сабагента, который отдельно сделает ресёрч по коду дешёвой моделью. Тогда дорогая модель не тратит токены на блуждание по файлам, а получает уже сжатый результат. Это выглядит практичнее, чем вручную жонглировать “сейчас включить rg, сейчас Serena, сейчас LSP”.Поэтому если grep-like конфиг сжигает 800k–1.2M токенов, для меня это скорее вопрос к harness/policy агента: лимиты чтения, stopping condition, планирование поиска, сабагенты. Не факт, что проблема именно в grep как инструменте.

Поэтому по умолчанию я рекомендую серену

Спасибо за статью и вывод, касающийся Serena MCP.

В качестве эксперимента тестирую LightRAG, индексируя репозитории и статьи базы знаний, чтобы построить граф зависимостей по коду.

Однако, здесь я ставлю несколько иную задачу: я хочу использовать LightRAG через MCP для большего круга задач. Например, в CI pipeline мы можем понять, что удаление/изменение какого-то endpoint может сломать фронтенд.

Ну те по сути вы хотите ast code graph бахнуть и видеть зависимости на лету?

Да, примерно так. Раз-два в сутки обходить инкрементальным индексом 100+ репозиториев (мое решение здесь: https://github.com/ArkadiyShuvaev/ligth-rag-ingestion-pipeline) и использовать LightRAG MCP для разных задач, требующих принятия решения по кодовой базе.

Для непосредственного программирования, как оказалось, это не совсем удобно. Я сделал skill для Claude Code и в skill явно попросил использовать LightRAG MCP.

Так как все 100+ репозиториев у меня были локально, Claude Code ни в какую не хотел использовать LightRAG MCP, он использовал grep. Когда я напрямую спросил у него о причинах, он мне ответил, что при наличии всех репозиториев локально на диске ему гораздо удобнее парсить все "налету", чем лезть в LightRAG MCP.

Я допускаю, что я то-то сделал неправильно. Но, в моем конкретном случае, кроме непосредственной помощи при разработке, я пытаюсь найти применение этому подходу и в задачах CI pipeline.

Зарегистрируйтесь на Хабре, чтобы оставить комментарий

Публикации