#六、RAG、检索、重排与知识增强

#代表笔试题

RAG，全称 Retrieval-Augmented Generation，输入通常不是单纯的一句用户问题，而是 用户问题 + 会话历史 + 用户身份和权限 + 知识库索引 + 检索配置；输出也不应只是一段自然语言答案，成熟系统会同时输出引用来源、被采用的证据片段、拒答或低置信提示、检索与生成日志。它解决的问题是：模型参数里的知识有限、可能过期、不可追溯；而企业文档、数据库、工单、论文和代码仓库等外部知识又不能每次都重新训练进模型。RAG 的核心思路是先从外部知识中找证据，再让模型基于证据作答。

端到端链路可以按两条线理解。离线入库线是 原始文档 -> 解析清洗 -> 切分 chunk -> 生成 embedding -> 写入向量库/倒排索引 -> 记录元数据、版本和权限。在线查询线是 问题理解 -> 查询改写 -> 稀疏/稠密召回 -> 重排 -> 上下文拼装 -> 带证据生成 -> 引用校验 -> 评测与观测。笔试题常考“RAG 为什么能缓解幻觉”，更准确的回答是：它让模型有机会依赖新鲜、可追溯的外部证据，但只要证据没召回、证据错误、上下文拼装失败、模型无视证据或证据之间互相矛盾，幻觉仍然会发生。

chunking 是入库质量的第一道关。chunk 太小会丢上下文，例如只切到一句“它的复杂度是 O(n)”但不知道“它”指谁；chunk 太大会稀释主题，导致 embedding 表征不集中，也浪费上下文窗口。常见策略有固定 token 切分、按标题/段落/语义边界切分、表格和代码块整体保留、parent-child chunk、适度 overlap。overlap 的作用是减少边界信息丢失，但过大时会制造重复召回、降低有效上下文密度。真正工程化的 chunk 还要带元数据：文档 ID、章节路径、时间戳、作者、租户、权限、版本、来源 URL 和业务标签。

embedding model 的作用是把问题和文档片段映射到同一个向量空间，让“语义相近”的内容在空间中距离更近。向量检索一般用 cosine similarity、dot product 或 L2 距离，并通过 HNSW、IVF、PQ 等近似最近邻索引降低大规模检索成本。它的优势是能处理同义表达，例如“报销规则”和“费用 reimbursement policy”；弱点是对精确实体、编号、错误码、专有名词、短查询不一定稳定。BM25 是典型稀疏检索，依赖词项匹配、词频和逆文档频率，适合精确关键词、产品型号、函数名和法律条款号。hybrid retrieval 通常把 BM25 与向量召回合并，再用加权分数或 RRF 等方法融合，目标是同时拿到语义相关和字面精确的候选。

#代表面试题

面试官问“你做过的 RAG 为什么效果不好”，希望听到的是分层定位。第一层看召回：相关文档是否进入 top-k，查询是否需要改写，chunk 是否切坏，embedding 是否覆盖领域术语，BM25 是否被停用词、分词或拼写影响。第二层看重排：初召回通常追求高 recall，会带很多噪声；reranker 用 cross-encoder、late interaction 或 LLM judge 对“问题-候选片段”联合打分，能把真正回答问题的片段排到前面，但成本更高，所以常见设计是向量/BM25 先取 top 50 或 top 100，再重排到 top 5 到 top 10。retriever 负责“便宜地捞候选”，reranker 负责“更准确地排序”。

第三层看 context packing。上下文窗口不是越大越好，RAG 要把有限 token 用在最能支撑答案的证据上。packing 需要去重、合并同一文档相邻 chunk、保留标题路径和出处、处理冲突证据、控制每个来源的 token 上限，并把关键证据放在模型更容易注意的位置，缓解 Lost in the Middle。一个好的 prompt 会要求模型“只根据给定证据回答、证据不足则说明不足、每个关键结论给引用”。但这不是形式主义：如果引用 ID 在上下文里不稳定，或生成后没有检查引用是否真的支撑句子，最终仍会出现看似有 citation、实际不 faithful 的答案。

索引更新和权限过滤是生产 RAG 的高频追问。知识库会持续变化，所以系统要支持增量解析、增量 embedding、版本号、删除 tombstone、重新索引队列和回滚；否则用户会问到已删除政策或旧合同。权限过滤必须进入检索链路，而不是生成之后才遮盖答案。常见做法是在 chunk 元数据中存租户、组织、用户组、文档 ACL、保密等级，检索时先做 tenant isolation 和权限过滤，或在向量库支持 metadata filter 的情况下把过滤条件下推。只在 rerank 或生成后过滤有两个风险：一是未授权文档可能影响排序和答案；二是日志、引用、缓存中可能泄露不可见内容。

RAG 也不是所有知识增强问题的默认答案。如果知识很稳定、需要模型在所有任务中内化一种能力，微调或继续预训练可能更合适；如果问题只需要精确数据库字段，Text-to-SQL 或工具调用比把表格塞进上下文更可靠；如果任务是复杂流程执行，Agent workflow 可能比一次检索生成更自然。RAG 的优势在于知识变化快、来源可追溯、文档规模大、不能或不值得频繁训练模型；代价是多了一套检索系统、索引治理、权限治理、评测体系和运行时延迟。

#这一块真正考什么

这一块真正考的是你能不能把“最终答案错了”拆成可测量的中间环节。检索侧常看 recall@k：标准答案所需证据有没有被召回；precision@k：召回结果里有多少是真的相关；MRR/NDCG：相关证据是否排在靠前位置。生成侧常看 answer correctness、faithfulness、citation accuracy 和 groundedness。faithfulness 的意思不是答案听起来对，而是答案中的关键断言能否被提供的上下文支持；citation accuracy 则看引用是否指向真正支撑该断言的片段。工程侧还要看延迟、成本、缓存命中、索引新鲜度、拒答率、权限误放行率和用户反馈。

GraphRAG 与普通向量 RAG 的区别在于，它把实体、关系、事件、社区摘要或路径显式建模。普通向量检索擅长找“和问题语义相似的片段”，但当问题需要跨文档聚合、关系推理、全局主题总结时，单个 chunk 未必足够。GraphRAG 可以先抽取实体和关系，构建图谱，再按实体邻域、路径、社区摘要召回上下文。它的代价是抽取质量、图谱更新、实体消歧、存储和查询复杂度都更高，不适合所有问答。面试中可以说：GraphRAG 适合关系密集、跨文档、多跳聚合场景；普通向量加 rerank 更适合局部事实问答和成本敏感场景。

long-context 与 RAG 也不是互相替代。长上下文可以减少切分和召回失败，适合一次性读完整报告、代码仓库中的少量文件或长会话；但它成本高、延迟高，且模型对长上下文中间位置的信息利用不一定稳定。RAG 通过先检索再压缩上下文，成本更可控，也更容易做权限、引用和索引更新。常见折中是：先用 RAG 找候选文档和关键片段，再把少量完整章节或 parent chunk 放进长上下文；或者对高价值任务使用 long-context，对高 QPS 任务使用短上下文 RAG。

#作答抓手

回答 RAG 问题时，可以固定按 数据入库 -> 切分 -> 表征 -> 召回 -> 重排 -> 上下文拼装 -> 生成 -> 引用 -> 评测 -> 监控 展开。先定义输入输出，再说明每一层为什么存在：chunking 决定可检索粒度，embedding 提供语义召回，BM25 补足精确匹配，hybrid 提高覆盖面，rerank 提高排序质量，context packing 负责把有限证据组织成模型能用的形式，生成阶段负责忠实表达而不是自由发挥。

常见误区需要主动避开。第一，RAG 不等于消除幻觉，它只是给模型更多证据和约束。第二，top-k 越大不一定越好，噪声会挤占上下文并干扰生成。第三，embedding 模型不是可随便替换的黑盒，领域术语、语言、查询长度和向量维度都会影响召回。第四，rerank 不能修复没有被召回的证据。第五，引用不等于可信，必须检查引用是否支撑断言。第六，权限过滤不是 UI 问题，而是检索和缓存层的安全边界。第七，离线评测集不能只放简单事实题，还要覆盖否定问题、冲突文档、过期文档、多跳问题、无答案问题和权限边界问题。

一个高质量追问链路可以这样回答：如果用户说答案错，先看 gold evidence 是否在召回 top-k；若不在，调 chunk、query rewrite、embedding、BM25/hybrid 和 metadata filter；若在但排名低，调 reranker、候选规模和特征；若排名高但没进 prompt，查 packing、去重、token budget、排序位置和截断；若进了 prompt 仍答错，查 prompt 约束、模型能力、冲突证据处理和引用校验；若只在部分用户上错，查权限、租户过滤、索引版本和缓存。这样回答的好处是把 RAG 从“调参玄学”变成可观测、可复现、可迭代的系统工程。