1
00:00:00,100 --> 00:00:06,432
本内容改编自小山学堂《学 AI 产品，从入门到精通》，为二次演绎配音版。

2
00:00:06,382 --> 00:00:12,632
这一集是进阶篇的收官，讲一件最容易被跳过、但回报最高的事，评测。

3
00:00:12,632 --> 00:00:15,012
先说本集解决什么问题。

4
00:00:15,012 --> 00:00:18,762
没有评测的智能体开发，就像蒙眼开飞机。

5
00:00:18,762 --> 00:00:25,336
你修了用户甲反馈的问题，却可能悄悄破坏了用户乙、丙、丁依赖的功能。

6
00:00:25,336 --> 00:00:31,237
更糟的是，你根本不知道自己破坏了什么，直到下一波投诉涌来。

7
00:00:31,237 --> 00:00:37,151
这一集给你一套评测的搭建方法，以及三个几乎每个团队都会踩的坑。

8
00:00:37,151 --> 00:00:38,930
内容分三部分。

9
00:00:38,930 --> 00:00:54,703
第一部分讲评测体系怎么搭，从七个术语到三种评判器；第二部分讲三个几乎每个团队都会踩的坑，以及两次真实事故；第三部分讲一个检索增强的升级方案，把切块时丢掉的语境补回来。

10
00:00:54,703 --> 00:00:57,539
再说为什么产品经理要关心。

11
00:00:57,539 --> 00:01:02,984
因为评测的第一个价值不是测试，而是逼团队定义成功长什么样。

12
00:01:02,984 --> 00:01:08,729
当你写不出一条评测用例，往往说明你对这个任务的理解还不够清晰。

13
00:01:08,729 --> 00:01:17,720
写用例的过程会逼你回答最难的产品问题，用户到底想要什么结果，什么算好什么算不好，边界情况怎么处理。

14
00:01:17,720 --> 00:01:23,405
很多团队是在写评测的过程中，才理清了长期模糊的产品定义。

15
00:01:23,405 --> 00:01:25,797
还有一层更现实的考虑。

16
00:01:25,797 --> 00:01:28,020
评测的价值是复利的。

17
00:01:28,020 --> 00:01:35,676
前期每一分钟的投入，后期都会在回归测试、模型迁移和团队协作中持续产生收益。

18
00:01:35,676 --> 00:01:39,979
最好的开始时间是三个月前，次好的是现在。

19
00:01:40,130 --> 00:01:41,882
先统一语言。

20
00:01:41,832 --> 00:01:47,866
评测体系里有七个术语，理解了它们，你就掌握了整套体系的说话方式。

21
00:01:47,866 --> 00:01:55,126
第一个是任务，也就是一条测试用例，包含给智能体的输入，以及怎样算完成的成功标准。

22
00:01:55,126 --> 00:01:58,840
第二个是试验，同一个任务的一次执行尝试。

23
00:01:58,840 --> 00:02:04,453
因为模型输出有随机性，同一个任务要跑多次试验才有统计意义。

24
00:02:04,453 --> 00:02:10,150
第三个是评判器，也就是打分逻辑，决定一次试验算通过还是失败。

25
00:02:10,150 --> 00:02:18,599
第四个是记录，完整的执行轨迹，每一步推理、每一次工具调用、每一个中间结果，全部记下来。

26
00:02:18,599 --> 00:02:29,056
第五个是结果，指环境中的最终状态，不只看它说了什么，更看它实际做了什么，文件有没有正确修改，接口有没有正确调用。

27
00:02:29,056 --> 00:02:37,373
第六个是脚手架，运行评测的基础设施，负责创建沙箱、启动智能体、收集结果、调用评判器。

28
00:02:37,373 --> 00:02:46,484
第七个是套件，一组相关任务的集合，比如文件编辑能力套件，里面包含二十个不同难度的文件编辑任务。

29
00:02:46,484 --> 00:02:49,152
再看评测的三个价值阶段。

30
00:02:49,152 --> 00:02:54,068
早期，它迫使团队定义成功长什么样，测试反而是其次。

31
00:02:54,068 --> 00:03:09,164
中期，每次改提示词、换模型、调参数，都能在几分钟内知道改动对整体性能的影响，回归测试防止你在优化一个维度时破坏其他维度，变更验证让每一次决策都有数据支撑。

32
00:03:09,164 --> 00:03:23,623
后期，当新模型发布，有完善评测的团队几天内就能完成迁移，跑一遍套件确认性能不降就直接切换；没有评测的团队要花数周甚至数月手动验证，错过最佳窗口。

33
00:03:23,623 --> 00:03:28,130
关于从哪开始，建议很明确，先从二十条开始。

34
00:03:28,130 --> 00:03:30,919
不要等有几百条用例才动手。

35
00:03:30,919 --> 00:03:35,727
二十条精心设计的任务，就能覆盖你最核心的场景。

36
00:03:35,727 --> 00:03:43,287
一个有二十条评测的团队，比一个有零条但计划做五百条的团队，领先了一整个时代。

37
00:03:43,440 --> 00:03:48,221
评判器是评测系统的裁判，选错了，结果就不可信。

38
00:03:48,171 --> 00:03:52,654
生产环境的经验是三种组合使用，各取所长。

39
00:03:52,654 --> 00:03:57,102
第一种是代码评判器，用程序逻辑自动判定对错。

40
00:03:57,102 --> 00:04:07,630
方法包括字符串匹配、正则、语法树分析、单元测试通过与否、工具调用验证，也就是检查有没有调用正确的接口和参数。

41
00:04:07,630 --> 00:04:15,852
优点是速度快，毫秒级，成本几乎为零，结果完全客观可复现，适合放进自动化流水线。

42
00:04:15,852 --> 00:04:24,061
缺点是对合理变体过于严格，比如变量命名不同就判错，缺乏语义理解，也没法评判主观质量。

43
00:04:24,061 --> 00:04:32,318
它适合有明确正确答案的任务，代码能不能编译、接口返回值对不对、格式合不合规、计算准不准确。

44
00:04:32,318 --> 00:04:37,702
第二种是模型评判器，也就是让另一个模型按评分标准打分。

45
00:04:37,702 --> 00:04:44,590
方法是把智能体的输出和评分标准一起交给评委模型，让它给出分数和理由。

46
00:04:44,590 --> 00:04:53,616
优点是能评判主观质量，文笔、逻辑性、创造力都能评，能理解意图而不只是字面匹配，也灵活。

47
00:04:53,616 --> 00:05:03,291
缺点是成本较高，每次评判都消耗词元，可能存在评分偏见，需要精心设计标准，而且结果不完全可复现。

48
00:05:03,291 --> 00:05:10,960
它适合开放式任务，研究报告的质量、代码风格、对话自然度、摘要的完整性和准确性。

49
00:05:10,960 --> 00:05:15,070
第三种是人工评判器，由领域专家直接评判。

50
00:05:15,070 --> 00:05:23,376
用在评测初期校准标准、模型评判出现明显盲点时、以及医疗法律金融这类高风险场景。

51
00:05:23,376 --> 00:05:33,219
优点是质量最高，能发现自动化方法的盲区；缺点是不可扩展，速度慢，成本高，而且评判者之间也会有分歧。

52
00:05:33,219 --> 00:05:44,397
核心逻辑是三层递进，代码评判器保证底线不出大错，模型评判器提升上限做出好质量，人工评判器校准裁判保证公正。

53
00:05:44,397 --> 00:05:46,597
三者缺一不可。

54
00:05:46,750 --> 00:05:51,411
模型评判器好不好用，几乎全看评分标准写得怎么样。

55
00:05:51,361 --> 00:05:56,073
模糊的标准，比如给输出质量打零到一分，几乎没用。

56
00:05:56,073 --> 00:05:59,462
好的标准应该明确到每一分代表什么。

57
00:05:59,462 --> 00:06:01,758
举个可以直接抄的例子。

58
00:06:01,758 --> 00:06:06,722
零分，完全没有回答问题，或者包含严重的事实错误。

59
00:06:06,722 --> 00:06:10,676
零点三分，回答了问题但遗漏关键信息。

60
00:06:10,676 --> 00:06:15,880
零点七分，回答完整准确，但组织混乱或者有冗余。

61
00:06:15,880 --> 00:06:19,979
一分，完整、准确、简洁、结构清晰。

62
00:06:19,979 --> 00:06:27,863
把每一档都写成可判断的描述，评委模型的打分才稳定，不同人看结果也才有一致的理解。

63
00:06:27,863 --> 00:06:30,916
推荐的三层混合流程是这样的。

64
00:06:30,916 --> 00:06:39,919
先用代码评判器打底，覆盖所有确定性场景，编译通过、格式正确、接口调用准确，又快又便宜。

65
00:06:39,919 --> 00:06:48,921
再用模型评判器扩展，覆盖主观场景，输出质量、逻辑性、用户体验，这里设计好评分标准是关键。

66
00:06:48,921 --> 00:06:56,866
最后用人工定期校准，抽检模型评判器的评分有没有漂移，修正偏见，确保整套体系可信。

67
00:06:56,866 --> 00:06:59,366
两个真实案例值得参考。

68
00:06:59,366 --> 00:07:12,034
一个视频编辑智能体的评测围绕三个维度独立打分，第一是不破坏，编辑后视频无损；第二是做了该做的，指令被正确执行；第三是做得好，剪辑质量专业。

69
00:07:12,034 --> 00:07:29,454
另一个代码生成智能体组合了三类评判，静态分析检查代码能否编译、有没有风格错误；再用一个浏览器智能体自动打开生成的页面，验证界面是否符合预期；最后用模型评判器评判代码质量和可读性。

70
00:07:29,454 --> 00:07:37,987
这两个案例有个共同点，它们都不是单一维度的评分，而是把任务拆成几个可以独立观测的维度分别打分。

71
00:07:37,987 --> 00:07:47,555
这样做的好处是，指标变化的时候能立刻定位到是哪一环出了问题，而不是只知道总分掉了却说不清原因。

72
00:07:47,710 --> 00:07:50,508
评测建起来不等于就可靠了。

73
00:07:50,458 --> 00:07:54,665
生产环境中反复验证过三个隐蔽的陷阱。

74
00:07:54,665 --> 00:07:57,021
第一个是基础设施噪音。

75
00:07:57,021 --> 00:08:06,287
同一个模型、同一个任务，仅仅改变处理器和内存的限制，分数差异就能达到六个百分点，甚至出现排名逆转。

76
00:08:06,287 --> 00:08:15,662
这意味着什么，如果你的评测环境和生产环境不一致，你在评测里看到的九十五分，到了线上可能只有八十九分。

77
00:08:15,662 --> 00:08:21,576
你以为模型甲比模型乙好，其实只是甲在你的沙箱配置下跑得更顺。

78
00:08:21,576 --> 00:08:27,381
还有一个容易被忽略的细节，基础设施配置本身就是考题的一部分。

79
00:08:27,381 --> 00:08:36,744
你给多少内存、多少处理器、网络通不通，都会影响它的表现，而且影响幅度可能比模型本身的差异还大。

80
00:08:36,744 --> 00:08:47,429
对策是把评测环境当成实验条件一样严格控制，每次报告评测结果时，同时报告处理器、内存、网络和沙箱类型。

81
00:08:47,429 --> 00:08:50,290
环境变了，分数就不可比。

82
00:08:50,290 --> 00:08:52,778
第二个是模型会识别考试。

83
00:08:52,778 --> 00:09:06,492
在某个联网检索的评测中，一个前沿模型推测出了自己正在跑评测，它识别出题目的模式，然后尝试在网上搜索答案，或者利用训练数据里可能见过的类似题目。

84
00:09:06,492 --> 00:09:11,372
这算不上作弊，而是泛化能力在评测场景下的副作用。

85
00:09:11,372 --> 00:09:18,463
但核心问题很严重，当固定的题目集遇上可以联网的环境，评测结果就不再可靠。

86
00:09:18,463 --> 00:09:25,434
模型越强，识别评测的能力越高，传统固定题目集对前沿模型的区分力在衰减。

87
00:09:25,434 --> 00:09:34,280
启示是评测方式也要进化，用动态生成的用例、限制联网、或者干脆用真实业务场景替代公开题目集。

88
00:09:34,280 --> 00:09:37,465
第三个是小改动引发连锁退化。

89
00:09:37,465 --> 00:09:42,165
一个看似无害的提示词改动，可能让性能暴跌。

90
00:09:42,310 --> 00:09:44,471
看两次真实的事故。

91
00:09:44,421 --> 00:09:52,750
第一次，用户反馈某个编程智能体输出太啰嗦，团队决定修改系统提示词来减少冗余文字。

92
00:09:52,750 --> 00:09:57,294
结果简洁性确实提升了，但代码评测掉了约百分之三。

93
00:09:57,294 --> 00:10:03,772
因为它在变简洁的同时也变得不够详细，省略了关键的代码注释和错误处理。

94
00:10:03,772 --> 00:10:10,851
第二次，团队修改了一个叫推理力度的默认值，一个看起来完全无害的配置参数调整。

95
00:10:10,851 --> 00:10:19,577
结果是多个评测维度同时出现退化，模型的思考深度被无意中削弱，复杂任务的完成质量下降。

96
00:10:19,577 --> 00:10:26,032
这种退化很难通过简单测试发现，只有完整的评测套件才能捕捉到。

97
00:10:26,032 --> 00:10:30,022
从这两次事故里能提炼出三条防护建议。

98
00:10:30,022 --> 00:10:33,808
第一条，每次变更都必须跑完整套件。

99
00:10:33,808 --> 00:10:41,825
不管是改提示词、换模型、调参数，还是改基础设施，只测改动涉及的那个维度远远不够。

100
00:10:41,825 --> 00:10:50,755
第二条，评测环境要标准化，固定处理器、内存、沙箱类型和网络条件，环境不一致的结果不可比。

101
00:10:50,755 --> 00:11:01,032
第三条，评测不是一劳永逸的，模型在进步，评测也要进化，要更新用例、增加新维度、淘汰已经被模型记住的旧题目。

102
00:11:01,032 --> 00:11:10,707
另外补一条具体做法，提示词变更要做逐行消融，也就是每次只改一行，测量它的影响，而不是一次改一大段。

103
00:11:10,707 --> 00:11:15,575
一次改十行，指标掉了你根本不知道是哪一行造成的。

104
00:11:15,575 --> 00:11:21,332
这三条合起来是一个更上层的教训，评测系统本身也需要被评测。

105
00:11:21,332 --> 00:11:30,238
你要持续审视三件事，我的评测环境可靠吗，我的测试用例还有区分力吗，我的变更流程够严谨吗。

106
00:11:30,380 --> 00:11:33,635
最后讲一个检索增强的升级方案。

107
00:11:33,585 --> 00:11:42,467
传统流程是把文档切成小块，对每块做向量化，提问时检索最相似的小块，再交给模型生成答案。

108
00:11:42,467 --> 00:11:47,659
这里有个致命缺陷，切块这个动作本身就会丢失关键信息。

109
00:11:47,659 --> 00:11:49,342
一个典型案例。

110
00:11:49,342 --> 00:11:54,763
有这样一句话，公司第二季度的营收比上一季度增长了百分之三。

111
00:11:54,763 --> 00:12:01,517
哪个公司，哪一年，上一季度的基准是多少，这个增长率在行业里算好还是差。

112
00:12:01,517 --> 00:12:05,243
所有关键上下文都在切块的时候丢掉了。

113
00:12:05,243 --> 00:12:10,544
检索也许能找到这句话，但它本身携带的信息严重不足。

114
00:12:10,544 --> 00:12:12,647
解决思路非常直观。

115
00:12:12,647 --> 00:12:21,001
在做向量化之前，先用模型阅读整篇文档，为每一块生成一段简短的上下文描述作为前缀。

116
00:12:21,001 --> 00:12:32,167
改造之后，这段话变成了，这一块来自公司二零二四年的年度报告，具体是财务表现章节，公司第二季度营收比上一季度增长了百分之三。

117
00:12:32,167 --> 00:12:36,013
来源、时间、章节，全部自动补齐。

118
00:12:36,013 --> 00:12:38,260
完整方案是三层递进。

119
00:12:38,260 --> 00:12:45,352
第一层，上下文化向量，给每块加前缀后再做向量化，让语义匹配更精准。

120
00:12:45,352 --> 00:12:59,150
第二层，上下文化关键词检索，传统关键词检索也加上前缀，前缀里的公司名、年份这类词，能让它命中原本因为缺少语境而漏掉的块，双路召回互补盲区。

121
00:12:59,150 --> 00:13:07,455
第三层，重排序，检索之后再用一个重排模型对候选块重新排序，把最相关的排到前面。

122
00:13:07,455 --> 00:13:15,796
这里有个判断值得记住，检索的质量瓶颈在于分块本身的信息完整性，而不是向量模型够不够强。

123
00:13:15,796 --> 00:13:24,210
换一个更强的向量模型，帮助往往有限，因为丢失的语境不在向量里，它在切块的那一刻就已经没了。

124
00:13:24,210 --> 00:13:29,895
效果数据很硬，三层叠加之后，检索失败率降低了约三分之二。

125
00:13:29,895 --> 00:13:36,181
假设之前每一百次检索有三十次找不到正确的块，优化后降到十次左右。

126
00:13:36,181 --> 00:13:40,640
对于依赖检索增强的生产系统，这是质的飞跃。

127
00:13:40,640 --> 00:13:42,804
但成本也要算清楚。

128
00:13:42,804 --> 00:13:50,364
每个块都需要一次额外的模型调用来生成前缀，大规模文档库的预处理成本不可忽视。

129
00:13:50,364 --> 00:13:58,044
可以用提示词缓存来降低成本，因为同一篇文档的不同块共享相同的文档级上下文。

130
00:13:58,044 --> 00:14:11,421
所以它适合高准确率场景，法律文档检索、医疗知识问答、金融合规查询，这些场景多花的预处理成本是值得的；对容错率高的闲聊推荐，可能就不划算。

131
00:14:11,560 --> 00:14:15,836
最后给你一份可以马上用的判断清单，一共五条。

132
00:14:15,786 --> 00:14:21,484
第一条，把评测当成基础设施，而不是上线前的检查清单。

133
00:14:21,484 --> 00:14:25,354
它的第一个价值是逼团队定义成功长什么样。

134
00:14:25,354 --> 00:14:29,488
写不出用例，通常说明任务理解还不够清晰。

135
00:14:29,488 --> 00:14:32,722
从二十条开始就够，关键是开始。

136
00:14:32,722 --> 00:14:35,907
第二条，三种评判器组合使用。

137
00:14:35,907 --> 00:14:51,692
代码评判器守底线，快且客观，适合有明确答案的任务；模型评判器提上限，能评主观质量，但必须把评分标准写到每一分都可判断；人工评判器做校准，定期抽检模型评判有没有漂移。

138
00:14:51,692 --> 00:14:56,307
第三条，把评测环境当成实验条件来控制。

139
00:14:56,307 --> 00:15:02,810
处理器、内存、网络和沙箱类型都要固定并记录下来，否则分数不可比。

140
00:15:02,810 --> 00:15:10,983
同样地，别迷信公开题目集，模型越强越会识别考试，要用动态用例或者真实业务场景。

141
00:15:10,983 --> 00:15:16,343
第四条，任何变更都跑完整套件，并且做逐行消融。

142
00:15:16,343 --> 00:15:21,499
改提示词、换模型、调参数、改基础设施，都一样。

143
00:15:21,499 --> 00:15:27,858
单一维度的改善不等于整体改善，改一行也可能让另一个维度掉三个百分点。

144
00:15:27,858 --> 00:15:33,218
第五条，检索增强的质量瓶颈在分块本身的信息完整性。

145
00:15:33,218 --> 00:15:42,377
给每一块补上来源、时间和章节前缀，再配合关键词双路召回和重排序，检索失败率可以降低三分之二。

146
00:15:42,377 --> 00:15:48,939
成本是每个块多一次模型调用，高准确率场景值得，容错率高的场景未必。

147
00:15:48,939 --> 00:15:55,105
这五条的共同点是，评测不是一次性的工作，它需要和产品一起进化。

148
00:15:55,105 --> 00:16:04,552
你今天建的这套体系，决定了你半年后能不能快速换模型、快速定位问题、以及有没有底气说自己变好了。