JetBrains о построении RAG-конвейера для семантического поиска по коду: парсинг, разбиение на фрагменты, векторизация

JetBrains опубликовала первую часть дневника разработчика о создании Air Context — своей платформы семантического поиска по коду, RAG-пайплайна, который снабжает LLM-агентов «точными, цитируемыми доказательствами из реальных репозиториев, а не тем, что случайно выдаст grep». Авторы — Адам Малек и Ашот Казарян; в первой части рассматриваются парсинг, чанкинг и векторизация.

Почему семантический поиск, а не grep

В статье утверждается, что поиск по ключевым словам и grep не работают, потому что требуют от агента заранее знать точный текст. Конкретный пример: «агент, ищущий, где обновляются session-токены, не может рассчитывать на то, что в коде любезно окажется слово „refresh“». Чтобы рассуждать об абстрактных доменах, агенту нужен поиск по смыслу. RAG индексирует исходный код так, чтобы улавливать семантику, а затем позволяет агенту по запросу извлекать релевантные фрагменты через поиск по свободному тексту.

Парсинг и чанкинг

Парсинг/чанкинг — это этап предварительной обработки, и JetBrains называет его «часто упускаемым из виду». Продакшн-репозитории содержат тысячи файлов, каждый из которых занимает сотни или тысячи строк, а агенты ещё больше раздувают кодовые базы, будучи «плодовитыми авторами». Файлы могут содержать множество классов, полей и методов с разной степенью связанности.

Неправильные подходы, согласно статье:

• Эмбеддинг целого файла — даже если бы файл поместился в модель эмбеддингов, поиск вернул бы весь файл, что сводит на нет цель найти конкретную функцию, символ или фрагмент.
• Построчный эмбеддинг — отдельные строки «семантически незначимы без окружающего контекста». Общее имя функции или комментарий «не заслуживает эмбеддинга и приведёт к неверному результату поиска», перегружая агента незначащими микрорезультатами.

Цель — правильно ограниченные единицы: рабочий процесс исследования агента в основном связан с поиском конкретной функции, символа или фрагмента кода, поэтому границы чанков должны совпадать с этими единицами (в формулировке статьи — «тонкий AST парсинга и чанкинга»).

Что дальше

Это первая часть серии. Авторы говорят, что расскажут о каждом этапе — от предварительной обработки до хранения и интеграции с агентами, включая «неверные повороты», которые они совершили. Материал обрывается на полуслове, не успев подробно описать особенности этапа векторизации, так что стоит ожидать продолжения о том, как чанки преобразуются в представление эмбеддингов.

Для кого это

Для разработчиков, создающих retrieval для кодирующих агентов на больших кодовых базах, а также для всех, кто оценивает стратегии чанкинга для RAG по коду.