企业官网建设流程全解析

最近圈子里流传一组"13 张口袋指南信息卡"，来自一位专门做 LLM 评估的资深实践者。他把一整门 AI 评估课程压缩成了 13 张卡片，每张讲透一个评估相关的决策点，从指标选择到评估集构建，再到模型当裁判的坑，基本覆盖了 LLM 应用开发中最容易被忽略、也最容易翻车的那部分。我把这 13 张卡一张张拆开看了一遍，又结合自己跑评估脚本踩过的坑，整理成一篇能直接照着做的东西。这篇文章不是课程笔记的复述，而是站在实操角度，告诉你每张卡到底在说什么、为什么这么说、以及你用的时候要注意什么。无论你是刚开始做 RAG 应用、微调模型，还是已经在生产环境里维护某条 Agent 链路，这套东西都值得留一份。

1. 整体设计与思路拆解：为什么评估比提示词工程更值得投入

先说个反直觉的结论：大部分 LLM 应用项目死在评估上，而不是死在 prompt 写得不好上。很多团队花几周调 prompt，觉得输出变好了，结果一换数据分布立刻崩盘，原因就是没有一套可靠的度量手段。这位实践者把课程浓缩成口袋卡，本质上就是在对抗这种"凭感觉开发"。

1.1 卡片体系解决的核心矛盾

LLM 应用开发和传统软件开发的最大区别在于：传统软件的行为是确定性的，函数输入输出可预期，你写单元测试就能锁定行为；而 LLM 的行为是概率性的，同一个 prompt 同一批参数，跑两次结果可能不一样。这种不确定性导致开发者很容易陷入两个极端：要么完全不评估，靠肉眼看几个样例就上线；要么过度评估，堆了二十个指标，结果没有一个是真能指导决策的。

13 张卡片的组织逻辑，基本就是按"开发一个 LLM 功能"的时间顺序来的：先定指标，再建评估集，然后选评估方式（人工、模型、脚本），最后建迭代循环。每一张卡对应一个具体决策点，比如"这个任务该用什么指标""评估集最少要多少条""LLM 当裁判时要不要交换顺序"。这种编排方式的好处是，它没有停留在理论层面，而是直接把决策时机嵌入了工作流。你不是先把所有知识学完再动手，而是做到哪一步、遇到哪个问题，就抽出对应那张卡看一眼。

1.2 为什么做成"卡片"而不是一篇长文

我一开始也怀疑，13 张卡能装下什么？一门课的信息密度怎么会这么高。仔细看才发现，卡片式的载体恰恰是经过设计的：每张卡都强制约束自己只讲一个决策点，不超过一页纸，背后是一门课的内容做支撑。这有点像技术书里的速查表——它的价值不在于替代你理解原理，而在于当你在代码里卡住的时候，扫一眼就能想起关键约束。

我自己用下来的体会是，评估知识最大的问题不是难懂，而是容易忘。评估集污染、位置偏差、判断漂移这些概念，看的时候觉得记住了，真正写评估脚本的时候根本想不起来。把关键原则压缩成巴掌大的卡，贴在工位或者存在手机里，实际开发时随时能翻，比存一份几十页的文档有用得多。这也是我把这篇文章标成"实操向"的原因：我会结合卡片内容，把每一类决策点的落地方式和坑位都展开讲一遍。

2. 评估指标与评估集构建：先定尺子，再量身材

2.1 别再一出场就堆指标了

很多刚接触评估的人喜欢把能想到的指标全加上：准确率、召回率、F1、BLEU、ROUGE、BERTScore，做一个"全面评估"。看着很专业，实际上你根本不知道看哪个。

这套卡片里反复强调一个原则：指标服务于决策。你先要明确一个问题——这个评估跑完之后，你要做什么决定？决定只有几类：这个版本能不能上线；prompt 改完是变好了还是变差了；微调出来的模型要不要替换当前模型。不同的决定对应不同的指标。

举个具体例子。如果你在做意图识别，准确率有意义；如果你在做检索增强生成（RAG），准确率就没什么用，因为你更关心"答案有没有被忠实生成"和"引用的内容能不能支撑答案"。这两件事用准确率是测不出来的，得换成交集覆盖度、引用命中率、忠实度这类任务指标。

这个表不是绝对标准，但它说明一个道理：指标要跟任务结构对齐，而不是跟论文里常见的榜单对齐。

2.2 评估集的最小可用规模

卡片里有个特别实用的建议：评估集最开始不需要一两千条，三四十条精心构造的样本就够了。很多人听到这个数字会怀疑，这么少能有统计意义吗？其实这里的逻辑不是让评估集在统计上代表整个人类语料，而是让它在行为上约束你的迭代方向。

三十到五十条样本，如果你每一条都看过，你的评估结果就是可解释的。模型改完以后，你能具体说出它修好了哪一类问题、又打破了哪一类行为。这个可解释性在早期开发阶段，比置信区间重要得多。等系统趋于稳定，再逐步把评估集扩充到几百条、上千条，那时候统计意义才变得关键。

构造这几十条样本有个技巧：不要平均用力。按"正常情况、边界情况、容易混淆的情况、完全不该响应的情况"四类来构造，尤其是最后一类，大部分人都会漏掉。一个客服助手如果用户问"我要自杀怎么办"它回答得再流畅，也不算合格；一个代码助手如果用户输入 SQL 注入语句它照抄不误，上线就是事故。这些负向样本在评估集里最能暴露问题。

2.3 构建评估集的三个数据陷阱

• 只有正样本：评估集全是理想输出，模型再差也能拿高分。务必混入负样本、偏斜样本、对抗样本。
• 评估集和开发集重叠：如果你反复用同一批数据调试 prompt，模型会在这些样本上过拟合。卡片里给了一个简单的规则：评估集一旦用过就不要改，要观察趋势就新建另一批。
• 用长度或格式作弊：有些模型在"更详细"这种提示下输出明显变长，人眼看觉得更好，但实际内容质量没提升。评估时一定要避免只用"像不像"这种模糊标准，要落到具体检查点上。

2.4 评估集的大小与版本管理

评估集不是一次建完就永远不变的。随着业务功能演进，你需要不断追加新类型的样本。我个人的做法是：每两周统一过一次评估集，看哪些样本已经失去区分度（所有模型都能答对），哪些样本因为业务规则变化已经过时，然后做一次增删。评估集本身要纳入版本管理，每次调整都要记录。不然你前后对比跑分，根本说不清分数变化是因为模型变了还是评估集变了。

3. 核心机制：LLM 当裁判、人工评估与半自动化流程

3.1 为什么需要用模型来评估模型

评估生成类任务的输出质量一直是个老大难问题。传统指标如 ROUGE 只能衡量字面重合，一个意思说得更流畅、更简洁但用词全变，得分就会很难看。所以这卡片里强调：很多场景要用一个更强的模型来给输出打分，也就是"模型当裁判"。

模型当裁判的基本思路是：把待评输出和评分标准一起发给一个相对更强的模型，让它按你给的分值档位打分，或者让它对比两个输出谁更好。这套方法跑起来省人力，而且一致性比人高——同一个 prompt 早上评和下午评，模型的结果基本稳定，人可不一定。

但这里有个大坑，而且我实测下来非常明显：模型裁判有偏见。

3.2 模型裁判的四大偏见与缓解方法

• 位置偏见：把输出 A 放前面、输出 B 放后面，模型经常倾向于选放后面的。缓解办法是换顺序评两遍，或者让模型先输出理由再给结论。
• 冗长偏见：更长的回答更容易得高分，哪怕内容啰嗦。缓解办法是在评分标准里明确"简洁性"这一项，并要求模型对每个维度单独打分。
• 自我偏见：模型更偏爱和自己风格相近的输出。这个很难消除，只能通过多次采样、用不同的裁判模型交叉验证来降低。
• 分数漂移：同一批输出，上午评和下午评可能给分尺度不同。缓解办法是每次给模型带上标准锚点示例（比如给出一个 5 分样例和一个 3 分样例，作为参考系）。

卡片里特别强调的一个点就是：任何模型打的分数，都不要直接用，要先做"取样抽验"。也就是抽一小部分模型评分结果，拿给人看，确认模型打分和人的判断一致。这个步骤叫"评估的评估"，听起来麻烦，但能省掉后面无数个被错误分数误导的夜晚。

3.3 人工评估用在什么地方

模型当裁判再强，有些任务也必须人来看。我总结下来大概三类：

• 事实正确性：涉及具体事实、数字、法规的答案，模型裁判只能判断"像不像正确答案"，无法判断"是不是正确答案"。
• 安全与合规：是否包含歧视、伤害性表述，是否绕过安全边界——这类必须人工复核，不能交给纯模型流水线。
• 主观偏好：比如文案风格、语气调性、创意质量，目标用户群体和模型本身的偏好未必一致。

这里有一个常见误区：人工评估就是叫几个人来给结果打分。不对。更有效的方式是让评估者做"对比判断"——两个输出放一起，问哪个更好，以及为什么。对比判断比绝对打分稳定得多。两个样本，一个 4 分一个 5 分，隔天可能就反过来了；但如果让评审说"比起方案 A 我更喜欢方案 B，因为 B 更简洁"，这个判断就稳定得多。这也是口袋卡里反复出现的一个技巧——只要可能，用对比代替打分。

3.4 半自动化评估的实际工作流

把人工和模型组合起来，是我现在最常用的一套流程：

1. 模型裁判跑全量评估集，给出分数和理由。
2. 把分数处于边界区间（比如中间档位）的样本抽出来。
3. 人工只看这些边界样本，做对比判断或修正分数。
4. 把人工修正后的结果重新并回评估结果，计算最终指标。

这么做的好处非常明显：全量自动跑省时间，人工只需要关注最有争议的部分，而真正影响决策的恰恰是这些边界样本。通过这种方式，人工工作量可以压缩到原来的十分之一，但评估质量仍然可控。

4. 实操流程与核心环节实现：从评估先行到迭代闭环

4.1 评估先行的开发工作流

这套课程里最有冲击力的一个主张是：先写评估，再写提示词。顺序反了，你的开发效率至少打折一半。

常规开发者拿到需求，第一反应是写 prompt、跑几个样例、看着不错就交付。这种做法的隐蔽问题在于：你看样例的时候，用的标准是你脑子里模糊的"好坏观"，它不稳定。你改了三版 prompt，每一版样例看起来都差不多，但你真的讲不清第三版好在哪里。

反过来做就能破这个局。接到需求后第一件事是建一个最小评估集（三五十条），再搭一条评估命令行工具，然后才开始写 prompt。每改一次 prompt，就跑一遍评估，让分数告诉你改得好不好。

拿我最近做过的一个项目举例。需求是从用户问题中抽取关键实体并映射到标准字段。我一开始就写了几十条"输入 → 期望输出"对，里面包括：

[ {"input": "帮我看看下周二的会议记录里提到了哪些客户", "expected": {"date": "下周二", "action": "查看会议记录", "object": "客户"}}, {"input": "周五之前把方案用邮件发给老张", "expected": {"date": "周五之前", "action": "发送邮件", "object": "方案", "recipient": "老张"}}, {"input": "市场部想要一份上个季度的数据汇总，顺便抄送给李姐", "expected": {"department": "市场部", "time": "上个季度", "type": "数据汇总", "recipient": ["李姐"]}} ]

然后写了一个简单的评估脚本，循环跑 prompt，对比输出，打分。再往后才是调 prompt。整个过程下来，我几乎不会出现"调了半天发现方向错了"的情况，因为每次改动都有分数反馈。

4.2 一个最小可跑的评估脚本

这里给一个精简的评估脚本结构，你可以直接拿去改。核心就是用测试样例集 + 调用模型 API + 判定器汇总结果。

import json import random # 模拟一个调用模型的函数，实际项目里替换成你的 API 调用 def call_model(prompt: str) -> str: # 这里填你的模型调用逻辑 return "客户A, 下周二, 查看会议记录" def run_eval(eval_file: str, prompt_builder, judge_score) -> dict: with open(eval_file, "r", encoding="utf-8") as f: cases = json.load(f) results = [] for case in cases: prompt = prompt_builder(case["input"]) output = call_model(prompt) score = judge_score(output, case["expected"]) results.append({"case": case, "output": output, "score": score}) passed = sum(r["score"] for r in results) / len(results) return {"num_cases": len(cases), "pass_rate": passed, "details": results} def prompt_builder(user_input: str) -> str: return f"从以下需求中抽取实体，输出 JSON：\n{user_input}" def judge_score(output: str, expected: dict) -> float: # 用一个简单规则：期望字段出现在输出文本中即得分 return 1.0 if expected["action"] in output else 0.0 # 使用示例 if __name__ == "__main__": result = run_eval("eval_cases.json", prompt_builder, judge_score) print(result["pass_rate"])

这个脚本非常简陋，但可以作为你评估体系的起点。实际项目中，judge_score 可以换成 LLM 裁判调用、规则校验或者两者的组合。再往后，你可以用类似的脚本做成持续集成里的一步——每次改动 prompt 或者模型版本，自动跑评估并把结果写到历史表格里。

4.3 迭代循环与防止过拟合评估集

有了评估集和评估脚本，就可以开始真正的迭代循环：

1. 跑基线评估，记录当前分数。
2. 挑一个你觉得有问题的地方，修改 prompt 或模型配置。
3. 重跑评估，比较分数变化。
4. 如果分数提升，保留这次改动；如果分数下降或不变，回退改动。

这套流程简单，但在实际运作时有一个特别隐蔽的问题：过拟合评估集。

你会不由自主地把注意力放在那几十条样本上，把 prompt 调到"完美适配"这些样本的状态。结果就是评估集分数很好看，一到真实场景就拉胯。防这个问题的办法有三个：一是定期换一批评估样本；二是评估集里故意留一部分"你从不调试"的样本，作为盲测集，定期看一次；三是不要追求评估集上的绝对满分，看到分数稳定在一个区间内就接受。这套防过拟合的思路，和传统机器学习里训练集验证集的思想完全一致，只是很多人到了 LLM 场景就忘了。

4.4 评估记录的重要性

口袋卡里还有一个点：每次评估的结果都要记录。这个记录不是为了应付汇报，而是为了让你能回答几个关键问题："上一版 prompt 在这个分类上的表现如何？""我们是从第几次迭代开始引入这个功能的？""当前模型比上一个模型在召回率上提升了多少？"

最简单的方式是维护一个 CSV 或表格，每次跑完评估就追加一行：日期、评估集版本、模型版本、prompt 版本、主要指标分数、备注。几个月后你会发现，这份记录比任何文档都有说服力。它能直接帮你定位问题：如果真实线上效果变差了，看评估记录就能知道是哪次改动之后开始劣化的。

5. 常见问题与排查技巧实录

5.1 评估集污染：分数变高是假象

我踩过最深的坑就是评估集污染。当时在做某问答产品，评估集用的是一批从真实日志里采样的用户问题。结果某次版本更新之后，评估分数涨了 5 个点，我一度以为是 prompt 优化见效了。后来才发现，新版本的模型在训练时见过类似的问题样本，它的"记忆能力"让它在评估集上表现变好，但在真实新问题上的表现根本没有提升。

排查污染的方式很直接：准备一批"模型训练截止日期之后的真实问题"，就是保证模型不可能见过的样本，拿这批样本跑一遍对比测试。如果评估集上分数高、新鲜样本上分数低，那基本可以断定是污染。还有一种更隐蔽的污染形式：你在调试 prompt 的过程中，反复把评估集的样本喂给了对话上下文，模型会把评估集的分布模式学走。这种时候最好的方法就是定期更新评估集，加入新的真实问题。

5.2 Loss 下降但评估分不动的排查思路

微调模型时经常碰到：训练 loss 一直在降，但评估集分数几乎没变。这种情况先别急着认为是评估集设计得不好，大部分原因是训练分布和评估分布不一致。

比如你的训练数据来自日志里的历史问题，评估集是人工构建的、偏规范和完整的提问句式，两者分布差异大会导致模型在训练时学到的东西无法迁移到评估场景。排查步骤如下：

• 先检查训练样本里是否包含评估集同分布的样本。
• 再检查评估集条数是否太少，导致分数方差太大，看不出变化。
• 确认模型是否真的收敛——生成类任务要先测生成质量，不能只看分类头或者 loss 曲线。

如果你用的是现成的模型服务商，没有训练环节，那问题往往出在 prompt 上。这种时候我会把评估结果按错误类型拆开看：是格式错误、遗漏信息，还是幻觉内容。按错误类型分布来指导下一步，比看一个总分有效率得多。

5.3 模型裁判分数不稳定的处理办法

有一次我用某个商用模型做裁判，同一批评估样本跑了两次，分数波动超过 10%。排查发现两个问题：一是模型接口开启了随机采样参数（temperature 偏高），二是评分 prompt 没有给定分锚点。

处理办法有两个：把裁判模型的随机参数调到最低；给评分 prompt 增加锚点样例。也就是在评分 prompt 里明确写"5 分表示什么水平，看这个例子；3 分表示什么水平，看这个例子"。加了锚点之后，两次运行的分差从 10% 降到了 2% 以内。这也是卡片里提到的"judge 也要被校准"的实际案例。

5.4 一套排查速查表

这六种情况覆盖了我过去一年里遇到的绝大部分评估问题。里面有些是工具层面的，有些是流程层面的，但全部能通过"多问一句：这个分数能指导我做什么决策"来收敛。

5.5 三个卡片之外的个人补充

原课程浓缩的 13 张卡很全，但实际开发中我还有三个补充建议，是它没覆盖但确实重要的：

第一，评估脚本本身也要测试。你的评估逻辑如果写错了，比如评分 prompt 模板有笔误，那所有后续决策都会建立在错误数据上。我会先拿一批确定好坏的数据测试评估脚本，确认判定器本身没问题再投入使用。

第二，把评估结果可视化。不需要多高级，把历次评估的线画出来就行。一张趋势图能让你的记忆立刻聚焦在变化上，比一堆零散数字管用。

第三，团队里必须有一个人对评估结果负责。不是负责写代码，而是负责回答"这个指标代表了什么、为什么这个版本要为此牺牲性能"。评估如果没有 owner，最后就会沦为形式主义的跑分游戏。

个人体会：把评估当成产品功能来对待

我最初对 LLM 评估的理解很浅，以为就是跑几个指标，看看分数。直到做一个检索增强的问答系统时，线上反馈一团糟，评估分数却稳定在 90 分以上，才意识到评估体系本身是需要设计、维护和投入的产品功能。这 13 张口袋卡最棒的地方，不在于它教你用什么指标，而在于它逼你先想清楚评估到底在服务什么决策。每次改 prompt 之前、每次换模型之前、每次上线之前，先看一眼对应的卡，按它说的检查一遍，能挡掉绝大部分低级问题。

如果你现在手头正有一个 LLM 相关的项目，建议你别急着调 prompt，先花两小时建一批评估样本，再跑一个最简陋的评估脚本。就这一件事，能让你接下来的所有迭代都走在看得见的方向上。