PERSLIS DEFENSE · 第三章 · 组合
规则堆多了，它就动不了。我们测了，也修了。
死局 6 → 0。把一条条都正确的规则堆起来，机器就会无路可走：30 条规则让它在 6 个情境里卡死，50 条是 12 个。按每条规则给整个集合带来的代价让它们退役，死局降到零——代价是什么，我们也摆给你看。
每一条交战规则、每一个禁入区、每一条火力协调规则，单看都有道理。没人去测它们合在一起会怎样。关键时刻卡死的机器，对班里来说跟乱跑的机器一样是个麻烦。
靠测量，不靠猜
在测试中系统实际遇到的 91 个情境里，我们逐个统计了规则集之下还剩多少动作是允许的。
| 规则集 | 规则数 | 死局 | 被迫 |
|---|---|---|---|
| 有上限的工作集 | 30 | 6 | 9 |
| 无上限 | 50 | 12 | 15 |
规则翻一倍，死局也翻一倍。其中每一条规则都是真实失败换来的，单看都对。不设上限时，系统的成绩比根本不学还差——不是哪条规则错了，而是允许的动作清单只会越缩越短。
安全功能就是这样最后被关掉的。这件事很少被写下来，因为只有测量整个集合、而不是一条一条地看，才看得出来。
让规则退役，它才能重新动起来
常见的办法是按每条规则自己的证据打分，留下最好的 N 条。我们一开始就是这么做的。它照样是盲的：它只给单条规则打分，从不问合在一起会怎样。
所以我们给整个集合打分。对系统实际遇到的每个情境：
actions_seen(S) − actions_blocked(S) = choices_left(S) 0 → 死局 所有选项被拒；地板变成了一堵墙 1 → 被迫 只剩一个选项；它在这里不再做任何决定
一条规则的保护，是它解释得了的失败次数；它的代价，是它把多少情境推进死局或被迫。退役按“代价换保护”最不划算的顺序撤掉规则，直到重新有得选。在实测集合上：死局 6 → 0，代价是交还 29 次已记录的失败，被迫从 9 升到 14——情境从没得选变成只有一个选择。
退役让允许的动作清单能够重新长回来。只加不减永远做不到，这个差别正是班组规模的规则系统需要它、而不只是需要一份更长的规则清单的全部理由。这次测试里的规则全部是系统从自己的失败中学到的；命令不在测试范围之内。
为什么这是班组的问题
一台机器配三十条规则，还管得过来。一个班组就是这个数乘以单元数量，再加上只存在于单元之间的规则——间距、责任区、火力协调、通信窗口。到了这个规模，规则怎么叠加不是细节，而是问题的大头。
一个测不出自己瘫痪程度的系统，最后只能靠剩下的唯一信号来调：士兵把它关掉。我们宁可把数字直接交给你。这是在单个系统上测的；多台机器协同作业还没有测试过。