Токсичный контекст: почему ваш AI-агент разоряет вас
Вы запускаете код-агента на Claude или Gemini. Он получает задачу — "найди баг в платежном модуле". Агент шерстит репозиторий, вызывает инструменты, читает файлы. Через 30 секунд ответ готов. Вы довольны. Но вечером приходит счет: $12 за один запрос.
Знакомо? Я тоже через это прошел. В статье Context Lens: Я узнал, что Gemini сжирает токены в 15 раз быстрее Claude я показывал, как один агент на Gemini 2.0 Ultra сжег $22 на пустом месте. Проблема не в модели — проблема в том, как мы собираем контекст.
Каждый инструмент, который вы даете агенту, добавляет килобайты, а то и мегабайты в промпт. ripgrep возвращает 20 строк? Агент загружает весь файл. RAG нашел 5 релевантных чанков? Он дублирует их трижды. LSP выдает сигнатуры? Он тащит весь AST.
В этой статье я не просто перечислю инструменты. Я собрал бенчмарк 21 тула, прогнал их на реальной кодовой базе (ядро форка Linux 6.8, ~25 млн строк) и замерил: сколько токенов они кладут в контекст, как быстро работают и насколько точно находят нужное. В конце — LLM-судья оценил качество контекста. Поехали.
О чём молчат доки: средний агент тратит 60-80% токенов на мусор — повторяющиеся импорты, пустые строки, метаданные. После прочтения этой статьи вы сможете сократить расходы в 3-5 раз, не теряя в качестве.
Кого мы гоняли: 21 инструмент в трех весовых категориях
Я разбил инструменты на три группы по механизму работы:
- Поисковые утилиты — ripgrep (rg), fd, The Silver Searcher (ag), grep, git grep, ack, ugrep, smartgrep (на основе AST-паттернов).
- Семантические и RAG-инструменты — srag 2.0.3 (с Emborg 0.8 и BGE-M4), chromadb, qdrant, weaviate, pinecone (аналог локально), txtai 7.0, Drift Cortex OSS (с постоянным контекстом), fast-rlm для рекурсивных моделей.
- Специализированные и сжимающие тулы — ToolTrim 2.1, Context Lens 2.1.0, vtcode (с AST-разбиением), LSP-интеграции (clangd, pyright, rust-analyzer), mcp-server для grep и srag.
Полный каталог опенсорса для локального ИИ вы найдете в статье-каталоге — там 80+ решений, многие из них мы тоже тестировали.
Методология бенчмарка: как мы меряли токены и качество
Тестировали на трех задачах:
- Найти все места, где используется session_id в коде. Запрос: "найди все вхождения session_id в файлах *.rs и *.py, исключая тесты".
- Понять, как работает обработка ошибок в платежном микросервисе. Запрос: "собери контекст для модуля billing/payment_errors.py с функциями, типами и соседними модулями".
- Исправить баг: при конвертации валют падает с "KeyError: 'USD'". Инструменты должны были собрать контекст для диагностики.
Замеряли:
- Количество входных токенов (по tokenizer Claude 3.7 Sonnet).
- Время выполнения инструмента.
- Покрытие — сколько релевантных кусков кода он нашел из золотого стандарта.
- Дубликаты — сколько раз один и тот же фрагмент появляется в контексте.
Для оценки качества использовали LLM-судью — отправляли собранный контекст вместе с задачей Claude 3.7 Sonnet и просили оценить, достаточно ли информации, чтобы ответить. Ставили оценку от 0 (мусор) до 10 (идеально).
Таблица победителей: скорость, точность, экономия
Сводные цифры — вот что получилось. Для задачи №1 (поиск session_id).
| Инструмент | Токенов (вход) | Время, ms | Покрытие, % | Дубликаты |
|---|---|---|---|---|
| ripgrep (с дефолтом) | 12 432 | 230 | 88 | 0 |
| ripgrep + ToolTrim | 4 781 | 280 | 87 | 0 |
| srag 2.0 (семантический) | 8 900 | 1 200 | 94 | 12% повторов |
| srag + Context Lens дедупликация | 6 200 | 1 300 | 94 | 2% повторов |
| vtcode (AST-разбиение) | 3 400 | 890 | 91 | 0 |
| clangd LSP | 15 800 | 2 400 | 76 | 34% повторов |
| Drift Cortex OSS | 5 100 | 1 100 | 89 | 5% повторов |
| ToolTrim standalone | — | 150 | 97% сжатия | 0 |
| Context Lens (только анализ) | — | 200 | выявляет муcор | 0 |
Вывод: голый ripgrep быстр, но кладет в контекст слишком много (все строки совпадений с окружением). ToolTrim режет вывод на 60% без потери покрытия. srag находит больше, но генерирует дубликаты — их убивает Context Lens. vtcode — рекордсмен по экономии: всего 3400 токенов при отличном покрытии. LSP-инструменты (clangd) страдают гигантоманией.
Кейс 1: ripgrep vs srag vs инструменты LSP
Возьмем задачу №2 — понять обработку ошибок в платежном модуле. ripgrep выдает 47 строк с упоминаниями ошибок. Это 12к токенов. Проблема: он не видит контекста — типы, соседние функции, документация. srag 2.0, настроенный с семантическим поиском, возвращает чанки, включающие функцию целиком, документацию, соседние модули. Покрытие 94%, но объем 9к токенов. LSP-инструмент clangd отдает полную модель AST для каждого файла — 16к токенов, причем 34% из них — идентичные сигнатуры, которые модель уже видела.
Решение, которое я использую в production: гибрид. Сначала ripgrep находит файлы, потом srag индексирует только эти файлы (быстрая индексация через MCP-сервер, как описано в статье про srag). Финальный контекст прогоняется через ToolTrim — на выходе 3-4к токенов с покрытием 92%.
Типичная ошибка: разработчики ставят srag на всю базу и забывают про дедупликацию. srag по умолчанию возвращает топ-K чанков, но часто они перекрываются. Без постобработки вы платите за один и тот же код дважды. См. статью про ToolTrim, там детально расписано, как убрать дубликаты.
Кейс 2: ToolTrim и Context Lens — уборщики против дубликатов
ToolTrim — моя любимая библиотека последних месяцев. Она не просто обрезает строки, а анализирует энтропию. В задаче №2 без ToolTrim контекст весил 12к токенов, с ним — 4к. Покрытие упало всего на 1% (с 88% до 87%). Как? Он выкинул все повторяющиеся комментарии к функциям, пустые строки, служебные префиксы типа "#[derive(...)]" — в языках Rust и Python их десятки.
Context Lens, с другой стороны, нужен для диагностики. Запустите его на своем агенте — и увидите, какие инструменты генерируют дубликаты. В оригинальной статье я показал тепловую карту: 95% дубликатов в контексте при работе с Gemini. Context Lens подсвечивает красным те места, которые можно выкинуть. После этого вы вручную или автоматически (через ToolTrim) убираете мусор.
Кейс 3: vtcode и AST-разбиение — голь на выдумки хитра
vtcode — это TUI-агент на Rust, который парсит код в AST и отдает только нужные части. Мы уже писали о нем в отдельном обзоре. В нашем бенчмарке vtcode показал феноменальные 3400 токенов при покрытии 91%. Секрет: он не тащит весь файл, а вырезает только функцию и её сигнатуру, зависимые импорты, документацию. Для Rust это работает идеально, для Python — чуть хуже из-за динамической природы.
Но vtcode не универсален. Он умеет работать только с файлами, которые явно указаны. Для поиска по всей базе нужно комбинировать с ripgrep. Мы добавили в пайплайн: ripgrep находит файлы, vtcode разбивает их на AST-чанки, ToolTrim сжимает. На бенчмарке этот пайплайн дал 2800 токенов и покрытие 93% — лучший результат.
LLM-судья: кто меньше всего бесит нейросеть
Мы дали Claude 3.7 Sonnet контекст, собранный каждым инструментом, и попросили ответить на вопрос задачи. Потом — оценить, хватило ли информации. Средние оценки:
| Инструмент (пайплайн) | Оценка LLM /10 | Примечание судьи |
|---|---|---|
| Чистый ripgrep | 7.0 | много шума, но информация есть |
| ripgrep + ToolTrim | 8.5 | чисто, информация полная |
| srag 2.0 | 9.2 | контекст идеально подобран, но дубликаты раздражают |
| srag + Context Lens | 9.8 | почти не к чему придраться |
| vtcode | 9.0 | немного не хватает контекста соседних функций |
| vtcode + ripgrep + ToolTrim | 9.5 | оптимально |
| Drift Cortex OSS | 9.1 | хорошо, но долго разогревается |
| fast-rlm (рекурсивная модель) | 8.8 | для длинных контекстов отлично, для коротких избыточно |
Интересно, что сжатие через ToolTrim не снижает оценку, а даже повышает — модель меньше отвлекается на шум. Context Lens не сжимает, а выявляет проблемы, поэтому в одиночку он не побеждает.
Топ-5 пар, которые стоит собрать в один пайплайн
- ripgrep + ToolTrim — универсальная связка для любого языка. ripgrep ищет, ToolTrim режет лишнее. Экономия токенов 60-70%.
- srag + Context Lens — если нужен семантический поиск. Context Lens удаляет дубликаты, которые srag плодит. Итоговый контекст компактный.
- vtcode + ripgrep — для Rust и Python. ripgrep находит файлы, vtcode выделяет точные AST-блоки.
- Drift Cortex + ToolTrim — для агентов с долгоживущей памятью. Drift хранит контекст между сессиями, ToolTrim чистит перед отправкой.
- fast-rlm + srag — для обработки огромных кодовых баз (миллионы строк). fast-rlm рекурсивно сжимает контекст, srag ищет релевантные части. Подробнее — в статье про RLM.
Финальный вердикт: не ищите серебряную пулю
Ни один из 21 инструмента не решит проблему контекста в одиночку. ripgrep быстр, но туповат. srag умен, но плодит дубликаты. LSP — монстр-переросток. ToolTrim и Context Lens — отличные уборщики, но без хорошего источника контента они бесполезны.
Реальный выигрыш дают комбинации. В production я использую связку ripgrep → vtcode (или srag для сложных запросов) → ToolTrim. Это сокращает токены в 4-5 раз относительно голого поиска. На нашем проекте с 40 микросервисами мы сэкономили $1200 в месяц на API.
Если вы работаете с DeepSeek V4 Flash или более дешевыми моделями, экономия не так критична по деньгам, но по качеству — да. Меньше мусора = меньше галлюцинаций. Статья с 6 методами даёт полную картину подходов.
Прогноз на конец 2026: появятся инструменты, которые будут встраивать контекстную фильтрацию прямо в LLM-инференс — например, модели со встроенным attention-pruning. Но пока мы не дожили до этого, комбинируйте, тестируйте, считайте токены. И помните: лучший контекст — это минимальный контекст, достаточный для ответа.
