文章摘要企业RAG效果不稳定时团队最常见的反应是更换更大的大模型或更贵的Embedding模型但大量问题其实发生在模型调用之前文档解析错误、Chunk边界破坏、版本冲突、权限过滤缺失、检索策略单一、上下文组装混乱以及缺少固定评测集。本文从一条完整RAG链路出发建立“数据—检索—上下文—生成—评测”五层诊断框架并给出可观测字段、质量门槛和治理流程。一、先重新定义企业RAG很多Demo中的RAG只有四步上传PDF → 切分 → 向量化 → 提问企业RAG则至少包含数据源接入 → 文档解析 → 清洗与结构恢复 → 版本和权限 → 分块 → Embedding → 索引 → 查询理解 → 检索 → 融合与重排 → 上下文组装 → 模型生成 → 引用 → 质量评测 → 反馈闭环任何一层出错最终都可能表现为模型回答不好但“回答不好”只是结果不是根因。二、为什么团队总是先换模型原因很简单换模型最容易。修改model参数 → 重新运行 → 立刻看到答案变化而文档治理、分块和评测需要业务人员参与数据清洗重新索引建立指标分析失败案例长期维护。模型升级有时确实能改善指令遵循长上下文处理多证据合并中文表达结构化输出。但如果输入证据本身错误更强模型只会更流畅、更自信地生成错误答案。三、建立五层诊断框架推荐把RAG拆成五层第一层数据质量 第二层检索质量 第三层上下文质量 第四层生成质量 第五层评测与治理排查必须从前向后而不是从模型开始。四、第一层数据质量1. 文档是否被正确解析PDF可能存在多栏排版页眉页脚扫描图片表格脚注水印隐藏文字层乱码公式嵌套列表。原文申请人提交差旅申请后 由直属负责人审批。错误解析后可能变成申请人 提交 2026公司制度 第12页 差旅申请后由 直属负责人 审批 版权所有向量模型不会知道哪些是页眉哪些是正文。2. 文档是否有效知识库中可能同时包含正式版 草稿 旧版 客户定制版 培训材料 历史方案如果没有状态检索会把它们全部召回。建议字段{document_id:TRAVEL-POLICY,version:V3.2,status:EFFECTIVE,effective_date:2026-05-01,expired_at:null,tenant_id:T001,department:HR}3. 文档是否重复重复来源包括同一文件多次上传Word与PDF同时入库邮件附件和知识库重复轻微修改生成多个版本Chunk重叠过大。重复会造成Top5全部是同一段模型看似获得很多证据实际只有一条信息。4. 文档是否有负责人每类知识应有owner reviewer last_reviewed_at next_review_at没有负责人知识库一定会逐渐过期。五、第二层分块质量1. 分块过小优点召回精准Token少。问题条件和结论分离标题丢失表格上下文丢失无法完整回答。2. 分块过大优点上下文完整。问题相似度被无关内容稀释检索定位不准Token成本高正确句子被淹没。3. 固定长度切分破坏结构错误每500字符切一段更合理标题 → 章节 → 条款 → 段落 → 句子 → Token兜底4. 父子分块子Chunk精准检索 父Chunk完整回答例如子4.2.1 普通员工标准 父4.2 住宿标准完整章节检索子Chunk后返回父Chunk或邻接内容。六、第三层Embedding质量1. 模型是否适合语言和领域需要测试中文中英文混合产品术语错误码数字否定表达长文本相似条款。不要只看通用榜单。2. 入库和查询是否使用同一模型必须一致模型 版本 维度 归一化方式 距离度量3. 模型升级是否重建索引不同Embedding模型产生的向量空间不可直接混用。推荐双索引knowledge_embedding_v1 knowledge_embedding_v24. 是否保存Embedding元数据embedding_model embedding_version vector_dimension created_at否则半年后无法解释索引来源。七、第四层检索质量1. 只用向量检索向量擅长语义但不一定擅长订单号SKU错误码法规编号API路径精确人名。企业RAG通常需要BM25 向量 Metadata Reranker2. Top K凭感觉设置Top3太少 Top50总能找到这两种判断都不可靠。Top K增大可能让Recall提高但也会增加噪声冲突Token延迟。3. Metadata过滤缺失过滤条件可能包括tenant_id user_role department status version effective_date language product_line权限过滤必须在检索阶段完成不能先召回其他租户内容再让模型忽略。4. 查询没有改写用户问题这个报错怎么办需要结合会话上下文改写Spring AI启动时报No ChatClient.Builder Bean错误如何处理但查询改写也可能引入错误实体因此要记录原查询和改写查询。八、第五层Reranker质量向量召回适合找候选Reranker负责精排。但需要注意主题相关 ≠ 包含答案评测标签建议区分ANSWER_BEARING SUPPORTING RELATED IRRELEVANT如果Reranker把背景介绍排在具体答案前面最终回答仍会失败。九、第六层上下文组装质量不要简单context\n.join(chunks)每条证据应包含证据编号 文档名 版本 章节 状态 内容示例[E1] 文档差旅管理制度 版本V3.2 状态现行 章节4.2 内容……上下文组装还要处理去重邻接补充冲突标记Token预算排名来源多样性。十、第七层Prompt质量企业RAG Prompt至少应明确只能根据证据回答 证据不足必须拒答 冲突必须指出 关键事实必须引用 不得创造数字和规则错误Prompt请尽可能完整回答。可能诱导模型填补空白。推荐输出结论 依据 不确定项十一、第八层生成模型质量只有前面各层确认正常后才评估模型。固定同一组问题 检索结果 上下文 Prompt比较不同模型是否遵守证据是否保留条件是否处理冲突是否正确引用是否拒答Token和延迟。这样才能真正判断模型差异。十二、第九层输出校验生成后检查1. Claim支持度答案中的每个事实 → 是否存在证据2. 引用准确性引用文档存在不代表它支持结论。3. 数字校验金额、日期、百分比和版本号应做规则校验。4. 权限校验输出中不能泄露不可见数据。5. 结构校验JSON、表格和字段必须有效。十三、建立可观测链路每次请求记录request_id user_id tenant_id original_query rewritten_query retrieval_strategy filters top_k retrieval_results rerank_results context_tokens prompt_version model answer citations faithfulness latency cost feedback推荐分段耗时query_rewrite_ms embedding_ms retrieval_ms rerank_ms model_ms total_ms没有分段数据就无法定位性能瓶颈。十四、建立失败分类每个错误不要只记回答错误建议分类PARSE_ERROR STALE_DOCUMENT CHUNK_INCOMPLETE RETRIEVAL_MISS WRONG_RANKING PERMISSION_FILTER CONTEXT_NOISE PROMPT_FAILURE MODEL_FAILURE UNSUPPORTED_CLAIM CITATION_ERROR长期统计才能知道最大问题在哪。十五、质量指标体系数据层解析成功率OCR准确率文档重复率过期文档比例Metadata完整率。检索层RecallKMRRnDCGAnswer-Bearing Recall权限过滤正确率。生成层答案正确率忠实度完整性拒答准确率引用准确率。运行层P95延迟Token成本错误率用户差评率。十六、建立黄金测试集至少包含问题 标准Claim 正确证据 禁止错误 权限 版本 难度每次变更都运行文档解析Chunk参数EmbeddingTop KRerankerPrompt模型。如果没有回归集就无法知道优化是否只是让演示问题变好。十七、一个推荐诊断顺序1. 原文是否正确 2. Chunk是否完整 3. 正确Chunk是否进入索引 4. 查询是否正确 5. Metadata过滤是否正确 6. 正确证据是否进入Top K 7. Reranker是否把它排前 8. 上下文是否保留完整条件 9. Prompt是否要求忠实回答 10. 模型是否遵守 11. 输出是否经过Claim校验不要从第10步开始。十八、常见错误优化1. 直接换更大模型可能只改善表达。2. 无限增加Top K可能引入更多噪声。3. 增大Chunk可能降低检索精度。4. 增加Overlap可能产生大量重复结果。5. 只看向量相似度相似不等于有答案。6. 只看用户点赞缺少可定位的离线指标。十九、团队治理流程文档上线上传 → 解析检查 → Metadata校验 → 负责人审批 → 入库 → 抽样检索系统变更离线评测 → 影子运行 → 灰度 → 指标观察 → 全量线上失败收集Trace → 分类根因 → 修复 → 加入黄金集 → 回归二十、企业RAG成熟度Level 1Demo上传向量检索聊天Level 2可用文档结构化 Metadata 混合检索 引用Level 3生产权限 版本 评测 监控 灰度 反馈闭环Level 4治理数据Owner 质量SLA 自动回归 成本优化 审计总结RAG效果差往往不是一个模型参数的问题而是整条知识链路的问题。正确治理顺序应是先保证数据正确 → 再保证检索正确 → 再保证上下文正确 → 最后评估模型生成《企业级RAG性能优化与质量治理》后续将继续深入递归分块、语义分块和父子分块PDF多栏、表格与扫描件解析BM25与向量混合检索Reranker多租户权限增量更新引用与忠实度自动化评测。
