目录
前言：Demo 跑通之后，真正的问题才刚刚开始
一、第一件事不是选向量数据库，而是搞清楚系统到底需要回答什么
二、企业知识入库，难的不只是把文档切成 Chunk
1. 文档解析的重点，是保留回答问题所需要的关系
2. 比 Embedding 更值得提前设计的，是知识的数据契约
三、Wiki 一旦开始频繁更新，RAG 就变成了一套数据同步系统
1. 一次任务完成，并不代表它应该被发布
2. 我更推荐将索引构建与索引发布分开
3. 为什么还要区分“可见”和“已写入”？
四、从“检索到了内容”到“能够回答问题”，中间还差一次证据决策
1. 有些事情应该交给程序，不应该交给模型猜
2. 为什么相关性高，不等于证据足够？
3. 检索策略为什么不能一开始就堆满？
五、LLM 应该负责组织答案，但不应该独自负责所有正确性
1. “有引用”不代表“答对了”
2. 多模态回答还需要处理资源引用
3. 外部知识不能反过来指挥模型
六、即使知识和答案都设计好了，生产环境仍然可能把系统击穿
1. 在线和离线应该具有明确的故障边界
2. 流式输出需要区分“正在生成”和“已经完成”
3. 性能优化应该先知道时间花在哪里
4. 缓存和权限必须一起设计
七、上线前，我真正想验收的是什么？
八、真正成熟的设计，不是从第一天就把所有组件装上
九、如果让我重新设计一套企业 RAG，我会留下这张架构图
十、回到最初的问题：企业为什么不敢让一个能跑的 Demo 直接上线？
参考资料
从一次真实的多模态 RAG 问答问题出发，聊聊企业知识库从 Demo 走向生产，究竟需要怎样的系统设计。
前言：Demo 跑通之后，真正的问题才刚刚开始
假设你正在给一家企业开发内部 AI 知识助手。
公司的知识散落在 Wiki、PDF 操作手册、产品文档和历史故障记录中。员工希望以后遇到问题，不必翻半天资料，直接问 AI 就能获得答案。
于是你搭建了一套标准 RAG：
文档解析、Chunking、Embedding、向量检索、Prompt 组装、LLM 生成。
上传几份 PDF，问几个技术问题，模型不仅能够回答，还能引用对应的文档内容。
演示效果很好。
但等到产品准备推广给售后、研发、客服等部门时，问题开始变得不一样了。
售后问：“为什么原始操作手册有截图，AI 的回答却没有？”
研发问：“Wiki 刚刚修改了，为什么 AI 还在引用旧知识？”
客服问：“V1 和 V2 的手册都在知识库里，怎么保证不会混用？”
管理员问：“这个员工没有研发文档的权限，AI 会不会把内容告诉他？”
运维问：“文档更新失败怎么办？高峰期响应慢怎么办？模型接口超时怎么办？”
这些问题不是把某个参数从 5 改成 10 就能解决的。
Demo 只证明了 RAG 的主链路能够运行，生产交付却要求这条链路在知识变化、权限约束、并发请求和服务故障下，仍然能够可靠工作。
这也是我在参与企业知识库多模态 RAG 开发，以及后续研究知识更新和检索架构时，逐渐意识到的一件事：
企业 RAG 不只是“检索 + 生成”，而是一套持续维护知识状态、组织可信证据并向用户提供答案的系统。
下面我想用一个贯穿全文的企业知识助手场景，把它从 Demo 到正式交付的过程完整推演一遍。
其中，涉及多模态手册处理和 SSH 问答漏图的部分来自我的实际实践；知识版本发布、任务乱序和生产架构等内容，则是基于常见工程约束展开的设计讨论，并非宣称所有方案都已在原项目中上线。
一、第一件事不是选向量数据库，而是搞清楚系统到底需要回答什么
企业知识助手刚开始建设时，很容易直接讨论技术：
Embedding 模型选哪个？Chunk 多大？用哪种检索方式？需不需要 Rerank？
这些问题当然重要，但我认为应该先确定一个更基本的前提：
系统究竟需要帮助什么人，完成什么任务？
例如，同样是技术知识库，用户的问题可能完全不同：
“SSH 默认端口是多少？”——需要准确事实。
“如何通过 SSH 远程登录设备？”——需要可执行的步骤。
“V1 和 V2 的网络配置有什么区别？”——需要跨版本比较。
“为什么设备连接失败？”——可能需要结合错误现象逐步排查。
“下一代产品什么时候发布？”——可能涉及未授权信息，或者知识库根本没有答案。
如果产品没有定义这些问题的成功标准，开发就很难判断系统到底做得怎么样。
我们可以把需求归纳成四个问题：
谁在问？问的是哪个业务对象？需要什么样的答案？这份答案允许使用哪些知识？
以“如何通过 SSH 登录 V2 开发板”为例。
它至少包含几个约束：
用户身份：售后工程师 业务对象：某型号开发板 产品版本：V2 任务类型：操作指导 期望结果：能够按照步骤完成 SSH 登录 知识范围：当前用户有权访问的有效文档一旦把问题定义清楚，很多后续设计就有了依据。
因为这是操作指导，系统需要考虑步骤完整性和相关截图。
因为指定了 V2，检索不能只看语义相似度，还需要关注版本适用性。
因为用户来自售后部门，系统只能使用该用户有权访问的知识。
如果知识库里没有适用 V2 的资料，就不能简单拿 V1 的步骤冒充正确答案。
企业 RAG 的架构，应该从这些约束推导出来，而不是从一张流行的技术架构图倒推业务需求。
二、企业知识入库，难的不只是把文档切成 Chunk
确定了业务任务，接下来才是知识建设。
我们的知识来源可能包括操作手册、研发 Wiki、FAQ、技术公告和历史故障记录。
Demo 阶段，可以把文本提取出来，按一定长度切块，再生成向量。
但生产环境会遇到两个问题：
第一，文档被切碎之后，原始知识关系可能丢失。
第二，同一份知识可能有多个版本、多个来源和不同的访问权限。
这两个问题会影响后面所有环节。
1. 文档解析的重点，是保留回答问题所需要的关系
这一点我有比较直接的体会。
在多模态 RAG 测试中，我使用过一份包含大量操作截图的开发板手册，并让系统回答：
“如何进行 SSH 网络登录？”
原始手册包含几张与操作有关的图片：
查询设备 IP 的终端截图、SSH 登录配置界面、登录成功后的界面。
结果生成的文字步骤基本正确，却只展示了后两张图片。
查询 IP 的终端截图没有出现在最终答案里。
进一步检查原始文档，可以发现这张截图处于跨页位置：前面的操作文字接近上一页末尾，截图位于下一页开头，而且缺乏明显的图注。
这并不能单独证明漏图一定发生在解析阶段，但它暴露了一个值得排查的风险：
图片被成功提取，并不等于图片与正文的关系被正确建立。
如果系统只把文档处理成一组彼此独立的文本 Chunk 和图片资源，后续检索时就可能出现：
找到操作步骤，却不知道应该关联哪张截图。
找到一张截图，却不知道它属于哪个产品版本。
检索到了图片，但最终回答无法定位原始页面。
所以，知识解析不应该只关注内容提取，还要尽可能保留：
文档的章节结构与标题层级；
图片、表格与相关正文的关联；
跨页内容之间的语义连续性；
原始页码、位置与来源标识。
当然，不是所有文档都需要复杂的版面分析。
结构清晰的 FAQ，可以直接按问答单元组织。
但对于操作手册、技术规范、多模态资料，结构关系往往直接影响答案能否完整。
好的 Chunk，不只是长度合适，还应该能够被放回原始知识的上下文中。
2. 比 Embedding 更值得提前设计的，是知识的数据契约
假设系统找到一段文字：
“默认超时时间为 30 秒。”
只看这段内容，我们无法判断它能不能用于回答当前问题。
至少还需要知道：
它来自哪份文档？对应哪个产品和版本？当前是否有效？用户有没有权限使用？原始位置在哪里？
因此，我更倾向于把知识抽象成几类对象：
Document（文档身份） └── Revision（文档版本） ├── Section（章节） │ └── Chunk（检索单元） └── Asset（图片、表格等资源） 另外关联： Source（来源） Permission（权限） Index Generation（索引构建代际）这里有几个概念，最好不要混在一起。
Document ID表示同一份逻辑文档的身份。
Revision表示文档内容的某次修订。
Chunk ID表示解析后用于检索的内容单元。
Asset ID表示可被引用和展示的图片、表格等资源。
Index Generation表示某次索引构建结果。它与业务文档版本不同，因为同一份文档可能在内容不变的情况下，重新切块或更换 Embedding 模型。
例如：
{ "document_id": "device_manual", "revision": "rev_12", "product_version": "V2", "status": "published", "chunk_id": "chunk_023", "section": "网络配置/SSH", "related_assets": ["image_014"], "source_page": 13, "permission_ref": "acl_001", "index_generation": "gen_003" }这是逻辑数据结构示例，不要求所有字段都必须放进同一张表。
不同信息可以存放在不同存储系统中，但它们之间的关联关系必须能够被可靠地维护。
这样设计之后，我们才有能力完成后续工作：
文档更新时定位旧数据。
用户查看引用时回溯原始来源。
查询指定版本时过滤不适用的知识。
图片引用时找到正确资源。
权限变更时限制派生知识的访问。
这里有一个我认为特别重要的认识：
向量索引应该是原始知识的派生检索视图，而不是企业知识唯一的事实来源。
向量负责帮助我们找到相关内容。
但知识的身份、来源、版本、有效性和授权，需要有独立且明确的管理规则。
如果这些东西在入库阶段就没有设计好，后面再去补知识更新、引用校验和权限管理，往往会更加麻烦。
三、Wiki 一旦开始频繁更新，RAG 就变成了一套数据同步系统
到这里，我们已经有了一套可以检索的知识资产。
但企业知识不是静止的。
产品手册会发布新版本，研发 Wiki 会持续修改，管理员也会删除过期资料。
所以企业 RAG 不可能只运行一次文档导入程序。
它需要一条能够持续工作的知识处理流水线。
通常，我们会把耗时较长的解析、切块、Embedding 和索引写入放到异步任务中。
问题也随之出现。
1. 一次任务完成，并不代表它应该被发布
假设某份 Wiki 当前对外可用的修订是 V1。
管理员在 10:00 修改文档，产生 V2。
一分钟后，他再次修改，产生 V3。
系统收到两个更新事件，分别创建任务 A、B。
但由于文档解析和模型调用耗时不同，任务可能乱序完成：
| 时间 | 事件 |
|---|---|
| 10:00 | V2 更新，任务 A 开始 |
| 10:01 | V3 更新，任务 B 开始 |
| 10:03 | 任务 B 完成，V3 索引构建成功 |
| 10:06 | 任务 A 才完成，V2 索引构建成功 |
假设我们的逻辑是：
“任务成功后，直接把当前文档索引替换为本次结果。”
那么 10:06 时，旧任务 A 就可能把已经发布的 V3 回退成 V2。
这不是大模型问题，也不是向量相似度问题。
这是典型的异步任务乱序与并发状态更新问题。
2. 我更推荐将索引构建与索引发布分开
可以把文档处理设计为以下状态：
PENDING ↓ PROCESSING ↓ INDEXED ↓ VALIDATED ↓ PUBLISHED 异常分支： FAILED / SUPERSEDED流程分为两件事。
第一件事：构建。
读取指定 Revision 的内容，解析、切块、生成索引记录。
构建完成后，检查索引数据是否完整、引用关系是否有效。
第二件事：发布。
只有通过校验、且满足当前发布策略的 Revision，才允许成为可检索版本。
这里的关键不是状态名称，而是发布时必须做并发校验。
例如，使用带条件的原子更新或等效机制，保证旧任务不能覆盖已经发布的新版本。
对于要求始终使用最新修订的场景，可以遵循如下规则：
目标 Revision = V3 任务 A 完成 V2： V2 已不是当前目标版本 → 不允许发布 任务 B 完成 V3： V3 构建和校验成功 → 将当前可见版本切换为 V3如果 V3 构建失败，则继续使用上一份已发布且仍允许使用的知识，并将新版本发布失败明确记录下来。
不应该把尚未完成的索引数据直接暴露给在线查询。
3. 为什么还要区分“可见”和“已写入”？
假设一份文档被切成 100 个 Chunk。
系统正在写入新版本，已经完成 60 个，剩余 40 个还没有处理。
如果在线查询可以直接搜索所有新写入的 Chunk，就可能读到一个不完整的新版本。
因此，可以让每个索引记录都关联构建代际，并通过“已发布版本”决定哪些记录可以参与检索。
在线请求只使用符合发布条件的数据。
在单文档维度，这可以避免查询使用未完成的修订；对于跨文档的全局一致性，则需要额外的快照或版本协调机制，不能假设一个文档版本指针就能解决所有一致性问题。
另外还需要考虑两种边界情况。
第一，任务重试。
同一事件可能被多次投递，写入必须尽量具备幂等性。一个常见做法是将 Document ID、Revision 和索引代际作为幂等依据，避免产生重复的有效记录。
第二，文档删除。
删除不能只依赖后台异步清理。对于已经被删除或禁止访问的知识，应该先通过逻辑失效或查询限制阻止继续使用，再异步清理索引、图片资源和相关缓存。
否则，原始文档消失了，向量库中却可能仍然存在可被检索的旧内容。
你会发现，当知识开始持续更新时，RAG 系统实际上已经具备了传统数据流水线的很多特征：
任务调度、状态转换、失败恢复、并发控制和数据一致性。
这部分工程能力，不会因为换一个更强的大模型而自动获得。
四、从“检索到了内容”到“能够回答问题”，中间还差一次证据决策
现在，我们终于拥有一份持续更新、状态明确的知识库。
用户再次提问：
“V2 开发板应该如何通过 SSH 远程登录？”
在线服务开始工作。
第一步不应该只是把整句话转换为向量。
因为这个问题包含三个不同层面的信息：
“V2 开发板”是适用范围。
“SSH”是技术主题。
“如何登录”意味着用户期望获得操作步骤。
因此，在线问答可以分成三个阶段：
确定查询约束 → 获取相关证据 → 组织能够回答问题的内容。
1. 有些事情应该交给程序，不应该交给模型猜
例如用户身份、访问权限、明确指定的产品版本。
这些约束已经可以被结构化表达，就没有必要让模型自由决定。
用户问 V2，应该优先限定适用 V2 的知识范围。
用户没有某份文档的访问权限，就不应该把它交给模型，再指望模型自觉不回答。
这类规则应该由检索服务或授权服务执行。
对于模型难以确定、又会实质影响答案的业务条件，例如用户没有说明设备版本，可以选择进行必要的澄清。
但也不必让每次查询都经过一套复杂的意图识别工作流。
结构化条件能够解决的问题，用确定性逻辑解决；真正需要语义理解的问题，再交给模型处理。
2. 为什么相关性高，不等于证据足够？
假设检索系统返回以下内容：
Chunk A：介绍 SSH 协议 Chunk B：介绍 SSH 远程登录原理 Chunk C：介绍 SSH 的安全特性 Chunk D：介绍设备 IP 查询步骤 Chunk E：介绍 V2 设备登录配置如果只按照语义相似度排序，前三段可能获得不错的分数。
但用户实际需要的是完成一次远程登录。
此时，Chunk D 和 Chunk E 可能比某些高度相关的背景介绍更重要。
对于这类任务，我认为需要明确区分：
相关性：证据和问题是否接近。
适用性：证据是否适用于当前产品、版本和环境。
充分性：这些证据能否支持用户完成当前任务。
它们不是同一个概念。
检索策略主要负责获得相关候选。
业务约束帮助我们确定适用范围。
证据组织则进一步关注回答是否缺少必要信息。
例如，对于操作类问题，可以先抽象出：
目标：完成 V2 设备 SSH 登录 需要覆盖： 1. 获取设备网络地址 2. 配置 SSH 客户端 3. 建立连接 4. 验证是否登录成功然后把检索到的文本、表格和截图关联到相应步骤。
如果某个步骤缺乏证据，系统就有理由继续检索、提示信息不足，或者缩小回答范围。
这并不是说每个问题都必须调用一个额外的 LLM 来做证据规划。
简单事实问答完全可以直接使用检索结果。
但对于多步骤、跨文档和多模态问题，显式组织证据能够带来更可控的回答过程。
3. 检索策略为什么不能一开始就堆满？
语义检索、关键词检索、结果融合和 Rerank 都有各自价值。
例如型号、错误码、接口名称等精确标识，可能更适合关键词匹配。
自然语言表达差异较大的问题，语义检索通常更有优势。
多路候选来源差异较大时，可以考虑融合排序与精排。
但每增加一个阶段，都可能带来额外延迟、计算成本与维护复杂度。
所以更合理的顺序是：
先分析真实问题中哪些证据无法被现有方案可靠找到，再决定是否引入新策略。
企业 RAG 的技术方案不应该由组件数量决定，而应该由证据需求决定。
五、LLM 应该负责组织答案，但不应该独自负责所有正确性
接下来，模型终于拿到了适用的知识。
是不是可以直接生成？
对于普通问答，通常可以。
但如果答案需要满足版本、引用和多模态要求，还需要考虑生成结果是否真正对应所选证据。
1. “有引用”不代表“答对了”
看一个构造例子。
用户问：
“V2 接口的默认超时时间是多少？”
知识库包含：
V1 文档：默认超时时间为 60 秒 V2 文档：默认超时时间为 30 秒模型回答：
“默认超时时间为 60 秒。”
并引用了 V1 文档。
引用确实存在，60 秒也确实写在对应文档里。
但对用户的问题而言，这个答案仍然是错的。
因此，引用校验至少需要关注：
来源是否真实存在；
引用内容是否支持对应结论；
来源的版本与适用环境是否符合当前问题。
对于关键数字、配置参数、版本号等结构化事实，可以考虑使用程序校验与必要的模型辅助检查。
模型负责把证据整理成用户能理解的语言。
系统则应尽量通过确定性规则保证身份、版本、资源和引用关系不被随意改变。
2. 多模态回答还需要处理资源引用
如果答案中需要图片，最好不要让模型凭空构造图片地址。
一种比较稳妥的方式，是给图片资源分配稳定的 Asset ID。
检索和证据组织阶段确定哪些图片可以使用。
模型生成时输出允许引用的图片标记。
后端校验标记确实属于当前证据集合，且用户有权访问，然后再解析为可展示的资源。
例如：
步骤 1：查询设备 IP 地址。 [IMAGE_REF: image_001] 步骤 2：配置 SSH 客户端。 [IMAGE_REF: image_002]这样系统能够明确区分：
图片是否存在；
是否被检索；
是否进入证据集合；
是否被模型引用；
是否成功展示。
但图片并不是越多越好。
真正重要的是，它有没有帮助用户理解和完成当前任务。
3. 外部知识不能反过来指挥模型
还有一条与事实正确性不同的边界。
企业 Wiki 是外部知识来源，不是 System Prompt。
如果某份文档夹带了“忽略原有指令”之类的内容，它应该被当成文档数据，而不是获得控制模型行为的权限。
这就是间接提示词注入的风险。
因此，需要将检索内容明确标记为外部数据，并结合知识源治理、必要的风险检测和输出校验进行防护。
不过，提示词边界并不是绝对安全保证。
尤其对于访问权限、敏感资源等确定性安全规则，必须在模型之外强制执行。
不能把系统必须遵守的安全边界，仅仅写成对模型的一句请求。
六、即使知识和答案都设计好了，生产环境仍然可能把系统击穿
到这里，我们讨论的主要是答案质量。
但企业上线面对的是大量持续发生的请求。
模型服务可能超时，检索服务可能不可用，文档更新任务可能失败，用户还可能在回答生成过程中关闭页面。
这些问题不能再靠 Prompt 解决。
1. 在线和离线应该具有明确的故障边界
离线任务可能需要调用文档解析服务、视觉模型和 Embedding 服务。
在线问答则更关心响应时间和稳定性。
两者可以共享知识存储，但通常不应该互相阻塞。
例如：
离线任务失败，不应该立即影响已经发布的可用知识。
新版本索引尚未构建成功，不应该让所有用户无法查询旧版本。
在线服务则应能够识别检索失败、模型超时和引用资源异常，并返回明确状态。
这里需要注意：降级不等于随便返回一个看起来合理的答案。
当知识证据不足时，可能更适合明确告知无法可靠回答，而不是跳过检索让模型凭自身知识猜测企业内部事实。
2. 流式输出需要区分“正在生成”和“已经完成”
为了降低等待感，RAG 服务经常使用流式输出。
但流式响应还有一个容易忽略的问题：
模型可能已经输出了一半内容，连接却突然中断。
前端如果把这些文字直接当成完整回答，就会造成误导。
因此，流式协议最好具备明确的结束状态。
例如：
STARTED ↓ STREAMING ├── COMPLETED ├── FAILED └── CANCELLED只有收到成功完成信号，客户端才将本次生成视为完整结果。
否则需要提示回答未完成，并提供适当的重新生成或恢复入口。
至于已经产生的部分内容是否保留、是否允许继续展示，则需要根据业务风险决定。
3. 性能优化应该先知道时间花在哪里
一次 RAG 问答可能包含：
身份校验、查询处理、知识检索、候选排序、上下文组装、模型首 Token 等待、持续生成和引用解析。
如果系统响应慢，首先应该拆分这些阶段的耗时。
例如，检索只占很小一部分时间，主要延迟来自模型输出，那么优化检索索引带来的收益就可能有限。
除了平均耗时，还应该关注高分位延迟、超时情况和模型调用成本。
同时，系统需要避免无意义的重复调用。
但也不能为了降低成本就无限压缩上下文，导致关键证据缺失。
质量、延迟和成本需要一起评估，而不是只优化其中一个数字。
4. 缓存和权限必须一起设计
缓存可以降低模型调用与检索成本，但企业知识有版本和权限。
不同员工可能无法访问相同文档。
相同问题在知识更新后，也可能得到不同答案。
因此，缓存命中不能只依赖用户输入的文本是否相同，还需要考虑知识版本、授权范围以及失效规则。
特别是敏感内容，不应该因为另一个用户曾经问过相同的问题，就直接复用他有权限看到的答案。
这再次说明：
企业 RAG 的安全和一致性设计，必须覆盖原始知识、索引、缓存、引用资源和最终回答的完整链路。
七、上线前，我真正想验收的是什么？
现在，系统已经有了知识处理、在线检索、生成回答和服务运行的基本能力。
但要决定能不能给真实用户使用，还需要完成一次系统级验收。
这里我认为最有价值的不是某个综合评分，而是建立一份真正可执行的测试清单。
| 验收维度 | 典型测试场景 | 需要验证什么 |
|---|---|---|
| 知识完整性 | 操作手册跨页图文、复杂表格 | 必要内容和结构关系是否保留 |
| 知识更新 | 连续修改、重复事件、任务乱序 | 旧任务是否会覆盖新版本 |
| 知识删除 | 删除文档后再次查询 | 已失效知识是否仍可被使用 |
| 版本适用性 | V1、V2 文档同时存在 | 是否使用符合问题约束的证据 |
| 权限安全 | 不同部门查询相同问题 | 是否发生越权检索或资源访问 |
| 答案可靠性 | 缺少证据、跨文档问题 | 是否能够正确回答或明确拒答 |
| 服务稳定性 | 模型超时、流中断、检索故障 | 是否存在明确失败状态与恢复方式 |
| 性能成本 | 正常负载和高峰负载 | 延迟、失败率与成本是否满足要求 |
| 可观测性 | 人为构造一次错误引用 | 是否能够定位出错阶段 |
其中，有些问题可以使用自动化测试检查。
例如版本状态、权限约束、图片 ID、接口错误和任务恢复。
有些问题需要业务评测。
例如回答是否完整、操作步骤是否正确、证据是否足够。
这两类测试不应该混为一谈。
模型评估分数再高，也不能证明系统没有权限漏洞；接口测试全部通过，也不能证明最终答案满足用户任务。
因此，我更建议把评估分为三层：
第一层：数据与流程正确性。
验证索引状态、版本、权限、资源引用等确定性条件。
第二层：问答质量。
使用代表性业务问题，检查相关证据、答案完整性、事实支持和任务完成度。
第三层：生产运行质量。
检查响应延迟、错误率、资源成本、更新时效和故障恢复。
这三层共同决定系统能否满足交付要求。
当然，不同业务对这些指标的要求不同。
具体数值应该由产品、业务、安全和技术团队共同确认，而不是开发人员拍脑袋规定一个“企业级标准”。
八、真正成熟的设计，不是从第一天就把所有组件装上
看到这里，可能会觉得企业 RAG 要考虑的东西太多。
那是不是一开始就应该搭建一套非常复杂的平台？
我反而不这么认为。
复杂度应该随着实际约束增长，而不是随着技术名词增长。
例如：
| 设计问题 | 简单方案已经足够时 | 值得进一步升级时 |
|---|---|---|
| 文档处理 | 文档结构简单、来源稳定 | 包含复杂图文关系和多种格式 |
| 知识更新 | 文档量少、更新低频 | 更新频繁、任务并发与成本上升 |
| 检索策略 | 单路检索覆盖主要问题 | 精确标识与语义表达都很重要 |
| 多模态索引 | 图片只需跟随相关文本展示 | 用户会直接根据图片内容提问 |
| 证据组织 | 简单事实查询 | 多步骤、跨文档、版本敏感任务 |
| 生成校验 | 低风险、结构简单的回答 | 关键参数、复杂引用或高风险场景 |
| 服务治理 | 小范围内部试用 | 多部门并发、明确可用性和成本要求 |
但这里有个前提：
简单方案不意味着可以省略基本的安全要求。
如果系统使用了企业私有数据，访问控制和数据保护从一开始就必须成立。
如果业务不能接受错误版本的知识，就必须有适当的有效性约束。
可以分阶段建设高级能力，但不能把必要的正确性和安全边界当成以后再处理的优化项。
我更推荐按照以下方式推进：
原型验证阶段：使用代表性业务问题，证明知识问答确实能够解决需求。
部门试点阶段：补充来源追溯、权限约束、知识更新、反馈渠道和必要的回归用例。
生产交付阶段：完善失败恢复、版本一致性、监控告警、负载测试和安全验收。
持续优化阶段：根据真实失败问题，决定是否增加更复杂的检索策略、增量处理或多模态增强。
这不是严格的项目管理模板，而是提醒我们：
应该先把系统当前承担的责任做好，再为新增的业务责任增加架构复杂度。
九、如果让我重新设计一套企业 RAG，我会留下这张架构图
回顾前面的推演，一套企业 RAG 可以从职责上划分为几个相对独立的部分。
企业知识来源 Wiki / PDF / FAQ / 业务文档 │ ▼ 知识接入与治理 来源、权限、版本、结构解析 │ ▼ 离线知识流水线 清洗 → 切块 → 增强 → 索引构建 │ ▼ 知识发布与存储 原始知识 / 资源 / 可检索索引 │ │ 用户请求 → 身份与业务约束 → 授权检索 │ ▼ 证据选择 │ ▼ 模型生成 │ ▼ 引用与结果校验 │ ▼ 最终回答 横向保障： 权限安全｜版本管理｜监控追踪｜质量评估 任务恢复｜成本治理｜数据删除｜回归测试这张架构图并不要求每一个方框都部署成独立服务。
小型系统完全可以把多个职责放在同一个应用中。
大型系统则可能根据任务负载、扩展需求和团队边界进行拆分。
重要的是职责划分，而不是微服务数量。
离线部分负责让知识持续保持正确和可用。
在线部分负责根据当前用户和问题组织适用证据。
生成部分负责把证据转化为答案，而不是替代权限和版本判断。
横向保障负责确保系统在变化和故障中仍然可以运行、检查和恢复。
我认为，这种划分比某个具体框架的调用链更加重要。
因为具体技术栈会变化，模型会升级，检索方案也可能替换。
但知识生命周期、证据适用性、安全边界和可靠交付这些工程问题不会因为技术栈变化而消失。
十、回到最初的问题：企业为什么不敢让一个能跑的 Demo 直接上线？
因为“能跑”和“可交付”，验证的根本不是同一件事。
Demo 阶段，我们通常验证：
文档能否入库，问题能否检索，模型能否生成回答。
生产阶段，我们还需要回答：
知识更新之后，新版本是否可靠生效？
旧知识失效之后，系统是否还会错误使用？
不同用户提问时，权限范围能否得到保证？
模型生成的关键结论，是否有适用的来源依据？
检索和模型服务出现异常时，系统会怎样表现？
修改索引和 Prompt 后，能否判断整体质量是否改善？
系统运行的性能与成本，是否在业务能够接受的范围内？
这些问题并不要求我们使用最复杂的架构。
恰恰相反，它们要求我们知道：
哪些规则必须可靠执行，哪些工作适合交给模型，哪些复杂度值得投入，哪些地方应该保持简单。
这是我在研究企业 RAG 过程中，逐渐形成的一个重要认识。
最开始，我更多关注怎样让模型从知识库里找到答案。
后来我发现，真正的工程工作还包括如何管理知识、维护版本、处理异常、校验证据，以及在真实业务约束下持续提供服务。
大模型解决的是理解与生成能力，但企业 RAG 的可靠性，需要由整个系统共同承担。
如果让我用一句话总结这篇文章：
一个 RAG Demo 证明了模型能够使用企业知识；一套成熟的企业 RAG，则需要证明知识始终可管理、答案有依据、权限有边界、故障可恢复，并且整套系统值得被长期使用。
这也是为什么，真正把 RAG 做成企业产品，远比跑通一次检索和生成复杂。
参考资料
Microsoft — Design and Develop a RAG Solution
Microsoft — RAG Preparation Phase
Microsoft — Information Retrieval Phase
Microsoft — RAG End-to-End Evaluation
Microsoft — Document-Level Access Control
OWASP — RAG Security Cheat Sheet
本文涉及的架构方案为技术研究与工程设计讨论，不代表全部方案已经在同一生产系统中落地。
