RAG 系统设计深入¶

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

这章解决什么问?¶

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

只会讲“文档切?+ 向量?+ LLM?- 或只会背某个框架的实现细? 但真实面试更想听的是?
为什么这样分?- 为什么这样检?- 为什么需?rerank
如何控制幻觉和权?- 如何评测质量和上线风? 这一章就是把 RAG ?demo 讲法升级成生产系统讲法?

先给一个标准答题主?¶

回答 RAG 题时，建议固定按?7 步走? 1. 需求澄?2. 数据与索引链?3. 在线查询链路 4. 检索和重排策略 5. 评测与幻觉控?6. 稳定性与安全 7. 成本与演? 有了这个主线，就不容易东一榔头西一棒子?

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

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

一个典型例?¶

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

Text Only

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

这样你后面的设计就有明确边界了?
## 一张够用的生产级架构图

![RAG 生产级架构图](images/rag-system-architecture.png)

*图源：[Google Cloud Architecture Center - RAG infrastructure for generative AI using GKE and Cloud SQL](https://cloud.google.com/architecture/rag-capable-gen-ai-app-using-gke)，许可：CC BY 4.0。*

```text
离线链路:
数据??解析与清??去重与权限标??分块
?Embedding / 索引构建
?向量?+ 倒排索引 + 元数据存?
在线链路:
用户 Query
?Query 理解 / 改写
?权限过滤
?混合检??Rerank
?上下文压缩与组装
?LLM 生成
?引用与后处理
?结果返回

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

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

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

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

1. 数据清洗与去?¶

如果数据源里本来就有? - 重复文档 - 旧版本制?- 无效页面 - OCR 噪声

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

你可以讲的设计点¶

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

2. 分块策略¶

分块是面试高频追问点?

常见方案¶

方案	优点	缺点
固定大小分块	简单稳?	容易切断语义
按段?标题语义分块	保持语义完整	块大小不?
递归分块	通用性强	需要调分隔?
父子分块	检索精度和上下文都较好	系统更复?

一个更像生产的表达¶

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

3. 索引构建¶

生产里通常不是只有向量库? 更常见的是：

向量索引
关键词倒排索引
元数据过滤索? 如果是关系型知识，还可能有图谱或结构化表?

4. 权限标注¶

企业 RAG 和公开问答最大的区别之一就是权限? 你至少要讲：

文档入库时写?ACL / 部门 / 角色标签
在线检索时先做权限过滤
结果返回前再做一次校? 这一点非常容易成为面试区分项?

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

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

1. Query 理解与改?¶

不是所?query 都应该直接拿去检索? 你可以考虑? - 意图识别 - query rewrite - query expansion - ?query 检?

但一定要补一?¶

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

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

2. 混合检?¶

2026/2027 年的高质量答案里，混合检索几乎已经是默认项? 原因很简单：

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

一个简洁表?¶

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

3. Rerank¶

很多候选人会漏掉这一层? 但真实生产里，召回不等于最终上下文质量? Rerank 的作用是? - 提高前几条结果的相关?- 减少 lost-in-the-middle - 帮助上下文预算更合理

你可以说? text 先做高召回，再做高精排，而不是直接把召回结果塞给模型?

4. 上下文组装与压缩¶

这部分越来越重要，因?token 预算和延迟都很现实? 常见做法? - 只保留高分片?- 合并相邻 chunk - 去掉重复内容 - 做摘要压?- 控制最大上下文长度

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

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

RAG 面试里，一定不要只说“看用户反馈”? 建议至少拆成 3 层?

1. 检索层评测¶

你可以讲? - Recall@K - MRR / NDCG - Context relevance

2. 生成层评?¶

你可以讲? - Faithfulness - Answer relevance - Correctness - 引用一致?

3. 端到端评?¶

你可以讲? - 人工抽样评分 - LLM-as-a-judge - 用户满意?- 工单解决?/ 搜索失败?

一个够用的表达¶

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

幻觉控制必须怎么?¶

这是 RAG 题最常见的追问之一? 建议按“多层防线”答?

第一层：检索质?¶

分块
混合检?- rerank
相关性阈?

第二层：Prompt 约束¶

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

第三层：后处理与校验¶

引用检?- 规则校验
结构化输出校?- 可?judge ?NLI 校验

第四层：人工反馈闭环¶

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

稳定性和降级怎么?¶

这部分非常多人会漏? 你最好固定讲下面这些? - 检索超?fallback - rerank 超时降级 - LLM 失败时返回保守答?- 缓存热点 query - 流量高峰时限?- 关键路径监控和告?

一个合格表?¶

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

权限和安全怎么?¶

企业 RAG 题里，这通常比模型更重要? 重点回答? - 文档权限如何建模 - 查询时如何预过滤 - 返回前如何二次校?- 如何?prompt injection 和越权工具调? 如果系统能访问外部工具，还要补：

工具白名?- 参数校验
审计日志

成本和性能怎么?¶

很多 RAG 系统真正的成本大头不只是模型，还包括? - embedding - 索引存储 - rerank - 大模型生?

常见优化手段¶

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

一个很实用的面试表?¶

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

Agentic RAG 怎么?¶

2026/2027 面试里，RAG 越来越经常和 agent 结合? 适合讲成? - 简单问答走单轮检?- 复杂任务走多步检索与工具调用 - 中间结果写入 trace - 必要时人类确认关键步? 重点不是“更炫”，而是? - 为什么单轮不?- 多步如何控制成本 - 失败时如何回退

一个可复用的结?¶

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

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

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

本章小结¶

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

下一?¶

⚠️ 核验说明（2026-03-26）：本页已纳入 2026-03-26 全站统一复核批次。若文中涉及外部模型、API、版本号、价格或第三方产品名称，请以官方文档和实际运行环境为准。

最后更新日期： 2026-03-26