JetBrains построила RAG-пайплайн для семантического поиска по коду

Building a RAG Pipeline for Semantic Code Search

JetBrains построила RAG-пайплайн для семантического поиска по коду

Инженеры JetBrains делятся опытом создания Air Context — RAG-системы, которая даёт LLM-агентам точные ссылки на код вместо результатов grep. В первой части цикла они рассказывают о парсинге и чанкинге с учётом структуры AST для девяти языков, оценке качества чанков с помощью LLM-судьи и векторизации, а также о компромиссах между размерностью эмбеддингов, точностью и стоимостью хранения.

Агент, ищущий, где обновляются сессионные токены, не может рассчитывать на то, что в коде услужливо встретится слово «refresh».
  1. keeda

    Думаю, что-то подобное станет ключом к улучшению качества кодирующих агентов. Очень распространённая проблема (возможно, самая большая), которую отмечают многие, — агенты часто порождают кучу дублирующегося и избыточного кода; множество абстракций, методов, классов, структур данных и т.д., обслуживающих незначительные вариации одной и той же цели... иногда в одном и том же файле!

    Моя теория: это из-за своего рода «туннельного зрения», которое возникает у этих моделей при выполнении конкретной задачи. Ведь инженеры, только пришедшие в компанию, делают то же самое, пока не освоятся и не поймут, что похожие проблемы уже решались где-то ещё.

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

    Мол, ты делаешь поиск по ключевым словам и изучаешь, если тебе нужна какая-то крупная функциональность, требующая значительной работы, или когда натыкаешься на абстракцию, кода которой нет в твоём репозитории, и хочешь узнать о ней побольше. Но когда ты в потоке и изобретаешь мелкие абстракции, вроде класса или утилитного метода, ты не обязательно вспоминаешь о поиске. Хуже того, даже если бы вспомнил, ты не смог бы эффективно искать, потому что что-то похожее может существовать с чуть другим именованием, терминологией или опечаткой, которую поиск по ключевым словам пропустит. Предсказуемо, в ск […]

  2. duhhhhh1212

    https://www.pangram.com/history/c901e80e-9cb7-46e4-bf10-7348...

    Не хочу говорить «не тратьте время», так как первая половина написана человеком. Вопрос к авторам: вы что, просто устали писать и сказали «да пошло оно, пусть LLM допишет остальное»? Или один из вас использовал LLM, чтобы написать вторую половину, а другой писал своими словами?

  3. simianwords

    Опять двадцать пять: индустрия в основном отказалась от RAG. На самом деле я почти не видел случаев, где grep работает не так же хорошо, как RAG.

Ещё за этот день

2026-10-04