高级 RAG 方法

基础 RAG 解决“先找资料，再让模型回答”，高级 RAG 继续追问六件事：该不该查、拿什么查、从哪里查、怎样组织知识、怎样修正错误，以及怎样证明答案确实受证据支持。

文章	重点
RAG 架构与方案选择	Naive、Advanced、Modular RAG，以及 RAG、长上下文、缓存和微调的边界
查询变换与检索路由	HyDE、Multi-Query、RAG-Fusion、问题分解、Self-Query 与路由
高级检索与排序	Dense、Sparse、ColBERT、混合召回、融合、MMR 与 reranker
层次化与上下文化索引	Parent Document、Small-to-Big、Contextual Retrieval、RAPTOR 与 LongRAG
自适应、纠错与 Agentic RAG	Self-RAG、CRAG、Adaptive-RAG、FLARE 和迭代检索控制
GraphRAG 与知识图谱检索	Knowledge Graph RAG、Microsoft GraphRAG、LightRAG 与图向量混合检索
上下文治理、证据约束与引用	压缩、重排、冲突处理、引用归因、拒答与检索内容注入防护

这些方法不是越多越好。阅读时始终把技术放回具体故障：召回不足、排序错误、上下文缺失、证据冲突、复杂问题拆不动，还是在线成本和延迟不可接受。没有评测数据时，复杂流水线通常只是在增加新的失败点。

学习清单

下面按文章分组列出问题和详细参考答案。完成每组后，建议用自己的业务数据再跑一遍，确认不仅会背概念，也能定位失败原因。

RAG 架构与技术选型

• Naive RAG、Advanced RAG 和 Modular RAG 的本质差别是什么？

  • 参考答案：Naive RAG 通常将原问题一次检索后直接拼接生成；Advanced RAG 在检索前、中、后加入查询变换、混合召回、过滤、重排和上下文治理；Modular RAG 则把这些能力做成可编排模块，并根据状态动态路由、循环和停止。差别主要在控制流和可组合性，不意味着越复杂一定越好。

• 固定检索、条件检索和迭代检索应该怎样选择？

  • 参考答案：专用知识问答且每次都要查时用固定检索；请求类型混合或数据源不同，用条件检索；比较题、多跳题、证据冲突等无法一次查全时，用有预算和停止条件的迭代检索。选择时同时测召回收益、模型调用数、P95 延迟和循环率。

• 大上下文模型为什么没有直接淘汰 RAG？

  • 参考答案：大窗口只解决“能否放入”，不保证低成本、低延迟、平均利用所有位置，也不负责从动态大语料中筛选最新且有权限的证据。小而稳定、需要全文推理的语料适合长上下文；大型动态知识库仍适合 RAG，二者也可组合。

• CAG 和 Prompt Cache 是同一个概念吗？

  • 参考答案：不是。CAG 是在有限知识场景下预加载知识并复用其运行时状态，以绕过在线检索的一种生成架构；Prompt Cache 是 API 或推理层对相同提示前缀计算结果的复用机制，可用于 CAG，也可用于普通会话和工具定义。缓存不承担语义检索、ACL 或新鲜度判断。

• 为什么微调不适合替代企业知识库？

  • 参考答案：企业事实常更新、撤回并受权限约束，而参数知识更新慢、难定点删除、难追溯来源，也不适合文档级 ACL。微调更适合学习输出风格、抽取格式和使用证据的行为；事实仍由运行时 RAG 提供。

• RAFT 到底优化了 RAG 的哪一段？

  • 参考答案：RAFT 优化 reader/generator 使用候选证据的能力。它用相关文档和干扰文档训练模型识别、引用并依据正确证据作答。它不替代 embedding、向量库或检索器，也不能修复正确证据未进入候选集的问题。

• 如何完整计算一次 RAG 请求的成本？

  • 参考答案：应累计路由、查询改写、query embedding、各检索器、reranker、最终生成输入/输出以及基础设施成本，并把离线 embedding、索引存储、更新和运维按请求或业务量摊销。还应报告每个成功答案的成本，避免便宜但错误的请求拉低平均值。

• 企业 RAG 中权限过滤为什么必须下推到检索层？

  • 参考答案：模型看见无权数据后再被要求“不说”已经越过安全边界。每个检索器都应使用服务端可信身份执行 tenant、role、document ACL 过滤；缓存 key 和 trace 也必须包含或遵守相同权限边界，并用跨租户攻击样例验证零越权。

• 怎样判断一次架构升级是否值得保留？

  • 参考答案：在固定数据集上做消融实验，比较升级前后的 Recall@k、MRR/nDCG、Faithfulness、引用正确率、拒答质量、P95/P99 延迟、调用次数和每成功答案成本。只有目标指标显著改善且安全、复杂度和运维代价可接受时才保留。

查询变换与检索路由

• Query Rewrite、Query Expansion 和多轮独立化分别解决什么问题？

  • 参考答案：Rewrite 将原问题改成语义等价且更适合检索的表达；Expansion 增加同义词、领域词或相关表达以扩大词汇覆盖；多轮独立化从历史中恢复明确的指代和省略，使问题脱离历史也能理解。三者都必须保留实体、时间、范围、否定和版本等关键约束，不能自行补事实。

• 为什么 Multi-Query 应保留原始 query 分支？

  • 参考答案：生成查询可能全部漂移，而原始 query 保留用户精确措辞、产品名、编号、版本和否定关系。将原始分支与生成分支并行召回，再融合和按原问题 rerank，可以增加兜底，并让系统单独测量生成查询的真实边际收益。

• HyDE 的真实原理是什么，假想文档能直接给用户看吗？

  • 参考答案：HyDE 先让语言模型生成一段可能相关的假想文档，再用 document encoder 编码，在真实语料向量空间中找邻近文档。假想文档可能幻觉，只是检索桥梁，不能成为证据、引用或答案来源。生产中应保留原 query 分支并对真实结果重排。

• 写出 RRF 公式，并解释它为什么不需要校准检索分数。

  • 参考答案：$RRF(d)=\sum_{r\in R}1/(k+rank_r(d))$。它只使用文档在各结果列表中的名次，不直接相加 cosine、BM25 等不可比的原始分数，因此不要求先把不同检索器分数映射到同一尺度。它会损失分数幅度信息，$k$ 和分支权重仍需评测。

• Step-back 和 Query Decomposition 有什么区别？

  • 参考答案：Step-back 将具体问题抽象为上位概念或一般原则，通常与原问题并行检索；Decomposition 将复合任务拆成多个可独立验证的子问题，并显式表达依赖。前者主要改变抽象层次，后者改变任务结构。复杂案例可能先分解，再为某个子问题做 step-back。

• Self-Query 的安全实现为什么要使用受限 AST？

  • 参考答案：让模型直接生成并执行 SQL 或数据库 DSL 会带来注入、非法字段、超大查询和绕过权限等风险。受限 AST 只允许白名单字段、类型和操作符，由服务端校验、编译并强制追加 tenant/ACL 条件。安全字段不能由模型或用户覆盖。

• 如何评估一次 Query Rewrite 是真的变好，而不只是更通顺？

  • 参考答案：先检查 must-keep 约束保留率和 unsupported addition rate，再在同一语料上比较原始与改写查询的 Recall@k、MRR/nDCG 和最终答案质量，同时记录延迟与成本。文本流畅度或与原句的语义相似度都不能替代检索结果评估。

• 如何评价 Multi-Query 或 HyDE 增加的额外调用是否值得？

  • 参考答案：做消融实验，比较新增分支带来的 union Recall、每条查询的边际相关文档、漂移率、重复率、最终答案增益、P95 延迟和每成功答案成本。如果后续分支几乎不新增正确证据，或噪声与尾延迟增长更快，就应减少分支或只对特定查询族启用。

• Router 的 false positive 和 false negative 分别有什么代价？

  • 参考答案：false positive 是不需要检索却检索，增加成本、延迟和无关证据污染；false negative 是需要外部事实却不检索，可能使用过期、私有或虚构知识。高风险、时效和企业事实通常优先降低 false negative，并通过代码硬规则强制检索。

• 分解后的某个子问题没有证据，最终答案应该怎么办？

  • 参考答案：合成前检查每个必需子问题的状态。仍有预算时针对缺口补查；无法找到时明确指出缺少哪部分，只回答已有证据支持的部分，不能用其他子问题的证据推断缺失事实。计算也只能在输入事实已验证后执行。

高级检索与排序

• 问题 1：为什么企业 RAG 常同时使用 BM25 和 dense retrieval？

  • 参考答案：两者捕获的相关性不同。BM25 对错误码、SKU、专有名词和原文关键词稳定，dense 对同义改写、口语表达和语义近似更强。生产系统通常并行召回，再用 RRF 或经过校准的分数融合。两路并用不保证必然更好，还需要去重、过滤、评测和延迟预算；若语料极小或查询类型单一，单路可能已经足够。

• 问题 2：为什么 dense 分数和 BM25 分数不能直接相加？RRF 解决了什么？

  • 参考答案：dense 与 BM25 的分数定义、范围和分布不同，同一个检索器在不同 query 上的分布也可能变化。直接加权会让数值尺度较大的一路支配结果。RRF 只使用每路名次，以 1 / (k + rank) 累加，因此不需要分数同尺度，适合作为稳定基线。代价是它忽略原始分数幅度，且仍受每路召回深度与平滑参数影响。

• 问题 3：SPLADE、ColBERT 和普通 dense embedding 的核心区别是什么？

  • 参考答案：普通 dense 通常把一个文档压成一个固定长度稠密向量；SPLADE 输出词表维度上的稀疏权重，可用倒排索引，并学习词项扩展；ColBERT 为 query 和文档保留 token 级向量，通过 late interaction 的 MaxSim 聚合相关性。SPLADE 的代价是神经编码与稀疏索引膨胀，ColBERT 的代价是多向量存储和更复杂索引。选型应由精确词、细粒度匹配需求及资源预算决定。

• 问题 4：正确证据已经在 dense top-50，加入 reranker 后仍未进入最终 top-5，怎样排查？

  • 参考答案：先确认候选是否在融合、去重或截断时提前丢失，再检查 reranker 输入是否因长度被截掉答案、分数方向是否用反、模型是否适合当前语言和领域、标题与关键 metadata 是否缺失。对比 rerank 前后 rank，单独重放该 query-document 对，并检查超时后是否走了错误降级。不能只通过扩大最终 top-k 掩盖精排错误。

• 问题 5：ACL filter 为什么不能只在检索后执行？

  • 参考答案：如果无权文档已进入候选、日志或模型上下文，即使最终答案没有展示，也可能已经造成信息暴露。安全过滤应由可信后端根据登录身份生成，并在模型看到候选前强制执行，优先 pre-filter。post-filter 还可能把 top-k 大量删掉造成结果不足。数据库受过滤 ANN 限制时，可以使用分区、过滤索引、迭代搜索或过采样，但不能把安全判断交给模型。

• 问题 6：怎样选择 k_retrieve、k_fuse 和 k_final？

  • 参考答案：先用评测集画出 Recall@k 曲线，找到继续扩大召回的边际收益；k_fuse 要覆盖多路并集但受 reranker 延迟预算约束；k_final 由证据完整性和上下文 token 预算共同决定。应同时记录 MRR/nDCG、p95 延迟、reranker 成本和最终答案质量。不同 query 类型可以使用不同预算，不能把一个固定 k 当成普适答案。

• 问题 7：HNSW 的 ef_search 调大后为什么通常召回更高，但系统仍不一定更好？

  • 参考答案：更大的 ef_search 会探索更多图节点，更接近精确近邻，因此 ANN Recall@k 往往上升；同时 CPU、内存访问和尾延迟也会上升，并可能在高并发下放大排队。更重要的是，ANN recall 只衡量对 exact 向量近邻的逼近。如果 embedding 本身把错误文档排得更近，调大参数不会提升业务相关性。应把 ANN recall 与证据 Recall@k 分开测。

• 问题 8：MMR 与候选去重有什么区别？什么时候不该使用强 MMR？

  • 参考答案：去重用于删除同一 chunk、同一版本或近重复内容；MMR 在剩余候选中同时考虑 query 相关性和候选之间的相似性，主动选择不同角度的证据。对需要多来源、多原因的任务很有用。对于唯一事实答案或多个重复片段构成相互佐证的场景，过强的多样性惩罚可能引入较弱证据，因此应调高相关性权重或直接不用。

• 问题 9：怎样证明加入 cross-encoder reranker 值得它的成本？

  • 参考答案：在冻结评测集上比较 rerank 前后的 MRR/nDCG、最终证据命中率和答案质量，同时记录 p95 延迟、吞吐、每请求候选对数与基础设施成本。按否定条件、版本冲突、长文本等类型切片，确认收益来自目标失败样本。还要验证超时降级路径。如果质量提升很小或只改善非关键样本，就应缩小候选数、换轻量模型或移除该层。

• 问题 10：线上答案错误时，怎样快速判断是召回、排序还是生成的问题？

  • 参考答案：先用标注来源检查正确证据是否进入各路 raw top-k；未进入就是查询、分块、filter、表示或 ANN 问题。若已进入但融合或精排后掉出，检查去重、RRF、截断和 reranker。若正确证据已进入最终上下文，才检查上下文顺序、证据冲突、提示词和生成模型。完整 trace 必须保留每阶段候选 id、排名、分数、过滤原因和延迟。

层次化分块与上下文索引

• 问题 1：固定分块、递归分块、语义分块和结构化分块分别适合什么场景？

  • 参考答案：固定分块简单且长度稳定，适合无结构文本和基线；递归分块优先保留标题、段落、句子等自然边界，适合普通 Markdown 和文档；语义分块根据相邻语义变化找边界，适合主题转折不依赖排版的访谈或会议记录，但成本和边界漂移更高；结构化分块按条款、表格、函数等领域结构切分，证据最完整但解析器复杂。生产中通常先结构化解析，再递归处理过长节点。

• 问题 2：为什么 overlap 不能从根本上解决分块边界问题？

  • 参考答案：overlap 只是机械复制边界附近内容，提高条件与结论同时出现的概率，但不知道哪里是业务完整边界。跨多个条款的例外、表头与数据行、函数签名与调用关系仍可能分离。overlap 越大，chunk 数、embedding 成本、重复召回和上下文冗余越高。应先利用结构，再通过 Parent 或 Sentence Window 恢复上下文。

• 问题 3：Parent Document、Sentence Window 和 Small-to-Big 有什么关系？

  • 参考答案：Small-to-Big 是“用小单元检索、返回更大上下文”的上位模式。Parent Document 使用预先定义的父子层级，命中子块后返回固定父块；Sentence Window 命中句子后按位置扩展前后句。两者都属于 Small-to-Big。选型取决于文档是否有可靠层级、局部邻接是否足够，以及扩展后的 token 和权限边界。

• 问题 4：Contextual Retrieval 与简单把标题放进 metadata 有什么区别？

  • 参考答案：标题路径是确定性的结构信息，成本低、可审计；Contextual Retrieval 通常让 LLM 根据全文为每个 chunk 生成主体、时间、主题等补充说明，并把它同时用于 contextual embedding 与 contextual BM25，能处理隐含指代，但有生成错误、离线成本和重建压力。应先试规则化 title + section_path + date，只有评测证明不足时再生成上下文。

• 问题 5：为每个 chunk 生成上下文时，prompt caching 为什么能省钱，怎样提高命中率？

  • 参考答案：同一文档的多个请求共享“固定指令 + 完整文档”前缀，只让当前 chunk 放在缓存点之后。首次请求写缓存，后续前缀完全一致且未过 TTL 时读取缓存，避免按普通输入价重复处理整篇文档。应按文档连续批处理、保持前缀字节与顺序稳定、移除时间戳和随机字段，并从 usage 中监控 cache read/write token。具体 TTL、最小长度和价格以供应商当前文档为准。

• 问题 6：RAPTOR 为什么适合跨章节问题，又为什么维护困难？

  • 参考答案：RAPTOR 递归地对叶子表示进行聚类和摘要，高层节点聚合了多个章节的主题，因此全局或多步问题能检索到不同抽象层级的信息。维护困难在于一个叶子变化可能改变聚类归属，连带影响同 cluster 摘要和祖先摘要；摘要还可能遗漏或引入内容。需要 lineage、版本化节点、局部或周期重建策略，并在回答具体事实时下钻到原文核验。

• 问题 7：LongRAG 与 Parent Document Retrieval 的差异是什么？

  • 参考答案：Parent Document 通常仍用小子块做匹配，命中后取固定父块；LongRAG 让更长的单元直接参与检索，再由长上下文 reader 在少量长单元中找答案。LongRAG 减少单元总数并保留上下文，但在线输入 token、长上下文定位和引用成本更高。论文中的 4K token 等设置属于特定数据集实验，不能直接当企业默认值。

• 问题 8：层次索引怎样做增量更新，避免新旧内容混用？

  • 参考答案：为文档版本、节点、内容 hash 和派生模型建立稳定标识，只重算内容或派生版本变化的节点；父子索引同步更新父节点，摘要树重算受影响祖先。新版本先写 shadow index 或版本化集合，通过一致性和回归检查后原子切换 active alias，再异步回收旧版本。查询始终强过滤 active version，不能边删旧数据边暴露半成品新索引。

• 问题 9：删除一篇文档时，为什么删除它的向量还不够？

  • 参考答案：文档内容可能已进入 sparse posting、contextual text、文档摘要、RAPTOR 祖先、查询缓存和答案缓存。只删叶子向量会留下仍可召回的“幽灵证据”。应先用状态过滤立即阻断召回，再沿 lineage 异步清理所有派生物并更新受影响摘要，最后用原查询回归验证旧事实不可见。

• 问题 10：怎样证明某种层次索引真的比普通 chunk 更好？

  • 参考答案：冻结一份按问题类型分层的评测集，标注答案句、必要条件、期望来源和版本。比较 Child/Parent Recall@k、条件完整性、Context Precision、扩展倍率、冗余、最终答案与引用，同时记录建库成本、freshness lag、p95 延迟和输入 token。Parent、RAPTOR、LongRAG针对的问题不同，应分别在局部事实、跨边界、文档路由和全局综合子集上报告，不能只看一个平均分。

自适应、纠错与 Agentic RAG

• 为什么 Self-RAG 不能简化成“让模型自我反思”的提示词？

  • 参考答案：Self-RAG 的关键是训练模型生成 Retrieve、ISREL、ISSUP、ISUSE 等 reflection tokens，并把这些信号纳入训练目标和推理控制。普通提示词只改变指令，不会让模型获得论文所需的控制 token、批评能力或对应校准。工程上可用外置 evaluator 模拟控制思想，但应明确称为 Self-RAG-style，而非论文原版。

• CRAG 的三条分支分别做什么，为什么不能只用一个相似度阈值？

  • 参考答案：Correct 说明已有证据足够，进入知识精炼；Ambiguous 说明部分相关或不稳定，应保留可用结果并补查；Incorrect 说明候选不能支持问题，应丢弃后改用 web 或其他检索。相似度只衡量表示空间接近，无法确认实体、时间、否定和条件是否一致，因此需要 retrieval evaluator 与 aspect coverage。

• Adaptive-RAG 的 no-retrieval、single-step、iterative 如何选择？

  • 参考答案：先看问题复杂度：闲聊、改写和当前上下文已足够的问题走 no-retrieval；单实体、单事实问题走 single-step；比较、多跳、跨版本或多条件资格判断走 iterative。论文使用复杂度分类器和特定实验流程，生产实现可用规则或小模型，但要用带复杂度标签的离线集评估误路由成本。

• FLARE 何时主动检索，masked sentence/query 解决了什么？

  • 参考答案：模型在生成下一句草稿时监测 token 或句子置信度，发现数字、实体或关键断言低置信度，就把不确定 span/句子掩码化形成查询，检索证据后再生成正式内容。它把检索放到长生成内部，能减少后半段失据，但会增加调用和延迟；低概率专名、代码等不应无条件触发。

• 迭代 RAG 与 Agentic RAG 的边界是什么？

  • 参考答案：迭代 RAG 可以是固定状态机，只在预定义的改写、检索、评估、补查动作间循环；Agentic RAG 让策略根据状态动态选择检索、SQL、网页、计算或人工确认等工具。前者可预测、易审计，后者适合开放式研究但需要更严格的权限、预算、防循环和 trace。Agentic RAG 常包含迭代 RAG，但两者不是同义词。

• 一个生产状态机必须记录哪些证据缺口和预算字段？

  • 参考答案：缺口至少要有 aspect、状态（missing/partial/covered/conflict/unverifiable）、优先级、支持它的 source/chunk 和更新时间；预算要记录最大时间、输入输出 token、工具调用次数、web 次数和费用上限，并持久化已用值。还应记录 seen query、结果 fingerprint、attempt、snapshot、策略和版本，才能停止、恢复、幂等和回放。

• 如何评估自适应或纠错 RAG 是否真的值得？

  • 参考答案：离线按单事实、多条件、多跳、过期、冲突、空结果和权限场景分层，分别测 Recall@k、aspect coverage、claim support、citation precision、路由准确率、停止和循环指标。线上再看 p50/p95 延迟、每问成本、补查比例、无新增证据比例、引用验证失败和用户纠错率。不能只比较最终答案字符串，要检查证据是否真的支持断言，以及复杂策略带来的质量提升是否超过成本。

• 什么时候不应该引入 Self-RAG、CRAG 或 FLARE？

  • 参考答案：若根因是文档解析、分块、ACL 或索引更新错误，先修基础数据链路；若问题是单事实高吞吐，迭代和 FLARE 会徒增延迟；若内部知识库禁止外部来源，CRAG 的 web 分支不可用；若没有标注、评测和预算控制，Self-RAG/Agentic 复杂度很难验证。技术选择应由具体失败类型和 SLO 驱动，而不是由方法名驱动。

GraphRAG 与知识图谱检索

• 能严格区分通用 Knowledge Graph RAG、Microsoft GraphRAG 和 LightRAG 吗？

  • 参考答案：Knowledge Graph RAG 是“图谱/图数据库 + 检索 + 生成”的通用范式，没有固定数据模型。Microsoft GraphRAG 是具体研究项目，默认知识模型包含 TextUnit、Entity、Relationship、可选 Covariate、Leiden Community 与 Community Report，并提供 Local、Global、DRIFT 等搜索。LightRAG 是另一套具体方法，论文重点是实体/关系图、文本 key-value 表示、向量匹配和 low/high 双层检索；当前仓库又扩展出 local、global、hybrid、naive、mix 等模式。三者不能用同一个“GraphRAG API”概括。

• 为什么实体、关系、claim 和来源映射要分开存？

  • 参考答案：实体和关系描述结构，claim 表达某个来源提出且可能带状态、时间和争议性的陈述；抽取 confidence 也不等于事实为真。来源映射负责把每个派生对象追回 document/version/chunk/span。分开后才能保留冲突、判断有效期、按贡献删除、逐项引用，并避免把“疑似导致”错误固化为“确定导致”。

• 怎样避免把“北辰材料”和“北辰新材”错误合并？

  • 参考答案：先查统一社会信用代码、主数据 ID 等确定性键；再用名称规范化召回候选，结合实体类型、地址、产品、邻居、时间和描述相似度打分。高置信自动合并，中间区间送人工，低置信创建新实体。规范化名称只用于候选召回，不直接决定合并；不同租户禁止跨域合并，并用 redirect 表保留后续纠错能力。

• Microsoft GraphRAG 的 Local、Global、DRIFT Search 分别怎样流动？

  • 参考答案：Local 先用问题定位语义相关实体，再收集相邻实体、关系、可选 Covariate、社区报告和关联 TextUnit，适合具体实体问题。Global 从指定层级社区报告出发，map 生成带评分的中间观点，再 reduce 汇总，适合全库主题。DRIFT 先用相关社区报告生成宽视角 primer 和追问，再用 Local Search 下钻并迭代，适合宽问题中的细节探索。它们是问题类型选择，不是简单的质量等级。

• LightRAG 的 local/global 与 Microsoft GraphRAG 的 Local/Global 为什么不能画等号？

  • 参考答案：LightRAG 论文的 low-level 通过 local keywords 定位实体及其局部信息，high-level 通过 global keywords 匹配关系的主题 key；当前仓库的模式建立在这套图和向量检索上。Microsoft Local 依据其知识模型收集实体关联的多类对象，Microsoft Global 则对 Leiden 社区报告做 map-reduce。名称相似，但索引产物和查询数据流不同。

• 图、向量和关键词三路候选应怎样融合？

  • 参考答案：关键词负责合同号、批次号、产品名等精确匹配；向量负责同义表达和语义候选；图从规范实体种子沿允许关系扩展多跳证据。各路原始分数不同量纲，可先用 RRF 按排名融合，再用 reranker 结合问题、路径质量、来源、时效和长度重排。所有通道必须在候选生成前应用租户和 ACL，最终回源到原始片段。

• 多跳路径为什么不能越深越好？

  • 参考答案：平均分支数为 $b$ 时，$h$ 跳候选可能接近 $O(b^h)$；路径越长，延迟、上下文和错误累积越大。生产查询应限制关系白名单、方向、有效时间、2-3 跳深度、每节点 fan-out 和总路径数。路径上每条边都要有当前用户可见的直接来源，缺一条就不能把整条路径当答案证据。

• 删除一份文档时，为什么不能直接删除它提到的节点和边？

  • 参考答案：同一节点或边可能由多份文档共同支持。正确做法是删除该版本的贡献与 chunk/向量，重算仍有其他来源的对象描述；只有活动来源数归零时才 tombstone 对象。同时失效相关 claim、社区摘要、全文索引和答案缓存，并验证旧 source_ref 不再可检索。先 tombstone 再异步清理可以在不确定状态下 fail closed。

• 更换 embedding 模型或图 schema 时怎样迁移？

  • 参考答案：用新的 manifest 从权威原文和贡献日志构建独立 v2，不能把不同向量空间混进旧索引。通过事件或 CDC 双写增量变更，先做图完整性、检索、答案、ACL、延迟和成本对比，再影子流量、灰度读取、切换并保留回滚窗口。还要核对距离函数、维度、过滤语义、缓存 key 和派生产物版本。

• 图 RAG 的权限检查为什么要做到“逐边”？

  • 参考答案：节点名称可见不代表连接关系可见，一条路径可能通过不可见边泄露调查、薪酬或供应商风险。租户和主体权限应进入每路检索过滤；图扩展每一步检查边是否至少有一个可见有效来源，路径权限取最严格边界。实体合并描述与社区摘要也要按安全域构建，日志、trace、缓存和无结果提示同样受限。

• 怎样证明图 RAG 比强普通 RAG 基线更好？

  • 参考答案：用同一问题集、生成模型和相近上下文预算，对比全文、dense+rerank、hybrid RAG、图+向量+关键词四组。分层测 Entity/Evidence/Path Recall@k、MRR 或 nDCG，测实体解析与关系 F1、provenance completeness、删除完整性，再测答案正确性、忠实度、引用正确性、多跳完整性和拒答。报告 p95 延迟、单问 token、索引成本和人工维护时间；只有目标问题的收益覆盖复杂度才上线。

• 哪些场景应继续使用普通 RAG，甚至完全不建图？

  • 参考答案：单段事实、精确文档查询、规模很小或高频更新的知识库，普通 hybrid RAG 往往更快。业务数据本就在 SQL 中时应直接查权威表。若 schema 不稳定、来源和权限未治理、无法做删除一致性、延迟预算极低，或只想追逐技术名词，都不应建图。图相连也不能直接支持因果或高风险自动决策。

上下文治理、证据对齐与引用

• 为什么模型支持 128K 上下文，也不应该把检索结果全部塞进去？

  • 参考答案：上下文窗口还要容纳系统指令、历史、问题、工具消息和输出；更长输入会增加费用和延迟，也会带来注意力竞争与位置敏感。Lost in the Middle 表明相关信息在长上下文中的位置会影响表现。生产系统应先计算证据预算，再按相关性、权威、时效、覆盖增量和 token 成本选择证据，并通过位置扰动测试验证当前模型。

• Extractive compression 与 abstractive compression 有什么区别，制度问答为什么通常优先前者？

  • 参考答案：抽取式压缩从原文选择句子或 span，不改写事实，容易保留 offset 并精确引用；生成式压缩由模型摘要或重写，压缩率更高，但可能漏掉否定、例外和数字，或把冲突合并成单一结论。制度问答强调原文、责任边界和可审计性，因此通常优先抽取；若使用生成式压缩，应保留每个摘要 claim 到原始证据的映射并再次做支持校验。

• 相关性很高是否说明证据足够回答？怎样判断充分性？

  • 参考答案：不说明。相关性只表示资料与主题有关，充分性要求证据覆盖推出答案所需的关键事实。可以先把问题拆成原子槽位，例如标准天数、起算时间、适用身份和取整规则，再计算关键槽位覆盖，并检查是否存在冲突。缺少必要字段时应追问或部分回答，不能因为某个 chunk 分数高就补全缺失事实。

• 新旧制度、总部制度和地区补充规则同时出现时，应该怎样裁决？

  • 参考答案：先匹配用户身份、地区、产品和事项类型等适用范围，再按问题发生时间检查 effective_from/effective_to，然后看正式的 supersedes 与版本关系，最后才比较来源权威。发布日期新不代表已生效，重复转载也不能多数投票。规则仍无法裁决时，应展示冲突及各自来源并转人工，而不是平均数字或任选一个。

• 什么是 Claim-Evidence 对齐？为什么段尾挂一个来源不够？

  • 参考答案：Claim-Evidence 对齐是把回答拆成可独立判真的原子主张，再为每条主张标记支持、反驳或未知证据。一个段落可能包含日期、数值、主体和额外推断，段尾引用可能只支持其中一部分。可靠系统要删除 unsupported claim，保留 evidence id 与原文 span，并验证引用确实蕴含其对应结论。

• Citation Precision 与 Citation Recall 分别惩罚什么问题？

  • 参考答案：Citation Precision 关注已经给出的引用里，有多少真正支持相邻 claim，惩罚乱挂来源；Citation Recall 关注所有需要核验的 claim 中，有多少获得了充分引用支持，惩罚漏引。只有引用存在率不能发现“有引用但不支持”。评测时还应检查引用粒度、位置、版本和来源权威。

• 空检索结果为什么不能直接回答“公司没有这项规定”？

  • 参考答案：空结果可能来自 query 改写错误、索引延迟、权限过滤、召回参数、服务超时或知识库真的缺失。它只证明本次检索没有拿到可用证据，不能证明现实中不存在。系统应区分可重试检索失败、证据不足、权限不可见和真实无答案，并分别采取改写重试、追问、受控拒答或转人工。

• RAG 文档中的间接 prompt injection 应怎样防？

  • 参考答案：把检索内容标为不可信数据只是第一层，还要实行最小权限、隔离控制指令与资料、限制副作用工具、入库与检索后扫描、结构化输出校验、敏感字段过滤、高风险动作确认和对抗回归。不能让文档内容直接决定工具调用或权限参数，也不能宣称某个过滤器能彻底消除注入。

• 如何设计一个可验证回答结构？

  • 参考答案：结构至少包含回答状态、自然语言答案、原子 claims、每个 claim 的 evidence_ids、缺失信息、冲突和实际使用的证据。代码层验证 id 来自本次授权检索、关键 claim 都有支持、版本一致、冲突已处理，并根据 answer/partial/clarify/abstain/escalate 决定展示方式。用户看到的是自然文本，系统保留的是可审计证据图。

• 怎样验证系统没有 Lost in the Middle 问题？

  • 参考答案：固定问题、证据集合和生成参数，只改变关键证据在上下文中的位置，分别放在开头、中间和结尾，多次运行并比较答案正确率、关键条件保留率与 citation recall。还应比较按相关性排序、首尾交错、按来源聚合等编排。若位置变化导致明显退化，应缩短上下文、提高证据密度或调整编排，而不是只换更长窗口模型。