局部解释支持用户对单次结果的接受或申诉

概念解释

保险拒赔。当事人要决定的是：认了这一次，还是针对这一次去争。能把这个决定撑起来的，是锁在本案的说明——用了哪几张单据、哪一项对不上、缺的是哪一页。局部解释的用处是支持对单次结果的接受或申诉（local explanation for accept or appeal），不是让人学会这套模型平时怎么想。

没有这一层，接受是盲签，申诉是盲写。

机制

接受和申诉都是对着一个已发生的裁定。要接受，人必须能判断本案事实是否被用对；要申诉，人必须能指出本案里哪一块可以补或可以驳。这些动作的输入是这一例的依据，不是群体通过率，也不是架构图。LIME 一类邻域方法之所以和申诉场景相配，是因为它试图标出这一例附近起作用的部分，正好是争点可能所在。

全局脾气在这里帮倒忙：告诉申请人「系统整体偏严」，既不能让他安心接受这一次，也不能让他知道该补哪一页。脾气是部署问题，不是个案程序。

怎么研究

给拒件配可定位到本案事实的局部说明，或只配总体政策说明，然后开放「接受 / 提交补充 / 正式申诉」。自变量：局部依据是否可核对到具体字段、申诉表是否预填了被标出的争点。因变量：补充材料与争点的相关度、无依据的申诉率、在事实已被用对时仍申诉的比例。

相关度比申诉率更要紧。说明若只是把人惹去申诉，而材料对不上，局部解释没有完成它的程序功能。

边界

不可申诉的场景（推荐下一首歌）不需要这层程序，局部说明若还在，用途就不是接受或申诉。高风险但没有人工复核通道时，局部解释会制造「可以争」的假象，比不解释更糟。这条假定存在接受或提出异议的通道；通道本身怎么设计是另一件事。

怎么落地

• 拒件旁列出本案用到的事实，每条可点开原件。申诉表预填这些条目，让人勾「有误 / 可补充」，不要给空白作文题。
• 接受按钮附近用一句话复述本案结论所依赖的那几项，而不是「本系统准确率百分之九十二」。
• 未列入本案依据的政策或模型介绍，放到别处，避免申请人拿它当争点。
• 验证：抽一批申诉材料，看是否对准说明里标出的字段。对不准，局部解释没有在支持申诉；再看接受的人能否复述本案依据，复述不出就是盲签。

延伸

• 同组：L5.02.1 局部解释说明单次输出 · L5.02.2 全局解释说明整体行为倾向 · L5.02.3 用户在不同场景需要不同层级 · L5.02.5 全局解释支持用户判断是否值得继续依赖这个系统 · L5.02.6 由若干局部解释归纳出的整体印象常常是错的 · L5.02.7 特征重要度是相关性排序，不能被读成因果说明 · L5.02.8 开发者需要的是调试信息，终端用户需要的是行动依据，二者不可共用一份解释
• 相邻：L5.01 可解释性的类型 · L5.08 反事实解释 · L5.05 透明度的适度原则
• 站内检索：local explanation for appeal · contest a decision · instance-level grounds