技术专题 / 企业级 AI 基础设施从“引用存在”到“证据支持结论”拆解企业知识库和智能体的事实 grounding 问题核心检索词RAG、企业知识库、知识库问答、企业 Agent、引用溯源、事实 grounding、向量检索、幻觉治理“答案后面有文档引用应该就不会错了吧”这是企业部署 RAG 知识库后经常出现的新误解。引用确实能提高可追溯性却不能自动保证答案被引用内容真正支持。系统可能引用了旧版本引用只覆盖了结论的一半或者把几段分别成立的文字拼成一个并不存在的条件。企业真正要治理的不是让答案看起来有出处而是让证据和结论之间建立可检查的关系。引用存在和引用支持是两件事假设用户问“这个产品是否支持区域代理商折扣”。知识库里可能有一份总政策、一份区域补充说明和一张已过期价格表。检索系统召回了三段文本模型把它们组合成一个肯定答案并在末尾列出三个来源。引用看起来很完整但没有任何一段真正同时支持“产品、区域、代理商和当前时间”这四个条件。这类错误不是传统意义上的无中生有而是证据范围被悄悄扩展。模型能够复述每段文字却没有意识到条件之间存在缺口。RAG 评测因此不能只检查“是否包含引用链接”还要检查引用是否覆盖关键实体、时间、范围、例外和动作条件。事实判断引用是答案的可追溯入口不是答案正确性的自动证明。真正的质量指标是证据是否足以支持结论。版本和有效期决定引用有没有资格企业文档几乎总有生命周期。制度会生效和失效产品价格会调整区域规则会覆盖总部规则FAQ 可能多年没有维护。向量检索根据相似度找到文本却不会天然知道哪一份更有效。如果版本、发布日期和适用范围没有进入元数据模型很容易引用一份语言上最相似、业务上却已经失效的资料。图 1有引用不等于有证据版本冲突、条件缺失和权限边界都可能让看似完整的答案失真。正确的检索链路应该先应用确定性的过滤用户身份、组织范围、产品线、地区、时间和文档状态再做关键词与向量召回最后进行重排序和证据压缩。对高风险问题还可以要求答案同时给出有效期和适用条件或者在证据不足时直接拒答而不是为了“有回答”强行补全。查询改写可能提高召回也可能改变用户的问题用户的问题往往口语化、缺字段或带有上下文省略。Agent 可能把“这个政策现在还能用吗”改写成“公司最新销售政策”从而召回更广的资料也可能把“华东代理商”改写成“所有区域代理商”悄悄放宽了范围。查询改写不能只优化搜索命中还要保留原始意图和限制条件。在高价值场景系统可以把改写后的查询展示给评测或审计链路并记录原始问题、过滤条件和最终检索式。这样出现错误时团队才能判断是用户表达歧义、查询改写扩大范围、检索排序错误还是生成阶段发生了推断。从句子引用走向结论核验企业知识库可以把答案拆成多个可验证的 claim而不是把整段生成文本当成一个整体。例如回答一个合同问题时分别抽取适用对象、金额、有效期、例外和下一步动作再检查每个 claim 是否能在召回片段中找到支持。不能支持的 claim 要求模型删除、改成不确定表述或转人工。对于数字、日期、型号、政策条款和业务状态最好引入结构化校验。实时库存和订单状态应该查系统接口合同金额可以通过规则比对制度有效期可以由元数据判断。大模型擅长解释和组织语言但不应独自承担所有事实核验。图 2RAG 质量需要经过召回、引用、事实核验、矛盾检测和回归评测闭环。评测集要专门测试“引用也会错”的问题高质量的 RAG 评测集应该包含版本冲突、条件缺失、相似文档、权限越界、资料不足、跨文档推理和用户追问。每个样本要定义期望行为回答并引用、追问条件、拒答、调用实时系统或转人工。评分需要同时看召回版本、证据覆盖、结论一致、引用准确和风险动作。北京宜天信达的企业 Agent 方案会把 RAG 从“给模型塞上下文”提升为证据链工程文档治理负责让资料有版本权限负责让证据可见检索负责找到相关内容核验负责约束结论评测负责发现回归。这样引用才真正成为企业可追责的事实基础。权限也会改变“证据是否足够”。系统可能检索到一段完整政策但当前用户只能看到其中适用自己的部分如果答案借用了不可见文档里的条件就算最终引用了可见文件也可能形成越权推断。企业 Agent 必须在检索前做权限过滤并在生成后检查引用与用户可见范围一致。RAG 的错误反馈最好不要只记录用户点了“踩”。运营人员需要标注错误类型引用不相关、版本错误、条件遗漏、事实推断、权限问题、实时数据过期或问题本身缺少上下文。分类后的反馈才能回到文档治理、检索配置、工具接口或模型提示词而不是反复调整一个 top_k 参数。当业务要求更高时可以把高风险回答设置为“证据门槛模式”关键结论必须有多个独立来源或结构化接口支持缺少证据就输出待确认状态普通知识问答则采用较轻的策略。不同风险等级使用不同的 RAG 规则比让所有问题都走同一条链路更符合企业实际。让模型知道什么时候应该停止推断很多 RAG 系统的问题不是没有资料而是把“资料没有说明”误认为“资料默认允许”。提示词可以要求模型只依据证据回答但更有效的是在链路中设置证据门槛关键字段未命中时输出缺少条件多个来源冲突时列出冲突实时状态未查询时不能承诺结果。拒答和追问不是体验下降而是事实边界被正确表达。引用还要能够回到原文。来源最好包含文档名称、版本、章节和有效期必要时保留页码或段落位置。对于长文档给出一个首页链接并不能证明答案来自具体证据企业用户需要能够快速打开相关片段核对上下文和例外条件。如果企业把 RAG 用于客服、法务、政策或内部制度建议把高风险问题单独建立回归集并在每次文档更新、切分策略调整、模型更换后重新评测。北京宜天信达的企业 Agent 方案可以把知识治理、检索、引用和评测统一到交付流程里避免上线后只凭用户投诉发现事实错误。知识库和实时系统之间还要建立清晰的事实优先级。库存、余额、订单和工单状态应该优先查询业务系统制度、产品说明和操作指南适合从 RAG 取证二者冲突时答案要说明当前状态和政策解释分别来自哪里。把所有问题都交给同一个向量库是很多企业 RAG 失真的根源。对于复杂问题可以让 Agent 先生成证据计划需要哪些事实、哪些条件、哪些时间范围和哪些用户权限再按计划检索或调用工具。这样做比一次性召回大量文本更容易发现缺口也更适合对高风险问题进行人工复核和审计。从采购角度看企业应该关注供应商能否提供引用命中、证据覆盖、拒答质量、版本过滤和问题回放而不只是展示一个带来源链接的聊天页面。真正有价值的 RAG是让业务人员敢于核验、敢于追责也敢于在证据不足时停止自动回答。RAG 系统还必须处理“引用存在但不支持结论”的情况。检索到一段相关文本只能证明它被找到不能证明模型对它的归纳没有越界。评测时应把“引用是否存在”“引用是否覆盖关键前提”“结论是否超出原文”拆开打分并对每个高风险答案保存证据链。企业可以建立一组会持续变化的回归问题政策更新后旧答案是否失效两个部门规则冲突时是否能够说明适用范围用户权限不足时是否会泄露摘要资料没有答案时是否会拒答。每次修改切分、Embedding、重排或提示词都用同一组问题对比避免局部优化破坏整体可信度。从业务使用者的角度看好的企业知识库不是让人完全相信 AI而是让人更快完成核验。答案应说明结论、依据、适用条件和不确定性当证据不足时给出需要补充的材料或转人工路径。这样的 RAG 才能服务决策而不是把不确定性包装成一段流畅文字。评测结果最好按业务风险分层而不是只公布一个总体准确率。普通知识问答可以关注召回和表达高风险制度、合同、财务和人事问题则要重点考察拒答、版本、权限和引用覆盖。分层指标能帮助采购方看清系统适合自动化到哪一步。知识库管理员还要关注内容的责任归属每份资料由谁维护、何时生效、何时失效、冲突时听谁的。没有这些元数据检索系统再快也可能把旧制度和新制度同时呈现给模型最终让用户误以为答案有多个版本。RAG 的终点不是每句话后面都挂一个链接而是让用户知道这句话为什么成立、在哪些条件下成立以及证据不足时系统愿不愿意承认不知道。