LM-Evaluation-Harness项目中的Tokenizer远程代码信任问题解析

在评估开源语言模型时，研究人员经常使用LM-Evaluation-Harness这一强大的评估框架。近期，有开发者在评估internlm2_5-1_8b-chat模型时遇到了一个典型的技术问题，这个问题涉及到Hugging Face Transformers库中的安全机制。

当使用本地推理服务器(vllm)加载internlm2_5-1_8b-chat模型的tokenizer时，系统会提示需要用户确认是否信任远程代码。这是因为该模型的tokenizer实现包含自定义代码，而Transformers库出于安全考虑默认不自动执行这些代码。在交互式环境中，系统会等待用户输入(y/N)，但在非交互式环境(如脚本或批处理作业)中，这会导致EOFError异常。

问题的核心在于LM-Evaluation-Harness的api_models.py文件中加载tokenizer的方式。当前实现没有考虑传递trust_remote_code参数，而这个参数对于加载包含自定义代码的模型是必要的。特别是在使用API模式进行评估时，这个问题会中断整个评估流程。

技术解决方案相对直接：需要在加载tokenizer时显式传递trust_remote_code参数。这个参数应该与模型的其他参数保持一致，如果用户在模型参数中指定了trust_remote_code=True，那么加载tokenizer时也应该采用相同的设置。

这个问题反映了在模型评估工具开发中需要考虑的几个重要方面：

1. 安全性：Hugging Face的信任机制是为了防止潜在恶意代码的执行
2. 自动化：评估工具需要适应非交互式环境
3. 一致性：模型加载和tokenizer加载的参数应该保持一致

对于开发者来说，理解这个问题有助于更好地处理类似包含自定义组件的模型评估场景。同时，这也提醒我们在构建模型评估流水线时，需要充分考虑各种运行环境和安全限制。

该问题的修复已经通过PR提交，允许用户通过model_args传递trust_remote_code参数，从而解决了自动化评估中的这一障碍。这个改进使得LM-Evaluation-Harness能够更顺畅地评估那些包含自定义tokenizer实现的模型，进一步提升了框架的兼容性和实用性。