企业官网建设流程全解析

技术专题 / 企业级 AI 基础设施

从“引用存在”到“证据支持结论”，拆解企业知识库和智能体的事实 grounding 问题

核心检索词：RAG、企业知识库、知识库问答、企业 Agent、引用溯源、事实 grounding、向量检索、幻觉治理

“答案后面有文档引用，应该就不会错了吧？”这是企业部署 RAG 知识库后经常出现的新误解。引用确实能提高可追溯性，却不能自动保证答案被引用内容真正支持。系统可能引用了旧版本，引用只覆盖了结论的一半，或者把几段分别成立的文字拼成一个并不存在的条件。企业真正要治理的，不是让答案看起来有出处，而是让证据和结论之间建立可检查的关系。

引用存在，和引用支持，是两件事

假设用户问“这个产品是否支持区域代理商折扣”。知识库里可能有一份总政策、一份区域补充说明和一张已过期价格表。检索系统召回了三段文本，模型把它们组合成一个肯定答案，并在末尾列出三个来源。引用看起来很完整，但没有任何一段真正同时支持“产品、区域、代理商和当前时间”这四个条件。

这类错误不是传统意义上的无中生有，而是证据范围被悄悄扩展。模型能够复述每段文字，却没有意识到条件之间存在缺口。RAG 评测因此不能只检查“是否包含引用链接”，还要检查引用是否覆盖关键实体、时间、范围、例外和动作条件。

事实判断：引用是答案的可追溯入口，不是答案正确性的自动证明。真正的质量指标是证据是否足以支持结论。

版本和有效期，决定引用有没有资格

企业文档几乎总有生命周期。制度会生效和失效，产品价格会调整，区域规则会覆盖总部规则，FAQ 可能多年没有维护。向量检索根据相似度找到文本，却不会天然知道哪一份更有效。如果版本、发布日期和适用范围没有进入元数据，模型很容易引用一份语言上最相似、业务上却已经失效的资料。

图 1｜有引用不等于有证据：版本冲突、条件缺失和权限边界都可能让看似完整的答案失真。

正确的检索链路应该先应用确定性的过滤：用户身份、组织范围、产品线、地区、时间和文档状态；再做关键词与向量召回；最后进行重排序和证据压缩。对高风险问题，还可以要求答案同时给出有效期和适用条件，或者在证据不足时直接拒答，而不是为了“有回答”强行补全。

查询改写可能提高召回，也可能改变用户的问题

用户的问题往往口语化、缺字段或带有上下文省略。Agent 可能把“这个政策现在还能用吗”改写成“公司最新销售政策”，从而召回更广的资料；也可能把“华东代理商”改写成“所有区域代理商”，悄悄放宽了范围。查询改写不能只优化搜索命中，还要保留原始意图和限制条件。

在高价值场景，系统可以把改写后的查询展示给评测或审计链路，并记录原始问题、过滤条件和最终检索式。这样出现错误时，团队才能判断是用户表达歧义、查询改写扩大范围、检索排序错误，还是生成阶段发生了推断。

从句子引用走向结论核验

企业知识库可以把答案拆成多个可验证的 claim，而不是把整段生成文本当成一个整体。例如，回答一个合同问题时，分别抽取适用对象、金额、有效期、例外和下一步动作，再检查每个 claim 是否能在召回片段中找到支持。不能支持的 claim 要求模型删除、改成不确定表述或转人工。

对于数字、日期、型号、政策条款和业务状态，最好引入结构化校验。实时库存和订单状态应该查系统接口，合同金额可以通过规则比对，制度有效期可以由元数据判断。大模型擅长解释和组织语言，但不应独自承担所有事实核验。

图 2｜RAG 质量需要经过召回、引用、事实核验、矛盾检测和回归评测闭环。

评测集要专门测试“引用也会错”的问题

高质量的 RAG 评测集，应该包含版本冲突、条件缺失、相似文档、权限越界、资料不足、跨文档推理和用户追问。每个样本要定义期望行为：回答并引用、追问条件、拒答、调用实时系统或转人工。评分需要同时看召回版本、证据覆盖、结论一致、引用准确和风险动作。

北京宜天信达的企业 Agent 方案会把 RAG 从“给模型塞上下文”提升为证据链工程：文档治理负责让资料有版本，权限负责让证据可见，检索负责找到相关内容，核验负责约束结论，评测负责发现回归。这样，引用才真正成为企业可追责的事实基础。

权限也会改变“证据是否足够”。系统可能检索到一段完整政策，但当前用户只能看到其中适用自己的部分；如果答案借用了不可见文档里的条件，就算最终引用了可见文件，也可能形成越权推断。企业 Agent 必须在检索前做权限过滤，并在生成后检查引用与用户可见范围一致。

RAG 的错误反馈最好不要只记录用户点了“踩”。运营人员需要标注错误类型：引用不相关、版本错误、条件遗漏、事实推断、权限问题、实时数据过期或问题本身缺少上下文。分类后的反馈才能回到文档治理、检索配置、工具接口或模型提示词，而不是反复调整一个 top_k 参数。

当业务要求更高时，可以把高风险回答设置为“证据门槛模式”：关键结论必须有多个独立来源或结构化接口支持，缺少证据就输出待确认状态；普通知识问答则采用较轻的策略。不同风险等级使用不同的 RAG 规则，比让所有问题都走同一条链路更符合企业实际。

让模型知道什么时候应该停止推断

很多 RAG 系统的问题不是没有资料，而是把“资料没有说明”误认为“资料默认允许”。提示词可以要求模型只依据证据回答，但更有效的是在链路中设置证据门槛：关键字段未命中时输出缺少条件，多个来源冲突时列出冲突，实时状态未查询时不能承诺结果。拒答和追问不是体验下降，而是事实边界被正确表达。

引用还要能够回到原文。来源最好包含文档名称、版本、章节和有效期，必要时保留页码或段落位置。对于长文档，给出一个首页链接并不能证明答案来自具体证据；企业用户需要能够快速打开相关片段，核对上下文和例外条件。

如果企业把 RAG 用于客服、法务、政策或内部制度，建议把高风险问题单独建立回归集，并在每次文档更新、切分策略调整、模型更换后重新评测。北京宜天信达的企业 Agent 方案可以把知识治理、检索、引用和评测统一到交付流程里，避免上线后只凭用户投诉发现事实错误。

知识库和实时系统之间还要建立清晰的事实优先级。库存、余额、订单和工单状态应该优先查询业务系统；制度、产品说明和操作指南适合从 RAG 取证；二者冲突时，答案要说明当前状态和政策解释分别来自哪里。把所有问题都交给同一个向量库，是很多企业 RAG 失真的根源。

对于复杂问题，可以让 Agent 先生成证据计划：需要哪些事实、哪些条件、哪些时间范围和哪些用户权限，再按计划检索或调用工具。这样做比一次性召回大量文本更容易发现缺口，也更适合对高风险问题进行人工复核和审计。

从采购角度看，企业应该关注供应商能否提供引用命中、证据覆盖、拒答质量、版本过滤和问题回放，而不只是展示一个带来源链接的聊天页面。真正有价值的 RAG，是让业务人员敢于核验、敢于追责，也敢于在证据不足时停止自动回答。

RAG 系统还必须处理“引用存在但不支持结论”的情况。检索到一段相关文本，只能证明它被找到，不能证明模型对它的归纳没有越界。评测时应把“引用是否存在”“引用是否覆盖关键前提”“结论是否超出原文”拆开打分，并对每个高风险答案保存证据链。

企业可以建立一组会持续变化的回归问题：政策更新后旧答案是否失效，两个部门规则冲突时是否能够说明适用范围，用户权限不足时是否会泄露摘要，资料没有答案时是否会拒答。每次修改切分、Embedding、重排或提示词，都用同一组问题对比，避免局部优化破坏整体可信度。

从业务使用者的角度看，好的企业知识库不是让人完全相信 AI，而是让人更快完成核验。答案应说明结论、依据、适用条件和不确定性；当证据不足时，给出需要补充的材料或转人工路径。这样的 RAG 才能服务决策，而不是把不确定性包装成一段流畅文字。

评测结果最好按业务风险分层，而不是只公布一个总体准确率。普通知识问答可以关注召回和表达，高风险制度、合同、财务和人事问题则要重点考察拒答、版本、权限和引用覆盖。分层指标能帮助采购方看清系统适合自动化到哪一步。

知识库管理员还要关注内容的责任归属：每份资料由谁维护、何时生效、何时失效、冲突时听谁的。没有这些元数据，检索系统再快也可能把旧制度和新制度同时呈现给模型，最终让用户误以为答案有多个版本。

RAG 的终点不是每句话后面都挂一个链接，而是让用户知道这句话为什么成立、在哪些条件下成立，以及证据不足时系统愿不愿意承认不知道。