Update check_loss utility for loss extraction

[zjjlivein]

改动内容

更新 tests/integration_test/check_loss.py（与 release/1.2 分支 PR #4759 相同改动 cherry-pick 到 develop）:

• 新增 write_loss_file 辅助函数，统一写出 loss 文件的逻辑
• 新增 --extract_loss_only 参数：仅从日志中提取 loss 值并写出，不依赖 ground truth 文件
• --gt_file 改为非必填（--extract_loss_only 模式下可不传）
• 简化 loss_pattern 正则

关联 PR

• release/1.2: Update check_loss utility for loss extraction #4759

测试

本地 python -m py_compile 通过，未做行为破坏性改动，其余分支逻辑保持一致。

---

🤖 Generated with Claude Code

[risemeup1111]

本次 review 发现一个需要修复后再合入的问题，细节已放在行级评论里。

• 优先级：P3 非行级：PR 描述目前仍是模板内容，建议补充这次 check_loss.py 变更的目的、支持的日志格式示例、--extract_loss_only 的使用场景，以及已执行或依赖的测试/CI。处理要求：请针对该评论进行回复（同意并已修改请回复 Done，不同意请说明理由）。

^{Powered by Nyanpasu with gpt-5.5 xhigh, please check the suggestions carefully.}

[risemeup1111]

优先级：P1

问题： 这里把 loss 正则放宽成任意位置匹配后，会把同一行里的非主训练 loss 字段也当成基准 loss。例如仓库里训练日志会把 global_training_logs 追加到同一条 metrics 中，字段包括 router_loss、lm_loss、mtp_depth_0_loss 等；另外 ZCC 也会输出 global_step:<n>, because loss:<v>。当前 loss:\s* 会命中这些字段名里的 loss: 或诊断文本里的 loss:，只要同一行还有 global_step:，就会写入 log_dict，可能覆盖真实训练 loss，导致精度基准误判。

处理要求：请针对该评论修复并提交新的 commit。

建议只匹配主训练日志里的独立 loss 字段，并绑定后续 learning_rate 字段，避免误抓其他 loss 指标，同时支持科学计数法：

Suggested change

	loss_pattern = re.compile(r"loss:\s*([0-9\.]+)")
	loss_pattern = re.compile(r"(?<![A-Za-z_])loss:\s*([+-]?(?:\d+(?:\.\d*)?|\.\d+)(?:[eE][+-]?\d+)?),?\s+learning_rate:")

[risemeup1111]

已复查当前提交，loss_pattern 已恢复为原来的受限匹配，之前这里误抓非主训练 loss 的问题已解决。

[risemeup1111]

已复查新提交，之前行级评论里的 P1 问题已经修复，当前代码侧未发现新的阻塞问题。CI 还有任务在运行中，建议等完整结果出来后再合入。

• 优先级：P3 非行级：PR 描述的“简化 loss_pattern 正则”现在与当前 diff 不一致；新提交已经恢复了该正则。建议把该条改成“保持原有 loss_pattern，仅新增 loss 提取模式/写出逻辑”，避免后续 review 或回溯时误解本 PR 的实际改动。处理要求：请针对该评论进行回复（同意并已修改请回复 Done，不同意请说明理由）。

^{Powered by Nyanpasu with gpt-5.5 xhigh, please check the suggestions carefully.}