最近两年，似乎所有企业，都在追AI的风口，很多企业都在做 AI 知识库、智能客服、问答助手、文档助手、研发助手、运营助手、决策建议等。技术方案听上去似乎也都很统一：把企业文档接入大模型，做一个 RAG 系统。
很多团队一开始觉得这件事不难：
不就是把文档切片，丢进向量数据库，然后用户提问时检索相关内容，再把内容塞给大模型回答吗？
从 Demo 角度看，确实不难。用 Spring Boot、LangChain4j、Spring AI、向量数据库，再接一个大模型 API，几天就能跑起来。
但真正进入企业生产环境后，很多团队会发现：
RAG 实现最难的，根本不是调用大模型，而是数据治理、检索质量、权限控制、效果评估和工程化落地。
一、先说清楚：RAG 到底是什么？
从事AI开发，RAG是必修课。它的称是 Retrieval-Augmented Generation，中文通常叫：检索增强生成。
简单来说，它的核心思想是：
大模型本身不一定知道你的企业内部知识，所以先从企业知识库里检索相关资料，再把资料和用户问题一起交给大模型，让大模型基于这些资料生成答案。
一个典型 RAG 流程大概是这样的：
1. 上传文档，例如 PDF、Word、Markdown、网页、数据库记录。
2. 系统解析文档内容。
3. 把文档切成多个文本片段，也就是 Chunk。
4. 对每个 Chunk 做 Embedding 向量化。
5. 把向量和原文存入向量数据库。
6. 用户提问时，先把问题也做向量化。
7. 在向量数据库中检索相似内容。
8. 把检索到的内容和用户问题拼成 Prompt。
9. 调用大模型生成答案。
10. 返回答案，并最好附带引用来源。
这个流程看起来很清晰，甚至有点像传统搜索引擎加大模型总结。
但问题在于：Demo 里的每一步，到了企业环境都会变复杂。
二、Demo 很简单，生产很困难？
很多小公司，直接找个能做AI开发的程序员，先折腾一番，搞个Demo出来，看起来效果很好，这几把都是在以下的理想条件下，如：
文档数量少 文档格式统一 内容质量高 没有权限控制 用户问题简单 不考虑成本 不考虑并发 不考虑答案准确率评估 不考虑数据更新 不考虑安全合规
但真实的企业使用环境完全不是这样，企业知识库里的数据通常是这样的：
有 PDF、Word、Excel、PPT、网页、飞书文档、数据库记录等。 文档里有表格、图片、代码块、标题、脚注、目录、页眉页脚。 很多文档已经过期，但没人维护。 同一个问题在不同文档里有不同版本的答案。 有些知识只能给部分部门看。 用户提问方式非常随意。 业务人员希望答案准确，研发希望接口稳定，老板希望成本可控。
所以，RAG 落地不是简单地“接入大模型”。它更像是一个结合了 搜索系统、知识管理系统、权限系统、推荐系统、NLP 工程和后端架构 的综合项目。
那么，难点在哪里？
一
文档解析，比你想象中复杂得多
很多人做 RAG 的第一步就是文档上传。听起来很简单：用户上传一个 PDF，解析出文本，切片，然后入库。但企业文档常常不是纯文本。
1. PDF 不等于文本
PDF 分很多种：
原生文本 PDF 扫描版 PDF 图片型 PDF 带复杂表格的 PDF 带多栏排版的 PDF 带页眉页脚和水印的 PDF
如果是扫描版 PDF，就需要 OCR。
如果是复杂表格，普通文本提取会直接把表格结构打乱。
如果是多栏排版，解析出来的文本顺序可能是错的。
一旦文档解析质量差，后面的向量检索和大模型回答都会受到影响。
垃圾进，垃圾出。
RAG 服务不是魔法。前面解析错了，大模型只会基于错误内容一本正经地胡说。
2. Word、Excel、PPT 各种坑
Word 文档里可能有：
标题层级 表格 图片 批注 页眉页脚 超链接 嵌入对象
Excel 里可能有：
多个 Sheet 合并单元格 复杂表头 公式 隐藏行列 备注 结构化数据
PPT 里可能有：
文本框 图表 流程图 图片 演讲备注 页内元素顺序问题
这些内容如果简单地全部转成纯文本，很多上下文信息都会丢失。
例如以下的 Excel 表格：
产品 价格 适用客户 A 套餐 999 元 小微企业 B 套餐 2999 元 中型企业
大模型未必能正确理解表格结构。
所以企业 RAG 的第一道门槛就是：文档解析不能只追求“能读出来”，还要尽量保留结构。
二
文本切片不是随便切 500 字
很多教程里会告诉你：把文档按固定长度切，如每 500 个字符切一段，每段重叠 50 个字符。
这个方法适合 Demo，但不一定适合企业知识库。
1. 切片太短，上下文不完整
例如原文是：
申请退款需要满足以下条件：1. 订单支付成功；2. 未超过 7 天；3. 商品未发货；4. 企业客户需要提交审批单。
如果切片时把“申请退款需要满足以下条件”和具体条件切开，那么用户问：
企业客户怎么申请退款？
系统可能只召回到部分条件，导致答案不完整。
2. 切片太长，检索不精准
如果一个 Chunk 太大，里面混合了很多主题：
退款规则、发票规则、合同规则、售后规则、审批规则……
用户只问“发票怎么开”，向量检索可能召回这个大段内容，但里面噪声很多。大模型最终生成的答案也容易跑偏。
3. 更合理的切片方式
企业 RAG 更推荐按照文档结构切片：
按标题层级切 按段落切 按表格切 按 FAQ 问答对切 按业务模块切 按语义边界切
例如：
一级标题：售后政策二级标题：退款规则三级标题：企业客户退款流程内容：……
切片时应该保留标题路径：
【售后政策 > 退款规则 > 企业客户退款流程】企业客户申请退款需要……
这样用户搜索“企业客户退款”时，召回效果会明显更好。
三
Embedding 不是越贵越好，向量检索也不是万能
RAG 的核心之一是 Embedding，也就是把文本变成向量。很多人会误以为：只要用了好的 Embedding 模型，检索效果就一定好。
实际不是。
1. 向量相似不等于业务相关
向量检索擅长找语义相近的内容，但企业问题常常需要非常精确的业务匹配。
例如用户问：企业版套餐支持多少个子账号？
知识库里有两段内容：
企业版套餐支持最多 100 个子账号。
专业版套餐支持最多 50 个子账号。
这两段在语义上非常相似。
如果检索策略不够精细，很可能把专业版内容也召回。
这时候，大模型可能会混合两个答案，最后回答出一个错误数字。
2. 关键词检索仍然很重要
很多企业 RAG 系统不能只靠向量检索，还需要结合关键词检索。尤其是下面这些场景：
产品型号 API 名称 错误码 订单号 合同编号 配置项 专有名词 人名、部门名 版本号
例如用户问：
ERR_10027 是什么错误？
这种问题用关键词检索可能比向量检索更靠谱。
所以实际工程中常见的方案是 混合检索：
向量检索负责语义相似 关键词检索负责精确匹配 业务过滤负责权限、分类、时间、版本 重排序模型负责最终排序
3. 召回之后还需要重排序
向量数据库返回 TopK 结果，并不代表前几个就是最适合回答问题的内容。
更稳妥的方式是：
先召回较多候选内容，例如 Top 20。 再用 Rerank 模型进行重排序。 最终选出 Top 3 到 Top 5 作为上下文。
这个过程能明显提高答案质量。
简单说：
“向量检索负责“找一批可能相关的”，Rerank 负责“从里面挑最相关的”。”
四
权限控制，是企业 RAG 绕不开的问题能
Demo 项目里的知识库通常默认所有人都能看所有文档。但企业里绝对不能这样。
不同员工提问时，系统不能把他无权查看的文档内容拿出来给大模型总结。否则就会出现严重的数据泄露问题。
1. 权限控制不能只放在前端
有些团队会想：前端隐藏无权限文档就行了。
这是不够的。
RAG 权限控制必须在服务端检索阶段完成。
也就是说，用户提问时，系统必须根据用户身份过滤可访问的知识范围：
用户所属部门 用户角色 用户所在租户 用户项目权限 文档密级 文档所属空间 文档可见范围 文档 ACL 权限列表
只有用户有权限访问的 Chunk，才能进入召回结果。
2. 权限粒度可能细到 Chunk
企业文档权限有时候不是文档级，而是段落级、章节级。
例如一份项目文档里：
项目背景可以公开 成本预算只有管理层可见 客户联系人只有销售团队可见 技术架构只有研发团队可见
如果系统只做文档级权限，就可能出现越权风险。
当然，Chunk 级权限实现成本更高，但对于金融、政企、医疗、法律等场景，往往是必须考虑的。
3. 大模型调用前也要脱敏
即使检索结果符合权限，也可能包含敏感信息：
手机号 身份证 银行卡 客户姓名 合同金额 内部密钥 Token 数据库连接串
这些内容是否可以直接发送给外部大模型，需要严格评估。
一般企业都会要求：
敏感字段脱敏 私有化部署模型 请求日志加密 不允许第三方模型保留数据 不允许训练使用企业数据
所以，企业 RAG 不只是技术问题，也是安全合规问题。
五
Prompt 拼接不是简单字符串拼接
很多 RAG Demo 的 Prompt 是这样写的：
请根据以下资料回答用户问题：资料：{context}问题：{question}这种方式能跑，但很难稳定。
1. Prompt 需要约束大模型行为
企业知识库问答最怕大模型胡编。所以 Prompt 里必须明确规则：
你是企业***助手。请严格基于给定资料回答问题。如果资料中没有答案，请回答“根据当前知识库资料无法确认”。不要编造不存在的政策、流程、数字、链接或联系人。回答时请尽量引用资料来源。
这些约束很重要。
如果不告诉大模型“不能编”，它很可能会根据常识补全答案。
但企业问答不能靠常识，必须靠企业内部资料。
2. 上下文不是塞得越多越好
有些团队为了提升准确率，会把很多检索结果全部塞进 Prompt。
但上下文太多会带来几个问题：
成本变高 响应变慢 噪声变多 模型注意力分散 更容易混淆答案
RAG 不是把所有资料都扔给大模型，而是要把 最相关、最干净、最有依据 的内容传给大模型。
3. 最好要求答案带引用来源
企业知识库问答里，答案是否正确很重要，但答案是否可追溯同样重要。
建议答案返回时带上来源：
根据《企业客户退款流程 V3.2》第 4 节，企业客户退款需要提交审批单，并由客户成功经理确认后进入财务退款流程。
这样用户可以点击查看原文，也方便排查问题。
如果用户不相信 AI 的答案，他至少可以相信原始文档。
六
知识更新和版本管理很容易被低估
企业知识不是一次导入后就不变了。现实中，知识库一直在变化：
产品价格变了 政策规则变了 API 文档更新了 流程审批人换了 老文档废弃了 新文档上线了 同一份文档有多个版本
如果 RAG 系统不处理版本问题，很容易回答过期内容。
1. 文档更新后，向量索引要同步更新
一份文档更新后，对应的 Chunk 和向量也要更新。
常见做法是：
文档内容变更。 计算文档版本号或 Hash。 找到旧 Chunk。 删除旧向量。 重新切片。 重新 Embedding。 写入新向量。 更新索引状态。
这个过程需要任务队列和状态管理，不能简单同步执行。
2. 过期知识必须下线
很多 RAG 系统效果差，不是因为召回不到内容，而是因为召回了太多旧内容。
所以每个知识片段最好带上元数据：
文档 ID 文档标题 文档版本 创建时间 更新时间 生效时间 失效时间 所属业务线 所属产品 所属部门 可见范围 数据状态
检索时可以根据元数据过滤：
只检索当前有效版本只检索用户所属业务线只检索最近更新时间较新的文档
这比单纯依赖向量相似度更可靠。
七
效果评估不能靠“感觉还不错”
很多开发做完 RAG Demo 后，会找几个人问几句：
感觉回答还可以。
这不叫评估。
企业 RAG 必须建立一套评估体系，否则你不知道系统到底有没有变好。
1. 至少要评估两个指标
RAG 的效果可以分成两层：
第一层是 检索效果：
有没有召回正确文档？ 正确内容是否排在前面？ 有没有召回无关内容？ TopK 是否足够？ Rerank 是否有效？
第二层是 生成效果：
答案是否准确？ 答案是否完整？ 是否基于资料回答？ 是否出现幻觉？ 是否引用正确来源？ 表达是否清晰？
很多人只看最终答案，但最终答案错了，不一定是大模型错，也可能是检索错了。
2. 建议准备标准测试集
企业可以整理一批典型问题：
问题：企业客户如何申请退款？标准答案：……标准引用文档：……标准 Chunk ID：……
然后每次优化后跑一遍评测。
这样才能知道：
换 Embedding 模型有没有提升？ 调整 Chunk 大小有没有提升？ 加 Rerank 有没有提升？ 改 Prompt 有没有提升？ 加关键词检索有没有提升？
没有评测集，RAG 优化就会变成玄学。
八
成本和性能会直接影响能不能上线
RAG 系统上线后，成本主要来自几个地方：
Embedding 模型调用成本 大模型调用成本 Rerank 模型调用成本 向量数据库存储成本 文档解析成本 OCR 成本 推理服务器成本 网络和存储成本
如果每次用户提问都召回大量内容，然后塞给大模型长上下文，成本会迅速上升。
1. 成本优化思路
常见优化手段包括：
缓存热门问题答案 缓存 Embedding 结果 控制 TopK 数量 控制上下文长度 对简单问题使用小模型 对复杂问题使用大模型 对低价值文档降低索引频率 批量处理文档向量化 异步处理文档导入 对用户请求做限流
2. 性能优化思路
RAG 请求链路通常比普通接口更长：
用户问题 -> 问题改写 -> Embedding -> 向量检索 -> 关键词检索 -> Rerank -> Prompt 构造 -> 大模型生成 -> 答案后处理 -> 返回结果
这里任何一步慢，用户都会觉得系统慢。
所以生产系统要考虑：
流式响应 超时控制 熔断降级 异步任务 请求追踪 结果缓存 模型服务监控 向量数据库性能监控
对于开发者来说，这本质上是一个典型的复杂链路服务治理问题。
