一个完整的 RAG 系统并非单一模块，而是由多个职责清晰的组件协同工作构成。理解这些组件的划分，有助于在实际项目中合理分工、渐进优化，避免“牵一发而动全身”的混乱。按照从数据到用户交互的流向，可以将 RAG 系统划分为五个核心层次：数据层、检索层、生成层、评估层、应用层。
1. 数据层：知识库的“原料工厂”
数据层负责将原始文档转化为可供检索的结构化形式。它的工作发生在问答之前，属于离线处理阶段。
- 核心任务：文档加载、文本清洗、智能切分、向量嵌入生成，以及这些结果的持久化存储。
- 输入：各种格式的原始文档，如 PDF、Word、Markdown、网页、数据库记录等。
- 输出：存入向量数据库的“文本片段 + 向量 + 元数据”记录集合。
- 常见工具：文档解析器（如 PyMuPDF、Unstructured）、切片策略（按段落、按语义、固定长度等）、嵌入模型（如 text-embedding-3-small、bge-large-zh）、向量数据库（如 Milvus、Pinecone、Weaviate、Qdrant）。
实用要点：切分策略会直接影响后续检索质量。过大的片段可能包含无关噪声，让模型分心；过小的片段又可能丢失上下文。通常需要根据文档类型反复试验，找到平衡点。另外，这一层要保留丰富的元数据（来源文件名、页码、章节标题、更新时间等），为后续溯源提供依据。
2. 检索层：问题到知识的“桥梁”
检索层是用户提问与知识库之间的纽带，负责从海量片段中快速找到最相关的信息。
- 核心任务：接收用户问题，将其转换为向量，在向量数据库中进行相似度搜索，召回 Top-K 个最相关的文本片段，并可选择性地加入关键词匹配、重排序等策略提升精度。
- 输入：用户原始问题文本。
- 输出：一组排序后的相关文档片段及其元数据和相似度分数。
- 关键设计：
- 嵌入模型选择：需与数据层一致，并针对领域语言特点（如中文法律、医学）可能有专用模型。
- 混合检索：纯向量检索可能遗漏精确关键词匹配（如产品型号、条款编号），结合 BM25 等传统检索方法往往能显著提升召回率。
- 重排序（Rerank）：初次召回的片段如果较多，可用更精准但稍慢的模型二次排序，只把最精华的几条送给生成层。
实用要点：检索层是决定“答案是否找得到”的关键。在实际项目中，大量调优精力会花在这里——调整切片大小、选择嵌入模型、调试召回数量、添加重排序步骤，每一项都可能让最终回答质量产生明显变化。
3. 生成层：从片段到自然语言的“翻译器”
生成层利用大语言模型的理解与表达能力，将检索到的片段“消化”成用户可读的自然语言回答。
- 核心任务：构建提示词，将检索到的文本片段与用户问题按模板组装，调用 LLM 生成最终回答，并可附带引用标记。
- 输入：用户问题 + 检索到的相关片段（通常附带来源信息）。
- 输出：结构化的自然语言回答，可包含要点总结、详细解释、引用出处等。
- 关键设计：
- 提示词设计：明确要求模型“仅根据提供的资料回答”，并规定回答格式（如要注明来源）。好的提示词能显著抑制幻觉。
- 模型选择：根据业务需要权衡速度、成本与能力。简单问答可用轻量模型，复杂推理则需要更强的模型。
- 引用整合：可以要求模型在正文中用标记（如
【来源：《员工手册》第3条】）指明依据，系统前端再渲染为可点击链接。
实用要点：生成层本身不存储知识，它的可靠性建立在检索层提供优质素材的基础上。如果检索到的内容无关或错误，再好的模型也可能产出误导性答案。因此这一层的优化常常是“下游受益”——检索做好，生成就轻松。
4. 评估层：系统能力与回答质量的“度量仪”
评估层不是一次性上线就结束的环节，而是一个持续运行的反馈与优化机制。它为系统提供改进方向，判断调整是否真正有效。
- 核心任务：对检索质量、生成答案的事实准确性、完整性、相关性等进行量化评估，并监控线上表现。
- 常见评估维度：
- 检索评估：召回率、精确率、MRR（平均倒数排名）等，回答是否找到了该找到的片段。
- 生成评估：答案与检索片段的一致性（是否存在幻觉）、答案与问题的相关性、是否有未回答的部分。
- 业务指标：用户满意度评分、答案采纳率、人工复核通过率等。
- 实施方式：可以人工标注一部分问答对作为评测集，也可以借助 LLM 本身进行自动评分（LLM-as-judge）。线上则通过日志分析和用户反馈收集信号。
实用要点：没有评估层，优化就是盲人摸象。哪怕只建立一个几十条标注样本的小型测试集，也能在调整切片策略、提示词或检索参数后，快速验证是否有正向提升。
5. 应用层：最终交付的“用户界面与业务集成”
应用层是 RAG 系统与最终用户或下游业务系统的接口，决定了体验和实际价值。
- 核心任务：
- 提供用户提问入口（如聊天窗口、API 接口、企业微信/钉钉机器人）。
- 渲染生成结果，将引用标记转换为可点击的原文链接。
- 收集用户反馈（点赞、点踩、备注），形成闭环。
- 处理会话历史、权限控制、多轮对话上下文管理等交互逻辑。
- 典型形态：内部知识库助手、客服辅助机器人、文档问答 API、合规审查辅助工具等。
实用要点：应用层需要做好的往往不是算法，而是工程与体验细节。例如，当检索层认为相关度不足时，应用层可以决定直接回复“未找到相关资料”，而不是展示低质量答案；又比如用户点击“查看原文”时，能准确定位到 PDF 的具体页码，才能让溯源能力真正落地。
五层协同关系
这些层次并非孤立存在，而是构成了一个清晰的数据流：
数据层提供索引好的知识 → 检索层从知识中找出相关片段 → 生成层将片段转化为答案 → 评估层衡量答案质量并反馈改进 → 应用层将答案交付用户并收集反馈。
每一层都有明确的边界和独立的优化空间。实际项目中，团队可以据此分工：有人专注数据层的文档处理和切片策略，有人负责检索层的向量库与混合检索调优，有人优化提示词和模型调用，有人搭建评测流水线，有人开发前端交互。这种分层设计让 RAG 系统的搭建和维护变得可管理、可演进，而不会成为一个无法理清的庞杂整体。