返回资讯中心
外部精选
软件工程
#开发者实时流

业界人士:系统业务可解释性已不再是可选项

来源标题:Business Explainability in Systems Is Not a Nice-to-Have Anymore

Farabi Innovations 的 Rabea AbdelWahab 在文章中提出,在企业级 AI 应用中,模型能力本身正在让位于系统业务可解释性这一瓶颈。随着执行成本降低,理解系统如何做出决策成为关键挑战。文章指出,在能力足够的模型、充分的上下文和合理的架构之上,可解释性正在成为企业落地 AI 的核心难题。

Hacker News 最新rabee32026/11/7 · 今天30 分钟阅读

以下正文由 AI 翻译自 Hacker News 最新(原文版权归原站所有),可能存在偏差,重要内容请以原文为准。

系统里的业务可解释性不再是锦上添花

当执行变得廉价,理解就成了瓶颈

Rabea AbdelWahab

阅读时长 10 分钟·

2026 年 10 月 14 日

--

和其他从事软件与 AI 工作的人一样,我一直在大量试验这些系统究竟能为企业做什么——不只是模型能回答什么问题,而是当你把它们放进真实的工作流、软件开发流程、QA、产品反馈闭环和业务运营中时,会发生什么。

在 Farabi Innovations,这已经成为我们工作的一大部分。我们在构建 agentic 工作流、定制化的 harness 和各类系统,在这些系统里,AI 不再作为聊天机器人待在旁边,而是逐渐成为工作实际完成方式的一部分。

就我个人的经验而言,到目前为止,对于大量企业用例来说,最先进的模型本身正迅速不再是瓶颈。考虑到我们对模型 benchmark、上下文窗口、推理分数以及每一次新发布的关注程度,这话听起来可能有些奇怪;但一旦你拥有了一个足够强的模型、良好的上下文、合适的架构以及围绕它的评审流程,更大的挑战就开始转移到别处了。

这篇文章不是又一篇讨论 AI 是否会取代软件工程师、产品经理、分析师或架构师的文章。我觉得那种讨论没什么意思。

我更感兴趣的是:当企业反馈生命周期中的某一个环节变得比周围所有环节都快得多时,这个生命周期会发生什么。

任何系统,无论是软件、流程还是 AI 驱动的产品,都需要某种形式的反馈生命周期。它通常长这样:

反馈生命周期:发现、分析、设计、行动、评估。

你发现一个潜在的功能或问题,分析反馈及其原因,给出设计方案和可能的解决方案,采取行动,然后评估你做的事情是否真的奏效。这里没什么复杂的。有意思的是 AI 正在对这个循环做什么。

在 AI 之前,这个生命周期的大量时间花在“发现问题”和“能够评估解决方案”之间。

得有人收集反馈、分析反馈、理解问题、想出可能的方案、构建东西、测试、评审,最终再把它摆到业务面前。

AI 正在压缩中间这一大段,压缩幅度惊人。今天你的团队可以拿到成百上千甚至上万条反馈,从中找出模式,检查代码库,提出不同的解决方案,实现其中一个,生成测试,评审实现,然后再次迭代——所用时间只是过去的一小部分。

软件工具是一个明显的例子。Claude Code、Codex 以及类似的系统正在大幅缩短从一个想法到可运行软件之间的距离。但同样的事情也发生在分析、文档、QA、支持运营和其他业务工作流中。

而且我认为我们还没有充分意识到这对组织其余部分意味着什么。因为业务并没有突然变快十倍。

你的用户仍然需要时间去体验系统。你的业务负责人仍然需要时间去理解某件事是否真的起了作用。仍然得有人决定下一次变更是不是正确的变更。也仍然得有人去评估这个系统当初是否做出了正确的决策。

AI 加速了分析、设计和行动。业务仍然要负责评估和发现。

AI 加速了循环的中间部分。业务在追赶。

当执行变得廉价而快速,理解就成了昂贵的那一环。

在我看来,这正是业务可解释性开始变得重要的地方。

人们听到 AI 领域的“可解释性”一词时,首先想到的通常是可解释 AI,也就是 XAI。比如特征重要性、模型可解释性,以及理解机器学习模型为什么给出某个特定预测。这些都是重要问题,但我在本文中说的不是这个。

换一个场景想象:你有一个内部采购系统。有人提交了一笔 42,000 美元的采购申请。部门经理批准了,供应商已在优选供应商名单上,预算也足够,但申请还是被送到了财务部。

等待财务审批

于是自然要问:

答案可能很简单。超过 25,000 美元的采购需要财务审批。系统知道这一点。它评估了这条规则。它把 42,000 美元和 25,000 美元做了比较。它正确地路由了这个申请。但业务用户只拿到了结果。

我感兴趣的就是这个差别。业务负责人要的不是一个 SHAP 值。他们问的是:

这些其实不是 AI 问题,而是业务问题。这就是我所说的业务可解释性。

业务可解释性是指:系统能够用业务负责人可以理解、可以据此行动的语言,解释其决策、条件和结果。

“据此行动”这一点很重要。如果一条解释不能帮助某人评估决策、纠正某个东西,或者做出下一个决策,那它基本上只是装饰。

这是我觉得最有意思的部分。在很多企业系统里,解释在执行过程中其实已经存在了。我们只是没有把它留下来。拿采购的例子来说,应用实际上可能评估了类似这样的内容:

采购金额:42,000 美元

财务审核阈值:25,000 美元

金额超过阈值:是

动作:

路由至财务

应用需要这些信息才能做出决策。然后决策做完了,而在很多系统里,这个上下文就消失了。后来有人问,为什么这笔采购卡在财务那里。消息传到支持团队。支持团队问产品。产品问工程。一名工程师翻查工作流或代码,最后说:

“超过 25,000 美元的任何东西都需要财务审批。”

软件在毫秒之内就知道这件事。而组织可能要花 30 分钟重新发现它。

(原文较长,此处译出前 6000 字,完整内容请点「打开原文」。)

正文由 探How 从来源站点 RSS 同步,内容未经改写;遇到排版缺失或需要图片、视频时请以原文为准。

打开原文
去社区讨论 →