大家好,我是金全。

很多人觉得,企业接入知识库以后,AI 就不会再胡说八道。

但企业里更难处理的一类问题,

恰恰不是编出来的。

而是查出来的。

比如在银行,一个业务人员问 AI:

某个客户是否符合一项产品的办理条件?

AI 很快给出答案。

引用了制度原文。

标出了具体条款。

出处是真的,内容也没有过期,回答逻辑看起来没有问题。

但最后,答案还是错了。

原因并不复杂:

这份制度适用于零售客户。

当前咨询的,却是一家企业客户。

AI 没有胡说。

它找到的资料也没有错。

真正的问题是:

资料是真的。

但它不能用在这次判断上。

这可能是企业做 RAG 和知识库时,比“查不到”更危险的一类问题。

RAG 最大的问题,往往不是查不到

过去大家担心大模型幻觉。

AI 没有依据,也能说得很像真的。

所以很多企业开始建设知识库,

希望 AI 回答问题时有出处、有引用、能追溯。

方向当然没有错。

但 RAG 真正进入生产以后,企业很快会遇到另一个问题:

AI 找到了资料。

资料也确实存在。

回答甚至比过去更完整、更专业。

可它仍然可能把事情说错。

而且这种错误更难发现。

一段明显编出来的话,人会本能地怀疑。

但当答案带着文档名称、制度原文和具体条款出现时,大家反而更容易相信。

明显的错误容易被发现。

有真实资料支撑的错误,更容易被采用。

所以我越来越觉得:

RAG 最危险的时候,往往不是没有找到资料。

而是找到了一份看起来完全正确的资料。

检索成功,不等于资料用对了

RAG 可以帮助 AI 找到信息。

但它不能保证找到的资料正好适合眼前这件事,

也不能保证资料没有过期、没有遗漏。

这是一个很容易被忽略的区别。

检索系统关心的是:

哪段内容和问题更相关。

但企业真正关心的是:

这段内容能不能用在眼前这件事上。

这两件事,并不相同。

找得更准,只解决检索问题。

至于这份资料能不能用在眼前这件事上,

仍然是业务问题。

一份资料可能和问题高度相关。

它也可能措辞权威、结构完整、来源可靠。

但只要适用对象、业务口径或者现场条件发生变化,它就可能把 AI 带向一个错误结论。

所以:

检索到了,不等于找对了。

引用准确,不等于口径一致。

内容真实,不等于信息已经足够。

这三个“不等于”,才是 RAG 进入企业以后真正难处理的地方。

第一层:检索到了,不等于找对了

这是企业知识库里非常常见,也很难只靠相似度解决的问题。

同一项产品,

个人客户和企业客户的办理规则可能不同。

同一份政策,

在不同地区、不同机构、不同风险等级下,适用条件也可能不同。

同一套操作规范,

在测试环境可以执行,到了生产环境却必须经过审批。

这些资料单独看,都没有错。

但 AI 要先弄清楚:

当前面对的到底是谁。

处于什么场景。

适用哪一套规则。

举个例子。

一个 Agent 查询到一份“服务异常处置规范”。

文档中明确写着:

连续出现三次健康检查失败,可以重启实例。

这条规则是真的。

但它只适用于普通业务时段。

当前却处在重保窗口。

这时候,AI 即使准确引用了规则,也不能直接据此行动。

资料本身没有错。

错的是 AI 把它用在了不适用的现场。

相关,不等于适用。

RAG 可以找到和问题最相似的资料。

但 AI 还要弄清楚,这份资料是不是眼前这个客户、这个地区、这个时间和这个业务状态真正该用的规则。

第二层:引用准确,不等于口径一致

还有一类问题,比版本错误更隐蔽。

数据是真的。

查询结果也是真的。

但双方说的,可能根本不是同一件事。

比如:

“华东”包不包括安徽?

“营收”是否扣除退款?

“有效客户”是指开户、发生交易,还是最近仍然活跃?

“故障恢复”是技术指标恢复,还是业务已经确认恢复?

这些问题,人和人之间都经常说不清楚。

到了 AI 系统里,

如果企业没有给出统一口径,

模型拿到的数据越精确,

答案反而可能越有迷惑性。

它可以给出一串完整数字。

可以生成一份结构清楚的分析。

甚至可以精确到小数点后两位。

但如果“营收”这个词在不同系统里代表不同含义,

后面的分析做得再漂亮,也可能建立在不同口径的数据上。

数据准确,不代表业务含义一致。

 

这已经不是简单的检索准确率问题。

而是企业有没有把这些数据的真实含义说清楚。

一份资料被准确引用,只能说明文字被找到了。

它不能证明回答采用了正确、统一的业务口径。

第三层:内容真实,不等于信息已经足够

AI 还可能找到几条完全正确的资料,

却仍然得不出可靠的结论。

因为真实的业务现场,往往不在一份文档里。

有资料,不等于资料已经够用。

 

比如:

  • AI 找到了授信规则,却没有拿到最新风险名单。

  • 找到了历史处置工单,却没有看到当前正处于变更窗口。

  • 找到了产品条款,却遗漏了客户签署的补充协议。

  • 找到了数据库告警,却不知道一项重要的批处理任务正在执行。

这里每一条已检索到的内容都可能是真的。

问题出在那些没有进入 AI 视野的信息。

这也是 RAG 很容易制造的一种错觉:

只要给出了引用,做判断需要的资料就已经齐了。

 

一条资料是否真实,

和现场信息是否完整,

是两个问题。

所以,不能只看已经找到的资料对不对。

还要看把它放回当时的业务现场,信息是不是已经足够。

知识,正在成为新的生产依赖

我做了十几年 APM 和可观测性。

过去很重要的一件事,是追踪服务依赖。

一次请求经过了哪些服务,访问了哪些数据库,调用了哪些接口。

因为这些依赖会直接影响结果。

AI 进入生产以后,企业开始出现另一类依赖。

制度、业务口径、历史记录和现场信息,

也开始直接影响 AI 怎么判断、怎么行动。

它们不再只是供人查阅的参考资料。

服务版本错了,可能导致系统故障。

知识的版本、口径或者使用范围错了,同样可能把 AI 带向错误的结果。

所以从某种意义上说:

知识,正在成为一种新的生产依赖。

 

过去企业追踪技术依赖。

未来还要开始追踪知识依赖。

企业不能只记录 AI 引用了什么

上一篇谈 AI 可观测性,我提出企业需要还原:

AI 当时到底看到了什么。

到了 RAG 场景,这个问题还要继续往下问。

企业不能只记录:

检索到了哪个文档。

还要知道:

这份资料来自哪个系统和版本。

当时是否仍然有效。

能用于哪些客户、地区和业务场景。

为什么 AI 会看到它。

有没有新规则已经覆盖了它。

有没有更关键的资料被遗漏。

它最终又怎样影响了 AI 的回答、判断或者动作。

把这些信息连起来,企业才可能看清 AI 这次到底用了哪些知识。

企业还要知道:

AI 为什么会用这份资料来做判断。

 

别让 AI 事后把理由讲圆

发现答案有问题以后,有人会直接问 AI:

你为什么引用这份资料?

模型通常能给出一段很完整的解释。

但这段解释,是它现在重新生成的一次回答。

它可能合理。

却未必能证明当时真实发生了什么。

所以企业需要留下的,不是模型事后的自我说明。

而是当时真正留下来的记录:

当时检索到了什么。

资料来自哪里。

它是哪个版本,能用在什么场景。

哪些内容真的被 AI 看到了。

最终引用了什么。

这些资料如何影响了判断和行动。

只有这些信息能够被核对,企业才可能判断:

问题出在知识库。

出在检索。

出在业务口径。

还是出在 AI 对当前现场的理解。

最后

企业建设知识库,

不是为了让 AI 的回答看起来更有出处。

而是为了让它真正拿到能用的资料。

这两者之间,还有很长一段距离。

所以,企业真正需要知道的,

不只是 AI 引用了什么。

还要知道:

这些资料当时还有效吗,信息够不够,能不能用在眼前这件事上。

AI 最危险的时候,往往不是没有依据。

而是依据看起来完全正确。

 

#AI系统 #AI可观测性 #因果AI #AgentOps #AI运行系统

推荐阅读

  • 基调听云作为一家专注于移动应用性能管理服务的公司,通过其产品和服务,为企业客户提供了有效的业务运维解决方案。基调听云介入合作企业的移动应用性能管理​,企业对基调听云带来的的好处给予了很高的评价。

    2023-08-11

  • 随着信息技术的快速发展,网络应用已经成为现代生活的重要组成部分。无论是在个人娱乐、商务交流还是政府服务等领域,网络应用已经无处不在。用户对网络应用的性能和可用性要求越来越高,因此,应用性能监控的功能选择成为了网络运维中至关重要的一环。

    2023-11-08

  • 随着企业业务的快速发展应用程序的性能问题变得越来越突出。稳定高效的应用程序对于企业的业务运营至关重要。为了解决应用性能问题选择一个服务好的应用性能监控工具是至关重要的。

    2023-09-14

  • 在软件开发和运维的过程中,故障是不可避免的。当软件发生故障时,及时而准确地找出故障的根因是解决问题的关键。为了解决这个问题,故障根因分析算法​应运而生。下面将介绍故障根因分析算法在问题定位、数据收集和分析,以及算法效果评估三个方面的重要性和挑战。

    2024-01-24

  • 移动应用性能管理系统是一种移动网络管理方向,旨在对企业的关键业务进行监控、诊断和优化,提高企业应用程序性能的质量和可靠性。移动APM可以帮助各行业数字转型,提升应用性能管理的效率。

    2023-08-11