RAG 如何找到正确的上下文

本文中的所有数字均通过真实运行生成，涉及超过 100,000 份文档。无任何虚构数据。使用 python3 demo.py 即可复现所有过程。

完整演示代码、测试及运行日志：github.com/vikasgupta4190/rag-vector-search-demo

📬 喜欢这种深度解析吗？ 我撰写 ByteBuilder 周报，深入剖析开发者常用工具背后的设计决策。免费订阅，无垃圾邮件，每周一封。立即订阅 →

TL;DR

• 精确向量搜索每次查询需对语料库中 100% 的内容进行评分。实测：100,000 文档耗时 8.858 毫秒。
• IVF 索引仅探测最近的 4 个质心列表。实测：0.725 毫秒，提速 12.2 倍。
• 代价：recall@10 下降至 0.883，仅对语料库中 6.71% 的内容进行评分。
• 核心调节参数为 nlist 与 nprobe。我们的 7×4 调优实验明确展示了每次调整的代价。

1. 为何检索是 RAG 的难点

检索增强生成的成败取决于一个问题：给定查询，哪些文档值得进入上下文窗口？

对每个文档与每个查询进行评分能完美回答此问题，但其成本随语料库规模线性增长。我们的示例让这一成本具体化：

• 100,000 份文档，418 维 TF-IDF 向量，余弦相似度。
• 精确查询 top-10：8.858 毫秒，评分覆盖 100.0% 语料库。
• 质量验证：98.3% 的精确 top-10 结果归属于查询的主题聚类。

诚实声明：我们使用 TF-IDF 而非神经网络嵌入模型。每个权重可解释，每个距离计算精确，其揭示的结构（98.3% 聚类纯度）与生产环境嵌入模型利用的结构一致。

2. 精确基线：真相与成本

精确 kNN 是召回率的基准。其 recall@10 定义为 1.000，因为所有近似索引均以精确 top-10 为标准进行评估。

scores = docs @ q          # 全部 100000 份文档，每个查询
top10  = argpartition(scores)[:10]

100k 文档耗时 8.858 毫秒。1000 万文档约需 1 秒。十亿级文档？不可能。规模化检索必须跳过部分计算。

3. IVF 技巧：先分类，后探测

生产环境向量数据库通过倒排文件索引（IVF）跳过计算：

• 在向量空间上训练 k 个质心（示例中使用 64 个）。
• 将每份文档归档至最近质心所属分区。
• 查询时仅探测 nprobe 个最近列表（示例中使用 4 个）。
• 在这些列表内进行精确重评分。

我们的索引采用与真实引擎相同的 CSR 布局，将列表存储在连续数组中。实测结果（100,000 文档）：

• 索引构建：294.7 毫秒（一次性成本）。
• 候选文档评分：覆盖语料库 6.71%。
• 查询延迟：0.725 毫秒，较精确搜索快 12.2 倍。
• 相对精确搜索的 recall@10：0.883。
• top-10 聚类纯度：0.992。

最后这个数字值得关注：93.3% 的语料库从未被访问，召回率仅下降 11.7 个百分点。

4. 参数调优与实测

所有向量数据库均暴露相同的两个参数。我们遍历了全部 28 种组合：

• 最佳组合：nlist 32, nprobe 8 → 召回率 1.000。
• 最差组合：nlist 192, nprobe 1 → 召回率 0.429。
• 增加探测数：召回率提升，延迟增加。
• 增加质心数：列表规模减小，单次探测工作量降低。

延迟随召回率同步上升。nprobe 8 与 nlist 32 组合可获得完美召回率，但也需评分更多列表。没有最优配置，只有经测量曲线选定的平衡点。

5. 检索器的记录

未记录的检索器无法优化。演示程序记录完整链条：

• DOCUMENT 链接其 EMBEDDING 行，每个嵌入器版本一行。
• INDEX_VERSION 记录 nlist、nprobe 及实测 build_ms。
• QUERY_LOG 存储每个查询的延迟及服务它的索引版本。
• HIT 存储每个查询的排名结果。

本文所有结论均可追溯至这些数据行，最终指向 workspace/runs 目录。

6. 故障模式（上线前必读）

• 索引过时。 新文档在重建前不可见。实测构建耗时 294.7 毫秒；请合理规划。
• 召回率崩溃。 nlist 192 下 nprobe 1 实测仅 0.429。错误参数会导致静默失败。
• 延迟误导。 小规模数据集上精确搜索看似即时，生产规模下可能崩溃。
• 缺少重排序。 探测获取候选集；精确重评分保障质量。
• 无查询日志。 缺少 QUERY_LOG 则无优化依据。
• 嵌入漂移。 更换嵌入器会导致索引孤立。需重新嵌入所有文档。

7. 生产环境规模规划（设计参考，非实测）

• 向量数据库通常在百万级语料库下将 nlist 默认设为 1024 左右。
• 典型 nprobe 运行值：每次查询探测 8 至 64 个列表。
• 查询预算通常要求 p50 延迟低于 10 毫秒。
• 重排序阶段需对 20 至 200 个候选文档进行二次评分。

请将这些作为设计参考。引用前请实测您的技术栈。

8. 核心结论

• 精确搜索既是真相也是代价：100% 语料库评分耗时 8.858 毫秒。
• IVF 跳过 93.3% 的计算，保留 88.3% 的结果。
• nlist 与 nprobe 是经过测量的权衡，而非神秘参数：参见调优实验。
• 记录每个查询。无日志优化如同猜测。
• 对候选文档进行精确重排序。探测获取候选；评分捍卫质量。

数据来源与复现

• 完整演示代码、测试套件及归档运行日志：github.com/vikasgupta4190/rag-vector-search-demo
• 终端输出：screenshots/ 目录，由 render_evidence.py 重新生成。
• 图表：images/demo-*.png，由 render_charts.py 重新生成。
• 指标数据：metrics.json。

订阅 ByteBuilder，在 AI 领域保持领先