Редакция 26 июля 2026 г.

PageRank против RAG: что реально работает, когда агенту не влезает весь репозиторий

Соло-разработчик, который подключает к проекту MCP-сервер для анализа кодовой базы или вручную урезает контекст агента, обычно смотрит на два показателя: сколько токенов сэкономили и насколько «точным» кажется ответ. В E2E-разборе на репозитории MSCodeBase Intelligence автор @mansio показывает: без метрики Hit@Gold эти цифры легко вводят в заблуждение — выигрывает не чистый PageRank, а гибрид с query-aware RAG.

Эксперимент: 406K токенов кода и бюджет ~70K для LLM

База — MSCodeBase Intelligence: 50K строк Python, 129 файлов, суммарно около 406K токенов (подсчёт через tiktoken, encoding cl100k_base). Для сравнения методов отбора контекста автор зафиксировал бюджет примерно 70K токенов — top 20% файлов, около 25 штук.

Методология построена вокруг Gold Standard: 50 тестовых запросов, у каждого вручную указан целевой файл. Ключевая метрика — Hit@Gold: попал ли отобранный контекст именно в тот файл, который отвечает на запрос. Это принципиально иной критерий, чем «keyword accuracy»: совпадение ключевых слов не гарантирует попадание в нужный модуль.

Сравнивались три подхода:

PageRank на графе зависимостей (NetworkX, Python AST) — пять плотностей: от random (0 рёбер) через import-only (110) до dense с вызовами функций (389 рёбер);
random baseline — случайный набор файлов в том же бюджете;
RAG на BM25 — query-aware отбор по пересечению терминов с файлами.

Для агентского пайплайна это прямой вопрос контекст-инжиниринга: какой механизм подсовывает модели релевантные файлы, когда весь кодбейз в окно не помещается.

Почему keyword accuracy обманывает агента

По keyword accuracy методы выглядели сильными — 80% на sparse-графе и 78% на dense. Реальный Hit@Gold при тех же условиях — 18% и 32% соответственно; автор признаёт, что ранние публикации опирались именно на эту ловушку.

Причина в том, что слова вроде search, error, lock, sql встречаются во многих файлах. Случайная выборка 25 файлов из 129 уже покрывает 76% запросов по ключевым словам, но даёт лишь 12% Hit@Gold. Отдельно проверили Smart Summary (~2K токенов сжатого обзора): 90% на 10 «лёгких» запросах и 26% на полном наборе из 50.

Для практики vibe-coding вывод простой: если инструмент или rule для агента отчитывается «точностью» без расшифровки метрики, высокий процент может означать лишь совпадение лексики, а не попадание в целевой файл.

Цифры: RAG держит 46%, PageRank растёт с плотностью графа

На sparse-графе (только imports, 110 рёбер):

Метод	Hit@Gold	SUFFICIENT	Avg Tokens
RAG (BM25)	46%	23/50	60,194
PageRank	18%	9/50	65,821
Random	12%	6/50	65,514

На dense-графе (imports + class refs + function calls, 389 рёбер):

Метод	Hit@Gold	SUFFICIENT	Avg Tokens
RAG (BM25)	46%	23/50	60,116
PageRank	32%	16/50	69,694
Random	12%	6/50	65,476

PageRank на dense даёт 32% Hit@Gold — это +14 п.п. над random (12%). На sparse разрыв меньше: 18% против 12% (+6 п.п.). RAG стабильно держит 46% на обеих плотностях и опережает PageRank dense на 14 п.п. (46% vs 32%).

По среднему числу токенов методы близки — порядка 60–70K; RAG чуть дешевле при лучшем Hit@Gold. Экономия токенов сама по себе не делает контекст полезным, если промах по целевому файлу.

Иллюстрация на запросе «where is DebounceBatch defined»:

RAG (BM25) находит rate_limiter.py по пересечению терминов;
PageRank тянет центральные хабы — engine.py, runtime_coordinator.py — и пропускает нужный файл.

Контраст в посте: PageRank — «карта автомагистралей», RAG — «GPS до конкретного адреса».

Плотность графа и коррекция старых тезисов

С ростом плотности графа корреляция Spearman ρ между рангом PageRank и размером файла растёт с 0,02 (import-only) до 0,39 (dense с вызовами функций). Hit@Gold у PageRank при этом идёт от 18% к 32% — центральность начинает лучше отражать структуру, но не догоняет query-aware отбор.

Автор пересматривает прежние заявления:

Прежнее утверждение	Что показал E2E
«Top 20% = −2% savings»	+72% savings (артефакт sparse graph)
«Smart Summary = 90% accuracy»	26% на 50 реальных запросах
«PageRank doesn't work»	32% Hit@Gold — работает умеренно
«PageRank beats RAG»	ложь: RAG 46%, PageRank 32%

Для настройки агентского контекста это сигнал не отбрасывать графовые методы, но и не заменять ими RAG.

Практика для AI code tools и MCP-контура

Выводы адресованы инструментам для работы с кодом; в том же проекте, где проводились замеры, упоминается MCP-сервер MSCodeBase Intelligence. Прямых ссылок на Cursor, Copilot или другие IDE в материале нет — речь о принципах отбора контекста, применимых к любому агенту с ограниченным окном.

Рекомендации из поста:

Использовать PageRank как prior — усиливать RAG, а не заменять его.
Строить плотный граф зависимостей: import-only слишком разрежен (18% → 32% Hit@Gold при densification).
Не путать экономию токенов с полезностью контекста.
Всегда включать random baseline и тестировать с Gold Standard целевых файлов.

Скрипты для воспроизведения лежат в experiments/ репозитория автора. Детали токенизации BM25 в посте не раскрыты — сравнение ограничено keyword overlap по файлам, без описания эмбеддингов и чанкинга.

В Related Work автор ссылается на Aider (symbol-level elision), CodeGraph (on-demand retrieval) и Codebase-Memory (83% quality vs 92% file-exploration) — как на соседние подходы индустрии, без собственных замеров в этом эксперименте.

Итог для соло-workflow: перед тем как доверять агенту урезанный контекст, проверьте не «сколько сэкономили», а попадаете ли в нужный файл — и закладывайте гибрид RAG + графовый prior, если строите MCP-слой над кодовой базой.

Источники

@mansio — I Measured PageRank Token Savings on a Real Codebase. Here Are the Honest Numbers. — Dev.to, 22 июля 2026; дата доступа: 22 июля 2026 (UTC).