OpenCompass多卡推理验证Lawbench时2-1子任务缓存文件丢失问题分析

问题背景

在使用OpenCompass评估框架对Qwen2-7B-Instruct模型进行Lawbench法律基准测试时，当采用多卡（4张NVIDIA RTX 3090）并行推理时，发现2-1子任务（document_proofreading文档校对）的评估过程出现异常。具体表现为评估过程中无法找到关键的缓存文件，导致该子任务的评估结果无法正常输出。

错误现象

从错误日志中可以清晰地看到两个关键问题：

1. 字符元数据文件缺失：系统在尝试加载char_meta.txt文件时失败，该文件是Lawbench评估过程中用于字符相似度计算的重要资源文件。

2. 临时M2文件缺失：在评估过程中生成的临时M2格式文件（/tmp/tmpf8i3a78z.m2）无法找到，这是用于存储模型输出与参考答案对比的中间文件。

根本原因分析

经过深入分析，这个问题可能由以下几个因素共同导致：

1. 多进程并行处理冲突：当使用多卡并行推理时，不同进程可能同时尝试访问或创建相同的临时文件，导致文件创建或访问冲突。

2. 文件路径解析问题：Lawbench评估脚本中使用的相对路径解析方式在多进程环境下可能不稳定，特别是在Python包安装路径和临时目录之间跳转时。

3. 资源文件部署不完整：char_meta.txt作为评估的关键资源文件，可能在OpenCompass安装过程中未被正确部署到指定位置。

解决方案

针对这个问题，推荐以下几种解决方案：

1. 使用--reuse参数重新运行：这是最简单直接的解决方案，通过重用已生成的部分结果，避免重复执行已完成的任务。

2. 单卡顺序执行：如果时间允许，可以尝试使用单卡顺序执行，避免多进程间的文件访问冲突。

3. 手动补全资源文件：可以手动将缺失的char_meta.txt文件放置到正确位置，确保评估脚本能够找到它。

4. 修改评估脚本：对于长期使用，可以考虑修改Lawbench的评估脚本，使其能够更稳定地处理多进程环境下的文件操作。

技术细节补充

Lawbench的2-1子任务（文档校对）评估过程实际上包含以下几个关键步骤：

1. 字符级比对：使用char_meta.txt中的字符相似度信息进行精细化的文本比对。

2. M2格式转换：将模型输出和参考答案转换为M2格式，这是一种用于语法错误检测的标准格式。

3. 差异分析：通过比较两个M2文件的差异来计算最终的校对得分。

在多卡环境下，这些步骤可能因为进程同步问题而导致中间文件处理异常。特别是M2文件的生成和读取时机需要严格控制，否则就会出现文件未生成就被尝试读取的情况。

最佳实践建议

对于需要在多卡环境下运行OpenCompass评估的用户，建议：

1. 监控临时文件：在执行过程中监控/tmp目录下的临时文件状态，确保它们被正确创建和使用。

2. 分阶段执行：对于大型评估任务，可以考虑分阶段执行，先完成推理部分，再单独执行评估部分。

3. 日志记录：增加详细的日志记录，帮助定位多进程环境下的文件操作问题。

4. 资源检查：在执行前检查所有必需的资源文件是否就位，特别是像char_meta.txt这样的评估依赖文件。

通过以上分析和建议，希望能够帮助用户更好地在OpenCompass多卡环境下完成Lawbench等复杂基准测试的完整评估。