完整题目
请详细解释检索增强生成（RAG）系统中检索模块（Retriever）的工作机制，包括其输入与输出、所采用的模型类型（如稀疏/稠密检索模型）、依赖的技术组件（如向量数据库、索引结构）、在整体流程中的作用，以及它如何与生成模块（Generator）协同工作以提升回答质量。
本文目录
Retriever的核心机制
输入输出
- 输入：用户Query（可能经过改写/扩展）
- 输出：Top-K相关文档片段（doc_id + 文本 + 相似度分数）
两大检索范式
| 类型 | 原理 | 代表模型 | 特点 |
|---|---|---|---|
| 稀疏检索 | 词袋模型 + 统计权重 | BM25、TF-IDF | 精确匹配，可解释强，适合关键词查询 |
| 稠密检索 | 双塔编码器，语义向量相似度 | DPR、Contriever、BGE | 语义理解好，泛化能力强，需GPU推理 |
关键技术组件
向量数据库与索引
- 存储：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）动手实践检索流程。
换一种问法，检查是否真正理解
场景切入
假设你在做一个客服系统，用户问“我的订单什么时候到”，你从知识库里检索相关文档再生成回答。那你这个检索模块具体是怎么从用户问题拿到那几段最相关的文档的？输入输出是什么？
层层追问
RAG系统里检索那部分你一般怎么设计？……比如用户问题里有个“它”，你怎么找到对应的文档？……更具体的，你用的是稀疏检索还是稠密检索？为什么？
直球架构
请详细解释RAG系统中检索模块的工作机制，包括它的输入输出、采用的模型类型（稀疏还是稠密）、依赖的组件比如向量数据库和索引结构，以及它如何与生成模块协作来提升回答质量。
练习口述回答 · 约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 文档的质量。