继续多码特征 & 自适应粒度迭代 & 组特征自举迭代 CreateTime 2025.04.30
35011
测能类比出显著特征
说明
做几张有点共同特征的简笔画测试下类比出显著特征。
手写3
简笔人
结果
如上，可以顺利类比出显著特征，并且可视化工具也好用了。
35012
测显著特征的显著度能越来越强
BUG
测得手写2和3很难准确的BUG。
思路
尝试提高识别竞争力度，然后重测下，结果发现如下线索。
示图
线索
如上图：局部特征全识别正确，但最后取整体后，却错了，得调试下，这问题怎么来的。
CreateTime 2025.04.29
起因：在前面尝试测试识别特征细节时，想到九宫可能有错位错漏等问题，本节解下此题。
本节主要针对以下两个问题，分析制定方案和尝试做一版大的迭代。
错位问题：在N34中多码特征虽然都是多粒度，但粒度按9宫来的不够平滑。可能出现错位问题：就是当9宫错了1到2格时，此时如果GV差异很大，会导致索引不上。
错漏问题：当3x3时，如果proto和ass正好是1.5倍怎么办？那可能因为比例问题，而错漏掉。
35021
针对错位错漏问题的自适应粒度问题分析
说明
本节错位问题目前只是猜测，并未实证，需要先找几张错位图来试一下。
错位图
错漏图
思路1
其实主要是不能再分九宫这种固定多粒度了，而是要平滑分粒度，比如细节需要时可能分1.2粒度，细节不需要时可能分18粒度。
思路2
可以从整体开始，一级级向细节逐轮进行识别（下一层建立在上一层的基础上，慢慢取交收缩识别范围）。
思路3
粒度要平滑，意味着一帧视觉，可能进行更多轮的组码识别，甚至更多轮的特征识别。
要求：必须达到比如80%以上相似度的组码，才激活，不然：
一来不准确的太多，导致特征识别算法数据量循环太多，太耗性能。
二来到特征就更不准确了（比如手写2和3就很相似）。
三来如果要平滑粒度后更需要很多轮识别特征了。
线索
可以根据内容对齐来定粒度（即ass的内容是怎样的，就怎样定粒度，而不是以固定的3x3或者1.1x1.1啥的来定）。
结果
本表一步步分析，得到根据内容对齐来切粒度的线索，下表展开将该线索制定成方案。
小结：35021大致制定了“根据内容对齐来切粒度”的方向，下表分析具体方案。
35022
主方案V1：根据内容对齐来切粒度
问题回顾
因错位问题导致有一些识别不到的问题，如下：
问题说明
无论多粒度按3x3九宫分，还是2x2四宫分，永远都会漏掉可能正好两个图错位，比例等问题导致的识别不到。
上节回顾
但是：我们可以让每一个被识别者自举，反向识别。我举个例子：
1、校长想在学生里找人才（但校长也不知道这么多学生，哪些各有什么特长）。
2、所以校长说：觉得自己是人才的学生自己举手，并上台表明自己有什么特长。
3、校长来决定，这些特长的学生，算不算自己要找的人才，哪个更人才。
即：这样的话，就不是按多少固定比例来做粒度，而是学生说自己属于哪个粒度，就切成哪个粒度。
方案V1
proto还按9宫，但每一格偏移都做成GV索引去找assT，找到assT后，立马转为用ass.content和rect来反向切割protoT做匹配判断。
说明
该方案做两手准备：
1、原来的9宫表征保留（即现在的主要表征手段不变）。
2、而最初的索引：protoGV则可以精细些，要照顾到没有错位错漏问题。
结果
该方案大致ok，但还有子问题，比如：protoGV怎么个精细法？怎么照顾到没有错位错漏问题？转下表继续。
追加
此方案不够深入，转35024继续深入展开思考下。
小结：35022制定了方案V1-“protoT靠算力每格都索引，然后找着assT后，立马转为根据assT内容对齐来切粒度”。
35023
子问题：protoGV怎么避免错位 和 错漏问题？
线索
九宫肯定会导致错位，所以proto每三格采一次样肯定不行了，缝隙太宽必然有错位。
说明
因为这些子问题，仅针对proto层，它没有性能问题，也不必持久化，不必担忧空间问题，所以可以放开手干，那么就不再是什么大问题。
即：protoGV的存储已经剥离了，proto只计算生成GV索引用（包含所在粒度层信息protoScale）。
方案1
proto按十等分一格格右移，分别得protoGV索引激活assT。
缺点：十格也可能有错位，不是格多格少的问题，而是每格都要照顾到的问题，10能照顾10以下，100格呢？
方案2
由原来的每3格采一次九宫改成每一格都要采样9宫。
分析：这方案对错位ok，对错漏不行。
方案3
在原来每3格采一次九宫甚至上，进行向后追加处理偏移两格，以遍历到所有格避免错位问题。
分析：这方案和方案2也没啥区别，走一大步原地抖两步，和一步一格三步三格，其实没区别。
方案4
可以每1.3倍一个粒度层，1-3，2-4，3-5...这样一格格取九宫转protoGV索引，反正不存，咱就细到它没问题为止 95%。
分析：此方案看似暴力，但即然不在识别时多个嵌套循环，又不持久化，算力就不再是问题。
优点：此方案即解决了错位问题，又解决了错漏问题，当首选。
抉择
经上分析，方案4更暴力简单直观实用，选定进行实践。
小结：35023中，针对错位错漏问题，制定并最终选定方案4：对protoT以1.3倍一个粒度层，一格格逐步向右取九宫，直到最后一格。
35024
主方案继续深入思考1-自举还是被举？（参考35022）
起因
一觉醒来，发现35022-主方案V1有两个缺点：
1、每一次都把assT的contents和rects读出来，本身就很有性能问题
2、再则proto如果已经找着ass了，说明已经确定它的粒度比例了，何必多此一举的再让它自举？
已确定
无论怎么做，35023的方案4是确定的：protoGV每个粒度都计算gv索引和找refPort。
1、protoGV自带protoScale表示它是从哪个粒度层切来的。
2、refPort自带rect也有粒度层refLevel，可用width来计算。
正方
应该继续方案v1以assT.content和rects来自举切粒度。
缺点1：这需要把assT提前取出来，这个缺点也比较致命（特征全量非常巨大，抽象的稳定的好不少）。
示例：如果ass是一个比例在变化的呢？第一个gv是1.5倍，第二个变成1.8，第三个又因为变形或别的局部干扰导致level层在更大粒度一层。
缺点2：
辩解：可以根据refPort的强度来竞争，只保留前20%，尝试找出抽象稳定的显著特征，而后再conPorts做整体特征识别。
反方
以当前gv的protoScale和refLevel，依次确定切下一个assT.gv在proto中的合适粒度 (废弃现特征识别算法中的固定deltaLevel)。
说明：protoScale和其refPort.level，这两个可以比较确定下一次proto应该以哪个粒度比例来应对下一个gv。
分析：这么多proto切粒度，其实这相当于多轮特征识别了，不过能边推进下一个gv.refPorts，边一轮轮淘汰assT也可以。
缺点1：但它终是无法明确比例，无法明确protoT的千变万化，这一计算非常复杂，看起来此缺点比较致命。
缺点2：除非assT自举切粒度，不然以proto为准去一个个refPort找，非常难以找准确，因为step1Model中的rank将大爆炸。
辩解：可以不断用当前gv的protoScale和refLevel预估切下一个gv的粒度，边ref边修正下个gv的scale。
抉择
反方即使知道ass下一个gv的粒度比例，protoT也会因自己的各种错位噪点等影响，导致切不出assT下一个gv所正对应需要的部分。
> 真正assT下一个gv要哪部分，还是assT自己最知道，靠简单的比例去蒙肯定是蒙不中的。
> 继续维持方案V1，必须先以assT去自举，才有可能准确，不然全靠蒙是不可能准确的。
小结：35024深入分析，并最终选择继续维持方案V1，不过加上：“缩小ref范围为仅竞争靠前的特征（前期为普通特征，后期一般为合理抽象程度的显著特征”。
35025
主方案继续深入思考2-比例变化怎么切粒度？（参考35022）
简述
其实在以不同视角观看同一物体时，这种形变非常常见。
说明
示图
说明
如图：A1找到A2后，B2怎么自举找着B1？
思路
根据B2在assT中的rect，推测对应B1在protoT中的rect，然后以与A1:A2相交处为锚点，进行缩放，直至找出最为相近的切粒度区域与比例。
即：每一条新的gv，都可以重新缩放找最相近的切粒度比例，做为下一个gv的初始比例。
小结：35025深入分析了比例变化的情况下怎么切粒度：“每一条新的gv都根据上次的初始比例，在锚点上缩放对齐，找出新gv下的最优比例”。
35026
流程整理：总结本节以上所有表为工作流程
1
protoT输入时，脱离存靠算力：按1.3倍一个粒度层，从第一格，逐格向后取九宫，直至最后一格结束 T。
2
每一个九宫都生成gv索引，尝试取refPorts，找到assT T。
3
对找到的assTs进行竞争缩小范围（如保留前20%）（冷启时胜者为普通assT，后逐步变成稳定合理抽象的显著特征）T。
4
找着assT后，立马转向自举：“根据assT的内容来一个个gv向后在protoT中切粒度” T。
5
每assT前一个gv做为下一个gv的初始比例，在描点上缩放对齐，找出最优比例，同时做为下一个gv的初始比例 T。
防重
一条proto.gv取得ref.assT后，自举掉一批assT.rect后，这些rect区域就不再进行12345步了 T 改为6。
> 这样的话，只需要少数的proto.gv就可以把整图穷尽了，避免了穷尽所有粒度和偏移太耗性能的问题。
6
防重改为根据assT.pId和assIndex来防重，因为像8有四个下斜线，切入点不同时，也许又行了 T。
7
出界时，图片只显示到局部，或推测的proto出界时，直接跳过该条gv处理，因为匹配度会除matchCount所以不会影响最终竞争 T。
结果
把以上几条都代码实践完成。
小结：35026中，把流程整理了下，并直接代码实践把这些做了。
CreateTime 2025.05.08
上节开发完毕，本节测试修细节和BUG。
35031
整体特征识别结果总为0条问题: 并最终将整体特征迭代为组特征。
V1以前的数据结构
V2现在的数据结构
说明
如图，现在没有自适应粒度的protoT，所以就没法从absT1234找到protoT，它们只能各自找到自己的assT一条。
方案
可以把absT1234整合成自适应粒度的protoT，并与absT1234建立关联，但它应该相当于组特征节点了，看来得再定义个GTNode了。
结果
本表新增了组特征GTNode，然后把组特征识别、类比、可视化等都支持并测试ok了，并且已经可以识别到整体特征了。 T。
小结：注意本表是把整体特征改成组特征了，然后局部特征相当于单特征，单特征都是固定三分九宫，而组特征是各种单特征组成的自适应粒度。
35032
回测组特征
测项1
看局部特征识别结果不可以太多，不然组protoGT的元素就太多了。
测项2
测下上万像素图片识别，看下性能怎么样，然后调试下性能优化下。
测项3
测下错位，细节等的识别。
35033
BUG及细节问题跟进
1BUG
组特征识别中有rectItems.count>assT.count的情况。导致符合度>1 转35034 T。
2细节
三通道都放开测下。
3思考
能不能单次就把三通道全给处理了？（建建别全通道合一，不然可能又要大改，等需求明确再说）T 暂不做。
4性能
调试下性能优化（尤其是局部特征识别的性能）T 转35041。
5测试
测下手写数字2和3的识别，看特征提取和组特征识别的效果怎么样。
35034
组特征识别rectItems重复BUG
起因说明
经查之所以rectItems.count>assT.count，是因为有重复，重复说明如下：
重复说明
有时protoGT有多条元素，指向同一条assT的同一个元素时，日志如下。
protoGT1722的Index:3=T1690（0左上）: {{0, 0}, {15, 3}} 指向assGT1691的refRect{{3, 12}, {15, 3}}
protoGT1722的Index:6=T1690（0右下）: {{3, 12}, {15, 3}} 指向assGT1691的refRect{{3, 12}, {15, 3}}
rectItem数:2 assT数:1 protoGT数:8
说明：日志可见，protoGT的左上角和右下角，全匹配到了assGT的同一帧（refRect一致即是同一帧），然后最终rectItem数2比assGT数1还大。
示例说明
比如protoGT为0时，其左上角(proto2)和右下角(proto5)都是上斜线，可能同时匹配到assGT中的(ass2)左上角。
方案1
分析下，这种情况，是否在单特征识别时，就加以分组防重？因为这里其实相当于是“重影“。
否定：在单特征识别时无法防重，此时还不知道哪个位置符合度更准确，如果单纯防重可能把protoGT0的左上角，和assGT0的右下角保留了。
方案2
到run4MatchDegree中，对deltaX和deltaY排序，把位置符合度最高的做为best留下 95%。
说明：即此处多条指向同一个assT的同一个assIndex时，它其实是冲突的，这几个应该竞争一下，只保留最优best那一个。
方案3
如果同一个subT指向同一个groupT.同一个itemT，此时为什么在GT中的rect一致，但refPort.rect却不一样呢？要不统一表征一下，这样就可以防重了。
否定：此处是在protoGT中的位置不同，比如0的左上角和右下角的两个上划线就是一样的只是位置不同，而在assGT中指向同一个元素，所以范围也是一模一样的。
抉择
选定方案2，方案2是针对位置符合度竞争后，取best一条，别的防重掉，这样可以保证protoGT0的左上角对应上assGT0的左上角。
结果
用方案2修复后，重复问题ok了。
CreateTime 2025.05.17
35041
局部特征识别调用太多，没复用缓存，很慢。
性能
DEBUG匹配 => 代码块:自适应粒度 循环圈:0 代码块:238 计数:1028 均耗:33.03 = 总耗:33952 读:176 写:0
说明
如上，局部特征识别一次33ms，但因为未缓存复用，导致1028次调用，用掉34s，巨慢。
思路
相近范围内，可以复用原局部特征识别缓存结果，示例分析如下：
比如
1、从原图(3,3,9,9)索引值0.8切入，以其相近95%的0.75取refPorts，识别结果为T1,T2,T3。
2、从原图(3,4,9,9)索引值0.7切入，以其相近95%的0.75取refPorts，识别结果同样为T1,T2,T3。
3、此时其实切入点都是0.75，只是rect不同但相近，即：切入rect一个是3,3,9,9一个是3,4,9,9。
4、那么：如何计算rect的相近度？多相近算可以复用，多不相近就不可以复用了？
方案1
两个rect交集 / 并集 > 70%时，即复用，否则重新识别，并计新rect识别结果条目缓存，亦可被别的相近rect去复用。
分析：该方案适用于单帧视觉，可以尽可能在性能允许的情况下，识别全面些。
方案2
参考35026-防重，还按rect区域来防重，更多的识别可以用持续注视来完成。
分析：该方案适用于连续视觉，或者持续注视时，可以快速响应识别。
抉择
目前并没有注视功能，所以先采用方案1来搞，性能上应该也够用了，后续有了注视机制之后再用方案2，到时性能更快。
TODO1
每次局部特征识别后，把切入rect的切入gv_p存下来 T。
TODO2
再次局部特征识别时，把新切入rect和gv_p与之前的缓存中求rect相近度（交/并=近）T。
TODO3
大于70%则直接复用结果（其实相当于直接跳过此轮识别）T。
TODO4
小于70%则进行该轮识别，并将识别结果再次缓存到当前rect和gv_p中 T。
结果
1200多条识别，加上防重后，还剩200多条，但仍然非常慢，需要继续优化。
小结：本表做了进行局部特征识别的条数防重优化，从原1200条优化到200条，但这只是最外层减少循环数，还不足以性能达标，后面继续搞。
35042
局部特征识别调用太多，多层for循环太多，最内层要18w次执行，很慢
说明
从每次调用后的gv识别结果循环，到refPorts循环，再到assT.content循环，再到scale缩放判断循环。
每一个for循环导致量都在爆炸增强，但却没有收束。
方案1
for循环收束：层层竞争，层层防重，最好是能逼近每一条最终成功匹配都执行且仅执行一次。
说明：每一条有效assT都只执行一次是不可能的，但我们可以尽量去逼近，让性能达到可接近的程度。
实践
边调试每层for循环的内容，边分析竞争或防重方式，最终把每一次都尽可能的收束，最终达到总循环数很少的程度为止。
TODO1
写了beginRectExcept在切入点上进行防重 T。
TODO2
写了assRectExcept在已被识别区域上进行防重 T。
TODO3
为防止宏观识别后，微观全被防重掉，每个dotSize层级，都单独进行防重 T。
TODO4
在局部特征识别成功时，才更新防重到beginRectExcept和assRectExcept中 T。
结果
加了beginRectExcept和assRectExcept后，性能到了可接受的程度，识别速度也可以至少跑起来了。
小结：本表把单通道识别性能从几十秒，优化到一两秒内了，当然还有优化空间，不过目前用于调试是够用了，那性能问题就先这样。
35043
protoGT有重影BUG
示图
说明
在各个dotSize粒度层级识别的结果，全都收集到一起了，导致最终absT收集构建成protoGT后，必须是多个层级的结果都在一块儿。
尝试1
可以尝试把各个dotSize粒度层识别的结果，单独进行类比打包protoGT T。
结果：改代码为：每个dotSize层单独打包protoGT后，还是有重影问题。
回顾
组成protoGT的absT都是由assT来的，而absT最终在proto图片中的位置，都是有计算的。
原则
因为性能连打包都来不及，其实视觉看到的，都是由以往的经验重组而成，而protoGT在这里也是重组来的。
那么：我们偏婴儿期重组到的，有偏差也是很正常的事，毕竟局部T最符合的也没多符合（位置不符导致重影是正常现象）。
验证
验证一下以上猜想，如果只是正常现象，那么就多测测，看偏成熟期后，拼接的protoGT能不能越来越符合原图的样子。
查明
最终查明，在特征识别中，比如0的内圈0和外圈0，都会被识别，导致重影。
修复结果
单特征识别后，根据assT.pId来防重下（保留最准确的一条）T。
35044 ：protoGT的元素rect和可视化之后的大小不一致 ：
> 在构建protoGT时 ，再把这个坐标修正下 ，不要影响类比这里的代码 。
**代码回顾 ：**
* 16 A . 方案1 、采用bestGV at assT的位置 ，做absT的元素位置分布 ：将gvRect在assT的范围 ，转成在newAbsT中的位置 。
CGRect assGVRect = VALTOOK (ARR_INDEX (jvBuModel .assT .rects , obj .assIndex )).CGRectValue ;
CGRect bestGV_absT1 = CGRectMake (assGVRect .origin .x - absT_AssT1 .origin .x , assGVRect .origin .y - absT_AssT1 .origin .y , assGVRect .size .width , assGVRect .size .height );
* 16 B . 方案2 、采用bestGV at protoT的位置 ，做absT的元素位置分布 ：此方案优点在于构建protoGT时 ，尺寸及位置可以更准确 ，缺点是类比这里本来就应该以assT为准 ，不关protoT的事 ，所以先采用方案1 。
CGRect bestGV_absT2 = CGRectMake (obj .bestGVAtProtoTRect .origin .x - jvBuModel .bestGVsAtProtoTRect .origin .x ,obj .bestGVAtProtoTRect .origin .y - jvBuModel .bestGVsAtProtoTRect .origin .y ,obj .bestGVAtProtoTRect .size .width , obj .bestGVAtProtoTRect .size .height );
* 16 C . 但这里有个问题 ，就是每个bestGVObj （AIFeatureJvBuItem ）是有不同的scale的 ，即它并不是按assT直接抽象出来的 ，而是每个元素识别匹配时都有各自的比例 。
- 那么 ：这个比例要体现在bestGV_absT中吗 ？按ass抽具象树内的原则 ，肯定是不需要体现 ，但absT用于生成protoGT时 ，就丢失了这个gv的scale信息 。
- 除非 ：每个GT中 ，单独把每个itemT .itemGV的scale都存下来 （转下面方案3 ）。
* AB二者说明 ：代码有两种坐标计算方式 ，一个向ass对齐 ，一个是向proto对齐 ，二者是有一个比例的
* AB二者总结 ：显然 ，这里是不同粒度间的识别匹配 ，它天然与proto上的rect就是有一个比例的 ，如果忽略了这个比例 ，显示到protoGT上当然就尺寸不准确 。
**原因如下 ：**
1. 微观上 ：absT .gvs都是以assT为准进行rects计算的 。
2. 宏观上 ：protoGT .rects又是以absT at protoT为准的 。
3. 即absT对protoGT而言可能是rect1 ，而对其内的gvs而言又可能是rect2 。
4. 即rect1和rect2之间的比例问题 。。。
5. 而protoGT中的每个absT的比例差 ，可能各有不同 ，所以只有两个方法 ：
**方案如下 ：**
1. 方案1 、把absT统一比例向protoGT对齐 （即一个个生成protoT单特征 ），但这样absT与assT的抽具象关联又不那么对齐了 。
- 缺点 ：方案1会导致assT和absT之间对齐又不准确了 。
- 分析 ：最好是在自己的ass抽具象树内进行对齐 （这是符合直觉 ，也容易调试 ），那absPort不存scale了 ，refPort就得存 ，所以转方案2 。
2. 方案2 、protoGT与其元素本来就有比例问题 ，记录一下xScales和yScales比例到AIGroupFeatureNode中 。
- 缺点 ：方案2可以解决比例问题 ，不过这太复杂了 ，组特征识别算法是不是也要因此变的更复杂 ？（因为计算位置符合度等都是依赖rect来计算的 ）。
3. 方案3 、protoGT的元素的元素都各自有比例 ，protoGT虽然是用它们表征的 ，但细到每个gv都得各自变换拼接回protoGT ，即每个absT都要存一个dic比例表 。
- 缺点 ：方案3更能解决比例问题 ，不过更复杂 ，也因此GT识别算法在计算rect时 ，变的更复杂 ，容易不可控的出各种太复杂导致的bug 。
- 优点 ：别的方案都无法把每一个gv的比例存下来 ，只有这里存下来了 ，此只有此方案可以完全还原protoGT的原图 。
- 示例 ：我们斜着看到一个长方形时 ，脑中激活的却是正的长方形 ，我们看到一个写的很漂亮的字时 ，如果不再去看一眼 ，却说不出它哪里漂亮的具体特征 。
4. 方案4 、类比时 ，同时生成absT和protoT ，这些protoT用于构建protoGT 。
- 优点 ：二者兼得 ，虽然浪费些空间 （但缺点是会影响复用性 ，如下 ）。
- 缺点 ：absT的复用性降低了 ，因为单独生成protoT了 ，absT就不易复用到 ，需要测下GT识别会不会因此受影响 ？不过GT识别本来就是找protoGT ，对于变形严重的不易识别到应属正常 。
5. 方案5 、尽量还用原来的refPort .rect和tNode .rects来表示比例 ，即拉伸平铺显示 ，拉伸的比例替代此需求中要存的scale比例差 。
- 优点1 ：实践简单 -可复用以往rects相关的代码设计 。
- 优点2 ：符合直觉 -ass抽具象树内 ，使用原1 :1 比例 ，refPort .rect和rects中使用引用比例 ，也符合原代码设计 。
**方案PK如下 ：**
* 原则 ：单特征的形状和比例 ，二者必须单独表征各自可独立运行 ，这样才可保证形状 的 复用性 。
* 抉择1 ：淘汰错误答案 ：方案1是取此失彼 ，不可行 。方案4必然影响复用性 ，也不行 。方案2画蛇添足没必要 （方案5即可以表征protoGT元素的比例又改动简单 ），也也不行 。
* 抉择2 ：决赛PK ：方案3优点是可还原 ，缺点是代码和算力会复杂些 。方案5缺点是仅估计了整个单特征比例不够还原 ，但优点是足够简单 （可用现tNode .refPort和tNode .rects直接实现 ）。
* 结果 ：根据 `方案3 -示例 `可见 ：我们未必需要完全还原 ，可以先用方案5 ，如果后面确实需要完全还原了 或 方案5不够用了 ，再回来搞这个方案3吧 `T `。
35045
GT识别结果总是不全面
回顾
过去几天从单特征识别到类比，再到组特征识别到类比。
问题
测试单特征识别类比后，没发现什么异常情况。但测组特征识别类比后，感觉可视化结果总是不太成形，如下图：
示图
说明
如图，有时protoGT生成的就不太全，可能只有0的上面2/3，而再组特征识别后，结果又本来都是抽象的，导致不全面。
分析
1、局部识别不全，所以组成protoGT不全面。2、组特征识别结果是抽象的，所以更加不全面，如下图：
示图
说明：如图，单T识别可能就不全了，生成protoGT也不全，组T识别时可能进一步更不全了。
方案v1
最终输出具层结果，GT识别交层后，向似层再走一步。
缺点1
不过现在构建的protoGT就不全面，那我们即使向具层也不全。
思路1
比如我们看到0，会在意它的背景吗？如果不在意，是否相当于识别到完整的0（类似0抠图）就行。
线索1
不全面问题，其实答案也许并不是最具象的具层，而是一个即似层又全面的表征（类似0抠图）。
所以1
protoGT还是用itemAbsT来组成，只是它需要逐渐趋于更全面（健全度）。
方案v2
根据以上几行的分析，给GT识别竞争加上健全度因子，使之可以慢慢趋于健全（全面）。
回顾2
经查，现代码GT匹配度=匹配元素数/assGT.count，它本身其实就相当于比较趋于全面。
方案v3
多跑跑加训一下，也许随着训练的增多，抽象T变多，protoGT也变丰富了，就更全面了。
加训3
说明3
如上图，训练10张0，确实可以得到更准确的识别GT结果。
35046
GT识别结果总是乱糟糟的
加训3
起因3
接35045末，发现单T或GT识别结果总是有些乱糟糟的。
问题3
但它还是不够准确，比如拼接的双竖线看起来不协调（图左下方），再比如生成的protoGT也比较乱糟糟的（图右侧）。
思路3
说到底还是一旦脱离了proto具象原图，那么它的再拼接，就会难免混乱。
分析3
protoGT是用absT来拼接，而absT来自于assT，所以相当于各个assT的部分，最终拼接在一起，变成新的protoGT。
1、首先absT确实要从assT来抽象，因为它们需要保证assT的树内同质。
2、但拼接成protoGT的，却不应该是absT了，不然就难免混乱，因为absT没一个来自proto原图。
方案v4
还是得原图proto，在单特征识别时，就得把protoT补回来，但protoT是固定粒度，而识别结果assT却是自适应粒度来的。
方案v5
要不还是识别具层结果，无论是单T还是GT。
方案v6
尝试：切回向具象取整体特征方案的思考，如下图：
如上图优点是结构比较简单，虽然无法表征“自适应粒度”的所有GV数据，但识别等也也够用。
缺点是如果protoT不表征自适应粒度所有GV，那我们为什么还要这么做？
原则1
可视化不能跨图，即assGT1和assGT2的各自局部不能显示在同一个画布中。
原则2
本表只是可视化问题，绝不可因可视化问题就影响到内核设计。
所以
protoGT绝对不允许由absTs来组成，但由protoDic自适应粒度切的GVs不能持久化。
方案v7
既然不能存那就不存，可视化时直接在protoDic中现算现取。
缺点1：感觉，表征的和可视化的不一样，这太割裂了。
缺点2：如果protoT和absT之间，没有存抽具象相似度，那识别GT的范围就会很窄（只有absT自己的ref才能识别到）。
原则3
由itemAbsT组成的protoGT，其实它一点都不具象，反而是抽象+混乱，比如它来自多个不同的T树。
> 脱离具象是非常严重的问题，因为它无论怎么有规律，也会脱离具体，慢慢变成偏向想像中的正确，空中楼阁。
分析
1、如果没有protoT就没有protoT和absT之间的匹配度。
2、如果没有这个匹配度，在抽具象上，就没法跨树。
3、如果没有跨树，单纯靠absT碰头，assGT的激活范围就会很窄。
结果、感觉还是应该回到以前的网络结构，不应该因为缺少protoT就改成现在这种随意瞎搞的特征网络。
方案v8
废弃组特征，生成自适应粒度的protoT时，可以由itemAbsT们，共同向proto中取相应的gvs，来组成protoT。
优点：这个方案其实和当时的固定粒度V1特征算法中的具层整体特征是一样的设计。
抉择
这段时间下来发现组特征意义不充足，还是采用方案v8，退回去，把组特征废弃掉，方案v8实践如下：
TODO1
实时取protoColorDic的gvs，来组成自适应粒度下的整体特征protoT T。
TODO2
把原来的整体特征识别v1算法，迭代成v3，还是向具象做整体特征识别（看有没需要改的）T。
TODO3
把原来的整体特征类比v1算法，迭代成v3，还是整体特征类比（看有没需要改的）T。
TODO4
看下用不用改成：局部特征类比前，直接用局部特征assT们来组建整体特征。
> 优点：这样肯定数据结构流程更简单，毕竟直接protoT指向assT。
> 抉择：但影响似乎也没那么大，目前没发现用absT又有什么问题？所以先不动。
TODO5
尝试用GTNode来构建整体特征，这样省空间，但局部特征识别就没法识别它了。
> 优点：这样非常省空间。
> 缺点：这样局部特征识别，就非常难以识别到较为整体的特征结果了。
> 抉择：但局部特征识别也不需要识别那么整体吧？毕竟本来就还有整体特征识别算法。
TODO6
整体特征识别，有没有必要再搞自举？目前用局部特征拼接应该就ok T。
结果
TODO4和TODO5现在需求不明确，再测测，确实需要再做。
小结：上表中，在局部特征识别后，依据protoColorDic补全了构建protoT，并且废弃了组特征。
CreateTime 2025.06.11
上节末，补全构建了protoT，废弃了组特征，本节回归测试下，看自适应粒度下的性能和识别等效果。
35051
回归测试
TEST1
测下性能问题。
TEST2
逐步测试下局部特征识别，局部特征类比，整体特征识别，整体特征类比。
TEST3
测下手写2和3提取显著特征。
35052
1经常被识别成0
说明
如下代码段1，训练0五个，1八个后，输入1时，很多粒度层下，最终还是识别成了0，并且是唯一结果。
分析
查下，为什么训练这么多次，还会经常输出唯一结果？是不是网络结构还是复杂，导致两端碰头困难。
怀疑
大几率就是因为网络结构的复杂（跨度大，联结少）导致识别结果太过单一。
TODO1
先把单特征识别后assT和protoT建立上抽具象关联再说 T。
TODO2
把bestGVs在assT的rect 和 bestGVs在protoT的rect => 计算成assT在protoT的rect，然后存conPort.rect下 T。
TODO3
assT与protoT的抽具象匹配度，即要取bestGVs的平均匹配度，也要除以assT的长度（匹配数）T。
结果
已改完，后面继续回测视觉（下表回测手写1经常识别成0的问题）。
** 35052代码段1**
单特征识别结果总结：(Mnist0=1.00 )
单特征识别结果总结：(Mnist0=1.00 )
单特征识别结果总结：(Mnist1=0.64 ,Mnist0=0.36 )
35052
继续回归测试
测试项1
先测下手写0和1的识别，尤其先看下识别结果是否还那么单一。
35053
问题1、单T识别都是最近的新T结果 & 问题2、识别性能越来越慢问题。
问题1
大多refPort都是后面慢慢形成的新的，所以导致单T识别结果大多是很新生成的。
问题2
训练前几张手写0时还ok，但训练到第10张左右时，变的越来越慢（因为refPorts越来越多）。
分析1
随着训练，一个T有几十个GV，各种顺序和GV等都不同，有几万refPorts关联都很正常。
分析2
本来gv.refPorts就越来越多，也就是随着单T积累的越来越多自然识别到更多新节点，因为新的占比越来越多。
分析3
这也很不利于稳定的显著的局部特征在竞争中慢慢浮现。
方案1
增强ref.target的防重性，比如：gvs之间的比例变化，比如1：3：9和3：9：27，能不能表征成一个T？
缺点：这样治标不治本，其实少不了多少，最多减少60%左右，并不能解决当前的问题。
示例
借助示例分析该问题：
例：如果桌角或桌腿可以用来索引到桌子，那么桌面上无关紧要的一个小小的局部则不应该也索引到桌子。
即：能索引到桌子，也应该是多次发生，则有资格时才能索引到，所以方案如下：
方案2
用ref.strong竞争，多次发生时ref.strong自然增强，然后具备激活资格。
疑问1：只用ref强度够吗？是不是还需要content强度？
答1：content强度每个元素都一样，所以还是ref吧。
疑问2：一个角，要ref多少，才能保证覆盖到桌角特征？
答2：无论ref多少都不够，只要可以找到一个抽象角单特征就行，至于真正的桌角，可以在识别组特征时再找到。
结果
按方案2加上refPorts的强度竞争后，确实有效，日志见下代码段。
33053 -代码段 ：按方案2修复前后的日志对比 ，与总结 。
//修复前：一是随着训练refPorts激活的巨多。
/////////第10张训练日志
3802 [23 :02 :21 :212 TI AIFeatureJvBuMode .. 47 ] aaaa101 (100 = 1 )
3803 [23 :02 :21 :212 TI AIFeatureJvBuMode .. 47 ] aaaa102 (100 = 12 )
3804 [23 :02 :21 :212 TI AIFeatureJvBuMode .. 47 ] aaaa103 (100 = 2195 )
3805 [23 :02 :21 :213 TI AIFeatureJvBuMode .. 47 ] aaaa104 (100 = 5408 )
3806 [23 :02 :21 :213 TI AIFeatureJvBuMode .. 47 ] aaaa105 (100 = 5408 )
3807 [23 :02 :21 :213 TI AIFeatureJvBuMode .. 47 ] aaaa106 (100 = 14412 )
//修复前：二是最后识别结果aaaa3000往往因为最近的refPorts巨多，导致pid最近的400范围最多，所以识别了13条，占比很大。
aaaa1001 (0 = 5 ,100 = 115 ,200 = 285 ,300 = 349 ,400 = 941 ,500 = 500 )
aaaa1002 (0 = 4 ,100 = 42 ,200 = 63 ,300 = 151 ,400 = 479 ,500 = 332 )
aaaa1003 (0 = 4 ,100 = 42 ,200 = 63 ,300 = 151 ,400 = 479 ,500 = 332 )
aaaa1004 (0 = 2 ,100 = 3 ,200 = 8 ,300 = 22 ,400 = 173 ,500 = 130 )
aaaa2000 (0 = 2 ,100 = 3 ,200 = 8 ,300 = 22 ,400 = 173 ,500 = 130 )
aaaa3000 (300 = 3 ,400 = 13 ,500 = 4 )
//修复后：一是refPorts激活的没那么巨多了，二是最后竞争aaaa3000发现旧的稳定节点识别结果多了，不再全是新的最近的特征识别结果。
aaaa102 (100 = 396 )
aaaa103 (100 = 2706 )
aaaa104 (100 = 986 )
aaaa105 (100 = 986 )
aaaa106 (100 = 1116 )
aaaa1001 (0 = 132 ,100 = 561 ,200 = 561 ,300 = 759 ,400 = 693 )
aaaa1002 (0 = 99 ,100 = 396 ,200 = 99 ,300 = 165 )
aaaa1003 (0 = 99 ,100 = 396 ,200 = 99 ,300 = 165 )
aaaa1004 (0 = 1 ,100 = 5 ,300 = 3 )
aaaa2000 (0 = 1 ,100 = 5 ,300 = 3 )
aaaa3000 (0 = 1 ,100 = 4 ,300 = 3 )
35054
交替跑六个0八个1后，还会把1识别成组特征0
思路1
查下它的位置符合度，应该很低了才对，是怎么识别到它的？
跟进：在35055修复后，组特征识别的位置符合度高了。
思路2
从单特征一步步查，查这些竞争浮现的配置参数（转35055）。
跟进：在35055修复后，单特征的竞争因子竞争浮现好多了。
35055
单特征的几个竞争因子，并没有随着训练过程浮现的越来越准。
思路
调试单特征识别竞争浮现。
疑点
难道是准确的没有激活机会吗？
调试
记录：经查，看起来没一个准的，准的没激活机会吗？调试一下准确的单特征的strong变化过程。
结果
经查：matchDiffValue计算的是绝对值，不是匹配度，改成差似度后，整个单特征识别的竞争浮现好多了。
35056
识别0成1问题没原来那么严重的错误了，但两边50%左右，还是结果不明确
说明
日志如下，输入0时结果1和0各占50%左右，输入1时仍然如此。
Input:Mnist0_0 单特征识别结果总结：(Mnist1=0.51 ,Mnist0=0.49 )
Input:Mnist0_0 组特征识别结果总结：(Mnist1=0.55 ,Mnist0=0.45 )
Input:Mnist1_0 单特征识别结果总结：(Mnist1=0.56 ,Mnist0=0.44 )
Input:Mnist1_0 组特征识别结果总结：(Mnist1=0.60 ,Mnist0=0.40 )
思路1
往后流程：继续往后调试竞争因子，和单特征抽象，组特征识别等（思路2发现问题了，如下，所以思路1不用了先）。
思路2
深入细节：把单特征识别中，最不准确的一次item粒度层识别结果找出来，看下为什么它不准确，如下日志：
单特征识别结果:T766{Mnist1 = 2.01;Mnist0 = 0.01;} 匹配条数:10/ass10 匹配度:0.66 匹配率:1.0 色似度:0.8
单特征识别结果:T776{Mnist1 = 2.16;} 匹配条数:7/ass14 匹配度:0.71 匹配率:0.5 色似度:0.8
单特征识别结果:T668{Mnist0 = 1.00;} 匹配条数:7/ass45 匹配度:0.38 匹配率:0.2 色似度:0.7
item粒度层 单特征识别结果总结：(Mnist1=0.81 ,Mnist0=0.19 )
示图
说明
如上图，训练4个0，然后第2个1时，跑到最后一个粒度层时，发现有一个把1识别成0的，7/45匹配率。
分析1
如上图，1是竖直的，这里是怎么识别到0的两边竖线的呢？既然可复现，那就继续调试下原因。
分析2
如上日志，匹配率只有0.2太低了，这么低的匹配率和1像才奇怪了。
方案
考虑多粒度全部单特征识别完成后，统一进行竞争，否则单粒度层可能只有几条结果，大几率会竞争几个不准确的来。
实践
上述方案的-实践如下：
TODO1
把多个自适应粒度全单特征识别完后，统一进行竞争 T。
TODO2
以及后续流程中：统一进行单特征类比，统一进行组特征识别，统一进行组特征类比 T。
测试
思路2-方案：改成统一竞争后，也要继续测有没不准确的情况了，即使没有了，也要继续测下0识别到1的情况还有没有（经测还有）。
TODO3
把单特征的竞争值，用到组特征识别竞争中 T。
TODO4
单特征识别结果去掉防重，因为比如手写8有四个下划线，都是相同的局部，但不在一个位置，不应该防重掉 T。
TODO5
单特征结果竞争只淘汰20%，多保留结果用于组特征用，淘汰太强，会导致组特征激活的太少 T。
再测
还是有不准的情况，转35057。
35057 -如下日志 ，交替训练5个0 ，5 个1后 ，发现单特征匹配的都是匹配率超低的 ，查下那些匹配率高的哪去了 ？没激活 ？还是 ？
单特征识别结果 :T408 {Mnist1 = 0.03 ;Mnist0 = 2.02 ;} 匹配条数 :7 /ass111 匹配度 :0.51 匹配率 :0.1 色似度 :0.7
单特征识别结果 :T407 {Mnist0 = 2.02 ;} 匹配条数 :6 /ass268 匹配度 :0.94 匹配率 :0.0 色似度 :1.0
单特征识别结果 :T407 {Mnist0 = 2.02 ;} 匹配条数 :6 /ass268 匹配度 :0.94 匹配率 :0.0 色似度 :1.0
单特征识别结果 :T66 {Mnist1 = 0.52 ;Mnist0 = 1.62 ;} 匹配条数 :5 /ass45 匹配度 :0.27 匹配率 :0.1 色似度 :0.7
单特征识别结果 :T407 {Mnist0 = 2.02 ;} 匹配条数 :6 /ass268 匹配度 :0.92 匹配率 :0.0 色似度 :1.0
单特征识别结果 :T327 {Mnist1 = 0.02 ;Mnist0 = 2.02 ;} 匹配条数 :9 /ass129 匹配度 :0.38 匹配率 :0.1 色似度 :0.7
结果 ：经查单特征识别时 ，似层的组码过滤掉了 ，但交层组码没过滤 ，导致可以识别到组码 ，把组码彻底过滤掉后ok了 `T `。35058 -如下日志 ，交替训练6个0 ，6 个1后 ，发现组特征匹配的都是健全度超低的 ，查下那些匹配度高的哪去了 ？没激活 ？还是 ？
> 组特征识别结果 :T33 {Mnist1 = 1.36 ;Mnist0 = 3.11 ;} （单特征数 :2 assGV数 :38 protoGV数 :139 ） 匹配度 :0.97 符合度 :1.0 健全度 :0.05 (2 /38 ) 局部综合匹配度 :0.97
> 组特征识别结果 :T415 {Mnist1 = 1.00 ;Mnist0 = 0.14 ;} （单特征数 :19 assGV数 :29 protoGV数 :139 ） 匹配度 :0.32 符合度 :0.2 健全度 :0.66 (19 /29 ) 局部综合匹配度 :0.23
> 组特征识别结果 :T350 {Mnist1 = 1.00 ;Mnist0 = 1.04 ;} （单特征数 :1 assGV数 :23 protoGV数 :139 ） 匹配度 :0.52 符合度 :1.0 健全度 :0.04 (1 /23 ) 局部综合匹配度 :0.46
> 组特征识别结果 :T205 {Mnist1 = 1.10 ;Mnist0 = 0.26 ;} （单特征数 :7 assGV数 :73 protoGV数 :139 ） 匹配度 :0.19 符合度 :0.7 健全度 :0.10 (7 /73 ) 局部综合匹配度 :0.54
> 组特征识别结果 :T421 {Mnist1 = 1.00 ;Mnist0 = 0.10 ;} （单特征数 :33 assGV数 :93 protoGV数 :139 ） 匹配度 :0.14 符合度 :0.4 健全度 :0.35 (33 /93 ) 局部综合匹配度 :0.29
> 组特征识别结果 :T399 {Mnist1 = 0.94 ;Mnist0 = 1.63 ;} （单特征数 :3 assGV数 :39 protoGV数 :139 ） 匹配度 :0.32 符合度 :1.0 健全度 :0.08 (3 /39 ) 局部综合匹配度 :0.20
> 组特征识别结果 :T159 {Mnist1 = 1.06 ;Mnist0 = 0.20 ;} （单特征数 :6 assGV数 :78 protoGV数 :139 ） 匹配度 :0.15 符合度 :0.6 健全度 :0.08 (6 /78 ) 局部综合匹配度 :0.60
> 组特征识别结果 :T100 {Mnist1 = 2.68 ;Mnist0 = 3.34 ;} （单特征数 :2 assGV数 :36 protoGV数 :139 ） 匹配度 :0.41 符合度 :0.5 健全度 :0.06 (2 /36 ) 局部综合匹配度 :0.32
> 组特征识别结果 :T66 {Mnist1 = 5.37 ;Mnist0 = 4.27 ;} （单特征数 :2 assGV数 :45 protoGV数 :139 ） 匹配度 :0.27 符合度 :1.0 健全度 :0.04 (2 /45 ) 局部综合匹配度 :0.28
> 组特征识别结果 :T133 {Mnist1 = 0.04 ;Mnist0 = 1.20 ;} （单特征数 :5 assGV数 :82 protoGV数 :139 ） 匹配度 :0.17 符合度 :0.6 健全度 :0.06 (5 /82 ) 局部综合匹配度 :0.53
> 组特征识别结果 :T81 {Mnist1 = 1.00 ;Mnist0 = 1.65 ;} （单特征数 :2 assGV数 :20 protoGV数 :139 ） 匹配度 :0.08 符合度 :1.0 健全度 :0.10 (2 /20 ) 局部综合匹配度 :0.28
> item粒度层 :0.85 组特征识别结果总结 ：(Mnist0 =0.51 ,Mnist1 =0.49 )
分析 ：健全度 =rectItems .count / assGT .count
思路 ：健全度问题 ，看起来其实是单特征的覆盖问题 ，单特征太少 ，它自然健全度就小 。
矛盾1 . 如果单特征过多 ，会有性能问题 。
矛盾2 . 如果单特征太少 ，健全度又太小 。
那么 ：我们如何解决单特征少 ，但又要覆盖到健全度呢 ？
方案1 、打通单特征和组特征识别 ？即单特征识别后立马执行组特征识别 ？
方案2 、组特征也自举 ，撞大运几率太低 ，那就找大运 。
抉择 ：方案1只是提前及时联想组特征而已 ，方案2才是真正覆盖组特征健全度的关键 。
结果 ：二者结合 ，其实就是组特征识别支持自举 `转n35p06 T `。CreateTime 2025.07.29
35058中测到组特征识别健全度太低问题，然后在末尾，分析得到方案为：组特征需要支持下自举，本文工程实践之。
35061
组特征识别支持自举方式之：工程实践
TODO1
组特征识别中，每联想到一个组特征，就将其内容全取出来，到protoGT中，自举取值，判断匹配度等 T。
回顾
现在是通过gv.refPorts筛选出单特征结果实现单特征自举识别。
TODO2
通过gv.refPorts筛选出组特征结果，并与单特征.conPorts取交集，来联想有效组特征 T
TODO3
联想到有效组特征后，复用原单特征自举算法，来实现组特征的自举识别 T。
35062
组特征类比迭代：方案分析
回顾
以前是由单特征求gv并集得到protoT，来进行组特征类比用。
疑问
而现在，单特征识别结果有不健全问题，那么protoT是否也有此问题呢？
方案1
维持原状（用单特征识别结果并集，生成protoT），与现在的识别结果assGT类比，如果有问题再说。
缺点：1、现在的单特征识别更像只是一个切入点，而组特征识别才是全貌。
缺点：2、所以可能类比时，现在的protoT 和 新版自举识别的assGT之间可能互相不健全gv互相映射不上。
方案2
每个组特征自举识别assGT结果，各自从protoColorDic取对应的gvs生成protoGT，进行类比。
缺点：太麻烦，每一个识别结果，都生成一个protoGT，性能不好，空间也浪费，尽量不用该方案。
方案3
单纯把组特征识别结果中，显著bestGVs的提取出来，构建为类比absGT结果。
做点：该方案仅使用当前识别的bestGVs竞争，来实现显著度判断，和抽象构建absGT。
抉择
如上分析，暂选方案3，但先测测跑跑，等方案1的问题确实出现时，再实践方案3。
TODO1
先测方案1太麻烦了，直接写方案3（复用单特征类比来写）T。
TODO2
原来的单特征类比并没有论责排除，加上论责过滤掉全责的 T。
TODO3
把构建protoT去掉，因为类比时其实用不着它：T
TODO3.1：但因此固定粒度就得构建成isGT了，不然最具象组特征就没地方构建了，所有长时记忆里的T都是源自固定粒度了 T。
TODO3.2：并且所有T抽具象存匹配度，符合度等时，就得重新考虑下该计算成什么值才准确 T。
TODO3.3：即所有T构建时默认全是组T，单T识别的类比结果为单T，组T识别和类比结果保持为组T T。
35063
回测
说明
测试本节上述改动。
测试项1
回测下0和1识别不准确问题。
测试项2
测试下显著特征浮现。
测试方式
边训练边观察日志，一步步观察识别算法的识别率竞争因子数据变化。
35064
BUG1：组特征竞争浮现不明显问题
说明
经测训练手写0十张左右，查看组特征识别结果的日志，发现竞争浮现的变化不够明显：
日志A组
竞争第一名如下
匹配条数:16/ass36 匹配度:0.46 匹配率:0.4 色似度:0.8
匹配条数:35/ass38 匹配度:0.47 匹配率:0.9 色似度:0.7
匹配条数:34/ass38 匹配度:0.62 匹配率:0.9 色似度:0.8
匹配条数:37/ass39 匹配度:0.55 匹配率:0.9 色似度:0.8
匹配条数:36/ass38 匹配度:0.64 匹配率:0.9 色似度:0.8
日志B组
竞争最后一名如下
匹配条数:14/ass39 匹配度:0.36 匹配率:0.4 色似度:0.7
匹配条数:14/ass39 匹配度:0.27 匹配率:0.4 色似度:0.7
匹配条数:13/ass45 匹配度:0.38 匹配率:0.3 色似度:0.7
匹配条数:13/ass36 匹配度:0.35 匹配率:0.4 色似度:0.7
匹配条数:15/ass47 匹配度:0.41 匹配率:0.3 色似度:0.6
问题
发现无论是匹配率，还是匹配度的竞争浮现，效果都不明显。
分析
说白了，主要是匹配率太低，它受到另外两个因子的影响，要么增强匹配率的权重，要么就减弱另外两个的权重。
方案
先去掉色似度，色似度看起来也没啥用，上次增加它的原因，现在可能已经用不到了，先去掉试下 T。
结果
去掉色似度后ok了，如果以后因为去掉色似度导致bug，可以改回来，然后把匹配率改成2次方来强调它的作用试下。
回测
1、单特征识别结果首位：匹配条数:5/ass5 匹配度:0.61 匹配率:1.0
2、组特征识别结果首位：匹配条数:35/ass38 匹配度:0.47 匹配率:0.9
35065
回测下0和1识别不准确问题。
说明
扔0稳定后，再扔1，稳定后，再扔0，看能不能慢慢识别二者都准。
问题
经训练：来回跑了6个0，12个1后，发现虽然能识别各自，但不太明显，如下：
识别1：组特征识别结果总结：(Mnist1=0.53 ,Mnist0=0.47 )
识别0：组特征识别结果总结：(Mnist0=0.56 ,Mnist1=0.44 )
分析
如上，虽然识别>50%，但不多，这比率不明显。
方案1
加训，再跑跑看，加训能不能使准确率提升？
查下：目前竞争的gt中，是后面的很不准，导致整体太不准？那总结日志是不是要考虑乘上这个权重。
方案2
展开分析，看抽象gt的情况，识别过程，查为什么明明0和1很不同，却搞出来的结果准确率不明显。
查下：是不是抽象gt的ref没构建上？还是logDesc没更新上？
继续查
如下日志，扔1，然后组特征识别前三条如下：
组特征识别结果:GT413{Mnist1 = 1.00;} 匹配条数:22/ass23 匹配度:0.74 匹配率:1.0
组特征识别结果:GT459{Mnist1 = 1.00;} 匹配条数:21/ass29 匹配度:0.45 匹配率:0.7
组特征识别结果:GT33{Mnist0 = 2.00;} 匹配条数:30/ass38 匹配度:0.40 匹配率:0.8
说明：第3条日志，把1识别成0，并且匹配条数还这么高（30/38）？
示图：
分析：如上图，1和0大不同，匹配率肯定不应该这么高，即使0的一侧识别成1，也最多50%才对。
35066 -训练0十个 ，1 十个后 ，扔1识别的单特征和组特征结果全是0 。
单特征识别结果 :T503 {Mnist0 = 2.00 ;} 匹配条数 :12 /ass12 匹配度 :0.49 匹配率 :1.0
单特征识别结果 :T525 {Mnist0 = 8.00 ;} 匹配条数 :16 /ass16 匹配度 :0.47 匹配率 :1.0
单特征识别结果 :T470 {Mnist0 = 10.00 ;} 匹配条数 :12 /ass12 匹配度 :0.44 匹配率 :1.0
单特征识别结果 :T463 {Mnist0 = 2.00 ;} 匹配条数 :15 /ass16 匹配度 :0.46 匹配率 :0.9
单特征识别结果 :T574 {Mnist0 = 4.00 ;} 匹配条数 :16 /ass16 匹配度 :0.43 匹配率 :1.0
组特征识别结果 :GT453 {Mnist0 = 2.00 ;} 匹配条数 :17 /ass20 匹配度 :0.45 匹配率 :0.9
组特征识别结果 :GT452 {Mnist0 = 2.00 ;} 匹配条数 :16 /ass21 匹配度 :0.49 匹配率 :0.8
组特征识别结果 :GT378 {Mnist0 = 2.00 ;} 匹配条数 :18 /ass24 匹配度 :0.38 匹配率 :0.8
分析 ：查下 ，1 都哪去了 ？都没资格激活 ？经查 ，代码和日志如下 ：
* refPorts = ARR_SUB (refPorts , 0 , MIN (MAX (refPorts .count * 0.3f , 5 ), 20 ));
* 前识别结果总结 ：(Mnist0 =0.99 ,Mnist1 =0.01 )
* 后识别结果总结 ：(Mnist0 =1.00 )
说明 ：在上面识别算法中 ，激活的refPorts在竞争后 ，导致新事物都被过滤掉了 。
方案 ：这里竞争的有点早了 ，新事物会全被竞争过滤掉 ，可以去掉这个竞争代码试下 。
结果 ：去掉后 ，有1了 ，但不多 ，还是只有一点点 ，如下日志 ：
* 特征识别Step2竞争过滤前总结 ：(Mnist0 =0.99 ,Mnist1 =0.01 )
* 特征识别Step2竞争过滤后总结 ：(Mnist0 =0.99 ,Mnist1 =0.01 )
后续 ：转下表继续查 & 另外如果最后修复后 ，发现本表方案 ，其实作用不大 ，看要不要回滚掉本表方案的代码改动 。35067 -接上表 ，经测 ：发现单特征识别结果中 ，就99 %是0 ，只有1 %是1 ，如下 ：
* 单特征识别结果 :T453 {Mnist1 = 1.00 ;} 匹配条数 :23 /ass23 匹配度 :0.98 匹配率 :1.0
* 单特征识别结果 :T562 {Mnist0 = 4.00 ;} 匹配条数 :6 /ass6 匹配度 :0.65 匹配率 :1.0
* 单特征识别结果 :T559 {Mnist0 = 8.00 ;} 匹配条数 :5 /ass5 匹配度 :0.64 匹配率 :1.0
* 单特征识别结果 :T546 {Mnist0 = 2.00 ;} 匹配条数 :8 /ass8 匹配度 :0.64 匹配率 :1.0
* 单特征识别结果 :T278 {Mnist0 = 16.00 ;} 匹配条数 :5 /ass5 匹配度 :0.63 匹配率 :1.0
分析 ：几乎都是0抽象来的 ，那1的抽象特征都哪去了呢 ？
思路 ：扔10个0的时候 ，生成了0的知识网 ，然后扔10个1的时候 ，难道没能动态渗透到这个知识网中吗 ？
待查 ：为什么激活的1那么少 ？查下1往0的知识网中动态渗透时 ，到哪步遇阻导致这么少的 ？
分析 : 还是先查下这里 ：
1. sv和gv识别没问题 ，就是匹配度来排序的 。
2. 核实下此处是否还是旧太多 ，新太少 ？
3. 如果这里根本没啥问题 ，那就是单纯的想不起来了 ，那就得对近期事物有更大的优先级 （说白了 ，对时间做为一个竞争因子 ）。
4. 即使如此 ，现在也太窄了 ，才0和1两个数字就覆盖不到了 ？所以这个覆盖这么窄肯定不行 。
经查1 : 发现训练到后面时 ，pid也是最近的 ，所以并不是最近的特征没被激活到 。
经查2 : 经查现在特征类比没有protoT ，所以仅仅是assT中类比出absT ，如果最初的assT是0来的 ，然后用1识别到它多次 ，它无论类比多少次 ，得到absT的logDesc都是0 ，没有1 。
方案 ：经查2可得 ，特征类比时logDesc应该从protoT .logDesc +1 才对 （尽管此时没有protoT ，但却是有protoLogDesc的 ）`T `。
实践 ：在特征类比算法中 ，把protoLogDesc传过去 ，并 +1 `T `。
结果 ：去掉后 ，有1了 ，但仍不够 ，比如扔了10个0 ，10 个1后 ，此时1还是只识别到20 %，这显然不对 ，如下 ：
* 单特征识别结果总结 ：(Mnist0 =0.80 ,Mnist1 =0.20 )
* 组特征识别结果总结 ：(Mnist0 =0.89 ,Mnist1 =0.11 )
后续 ：转下表继续查 。35068 -接上表 ，继续查1只识别成20 %为1的问题 。
* 单特征识别结果 :T349 {Mnist1 = 3.50 ;Mnist0 = 18.61 ;} 匹配条数 :5 /ass5 匹配度 :0.54 匹配率 :1.0
* 单特征识别结果 :T458 {Mnist1 = 4.11 ;Mnist0 = 8.00 ;} 匹配条数 :8 /ass8 匹配度 :0.53 匹配率 :1.0
* 单特征识别结果 :T424 {Mnist1 = 15.24 ;Mnist0 = 76.00 ;} 匹配条数 :7 /ass7 匹配度 :0.53 匹配率 :1.0
* 单特征识别结果 :T570 {Mnist1 = 5.42 ;Mnist0 = 10.00 ;} 匹配条数 :6 /ass6 匹配度 :0.53 匹配率 :1.0
* 单特征识别结果 :T347 {Mnist1 = 5.23 ;Mnist0 = 64.81 ;} 匹配条数 :7 /ass7 匹配度 :0.53 匹配率 :1.0
* 单特征识别结果 :T279 {Mnist1 = 46.32 ;Mnist0 = 283.64 ;} 匹配条数 :6 /ass6 匹配度 :0.52 匹配率 :1.0
* 组特征识别结果 :GT471 {Mnist1 = 2.20 ;Mnist0 = 15.00 ;} 匹配条数 :9 /ass9 匹配度 :0.41 匹配率 :1.0
* 组特征识别结果 :GT509 {Mnist1 = 0.37 ;Mnist0 = 3.00 ;} 匹配条数 :10 /ass10 匹配度 :0.40 匹配率 :1.0
* 组特征识别结果 :GT471 {Mnist1 = 2.20 ;Mnist0 = 15.00 ;} 匹配条数 :8 /ass9 匹配度 :0.43 匹配率 :0.9
* 组特征识别结果 :GT510 {Mnist1 = 0.35 ;Mnist0 = 3.00 ;} 匹配条数 :10 /ass10 匹配度 :0.38 匹配率 :1.0
* 组特征识别结果 :GT510 {Mnist1 = 0.35 ;Mnist0 = 3.00 ;} 匹配条数 :9 /ass10 匹配度 :0.37 匹配率 :0.9
* 组特征识别结果 :GT317 {Mnist0 = 2.46 ;} 匹配条数 :12 /ass16 匹配度 :0.41 匹配率 :0.8
* 组特征识别结果 :GT509 {Mnist1 = 0.37 ;Mnist0 = 3.00 ;} 匹配条数 :8 /ass10 匹配度 :0.38 匹配率 :0.8
* 组特征识别结果 :GT319 {Mnist0 = 2.41 ;} 匹配条数 :11 /ass16 匹配度 :0.40 匹配率 :0.7
说明 ：如上 ，训练十个0 ，十个1时 ，最后一个1时 ，取日志如上 。
分析 ：可见 ，这些抽象结果都是从0抽象来的 ，因为它与1有共同点 ，又因为它已经抽象过有较高匹配率 ，所以它竞争中优胜了 。
思路 ：那么是不是一半采用匹配率 ，另一半可以弱化甚至不用匹配率 ？避免最终识别到的都是抽象的别的事物 。
比如 ：见过几次乔峰后 ，用抽象乔峰风格来辨所有别的江湖人士 ，哪怕明明很多具象细节不同 ，也会只匹配到抽象的乔峰 ，这显然不对 。
方案1 ：在组特征识别时 ，建议去掉匹配率试下 ，毕竟组特征是整体特征 ，是可以适当具象的 。
结果1 ：GT识别去掉匹配率 ，一样识别的还是不准确 。
方案2 ：改为组特征只识别似层GT结果试下 （因为只识别似层结果 ，当初也是一个挺原则的事 ）。
结果2 ：采用方案2后 ，把方案1回滚 ，只保留方案2改动 ，感觉有点效果 ，但识别还是不太准 。
思路3 ：不得不怀疑 ，问题还是出现在自举算法上 ？
方案3 ：输入多个数字 ，然后用第二张某数字 ，来一一自举匹配下 ，看究竟与哪个更匹配 （以此来验证自举算法的可靠性 ）。35069 -上节方案3实践后 ，我们先收集下前10个0的具象特征 ，然后用用第11 、12 个0 ，以及第1 、2 个1分别与前10个0进行自举算法比较匹配度 ，日志如下 ：
//第11个0与前10个0的识别结果
//0. 单特征识别结果:T198{Mnist0 = 1.00;} 匹配条数:39/ass41 匹配度:0.70 匹配率:1.0
//1. 单特征识别结果:T205{Mnist0 = 1.00;} 匹配条数:33/ass36 匹配度:0.69 匹配率:0.9
//2. 单特征识别结果:T90{Mnist0 = 1.00;} 匹配条数:33/ass36 匹配度:0.66 匹配率:0.9
//3. 单特征识别结果:T111{Mnist0 = 1.00;} 匹配条数:36/ass39 匹配度:0.62 匹配率:0.9
//4. 单特征识别结果:T33{Mnist0 = 1.00;} 匹配条数:34/ass38 匹配度:0.63 匹配率:0.9
//5. 单特征识别结果:T66{Mnist0 = 1.00;} 匹配条数:42/ass45 匹配度:0.58 匹配率:0.9
//6. 单特征识别结果:T168{Mnist0 = 1.00;} 匹配条数:39/ass44 匹配度:0.52 匹配率:0.9
//7. 单特征识别结果:T133{Mnist0 = 1.00;} 匹配条数:43/ass47 匹配度:0.49 匹配率:0.9
//8. 单特征识别结果:T157{Mnist0 = 1.00;} 匹配条数:34/ass44 匹配度:0.51 匹配率:0.8
//9. 单特征识别结果:T184{Mnist0 = 1.00;} 匹配条数:30/ass39 匹配度:0.47 匹配率:0.8
//第12个0与前10个0的识别结果
//0. 单特征识别结果:T184{Mnist0 = 1.00;} 匹配条数:37/ass39 匹配度:0.55 匹配率:0.9
//1. 单特征识别结果:T157{Mnist0 = 1.00;} 匹配条数:39/ass44 匹配度:0.58 匹配率:0.9
//2. 单特征识别结果:T133{Mnist0 = 1.00;} 匹配条数:41/ass47 匹配度:0.58 匹配率:0.9
//3. 单特征识别结果:T33{Mnist0 = 1.00;} 匹配条数:35/ass38 匹配度:0.53 匹配率:0.9
//4. 单特征识别结果:T66{Mnist0 = 1.00;} 匹配条数:39/ass45 匹配度:0.48 匹配率:0.9
//5. 单特征识别结果:T205{Mnist0 = 1.00;} 匹配条数:31/ass36 匹配度:0.49 匹配率:0.9
//6. 单特征识别结果:T111{Mnist0 = 1.00;} 匹配条数:33/ass39 匹配度:0.48 匹配率:0.8
//7. 单特征识别结果:T198{Mnist0 = 1.00;} 匹配条数:34/ass41 匹配度:0.49 匹配率:0.8
//8. 单特征识别结果:T168{Mnist0 = 1.00;} 匹配条数:35/ass44 匹配度:0.50 匹配率:0.8
//9. 单特征识别结果:T90{Mnist0 = 1.00;} 匹配条数:31/ass36 匹配度:0.43 匹配率:0.9
//第1个1与前10个0的识别结果
//0. 单特征识别结果:T90{Mnist0 = 1.00;} 匹配条数:28/ass36 匹配度:0.45 匹配率:0.8
//1. 单特征识别结果:T111{Mnist0 = 1.00;} 匹配条数:31/ass39 匹配度:0.44 匹配率:0.8
//2. 单特征识别结果:T205{Mnist0 = 1.00;} 匹配条数:27/ass36 匹配度:0.44 匹配率:0.8
//3. 单特征识别结果:T66{Mnist0 = 1.00;} 匹配条数:34/ass45 匹配度:0.43 匹配率:0.8
//4. 单特征识别结果:T33{Mnist0 = 1.00;} 匹配条数:30/ass38 匹配度:0.41 匹配率:0.8
//5. 单特征识别结果:T198{Mnist0 = 1.00;} 匹配条数:29/ass41 匹配度:0.44 匹配率:0.7
//6. 单特征识别结果:T168{Mnist0 = 1.00;} 匹配条数:31/ass44 匹配度:0.37 匹配率:0.7
//7. 单特征识别结果:T157{Mnist0 = 1.00;} 匹配条数:26/ass44 匹配度:0.41 匹配率:0.6
//8. 单特征识别结果:T133{Mnist0 = 1.00;} 匹配条数:28/ass47 匹配度:0.38 匹配率:0.6
//9. 单特征识别结果:T184{Mnist0 = 1.00;} 匹配条数:23/ass39 匹配度:0.38 匹配率:0.6
//第2个1与前10个0的识别结果
//0. 单特征识别结果:T90{Mnist0 = 1.00;} 匹配条数:22/ass36 匹配度:0.45 匹配率:0.6
//1. 单特征识别结果:T198{Mnist0 = 1.00;} 匹配条数:27/ass41 匹配度:0.42 匹配率:0.7
//2. 单特征识别结果:T111{Mnist0 = 1.00;} 匹配条数:25/ass39 匹配度:0.40 匹配率:0.6
//3. 单特征识别结果:T66{Mnist0 = 1.00;} 匹配条数:28/ass45 匹配度:0.40 匹配率:0.6
//4. 单特征识别结果:T33{Mnist0 = 1.00;} 匹配条数:25/ass38 匹配度:0.37 匹配率:0.7
//5. 单特征识别结果:T205{Mnist0 = 1.00;} 匹配条数:23/ass36 匹配度:0.36 匹配率:0.6
//6. 单特征识别结果:T133{Mnist0 = 1.00;} 匹配条数:24/ass47 匹配度:0.44 匹配率:0.5
//7. 单特征识别结果:T168{Mnist0 = 1.00;} 匹配条数:23/ass44 匹配度:0.43 匹配率:0.5
//8. 单特征识别结果:T184{Mnist0 = 1.00;} 匹配条数:26/ass39 匹配度:0.33 匹配率:0.7
//9. 单特征识别结果:T157{Mnist0 = 1.00;} 匹配条数:21/ass44 匹配度:0.40 匹配率:0.5
说明 ：如上日志可见 ，用0识别0和识别1 ，二者区别似乎不太明显 。
分析 ：用0识别0确实准一些 ，但单纯的这样自举肯定不太够 ，继续分析 “自举算法 ”是不是有问题 。
问题 ：即主要是 ：用0来识别 （0 和1 ），二者识别匹配度差别不明显问题 。
* 分析Step1 ：重新分析下自举算法 ：我们的要素有 ：抽象局部特征 ，抽象整体特征 ，具象整体特征 。
思路1 、首先这种单纯的具象AB ，AC的匹配度 ，肯定是不足的 （差别不明显 ），必须得向抽象找一般性规律 。
思路2 、现在的自举算法太简陋了 ，ST找了抽象 ，GT马上就找最具象 。
1 、现在的局部特征太不全面了 ，可能识别到数个结果 ，全是0的左上角 。
2 、比如0的左右有两竖 ，这两竖是两个局部特征 ，但也是整体0中必须存在的显著特征 （一般性抽象特征 ）。
3 、那么 ：我们是不是还是应该改回支持特征嵌套 ？（即还是改回把GT独立成一个网络模块 ）。
4 、即 ：特征识别算法 ，对自举依赖度过高了 ，它效果有限 。
**方案1 、即 ：GT要独立成网络模块 ，它由ST组成 ，是宏观一级的网络模块 。**
5 、GT要独立成网络模块 ，它由ST组成 ，是宏观一级的网络模块 （参考35069 -Step1 ）。
6 、正据 ：当下很难在如此简单的 （抽象为ST ，具象为GT ）结构下 ，识别到准确的GT出来 。所以 ：本方案把GT改回独立的网络模块 ，由嵌套ST构成 。
7 、例子 ：像0的左右两竖 ，就是一个GT特征 ，它表征了两个显著ST局部特征 ，即 ：有两个竖线左右并排着 。
8 、TODO1 ：从ST向GT识别时 ，也要用到位置符合度 ，比如0的两竖 ，就是位置符合度为左右两边 。
* 分析Step2 ：如上日志中 ，匹配率0 .9 以上的绝对准确吗 ？加重匹配率权重 ，可以使之变的准确吗 ？
1 、方案1的问题 ，其实归根结底还是健全度的问题 ，其实我们在35061改GT识别为自举方式 ，就是解决这一问题的 。
2 、那么我们是不是不需要搞方案1那么麻烦 ，直接加重匹配率权重 ，试下能不能行 ？方案如下 ：
3 、因为ST和GT如果是两个宏微模块 ，那么就需要从微观宽入 ，对撞出一个窄出的GT出来 ，在图像识别这种大数据量的识别中 ，是很难的 。
4 、而自举算法 ，其实就很解决这个宽入窄出的难点 ，它即偷懒又性能好 ，依此推断它的效果应该不差的 ，所以我们还是要多给自举算法机会 ，再跑跑看 ，再多观察观察 。
方案2 、得跑跑看试下 ，凭空猜测想不出这样有没什么问题 。
5 、先增强匹配率权重 ，然后重跑跑看 ，能不能变的准确 ，以及看下有没有别的什么问题 （参考35069 -Step2 ）。
6 、重跑后发现 ，增加权重后 ，0 识别0有所提升 （比如匹配率从0 .85 左右变成0 .95 左右 ），但0识别1也有0 .5 到0 .8 左右的匹配率 ）。
7 、那么 ：为什么0识别1的匹配率那么高 ？0 识别0的识别率为什么很难拉开差距 ？
8 、分析 ：0 和1的各种方向姿态都有变化 ，如果单纯的自举匹配 ，切块很难切到一起去 ，所以说白了只是在蒙而已 ，它受这种姿态方向书写习惯等的直接影响 。
9 、而这种直接影响需要被滤掉 ，滤掉的方式就是增加一个宏微层 。
10 、所以还是得转向方案1 ，方案2应该是效果怎么也好不了太多的 （效果有限 ）。CreateTime 2025.09.04
接上节末方案1，因为组特征自举的效果有限，所以转而加一层组特征网络模块，通过宏微加一层，来解决这个问题。
35071-问题：即主要是：用0来识别（0和1），二者识别匹配度差别不明显问题（接35069-方案1）。
分析：重新分析下自举算法：我们的要素有：抽象局部特征，抽象整体特征，具象整体特征。
思路1、首先这种单纯的具象AB，AC的匹配度，肯定是不足的（差别不明显），必须得向抽象找一般性规律。
思路2、现在的自举算法太简陋了，ST找了抽象，GT马上就找最具象。
现在的局部特征太不全面了，可能识别到数个结果，全是0的左上角。
比如0的左右有两竖，这两竖是两个局部特征，但也是整体0中必须存在的显著特征（一般性抽象特征）。
那么：我们是不是还是应该改回支持特征嵌套？（即还是改回把GT独立成一个网络模块）。
即：特征识别算法，对自举依赖度过高了，它效果有限。
方案1、即：GT要独立成网络模块，它由ST组成，是宏观一级的网络模块。
GT要独立成网络模块，它由ST组成，是宏观一级的网络模块（参考35069-Step1）。
例子：像0的左右两竖，就是一个GT特征，它表征了两个显著ST局部特征，即：有两个竖线左右并排着。
正据1：当下很难在如此简单的（抽象为ST，具象为GT）结构下，识别到准确的GT出来。所以：本方案把GT改回独立的网络模块，由嵌套ST构成。 从例子来看，其实显著特征早就是桌边桌角、0的两边侧线、小人的头手脚等等这样的了，所以组特征是绝对需要嵌套单特征的。 而当下没独立GT模块，确实也导致识别很难拉开准确率（因为显著特征总是有位置等偏差，无法直接判断同区域匹配度等）。 为了显著GT特征（即得到absGT抽象）带来识别准确度的升华（参考35074-方案v3-疑问）。
35072
组特征改回独立网络模块实践规划1：TODOLIST
TODO1
从ST向GT识别时，也要用到位置符合度，比如0的两竖，就是位置符合度为左右两边 T。
TODO2
GT.content由ST_p组成，还是由ST.gvs组成？按直观来看，几乎肯定是应该由ST_p组成 T。
回顾：以前用ST.gvs组成过，不过后来因为各种absST.gvs组起来后，成了想像中的正确（参考35046-原则3&方案v8）。
问题：由哪些ST来组成GT.content？比如桌角位置有多个局部特征时，要防重么？
解答：不因同在桌角就防重：比如桌角是直角，但有一定的弧度，这个直角和弧度，虽然在同一个位置，确是两个ST。
方案1：先由ST识别结果的前10条，组成GT.content，如果以后发现这样不太行，再深入改进该方案。
问题：组特征改回独立网络模块测试之：。
矛盾1：如果取100条st，则太长，很多重复的表达，比如0的左上角可能有多个st结果，都打包进protoGT去了。
矛盾2：如果取前10条st，则太短，如果这些st重复表达，则必然不全面。
方案2：加防重机制：对这些stModels进行竞争，类似rect的st，仅保留最准确的一条。
方案3：不改，就100条全放进去，在gt识别类比中，再慢慢使之抽象化一般化，缩短gt的内容长度。
抉择：方案1太少可能不全面，方案2很可能把不那么准但却很普适抽象的st过滤掉，方案3借助类比竞争浮现机制是最佳的。
佐例：记忆里的头发和羽毛，是根根丝滑清晰的吗？显然不是，对于整体的质感，可能只是一个特征而已（所以还是方案3合理）。
结果：并且方案3还有个做点，它最简单，不用加任何代码，直接测试观察gt的类比浮现过程就行。
TODO3
GT识别不能用自举，因为显著特征的相对位置可能会有变化，在protoDic中切图，往往切不准确 T。
方案：正好ST和GT分开宏微层了，用ST.ref取交，对撞出GT是目前较为直观可行的方案。
竞争因子1：匹配度无用：ST和GT匹配度全是1，因为本来就是直接的ref引用关系，一模一样，当然为1。
竞争因子2：位置符合度，继续延用原来的zenTiModel里的“缩放+平移”，的计算方式。
竞争因子3：健全度，即匹配率，用rectItems.count / assGT.count来计算。
竞争因子4：ref到GT的来源ST的匹配率匹配度，也可以参与竞争（比如：用牙签组成的数字0，这两个竖是否与0的左右两竖匹配）。
结果
按照以上推进迭代了组特征识别V5算法。
35073
组特征改回独立网络模块实践规划2：TODOLIST
问题
用assST还是absST构建protoGT？
方案1
用单特征类比结果absSTs，来生成absGT。
TODO1. 根据gvsAtProtoRect和itemAtAssRect，可以计算出absST在absGT中的位置。
缺点：下面的sameItems下存的是jvBuModel，而jvBuModel.bestGV是不会存在protoTG下的，protoGT的元素是ST，而bestGV应该是存在各个st下的才对（所以该方案在实践上会复杂不少）。
缺点：方案1麻烦，要先单特征类比再构建和类比组特征，并且各种后续思维操作用这些数据时，还得照顾到这一层抽象（多取一层，并且不好取，可能还得在工作记忆里传递它）。
方案2
构建protoGT的，和GT识别的，都是整个assST，所以此处其实也不必说必须得用absST，先就用assST也是可以的（采纳方案）。
TODO1. absGT在assGT中的位置：absGT和assGT要构建抽具关联，可直接用itemAtAssRect求并区域做为assST在assGT中的位置（如上newAbsAtAssRect） T。
TODO2. itemST在absGT中的位置：同时它也可以做为assST在absGT中的位置（只是需要左上角把leftMargin和leftMargin留白减掉）（见下代码） T。
TODO3. 另外：absGT和protoGT就先不进行抽具关联了，它俩的关联需求没那么强，看起来不怎么用的着 T。
缺点：用assST构建protoGT比absST构建滞后一步。
优点：但这么做，这样效率快许多（不用来回传递assST和对应的absST了），但效果却只少一点点（旧有知识体系是终身学习的本就已经很稳妥了）。
抉择
终上优缺点分析，采纳方案2，实践如下 T。
结果
按照以上推进迭代了组特征类比V5算法。
35074
组特征改回独立网络模块测试之：有些GT识别结果有重影。
示图
分析
以前在35043“组特征本来就是独立模块时”已有过类似重影问题，回顾下当时的原因。
回顾1
当时为了防重(比如0的内外圈都会识别到导致重影)，当时直接把st结果根据pid防重了（参考35043）。
回顾2
但后来因为8有四个下划线，防重后只有一个了，所以又废弃掉了（参考35056-TODO4）。
总结
所以，上回的解决经验看来是无用了，此问题还是重新思考解决吧。
分析
后来亦有混乱问题，原因是protoGT的构成，它由各个assST来构成，必然有拼凑的混乱痕迹。
方案1
可以每个dotSize单独生成组特征。
缺点：但如果确实是跨dotSize才能识别的更好的gt，这样反而识别的不准，多方向尝试成了单向尝试，结果准确度肯定受影响。
方案2
可以在gt慢慢竞争中，把多余的残影重影排除掉。
实践：这个得实际跑下观察效果，如下：
跟进1
如下代码段1，因为0.T33 和 5.T94识别到两个近乎完全的0的ST特征，所以最终构建protoGT时，必然有重影。
分析：即使结果不是多个全面的0，而只是0的上方那条横线，这些横线统合生成protoGT后，一样会体现为横线的重影。
跟进2
随着训练和类比慢慢竞争，最终ST识别结果中，还会有这些具象全面的ST结果吗？
训练到第7个0时，GV数都在5到12之间，可见：往后走那么全面的ST确实少了。
线索
那么生成protoGT时，是否应该修正一下它的rect？是不是有计算错误？经核实确实有错误，如下：
经查
assST在protoGT中的rect位置，用了bestGVsAtProtoRect，但这个不准确，bestGVs只是assST元素的一部分。
思路
所以要么就改成absST来构建protoGT算了，本来也不是每个assST的全部元素都匹配上了，只是bestGVs部分而已。
方案v3
先类比ST，把类比结果absST们用来构建protoGT，并正确计算每个absSTAtProtoGT.rect。
疑问：此方案相当于把protoST的absSTs构建成protoGT，那我们何必要protoGT呢？直接用初版的具象交整体protoST不就行了吗？
第一版本回顾分析：初版通过conPorts交集找整体特征GT，其实是单纯在找准确度。
第二版本回顾分析：GT自举版也是在单纯求准确度，单纯求准确度是升华不来显著度的（参考35071）。
总结：单纯求准确度最终很难升华，往往准确度不会太高，比如：初版的2和3分不清的问题，第二版更是0和1的识别准确率都只有55%到60%。
解答：所以为了升华显著度，就必须独立GT模块，通过protoGT来抽象absGT，通过抽象来出显著GT特征，来达成识别更准确的目标。
TODOv4
到代码中，把GT类比v5的结果收集出来，取absST和其rect结果，来构建protoGT T。
结果
改为由absST和absSTAtProtoRect来构建后，问题好多了，几乎没什么重影了。
35074-代码段1：
0 . 单特征识别结果: T33 { Mnist0 = 1.00; } 匹配条数:36/ass38 匹配度:0.61 匹配率:0.9
1 . 单特征识别结果: T70 { Mnist0 = 2.38; } 匹配条数:17/ass18 匹配度:0.57 匹配率:0.9
2 . 单特征识别结果: T68 { Mnist0 = 2.49; } 匹配条数:25/ass26 匹配度:0.50 匹配率:1.0
3 . 单特征识别结果: T69 { Mnist0 = 2.43; } 匹配条数:18/ass21 匹配度:0.47 匹配率:0.9
4 . 单特征识别结果: T66 { Mnist0 = 1.00; } 匹配条数:31/ass45 匹配度:0.45 匹配率:0.7
5 . 单特征识别结果: T94 { Mnist0 = 1.00; } 匹配条数:23/ass36 匹配度:0.47 匹配率:0.6
6 . 单特征识别结果: T70 { Mnist0 = 2.38; } 匹配条数:11/ass18 匹配度:0.44 匹配率:0.6
7 . 单特征识别结果: T68 { Mnist0 = 2.49; } 匹配条数:14/ass26 匹配度:0.41 匹配率:0.5
8 . 单特征识别结果: T69 { Mnist0 = 2.43; } 匹配条数:11/ass21 匹配度:0.42 匹配率:0.5
35075A
组特征改回独立网络模块测试之：特征演化效率问题
说明
如果它识别到的st不够覆盖全面，比如st只识别到3上半部分的2，那么它的gt识别就必然错误识别成是2。
思路
重点测试一下局部特征能否各局部覆盖全面。在无遮挡时，显出来的部分至少应该尽量都识别到。
训练项1
把局部特征识别结果可视化出来，分别训练0，小人简笔画，观察一下覆盖是否全面。
35075B
训练项2-观察下GT识别的竞争浮现情况（以及宽入窄出等相关参数调整）。
问题
如下代码段1，跑到第23个0了，健全度还很普遍的0.1x，这也太低了。
分析1
首先每次识别的少，应该让它成大批量的去充分竞争。
否决：都一百条ST识别结果了，也不少了。
分析2
再次可能GT的长度太长了，什么杂鱼ST都能进来，导致重复发生的没进来，不重复的倒是在GT里含了很多。
否决：一百条st这么宽入了，都对不上，如果变窄就更对不上了。
疑问
识别GT时，st必须完全一致才算对的上吗？
线索
这些不一致的st有没有抽具象关系？有没有匹配度可复用？
思路
所以，把GT识别也改成自举，但不是识别ST时的切图方式，而是通过抽具象来判断是否匹配。
示例
桌角因为视角方向，视角远近，材质等有无数种桌角，但要想匹配上，就必须先在抽象上匹配上，然后再向具象找识别结果。
解读
抽象桌角即为ST识别结果，而向具象回归匹配，即向具象找识别结果。
即：GT的自举是指GT的st元素的抽象，在ST识别结果中。
主题
本表指向一个主要任务：迭代下GT识别v6。
方案1
GT识别改为自举方式，即GT每个元素分别取具象，然后与ST识别结果取交，然后根据位置符合度匹配度等来竞争。
优点：自举更能全面判断，而不依赖微观层的激活。
缺点：ST识别结果中，可能连切入点都没有，更谈不上ref到assGT之后的自举了。
结合实际分析：训练到第6个0左右，才可以识别到两三个GT结果，可见确实很缺切入点。
方案2
或者更直接些，把识别的ST结果，先取具象，再取refPorts，这样的联想assGT进行识别。
优点：切入点绝对充足。
缺点1：这么多切入点，都要取refPorts，性能是不是太卡了？
结合实际分析：无论是取conPorts，还是refPorts，都可以仅取前20%，所以性能问题，倒也有些可控。
缺点2：但这种可控，又会减少切入点，导致同一个GT的100个ST，可能有20个在前20%，别的在20%之后的，有也匹配不上了。
方案3
方案1+方案2，通过st识别结果取conPorts再取refPorts，然后取到assGT后进行自举。
优点：不缺切入点，且自举可全面判断。
缺点：这么多切入点性能可能不佳。
结果实际分析：取前20%的conPorts和refPorts控制好性能，再通过自举覆盖所有GT的100个ST元素全面可判断。
抉择
由上可见，方案3涵盖方案1和2的优点，又可以解决掉性能问题的缺点，暂选定方案3。
结果
根据以上方案，迭代了组特征识别V6和类比V6算法 T。
35075B-代码段1：Input: Mnist0_23 组特征识别结果如下：
组特征识别结果: T5703 { Mnist0 = 10.24; } ProtoGT长:24 符合度:1.0 健全度:1.00(1/1) 局部综合匹配度:0.52
组特征识别结果: T5855 { Mnist0 = 4.47; } ProtoGT长:24 符合度:1.0 健全度:0.50(1/2) 局部综合匹配度:0.50
组特征识别结果: T5665 { Mnist0 = 5.50; } ProtoGT长:24 符合度:1.0 健全度:0.25(1/4) 局部综合匹配度:0.48
组特征识别结果: T5700 { Mnist0 = 2.78; } ProtoGT长:24 符合度:1.0 健全度:0.17(2/12) 局部综合匹配度:0.53
组特征识别结果: T5803 { Mnist0 = 1.90; } ProtoGT长:24 符合度:1.0 健全度:0.06(1/17) 局部综合匹配度:0.56
组特征识别结果: T5903 { Mnist0 = 1.24; } ProtoGT长:24 符合度:0.5 健全度:0.12(2/17) 局部综合匹配度:0.53
35076
回测BUG之：GT识别结果总是只有0的下半部分
示图
说明
如上图，为什么训练这么多0后，GT识别结果总是只有0的下半部分？
思路
把这些GT识别到的itemST打出来看看，确定是只有下半部分吗？
分析：图中G464很明显只识别到了下半部分，且这种情况在识别结果中是大部分情况。
所以：不用把itemST打出来，也知道它只识别到了下半部分。
思路2
调试下单特征识别，为什么只识别到下半部分？
答：经查，刚开始识别的有上半部分，也有下半部分，但随着训练的推进（五六个0后），慢慢就都剩下下半部分了。
调试1
实测发现，因为手写0的下半部分更有规律，顶上是起手部分，所以很可能是这个导致了absST越来越趋向于0下半部分。
方案1、先跑跑别的，比如手写1，2这些，或者简笔小人，看有没有同样的问题。
调试2
单特征有没有强者恒强，弱者无出头之日的情况？
方案2、考虑让ST识别结果只保留最具象层，这样的话，它不会抽象再抽象，导致越来越脱离实际，只激活最抽象的那些ST特征了。
分析3
说白了，其实是过度抽象的问题，ST识别中只有0的下半部分，却没有别的部分。
回顾1：参考34092-方案3：就由SP稳定性来表达其是否过度抽象，不要搞那种SP反过来影响识别的事，那太复杂了。
回顾2：参考34175-公式3：显著度 = 当前itemAbsTs的总抽象强度和 / assT.absPortPorts总强度和。
方案3、加上ST识别结果的显著度计算竞争，公式如上回顾2。
TODO1：ST识别竞争中，用bestGVs.count/assST.count显著度防止过度具象，然后用bestGVs.count匹配数防止过度抽象（二者动态平衡竞争）T。
分析4
0的下半部分很稳定，上半部分却不那么稳定，但上半部分也不可或缺，但上下部分都在ST识别中一起竞争。
问题：这样必然导致上半部分慢慢被淘汰，但它又不应该被完全淘汰。
思路：要不把下半部分防重，即同样下半部分，只保留一个ST识别结果（只保留一个也不太好，以后用的时候，它没有备用，取交集取不到导致识别不了GT了）。
所以：同一个区域，要保留多个结果，但多个区域间，不能直面竞争，即防止最后所有结果中，全是0的下半部分的情况。
方案4、要不就分组竞争，rect不同的区域，不可以直接竞争，要分区竞争（就像各省高考卷和录取分数线不一样）。
TODO2：每个assST为范围，缩放1.3倍，与范围内所有assST进行竞争，并把最好的几条打分，最后综合得分高的留下来 T。
优点：这么做的好处是：每个区域都充分竞争，然后最终每个区域内最好的都有机会，最终综合竞争优胜保留下来。
TODO2.1: 问：如果范围内只有自己一条是不是就是最优了？答：那它自己就是当前区域内的第一名 T。
TODO2.2: 为了分区域竞争后，不受原getSTMatch分数影响，竞争后的得分，应该用名次来（第一名最好）T。
TODO2.3: 如果密度高的地方，比较了十次，低的地方只对比了3次，那么10次的总分必然高，所以应取平均分（名次分/考试数）T。
抉择
这个易调代码，易复现，但不易分析具体怎么调才能好：所以可以边测边试，实测怎么调会更好。
实践
方案3的TODO1和方案4的TODO2，都要进行实践，TODO1防止过度抽象或过度具象，TODO2防止单区太牛逼把别的区卷死。
结果
方案3和方案4的TODO1，TODO2，TODO2.1&2.2&2.3全实践了 T。
回测
经回测：看起来0的左上，上，下，各部位ST识别结果都有了 T。
n35p08 测试独立模块的组特征 & 测特征演化竞争浮现 CreateTime 2025.10.22
35081
上面0的识别没问题了，再测下2和3，因为前面当时2和3会识别混乱来着
问题
测得2很多张后，GT识别条数还是0，转下表查修。
35082
查下：训练手写2，第10张了，还是总GT识别条数为0。
调试
经查GT识别时absST.conPorts往往只有一条，查下抽象没对撞上？只有多个conST抽象到同一个absST时，才能取到多条。
分析1
分析下，如果这里就是很难快速对撞上，总得先让它能识别到GT吧？
方案1
提升单特征的识别结果数，现在是30条（经实测改成100条后，无效）。
分析2
所有conST对撞（取交）不上：即conST没重复过，只有这一条。
分析3
所有assST都对撞（取交）不上：即assST也都是conST而不是assST，它也没被GT引用过（为了方便调试，可以把抽象次数absLevel打出来）。
思路1
说白了，这个问题的根本，在于快速的st抽象，只要st可以快速抽象，它就能更快构建和识别到可以取交对撞上的gt结果。
思路2
st快速抽象了，但st识别结果也得快速识别抽象结果（即st.count数中等稳定的）。
调试
经查日志，训练到第10个2的时候，ST识别结果的匹配数还是近40条，这么高难怪取交对撞不上。
0. 单特征识别结果:T405{Mnist2 = 1.00;} 匹配度:0.63 匹配数:37/37 匹配率:1.0 排名因子:0.00
1. 单特征识别结果:T290{Mnist2 = 2.41;} 匹配度:0.49 匹配数:37/38 匹配率:1.0 排名因子:1.00
2. 单特征识别结果:T290{Mnist2 = 2.41;} 匹配度:0.48 匹配数:37/38 匹配率:1.0 排名因子:2.00
3. 单特征识别结果:T73{Mnist2 = 1.00;} 匹配度:0.49 匹配数:37/39 匹配率:0.9 排名因子:3.00
思路3
从上日志可见，st识别结果果然太具象了，查下前段时间改的分区竞争排名因子，该问题是其副作用来的。
> 经核实：确实是因为分区竞争，导致它稳定性没那么强竞争力了（即多样性影响到了稳定性）。
思路4
分析下，分区竞争对稳定性竞争因子的削弱影响有多大，怎么重新恢复其作用（应该多样性评分，只做为其中一个竞争因子，而别的几个竞争因子，看下应该继续起作用才行）。
方案2
把分区竞争里的基于STMatch竞争改为matchValue，然后把防止过度抽具象的两个因子matchAssRatio * bestGVs.count放到与rankScore平级进行assSTs竞争。
> 这个比较麻烦，毕竟排名也是未归1化后的值，即使先计算rankScore，再与防止抽具象进行乘积竞争，也容易导致问题（转方案4，先归1化，再乘积竞争）。
方案3
把STMatch中的bestGVs.count去掉试下（因为这个是防止过度抽象的，现在的问题是不够抽象，等确实过度抽象时，再来考虑过度抽象的问题）。
> 经尝试：按方案3修改后，对此问题有效（但过度抽象问题肯定也是需要考虑的，转方案4，找一个避免bestGVs.count值太大的影响，又能用上bestGVs.count的方案。
方案4
无论任何竞争因子必须归一化之后，再做为竞争，不可直接将排名rankScore，bestGVs.count等这些，直接用于竞争 T。
TODO1: 把1、区域匹配度（匹配度区域均衡排名后总得分进行归一化）2、防过具象（匹配率）3、防过抽象（把bestGVs.count归一化）T。
TODO2: 然后把以上归一化后的值，用于st识别结果竞争 T。
TODO3: 增加一下st识别结果的竞争，把保留改成50%改成30% T。
结果
方案1无效，方案4实践完成。
35083
回测上表中手写2第10张识别GT条数还是0条问题。
回测1
st识别结果竞争，日志看起来很正常 T。
回测2
看下st识别结果的可视化，多样性有没问题（看下是不是都是单调的: 0的某个部位）。
> 看起来st结果都比较全的显示出来了整个2，看不出来是否影响到了多样性，下面测下是不是st识别结果还是太具象了。
回测3
测下还有没过度具象的问题（上面过度具象时bestGVs.count有37条），看下现在st识别结果有多少匹配数。
0. 单特征识别结果:T300{Mnist2 = 4.43;} 区匹配度:1.0 防过具象:0.9(25/27) 防过抽象:0.7 = 综合:0.65
1. 单特征识别结果:T169{Mnist2 = 5.95;} 区匹配度:0.8 防过具象:0.9(28/30) 防过抽象:0.8 = 综合:0.62
2. 单特征识别结果:T305{Mnist2 = 3.41;} 区匹配度:0.9 防过具象:0.9(27/31) 防过抽象:0.8 = 综合:0.62
分析：从以上日志可见，有26条左右，还是有点高，感觉26条，还是很难识别到GT结果，下面继续测下。
回测4
回测手写2的GT识别结果，看会不会慢天识别不到结果。
经测：确实还是识别不到GT结果，看来26的长度还是太具象了，得再尽量向抽象走走，下面分析下这个。
线索：现在的做法是优先具象（即准确里越具象越好，但这会导致26左右长的st就是最准的具象，它还是太具象很难识别到GT结果）。
思路：可以加个竞争因子，使之优先尽量抽象，方案如下：
方案1
加个absLevel，使抽象程度高就更好。
> 此方案执行起来很简单，在类比时+1即可 T。
方案2
加上索引强度，sum(强度)更强就更好。
> refPorts的强度不太好收集，因为特征是自举识别的，不靠ref（如果根据content_ps再取ref又太耗能了，并且现在refPort也没存strong现在）。
> conPorts倒是可以取到sum(conPort.strong) T。
抉择
方案1和2看起来都可以，并且实践起来都不难，实测pk下效果。
结果
无论是方案1还是方案2，都会导致结果bestGVs.count=6左右，这些小小局部，组成的protoGT也并不全面。
分析：看起来，过于具象或过于抽象的问题，还是想简单了。
追加
继续边测边分析用哪些来搞st识别竞争：absLevelRatio 和 conPortStrongRatio 替代现在的防过具象过抽象竞争因子，试一下呢？
结果
最后用obj.matchValue * self.absLevelRatio * self.conPortStrongRatio来做分区竞争，然后st竞争仅用areaRankRatio来进行。
回测
0. 单特征识别结果:T290{Mnist2 = 3.43;} (18/18) 匹配度:0.45 防抽:0.33 防具:0.67 = 区域竞争力:1.00(52.89)
1. 单特征识别结果:T291{Mnist2 = 2.43;} (23/23) 匹配度:0.41 防抽:0.67 防具:0.33 = 区域竞争力:0.90(47.56)
2. 单特征识别结果:T276{Mnist2 = 5.87;} (9/9) 匹配度:0.43 防抽:0.33 防具:1.00 = 区域竞争力:0.83(44.00)
3. 单特征识别结果:T272{Mnist2 = 2.38;} (20/21) 匹配度:0.42 防抽:0.67 防具:0.33 = 区域竞争力:0.83(43.89)
4. 单特征识别结果:T292{Mnist2 = 3.53;} (21/21) 匹配度:0.52 防抽:0.33 防具:0.67 = 区域竞争力:0.82(43.22)
5. 单特征识别结果:T254{Mnist2 = 2.45;} (9/11) 匹配度:0.43 防抽:0.67 防具:0.33 = 区域竞争力:0.81(43.00)
总结
1、现在st识别结果的匹配数有长的也有短的，有全一些的也有短一些的。
2、最终拼接成的protoGT是全面的。
3、能识别到assGT了，只是条数不很多（这个后面再查下）。
35084
查上表末手写2第10张识别GT条数还是只有少数几条问题。
分析
1. 经以上分析，本质上是：st太多，用于构建gt的st也没覆盖多少，识别30到100条assST都很可能无法ref到几条assGT来。
2. 还有个问题是越抽象的st它越能ref到assGT，但太抽象的st又缺少有效意义，甚至只是很小一段曲线而已，太泛了。
3. 难道我们只能通过增加assST的数量来解决此问题吗？（转方案1，看起来这方案只是量变，治标不治本）。
4. 或者提前知道哪些assST最后能ref到assGT，比如assST的refPorts条数做为st识别的竞争因子（转方案2）。
5. 或者像fo的SP统计一样，把assST最终能识别成功assGT时计个数，在st识别竞争时就提前筛出最终更能识别到assGT的assST结果（转方案3）。
方案1
st识别结果调多些试下。
> 经实测无效，改成100条也只是多了一半条，结果还是0到3条最多，这太少了 失败 T。
方案2
st.refPorts条数做为一个竞争力（这个很耗能，因为我们现在是没实时更新refPort.strong的）。
分析：原来的st到gt之间，有些st构建过gt，有些没有。
疑问：现在的gt识别算法，是先根据assST抽象后的absST取conPorts，然后再根据这些从refPorts求assGT解。
那么：我们在st识别时，即使assST的refPorts多，也不表示它的abs.con也refPorts多。
所以：用st.refPorts条数直接做为一个竞争力，这个是不可行的 失败 T。
方案3
识别GT成功时，加一个成功计数也可以，即哪个assST最后能识别到assGT直接统计一个成功计数值。
分析：这个方案可以先试下，看起来可以有效避免。
分析：每个st的抽象都有gt指向，至少它已经被用于构建protoGT了。
线索：先查下，这个refGT是否运行的正常，再来考虑是否做gt成功计数值的事。
调试：经查assST经常抽象后的absST还是assST自身。
问题1、所以应该是st类比算法不够强烈，导致当前assST的抽象就不够，导致它在当前gt识别算法中无法ass到GT。
>>> 分析：几乎是assST抽象后还是assST自己，即没有抽象，明天先查下类比算法中，它是不是往往抽象后还是自己，为什么没剔除掉gvItem。
>>> 调试：把类比调成竞争力更强后，每次absST都不一样了，但取conPorts还是只有assST一条，这说明这个absST只被抽象到这么一次。
>>> 调试：经测，即使增强assST的类比抽象强度，它仍然无法ref到GT（转下问题2）。
问题2、根本原因还是GT识别时，先取abs再取con，而conPorts往往只有一条，这一个assST最多也就能联想到一条assGT。
>>> 分析：absST只有6条左右时，才会有被多个assST共同abs指向之，而在10左右以上时，几乎都是只被抽象了一次的（还未达到被重复多次的训练量）。
>>> 那么：难道只能继续训练，不断训练，使之更多的抽具象树繁茂起来吗？还是？（转下问题3）
问题3、GT识别很难对撞上，是现在规则的推力不足，还是结果的拉力不足？
>>> 1、推力：现在由absST构建GT，对撞不上太正常了（st抽象要对撞absST，再然后识别assST时还得能再碰着absST，再然后才是识别GT时每一个元素都要返过来跟assST对接上，这很难）。
>>> 2、拉力：由结果拉，即建sp反向拉去也很难，需要取abs再取con识别GT，这个过程有好几步，很难保证拉动有效。
>>> 3、结果：要不返过来想想，GT构建是不是用assST？然后识别时是不是仅用assST来refGT，而不是先abs再con（转总结）。
总结
怎么看都是先取abs再con的方式太复杂了，导致识别不顺畅（转n35p09）。
CreateTime 2025.11.05
在上节末，发现原来的GT识别v6算法中，先取absPorts，再取conPorts，再refGT的方式，太繁琐了，导致识别不畅，这么一绕最后都ref不到几个GT了。所以本节还是参考以往的识别算法，直接用refGT，不去先abs再con那么绕了。
35091
TODOLIST：把先abs再con再ref.GT改成直接assST.ref.GT识别。
示例
试想一个人眼镜像亦飞，眼距像大刘，鼻子像成荣，嘴巴像姚敌，笑容像张飞，那么他还是他自己的样子吗？protoST还是本来的样子，但protoGT是即像又像的混合体，混合体像眼睛嘴巴有重影很正常，如果不经过抽象我们很难一眼记住一个毫无特征的陌生人脸。
TODO1
简化1、组成protoGT的也应该调整成assST，而不是absST T。
疑问：可是assST中只有一部分(bestGVs)匹配上了，要整个assST用于构建gt吗？
反证：拆开肯定不可行，因为只拆bestGVs的话，它都不是一个局部特征。
解答：根据以上示例有混合体的重影是没问题的，再加上反证也说明了不能单纯用bestGVs来构建，这两点都支持：就用整个assST构建protoGT。
TODO2
简化2、直接由assST取ref.GT T。
细节：整个计算元素在assGT中的位置计算都要简化很多。
回测
以上实践后，回测下手写2的识别，重点观察下，GT识别的演化浮现过程。
35092
回测BUG之：GT能识别到5条左右，但防重卡的太死了，一共就没几条进入最终识别流程
调试
GT识别中的refPorts此处只有20%有值跑到了最后识别GT匹配流程。
日志：refPorts条数：5 防重后：2 防PROTO后：1 防不应期后：1。
分析：refPorts中有很多重复的。
调试：同一个item根据index和rect不同，确实可能重复出现在gt中。
思路1：要根据这个调整下这里gt识别的防重规则吗？思考下（下面会逐帧从matchModels中筛选，所以这里防重后面也会全给找回来参与算法），
思路2：后面全找回来，和这里切入点assIndex不同，不是一回事，全找回来是为了竞争best，而这里是为了根据切入点不同各自跑GT识别。
分析
现在对assGT在防重，但assGT中可能有几个上元素是重复的（不同局部但很相似的assST）。
原因
而这些重复元素如果只取了一个切入点（第一个），可能导致识别结果变少。
方案
防重不仅对assGT也要对切入点assIndex。
TODO
切入点assIndex要用rect来计算，用assT.p不行（因为有重复元素，会全取成第一个匹配的）T。
回测
无明显效果：还是只有几条GT识别结果。
35093
GT识别数少的问题总结
原因
经测，仅仅是因为GT太少了，训练一次视觉生成一个protoGT，第10个手写2时，一共才10个protoGT，再加上前面没识别几个结果，构建的absGT也没几个。
结果
把手写0，1，2分别训练10个，发现很容易识别到30条assGT结果了。
35094
测GT识别的竞争浮现
计划1
观察训练GT的竞争浮现，看这些竞争因子能不能让它快速竞争出越来越准确的absGT。
0. 组特征识别结果:T107{Mnist2 = 2.20;} ProtoGT长:9 符合度:1.00 健全度:0.60(3/5)
1. 组特征识别结果:T143{Mnist2 = 1.67;} ProtoGT长:9 符合度:0.50 健全度:0.67(6/9)
基础视觉库
因为最开始时没有视觉基础，导致GT总共也没多少条，所以先对0-9各喂一两张，让它有基础视觉知识库，然后再基于此，进行测试训练。
计划2
必须深入到数据细节中测试，以此观察ST和GT的演化浮现。
TODO1
GT竞争因子中有没归一化的，改支持归一化下 T。
计划3
再简单些：先多训练几个0，比如20张，观察其识别演化过程 T。
> 看起来训练多个0时，GT类比生效速度还可以，第4张0的时候，已经可以识别并类比到比较明确显著的0。
计划4
继续跑观察ST和GT的识别和类比的竞争浮现过程。
> 经训练测得两个问题，转下表继续。
35095
训练0观察ST的抽象和竞争浮现，测得以下问题。
问题1
训练到第11个0时，虽然大多ST结果都是9/10,5/5,11/12这种，但也有一条10/47的，这种为什么没被竞争掉呢。
日志：9. 单特征识别结果:T156 (10/47) 匹配度:0.47 防抽:1.00 防具:0.00 = 区域竞争力:0.92(2054/30=68)
问题2
它生成的protoGT也如下图所示不成形，按道理来说，喂11个0后ST够抽象了，ST识别结果也够多样了，应该能拼成比较像0的ProtoGT才对。
示图：第11个0时拼成的ProtoGT：
调试1
可以把问题1中的那些匹配度低的在可视化中过滤掉试下，看是不是问题1导致了问题2。
> 无效，过滤掉后，仍然不成形的情况（比如ST中0的下半部分，在ProtoGT中显示到了顶部）。
调试2
训练0到第5张时，就可以复现不成形问题了，并且很明显，0的下半部分显示到了上面，而顶半部分反而显示到了下面，具体情况如下：
1
训练到Mnist0 5时，0的下半部分，打出bestGVsAtProtoTRect是<0,0,21,18>这个显然不对，因为它的xy肯定不是0,0。
> 日志：单特征识别结果:T525 (15/15) 匹配度:0.31 防抽:0.67 防具:0.33 = 区域竞争力:0.51(57/5=11)
2
而另一个ST是0的顶半部分，却坐标在中下面。日志如下：
> 日志：单特征识别结果:T494 (12/14) 匹配度:0.34 防抽:0.33 防具:0.67 = 区域竞争力:0.56(248/20=12)
3
最后构建ProtoGT时，它的元素收集的范围rect依然是错误的，日志如下：
> assST525 bestGVsAtProtoTRect: assSTAtProtoGT:
> assST494 bestGVsAtProtoTRect: assSTAtProtoGT:
4
所以：显然从assST识别开始，其bestGVsAtProtoTRect计算就有错误。
5
调试示图：
说明
1、看起来上图没啥问题，ST33的右下角是个上斜线，正好匹配到了Mnist0_4的左上角的上斜线。
2、所以rect转换后，ST33显示在了ProtoGT的左上角。
6
问题：那ProtoGT155中的ST33和下面那另外半个0，之间也没拼到一块儿去，俩处半个0的中间还有条缝。
分析1：GT识别的位置符合度，现在是以平均XYWH比例为准的，是否应该改为以ProtoT原图为准，这样就不会割裂了。
分析2：现在ST识别后，计算出的rect已经在割裂了，识别的这些assST结果之间，真的可以互相兼容吗？
分析3：一个0的外圈像豆子，内圈像南瓜，此时用豆子和南瓜拼成ProtoGT后，二者凭什么不割裂，割裂才是对的。
7
依上分析可得，这里不成形是正常现象，只是还不够抽象，归纳的程度还不够罢了。
总结
在35091-TODO1中，把构建protoGT的元素由absST改成assST了，导致其割裂更容易显现出来，这是很正常的。
方案1
依上总结，我们多训练几个0试下，看能不能尽快过度到更显著的局部特征，构建出不那么割裂的ProtoGT来。
> 总感觉这里还是不太对，如下：
日志1
单特征识别结果:T468 (7/47) 匹配度:0.46 防抽:1.00 防具:0.00 = 区域竞争力:0.52(290/25=12)
日志2
item在ProtoGT中范围(ST468)：BestGVs = AssST =
说明
上面日志中，BestGVs明明是0的顶部拱形，但它为什么Y会是16，相当于说：虽然这是0的顶部拱形，但却匹配到了Proto中的最底部的锅形。
分析
看起来，T468也有0.52的区域竞争力，但似乎导致ProtoGT不成形的assST都是末尾几条，看来这几个局部特征确实识别匹配度就不太行。
方案2
还是再多跑跑训练，看st识别的匹配度能不能提升上来。
缺点：方案1明显的治标不治本，其实0.52的区域竞争力得分也不低了，在前30%名了。
线索
感觉这些区域竞争力还不错的assST结果，其防具或防抽，总是有0分的情况。
方案3
看来这些防具防抽为0的，得打压一下，不然总是出现这些明明很不准确，但这些很烂的，在某个平均很烂的区域内，其区域竞争力仍排在前面。
优点：这个方式，可以打压很防具=0，或防抽=0的情况，还不影响别的区域竞争逻辑。
抉择
综上，方案1和方案2都没找着核心问题，方案3还行，可以先实践跑跑试下 转下表。
35096
方案3实践规划：在ST识别中，对防抽具=0的降权
回顾
ST分区均衡竞争算法：现代码为匹配度防抽 防具，三者都用于竞争，竞争后的排名则用于打分（本表的降权，意思就是对此打分降权）。
说明：即第一步是竞争，第二步是打分（现代码打分 = 排名）。
实践：实践有两种方案，如下：3A & 3B。
方案3A
直接改第二步打分：对防抽具低值的进行打分降权 T。
TODO3.1
可以把这些区域内平均很烂的，得分打压一下，比如乘0.2（即只给其打两成分）T。
TODO3.2
但只打压防抽具=0的么？如果=0.1呢？所以还是按乘积来打压比较好（越接近0，越只出两成权重，越接近1，越出满权重）T。
TODO3.3
或者只对防抽具>=0 && <0.3的降权重，别的不降权重T。
方案3B
把第一步改为仅按匹配度竞争（去掉防抽和防具），然后第二步打分时，防抽防具则单纯用做权重（即打分 = 名次 x 防抽 x 防具）。
抉择
先尝试方案3A，如果不行再改为方案3B试下。
实践
实践方案3A后，过抽过度的ST识别结果成功被过滤掉了（如下，最后两条assST的防抽防具都不是0）。
28. 单特征识别结果:T188 (10/11) 匹配度:0.42 防抽:0.33 防具:0.67 = 区域竞争力:0.59 (2973/64=46)
29. 单特征识别结果:T187 (11/12) 匹配度:0.42 防抽:0.33 防具:0.67 = 区域竞争力:0.59 (2875/62=46)
回测
结果
如上图，实践方案3A后，第4个时assST识别竞争分全是0，看来还没冷启好，再跑到第6个0时，ProtoGT还算成形（上图即是第6个）。
CreateTime 2025.11.26
在上节简化了GT识别的ref通路，并且修复了ProtoGT不成形问题，本节回归继续测试往时训练项。
35101
回归往时训练项
训练项
训练手写2和3，看能不能准确识别二者的区别，并观察下GT识别的竞争浮现情况。
训练
先训练8个2，再训练几个3，取识别结果总结日志如下：
日志：组特征识别结果总结：(Mnist3=0.93 ,Mnist2=0.07 )
问题
如上日志，明明识别结果可视化全是2，却打出总结显示93%是3。
分析
看起来是很多2的GT上，打上了3的标签，导致明明不是，却打了很多标签认为它就是3。
结果
先不论打标签的问题，下表发现了更大的问题，先修下表 暂停，先修下表问题。
35102
训练3多张后，发现ProtoGT仍不成形
分析
用assST构建ProtoGT后，发现总是太具象或不成形问题。
回顾
而当时用absST就没这个问题，在35091-简化GT识别ref通路时才改为由assST构建ProtoGT的。
方案1
按前面的想法，是在assST随着训练，变的越来越抽象时，自然可以构建出成形的ProtoGT。
问题：其实识别bestGVs的时候，已经知道ProtoGT该用哪些gvs来构建了，何必非要等assST变的越来越抽象呢？有现成的却不用？
否掉：方案1肯定不可取，上行问题中：有现成更好的成果却不用，这样影响智能效率，断不可取。
方案2
可以改回由absST构建ProtoGT试下 T。
问题：用absST构建的问题前面已经遇到过了，就是单纯用assST.ref很难联想到assGT结果，导致GT识别结果数很少。
解答：以上缺点应该无碍，因为assST识别就是有防具的，它更容易识别到absST而不是conST，所以应该更能通过ref到assGT才对。
方案3
如果方案2不成，可以试下两种都保留（即用assST构建也用absST构建ProtoGT）。
分析1：即看是否有必要像Alg和Fo识别一样：把ST和GT识别的似交层分开收集，用来构建两种ProtoGT。
分析2：不用似交层分开收集，因为bestGVs本来就相当于交层，而assST就相当于似层（它不是单纯的似交层，而是哪些GV被匹配上了）。
举例
刘亦飞的眼睛毕竟只是眼睛，还是不能直接把刘亦飞挂上去（这样肯定会发生最近的ProtoGT不成形等乱套问题）。
抉择
由上可见，可以先采纳方案2，实测下，如果不成，再考虑方案3，或再制定更好的方案。
结果
方案2已实践，先这么测跑着，如果有问题，再回来看方案3。
35103
训练到第10张0后，生成ProtoGT可视化位置偏了
示图
说明
如上图，明明是0的下半部分，assST为什么在顶端显示？protoGT又为什么也在顶端显示？
结果
因为本来rect在构建absST和protoGT时，就是左上角marginLeft和marginTop置0的，当然就显示在左上角了 T。
35104 -问题 ：训练手写3时ProtoGT就不成形 （很难看出有3的形状 ），训练手写0时ProtoGT又偏移 （下半部分显示在顶端 ）。
TODOTOMORROW20251202 : 训练3到6张左右时 ，发现始终不成型 。
疑点 ：gvsAtProtoGT通过union计算应该是错误的 ，没有topLeftMargin值 。
思路 ：可以把assSTAtProto的topLeft值取出来计进去即可 。
回顾 ：看了下代码 ，bestGVAtProtoRect应该是正确的 ，是从protoDic中直接取的rect值 ，所以不会有错 。
小结 ：没查到原因 ，看起来都很正确 ，明天继续查下 。。。
疑点 ：难道单纯就是匹配度不行 ？所以还原不出来ProtoGT的样子 ？（对比下 ，0 是可以成型的 ，所以训练0和3时的匹配度区别 ，或者把别的日志也对比下 ，看能不能找出区别来 ）。
2025.12 .03 ：调试 ，结果如下 ：
经对比 ：二者确实有点区别 ，3 感觉st结果匹配度还比较低 ，但0的识别感觉更同质化 ，很多都是0的下半部分 ，并且0的GT识别结果条数也不多 ，导致GT类比也不多 ，说白了一共就没几条0的GT 。
反方 ：GT本来就是个从不成形到成形的演化过程 ，不可能刚上来就成形 ，毕竟那么多GT之间来回找规律 ，哪能一下就找稳 。
正方 ：可是ProtoGT是根据原图取坐标的匹配的 ，即使不太准确也应该成形才对 （把assST的可视化 ，加上leftTop和proto原图对齐显示 ，然后对比看下是不是同位置显示的大概一样 ？）。
经测 ：0 加了top和left可视化后 ，assST识别结果还是有下半部分显示在上面的情况 。
经测 ：3 的st识别结果坐标也不太对 ，也有各种错位的情况 。
总结一下 ：经上面调试 ：
问题1是GT识别结果总是较少 （要把竞争力调低一些试下 ，即改为末尾淘汰 ）。
问题2是assST识别结果的位置也很多偏移错误 ，rect应该还是计算有错误 ，单通过代码看不出问题 ，深入到某个assST的数据细节中查一下 ，看其偏移原因是什么 。
TODOTOMORROW20251204 : 会不会是此处防重太严格了 。
1. 切入点如果错了位 ，后面的都会错位 。
> 可以打日志验证一下切入点是不是已经错位了 ，这个大概念是会的 ，毕竟就一个GV错点位可太正常了 。
2. 如果错位的已经识别了 ，那么不错位的也没资格再进来了 。
> 可以关掉防重试一下 ，看能不能有更准确的识别进来 。
3. 调试 ：每次收集GV时 ，打出此日志 ：
NSLog (@ "识别assST%ld.%ld %@ %@ begin ==>" ,assT .pId ,beginAssIndex ,Rect2Str (lastAtAssRect ),Rect2Str (lastProtoRect ));
结果打出取0下半部分显示到顶端时的某一个assST的识别结果日志如下 ：
> 识别assST194 .6 <x0 y9 w9 h9 > <x0 y15 w7 h7 > begin ==>
> 识别assST194 .7 <x9 y9 w9 h9 > <x7 y15 w7 h7 >
> 识别assST194 .8 <x9 y12 w3 h3 > <x7 y17 w2 h2 >
> 识别assST194 .9 <x15 y12 w3 h3 > <x12 y17 w2 h2 >
> 识别assST194 .0 <x0 y0 w9 h9 > <x0 y8 w7 h7 >
> 识别assST194 .1 <x9 y0 w9 h9 > <x7 y8 w7 h7 >
> 识别assST194 .2 <x18 y0 w9 h9 > <x14 y8 w7 h7 >
> 识别assST194 .4 <x12 y6 w3 h3 > <x9 y13 w2 h2 >
如上日志中 ：ProtoRect的X最小 =0 ，但Y最小 =7 。但可视化的这一条assST扔显示在顶端了 ，这显然不对 ，明明匹配了Proto的下半部分0 ，为什么可视化到了顶端呢 ？
把jvBuModel的model内存地址打出来 ，发现unionRect计算没问题 ，这些不在顶端和最后打印的 ，不是一回事 ，应该是在中途哪里就被竞争掉了 。
经查 ：这些是在ST结果竞争中被竞争掉的 ，看起来应该有竞争问题 ，比如前20名全是0的下半部分 （且是显示在顶端的那些下半部分 ）。
所以 ：查下区域竞争算法 ，在训练多个0后 ，为什么ST识别的前20名会有同质化问题这么严重 （全是0的下半部分 ）（查ST竞争算法 ）。
TODOTOMORROW20251208 : 继续查下这里 ，训练0到第6张时 ，明明是0的下半部分 ，为什么仍是识别到顶部了 。
看能不能精准的把日志打到第6个0的第一个assST结果 ，查哪里有计算错误 ，还是itemGV的匹配度本来就不高 ，匹配错了 ？还是那个锚点计算有问题 ，本来就已在特定情况下有错位了 ？
明天继续查下 ，ST识别之初 ，为什么把第一条assST激活到的 ，是哪个rect激活到了哪块rect ，具体再追查0的下半部分 ，显示到了顶端的问题 。
TODOTOMORROW20251209 : 可是成功过不表示最准确 ，可能是错位的手写0只有30 %的匹配度 。
2025.12 .0 9 : 为了防止startX =0 ,startY =0 的识别太多 （会导致差生占位 ，优生没位置了 ，错位的差生明明错位了 ，因为startXY =0 都显示在顶端 ），改为不根据切入点防重了 。
分析1 ：说白了 ，差生先进占了位置优生就没位置了 ，所以这个防重方式肯定是不对的 。
分析2 ：dotSize和xy循环切入点时从0开始循环的 ，所以往往顶端的差生先进来 ，也所以可视化时0的下半部分被显示到了顶端 （差生的marginLeftTop都 =0 ）。
分析3 ：看来这个切入点肯定不能这么防重了 ，只能在报续识别算法中中 ，尽量搞复用 （找具体识别代码哪里可以优化 ）。
方案 ：把原来的BeginRect切入点和AssRect防重都去掉 ，因为这个切入点防重肯定是过早了 ，导致差生占位优生无位的情况 `T `。
结果 ：上述方案已实践 ，然后再看性能看着再优化 `转35105进行优化 `。
回测 ：回测跑下效果看看有没错位bug了 （经测第下标2个手写0就成形且不偏移了 ，第下标1个手写3时就已经成形了 ）。
原则 ：**本BUG原因总结 ：识别要广入窄出 ，这种切入点防重的方式 ，防的有点过度了过早了 ，导致影响到了广入 。**小结：在35104中，ProtoGT不成形和偏移错位的问题终于解决了，但性能有了很大问题，转下表优化。
CreateTime 2025.12.09
上表解决了ProtoGT不成形和偏移错位问题，主要是因为ST切入点防重太过度所致，所以本节需要紧跟着做ST识别优化。
35105
上表去掉防重，本表需优化ST自举算法（不然肯定卡死）
原则
上表bug主要是影响到了广入，而本表方向主要是解决窄出问题（即在尽可能不影响结果的情况下，加上窄出限制以优化性能）。
方案1
应该是类似区域的protoRect切入点，的同一个assST，的同一个切点入gvIndex进行防重 T。
方案2
通过竞争来实现优化吧，比如ref只激活前20% T。
问题：其实原来就是20%，不过后来又去掉了，因为新的事物将无机会激活（参考35066-方案）。
解决：新事物也可以由旧局部特征拼出来，一看微观复用性，二看旧特征的抽象程度，但肯定不能自己拼自己，不然性能肯定跪。
方案3
把一切ST识别过程可复用的复用之：protoGVIndex复用，即每次从protoDic切图，改成切图区域相似90%以上的直接复用 T。
> 方案3A：要么循环判断哪些区域匹配90%以上（计算量大些，不过准确度高）。
> 方案3B：要么直接把精度降低做KEY（比如宽高93，精度10%计为9，x=18计为2）（这个精度内的直接取这个KEY复用即可）。
> TODO3.1：先采纳3A，如果不行再3B T。
方案4
宽27像素，dotSize=1时，27x27像素全过一次？这么小的单像素，多出那么多次循环，却一个都不能复用（因为太细小，每个像素的protoRect都是不一样的）T。
> 核实下代码（现在应该也不是要到1为止，肯定到dotSize<3就停了），如果dotSize<10时，就别做切入点了。
> 经核实，现在最小切图也是9宫，9宫的切图就是可以有复用的。
方案5
起因：ST识别的stModels在训练0_3时，还没识别完就达到了5000多条，这显然太多了，也没必要识别这么多结果 T。
> 那么怎么实现即过滤掉很多，又留下的足够多样呢（只能整图上均衡调参来降低识别结果的数据量）。
> 调低rect交集防重的阈值：把阈值调低后（有三处阈值，调成了0.4，0.5，0.6），这里最多到到2000条 T。
方案6
ST识别结果中很多ST重复：比如同样是ST347就占了28% T。
> 复现：通过训练手写3到3_1时就可以复现。
> 分析：有些匹配了18个gv，有些19个，这18个和19个的gv还都是相似的。
> 思路：那么为什么要识别这么多次？直接填充一条ST347就行了，把这19个全做到最全的那一条里面就行。
> 调试：经查重复的ST其Rect也很相似，比如有一条只是前后两次的Y差2，别的都一模一样。
> TODO6.1: 判断两次st的pid一样，且whxy相近，则允许合并处理 T 转TODO6.6。
> TODO6.2: 把每个assIndex对应的gv合并复用（只保留最好的一条）T。
> TODO6.3: 以及即使不是最好的gv，也把其rect记录下来，用于防重（即每个rect只要失败过，直接判为失败）T。
> TODO6.4: 没失败过的，则可以与best二者PK一下 T。
> TODO6.5: 现代码中的bestGV是用别的方式在竞争的，看现在这个是与之融合代码，还是单独再写一块bestGV竞争代码 T 不能融合，各跑各的。
疑问：ST识别结果是切入时就判重，还是中途再判重？
分析：如果有重复，因为每index都是等比计算的，所以切入时就可以判断，但如果第二次的assST的切入点在第一次压根没发生过呢？
解答：可以直接根据切入点计算出整个assST在protoRect的总范围，然后直接对比这个总范围即可。
所以：assST1和assST2都有已知bestGVs也有未知，用已知计算出未知，然后求整个assSTAtProtoRect（assST1用bestGVs来计算，assST2用切入点来计算）。
> TODO6.6: 计算整个assSTAtProtoRect，然后对比rect相近度，匹配度>0.6)，则对两个assST进行合并 T。
35106
回测上表优化六个方案，如果性能还不行，继续优化
回测
经回测，性能好了不少，但第四张0时，还是会显然慢，需要继续优化。
方案7
protoGVIndexPool池子太大导致复用性能必然不佳（参考35105-方案3）。
方案7A: 可以限制最大长度，超过一定范围后，就不可能再能复用了。
--- 简单粗暴，切图是根据新的gv全图来回切的，不存在旧的绝对没用了，此方案否掉。
方案7B: 或对池子进行分片，通过分片每次只从可能的区域内求复用（参考35105-方案3B）。
--- 可考虑，但麻烦些，要对不同精度进行合理切片，比如宽0-5每5个x切一组，5-15的每10个x切一组。
方案7C: 直接对大池子中的xywh做下判断，如果判断不可能相交（比如newMaxY < oldMinY则不可能相交），直接continue。
--- 此方案很简单，但没有减少for循环数，可能效果不佳。
抉择: 本应先试下方案7C的性能不行，再做7B分片组，但方案8也需要这种分组策略，所以直接实践方案7C也可以。
方案8
对切图算法进行优化，比如把0-10求和成一个值，以后累加时，直接找出来复用这个值即可。
方案9
ST识别中，加载vInfoCache和dataDicCache比较慢 T。
日志：计数:3081 均耗:0.33 = 总耗:1024，ST识别切入3081次，这里加载了3081次，共耗时1秒。
说明：把这个调整到循环外执行了，只跑一次即可。
暂停
经XGDebug工具实测，发现在调用ST识别时，稀疏码识别更慢，所以先优化下稀疏码识别，再回来测ST识别性能 转下节优化。
追加
在下节把稀疏码识别优化了，然后需要继续优化方案7和方案8，转n35012继续。
CreateTime 2025.12.17
上上节末，把ST识别切入点打开了，导致上节一直在优化ST识别，但优化到上节末时，发现稀疏码识别当前更严峻，更应该先优化，本节优化之。
35107
优化稀疏码识别算法
日志
计数:3081 均耗:1.41 = 总耗:4336，总共切入了3081次，每次都进行V和GV识别，共耗时4.3秒。
方案1
V识别优化：可以把V结果按顺序切片排好（比如3%一个切片），识别V时直接取自身所在组，以及左右相邻组，共9%即可 否掉，转方案2&3 T。
优点：这样不必每次识别V时都重新排序，直接取结果，自然性能更好。
否掉：经实测：真正卡的压根不是排序，而是别的未复用（vInfo等），以及调用次数太多（3000多次）转方案2&3。
方案2
把V识别中的vInfo等改成复用（性能从4.3s优化到1.2s） T。
方案3
减少调用次数，给每次调用增强复用池，即第二次调用如果还是相近的值，则直接复用相近值的旧识别结果 T。
TODO3.1: 切入v值按精度1%来复用，即如果值域内有1000个值，每10个index下标归为一组 T。
TODO3.2: 以此类推，复用池内最多有100个条目供复用，比如index在320-330区间复用同一个识别结果 T。
回测：经测单稀疏码识别算法的性能从1.2s优化到了0.2s）。
CreateTime 2025.12.19
35121
优化方案
问题
经测ziJvItem算法因为执行1.8w次导致慢，要增加复用，减少调用次数。
回顾
在35106中，方案7和方案8就是针对这一问题的，现在继续即可（参考35106-方案7 & 方案8）。
分析
不过经过35107中对V进行切片分组，发现其实这里ST切图和取bestGV这两个优化池，其实也可以通过分组切片来比较好。如下方案：
方案1
切图防重优化：经测切图缓存池protoGVIndexPool的性能占1.5s，可以直接改成分组切片，到时候符合分组的直接用key取结果即可。
TODO1.1: 必须对protoRect分组成索引key，比如每80%比例分一个wh粒度组，然后每个粒度单元的20%偏移分一个xy偏移组 T。
TODO1.2: 求分组单元尺寸：高度和宽度都是从1到最大(maxSize)，每1.3倍分一组（如：1一组，1.3一组，1.69一组，如果w=1.65则其wIndex=3） T。
TODO1.3: 以每分组单元尺寸的20%，将XY分组（如：w单元宽1.69，则x单元宽1.69*0.2=0.338，如果x=3.4则其xIndex=10） T。
TODO1.4: 以上四个分组索引whxyIndex，构建一个4维字典，取四个key，然后一级级取出最终对应的缓存 T。
方案2
自举结果优化：对bestGVModel的防重再改进，原来用gvId_ProtoRect的Key太具体了，改成一个范围记同一个key T。
TODO2.1：类似TODO5.1生成分组切片key，然后依此对bestGVModel防重，即把protoRect分组key，依此直接取最终结果返回 T。
回测1
BestGV缓存和切图缓存池都按以上方案迭代后，经测切图复用率77%，BestGV复用率42%（因为针对每个GV计算不同，所以复用率低）。
回测2
改为v2缓存池后，经回测，次数还是多，经测数据：bestGVs复用率47%（其中isNull占18%），切图复用率77%（其中isNull占35%）。
回测3
日志：并且即使调整参数提升复用率，也提升不了多少了，回测日志如下：
参数1：1.3一个粒度层，0.20一份xy间隔时：切图池复用率：9115 / 11892 = 0.77 BestGV池复用率：8080 / 19342 = 0.42
参数2：1.5一个粒度层，0.33一份xy间隔时：切图池复用率：7667 / 9408 = 0.81 BestGV池复用率：8066 / 16758 = 0.48
参数3：1.5一个粒度层，0.50一份xy间隔时：切图池复用率：5778 / 6700 = 0.86 BestGV池复用率：7659 / 13528 = 0.57
总结
77%就是针对切图的没什么优化空间了，而42%只是针对不同assGV分别做了计算匹配度也没什么优化空间了。
结果
但这样的优化虽然有效但还远远不够，下表分析下能不能把匹配度持久化复用，比如存在AIPort中。
35122
优化方案之：继续分析空间换时间的优化方式。
说明
将匹配度持久化存到神经网络，这样更彻底的复用来优化性能。
但是
每个assST总要和protoGV比较，而protoImg总是多变的，所以实时切图不可避免（所以自举调用量并不会减少）。
方案1
唯一可做优化的点就是：在切图后的结果 与 assST.itemGV比较，这个比较结果匹配度可以存到长时网络（如AIPort中）。
方案2
可以实际调试下，计算GV匹配度的代码，哪一行慢，看哪些可以移到循环外执行。
方案3
往微观一层计算优化：计算vMatchValue与checkCurProtoRect的相似度，存成复用池，能省不少计算量。
方案4
把protoRect计算成的四维key索引Index：直接存到长时记忆中，然后以后用这个来索引激活。
被否
1、但即使存到网络，计算这一步的1.3s被优化成0了，可是自举跑了2w次，别的步骤加起来也跑了近3秒。
2、无论怎么优化一张大图，上万次调用自举，最终都会变成，一点小小的加减乘除，都要变成很耗能的事。
性能
把调试日志关掉，现在性能为识别一张手写0共耗时2.2s（已达到可接近范围，把调用数太降降，性能先这样就可以了，转下表）。
所以
长时网络存一下匹配度有效，但也不彻底，真正的问题就是：自举算法调用数太多了 转下表继续。
小结：35122的没优化，因为发现意义不大，因protoImg一直变，效果很有限，但却很麻烦，主要还是针对切入循环数优化下才对，转下表。
35123
优化方案之：减少自举算法调用次数。
思路
自举算法需要继续优化，调用几百次还差不多，几万次，什么操作都会慢死。
原则
原则是只要能识别到少数几条相对准确的结果就行，没必要保证一大堆，性能上也不允许。
方案1
因assST调用数：减少refAssST的数据量，比如不管能激活多少，只激活前50个。
方案2
因assGV调用数：相同assST的GV不重复判断best了，每一条都判断是否更好，相当于每次切后全判断一遍（只保留判断1或3次）T。
回测：把方案2实践后，自举算法从近2w次执行减到了6k左右，识别一张手写0耗时，从2.2s优化至1.7s。
追加：感觉这优化力度没啥意义，先废弃掉，先优化另外几个方案。
方案3
dotSize太小的没必要做切入点，过小的gv，指向的assST太多，但大多不准确，性价比很低。
方案4
把大算力浪费到准中之准没有意义，识别率就是准确度，没必要再用v相近度来乘出来（迪米特隔离）。
35124
测得BUG：<错误> assRect数据异常: 宽高不一致，或宽高为0
复现
手写0随便扔两张跑，就报了。
原因
经查为bestGV复用时，同一个gv在不同的assST中的assIndex下标不同，复用后有了错误越界的值，取assRect异常了。
修复
直接把bestGVs改成字典了，用assIndex做Key T。
35125
继续回测ST识别BUG
BUG1
同样是T33，并且rect也很接近，为什么没有合并？
0. 单特征识别结果:T33 (25/38) 匹配度:0.61 (182/13=14) 0x600000f022f0:RECT:<x-5 y-2 w32 h30>
1. 单特征识别结果:T33 (15/38) 匹配度:0.42 (169/13=13) 0x600000f14ea0:RECT:<x-5 y-1 w32 h27>
经查：起初时，都没那么匹配，后面才随着收集慢慢变匹配的。
比如：如下AB例子，B与A开始时并不匹配，但最终时却是很匹配的。
1. B = 0x600003a82560 已经最终为：<x-5 y-1 w32 h27>（注：B先识别的，它已经完成且有最终rect了）。
2. A = 0x600003a96be0 开始时为：<x8 y-6 w27 h27> 最终: （注：A起初时和B并不匹配，但A跑完后匹配）。
修复：写个方法，每次newSTModel新收集一条bestGV时，都检查一下是否有可合并的，进行合并处理 按此修复有效 T。
BUG2
同样T33也具备近整体的0的形状，为什么能错位到9,11这么多？
15. 单特征识别结果:T33 (20/38) 匹配度:0.63 (2/2=1) 0x600000f29ba0:RECT:<x9 y11 w17 h17>
分析：这除了左上角的斜线，别的部分都出界了，是不是切图切到isNull了，也计进去了？
实测：如图在第4张0时，有些st识别结果肯定是有错位偏移问题的:
日志：ST识别结果：匹配率:(19/30) 匹配度:0.57 atProtoRECT:<x9 y-2 w18 h18>
分析：这个<x9 y-2 w18 h18>，这里的x9肯定有问题，应该可视化不显示出0左边的黑块才对。
思路：可以把每个gv都打出来，细查下比如0的顶部的点，与protoRect哪里匹配上了。
结果：转35126进行调试制定方案和修复 转35126 T。
问题：见35125-BUG2，发现ST识别结果中，有错位偏移很多的结果。
分析：可以把这个model.assST按第一个为切入点，与protoImg进行匹配下，然后调试下，错位这么多，是怎么匹配上这么高匹配率的。
可疑：还是说，切入点够多，每个只有一点点准的都切进来了，切入点又全合并了，导致一个个不准确全被合并进来的？
可疑：还是合并时，没重新计算AtProtoRect，导致bestGVs之间，切ProtoRect时切的位置本来就互有位置：改下stModel合并方法，看这些bestGVs互相之间不兼容时怎么弄，或者查下可视化，按AtProtoRect来显示试下）。
调试：调试下再次跑自举算法的数据情况。
1. debugaaaa 111 atAss:<x0 y0 w18 h27> atProto:<x13 y0 w13 h26>
2. debugbbbb 111 atAss:<x0 y6 w18 h21> atProto:<x3 y6 w19 h22>
分析：经查，34条重跑后，还有20条能匹配上，并且位置确实都有变化，重跑后，生成的是<3,6,19,22>。
疑点1：合并确实导致了atProtoRect的兼容性问题。
疑点2：ziJvItem每次curIndex更新了，但lastProtoRect并没有更新，相当于全是用beginAssIndex来推算的，不是一个个相邻推算。
思路：这个得系统性的分析一下，像这种合并时，AtProtoRect该怎么更新一下比较好？
思路1：两个同质化较高的部门要合并，那旧的大致别动，新来的职位没重复就适配性的加入，重复就直接淘汰掉。
思路2：两个同质化较高的部门要合并，先PK一下哪个好，然后坏的往好的里面并。
思路3：两个同质化较高的部门要合并，每个职位有重复的分别两两PK，留下好的（现做法即如此，有兼容性问题）。
思路4：两个同质化较高的部门要合并，直接综合PK一个，把坏的部门全淘汰掉，留下好的。
方案1：既然都是切入点来计算的，那每个jvBuModel都记录一下切入点：判断是否可合并时，都转成切入点之后直接对比匹配60%，不必再等自举收集过程中每一步都做判断了。
细节：那合并时呢？保留哪个AtProtoRect？或者每个gvAtProtoRect都根据切入点实时推算？而只记录切入点即可。
因为：如果合并了，beginIndex和beginGV_ProtoRect一样了，那么每个itemGV_ProtoRect也都一样了，没必要再跑一遍，所以可以直接防重掉。
那么：合并时只要pk下哪个综合匹配度高，就保留认证的切入点值（因为切入时就能判断是否可合并，切入时就判断了，就不用合并了，因为一个已经完成，一个还没开始，没必要合并，直接防重即可）。
方案2：既然加了rectToKeys来切片分组，那这种反推肯定会有很多错位偏移，比如小像素的3,3和2,3别看只差了1格，但放大到27时，就能差9格。所以把每个AtProtoRect单独记录一下，不要记录在jvBuModel中（不然来回复用都错位了）。
关键：这里最大的问题就是，如果微观上差3�0%，那宏观上就会差太多，合并后，宏观上自然就错位偏移。
所以1：同一个3x3的GV中，差一格，dotSize27时就能差9，那复用哪一个？复用到第1格，第2格，第3格，最后会导致整个assST综合匹配度有很大差异。
所以2：有个方法是微观3x3这种太小的，不做切入点，因为它最耗能（微观太多切入点多循环多），但所得的效果却最差（差一丝就会导致宏观差太多）。
TODO1：把切入下标beginAssIndex和切入时beginGV_ProtoRect存到jvBuModel中 `T`。
TODO2：别的itemAssIndex对应的itemGV_ProtoRect都通过方法实时计算 `T`。
TODO3：自举算法调用时，都通过调用TODO2的方法来计算itemGV_ProtoRect `T 原代码跑的正常，不动先`。
TODO4：废弃jvBuModel合并算法，通过checkItemGV_ProtoRect()方法来判断匹配度，可合并则直接防重掉，不用重跑了 `T`。
TODO5：现在的分组切片是20%，所以dotSize<5时这种太微观的gv就不必切入识别算法了，直接用>5的来切入即可 `T`。
结果：本表最终方案1和方案2都实践了，即TODO1-TODO5 `T`。
问题回测：经测错位问题没了 `T`。
性能回测：经测ST识别速度从2-7秒，变成了0.2s左右，应该是随着本表的错位BUG，防重调的又简单又直白，直接有任何一个GV重复，则整个ST不会重新处理识别了，所以快了很多。
小结：本节性能优化到ST识别一共只需要0.2s，还修了rect数据异常、ST合并BUG、错位偏移BUG等问题，下节可以继续回去测ProtoGT不成形问题
CreateTime 2025.12.29
35131
继续往回测：跑几张手写3，发现ProtoGT仍不成形问题（参考35102）
经测
跑第2张ProtoGT的手写3就成形，后面再跑也一样成形，看来不成形问题ok了。
35132
继续往回测：训练手写2和3，看能不能准确识别二者的区别，并观察下GT识别的竞争浮现情况（参考35101）
经测
ST识别结果少，GT识别结果更少。
复现
起初分别跟4张2和3，然后各一张交替的跑，发现到第6张2和3时，才有GT识别结果 转35133。
35133
触发GT识别结果太慢问题一：查GT识别结果太少甚至几乎一直是0条的问题
问题
即使识别到，往往识别的GT结果长度只有1，需要查下为什么GT识别这么少，并且元素匹配数还常只有一个
回顾
现在是在用absST构建ProtoGT，而前天刚加大了ST抽象力度，所以几乎每次都是新生成的absST，当然就没有用来构建过GT。
线索
所以：新的absST.refPorts压根就没有GT（激活不到GT），当然就识别不到。
分析1
如果ST抽象力度太大，每次都是新absST，那肯定就很难对撞上GT，ST的抽象力度也得降降。
分析2
其实assST的识别本来就是防过抽过具的，重点是需要快速类比出稳定的抽象，让新的protoST的GV都很像，没一个能再被类比剔除掉。
分析3
只要absST能稳下来，它就必然能ref到GT，我们需要的是快速让稳定的absST真正稳定下来。
方案1
要么改成由assST来构建ProtoGT 有如下缺点，所以否掉 T。
否掉：bestGVs只是assST的一部分，所以用assST来构建ProtoGT，必然有不符合的多余GV被收集进去。
方案2
要么降一下ST类比力度。
正据：不仅能快速类比抽象，还得让真正稳定的抽象能稳下来，不然就无法识别到GT结果。
实践：经实践方案2发现无效，还是都只识别到0条GT结果。
方案3
要不直接关掉ST类比力度（在识别时已经竞争过了留下了bestGVs，类比没必要再加一层过滤了）。
实践：经实践方案3发现仍然无效，还是只能识别到0或1条GT结果。
方案4
把ST类比力度降回增强前的默认力度2.0 T。
实践：最终采用了此方案，因为抽象类比快不表示稳定也快，只要对撞不上，类比抽象力度再大也没卵用。
小结
但采纳方案4并不表示此问题修复了，还得继续测一下按正途：“实测下ST抽象的稳定节奏快慢（即训练多少张开始能比较常见的对撞上）”。
总结
转35134继续测下，ST的一次次识别竞争触发类比，直到有稳定的absST的浮现，这个过程要多久？转35134
35134
触发GT识别结果太慢问题二：实测并分析竞争浮现出稳定的absST，至少需要多少张
经测1
前13个手写3触发类比后全没对撞上，即前13轮assST类比，构建的absST全是新生成，没对撞上。
经测2
到了第14个3时，才开始对撞上absST，并因此立马就有了数个GT识别结果。
举例
小红相亲要求有10条，按各自满足哪些条目，对相亲的1000人进行分组，她至少要求符合七条，结果很少有符合条目完全一模一样的两个人。
方案1
模糊分组：182的高富帅 和 185的高富帅也差不了多少，不如就归为一组得了。
否掉：特征只有指针没有值，只有以量取contains来判断一组，不能通过182到185这种值域来判断一组。
方案2
增加样本：想办法增加ST识别结果，这样即可多触发类比抽象，提升对撞上稳定absST的效率。
方案2.1 可以rectIndex防重间隔小一些，把20%调整成10%试下，以此来增加assST识别结果数。
方案2.2 加训，各视觉物体都跑点，形成基础视觉知识后，再有新物体可直接融入其中快速达成对撞（比如形成桌角后，书角也一样复用它）。
方案3
降低要求：即ST允许识别更抽象的结果，这样就更容易对撞上。
缺点：更抽象的缺点就是过度抽像，不过稍微调整一些是可以的。
抉择
方案2和3都可以试试，其中方案2.1和方案3用于辅助治标，方案2.2用于主药治本。
TODO2.1
经测方案2.1调整为10%后，没有变化，此方案无效，本来ST就不多，防重多一些少一些，没啥影响 无效 T。
TODO3
经测方案3增加抽象竞争权重后，无效没变化，现在是先分区竞争再综合排名，前期ST就不多，即使增强抽象权重也没啥反应 无效 T。
TODO2.2
加训并观察“基础视觉知识”的形成过程（其实就是ST识别结果更容易起步就多，并且比如可以用3的上半部分，做2的上半部分用）有效 T。
结果
方案2.2有效，把手写0-9跑了两轮（每两张）后，发现再识别3时，确实可以快速识别到多条结果了，详情如下：
条数
第2步、单特征竞争后条数:10条，第4步、组特征识别条数:4条
日志
组特征识别结果总结：(Mnist3=0.47 ,Mnist5=0.26 ,Mnist8=0.15 ,Mnist0=0.06 ,Mnist4=0.06 )
总结
在0-9跑两轮基础上，分别识别手写2和3都是可以正常识别的，只是还有别的问题，转35136 & 35137解决。
35135
BUG: 为什么有时突然又识别不到ST结果
经查
在第2和4张3时，就没有ST识别结果。
结果
但后来已训练了“基础视觉知识”，此问题已经没了 参考35134-方案2.2 & TODO2.2。
35136
BUG2: 在跑过0-9两轮得到基础视觉知识后，还是偶尔GT识别结果为0条
分析
调试一下ref激活过程，看这些assGT的匹配率是多少，为什么有时GT识别会没结果。
调试
经查，如果ST识别结果匹配率全<1，此时抽象absST就可能全是新节点，而新节点当然就无法ref到assGT。
方案1
可以考虑用assST来构建ProtoGT，而不是absST。
缺点：会有非ProtoGT的局部特征被表征进去，比如会造成前期有重影问题。
优点：提升通路简单度通畅度，这样更容易识别到GT结果，也就更容易触发抽象等学习效率。
抉择：这缺点起初时更严重，更随着基础视觉识别的完善，快速的稳定抽象，会快速过度到又稳又准又快速上来。
TODO1：所以，此方案可以试一下，应该可行 经实测这样不好，原因如下 T。
经实测：发现重影问题还是严重，当输入一张图可以被各种图填充成ProtoGT时，其实就熵增的过份了。
方案2
可以考虑用absST构建ProtoGT，但用assST来ref激活和识别GT T。
优点：二者的优点都保留了，即容易ref到GT识别，又不会影响到构建时有杂项记忆，导致的重影问题。
回测
按方案2改后，跑了10张3，一直成形无重影，不过0-9全跑的时候，有重影，不过方案2应该比方案1效果要好，先保持方案2做法。
结果
并且GT也往往可以识别到了，不过有新的问题，ST类比来类比去，还有20个左右的GV，但GT类比几下就只剩下1个ST了，转35138。
35137
BUG3: 在跑过0-9两轮得到基础视觉知识后，训练手写3，发现assGT还不够抽象。
分析
再加训一下，观察absGT手写3的抽象过程及抽象程度，看能不能浮现出稳定的absGT手写3。
结果
一步一步来，先搞ST浮现，再测拼接GT，再测GT的竞争浮现（转35138-方案）。
35138
BUG4: ST类比来类比去，还有20个左右的GV，但GT类比几下就只剩下1个ST了。
如图
分析
assST几乎全是很整体的特征了，几乎个个assST都能显示出几乎全面的3出来。
思路
ST类比力度太低，导致不够抽象对撞不上，所以GT识别时往往只匹配到GT的一两个元素，所以类比只剩1条ST了。
方案
一步一步来，先解决ST不是真局部问题，再解决由各个局部拼成ProtoGT，再测这些GT的类比抽象浮现过程。
第一步：先增强ST竞争力，跑10来张3，先把各个局部特征跑成真正的局部，不能每个assST可视化后全是整体3。
第二步：这些局部在识别时能够再拼成各种ProtoGT3。
第三步：再然后再看这些GT能不能类比浮现等。
TODO1
先测ST跑成真正的局部（提升ST识别时GV自举匹配度阈值 或 ST类比时的竞争力）T。
TODO2
测下这些真局部的assST可以拼成ProtoGT 经测可以拼成ProtoGT，并且几乎是可以成形没问题的 T。
TODO3
测ProtoGT是否更容易识别到（经测assGT匹配数全是1-2条，类比后当然也只有1条左右）转35139继续查修。
总结
本表中一步步测特征识别类比这套流程，增强了ST竞争力，也有效果，但测到GT识别时遇到新的问题，转下表继续。
35139
AssGT识别结果匹配数只有1-2条问题（参考35138-TODO3）
示图
说明
如上图，assGT的元素匹配数很少（共5-7条，但只匹配到一两条）。
分析
说白了就是：GT识别时itemST元素匹配不上。
原因
1. 视觉千变万化，类似物体的稳定抽象absST也有数千种，而ST识别条数少不可能覆盖太多，所以最多就一两条能匹配上。
2. 其实第一条itemST匹配上的就是切入点，第二条itemST都是看运气好了才能匹配上。
实例
比如像熟悉人的人影，更难识别到（人影本来就更难识别到这个人的ST，所以识别到准确的GT就更别想了）。
思路
所以，还是得自举，assST.refGT只是个切入点，切入后还是得自举，当然自举方案不一定和ST的自举一样，方案如下：
方案1
延着ST抽具象进行自举：即判断与assST识别结果有没有抽具象关联，可以直接复用取其匹配度，做为自举匹配度结果。
子问题1：我们应该判断抽象还是具象关联？
实例分析：我们识别这是小明家的猫，而不是这是当时正在吃鱼并且尾巴耷拉着的小明家的猫。
子解答1：所以应该取抽象关联，即assGT.itemST必须是assST的抽象才行（即assST抽象指向assGT.item）。
子问题2：那任何assST都是最抽象object，这会不会导致过抽象呢？
子解答2：只要根据匹配度竞争即可，过抽象的匹配度太低自然被竞争淘汰掉了。
方案2
复用ST自举算法：即每个GT.itemST.itemGV分别从ProtoImgDic上切图，并以此判断整个assGT的匹配度。
抉择
方案1肯定更简单，方案2更复杂算力也大，但究竟哪个方案更好，还是得继续深入分析，或者用实测来试下效果。
TODO1
GT识别时，也写个自举算法 现代码本来就有 T。
TODO2
每个assST只要抽象指向assGT.item即有效 原来是equal现在改成mIsC了 T。
TODO3
GT识别竞争时，也加上itemMatchValue因子来参与其竞争 T。
测试
测一下改之后，能不能识别到更多条GT，并且这些GT加上匹配度后的竞争有效果。
结果
经测可以识别更多条GT了，匹配度也作用于竞争效果了，不过这只是初步ok，还得继续往深入测，转下节继续。
小结：本节主要修复了GT识别困难的问题，下表继续回测。
CreateTime 2026.01.11
本节主要继续深入回测，测整个特征识别类比的演化浮现，最好是可以达到稳定识别每个数字有高准确度。
35140
继续往回测：训练手写2和3，看能不能准确识别二者的区别，并观察下GT识别的竞争浮现情况（参考35101）
训练
先跑下基础视觉知识库：0-9各训练三张。
然后
在以上基础视觉知识库基础上识别手写1，测得以下几个BUG：
小结: 35140在测试用ST识别区分手写2和3时，测得多个BUG
35141
BUG1：ST识别结果中有些匹配数有些也太短了，才匹配2个gv，还排在第一第二名（并且防过抽竞争力0.71）。
示图
说明：如上图，第一列是ST识别结果，第三列是GT识别结果。
日志：单特征识别结果:T213(2/4) 匹配度:1.00 防抽:0.71 防具:0.25 = 区域竞争力:1.00 (143/13=11)
分析：现在防过抽是根据抽象等级来计算的，而有时从40条抽象到2条需要7次，有时只需要2次。
思路：assST的长度与absLevel并不线性正相关，ST识别的匹配数决定了构建absST的长度，可能ST只抽象了一次但长度很小。
所以：absLevel不适合做为计算“防过抽”的因素唯一，assST长度更直观可考虑替代之。
方案1：从用absLevel改为用：assST长度或bestGVs长度 来计算防过抽竞争力 经实测无效果，assST识别结果匹配数仍只有2条。
方案2：防过抽过具，直观来看应该是末尾淘汰：即把过抽过具的排除掉，然后单纯按匹配度竞争。
疑点：防过具也有类似问题，现在是用sumStrong来计算的（强度越强越好），即被抽象次数越多越好，但经调试最高的才3次。
方案3：防过具也改用别的因素来计算：比如匹配率（具象不太可能100%匹配，当然真要匹配了也算）T。
结果
方案1和3实践后，有效果，方案2还没来的及试，即使1+3已经有效果了，方案2就先不做了。
小结: 35141主要优化调整了ST的防过抽过具两个因子因子，并经测试有效。
35142
BUG2：GT识别手写1，结果里还有0，并且匹配率是17/17，并且匹配度是85%，这显然不对。
日志
组特征识别结果:T548 符合度:1.00 匹配度:0.85 防过具(健全度):1.00(17/17) 防过抽(匹配数):0.89 = 综合得分:0.756
35143
BUG3：查下那么多ST经历，为什么还能识别这么不准确，是不是广入有问题？
经查
应该还是ST竞争因子不太行，因为35141的方案1和方案3都改后，ST识别结果已经准确了不少。
结果
经回顾代码，广入没啥问题，就是单纯GV.ref激活的 T。
35144
BUG4：为什么ST结果全几乎是全屏显示，难道每个0,0,27,27都匹配度很高，实在淘汰不了它？
方案1
取消ST的区域竞争？
否掉：肯定不能取消，不然ST识别结果又全成0的上半部分了。
小结：在35141中修复了ST识别竞争因子这个关键BUG，所以先把35142-35144这三个BUG放放，趁热打铁，我们先继续测下GT识别准确度，转下节。
n35p15 提升对撞率一、特征识别不准问题 & 识别竞争的准中取具 & 识别结果的全含抽象 CreateTime 2026.01.17
上节35141修了ST识别竞争因子，本节继续测下GT识别的准确情况，最终测得识别不准确的情况，并转向：识别改为准确中越具象越好 & 识别结果的全含抽象。
35151
通过“测GT识别准确情况（参考上节末小结）”，转向本节重点之一：识别结果取全含抽象。
测试
先训练(0-9)x3基础视觉知识库，然后再扔个2，得出如下35151代码段日志。
示图
说明
如下35151代码段日志：发现扔2后，识别成2之外，还识别成了别的像8、3、0等等。
分析1
单特征识别没什么问题，本来就是局部特征，另外可视化看到最终构建的ProtoGT2是成形的，所以局部特征其实并没有问题。
分析2
那么问题就出在组特征识别，从可视化可见（第三列），2就是被识别成别的GT了（8，3等）。
怀疑1
调试一下，是否因为GT识别中的符合度太低导致的（现做法是符合度竞争，但并未限制最小阈值）。
正据：符合度太低，相当于胡乱拼凑，毕竟2和3本来就很像，如果符合度低，可以2拼成3，3拼成2，导致无法区分二者。
方案1
如果调试后发现确实是这个原因：那GT识别算法中加个过滤器，随时发现符合度太低，直接过滤掉。
1. 每收集一条bestST，就实时计算预计rect（每收集一条bestST，都根据已收集bestSTs来预计整个assGT的ProtoRect）。
2. 然后取真实ProtoGT.rect，对上条预计 与 此条实际ProtoRect，根据交集来计算符合度。
3. 任一条bestST收集时，发现符合度低于阈值，直接过滤掉。
怀疑2
根据以下35151代码段日志可见，组特征的符合度是1.0并不低，方案1猜测的原因未必准，不过也不难，可以边调试边查下真实原因。
变数
方案1只是假想（未去证实），已经测到如下调试的问题，转向方案2和方案3了，所以方案1先搁置下来。
调试
经测，很多AssST本身匹配率就低，只有匹配上的bestGVs是很准确的，没匹配上的那些gv都是不准确的。
比如：2识别到AssST8，只有顶部那一点是匹配上的bestGVs。
思路：而现在是在用assST去refGT，这就会导致assST本来就不准（只有bestGVs才是准确的），还用它来refGT，当然就更不准。
结果：用不准的AssST去refGT，得到的assGT也是不准确的，所以据此分析以下两个方案：
白话：如果鞋张嘴像刘一飞仰面，就用刘一飞去refGT，结果肯定只有刘一飞，是不可能识别到准确的鞋的。
方案2
ref后竞争时更准的更有竞争力：用ST匹配率参与assGT竞争，用竞争来打压那些匹配率低的assST.refGT。
否掉：此方案本末倒置，如果refGT时就有问题，你再怎么竞争，也只是在错误里找正确，不可能找的着。
方案3
ref时就修的更准些：别用assST来refGT，而是用类似bestGVs的那些absST来refGT（从抽象中根据全含，取有效抽象）。
抉择
方案3更符合当前问题的解，暂采用此方案来实践如下：
TODO3.1
需要从abs找出与bestGVs全含部分的absST（取做validAbsST），然后再用这些来refGT T。
TODO3.2
GT识别自举算法中的mIsC，也会导致不准确，也改由validAbsST.contains来判断 T。
比如：识别2时，自举对应的某一条assST是8，而assGT.itemST也是70%的8，此时用mIsC成立，但其实它并不是2（导致了不准确），而validAbsST是筛选出了符合2的局部特征的部分，它必然是2的局部是准确的。
结果
实践以上改动后，回测训练(0-9)x3轮，然后扔手写1识别如下图：
示图
说明
以上回测：在基础视觉知识图后，扔个手写1，虽然也会有AssGT0（前列），但真正匹配上的部分就是竖着的1轨迹（后列）
总结
说明确实修复是有效的（前进了一小步，不会再用1识别到0，这种特别明显的不准确）。
追加
本表最重要的改动是：从识别结果中取有效抽象（用全含判断），这些有效抽象全算做识别结果。
** 35151代码段日志**
0 . 单特征识别结果: T80 (41/41) 匹配度:1.00 匹配数防抽:1.00 匹配率防具:1.00 = 区域竞争力:1.00 (475/19=25) bestGVs_Proto:<x0 y0 w27 h27 >
1 . 单特征识别结果: T201 (13/32) 匹配度:0.82 匹配数防抽:0.32 匹配率防具:0.41 = 区域竞争力:0.88 (418/19=22) bestGVs_Proto:<x0 y0 w27 h27 >
2 . 单特征识别结果: T699 (15/33) 匹配度:0.79 匹配数防抽:0.37 匹配率防具:0.45 = 区域竞争力:0.80 (380/19=20) bestGVs_Proto:<x0 y0 w27 h27 >
3 . 单特征识别结果: T103 (9/9) 匹配度:1.00 匹配数防抽:0.22 匹配率防具:1.00 = 区域竞争力:0.79 (375/19=20) bestGVs_Proto:<x0 y0 w27 h27 >
4 . 单特征识别结果: T502 (15/45) 匹配度:0.78 匹配数防抽:0.37 匹配率防具:0.33 = 区域竞争力:0.72 (342/19=18) bestGVs_Proto:<x0 y0 w27 h27 >
5 . 单特征识别结果: T105 (13/43) 匹配度:0.77 匹配数防抽:0.32 匹配率防具:0.30 = 区域竞争力:0.68 (323/19=17) bestGVs_Proto:<x0 y0 w27 h27 >
6 . ...
单特征识别结果总结：(Mnist2=0.23 ,Mnist8=0.20 ,Mnist3=0.15 ,Mnist5=0.10 ,Mnist7=0.10 ,Mnist9=0.08 ,Mnist0=0.07 ,Mnist1=0.04 ,Mnist6=0.03 ,Mnist4=0.02 )
0 . 组特征识别结果: T679 符合度:1.00 匹配度:0.79 防过具(健全度):1.00(18/18) 防过抽(匹配数):1.00 = 综合得分:0.789
1 . 组特征识别结果: T715 符合度:1.00 匹配度:0.79 防过具(健全度):1.00(15/15) 防过抽(匹配数):0.83 = 综合得分:0.660
2 . 组特征识别结果: T486 符合度:1.00 匹配度:0.83 防过具(健全度):1.00(12/12) 防过抽(匹配数):0.67 = 综合得分:0.556
3 . 组特征识别结果: T680 符合度:1.00 匹配度:0.77 防过具(健全度):0.93(13/14) 防过抽(匹配数):0.72 = 综合得分:0.515
4 . 组特征识别结果: T681 符合度:1.00 匹配度:0.84 防过具(健全度):1.00(11/11) 防过抽(匹配数):0.61 = 综合得分:0.514
5 . ...
组特征识别结果总结：(Mnist4=0.18 ,Mnist1=0.15 ,Mnist8=0.15 ,Mnist9=0.15 ,Mnist2=0.14 ,Mnist6=0.10 ,Mnist3=0.06 ,Mnist0=0.06 ,Mnist7=0.01 ,Mnist5=0.00 )小结：35151中，GT识别准确性问题解决了（通过取有效抽象来索引和判自举匹配），但也测得新的问题，下表查修。
35152
以特征识别结果太轮廓的问题：分析全含抽象后续 及 废弃防过具。
复现
在训练(0-9)x3轮的基础视觉知识库基础上，扔手写1，结果如下图：
示图
说明
如上图，识别手写1的AssGT，匹配到3条ST，但这3条都是过抽象的，即没什么实质内容。
分析
1、即GT识别结果中的ST过抽象。
2、其实3条ST还好不算太短，但每个ST都过抽象，这个得查一下。
线索
上表刚改了用“有效抽象”来索引，有可能是这个导致的，因为有效抽象极可能过抽象。
疑点
但也有可能是竞争有问题导致的，过抽象的ST匹配度应该也很低，为什么还能竞争到前面呢？
调试
assST中，有些有明确特征点，有些其实就是一个过于抽象的图像背景（比如9和7匹配时，就没几像素所在的gv能匹配上的）。
思路
那么，我们就得让那些更明确的ST，在GT识别中有竞争优势，比如分析这两种ST的匹配度有什么差异，如何作用于GT识别竞争。
白话：说白了，要让ST识别聚焦于细节，而非轮廓（ST中就匹配几个无细节的轮廓当然容易，并且越容易越增强）。
示例
例1、识别桌子时为什么要识别桌腿桌角而不是桌面中间。
例2、识别圆心渐变时为什么能识别到圆。
例3、为什么识别盒子算算是识别到它是盒子，而不是仅识别到大概是个长方形。
方案1
仅仅是不够具象，更多的bestGVs条数自然就会有更多细节 5%。
方案1.1、仅提高ST竞争力，比如仅保留20%，自然就把太抽象的过滤掉了。
否掉：并不是因为ST不够具象，而是因为GT识别时，assST向抽象又取了有效抽象，导致它会过抽象 5%。
方案2
即使是同样的抽象（匹配率）之间，也存在太轮廓和有细节的区别 5%。
方案2.1、计算信息密度，根据bestGVs长度 和 rect范围来计算。
方案2.2、根据其具象指向数来判断，如果指向的非常多，则说明它是一个过于泛化的抽象特征。
否掉：无论是rect计算信息密度，还是指向具象数，二者都像是一种特殊处理，所以否掉 5%。
结果：还是建议用竞争来解决，所以转如下方案3.1。
方案3
本质上还是在GT识别时，assST取有效抽象：validAbsST导致了过抽象的问题 95%。
正据1、ST识别其实是有足够细节的，它组成的ProtoGT是成形的。
正据2、GT识别先取了有效抽象再refGT的，这一步取抽象会导致它有过抽象问题。
所以：ST识别没有过抽象问题，但refGT时它取有效抽象会导致ST过抽象，这些过抽的assGT.itemST必然匹配度更高。
方案3.1、GT的防过抽竞争因子，得把ST的抽象程度的影响也纳入进来（因为有过抽的ST切入）。
抉择
如上，选定方案3.1。
TODO1
ST识别不需要防过具了，因为反正GT识别时还要向上取有效抽象 其实就是废弃防过具，转35153继续深入下 T。
TODO2
把其ST的抽象度（匹配率）参与到GT识别竞争中来 上面改了ST准中取具，那GT也应如此，转35153-TODO3 T。
变数
经边测边分析，发现思路开始慢慢明确起来了，即：识别改为准确中越具象越好，所有有效抽象全计做识别结果 。
总结
本节虽然有问题，也有方案3的大致思路，但不够明确，明确的改法转35153下表继续推进 T。
35153
本节重点之二：废弃防过具（即准中取具）。
原因1
因为识别太轮廓：上表测得特征识别结果太轮廓的问题，必须向具象找答案。
原因2
因为很难对撞上：试图找出稳定且适当的抽具象层，本身就是不现实的，越后期知识量越大越难单靠明确的某个稳定层对撞上。
原因3
已有新对撞方法：所有有效全含的抽象全算识别结果（参考35151-方案3）。
方案
应该在准确的情况下尽量识别具象，然后其所有有效抽象，同视为识别结果。
TODO1
ST识别中的防具没必要了，改为：准中取具（准确中优先取具象）T。
TODO2
GT识别也改为：准中取具 T。
TODO3
GT识别结果也改为取全含抽象 以后再支持，现在未完全测到概念识别，暂不需要 T。
回测
边加训边分析调整特征识别的竞争（期间的竞争力参数等阈值调整）。
结果
经回测，GT识别不准确问题仍然存在，继续查，转下表。
图中是8吗？如果用assT8来自举，它是肯定匹配不到此图的。
