代码库RAG与跨仓库语义搜索
00:00
2026年每个严肃工程组织都运行理解语义的内部代码搜索：tree-sitter解析、函数/类级分块、混合搜索(稠密+BM25)、重排序、带引用的回答。构建处理2M行代码跨10个仓库的系统，在每次git push时存活增量重新索引。
问题
到2026年每个前沿编码代理都配备代码库检索层，因为上下文窗口本身不能解决跨仓库问题。Claude的1M token上下文有帮助；它不消除对排序检索的需求。朴素余弦搜索在生成代码、monorepo重复和罕见导入符号长尾上毒害结果。生产答案是AST感知分块上的混合（稠密+BM25）搜索加重排序器，由符号引用图支持。
你通过索引真实舰队——不是一个教程仓库——来学习这一点，并测量MRR@10、引用忠实度和增量新鲜度。失败模式是基础设施性的：100k文件monorepo、触及一半文件的push、需要跨四个仓库才能正确回答的查询。
核心架构
摄取管线
- 克隆与解析。 Git clone + tree-sitter解析为AST。
- 分块。 函数级和类级分块，保留符号边界。
- 嵌入。 稠密嵌入（代码模型）+ BM25稀疏索引。
- 符号图。 构建跨仓库引用图（谁导入谁）。
混合检索
稠密搜索捕获语义相似性；BM25捕获精确token匹配。生产系统两者都运行并合并结果。重排序器（bge-reranker-v2-gemma风格）对合并候选重新排序。
增量索引
每次git push触发增量重新索引：仅重新解析变更文件，更新受影响分块的嵌入，更新符号图。2M行代码库的完整重新索引需要小时；增量在秒级完成。
评估
MRR@10（前10结果中正确答案的倒数排名均值）、引用忠实度（回答是否正确归属源代码）、增量新鲜度（push后多久新代码出现在搜索结果中）。
关键术语
| 术语 | 常见说法 | 实际含义 |
|---|---|---|
| Hybrid search | ”混合搜索” | 稠密+BM25组合检索 |
| AST-aware chunking | ”AST感知分块” | 按语法结构而非固定长度切分代码 |
| Symbol graph | ”符号图” | 跨仓库导入/引用关系图 |
| MRR@10 | ”倒数排名均值” | 前10结果中正确答案排名的评估指标 |
| Incremental re-index | ”增量重新索引” | 仅更新变更文件的索引 |
延伸阅读
- Sourcegraph Amp — 企业代码搜索
- Cursor codebase answers — IDE集成代码搜索
- Augment enterprise graph — 代码知识图谱