高频面试题（汇总）

高频面试题（汇总）

一般都考察什么

对于知识/记忆/检索的考察表面上在问 RAG、Memory、检索优化、GraphRAG，实际上在考你有没有把一个知识系统拆成下面几层：

1. 知识从哪里来：外部知识库、数据库、搜索、代码仓库、用户记忆、会话状态分别是什么。
2. 知识怎么进系统：解析、切块、索引、权限绑定、增量更新做得怎么样。
3. 知识怎么被取出来：query understanding、hybrid retrieval、rerank、上下文组装是否合理。
4. 模型怎么被证据约束：有没有引用、拒答、groundedness 和 trace。
5. 系统怎么上线：有没有多租户隔离、审计、删除、回放、回归测试。

高频题速览

RAG 基础

• 什么是 RAG？为什么它比直接让模型回答更适合企业知识问答？
• RAG 和微调有什么区别？什么时候用哪个？
• RAG 和长上下文模型谁更好？
• RAG 的核心链路是什么？
• 为什么说 RAG 不是一个"向量库项目"？
• 什么时候不应该上 RAG？
• RAG 的核心指标有哪些？
• 为什么很多 RAG demo 能跑，线上却不好用？

检索优化

• 为什么说 chunking 决定了检索系统的上限？
• chunk size 应该怎么定？
• overlap 有什么作用，为什么不能太大？
• embedding 模型怎么选？
• 为什么 dense retrieval 很强了，生产里还要 sparse？
• Hybrid Retrieval 的本质是什么？
• 为什么很多系统要加 rerank？
• Query Rewrite 的目的是什么？风险是什么？

Memory 与长期记忆

• RAG 和 Memory 最本质的区别是什么？
• 为什么会话历史不等于长期记忆？
• session state、working memory、long-term memory、cache 分别是什么？
• 为什么说 memory 需要写入策略？
• semantic、episodic、procedural memory 分别是什么？
• 长期记忆和用户画像有什么区别？
• 为什么用户记忆不能只靠向量检索？
• 长期记忆怎么做更新、遗忘和删除？

Agentic RAG / GraphRAG

• 什么是 Agentic RAG？
• 什么情况下普通 RAG 不够用？
• 如何证明你的 Agentic RAG 不是"套个 Agent 壳"？
• GraphRAG 和知识图谱问答是一回事吗？
• GraphRAG 的 local search、global search、DRIFT search 分别适合什么问题？
• GraphRAG 一定比 vanilla RAG 强吗？

失败模式 / 治理

• RAG 最常见的失败模式有哪些？
• 为什么说很多 RAG 问题不是模型问题？
• 如何区分召回失败和排序失败？
• 什么是 lost-in-the-middle？
• Prompt Injection 在 RAG 里为什么危险？
• 为什么说 RAG 系统里最严重的问题可能不是幻觉，而是越权？
• 多租户隔离有哪些常见方案？
• 为什么需要 trace、回放和回归测试？

思维导图

一、RAG 基础与边界

:::color1

Q1：什么是 RAG？为什么它比直接让模型回答更适合企业知识问答？

:::

:::color3

A：

RAG 是 Retrieval-Augmented Generation，也就是先从外部知识源中检索证据，再基于证据生成答案 。面试里不要只说"向量检索 + Prompt 拼接"，更高分的讲法应该是：RAG 是推理时访问外部知识，并用证据约束生成的一整条工程链路。

它比直接让模型回答更适合企业知识问答，主要有四个原因：

1. 知识可更新：制度、商品、价格、代码、工单状态都在变，不能每次都靠重新训练模型。
2. 私域知识可接入：企业 wiki、CRM、工单、代码仓库本来就不在底座模型参数里。
3. 答案可追溯：企业场景通常要求引用来源，而不是只给一个"像是真的"的答案。
4. 治理成本更低：相比把所有知识塞进上下文或做频繁微调，RAG 更便于更新、审计和权限控制。

面试里最后一定要补一句边界：RAG 能降低无依据胡说的概率，但不能自动保证正确，仍然需要权限、引用、评测和拒答机制。

:::

:::color2

追问1：怎么解释 parametric memory 和 non-parametric memory？

:::

参数记忆是模型训练进参数里的知识，优点是调用方便，缺点是更新成本高、不可追溯；非参数记忆是外部知识索引，优点是可热更新、可审计。RAG 的核心就是把二者结合起来。

:::color1

Q2：RAG 和微调有什么区别？什么时候用哪个？

:::

:::color3

A：

RAG 主要解决的是推理时访问外部知识 ，微调主要解决的是改模型行为和输出风格。如果知识变化很快、需要来源追溯、属于私域数据，优先用 RAG；如果问题是输出格式不稳定、领域表达不一致、工具调用习惯不好，优先考虑微调。

最稳妥的表述是：RAG 补知识，微调改行为。生产里两者常常一起用，而不是二选一。

:::

:::color1

Q3：RAG 和长上下文模型谁更好？

:::

:::color3

A：

不能绝对比较。长上下文解决的是容量问题 ，RAG 解决的是从大规模候选中选出真正该看的那一小部分。在知识库较小、权限简单、整库放进上下文更省事的时候，直接 long-context 往往更简单；在知识源很大、更新频繁、权限复杂、成本敏感时，RAG 更合适。

更成熟的工程说法不是"谁替代谁"，而是路由：小库直接 long-context，大库走 RAG，复杂任务走"检索 + 长上下文综合推理"。

:::

:::color1

Q4：RAG 的核心链路是什么？

:::

:::color3

A：

面试里最好把 RAG 拆成离线链路和在线链路。

离线链路 ：数据接入 -> 解析与标准化 -> 切块 -> 索引构建 -> metadata 和 ACL 绑定。\

在线链路：查询理解 -> 召回 -> 重排 -> 上下文组装 -> 生成答案 -> 返回引用 -> trace 和回放。

离线链路决定知识能否被正确表征，在线链路决定证据能否被正确使用。

:::

:::color1

Q5：为什么说 RAG 不是一个"向量库项目"？

:::

:::color3

A：

因为向量索引只是召回层的一种实现，真实生产系统还包含：

1. 文档解析与清洗。
2. 切块和 metadata 设计。
3. dense / sparse / hybrid 召回。
4. rerank 和上下文组装。
5. 引用、拒答、权限、审计、评测和回归。

所以更准确的说法是：RAG 是知识访问、证据约束、系统治理和成本控制的组合方案，不是单点向量检索技巧。

:::

:::color1

Q6：什么时候不应该上 RAG？

:::

:::color3

A：

至少有三种典型情况：

1. 知识库很小，直接放进上下文更简单。
2. 任务本质不是补知识，而是改行为，比如格式、风格、分类边界不稳，这更像微调问题。
3. 团队还没有解析、评测和治理能力，这时先上复杂 RAG 很容易把系统做得又慢又不稳。

一句话总结就是：当"选信息"的难度很低时，不一定要上 RAG；当"改模型行为"的需求更强时，也不应该硬上 RAG。

:::

:::color1

Q7：RAG 的核心指标有哪些？

:::

:::color3

A：

一定不要只说"看回答准不准"。更完整的讲法是拆成三层：

1. 检索指标：Recall@k、MRR、nDCG、Hit Rate。
2. 生成指标：正确率、faithfulness、citation accuracy、拒答准确率、hallucination rate。
3. 系统指标：P95 延迟、单问成本、索引更新时间、权限错误率、失败重试率。

高分表达是：RAG 的问题定位必须按链路拆指标，否则你根本不知道问题在召回、排序还是生成。

:::

:::color1

Q8：为什么很多 RAG demo 看起来能跑，线上却不好用？

:::

:::color3

A：

因为 demo 只验证单轮 happy path，而线上会遇到脏文档、表格、代码块、权限、长尾术语、版本冲突、查询分布漂移和性能约束。很多 demo 连引用、回放、ACL、增量更新和回归测试都没有，所以只能证明"能跑"，不能证明"能上线"。

面试里可以用一句话收尾：demo 验证的是可行性，生产系统考验的是稳定性、可追溯性和治理能力。

:::

二、检索链路优化

:::color1

Q9：为什么说 chunking 决定了检索系统的上限？

:::

:::color3

A：

因为召回只能在已有 chunk 上做选择。如果切块时把关键定义、限制条件、表格列、代码函数边界切坏了，后面的 embedding 和 rerank 再强，也只能在坏候选里挑"相对没那么坏"的。

所以 chunk 的本质不是按长度裁文本，而是定义一个可被索引、可被召回、可被引用、可被组装的最小语义单元。

:::

:::color1

Q10：chunk size 应该怎么定？

:::

:::color3

A：

不要背固定参数。正确答法是：根据文档类型、查询类型、上下文预算和评测结果联调。

1. FAQ、短问答更适合细粒度。
2. 制度文档、长流程说明更适合保留结构边界。
3. 表格、代码、合同条款往往需要特殊解析。
4. 起步可以用中等长度 + 适度 overlap，再根据 recall@k、citation precision 和人工评审来调。

面试里要体现的是 trade-off，而不是死记一个 512 或 1024。

:::

:::color1

Q11：overlap 有什么作用，为什么不能太大？

:::

:::color3

A：

overlap 是为了减少边界截断问题，防止定义和限制条件恰好被切在两个 chunk 里。但它不是越大越好，因为 overlap 太大会导致索引膨胀、重复召回、rerank 浪费和上下文冗余。

可以把它理解成一种边界保险机制，而不是默认拉满的参数。

:::

:::color1

Q12：embedding 模型怎么选？

:::

:::color3

A：

不要只看榜单。至少要看下面几个维度：

1. 领域适配。
2. 语言覆盖。
3. query / document 是否区分编码。
4. 向量维度和存储成本。
5. 推理延迟和吞吐。
6. 是否适配你的向量库和索引框架。

更成熟的工程路径是：先用成熟通用模型起步，再用自己的评测集验证是否值得替换。

:::

:::color1

Q13：为什么 dense retrieval 很强了，生产里还要 sparse？

:::

:::color3

A：

dense 擅长语义相似，但对编号、版本号、函数名、报错码、产品代号、长尾缩写这类词面强约束不一定稳。企业知识库里恰好充满这类信号，所以 sparse 仍然很重要。

一句话记忆：dense 保语义，sparse 保词面，hybrid 保稳。

:::

:::color2

追问1：Hybrid Retrieval 的本质是什么？

:::

本质是用多路相关性信号覆盖不同错误类型，让 sparse 负责精确词面，让 dense 负责语义相似，再通过融合和 rerank 得到更稳的候选池。

:::color2

追问2：RRF 为什么常被用来做融合？

:::

因为不同检索器的原始分数往往不可直接比较，而 RRF 只依赖排序位置，稳健、实现简单，对异构检索器友好。

:::color1

Q14：为什么很多系统要加 rerank？

:::

:::color3

A：

首阶段召回追求的是别漏掉好候选，所以偏 recall；rerank 追求的是把最像答案证据的候选排到前面，所以偏 precision。很多系统"能召回来，但用户还是觉得不准"，根因就在 top-k 排序质量不够。

所以可以这样说：hybrid 扩大并稳定候选池，rerank 决定最终 front page 的质量。

:::

:::color2

追问：cross-encoder rerank 和向量召回的关系是什么？

:::

向量召回适合在大规模文档里快速粗筛；cross-encoder 更适合对少量候选做精排序。前者负责"不漏"，后者负责"更准"。

:::color1

Q15：Query Rewrite 的目的是什么？风险又是什么？

:::

:::color3

A：

Query Rewrite 的目标不是润色自然语言，而是把原始问题改造成更适合被检索系统命中的表达。它常见的作用包括：补齐上下文、消歧、显式化约束、改善词项覆盖、拆解复杂问题。

它的最大风险是查询漂移。如果把实体词改偏了，或者错误继承了多轮对话里的历史语境，就会把正确意图带偏。所以高风险场景里最好保留原 query，采用"原 query + rewrite query"双路检索。

:::

:::color2

追问1：rewrite 和 expansion 有什么区别？

:::

rewrite 更强调保留原意并重述；expansion 更强调增加同义词、别名、相关词，扩大召回覆盖面。

:::color2

追问2：HyDE 和 step-back 各适合什么场景？

:::

HyDE 适合原始 query 很短、语义稀疏时，先生成一段"假想答案文档"作为语义锚点；step-back 更适合问题过于具体、词面不稳定时，先上抽象层找基础原理，再回到具体问题。

:::color1

Q16：元数据为什么对检索效果重要？

:::

:::color3

A：

很多业务问题不仅依赖正文，还依赖标题层级、版本号、更新时间、页码、产品线、项目标签、权限标签。没有 metadata，就很难做过滤、排序、引用和 ACL 控制。

所以一个成熟的答法是：正文决定语义，metadata 决定可检索性、可治理性和可引用性。

:::

三、RAG vs Memory 与上下文分层

:::color1

Q17：RAG 和 Memory 最本质的区别是什么？

:::

:::color3

A：

RAG 主要解决外部知识访问与证据提供 ，Memory 主要解决个体化持续信息管理。前者面向世界和业务知识，后者面向用户、任务和经历。

更高分的表达是：二者最大的区别不在"是不是都能检索"，而在于服务对象、更新规律、权限边界和评测方式不同。

:::

:::color1

Q18：为什么会话历史不等于长期记忆？

:::

:::color3

A：

会话历史是原始日志，会话摘要是为了继续推理做的压缩，而长期记忆是经过筛选后留下、未来仍然有复用价值的信息。三者生命周期和用途完全不同。

所以面试里一定要说明：长期记忆不是把聊天记录全存起来，而是对高价值信息做抽取、压缩、写入、检索和淘汰。

:::

:::color1

Q19：session state、working memory、long-term memory、cache 分别是什么？

:::

:::color3

A：

这是非常高频的边界题，可以按四层来答：

1. session state：当前流程运行状态，比如 step、工具参数、中间结果。
2. working memory：当前会话中临时有用的信息，比如对话摘要、当前任务约束。
3. long-term memory：跨会话复用的信息，比如用户偏好、稳定背景、历史决策。
4. cache：为了省成本和延迟复用结果，不代表系统真正"记住了什么"。

一句话记忆：state 管流程，memory 管认知，cache 管成本。

:::

:::color1

Q20：为什么说 memory 需要写入策略？

:::

:::color3

A：

因为不是所有交互都值得存。如果每轮都写，就会出现三类问题：噪声堆积、错误沉淀、隐私风险。memory 的关键不只是怎么查，更是什么时候写、写什么、写到哪一层、是否允许覆盖旧值。

工程上常见做法是：先让模型抽取候选记忆，再通过显著性、稳定性、来源可信度和作用域来筛选是否落库。

:::

:::color1

Q21：semantic、episodic、procedural memory 分别是什么？

:::

:::color3

A：

1. semantic memory：稳定事实和偏好，比如用户喜欢简洁回答、所在行业、岗位方向。
2. episodic memory：过去经历和事件，比如上次尝试过某方案但失败了。
3. procedural memory：做事方式或规则，比如某类任务的固定 SOP、回复模板、审批路径。

如果面试官继续追问，你还可以补充 working memory，表示当前任务中短期有效的临时信息。

:::

:::color1

Q22：什么时候优先走 RAG，什么时候优先查 memory？

:::

:::color3

A：

共享知识、客观资料、可被外部验证的证据，优先走 RAG；与某个用户或某个任务绑定的长期信息，优先查 memory。

举例：

1. "公司报销制度怎么走" -> RAG。
2. "我以后都喜欢你先给结论" -> user memory。
3. "这次审批走到哪一步了" -> session state / working memory。

面试里最关键的是把知识、记忆、状态、缓存这几个边界讲清楚。

:::

四、长期记忆与用户记忆

:::color1

Q23：长期记忆和用户画像有什么区别？

:::

:::color3

A：

用户画像通常只是长期记忆里最稳定、最结构化的一部分，比如偏好、行业、岗位方向；长期记忆还包含经历、计划、失败经验、共享上下文和历史决策。

所以你可以说：profile 是长期记忆的一部分，但长期记忆明显比 profile 更宽。

:::

:::color1

Q24：长期记忆不能每轮都写，那到底该记什么？

:::

:::color3

A：

长期记忆更适合记录五类东西：

1. 稳定偏好。
2. 显式用户事实。
3. 高价值经历和失败经验。
4. 跨会话计划与承诺。
5. 多 Agent / 多角色共享的项目背景。

判断标准是：未来是否高概率复用、是否足够稳定、是否来源可信、是否确实影响后续决策。

:::

:::color1

Q25：哪些信息更适合做常驻记忆，哪些更适合做可检索记忆？

:::

:::color3

A：

高频、短小、稳定、几乎每次都会影响回答的信息，适合常驻记忆；长文本、事件型、低频但重要的经历，更适合做按需检索的长期记忆。

例如：

1. 回答风格偏好、语言偏好、岗位意向 -> 常驻。
2. 历史项目背景、上次为什么否决某个方案 -> 可检索。

这就是常说的resident memory vs retrievable memory 分层。

:::

:::color1

Q26：显式触发写入和自动提炼写入怎么取舍？

:::

:::color3

A：

显式触发精度高但覆盖低，自动提炼覆盖高但风险大。工程上通常是两者结合：显式输入优先级最高，自动提炼只作为候选，再经过规则、阈值、确认或后台审查决定是否落库。

如果面试官问你偏向哪种，你可以回答：高风险字段偏显式，高价值低风险字段可以自动提炼。

:::

:::color1

Q27：如果用户偏好发生变化，你怎么处理？

:::

:::color3

A：

不能简单追加一条新记忆，而是要识别冲突字段，更新旧值，并保留时间戳、来源、版本历史和是否用户显式确认过。

一个成熟的 memory schema 至少应包含：

1. memory_type。
2. key / value。
3. source 和 confidence。
4. created_at / updated_at。
5. status（active / superseded / deleted）。

面试里主动提到 versioning 和 conflict resolution，分会更高。

:::

:::color1

Q28：为什么用户记忆不能只靠向量检索？

:::

:::color3

A：

因为很多高价值记忆本质上是结构化事实，比如 response_style = concise、job_target = backend。这类信息直接按 key 读取更稳。向量检索更适合召回经历型、长文本型、事件型记忆。

所以成熟系统往往是：KV / JSON profile + 文档存储 + 向量检索 的组合，而不是一个向量库包打天下。

:::

:::color1

Q29：长期记忆怎么做遗忘、删除和隐私治理？

:::

:::color3

A：

这是长期记忆最容易被忽略、但实际最重要的问题之一。常见策略包括：

1. TTL 或生命周期分层。
2. 最近使用频率衰减。
3. 冲突覆盖与旧值失活。
4. 用户显式删除。
5. 敏感字段暂停写入和作用域收缩。

一句话总结：长期记忆不是"多存"，而是"有选择地存、可纠错地改、可删除地管"。

:::

:::color1

Q30：怎么评估长期记忆系统好不好？

:::

:::color3

A：

长期记忆比 RAG 更难评测，但至少可以从六个维度看：

1. 写入精度。
2. 召回相关性。
3. 个性化收益。
4. 冲突更新正确率。
5. 删除生效率。
6. 用户满意度。

高分表达不是说"记住得越多越好"，而是强调记忆精度、治理能力和长期一致性。

:::

五、Agentic RAG 与 GraphRAG

:::color1

Q31：什么是 Agentic RAG？

:::

:::color3

A：

Agentic RAG 不是"给 RAG 套一层 Agent 壳"，而是让检索进入 计划 -> 行动 -> 观察 -> 反思 的闭环。也就是说，系统会根据中间结果动态决定：要不要继续查、怎么改 query、是否拆子问题、要不要切换知识源。

所以它的关键不在 Agent 三个字，而在于检索是否变成了一个有决策的迭代过程。

:::

:::color1

Q32：什么情况下普通 RAG 不够用？

:::

:::color3

A：

当问题需要多步取证、跨工具或跨知识源、先查 A 再查 B、或者必须边查边调整策略时，单次 top-k 检索通常不够。

比如：

1. 先查投诉数据，再查 roadmap，再看是否有重合。
2. 先查文档，再查数据库，再回到文档做解释。
3. 先定位问题实体，再围绕实体继续扩展检索。

这种场景本质上已经不是单跳问答，而是检索驱动的任务求解。

:::

:::color1

Q33：怎么证明你的 Agentic RAG 不是"套个 Agent 壳"？

:::

:::color3

A：

要说明它的检索策略会随着中间结果变化，而不是固定调用一次 retriever。比如：

1. 先判断问题复杂度。
2. 对复杂问题做 decomposition。
3. 针对不同子问题路由不同知识源。
4. 如果证据不足，再改 query 或继续追检。
5. 最后对证据链做校验。

只要你讲出了"中间结果会反过来影响后续检索动作"，这就不是简单套壳。

:::

:::color1

Q34：GraphRAG 和知识图谱问答是一回事吗？

:::

:::color3

A：

不完全是。GraphRAG 更强调从原始文本中自动抽取实体、关系和 claims，构建图结构，做 community detection，再基于社区报告和图搜索来回答问题。

所以它不是简单地"把知识图谱接到 RAG 前面"，而是在知识表示层做结构化增强，特别适合多跳关系和全局主题问题。

:::

:::color1

Q35：GraphRAG 的 local search、global search、DRIFT search 分别适合什么问题？

:::

:::color3

A：

1. local search：适合围绕某个实体或局部主题做细粒度关系推理。
2. global search：适合整库主题概览、宏观总结、跨社区综合。
3. DRIFT search：先从全局社区信息出发，再逐步收缩到局部细节，适合既要背景又要落地细节的问题。

面试里如果能把这三个模式讲清楚，通常说明你不是只听过 GraphRAG 这个词。

:::

:::color1

Q36：GraphRAG 一定比 vanilla RAG 强吗？

:::

:::color3

A：

不一定。只有在任务确实依赖实体关系、多跳推理、跨文档关系网络或全局主题总结时，GraphRAG 才更可能带来收益。对简单定位题、FAQ、条款检索题，GraphRAG 可能更慢、更贵，还可能引入图噪声。

所以更成熟的说法是：GraphRAG 是条件性增强，不是默认替代方案。

:::

:::color1

Q37：GraphRAG 的主要成本在哪？

:::

:::color3

A：

主要有五类成本：

1. 实体和关系抽取。
2. 实体归一化。
3. 图构建和社区检测。
4. 社区报告生成。
5. 增量更新和线上查询复杂度。

所以图方案的真正门槛不在"能不能搭"，而在"图构建质量和维护成本是否值得"。

:::

:::color1

Q38：Agentic RAG 和 GraphRAG 是替代关系吗？

:::

:::color3

A：

不是。Agentic RAG 解决的是检索过程层 的问题，GraphRAG 解决的是知识表示层的问题。一个系统完全可以同时是 Agentic 的，也是 Graph-based 的。

比如 planner 先判断这是一个关系密集问题，于是路由到 GraphRAG 的 local search；如果还需要原文验证，再补一次普通文档检索。这才是更接近真实生产系统的组合方式。

:::

六、失败模式、安全与治理

:::color1

Q39：RAG 最常见的失败模式有哪些？

:::

:::color3

A：

不要只答"幻觉"，要按链路拆：

1. 解析失败。
2. 切块失败。
3. 召回漏失。
4. 排序错误。
5. 上下文组装失败。
6. 生成不受证据约束。
7. 知识过期和版本冲突。
8. 权限误配置。
9. Prompt Injection / 检索投毒。
10. 评测盲区。

面试里最关键的是体现你的分层排障意识。

:::

:::color1

Q40：为什么说很多 RAG 问题不是模型问题？

:::

:::color3

A：

因为很多错误在模型回答之前就已经发生了：文档没解析对、chunk 切坏了、gold evidence 没召回、rerank 没排上来、上下文组装把关键证据淹没了。模型只是最后一个暴露问题的环节。

所以排障时一定要先问：证据在不在、证据有没有被召回、证据有没有被模型真正读到。

:::

:::color1

Q41：如何区分召回失败和排序失败？

:::

:::color3

A：

看正确证据是否出现在更大的候选集合里：

1. 如果 top-50 里有、top-5 没有，通常是排序问题。
2. 如果 top-50 都没有，通常是召回问题。

这是非常经典的面试追问，答对说明你会做链路定位，而不是只会说"继续调模型"。

:::

:::color1

Q42：什么是 lost-in-the-middle？为什么加入更多 chunk 不一定更好？

:::

:::color3

A：

lost-in-the-middle 指的是关键信息虽然在上下文里，但被放在长上下文中部，模型没有有效利用。加入更多 chunk 不一定更好，因为它会带来：

1. 噪声变多。
2. 重复内容变多。
3. 关键证据被稀释。
4. 成本和延迟上升。

所以不是"塞得越多越好"，而是怎么把最关键的证据放到最有效的位置。

:::

:::color1

Q43：知识过期和版本冲突怎么处理？

:::

:::color3

A：

要在索引层和生成层同时处理：

1. 文档写入版本字段和更新时间。
2. 默认偏向最新文档。
3. 旧版本显式失活。
4. 建立增量更新和缓存失效机制。
5. 关键场景下在答案里展示生效日期。

如果不做这些，RAG 的"时效性优势"就会变成"把过期知识说得更像真的"。

:::

:::color1

Q44：Prompt Injection 在 RAG 里为什么危险？

:::

:::color3

A：

因为恶意文档可能被检索进上下文，再借助模型对指令的服从性来操纵后续行为，或者污染答案。RAG 把外部内容拉进 prompt，本身就扩大了攻击面。

最基本的防护思路包括：

1. 来源可信度分层。
2. 内容清洗与安全过滤。
3. 生成阶段显式忽略文档中的操作性指令。
4. 高风险场景做 groundedness 检查和人工审批。

:::

:::color1

Q45：为什么需要 trace、回放和回归测试？

:::

:::color3

A：

因为没有中间过程可见性，就无法知道问题到底出在哪一层，也无法稳定复现修复效果。RAG 不是普通黑盒问答系统，它天然需要链路可观测。

一套成熟的 trace 至少要记录：

1. 原始 query 和 rewrite query。
2. 过滤条件和 ACL。
3. 召回候选和 rerank 结果。
4. 最终注入上下文。
5. 生成答案和引用。

回归测试则要按错误类型建桶，覆盖解析、召回、排序、权限、安全和最终回答。

:::

:::color1

Q46：为什么说 RAG 系统里最严重的问题可能不是幻觉，而是越权？

:::

:::color3

A：

因为幻觉大多是质量问题，而越权是安全和合规问题。一次错误暴露私域信息，系统可能直接无法上线。

所以企业知识 Agent 的底线通常不是"必须百分百答对"，而是绝不能把不该看的东西检出来、拼进去、生成出来。

:::

:::color1

Q47：多租户隔离有哪些常见方案？

:::

:::color3

A：

常见有三种：

1. 独立库 / 独立集合 / 独立索引：隔离最强，运维成本更高。
2. namespace / shard / partition 隔离：隔离和效率之间的折中。
3. 单集合 + tenant_id / payload filter：资源利用率高，但对查询过滤和审计要求更高。

面试里一定要体现：没有唯一最佳方案，关键看租户规模、隔离强度和运维成本。

:::

:::color2

追问1：为什么不建议只做后过滤？

:::

因为后过滤意味着越权结果可能已经被召回、进入日志、缓存或 rerank，同时还会损失 top-k 质量。更安全的方式是 tenant 和 ACL 在检索前就下推过滤。

:::color2

追问2：ACL 应该挂在哪里？

:::

至少要能从 chunk 追溯到源文档，并在查询时基于文档级或 chunk 级 ACL 做过滤。权限设计必须从 ingest 阶段就跟随 chunk 一起下沉。

七、面试里的项目表达模板

:::color3

项目表达模板：

我们没有把系统简单做成"向量库 + 大模型"，而是把它拆成四层：当前流程状态放 session state，当前会话的临时结论放 working memory，用户偏好和跨会话信息放 long-term memory，企业制度和文档走 RAG。检索链路上我们先做结构化解析和 metadata 保留，再用 hybrid retrieval 保 recall，用 rerank 提 top-k 质量，最后在生成阶段加引用和拒答约束。上线前我们重点补了 ACL、trace、回放和回归测试，因为企业场景里最危险的不是答错，而是越权。

:::