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

2
00:00:06,382 --> 00:00:11,394
这一集是降本增效这个专题的收官，要解决的问题很直接。

3
00:00:11,394 --> 00:00:17,355
为什么同样一个功能，别人家的账单是你的五分之一，响应速度还比你快。

4
00:00:17,355 --> 00:00:30,576
前面几集我们看懂了账单、踩过了跳档的坑、算清了 Agent 的平方级膨胀，这一集讲真正的实战四层，从语义层、架构层到输出层，把成本一刀一刀砍下去。

5
00:00:30,576 --> 00:00:33,293
这一集的四层是这么排的。

6
00:00:33,293 --> 00:00:43,209
语义层管喂进去什么，架构层管怎么复用算过的结果，输出层管让模型说多少话，最后收官把三层串成一条判断标准。

7
00:00:43,209 --> 00:00:52,788
四层都不需要你换模型、也不需要改产品形态，改的全是工程细节和提示词写法，但叠加起来的收益能到几倍。

8
00:00:52,788 --> 00:00:55,120
为什么产品经理要关心。

9
00:00:55,120 --> 00:01:01,742
因为 Token 成本不是财务侧的一行数字，它是财务、延迟、质量的三重映射。

10
00:01:01,742 --> 00:01:10,060
提示词每多一千个 Token，你不光多付钱，用户还要多等一段首字延迟，模型还更容易抓不住重点。

11
00:01:10,060 --> 00:01:14,795
省钱省到点子上，体验是跟着变好的，而不是变差。

12
00:01:14,795 --> 00:01:21,706
这一集还会给你一条审方案的标准，简短到一句话，但足够卡住大部分浪费。

13
00:01:21,840 --> 00:01:23,520
先讲语义层。

14
00:01:23,470 --> 00:01:29,612
RAG 和长文档场景里最常见的工程错误，是把上下文窗口当垃圾桶。

15
00:01:29,612 --> 00:01:35,069
Few-Shot 案例、检索回来的文档，全部怼进去，让模型自己辨识。

16
00:01:35,069 --> 00:01:37,521
能用，但不该这样用。

17
00:01:37,521 --> 00:01:40,982
先把这个错误的典型长相描述清楚。

18
00:01:40,982 --> 00:01:48,807
产品经理在需求文档里写，把知识库里相关的文档都带上，让模型自己判断哪些有用。

19
00:01:48,807 --> 00:02:00,357
这句话听起来很合理，但它把选择的责任推给了模型，而模型为此付出的代价是注意力被摊薄，你为此付出的代价是账单和延迟。

20
00:02:00,357 --> 00:02:01,848
它有两宗罪。

21
00:02:01,848 --> 00:02:03,819
第一，贵而且慢。

22
00:02:03,819 --> 00:02:10,297
Transformer 自注意力的计算复杂度是 N 的平方，提示词长度翻倍，计算量翻四倍。

23
00:02:10,297 --> 00:02:17,713
提示词越长，预填充越久，首字延迟越高，用户还没看到第一个字，耐心已经消磨没了。

24
00:02:17,713 --> 00:02:20,165
第二，效果可能更差。

25
00:02:20,165 --> 00:02:24,877
有效信息被废话淹没之后，会产生中段迷失效应。

26
00:02:24,877 --> 00:02:35,790
就像人读长文章，开头认真看，因为要搞清楚讲什么；结尾也留意，因为快出结论了；中间那一大坨，眼睛扫过去了，脑子没过去。

27
00:02:35,790 --> 00:02:41,619
你精心挑选的参考资料如果不幸落在中段，模型可能根本没认真看。

28
00:02:41,619 --> 00:02:50,658
有个交互演示模拟了这件事，色条代表模型对各个位置的注意力强度，六千 Token 的时候，中段基本塌成灰色。

29
00:02:50,658 --> 00:02:53,122
这条规律还能反过来用。

30
00:02:53,122 --> 00:03:00,850
很多人以为长上下文窗口的出现，意味着可以不用再挑素材了，反正一百万的窗口塞得下。

31
00:03:00,850 --> 00:03:07,953
塞得下和抓得住是两回事，窗口变长只是提高了上限，没有改变注意力的分布形状。

32
00:03:07,953 --> 00:03:15,898
你把检索回来的二十篇文档一股脑丢进去，模型对其中每一篇的注意力，都比你只放五篇时要弱。

33
00:03:15,898 --> 00:03:23,542
结论就一句，关键信息要么放开头，要么放结尾，中间的位置留给丢了也不心疼的内容。

34
00:03:23,690 --> 00:03:26,572
既然不能全塞，就要学会挑。

35
00:03:26,522 --> 00:03:29,190
第一重蒸馏针对 Few-Shot 案例。

36
00:03:29,190 --> 00:03:37,952
拿 Text-to-SQL 举例，为了覆盖各种业务场景，有人在提示词里写死二十个 SQL 案例，加起来四千多个 Token。

37
00:03:37,952 --> 00:03:43,602
每次用户提问，模型都要先把这四千字复习一遍，既烧 Token 又慢。

38
00:03:43,602 --> 00:03:45,008
换个思路。

39
00:03:45,008 --> 00:03:53,614
把二十个案例存进向量数据库，用户问上个月销售额的时候，先用语义检索只捞三个财务相关的案例。

40
00:03:53,614 --> 00:04:02,592
最终提示词从四千砍到五百，省了八成多，响应速度更高，准确率反而提升，因为去掉了无关案例的干扰。

41
00:04:02,592 --> 00:04:06,077
第二重蒸馏针对检索回来的长文档。

42
00:04:06,077 --> 00:04:14,359
金融研报、会议纪要这类文档充满正确的废话，免责声明、重复的背景介绍、口语化垫话。

43
00:04:14,359 --> 00:04:19,323
直接喂给 AI，等于花大成本请博士生帮你读垃圾邮件。

44
00:04:19,323 --> 00:04:26,186
解法是在检索之后、推理之前插一层压缩中间件，比如 LLMLingua-2。

45
00:04:26,186 --> 00:04:36,967
它不是粗暴砍词，而是用双向注意力同时看到上下文前后，精准识别核心语义，实体、数据、关键动词，剔掉冗余噪音。

46
00:04:36,967 --> 00:04:45,116
压缩五到二十倍，原本一秒的预填充压完五十毫秒搞定，高并发场景的吞吐量直接上一个量级。

47
00:04:45,116 --> 00:04:50,657
这里有个容易忽略的收益，压缩不只是省钱，它还提升了答案质量。

48
00:04:50,657 --> 00:04:59,299
原始文档里那些重复的免责声明和口语化垫话，对模型来说是干扰项，会稀释它对关键数字的注意力。

49
00:04:59,299 --> 00:05:05,837
压完之后，剩下的全是实体、数据、关键动词，模型的判断反而更稳。

50
00:05:05,837 --> 00:05:10,993
两道漏斗滤掉噪音，高密度提示词才能换来高质量注意力。

51
00:05:11,140 --> 00:05:16,835
接下来是架构层，KV Cache 是商业化降本里最被低估的技术点之一。

52
00:05:16,785 --> 00:05:20,847
命中缓存和没命中，最高差九成的成本。

53
00:05:20,847 --> 00:05:22,674
原理其实很朴素。

54
00:05:22,674 --> 00:05:29,237
大模型的本质是 Token 推 Token，它不关心你问的是什么问题，只关心前文是什么。

55
00:05:29,237 --> 00:05:35,667
这意味着如果两次请求的前缀相同，模型其实在重复计算同样的内容。

56
00:05:35,667 --> 00:05:45,715
缓存就是把算过的中间结果存下来，下次遇到相同前缀直接复用，用廉价的存储换昂贵的实时计算，空间换时间。

57
00:05:45,715 --> 00:05:47,049
举个例子。

58
00:05:47,049 --> 00:05:49,946
你问二加四等于几，它算出六。

59
00:05:49,946 --> 00:05:54,321
再问三加四等于几，前缀变了，只能从头算。

60
00:05:54,321 --> 00:06:01,328
但如果问的是二加四加一等于几，前缀二加四没变，模型直接从六开始算出七。

61
00:06:01,328 --> 00:06:04,573
只要前缀不变，缓存就能命中。

62
00:06:04,573 --> 00:06:13,828
DeepSeek、Qwen、智谱都支持这个能力，缓存价只有标准价的五分之一，这是挑选大模型接口时必看的一项。

63
00:06:13,828 --> 00:06:17,458
产品经理在这里要做的决策其实很具体。

64
00:06:17,458 --> 00:06:27,434
系统提示词、工具定义、产品规则、长期人设，这些不变的部分要放在最前面并且保持稳定，它们就是你的缓存本金。

65
00:06:27,434 --> 00:06:33,311
变化的部分，用户这一轮的提问、检索回来的文档，放在后面。

66
00:06:33,311 --> 00:06:38,564
顺序看起来是工程细节，实际直接决定了每个月的账单。

67
00:06:38,720 --> 00:06:42,131
缓存好用，但有几个隐形的大坑。

68
00:06:42,081 --> 00:06:46,312
第一个坑，用工具参数，就别动态切换工具。

69
00:06:46,312 --> 00:06:54,281
有些产品为了极致省钱，根据用户意图动态挂载工具，问天气挂天气工具，闲聊就不挂。

70
00:06:54,281 --> 00:06:57,129
看起来省 Token，实际是大坑。

71
00:06:57,129 --> 00:07:10,374
问题出在大模型后端的模板逻辑，只要请求带了工具参数，服务器就会在系统提示词后面插入一段工具说明；如果你没写系统提示词，模板还会自动帮你加一个再插。

72
00:07:10,374 --> 00:07:20,218
于是工具状态一变，从有到无、从 A 换成 B，提示词头部前缀就变了，之前缓存的几十万 Token 瞬间灰飞烟灭。

73
00:07:20,218 --> 00:07:25,531
这个坑最阴的地方在于，它不会报错，账单也不会立刻爆炸。

74
00:07:25,531 --> 00:07:39,184
你只是发现换了模型供应商之后，缓存命中率从八成掉到一成，而工程团队查遍了提示词也找不出原因，因为前缀的变化发生在服务端模板里，你本地根本看不到。

75
00:07:39,184 --> 00:07:50,038
推荐的做法是，系统提示词保持不变，不用工具字段；或者宁可浪费点 Token，把全量工具定义一直挂着，也要保住缓存命中。

76
00:07:50,038 --> 00:07:54,629
系统提示词的稳定性，比省那点 Token 重要得多。

77
00:07:54,780 --> 00:07:59,201
第二个坑，慎用滑动窗口，尽量采用归纳形式。

78
00:07:59,151 --> 00:08:07,732
多轮对话和长文本场景，很多产品用滑动窗口处理超长历史，只保留最近 N 轮，旧的直接丢。

79
00:08:07,732 --> 00:08:10,425
这是偷懒，而且会出问题。

80
00:08:10,425 --> 00:08:17,853
滑动窗口的本质是先进先出队列，每滚动一次，前缀就变一次，缓存永远命不中。

81
00:08:17,853 --> 00:08:25,954
有个真实产品叫伴写，用前文生成后文，早期就是固定八百字滚动窗口，又贵又容易失忆。

82
00:08:25,954 --> 00:08:38,213
后来改成章节缓存，AI 生成时识别到话题转换，场景切换、新章节，就插入分隔标记，系统据此判断哪些内容压缩成摘要、哪些完整保留。

83
00:08:38,213 --> 00:08:40,052
指标对比很直观。

84
00:08:40,052 --> 00:08:50,737
命中率从大约百分之十提到大约百分之八十，逻辑连贯性从经常失忆变成摘要加完整章节，Token 成本从重复计算的高位降下来。

85
00:08:50,737 --> 00:08:55,341
与其让 AI 自己有损压缩，不如让前缀尽量稳定。

86
00:08:55,341 --> 00:09:00,845
换个角度看，滑动窗口和章节缓存的差别，不只是命中率。

87
00:09:00,845 --> 00:09:12,744
滑动窗口丢的是最老的信息，而最老的信息往往是用户最早定下的目标和约束；章节缓存保留的是话题边界，正好对应人类记忆的组织方式。

88
00:09:12,744 --> 00:09:17,805
所以后者除了省钱，还顺手解决了失忆这个体验问题。

89
00:09:17,805 --> 00:09:21,410
由此可以导出上下文管理的四个设计决策。

90
00:09:21,410 --> 00:09:40,284
哪些信息必须恒久保留，放进稳定区作为缓存前缀；哪些信息可以压缩存档，用摘要替代原文；哪些信息需要按需加载，按章节或话题切分动态挂载；如何识别可压缩边界，设计分隔符机制让 AI 标记话题转换点。

91
00:09:40,430 --> 00:09:42,206
最后是输出层。

92
00:09:42,156 --> 00:09:47,469
输出 Token 比输入贵好几倍，而且直接决定接口返回速度。

93
00:09:47,469 --> 00:09:52,661
管住模型的嘴，第一类操作是指令层，写明确的负向约束。

94
00:09:52,661 --> 00:10:00,642
很多人知道要求请简洁回答，但这是有问题的，简洁对模型来说太抽象了，它不知道你要多简洁。

95
00:10:00,642 --> 00:10:03,791
有效的写法是把别干什么列清楚。

96
00:10:03,791 --> 00:10:08,286
不要寒暄、不要总结、不要客套，直接输出结果。

97
00:10:08,286 --> 00:10:12,938
英文社区有个更直白的说法，不要开场白，不要结束语。

98
00:10:12,938 --> 00:10:14,608
对比一下效果。

99
00:10:14,608 --> 00:10:22,830
模糊约束那一版，模型回的是，当然，这是您要的代码，它实现了一个简单的功能，希望对您有帮助。

100
00:10:22,830 --> 00:10:27,108
明确负向约束那一版，模型直接回函数定义。

101
00:10:27,108 --> 00:10:31,411
实测下来，智能体场景能砍掉三成的废话。

102
00:10:31,411 --> 00:10:36,075
说白了就是告诉它，别整那些有的没的，直接上结果。

103
00:10:36,075 --> 00:10:38,815
这条对多轮对话尤其重要。

104
00:10:38,815 --> 00:10:45,870
废话不只是浪费输出 Token，它还会被写进历史上下文，下一轮再被完整读一遍。

105
00:10:45,870 --> 00:10:52,217
一轮多说三十个字，十轮下来就是几百个 Token 的输入成本，而且是复利式的。

106
00:10:52,217 --> 00:10:56,387
管住嘴这件事，收益会随对话轮次放大。

107
00:10:56,530 --> 00:10:58,847
第二类操作是代码层。

108
00:10:58,797 --> 00:11:02,030
这是文字润色场景最大的成本坑。

109
00:11:02,030 --> 00:11:08,220
用户说把这句话改通顺一点，模型把两千字的文章从头输出一遍。

110
00:11:08,220 --> 00:11:12,944
就算约束到只输出那个段落，Token 也在哗哗地烧。

111
00:11:12,944 --> 00:11:16,670
换个思路，让模型只输出修改的部分。

112
00:11:16,670 --> 00:11:24,927
用差异格式标出原文到改后的对应关系，或者直接返回查找替换指令，程序拿到后再做替换。

113
00:11:24,927 --> 00:11:27,764
只动那两三个词，一秒搞定。

114
00:11:27,764 --> 00:11:34,855
成本差几十倍，体验还更好，速度快，用户还能直接看到改了哪里，不用自己对比。

115
00:11:34,855 --> 00:11:38,305
成本差几十倍这件事值得再算一遍。

116
00:11:38,305 --> 00:11:46,141
两千字的文章重写一遍，输出大概两千多个 Token；改成差异输出，可能只有三十个 Token。

117
00:11:46,141 --> 00:11:51,333
而输出比输入贵好几倍，一进一出，单次的价差就是几十倍。

118
00:11:51,333 --> 00:11:56,165
高频润色场景里，这一条往往比换模型更能省钱。

119
00:11:56,165 --> 00:12:00,624
第三类操作是工程层，用停止序列做物理截断。

120
00:12:00,624 --> 00:12:08,689
在提示词里写请只输出三项，模型听不听是玄学，可能输出三项，也可能五项再加一段总结。

121
00:12:08,689 --> 00:12:19,807
但停止序列是物理截断，和模型听不听话无关，接口检测到指定字符串就直接掐断生成流，被掐掉的部分不计费、不进历史上下文。

122
00:12:19,807 --> 00:12:30,083
常用的几个掐点，列表掐第四项的编号，单行答案掐换行，结构化数据掐右花括号，防止自问自答掐用户冒号。

123
00:12:30,083 --> 00:12:32,704
简单，粗暴，但好用。

124
00:12:32,704 --> 00:12:38,076
停止序列还有个附带好处，被掐掉的内容不进历史上下文。

125
00:12:38,076 --> 00:12:46,213
这意味着模型跑偏时说的那些废话，不会污染下一轮的输入，等于顺手做了一次上下文清理。

126
00:12:46,213 --> 00:12:52,235
这一条在多轮智能体场景里的价值，比省下的那点 Token 更大。

127
00:12:52,380 --> 00:12:56,632
做完这几层优化，你基本上已经跑赢九成的团队。

128
00:12:56,582 --> 00:13:00,308
收官这一节，把整个专题串成一句话。

129
00:13:00,308 --> 00:13:04,335
省 Token 这件事，本质上是在提高信息密度。

130
00:13:04,335 --> 00:13:14,275
我们聊过分词、报价梯队、跳档陷阱、智能体账单、格式压缩、缓存复用、停止序列，看起来都是在省钱抠成本。

131
00:13:14,275 --> 00:13:21,606
但往深了想，过滤掉格式噪音、文档废话、重复计算之后，喂给模型的都是干货。

132
00:13:21,606 --> 00:13:25,789
密度越高，注意力越不容易分散，幻觉也越少。

133
00:13:25,789 --> 00:13:28,289
高信噪比等于高智能。

134
00:13:28,289 --> 00:13:30,429
还有个副产品，快。

135
00:13:30,429 --> 00:13:39,130
Token 少了，首字出得快，端到端延迟短，在面向消费者的产品里，这直接决定用户愿不愿意继续用。

136
00:13:39,130 --> 00:13:43,505
这条标准也可以翻译成给设计师和运营的语言。

137
00:13:43,505 --> 00:13:52,135
界面上一次默认全选、一次不设上限的多图上传、一次自动带上全部历史记录，背后都是真金白银。

138
00:13:52,135 --> 00:13:56,534
极简主义在这里不是美学偏好，是成本结构的要求。

139
00:13:56,534 --> 00:14:04,563
下次审工程化方案时，用一个标准卡一卡，这里的每一个 Token，都在为最终结果贡献价值吗。

140
00:14:04,563 --> 00:14:07,135
如果不是，考虑把它干掉。

141
00:14:07,135 --> 00:14:12,424
把算力留给真正的思考，这才是 AI 时代精益计算的美学。

142
00:14:12,424 --> 00:14:16,763
再补三条通用红线，可以直接写进工程规范。

143
00:14:16,763 --> 00:14:25,008
单次输入控制在三万二千 Token 以内，超了就做预算感知截断，检索、多图、多轮历史通用。

144
00:14:25,008 --> 00:14:29,335
智能体轮次控制在十轮以内，用熔断机制兜底。

145
00:14:29,335 --> 00:14:38,169
输入输出比超过五十比一就要告警，那通常意味着智能体在空转，先查流程而不是先加预算。

146
00:14:38,169 --> 00:14:40,537
可带走的清单有四句。

147
00:14:40,537 --> 00:14:48,433
第一，提示词翻倍等于计算量翻四倍，关键信息放开头或结尾，中间留给丢了不心疼的内容。

148
00:14:48,433 --> 00:14:55,044
第二，Few-Shot 别硬编码，存向量库按问题动态检索，长文档先压缩再推理。

149
00:14:55,044 --> 00:15:04,599
第三，前缀稳定就是省钱，别动态切换工具，别用简单粗暴的滑动窗口，用稳定前缀加摘要存档加章节挂载。

150
00:15:04,599 --> 00:15:13,265
第四，管住模型的嘴，负向约束要具体，润色输出差异或替换指令，停止序列做物理截断。