Как Cursor индексирует код: разбор RAG-пайплайна для понимания codebase

Почему Cursor понимает ваш код, а вы - нет

Вы открываете проект на 200 тысяч строк. Нужно найти, где вызывается processPayment(). Гуглите по файлам, grep'аете, тратите полчаса. Cursor делает это за три секунды. Спрашиваете "как работает аутентификация в этом микросервисе?" - получаете внятное объяснение с ссылками на конкретные файлы. Магия? Нет, просто грамотно собранный RAG-пайплайн, который превращает вашу кодобазу в семантическую поисковую систему.

Но под капотом - не магия, а инженерные решения, каждое из которых можно разобрать на винтики. И некоторые из этих винтиков в 2026 году выглядят совсем не так, как в 2024.

RAG для кода: почему это сложнее, чем для документов

Retrieval-Augmented Generation для текста - уже отработанная технология. Берешь текст, режешь на куски, превращаешь в вектора, ищешь похожее. С кодом так не работает.

Попробуйте разбить функцию на две части случайным образом. Смысл теряется. Код имеет жесткую структуру: импорты, классы, функции, вызовы. Разорвите связь - и нейросеть не поймет, что userService.validate() относится к class UserService из другого файла.

Cursor решает эту проблему трехслойным подходом к chunking'у, о котором мало кто пишет. И да, он сильно эволюционировал с момента первого релиза.

1Сбор и фильтрация: что на самом деле индексирует Cursor

Откройте проект в Cursor. Зайдите в настройки. Там нет галочки "индексировать все". Потому что индексировать node_modules, .git и бинарники - глупо. Но как он отличает полезный код от мусора?

Пайплайн начинается с walker'а по файловой системе с умной фильтрацией:

• По расширению: .py, .js, .ts, .java, .go, .rs - все основные языки. Конфиги вроде .json, .yaml тоже, но с другим обработчиком.
• По размеру: файлы больше 2 МБ часто пропускаются (это эмпирика, но работает).
• По игнор-листам: используются стандартные .gitignore, .cursorignore (да, есть такой), плюс внутренние эвристики.

Важный нюанс: Cursor не индексирует все подряд при старте. Он делает это лениво - когда вы начинаете работать с файлом или делаете первый запрос. Это экономит ресурсы и время.

2Chunking: как резать код, чтобы не убить смысл

Вот сердце системы. Три уровня декомпозиции:

Почему именно так? Потому что нейросеть (даже GPT-4o 2026 года выпуска) имеет ограниченное контекстное окно. Если отправить весь UserService.ts на 500 строк, модель "забудет" начало к концу. А если резать вслепую - потеряются связи между методами.

Cursor использует парсеры для каждого языка, чтобы понимать границы структур. Это дорого по CPU, но необходимо. Кстати, если ваш проект на Elixir или другом нишевом языке, могут быть проблемы - стандартные парсеры не всегда справляются. В таких случаях помогают кастомные решения вроде гибридного RAG для Elixir.

# Пример того, как НЕ НАДО делать chunking кода:
def process_data(data):
    # 50 строк кода
    result = step1(data)
    # ... еще код
    return result

def step1(data):
    # 30 строк кода
    return transformed_data

# Если разрезать здесь между функциями - связь step1 и process_data теряется.
# Cursor сохраняет эту связь через метаданные чанков.

3Embedding: в какие вектора превращается ваш код

Здесь Cursor до недавнего времени использовал OpenAI embeddings. Но с 2025 года появилась гибридная модель: для публичных репозиториев - облачные эмбеддинги (text-embedding-3-large или ее преемник), для приватных - локальные модели типа BGE-M3 или новее.

Почему? Приватность. Ваш код не должен утекать в облако без спроса. Но локальные эмбеддинги хуже понимают семантику кода. Компромисс: Cursor индексирует метаданные (имена функций, классов, типы) локально, а для семантического поиска по логике может использовать облако, если вы разрешили.

Каждый чанк превращается не в один вектор, а в несколько:

• Текстовый эмбеддинг: сам код как текст.
• Структурный эмбеддинг: AST в сжатом виде (путь в дереве, тип узла).
• Мета-эмбеддинг: имена сущностей, типы, комментарии.

При поиске Cursor комбинирует эти три вектора с разными весами. Спросили "найди функцию валидации email" - больше вес мета-эмбеддинга. Спросили "как работает этот алгоритм" - больше вес текстового.

4Хранение и поиск: не просто векторная БД

Ранние версии Cursor хранили вектора в SQLite с расширением векторов. Сейчас - специализированная in-memory векторная БД с persistence на диск. Причем индексы строятся при запуске IDE и обновляются инкрементально при изменении файлов.

Поиск работает так:

1. Ваш вопрос "где используется JWT токен?" превращается в вектор (или несколько).
2. Быстрый k-NN поиск по векторному индексу возвращает топ-10 чанков.
3. Критически важный шаг: reranking с помощью кросс-энкодера. Это маленькая модель, которая переоценивает релевантность каждого чанка. Без reranking'а вы получаете мусор в 30% случаев.
4. Чанки фильтруются по релевантности, объединяются (если из одного файла), и отправляются в LLM как контекст.

Почему reranking так важен? Потому что векторный поиск по коду часто находит что-то "похожее по словам", но не по смыслу. Reranker учится на ваших предыдущих запросах и правках - если вы часто игнорируете результаты из файла utils/old/legacy.py, система понижает его вес.

5Генерация: какой LLM отвечает и как его кормят

Cursor по умолчанию использует GPT-4o (или актуальную на 2026 год модель от OpenAI). Но есть тонкость: он не просто "вот контекст, ответь на вопрос".

Промпт инжиниринг здесь - отдельная наука. Cursor использует шаблоны, которые:

• Заставляют LLM ссылаться на конкретные файлы и строки.
• Ограничивают галлюцинации (но не полностью - см. ниже).
• Просят структурировать ответ: объяснение, пример кода, возможные проблемы.

Эти промпты постоянно обновляются. Если вы хотите сделать что-то подобное для своего агента, изучите готовые шаблоны для RAG - они спасают от многих ошибок.

Контекст упаковывается умно: сначала самые релевантные чанки, потом дополнительные, но так, чтобы не превысить лимит токенов. Если чанков слишком много - используется extractive summarization: нейросеть сама решает, какие части чанка самые важные, и оставляет только их.

Где ломается пайплайн: ошибки, которые все делают

Идеального RAG для кода не существует. Cursor падает в нескольких сценариях:

Самая большая проблема, о которой молчат разработчики Cursor: контекстное окно. Даже если у LLM окно в 128K токенов, отправлять 100 чанков - дорого и медленно. Cursor жертвует полнотой в угоду скорости. Поэтому на вопрос "опиши всю архитектуру" вы получите поверхностный ответ, а не детальный разбор.

А что дальше? Эволюция RAG для кода в 2026-2027

Тренды, которые уже видны:

• Graph RAG: вместо чанков - граф зависимостей между функциями, классами, файлами. Поиск идет не по тексту, а по связям. Roadmap RAG 2026 предсказывает массовый переход на графы к середине года.
• Multi-modal embeddings: код + комментарии + документация + даже скриншоты интерфейса, если речь о фронтенде.
• Personalized retrieval: система учится на том, какие ответы вы принимаете, какие правите, какие игнорируете. Ваш персональный coding style становится частью индекса.

Cursor, скорее всего, пойдет по пути интеграции с MCP (Model Context Protocol) серверами. Уже сейчас можно подключить сторонние инструменты для анализа кода (партнерская ссылка), которые дополнят встроенный RAG. Это разумно - не пытаться делать все самому, а стать платформой.

И последнее: не верьте хайпу. Тот самый твит про "миллион строк кода" оказался браузерным трюком. Cursor не волшебная таблетка. Он всего лишь инструмент, который ускоряет рутину. Понимать код все равно придется вам. Но теперь - в 3 раза быстрее.