1
00:00:00,160 --> 00:00:07,360
所以现在使用的是喇嘛，并且使用轻LM，你所要做的就是将其切换为美洲驼

2
00:00:07,960 --> 00:00:08,960
美洲驼 3.2。

3
00:00:08,960 --> 00:00:11,240
这就是 API 基础。

4
00:00:11,400 --> 00:00:14,520
呃，现在它将在我的计算机上运行。

5
00:00:14,640 --> 00:00:19,520
它将使用 llama 3.2 来实现同样的目标。

6
00:00:19,680 --> 00:00:20,600
呃，哎呀。

7
00:00:20,800 --> 00:00:21,320
我们开始吧。

8
00:00:21,360 --> 00:00:21,880
不挂断。

9
00:00:23,080 --> 00:00:26,600
让我们运行它，这样我的计算机就可以看到我的了。

10
00:00:26,640 --> 00:00:27,920
又很快了。

11
00:00:28,080 --> 00:00:30,880
呃，我的 GPU 突然加速了一秒钟。

12
00:00:31,040 --> 00:00:33,160
呃，让我们看看我们得到了什么。

13
00:00:33,440 --> 00:00:35,000
好吧，让我们比较一下。

14
00:00:35,160 --> 00:00:40,040
您可以立即看到 llama 3.2，因为它是完全免费的。

15
00:00:40,280 --> 00:00:47,360
呃，呃，正如您从非常精确的成本中看到的那样，0.00 $0.00。

16
00:00:47,520 --> 00:00:55,640
呃，呃，在输出方面，呃，它做得不太好，呃，你可以看到

17
00:00:55,640 --> 00:00:59,320
那，这就像这里的标题发生了一些有趣的事情。

18
00:00:59,520 --> 00:01:01,520
呃，没有，没有写标题这个词。

19
00:01:01,520 --> 00:01:07,250
相反，它在他们的，嗯，类别中添加了一个类似降价的标题。

20
00:01:07,370 --> 00:01:11,450
它说的是家庭安全，感觉这是一个非常具体的类别。

21
00:01:11,450 --> 00:01:16,410
我实际上并不太关心，但这些类别将为正在尝试的 LM 提供一个提示

22
00:01:16,410 --> 00:01:18,370
稍后再猜价格。

23
00:01:18,570 --> 00:01:22,410
但是，你仍然希望你想要一个感觉正确的类别。

24
00:01:22,570 --> 00:01:24,770
嗯，这个品牌是对的。

25
00:01:25,050 --> 00:01:29,090
呃，描述提供了一个安全且时尚的入口解决方案。

26
00:01:29,090 --> 00:01:30,410
没关系，没关系。

27
00:01:30,570 --> 00:01:35,850
嗯，但它显然没有达到 OSS 20 b 的精度。

28
00:01:36,610 --> 00:01:39,490
呃，实际上，这让我只想提一件事。

29
00:01:39,490 --> 00:01:40,370
你可能会注意到。

30
00:01:40,890 --> 00:01:46,050
输出token只有48个，而且这里的输出token数量要大得多。

31
00:01:46,050 --> 00:01:47,490
但它们在视觉上看起来是一样的。

32
00:01:47,490 --> 00:01:53,410
当我看到 125 时，我记得我在想，这肯定不是比 125 少得多

33
00:01:53,530 --> 00:01:54,690
呃，输出令牌。

34
00:01:54,730 --> 00:02:00,210
事实是，值得知道的是，当轻量级LM计算输出令牌时，它包括这些

35
00:02:00,210 --> 00:02:07,460
所谓推理代币，是OSS操作系统在思考过程中创建的代币

36
00:02:07,660 --> 00:02:09,340
如何得出最佳答案。

37
00:02:09,340 --> 00:02:11,940
所以它确实也有一些推理标记。

38
00:02:11,980 --> 00:02:16,940
因为这里更接近 48，所以这是一个很好且简短的描述。

39
00:02:17,220 --> 00:02:23,980
好的，所以对于你来说，如果你确实希望经历并解决这个问题，你可以选择使用

40
00:02:24,020 --> 00:02:25,940
llama 3.2 为您提供数据。

41
00:02:25,980 --> 00:02:27,780
当然需要很长时间。

42
00:02:27,820 --> 00:02:32,660
Llama 3.2 并不是非常快，但您可以在 llama 3.2 中重写所有内容。

43
00:02:32,900 --> 00:02:38,220
尽管如此，这些数据仍然比原始数据要好得多。

44
00:02:38,460 --> 00:02:40,820
但我将使用 grok 和 Q。

45
00:02:41,020 --> 00:02:43,940
这就是我们预处理所有数据的方式。

46
00:02:43,980 --> 00:02:51,900
我将对 Lite 数据集中的 20,000 个数据执行此操作，并且还将对 Lite 数据集中的 800,000 个或 820,000 个数据执行此操作。

47
00:02:51,980 --> 00:02:53,860
以及完整的数据集。

48
00:02:53,980 --> 00:02:59,140
我将使用这种批处理模式作为一种方法，可以非常快速地以一半的价格完成此任务。

49
00:02:59,180 --> 00:03:00,180
我们现在就去做吧。

50
00:03:00,180 --> 00:03:05,580
因此，从现在开始，在本实验的其余部分中，我们将重点关注使用 grok 和 Q。

51
00:03:05,580 --> 00:03:08,680
但是你可以直接应用类似于OpenAI的东西。

52
00:03:08,680 --> 00:03:11,080
如果您希望拥有几乎完全相同的 API。

53
00:03:11,240 --> 00:03:16,840
或者，如果您愿意，也可以循环遍历并使用 llama 3.2 来处理 20,000 个数据集。

54
00:03:17,080 --> 00:03:18,240
但这就是我们要做的。

55
00:03:18,680 --> 00:03:25,480
首先，我们将使用这个小辅助函数来生成一行 JSON。

56
00:03:25,520 --> 00:03:32,120
对于我们想要通过队列向 grok 发出的每个不同请求，用一行 JSON 表示。

57
00:03:32,160 --> 00:03:33,680
这就是批处理模式的工作原理。

58
00:03:33,840 --> 00:03:37,480
你还记得我们在第五周简短地讨论过这个问题。

59
00:03:37,800 --> 00:03:44,800
JSON L 是一种文件类型，它不仅仅是一个 JSON blob（JSON 文件就是这样），而是一个

60
00:03:44,800 --> 00:03:48,560
文件，其中每一行都是一个单独的 JSON 文档。

61
00:03:48,560 --> 00:03:51,400
这就是所谓的 JSON l JSON 行。

62
00:03:51,640 --> 00:03:57,040
嗯，我们将在每行上显示我们想要的模型。

63
00:03:57,080 --> 00:04:04,720
它有消息，这将是带有系统提示的常见 OpenAI 词典列表。

64
00:04:04,720 --> 00:04:08,560
用户提示将是完整的项目。

65
00:04:08,840 --> 00:04:13,330
嗯，你可以看到我们这里有镜子。

66
00:04:13,450 --> 00:04:16,530
我们之前实际上在这里打过电话。

67
00:04:16,730 --> 00:04:20,250
这正是我们放入 JSON 文件中的调用。

68
00:04:21,050 --> 00:04:23,610
我们也在每一行。

69
00:04:23,610 --> 00:04:31,170
您还必须输入一个 ID 号来标识您以批处理模式发送的每一行，因为

70
00:04:31,170 --> 00:04:35,290
您稍后将收到输入文件中每一行的响应。

71
00:04:35,570 --> 00:04:40,130
这就是为什么我将该 ID 设置为每个项目的编号，因为我们将使用它作为我们的

72
00:04:40,130 --> 00:04:43,050
对每行中的内容进行排队的方式。

73
00:04:43,410 --> 00:04:43,970
好的。

74
00:04:44,010 --> 00:04:45,730
这就是所谓的 make JSON L。

75
00:04:45,730 --> 00:04:50,850
为了让您真正了解这一点，让我向您展示使 JSON l 的项目为零的样子。

76
00:04:50,970 --> 00:04:53,970
这是一个提醒，零项是什么。

77
00:04:54,250 --> 00:04:55,290
我想我们知道这个。

78
00:04:55,290 --> 00:04:55,530
出色地。

79
00:04:55,530 --> 00:04:58,730
现在是这款带有锁舌的安多佛内部旋钮。

80
00:04:59,090 --> 00:05:03,010
如果我用第 0 项调用 make JSON L，就会发生这种情况。

81
00:05:03,250 --> 00:05:10,130
我得到客户 ID 为零，因为这是我们设置方法是聊天后完成的 ID。

82
00:05:10,130 --> 00:05:16,460
然后你会看到这里有DeCSS系统用户的列表，所有的东西都在里面

83
00:05:16,820 --> 00:05:22,060
来自非结构化数据，然后推理工作量很低。

84
00:05:22,100 --> 00:05:25,300
这就是我们调用 make jsonl 时得到的结果。

85
00:05:25,460 --> 00:05:29,180
它就像用一行 JSON 表示一个 API 调用。

86
00:05:30,060 --> 00:05:39,020
好的，现在我有了一个函数 make 文件，它将遍历并生成一个完整的文件

87
00:05:39,180 --> 00:05:45,420
通过从头到尾迭代每个项目并创建一个 jsonl 文件。

88
00:05:46,180 --> 00:05:49,500
再说一次，如果你不确定我的意思，现在你就会明白了。

89
00:05:49,580 --> 00:05:55,900
我将从索引 0 开始调用 makefile，直到索引 1000。

90
00:05:55,940 --> 00:05:58,540
我希望你为我制作一个 jsonl 文件。

91
00:05:58,700 --> 00:06:04,020
将其称为零下划线 1000 jsonl 并将其放在名为 jsonl 的文件夹中。

92
00:06:04,060 --> 00:06:05,060
让我运行一下。

93
00:06:05,100 --> 00:06:06,020
跑起来了

94
00:06:06,060 --> 00:06:07,260
我们去看看吧。

95
00:06:07,780 --> 00:06:09,220
这是一个名为 Jsonl 的文件夹。

96
00:06:09,260 --> 00:06:10,220
我已经到了这里。

97
00:06:10,220 --> 00:06:12,420
这是我们刚刚创建的文件。

98
00:06:12,420 --> 00:06:15,550
希望这对您来说是有意义的。

99
00:06:15,590 --> 00:06:17,190
这是一个有的文件。

100
00:06:17,230 --> 00:06:20,550
如果我一直向下滚动，希望它有 1000 行。

101
00:06:20,590 --> 00:06:21,110
让我们来看看。

102
00:06:21,150 --> 00:06:23,430
它确实有1000行。

103
00:06:23,430 --> 00:06:27,350
如果我们再次回到顶部，这是第一行。

104
00:06:27,630 --> 00:06:31,950
您可以看到的每一个都有一个自定义 ID 01234567。

105
00:06:32,390 --> 00:06:36,910
随着我的继续，您会发现每个调用看起来都像是一个 API 调用。

106
00:06:36,990 --> 00:06:40,710
这里的主体说明了我们要调用的模型是什么。

107
00:06:40,990 --> 00:06:48,750
然后这里是消息呃，系统，内容创建者，简洁的描述等等。

108
00:06:48,990 --> 00:06:56,070
因此，您可以查看其中的每一个，每行都传递不同的非结构化内容

109
00:06:56,070 --> 00:06:57,430
来自某个项目的数据。

110
00:06:57,590 --> 00:07:04,190
我们将要求 grok 浏览整个文件并一起处理所有这些内容，以便为我们提供

111
00:07:04,190 --> 00:07:05,230
我们的结果。

112
00:07:05,470 --> 00:07:06,030
好的。

113
00:07:06,070 --> 00:07:11,470
请记住，如果您没有遵循所有这些，请对我所说的内容有一些直觉，

114
00:07:11,470 --> 00:07:14,230
通过jsonl文件批量调用和LM。

115
00:07:14,590 --> 00:07:19,000
您将能够获得由此带来的回报，我将上传结果。

116
00:07:19,000 --> 00:07:22,200
您将能够下载它们并按原样使用它们。

117
00:07:22,800 --> 00:07:29,480
好吧，那我现在就用呃，grok呃，提供了一个库grok，我们直接用

118
00:07:29,680 --> 00:07:33,840
如果你以批处理模式调用OpenAI，它基本上是完全相同的。

119
00:07:33,840 --> 00:07:35,760
Grok 复制了 OpenAI 的做法。

120
00:07:35,760 --> 00:07:39,880
对于大多数提供商来说，这种方法是相当标准的。

121
00:07:40,080 --> 00:07:40,440
好的。

122
00:07:40,480 --> 00:07:46,120
所以我通过传入我的 grok API 密钥来初始化 grok 库。

123
00:07:46,560 --> 00:07:55,040
因此，当您在批处理模式下工作时，您需要执行的步骤很简单。

124
00:07:55,200 --> 00:07:58,000
基本上就是这三个步骤。

125
00:07:58,120 --> 00:08:00,120
您创建一个文件。

126
00:08:00,680 --> 00:08:03,680
然后，您可以使用该文件来创建批处理。

127
00:08:04,320 --> 00:08:06,360
然后你检索该批次。

128
00:08:06,480 --> 00:08:08,200
这就是我们现在要做的。

129
00:08:08,440 --> 00:08:12,560
因此，您要做的第一件事就是在 grok 中创建一个文件。

130
00:08:12,600 --> 00:08:14,720
我们告诉 grok 我已经拿到了这个文件。

131
00:08:14,720 --> 00:08:17,200
它称为零下划线 1000。

132
00:08:17,360 --> 00:08:20,250
杰森，我希望你上传这个文件。

133
00:08:20,250 --> 00:08:23,890
目的是为了批量目的。

134
00:08:24,010 --> 00:08:25,010
就是这样。

135
00:08:25,050 --> 00:08:29,050
我刚刚将该文件上传到 grok 并返回。

136
00:08:29,050 --> 00:08:35,970
它带有一个文件响应，呃，里面有一个 ID，它有它创建的字节数，

137
00:08:35,970 --> 00:08:38,010
名称、目的等。

138
00:08:38,650 --> 00:08:40,770
现在我可以收集那个身份证了。

139
00:08:40,930 --> 00:08:44,210
现在这是我上传到 grok 的文件。

140
00:08:44,250 --> 00:08:45,770
它就坐在 grok 上。

141
00:08:45,770 --> 00:08:48,010
有了这个ID就完成了。

142
00:08:48,010 --> 00:08:50,090
我们现在已经创建了文件时间。

143
00:08:50,090 --> 00:08:52,250
所以我们已经创建了该文件。

144
00:08:52,250 --> 00:08:56,170
现在是我们使用该文件来创建批处理的时候了。

145
00:08:56,370 --> 00:09:03,210
因此，我们不调用 grok create，而是调用 grok 批量创建。

146
00:09:03,730 --> 00:09:07,010
我们说我们需要您在接下来的 24 小时内完成此操作。

147
00:09:07,010 --> 00:09:07,570
不着急。

148
00:09:07,610 --> 00:09:08,330
慢慢来。

149
00:09:08,330 --> 00:09:09,890
因为这就是我们获得半价的方式。

150
00:09:10,170 --> 00:09:13,450
呃，我们说这是一个标准的聊天完成。

151
00:09:13,450 --> 00:09:20,170
我们给它输入文件，该文件是我们刚刚上传的文件的 ID，它有 jsonl.json 文件。

152
00:09:20,250 --> 00:09:22,620
每一行都是一个不同的 API 请求。

153
00:09:22,620 --> 00:09:26,260
所以我们刚刚创建了我们的批次。

154
00:09:26,300 --> 00:09:27,020
我们开始吧。

155
00:09:27,220 --> 00:09:33,700
它有这个批次 ID，让我们将该 ID 收集到呃抱歉中。

156
00:09:33,740 --> 00:09:34,060
开始了。

157
00:09:34,060 --> 00:09:40,340
响应 ID 是我们获取该 ID 的地方，当我们准备好后，我们就可以执行下一步，即

158
00:09:40,380 --> 00:09:43,940
检索该批次并查看它发生了什么。

159
00:09:43,940 --> 00:09:44,780
那么我们开始吧。

160
00:09:44,980 --> 00:09:49,100
我们使用 grok create 来创建该文件。

161
00:09:49,100 --> 00:09:54,140
然后我们执行 grok create 从文件中创建一个批处理。

162
00:09:54,300 --> 00:09:58,380
现在我们正在执行 grok 检索。

163
00:09:58,420 --> 00:10:00,300
现在找出来是怎么回事。

164
00:10:00,340 --> 00:10:08,260
我们返回呃，这里是批次ID，完成窗口，端点，输入文件ID

165
00:10:08,300 --> 00:10:10,460
状态已完成。

166
00:10:10,460 --> 00:10:15,900
所以 grok 有 24 小时的时间来做这件事，但它就那样做，通常是这样的文件

167
00:10:15,900 --> 00:10:16,180
这。

168
00:10:16,220 --> 00:10:17,420
完全不会有问题的。

169
00:10:17,420 --> 00:10:20,020
我想如果你们这样做的话，这件事就会发生在你们两个身上。

170
00:10:20,020 --> 00:10:21,100
没有错误。

171
00:10:21,140 --> 00:10:23,060
一切看起来都很棒。

172
00:10:23,060 --> 00:10:24,760
于是事情就这样发生了。

173
00:10:24,800 --> 00:10:27,040
我们已经成功了。

174
00:10:27,200 --> 00:10:32,880
然后，呃，我应该提到的另一个步骤，就是实际收集结果。

175
00:10:32,880 --> 00:10:37,040
你可以用 grok 内容来做到这一点。

176
00:10:37,040 --> 00:10:37,880
那么我们开始吧。

177
00:10:38,400 --> 00:10:40,400
格洛克内容。

178
00:10:40,400 --> 00:10:47,240
我刚刚将其写入 Jsonl 目录中名为 Batch results Jsonl 的文件中。

179
00:10:47,240 --> 00:10:47,960
我们来看看吧。

180
00:10:48,360 --> 00:10:49,240
呃，就是这里。

181
00:10:49,280 --> 00:10:50,680
批次结果就在这里。

182
00:10:50,920 --> 00:10:52,360
现在我们有了它。

183
00:10:52,360 --> 00:10:54,280
这就是文件的内容。

184
00:10:54,280 --> 00:10:58,600
这是一个文件，每一行都是一个 jsonl。

185
00:10:58,680 --> 00:11:00,640
呃，这是一块 JSON。

186
00:11:00,760 --> 00:11:02,640
看，这些自定义 ID 不匹配。

187
00:11:02,640 --> 00:11:06,840
它不会按照我们发送的顺序返回，因为这件事发生了，就像，

188
00:11:06,880 --> 00:11:12,320
处理它并返回它的 grok 进程场以某种不同的顺序出现。

189
00:11:12,320 --> 00:11:14,720
所以我们不能依赖文件的顺序。

190
00:11:14,720 --> 00:11:19,720
我们需要查看这个自定义 ID，您会发现这里有很多回复。

191
00:11:19,720 --> 00:11:24,520
如果你研究一下它们，你会发现在这个过程中的某个地方，我们确实应该有我们的，

192
00:11:24,640 --> 00:11:29,690
呃，如果我滚动到右侧，我们的实际答案。

193
00:11:29,930 --> 00:11:31,130
呃，这是尸体。

194
00:11:31,490 --> 00:11:33,290
这里有一个身份证。

195
00:11:33,570 --> 00:11:41,490
呃，然后我们会看到实际上有这样的反应，我们会

196
00:11:41,490 --> 00:11:43,490
查看回复内容。

197
00:11:43,890 --> 00:11:44,530
开始了。

198
00:11:44,810 --> 00:11:46,850
呃，消息助理的内容。

199
00:11:47,050 --> 00:11:51,890
你可以看到屏幕上出现了所有这些标题标题，

200
00:11:51,890 --> 00:11:59,330
这些都是从模特标题类别品牌返回的所有标题，呃，显示出来。

201
00:11:59,450 --> 00:12:03,890
我们已收到 grok 对这些项目的回复。

202
00:12:04,130 --> 00:12:05,010
杰出的。

203
00:12:05,250 --> 00:12:10,250
现在最后，我们可以编写一些普通的 Python 代码来迭代它。

204
00:12:10,250 --> 00:12:16,570
然后我们可以收集 ID，然后用它来提取摘要。

205
00:12:16,570 --> 00:12:17,850
看看这里的这一行。

206
00:12:18,010 --> 00:12:24,850
项目 ID 摘要是我们将从该 jsonl 行中提取的摘要。

207
00:12:24,850 --> 00:12:27,250
这就是我们接下来要运行的。

208
00:12:27,250 --> 00:12:29,010
然后我们将检查结果。