上一课我们聊了怎么“编排”流程。今天我们要聊聊，怎么让 AI 的“知识来源”更准确。因为在复杂的项目里，简单的向量检索往往会搜出一堆干扰项。

1. 核心概览 (Core Overview)

在前面我们学了 RAG。但在工业界，仅仅靠“余弦相似度”去搜向量是不够的。我们需要 “多路检索 (Hybrid Search)” 和 “重排序 (Reranking)”。

2. 分段拆解 (Breakdown)

A. 多路检索：向量 + 关键词

• 痛点： 向量检索擅长“意思相近”，但处理“特定专有名词（比如一个特殊的类名 OrderX7_Handler）”时，效果不如传统的 Elasticsearch 关键词匹配。

• 架构方案： 同时从 向量数据库 和 ES/数据库 检索。然后把两边的结果合并。

B. 重排序 (Rerank)：精挑细选

• 逻辑： 检索出来的 Top 20 结果里，可能有一半是杂音。

• 做法： 使用一个专门的 Rerank 模型（如 BGE-Reranker）。它计算速度极快，不看向量，而是直接对比“问题”和“搜出来的片段”之间的相关性，重新打分。

• 价值： 经过 Rerank 后，你可以把最相关的 3 条放在最前面。这解决了 Day 4 提到的 “中间失踪 (Lost in the Middle)” 问题。

C. 查询转换 (Query Transformation)

• 技巧： 用户问得可能很含糊。

• 架构做法： 先让一个便宜的 LLM 把用户的问题重写一遍（生成 3 个不同维度的搜索关键词）。这叫 Multi-Query。

3. 最终总结 (Summary)

RAG 的质量决定了 Agent 的上限。 工业级 RAG 是一套组合拳：重写问题 -> 多路检索 -> 结果合并 -> 重排序 -> 喂给 LLM。这一套流程能让你的 AI 在 1GB 代码库里找东西的准确率提升 40% 以上。

测验
分层检索： 假设你的 Java 项目代码存在 GitHub，文档存在 Confluence。你会把它们存在同一个向量数据库里吗？检索时如何分配这两者的权重？

长短权衡： 如果用户问“帮我分析一下 OrderService 的核心逻辑”，而这个类有 2000 行。你的检索系统搜到了 5 个相关的片段，但散落在类的不同位置。你认为重排序模型应该优先选择“代码定义开头”还是“具体的业务逻辑处理块”？

实时性： 程序员每分钟都在改代码。你的 RAG 系统如何保证检索到的永远是 当前 Git 分支 的最新代码，而不是一小时前的旧版本？