企业官网建设流程全解析

1. 评价一个LLM到底在评什么

先把问题拆开。很多人一上来就问“哪个模型最强”，这问题本身就没法回答，因为“强”在不同场景下指向完全不同的东西。我做了两年多模型评测相关的工作，踩过最大的坑就是拿一个通用榜单的分数去推断模型在具体业务里的表现，结果上线后效果差了一大截。

评价一个LLM，本质上是在评三个层面的东西：基础能力、任务适配度、工程可用性。基础能力包括语言理解、推理、知识储备、指令遵循这些底层素质；任务适配度是指它在你的具体场景（比如RAG问答、Agent工具调用、代码生成）里能不能稳定干活；工程可用性则涉及延迟、成本、并发、输出格式稳定性这些落地指标。三者缺一不可，但优先级取决于你的场景。

举个例子，你要做一个客服场景的RAG系统，那模型的基础知识广度可能没那么重要，因为知识都在你的知识库里，重要的是它能不能严格基于检索到的内容回答、能不能在检索结果不相关时说“我不知道”、能不能稳定输出你要求的JSON格式。这时候你去盯着MMLU分数看，方向就偏了。

所以评价LLM的第一步不是选榜单，而是定义你的评价目标。我通常会把目标分成三类：选型对比（在几个候选模型里选一个）、上线验收（确认模型在业务数据上达标）、持续监控（上线后跟踪效果变化）。三类目标的评价方法完全不同，后面会逐一展开。

注意：没有“万能评测方案”。任何告诉你“跑这个榜单就行”的说法，要么是偷懒，要么是没做过真实落地。

2. 主流评测基准到底测了什么

2.1 通用能力榜单的定位与局限

MMLU、BBH、ARC、HellaSwag这些榜单，本质上测的是模型的“通识素质”。MMLU覆盖57个学科的选择题，BBH测多步推理，ARC测科学推理。它们的好处是标准化、可复现、社区认可度高，适合做粗筛。

但局限也很明显。第一，选择题形式和真实生成任务差距大。模型在MMLU上选对答案，不代表它能生成一段结构清晰的回答。第二，数据污染问题严重。很多榜单题目已经进了训练数据，分数虚高。第三，不测指令遵循和格式稳定性，而这恰恰是工程落地最看重的。

我一般把通用榜单当“入场券”用：分数太低的直接排除，但分数高的不代表就能用。真正决定选型的，是后面的任务级评测。

2.2 指令遵循评测：IFEval与真实场景的差距

IFEval这类评测专门测模型能不能按指令做事，比如“用不超过50个字回答”“输出JSON格式”“包含三个要点”。这个方向比通用榜单贴近实战多了，因为实际业务里你几乎总在给模型下各种约束。

但IFEval的指令还是偏简单和孤立。真实场景里，指令往往是复合的、有上下文依赖的。比如“基于以下检索内容回答用户问题，如果检索内容不包含答案就说不知道，回答控制在100字以内，用中文，不要用markdown”。这种复合约束下，模型的遵循率会明显下降。

我的做法是：从IFEval里挑几类和你业务相关的指令类型，然后用自己的数据构造复合指令测试集。比如你做RAG，就重点测“基于给定内容回答”和“拒答”这两类；你做Agent，就重点测“工具调用格式”和“多步规划”。

2.3 RAG与Agent场景的专用评测

RAG场景的评测核心是三个指标：忠实度（faithfulness）、答案相关性（answer relevance）、上下文相关性（context relevance）。忠实度看模型有没有胡编，答案相关性看回答是否切题，上下文相关性看检索结果是否相关。这三个指标用RAGAS这类框架可以自动化跑，但要注意LLM-as-judge本身也有偏差。

Agent场景更复杂，要测工具选择准确率、参数填充正确率、多步任务完成率、错误恢复能力。我实测下来，很多模型在单步工具调用上表现不错，但一到多步规划就崩，要么重复调用同一个工具，要么在工具报错后不知道怎么处理。这类问题通用榜单完全测不出来。

实操心得：RAG和Agent的评测集一定要自己构造，用真实业务数据。公开评测集只能帮你排除明显不行的模型，选不出最适合的。

3. 从零搭建一套可落地的评测流程

3.1 定义评价维度与权重

先明确你要评哪些维度，每个维度的权重是多少。我常用的维度框架如下：

权重不是拍脑袋定的，要结合业务。比如客服场景拒答能力权重可以更高，因为胡编的代价很大；内部工具场景格式稳定性权重更高，因为解析失败会直接报错。

3.2 构造评测数据集

评测集的质量直接决定评测结论的可信度。我的构造流程是：

1. 从真实业务日志里采样。挑100-300条真实用户query，覆盖高频和长尾。
2. 人工标注标准答案。这一步最费时间，但省不得。标准答案不一定要唯一，但要有明确的评分标准。
3. 构造边界case。包括：检索结果为空、检索结果不相关、问题有歧义、问题超出知识库范围。
4. 分层抽样。按问题类型、难度、长度分层，确保评测集有代表性。

评测集规模不用太大，100-200条精心构造的case，比1000条随便凑的更有价值。我见过太多人拿几千条数据跑一遍，结论却站不住脚，问题就出在数据质量上。

3.3 自动化评测与人工评测的配比

全自动评测快但不可靠，全人工评测准但慢。我的配比是：自动化跑全量，人工抽检20%-30%。

自动化评测用LLM-as-judge，但要注意几点：judge模型要比被评模型强，prompt要写清楚评分标准，最好用多个judge取平均。人工评测用来校准自动化评测的偏差，如果两者差异大，说明judge prompt有问题。

具体操作上，我会先用人工标注50条，然后调judge prompt直到自动化结果和人工结果一致率超过85%，再用自动化跑全量。这个校准过程通常要迭代3-5轮。

4. 评测执行中的关键细节

4.1 Prompt模板的统一与变量控制

评测时最容易犯的错误是prompt不一致。同一个模型，prompt改一个字，结果可能差很多。所以评测前要固定prompt模板，只改变量（用户问题、检索内容），其他部分完全一致。

我通常会把prompt模板存成配置文件，评测时加载。模板里要包含：系统指令、格式要求、few-shot示例（如果有）、用户输入占位符。每次评测记录模板版本号，方便回溯。

另外要注意temperature和top_p的设置。评测时一般设temperature=0，保证可复现。但如果你要测模型的稳定性，可以设temperature=0.7跑多次，看输出方差。

4.2 评分标准的设计与校准

评分标准要具体到可操作。比如“答案质量”不能只说“好/中/差”，要拆成：准确性（事实是否正确）、完整性（是否覆盖要点）、条理性（结构是否清晰），每项1-5分。

校准方法是：找3-5个人独立标注同一批数据，算一致性（如Cohen's Kappa）。如果一致性低于0.7，说明标准太模糊，要重新定义。这个过程很枯燥，但跳过的话后面所有结论都不可信。

4.3 结果统计与显著性判断

跑完评测后，不要只看平均分。要看分布、看方差、看badcase。两个模型平均分差2分，可能是一个模型在某个子类上崩了，而不是全面落后。

统计显著性方面，样本量小的时候用bootstrap算置信区间，样本量大可以用t检验。但说实话，实际选型时，如果两个模型差距在5%以内，我一般会选成本更低或延迟更低的那个，因为这点差距在真实场景里往往被其他因素淹没。

5. 常见评测陷阱与避坑指南

5.1 数据污染与过拟合

数据污染是评测最大的敌人。很多模型在训练时见过公开评测集，分数虚高。判断方法是：看模型在私有评测集和公开评测集上的分数差距，如果差距很大，大概率有污染。

避坑方法：优先用私有数据评测。如果非要用公开榜单，选那些有防污染机制的（如定期更新题目、隐藏测试集）。另外，注意模型的训练数据截止时间，如果评测集在截止时间之后发布，污染风险低。

5.2 LLM-as-judge的偏差

LLM-as-judge有几个已知偏差：位置偏差（倾向于选第一个选项）、长度偏差（倾向于选更长的回答）、自我偏好（倾向于选和自己风格相似的回答）。

缓解方法：交换选项顺序跑两次取平均，控制回答长度差异，用多个不同家族的judge模型。我实测下来，GPT-4和Claude做judge的结论经常不一致，所以最好两个都用，取交集或加权。

5.3 评测集泄露与版本管理

评测集要严格管理，不能进训练数据，不能随便给人。我见过团队把评测集放在共享目录里，结果被不知情的人拿去微调了，整个评测就废了。

版本管理方面，评测集、prompt模板、评分标准、评测脚本都要版本化。每次评测记录：模型版本、评测集版本、prompt版本、评分标准版本。这样出问题时能快速定位。

6. 从评测到选型的决策框架

6.1 多维度加权打分

把各维度得分按权重加权，得到综合分。但综合分只是参考，最终决策还要看短板。比如一个模型综合分很高，但格式稳定性只有60%，那在需要结构化输出的场景就不能用。

我通常会把维度分成“必须达标”和“越高越好”两类。必须达标的维度设阈值，不达标直接排除；达标后再按其他维度排序。

6.2 成本与延迟的权衡

成本包括token价格和推理时间。同样效果的模型，价格可能差10倍。选型时要算清楚：按你的日均调用量，月成本差多少；延迟增加是否影响用户体验。

我一般会画一个“效果-成本”散点图，找帕累托最优的模型。有时候一个稍弱的模型，成本只有十分之一，那在非核心场景就完全够用。

6.3 持续监控与迭代

选型不是一次性的。上线后要持续监控：用户反馈、badcase率、格式错误率、延迟变化。模型提供方可能悄悄更新版本，效果可能变好也可能变差。

我的做法是：每周跑一次小规模回归评测（50条核心case），每月跑一次全量评测。发现效果下降就排查原因，必要时切换模型或调整prompt。

最后分享一个小技巧：评测时一定要记录每个case的原始输入和输出，不要只记分数。因为当你发现某个维度得分低时，只有看原始数据才知道问题出在哪。我踩过这个坑，只记了分数，回头想分析badcase时发现数据没存，只能重跑，浪费了大量时间。