面试题 · 检索
搜索「重排」匹配到口述回答，相关段落已展开。查看匹配内容 ↓
请详细阐述RAG（Retrieval-Augmented Generation）系统的架构设计和关键组件，并讨论提升检索效果的技术方法，包括检索器优化、向量数据库选择、重排序策略等？
RAG = 检索器(Retriever) + 生成器(Generator) + 融合机制
用户Query → 检索器 → 相关文档Top-K → 拼接Prompt → LLM生成答案关键设计：检索结果作为**上下文(Context)**注入，而非直接替换模型参数。
按学习路线查看教程、项目和面试题。
| 方法 | 核心思想 | 适用场景 |
|---|---|---|
| Dense Retrieval | 双塔Embedding（Query/Doc各编码） | 语义匹配、长尾Query |
| Sparse Retrieval | BM25、TF-IDF词项匹配 | 精确匹配、高频术语 |
| 混合检索(Hybrid) | Dense+Sparse结果融合（RRF/线性加权） | 通用场景首选 |
| 查询改写 | HyDE（生成假设文档）、Query Expansion | Query与Doc语义Gap大 |
Embedding模型选型：MTEB榜单参考，领域适配可作为候选，但是否提升及幅度应在固定留出集和相同检索预算下实测，不承诺10–20%。
核心考量维度：
关键参数：ef_construction（建图质量）、M（邻居数）影响召回-延迟权衡。
两阶段漏斗设计：
第一阶段（召回）：高Recall，轻量模型，候选池大（如Top-100）
第二阶段（精排）：高Precision，重模型，最终Top-K（如Top-5）| 问题 | 解决方案 |
|---|---|
| 上下文过长截断 | 检索结果摘要压缩、层次化检索（先章节后段落） |
| 多跳推理 | 迭代检索（IRCoT）、知识图谱增强 |
| 幻觉与归因 | 检索结果显式引用、置信度阈值过滤 |
| 冷启动/新文档 | 增量索引、实时向量更新管道 |
场景切入
假设你在做一个电商客服助手，用户问‘这个手机多少钱’，系统从文档里找到价格回复了。但如果用户接着问‘那另一个颜色呢？’，这时候光靠生成器可能答不准。你怎么设计一个检索增强的架构，让系统能自己去找对应的商品详情？
层层追问
RAG系统里检索怎么做的？……如果召回的结果不准，你一般从哪些角度优化？……那检索器、向量库、还有重排序，你觉得哪个环节对效果影响最大？……具体到向量数据库，你怎么选？
直球架构
给我详细讲讲RAG系统的完整架构，从检索器、向量数据库到重排序，每个组件你怎么选型优化？还有，如果业务要求首条回复在1秒内，你会在哪些地方做取舍？
这道题问[[RAG]]的架构和检索优化，我觉得本质是在问：怎么把外部知识可靠地注入到生成模型里，同时控制好延迟和[[幻觉]]。RAG不是简单拼装，而是检索和生成的桥接，设计时要时刻想着它们怎么配合。
先说核心架构，就是检索器加生成器再加一个融合机制。用户query进来，检索器从知识库捞Top-K文档，拼成prompt喂给LLM生成答案。这里有个关键前提：证据漏召回会限制基于该证据集作答，但高召回不保证忠实生成；解析、权限、重排、上下文与生成都要分阶段评估。所以我会把重心放在检索优化上。
检索器优化，我一般分两条路走。一条是[[Dense Retrieval]]，用[[Embedding]]做语义匹配，适合长尾query；另一条是[[Sparse Retrieval]]，比如[[BM25]]，做精确词匹配，适合高频术语或订单号这种场景。真正落地时，我很少单选一条，而是用[[Hybrid Search]]把两者结果融合，比如用RRF排序。举个具体例子：客服场景里用户问‘退款到账时间’，语义上可能匹配到‘退款流程’，但关键词‘到账时间’能精确命中FAQ里对应的字段，混合检索能把两类结果都捞上来。这里有个坑：如果query和文档的语义gap特别大，比如用户说‘订单异常’但文档里写的是‘交易失败’，纯向量检索可能漏掉。这时候我会用查询改写，比如HyDE先生成一个假设文档再检索，或者做query expansion。
接下来是[[向量数据库]]选型。索引算法上，HNSW是图索引，IVF是聚类倒排索引，不能按内存型/磁盘型二分；编码、落盘、召回和延迟取决于具体变体及参数。我会根据数据规模和延迟要求选。量化压缩也很关键，从FP32压到INT8能省不少内存，但精度会掉一点，得用业务数据测过再定。另外，权限条件应限制候选资格，内容返回与送模型前必须授权；引擎可使用预过滤或搜索中迭代过滤，不能一概说所有metadata都必须先完成一次预过滤。常见失败场景是：索引参数没调好，比如HNSW的ef_construction设太小，建图质量差，导致召回崩了。所以上线前我会用一批固定query回放，对比Recall@K和延迟。
[[重排序]]策略我用两阶段漏斗。第一阶段召回池大，比如Top-100，用轻量模型快速过滤；第二阶段用Cross-Encoder对召回候选交互打分，再选最终Top-K；例如给Top-100候选打分后取Top-5，而非只给已选的5篇打分。如果延迟敏感，我会用[[ColBERT]]做late interaction，精度折中但快很多。这里有个取舍：精排模型部署成本高，如果业务对延迟要求严格，我会考虑用[[Bi-Encoder]]加简单规则替代。
最后说落地权衡。延迟要按业务SLO、负载和输入输出长度分别测编码、检索、重排、TTFT与TPOT，不能统一承诺500/100/400ms。成本方面，Embedding调用费不贵，但精排模型部署费高，得算ROI。证据资格、漏召回与生成忠实性都可能成为瓶颈；先做阶段归因和消融，再决定优先优化哪部分。另外，上下文过长时我会做检索结果摘要压缩，或者用层次化检索先找章节再找段落。
还有一个点值得注意：当知识库频繁更新时，增量索引怎么做。直接原地动图索引会导致召回质量波动，我倾向用base加delta双索引，删除用软标记，后台异步重建，上线前做一致性校验。
所以综合来看，我更倾向把RAG看成一套系统工程，不是调个模型就完事。检索器、数据库、重排序每一步都有取舍，得根据业务场景和资源来定。