企业知识库接入更强的模型，答案就会更可靠吗？很多实际问题说明，两者并不能直接画等号。
哪怕模型升级到 GPT-5.6，只要前面的检索系统拿错了合同版本、漏掉表格单位，或者把过期会议纪要当成现行规则，模型依然可能生成一段语气笃定、事实有误的回答。模型负责理解与生成，至于它能看到什么材料，首先由检索链路决定。
IBM 软件事业部高级副总裁 Dinesh Nirmal 对传统 RAG 的评价相当直接：“RAG 在很大程度上存在缺陷。纯 RAG 并不能真正达到预期的最佳结果。”IBM 列出的问题包括上下文窗口限制、聚合能力不足、复杂关系理解缺陷，以及分块策略不当造成的低质量输出。RAG 的实施还可能带来数据泄露风险。
找到相似文字，不等于找到正确事实
常见做法是把 PDF、Word、Excel 等文件拆成多个 Chunk，写入向量数据库。用户提问后，系统按照语义相似度召回若干片段，再交给大模型组织答案。
这套流程善于识别不同说法表达的相近含义，但在企业场景里，“相似”经常不够。
比如员工查询“Q3 华东区利润率”，知识库中可能同时存在多条产品线的数据，也可能保存了同一材料的多个修订版本。只看语义相似度，包含“华东区”“季度”“利润”等词的片段都有机会被召回。它们看起来相关，统计口径、适用范围和生效时间却可能完全不同。
产品编号、合同条款号、人名和内部缩写更容易暴露纯向量检索的短板。这些字段不需要联想，要求的是准确命中。系统如果把近似型号或相邻条款当成同一内容，后续生成再流畅也没有意义。
先用版本和权限排除错误材料
企业知识库可以把向量检索、关键词检索和元数据过滤放在同一条链路里，各自处理擅长的问题。
元数据过滤适合限定部门、时间、文档类型、版本和权限范围。查询某一季度的财务数据时，应先排除其他季度、其他业务线以及已经失效的文件，再进行语义召回。否则，旧材料很容易因为名称相近而进入候选结果。
关键词检索更适合产品型号、专有名词和条款编号。向量检索理解用户想问什么，关键词检索守住不能出错的字段，之后再融合并排序。具体权重应跟随查询类型调整，不能给所有问题套用同一套配置。
有些问题还需要直接查询结构化数据。“某客户当前执行哪一版合同”同时涉及客户、合同、版本和生效状态。仅靠文档相似度，很难持续给出可靠答案。此时可以由 ERP、CRM 或其他业务系统确认当前状态，再让文档提供条款解释和引用依据。
Chunk 怎么切，决定模型能看到多少上下文
不少团队为了实施方便，按固定长度处理所有文件。合同、技术手册、会议纪要和表格的结构差别很大，统一切分很容易拆散原本完整的信息。
合同可以沿条款边界拆分，技术手册适合保留章节或操作步骤，表格则需要连同表头、单位和行列关系一起处理。一个数值即使被准确召回，如果没有指标名称、时间和单位，仍然无法支撑可靠回答。
片段太短，条件和例外条款可能被分到别处；片段太长，又会夹带大量无关内容。比预设统一长度更重要的是检查两个问题：回答所需事实是否保存在同一片段，必要的上下文是否一并留下。
切分之后，元数据也要跟上。每个片段至少应能追溯到原文件和具体位置。频繁修订的材料还需要保留已有的版本、生效状态等字段。缺少这些信息时，向量数据库只能判断两段话是否相似，无法识别哪一段已经过期。
多路召回之后，还要再筛一次
混合检索会扩大候选范围，也会带来更多噪声。初步召回完成后，可以加入重排序环节，围绕用户的原始问题重新判断片段相关性，把真正包含答案依据的材料排到前面。
生成环节则要保留来源。员工不仅需要一个结论，还需要知道结论来自哪份文件、哪个位置。遇到证据不足、不同来源冲突或检索结果缺失时，系统应明确提示无法确认，并补充检索或转交人工复核。
评测也不能只看最终答案是否通顺。答案可能碰巧正确，却引用了错误文件；也可能已经召回正确材料，生成时却漏掉适用条件。将召回、排序、生成和引用分别检查，才能判断问题究竟发生在哪一步。
换模型之前，先检查资料是怎么进来的
更强的模型可以改善语言理解、总结和推理，却无法自动清理知识库里的旧版本文件，也不能替缺失的权限字段和表格关系补齐事实。
更实际的处理顺序是：先整理文档和元数据，确认 Chunk 保留了完整语义；再引入向量检索、关键词检索和必要的结构化查询；随后通过重排序降低噪声；最后补上来源引用、冲突处理与人工复核。
RAG 仍是企业调用内部知识的一条重要路径，但把文档写入向量数据库只是起点。多模态 Agent 能调用文档、表格和业务系统等更多工具，对数据边界和查询接口的要求也会更高。可调用的工具增加后，任何一次选错来源，都可能把错误带进最终答案。
判断企业知识库是否可靠，可以先问一个很具体的问题：系统拿到的，究竟是不是那份正确、有效，而且当前用户有权使用的资料？
