17元序可解释性设计

元序 WorldScript 可解释性设计

元序运行时的可解释性框架：回答「为什么触发这条规则」「哪些条件贡献最大」「偏差从哪条因果链扩散而来」。
本文档定义可解释性的输出格式、实现机制和使用方式。
前置阅读：《04元序规则》《05运行时架构》《16验证与确认体系》。

一、为什么可解释性是元序的生命线

元序的运行时包含因果匹配、趋势预判、偏差收敛、自演化等多个自动机制。如果这些机制是黑箱，用户无法回答：

这个 Tick 为什么触发了这条规则？
哪些条件对触发贡献最大？
某个偏差是从哪条因果链扩散来的？
Evolve 为什么调整了这个参数？
新旧规则相比，系统指标为什么变好了或变差了？

Trae 在评审中指出：「这门语言后面成不成立，不取决于语法是否优雅，而取决于它能否回答这些问题。如果打不通，它会沦为一个很会说话的黑箱规则系统。」

因此，可解释性不是元序的附加功能，而是与五种核心句式同等重要的语言级能力。

二、可解释性的三个层次

2.1 L1：规则触发解释（已实现）

回答：「这条规则为什么触发？各条件贡献多少？」

输出格式：

规则 [温度过低加热] ✓ 触发 (强度=0.800, 阈值=0.400)
  条件贡献度分解:
    环境.温度 < 环境.目标温度
      满足度=0.800 权重=1.00 贡献=0.800 ███████████████
  合计贡献=0.800

多条件规则示例：

规则 [拥堵预警] ✓ 触发 (强度=0.720, 阈值=0.600)
  条件贡献度分解:
    路段.平均车速 < 15km/h
      满足度=0.900 权重=0.50 贡献=0.450 █████████
    路段.车流密度 > 0.8
      满足度=0.540 权重=0.50 贡献=0.270 █████
  合计贡献=0.720

用户可以直观看到：车速低贡献了0.45，密度高贡献了0.27，合计0.72超过阈值0.6，因此触发。

2.2 L2：偏差溯源（已实现）

回答：「这个偏差是从哪条因果链扩散来的？」

每个偏差记录携带 source_rule 字段，标识产生该偏差的规则。偏差持续不收敛时，告警信息包含来源规则：

⚠ [Tick 45] 偏差持续告警: 偏差[温度偏差] 已持续20个Tick,
  当前强度=0.350, 来源规则=温度过低加热

这帮助用户定位：不是偏差本身的问题，而是产生偏差的上游规则需要调整。

2.3 L3：演化审计（已实现）

回答：「Evolve 为什么调整了这个参数？调整前后是什么？」

所有演化操作写入审计日志，包含：Tick、目标参数、旧值、新值、原因、是否回滚。

演化审计日志:
  Tick 20: threshold 0.400→0.380 [已应用] (活跃偏差=8>5, 降低阈值提高灵敏度)
  Tick 40: threshold 0.380→0.360 [已回滚] (活跃偏差=12, 偏差持续告警)

回滚机制确保：如果演化调整导致偏差恶化，自动撤销并记录原因。

三、实现机制

3.1 条件贡献度计算

因果引擎在评估规则时，递归计算每个子条件的：

满足度（satisfaction）：该条件被满足的程度，0~1
权重（weight）：该条件在父条件中的权重（合取条件默认平均分配）
贡献度（contribution）= 满足度 × 权重

合取条件（&）：各子条件权重各0.5，强度取平均
析取条件（或）：各子条件权重各0.5，强度取最大值
否定条件（非）：贡献度 = 1 - 子条件满足度

3.2 偏差溯源

偏差由规则的 偏差[D] 动作产生。调度器在记录偏差时，反向查找触发该动作的规则，将规则名（或条件描述）写入偏差的 source_rule 字段。

3.3 演化审计与回滚

EvolutionLog 类维护：

entries：所有演化操作的完整记录
rollback_stack：可回滚的操作栈

安全策略：

存在告警偏差时，不执行新的演化操作
存在告警偏差时，回滚最近一次演化操作
所有操作记录原因，支持事后审计

四、使用方式

4.1 CLI 可解释性模式

# 开启可解释性输出（每5个Tick输出一次规则解释）
python -m worldscript.cli examples/thermostat.ws --explain

# 可解释性 + 静默（只输出解释和最终报告）
python -m worldscript.cli examples/thermostat.ws --explain --quiet

4.2 编程接口

from worldscript.parser import parse
from worldscript.runtime.scheduler import Scheduler

program = parse(source)
scheduler = Scheduler(program, {'explain': True, 'verbose': False})
scheduler.run(max_ticks=100)

# 获取所有规则的解释
for exp in scheduler.causality.get_explanations():
    print(exp.format())

# 获取演化审计日志
for entry in scheduler.evolution_log.get_audit_trail():
    print(entry)

# 获取告警记录
for alert in scheduler.alerts:
    print(alert)

4.3 偏差持续告警配置

# 偏差持续15个Tick不收敛则告警（默认15）
scheduler = Scheduler(program, {'alert_persistent_ticks': 15})

五、可解释性与 VVUQ 的关系

可解释性是 VVUQ（验证与确认）的基础：

VVUQ 层次	可解释性的作用
L1 实现验证	规则解释帮助定位实现错误
L2 参数校准	条件贡献度帮助识别敏感参数
L3 模型确认	偏差溯源帮助验证模型机制是否符合领域知识
L4 不确定性量化	演化审计帮助追踪参数变化对结果的影响

没有可解释性，VVUQ 无法落地——你无法验证一个你不理解的系统。

六、未来扩展（M3+）

6.1 因果链可视化

将规则触发、偏差扩散、演化调整绘制成有向因果图，支持交互式探索。

6.2 反事实解释

回答「如果这个条件不满足，规则还会触发吗？」——通过干预语义（do算子）计算反事实。

6.3 规则对比解释

新旧规则版本对比：哪些条件的贡献度变化了，导致系统指标变化。

6.4 自然语言解释

将条件贡献度、偏差溯源、演化审计转换为自然语言报告，供非技术决策者阅读。

七、设计原则

默认开启，可关闭：可解释性数据始终收集，输出可通过 --explain 控制
零额外开销：贡献度计算是因果评估的副产品，不增加额外计算
结构化输出：解释数据以结构化对象存储，可程序化处理，不仅是文本
与审计联动：可解释性数据同时是审计数据，支持事后追溯
不替用户判断：解释「为什么」，但不判断「对不对」——判断留给用户和VVUQ

文档版本: WorldScript Explainability Design v1.0
创建日期: 2026-09-03
关联文档: 《04元序规则》《05运行时架构》《16验证与确认体系》
实现状态: L1规则触发解释 ✅、L2偏差溯源 ✅、L3演化审计 ✅、L4因果链可视化 ⏳

posted @ 2026-09-03 16:32 新哲阅读(4) 评论(0) 收藏举报

刷新页面返回顶部

新哲