面试题 · 检索
搜索「Faiss」匹配到口述回答，相关段落已展开。查看匹配内容 ↓
请详细解释检索增强生成（RAG）系统中检索模块（Retriever）的工作机制，包括其输入与输出、所采用的模型类型（如稀疏/稠密检索模型）、依赖的技术组件（如向量数据库、索引结构）、在整体流程中的作用，以及它如何与生成模块（Generator）协同工作以提升回答质量。
输入输出
| 类型 | 原理 | 代表模型 | 特点 |
|---|---|---|---|
按学习路线查看教程、项目和面试题。
| 词袋模型 + 统计权重 |
| BM25、TF-IDF |
| 精确匹配，可解释强，适合关键词查询 |
| 稠密检索 | 双塔编码器，语义向量相似度 | DPR、Contriever、BGE | 语义理解好，泛化能力强，需GPU推理 |
向量数据库与索引
Query → [Retriever] → Top-K Docs → [Prompt拼接] → Generator → Answer关键协作点
质量提升本质：Generator从" parametric memory "（参数知识）扩展到" non-parametric memory "（外部知识），减少幻觉，实现可溯源回答。
建议先掌握RAG整体架构，再重点理解Retriever的两种主流技术（如BM25与DPR），并通过开源项目（如LangChain）动手实践检索流程。
场景切入
假设你在做一个客服系统，用户问“我的订单什么时候到”，你从知识库里检索相关文档再生成回答。那你这个检索模块具体是怎么从用户问题拿到那几段最相关的文档的？输入输出是什么？
层层追问
RAG系统里检索那部分你一般怎么设计？……比如用户问题里有个“它”，你怎么找到对应的文档？……更具体的，你用的是稀疏检索还是稠密检索？为什么？
直球架构
请详细解释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]] 模式。