什么是 Evaluation Harness？和 Benchmark 有什么区别

1️⃣ 考察意图

面试官想看你是否理解评估基础设施（Evaluation Harness）与评估内容（Benchmark）的本质区别，而非停留在“Harness是工具，Benchmark是数据集”的浅层认知。这是典型的“概念辨析+工程取舍”题，刁钻点在于：很多人能背定义，但说不清Harness如何解决Benchmark碎片化、结果不可复现的问题。答好了能展示你对LLM评估整条链路的系统思考，包括缓存、并行、标准化接口等工程细节，以及从“跑分”到“可信评估”的认知升级。

2️⃣ 标准答

核心定义

Evaluation Harness：一个标准化的评估框架，负责加载模型、数据集、评测指标，自动化执行并输出结构化结果。它像“测试流水线”，屏蔽了不同Benchmark的调用差异。典型代表：EleutherAI的lm-evaluation-harness、OpenAI的evals、Hugging Face的lighteval。
Benchmark：一组固定的任务+数据集+指标，用于衡量模型在特定能力上的表现。例如MMLU（57学科知识）、GSM8K（数学推理）、HumanEval（代码生成）。它是“考卷”，不是“考场”。

关键区别（3个维度）

抽象层级：Harness是基础设施（infrastructure），Benchmark是内容（content）。Harness定义“如何考”，Benchmark定义“考什么”。
可扩展性：Harness必须支持插件式添加新Benchmark（如通过YAML配置），而Benchmark是静态的。例如lm-evaluation-harness只需实现一个Task类就能接入新数据集。
结果复现：Harness通过固定随机种子、模型加载方式、tokenizer配置来保证结果可复现；Benchmark本身不保证这一点——同一个MMLU，不同人用不同prompt模板可能差5个点。

工程取舍（Trade-off）

缓存 vs 实时计算：Harness通常对模型输出做缓存（如按(model_id, task, params)哈希），避免重复推理。但缓存粒度需要权衡：缓存整个输出会占用大量磁盘（一个7B模型跑MMLU约500MB），缓存logits则需重算解码。实践中常用“输出级缓存+过期策略”。
并行 vs 确定性：多进程/多卡并行能加速，但会引入非确定性（如GPU算子顺序不同）。Harness需提供--num_fewshot和--seed参数，并在文档中声明“并行下结果可能微小波动”。

实际落地的坑 + 解法

坑1：Prompt模板不一致。同一个Benchmark（如MMLU），不同Harness的few-shot格式不同（Question: ... Answer: vs Q: ... A:），导致分数差异。解法：Harness应内置“规范模板”并强制校验，或提供--template参数让用户显式指定。
坑2：模型加载开销。每次跑新Benchmark都重新加载模型权重，耗时巨大。解法：Harness实现“模型池”或“热加载”，支持一次加载模型后连续跑多个Benchmark（如lm-evaluation-harness的--model_args支持pretrained=...复用）。
坑3：Agent评估的复杂性。传统Harness只测单轮问答，但Agent需要多轮交互、工具调用。解法：扩展Harness支持“回合制”评估，记录每一步的action、observation、reward，并计算成功率、平均步数、成本等指标。

3️⃣ 答题模板（30 秒电梯版）

“这个问题我从定义、区别、工程实现三个层面回答。定义上，Evaluation Harness是评估基础设施，负责加载模型、数据集、指标并自动化运行；Benchmark是具体的评测基准，如MMLU、GSM8K。区别在于抽象层级——Harness是‘考场’，Benchmark是‘考卷’；可扩展性——Harness支持插件式添加新任务；结果复现——Harness通过缓存和固定种子保证一致性。总结一句：Harness解决‘怎么测’，Benchmark解决‘测什么’，二者缺一不可。”

4️⃣ 高频追问 & 应对

追问 1：你如何设计一个Harness来支持Agent评估？

核心是扩展传统Harness的“单轮问答”模式为“多轮交互”。我会定义AgentTask类，包含initial_prompt、max_steps、tool_spec（工具列表及调用方式）。评估时，Harness维护一个Episode对象，记录每一步的action、observation、reward。指标上，除了最终成功率，还要加“平均步数”、“工具调用成功率”、“成本（token消耗）”。缓存策略需按(episode_id, step)粒度缓存，避免重复调用模型。参考开源项目agent-eval-harness（如微软的TaskWeaver评估框架）的设计。

追问 2：Harness的缓存机制如何设计才能兼顾速度和磁盘占用？

采用两级缓存：第一级是“输出级缓存”，按(model_id, task_name, params_hash)哈希，存储模型生成的完整文本。优点是速度快，缺点是磁盘占用大（一个7B模型跑MMLU约500MB）。第二级是“logits级缓存”，只存储模型最后一层的logits，解码时实时计算。优点是磁盘小（约50MB），缺点是重算解码耗时。实践中，我倾向混合策略：对短输出（如多选题）用输出级缓存，对长生成（如代码）用logits级缓存。同时加过期策略：模型版本更新后自动清空缓存。

追问 3：如何保证不同Harness之间的结果可比性？

关键在于标准化。首先，定义统一的Task接口，强制要求提供prompt_template、fewshot_examples、metric_fn。其次，发布“参考实现”和“黄金结果”，例如lm-evaluation-harness的results/目录会包含官方跑分。最后，在论文中必须声明Harness版本和参数（如--num_fewshot 5 --seed 42）。实践中，OpenAI的evals通过YAML文件固化所有配置，确保任何人跑同一YAML得到相同结果。

5️⃣ 避坑 · 常见错误答法

❌ “Evaluation Harness就是Benchmark，只是叫法不同。” → ✅ “Harness是框架，Benchmark是内容。Harness可以跑多个Benchmark，而Benchmark不能自己跑自己。”
❌ “Harness只负责跑分，不关心结果复现。” → ✅ “Harness的核心价值之一就是通过缓存、固定种子、标准化prompt来保证结果可复现。没有Harness，不同论文的分数无法直接对比。”
❌ “Agent评估用传统Harness就行，加个工具调用接口。” → ✅ “Agent评估需要多轮交互、状态追踪、工具调用记录，传统Harness的‘单轮问答’模式完全不够用，必须重新设计Episode和Step数据结构。”

6️⃣ 简历呼应

如果你有RAG项目：从“评估RAG系统的Harness”切入，说明如何设计RetrievalTask（包含chunking、检索、生成三步），并对比不同检索器（BM25 vs DPR）的端到端效果。
如果你只做过传统NLP：用“GLUE/SuperGLUE时代的评估脚本”类比，说明传统脚本是硬编码的，而Harness是插件化的。强调你理解“从脚本到框架”的演进逻辑。
如果你是校招无项目：聚焦lm-evaluation-harness的源码解读，说明你读过它的Task类和Model类设计，并自己写过一个demo：用Harness跑MMLU和GSM8K，对比Llama-2-7B和Mistral-7B的分数。
EleutherAI lm-evaluation-harness 官方文档及论文
OpenAI evals 仓库及 Eval 类设计
Hugging Face lighteval 框架及多任务并行实现
《Evaluating Large Language Models: A Survey》中关于评估基础设施的章节
Agent评估框架 agent-eval-harness（微软TaskWeaver相关论文）

—— 本场面试完 ——