大模型评估这块水太深了，如果不搞清楚评价指标到底在测什么

最近在复盘自己搭建的那个 RAG 工作流，发现了一个特别头疼的问题：模型回答得看起来挺像那么回事，但实际检索出来的知识点全是错的，或者干脆就是幻觉。以前总觉得只要模型够强、参数够大，回答质量自然就上去了，后来才发现，没有一套科学的评估体系（LLM Evaluation），所有的调优其实都是在盲目试错。

我把最近看的一套关于大模型评估的深度干货拆解了一下，这套逻辑其实非常清晰，主要围绕着几个核心维度在转：

评估的核心维度

• 相关性 (Relevance)： 这不是指语义上的接近，而是指模型给出的答案是否真的解决了用户提出的问题。很多时候模型会开启“复读机”模式，说了一堆正确的废话，但对解决问题毫无帮助，这就是相关性得分低。
• 忠实度 (Faithfulness)： 这是针对 RAG 场景最关键的一点。简单说就是模型有没有“胡编乱造”。它必须严格基于你提供的上下文（Context）来回答，如果模型结合了它自身的预训练知识去修正你的文档内容，那在严谨的业务场景下就是不及格的。
• 答案准确性 (Answer Correctness)： 这是把模型输出的结果和标准答案（Ground Truth）进行比对。

实际操作中的坑

在做实战部署的时候，我发现最难的不是选指标，而是怎么大规模地跑评估。如果你手动去对比，那效率太低了。现在主流的做法是引入 LLM-as-a-judge，也就是用一个更强大的模型（比如 GPT-4o 或 Claude 3.5 Sonnet）来给你的业务模型打分。

但是这里有个巨大的坑：评分偏见。

• 位置偏见： 如果你让裁判模型对比两个答案，它往往更倾向于选排在第一个的答案。
• 长度偏见： 裁判模型容易觉得“长即是好”，哪怕那个长答案里充满了废话。

为了规避这些，我在配置评估工作流时，会尝试交换选项顺序，或者引入多维度评分量表，而不是简单地给一个 0 到 1 的分数。

如果大家在做 Agent 或者知识库落地的时候，发现模型效果不稳定，别急着去换模型，先去梳理一下你的评估数据集（Eval Dataset）够不够硬，指标定得对不对。