检索增强生成面试题

这一类题最容易被答成“我会向量数据库”。真正要讲的是：你能不能让答案有证据、可追溯、可评估，而且知道什么时候不该检索。

答题主线

公司制度问答是最容易看出 RAG 边界的例子：员工问“试用期能休几天年假”，系统要找到当前版本、适用人群和原文位置；如果资料没有答案，就应说没找到，而不是用常识补一句听起来很像真的话。

回答 RAG 题时，建议按这条线展开：

文档怎么入库 -> 怎么切分 chunk -> 怎么做 embedding -> 怎么检索和 rerank
-> 怎么把证据放回上下文 -> 怎么生成带来源答案 -> 怎么评估和更新

面试官通常会追问这几个点：

• 为什么不能把全文直接塞给模型。
• chunk 怎么切。
• 召回差怎么办。
• 常见向量数据库怎么选。
• 权限和 prompt injection 怎么防。
• 评估怎么做，不只看答案顺不顺。

通用答题模板

除非题目只是概念辨析，建议每道题都按下面的顺序回答：

1. 考察点：先说面试官要确认的能力边界。
2. 回答脉络：用一到三句话给出判断标准和展开顺序。
3. 详细参考答案：说明方案、原因、关键数据和限制条件。
4. 常见追问及答案：准备一个实现细节和一个取舍问题。
5. 扣分点：说明哪些回答看似正确但不够工程化。

回答中尽量把“召回、排序、生成”分层。召回解决找得到，rerank 解决排得准，上下文组装解决放得对，生成解决说得清，引用和拒答解决能不能信；每一层都要有独立指标和日志。

一、RAG 的基本理解

Q1：RAG 解决什么问题？

考察点

考察是否理解 RAG 的边界、证据链和企业知识更新问题，而不是只会报组件名称。

回答脉络

先讲知识更新和证据问题，再讲它不是万能。

参考答案

RAG 的作用是把外部知识接到生成过程中，让模型回答时有证据可用，降低知识过时和幻觉风险。它特别适合：

• 企业知识库问答。
• 政策和流程查询。
• 需要引用来源的问答。
• 外部资料经常变化的场景。

RAG 解决的是“如何把外部知识可靠接进来”这个问题，但它不能自动保证答案一定正确。检索错了、切分错了、证据冲突、上下文污染，都可能让生成阶段继续出错。

常见追问及答案

追问：RAG 能不能消除幻觉？ 不能。它只能提供可引用的证据和拒答依据；还需要召回评估、引用一致性检查、答案约束和人工兜底。

扣分点

• 把 RAG 说成“给模型外挂知识”，却不提证据、权限和更新。
• 只承诺降低幻觉，不说明检索错误会被生成阶段放大。

Q2：为什么不能把整份文档直接塞进 prompt？

考察点

考察能否从质量、成本、延迟和审计四个维度做架构取舍。

回答脉络

从成本、噪声、上下文和可维护性四个角度讲。

参考答案

不能直接塞全文，主要有四个原因：

• 贵：输入 token 太多，成本高。
• 慢：上下文越长，延迟越高。
• 噪声多：模型容易被无关内容干扰。
• 不易追踪：很难判断哪一段内容支持了哪个结论。

RAG 的本质是把“全文阅读”变成“按需检索”，让系统只把和问题最相关的片段拿给模型看。

常见追问及答案

追问：长上下文什么时候反而更好？ 当文档数量少、需要跨章节整体理解、且能接受成本和延迟时，可以先检索文档，再对单份文档使用长上下文阅读；不能把“模型能装下”当成“模型一定会用对”。

扣分点

• 只说上下文窗口不够，忽略无关内容、权限泄露和引用定位。
• 没有说明 RAG 与长上下文可以组合。

Q3：RAG 和长上下文应该怎么选？

考察点

考察是否能按问题类型、文档规模、时效性和可审计性选择方案。

回答脉络

不是二选一，而是看任务性质。

参考答案

长上下文适合整体阅读性很强、证据集中、材料不算太多的任务。RAG 适合知识量大、要从很多资料里找相关片段、且需要持续更新的任务。

我通常会这样判断：

• 如果问题需要查大量文档中的局部证据，优先 RAG。
• 如果材料不多，但需要整体推理，可以考虑长上下文。
• 如果既要整体理解又要证据支持，可以两者结合。

真实系统里，长上下文和 RAG 经常不是对立的：RAG 负责筛选，长上下文负责容纳整理后的证据和推理。

常见追问及答案

追问：如何验证组合方案确实更好？ 固定同一批问题，分别比较纯长上下文、纯 RAG 和两阶段方案的答案正确率、引用覆盖率、P95 延迟、输入 token 和拒答准确率。

扣分点

• 只按文档字数选择，没有考虑问题是否需要全局关系。
• 没有提出可回放的对照实验。

二、切分、入库与向量

Q4：chunk 是什么？chunk size 和 overlap 怎么选？

考察点

考察是否理解语义边界、检索粒度、上下文完整性与 token 成本的权衡。

回答脉络

先解释 chunk 是“入库和检索的基本单元”，再讲切分原则。

参考答案

chunk 是把文档切成可检索的小片段。因为文档通常太长，不能直接把整篇文档都作为一个检索单元。chunk size 和 overlap 的选择没有统一答案，核心是平衡“上下文完整性”和“检索精度”。

一般思路是：

• 太小：语义被切碎，答案需要跨多个 chunk 才能拼起来。
• 太大：召回噪声多，检索成本高，相关内容容易被稀释。
• 适当 overlap：能避免关键信息被切断，但重叠太多会重复占 token。

如果是 FAQ、政策条款、短说明，chunk 可以偏小；如果是长段落技术文档，chunk 可以按标题、段落或语义边界切，再配少量 overlap。

常见追问及答案

追问：如何确定具体数值？ 先按标题、条款、问答对等结构切，再设置 token 上限；用标注了“应命中片段”的验证集比较不同大小的 Recall@k、context precision 和最终答案质量，而不是只凭经验固定一个值。检索可用子 chunk，生成时回填父段落或相邻窗口。

扣分点

• 只给一个固定字符数，完全不看文档结构。
• overlap 设置很大，却不说明重复 token 和去重策略。

Q5：RAG 里 embedding、metadata 和索引分别做什么？

考察点

考察是否能把语义表示、权限/版本过滤和近邻检索效率拆开设计。

回答脉络

讲清“向量负责语义，metadata 负责过滤，索引负责检索效率”。

参考答案

在 RAG 中：

• embedding 把文本变成向量，负责语义相似度计算。
• metadata 记录标题、路径、版本、权限、更新时间、文档类型等，用来过滤、排序和追踪来源。
• 索引 是向量库内部的数据结构，负责高效查找近邻向量。

如果只有向量没有 metadata，检索结果很难做权限过滤、版本控制和引用溯源。真正可用的 RAG 不是只有相似度，而是“相似度 + 过滤条件 + 来源信息”的组合。

常见追问及答案

追问：哪些字段不能只放在向量库里？ 原文、版本状态、ACL 变更记录和审计事件应有权威存储；向量库中的 metadata 是检索副本，丢失时应能从原文和 manifest 重建。

扣分点

• 只保存文本和向量，没有稳定 ID、文档版本、页码或权限。
• 把向量索引误当成业务事实源。

Q6：embedding 模型和入库模型一定要一样吗？

考察点

考察是否理解向量空间一致性、模型升级和索引迁移。

回答脉络

要区分“同一套检索空间”和“不同模型兼容性”。

参考答案

查询和入库必须使用同一套 embedding 空间，通常也就是同一个模型或同一套兼容配置。因为检索依赖的是向量距离，如果入库和查询用的不是同一个语义空间，距离就失去意义了。

有些系统会在模型升级时做双写或重建索引，但这仍然是“在同一个阶段里统一切换”，不是随便混着用。面试里可以直接说：入库和查询的 embedding 必须一致，否则检索结果不可信。

常见追问及答案

追问：升级 embedding 时怎么避免停机？ 新建独立索引，离线回填并抽样验证，查询侧支持按索引版本路由，灰度通过后原子切换 alias；保留旧索引一段时间，发现 Recall@k 或线上质量下降即可回切。

扣分点

• 在线直接混用不同维度或不同语义空间的向量。
• 只说“重新生成向量”，没有双索引、校验和回滚。

三、检索、召回与排序

Q7：向量检索、关键词检索、混合检索有什么区别？

考察点

考察是否知道语义匹配与精确匹配的互补关系，以及混合分数不能直接生硬相加。

回答脉络

向量擅长语义，关键词擅长精确；混合检索兼顾两者。

参考答案

三者的区别是：

• 向量检索：适合语义相似，比如“怎么报销差旅”与“差旅费用报销规则”。
• 关键词检索：适合精确匹配，比如编号、错误码、专有名词、版本号。
• 混合检索：把两者结合起来，兼顾语义召回和精确命中。

如果场景里经常出现编号、表单字段、代码错误码、政策条款编号，我通常会优先考虑混合检索，而不是纯向量检索。

常见追问及答案

追问：混合结果怎么合并？ 可以用 RRF 按各路排名合并，也可以在验证集上学习或调节归一化后的分数权重；不同检索器的原始分数通常不可直接比较。

扣分点

• 把 hybrid 说成“向量分数加 BM25 分数”，却不做归一化或离线调参。
• 不说明精确编号、缩写和错别字场景。

Q8：rerank 是什么？为什么召回之后还要 rerank？

考察点

考察是否理解候选集大小、排序模型成本和生成上下文预算。

回答脉络

召回负责“找得到”，rerank 负责“排得准”。

参考答案

召回阶段的目标是尽量别漏掉相关片段，所以它通常会拿比较宽的候选集。rerank 阶段则是在候选集中重新排序，把最相关的内容排到前面。

为什么需要 rerank：

• 向量召回可能把语义接近但不够精确的内容捞上来。
• 关键词召回可能把表面匹配但实际不相关的内容捞上来。
• 生成模型输入位置有限，必须把最有价值的证据优先放进去。

所以 RAG 不应该只说“向量检索”，而要把“召回 + rerank + 证据裁剪”讲成一个整体。

常见追问及答案

追问：top_k 应该怎么定？ 先宽召回，取几十条候选，再由 rerank 排序并保留少量证据；候选太小会漏召回，太大则增加 rerank 延迟和噪声。用 Recall@k 与端到端质量、P95 延迟联合调参。

扣分点

• 把 rerank 当作第二个向量库，讲不清它输入的是 query 和候选文本。
• 只追求排序分数，不考虑证据去重、覆盖不同文档和上下文长度。

Q9：召回差时怎么排查？

考察点

考察是否能用分层观测定位问题，而不是反复修改 prompt。

回答脉络

按“入库 -> 切分 -> 查询 -> 检索 -> 排序 -> 生成”逐层查，不要一上来改 prompt。

参考答案

我会按这个顺序排查：

1. 文档有没有正确入库。
2. chunk 是否切得太碎或太长。
3. query 是否需要改写。
4. embedding 模型是否适合语种和领域。
5. top_k 是否太小。
6. 是否需要混合检索。
7. 是否需要 rerank。
8. 生成阶段是否把证据又冲掉了。

很多召回差的问题，根源根本不在 prompt，而在检索链路。

常见追问及答案

追问：如何判断是 embedding 还是切分的问题？ 抽取包含标准证据的样本，分别回放原文、chunk、query embedding 和候选排名；如果原文相关但 chunk 不完整，优先修切分；如果合理 chunk 仍不相近，再比较 embedding 模型、语言和领域数据。

扣分点

• 只给“调大 top_k”这一种办法。
• 没有保存检索候选，导致线上无法复盘。

Q10：常见向量数据库有哪些？怎么选？

考察点

考察是否能结合规模、过滤、混合检索、运维和故障恢复做选型。

回答脉络

不要只会说一个名字，要说选型维度。

参考答案

常见向量数据库或相近方案包括：

• Milvus：开源、生态成熟，适合独立向量检索系统。
• pgvector：如果已经有 PostgreSQL，做中小规模向量检索很方便。
• Elasticsearch / OpenSearch：适合混合检索、关键词和向量一起做。
• Pinecone：托管式向量数据库，省运维。
• Weaviate：向量检索和对象管理结合得比较完整。
• Qdrant：轻量、开源、过滤能力强。
• Chroma：本地开发和原型验证方便。
• FAISS：更偏库，不是完整数据库，适合本地或内存级实验。

选型时主要看：

• 数据量。
• 是否要过滤权限。
• 是否要混合检索。
• 运维能力。
• 成本。
• 延迟。
• 是否要托管。

面试时最稳的说法不是“我会某某库”，而是“我会根据规模、过滤、混合检索和运维约束选库”。

常见追问及答案

追问：为什么企业场景常选搜索引擎而不是纯向量库？ 企业知识常有编号、版本、权限过滤和关键词要求，搜索引擎更容易把 BM25、向量、过滤、聚合和高亮统一起来；但独立向量库在大规模向量吞吐或专门索引能力上可能更合适。

扣分点

• 只背产品名，不说数据规模、QPS、过滤和恢复目标。
• 忽略索引构建与在线查询的资源隔离。

四、答案生成、引用与更新

Q11：为什么 RAG 的答案要带来源？

回答脉络

把“可追溯、可审计、可复核”讲出来。

参考答案

带来源的原因有三点：

• 可追溯：知道结论来自哪份文档、哪一段内容。
• 可审计：出错时能回看证据链。
• 可复核：人类可以快速判断模型是不是乱编。

如果一个系统不给来源，用户很难相信它。尤其在知识库问答、政策、法律、金融和企业流程这类场景，来源不是装饰，而是产品能力的一部分。

Q12：检索到多份来源冲突时怎么办？

回答脉络

不要强行合并，先标冲突，再看权威性和更新时间。

参考答案

遇到冲突时，我会优先做这几件事：

• 标出冲突来源。
• 看权威性。
• 看更新时间。
• 看是否属于不同版本或不同场景。
• 必要时输出“当前无法确定”。

如果强行把冲突内容合并成一个答案，往往会把不确定性伪装成确定性。更稳的做法是把冲突展示出来，让用户或上游流程决定哪个来源更可信。

Q13：文档更新后索引怎么处理？

回答脉络

讲清增量更新、重建和版本控制。

参考答案

文档更新后，我会优先做增量同步：检测变更文档、重新切分、重新 embedding、更新向量库和 metadata。对于大改版或 embedding 模型升级，可能需要重建索引。

关键点是：

• 要有文档版本号。
• 要有更新时间。
• 要能区分旧索引和新索引。
• 要确保查询只用当前可见版本。

如果版本管理做不好，系统会把过期内容和新内容混着查，答案就会飘。

五、权限、安全与评估

Q14：RAG 里的权限怎么做？

回答脉络

权限要前置到检索阶段，不是生成后补救。

参考答案

权限应该在检索前或检索时过滤，而不是等生成结束后再处理。常见做法是：

• 文档入库时写入权限 metadata。
• 查询时按用户身份过滤候选文档。
• 生成答案时只使用有权访问的证据。
• 日志里保留审计信息，但不要泄露无权限原文。

如果把权限检查放到生成后，敏感内容可能已经进 prompt 了，这就晚了。

Q15：RAG 怎么防 prompt injection？

回答脉络

强调检索内容是数据，不是指令。

参考答案

RAG 防 prompt injection 的核心原则是：外部资料只能作为证据，不能覆盖系统规则。具体措施包括：

• 检索内容和系统提示分层。
• 不把外部文本当系统指令执行。
• 对敏感动作加工具权限校验。
• 高风险步骤加确认。
• 对异常内容做过滤或标记。

用户可以在知识库里放“忽略之前所有规则”这种文本，但系统不能真的照着执行。这个边界要靠架构和工具层来守，而不是只靠 prompt 文字。

Q16：RAG 怎么评估，不只是看答案顺不顺？

回答脉络

把检索层和生成层分开评估，再加成本和延迟。

参考答案

RAG 评估至少看四层：

层级	常看指标
检索层	recall@k、命中文档比例、MRR
排序层	rerank 后相关性、前几条是否最有用
生成层	答案正确率、引用准确率、无答案识别率
系统层	成本、延迟、权限违规率、注入拦截率

只看最终答案是否“看起来顺”，不够。因为可能答案顺，但证据错；也可能答案对，但成本太高。

六、进阶 RAG 题型

Q17：RAG 和微调有什么区别？怎么选？

回答脉络

RAG 解决知识接入，微调改变模型行为和风格。

参考答案

RAG 和微调解决的问题不同：

• RAG：把外部知识按需检索进上下文，适合知识更新快、需要引用来源、数据权限复杂的场景。
• 微调：让模型学会特定风格、格式、任务模式或领域表达，适合行为模式稳定、样本质量高的场景。

如果问题是“模型不知道最新制度”，优先 RAG；如果问题是“模型不会按公司格式输出工单摘要”，可以考虑微调或少样本示例。很多系统会两者结合：微调改善行为，RAG 提供事实。

Q18：Query Rewrite 有什么用？会不会改坏用户问题？

回答脉络

Query Rewrite 是为了提升检索表达，但必须保留用户意图。

参考答案

Query Rewrite 的作用是把用户的口语化、上下文依赖、表达省略的问题，改写成更适合检索的查询。例如用户问“这个能报吗”，系统需要结合上下文改成“差旅打车费用是否可以报销”。

它的风险是改坏用户意图。控制方法包括：

• 只补全上下文，不新增事实。
• 保留原始 query 和改写 query。
• 多 query 召回后合并，而不是只信一个改写。
• 用 eval 看改写是否提升 recall@k。

Q19：Multi-Query Retrieval 是什么？

回答脉络

一个问题生成多个检索表达，扩大召回。

参考答案

Multi-Query Retrieval 是把同一个用户问题改写成多个不同角度的查询，再分别检索，最后合并候选结果。它适合用户问题很模糊、文档表达方式多样、单个 query 容易漏召回的场景。

代价是：

• 检索次数增加。
• 去重和合并更复杂。
• 成本和延迟上升。

所以它适合召回要求高的场景，不一定适合简单 FAQ。

Q20：HyDE 是什么？适合什么场景？

回答脉络

先生成一个假想答案，再用假想答案检索。

参考答案

HyDE 的思路是：先让模型根据问题生成一个“假想答案”或“假想文档”，再用这个文本去做 embedding 检索。这样做的原因是，假想答案可能比原始问题更接近知识库里的文档表达。

适合场景：

• 用户问题很短。
• 问题和文档表达差距大。
• 语义召回不稳定。

风险是：假想答案可能带入错误方向，所以要评估它是否真的提升召回。

Q21：Self-RAG 和 Corrective RAG 这类方法在解决什么问题？

回答脉络

它们都在尝试让系统判断“要不要检索、检索够不够、答案需不需要修正”。

参考答案

这些方法的共同目标是让 RAG 更自适应：

• 判断问题是否需要检索。
• 判断检索结果是否足够支持答案。
• 检索差时重新查询或换策略。
• 生成后检查答案是否忠于证据。

工程上不一定要照搬论文名字，但思想很有用：不要让系统机械地“每个问题都检索一次”，而是根据证据质量决定下一步。

Q22：GraphRAG 或知识图谱适合什么场景？

回答脉络

当问题依赖实体关系、层级和多跳推理时，图结构更有价值。

参考答案

普通向量检索擅长找语义相似片段，但不擅长显式关系推理。GraphRAG 或知识图谱适合：

• 实体关系复杂。
• 需要多跳查询。
• 文档之间引用关系重要。
• 需要解释“谁和谁有什么关系”。

代价是建图成本高、维护复杂、抽取错误会传播。所以我会在实体关系确实重要时再考虑，不会一上来就上图谱。

Q23：向量数据库性能差时怎么优化？

回答脉络

从数据、索引、过滤、top_k、rerank 和缓存查。

参考答案

我会看这些方向：

• 向量维度是否过高。
• 数据量是否需要分片。
• 索引类型和参数是否合适。
• metadata 过滤是否能前置。
• top_k 是否太大。
• 是否把 rerank 候选集设得过宽。
• 热门 query 是否可以缓存。

性能优化不能只看向量库本身，还要看检索链路和生成上下文长度。

七、常见追问

Q24：RAG 一定比直接让模型回答好吗？

不一定。RAG 在知识更新快、需要引用来源、证据分散的场景更有价值。但如果任务很简单、知识很稳定、问题很短，直接模型回答可能更便宜、更快。

Q25：为什么有些 RAG 系统答案反而变差？

通常是因为检索噪声、切分不当、过多无关上下文、rerank 不佳或者证据太长。RAG 不是“加检索就会变好”，而是“检索链路做好了才会变好”。

Q26：什么时候需要多轮检索？

当问题复杂、需要先拆解子问题、或第一轮证据不足时，可以做多轮检索。但每多一轮就多成本和延迟，所以要设置上限和停止条件。

基础题补充答法（追问版）

下面补齐 Q11-Q26 的考察点、工程化追问和扣分点；前面的简答适合先给结论，这里适合面试官继续深挖时展开。

Q11-Q13：引用、冲突与更新

考察点：考察能否把答案和具体证据、版本及生效时间绑定。

补充参考答案：引用应保存稳定的 document_id、版本、chunk_id、标题路径、页码/段落位置和内容 hash。多来源冲突时先判断是不是不同版本、组织或适用范围，再按权威性、生效时间和场景裁决；无法裁决就显式展示冲突并拒答或转人工。更新采用内容 hash 幂等、增量重切分和新索引构建，删除要传播到倒排、向量、缓存和引用服务，发布通过 alias 原子切换。

常见追问及答案：追问：只展示文档链接够吗？ 不够，链接可能失效或指向最新版本，必须附版本和位置；追问：如何查历史制度？ 用用户问题中的时间范围过滤 effective_from/effective_to，不能只按当前最新排序。

扣分点：只给文件名；把最新文件无条件覆盖历史版本；只讲 upsert 不讲删除和缓存失效。

Q14-Q16：权限、安全与分层评估

考察点：考察是否能把权限和安全放在生成前，并区分召回、排序、生成和系统指标。

补充参考答案：文档和 chunk 带租户、部门、角色、用户组及策略版本，查询时由身份服务生成 filter，默认拒绝；答案、引用、缓存和日志也继承同一权限边界。检索资料被视为不可信数据，不能执行其中的指令；工具调用必须经过服务端授权和高风险确认。评估集应包含标准证据、不可回答题、权限身份和版本，分别评估 Recall@k、MRR/nDCG、context precision/recall、答案正确性、faithfulness、引用支持率、拒答准确率、越权率、P95 和成本。

常见追问及答案：追问：ACL 服务超时怎么办？ 受保护数据 fail-closed，只能使用仍在安全 TTL 内且带策略版本的缓存；追问：答案对但引用错算不算通过？ 不算，企业场景要把引用支持率作为独立门槛。

扣分点：前端隐藏、生成后脱敏；只说“防 prompt injection”；只报最终准确率。

Q17-Q20：微调、改写与多路检索

考察点：考察能否区分知识接入和行为改变，并控制 query rewrite、multi-query、HyDE 的成本与风险。

补充参考答案：RAG 提供可更新、可过滤、可引用的事实，微调更适合固定格式、风格和任务行为。query rewrite 补全实体、时间和上下文，但保留原 query；multi-query 生成多个表达扩大召回，query decomposition 把复杂问题拆成子问题，HyDE 则用假想答案辅助检索。它们不是默认全开，应由问题类型和证据质量触发，并设置查询次数、超时和 token 上限。

常见追问及答案：追问：改写可能引入事实怎么办？ 约束为只补上下文、不新增事实，原 query 与改写 query 并行召回并比较离线 Recall@k；追问：什么时候不要用 HyDE？ 精确编号、低延迟 FAQ 和高风险问题不应让假想答案主导检索。

扣分点：所有问题都多路检索；把改写结果当唯一真相；只讲论文名不讲收益和成本。

Q21-Q23：自适应、图检索与性能

考察点：考察能否根据问题类型选择深度，并说明 GraphRAG 与向量 RAG 的边界。

补充参考答案：可以用策略路由器把简单 FAQ、精确编号、复杂比较、多跳关系和高风险问题分流。证据不足才升级到多轮检索、更多候选或图查询，达到覆盖阈值就停止。GraphRAG 适合实体关系和多跳路径，但抽取与维护成本高；普通 RAG 适合局部语义证据。性能优化从索引参数、分片、metadata filter、top-k、rerank 候选、批量 embedding 和分层缓存入手，必须用压测验证。

常见追问及答案：追问：向量库变慢先查什么？ 查过滤选择率、索引内存、分片和 P95，再看上游是否把 top-k 或 rerank 候选设得过大；追问：GraphRAG 一定更准吗？ 不一定，图抽取错误会传播，只有多跳关系收益明显时才值得引入。

扣分点：只会加机器或加 top-k；把图谱当万能方案；没有性能基线和停止条件。

Q24-Q26：方案边界与多轮检索

考察点：考察是否知道 RAG 不是默认答案，以及多轮检索的停止、降级和状态管理。

补充参考答案：知识稳定、问题简单时直接回答可能更便宜；结构化数据应优先查数据库或业务 API；文档少且需要整体阅读时长上下文可能更合适。需要多轮检索时，保存子问题、已验证证据和未解决槽位，每轮重新校验 ACL 和版本，设置最大轮数、总延迟和总 token 预算；达到证据覆盖阈值、发现冲突或超过预算就停止并拒答/转人工。

常见追问及答案：追问：第二轮检索没有新证据怎么办？ 不要重复循环，返回当前证据和缺口，邀请用户澄清；追问：多轮会话如何避免旧错误？ 保存结构化摘要和证据 ID，不无限拼接历史，并让每轮结论重新绑定当前证据。

扣分点：把多轮理解成无限调用模型；没有最大轮数和成本上限；遇到无答案仍强行总结。

八、数据治理与文档生命周期

Q27：一个企业 RAG 系统在文档入库前要做哪些数据治理？

考察点

考察是否把 RAG 当成数据工程问题，而不是只会调用 embedding API。

回答脉络

按“来源登记 -> 权属和权限 -> 内容清洗 -> 质量校验 -> 版本与生命周期 -> 可追溯性”展开。

详细参考答案

我不会把共享盘里的所有文件直接向量化。入库前至少要建立文档登记和治理流程：记录来源系统、业务 owner、文档类型、适用范围、更新时间、保密等级、访问主体和失效时间。这样后面出现错误答案时，才能知道这段知识从哪里来、谁负责确认、当前是否还有效。

接着做内容处理。需要解析 PDF、Office、HTML、扫描件和表格，去掉导航栏、页眉页脚、重复版权声明等噪声；对 OCR 内容保留置信度，对表格保留行列关系，不能把表格简单拼成无意义的文字。还要做空文档、乱码、超长行、重复文档和异常编码检查。

质量校验可以包括：文档是否有标题和更新时间、正文是否为空、分段后 chunk 是否过短或过长、关键字段是否缺失、同一内容是否来自多个来源。对低质量内容可以隔离到待审核队列，而不是让它和正式知识混在一起。

最后把每个 chunk 与原文件、版本、解析器版本、切分策略、embedding 模型和权限策略绑定起来。向量只是派生数据，原文和这些元数据才是可治理的事实来源。

工程落地

我会设计一个 ingestion manifest，例如包含 source_uri、document_id、content_hash、version、owner、acl、effective_from、effective_to、parser_version、chunker_version、embedding_version 和 index_status。流水线按 discovered -> parsed -> reviewed -> indexed -> retired 推进，每一步都写入事件和失败原因。生产查询只读取状态为 indexed 且在有效期内的版本。

常见追问及答案

追问：为什么内容 hash 很重要？

它可以区分“文件修改时间变了但正文没变”和“正文真的发生变化”，避免无意义地重复切分和 embedding，也能支持幂等重跑。

追问：模型生成的摘要能不能直接作为知识入库？

可以作为检索辅助字段，但不能未经标记就替代原文。摘要是派生内容，可能丢失限定条件；回答需要引用时，仍应回到有版本和位置标记的原文。

扣分点

• 只说“清洗后做 embedding”，没有文档 owner、权限和版本。
• 把文件名、修改时间等 metadata 当成可有可无的信息。
• 忽略 OCR、表格和重复文档带来的质量问题。
• 没有说明坏数据如何隔离和追溯。

Q28：chunk 应该怎样设计，固定长度切分为什么经常不够？

考察点

考察能否理解 chunk 的语义边界、父子关系和检索粒度之间的权衡。

回答脉络

先解释 chunk 是检索单元，再比较固定长度、结构化和语义切分，最后说明“召回小块、生成用大上下文”的折中。

详细参考答案

固定 token 长度切分实现简单，但它只知道字符或 token 数，不知道标题、段落、列表、代码块和表格的语义边界。一个规则如果正好被切在“例外条件”和“适用范围”之间，单独召回其中一块就可能改变原意。

我通常采用分层切分：先按文档、章节、标题、段落和列表等结构切分，再对过长节点做递归切分；代码按函数或类切，表格按表头和行组切，FAQ 尽量保持问题与答案在同一块。chunk 的大小不是越大越好，要根据问题类型、模型上下文预算和答案所需证据量通过离线评估确定。

一个常用的折中是 parent-child：用较小的 child chunk 做向量召回，提高定位精度；命中后回填对应的 parent section 或相邻窗口，让生成模型拿到完整条件。这样避免“小块检索不到”和“大块上下文噪声多”同时出现。

工程落地

每个 chunk 都保存 parent_id、section_path、start_offset、end_offset、page_no、heading、neighbor_ids 和 content_hash。切分器先保留结构信息，再按策略生成文本。离线评估至少比较三种策略：固定长度、按标题递归、parent-child；不要只通过主观阅读几条结果决定参数。

常见追问及答案

追问：overlap 越大召回越好吗？

不是。overlap 能降低边界截断，但会增加重复向量、索引体积和上下文重复。关键是让语义单元完整，overlap 只是边界保护手段；如果依赖很强，优先用 parent-child 或邻居扩展解决。

追问：怎么发现 chunk 切坏了？

检查标题是否丢失、列表编号是否断裂、条件和结论是否分离、表格是否错列，并在标注集上测“支持答案的 chunk 是否能被召回”。

扣分点

• 只给一个固定的 chunk size，声称适用于所有文档。
• 只讨论 token 数，不讨论语义边界和文档结构。
• 把 overlap 当成解决所有切分问题的办法。
• 没有保存原文位置，无法引用和回溯。

Q29：metadata 应该存什么？哪些字段应该参与过滤，哪些只用于展示？

考察点

考察是否能把 metadata 设计成可查询、可审计的数据模型，而不是随便塞几个键值。

回答脉络

按身份、权限、时效、来源定位、检索辅助和运营字段分类，并强调字段的规范化。

详细参考答案

metadata 至少可以分成几类。身份字段包括 document_id、chunk_id、parent_id 和 source_uri；定位字段包括标题路径、页码、段落编号和原文偏移；时效字段包括版本、生效时间、失效时间和更新时间；权限字段包括租户、部门、角色、ACL 或策略标签；检索辅助字段包括语言、文档类型、产品线和关键词；运营字段包括解析器版本、切分版本、embedding 版本、状态和质量分数。

参与检索前过滤的字段必须稳定、可索引、来源可信，例如租户、文档状态和 ACL。标题、页码可以用于引用展示或结果解释，不应被当成安全边界。业务 owner 填写的标签如果没有校验，也不能直接决定权限。

metadata 还要避免过度自由化。字段名、枚举值、时间格式和权限表达式要统一，否则同一个部门可能被写成多个值，导致过滤漏数据或误拒绝。权限字段最好引用统一的授权系统，而不是在向量库里复制一套会过期的用户列表。

工程落地

查询上下文先由身份服务解析成不可伪造的过滤条件，再交给检索器，例如 tenant_id = T1 AND status = active AND acl_overlap(user_groups) AND effective_from <= now < effective_to。结果返回时保留完整 provenance，但只返回已通过过滤的 chunk。metadata schema 发生变化时进行版本化迁移，不能静默改变旧数据的语义。

常见追问及答案

追问：metadata filter 会不会让向量检索变慢？

会，尤其是过滤选择性很低或索引不支持过滤下推时。要通过租户分区、标量索引、分区键和查询计划优化；安全过滤不能为了性能被移到生成之后。

追问：把 ACL 拼到 chunk 文本里可不可以？

不可以把它当作真正的权限控制。文本里的 ACL 只是模型可见内容，无法阻止向量库把无权限 chunk 召回。权限必须是检索层的结构化过滤和服务端校验。

扣分点

• metadata 只有标题和文件名，没有版本、状态和权限。
• 用展示字段代替安全过滤。
• 允许用户输入直接拼接任意过滤表达式。
• 没有说明 metadata 如何同步和迁移。

Q30：dense、sparse 和 hybrid 检索如何选择和组合？

考察点

考察是否理解语义检索和词法检索的互补性，以及融合分数不能直接相加。

回答脉络

先说明 dense 与 sparse 的优势，再讲 hybrid 的召回流程和分数融合，最后给出适用场景。

详细参考答案

dense 检索把 query 和文档映射到连续向量空间，擅长处理同义表达、口语表达和概念相似；sparse 检索通常基于倒排索引和 BM25，擅长错误码、合同编号、人名、版本号和精确术语。两者的分数尺度不同，不能简单把 cosine 分数和 BM25 分数直接相加。

hybrid 的典型做法是两路独立召回，再用 RRF、归一化加权或学习排序融合。RRF 可以按排名计算：对每个结果按 1 / (k + rank) 累积分数，某个片段同时出现在两路结果中通常会得到更高排名。融合后再去重、做权限和版本过滤，最后交给 rerank。

如果企业文档里有大量政策编号和产品型号，我会优先 hybrid；如果是开放域语义问答且术语不严格，dense 可以作为主路；如果 query 很短或包含特殊符号，sparse 的贡献通常更重要。选择应该由数据集上的 recall@k 和延迟结果决定。

工程落地

两路检索使用同一套 chunk_id 和 metadata，先分别取较宽的候选集，例如 dense 取 30、BM25 取 30，再做去重和 RRF，交给 cross-encoder 对前 40 个候选精排。线上保留各路命中来源和融合分数，便于判断是 dense 漏召回、关键词漏召回，还是融合权重不合适。

常见追问及答案

追问：RRF 和加权分数怎么选？

RRF 对不同检索器的分数标定要求较低，适合快速上线和异构系统；加权分数在有稳定标注集并完成归一化后更可控。两者都要通过离线实验和线上指标验证，不能凭直觉固定权重。

扣分点

• 说 dense 一定优于关键词检索。
• 直接把 BM25 分数和向量相似度相加。
• 没有提到编号、错误码、专有名词等精确匹配场景。
• 只讲“两路并行”，没讲去重、融合和评估。

Q31：query rewrite、multi-query 和 query decomposition 有什么区别？

考察点

考察能否区分“改写一个问题”“扩展多个表达”和“拆成有依赖的子问题”。

回答脉络

先定义三者，再讲选择条件、风险和原始问题保留。

详细参考答案

query rewrite 通常是把一个问题改成更明确、包含上下文的检索表达，结果可以只有一个。例如“这个能报吗”改写为“2026 年差旅政策中，网约车费用是否可以报销”。它主要解决省略、代词、口语和多轮上下文问题。

multi-query 是围绕同一个意图生成多个检索表达，例如分别使用业务术语、用户口语和同义表达，解决文档写法与用户写法不一致的问题。query decomposition 则把复杂问题拆成多个子问题，例如先查“产品 A 的负责人”，再查“负责人所在部门的预算”，后一个问题可能依赖前一个结果。

改写和拆解都有把用户意图改坏的风险，所以系统要保留原始 query、改写结果、拆解关系和每个子问题的依据。没有必要时不要让模型自由扩展事实；可以限制为补充实体、时间、产品和约束，不允许凭空添加条件。

工程落地

先用规则处理明显的对话指代，再用模型生成结构化结果：queries、sub_questions、dependencies、must_preserve_constraints。对简单问题直接单路检索；只有检测到多实体、比较、时间变化或跨文档关系时才启动 multi-query 或 decomposition，并设置子问题数量上限。

常见追问及答案

追问：多查询变多后，结果如何合并？

以 chunk_id 去重，保留命中 query 列表，按融合排名和证据覆盖度排序。如果不同 query 召回了互相矛盾的版本，不能只按出现次数投票，要走版本和权威性规则。

扣分点

• 把 query rewrite、multi-query、decomposition 混为一谈。
• 改写后丢失时间、范围、否定词等关键约束。
• 不限制模型生成的查询数量，导致成本和延迟失控。
• 只看最终答案，不评估改写是否提高召回。

Q32：rerank 的原理是什么，候选集和截断位置如何设置？

考察点

考察是否理解召回和精排的职责边界、cross-encoder 的代价，以及 top_k 不是越大越好。

回答脉络

说明双编码召回的效率优势，再说明 cross-encoder 精排的准确性和成本，最后讲候选集调参。

详细参考答案

向量召回通常可以提前计算文档向量，在线只计算 query 向量并做近邻搜索，速度快但对 query 和文档的细粒度交互建模有限。cross-encoder 会把 query 和候选文本一起输入模型，直接判断二者相关性，通常精度更高，但每个候选都要单独计算，所以不能对整个语料库使用。

我会把流程分为 初召回 top_k1 -> 去重和过滤 -> rerank top_k2 -> 上下文裁剪 top_k3。k1 要足够大以保证召回，k2 受 rerank 延迟预算限制，k3 受模型上下文和答案需要的证据量限制。参数不应照搬别人的数字，要在标注集上观察“相关片段在初召回中是否出现”和“rerank 是否把它排到前面”。

rerank 还要注意文档长度和重复片段的影响。可以先按 parent 去重、合并相邻 chunk，再精排，避免同一段内容占满候选集。对于高风险问答，宁可减少答案覆盖，也不能把低相关但看起来相似的内容塞满上下文。

工程落地

线上记录初召回排名、rerank 排名、最终入 prompt 的 chunk，以及每阶段耗时。设置降级策略：rerank 服务超时就使用初召回的安全子集，而不是无限等待；热点 query 可缓存经过权限分区的候选 ID，但最终权限仍需再次校验。

常见追问及答案

追问：LLM rerank 和专用 reranker 怎么选？

专用 reranker 延迟和输出更稳定，适合高 QPS；LLM rerank 表达能力强，适合复杂语义或低 QPS场景。也可以离线用大模型生成标注或比较结果，线上使用轻量 reranker。

扣分点

• 认为 rerank 就是再次做一次向量搜索。
• 不区分初召回数量和最终上下文数量。
• 没有延迟、超时和降级策略。
• 候选集里全是同一文档重复 chunk 也不处理。

九、复杂问题与结构化检索

Q33：多跳检索怎样设计？什么时候应该停止继续检索？

考察点

考察复杂问题的分解、证据依赖和终止条件，而不是只会循环调用搜索接口。

回答脉络

先识别问题是否需要多跳，再构建依赖图，每跳验证中间结果，最后用覆盖度和置信度停止。

详细参考答案

多跳检索适用于答案不能从一个 chunk 直接得到的任务。例如先根据项目名称找到项目负责人，再根据负责人找到所属部门，最后查询该部门的预算规则。它和“把 top_k 调大”不同：多跳是后一个 query 依赖前一个结果，并且每一跳都有自己的证据。

一个稳妥流程是：解析问题和实体，生成子问题；检索第一跳并抽取结构化中间实体；验证中间实体是否来自可信来源；用已验证实体构造下一跳 query；把每跳证据放入证据图，直到覆盖最终问题的所有约束。每一跳都要保存来源和置信度，不能把模型猜出的实体直接当成事实继续搜索。

停止条件可以包括：所有必需子问题都有支持证据、连续一跳没有新增实体、候选证据质量低于阈值、达到最大跳数或超过延迟预算。若仍无法闭环，应明确说明缺少哪一环，而不是继续随机搜索。

工程落地

用有向无环图表示子问题依赖，节点记录 question、answer、evidence_ids 和 confidence，边表示“下一问题依赖上一步实体”。设置最大跳数、单跳候选数和总 token 预算。对中间实体做 schema 校验和来源校验，最终答案引用覆盖每一条关键推理链。

常见追问及答案

追问：多跳检索失败，优先改模型还是改数据？

先看哪一跳的支持证据缺失。如果原文存在但初召回漏掉，改检索和索引；如果文档本身没有关系表达，考虑结构化数据或知识图谱；如果证据齐全但抽取错误，改 schema、提示和验证器。不能笼统归因于模型能力。

扣分点

• 把多跳检索说成多次无条件搜索。
• 没有保存中间结论的证据。
• 没有最大跳数和停止条件。
• 允许模型猜出的实体污染后续检索。

Q34：GraphRAG 和普通向量 RAG 的边界是什么？

考察点

考察是否知道图结构解决的是关系和全局组织问题，而不是“图一定比向量高级”。

回答脉络

从问题类型、构建成本、维护成本和失败方式比较，给出渐进式选型。

详细参考答案

普通向量 RAG 以文本片段为主要检索单元，擅长回答“哪段内容和问题最相似”。GraphRAG 会从文档中抽取实体、关系、社区或主题摘要，利用图的连接关系组织检索，适合“某人负责哪些项目”“多个实体之间如何关联”“跨多份文档总结一个社区主题”这类关系或全局问题。

GraphRAG 的代价是实体和关系抽取可能出错，图构建、去重、合并和增量维护都比较复杂。图上的错误还可能沿关系传播。它不能替代原文证据，图中的节点和边仍应指向原文位置，以便审计。

我会先用 hybrid RAG 和 metadata 过滤解决大多数局部事实问答；当评估数据明确显示问题需要多跳关系或全局聚合，再引入图索引。也可以采用混合架构：图负责找到相关实体和文档集合，向量检索负责返回可引用的原文 chunk。

工程落地

实体、关系和社区摘要都保存 source_chunk_ids、抽取模型版本、置信度和生效版本。查询路由先判断问题是局部语义、实体关系还是全局总结，再选择向量、图或两者联合。图谱更新不能只更新节点，还要处理删除、关系失效和原文版本切换。

常见追问及答案

追问：知识图谱中的关系比模型抽取的关系可靠吗？

不一定。关系质量取决于来源、抽取和审核。高风险关系要有规则或人工确认；任何关系都应该保留原文证据，不能因为它在图里就默认真实。

扣分点

• 只背 GraphRAG 名词，没有说明它解决哪类问题。
• 认为加一张图就能自动完成推理。
• 忽视图谱构建、更新和错误传播成本。
• 没有把图节点关系绑定到原文证据。

十、召回、精排与端到端评估

Q35：如何构建一套 RAG 评估集？

考察点

考察能否把评估从“随便问几个问题”升级成可分层、可回归的数据集。

回答脉络

覆盖真实分布、困难样本、无答案样本和权限样本，并为每题标注证据而不只标答案。

详细参考答案

评估集中的每条样本至少包含用户问题、用户身份或权限上下文、期望答案、支持文档或 chunk、问题类型、版本和风险等级。问题类型要覆盖事实查找、条件判断、比较汇总、多轮指代、多跳关系和无答案，而不是全是简单 FAQ。

数据来源可以是脱敏真实日志、业务专家编写的问题、历史工单和专门构造的困难样本。每个问题最好有一个或多个可接受证据，并标注关键约束，例如时间、地域、产品版本和否定条件。无答案样本很重要，它用来检验系统是否会诚实拒答。

评估集要拆成开发集、固定回归集和隐藏测试集，避免反复调 prompt 把测试集记住。数据和标注都要版本化，文档更新后说明哪些题目受影响。对于主观答案，可以采用专家评分规则或成对比较，但不能只依赖模型裁判。

工程落地

建立 question_id、corpus_version、expected_evidence_ids、answer_constraints、is_unanswerable 和 access_context 字段。每次索引、模型或 prompt 变更都自动跑固定集，输出分检索阶段、生成阶段和权限阶段的报告，并保留失败样本供人工复盘。

常见追问及答案

追问：没有人工标注，能不能用 LLM-as-a-judge？

可以作为规模化初筛，但要用少量人工样本校准裁判，检查裁判偏好和与人工的一致性。涉及权限、合规和关键事实时，不能只依赖自动裁判。

扣分点

• 评估集只有问题和答案，没有支持证据。
• 没有无答案、版本和权限样本。
• 用同一批问题调参又报告效果，造成数据泄漏。
• 只看平均分，不看困难类别和回归失败。

Q36：recall@k、precision@k、MRR、nDCG 在 RAG 中分别说明什么？

考察点

考察是否能把检索指标和业务含义对应起来，而不是只罗列英文缩写。

回答脉络

先定义指标，再说明召回阶段和精排阶段的关注点不同，最后强调指标要按样本类型切片。

详细参考答案

recall@k 关注前 k 个结果里是否包含至少一个相关证据，适合衡量初召回有没有把答案找回来。precision@k 关注前 k 个结果中相关结果的比例，噪声越多越低。MRR 主要看第一个相关结果出现得有多靠前，适合单证据问答。nDCG 能处理多个相关结果和不同相关等级，适合比较、总结和多证据任务。

实际评估时，召回阶段通常优先保证 recall，精排和最终上下文更关注 precision、MRR 或 nDCG。不能只看 recall@100：如果相关证据在第 100 位，生成阶段可能根本用不到。也不能只看 top1，因为多证据答案可能需要多个 chunk。

指标要按问题类别、语言、文档类型、权限和新旧版本切片。比如总体 recall 提升可能只是简单问题变好，而多跳问题和无答案识别变差。还要结合最终答案的证据忠实度，因为检索命中不等于模型正确使用了它。

工程落地

为每个样本维护相关性标注 0/1/2：不相关、部分相关、直接支持。评估报告同时输出 recall@5、recall@20、MRR、nDCG@10、上下文 token 数和 P95 延迟，并将“相关证据初召回命中但最终答案错误”单独归为生成或证据使用问题。

常见追问及答案

追问：recall@k 越大，k 是否应该一直增大？

不应该。k 增大可能提高召回，但也会提高 rerank、上下文、成本和噪声。最终应在质量和延迟预算下选择拐点，而不是追求单一指标最大化。

扣分点

• 把 recall 和 precision 的含义说反。
• 只会报一个综合准确率。
• 不区分初召回指标和最终答案指标。
• 不考虑多证据、无答案和样本分层。

Q37：如何评估答案是否忠于检索证据？

考察点

考察能否区分“答案正确”“有证据支持”“引用指向正确”这三个不同问题。

回答脉络

把答案拆成可验证 claim，分别检查支持关系、引用正确性和遗漏情况。

详细参考答案

我会把生成答案拆成若干事实 claim，再检查每个 claim 是否能被检索上下文直接支持。答案可能碰巧正确但引用错误，也可能引用存在但模型补充了证据中没有的数字和条件，所以“看起来正确”不能代替 groundedness 检查。

至少要区分：答案与标准答案的正确性、claim 是否被上下文蕴含、引用是否指向支持该 claim 的原文、是否遗漏了关键限制条件、是否把多份冲突资料错误合并。对于数字、日期、阈值和否定词，可以采用规则抽取加人工核验。

还要评估无答案行为。检索没有足够证据时，系统应该说明“当前资料不足”，而不是使用模型参数中的常识填空。拒答率本身不是越高越好，要看它是否在真正无答案的样本上拒答、在有答案的样本上不误拒答。

工程落地

要求模型输出结构化引用，例如每个 claim 绑定 citation_ids。服务端根据 citation_ids 查回原文并做可见性校验，不能相信模型自己写的 URL。对高风险领域增加“引用片段必须包含数字和条件”的校验，校验失败则进入重试或人工审核。

常见追问及答案

追问：让另一个 LLM 判断是否忠实可靠吗？

它适合辅助判断，但应给裁判完整证据、明确评分标准，并用人工样本校准。关键事实可以使用规则、检索证据比对和专家抽检组合，不能把模型裁判当成绝对真值。

扣分点

• 把引用存在等同于引用正确。
• 只比较答案文本，不检查关键条件是否遗漏。
• 没有无答案和拒答质量指标。
• 让模型自由生成不可验证的引用链接。

十一、权限、增量索引与版本回滚

Q38：RAG 的权限过滤应该怎样设计，为什么必须尽量前置？

考察点

考察是否理解检索泄露、租户隔离和“生成后脱敏”并不能补救的问题。

回答脉络

先确定身份和授权，再做候选过滤；生成、引用和日志各自再做一次边界校验。

详细参考答案

权限过滤必须在检索候选进入模型上下文之前完成。因为一旦无权限内容进入 prompt，模型可能从中总结、改写或通过“我不能展示原文”间接泄露其存在。生成后再删敏感字段无法保证没有隐式泄露。

我会把用户身份、租户、角色、部门、资源范围和时间条件解析为服务端生成的授权谓词，再交给检索层执行。查询接口不接受用户直接传入 acl 表达式。召回结果、rerank 输入、最终引用和缓存命中都必须遵守同一权限边界。

缓存尤其容易出问题：如果把未按用户权限分区的答案或候选 chunk 全局缓存，用户 B 可能命中用户 A 的结果。缓存 key 至少要包含租户和权限策略版本，或者只缓存公共知识；权限发生变化时要让旧缓存失效。

工程落地

在服务端形成不可篡改的 AccessContext，检索器只接受这个对象。向量库使用租户分区或 metadata filter，结果返回前再调用授权服务复核。日志记录文档 ID 和策略结果，不在普通业务日志中写入无权原文；定期用越权测试集验证不同角色的召回集合是否相交异常。

常见追问及答案

追问：向量库不支持复杂 ACL 怎么办？

可以按租户或安全域分区，或者先用授权服务生成允许的文档 ID 集合再检索；如果候选集合过大，应在架构上更换支持过滤下推的存储。不能把无权限结果先召回再依赖模型隐藏。

扣分点

• 只在回答展示层做脱敏。
• 忽略租户隔离、缓存和引用链接。
• 允许前端传权限条件。
• 没有权限变更后的缓存失效和审计方案。

Q39：文档增量更新、删除和索引一致性如何保证？

考察点

考察是否能处理生产环境中的更新失败、重复事件、删除传播和最终一致性。

回答脉络

用内容 hash 和事件驱动识别变更，再通过幂等 upsert、软删除或 tombstone、状态机和对账任务保证一致。

详细参考答案

文档更新不能只依赖定时扫描文件夹。系统应识别新增、正文变化、权限变化、重命名和删除等事件。正文变化时重新解析、切分和 embedding；只有 metadata 变化时可以只更新 metadata；删除时要让旧 chunk 不再被查询，同时保留 tombstone 或审计记录，防止迟到的旧事件把它重新写回来。

每个版本的索引任务都要幂等。可以用 document_id + version + chunk_id 作为业务键，写入前检查内容 hash 和状态。异步任务失败要可重试，对账任务定期比较源系统和索引的文档版本，发现缺失、孤儿 chunk 或权限不一致后自动修复或告警。

更新期间要定义可见性语义：是允许读到旧版本，还是必须等待新版本就绪。多数知识库会先构建新版本，校验完成后切换别名；这样避免用户看到半套新索引。

工程落地

用消息队列承载 DocumentChanged 事件，事件携带 event_id、document_id、source_version 和 content_hash。索引流水线用 outbox 或可靠事件机制保证源系统提交和事件发布的一致性，写入完成后更新 manifest。查询只使用当前 alias 指向的已验证版本，删除操作通过状态过滤和物理清理两阶段完成。

常见追问及答案

追问：同一个变更事件重复到达怎么办？

以 event_id 或业务版本做幂等去重，并保证旧版本事件不能覆盖新版本。任务可以重复执行，但结果必须相同。

追问：物理删除失败时是否会泄露？

只要查询过滤已经把该版本标为不可见，短暂的物理残留不会被正常召回；但仍需记录清理失败并设置完成期限，不能把软删除当作永久合规清理。

扣分点

• 只说“重新 embedding”，没处理删除、重复事件和失败重试。
• 没有版本可见性和旧事件覆盖保护。
• 没有对账机制。
• 把最终一致性说成完全实时且无窗口。

Q40：embedding 模型或 chunk 策略升级时，如何灰度和回滚？

考察点

考察索引版本管理、双写、别名切换和可复现性。

回答脉络

新旧索引并存 -> 离线评估 -> 小流量灰度 -> 监控 -> 原子切换 -> 保留旧版本回滚。

详细参考答案

embedding 模型、维度、归一化方式、距离度量或 chunk 策略变化，都可能改变整个检索空间，不能在同一索引里随意混用。应为每套组合建立独立索引版本，记录模型、维度、距离、解析器和切分器版本。

先对新索引做离线评估，比较不同问题类别的 recall、nDCG、引用正确率、延迟和成本。通过后可以双写新增文档，或对全量文档异步重建新索引。线上用租户、用户百分比或固定实验集做灰度，并确保同一个请求只使用一个索引版本，避免结果混杂。

切换时通过 alias 或路由配置原子地把 knowledge_current 指向新索引，同时保留旧索引和 manifest。若线上出现召回下降、越权、延迟异常或成本超预算，直接切回旧 alias；修复后再继续重建，而不是在生产索引上手工改几条向量。

工程落地

给每次索引发布生成 index_release_id，将查询 trace、答案引用和评估结果绑定到 release。切换前执行文档数量、权限覆盖、版本分布和抽样查询校验；切换后观察错误率、无答案率、recall 代理指标、P95 延迟和成本。旧索引保留到新版本稳定且满足合规保留周期。

常见追问及答案

追问：模型维度变了，能不能直接更新原向量字段？

通常不应直接更新。维度和语义空间都变了，应该新建兼容索引；除非底层系统明确支持并且可以保证所有向量和查询配置同步切换。

扣分点

• 在一个索引中混用不同 embedding 模型。
• 没有灰度、alias 和回滚方案。
• 只比较离线答案，不检查权限、延迟和成本。
• 升级后删除旧索引，失去快速恢复能力。

十二、无答案、引用与线上成本

Q41：RAG 如何判断“资料里没有答案”，并避免模型硬编？

考察点

考察是否理解无答案检测是证据覆盖问题，而不是简单看相似度阈值。

回答脉络

综合检索质量、证据覆盖、问题约束和生成后验证，设计拒答和澄清路径。

详细参考答案

相似度高不代表证据足够，模型也可能从相似但不回答问题的文档中推断出不存在的结论。因此无答案判断不能只设一个 cosine 阈值。我会综合判断：候选是否通过权限和时效过滤、是否覆盖问题中的实体和约束、是否有明确支持结论的句子、多个来源是否一致、检索器置信度是否达到阈值。

问题本身不完整时，应先澄清；资料确实不足时，应返回“当前知识库没有足够依据”，说明已覆盖的范围和缺失信息，必要时提供人工渠道。生成 prompt 要明确只允许根据证据回答，不能用参数记忆补充事实；生成后再检查每个关键 claim 是否有引用支持。

拒答也要避免过度保守。阈值应在有答案和无答案样本上校准，分别观察误拒答和幻觉率。不同风险等级可以使用不同阈值：付款、合规和安全问题宁可转人工，普通 FAQ 可以允许更灵活的澄清。

工程落地

设置 answerable、evidence_coverage、conflict_flag 和 abstain_reason 等中间字段。路由分为直接回答、澄清问题、扩大检索、转人工和明确拒答。最终响应除了答案，还返回证据范围和时间边界；拒答原因写入评估日志，便于调阈值。

常见追问及答案

追问：top1 相似度低于阈值就拒答可以吗？

只能作为特征，不能作为唯一规则。不同 query 长度、文档类型和 embedding 模型的分数分布不同，需要校准；还应看多条证据的覆盖和是否存在精确关键词命中。

扣分点

• 把最高相似度直接当作答案置信度。
• 没有澄清、转人工和范围说明。
• 为了提高回答率让模型自由补全。
• 不区分误拒答和幻觉。

Q42：RAG 的引用应该怎样做到真正可验证？

考察点

考察是否能设计从原文到答案 claim 的完整 provenance，而不是只在末尾附几个文件名。

回答脉络

原文定位 -> chunk 证据 -> claim 绑定 -> 服务端校验 -> 前端展示和审计。

详细参考答案

引用不应只是“来源：员工手册.pdf”，而应尽量定位到文档版本、章节、页码或原文偏移。回答先拆成若干可验证 claim，再为每个 claim 绑定一个或多个证据 chunk。引用必须来自本次检索且通过权限校验，模型不能自行编造链接或文档编号。

如果多个来源共同支持一个结论，应展示它们的关系；如果来源存在版本冲突，应分别标出有效期和权威性。对于摘要型答案，引用覆盖所有关键数字、时间、条件和例外，而不是只引用第一段背景介绍。

引用展示和证据存储要分离：用户界面可以显示标题、页码和展开片段，后端则保存 immutable 的 provenance 记录，用于审计和回放。文档被删除或权限变化后，历史回答仍应能说明当时使用的 release，但不能让用户通过历史链接越权读取原文。

工程落地

响应 schema 可以包含 claims: [{text, citation_ids, support_type}] 和 sources: [{citation_id, document_id, version, locator}]。服务端检查 citation 是否属于当前请求的证据集合，检查文档版本和 ACL，再渲染可见引用。离线用“引用存在率、引用支持率、关键 claim 覆盖率”评估质量。

常见追问及答案

追问：为什么不能让模型直接输出页码？

因为模型可能记错或编造页码。页码和 URL 应由检索结果的 metadata 注入，模型只负责选择 citation ID，最终定位由服务端完成。

扣分点

• 只有文档名，没有版本和精确位置。
• 不检查模型生成的引用是否真实存在。
• 忽略引用本身的权限问题。
• 把“有引用”当成“引用支持结论”。

Q43：如何在质量、延迟和成本之间设计自适应检索？

考察点

考察是否能把 RAG 设计成有预算和降级的线上系统。

回答脉络

先做问题分级，再选择检索深度和模型，最后用证据质量触发升级或降级。

详细参考答案

不是每个问题都需要 query decomposition、multi-query、rerank 和多跳检索。可以先用轻量分类器或规则判断问题类型、风险等级和是否需要最新资料：简单 FAQ 走单路 hybrid；术语密集的问题加 sparse；复杂比较问题开启多查询和 rerank；高风险问题要求更高证据覆盖并允许转人工。

每个请求都有明确预算，包括最大检索次数、候选数量、rerank 时间、输入 token、输出 token 和总费用。第一阶段结果不足时才升级检索；达到证据覆盖阈值就停止。检索服务超时可以返回安全的有限结果或明确降级，而不是让生成模型无边界等待。

缓存也应按层设计：query embedding 缓存可以复用向量计算，公共文档的检索候选可以缓存，最终答案缓存必须绑定权限、知识版本和 prompt 版本。缓存命中不能跳过当前权限校验和版本有效性检查。

工程落地

维护 retrieval_policy，根据问题类别配置 top_k、是否 hybrid、是否 rerank、最大跳数和 token 预算。trace 中记录实际走过的策略、升级原因、各阶段耗时和 token。线上同时看答案质量、无答案率、P95 延迟、缓存命中率和每请求成本，避免单独优化某一个数字。

常见追问及答案

追问：缓存了检索结果，文档更新后怎么办？

把 index_release_id 或知识版本放入缓存 key，发布新索引后切换版本自然失效；权限相关结果还要绑定租户和策略版本，不能只按 query 文本做全局缓存。

扣分点

• 所有请求都走最重的检索链路。
• 没有总预算、超时和降级。
• 最终答案做无权限的全局缓存。
• 只看准确率，不看 P95、成本和缓存一致性。

本节常见扣分点

• 把 RAG 等同于向量数据库。
• 不知道 chunk、metadata、rerank、引用和评估。
• 文档有答案却检索不到，或者没答案还硬答。
• 权限过滤做在生成后。
• 不知道混合检索、召回和排序的区别。
• 说不清常见向量数据库的适用场景。