RAG 不是"一种架构"而是"一类架构"——不同应用场景对 RAG 的检索策略、数据管道、生成控制有截然不同的要求。理解场景差异，才能选择正确的 RAG 模式和技术栈。

一句话解释

RAG 的应用场景决定了架构选型——企业知识库、智能客服、智能搜索、文档分析四大场景的 RAG 设计逻辑完全不同。

核心问题

为什么要按场景选型 RAG 架构？

1. 场景决定数据特征：FAQ 是短问答对，技术文档是长篇论述，代码是结构化文本——不同数据需要不同的切分和检索策略
2. 场景决定质量要求：客服场景对幻觉零容忍，内部搜索可以容忍一定的不精确
3. 场景决定延迟要求：在线搜索需要 <1s 响应，文档分析可以接受 10s+ 的处理时间
4. 场景决定成本敏感度：高并发客服系统对每次 LLM 调用的成本敏感，内部工具可以接受更高成本

四大场景架构差异

1. 企业知识库

核心需求：基于企业内部文档（制度、流程、技术规范等）的问答系统。

数据特征：

• 文档类型多样（PDF、Word、Confluence、飞书文档）
• 更新频率中等（月度/季度更新）
• 需要权限控制（不同部门看不同文档）

RAG 架构要点：

维度	推荐方案
文档解析	多格式解析器（PDF/Word/HTML）
Chunk 策略	512 tokens + 语义切分，按文档结构保留层级
检索策略	Hybrid Search + Metadata 过滤（按部门/文档类型）
权限控制	在 Metadata 中嵌入权限标签，检索时做权限过滤
生成控制	要求标注来源文档和段落

典型技术栈：LangChain/LlamaIndex + Chroma/Milvus + Reranker + GPT-4o/qwen-max

与 企业知识库RAG 的关系：该笔记提供了更详细的企业知识库 RAG 实现方案。

2. 智能客服

核心需求：面向外部用户的自动客服系统，结合产品知识库回答用户问题。

数据特征：

• FAQ 对（问题-答案对）是核心数据
• 产品文档和操作手册
• 历史工单和解决方案
• 数据更新频繁（产品迭代快）

RAG 架构要点：

维度	推荐方案
文档解析	FAQ 结构化导入 + 文档解析
Chunk 策略	FAQ 按问答对切分（128-256 tokens），文档按段落切分
检索策略	先做 FAQ 精准匹配，未命中再做文档检索
生成控制	严格忠实度约束，不允许编造；不确定时转人工
多轮对话	指代消解 + 上下文补全（见 Query Rewrite查询改写）
降级策略	置信度低时转人工客服

关键差异：客服场景对幻觉零容忍，必须有"不知道就说不知道"的机制，以及无缝转人工的降级路径。

3. 智能搜索

核心需求：超越关键词匹配的语义搜索，理解用户搜索意图并返回最相关的结果。

数据特征：

• 数据量大（数万到数百万文档）
• 数据类型多样（网页、文档、邮件、消息）
• 实时性要求高

RAG 架构要点：

维度	推荐方案
检索策略	多路召回（向量 + BM25 + 知识图谱）+ RRF 融合
查询处理	Query Routing + Query Rewrite + Multi-query
排序策略	Rerank + 个性化排序 + 时效性加权
结果展示	摘要式展示 + 来源链接，而非直接生成回答
性能要求	P99 延迟 <500ms，需要缓存和索引优化

关键差异：智能搜索更侧重"检索质量"而非"生成质量"，很多时候不需要 LLM 生成，只需要精准的检索排序。

4. 文档分析

核心需求：对大量文档进行深度分析、信息提取和综合推理。

数据特征：

• 长文档为主（合同、论文、报告）
• 需要跨文档推理
• 分析深度要求高

RAG 架构要点：

维度	推荐方案
Chunk 策略	Parent-child Chunk + 大 Chunk（1024 tokens）
检索策略	迭代检索 + 多轮检索（Agentic RAG）
生成控制	长回答 + 详细引用 + 结构化输出
特殊能力	表格理解、图表分析、跨文档对比
延迟容忍	可接受 10-30s 的处理时间

关键差异：文档分析是四个场景中对"推理深度"要求最高的，需要 Agentic RAG 的多轮迭代检索能力。

场景选型决策框架

需求分析
│
├─ 用户是谁？
│   ├─ 内部员工 → 企业知识库
│   ├─ 外部用户 → 智能客服 / 智能搜索
│   └─ 专业分析师 → 文档分析
│
├─ 数据特征？
│   ├─ 短问答对为主 → FAQ 优先匹配（客服）
│   ├─ 长文档为主 → Parent-child Chunk（文档分析）
│   ├─ 海量异构数据 → 多路召回 + RRF（智能搜索）
│   └─ 混合数据 → 分层索引（企业知识库）
│
├─ 质量要求？
│   ├─ 零容忍幻觉 → 严格忠实度约束 + 来源标注（客服）
│   ├─ 允许一定模糊 → 生成式回答（知识库）
│   └─ 需要深度推理 → 迭代检索 + Reflection（文档分析）
│
└─ 性能要求？
    ├─ <500ms → 缓存 + 轻量模型 + 预计算
    ├─ <3s → 标准 RAG 流程
    └─ <30s → Agentic RAG + 多轮迭代

RAG 模式适配

不同场景适合不同复杂度的 RAG 模式：

场景	推荐 RAG 模式	理由
简单 FAQ 客服	Naive RAG	数据量小、问题类型固定，简单流程即可
企业知识库	Advanced RAG	需要 Query Rewrite + Rerank + Hybrid Search
智能搜索	Advanced RAG + Query Routing	多数据源、多查询类型需要路由
文档分析	Agentic RAG	需要多轮迭代检索和推理

跨场景通用组件

无论哪种场景，以下组件是通用的：

• 文档解析：文档解析 — 所有场景的第一步
• 文档清洗：文档清洗 — 数据质量是基础
• Chunk 设计：Chunk设计 — 根据场景调整参数
• 评估体系：RAG评估与优化 — 持续监控和优化

从场景反推架构设计

反向设计思路：从用户场景出发，反推每个环节的技术选型。

场景需求 → 数据特征 → 切分策略 → 检索策略 → 生成控制 → 评估指标

示例：

• 场景：法律合同审查
• 数据特征：长文档、条款间交叉引用、专业术语
• 切分策略：按条款切分 + 20% Overlap + Parent-child
• 检索策略：Hybrid Search + Metadata 过滤（按合同类型/年份）
• 生成控制：逐条引用 + 对比分析 + 风险提示
• 评估指标：Faithfulness（必须高）、Context Recall（条款不能遗漏）

常见误区

• 一种架构打天下：不同场景用同一套配置，导致某些场景效果差
• 过度设计：简单 FAQ 场景用 Agentic RAG，增加不必要的复杂度和成本
• 忽视场景特殊性：客服场景的"转人工"降级路径、搜索场景的延迟要求
• 不从场景出发：先选技术再找场景，而非从场景需求反推技术选型

可继续补充的方向

• 各场景的详细案例研究
• 场景间的架构迁移（如何从 Naive RAG 升级到 Agentic RAG）
• 多场景融合架构（一个系统同时支持知识库和客服）
• 行业特定 RAG 架构（医疗、法律、金融）

关联笔记

• RAG基础 — RAG 基础架构
• 企业知识库RAG — 企业知识库场景的详细方案
• 本地知识库RAG — 本地部署场景的方案
• RAG常见失败模式 — 各场景的常见问题
• RAG评估与优化 — 场景化的评估策略
• AI搜索 — 智能搜索场景