OpenCompass主观评估配置问题解析与解决方案

问题背景

在使用OpenCompass进行大模型主观评估时，用户遇到了一个配置错误导致评估流程无法正常运行的问题。该问题出现在使用HuggingFace模型作为评估模型（evaluator model）进行主观评估的场景中。

错误现象

当用户运行主观评估脚本时，系统报出KeyError: 0错误，提示在配置访问过程中出现了键值缺失的情况。具体错误发生在尝试访问evaluator_models配置项时，系统无法找到索引为0的元素。

问题根源分析

经过深入分析，发现问题的根本原因在于配置文件中evaluator_models的定义方式不正确。在原始配置中，evaluator_models被定义为一个字典(dict)对象：

evaluator_models = dict(
    type=HuggingFacewithChatTemplate,
    abbr='qwen1.5-4b-chat-hf',
    path='Qwen/Qwen1.5-4B-Chat',
    meta_template=api_meta_template,
    query_per_second=16,
    max_out_len=2048,
    max_seq_len=2048,
    batch_size=4,
    temperature=0,
)

然而，OpenCompass的主观评估系统在设计上期望evaluator_models是一个包含多个评估模型的列表(list)，即使只使用一个评估模型，也需要将其放入列表中。这种设计允许系统同时使用多个不同的评估模型进行综合评估。

解决方案

正确的配置方式是将评估模型的定义放入列表中：

evaluator_models = [dict(
    type=HuggingFacewithChatTemplate,
    abbr='qwen1.5-4b-chat-hf',
    path='Qwen/Qwen1.5-4B-Chat',
    meta_template=api_meta_template,
    query_per_second=16,
    max_out_len=2048,
    max_seq_len=2048,
    batch_size=4,
    temperature=0,
)]

这种修改后，系统就能正确识别评估模型配置，评估流程可以正常执行。

技术原理

OpenCompass的主观评估系统采用了一种灵活的架构设计，允许用户配置多个评估模型。这种设计基于以下考虑：

1. 模型多样性：不同的评估模型可能擅长评估不同方面的能力，组合使用可以提高评估的全面性。

2. 结果可靠性：通过多个模型的评估结果对比，可以减少单一模型的偏见或局限性。

3. 扩展性：系统架构支持未来轻松添加更多评估模型，而无需修改核心逻辑。

当系统尝试访问评估模型时，它会按照列表索引的方式访问配置，因此必须将评估模型定义放在列表中，即使只有一个模型。

最佳实践建议

1. 始终使用列表格式：即使只使用一个评估模型，也建议使用列表格式，保持配置的一致性。

2. 多模型配置：可以考虑配置2-3个不同风格的评估模型，以获得更全面的评估结果。

3. 参数调优：对于评估模型，适当调整temperature参数可以控制生成结果的随机性，通常主观评估中设置为0以获得确定性结果。

4. 资源考虑：多个评估模型会增加计算资源消耗，需要根据实际硬件条件权衡。

总结

OpenCompass的主观评估功能为研究人员提供了强大的模型能力评估工具。正确理解和使用评估模型配置是确保评估流程顺利运行的关键。通过将评估模型定义放入列表中，可以避免常见的配置错误，充分发挥OpenCompass的主观评估能力。