Почему я против извлечения данных в Claude Code только через grep? Оно просто сжигает слишком много токенов
AI-ассистенты для кодинга стремительно набирают популярность. Всего за последние два года такие инструменты, как Cursor, Claude Code, Gemini CLI и Qwen Code, превратились из диковинок в повседневных помощников для миллионов разработчиков. Но за этим быстрым взлётом скрывается назревающая борьба вокруг чего-то обманчиво простого: как AI-ассистент для кодинга должен на самом деле искать контекст в вашей кодовой базе?
Сейчас есть два подхода:
RAG на основе векторного поиска (семантическое извлечение).
Поиск по ключевым словам с помощью grep (буквальное сопоставление строк).
Claude Code и Gemini выбрали второй вариант. На самом деле инженер Claude открыто признал на Hacker News, что Claude Code вообще не использует RAG. Вместо этого он просто прогоняет grep по вашему репозиторию построчно (то, что они называют “agentic search”) — никакой семантики, никакой структуры, только сырое сопоставление строк.
Это откровение раскололо сообщество:
Сторонники защищают простоту grep. Он быстрый, точный и — что важнее всего — предсказуемый. В программировании, утверждают они, точность решает всё, а современные embeddings всё ещё слишком размыты, чтобы им доверять.
Критики считают grep тупиковым путём. Он заваливает вас нерелевантными совпадениями, сжигает токены и тормозит рабочий процесс. Без семантического понимания это всё равно что просить ваш AI отлаживать код с завязанными глазами.
Обе стороны по-своему правы. И после создания и тестирования собственного решения я могу сказать следующее: подход RAG на основе векторного поиска меняет правила игры. Он не только делает поиск значительно быстрее и точнее, но и сокращает использование токенов на 40% или больше. (Перейдите к части Claude Context, чтобы увидеть мой подход)
Так почему же grep настолько ограничивает? И как векторный поиск может на практике давать лучшие результаты? Давайте разберёмся.
Что не так с поиском по коду в Claude Code, основанным только на grep?
Я столкнулся с этой проблемой при отладке сложной ошибки. Claude Code запускал grep-запросы по всему моему репозиторию, вываливая на меня гигантские куски нерелевантного текста. Через минуту я всё ещё не нашёл нужный файл. Пять минут спустя у меня наконец были нужные 10 строк — но они были похоронены в 500 строках шума.
Это не единичный случай. Быстрый просмотр issues Claude Code на GitHub показывает множество разочарованных разработчиков, которые упираются в ту же стену:
issue1: https://github.com/anthropics/claude-code/issues/1315
issue2: https://github.com/anthropics/claude-code/issues/4556
Разочарование сообщества сводится к трём болевым точкам:
Раздувание токенов. Каждый вывод grep забрасывает в LLM огромные объёмы нерелевантного кода, увеличивая расходы, которые ужасно масштабируются с размером репозитория.
Налог на время. Вы вынуждены ждать, пока AI играет в двадцать вопросов с вашей кодовой базой, убивая концентрацию и поток.
Нулевой контекст. Grep сопоставляет буквальные строки. У него нет понимания смысла или связей, поэтому вы фактически ищете вслепую.
Вот почему эта дискуссия важна: grep — это не просто “старая школа”, он активно тормозит программирование с помощью AI.
Claude Code против Cursor: почему у последнего лучше контекст кода
Когда речь идёт о контексте кода, Cursor справился лучше. С первого дня Cursor сделал ставку на индексацию кодовой базы: разбивать ваш репозиторий на осмысленные фрагменты, преобразовывать эти фрагменты в векторы и семантически извлекать их всякий раз, когда AI нужен контекст. Это классический Retrieval-Augmented Generation (RAG), применённый к коду, и результаты говорят сами за себя: более точный контекст, меньше потраченных впустую токенов и более быстрое извлечение.
Claude Code, напротив, сделал ставку на простоту. Никаких индексов, никаких эмбеддингов — только grep. Это означает, что каждый поиск — это буквальное сопоставление строк, без понимания структуры или семантики. В теории это быстро, но на практике разработчикам часто приходится просеивать стога нерелевантных совпадений, прежде чем найти ту самую иголку, которая им действительно нужна.
| Claude Code | Cursor | |
|---|---|---|
| Точность поиска | Показывает только точные совпадения — пропускает всё, что названо иначе. | Находит семантически релевантный код, даже когда ключевые слова не совпадают точно. |
| Эффективность | Grep выгружает в модель огромные фрагменты кода, повышая затраты на токены. | Более мелкие фрагменты с более высоким сигналом снижают нагрузку по токенам на 30–40%. |
| Масштабируемость | Каждый раз заново прогоняет grep по репозиторию, что замедляется по мере роста проектов. | Индексирует один раз, затем извлекает данные в масштабе с минимальной задержкой. |
| Философия | Оставаться минималистичным — без дополнительной инфраструктуры. | Индексировать всё, извлекать умно. |
Так почему Claude (или Gemini, или Cline) не последовал примеру Cursor? Причины отчасти технические, отчасти культурные. Векторный поиск нетривиален — нужно решить задачи разбиения на фрагменты, инкрементальных обновлений и крупномасштабного индексирования. Но что ещё важнее, Claude Code построен вокруг минимализма: никаких серверов, никаких индексов, только чистый CLI. Эмбеддинги и векторные БД не вписываются в эту философию дизайна.
Эта простота привлекательна, но она также ограничивает верхнюю планку того, что Claude Code может дать. Готовность Cursor инвестировать в настоящую инфраструктуру индексирования — причина, по которой сегодня он ощущается более мощным.
Claude Context: open-source проект для добавления семантического поиска по коду в Claude Code
Claude Code — сильный инструмент, но у него слабый контекст кода. Cursor решил это с помощью индексирования кодовой базы, но Cursor закрыт, привязан к подпискам и дорог для отдельных пользователей или небольших команд.
Именно этот пробел стал причиной, по которой мы начали создавать собственное open-source решение: Claude Context.
Claude Context — это open-source MCP-плагин, который добавляет семантический поиск по коду в Claude Code (и в любой другой AI-агент для программирования, который поддерживает MCP). Вместо brute-force поиска по репозиторию через grep он интегрирует векторные базы данных с embedding-моделями, чтобы давать LLM глубокий, точный контекст из всей вашей кодовой базы. Результат: более точное извлечение, меньше потерь токенов и гораздо лучший опыт для разработчика.
Вот как мы его построили:
Технологии, которые мы используем
🔌 Интерфейсный слой: MCP как универсальный коннектор
Мы хотели, чтобы это работало везде — не только в Claude. MCP (Model Context Protocol) действует как USB-стандарт для LLM, позволяя внешним инструментам подключаться бесшовно. Упаковав Claude Context как MCP-сервер, мы сделали так, что он работает не только с Claude Code, но и с Gemini CLI, Qwen Code, Cline и даже Cursor.
🗄️ Векторная база данных: Zilliz Cloud
В качестве основы мы выбрали Zilliz Cloud (полностью управляемый сервис, построенный на Milvus). Он высокопроизводительный, cloud-native, эластичный и разработан для AI-нагрузок вроде индексирования кодовой базы. Это означает извлечение с низкой задержкой, почти бесконечное масштабирование и надежность как скала.
🧩 Embedding-модели: гибкость по дизайнуУ разных команд разные потребности, поэтому Claude Context поддерживает несколько поставщиков эмбеддингов из коробки:
OpenAI embeddings — для стабильности и широкого распространения.
Voyage embeddings — для производительности, специализированной под код.
Ollama — для локальных развертываний с приоритетом приватности.
Дополнительные модели можно подключать по мере изменения требований.
💻 Выбор языка: TypeScript
Мы обсуждали Python против TypeScript. TypeScript победил — не только из-за совместимости на уровне приложения (плагины VSCode, веб-инструменты), но и потому, что Claude Code и Gemini CLI сами основаны на TypeScript. Это делает интеграцию бесшовной и сохраняет экосистему согласованной.
Архитектура системы
Claude Context следует чистому многоуровневому дизайну:
Основные модули выполняют тяжелую работу: разбор кода, разбиение на фрагменты, индексирование, поиск и синхронизацию.
Пользовательский интерфейс обрабатывает интеграции — MCP-серверы, плагины VSCode или другие адаптеры.
Такое разделение сохраняет основное ядро переиспользуемым в разных средах, позволяя интеграциям быстро развиваться по мере появления новых AI-ассистентов для программирования.
Реализация основных модулей
Основные модули формируют фундамент всей системы. Они абстрагируют векторные базы данных, модели эмбеддингов и другие компоненты в компонуемые модули, которые создают объект Context, позволяя использовать разные векторные базы данных и модели эмбеддингов для разных сценариев.
import { Context, MilvusVectorDatabase, OpenAIEmbedding } from '@zilliz/claude-context-core';
// Initialize embedding provider
const embedding = new OpenAIEmbedding(...);
// Initialize vector database
const vectorDatabase = new MilvusVectorDatabase(...);
// Create context instance
const context = new Context({embedding, vectorDatabase});
// Index your codebase with progress tracking
const stats = await context.indexCodebase('./your-project');
// Perform semantic search
const results = await context.semanticSearch('./your-project', 'vector database operations');
Решение ключевых технических задач
Создание Claude Context заключалось не только в соединении эмбеддингов и векторной БД. Настоящая работа состояла в решении сложных проблем, которые определяют успех или провал индексирования кода в масштабе. Вот как мы подошли к трем главным задачам:
Задача 1: Интеллектуальное разбиение кода на фрагменты
Код нельзя просто разделить по строкам или символам. Это создает беспорядочные, неполные фрагменты и лишает код логики, которая делает его понятным.
Мы решили это с помощью двух взаимодополняющих стратегий:
Разбиение на основе AST (основная стратегия)
Это подход по умолчанию, использующий парсеры tree-sitter для понимания синтаксической структуры кода и разделения по семантическим границам: функциям, классам, методам. Это обеспечивает:
Синтаксическую полноту — никаких обрезанных функций или сломанных объявлений.
Логическую связность — связанная логика остается вместе для более качественного семантического поиска.
Поддержку нескольких языков — работает с JS, Python, Java, Go и другими через грамматики tree-sitter.
Разбиение текста LangChain (резервная стратегия)
Для языков, которые AST не может разобрать, или когда разбор завершается неудачей, RecursiveCharacterTextSplitter от LangChain предоставляет надежный запасной вариант.
// Use recursive character splitting to maintain code structure
const splitter = RecursiveCharacterTextSplitter.fromLanguage(language, {
chunkSize: 1000,
chunkOverlap: 200,
});
Он менее «интеллектуален», чем AST, но очень надежен — гарантируя, что разработчики никогда не останутся без решения. Вместе эти две стратегии балансируют семантическую насыщенность с универсальной применимостью.
Задача 2: Эффективная обработка изменений кода
Управление изменениями кода представляет собой одну из самых больших задач в системах индексирования кода. Повторное индексирование целых проектов из-за незначительных изменений файлов было бы совершенно непрактичным.
Чтобы решить эту проблему, мы создали механизм синхронизации на основе дерева Меркла.
Деревья Меркла: основа обнаружения изменений
Деревья Меркла создают иерархическую систему «отпечатков», где у каждого файла есть собственный хеш-отпечаток, у папок — отпечатки на основе их содержимого, и все завершается уникальным отпечатком корневого узла для всей кодовой базы.
При изменении содержимого файла хеш-отпечатки каскадно поднимаются вверх через каждый слой к корневому узлу. Это обеспечивает быстрое обнаружение изменений путем сравнения хеш-отпечатков послойно от корня вниз, быстро выявляя и локализуя модификации файлов без полной переиндексации проекта.
Система выполняет проверки синхронизации рукопожатия каждые 5 минут, используя оптимизированный трехфазный процесс:
Фаза 1: Молниеносное обнаружение вычисляет корневой хеш Merkle всего кодовой базы и сравнивает его с предыдущим снимком. Идентичные корневые хеши означают, что изменений не произошло — система пропускает всю обработку за миллисекунды.
Фаза 2: Точное сравнение запускается, когда корневые хеши различаются, выполняя детальный анализ на уровне файлов, чтобы точно определить, какие файлы были добавлены, удалены или изменены.
Фаза 3: Инкрементальные обновления пересчитывает векторы только для измененных файлов и соответствующим образом обновляет векторную базу данных, максимально повышая эффективность.
Управление локальными снимками
Все состояние синхронизации сохраняется локально в директории пользователя ~/.context/merkle/. Каждая кодовая база поддерживает собственный независимый файл снимка, содержащий таблицы хешей файлов и сериализованные данные дерева Merkle, что обеспечивает точное восстановление состояния даже после перезапуска программы.
Такая архитектура дает очевидные преимущества: большинство проверок завершается за миллисекунды, когда изменений нет, только действительно измененные файлы запускают повторную обработку (избегая огромных вычислительных потерь), а восстановление состояния безупречно работает между сеансами программы.
С точки зрения пользовательского опыта изменение одной функции запускает переиндексацию только этого файла, а не всего проекта, что значительно повышает эффективность разработки.
Задача 3: Проектирование интерфейса MCP
Даже самый умный движок индексации бесполезен без удобного интерфейса для разработчиков. MCP был очевидным выбором, но он создал уникальные трудности:
🔹 Проектирование инструментов: сохраняйте простоту
Модуль MCP служит пользовательским интерфейсом, делая пользовательский опыт главным приоритетом.
Проектирование инструментов начинается с абстрагирования стандартных операций индексации и поиска кодовой базы в два основных инструмента: index_codebase для индексации кодовых баз и search_code для поиска по коду.
Это поднимает важный вопрос: какие дополнительные инструменты необходимы?
Количество инструментов требует тщательного баланса — слишком много инструментов создают когнитивную нагрузку и усложняют выбор инструментов LLM, тогда как слишком малое количество может упустить важную функциональность.
Движение от реальных сценариев использования в обратном направлении помогает ответить на этот вопрос.
Решение проблем фоновой обработки
Индексация больших кодовых баз может занимать значительное время. Наивный подход с синхронным ожиданием завершения заставляет пользователей ждать несколько минут, что просто неприемлемо. Асинхронная фоновая обработка становится необходимой, но MCP изначально не поддерживает этот паттерн.
8.png
Наш MCP-сервер запускает фоновый процесс внутри MCP-сервера для обработки индексации, сразу возвращая пользователям сообщения о запуске и позволяя им продолжать работу.
9.png
Это создает новую проблему: как пользователям отслеживать прогресс индексации?
Специальный инструмент для запроса прогресса или статуса индексации элегантно решает эту задачу. Фоновый процесс индексации асинхронно кеширует информацию о прогрессе, позволяя пользователям в любое время проверять процент выполнения, статус успеха или условия сбоя. Кроме того, инструмент ручной очистки индекса обрабатывает ситуации, когда пользователям нужно сбросить неточные индексы или перезапустить процесс индексации.
Итоговый дизайн инструментов:
index_codebase - Индексировать кодовую базу
search_code - Искать код
get_indexing_status - Запросить статус индексации
clear_index - Очистить индекс
Четыре инструмента, которые обеспечивают идеальный баланс между простотой и функциональностью.
🔹 Управление переменными окружения
Управление переменными окружения часто остается без внимания, несмотря на то что оно существенно влияет на пользовательский опыт. Требование отдельной настройки API-ключей для каждого MCP-клиента вынуждало бы пользователей настраивать учетные данные несколько раз при переключении между Claude Code и Gemini CLI.
Подход с глобальной конфигурацией устраняет это неудобство, создавая файл ~/.context/.env в домашнем каталоге пользователя:
# ~/.context/.env
OPENAI_API_KEY=your-api-key-here
MILVUS_TOKEN=your-milvus-token
Этот подход дает очевидные преимущества: пользователи настраивают один раз и используют везде во всех MCP-клиентах, все конфигурации централизуются в одном месте для удобного обслуживания, а чувствительные API-ключи не распределяются по множеству конфигурационных файлов.
Мы также реализуем трехуровневую иерархию приоритетов: переменные окружения процесса имеют наивысший приоритет, глобальные конфигурационные файлы — средний приоритет, а значения по умолчанию служат резервным вариантом.
Такая архитектура обеспечивает огромную гибкость: разработчики могут использовать переменные окружения для временных переопределений при тестировании, production-среды могут передавать чувствительные конфигурации через системные переменные окружения для повышенной безопасности, а пользователи настраивают все один раз, чтобы бесшовно работать в Claude Code, Gemini CLI и других инструментах.
На этом этапе базовая архитектура MCP-сервера завершена: от парсинга кода и векторного хранения до интеллектуального поиска и управления конфигурацией. Каждый компонент был тщательно спроектирован и оптимизирован, чтобы создать систему, которая одновременно мощная и удобная для пользователя.
Практическое тестирование
Так как же Claude Context на самом деле работает на практике? Я протестировал его на том же самом сценарии поиска бага, который изначально меня так разочаровал.
Для установки потребовалась всего одна команда перед запуском Claude Code:
claude mcp add claude-context -e OPENAI_API_KEY=your-openai-api-key -e MILVUS_TOKEN=your-zilliz-cloud-api-key -- npx @zilliz/claude-context-mcp@latest
После того как моя кодовая база была проиндексирована, я дал Claude Code то же описание бага, которое ранее отправило его в пятиминутную бесплодную погоню на grep. На этот раз через MCP-вызовы claude-context он мгновенно указал точный файл и номер строки, вместе с объяснением проблемы.
Разница была не едва заметной — это были небо и земля.
И дело было не только в поиске багов. С интегрированным Claude Context Claude Code стабильно выдавал более качественные результаты в следующих задачах:
Решение issues
Рефакторинг кода
Обнаружение дублирующегося кода
Комплексное тестирование
Прирост производительности виден и в цифрах. В параллельном тестировании:
Использование токенов сократилось более чем на 40% без какой-либо потери полноты поиска.
Это напрямую означает более низкие расходы на API и более быстрые ответы.
В качестве альтернативы, при том же бюджете Claude Context обеспечивал гораздо более точные результаты поиска.
Мы сделали Claude Context open-source на GitHub, и он уже получил 2.6K+ звезд. Спасибо всем за вашу поддержку и лайки.
Вы можете попробовать сами:
Подробные бенчмарки и методология тестирования доступны в репозитории — мы будем рады вашим отзывам.
Взгляд в будущее
То, что началось с разочарования в grep в Claude Code, выросло в надежное решение: Claude Context — open-source MCP-плагин, который приносит семантический поиск на базе векторов в Claude Code и другие ассистенты для программирования. Посыл прост: разработчикам не нужно мириться с неэффективными AI-инструментами. С RAG и векторным поиском вы можете быстрее отлаживать код, сократить расходы на токены на 40% и наконец получить AI-помощь, которая действительно понимает вашу кодовую базу.
И это не ограничивается Claude Code. Поскольку Claude Context построен на открытых стандартах, тот же подход беспрепятственно работает с Gemini CLI, Qwen Code, Cursor, Cline и другими. Больше никакой привязки к компромиссам поставщиков, которые ставят простоту выше производительности.
Мы будем рады, если вы станете частью этого будущего:
Попробуйте Claude Context: он имеет открытый исходный код и полностью бесплатен
Внесите вклад в его развитие
Или создайте собственное решение с использованием Claude Context
👉 Поделитесь отзывами, задайте вопросы или получите помощь, присоединившись к нашему сообществу Discord.
Читать далее
Demystifying the Milvus Sizing Tool
Explore how to use the Sizing Tool to select the optimal configuration for your Milvus deployment.
Balancing Precision and Performance: How Zilliz Cloud's New Parameters Help You Optimize Vector Search
Optimize vector search with Zilliz Cloud’s level and recall features to tune accuracy, balance performance, and power AI applications.
Introducing DeepSearcher: A Local Open Source Deep Research
In contrast to OpenAI’s Deep Research, this example ran locally, using only open-source models and tools like Milvus and LangChain.