Explainability Assistant 解析 94% 的查询，胜过 TalkToModel 的 76.8%

管理楼宇的人很少有机会向他们的预测模型提问。他们得到的是一块仪表盘：一张特征重要性图表，一排为已经知道该拧哪个旋钮的人设计的控件。对于一位想弄清楚周二负荷预测为何偏高的设施经理来说，那张图表算不上解释。

一篇于 2026 年 9 月 10 日提交至 arXiv 的论文认为，问题一直出在界面本身，而解决办法来自一个意想不到的地方。作者称 Explainability Assistant 为开源系统，它让运营人员可以用日常语言诘问一个能耗模型。该系统报告意图解析准确率为 94%，而更早的对话式 XAI 系统 TalkToModel 为 76.8%, , 后者受限于手工编写的语法。

17 个百分点的差距并不是有趣之处。真正重要的是它为何存在：TalkToModel 只能识别一组固定的措辞，而 Explainability Assistant 通过现代大语言模型的函数调用能力来路由问题。根据论文，这使系统能够支持灵活的自然语言，并无需针对特定任务微调即可适应不同的机器学习问题类型。

手工编写的语法才是瓶颈

自定义语法是一场赌注：赌你能预测人们会如何措辞提问。你为“为什么”这个词写模式，为假设性问题写模式，为解释某一次预测的请求写模式，然后一位运营人员问出了这些模式从未预料到的东西。语法没匹配上。运营人员稍微换个说法再问。即便背后的模型运转正常，界面给人的感觉还是坏了。

函数调用绕开了这一问题：它让模型自行判断一个问题对应哪个工具，而不是拿问题去和一份清单比对。论文把这视为核心的架构选择，而 76.8% 到 94% 的差距就是附于其上的证据。这 17 个百分点，区隔开的是一个能听懂大部分提问的系统，与一个几乎能听懂全部提问的系统。

摘要中还有第二项主张值得拆解。论文称，由于该界面并未针对特定任务进行微调，它可以跨不同机器学习问题类型自适应。一个对话层可以放在基于遗传编程的符号回归器或其他模型之前，而无需重建。评估设定在能源领域，但其架构层面的论点并不依赖于此。

那个主标题数字没有覆盖到什么

看那张表，它像是一场干净利落的胜利，这也大致是摘要呈现它的方式。意图解析准确率衡量的是系统是否弄清了用户想要什么。它完全没有说明随后的解释是否正确、完整，或对读它的人是否有用。

论文确实报告了一项与能源领域专家共同进行的对比评估，将该助手与传统的 XAI 仪表盘相对照。结果被描述为可用性提升、任务准确率稳定，且所有专家在实际使用中都更偏好对话式界面。

一致的偏好是一个真实的信号，也是一个界定不清的信号。现有材料没有说明有多少专家参与、每人完成了多少任务，或任务准确率是否依据固定评分标准打分。界面研究中的偏好往往偏向让人感觉更快、响应更及时的一方，而聊天机器人通常如此。运营人员是否得出了更好的结论，是另一项测量，也是摘要没有报告的一项。

论文没有讨论的依赖关系

一个建立在函数调用之上的解释层，会继承其底层模型的属性。每个问题都带来单次查询成本和一定延迟，而托管该模型的一方可以在不征求任何人意见的情况下更新或停用它。作者称该系统为开源，但所提供的材料没有指明它调用的是哪个模型，也没有说明该模型是本地运行还是通过托管 API 运行。对于校园设施团队或正在决定是否将其推到员工面前的公用事业公司来说，这一细节很可能决定是否部署。

下一次评估必须走向何处

这里的贡献比“一个能解释预测的聊天机器人”要窄，也比听上去更有用。如今，一个对话式 XAI 层无需定制解析器就能搭建起来，这消除了使这类界面无法进入设施管理软件的其中一项主要工程成本。这项成本过去意味着雇一个团队来编写和维护语法。现在它意味着接上一个具备函数调用能力的模型。

没有变得更容易的，是解析之后的环节。一位追问模型为何预测高能耗的运营人员，想要的是一个能据以行动的答案：调整排程，或检查某个传感器。正确识别问题只是做到这一点的前提，而非替代。另一端的解释是否会改变运营人员接下来的行动，是这篇论文提出却悬而未答的问题。