感谢harry提出的问题，促使我对dp2rms内的查重窗的加权判重算法进行了一定的增补改进。
原来的配置和用法完全兼容。
新增了两种配置办法(在服务器节点下的cfgs/dup配置文件中)：
1) <accessPoint>元素中，weight属性值原来是一个数字，表示当前检索点命中一次后要加的分数值。现在增加了一种能力，可以定义为多个数字用逗号间隔的列表，如：
<accessPoint name="责任者" weight="30,10,0" searchStyle="" />
表示从第一次开始，该检索点每次命中后所采用的不同的分数值。如果实际运行时命中次数超过列表中数字的个数，则依最后一个数字。显然，这个策略在只定义了一个数字的时候，行为和原来的只能定义一个数字时正好相同，这就叫“兼容”。
2) <accessPoint>元素中，searchStyle属性值原来是一个字符串，表示当前检索点采用的匹配风格，有“exact” “left” “middle” “right” 4种取值的可能，分别表示“精确一致”“前方一致”“中间一致”“后方一致”。如果该字符串缺省，则相当于“exact”效果。
现在增加了一种能力，允许这个字符串为一个由多个字符串值用逗号连接起来的列表，如：
<accessPoint name="责任者" weight="30" searchStyle="exact,average" />
或者
<accessPoint name="责任者" weight="30" searchStyle="average" />
searchStyle属性值中的average表示如果该检索点多次命中，则将累加的总分数除以应命中的次数，最终累加到权值里面的是这个运算后的分数，好像一个“平均数”。
注意，累加的总分数是被查重的记录的，而“应命中次数”是发起记录的检索点中该途径的key总数。
例如，发起记录中有三个责任者检索点，分别叫做“作者1” “作者2” “作者3”；而某一条被查重的记录中有两个责任者检索点，分别叫做“作者1” “作者2”。如果每次责任者检索点的命中都是要加30分，则被查重记录的这一次查重，将因为命中2个责任者检索点而形成60分，但是需要除以应命中次数3，也就是发起记录中的责任者检索点key个数3，运算结果为20，所以最后累加到权值总和里面的是20。
这个策略的用意，是试图评估类似多责任者检索点的情况下，两条记录吻合的程度。如果发起记录有3个责任者，和被查重记录吻合2个，那么得分应当为原始分数的2/3，这是很朴实的做法。
当然，如果发起记录有2个责任者，被查重记录有3个责任者，发起记录和被查重记录吻合2个，那么得分应当为原始分数的2/2，也就是100%，被查重记录多出来的1个责任者，没有被考虑进去。这是本策略不够复杂的地方。表明从发起记录到被查重记录，有一个“方向性”特性，...。
~~~
上述两种方法，建议不要在同一个<accessPoint>元素中混用。如果混用，可能有复杂的效果，目前没有来得及去测试验证，虽然不禁止，但是效果不清楚。
~~~
进行这些改进，是想用合适的成本和复杂度，对原有的加权算法进行改良。
dp2batch的安装包和函数库也已经更新，一边查重一边转入的方案，也能用到新的方法了。
不过dp2libraryws内的查重算法还没有更新，还是以前的算法。值得提醒的是，dp2catalog中使用的dp2libraryws协议的查重功能，和dp2rms和dp2batch都无关，它是dp2libraryws中的，显而易见。