摘要
游戏的战斗日志（Logs）是一个可以翻页的文字窗口，逐行记录“谁攻击了谁、造成多少伤害、死了几个、施放了什么法术”，每行前面有一个日志时钟。它是推断对局的最重要证据之一，但项目里一直缺少一份逐行的参考数据来衡量日志读取器。
本实验先把数据和审核工具准备好：从 42 段录像中选出 400 页日志截图，用已有的整帧 OCR 生成逐行预标注，按录像、时钟和原文去重成 4323 行，再把每行解析成模板、声明种类和参数；同时让生产日志读取器读同样的 400 页，比较两者的一致程度；最后做一个离线审核网页，供用户逐行确认或纠正。本轮人工审核数为 0，所以所有比较都只是“机器预标注与生产读取器之间的一致率”，不是准确率。
要回答的问题
- 能否从已有录像中，按来源划分（开发/测试）可复现地构造一份日志逐行参考的候选集，并让用户高效审核？
- 在用户审核之前，生产日志读取器与预标注在哪些字段上分歧最大？
数据与来源
- 400 页日志、42 段录像、22 个日期；开发 250 页/2997 行，测试 150 页/1326 行。划分沿用已有的整段来源划分，来源不明的不打开。
- 33 页来自 8 月 31 日游戏更新前的录像，都在开发集；一段晚间测试池录像的 23 页都在测试集。冻结的八段录像和两段冻结评估录像保持关闭。
- 9124 次“行出现”去重为 4323 行。去重按录像、可读的日志时钟和逐字 OCR 原文进行；时钟读不出的行不跨帧合并。每行保留它所有的出现（视频毫秒、整帧、原生行框和 OCR 片段）。
- 整帧图像沿用已有采集保存的 JPEG（质量 95），不宣称是原视频的无损像素。
方法
- 预标注字段： 原文、日志时钟、前缀、对应的游戏安装文本模板 ID、声明种类和每个参数的值/状态。模板候选不唯一时 ID 为空；完全对不上为“未匹配”；尚未实现的声明为空，不升级为已确认事件。
- 检查表： 重复行、同一时钟下可能的 OCR 变体、参数类型和时钟顺序问题。同一页上同时可见的不同行不算变体；相同时钟的不同事件可能被误列为候选，不自动合并。
- 与生产读取器比较： 用公开的日志读取接口读 400 页（复用整帧 OCR，加两次局部 OCR，启用扩展语法），按去重行计数；出现帧按几何选择，不能挑对答案的帧。
- 审核网页： 离线运行，进度保存在浏览器本地，可导出 JSON；原标签不变，只有用户明确点击确认的字段才进入“已审核”。合并导出时校验整批 ID、原文、允许字段和类型，不允许覆盖原文件。
设置
生产读取器对比在 GPU 上运行局部 OCR，用时 286.54 秒；因为复用了已有整帧 OCR，不能当作从零开始的整帧时延。读取程序每页及每次局部 OCR 前检查游戏进程，游戏在运行就暂停 GPU。
结果
数据规模： 4323 行、30697 个预标注字段；已审核 0 个。
生产读取器与预标注的一致率（不是准确率）：
| 字段 | 一致 / 可比较 |
|---|---|
| 行定位 | 4255 / 4323 |
| 日志时钟 | 3175 / 4247 |
| 安装模板 | 3004 / 4071 |
| 声明种类 | 3111 / 4218 |
| 逐字原文 | 1630 / 4323 |
逐字原文一致率低，很大一部分来自标点、空格变化以及三通道拒识，这类严格字面比较会显著拉低数字。
检查表： 2024 行重复出现；993 对可能的 OCR 变体涉及 1508 行（仍可能是同时发生的不同事件，保留为独立行）；252 行模板歧义、77 行未匹配；28 行安装模板尚无状态估计的声明支持；76 个时钟未知、3 个数值参数未知；页内时钟非单调 0 次。身份或语法失败没有被悄悄从分母里删除。
失败与负结果
- 助手目视检查了 48 个诊断行的上下文（不写入“已审核”），发现截断或错位的 OCR 框，以及边框和鼠标被读成的伪文字。这些留给用户纠正。
- 预标注行的总量不能证明“页面上所有可见日志行都被收录”；需要用户在审核中补录漏行才能确认覆盖。
局限
- 已审核为 0：不能宣称日志金标准已完成，也不能宣称逐字段 95%。
- 模板 ID 对比是把生产输出的原文反查回安装模板，生产读取器本身并不直接返回模板 ID。
- 17 个行为测试和审核页的桌面/手机检查通过，只证明工具可用；合成导出仅用于测试，评分始终排除它。
结论与下一步
数据集、检查表、生产对比和审核网页都已就绪，但一份真正的日志参考还要等用户审核。建议的审核顺序：先看未匹配、非法数值、短框和破损时钟、模板歧义，再按原图核对常见的攻击和伤害行，同时补录漏掉的行。
Comments