JetBrains, 시맨틱 코드 검색을 위한 RAG 파이프라인 구축: 파싱, 청킹, 벡터화

JetBrains가 시맨틱 코드 검색 플랫폼인 Air Context 구축에 관한 개발 일지 첫 번째 편을 공개했습니다. 이 플랫폼은 LLM 에이전트에게 "grep이 우연히 찾아내는 결과가 아니라 실제 저장소에서 가져온 정확하고 인용 가능한 근거"를 제공하는 RAG 파이프라인입니다. Adam Malek과 Ashot Kazaryan이 작성한 1부에서는 파싱, 청킹, 벡터화를 다룹니다.

grep이 아닌 시맨틱 검색이 필요한 이유

이 글에서는 키워드 검색과 grep이 실패하는 이유는 에이전트가 정확한 텍스트를 미리 알고 있어야 하기 때문이라고 주장합니다. 구체적인 예로 "세션 토큰이 갱신되는 위치를 찾는 에이전트는 코드에 친절하게 'refresh'라는 단어가 포함되어 있을 것이라고 기대할 수 없다"는 점을 듭니다. 추상적인 도메인을 추론하려면 에이전트는 의미로 검색해야 합니다. RAG는 소스 코드를 의미를 포착하는 방식으로 인덱싱한 다음, 에이전트가 자유 텍스트 검색을 통해 필요할 때 관련 조각을 검색할 수 있게 합니다.

파싱과 청킹

파싱/청킹은 전처리 단계이며 JetBrains는 이를 "흔히 간과되는 부분"이라고 말합니다. 프로덕션 저장소에는 각각 수백 또는 수천 줄에 달하는 수천 개의 파일이 포함되어 있고, 에이전트는 "왕성한 작성자"로서 코드베이스를 더욱 부풀립니다. 파일에는 관련성이 다양한 여러 클래스, 필드, 메서드가 포함될 수 있습니다.

글에서 지적하는 잘못된 접근 방식은 다음과 같습니다:

• 전체 파일 임베딩 — 파일을 임베딩 모델에 넣을 수 있다 해도 검색은 전체 파일을 반환하므로 특정 함수, 심볼, 스니펫을 찾는다는 목표가 무너집니다.
• 줄 단위 임베딩 — 개별 줄은 "주변 맥락 없이는 의미가 거의 없습니다." 일반적인 함수 이름이나 주석은 "임베딩할 가치가 없으며 잘못된 검색 결과를 낳고", 하찮은 미세 결과로 에이전트를 과부하시킵니다.

목표는 적절히 범위가 정해진 단위입니다. 에이전트의 탐색 워크플로는 대부분 특정 함수, 심볼, 코드 스니펫을 찾는 데 관련되므로 청크 경계는 이러한 단위와 일치해야 합니다(글 표현대로 "파싱과 청킹의 정교한 AST").

다음 내용

이 글은 시리즈의 1부입니다. 저자들은 전처리부터 저장 및 에이전트 통합까지 각 단계를 다루고, 그들이 겪은 "잘못된 방향"도 포함할 것이라고 말합니다. 이 글은 벡터화 단계의 세부 사항을 설명하기 전에 문장 중간에서 끝나므로, 청크가 임베딩 표현으로 변환되는 방식에 대한 후속 편이 예상됩니다.

누구를 위한 글인가

대규모 코드베이스에서 코딩 에이전트를 위한 검색을 구축하는 개발자, 또는 코드 RAG를 위한 청킹 전략을 평가하는 모든 사람을 위한 글입니다.