RAG Retriever 工作机制详解

回答与解析

Retriever的核心机制

输入输出

• 输入：用户Query（可能经过改写/扩展）
• 输出：Top-K相关文档片段（doc_id + 文本 + 相似度分数）

两大检索范式

关键技术组件

向量数据库与索引

• 存储：FAISS、Milvus、Pinecone 存储文档Embedding
• 索引结构：HNSW（图索引，快但内存大）、IVF-PQ（磁盘友好，略慢）
• 量化：FP16/INT8降低存储，平衡精度与速度

与Generator的协同

Query → [Retriever] → Top-K Docs → [Prompt拼接] → Generator → Answer

关键协作点

• 上下文融合：检索结果按相关性排序，截断至上下文窗口
• 置信度过滤：低分文档丢弃，避免引入噪声
• 迭代优化：Advanced RAG中加入重排序（Rerank）或查询改写，提升召回精度

质量提升本质：Generator从" parametric memory "（参数知识）扩展到" non-parametric memory "（外部知识），减少幻觉，实现可溯源回答。

学习建议

建议先掌握RAG整体架构，再重点理解Retriever的两种主流技术（如BM25与DPR），并通过开源项目（如LangChain）动手实践检索流程。

口语版讲法(约4分钟)

• 一句话点题：RAG本质上在解决模型的时效性和幻觉问题
• 输入输出与两种检索范式：稀疏和稠密各适合什么场景，落地常混用
• 关键技术组件：向量数据库与索引结构，以及工程上的取舍
• 与生成器的协同：上下文融合、置信度过滤、重排，以及背后的原理
• 落地风险与收尾：常见失败场景和我的工程师判断

这道题其实是在问，当大模型的知识储备不够用或者太旧的时候，我们怎么给它外挂一个知识库。说白了，RAG 的检索模块就是那个从外部知识库里捞相关信息的管道。

先看输入输出。输入是用户的 query，但注意，这个 query 可能会被改写或扩展，比如拆成子问题、加上历史上下文。输出呢，是 top-K 个文档片段，每个片段带着 doc id、文本和相似度分数。这个分数很关键，后面生成模块会用。

检索本身分两大流派。先说稀疏检索，典型的就是 BM25 或者 TF-IDF，本质上做词袋加统计权重，靠关键词精确匹配。它的好处是可解释性强，对高频词、专有名词特别准。比如客服场景里用户问'订单号 12345 退款到哪了'，这种精确匹配 BM25 一把就能捞到。但它的问题是语义理解弱，'苹果手机'和'iPhone'可能就匹配不上。

反过来稠密检索，像 DPR 或者 Contriever，用双塔编码器把 query 和文档都映射成语义向量，然后算余弦相似度。它能理解近义词和上下文，泛化能力强。比如用户说'怎么退单'，它能关联到'取消订单流程'。但它的缺点是依赖 GPU 推理，而且对生僻词、数字、ID 类的匹配很弱。

所以真正落地的时候，我很少只用一种。更常见的做法是 Hybrid Search，把 BM25 的精确匹配和稠密检索的语义理解结合起来，用加权融合或者 RRF 算法合并结果。这样既能捞到订单号，又能理解意图。

再聊技术组件。稠密检索得把文档转成向量存起来，这就用到 Vector Database 了，像 Faiss、Milvus 这些。索引结构我重点说两个：HNSW 和 IVF-PQ。HNSW 是图索引，检索快，延迟低，但吃内存，适合几百万级别的场景。IVF-PQ 呢，先用 IVF 做粗聚类缩小范围，再用 Product Quantization 压缩向量，对磁盘更友好，但召回率会掉一点。上线前我会做压力测试，看延迟和召回率的 trade-off。如果 QPS 要求高，我会倾向 HNSW；如果数据量上亿又不想堆内存，那就 IVF-PQ。

现在说它怎么跟生成器配合。流程很简单：query 进检索器，捞出 top-K 文档，然后拼到 prompt 里喂给生成器。但这里有几个坑。先看上下文窗口限制，文档太多太长会截断，所以得按相关性排序，截到窗口能装下为止。然后看置信度过滤，相似度低于某个阈值的文档直接扔掉，不然噪声会让模型胡说八道。另外还要看 Rerank，就是加一个 Cross-Encoder 对检索结果重新排序，因为双塔的分数不一定准，重排能显著提升 top 文档的质量。

本质上看，RAG 让模型从纯参数记忆变成了 参数加非参数记忆，也就是把知识外挂到数据库里。这样回答就能溯源，幻觉也少很多。

不过这里有个有意思的点，就是检索结果的质量并不完全由召回率决定。如果检索回来的文档本身就有冲突或者错误，生成器反而会更困惑。比如企业 SOP 文档里新老版本同时存在，模型可能选错。所以我会在生成前加一步 Faithfulness 校验，或者用 Self-RAG 让模型自己学会反思。

最后说落地风险。前提是文档质量要干净，切分策略要合理。如果文档是扫描件 OCR 出来的，或者切分把一句话拦腰截断，召回率会崩。常见失败场景是用户问一个很模糊的问题，比如'怎么投诉'，检索器可能捞出一堆不相关的文档。这时候我会在 query 侧做改写，或者加一层意图识别。所以我的判断是，RAG 不是银弹，它更适合知识密集型、答案可溯源的场景，而对需要强推理或者多步交互的场景，我更倾向用 Agentic RAG 或者 ReAct 模式。

关键一句:检索结果冲突时，生成器会更困惑，需要额外的 Faithfulness 校验或 Self-RAG 来保障回答质量。

面试官还可能这样问

1. 问法 1 · 场景切入

   假设你在做一个客服系统，用户问“我的订单什么时候到”，你从知识库里检索相关文档再生成回答。那你这个检索模块具体是怎么从用户问题拿到那几段最相关的文档的？输入输出是什么？

2. 问法 2 · 层层追问

   RAG系统里检索那部分你一般怎么设计？……比如用户问题里有个“它”，你怎么找到对应的文档？……更具体的，你用的是稀疏检索还是稠密检索？为什么？

3. 问法 3 · 直球架构

   请详细解释RAG系统中检索模块的工作机制，包括它的输入输出、采用的模型类型（稀疏还是稠密）、依赖的组件比如向量数据库和索引结构，以及它如何与生成模块协作来提升回答质量。