Журнал «Отинофф»
Схема работы RAG-инструмента ragforgit: индексация кода и задач, выборка контекста для AI-ассистента, снижение расхода токено

RAG для кода и таск-трекера: как снизить расход токенов

ИИ-инструменты 30 июня 2026 г.

Разработчик, работающий с AI-ассистентами, тратит до половины времени на ручной сбор контекста: какие файлы относятся к задаче, какие символы задействованы, какие PR уже были. Каждый раз это стоит денег — токены уходят на передачу одних и тех же данных.

Источник: Habr

Открытый репозиторий mimfort/rag_for_git предлагает третий путь: построить один раз индекс кодовой базы и таск-трекера, а затем отдавать AI-ассистенту только то, что нужно для конкретной задачи. Автоматически, без ручного копирования и без лишних токенов.

Прежде чем внедрять, стоит понять, что именно даёт этот подход, где он экономит, а где — создаёт новые расходы.

Что именно появилось: открытый плагин для Claude Code

Автор репозитория mimfort/rag_for_git опубликовал не просто код, а готовый скилл reviewer_solve-task для Claude Code (и совместимого OpenCode). Скилл — это не поиск по файлам и не семантическая база данных. Это система, которая:

  • строит векторный индекс кода (ParadeDB на PostgreSQL с pgvector и pg_search);
  • строит граф вызовов (Neo4j с узлами Symbol и рёбрами CALLS и IMPLEMENTS);
  • индексирует задачи из трекера через server-side ETL без участия LLM;
  • при каждом запуске solve-task собирает релевантный контекст и передаёт его модели.

Инфраструктура поднимается в Docker двумя контейнерами. Индекс строится один раз командой reviewer index /path/to/repo --ref main --repo owner/name, после чего работает инкрементально — синхронизируются только изменившиеся файлы.

Как это меняет стоимость работы с AI-ассистентом

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

В схеме solve-task контекст собирается один раз при индексации. При каждом запросе модель получает только релевантные чанки — те, которые Retriever отобрал по гибридному поиску (ANN по векторам + BM25 по тексту, слияние через RRF). Это снижает количество токенов на запрос.

Отдельный выигрыш — индексация задач из трекера. Скилл reviewer_sync-tasks вызывает один MCP-тул sync_board, и сервер сам ходит на доску по REST, нормализует задачи и индексирует батчем через Voyage. LLM не перечисляет доску, не передаёт текст задач — всё делает Python на стороне reviewer-mcp. Стоимость bulk-синка — O(1) токенов Claude независимо от размера доски.

Где этот подход применим, а где — нет

Инструмент рассчитан на команды, которые уже используют Claude Code и хотят автоматизировать сбор контекста для задач, затрагивающих несколько модулей. Он подходит для:

  • проектов с историей PR и связанными задачами;
  • кодовых баз, где важно не сломать существующие паттерны;
  • команд, готовых поднять Docker и настроить ParadeDB с Neo4j.

Он не подходит для:

  • изолированных задач в одном файле — там ручной контекст дешевле;
  • проектов без таск-трекера или с трекером без REST API;
  • команд, которые не готовы администрировать ещё две инфраструктуры.

Что проверить до внедрения: чек-лист на неделю

Прежде чем разворачивать решение в рабочем проекте, стоит проверить пять вещей.

  1. Совместимость с вашим AI-ассистентом. Инструмент завязан на Claude Code. Если команда использует другую модель, потребуется адаптация скилла.
  2. Доступность ParadeDB и Neo4j. Оба контейнера должны работать в вашей инфраструктуре. Убедитесь, что Docker-окружение настроено и есть ресурсы для хранения индекса.
  3. Стоимость Voyage API. Эмбеддинги для кода и задач считаются через Voyage. При большом количестве задач или частой переиндексации стоимость может быть значительной. Оцените объём до внедрения.
  4. Инкрементальность индекса. Инструмент сверяет SHA индекса с HEAD ветки и досинхронизирует только изменившиеся файлы. Проверьте, что этот механизм работает на вашем репозитории — особенно если в проекте много веток.
  5. Надёжность источника. Единственный публичный источник — статья на Habr и GitHub-репозиторий. Репозиторий может быть нестабильным или не обновляться. Перед внедрением стоит форкнуть и протестировать на тестовом проекте.

Что может пойти не так: скрытые риски

Помимо очевидных ограничений (зависимость от Claude Code, необходимость Docker), есть три риска, которые стоит учитывать.

Риск 1: стоимость эмбеддингов при масштабировании. Если в трекере тысячи задач, bulk-синк через Voyage может оказаться дороже, чем ручной сбор контекста. Инструмент экономит токены Claude, но создаёт расходы на эмбеддинги.

Риск 2: привязка к одному AI-ассистенту. Если команда решит перейти на другую модель, скилл reviewer_solve-task придётся переписывать. Это не plug-and-play решение.

Риск 3: сложность отладки. Гибридный поиск (ANN + BM25 + RRF) даёт результаты, которые сложно проверить вручную. Если Retriever отдаёт нерелевантный контекст, модель будет работать с неверными данными, а разработчик не сразу это заметит.

Что можно сделать на этой неделе

Не внедряйте инструмент в боевой проект сразу. Сделайте три шага.

  1. Форкните репозиторий mimfort/rag_for_git и разверните на тестовом проекте с 5-10 файлами и 2-3 задачами в трекере.
  2. Запустите solve-task для задачи, которая затрагивает два модуля. Сравните результат с ручным сбором контекста — по времени, качеству и стоимости токенов.
  3. Оцените стоимость Voyage API для вашего объёма задач. Если она превышает экономию на токенах Claude, инструмент не даст выгоды.

Только после этих проверок принимайте решение о внедрении в рабочий процесс.

Дополнительные рекомендации по внедрению

Чтобы минимизировать риски при переходе на автоматизированный сбор контекста, стоит начать с пилотного проекта. Выберите одну команду и один репозиторий, где задачи часто затрагивают несколько модулей. Замерьте текущие затраты на токены при ручном сборе контекста и сравните с затратами после внедрения RAG. Это даст объективные данные для принятия решения о масштабировании.

Также полезно настроить мониторинг стоимости Voyage API с самого начала. Установите лимиты на количество запросов к эмбеддингам в день и неделю, чтобы избежать неожиданных расходов. Если стоимость Voyage окажется высокой, рассмотрите альтернативы — например, использование локальных моделей эмбеддингов, которые не требуют оплаты за каждый запрос.

Источники

Генерация изображения

  • Модель: flux-schnell
  • Провайдер: replicate

Темы журнала

Что почитать дальше

Теги

Андрей Отинов

Рекомендуем