简而言之：首先，针对你的用例定义“良好”的标准，然后使用具有代表性的、版本化的提示和极端情况进行测试。将自动化指标与人工评分标准相结合，同时进行对抗安全性和提示注入检查。如果成本或延迟限制成为关键因素，则通过每英镑成本的任务成功率和 p95/p99 响应时间来比较模型。
要点总结：
问责制：明确指定负责人，保留版本日志，并在任何提示或模型更改后重新运行评估。
透明度：在开始收集分数之前，写下成功标准、限制条件和失败成本。
可审计性：维护可重复的测试套件、标记的数据集和跟踪的 p95/p99 延迟指标。
可争议性：对有争议的结果采用人工评审标准和明确的申诉途径。
抗滥用能力：红队提示注入、敏感话题，以及过度拒绝保护用户。
如果你要为产品、研究项目，甚至是内部工具选择一个模型，你不能仅仅因为“听起来很智能”就直接发布（参见OpenAI 评估指南和NIST AI RMF 1.0 ）。否则，你最终得到的可能就是一个自信满满地解释如何用微波炉加热叉子的聊天机器人。😬
您可能还想阅读以下文章：
🔗人工智能的未来：塑造下一个十年的趋势——
值得关注的关键创新、就业影响和伦理问题。
🔗为初学者讲解生成式人工智能中的基础模型
了解它们是什么、如何训练以及为什么它们很重要。
🔗人工智能如何影响环境和能源使用？
探索排放量、电力需求以及减少碳足迹的方法。
🔗如今，AI 如何通过图像放大技术使图像更清晰？
了解模型如何增加细节、去除噪点并清晰地放大图像。
1）“好”的定义（视情况而定，这没关系）🎯
在进行任何评估之前，先确定成功的标准。否则，你会衡量一切却一无所获。这就像拿着卷尺去评判蛋糕比赛一样。当然，你会得到一些数字，但它们并不能告诉你太多东西😅
阐明：
-
用户目标：摘要、搜索、写作、推理、事实提取
-
失败成本：错误的电影推荐很有趣；错误的医疗指示……一点也不好笑（风险框架： NIST AI RMF 1.0 ）。
-
运行时环境：设备端、云端、防火墙后、受监管环境
-
主要限制因素：延迟、每次请求成本、隐私、可解释性、多语言支持、语气控制
一款模型在某项工作中表现“最佳”，但在另一项工作中可能却会是一场灾难。这并非自相矛盾，而是事实。🙂
2）一个稳健的AI模型评估框架是什么样的🧰
没错，这部分经常被人忽略。他们随便找个基准测试工具，运行一次就完事了。一个完善的评估框架应该具备一些共同的特征（实用工具示例： OpenAI Evals / OpenAI Evals 指南）：
-
可重复性——下周你可以再次运行，并相信对比结果。
-
代表性——它反映了您的实际用户和任务（而不仅仅是琐碎的信息）。
-
多层级——结合自动化指标、人工审核和对抗性测试
-
可操作性——结果会告诉你应该改进什么，而不仅仅是“分数下降了”。
-
防篡改——避免“应试教学”或意外泄漏
-
注重成本——评估本身不应该让你破产（除非你喜欢自讨苦吃）。
如果你的评估经不起队友的质疑，比如“好吧，但要把它应用到生产环境中”，那就说明评估还没完成。这就是所谓的“氛围检验”。.
3) 如何从用例切片入手评估人工智能模型🍰
这里有一个可以节省大量时间的技巧：将用例分解成多个部分。
不要“评估模型”，而是：
-
意图理解（是否理解了用户想要的内容）
-
检索或上下文使用（是否正确使用了提供的信息）
-
推理/多步骤任务（各步骤之间是否保持连贯性）
-
格式和结构（是否符合说明）
-
安全性和策略一致性（是否避免不安全内容；参见NIST AI RMF 1.0 ）
-
语气和品牌声音（听起来是否符合你的预期）
这使得“如何评估人工智能模型”这门课感觉不像是一场大型考试，而更像是一系列有针对性的测验。测验虽然烦人，但还能应付。😄
4) 线下评估基础知识——测试集、标签以及其他重要的细节📦
离线评估是指在用户接触任何内容之前进行受控测试（工作流程模式： OpenAI 评估）。
构建或收集一套真正属于你自己的测试套件
一套好的测试套件通常包括：
-
黄金范例：您引以为豪的理想成果
-
特殊情况：含糊不清的提示、杂乱无章的输入、意外的格式
-
故障模式探测：诱发幻觉或不安全回复的提示（风险测试框架： NIST AI RMF 1.0 ）
-
覆盖范围广泛：涵盖不同的用户技能水平、方言、语言和领域。
如果你只用“干净”的提示信息进行测试，模型看起来会很棒。但你的用户就会出现拼写错误、句子不完整，以及愤怒点击的情况。这就是现实。.
标签选择（又称：严格程度）
您可以将输出标记为：
-
二元制：通过/失败（快速、严苛）
-
序数评分：1-5 分（细致、主观）
-
多属性：准确性、完整性、语气、引用使用等（最佳，但速度较慢）
多属性评价对很多团队来说都是最佳方案。这就像品尝食物时，要将咸度和口感分开来判断。否则，你只会说“不错”然后耸耸肩。.
5）不会说谎的指标——以及有点说谎的指标📊😅
指标固然重要……但它们也可能像一颗闪光弹。闪闪发光，无处不在，而且难以清理。.
常用度量衡族
-
准确率/精确匹配：非常适合提取、分类和结构化任务。
-
F1 / 精确率 / 召回率：当漏掉某些东西比额外的噪声更糟糕时，这些指标就很有用（定义： scikit-learn 精确率/召回率/F-score ）
-
嵌入相似度：有助于语义匹配，可以奖励错误但相似的答案
-
任务成功率：“用户是否获得了他们所需的东西”——定义明确时的黄金标准
-
约束合规性：符合格式、长度、JSON 有效性、模式一致性
关键点
如果你的任务是开放式的（比如写作、推理、在线客服），那么用单一数字来衡量可能不太准确。并非毫无意义，只是不太可靠。用尺子测量创造力当然可行，但你会觉得这样做很傻。（而且你很可能会戳到自己的眼睛。）
因此：使用指标，但要将其与人工审查和实际任务结果挂钩（基于 LLM 的评估讨论的一个例子 + 注意事项： G-Eval ）。
6) 对比表 - 最佳评估选项（包含一些小瑕疵，因为生活总有瑕疵）🧾✨
这里提供一份实用的评估方法清单。您可以根据实际情况灵活组合使用。大多数团队都会这样做。.
| 工具/方法 | 观众 | 价格 | 为什么有效 |
|---|---|---|---|
| 手工构建的提示测试套件 | 产品 + 工程 | $ | 目标非常明确，能快速发现回归问题——但你必须一直维护它🙃（入门工具： OpenAI Evals ） |
| 人工评分小组 | 能够抽出审稿人的团队 | $$ | 最适合展现语气、细微差别，以及“人类是否会接受这种风格”，略带混乱的程度取决于评论者。 |
| 法学硕士担任评委（附评分标准） | 快速迭代循环 | $-$$ | 快速且可扩展，但可能带有偏见，有时会根据感觉而非事实进行评分（研究 + 已知的偏见问题： G-Eval ） |
| 对抗性红队演练冲刺 | 安全与合规 | $$ | 发现棘手的故障模式，尤其是即时注入——感觉就像在健身房进行压力测试（威胁概述： OWASP LLM01 即时注入/ OWASP LLM 应用十大威胁） |
| 合成测试生成 | 轻数据团队 | $ | 覆盖面很广，但合成提示语可能过于整齐、过于客气……用户并不客气。 |
| 使用真实用户进行 A/B 测试 | 成熟产品 | $$$ | 最清晰的信号——也是指标波动时最令人情绪紧张的信号（经典实用指南： Kohavi 等人，《网络上的受控实验》 ） |
| 基于检索结果的评估（RAG 检查） | 搜索 + 问答应用 | $$ | 措施“正确使用上下文”，减少幻觉评分膨胀（RAG 评估概述： RAG 评估：一项调查） |
| 监测+漂移检测 | 生产系统 | $$-$$$ | 随着时间的推移，它会逐渐降低性能——平时默默无闻，但总有一天会帮到你😬（漂移概述：概念漂移调查（PMC） ） |
请注意，价格故意设置得比较模糊。它们取决于规模、工具以及您意外触发的会议数量。.
7）人工评估——人们往往忽视的秘密武器👀🧑⚖️
如果只进行自动化评估，你会错过：
-
语气不搭调（“为什么这么尖酸刻薄”）
-
看似流畅的细微事实错误
-
有害的暗示、刻板印象或尴尬的措辞（风险 + 偏见框架： NIST AI RMF 1.0 ）
-
遵循指令却失败，但听起来仍然“聪明”
制定具体的评分标准（否则评审员会随意发挥）
不恰当的评分标准：“实用性”
更恰当的评分标准：
-
正确性：根据提示和上下文，事实准确无误
-
完整性：涵盖了所有必要要点，且不冗长赘述。
-
清晰度：易读、结构清晰、避免混淆
-
政策/安全：避免限制性内容，妥善处理拒绝情况（安全框架： NIST AI RMF 1.0 ）
-
风格：与声音、语调和阅读水平相匹配
-
忠实：不捏造未经证实的信息来源或说法。
此外，有时也应该进行评分者间信度检验。如果两位评审员意见不一致，这不是“人的问题”，而是评分标准的问题。通常情况下（评分者间信度基础知识： McHugh 论 Cohen's kappa ）。
8) 如何评估人工智能模型的安全性、鲁棒性以及“唉，用户”体验🧯🧪
这是发布前需要做的——然后还要继续做，因为互联网永不停歇。.
稳健性测试包括
-
拼写错误、俚语、语法错误
-
很长的提示和很短的提示
-
相互矛盾的指示（“要简洁，但要包含所有细节”）
-
用户改变目标的多轮对话
-
提示注入尝试（“忽略之前的规则……”）（威胁详情： OWASP LLM01 提示注入）
-
需要谨慎拒绝的敏感话题（风险/安全框架： NIST AI RMF 1.0 ）
安全评估不仅仅是“它是否拒绝”
一个好的模型应该：
-
明确、冷静地拒绝不安全的请求（指导框架： NIST AI RMF 1.0 ）
-
在适当情况下提供更安全的替代方案
-
避免过度拒绝无害的查询（误报）
-
（在允许的情况下）通过提问澄清来处理含糊不清的请求。
过度拒绝是一个真正的产品问题。用户不喜欢被当作可疑的小妖精对待。🧌（即使他们真的是可疑的小妖精。）
9) 成本、延迟和实际运营情况——每个人都会忽略的评估💸⏱️
即使某个型号“很棒”，如果它运行缓慢、价格昂贵或操作不稳定，它仍然可能不适合你。.
评价：
-
延迟分布（不仅仅是平均值——p95 和 p99 也很重要）（为什么百分位数很重要： Google SRE 监控工作簿）
-
每次成功任务的成本（而非单独计算每个代币的成本）
-
负载下的稳定性（超时、速率限制、异常尖峰）
-
工具调用可靠性（如果它使用函数，它是否运行正常）
-
输出长度倾向（有些模型冗长，而冗长会增加成本）
性能稍逊但速度快一倍的车型在实际应用中往往能胜出。这听起来显而易见，但人们却常常忽略。这就好比买了一辆跑车只用来买菜，然后抱怨后备箱空间不够一样。.
10) 一个简单的端到端工作流程，您可以复制（并进行调整）🔁✅
评估人工智能模型而不陷入无休止实验的实用流程
-
定义成功：任务、约束条件、失败成本
-
创建一个小型“核心”测试集：包含 50-200 个反映真实使用情况的示例
-
添加边缘和对抗集：注入尝试、模糊提示、安全探测（提示注入类： OWASP LLM01 ）
-
运行自动化检查：格式检查、JSON 有效性检查、基本正确性检查（尽可能）。
-
运行人工审核：抽取各类别样本输出，并使用评分标准进行评分
-
权衡利弊：质量 vs 成本 vs 延迟 vs 安全性
-
试点阶段：有限发布：A/B 测试或分阶段推广（A/B 测试指南： Kohavi 等人）
-
生产环境中的监控：漂移、回归、用户反馈循环（漂移概述：概念漂移调查（PMC） ）
-
迭代：更新提示、检索、微调、护栏，然后重新运行评估（评估迭代模式： OpenAI 评估指南）
保留版本控制的日志。这并非为了好玩，而是因为未来的你会一边喝着咖啡，一边喃喃自语“发生了什么变化……”时感谢自己。☕🙂
11）常见陷阱（又称：人们无意中欺骗自己的方式）🪤
-
以测试为导向的训练：你不断优化提示，直到基准测试结果完美，但用户体验却很糟糕。
-
评估数据泄露：测试提示出现在训练或微调数据中（糟糕）
-
单一指标崇拜：追求一个无法反映用户价值的分数。
-
忽略分布变化：用户行为改变，模型悄然退化（生产风险框架：概念漂移调查（PMC） ）
-
过分强调“聪明才智” ：即使推理再巧妙，如果破坏格式或捏造事实，也毫无意义。
-
未测试拒绝质量：“不”可能是正确的，但用户体验仍然很糟糕。
另外，要小心演示版。演示版就像电影预告片，只展示精彩片段，掩盖慢节奏的部分，有时还会配上煽情的音乐。🎬
12) 人工智能模型评估方法总结🧠✨
评估人工智能模型并非靠单一分数，而是一顿营养均衡的餐食。你需要蛋白质（正确性）、蔬菜（安全性）、碳水化合物（速度和成本），当然，有时也需要甜点（音调和愉悦感）🍲🍰（风险框架： NIST AI RMF 1.0 ）
如果你什么都记不住的话：
-
明确“好”在你的用例中意味着什么
-
使用具有代表性的测试数据集，而不仅仅是著名的基准测试集。
-
将自动化指标与人工评分标准相结合
-
测试鲁棒性和安全性，就像用户具有对抗性一样（因为有时……他们确实如此）（提示注入类别： OWASP LLM01 ）
-
评估时应考虑成本和延迟，而不是事后才考虑（为什么百分位数很重要： Google SRE 工作簿）
-
发布后的监测——模型会发生变化，应用程序会不断演变，人们会变得更有创造力（变化概述：概念变化调查（PMC） ）
这就是评估人工智能模型的方法，它能确保产品上线后，用户开始做出各种不可预测的行为时，模型依然有效。而这种情况总是会发生的。🙂
常问问题
评估人工智能模型在实际产品中的应用的第一步是什么？
首先，明确“好”在你的具体应用场景中意味着什么。阐明用户目标、失败的代价（低风险与高风险），以及模型将在哪些环境中运行（云端、设备端、受监管环境）。然后列出一些硬性限制，例如延迟、成本、隐私和语调控制。如果没有这些基础，即使你做了大量的测量，最终也可能做出错误的决策。.
如何构建一个真正反映我用户群体的测试集？
构建一个真正属于你自己的测试集，而不仅仅是一个公开的基准测试集。测试集应包含你引以为豪的优秀示例，以及包含拼写错误、不完整句子和模糊请求等真实场景下常见的嘈杂提示。添加一些极端情况和故障模式探测，以诱发异常或不安全的响应。测试集应涵盖技能水平、方言、语言和领域的多样性，以确保测试结果在生产环境中不会崩溃。.
我应该使用哪些指标，哪些指标可能会产生误导？
根据任务类型选择合适的指标。精确匹配和准确率适用于提取和结构化输出，而精确率/召回率和 F1 值则适用于漏掉某些信息比额外噪声更糟糕的情况。像 BLEU/ROUGE 这样的重叠指标可能会误导开放式任务，而嵌入相似度指标可能会奖励“错误但相似”的答案。对于写作、支持或推理任务，应将这些指标与人工审核和任务成功率结合起来使用。.
我应该如何构建评估流程，才能使其具有可重复性和生产级标准？
一个稳健的评估框架应具备可重复性、代表性、多层次性和可操作性。将自动化检查（格式、JSON 有效性、基本正确性）与人工评分和对抗性测试相结合。通过避免数据泄露和“针对测试进行训练”来确保其防篡改能力。保持评估成本可控，以便能够频繁地重复运行，而不仅仅是在发布前运行一次。.
如何才能在不陷入混乱的情况下进行有效的人工评估？
使用具体的评分标准，避免审阅者随意发挥。评分内容应涵盖正确性、完整性、清晰度、安全/政策处理、风格/语气匹配度以及忠实性（不捏造事实或来源）。定期检查评分者间的一致性；如果审阅者意见持续不一致，则评分标准可能需要改进。人工审阅对于语气不匹配、细微的事实错误以及未能遵循指示等问题尤为重要。.
如何评估安全性、稳健性和快速注射风险？
测试时要包含一些“哎，用户啊”的输入：拼写错误、俚语、相互矛盾的指令、过长或过短的提示，以及需要多次更改目标的情况。测试中还要包含一些提示注入尝试，例如“忽略之前的规则”，以及需要谨慎拒绝的敏感话题。良好的安全性能不仅仅是拒绝——还要清晰地拒绝，在适当的时候提供更安全的替代方案，并避免过度拒绝那些无害的查询，以免损害用户体验。.
如何评估成本和延迟才能使其符合实际情况？
不要只关注平均值，还要追踪延迟分布，尤其是 p95 和 p99。评估每次成功任务的成本，而不是单独评估每个令牌的成本，因为重试和随机输出可能会抵消节省的成本。测试负载下的稳定性（超时、速率限制、峰值）以及工具/函数调用的可靠性。性能稍差但速度快一倍或稳定性更高的型号，可能是更好的产品选择。.
评估人工智能模型的简单完整的工作流程是什么？
首先定义成功标准和约束条件，然后创建一个小型核心测试集（大约 50-200 个示例），以模拟实际使用情况。添加边缘测试集和对抗测试集，以验证安全性并进行注入测试。运行自动化检查，然后对输出结果进行抽样，以便人工评分。比较质量、成本、延迟和安全性，进行小范围试点或 A/B 测试，并在生产环境中监控性能变化和回归情况。.
团队在模型评估中最常犯的错误有哪些？
常见的陷阱包括：为了在基准测试中取得好成绩而优化提示信息，却牺牲用户体验；将评估提示信息泄露到训练或微调数据中；以及盲目崇拜无法反映用户价值的单一指标。团队还会忽略分布变化，过分强调“智能”而非格式的合规性和忠实度，并跳过拒绝质量测试。演示可能会掩盖这些问题，因此应依赖结构化的评估，而不是精彩片段集锦。.
参考
-
OpenAI - OpenAI 评估指南- platform.openai.com
-
美国国家标准与技术研究院 (NIST) -人工智能风险管理框架 (AI RMF 1.0) - nist.gov
-
OpenAI - openai/evals（GitHub 代码库） - github.com
-
scikit-learn - precision_recall_fscore_support - scikit-learn.org
-
计算语言学协会（ACL 文集） - BLEU - aclanthology.org
-
计算语言学协会（ACL 文集） - ROUGE - aclanthology.org
-
arXiv - G-Eval - arxiv.org
-
OWASP - LLM01：提示注入- owasp.org
-
OWASP - OWASP Top 10 for Large Language Model Applications - owasp.org
-
斯坦福大学- Kohavi 等人，“网络上的受控实验” - stanford.edu
-
arXiv - RAG 评估：一项调查- arxiv.org
-
PubMed Central (PMC) -概念漂移调查 (PMC) - nih.gov
-
PubMed Central (PMC) - McHugh 论 Cohen's kappa 系数- nih.gov
-
Google - SRE 监控工作簿- google.workbook