1. 三个项目踩下来Demo和生产之间隔着什么我前后经手过三个企业级RAG项目行业跨度不小一个是制造业的设备运维知识库一个是金融合规文档问答还有一个是大型集团的内部制度检索。这三个项目有一个共同点——立项时都跑过Demo而且Demo效果都挺好领导看完演示当场拍板。但真正推到生产环境之后问题一个接一个冒出来有些甚至直接把整个方案推翻重做。这篇文章不是要劝你别做RAG恰恰相反RAG在企业知识问答场景里依然是目前最务实的路线。我想聊的是为什么90%的Demo方案扛不住生产环境以及我在实际项目里踩过的坑、做过的取舍、最后跑通的方案长什么样。如果你正在做RAG项目或者准备立项这篇文章能帮你少走至少三个月的弯路。先说一个最直观的感受Demo阶段你面对的是几十份文档、几百个问题用户是你自己生产阶段你面对的是几万甚至几十万份文档、几千个真实用户问题是你根本想不到的。这两个场景的差距不是调调参数就能弥补的它涉及到检索架构、权限体系、评估机制、运维成本等一整套工程问题。我见过太多团队在Demo阶段用一套向量检索大模型生成就跑通了然后信心满满地上生产结果第一周就被用户投诉淹没。下面我按实际踩坑的顺序把这些问题一个个拆开讲。2. 文档解析这一关Demo里最容易被糊弄过去2.1 为什么Demo阶段的解析看起来没问题Demo阶段大家通常选几份格式规整的PDF或者Word文档用LangChain的文档加载器一读切一切扔进向量库效果就出来了。这时候你会觉得文档解析根本不是问题。但生产环境的文档是什么样的我拿制造业那个项目举例设备手册有扫描版PDF、有带复杂表格的Excel、有嵌套层级的Word、还有大量CAD图纸配套的说明文档。金融项目更夸张合规文件里有大量双栏排版、页眉页脚、脚注、表格嵌套表格的情况。通用文档加载器在这些场景下基本是半残废的。扫描版PDF直接读出来是空白或者乱码双栏排版读出来顺序全乱表格读出来变成一堆没有结构的文字。你拿这些脏数据去做Embedding检索出来的结果自然是一塌糊涂。2.2 生产级文档解析的完整链路我在第三个项目里最终落地的解析链路是这样的你可以参考格式识别层先判断文档类型PDF分文本型和扫描型Office文档分docx/xlsx/pptx还有HTML、Markdown、纯文本等。不同类型走不同解析器。OCR兜底层扫描型PDF和图片走OCR这里要注意OCR的精度直接影响后续所有环节。我试过几个开源方案最后在中文场景下选了一个识别率相对稳定的同时加了版面分析来保留段落结构。结构化提取层表格单独提取成结构化数据保留行列关系标题层级用样式信息还原这样切分的时候能按语义边界切而不是按固定字数硬切。清洗层去掉页眉页脚、页码、重复的水印文字统一全半角处理乱码字符。元数据标注层每份文档打上来源、部门、密级、生效日期等标签这些标签后面权限过滤和检索排序都要用。这套链路跑下来解析一份复杂PDF的时间大概是Demo方案的5到10倍但检索准确率的提升是数量级的。我的经验是文档解析阶段多花一周后面检索和生成阶段能省一个月。2.3 切分策略固定长度切分是最省事也最坑的做法Demo里最常见的切分方式就是按固定字符数切比如500字一段重叠50字。这种做法在生产环境里问题很大它会把一个完整的语义单元切断导致检索出来的片段缺少上下文大模型拿到半截话自然生成不出好答案。我后来用的策略是基于文档结构的语义切分先按标题层级切大块大块超过阈值再按段落切段落还超才按句子切。同时保留每个片段的父级标题路径检索的时候可以把父级标题一起带给大模型作为上下文。这个改动看起来简单但在实际项目里对答案质量的提升非常明显。还有一个细节不同文档类型要用不同的切分粒度。制度类文档适合按条款切每一条是一个完整语义单元技术手册适合按操作步骤切FAQ类适合一问一答切。一刀切的切分参数在生产环境里必然出问题。3. 检索环节向量检索不是万能的3.1 纯向量检索的三个致命短板Demo阶段大家基本都用纯向量检索因为搭起来快、效果好展示。但生产环境里纯向量检索有三个绕不过去的短板第一专有名词和缩写检索不准。向量模型对语义相似度敏感但对精确匹配不敏感。比如用户搜ACL配置向量检索可能返回一堆讲权限控制的文档但真正讲ACL具体配置的那篇反而排不到前面。企业场景里大量查询是带专有名词的这个问题非常突出。第二数字和编号检索几乎失效。用户搜GB/T 19001向量检索基本抓瞎。设备编号、合同编号、条款号这类查询在企业场景里占比很高。第三长尾查询召回率低。向量模型是在通用语料上训练的对垂直领域的术语理解有限。我做过测试在制造业术语上纯向量检索的召回率比预期低了将近30%。3.2 BM25和向量检索的混合策略解决上面这些问题BM25加向量检索的混合方案是目前最务实的做法。BM25擅长精确匹配和关键词召回向量检索擅长语义匹配两者互补。具体怎么做我一般是这样配的检索方式权重适用场景注意事项BM250.3-0.4专有名词、编号、精确查询需要做好中文分词和同义词扩展向量检索0.6-0.7语义查询、自然语言提问Embedding模型要选垂直领域适配的混合融合-全部场景用RRF或加权融合别简单相加融合策略我用的是RRFReciprocal Rank Fusion它对不同检索方式的分数尺度不敏感比直接加权求和稳定得多。具体做法是两路各取Top K然后按排名倒数求和重新排序。K值一般取20到50太小召回不够太大噪声多。3.3 Embedding模型选型别只看排行榜网上有很多Embedding模型排行榜但我要说一句可能得罪人的话排行榜上的分数和你的实际业务效果之间隔着一条河。排行榜大多是在通用语料上评的你的业务场景是垂直领域分布完全不一样。我在三个项目里试过的Embedding模型不下十种最后选型的标准不是排行榜分数而是在自己的业务测试集上的召回率。具体做法是从真实用户问题里抽200到500条人工标注正确答案然后拿这个测试集去评各个模型。这个工作量不小但比盲目选型靠谱得多。另外几个实操要点维度不是越高越好。高维度检索精度可能略好但存储和检索成本成倍增加。1024维在大多数企业场景下够用了。中文场景要选中文优化过的模型。有些模型英文很强中文一塌糊涂。考虑部署成本。如果数据不能出内网就得选能本地部署的模型这时候模型大小和推理速度就是硬约束。别忘了归一化。做余弦相似度之前一定要把向量归一化这个细节很多人会漏。3.4 Rerank召回之后的第二道关混合检索解决了召回问题但排序精度还不够。Rerank模型的作用是对召回结果做精排把真正相关的片段顶到最前面。Rerank的收益有多大我在金融项目里做过对比不加RerankTop 5里平均有2.3个是无关片段加了Rerank之后Top 5里无关片段降到0.8个。这个提升直接反映在最终答案质量上。但Rerank有代价延迟增加。一个Cross-Encoder的Rerank模型对50个候选做精排大概要增加200到500毫秒。如果你的场景对延迟敏感就得在精度和速度之间做取舍。我的做法是召回阶段取Top 30到50Rerank之后取Top 5到8送给大模型这样精度和延迟比较平衡。4. 权限控制企业级RAG和Demo最大的分水岭4.1 为什么权限是绕不过去的Demo阶段所有文档对所有用户可见没有任何权限问题。但企业环境里不同部门、不同职级的人能看的文档是完全不一样的。财务数据不能让研发看高管会议纪要不能让普通员工看客户隐私数据更是有严格的访问控制。我见过一个项目Demo做得漂漂亮亮上线第一天就出了事故一个普通员工通过问答系统查到了薪酬相关的文档内容。这个事故直接导致项目暂停整改了两个月。4.2 ACL权限模型怎么落到RAG里ACLAccess Control List是最常见的权限模型核心思想是每个文档有一个访问控制列表记录哪些用户或角色可以访问。落到RAG系统里关键是在检索阶段就做过滤而不是检索完了再过滤。为什么因为如果你先检索Top 50再过滤掉无权限的可能剩下不到5个召回严重不足。正确做法是把权限条件作为检索的硬约束在向量库和BM25索引里都带上权限标签检索时直接过滤。具体实现上我一般这样做文档入库时给每个片段打上权限标签标签可以是部门ID、角色ID、密级等。用户查询时先解析用户的权限集合。检索时把权限集合作为过滤条件传给检索引擎。向量库用支持元数据过滤的比如Milvus、Qdrant都支持BM25索引用支持字段过滤的Elasticsearch的filter查询。这里有个坑权限标签的粒度。如果标签太粗比如只分公开和内部那过滤效果有限如果太细比如每个文档单独配权限维护成本又太高。我的经验是按部门密级两个维度做标签基本能覆盖大多数企业场景。4.3 权限变更和继承的处理生产环境里权限不是静态的。员工转岗、部门调整、文档密级变更这些都会影响权限。如果每次变更都要重建索引成本太高。我的做法是权限标签和文档内容分离存储。文档内容和向量存在一个集合里权限标签存在另一个映射表里。检索时先查映射表拿到用户能访问的文档ID集合再拿这个集合去过滤。这样权限变更只需要改映射表不用动索引。另外要注意权限继承。比如一个文件夹设了权限里面的文档默认继承。这个逻辑要在入库时处理好把继承后的最终权限标签打到每个片段上检索时就不用再算继承了。5. 评估体系没有评估就没有优化5.1 Demo阶段的评估为什么不可信Demo阶段评估基本靠感觉随便问几个问题看看答案像不像样。这种评估方式有两个问题一是样本太少覆盖不了真实场景二是评估标准主观不同人看同一个答案可能给出完全不同的判断。生产环境需要的是可量化、可复现、可持续的评估体系。没有这个体系你根本不知道每次改动是变好了还是变差了。5.2 三层评估指标怎么搭我一般搭三层评估第一层是检索层指标包括召回率、准确率、MRR、NDCG。这一层评估的是检索模块不涉及大模型生成。做法是人工标注一批问题-相关文档对然后跑检索看命中情况。第二层是生成层指标包括答案准确性、完整性、忠实度。忠实度特别重要指的是答案是否完全基于检索到的内容有没有大模型自己编造的内容。这一层可以用大模型做自动评估但要有一定比例的人工抽检。第三层是端到端指标包括用户满意度、问题解决率、平均响应时间。这一层最贴近业务但采集周期长一般作为长期观测指标。评估层级核心指标采集方式更新频率检索层召回率、MRR、NDCG人工标注测试集每周生成层准确性、忠实度大模型评估人工抽检每周端到端满意度、解决率用户反馈埋点每月5.3 测试集怎么建才靠谱测试集是评估的基础建得好不好直接决定评估有没有意义。我的经验是问题要来自真实用户不要自己编。真实问题的表达方式、用词习惯和你编的完全不一样。覆盖要全包括简单查询、复杂查询、多跳查询、否定查询、模糊查询等不同类型。标注要双人交叉一个人标容易有偏差。定期更新业务在变用户问题也在变测试集要跟着更新。测试集规模不用太大200到500条就能有统计意义了。关键是质量不是数量。6. 那些Demo里根本不会遇到的生产问题6.1 并发和延迟Demo阶段就你一个人用响应慢点无所谓。生产环境可能几百人同时用延迟直接决定用户体验。RAG的延迟主要来自三块检索、Rerank、大模型生成。检索和Rerank可以优化大模型生成的时间基本是固定的。我的优化经验检索和Rerank做缓存相同或相似查询直接返回缓存结果。大模型生成做流式输出让用户先看到部分内容感知延迟降低。异步处理复杂查询可以后台处理处理完了通知用户。限流和降级高峰期保证核心功能可用非核心功能降级。6.2 成本控制Demo阶段不计成本生产环境必须算账。RAG的成本主要来自Embedding计算、向量存储、大模型调用。其中大模型调用是大头。控制成本的手段缓存相同问题不重复调用大模型。模型分级简单问题用小模型复杂问题用大模型。控制上下文长度送给大模型的片段不是越多越好精挑细选Top 5比塞20个片段效果好还省钱。批量处理Embedding计算尽量批量做。6.3 数据更新和版本管理企业文档是不断更新的。新文档要入库旧文档要下架文档改版要替换。Demo阶段一次性导入就完事了生产环境需要一套完整的数据更新机制。我的做法是增量更新新文档走单独的入库流程不影响已有索引。版本管理每个文档保留版本号检索时默认用最新版但支持查历史版本。软删除文档下架不直接删索引而是标记为失效检索时过滤掉。定期重建每隔一段时间做一次全量重建清理碎片和过期数据。7. 从Demo到生产我的落地路线图7.1 分阶段推进别想一步到位我见过太多团队想一步到位结果项目拖了半年还没上线。我的建议是分阶段第一阶段最小可用版本。核心链路跑通文档解析、检索、生成基本可用权限做粗粒度控制。这个阶段目标是上线让用户用起来。第二阶段效果优化。加Rerank、优化切分、调检索权重、建评估体系。这个阶段目标是让答案质量达到可用水平。第三阶段工程完善。并发优化、成本控制、数据更新机制、监控告警。这个阶段目标是让系统稳定可靠。每个阶段大概一到两个月具体看团队规模和业务复杂度。7.2 团队配置建议RAG项目不是一个人能搞定的。我的经验是最小团队配置算法工程师1到2人负责检索、Rerank、Embedding选型和调优。后端工程师1到2人负责服务架构、权限、数据管道。产品/业务1人负责需求梳理、测试集建设、效果验收。运维1人可兼职负责部署、监控、成本。如果团队里有人既懂算法又懂工程那是最理想的能省很多沟通成本。7.3 技术选型的几个原则最后说说选型。RAG技术栈更新很快选型时我遵循几个原则优先选社区活跃的遇到问题能搜到答案。优先选能本地部署的企业数据安全是底线。优先选模块化的检索、Rerank、生成各模块能独立替换。别追新生产环境稳定比先进重要。具体到组件向量库我常用Milvus或QdrantBM25用ElasticsearchRerank用开源的Cross-Encoder模型大模型根据数据安全要求选本地部署或合规的云服务。这套组合不是最先进的但在三个项目里都跑通了稳定性有保障。8. 几个让我印象深刻的踩坑瞬间说几个具体的踩坑经历都是Demo阶段完全想不到的。第一个坑PDF里的表格。制造业项目里设备参数全是表格Demo阶段用的加载器把表格读成了一堆乱序文字检索出来的参数全是错的。后来单独做了表格提取把表格转成结构化数据再入库问题才解决。这个坑让我明白通用工具在垂直场景下往往不够用该自己写的就得自己写。第二个坑同义词。金融项目里用户搜理财和搜投资产品其实是同一个意思但向量检索对这类同义词的处理不稳定。后来加了一层同义词扩展在查询阶段把同义词一起检索召回率提升明显。同义词表是业务专家整理的这个工作算法替代不了。第三个坑大模型的自信胡说。有次用户问一个文档里根本没有的问题大模型基于检索到的无关片段编了一个看起来很像那么回事的答案。这个问题的根源是检索没做好返回了无关片段大模型又不敢说我不知道。后来在Prompt里加了强约束要求大模型只基于给定内容回答没有就说没有同时提高了检索的相关性阈值。第四个坑权限过滤的性能。一开始权限过滤是在应用层做的检索Top 100然后过滤结果发现过滤后经常剩不到10个而且性能很差。后来把权限过滤下沉到检索引擎用元数据过滤性能和效果都好了很多。第五个坑评估集的偏差。早期测试集是我们自己编的问题评估结果很好但上线后用户反馈很差。后来换成真实用户问题发现之前测试集覆盖的场景太窄了。测试集一定要来自真实用户这是血的教训。9. 写在最后的一些个人体会做了三个项目最大的体会是RAG的难点不在算法在工程。Demo阶段拼的是算法生产阶段拼的是工程能力。文档解析、权限控制、评估体系、成本控制这些看起来不酷的东西才是决定项目成败的关键。另一个体会是别追求一步到位。我第一个项目就是想一步到位结果拖了半年业务方失去耐心项目差点被砍。后来两个项目都是先上线最小可用版本然后迭代优化反而推进得很顺利。还有一点业务理解比技术选型重要。你得知道用户真正需要什么文档里真正有什么才能设计出好用的系统。我见过技术很先进但用户不买账的RAG项目问题就出在没搞懂业务。最后说个实用的建一个bad case库。每次发现效果不好的case记下来分析原因定期回顾。这个库是你优化系统最宝贵的资产比任何排行榜和论文都有用。我在第三个项目里积累了300多个bad case每次优化都从里面找方向效果提升非常明显。RAG这个方向还在快速演进新的模型、新的架构层出不穷。但不管技术怎么变把文档解析做扎实、把检索做准、把权限做严、把评估做实这四件事是不会变的。把这四件事做好你的RAG系统就能扛住生产环境。