54. 模块六：RAG、检索、重排与知识增强知识点

#模块六：RAG、检索、重排与知识增强知识点

#一、先把 RAG 看成一条证据流水线

RAG 不是“把向量数据库接到大模型前面”这么简单，而是一条从资料到答案的证据流水线：文档进入系统后先做采集、清洗、去重、权限标注和版本标注，再按语义结构切成 chunk；chunk 被 embedding model 编码成向量，同时也可以保留标题、路径、关键词、时间、作者、ACL 等 metadata；用户提问进入后，系统先做 query rewrite、意图识别和权限过滤，再从 BM25、向量索引或 hybrid retrieval 里召回候选证据；候选证据经过 reranker 精排和去重后，被 context packing 组织成可读、可引用、长度受控的上下文；最后生成模型基于这些证据回答，并输出引用、置信度、无法回答边界和日志。面试里讲 RAG，最好顺着这条链路讲，因为 RAG 的问题通常不是单点坏掉，而是链路某一层让正确证据没有进入、没有排前、没有被模型用上。

这也是 RAG 能缓解幻觉的真正原因：它把“模型凭参数记忆回答”改成“模型在显式证据约束下回答”。但它不会自动消灭幻觉。召回错、重排错、上下文塞太多噪声、引用没有校验、模型没有被约束只能基于证据作答，都会让系统继续编。好的 RAG 设计一定要把答案正确性拆成三件事：证据是否找到了，证据是否放到了模型容易使用的位置，答案是否忠实于证据。

#二、离线侧：chunking、embedding 与索引

Chunking 的目标不是机械地每 500 token 切一刀，而是在“语义完整”和“检索颗粒度”之间取平衡。chunk 太小，定义、条件、例外条款可能被切散，召回回来也缺上下文；chunk 太大，向量会被多个主题平均掉，BM25 也容易被无关词污染，生成阶段还会消耗窗口。工程上通常先按标题、段落、表格、代码块、FAQ 问答等结构切，再设置 token 上限和 overlap。overlap 的意义是保住跨段证据，例如一个产品限制写在上一段，处理步骤写在下一段；代价是索引变大、重复召回变多，所以后面要做去重和相邻 chunk 合并。

Embedding model 决定“语义相似”到底怎么被表示。它把 query 和 chunk 映射到同一个向量空间，向量距离近意味着模型认为二者语义相关。选型时不要只看公开榜单，而要看业务查询的 recall@k：中文、代码、法律、医学、企业缩写、多语言混合都会改变最佳模型。还要注意 embedding 版本管理：模型升级后，新旧向量空间可能不兼容，通常需要重建索引或双索引灰度。索引本身也不是只有向量库，百万文档场景会同时维护稀疏倒排索引、向量 ANN 索引、metadata 过滤字段、文档版本表和删除 tombstone，以支持增量更新与回滚。

#三、在线侧：BM25、向量、混合召回与重排

BM25 属于稀疏检索，优势是关键词、编号、错误码、专有名词、函数名和精确短语很稳；缺点是不懂同义表达。向量检索属于稠密检索，优势是能处理“如何申请退款”和“退款流程在哪里”这类语义匹配；缺点是对数字、专名、否定条件和稀有词可能不如 BM25 稳。Hybrid retrieval 的价值就是把两者互补起来：先分别召回 top-k，再用加权分、RRF 或学习到的融合器合并候选。面试时可以强调，hybrid 的目标通常是提高 recall，而不是直接得到最终排序。

Retriever 做粗召回，追求快和召回全；reranker 做精排序，追求把真正能回答问题的证据排到前面。常见 reranker 是 cross-encoder 或 LLM reranker，它会同时看 query 和 chunk，因此比单独向量距离更准，但成本更高。实际系统经常是“召回 100 条、重排 20 条、入 prompt 5 条”。重排后还要做多样性控制：如果 top 5 都来自同一个页面的重复段落，模型看到的信息并不会更多；如果问题需要多跳证据，则要保留不同实体、不同时间或不同章节的材料。

#四、上下文组织、引用与 faithfulness

Context packing 是 RAG 很容易被低估的一层。它不是把 top-k 原样拼进去，而是在窗口预算内安排证据顺序、长度、来源和冲突信息。常见做法是把最高价值证据前置，保留标题、来源 URL、更新时间和 chunk id；相邻 chunk 可以合并，重复 chunk 要删除；长文档可以先做 evidence summary，再把摘要和关键原文一起放入。遇到 Lost in the Middle，不能只说“换长上下文模型”，还要通过重排、关键证据前置、分段回答、引用锚点和问题拆解，让模型在生成时更容易定位证据。

引用和 faithfulness 是企业 RAG 的底线。引用不是装饰，而是回答中每个关键事实都能追到具体证据。faithfulness 评估的是“答案是否被给定证据支持”，它不同于 correctness：答案可能事实上正确，但证据里没有，那就是不忠实；答案可能引用了文档，但把条件、范围或时间说错，也是不忠实。工程上可以要求模型按句子给 citation，做答案-证据 entailment 检查，或在生成后用 verifier 判断哪些句子没有证据支撑。更强的策略是允许模型回答“资料中没有足够证据”，这比强行编一个看似完整的答案更可靠。

#五、权限过滤、更新机制与系统边界

权限过滤必须前置到检索链路，而不是生成后再删。文档入库时应写入租户、部门、用户组、密级、有效期等 ACL；在线检索时先根据用户身份做 metadata filter，再召回和重排。否则系统可能把无权限证据送进 prompt，即使最终答案没有直接展示，也已经发生信息泄露。多租户 RAG 还要防止 embedding 缓存、日志、引用链接和错误提示泄露数据。

索引更新要区分新增、修改、删除和重算。新增文档可以异步切块并写入索引；修改文档要让旧 chunk 失效，避免新旧版本同时被召回；删除文档要处理向量库里的软删除或后台 compaction；embedding 模型升级、chunk 规则变化、权限规则变化则可能触发批量重建。成熟系统会记录 ingestion job、文档版本、chunk hash、索引版本和查询日志，这样才能复现“为什么昨天答对、今天答错”。

RAG 也不是所有知识问题的答案。高频稳定的输出格式、风格偏好、工具调用习惯，更适合 SFT 或提示模板；严格结构化查询可能应该走 SQL、搜索引擎或知识图谱；文档很少且一次性给全时，long context 可能比建 RAG 更简单。RAG 与 long context 的区别在于：long context 负责“看得多”，RAG 负责“先选证据再看”。窗口越长，成本、延迟和噪声利用问题越明显；检索越准，短窗口也能答得很好。实际系统常常二者结合：先检索过滤，再把少量高价值文档放进长上下文。

#六、GraphRAG 与知识增强的扩展

GraphRAG 解决的是普通向量检索不擅长的结构化、多跳和全局归纳问题。向量检索擅长找“与 query 相似的段落”，但用户问“某公司近三年战略变化背后的关键人物和合作关系是什么”时，答案可能分散在多个文档、多个实体和多条关系里。GraphRAG 会抽取实体、关系、事件和社区，把文本块挂到图节点或边上；查询时先定位相关实体与子图，再做路径扩展、社区摘要或多跳证据聚合。它的优势是关系可解释、适合复杂知识依赖；代价是抽取成本、图谱噪声、更新复杂度和评估难度更高。面试里不要把 GraphRAG 神化，它是为关系密集型问题服务的增强层，不是向量检索的全面替代品。

如果进一步细分，GraphRAG 通常有两类 query mode：local search 偏实体邻域和具体事实，适合问某个公司、人物、系统组件的关系；global search 偏社区摘要和全局主题，适合问“整个材料集合里有哪些主要风险/趋势/阵营”。这个区别很适合面试追问，因为它能说明你理解 GraphRAG 不是简单“建个图”，而是在不同问题类型下选择不同证据聚合方式。

#七、纠错型 RAG 与 evidence verifier

Self-RAG、CRAG 和 verifier 型 RAG 的共同问题意识是：检索结果本身不一定可信。传统 RAG 往往默认 top-k 就是可用证据，但真实系统里会出现召回无关文档、旧版本文档、冲突文档、无权限文档和证据不足。纠错型 RAG 会在生成前加入 evidence verifier，判断证据是否 relevant、sufficient、fresh、authorized；如果证据不足，就触发 query rewrite、二次检索、扩大数据源、冲突说明或拒答。

面试里可以把这套机制压成一条链：retrieve -> verify -> route -> generate -> cite -> post-verify。verify 不是只看相似度分数，还要看证据能否支撑具体断言。post-verify 则检查最终答案的每个关键句是否被引用支持。这样讲能把 RAG 从“找几段材料让模型答”提升到“证据质量控制系统”。代价也要说清楚：纠错链路增加延迟、judge 成本和错误传播风险，所以应按任务风险分层启用。

#八、企业知识库的缓存、版本和审计

企业 RAG 的缓存不能只按 query 字符串命中。两个用户问同一句话，权限不同，能看的证据就不同；同一用户隔一天问同一句话，索引版本和文档版本可能已经变了。因此缓存 key 至少要包含 tenant、权限摘要、index_version、document_version watermark、retrieval config、prompt version 和 model id。高风险场景宁可牺牲命中率，也不能跨租户、跨权限或跨版本复用答案。

日志也不应只保留最终问答。可复现 trace 至少要包含 raw query、rewrite 后的 query、检索配置、top-k 文档 ID 与分数、rerank 后排序、最终塞进 prompt 的 evidence ids、模型和 prompt 版本、生成答案、citation、verifier 结果、拒答原因、延迟、token 成本和 cache hit。没有这些信息，线上 bad case 只能靠猜；有了这些信息，才能把失败样本回流到召回、重排、引用和权限的回归评测集中。

#九、常见误区与复盘清单

误区一：只调 prompt。如果正确证据没有进入 top-k，再好的 prompt 也只能组织错误材料。
误区二：只看最终答案。要分开看 retrieval recall、rerank MRR/nDCG、context 利用率、citation faithfulness 和 answer correctness。
误区三：chunk 越大越安全。大 chunk 会带来主题漂移和窗口浪费，真正重要的是语义边界、overlap 与后处理。
误区四：向量检索取代关键词检索。生产系统里错误码、合同编号、API 名称、专有名词通常仍需要 BM25 或过滤条件。
误区五：有引用就可信。引用必须能支持具体句子，否则只是“看起来有来源”。
误区六：缓存只看 query。RAG 缓存还必须看权限、索引版本、文档版本、prompt 版本和模型版本。
误区七：GraphRAG 一定更高级。如果问题只是局部事实问答，普通 hybrid retrieval + rerank 往往更便宜、更稳。

复盘一个 RAG 问题时，可以按这张清单走：用户问题是否被正确改写；权限过滤是否漏掉或误杀；正确文档是否在库中且版本正确；chunk 是否包含完整证据；BM25、向量、hybrid 的 top-k 是否召回正确证据；reranker 是否把它排到前面；context packing 是否把证据放在模型能注意到的位置；生成 prompt 是否要求基于证据回答并允许拒答；引用是否逐句可验证；线上日志是否能复现这次链路。这个清单比“换个 embedding 模型试试”更像工程诊断。

#十、面试追问链路

如果面试官从“什么是 RAG”继续追问，可以按链路展开：先讲端到端 pipeline；再解释 chunk size、overlap、Contextual Retrieval 和 parent-child 如何影响召回；接着比较 BM25、vector、hybrid、ColBERT / cross-encoder rerank 的适用边界；然后说明 context packing、Lost in the Middle、引用和 faithfulness；随后补上权限过滤、增量更新、缓存版本和 trace 可观测性；最后讨论 RAG vs fine-tuning、RAG vs long context、GraphRAG、Self-RAG/CRAG 适合什么问题。一个成熟回答的重点不是背工具名，而是能把每个组件的输入、输出、失败模式、评估指标和启用代价讲清楚。