RAG 是什么

RAG 是 Retrieval-Augmented Generation，意思是检索增强生成。它让模型在回答前先检索资料，再基于资料生成答案。

RAG 曾经是 AI 知识库最流行的方案。

它的基本思路很直观：模型本身不知道你的私有资料，所以先把文档放进知识库；用户提问时，系统从知识库里找相关片段；再把这些片段放进上下文，让模型基于资料回答。

这解决了大模型的一个关键问题：模型不能凭空知道你的文档、笔记、制度、项目和历史内容。

RAG 的基本流程

一个典型 RAG 系统通常包含五步。

第一，导入文档。

把 PDF、网页、Markdown、Word、Notion 页面或数据库内容放进系统。

第二，切块。

把长文档切成较小片段，方便检索。

第三，向量化。

用 embedding 模型把文本片段变成向量。

第四，检索。

用户提问时，把问题也向量化，然后找出最相似的文档片段。

第五，生成。

把检索到的片段放进 prompt，让模型基于资料回答。

RAG 适合什么

RAG 很适合知识问答。

例如：

• 产品文档问答。
• 公司制度查询。
• PDF / 报告摘要。
• 客服知识库。
• 法规条款检索。
• 从大量笔记里找相关内容。

这些场景的共同点是：问题相对明确，答案主要藏在资料里。

RAG 的局限

RAG 的局限来自它的结构。

第一，切块会破坏原文结构。

一个观点的定义、背景、例子、反驳和结论可能被切到不同片段里。系统找到了相似片段，不代表理解了整体逻辑。

第二，相似不等于重要。

向量检索擅长找语义相近的文本，但复杂工作常常需要判断优先级、历史演化、概念关系和任务目标。

第三，RAG 主要解决「看什么资料」，不解决「怎么工作」。

它不能天然处理任务拆解、文件写回、工具调用、质量验收、长期记忆更新和工作流管理。

RAG 和 AI OS 的区别

RAG 是知识检索层。

AI OS 是工作系统。

RAG 关心：模型回答时应该参考哪些资料？

AI OS 关心：AI 如何进入你的文件系统、工具、工作流、项目规则和长期记忆？

所以，RAG 可以成为 AI OS 的一部分，但不能代表 AI OS。

RAG 和 Context Engineering 的关系

RAG 是 Context Engineering 的一种技术手段。

Context Engineering 关心的是 AI 执行任务时应该看到什么。

RAG 负责从资料库里找出一部分内容，放进上下文。

但上下文不只包括资料片段，还包括任务目标、角色、输出标准、历史步骤、工具结果和用户偏好。

RAG 还有必要吗

有必要。

但不要把它当成万能答案。

如果你的目标是问答，RAG 很有效。

如果你的目标是长期写作、研究、项目执行、内容生产或个人 AI OS，RAG 只是其中一层。

更完整的系统还需要：

• 文件系统。
• Markdown。
• Skills。
• MCP。
• Agent 分工。
• 工作流。
• 质量验收。
• 结果回写。

一个判断标准

如果你的需求是「从资料里找到答案」，优先考虑 RAG。

如果你的需求是「让 AI 和我一起长期工作」，就不能只停在 RAG。

知识库的终点不是问答，而是可操作的工作系统。