RAG 系统设计深入¶

到 2028，RAG 已经不是“检索加生成”的原型题，而是最能考出候选人 AI 系统工程能力的一类题。因为它天然要求你同时处理 数据、索引、检索、重排、生成、评测、安全、稳定性、成本。

这章解决什么问题¶

很多人会把 RAG 题答成下面两种：

• 只会讲“文档切块 + 向量库 + LLM”
• 或只会背某个框架的实现细节

但真实面试更想听的是：

• 为什么这样分块
• 为什么这样检索
• 为什么需要 rerank
• 如何控制幻觉和权限
• 如何评测质量和上线风险

这一章就是把 RAG 从 demo 讲法升级成生产系统讲法。

先给一个标准答题主线¶

回答 RAG 题时，建议固定按这 7 步走：

1. 需求澄清
2. 数据与索引链路
3. 在线查询链路
4. 检索和重排策略
5. 评测与幻觉控制
6. 稳定性与安全
7. 成本与演进

有了这个主线，就不容易东一榔头西一棒子。

需求澄清时必须问的 6 个问题¶

• 面向内部员工还是外部用户
• 文档规模多大，更新频率如何
• 是否需要权限隔离
• 是否要求引用来源
• 延迟目标是多少
• 更看重准确率、覆盖率还是响应速度

一个典型例子¶

如果题目是“设计企业知识库问答系统”，你可以这样收敛：

假设面向企业内部员工，文档规模百万级，包含 PDF、网页、制度文档和知识库页面。
需要部门级权限控制，回答必须带引用。
峰值 QPS 约数百级，首 token 目标 2 秒内，完整回答 8 到 10 秒内。

这样你后面的设计就有明确边界了。

一张够用的生产级架构图¶

离线链路:
数据源
→ 解析与清洗
→ 去重与权限标注
→ 分块
→ Embedding / 索引构建
→ 向量库 + 倒排索引 + 元数据存储

在线链路:
用户 Query
→ Query 理解 / 改写
→ 权限过滤
→ 混合检索
→ Rerank
→ 上下文压缩与组装
→ LLM 生成
→ 引用与后处理
→ 结果返回

闭环:
日志 / 反馈
→ 评测
→ 数据修复 / Prompt 调整 / 索引更新

你可以根据岗位重点继续展开其中某一层。

离线链路最重要的 4 个点¶

离线链路讲得清不清楚，基本决定了你能不能把 RAG 从“会用”讲到“会设计”。

1. 数据清洗与去重¶

如果数据源里本来就有：

• 重复文档
• 旧版本制度
• 无效页面
• OCR 噪声

那后面再强的检索和生成也会被污染。

你可以讲的设计点¶

• 文档 fingerprint 去重
• 版本字段和生效时间
• 标题、来源、更新时间等元数据抽取
• 解析失败和低质量文本的隔离处理

2. 分块策略¶

分块是面试高频追问点。

常见方案¶

一个更像生产的表达¶

默认我会选递归分块或父子分块，而不是单纯固定长度。
因为企业文档往往有标题层级和段落结构，纯 token 切分容易把关键定义和解释拆开。

3. 索引构建¶

生产里通常不是只有向量库。

更常见的是：

• 向量索引
• 关键词倒排索引
• 元数据过滤索引

如果是关系型知识，还可能有图谱或结构化表。

4. 权限标注¶

企业 RAG 和公开问答最大的区别之一就是权限。

你至少要讲：

• 文档入库时写入 ACL / 部门 / 角色标签
• 在线检索时先做权限过滤
• 结果返回前再做一次校验

这一点非常容易成为面试区分项。

在线查询链路怎么讲更好¶

在线链路最容易暴露工程深度，下面这些点最好按用户请求真正经过的顺序来讲。

1. Query 理解与改写¶

不是所有 query 都应该直接拿去检索。

你可以考虑：

• 意图识别
• query rewrite
• query expansion
• 多 query 检索

但一定要补一句¶

query 改写要做可控开关和离线评测，因为改写过度会引入错误召回。

这是非常像真实工程师的说法。

2. 混合检索¶

2028 的高质量答案里，混合检索几乎已经是默认项。

原因很简单：

• 向量检索擅长语义
• BM25 擅长关键词和精确匹配
• 元数据过滤保证范围正确

一个简洁表达¶

我会采用 dense + sparse 的混合检索。
先保证关键词和编号类信息不丢，再用语义召回补全同义表达和上下文相关内容。

3. Rerank¶

很多候选人会漏掉这一层。

但真实生产里，召回不等于最终上下文质量。

Rerank 的作用是：

• 提高前几条结果的相关性
• 减少 lost-in-the-middle
• 帮助上下文预算更合理

你可以说：

先做高召回，再做高精排，而不是直接把召回结果塞给模型。

4. 上下文组装与压缩¶

这部分越来越重要，因为 token 预算和延迟都很现实。

常见做法：

• 只保留高分片段
• 合并相邻 chunk
• 去掉重复内容
• 做摘要压缩
• 控制最大上下文长度

如果你能讲到这层，答案会成熟很多。

评测怎么讲才像生产系统¶

RAG 面试里，一定不要只说“看用户反馈”。

建议至少拆成 3 层。

1. 检索层评测¶

你可以讲：

• Recall@K
• MRR / NDCG
• Context relevance

2. 生成层评测¶

你可以讲：

• Faithfulness
• Answer relevance
• Correctness
• 引用一致性

3. 端到端评测¶

你可以讲：

• 人工抽样评分
• LLM-as-a-judge
• 用户满意度
• 工单解决率 / 搜索失败率

一个够用的表达¶

我会把 RAG 评测拆成检索、生成和端到端三层。
检索层保证拿到对的上下文，生成层保证回答忠于上下文，端到端再用人工抽样和线上反馈看真实效果。

幻觉控制必须怎么答¶

这是 RAG 题最常见的追问之一。

建议按“多层防线”答。

第一层：检索质量¶

• 分块
• 混合检索
• rerank
• 相关性阈值

第二层：Prompt 约束¶

• 限制只基于检索内容回答
• 找不到信息就明确说不知道
• 要求引用来源

第三层：后处理与校验¶

• 引用检查
• 规则校验
• 结构化输出校验
• 可选 judge 或 NLI 校验

第四层：人工反馈闭环¶

• bad case 回流
• FAQ / 规则修正
• Prompt 和索引策略持续调整

稳定性和降级怎么答¶

这部分非常多人会漏。

你最好固定讲下面这些：

• 检索超时 fallback
• rerank 超时降级
• LLM 失败时返回保守答案
• 缓存热点 query
• 流量高峰时限流
• 关键路径监控和告警

一个合格表达¶

如果向量检索或 rerank 超时，我会降级到关键词检索或直接返回带引用的检索结果摘要，保证服务可用性优先于回答完整性。

权限和安全怎么答¶

企业 RAG 题里，这通常比模型更重要。

重点回答：

• 文档权限如何建模
• 查询时如何预过滤
• 返回前如何二次校验
• 如何防 prompt injection 和越权工具调用

如果系统能访问外部工具，还要补：

• 工具白名单
• 参数校验
• 审计日志

成本和性能怎么答¶

很多 RAG 系统真正的成本大头不只是模型，还包括：

• embedding
• 索引存储
• rerank
• 大模型生成

常见优化手段¶

• 本地 embedding
• 检索和生成缓存
• 小模型做简单任务
• 只在需要时启用高成本 rerank
• 上下文压缩减少 token

一个很实用的面试表达¶

我不会让所有请求都走最重的路径，而是分层：
先用较轻的检索和规则筛掉大部分请求，再把高价值请求送入更高成本的 rerank 和生成链路。

Agentic RAG 怎么讲¶

2028 面试里，RAG 越来越经常和 agent 结合。

适合讲成：

• 简单问答走单轮检索
• 复杂任务走多步检索与工具调用
• 中间结果写入 trace
• 必要时人类确认关键步骤

重点不是“更炫”，而是：

• 为什么单轮不够
• 多步如何控制成本
• 失败时如何回退

一个可复用的结尾¶

当你答完主链路后，可以这样收口：

整体上，这个 RAG 系统的关键不是把模型接上，而是把数据质量、检索精度、生成约束、权限、安全、稳定性和评测闭环一起做起来。
如果继续演进，我会优先补权限治理、bad case 回流和分层成本控制。

这个结尾会让整道题完整很多。

本章小结¶

• RAG 系统设计题的核心不只是“检索 + 生成”，而是整个知识系统和交付链路
• 2028 高质量答案必须覆盖：分块、混合检索、rerank、评测、权限、安全、降级、成本
• 你要把 RAG 当成一个生产系统来答，而不是一个 demo

下一步¶

• 继续看 03-多 Agent 系统设计
• 再看 07-AI 系统设计高频追问与深度题
• 结合 AI编程实战/09-Agentic软件工程项目交付模板 准备项目表达