企业官网建设流程全解析

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

先把问题拆开。问“这个LLM好不好”，其实跟问“这辆车好不好”一样，答案完全取决于你要拿它干什么。拉货的嫌轿车小，跑赛道的嫌卡车慢。LLM的评价也一样，脱离场景谈好坏，基本等于没说。

我在实际项目里踩过最大的坑，就是早期拿一个通用榜单的高分模型直接上生产，结果在业务场景里表现一塌糊涂。后来才想明白：评价LLM的本质，是评价它在你的任务分布上的表现，而不是它在别人榜单上的排名。

所以评价体系要分三层来看：

• 基础能力层：语言理解、知识储备、推理、指令遵循。这是模型的“底子”，决定了能力上限。
• 任务适配层：在你的具体场景（RAG问答、Agent工具调用、代码生成、结构化抽取）里能不能干活。
• 工程可用层：延迟、成本、稳定性、上下文长度、并发能力。这层最容易被忽略，但往往是一票否决项。

很多人只盯着第一层，看几个Benchmark分数就下结论，这是典型的“纸上谈兵”。一个模型MMLU考了85分，但你的RAG场景里它老是忽略检索到的上下文、自己编答案，那对你来说它就是不及格。

提示：评价LLM的第一步不是找榜单，而是把你的业务任务拆成可量化的评测集。没有评测集的评价，都是感觉。

2. 主流Benchmark到底测了什么，又漏了什么

2.1 常见Benchmark的能力映射

Benchmark是快速筛选模型的工具，但必须知道每个榜单背后测的是什么能力，否则容易被分数误导。下面这张表是我自己整理的能力映射，实际选型时经常翻出来看：

这张表的关键用法是：先明确你的任务需要哪些能力，再去看对应榜单，而不是看总分。比如你做Agent，那BFCL和IFEval的权重应该远高于MMLU。

2.2 Benchmark的三大陷阱

第一个陷阱是数据污染。很多榜单题目在训练数据里出现过，模型是“背答案”而不是“会做题”。判断方法很简单：看模型在榜单上的分数是否明显高于同规模同架构的模型，如果高得离谱，大概率有污染。我一般会自己构造一批“榜单风格但全新”的题目做交叉验证。

第二个陷阱是选择题偏差。MMLU这类选择题，模型可以靠排除法、靠选项分布规律拿分，实际生成能力可能很差。所以选择题高分不等于生成能力强，一定要补生成类评测。

第三个陷阱是裁判模型偏见。用GPT-4当裁判评MT-Bench，会系统性偏好“像GPT-4风格”的回答，长回答、结构化回答容易拿高分，哪怕内容空洞。我实测过，把同样内容的回答拆成更多要点，裁判分数会涨。所以裁判评测只能做参考，不能当唯一标准。

2.3 自建评测集才是王道

说了这么多榜单的局限，结论其实很明确：通用Benchmark用来初筛，自建评测集用来定稿。

自建评测集的流程我一般是这样的：

1. 任务采样：从真实业务日志里采样200-500条，覆盖高频场景和边界case。
2. 标注标准答案：能自动判定的（分类、抽取、格式）写规则判定；不能自动判定的（生成质量）人工标注或双人交叉标注。
3. 分层设计：简单/中等/困难各占一定比例，避免全是简单题导致分数虚高。
4. 留出集：永远留20%不参与调优，只用于最终评估，防止过拟合。

这套流程走下来，虽然前期投入大，但后面每次换模型、改Prompt、调RAG，都能快速拿到可信的对比数据，长期看非常划算。

3. 分场景评价：RAG、Agent、指令遵循各有各的坑

3.1 RAG场景：别只看答案对不对

RAG的评价是最容易做偏的。很多人只看最终答案对不对，但RAG是个流水线，检索和生成任何一环出问题，最终答案都会错。所以必须分环节评价。

检索环节看这几个指标：

• Recall@K：正确答案所在的文档有没有被召回。这是RAG的生命线，召回不到，生成再强也没用。
• Precision@K：召回的文档里有多少是相关的。太多无关文档会干扰生成。
• 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单价算。

4.3 稳定性与一致性

这个最玄学但最要命。同一个Prompt，同一个模型，不同时间调用结果可能不一样。原因包括：服务端负载、版本悄悄更新、采样随机性。

我的应对方法：

• 固定随机种子（如果API支持），减少采样波动。
• 关键任务用低温度，牺牲一点多样性换稳定性。
• 定期回归测试，用固定评测集跑，发现分数突然下降就排查是不是模型版本变了。
• 多模型备份，主模型出问题时能快速切换。

提示：生产环境一定要做模型版本的“金丝雀发布”，新版本先小流量跑，对比老版本指标，没问题再全量。直接全量切换，出问题就是事故。

5. 一套可落地的LLM评价流程

5.1 评价流程五步走

把前面所有内容串起来，我实际用的评价流程是这样的：

1. 明确任务与指标：先写清楚要评什么任务，成功标准是什么，对应哪些指标。
2. 构建评测集：通用榜单初筛 + 自建评测集定稿，自建集覆盖正常/边界/困难case。
3. 自动化评测：能自动判定的写脚本，不能的用裁判模型+人工抽检。
4. 工程指标实测：延迟、吞吐、成本、稳定性，用真实流量或压测数据。
5. 综合决策：按任务权重加权，选出综合最优，而不是单项最高。

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 常见问题速查表

6.4 几个独家避坑技巧

技巧一：用“对抗样本”测鲁棒性。在评测集里加入一些故意刁难的case，比如错别字、语序颠倒、无关信息干扰，看模型能不能稳住。真实用户输入往往不规范，鲁棒性比“标准题”得分更重要。

技巧二：关注“拒答率”。模型该拒答时拒答（比如问它不知道的事），不该拒答时不拒答（比如正常问题）。拒答率异常高或异常低都是问题。我一般会单独统计这两类。

技巧三：长上下文要测“中间遗忘”。很多模型号称支持128K，但信息放在中间就找不到。测试方法：把关键信息放在长文本的不同位置，看模型能不能都找到。实测很多模型是“两头强中间弱”。

技巧四：多轮对话要测“指令漂移”。聊了几轮之后，模型是否还记得最初的约束。比如第一轮说“之后都用JSON回答”，第五轮还遵守吗。这个在生产环境很关键。

技巧五：成本要算“失败成本”。模型失败一次，可能要重试、要人工介入、要用户流失。这些隐性成本往往比Token成本高得多。所以稳定性差的模型，实际成本远高于账面。

7. 评价体系的持续迭代

LLM评价不是一次性工作，而是持续过程。模型在更新，业务在变化，评价体系也要跟着迭代。

我的做法是建一个评测看板，每次模型切换、Prompt调整、RAG改动，都跑一遍固定评测集，记录指标变化。时间长了就能看出趋势：哪些改动有效，哪些模型在退步，哪些场景一直是短板。

另外，线上指标和离线评测要打通。离线评测分数高，线上业务指标（点击率、解决率、满意度）也要跟着涨，否则说明评测集和真实目标脱节了。我一般会定期做离线-线上相关性分析，相关性低就调整评测集。

最后分享一个我自己的体会：评价LLM这件事，工具和方法都是次要的，最重要的是想清楚“好”的定义。你的业务里，什么算好？是准确率、是速度、是成本、还是用户体验？定义清楚了，评价体系自然就出来了。定义不清楚，用再多榜单也是瞎评。

这个方向后续还可以扩展的点很多，比如多模态模型的评价、Agent长任务的评价、以及如何用LLM自动生成评测集。每个都值得单独展开聊。