Building a RAG Pipeline for Semantic Code Search: A Developer Diary and Field Notes
The JetBrains Blog · 软件开发
Part 2: Storage, Search, and Agent Tooling In this blog series, we aim to share some of the lessons we learned over the past six months as we built and rolled out Air Context , a production-grade RAG system for code search. In the first post of the series , we covered chunking, parsing, and vectorization. Turning code into vectors, however, represents only part of the journey. In this post, we’ll tackle the next problems that must be solved for any serious production-grade RAG system: how to store millions of vectors so that the index keeps up with Git, and how to retrieve the right vectors in milliseconds. Storage Once we have the code parsed, chunked, and turned into vectors, our next question is where to put them. A real-world codebase can produce millions of vectors. To compound the problem, codebases are not static. Not only do they change often and exist in dozens of branches at once, but the agent expects an answer in milliseconds, filtered down to the right repository, the right path, and only the files that the user is allowed to see. All this requires a special storage layer that efficiently handles the search operations under the given constraints. At the center of this storage layer sits the vector index. Vector search requires finding the vectors closest to the one representing the query. Comparing a query against a million vectors one by one is far too slow, so in practice we use approximate nearest-neighbor (ANN) structures such as HNSW or IVF. These skip most of the comparisons and return results that are very close to the best match, but are not guaranteed to be the best match. That speed comes with trade-offs when it comes to how many of the truly relevant results are actually returned (also known as recall), how much memory the index needs, how well it copes with a constant stream of inserts and deletes, and whether it can respect filters at all. On top of that, any healthy codebase must support multiple incremental index updates as commits land.