🤖 AI

An XAI View on Explainable ASP: Methods, Systems, and Perspectives

本调查提供了一个由可解释人工智能（XAI）引导的、针对现有答案集程序（ASP）解释方法与工具的综述，将其映射至用户需求，同时识别了当前的空白并概述了未来的研究方向。

原作者： Thomas Eiter, Tobias Geibinger, Zeynep G. Saribatur

发布于 2026-06-11

📖 1 分钟阅读☕ 轻松阅读

原作者： Thomas Eiter, Tobias Geibinger, Zeynep G. Saribatur

原始论文采用 CC BY 4.0 许可（http://creativecommons.org/licenses/by/4.0/）。 ✨ 这是对下方论文的AI生成解释。它不是由作者撰写或认可的。如需技术准确性，请参阅原始论文。阅读完整免责声明

想象一下，你构建了一个非常聪明、逻辑严密的机器人来解决一个复杂的谜题。你给它一套规则（就像一份食谱），它就会吐出一个解决方案。但有时，机器人给出的答案会让你感到惊讶，或者更糟的是，它拒绝给出任何答案。你会问：“你为什么那样做？”或者“为什么你无法解决这个问题？”

这篇论文是一本关于如何向 回答集程序编程 (Answer Set Programming, 简称 ASP) 系统提出这些问题的指南。ASP 是一种“符号 AI”，它使用严格的逻辑规则（就像一本极其精确的食谱）来解决问题。与现代的“神经网络”AI 不同——后者通常是黑盒，你输入数据，发生“魔法”，然后得到答案——ASP 本质上是透明的，因为它遵循清晰、书面的规则。

然而，即使有了清晰的规则，逻辑也可能会变得纠缠不清。这篇论文调查了我们用来解释“机器人在思考什么”的各种“工具”和“方法”。作者 Thomas Eiter、Tobias Geibinger 和 Zeynep G. Saribatur 根据两个主要视角对这些工具进行了分类：局部 (Local) 和 全局 (Global)。

两种类型的提问

把 ASP 系统想象成一个正在侦破案件的侦探。

1. 局部解释（“特定案件”侦探）

问题： “我有一个特定的解（一个特定的回答集）。为什么这个事实在这个解中是真的？”或者“为什么这个事实是假的？”
类比： 想象你正在看一张特定的犯罪现场照片。你问：“为什么嫌疑人手里拿着一把伞？”工具会查看导致那把伞出现在照片中的特定规则。
工具： 论文列举了几种实现这一目标的方法：
- 证明树 (Justification Trees)： 就像逻辑领域的家谱。它展示了一个事实是如何从其他事实和规则中“衍生”出来的。
- 支持图 (Support Graphs)： 一张显示哪些规则“支持”了某个决策的地图。
- 对比解释 (Contrastive Explanations)： 这就像是在问：“为什么嫌疑人戴的是伞而不是帽子？”该工具通过解释实际结果与假设的“如果……会怎样”场景之间的差异来进行说明。

2. 全局解释（“大局观”侦探）

问题： “为什么机器人从不给出答案？”或者“为什么机器人总是在每一个解中都包含这个事实？”
类比： 想象你正在查看侦探的整本规则手册。你问：“为什么解决这个案件是不可能的？”或者“为什么无论如何嫌疑人总是有罪的？”
工具：
- 调试 (Debugging)： 如果机器人崩溃了（没有解），这些工具就像是寻找引擎故障部件的机械师。它们寻找“最小不满足集 (Minimal Unsatisfiable Sets)”——即那些互相冲突并导致系统崩溃的最小规则组。
- 抽象 (Abstraction)： 这就像是在地图上缩小视野。如果地图太拥挤而看不清问题，你就模糊掉小街道，只看主干道。这有助于找到系统卡住的核心原因。

当前的工具箱现状

这篇论文是对 ASP 用户可用“工具箱”的一次综述。以下是他们的发现：

我们在“为什么 X 是真的？”方面有很多工具。 有许多方法可以解释为什么一个特定的事实出现在某个解中（局部）。
我们缺乏“为什么这个解是最优的？”方面的工具。 如果机器人根据某些偏好选择了“最佳”解，那么解释为什么它是最好的，目前仍然非常困难。
“语言鸿沟”： 许多这些解释工具在处理简单规则时表现良好。但现实世界的问题经常使用高级特性，如“析取 (disjunction)”（A 或 B）、“聚合 (aggregates)”（计数）或“弱约束 (weak constraints)”（偏好）。论文指出，许多解释工具尚无法处理这些高级特性。这就像你有一个只能拧小螺栓的扳手，但你的机器上全是巨型螺栓。
“系统分歧”： 你通常必须在“解释特定解的工具（局部）”和“解释整个系统为何失效的工具（全局）”之间做出选择。你很少能得到一个能同时无缝实现两者的工具。

人为因素（认知层面）

作者还指出，仅仅拥有技术上的答案是不够的；解释必须是人类能够理解的。

信息过载： 如果你有一个拥有数千条规则的庞大程序，向用户展示整个逻辑“家谱”会让人应接不暇。论文建议我们需要更好的“总结”或“抽象”这些解释的方法，例如隐藏乏味的细节，只展示核心逻辑。
与非专家交流： 大多数工具输出的是技术性的图表或规则列表。论文建议使用 大语言模型 (LLM)（比如你现在正在交谈的这类 AI）将这些技术性的“机器人语言”翻译成通俗易懂的英语。想象一下机器人说：“我选择雨伞是因为在下雨，”而不是展示一个复杂的逻辑规则图表。

核心结论

这篇论文是“可解释 ASP”领域现状的一张地图。它告诉我们：

我们擅长解释特定的、局部的决策。
我们在处理解释系统为何完全失效或为何在众多选项中选择“最佳”选项方面感到吃力。
我们需要更好的工具来处理复杂的、现实世界的规则类型。
我们需要使其对人类友好，通过总结复杂的逻辑并将其转化为自然语言。

作者总结道，虽然我们拥有丰富多样的手段，但目前还没有一个工具能满足所有需求。ASP 解释的未来在于弥合复杂的逻辑推理与人类理解之间的鸿沟，或许可以通过使用新的 AI 技术来充当“翻译官”。

技术摘要：可解释 ASP 的 XAI 视角

问题陈述

答案集程序编程（ASP）是符号人工智能中一种重要的声明式推理范式，因其基于规则的形式化特征而备受推崇，这种特征使其比神经网络等亚符号方法具有更强的内在可解释性。尽管如此，求解器输出的“黑盒”性质仍然是其在工业和社会领域广泛应用中的障碍，特别是在可解释人工智能（XAI）日益受到重视的背景下。用户往往难以理解特定求解器结果（答案集）背后的推理机制，或程序的整体行为（例如，为什么不存在解）。

虽然先前的综述（如 Fandinno 和 Schulz, 2019）对特定的解释技术进行了分类，但它们通常侧重于狭窄的场景（例如，“为什么原子 $a$ 在答案集 $I$ 中？”）。目前缺乏一个以用户为中心的综合概述，将多样化的用户问题映射到现有的理论方法和工具，识别当前覆盖范围的空白，并将 ASP 的解释能力与更广泛的 XAI 中关于局部解释与全局解释的区分相统一。

方法论

作者在 XAI 视角的指导下对 ASP 解释方法进行了调查。该方法包括：

分类： 将解释的格局结构化为局部解释（涉及特定的计算出的答案集）和全局解释（涉及程序的通用行为或所有答案集的集合）。
问题驱动分析： 确定了一系列典型的用户问题（Q1–Q8），范围从“为什么文字 $\ell$ 在 $I$ 中？”到“为什么程序没有答案集？”以及“为什么 $I$ 是最优的？”。
映射与归约： 分析现有方法（标记为 M1–M15）和系统（如 xASP2, xclingo, s(CASP), UCOREXPLAIN）如何处理这些问题。作者还识别了哪些问题可以归约为其他可解问题（例如，将“为什么 $a \in I$ ”归约为“为什么修改后的程序是不可满足的”）。
差距识别： 评估现有工具针对语言特性（析取、聚合、选择规则、弱约束）和用户需求（可扩展性、认知负荷、交互性）的覆盖情况。

核心贡献

本文提供了一个结构化的 ASP 解释方法分类法，并强调了以下具体贡献：

1. 解释类型分类

局部解释： 侧重于推导特定答案集 $I$ $I$ 中原子的存在或缺失。
- 证明（Justifications） (M1–M4)： 包括离线证明（推导图）、基于 ABA 的证明（论证树）、因果证明（代数项）以及来自求解器追踪的基于规则的证明。
- 扩展证明 (M5)： 用于 UCOREXPLAIN 的单位可证不可满足子集（1-PUS），用于寻找解释某个文字的最小规则集。
- 支持图 (Support Graphs) (M6)： 由 xclingo 使用，将原子链接到支持它们的规则，从而允许自然语言注释。
- 见证（Witnesses） (M7)： 求解器无关的逐步逻辑推导。
- 对比解释 (Contrastive Explanations) (M8)： 解释为什么一组原子 $E$ 在 $I$ 中而不是在 $F$ 中，使用反事实推理（Eiter 等人，2023）。
全局解释： 侧重于不针对特定答案集的程序行为。
- “为什么不”溯源 (Why-not Provenance) (M9)： 识别需要进行的程序修改以改变真值。
- 自顶向下计算 (Top-down Computation) (M10)： 目标导向的证明树（例如 s(CASP)）。
- 证明系统 (Proof Systems) (M11)： 用于怀疑性蕴含的演算（解释为什么一个原子在所有或没有答案集中）。
- 调试 (Debugging) (M12–M14)：：* 诸如元编码（spock）、最小不可满足集（MUS）和交互式单步执行等技术，用于解释不一致性。
- 抽象 (Abstraction) (M15)： 过近似技术，通过省略无关细节来对不可满足部分进行“缩放”。

2. 用户问题分析 (Q1–Q8)

本文将特定的用户查询映射到可用方法：

Q1 (为什么 $\ell \in I$ ？)： 被大多数局部方法（M1–M7）覆盖。
Q2 (为什么 $\ell \in I$ 但 $\ell' \notin I$ ？)： 由对比解释（M8）或归约为不可满足性来解决。
Q3 (为什么 $I$ 是最优的？)： 目前缺乏原生支持；可归约为解释一个更好的答案集不存在。
Q4–Q6 (全局存在性/不存在性)： 由溯源、证明系统和调试/抽象方法解决。
Q7–Q8 (定量/集体行为)： 被识别为差距。目前的工具无法原生解释为什么某种属性在一组答案集中成立，或者为什么程序具有特定数量的答案集。

3. 工具与语言支持分析

作者根据 ASP 语言扩展评估了现有工具（表 2）：

析取 (Disjunction)： 支持较差；大多数工具（LABAS, s(CASP), xASP2）由于生成解释的复杂性，无法很好地处理析取规则。
选择规则与聚合 (Choice Rules & Aggregates)： 部分支持（例如 xASP2, xclingo, UCOREXPLAIN），但通常带有限制。
弱约束 (Weak Constraints)： 通常不支持用于解释目的，但 DWASP 是一个显著的例外，用于调试。
求解器依赖性： 存在求解器相关型（如 xclingo, s(CASP)）和求解器无关型（如 LABAS, 因果证明）方法。

结果与发现

覆盖范围： 大多数用户问题可以通过原生方法或归约为不可满足性（解释为什么程序没有答案集）来回答。
局限性：
- 语言差距： 析取和弱约束仍然是解释工具面临的重大障碍。
- 可扩展性： 大多数方法是事后的（post-hoc）并在经过实例化（grounded）的程序上运行，导致大规模问题的计算复杂度极高。
- 认知负荷： 用于解释不一致性（调试）的方法通常是技术性的（规则集），对于非专家来说难以理解。
- 缺失场景： 目前没有任何方法处理关于答案集数量的问题，或关于属性在多个答案集上同时成立的问题。
互操作性： 存在一个“系统分歧”，即用户必须在局部解释工具或全局解释工具之间做出选择，缺乏统一的框架。

意义与未来方向

本文旨在为研究人员和非专家 ASP 用户提供指南，试图弥合理论解释能力与实际用户需求之间的鸿沟。

意义：

它建立了一个统一的 ASP XAI 框架，区分了局部推理与全局推理。
它强调解释不一致性（不可满足性）是实现通用解释方法的关键步骤，因为许多问题都可以归约为这种形式。
它识别了对简洁且可解释解释的需求，表明抽象和逐步推理对于降低认知努力至关重要。

未来研究方向：

认知方面： 开发能够以易于非专家理解的方式（例如通过隐藏的“引理”或图着色中的团）呈现不一致性的方法。
交互： 集成大语言模型（LLM），将技术性解释（如 MUS）转化为自然语言，并解析用户查询。
可扩展性： 将解释技术直接集成到求解器中，以处理非实例化（non-ground）程序和大规模问题。
新问题类型： 开发专门针对答案集数量及集体行为问题的解决方案（Q7, Q8）。

作者总结道，虽然存在丰富的各种方法，但没有单一的工具能满足所有需求，未来的工作必须解决语言支持、可扩展性和复杂逻辑推理的认知解释问题。