推荐语
企业RAG落地最难的并非技术实现，而是数据治理与工程化。本文带你走出Demo误区，直面真实生产环境的复杂挑战。核心内容： 1. RAG基础流程解析与Demo理想条件的局限性 2. 企业真实环境中的数据多样性、权限与成本等综合挑战 3. 文档解析、检索质量等核心难点的深度剖析
杨芳贤
53AI创始人/腾讯云(TVP)最具价值专家
最近两年，似乎所有企业，都在追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，就需要 OCR。
如果是复杂表格，普通文本提取会直接把表格结构打乱。
如果是多栏排版，解析出来的文本顺序可能是错的。
一旦文档解析质量差，后面的向量检索和大模型回答都会受到影响。
垃圾进，垃圾出。
RAG 服务不是魔法。前面解析错了，大模型只会基于错误内容一本正经地胡说。
2. Word、Excel、PPT 各种坑
Word 文档里可能有：
Excel 里可能有：
PPT 里可能有：
这些内容如果简单地全部转成纯文本，很多上下文信息都会丢失。
例如以下的 Excel 表格：
如果解析后变成：
产品 价格 适用客户 A 套餐 999 元 小微企业 B 套餐 2999 元 中型企业
大模型未必能正确理解表格结构。
所以企业 RAG 的第一道门槛就是：文档解析不能只追求“能读出来”，还要尽量保留结构。
很多教程里会告诉你：把文档按固定长度切，如每 500 个字符切一段，每段重叠 50 个字符。
这个方法适合 Demo，但不一定适合企业知识库。
1. 切片太短，上下文不完整
例如原文是：
申请退款需要满足以下条件：1. 订单支付成功；2. 未超过 7 天；3. 商品未发货；4. 企业客户需要提交审批单。
如果切片时把“申请退款需要满足以下条件”和具体条件切开，那么用户问：
系统可能只召回到部分条件，导致答案不完整。
2. 切片太长，检索不精准
如果一个 Chunk 太大，里面混合了很多主题：
退款规则、发票规则、合同规则、售后规则、审批规则……
用户只问“发票怎么开”，向量检索可能召回这个大段内容，但里面噪声很多。大模型最终生成的答案也容易跑偏。
3. 更合理的切片方式
企业 RAG 更推荐按照文档结构切片：
例如：
一级标题：售后政策二级标题：退款规则三级标题：企业客户退款流程内容：……
切片时应该保留标题路径：
【售后政策 > 退款规则 > 企业客户退款流程】企业客户申请退款需要……
这样用户搜索“企业客户退款”时，召回效果会明显更好。
Embedding 不是越贵越好，向量检索也不是万能
RAG 的核心之一是 Embedding，也就是把文本变成向量。很多人会误以为：只要用了好的 Embedding 模型，检索效果就一定好。
实际不是。
1. 向量相似不等于业务相关
向量检索擅长找语义相近的内容，但企业问题常常需要非常精确的业务匹配。
例如用户问：企业版套餐支持多少个子账号？
知识库里有两段内容：
企业版套餐支持最多 100 个子账号。
专业版套餐支持最多 50 个子账号。
这两段在语义上非常相似。
如果检索策略不够精细，很可能把专业版内容也召回。
这时候，大模型可能会混合两个答案，最后回答出一个错误数字。
2. 关键词检索仍然很重要
很多企业 RAG 系统不能只靠向量检索，还需要结合关键词检索。尤其是下面这些场景：
例如用户问：
ERR_10027 是什么错误？
这种问题用关键词检索可能比向量检索更靠谱。
所以实际工程中常见的方案是 混合检索：
3. 召回之后还需要重排序
向量数据库返回 TopK 结果，并不代表前几个就是最适合回答问题的内容。
更稳妥的方式是：
- 最终选出 Top 3 到 Top 5 作为上下文。
这个过程能明显提高答案质量。
简单说：
“向量检索负责“找一批可能相关的”，Rerank 负责“从里面挑最相关的”。”
Demo 项目里的知识库通常默认所有人都能看所有文档。但企业里绝对不能这样。
不同员工提问时，系统不能把他无权查看的文档内容拿出来给大模型总结。否则就会出现严重的数据泄露问题。
1. 权限控制不能只放在前端
有些团队会想：前端隐藏无权限文档就行了。
这是不够的。
RAG 权限控制必须在服务端检索阶段完成。
也就是说，用户提问时，系统必须根据用户身份过滤可访问的知识范围：
只有用户有权限访问的 Chunk，才能进入召回结果。
2. 权限粒度可能细到 Chunk
企业文档权限有时候不是文档级，而是段落级、章节级。
例如一份项目文档里：
如果系统只做文档级权限，就可能出现越权风险。
当然，Chunk 级权限实现成本更高，但对于金融、政企、医疗、法律等场景，往往是必须考虑的。
3. 大模型调用前也要脱敏
即使检索结果符合权限，也可能包含敏感信息：
这些内容是否可以直接发送给外部大模型，需要严格评估。
一般企业都会要求：
所以，企业 RAG 不只是技术问题，也是安全合规问题。
很多 RAG Demo 的 Prompt 是这样写的：
请根据以下资料回答用户问题：资料：{context}问题：{question}
这种方式能跑，但很难稳定。
1. Prompt 需要约束大模型行为
企业知识库问答最怕大模型胡编。所以 Prompt 里必须明确规则：
你是企业***助手。请严格基于给定资料回答问题。如果资料中没有答案，请回答“根据当前知识库资料无法确认”。不要编造不存在的政策、流程、数字、链接或联系人。回答时请尽量引用资料来源。
这些约束很重要。
如果不告诉大模型“不能编”，它很可能会根据常识补全答案。
但企业问答不能靠常识，必须靠企业内部资料。
2. 上下文不是塞得越多越好
有些团队为了提升准确率，会把很多检索结果全部塞进 Prompt。
但上下文太多会带来几个问题：
RAG 不是把所有资料都扔给大模型，而是要把 最相关、最干净、最有依据 的内容传给大模型。
3. 最好要求答案带引用来源
企业知识库问答里，答案是否正确很重要，但答案是否可追溯同样重要。
建议答案返回时带上来源：
根据《企业客户退款流程 V3.2》第 4 节，企业客户退款需要提交审批单，并由客户成功经理确认后进入财务退款流程。
这样用户可以点击查看原文，也方便排查问题。
如果用户不相信 AI 的答案，他至少可以相信原始文档。
企业知识不是一次导入后就不变了。现实中，知识库一直在变化：
如果 RAG 系统不处理版本问题，很容易回答过期内容。
1. 文档更新后，向量索引要同步更新
一份文档更新后，对应的 Chunk 和向量也要更新。
常见做法是：
这个过程需要任务队列和状态管理，不能简单同步执行。
2. 过期知识必须下线
很多 RAG 系统效果差，不是因为召回不到内容，而是因为召回了太多旧内容。
所以每个知识片段最好带上元数据：
检索时可以根据元数据过滤：
只检索当前有效版本只检索用户所属业务线只检索最近更新时间较新的文档
这比单纯依赖向量相似度更可靠。
很多开发做完 RAG Demo 后，会找几个人问几句：
感觉回答还可以。
这不叫评估。
企业 RAG 必须建立一套评估体系，否则你不知道系统到底有没有变好。
1. 至少要评估两个指标
RAG 的效果可以分成两层：
第一层是 检索效果：
第二层是 生成效果：
很多人只看最终答案，但最终答案错了，不一定是大模型错，也可能是检索错了。
2. 建议准备标准测试集
企业可以整理一批典型问题：
问题：企业客户如何申请退款？标准答案：……标准引用文档：……标准 Chunk ID：……
然后每次优化后跑一遍评测。
这样才能知道：
没有评测集，RAG 优化就会变成玄学。
RAG 系统上线后，成本主要来自几个地方：
如果每次用户提问都召回大量内容，然后塞给大模型长上下文，成本会迅速上升。
1. 成本优化思路
常见优化手段包括：
2. 性能优化思路
RAG 请求链路通常比普通接口更长：
用户问题 -> 问题改写 -> Embedding -> 向量检索 -> 关键词检索 -> Rerank -> Prompt 构造 -> 大模型生成 -> 答案后处理 -> 返回结果
这里任何一步慢，用户都会觉得系统慢。
所以生产系统要考虑：
对于开发者来说，这本质上是一个典型的复杂链路服务治理问题。
一个企业级 RAG 系统应该怎么设计？下期我们慢慢讲
粤ICP备14082021号
免费POC，
零成本试错
