- GT识别：不准确问题 & 错位问题 & 迭代GT自举到GV切图
- n36p01 提升对撞率二、GT识别不准确问题
- n36p01 提升对撞率三、迭代GT识别算法V7
- n36p02 提升识别准确度、GT识别竞争支持下显著度
- n36p03 提升识别准确度、深入调试ST竞争浮现的细节
- n36p04 提升识别准确度、深入调试GT竞争浮现的细节
- n36p05 提升识别准确度、回测GT竞争浮现（一）
- n36p06 提升识别准确度、回测GT竞争浮现（二）
- n36p07 GT自举GV实现（一）：解决ST错位问题
- n36p07B GT自举GV实现（二）：思考其后续SV实现
- n36p08 GT自举GV实现（三）：回测GT竞争浮现
- n36p09 GT自举GV实现（四）：迭代GT类比部分
- n36p10 GT自举GV实现（五）：回测GT竞争浮现
- n36p11 GT自举切图实现（一）：解决GV错位问题
- n36p12 GT自举切图实现（二）：测试
- n36p13 提升ST识别准确度
- n36p14 提升识别准确度、回测GT竞争浮现（三）
CreateTime 2026.01.24
在上节识别不准确问题中（主要是ST的问题），改了ST和GT都支持了“准中取具”，但经回测GT识别还是不准确，后来。
| 36011 | 准中取具后，GT识别仍然不准确问题 |
|---|---|
| 示图 |  |
| 复现 | 如上图训练0-9x3后，再扔个9。 |
| 说明1 | 如下代码段：虽然组特征识别总结里，显示91%是9，但其实个别GT识别结果并不准确。 |
| 说明2 | 如上图中，第3条压根无实质内容，完全不成形，第4条还像个9的样子，但仍不够。 |
| 说明3 | GT识别结果第一名（4/5匹配数），也是个不完整的局部特征（只显示了中间一小块儿长方形，未显出9的样子）。 |
| 分析 | 为什么这些前几名，符合度是1，匹配度0.87，防抽0.8，全是高分，但其实与9并不像（参考代码段第一行）。 |
| 思路1 | 查细节：可以把匹配到的元素打出来看看，看下这些元素，是怎么达到符合度匹配度都这么高的。 |
经调试：GT识别结果的匹配数偏低，转下表先处理这个问题 转下表。 |
|
| 思路2 | 即使结果里也有大致成形的9，为什么这些没能在竞争中优胜？ |
| 说明：这个其实还是GT的竞争问题，后面再修，现在先修思路1的子问题。 | |
| 结果 | 思路1的子问题到下表继续展开来查修，思路2的问题先放放，后面再说。 |
35154-代码段
//0. 组特征识别结果:T1434 符合度:1.00 匹配度:0.87 匹配数防抽:0.80 = 综合得分:0.692
//1. 组特征识别结果:T1414 符合度:1.00 匹配度:0.87 匹配数防抽:0.80 = 综合得分:0.692
//2. 组特征识别结果:T1309 符合度:1.00 匹配度:0.87 匹配数防抽:0.80 = 综合得分:0.692
//3. 组特征识别结果:T1275 符合度:1.00 匹配度:0.87 匹配数防抽:0.80 = 综合得分:0.692
//4. 组特征识别结果:T1475 符合度:1.00 匹配度:0.87 匹配数防抽:0.60 = 综合得分:0.523
//5. 组特征识别结果:T1334 符合度:1.00 匹配度:0.87 匹配数防抽:0.60 = 综合得分:0.523
//6. 组特征识别结果:T1476 符合度:1.00 匹配度:0.86 匹配数防抽:0.60 = 综合得分:0.516
组特征识别结果总结：(Mnist6=100% ,Mnist9=91% ,Mnist5=88% ,Mnist0=85% ,Mnist8=67% ,Mnist2=65% ,Mnist1=63% ,Mnist7=60% ,Mnist4=37% ,Mnist3=12% )小结：36011测得GT识别不准确是因为匹配数偏低（对撞率偏低）。
| 36012 | GT识别匹配数偏低问题 接35154-思路1-子问题 |
|---|---|
| 说明 | GT识别不够准确，测细节，发现普遍匹配数太低（对撞太少是基础都达不到，更别提更后面的准确问题了）。 |
| 复现 | 训练(0-9)x3，然后扔个9，让它识别，发现GT识别匹配数有偏低的问题（一般只有三四条）。 |
| 分析 | absST里有0的上半部分，assGT.itemST也必然存在这个上半部分吗？二者有交集？还是二者有包含关系？ |
| 1、二者不可能绝对相等现在就是这种，但匹配数很低。 | |
| 2、二者不能算交集，因为有交集肯定有非交集问题，会导致猫不是狗，狗也不是猫这样的不准确。 | |
| 3、absST包含assGT.itemST也不对，因为这样会让absST中有多余gv，识别出后会不准确。 | |
| 4、assGT.itemST包含absST，这个倒是一切ok，可计为匹配。 | |
| 原则 | 现在识别中要求equal对等关系，还是得改成contains全含关系，不然很难对撞上。 |
| 重点 | 说白了现在的识别不准问题说到底还是：对撞太低的问题（即需要提升对撞率）。 |
| 比如 | 比如absST为0的上半部分，而assGT.itemST为9的上半部分，比0的上半部分多一点尾巴，而0的上半部分不带。 |
| 此时9上半部分多一两个gv，但包含0上半部分，也应计为匹配上了。 | |
| 回顾 | 现在的GT识别算法，上例中这一条ST肯定就匹配不上了。 |
| 但其实9的上半部分只是少匹配上一两个GV，别的部分与现在的ProtoT还是很匹配的。 | |
| 方案1 | 把GT识别自举算法，改为assGT.itemST全含absST 5%。 |
| 优点、方案1可以直接判断全含，很可靠。 | |
| 缺点1、判断全含性能太差了。 | |
| 缺点2、全含后根据全含的gvs也判断不了位置符合，并且计算匹配度算力更吃不消，匹配度和位置符合度都计算不了。 | |
| 缺点3、全含也不表示这些全含的gvs可组成当前树下真实存在的神经元，它还未组建成node，就不可臆想定义的存在。 | |
| 否掉、方案1的缺点不可接受：臆想定义 & 无法复用 & 不易计算 & 性能差。 | |
| 方案2 | 直接判断mIsC即可，即：assGT.itemST抽象指向absST 95%。 |
| 分析、把GT识别自举算法：改为取出assGT.itemST.content_ps，判断其全含absST.content_ps。 | |
| 本质、其实取assST的全含抽象（有效抽象），再取assGT.itemST的抽象全含，其实就是判断二者mcIsBro。 | |
| 缺点、有可能mIsC不成立，但其实全含是成立的，所以方案2性能好但不那么可靠。 | |
| 优点、方案2的优点是可以复用匹配度。 | |
| 抉择、方案2的缺点也是一种优点，因为有抽象说明absNode被定义了，它可复用，是真实存在的信息神经元单元。 | |
| 方案PK | 1、有可能mIsC不成立，但其实全含是成立的，所以方案2性能好但不那么可靠，方案1可靠但性能差。 |
| 2、需要实际分析或测下方案1和2究竟哪个在这里更适合。 | |
| 3、其实主要性能差是因为assGT很多，不可能一个个全取出来。 | |
| 4、还有个方法，absST的GV是源自assST，而assST数据不多，assST.GV全取出来也不多。 | |
| 5、用所有的assST.GV取其refPorts来判断是否全含assGT.itemST也是可以的。 | |
| 6、不过这仍然需要把assGT.itemST全取出来。 | |
| 7、画图分析：这里的启发式激活通路，其实就是assST和assGT.itemST，二者有共同抽象。 | |
| 白话 | 世上没有两片完全一样的树叶，识别本身就是找共同抽象，只是哪个更准罢了（位置符合&匹配度竞争）。 |
| 结果 | 下表36013继续深入分析确定下该方案有没问题，然后在36014进行工程实践。 |
小结：36012为GT识别匹配数偏低（对撞率偏低）问题，制定了解决方案，并最终选定方案2。
| 36013 | 疑问：现在特征识别的通路，要走的层级有点多。 |
|---|---|
| 示图 |  |
| 说明 | 如图，从ProtoT到最后一步步识别GT的通路如上图，从这个图上看，我们怎么来优化GT识别算法比较好？ |
| 通路1 | 1. Proto向上：从最具层ProtoT，到似层AssST，再到交层AbsST |
| 通路2 | 2. Ass向上：然后AssGT.itemST本身应处于似层，再向交层取AbsST。 |
| 疑问1 | 那么：我们能否简化一下？是否需要简化？ |
| 说明：比如只从ProtoT -> AssST后，不取AbsST了，直接向具象找ConST，然后refGT。 | |
| 缺点：AssST之所以取有效全含抽象：AbsST，是因为AssST太单一了，它不向上取全含有效抽象的话，甚至具象就只有ProtoT了。 | |
| 解答：本来就是提升对撞率的，不向抽象匹配激活有效抽象ST，就无法实现广入，所以暂不需要简化。 | |
| 疑问2 | 按上图所示，怎么refGT？ |
| 解答：现在的refGT方式就ok，取AssST的有效absST后，直接refGT。 | |
| 结果 | 现在的特征识别走的通路并不算多，还是继续实践36012的方案2吧 转下表进行工程实践。 |
小结：在36013继续深入分析了36012中解决方案2是否还有什么问题，主要是怀疑其通路复杂，经分析发现方案2没问题，可以继续推进工程实践。
| 36014 | GT识别匹配数偏低问题：用mcIsBro改进GT识别算法对撞率（参考36012-方案2） |
|---|---|
| TODO1 | 其实就是判断assST和assGT.itemST二者mcIsBro=true（参考方案2-本质）。 |
| TODO2 | 然后把二者共同抽象中，复用匹配度相乘（aIsC 乘 bIsC）最best的匹配度计算出来。 |
| TODO3 | 即然GT识别自举用isBro来判断，那切入点是不是也应用absST.conST来refGT（现在是用absST在refGT) |
| 中断 | 以上3个TODO都很简单，其实难点在于GT自举算法也得跟着改，通路一变，整个位置符合度就得重新计算，转下表。 |
| 追加 | 其实以上相当于把GT识别算法的通路都加了一层，这已经不单单是改下mcIsBro了，而是整个模型和算法都需要改进 转n36p02。 |
小结：36014本来要实践TODOLIST了，但发现还是想的不够深入，先中断下，转下表先分析下：GT自举算法需要跟着怎么迭代。
| 36015 | 继续深入：识别通路变了，GT自举的位置符合度的Rect计算也得跟着变 |
|---|---|
| 分析 | 通过预演GT自举算法的步骤，来思考新通路下的Rect怎么算，如下： |
| 第1步 | 本来assST只是识别的准中取具的结果，而absST才是真正的单特征识别结果。 |
| 第2步 | 而为了提高对撞率，用absST.con取的兄弟broST，是可以预估broST_ProtoRect的。 |
| 第3步 | 并且根据broST.refGT后，也可得出broST_AssGTRect。 |
| 第4步 | 统一坐标系：为方便计算需要统一下坐标系，我们可以选择到AssGT下统一坐标系，因为AssGT的元素是确定的。 |
| 第5步 | 自举时：根据每个AssGT.itemST在assGT中的rect，计算预估其在Proto中的Rect。 |
| 第6步 | 把这个预估broST_ProtoRect，转为rectIndex，然后从broST池中，找出rectIndex一样的。 |
| 第7步 | 对以上池中筛选出的有效broSTs，仅保留best匹配度的一条。 |
| 总结1 | 以上步骤，是在位置符合度建立索引，然后完全一致防重的基础上，计算其匹配度。 |
| 总结2 | 即位置符合度绝对是100%，只是匹配度在通过竞争找最准的而已。 |
| 总结3 | 这做法其实和ST识别时是类似的，位置符合的基础上，进行rectIndex防重，进行匹配度best竞争。 |
| 结果 | 经以上分析，看来GT识别确实需要这么大改，且改动挺大的。 |
小结：35015中，通过预演GT自举算法的步骤，捋顺当前GT识别算法迭代需求的大致情况，且发现这一改动，与先前的ST识别迭代非常相似（ST时是自举切protoRect像素范围，现在是自举预估AtProtoRect范围，其实二者都是回归到ProtoT原图上，取同样的范围，这样可以避免走形问题，并且还始终不脱离ProtoT原图）。
CreateTime 2026.01.29
上节末捋顺了提升GT对撞率的方式：用mcIsBro来判断GT识别的匹配，相当于识别通路的大变动，整个识别算法，GT识别自举，GT识别模型，计算Rect都要顺着这个通路做迭代，所以本节在这个思路下迭代下GT识别算法V7版本。
| 36011 | 迭代GT识别算法V7版本：TODOLIST |
|---|---|
| TODO1 | 把识别过程中的模型迭代为GTModelV2和GTItemV2，支持记录assST、absST、broST T。 |
| TODO2 | 新模型中要支持计算assST、absST、broST分别在Proto的Rect T |
| TODO3 | 先用assST取absST 现就有这个 T |
| TODO4 | 再用absST取broST T |
| TODO5 | 再用broST取ref.assGT T |
| TODO6 | 再对每个assGT做GT自举算法 T |
| TODO7 | 性能：用assST_Proto建立rectIndex + absST + broST整个通路来做防重 T。 |
| TODO8 | assGTs结果竞争排序可视化debug等代码复用原代码不变 不用改 |
| TODO9 | GT类比算法也改下兼容新的GTModelV2和GTItemV2模型 T |
| TODO10 | 性能1：broST_ProtoRect可用于复用优化性能？还是别的什么作用 还没明白怎么用，后做 |
| TODO11 | 性能2：同一个assGT，在同一个broST_ProtoRect.rectIndex时，进行防重 T。 |
小结：上表迭代了GT识别算法V7版本。
| 36012 | 训练和回测：组特征识别 |
|---|---|
| 基础知识库 | 跑下0-9x4（0-9依次跑，共跑4轮）。 |
| 回测项1 | 测下对撞率是否已经提升了。 |
| 结果：经测对撞率提高了，经常有匹配数8条以上的，以前匹配数只有两条左右。 | |
| 回测项2 | 看能不能识别出2和3的区别。 |
| 计划：在基础知识库基础上，扔第5张0-9，看下GT识别可视化和总结日志，是否准确。 | |
| 结果1 | 经观察，扔0-9整体比较偏向准确，比如0、1、5、8、9都能100%准确。 |
| 结果2 | 但也有别的只是偏向准确，比如2可能识别成100%的3，80%的5，40%的2。 |
小结：上表测试了对撞率确实提升了。
| 36013 | 看下“更新logDesc”有没什么问题， |
|---|---|
| 疑问 | 看下总结日志，都应该把匹配率乘进去，不然匹配数很低的太占便宜。 |
| 结果 | 把匹配率也乘进去了 T。 |
| 36014 | 组特征识别结果只有第一条综合得分>0 |
|---|---|
| 日志 | 0. 组特征识别结果:T1489 匹配度:0.35 匹配数防抽:1.00 = 综合得分:0.349 |
| 1. 组特征识别结果:T1269 匹配度:0.28 匹配数防抽:0.00 = 综合得分:0.000 | |
| 2. 组特征识别结果:T1075 匹配度:0.28 匹配数防抽:0.00 = 综合得分:0.000 | |
| 3. 组特征识别结果:T1074 匹配度:0.28 匹配数防抽:0.00 = 综合得分:0.000 | |
| 说明 | 如上日志，为什么除了第一条，别的全是0，匹配数防抽全是0。 |
| 原因 | 因为float类型，在计算时分子分母全是int，所以匹配率算出来的全是1和0T |
| 结果 | 修复后，不再全是1和0了 T。 |
小结：上表修复了竞争因子匹配数=0的BUG。
| 36015 | 测区分手写2和3 |
|---|---|
| 基础知识库 | 先跑(0-9)x6。 |
| 测试 | 然后扔第7张2和3，只看识别最准确的第一条总结日志如下： |
| 扔2时 | 组特征识别结果总结：(Mnist2=100% ) |
| 扔3时 | 组特征识别结果总结：(Mnist3=100% ) |
| 结果 | 看起来，区分2和3没什么问题。 |
| 追加 | 以上只是总结了第一条GT识别结果，因为第二条开始识别率很低，转下表查修 T。 |
| 36016 | 问题：查为什么GT识别结果第一条匹配率高，后面的都低。 |
|---|---|
| 分析 | 比如第一条匹配率是（15/15），第二条开始就成了（5/13）、(4/17)、（2/12）等很低的匹配率。 |
| 修复 | 第1条是ProtoT，第二条开始才是正常的，把ProtoT过滤掉了 T。 |
小结：上表把ProtoT从GT识别过程中过滤掉。
| 36017 | logDesc的传递问题 |
|---|---|
| 说明 | 边跑边测哪里有不合理的细节问题，就改下，如下： |
| TODO | logDesc不需要从protoGT传递到assGT，虽相似但自己就是自己，相似之处已经存到absT中了 T。 |
小结：上表改了个细节问题：“logDesc不从protoGT传递到assGT”，
| 36018 | 测GT识别结果的竞争浮现过程：“GT识别中未体现出显著度的问题”。 |
|---|---|
| 经测 | GT竞争浮现过程效果不够明显，下面分析之。 |
| 问题 | GT竞争浮现效果没那么明显，GT识别的结果往往不是很明显的成形。 |
| 疑点1 | 是GV压缩，导致了GT识别有影响？（轮廓和细节要区分判断匹配权重？） |
| 分析、本来T模块只有指针类型，只允许抽具关联来判别，不管GV压不压缩，在ST时都不允许再用稀疏码计算。 | |
| 结果、所以不是这个疑点的问题，想想别的疑点，如下。 | |
| 疑点2 | 加训基础知识库，自然能把基础特征都抽出来，无论0-9还是别的，最终都由这些基础抽象特征来拼成。 |
| 分析 | 疑点2需要细节分析下步骤，如下： |
| 步骤1 | ST可能来自0-9任何一处（比如0上半部分，可能来自9也可能来自6，来自0）。 |
| 步骤2 | ST一定要可以识别到这些显著特征（比如要可以从assST的有效抽象中，可稳定取到0的上半部分）。 |
| 步骤3 | 识别GT时找broST，那么如果一个absST是显著特征，在这个过程中有什么竞争优势？ |
| 解释：如果它没有竞争优势，我们找不找得出这个显著特征，就体现不出意义。 | |
| 线索：识别的assST->absST->broST通路中，如果absST是0的上半部分，那应在GT识别竞争中体现出其优势。 | |
| 思路：它能体现出竞争优势，这个稳定的抽象才能体现作用：“使显著的ST在GT识别结果中有所体现”。 | |
| 解答：即在GT识别中，应该让ST的显著度影响竞争因子。 | |
| 总结 | 如上疑点2，及其展开的步骤分析（尤其是步骤3），挑明了现在问题出在显著ST没在GT识别中体现出来。 |
| 方案 | 把ST显著度作用于GT识别竞争。 |
小结：上表测得GT竞争浮现不够明显的问题（说白了就是显著特征未起到作用），并分析制定解决方案。
| 36019 | 继续深入分析显著特征：“显著特征的竞争浮现演化” |
|---|---|
| 意义 | 显著ST的意义在于，线段是由两个端点一条线组成的，而不是由一小段线段，再加一小段线段...组成的。 |
| 问题 | 如何保证protoGT或absGT是由显著特征构成的？ |
| 演化 | 我们应该让越来越显著的抽具象ST树，能够浮现出来，这将是高质量识别的升华。 |
| 分析 | 如果GT不由显著特征构成，我们怎么让它慢慢由显著构建的越来越多，这个演化步骤分析如下。 |
| 步骤1 | ProtoT都是不显著的（显著和不显著的全在里面），由具层assSTs构建而成。 |
| 步骤2 | 用assST取absST时，就可以体现显著度了，使之越显著越有竞争力。 |
| 步骤3 | 用absST取broST时，依然体现显著度，使之越显著越有竞争力。 |
| 步骤4 | 因为步骤2和3的竞争，可把assGT中，那些竞争力强的显著ST，构建成absGT。 |
| 步骤5 | 这些显著度高一些的absGT，在今后的竞争中，会更容易优胜，变的越来越显著。 |
| 总结 | 以上步骤，仅通过步骤2和3的改动，就顺利把整个GT的显著演化过程打通了。 |
小结：上表深入分析了显著特征的竞争浮现演化过程，并寻得步骤2和3这两个关键，为后续TODOLIST找准了方向。
| 3601a | 示例分析：没有显著度相当于匹配度高但识别错误识别结果。 |
|---|---|
| 白话 | GT识别通路解决了宽入的问题，但窄出用匹配度是不够的，有很多匹配度高的错误识别结果。 |
| 回顾 | 36018的前提当时跑代码时，就是明明很多像2的结果，但其实只是别的数字的某部分形似，是却又不准。 |
| 示例1 | 2也有0的上半部分，但没人会直觉上优先2的半圆。 |
| 示例2 | 4也有7的横竖拐角，但4的显著特征是ㄥ和⎜，而不是左下角的7和上半部分/L。 |
| 总结 | 如果不做显著度，相当于有很多“匹配度高的错误识别结果”。 |
小结：上表继续通过示例分析了显著度的重要性，将当前问题总结为：“匹配度高的错误识别结果”。
CreateTime 2026.02.07
上表36019和3601a，敲定了GT识别中显著度的重要性，以及TODOLIST的切入点（参考36019步骤2 & 步骤3）。
| 36021 | GT识别竞争支持下显著度：TODOLIST |
|---|---|
| TODO1 | 将assST指向absST的强度计为计算显著度的因素之一 T。 |
| TODO2 | 将absST指向broST的强度计为计算显著度的因素之二 T。 |
| TODO3 | 核实下特征抽象时，增强强度strong+1 T 本来就有。 |
| TODO4 | 考虑下抽具象强度每次不是+1，而是+抽具象匹配率 这个属于后续优化，先测着有效再做这个。 |
| 回测 | 没什么效果，经测显著度都是1，0.64，0.8什么的，似乎分母比较小？转下表继续查下。 |
| 36022 | 继续查下GT识别加上显著度后，效果不理想的原因。 |
|---|---|
| 可疑1 | absT很难对撞，所以显著值strongValue应该无法正常累计起来（导致全是1，0.64等）。 |
| 思路：但它的GV是可以累计起来的。 | |
| 可疑2 | ST识别竞争也得加上显著度吧？ |
| 思路：ST都没有抽象，如果要加显著度，相当于必须分析其GV是否显著了。 | |
| 实践分析 | 两个可疑都指向GV，相当于抽象ST中，每个GV都要单独统计强度值（AIPort.strong）。 |
| 但是contentPorts必然是同时统计的，所以字典和不字典也没差别。 | |
| 所以：可以把abs的content的总和统计值，统计到con中，这样就可以了。 | |
| 相当于在conT.contentPorts中的强度值。 | |
| 白话 | ST的显著度不能以ST的抽具Port强度来，而是以元素GV的被抽象使用次数来。 |
| TODO1 | 类比T时，把absT的内容，在assT中的contentPort的strong+1 T。 |
| TODO2 | 在GT识别absST的显著度:以具象(assST/broST)的contentPorts的强度统计来做显著度 T。 |
| 回测 | 看起来显著度确实各种精度值都有了 T。 |
| 追加 | 但GT识别的竞争浮现仍不明显，还是得深入细节调试整个流程。 |
小结：上面两个表，在GT识别中新增了显著度，不过识别准确度效果不明显，需要继续深入细节中查一下，转下表。
CreateTime 2026.02.08
主要做竞争浮现的调参：本节做了ST部分，下节搞GT部分。
| 36031 | 大岗：深入调试GT竞争浮现的细节。 |
|---|---|
| 前期准备 | 训练下基础知识库：0-9x5轮。 |
| 调试项1 | 调试下扔2识别2时，识别结果中logDesc也是2的结果： |
| ST识别：在assST结果中，它们的匹配项及等竞争因子实际情况。 | |
| GT识别：在assGT结果中，它们的匹配项及等竞争因子实际情况。 | |
| 调试项2 | 边测试边调整ST竞争因子，使识图结果浮现显著局部特征OK。 |
| 比如：随着竞争浮现，可以取到0的上半部分，或者2下面的拐角，或者5左上的直角。 |
小结：制定了深入细节测试，先测ST，再测GT的大岗。 计划：下面测调ST的竞争浮现及竞争因子参数，目标是随着竞争浮现，可以显示出局部显著特征（如0的上半部分，2下方的拐角，5左上的直角）。
| 36032 | BUG1：9里面识别到了0的BUG（GV零散导致的特征不独立问题） |
|---|---|
| BUG1 |  |
| 如图 | 明明扔的是0，却识别到assST=9，匹配到6个GV，但这些GV不相邻。 |
| 思路 | 看起来这6个GV确实摆出了0的样子，只是这些GV并不是9的显著特征。 |
| 而是很多边缘边角料呈现出来的0的一点外轮廓的样子。 | |
| 原因 | 看起来就是：“GV零散导致的特征不独立问题” |
| 相邻才可能共同呈现出一个明确独立的局部特征。 | |
| 方案 | ST识别时，GV匹配优先相邻的（给相邻度评分做为ST竞争因子）T。 |
| 回测 | 发现效果不明显，下表BUG2修了后，再测试。 |
小结：上表修ST特征识别太零散问题，加了相邻度，不过效果不明显。
| 36033 | BUG2：很多ST识别结果都是铺满画布的 |
|---|---|
| 说明 | 发现很多都是27x27把画布铺满的，其实前面就发现这个问题了，不过一直没修。 |
| 方案 | 可以加个粒度竞争因子：太大的GV粒子，或太小的GV粒子，都打压一下 T。 |
| 回测 | 发现效果不明显，下表继续查修。 |
| 36034 | 问题：调试下27x27的竞争因子都是什么值，为什么它那么强总是可以优胜。 |
|---|---|
| 经查 | 27x27的全是切入点。 |
| 方案1 | 铺满画布做切入点没意义，粒度太大了（可以先去掉27x27的切入点试下识别）粒度太大，转方案2。 |
| 经查：现在dotSize粒度是>5才行。 | |
| 所以：九宫就是3倍，即15-27最大，所以切入点太大了，现在的切入九宫范围为:15-27。 | |
| 方案2 | 把切入九宫范围从现在的15-27 -> 调整为3-13.5，把极大极小都切掉。 |
| 说明：把GV粒度调整为3-(27/3)，即SV大小为1-(27/6)， | |
| 重点 | 粒度太小切分组20%都不够，太大则只有轮廓而已，二者意义都不明，还浪费很多性能(参考35126) |
| TODO2.1 | 即dotSize的范围为1-4.5之间 T。 |
| 测图 |  |
| 回测 | 改方案2-TODO2.1后，全是27x27的问题好了（如上图），但有性能问题，转下表进行优化。 |
小结：上两表修ST识别总是铺满画布的问题，加了dotSize粒度切入范围，回测ok。
| 36036 | 上表调整切入点范围后，ST识别有5000多条，非常卡 |
|---|---|
| 思路 | 有一些ST结果即可，那些过抽象的，提前就可以过滤了。 |
| 本质 | 说白就是广入窄出，广入太多了（无非是针对广入的竞争不够激烈）。 |
| 方案V1 | 以前有过类似做法：直接只取最具层isJiao=false，交层全过滤掉。 |
| 说明：把所有refPorts的强度前x名大量减少即可。 | |
| 优点：本来就没法照顾到所有似交层特征，只识别似层，然后交层通过有效抽象也可取得。 | |
| 缺点：现在的refPorts太散了，都是针对不同的gv来ref的，所以不太好同台竞争。 | |
| 实践：改后发现没效果，虽然确实过滤了交层，但激活的ST仍然很多。 | |
| 思考进展1 | 增强相近GVs的竞争力，以减少GV切入点。 |
| 说明：40个gv，分别激活相近的20个gv，又分别ref到5个assST，就是4000条了。 | |
| 白话：说白了，要加强GV的竞争淘汰机制。 | |
| 分析1：最终稳定浮现的局部特征无非是线，弦，角，方形，等这些常见的。 | |
| 分析2：组成这些稳定的“线弦角方”的GV就是我们应该采纳的切入点，别的全否掉。 | |
| 问题：用什么竞争因子来实现GV的竞争？ | |
| 思考进展2 | 用GV相近度来实现GV竞争。 |
| 缺点：相近的特多，并且相近不表示准确，如不同光线相近度很不同，但结果导向时发现它才是准确的。 | |
| 思考进展3 | 结果导向，当GV识别到稳定浮现的ST时，加强其GV.refPort.strong强度。 |
| 缺点：GV.refPort.strong来竞争，又有方案V1中refPorts太散的问题。 | |
| 思路：不管太散了，把这些散的全收集起来，然后用强度统一竞争淘汰吧。 | |
| 比如：全国高考时，总分都差不多，那么随便一个考生直接问总分，也是可以大致判断出成绩好坏的。 | |
| 方案V2 | 把GV.refPorts全收集起来，只对前20%强度的refPort对应的assST进行识别。 |
| 说明：即无论是GV.refST还是st.refGT，在广入上都要控制好量，量太大肯定就爆炸。 | |
| 比如：GV的refPorts中最强的，就是ST中最常用的，如“线弦角方”等这些ST（参考35105-方案2-解决）。 | |
| 子问题1 | “线弦角方”这些ST如果从似层找，其强度很难累计成长起来（参考35105-方案2-解决）。 |
| 子分析1 | 能不能累计成长起来，要看assST的候选量（越少越好），以及累计次数（发生越多越好）。 |
| 子解答1 | 识别累计次数是相对固定的A，而取似层则候选量少B，所以A/B应该是更容量累积的。 |
| 示例推演 | 1. 比如刚开始识别陌生物种都是一模一样的。 |
| 2. 后面慢慢这些GV慢慢构建起来。 | |
| 3. 其GV.refST.strong也慢慢构建越来越强。 | |
| 4. 才能达到原知识激活的min阈值，才有资格激活。 | |
| 5. 才能够识别分辨这个陌生物种。 | |
| 注1. 活的越久，这个min阈值就越强大，越难达成。 | |
| 注2. 亦可借助即有特征提前达成识别：如陌生物种的肤色、身高、胖瘦，毛发长短。 | |
| TODO | ST识别算法中，把GV.refPorts全收集起来，竞争强度，只保留强度最强的20到100条 T。 |
| 回测 | 经回测，性能好了，但有别的问题，转下表。 |
小结：上表修复了ST识别的性能问题，但有别的问题转下表。
| 36037 | 问题：GV.refPorts强度排名靠前的全是同一个assST，最终强者恒强。 |
|---|---|
| 说明 | 问题体现为：从同一个assST中可以找出任意局部ST，并拼成0-9任何一个数字 |
| 问题1 | 但全从一个assST中各种protoRect找局部特征，它匹配率一般都偏低（用0识别1肯定匹配率很低）。 |
| 问题2 | 如果不识别就不知道它很低，如果识别了，它就排在前100名被正常广入。 |
| 方案v1 | 要么把广入增加一些，让别的都有机会进去。 |
| 缺点：如果前3000条全是同一个assST呢？总不能增加3000条机会 | |
| 方案v2 | 要么同一个assST与proto的识别结果：只保留最准确的一条。 |
| 缺点：怎么找出识别结果最准确的一条呢，如果有3000条难道全识别一遍？ | |
| 方案v3 | 同一个assST与proto的识别结果：只保留最准确的一条，且给10次识别机会 95%。 |
| 说明：如果10次还捕捉不到很好的局部匹配，那说明assST和protoT真的很不一样，不必强找相同局部。 | |
| 抉择 | 方案v1缺点会导致性能差，方案v2也一样，方案v3折中，即照顾了10次保底机会，又不至于拖死性能。 |
| TODO1 | 同一个assST只允许进十次 T。 |
实践：写个计数字典即可 T。 |
|
| TODO2 | 同一个assST怎么只保留最准确的一两条？不用改，当前竞争机制本就可以 |
| 解答：在竞争中，把不准确的那些assST多余条数自然竞争淘汰掉。 | |
| 回测 | 经回测有效果。 |
小结：上表修复了一例BUG。
| 36038 | ST识别结果中：最准确的为什么排在最后面 |
|---|---|
| 示图 |  |
| 说明 | 识别0时，识别到结果0的匹配数最高，但竟然排在最后一名，查下原因，日志如下： |
| 0. 单特征识别结果:T1491 (5/41) 匹配度:0.72 匹配数防抽:0.29 区域竞争力:0.57 (总分35/科数8=均分4) 相邻度:0.65 中心度:0.96 = 总分:0.36 | |
| 1. 单特征识别结果:T1599 (4/38) 匹配度:0.73 匹配数防抽:0.24 区域竞争力:0.60 (总分37/科数8=均分5) 相邻度:0.76 中心度:0.74 = 总分:0.34 | |
| 2. 单特征识别结果:T1560 (4/32) 匹配度:0.74 匹配数防抽:0.24 区域竞争力:0.62 (总分53/科数11=均分5) 相邻度:0.52 中心度:0.98 = 总分:0.31 | |
| 3. 单特征识别结果:T1491 (7/41) 匹配度:0.76 匹配数防抽:0.41 区域竞争力:1.00 (总分85/科数11=均分8) 相邻度:0.55 中心度:0.50 = 总分:0.28 | |
| 4. 单特征识别结果:T1560 (3/32) 匹配度:0.80 匹配数防抽:0.18 区域竞争力:0.71 (总分38/科数7=均分5) 相邻度:0.65 中心度:0.54 = 总分:0.25 | |
| 5. 单特征识别结果:T859 (4/38) 匹配度:0.75 匹配数防抽:0.24 区域竞争力:0.73 (总分34/科数6=均分6) 相邻度:0.43 中心度:0.69 = 总分:0.22 | |
| 6. 单特征识别结果:T893 (6/23) 匹配度:0.81 匹配数防抽:0.35 区域竞争力:0.65 (总分5/科数1=均分5) 相邻度:0.50 中心度:0.64 = 总分:0.21 | |
| 7. 单特征识别结果:T1491 (8/41) 匹配度:0.75 匹配数防抽:0.47 区域竞争力:0.65 (总分35/科数7=均分5) 相邻度:0.32 中心度:0.92 = 总分:0.19 | |
| 8. 单特征识别结果:T859 (9/38) 匹配度:0.74 匹配数防抽:0.53 区域竞争力:0.52 (总分4/科数1=均分4) 相邻度:0.38 中心度:0.94 = 总分:0.18 | |
| 9. 单特征识别结果:T1529 (7/43) 匹配度:0.71 匹配数防抽:0.41 区域竞争力:0.63 (总分34/科数7=均分5) 相邻度:0.36 中心度:0.79 = 总分:0.18 | |
| 10. 单特征识别结果:T1491 (7/41) 匹配度:0.72 匹配数防抽:0.41 区域竞争力:0.63 (总分34/科数7=均分5) 相邻度:0.32 中心度:0.71 = 总分:0.15 | |
| 11. 单特征识别结果:T859 (17/38) 匹配度:0.70 匹配数防抽:1.00 区域竞争力:0.29 (总分9/科数4=均分2) 相邻度:0.54 中心度:0.91 = 总分:0.14 | |
| 分析 | 如上日志，各项全是满分，但区域竞争力竟然是最低分，这个区域竞争力应该可以废弃了。 |
| 正据 | 前段时间一直想废弃它，但没机会，这次算是需求明确了，该废弃了。 |
| 回测 | 废弃掉后，最准确的不会排在后面了，排在前面了。 |
小结：上表修复了ST识别准确的排在最后面问题，把区域竞争废弃了，下表继续测GT识别的准确问题
CreateTime 2026.02.16
| 36041 | 继续测GT识别及调参 |
|---|---|
| 说明 | GT识别结果明确不准确，跑了0-9x4的基础视觉库后，识别还是不准确。 |
| 测试项 | GT识别：在assGT结果中，它们的匹配项及等竞争因子实际情况。 |
| 调试项 | 调试下GT识别算法的竞争，看为什么不准确，原因，及调用。 |
| 测得 | 测得GT识别的匹配度都很低，转下表查修。 |
36042-BUG：查下GT识别的matchValue值很低，一般只有0.1左右。
修复目标、将GT匹配度从0.1提升到0.8以上。
分析、这里乘上匹配率后就很低，而这个率又是assST -> absST -> broST这个通路带来的。
思路1、那么，似层assGT中，就不可能有很准确的，把通路迁移的低匹配率全乘进来，更是很难找着准确的。
否掉：可是这个通路应该没问题的，毕竟要维持对撞率，就必须有这个通路。
思路2、还有一种可能，任何一条assGT.itemST都会因为很不匹配，而把整个匹配度拉低。
否掉：现在的GTModel.matchValue是取平均，无此问题。
思路3、加训，让absST更丰富起来，然后能找到更好的assST -> absST -> broST通路，使匹配度有更高的选择。
调试：可以去掉显著度，去掉匹配率，跑一下基础视觉库，看这块匹配度能不能随着加训，变的越来越高。
经测：去掉后，扔7个0，发现GT识别结果匹配度还是0.1左右，并且匹配数一般只有1条。
继续查下：为什么匹配数只有1条（对撞不上了？），再查下为什么匹配度这么低（应该是因为乘了匹配率：见下方matchValue = stModel.matchValue * matchCountRatio代码）。
查下为什么匹配数又只有一条了：发现在关掉<关掉显著度测试>之前还算ok。
思路4、这个通路说到底：只是在判断assST与broST的交集而已，那么，是否可以把取<有效抽象>改为取<所有抽象>。
实测：需要实测下，如果取有效抽象，改为所有抽象后，能不能使GT随着加训匹配度越来越高。
思路5、把通路改成assST -> absST，去掉broST，然后识别的assGT改成由absST构成。
原因：因为absST -> broST这个相当于介入了混乱熵增，是不符合原则的，如下（计算通路匹配度的公式AxB如下）：
A、assST与有效抽象的匹配度 = 匹配的indexDic对应的bestGVs的平均匹配度。
B、而有效抽象与bro的匹配度 = 。。。（这个总是会很低的，并且介入了absST中都没有的gv，这个不符合熵减原则）。
总结：上面有五个思路，逐个推进，主要是思路5，从原则角度上推导出如下方案：
方案1：把通路改成assST -> absST，去掉broST，然后识别的assGT改成由absST构成。
TODO1：这样就识别不到似层AssGT结果了（因为全是absST来refGT的）`不成立，因为protoGT本就是由absST构成的 T`。
思路1：即似层的宏观一级应该由交层的微观一级构成，即：构成似层GT的也是absST。
TODO1.1: 在GT类比中，如果sameOrders长度与protoGT长度一致，则absGT也计做似层（这不现实，类比后很难匹配率=1）。
TODO1.2：GT识别允许交层，只是竞争时，加上匹配率，使似层优先（目前似层就够了，因为ProtoGT是由absST构成的，如下TODO1.3）。
TODO1.3: ProtoGT本来就是由absST构成的，不用改 `T`。
TODO2：GT类比时，把absGT与protoGT的匹配度关联，这些代码补上（以前有些我看没写）。
TODO3：在GT识别算法中，把取broST这步及相关代码全去掉。
方案1中断：**熵增有时候是有必要的，只是要可控：虽然找broST有熵增，但是一来这是广入的必要条件，二来有匹配度竞争，所以并不算不可控熵增。**
方案1转折：TODO2和TODO3先不做，因为如上中断 & 如下疑问6，重新制定了方案2（如下）。
疑问6：当时做assST->absST->broST通路就是为了对撞率，现在去掉broST对撞率必然下降，当然即使不去掉broST对撞率现在也不高。
分析6：现在简化通路为:assST->absST并不能解决问题，反而会更降低对撞率。
思路6、还是得让足够明显的ST尽快在竞争中浮现出来，比如：5的下方半圆部分，7的拐角部分。
方案2：还不如先调整显著assST的竞争力，使显著的局部特征可以快速“竞争浮现”。
TODO4：使可重用性高的assST能更有竞争力（用assST.absPorts.sumStrong来竞争）`T`。
后续：提升抽象指向数的竞争力后，先继续测下GT识别的匹配率。
经测：GT匹配率有明确上升，但GT匹配度仍然很低，如下日志：
0. 组特征识别结果:T857 (8/20) 匹配度:0.08 匹配率:0.53 显著度:1.00 = 综合得分:0.045
1. 组特征识别结果:T895 (9/9) 匹配度:0.07 匹配率:0.60 显著度:1.00 = 综合得分:0.041
总结：本表过了春节，所以比较散慢，大致是匹配率ok了，但匹配度还不行，下表继续查修。小结：本表过了春节，所以比较散慢，大致是匹配率ok了，但匹配度还不行，下表继续查修。
| 36043 | 继续查下GT识别匹配度很低的问题 |
|---|---|
| 经查 | 现计算方式为：absST.count / MAX(stModel.assT.count, broST.count); |
| 分析 | assST.count太长了，其实只是识别了bestGVs，不必整个assST全除。 |
| TODO1 | 改成：absST.count / MAX(stModel.bestGVs.count, broST.count) T; |
| 回测：修TODO1后经测，发现GT识别结果中，匹配度达到了0.5。 | |
| TODO2 | 还可以再看下可以不可以再优化下，提升匹配度 T。 |
| 实践：不管stModel.matchValue，只保留absST.count/MAX(stModel.bestGVs.count,broST.count); | |
| 回测：匹配度很正常了，达到0.7了。 | |
| TODO3 | 现在随着训练，GT识别结果匹配度并没有越来越高，可以查下。 |
| 原因1：从ass-abs-bro这个通路太复杂，结果匹配度本来就不好控制。 | |
| 原因2：即使往abs时可以强度控制，往bro时的竞争稳定也控制不住。 | |
| 原因3：而protoGT现在也是由absST来构建的，可以试下不用broST，简化通路，避免熵增。 | |
| 原因4：多一个通路，会导致strong竞争无效，匹配度多出多余信息也会无效。 | |
| 所以5：还是把通路assST->absST->broST改成assST->absST试下（参考36042-方案1）。 | |
| 结果 | TODO1和TODO2好了，TODO3转下表简化GT识别通路 转36044。 |
小结：优化GT匹配度过低的问题（从只有0.1或以下优化到了有0.7了）。
| 36044 | GT识别竞争浮现有问题（参考36043-TODO3） |
|---|---|
| 方案 | 简化GT通路为assST->absST（参考36042-方案1 & 36043-所以5）。 |
| TODO | 先调试下，如果改通路后，能不能识别到，匹配率怎么样，会不会导致别的问题 T。 |
| 结果 | 改完TODO简化通路后，发现GT识别没问题，匹配率也没问题，但测到了别的BUG见下表。 |
小结：简化GT识别通路为：assST-absST（并回测GT识别仍可以正常跑）。
| 36045 | BUG: 当前GT识别中似乎没有做位置符合判断 |
|---|---|
| 问题 | 看到GTItemV2中虽然计算了各种通路rect值，但未与assGT的进行比对。 |
| 回忆 | 但当时好像是用rectIndex进行分组了，判断了rect的匹配。 |
| 回顾1 | 经查代码，确实没有对absST_protoRect 与 absST_AssGTRect进行缩放偏移比对。 |
| 分析 | 查下在gtZiJv算法中，需要对assGT.item的rect 与 assST->absST在protoRect进行比对。 |
| 释义 | 两个场景分别为：absST_ProtoT（实际）和absST_AssGT（预计）。 |
| 回顾2 | 现在GT自举算法中：只判断了assST_Proto的rectIndex，应补上预计：absST_assGT也判断。 |
| 所以：最少也得把absST_AssGT加进防重来。 | |
| 回顾3 | 现代码中：GTItemV2中有absST_AssGT和absST_ProtoT。 |
| 方案1 | 预计与实际完全相同才重用：位置必须符合，不然不让其复用到 否掉 T。 |
| 说明：即位置符合度直接取1，然后用rectIndex来防重，判定其是否位置匹配。 | |
| 疑问：预计与实际必然有各种偏移缩放不同但相似的情况，二者的rectIndex很难完全匹配。 | |
| 比如：就像文字变形，写的8上面的0太小，下面的0太大的情况等。 | |
否掉：预计与实际的rectIndex完全一致，这种情况太理想，不可取 T。 |
|
| 方案2 | 实时判断预计与实际的rect交集率，需大于60%。 |
| 实践：bestSTDic收集一条元素就判断一次（已收集的：预计区域 与 实际区域 > 60%交集）。 | |
| TODO1 | 根据现有bests预计任意一个assIndex的rect（以前写过找不到了）下方展开 T。 |
| TODO2 | 计算预计NewBestAbsST在AssGT中的Rect T。 |
| 公式：根据1.bests_AssGT 2.bests_Proto 3.newAbsST_Proto 计算出4.newAbsST_AssGT | |
| TODO3 | 然后用预计的newAbsST_AssGT 和 实际的newAbsST_AssGT，计算二者的rect交集率 T。 |
| 测试1 | 测下TODO2计算的NewBestAbsSt_AssGTRect是否准确 T。 |
| 测试2 | 测下TODO3计算的交集率是否ok T。 |
| 结果 | 本表测试没啥问题了，继续向上回归测试从ST到GT识别是否准确 转n36p05。 |
小结：本节：1、修复了GT匹配度低的问题 2、简化了GT识别通路(assST-absST) 3、补齐了GT识别的位置符合度。
CreateTime 2026.03.05
上节修了GT匹配度低，简化通路，补齐位置符合度，本节继续回测GT识别。
| 36051 | 继续测GT识别是否准确，以及调参 |
|---|---|
| 方式1 | 先跑(0-9)x4基础视觉库，再测识别是否准确。 |
| 方式2 | 先跑多个0，再跑多个1...，以此类推，看能不能把位置符合度高的抽象GT的0，1...抽象出来。 |
| 方式3 | 站到更宏观的角度上，并结合示例，去分析整个特征T识别的系统设计，看有没什么问题或线索。 |
| 36052 | 方式3之：updateLogDesc到assGT识别结果上。 |
|---|---|
| 说明 | GT识别结果是不是准确识别匹配到logDesc不重要，重要的是我们认为它是（它就是识别结果）。 |
| 所以 | 把logDesc更新给assGT。 |
| 结果 | 转至36053-方案4，并且又改进直接更新给有效抽象GT了 转至36053-方案4 T。 |
| 36053 | 方式1之：训练基础视觉库后，发现有些GT识别准确，有些不准确，查下原因。 |
|---|---|
| 疑问1 | 继续加训基础视觉库，把0-9跑到第6轮后，发现GT识别匹配率并没有明显提高。 |
| 思路1 | 目前ST和GT的匹配率，全是按bests / maxCount 来做：归一化来计算的。 |
| 方案1 | 不如就改成：直接用bests / assT.count？ |
| 否掉：原本求的就是匹配数，而不是真的要匹配率，因为匹配到的有效抽象才是真正的识别结果。 | |
| 思路2 | 也不能完全就是找匹配数高的，总得从中找质量高的（显著ST）。 |
| 方案2 | GT识别时还是得把assST的竞争因子也乘进去，不然assST中三个竞争因子都有可能蒙混过去 T。 |
| 正据：assST的三个竞争因子是：匹配数，显著度，匹配度，三个任一个低了都会拖累让assGT也不好。 | |
| 方案3 | 在总结GT识别结果时，把有效抽象也计入其内？T |
| 正据：其实真正的识别结果是有效抽象，并不是那个assGT。 | |
| 方案4 | 把protoLogDesc同步更新到assST和assGT的有效抽象上 T。 |
| 正据：不然absT永远很难更新logDesc，事实上现在的识别结果其实是有效抽象，而不是assT。 | |
| 结果 | 方案1否掉了，方案2、3、4都改到代码了，下节回测GT识别。 |
小结：本节修了：1、GT识别把ST竞争因子也乘进去 2、总结识别结果改成对有效抽象做 3、把protoLogDesc同步到有效抽象。
CreateTime 2026.03.07
上节修了：1、GT识别把ST竞争因子也乘进去 2、总结识别结果改成对有效抽象做 3、把protoLogDesc同步到有效抽象，本节继续回测GT识别。
| 36061 | 继续测GT识别是否准确，以及调参 |
|---|---|
| 训练 | 跑(0-9)xN基础视觉库。 |
| 测试 | 边一轮轮跑0-9边观察GT识图结果的竞争因子是否越来越高越稳，并观察识别结果是否准确。 |
| 36062 | GT竞争因子随着训练越来越高，但却没有识别到准确的assGT结果。 |
|---|---|
| 问题 | GT识别结果从第1轮到第5轮，确实匹配数越来越高，别的竞争因子也都ok，但就是不准确。 |
| 说明 | 主要是直观从可视化看不太匹配，比如识别5结果有点乱，总之不像5。 |
| 分析 | 怀疑assST结果中，那些排名靠前的没在GT匹配数里，那些排名靠后的倒是在。 |
| 思路 | 1、调试下细节，debug下assGT第一名的细节，看下为什么它竞争优胜，但就是不准确。 |
| 2、查下assGT第一名的每个bests都是哪个，打出来看看，为什么没拼成整个准确的GT结果。 | |
| 经查 | GT识别的匹配数不高，共训练5轮，从开始的3到5，7最后第五轮也就达到8/14左右。 |
| 分析 | 1、训练了5轮0-9，但匹配数总是不太行，识别出的效果也不太明确。 |
| 2、感觉就是有些熵没有压下来，这里面肯定还是有设计问题。 | |
| 3、难道已经训练过了5个7，再跑新的7也识别不到原来的7么？ | |
| 4、为什么别的不像7的GT都能竞争到第一名，而原来跑过的7却不能激活或跑到第一名？ | |
| 5、目前最怀疑的是ST的错位问题，比如：7可以表征成横竖 或者 拐角和两点水。 | |
| 结果 | 1、本表测得GT识别各项竞争因子都看起来越来越好，但识别数不高，结果仍然不准确。 |
| 2、只能先从识别数入手了，争取把识别数再提升起来，转下表。 |
小结：上表测试发现，GT识别竞争因子看起来进展的还行，但匹配数有了瓶颈，识别结果也不准确。
CreateTime 2026.03.08
上节测得GT竞争因子的值虽然越来越高，但匹配数遇到瓶颈（提升很慢），而识别结果也不准确，本节分析方案并实践之。
| 36071 | ST识别结果错位问题（一）：“7可以表征成横竖 或者 拐角和两点水”。 |
|---|---|
| 示例 | 如果GT1表征了横竖，GT2表征了拐角和两点水。 |
| 问题1 | 那么：我们怎么保证下回进来的assST结果，同样表征了这些呢？ |
| 本质 | 即：针对不同的局部，可以对一个GT有很多很多种ST组合方式。 |
| 公式 | 如果一个GT有8种局部特征，如果任意3条ST就能表示它的整体，那就有8x7x6=336种。 |
| 即：我们很难再次在assST中正好激活到这三个ST，那我们就很容易识别GT失败。 | |
| 解答1 | 那我们就把它解析减少一个维度：把assSTs的bestGVs全收集成allBestGVs。 |
| 方案1 | 减少一个维度，把GT识别时，拆成allBestGVs来识别。 |
| 这样：无论识别到哪三个assST，都可以解析成和别的任意三条ST，一样的allBestGVs。 | |
| 正据：通过先合并allBestGVs再与GT自举的item进行全含判断（这样可以解决ST错位问题）。 | |
| 问题2 | 追问下：解析成allBestGVs就行了吗？会不会GV一样有错位的问题。 |
| 分析 | 那难道我们要再解析减少一个维度，把它再拆成单稀疏码SV吗？ |
| 解答2 | 问题2有可能但可能性小，我们只能先减少一个维度试一下，如果不行，再思考再减维度的事。 |
| 方案2 | 减少两个维度，把GT识别时，拆成allBestSVs来识别。 |
| 抉择 | 先尝试方案1，应该就好了，如果不好，再想方案2。 |
| 36072 | ST识别结果错位问题（二）：“相对方案：激活 + 识别” |
|---|---|
| 示例 | 识别人脸时，真的是按鼻子眼睛嘴巴来识别的么？ |
| 1、比如人脸的整体感觉，其实是整体的比例等整体感来的（每个人的整体感不同，其实是很自举的）。 | |
| 2、比如有一人脸上有道疤就成了识别他的最佳方法。 | |
| 本质 | 1、assSTs结果是很通用的显著稳定的局部。 |
| 2、但assGT却是个性化十足，很难被通用assST照顾涵盖到。 | |
| 3、故以有穷应无穷怠矣。 | |
| 原则 | 其实还是GT识别的自举问题，现在是自举到ST一层，发现不太够，只能再减维自举到GV一层了。 |
| 入 | 激活：通过GV-ST-GT方式能ref激活就行。 |
| 出 | 识别：识别还是得靠自举解析来搞GT-ST-GV。 |
| 白话 | 说白了，根本没有通用的筛子，通用的ST，还是得靠因材施教，一人一方。 |
| 方案3 | 保持GV-ST-GT来激活，把自举识别由GT-ST，细化下改成GT-ST-GV。 |
| 总结 | 其实方案3就是方案1，其实就是把GT自举算法迭代下，减少一个维度到GV统合起来来提升广入。 |
小结：36071从问题切入来直接分析问题，36072回到理论层面来深入分析问题。 其实：二者殊途同归，都是需要把GT自举算法减少一个维度。
| 36073 | ST识别结果错位问题（三）：“想想还有没别的方案” |
|---|---|
| 说明 | 说白了，就是要提升assST的广入。 |
| 方案4 | 还是广入的不够，把assST的数量级提上来，自然就能提升assGT的匹配数了。 |
| 缺点：此方案是单纯直接调整广入数量，在性能上会不佳，并且感觉治标不治本，效果有限。 | |
| 否掉：还是得自举，用单纯提升广入必然是不够的。 | |
| 方案5 | 粒度改为固定切图，而不是根据信息密度来切图（现在是无信息的地方就不切了）。 |
| 说明：切图规则统一后看似GT识别时更容易识别了。 | |
| 缺点：但ST还会经历各种抽象，输入视野也会不断变化，这种理想化是难以维系的。 | |
| 否掉：想像中的规则统一，在各种分层，变形，抽象，等之后，很难维系，否掉。 | |
| 方案6 | GT自举时，也落实到Proto层来切图，避免想像中的assSTs，再过一层，更脱离Proto。 |
| 分析：方案6与36071的方案2比较类似，相当于再再降维一层，落实到Proto切图上来。 | |
| 缺点：局部特征因为书法不同，每个7的这一横未必在Proto的同一个位置，有些高些，有些低些。 | |
| 否掉：完全落实到Proto切图不可行，因为“assGT的这个局部”与“Proto的这个局部”必然不太一样。 | |
| 结果 | 本表未想到更好的方案，目前来看，还是方案1&3，转下表实践规划。 |
小结：上表分析了有没别的方案，最终还是36071-方案1 和 36072-方案3更优，下面进行实践规划。
| 36074 | 36071-方案1 & 36072-方案3：TODOLIST实践规划 |
|---|---|
| 方案 | GT自举减少一个维度到GV层，统合成allBestGVs，来提升absST的广入（参考方案1 & 3）。 |
| TODO1 | 把GT自举算法根据每个assSTs的bestGVs，收集成allBestGVs 转TODO4。 |
| TODO2 | GT自举的assGT.item直接判断它的contentGVs被allBestGVs全含 转TODO4。 |
| TODO3 | GT的类比与ProtoGT没关系了，保留现在从assGT中把匹配的元素抽象成absGT即可 转TODO9。 |
| 示图 |  |
| TODO4 | 用ST给GV分组：对ST自举按ST中的rects对allBestGVs分组成ziJvGroup.groups T。 |
| TODO5 | 用GT给ST分组：然后递归到GT展开的ST，再按GT中的rects对分组groupSTs进行分组 T。 |
| TODO6 | 性能：ST给GV分组，按ST来防重复用（即每个ST仅对GV分组一次）T。 |
| TODO7 | 性能：GT给ST分组，按GT来防重复用（即每个GT仅对ST分组一次）T。 |
| TODO8 | 同时迭代下GT识别V9算法，采用以上自举算法 T。 |
| TODO9 | 同时迭代下GT识别的结果模型，从GTModelV2迭代成ZiJvGroup T。 |
| TODO10 | 同时迭代下GT类比算法，从GTModelV2迭代成支持ZiJvGroup T。 |
| 测试 | 修复小BUG使之跑起来了，回测训练转下节。 |
小结：上表对GT自举减维到GV层做了实践，并跑起来了，下表进行训练回测。
CreateTime 2026.03.16
如果还是不能准确识别到，分析下是否因为还没能完全减维到SV导致的？如果是，继续减维。
| 36075 | GT自举减维到SV：方案与实践规划 |
|---|---|
| 方案 | 如果需要这么做，GT自举再加一个减维算法，即写：gtZiJvV9_GV() |
| TODO1 | SV得判断相近度，而不是匹配度了。 |
小结：先不做，等测着迫切需求了再做。
CreateTime 2026.03.15
跑跑GT视觉识别算法演化过程，看能不能准确识别到。
| 36081 | 测试项（一） |
|---|---|
| TEST1 | 先跑下基础视觉库，并观察每跑一轮，GT识别有没明显变越来越准。 |
| 经测：跑完第一轮时，GT识别结果的各项竞争力已经很好了。 | |
| 日志：assGT1 (14/14) GT匹配度:0.63 GT符合度:0.81 匹配率:0.78 ST匹配度:0.78 ST符合度:1.00 | |
| TEST2 | 测下GT自举的性能。 |
| 经测：性能很差，第二轮时，识别一个0需要20s，得优化下。 | |
| 经查：GT自举最内层（分组）循环次数太多，有20w次，导致很慢。 | |
| 主要优化：把GT自举匹配数低的提前淘汰，减少循环数（GT自举中每条item跑完只保留匹配数前10名）。 | |
| 补充优化：把refPorts前三才进入循环。 | |
| 结果：优化后，GT识别共耗时1.5s，先这样，后面跑连续视觉时再优化到0.1s级。 |
| 36082 | 测试项（二） |
|---|---|
| TEST1 | 训练基础视觉库，观察细节GT识别准确情况。 |
| TEST2 | 连续训练2或3，看能不能识别到区别。 |
| 结果 | 测得下节问题，先继续迭代下类比V8再测。 |
小结：本节测试了GT识别降维到GV层，优化了性能。
CreateTime 2026.03.21
| 36091 | GT类比亦需降维至GV |
|---|---|
| 简介 | 上表（36082）测试时，测得需先完善下上节遗留的细节问题：GT类比也得降维到GV来完成。 |
| 步骤 | 1、先抽象ST（把gtGroup的每个bestSTs里的stGroup根据bestGVs先抽象出来）。 |
| 2、再抽象GT。 | |
| 优点 | 这样才更准确，不然明明bestST中只有一部分bestGVs到了，却要全抽象到absGT中？ |
| 说明：总不能bestGVs只匹配到半个圆，就把整个局部特征圆，都抽象构建到absGT里。 | |
| 缺点 | 变复杂了: 抽具象GT不再单纯是全含关系了，如具象是ABC，抽象可能是Ab |
| 说明：即不仅仅是少了C，连B也变成b（b只是B的一部分了）。 | |
| TODO1 | GT类比时，先把ST类比下（用stGroup.bestGVs来做ST抽象）T。 |
| TODO2 | 这样的话根据assGT取有效抽象validAbsGT，也得降维判断到bestGVs来取 不用改。 |
| 不用改：现在本来就是indexDic来判断有效抽象的，降维到GV后，不需要改。 | |
| TODO3 | GT类比先类比了stGroup，然后收集到这些absST，来构建absGT T。 |
| TODO4 | 即bestGVs构建absST，absSTs再构建absGT T。 |
| TODO5 | 而这期间的类比算法中的rect也要重新计算（因为改为用absST构建absGT了） T。 |
小结：上表迭代了GT类比V8：将GT类比也降维到GV层来实现了。
| 36092 | 回测GT类比V8算法 |
|---|---|
| BUG1 | GTV8类比中，indexDic有越界的情况 T。 |
CreateTime 2026.03.22
| 36101 | 训练回测 |
|---|---|
| 训练 | 跑2和3，看能不能越来越准确清楚的浮现出显著整体特征。 |
| 实际：跑的时候，只是扔几个0就行，压根不用扔2和3，直接在不同的0之间识别即可达到测试目的。 | |
| 调参 | GT识别，竞争因子有点多（现在是5项），分析精简下，看能不能优化竞争浮现效率 T。 |
| 思路：有些竞争因子没什么用了。 | |
| 比如：基于GV的位置符合度计算的因子，在GT竞争时就没必要了，明确隔了层。 | |
| 调试 | GT识别降维到GV层了：把整体GV匹配率打出来，看每个baseST都匹配到的比例 T。 |
| 结果：把匹配率和匹配数都调整了下配置，看起来打印出来的竞争因子值都不算太低，还行。 | |
| 结果 | 但发现absGT的抽象结果不太像个显著特征，转下表查修。 |
| 36102 | GT类比不出显著特征问题 |
|---|---|
| 示图 |  |
| 说明 | 如上图，扔了几个0，然后发现assGT2483识别的0看起来挺准确的。 |
| 但类比抽象成AbsGT2560时，发现并非准确抽象出显著GT特征。 | |
| 结果 | 转下节继续吧，感觉上十有八九是GV的错位问题。 |
CreateTime 2026.03.22
上节末测得GV应该有错位问题，参考n36p07B当时的设想，看来此处需求迫切了，可以开始继续降维了。
| 36111 | GV错位问题：方案制定 |
|---|---|
| 源起 | 上节末，测得“GT类比不出显著特征问题”，如下图，怀疑是GV错位导致的。 |
| 示图 | |
| 疑点 | 其实现在的GV是能大尽大，小的表征细节，所以有一点变化，会导致同一个图也可能生成非常异同的GVs。 |
| 分析 | 1、所以有可能还是错位问题？只是这次是gv错位，即得继续降维（参考36075）。 |
| 2、不过只要匹配率提上来就没问题，既然能匹配率提上来，说明错位问题没造成绝对性的坏影响。 | |
| 3、再跑跑训练，多观察一下匹配率的变化（转：验证）。 | |
| 4、其实到gv就不再是继续展开成sv了，而是根据protoRect切图比对。 | |
| 方案 | 如果确实是错位问题：也无需再降维到SV，直接写复用ST识别中的切图算法来实现即可。 |
| 验证 | 此方案的提前未必成立，需要先实测下是否真是GV错位问题。 |
| 1. 先调试查：为什么会打印出这么个样子（最好先实际调试验证下）。 | |
| 2. 验证方式：如打印st自身的gvs与匹配到的对比，如增高位置符合度要求，匹配率还能接近1吗 | |
| 3. 验证实证：把位置符合度阈值从0.6调整为0.95后，确实匹配率跑了10张0，也只在35%左右。 | |
| 4. 总结说明：在符合度高些后，GT自举中的stGroup很难匹配多条匹配率都很低。 | |
| 矛盾 | 这里就有个矛盾，位置符合度要求高则匹配率太低，符合度要求低则结果不成形。 |
| 结果 | 如上验证，确实有错位问题，可以继续迭代下GT自举，展开到切图。 |
小结：上表分析了GV的错位问题，经不算严谨的验证，90%支持方案：“迭代GT降维到切图”。
| 36112 | GV错位问题：迭代GT自举算法减维到切图TODOLIST |
|---|---|
| TODO1 | 根据stGroup.bestGVs的bestGV_Proto切图，与bestGV对比匹配度 T。 |
| TODO2 | 切图可以复用ST识别算法中的切图复用缓存池 T。 |
| TODO3 | 竞争因子：这样改后从ST到GV的位置符合度就全是1了 也可以根据scale缩放尝试来做为符合度 T。 |
| TODO4 | 相当于JvBuModel和JvBuItem全不用了，完全就是assGT循环出ST再循环出GV去切图匹配判断 T。 |
| TODO5 | 把GT类比算法也升级下，总得支持V10迭代的GTZiJvModelV2新数据模型 T。 |
| 结果 | 全改了，下表还有一些要实践的，一并改完再测。 |
小结：本表实践迭代了GT自举V10大多数TODOLIST。
<!================= 36113: 继续用示图分析下GT自举到切图 =================>
+------+ +------+ +------+
| | ---> | ST1 | ---> | GV1a | ----> [切图] (Cuts)
| | | | ---> | GV1b | ----> [切图] (Cuts)
| | +------+ +------+
| |
| | +------+ +------+
| | ---> | ST2 | ---> | GV2a | ----> [切图] (Cuts)
| GT | | | ---> | GV2b | ----> [切图] (Cuts)
| | | | ---> | GV2c | ----> [切图] (Cuts)
| | +------+ +------+
| |
| | +------+ +------+
| | ---> | ST3 | ---> | GV3a | ----> [切图] (Cuts)
| | | | +------+
+------+ +------+ |
|
| |
| |
\|/ \|/
+------------------+ +----------------------+
| 问题:有错位问题 | | 问题:有错位问题 | ------> [切图] (Cuts)
| 解决:不再依赖assSTs| | 解决:不再依赖assGVs |
+------------------+ +----------------------+
> 说明：如上图， 其实不需要再从ass识别结果中找什么，直接从ProtoImg上切图即可。
> 但是：assGT并非直接平辅在ProtoImg上，所以中途的那些best的Rect还是管用的，要以此影响到切图Rect。小结：本表对错位问题，及现在的GT自举，画个模型图，可直观看。
| 36114 | 子问题：用一个beginST切入的rect来预判整个GT，以至所有的gv_Proto肯定会不准确。 |
|---|---|
| 说明 | 现在完全用自举，不用assST和assGV结果，相当于所有切图的protoRect要通过自举来预算。 |
| 回顾 | 原先是用了jvBuItem.bestGVAtProtoTRect，但现在不用assGV了，也就没这个了。 |
| 思路 | 用完全预算不准确（因为会有变形），但又必须得预算，那就只好围绕标准值向周围扩散几个尝试了。 |
| 方案 | 按缩放几种比例、平移几种方向、平移几种距离，来分别尝试下GV匹配。 |
| 抉择 | 先这么跑跑看，性能的话，先复用切图池，应该跑的过来，到时候再优化性能。 |
| TODO1 | 从0.8,1.0,1.2缩放范围(三种) + 八个方向各偏移1.0,1.2两个值(9种) = 共27种 转TODO3。 |
| TODO2 | 性能：先向8个方向尝试1.2偏移把能最准的方向算出来，再在此上尝试缩放(共9+3=12种) 转TODO3。 |
| TODO3 | 变动：复用了当时ST识别自举时的切图逻辑，有锚点，不需要左右偏移了，只缩放即可 T。 |
| TODO4 | 先不缩放，等测个差不多了，再把缩放打开（现在注掉了）。 |
| 结果 | 全改了，下表测试。 |
小结：本表实践迭代了GT自举V10剩下的TODOLIST：在附近通过锚点缩放来找更优切图Rect。
CreateTime 2026.03.28
上节迭代了GT自举切图实现V10版本，本节测试。
| 36121 | 测试GT自举V10算法：测V10有没效果（解决错位问题 & 提升匹配率） |
|---|---|
| TODO1 | 看下现在的GT自举V10新算法，其竞争因子是不是也得有些变化 先不动测 T。 |
| 结果：扫了下，不需要改，先这么跑，看有问题再改。 | |
| TODO2 | 测GV错位问题好了没,匹配率能不能提上来(之前只有35%,参考36111) T。 |
| 结果：匹配率提上来了，现在从0.3到0.9x全有了。 | |
| 总结 | 验证了v10是有效的：V10在解决错位和提升匹配率上都有效。 |
小结：上表证实了v10应对错位问题 和 提升匹配率都是有效的。
| 36122 | 继续测V10：调整竞争因子。 |
|---|---|
| 说明 | 通过训练0和1，看能不能识别准确。 |
| 训练：现在还不准，但看起来应该没什么大问题，可以调好。 | |
| 方案 | 边跑边分析改哪些配置参数可以提升识别准确度。 |
| TODO | 1.只识别具层 2.竞争因子只保留匹配度和匹配率 3.识别结果总结时只总结具层LogDesc 4.具层logDesc不变 T。 |
| 结果 | 比原来准多了，0和1交替训练，训练到各第7张左右时，几乎大概率能识别准确。但还有别的问题，下表继续。 |
| 总结 | 按TODO调整后，准多了。 |
小结：上表调整了只识别具层 和 竞争因子只保留匹配度和匹配率，且有效果（重要）。
| 36123 | 继续测修V10的BUG：absGT不太像的问题。 |
|---|---|
| CASE1 | 问题1、有时抽象出一条条横条，这么巧合么？ |
示图： |
|
| 说明：如上图，训练4张0后，然后训练第1张1时，显示出上图这种，洽好抽象出一条条横条，且整体看不成形。 | |
| CASE2 | 问题2、交替0和1跑训练到第7张时，抽象出来的absGT完全不像。 |
示图： |
|
| 说明：如上图，此条在GT识别结果中排名第一，匹配率70%，但absGT就一点都不像assGT。 | |
| 分析 | 如上两个CASE，其实都是absGT与assGT不太像（压根不像是assGT抽象出来的）。 |
| 思路 | 估计GT抽象算法有问题（重点查rect计算）。 |
| 修复 | 经查，是因为在GT类比时，把absST_BaseST当成absST_BaseGT用了 T。 |
| 总结 | 根据以上原因，把absST_BaseGT用对后，回测发现修复好了，抽象后的absGT都成形了。 |
小结：上表修复了absGT不成形的问题。
| 36124 | 继续测修V10的BUG：0识别成1匹配率还高的问题。 |
|---|---|
| 示图 |  |
| 日志 | 2. 组特征识别结果:T331 匹配度:0.49 匹配率(防过具):0.71 = 综合得分:0.349 |
| 说明 | 如上示图和日志，Proto0识别成AssGT1了，但匹配率高达0.71。 |
| 分析 | 确实有1、按GT自举，0的左侧偏下部分确实像个1，激活1后，到Proto0上面自举确实匹配率挺高。 |
| 确实有2、那么从8上面识别3是正常的，从0左侧识别到1也是正常的。 | |
| 不充分3、那1的上下两端需要保持独立性，这个也是1的特征，只是这个在不匹配的那29%中而已吧？ | |
| 不充分4、那只要再加训，让两端独立的特征都能体现的，更高的匹配率的能竞争出来即可。 | |
| 结果：如上4步分析，第4条可见：只要加训提升匹配率，再看是不是自然就好了。 | |
| 方案v1 | 先“加训”，把匹配率提升到90%以上，再看下识别准确情况。 |
| 实践：加训到第11张0和1时，还是有问题，如下图： | |
示图： |
|
| 日志：01. 组特征识别结果:T464 匹配度:0.58 匹配率:0.79 = 综合得分:0.461 | |
| 说明：如上，训练到第11张时，1识别成了0，并且看absGT显示1被识别成两条0两侧线，这显然不对。 | |
| 方案v2 | 发现匹配度只有平均0.58，低的会更低于0.58很多，提升下gv匹配度阈值试下。 |
| 实践：尝试把GT自举里的gvResult.matchValue阈值从0.1调整成0.6，再识别GT立马准多了，如下图： | |
示图： |
|
| 日志：01. 组特征识别结果:T464 匹配度:0.72 匹配率:0.36 = 综合得分:0.263 | |
| 说明：如上，gvResult匹配度阈值提升为0.6后，整体GT匹配度也提到0.72了，匹配率低了只有准的才能匹配上。 | |
| 结果 | 方案v2有效，匹配度提升了，匹配率该高的高，该低的也低了（比如像用1识别到0这种不匹配的当然应该低）。 |
小结：上表方案v2，有效解决了GT识别不准确的问题，识别准确多了，但学没全面测，转n36p14继续。
CreateTime 2026.04.01
| 36131 | ST识别准确度参考GT最近做法改进下。 |
|---|---|
| 回顾 | 在36122时，把GT改为只识别具层，竞争因子只保留匹配度和匹配率， |
| 方案 | 那么ST也改为只识别具层，竞争因子只保留匹配度和匹配率试下 T。 |
| 结果 | 不改以前也可以跑，改后也可以。先按此方案改后的代码来跑着吧 T。 |
小结：ST识别准确度并未明显提升，但改后代码更简单，先保留着吧。
CreateTime 2026.04.01
在36124末，测试0和1准确多了，但无论是区分0和1，还是2和3都还没深入测，本节测下。
| 36141 | 测识别0和1，发现相比36124方案v2之前虽然准了不少，但仍然有不准确的问题。 |
|---|---|
| 说明 | 在36124中0和1各训练了10张的基础上，再扔0和1，识别结果如下。 |
| 识别0：组特征识别结果总结：(Mnist0=100% ,Mnist1=50% ) | |
| 识别1：组特征识别结果总结：(Mnist1=100% ,Mnist0=13% ) | |
| 问题 | 但再扔，还是有不准确的情况，继续分析下原因。 |
| 结果 | 测得识别0和1仍然有不准情况，转下表分析查修。 |
小结：上表测得0和1仍识别不准确情况。
| 36142 | 识别0和1仍有不准确情况（接上表）。 |
|---|---|
| 复现 | 跑完0和1各10张后，第11张0和1仍然有识别不准的情况。 |
| 调试 | 经查：ST识别结果结果匹配率从前到后才0.47-0.21，GT识别结果更是只有0.25-0.17。 |
| 思路 | 只要匹配率可以提升上来，让0和0总是高匹配率，0和1总是低匹配率，肯定可以提升识别准确度。 |
| 方案v1 | 在自举算法中，打开scales，让它偏移变形也可以找到匹配解，以提升匹配率。 |
| 结果：打开scales后匹配率有一点提升，ST有0.59-0.26，GT的有0.43-0.3。 | |
| 调试 | 重训练0和1各11张后，第12张识别0，日志如下： |
| 日志 | 00. 组特征识别结果:T716 匹配度:0.76 匹配率:0.43 = 综合得分:0.326 {Mnist1 = 1.00;} |
| 01. 组特征识别结果:T205 匹配度:0.77 匹配率:0.40 = 综合得分:0.309 {Mnist0 = 1.00;} | |
| 示图 |  |
| 解读 | 如上日志和示图，可得到如下两个问题： |
| 问题1 | 前两条分别把0识别成了1和0，匹配率都是差不多0.4 转36143。 |
| 对和错匹配率都是0.4，这个肯定需要展开查修下，转下表36143继续。 | |
| 问题2 | 为什么0识别成0，看可视化，匹配到的很成形了，应该不止0.4吧，或者想办法再提升提升 转36144。 |
| 分析：现在只是做了scales，如果再加上偏移等，肯定可以提升匹配率。 | |
| 反思：确定需要再提升吗？是不是0.4已经够了？哪有一模一样的树叶，有这样的匹配率已经很不错了。 | |
| 结果：等测到0.4匹配率确实不够的时候，再来想办法迭代改进。 | |
| 总结 | 方案v1有效但不多，问题1转下表继续，问题2需求不迫切成熟时再改。 |
小结：上表打开了scales缩放切图（有一点效果，但不多）。
| 36143 | 问题1、识别对和错的匹配率接近的问题。 |
|---|---|
| 分析 | 0识别成1后，因为自举的在0左侧的竖匹配上了，所以匹配率也不低。 |
| 示图 | |
| 线索 | 得判断除匹配之外的proto别的区域是否还有关键信息未被匹配。 |
| 思路 | 对Proto自身的rects 与 自举识别的bestSTs的rects，做比较即可。 |
| 1、proto被表征成protoST就有其gvs和rects，这些可以表征它的有效信息匹配。 | |
| 2、而切图匹配后的GT识别结果，其bestSTs也可以取得bestSTs_Proto。 | |
| 方案 | 自举匹配区 / 原始信息区 = 得出的比率，可以做为竞争因子，取名叫：完整性。 |
| 名词1 | 原来的匹配率指自身的匹配情况，而现在这个是除自身外的考虑，所以叫完整性。 |
| 名词2 | 完整性：其实就是以前的匹配数，只是现在更严谨，用高亮信息面积来计算了。 |
| 名词3 | 简称完整性，全名是高亮信息完整性（因为背景板其实没啥信息量，主要集中在小rect）。 |
| 公式 | 匹配到的总rect / protoRect占用率，和匹配到的总rect / assGTRect占用率，二者取小 T。 |
| TODO1 | 给GT识别中加：完整性 T。 |
| TODO2 | 如果大Rect套着小Rect，那优先以小Rect为准（它体现信息细节），大的排除掉 T。 |
| TODO3 | 识别结果：在Proto中的完整性 和 在Ass中的完整性，都算出来，将二者小的计为完整性 T。 |
| 回测 | 发现准确了不少，尤其是GT算法，即使ST结果不准，GT也会明显纠正不少，但还不够，转下表继续。 |
小结：新增GT识别竞争因子：完整性（有效果，但仍不够，下表继续）。
| 36144 | ST新增竞争因子：完整性。 |
|---|---|
| 问题 | 现在ST结果仍不够准，进而导致识别0和1也仍不够准确。 |
| 调试 | 识别0时，GT识别确实可以给0的结果更大竞争优势，但如果ST偏的太多，GT也纠正不过来，如下： |
| 日志1 | 单特征识别结果总结：(Mnist0=100% ,Mnist1=100% ) |
| 组特征识别结果总结：(Mnist0=100% ,Mnist1=25% ) | |
| 日志2 | 单特征识别结果总结：(Mnist1=100% ,Mnist0=32% ) |
| 组特征识别结果总结：(Mnist1=100% ,Mnist0=81% ) | |
| 说明 | 日志1是识别0_12时的结果，ST结果认为可能是0也可能是1，GT结果认为就是0。 |
| 日志2是识别0_13的结果，ST结果认为是1，而GT结果纠正了一些感觉更像0，但纠正的还是不够。 | |
| 本质 | 本质上是由微向组激活时，只要一步不准，激活就会失准，而自举也只能把这个失准拉回来十之四五。 |
| 所以：要不就彻底解决失准问题别再失准，要不就别失准那么多。 | |
| 方案1 | 完全解决失准源头，展开分析如下： |
| 正据：本来ST就是广为复用的，它可能组成任何protoGT（0和1都有可能）。 | |
| 怀疑：它的复用性真有那么强吗？GV的错位问题，是不是导致很多明明是抽具象的ST最终因错位而抽具关联不上。 | |
| 比如：我们都知道直角，不应该有一堆各种GV错位的直角表征，让彼此之间完全隔离复用不到。 | |
| 思路：怎么彻底打破GV错位的问题？除非不建立GV，但不建立我们就没了这个向组激活的途径。 | |
| 否掉：GV是绝对不能废弃的，这条捷径必须留着，不然连第一步向组激活都做不到。 | |
| 结果：方案1不可行，所以转向方案2，分析如下： | |
| 方案2 | 微观上别失准那么多，让GT可以把这个失准拉回来（先给ST识别加上“完整性”）。 |
| 解析：既然方案1的错位问题不可避免，那绝路逢生，用相对解决此矛盾，如下： | |
| 相对：A有错位但可以顺利向组激活，B激活后的自举没错位问题（其实就是现做法）。 | |
| 优点1、前者A照顾了性能（因为有错位才能有向组激活的阶梯）。 | |
| 优点2、后者B照顾了准确（自举完全回到proto上来切图匹配）。 | |
| 思路：那就保证每一步微观失准不能太多，让宏观一步可以把它拉回来（即此方案2）。 | |
| 结果 | 新增了完整性（作为竞争因子，把匹配率替代掉了）T。 |
小结：上表通过ST识别结果不准，分析出ST需要新增竞争因子：完整性。
| 36145 | ST再增竞争因子：稳定性。 |
|---|---|
| 问题 | 在上表中放任了ST表征错位的问题，那就可能有几十个“直角”ST表征，那需要的通路未必激活到。 |
| 需求 | 如果直角有几十个，我们怎么保证自己能激活到那个属于7的呢？如果激活不到，那就识别不到7。 |
| 思路 | 想让我们需要的激活通路总是99%能激活到：即必须竞争出稳定的ST，让稳定的ST来承载这个强通路。 |
| > ST竞争必须加上强度，让那些强度的稳定的能激活，它优先用于构建一切拥有此局部特征的GT。 | |
| 示例 | 比如我们识别一个古风的桌子，会记住它有桌角，以及桌角有云形图案。 |
| > 这里有桌角为主，桌角有云形图案为辅，此处甚至要记两个ST来表征桌角。 | |
| > 这个有桌角为主，就是为了有稳定ST，同时为了有触发源，触发这个桌子有可能的激活。 | |
| 性能 | 这样会导致，它激活的GT有上万个，此时GT自举过程中的批量判否就必要了。 |
| > 现在的缓存池方案应该性能也不差，先用着测到不行再优化。 | |
| 疑问1 | 用它构建ProtoGT吗？如果识别到的assST的bestGVs比这个稳定st有更多GV呢？ |
| 1、是不是应该保持现状：用原本的bestGVs构建的absST来构建ProtoGT。 | |
| 2、然后从它的有效抽象中找：“稳定st”？（可是有可能因错位问题从抽象是找不到的）。 | |
| 3、所以还是得找稳定的，自己的个体性的“直角”，怎么能和已稳定的“直角”相提并论。 | |
| 解答：所以即使bestGVs有更多gv，也是优先识别出“稳定assST结果”。 | |
| 疑问2 | 如果全成了稳定的ST，那构建的ProtoGT就不再有个体性了。 |
| 解答：具备稳定性的，和不具备稳定性的，各识别几条出来，二者都重要，都需要。 | |
| 方案 | ST再加个稳定性的竞争因子，它的优先级甚至大于匹配度等。 |
| 结果 | 新增了稳定性（单独用于过滤stModels前30%）T。 |
小结：上表通过36144中放任ST表征错位问题，分析出ST需要再增竞争因子：稳定性。
| 36146 | 测得完整性计算可能有问题 |
|---|---|
| 示图 |  |
| 说明 | 如图：有一些识别0，识别到1，并且匹配到的高亮信息很少，但却有70%的完整性。 |
| 复现 | 交替训练0和1，就能复现。 |
| 方案1 | 把高亮indexes从Proto上找出来后，bests也得只有这些indexes才有效。 |
| 方案2 | 还是把完整性，拆分成原来的内匹配率+外匹配率（在Proto的完整性），来组成。 |
| 抉择 | 方案1复杂，方案2更全面简单可行（全面是指大rect未必就没用）。 |
| 疑惑 | 完整性计算复杂，并且它剔除了背景大rect，也没那么显著的效果，感觉得不偿失。 |
| 感觉还是整个竞争因子配置参数调整等，不是一两个竞争因子的增删调整就能好的。 | |
| 实践 | 实践如下，边实践方案2，边主要进行特征识别的配置调整（边测试边训练边调整）。 |
小结：上表决定把完整性替代匹配率，改回：内匹配率（原来的）和外匹配率（现在完整性中对Proto的部分）。
| 36147 | 实践上表方案2 + 边测边调整特征识别的竞争因子配置调整等。 |
|---|---|
| TODO1 | ST尝试匹配度+匹配数（因为局部特征的率不重要，主要是数）T。 |
| TODO2 | 保留着稳定性，稳定性无论在ST还是GT都重要 T。 |
| TODO3 | GT尝试匹配度+匹配率（所有sum(bestGVs.count) / sum(GT.ST.gvCount) T。 |
| > 所有GV一视同仁，就按所有gv匹配数 / 所有gv数来计算匹配率也不比现在的完整性差。 | |
| TODO4 | 把完整性改成单纯对Proto的完整性（即外匹配率）T。 |
| 测得 | 测得自举匹配数太低的问题，比如：同样是2，只是有一些倾斜变形，就导致39条GV只匹配到8条。 |
| 结果 | 上面主要实践方案2和边测边调整了各个竞争配置，但效果仍不够好，测到匹配数低问题下节继续。 |
小结：上表再测：发现现在的scales自举匹配不够用，至少得支持平移，相邻预判平移度，缩放度这些。