摘要

战斗日志（Logs）的每一行都被 OCR（光学字符识别）读三次（不同的裁剪/尺度）。之前的一个实验候选（这里称为“三读两同”规则）规定：如果三次中有两次完整解析出同一条内容，而第三次无法解析，就接受这两次的结果。这个规则提高了读出的行数，但有一个隐患：第三次“无法解析”的文本里，可能其实写着不同的伤害数、不同的单位或不同的时间——直接忽略它不安全。

本实验只做审计，不重跑识别：先写出一个更窄的守卫条件——第三次读数与另两次的唯一差别只能是“时间戳少了右括号”，再用 24 个事先标好的合成案例检验旧规则和守卫，最后对已经保存的 13 个被旧规则“提升”的日志行做一次检查。结果：旧规则在 18 个不应接受的合成案例中接受了 12 个；守卫一个都没接受，同时保留了全部 6 个应接受的对照。已保存的 13 个提升行全部满足守卫条件。

要回答的问题

旧“三读两同”规则会不会在第三次读数含有不同内容时仍然接受？一个只允许“缺时间戳右括号”的守卫，能否挡住这些情况，又不误伤已保存的真实提升？

数据与来源

  • 24 个固定的合成案例：6 个应接受的对照（右括号缺失分别出现在第一、二、三次读数，带全角/空格差异的情况，分数刚好在门槛上，法术行），18 个不应接受的案例（第三次读数的伤害、死亡数、单位、数量、玩家、时间、法术不同；文本被合并或截断；缺左括号；只有一次有效读数；第三次是另一条完整但冲突的内容；空读数；低分；框越界；不是日志行；数字损坏；引号标点不同）。标签在测量前按规则写定。
  • 已保存的旧候选输出：6 个案例文件中的 13 个被提升行。
  • 原图、解码、OCR、GPU、视频都没有使用。

方法

守卫条件（全部满足才算“可接受”）：

  1. 是日志行，原生框在 2560×1440 范围内，恰好三次非空读数，每次不超过 2048 字符，分数都 ≥0.90。
  2. 恰好两次完整解析成同一条字面内容。
  3. 这两次原文在 Unicode 规范化（NFKC）和去空白后也相同。
  4. 第三次原文等于同一规范化文本、只少了时间戳的右括号，其他内容、时间和标点都必须一致。

守卫不修改也不输出任何文字，只给出“是否符合”和原因。

设置

在合成案例上运行冻结的旧规则，与守卫的标准答案对比；然后对已保存的 13 个提升行逐个评估一次，先保存评估文件，不改动旧文件。协议、案例、代码和测试在检查前先冻结提交。

结果

合成案例 数量 旧规则接受 守卫判为可接受
应接受的对照 6 6 6
不应接受的案例 18 12 0

旧规则误接受的 12 个，包括第三次读数的伤害、死亡数、单位、数量、玩家、时间、法术不同，文本合并，缺左括号，数字损坏，框越界，以及两次完整文本引号标点不同。旧规则本来就拒绝了其余 6 个（第三次是冲突的完整读数、只有一次完整读数、低分、空读数、缺读数、非日志行）。

已保存输出：13 个提升行（分别来自一个 5 行短日志案例中的 3 行和一个 29 行滚动日志案例中的 10 行）全部符合守卫条件，0 个被拒绝；原始证据完整保留。

耗时：合成案例约 0.0024 秒，已保存输出检查约 0.0005 秒。

失败与负结果

旧规则存在明确的安全缺陷：它在合成案例上会接受第三次读数内容不同的情况。这次检查没有在已保存的真实输出里发现这种情况，但这不代表实际不会发生。

局限

  • 合成案例是对抗性的软件检查，不代表真实 OCR 错误出现的频率，也不是精确率或校准置信度。
  • 同一个 OCR 引擎两三次读出同样的错字，守卫仍会通过；“符合条件”不证明像素真值。
  • 守卫只是私有诊断输出，没有改变生产接受策略。旧候选的历史准确率（39 条可读完整行中 36 条正确，另有 1 条参考不确定）不因本审计改变。

结论与下一步

如果继续使用“三读两同”，应收窄为“只差时间戳右括号”的守卫。本次只在已保存的输出上验证了守卫不会误伤；真实的 1–2 行日志、被裁切和正在淡出的日志图片，需要另外划定范围的参考批次来检验。