1. 评价一个LLM到底在评什么先把问题拆开。问“这个LLM好不好”其实跟问“这辆车好不好”一样答案完全取决于你要拿它干什么。拉货的嫌轿车小跑赛道的嫌卡车慢。LLM的评价也一样脱离场景谈好坏基本等于没说。我在实际项目里踩过最大的坑就是早期拿一个通用榜单的高分模型直接上生产结果在业务场景里表现一塌糊涂。后来才想明白评价LLM的本质是评价它在你的任务分布上的表现而不是它在别人榜单上的排名。所以评价体系要分三层来看基础能力层语言理解、知识储备、推理、指令遵循。这是模型的“底子”决定了能力上限。任务适配层在你的具体场景RAG问答、Agent工具调用、代码生成、结构化抽取里能不能干活。工程可用层延迟、成本、稳定性、上下文长度、并发能力。这层最容易被忽略但往往是一票否决项。很多人只盯着第一层看几个Benchmark分数就下结论这是典型的“纸上谈兵”。一个模型MMLU考了85分但你的RAG场景里它老是忽略检索到的上下文、自己编答案那对你来说它就是不及格。提示评价LLM的第一步不是找榜单而是把你的业务任务拆成可量化的评测集。没有评测集的评价都是感觉。2. 主流Benchmark到底测了什么又漏了什么2.1 常见Benchmark的能力映射Benchmark是快速筛选模型的工具但必须知道每个榜单背后测的是什么能力否则容易被分数误导。下面这张表是我自己整理的能力映射实际选型时经常翻出来看Benchmark主要测什么适用判断明显局限MMLU / MMLU-Pro多学科知识推理通用知识底子偏选择题不测生成质量GSM8K / MATH数学推理逻辑推理能力题目偏模板化易被刷分HumanEval / MBPP代码生成编程能力函数级不测工程能力IFEval指令遵循格式/约束遵守约束类型有限MT-Bench多轮对话质量对话体验依赖裁判模型主观性强LongBench长上下文长文本处理场景覆盖有限RAGASRAG专项检索增强问答需要自建数据集BFCL / ToolBench工具调用Agent能力工具集与真实环境有差距这张表的关键用法是先明确你的任务需要哪些能力再去看对应榜单而不是看总分。比如你做Agent那BFCL和IFEval的权重应该远高于MMLU。2.2 Benchmark的三大陷阱第一个陷阱是数据污染。很多榜单题目在训练数据里出现过模型是“背答案”而不是“会做题”。判断方法很简单看模型在榜单上的分数是否明显高于同规模同架构的模型如果高得离谱大概率有污染。我一般会自己构造一批“榜单风格但全新”的题目做交叉验证。第二个陷阱是选择题偏差。MMLU这类选择题模型可以靠排除法、靠选项分布规律拿分实际生成能力可能很差。所以选择题高分不等于生成能力强一定要补生成类评测。第三个陷阱是裁判模型偏见。用GPT-4当裁判评MT-Bench会系统性偏好“像GPT-4风格”的回答长回答、结构化回答容易拿高分哪怕内容空洞。我实测过把同样内容的回答拆成更多要点裁判分数会涨。所以裁判评测只能做参考不能当唯一标准。2.3 自建评测集才是王道说了这么多榜单的局限结论其实很明确通用Benchmark用来初筛自建评测集用来定稿。自建评测集的流程我一般是这样的任务采样从真实业务日志里采样200-500条覆盖高频场景和边界case。标注标准答案能自动判定的分类、抽取、格式写规则判定不能自动判定的生成质量人工标注或双人交叉标注。分层设计简单/中等/困难各占一定比例避免全是简单题导致分数虚高。留出集永远留20%不参与调优只用于最终评估防止过拟合。这套流程走下来虽然前期投入大但后面每次换模型、改Prompt、调RAG都能快速拿到可信的对比数据长期看非常划算。3. 分场景评价RAG、Agent、指令遵循各有各的坑3.1 RAG场景别只看答案对不对RAG的评价是最容易做偏的。很多人只看最终答案对不对但RAG是个流水线检索和生成任何一环出问题最终答案都会错。所以必须分环节评价。检索环节看这几个指标RecallK正确答案所在的文档有没有被召回。这是RAG的生命线召回不到生成再强也没用。PrecisionK召回的文档里有多少是相关的。太多无关文档会干扰生成。MRR / NDCG相关文档的排序质量越相关的排越前越好。生成环节看这几个指标忠实度Faithfulness答案是否完全基于检索到的上下文有没有编造。这是RAG最核心的指标。答案相关性Answer Relevancy答案是否切题有没有答非所问。上下文利用率检索到的有用信息有没有被用上。我踩过的一个典型坑某模型忠实度很高不编造但答案相关性很低答非所问因为它太“保守”检索到什么就复述什么不理解用户真正问的是什么。所以这两个指标必须一起看单看一个都会误判。注意RAG评测集一定要包含“检索不到答案”的case看模型是老实说“不知道”还是硬编一个答案。后者在生产环境是灾难。3.2 Agent场景工具调用是硬门槛Agent对LLM的要求和普通对话完全不同。它需要模型能理解任务、规划步骤、选择工具、填对参数、处理工具返回、根据结果调整。这里面任何一环掉链子整个任务就失败。评价Agent能力我主要看这几个维度工具选择准确率给定任务模型选的工具对不对。参数填充准确率工具选对了参数填得对不对。这个最容易被忽略但实际出错率很高尤其是嵌套参数、枚举值、格式要求。多步规划能力需要多步才能完成的任务模型能不能拆解并顺序执行。错误恢复能力工具返回错误时模型能不能理解错误并调整而不是死循环重试。BFCL这类榜单能测一部分但真实环境的工具描述、参数复杂度、错误类型都更丰富。我的做法是用真实工具集构造评测把线上常见的工具调用日志整理成测试用例覆盖正常调用、参数错误、工具报错、需要多步等场景。实测下来很多在BFCL上分数不错的模型在真实工具集上参数填充错误率能到20%以上。这个差距只有自建评测才能发现。3.3 指令遵循格式约束是生产环境的刚需Instruction Following在生产环境的重要性被严重低估。你的系统Prompt里写了“输出JSON”“不要用markdown”“只回答一句话”模型不遵守下游解析就崩了。IFEval测的是一部分但真实场景的约束更细碎。我一般会构造这几类约束测试格式约束JSON、XML、特定分隔符、字段名。长度约束不超过N个字、恰好N个要点。内容约束必须包含某关键词、不能提及某内容。风格约束语气、人称、语言。组合约束以上多种同时满足。这里有个经验约束越多模型遵守率下降越快而且是非线性的。单约束遵守率95%的模型五个约束叠加可能掉到60%。所以评测一定要测组合约束单约束分数好看没用。4. 工程可用性最容易被忽略的一票否决项4.1 延迟与吞吐模型再好延迟高到用户等不了就是不能用。延迟要分几个指标看首Token延迟TTFT流式输出场景下用户感知的“反应速度”这个比总延迟更重要。输出速度Tokens/s生成快不快影响长回答的体验。总延迟完整回答的时间。实测经验TTFT超过2秒用户就会明显感觉“卡”输出速度低于20 tokens/s长回答会让人等得不耐烦。这两个指标在选型时一定要实测不能只看模型参数量猜。吞吐量则决定了你的成本上限。同样的GPU不同模型的并发能力差异很大。我一般会压测出“单卡稳定支持的并发数”再结合业务峰值算需要多少卡。4.2 成本核算成本不能只看API单价要算单次任务完整成本。RAG场景下一次问答可能包含检索、Prompt组装、LLM调用、后处理。LLM调用可能还不止一次比如先判断意图再回答。我的成本核算模板是这样的成本项计算方式备注输入Token输入长度 × 单价注意RAG会大幅增加输入输出Token输出长度 × 单价长回答成本高调用次数单任务LLM调用次数Agent场景可能多次重试成本失败率 × 单次成本稳定性差的模型隐性成本高基础设施GPU/带宽/存储自部署时计入算下来经常发现单价便宜的模型因为调用次数多、重试率高总成本反而更高。所以成本要按任务算不能按Token单价算。4.3 稳定性与一致性这个最玄学但最要命。同一个Prompt同一个模型不同时间调用结果可能不一样。原因包括服务端负载、版本悄悄更新、采样随机性。我的应对方法固定随机种子如果API支持减少采样波动。关键任务用低温度牺牲一点多样性换稳定性。定期回归测试用固定评测集跑发现分数突然下降就排查是不是模型版本变了。多模型备份主模型出问题时能快速切换。提示生产环境一定要做模型版本的“金丝雀发布”新版本先小流量跑对比老版本指标没问题再全量。直接全量切换出问题就是事故。5. 一套可落地的LLM评价流程5.1 评价流程五步走把前面所有内容串起来我实际用的评价流程是这样的明确任务与指标先写清楚要评什么任务成功标准是什么对应哪些指标。构建评测集通用榜单初筛 自建评测集定稿自建集覆盖正常/边界/困难case。自动化评测能自动判定的写脚本不能的用裁判模型人工抽检。工程指标实测延迟、吞吐、成本、稳定性用真实流量或压测数据。综合决策按任务权重加权选出综合最优而不是单项最高。5.2 评测集构建的实操细节评测集质量直接决定评价结论的可信度。几个实操细节样本量每个任务至少100条重要任务300条以上。太少波动大结论不可靠。标注一致性多人标注时先对齐标准算Kappa系数低于0.7说明标准不清晰要重新对齐。难度分布简单30%、中等50%、困难20%这个比例比较接近真实业务分布。定期更新业务在变评测集也要更新建议每季度补充新case淘汰过时case。5.3 裁判模型的使用技巧用LLM当裁判能省大量人力但要用对裁判模型要比被测模型强否则评不准。给裁判明确的评分标准最好带评分示例few-shot减少主观性。位置偏见对比两个回答时交换顺序各评一次取平均消除位置偏好。长度偏见裁判容易偏好长回答可以在Prompt里明确“长度不是评分因素”。人工抽检裁判结果抽10%人工复核发现偏差及时调整Prompt。我实测过一个技巧让裁判先输出评分理由再输出分数比直接输出分数更准。因为“先想后答”能激活模型的推理能力减少拍脑袋打分。6. 常见问题与排查技巧实录6.1 评测结果与体感不符怎么办这是最常见的问题。评测分数高但实际用起来感觉不行。排查思路评测集是否覆盖真实场景大概率是评测集太“干净”没覆盖真实业务的脏数据、边界case。指标是否选对比如RAG只看答案准确率没看忠实度模型编答案也能拿高分。是否过拟合评测集调Prompt调到评测集上但泛化差。检查留出集分数。体感是否有偏差有时候是少数bad case印象太深实际整体不差。用数据说话。6.2 模型表现忽好忽坏同一模型同一任务表现不稳定。排查方向采样参数温度、top_p是否设置合理高温度会导致波动。输入长度长输入时模型表现下降检查是否超出有效上下文。Prompt顺序RAG场景下检索文档的顺序会影响结果相关文档放前面通常更好。服务端问题API是否有版本更新、负载波动看服务商状态页。6.3 常见问题速查表问题现象可能原因排查方法解决方向评测高分体感差评测集不真实对比评测集与真实日志分布重建评测集RAG答非所问检索召回差看RecallK优化检索RAG编造答案忠实度低看Faithfulness加约束Prompt/换模型Agent参数填错工具描述不清检查工具Schema完善描述/加示例指令遵循差约束太多逐个约束测试拆分约束/换模型延迟高模型大/输出长测TTFT和输出速度换小模型/限制输出成本超预期调用次数多统计单任务调用次数合并调用/缓存结果不稳定温度高/版本变固定种子/回归测试降温度/锁版本6.4 几个独家避坑技巧技巧一用“对抗样本”测鲁棒性。在评测集里加入一些故意刁难的case比如错别字、语序颠倒、无关信息干扰看模型能不能稳住。真实用户输入往往不规范鲁棒性比“标准题”得分更重要。技巧二关注“拒答率”。模型该拒答时拒答比如问它不知道的事不该拒答时不拒答比如正常问题。拒答率异常高或异常低都是问题。我一般会单独统计这两类。技巧三长上下文要测“中间遗忘”。很多模型号称支持128K但信息放在中间就找不到。测试方法把关键信息放在长文本的不同位置看模型能不能都找到。实测很多模型是“两头强中间弱”。技巧四多轮对话要测“指令漂移”。聊了几轮之后模型是否还记得最初的约束。比如第一轮说“之后都用JSON回答”第五轮还遵守吗。这个在生产环境很关键。技巧五成本要算“失败成本”。模型失败一次可能要重试、要人工介入、要用户流失。这些隐性成本往往比Token成本高得多。所以稳定性差的模型实际成本远高于账面。7. 评价体系的持续迭代LLM评价不是一次性工作而是持续过程。模型在更新业务在变化评价体系也要跟着迭代。我的做法是建一个评测看板每次模型切换、Prompt调整、RAG改动都跑一遍固定评测集记录指标变化。时间长了就能看出趋势哪些改动有效哪些模型在退步哪些场景一直是短板。另外线上指标和离线评测要打通。离线评测分数高线上业务指标点击率、解决率、满意度也要跟着涨否则说明评测集和真实目标脱节了。我一般会定期做离线-线上相关性分析相关性低就调整评测集。最后分享一个我自己的体会评价LLM这件事工具和方法都是次要的最重要的是想清楚“好”的定义。你的业务里什么算好是准确率、是速度、是成本、还是用户体验定义清楚了评价体系自然就出来了。定义不清楚用再多榜单也是瞎评。这个方向后续还可以扩展的点很多比如多模态模型的评价、Agent长任务的评价、以及如何用LLM自动生成评测集。每个都值得单独展开聊。