1. 为什么说检索链路设计是 RAG 项目的“生命线”1.1 大模型回答质量很多时候不是模型决定的而是证据决定的在 RAG 系统里大模型像一个会组织语言的“回答器”但它能不能答准取决于它面前有没有正确证据。如果检索链路漏掉了关键文档模型再强也只能凭记忆和概率猜如果检索链路塞进来一堆无关文本模型就容易被噪声带偏如果证据排序不合理真正重要的信息排在很后面模型也未必能稳定利用。所以检索链路设计的核心不是“搜到越多越好”而是把最能回答问题的证据以最合适的顺序、最干净的形式、最低可接受的成本交给大模型。2. 检索链路整体应该怎么拆离线建库 在线查询两条线2.1 离线建库决定知识有没有被正确放进系统离线建库通常包括文档接入、解析清洗、切分分块、向量化、索引入库、元数据绑定、原文存储等步骤。不要小看这条线很多线上检索问题其实根源在离线阶段。比如 PDF 解析丢了表格标题层级没保留chunk 切得太碎元数据没有文档版本和权限字段这些都会直接影响后续检索质量。2.2 在线查询决定用户问题来了以后能不能找到正确证据在线查询则是另一条链路用户问题进来后先做查询理解、改写、拆解和路由然后走多路召回再融合、重排、过滤最后把证据整理成上下文交给模型。这个过程每一步都可能影响最终效果。一个高质量回答通常不是某个单点技术带来的而是这两条线一起配合的结果。3. 第一层查询理解先把“用户到底想问什么”搞清楚3.1 为什么不能直接拿用户原话去检索用户输入往往很口语化、很模糊还可能夹杂错别字、指代、省略和业务黑话。比如“这个单怎么还没动静”如果直接拿去搜系统可能不知道用户在问订单状态、物流状态、退款状态还是售后审核状态。查询理解层要做的就是把用户原话变成适合检索的形式。常见动作包括纠错、标准化、意图识别、查询改写、同义词扩展、多查询拆解和路由判断。3.2 查询改写、扩展、拆解分别解决什么问题查询改写解决“用户说得不清楚”的问题查询扩展解决“用户说法和文档说法不一致”的问题查询拆解解决“一个问题里包含多个子问题”的问题。比如用户问“新员工入职社保、公积金和电脑领取流程分别怎么走”就应该拆成多个子查询而不是只检索一个大问题。4. 第二层多路召回不要把所有希望都压在一种检索方式上4.1 BM25、向量检索、FAQ、结构化检索、GraphRAG 各有分工BM25 更擅长精确匹配比如编号、专有名词、法规条款向量检索更擅长语义相似比如用户换一种说法问同一个意思FAQ 适合高频稳定问题结构化检索适合带权限、时间、部门、产品等字段过滤GraphRAG 则适合实体关系复杂、多跳推理和全局总结。如果只用一种方式很容易出现盲区。只用 BM25口语化表达和同义表达可能召回不到只用向量检索精确编号和专有名词可能不够稳只用 FAQ长尾问题覆盖不了。4.2 混合检索为什么越来越常见混合检索的本质是把关键词检索的“精确性”和向量检索的“语义理解”结合起来。比如用户问“年假怎么计算”BM25 可以命中“年假”这个关键词向量检索可以找到“带薪休假规则”“入职年限与假期额度”等语义相关文档。两者结合通常比单一路径更稳。5. 第三层结果融合与重排召回不是终点排序才决定模型能看到什么5.1 为什么多路结果不能直接拼在一起不同召回方式的分数往往不可直接比较。BM25 的分数、向量相似度、FAQ 命中分、图检索分数本质都不一样。如果简单拼接很容易出现一个召回源霸榜或者相同内容重复出现。因此工程里通常要做结果融合和去重。常见做法包括加权融合、RRF、按召回源设置优先级、按文档版本和业务权重做二次排序等。RRF 的好处是更关注排名位置而不强行比较不同模型的原始分数。5.2 为什么还要 Rerank第一阶段召回通常追求“不要漏”所以它会带来不少噪声。Rerank 的目标是在较小候选集合中重新判断哪个证据最能回答用户问题。常见 Rerank 方式包括 Cross-Encoder、LLM Rerank、规则重排和业务权重重排。面试时可以这样总结召回阶段求全重排阶段求准。6. 第四层上下文构造检索结果不能原样塞给模型6.1 上下文构造的任务是把候选 chunk 变成“证据包”很多 RAG 系统明明检索到了正确内容最后答案却不好原因是上下文构造太粗糙。比如把十几个长 chunk 原样塞进去模型抓不到重点或者没有来源引用用户无法验证或者把新旧规则放在一起模型不知道哪个版本优先。一个好的证据包通常要包含回答规则、按相关性排序的证据、来源引用、必要的文档版本、冲突提示、以及“证据不足时不要编造”的约束。6.2 上下文压缩为什么重要上下文不是越长越好。太长会增加成本和时延也会让模型更难聚焦。上下文压缩可以把 chunk 中的废话、导航、重复内容删掉只保留与问题相关的关键句、表格字段和结论。7. 第五层速度、成本与稳定性检索链路不能只追求“更准”7.1 线上系统必须分层路由而不是所有问题都走重链路最常见的线上策略是高频标准问题先走 FAQ 或答案缓存普通知识问答走 BM25 向量混合检索复杂问题再走多查询、重排或 GraphRAG超时或低置信度时则走澄清、降级或转人工。这样设计的好处是大部分简单问题能快速返回只有少量复杂问题才消耗重资源。否则所有问题都走最重链路系统很快会被时延和成本拖垮。7.2 缓存、并行和候选裁剪是提速三件套缓存可以避免重复检索并行可以让 BM25、向量、图检索同时跑候选裁剪可以减少重排和生成阶段的负担。真正有经验的团队往往不是单纯换更大的模型而是先把链路路径、缓存策略、候选数量、上下文长度优化好。8. 第六层评估与可观测性必须知道问题到底出在哪一层8.1 不要只看最终回答好不好要拆开看每一层检索链路评估要分层看。召回层看 RecallK、Hit Rate排序层看 MRR、nDCG上下文层看上下文相关率、引用覆盖率、冗余率生成层看忠实性、正确性、完整性线上层看时延、成本、缓存命中率、用户采纳率和转人工率。8.2 日志必须能还原每次回答的证据路径如果线上出了问题你要能回放用户原始 query 是什么、改写后是什么、走了哪些召回源、各自返回了哪些 TopK、融合前后排名如何、rerank 分数如何、最终哪些 chunk 进入 prompt、模型引用了哪些证据。只有这样才能真正定位问题。9. 常见面试追问检索链路设计怎么答才像做过项目9.1 如果问“你们怎么提升召回率”可以回答先从离线侧看数据质量、chunk 粒度、元数据是否完整再从在线侧做 query rewrite、query expansion、多查询拆解、多路召回和 hybrid search。最后用 RecallK 和人工抽样验证是否真的提升。9.2 如果问“为什么要做混合检索”可以回答关键词检索擅长精确词和专有名词向量检索擅长语义相似。真实业务里两类问题都存在所以混合检索能兼顾精确性和语义泛化。9.3 如果问“Rerank 为什么不能直接全量做”可以回答Rerank 通常更准但更慢尤其是 Cross-Encoder 或 LLM Rerank。如果对大量候选全量精排成本和时延会很高。更合理的是先粗召回再对较小候选集做精排。9.4 如果问“怎么避免检索结果污染模型”可以回答要做去重、阈值过滤、权限过滤、版本过滤、上下文压缩和证据排序同时在提示词里要求基于证据回答证据不足时拒答或追问。10. 总结检索链路设计的核心是让模型“拿着正确证据回答”如果把整篇文章压缩成一句话那就是检索链路设计不是简单向量检索而是从离线建库到在线查询的完整证据生产线。离线侧要做好解析、清洗、切分、元数据和索引在线侧要做好查询理解、多路召回、融合重排、上下文构造、性能治理和评估闭环。好的检索链路要做到找得全、找得准、排得对、拼得好、跑得快。只有这样大模型才能从“凭感觉回答”变成“基于证据回答”。面试时只要围绕这条主线展开结合 BM25、向量检索、混合检索、RRF、Rerank、上下文压缩、缓存和评估指标就能把检索链路设计讲得非常完整。附30 秒快答模板“检索链路设计不是单纯向量检索而是一个端到端系统。离线侧要做好文档解析、清洗、切分、元数据和向量化在线侧先做查询理解包括改写、扩展、拆解和路由再走 BM25、向量、FAQ、结构化检索、GraphRAG 等多路召回之后进行融合去重、rerank、权限过滤和上下文构造。上线后还要做缓存、分层路由、并行和降级最后用 RecallK、MRR、Faithfulness、时延、成本和用户反馈做评估闭环。核心目标是让模型拿到最相关、最可信、最干净的证据。”