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

2
00:00:06,382 --> 00:00:11,358
这一集要解决的，是一个非常具体、也非常花钱的问题。

3
00:00:11,358 --> 00:00:19,579
你可能已经发现，产品上线第一个月账单还看得过去，第二个月开始，用户量没怎么涨，成本却在往上爬。

4
00:00:19,579 --> 00:00:24,639
你查调用量没变化，查功能也没加多少，钱就是多花了。

5
00:00:24,639 --> 00:00:33,389
这一集就是把这笔账拆开给你看，钱花在哪几层，每一层能用什么办法砍下来，砍到什么程度就该收手。

6
00:00:33,389 --> 00:00:35,721
为什么产品经理要关心。

7
00:00:35,721 --> 00:00:42,103
因为在人工智能产品里，成本不是一个事后优化项，它是架构决策的结果。

8
00:00:42,103 --> 00:00:57,539
同样一个功能，上下文怎么组织、提示词怎么写、图片传多大、模型怎么选，这些看起来是技术细节的选择，最后都会变成账单上的数字，而且在设计定下来的那一刻就基本定死了。

9
00:00:57,539 --> 00:01:02,023
上线之后再来优化，难度是当初就设计好的十倍。

10
00:01:02,023 --> 00:01:04,378
还有一个更现实的原因。

11
00:01:04,378 --> 00:01:07,551
成本决定你能不能把产品做下去。

12
00:01:07,551 --> 00:01:18,104
同样一个助手功能，一个团队每个用户每个月花几毛钱，另一个团队花几块钱，后者要么涨价、要么砍功能、要么关停。

13
00:01:18,104 --> 00:01:26,782
这门课把成本单独拿出来讲一大章，就是因为它是产品能不能活下来的变量，而不是财务报表上的一个数字。

14
00:01:26,782 --> 00:01:33,513
听完这一集，你应该能跟研发坐下来，把成本这条线上的每一个开关都点一遍。

15
00:01:33,650 --> 00:01:36,580
先讲清楚钱是怎么滚起来的。

16
00:01:36,530 --> 00:01:44,691
模型是按输入词元的数量计费的，而每一轮对话，都要把之前的所有历史记录重新发给模型。

17
00:01:44,691 --> 00:01:48,069
历史越长，词元越多，费用越高。

18
00:01:48,069 --> 00:01:53,273
注意是每一轮都重发全部历史，不是只发新增的那一句。

19
00:01:53,273 --> 00:01:55,100
举个具体的例子。

20
00:01:55,100 --> 00:01:57,251
第十轮的输入是什么。

21
00:01:57,251 --> 00:02:02,997
是系统提示词，加上前九轮的所有问答，再加上本轮这个问题。

22
00:02:02,997 --> 00:02:10,244
也就是说到了第十轮，模型要把整段对话从头到尾重新读一遍，才能回答你这一句。

23
00:02:10,244 --> 00:02:15,304
就像你每问一个新问题，对方都要先把前面聊过的原样背一遍。

24
00:02:15,304 --> 00:02:19,787
你感觉只是多问了一句，后台其实多付了九轮的钱。

25
00:02:19,787 --> 00:02:28,345
这也解释了一个很多产品会踩的坑，为什么有的对话产品聊到后面开始变慢、变贵，甚至答非所问。

26
00:02:28,345 --> 00:02:31,927
不是模型不行，是上下文在滚雪球。

27
00:02:31,927 --> 00:02:43,405
课程里还专门做了一个费用模拟器，让你拖动轮次去看费用怎么往上累积，那个曲线看着很直观，前面几轮几乎平着走，越到后面抬得越快。

28
00:02:43,405 --> 00:02:53,297
所以成本优化的第一步永远是看清楚，你的支出里有多少是真正必要的计算，有多少只是在为重复的历史付费。

29
00:02:53,450 --> 00:02:56,633
那重复的历史能不能不重复付费。

30
00:02:56,583 --> 00:02:59,251
能，这就是键值缓存。

31
00:02:59,251 --> 00:03:10,597
原理不复杂，每轮对话模型都要对历史词元做注意力计算，键值缓存把已经算过的中间结果存下来，下一轮只计算新增的那几个词元。

32
00:03:10,597 --> 00:03:13,458
课程里给了一个很好懂的类比。

33
00:03:13,458 --> 00:03:18,518
没有缓存，等于每次上课都从头默写一遍所有课本。

34
00:03:18,518 --> 00:03:23,686
有缓存，等于课本已经拍好存档，今天只看今天的新笔记。

35
00:03:23,686 --> 00:03:25,525
差距有多大呢。

36
00:03:25,525 --> 00:03:32,652
五千词元的系统提示词，在一千轮对话之后，键值缓存能省掉大约八成的总成本。

37
00:03:32,652 --> 00:03:38,193
所以有一句话要记住，系统提示词越长，键值缓存越值钱。

38
00:03:38,193 --> 00:03:43,025
而让缓存命中的前提只有一条，系统提示词保持不变。

39
00:03:43,025 --> 00:03:47,568
但这里有个隐藏的大坑，很多团队上线之后才发现。

40
00:03:47,568 --> 00:03:54,587
云端的模型通常跑在多台推理服务器上，你的请求每次可能被随机分配到不同节点。

41
00:03:54,587 --> 00:03:59,503
那个节点上没有你的前文缓存，缓存就永远命中不了。

42
00:03:59,503 --> 00:04:08,794
课程里给的实际命中率低于百分之三十，也就是说你以为自己在省钱，实际上三分之二以上的请求还是在全量重算。

43
00:04:08,794 --> 00:04:11,438
解决办法是显式缓存。

44
00:04:11,438 --> 00:04:21,210
在请求里加一行缓存控制标记，平台会主动把请求路由到有缓存的节点，不再依赖随机分配，命中率接近百分之百。

45
00:04:21,210 --> 00:04:35,212
这里有个反直觉的地方，隐式缓存的折扣看起来更大，是标准价的百分之二十，显式缓存只有百分之十，但因为显式缓存几乎不会落空，实际省下来的输入成本接近九成。

46
00:04:35,212 --> 00:04:42,304
课程里也给了主流平台的写法示例，本质上都是同一行标记，差别只在字段名字。

47
00:04:42,304 --> 00:04:46,066
结论很硬，生产环境必须用显式缓存。

48
00:04:46,066 --> 00:04:52,424
把省钱寄托在随机路由上，相当于靠运气省钱，既不可靠，也不专业。

49
00:04:52,560 --> 00:04:59,493
接下来是一个小小的设计错误，它可以让你的键值缓存完全失效，每轮成本翻倍。

50
00:04:59,443 --> 00:05:03,517
这个错误就是在系统提示词里写动态时间。

51
00:05:03,517 --> 00:05:12,387
很多人为了让模型知道现在几点，会在系统提示词里加一句当前时间是某年某月某日某时某分某秒。

52
00:05:12,387 --> 00:05:16,426
看起来很合理，结果是缓存命中率归零。

53
00:05:16,426 --> 00:05:23,109
因为系统提示词每一秒都在变，刚才说的那个保持不变的前提，被你自己破坏了。

54
00:05:23,109 --> 00:05:26,390
正确做法是把时间挪到用户消息里。

55
00:05:26,390 --> 00:05:35,597
系统提示词只写你是助手，时间作为前缀跟在用户问题前面，比如方括号里写一个日期，再跟上你的问题。

56
00:05:35,597 --> 00:05:41,847
这样系统提示词是固定的，缓存能一直命中，模型也依然拿到了时间。

57
00:05:41,847 --> 00:05:55,500
课程里做了一个实时对比，左边是带动态时间戳的系统提示词，右边是静态的，两边每秒各发一次请求，跑一会儿就能看到，左边的命中率一直是零，右边稳定在百分之百。

58
00:05:55,500 --> 00:05:58,541
这个演示比任何解释都有说服力。

59
00:05:58,541 --> 00:06:03,722
除了精确到秒的时间戳，还有几类内容同样是缓存杀手。

60
00:06:03,722 --> 00:06:10,981
随机会话标识、用户标识前缀、灰度测试变量、随机表情前缀、动态广告文案。

61
00:06:10,981 --> 00:06:18,710
判断标准就一句话，任何让系统提示词每次都不一样的内容，都会导致缓存完全失效。

62
00:06:18,710 --> 00:06:29,479
原则可以背下来，系统提示词等于固定前缀，所有动态的内容，时间、用户信息、带随机性的内容，统统放到用户消息里。

63
00:06:29,640 --> 00:06:31,957
讲完文字，讲图片。

64
00:06:31,907 --> 00:06:38,638
多模态模型不是按一张图计费的，它把图片切成像素块，再换算成词元。

65
00:06:38,638 --> 00:06:46,198
计费公式是，词元数等于缩放后的高乘缩放后的宽，除以每个词元对应的像素数，再加二。

66
00:06:46,198 --> 00:06:52,833
这里有个容易忽略的机制，模型不按原图计费，而是按缩放对齐之后的尺寸算。

67
00:06:52,833 --> 00:06:59,059
超过上限就缩小，低于下限还会放大，最后还要对齐到三十二的整数倍。

68
00:06:59,059 --> 00:07:00,693
这意味着什么。

69
00:07:00,693 --> 00:07:07,328
意味着你传一张分辨率很低的图，它可能先被放大再计费，你以为省了，其实没省。

70
00:07:07,328 --> 00:07:15,777
也意味着你传一张超高清大图，它会被压缩下去，你多花的带宽和等待时间换不来任何效果提升。

71
00:07:15,777 --> 00:07:29,479
很多团队在这里犯的错误是，前端直接把手机拍的原图传上去，一张图几兆，实际计费尺寸却早就被压缩到一个固定的格子，中间的传输成本和等待时间全白花了。

72
00:07:29,479 --> 00:07:32,652
所以按任务匹配分辨率很重要。

73
00:07:32,652 --> 00:07:42,015
不同任务对细节的要求差很远，识别一张票据上的金额，和判断一张照片里有没有人，需要的分辨率完全不是一个量级。

74
00:07:42,015 --> 00:07:52,604
课程里把任务分成高、中、低三档，每一档有推荐的分辨率区间，你只要先想清楚这个任务到底要看见什么，就能落到对应的那一档。

75
00:07:52,604 --> 00:08:01,090
核心原则是，分辨率不是越高越好，用最低能满足任务需求的分辨率，词元数的差距可以达到十倍到一百倍。

76
00:08:01,090 --> 00:08:07,773
这一条在多模态产品上是最直接的省钱点，也是最容易被忽略的一条。

77
00:08:07,920 --> 00:08:11,103
这一段讲提示词本身怎么省钱。

78
00:08:11,053 --> 00:08:12,759
先说语法层。

79
00:08:12,759 --> 00:08:17,531
格式性词元最高能占到提示词的百分之十三到二十。

80
00:08:17,531 --> 00:08:18,985
什么意思呢。

81
00:08:18,985 --> 00:08:29,370
你为了让提示词看起来专业而加的加粗符号、结构化数据的大括号、缩进和换行，模型并不需要这些，但每一个符号都要计费。

82
00:08:29,370 --> 00:08:41,533
课程里给了一组实测量级，某个提示词里加粗符号就吃掉了百分之八点五的词元，算上列表、标题和格式化缩进，整体格式性词元达到百分之十三。

83
00:08:41,533 --> 00:08:50,416
换算成钱就是，在千万级调用量下面，每个月有百分之二十的预算花在了让产品经理看着舒服这件事上。

84
00:08:50,416 --> 00:08:56,618
所以有一句很扎心的话，提示词是写给机器的指令，不是给人看的文档。

85
00:08:56,618 --> 00:09:01,798
换成更紧凑的结构化格式，就能省下百分之十五到三十。

86
00:09:01,798 --> 00:09:05,127
当然也不用一刀切，要按用途选。

87
00:09:05,127 --> 00:09:16,005
给用户流式展示的，用可以增量解析的格式；后端程序消费的，用紧凑格式；文档和富文本展示的，用渲染友好的标记语言。

88
00:09:16,005 --> 00:09:17,615
再说语义层。

89
00:09:17,615 --> 00:09:22,074
语义层要解决的是信息密度，让每一个词元都有价值。

90
00:09:22,074 --> 00:09:25,908
这里还有一个配套动作，上下文满了怎么办。

91
00:09:25,908 --> 00:09:28,372
课程给了三条溢出策略。

92
00:09:28,372 --> 00:09:34,887
第一条是截断，简单直接，但早期信息会永久丢失，适合短对话工具。

93
00:09:34,887 --> 00:09:42,783
第二条是摘要压缩，属于平衡之选，需要额外调用一次模型来生成摘要，适合长期对话。

94
00:09:42,783 --> 00:09:48,925
第三条是语义检索，最精准，需要向量系统支撑，词元消耗也最优。

95
00:09:48,925 --> 00:09:54,009
这三条不是三选一，而是按你的对话长度和重要性来配。

96
00:09:54,009 --> 00:09:57,110
那为什么不能无限往里塞内容。

97
00:09:57,110 --> 00:09:59,190
材料里给了两条理由。

98
00:09:59,190 --> 00:10:06,533
第一条是贵而且慢，注意力的复杂度随长度呈平方级增长，提示词翻倍，计算量翻四倍。

99
00:10:06,533 --> 00:10:16,089
第二条更关键，效果会变差，模型对中间内容的注意力最弱，你把关键信息塞在大段材料的中间，它就容易被淹没。

100
00:10:16,089 --> 00:10:22,856
所以三个策略，动态选取示例、对长材料做语义压缩、把关键信息放在首尾。

101
00:10:22,856 --> 00:10:29,562
这一条其实和省钱是同一件事，密度上去了，词元少了，效果反而更好。

102
00:10:29,710 --> 00:10:32,184
第七段讲输出和选型。

103
00:10:32,134 --> 00:10:36,737
先记住一个比例，输出词元比输入词元贵三到五倍。

104
00:10:36,737 --> 00:10:42,422
同样的内容，让模型多说一百个字，比让它多读一百个字贵得多。

105
00:10:42,422 --> 00:10:55,162
所以控制输出就是控制成本，具体有三个技巧，用负向约束明确告诉它不要什么，只让它润色差异而不是重写全文，以及设置停止序列让它该停就停。

106
00:10:55,162 --> 00:10:57,230
然后是模型选型。

107
00:10:57,230 --> 00:11:00,235
优化做完了，还得选对模型。

108
00:11:00,235 --> 00:11:05,968
选型的公式是三个变量相乘，任务难度、调用量、容错空间。

109
00:11:05,968 --> 00:11:18,588
任务难但调用量小，用旗舰模型不心疼；任务简单但调用量巨大，就必须往下走；容错空间小的场景，省钱的余地本来就小，该花的钱不能省。

110
00:11:18,588 --> 00:11:33,087
课程里还专门做了一张能力和成本的散点图，你会发现很多任务根本用不上最贵的那一档，真正拉开差距的是你有没有把任务按难度分开，而不是一刀切给所有请求配同一个模型。

111
00:11:33,087 --> 00:11:37,714
这一刀切下去，就是那百分之二十的旗舰模型开销。

112
00:11:37,714 --> 00:11:50,142
课程里还给了综合视角，把前面几层叠加起来看，重复历史占三成五，不必要的检索占两成五，旗舰模型占两成，真正必要的计算只占两成。

113
00:11:50,142 --> 00:12:03,1000
对应的五层优化分别是键值缓存省三成五、模型路由省一成二、检索过滤省一成八、历史压缩省百分之八、语义缓存百分之七，叠在一起能把整体成本压下来七成到九成。

114
00:12:03,1000 --> 00:12:08,940
还是那句话，成本优化是架构设计，不是事后补救。

115
00:12:09,090 --> 00:12:10,878
最后回到原点。

116
00:12:10,828 --> 00:12:20,732
学了这么多手段，本质只有一件事，一切方法归根到底都是为了构造更优质的上下文，让模型更准确地理解你的意图。

117
00:12:20,732 --> 00:12:32,571
上下文管理有三个维度，质量，注入精准高密度的信息；结构，把关键信息放对位置；成本，用最少的词元传递最多的有效信息。

118
00:12:32,571 --> 00:12:35,804
那怎么判断一件优化该不该做。

119
00:12:35,804 --> 00:12:37,932
课程给了两条清单。

120
00:12:37,932 --> 00:12:50,696
值得做的，是能跟友商拼成本、拼效率、拼效果的，是模型升级之后效果会更好而不是被替代的，是能形成产品护城河的，是收益明确、成本可控的。

121
00:12:50,696 --> 00:13:01,610
可以放弃的，是消耗极大资源、维护成本高的，是模型一升级就直接被替代的，是用户完全感知不到提升的，是边际收益趋近于零的。

122
00:13:01,610 --> 00:13:07,848
所以每做一件之前，先问一句，这件事模型版本升级之后还需要吗。

123
00:13:07,848 --> 00:13:12,343
这个问题很残酷，但能帮你砍掉一半的无效投入。

124
00:13:12,343 --> 00:13:15,131
同样的分寸感也适用于迭代。

125
00:13:15,131 --> 00:13:30,508
课程里演示了一个真实的文案迭代过程，跟着走了四轮，前三轮质量确实在持续上升，相关性、具体性、可用性都在涨，可到了第四轮就开始画蛇添足，加进去的东西反而把原文稀释了。

126
00:13:30,508 --> 00:13:36,025
所以迭代的艺术不在于能改多少轮，而在于知道什么时候该收手。

127
00:13:36,025 --> 00:13:41,265
这一点和成本优化是相通的，都是要判断边际收益什么时候归零。

128
00:13:41,265 --> 00:13:47,142
还有一个每次用人工智能之前都该问的问题，这个答案，我能验证吗。

129
00:13:47,142 --> 00:13:50,279
按这条线可以把事情分成四类。

130
00:13:50,279 --> 00:13:53,392
你懂、模型也懂的，放心用。

131
00:13:53,392 --> 00:13:57,936
你不懂、模型可能懂的，这是高危区，必须核查。

132
00:13:57,936 --> 00:14:02,864
你懂、模型不懂的，这一类要反过来，由你来投喂它。

133
00:14:02,864 --> 00:14:05,652
谁都不懂的，就别指望了。

134
00:14:05,652 --> 00:14:11,674
这一条比任何技巧都重要，因为它决定的是你把判断权交出去多少。

135
00:14:11,830 --> 00:14:16,046
最后留一份可以带走的判断清单，一共五条。

136
00:14:15,996 --> 00:14:18,568
第一条，先测量再优化。

137
00:14:18,568 --> 00:14:26,092
把成本构成拆开，看清楚重复历史、不必要的检索、模型档位、必要计算各占多少。

138
00:14:26,092 --> 00:14:29,494
没有这张图，所有优化都是拍脑袋。

139
00:14:29,494 --> 00:14:33,148
第二条，系统提示词必须是固定前缀。

140
00:14:33,148 --> 00:14:43,496
精确到秒的时间戳、随机会话标识、灰度变量，任何会变的东西都挪到用户消息里，这是键值缓存能不能生效的分界线。

141
00:14:43,496 --> 00:14:46,898
第三条，生产环境用显式缓存。

142
00:14:46,898 --> 00:14:52,811
隐式缓存在分布式架构下命中率低于三成，不要靠随机路由省钱。

143
00:14:52,811 --> 00:14:56,862
第四条，按任务匹配分辨率和模型档位。

144
00:14:56,862 --> 00:15:06,393
分辨率不是越高越好，词元数可以差十到一百倍；模型也不是越强越好，选型等于任务难度乘调用量乘容错空间。

145
00:15:06,393 --> 00:15:14,109
第五条，回到那个终极问题，我现在给模型的上下文，是它做好这件事所需要的全部吗。

146
00:15:14,109 --> 00:15:18,148
如果答不上来，先补上下文，再谈别的手段。

147
00:15:18,148 --> 00:15:20,984
大道至简，上下文为王。

148
00:15:20,984 --> 00:15:23,388
好，这一集就到这里。

149
00:15:23,388 --> 00:15:30,696
希望下次你再看账单的时候，能一眼看出钱花在哪一层，以及那一层的开关在哪里。