我如何学习？

我目前查资料基本都是ChatGPT，月付，当然偶尔也会用谷歌。比如这次系统的学习AI，我就会先问ChatGPT，结合我前端开发的身份，我想要在日后的开发中，更好的使用AI工具，我应该如何学习AI。它会给我一些学习路线，然后我参考他的学习路线，反复的问ChatGPT，直到我弄明白了。

基本概念

token

token不一定是一个字母，也不一定是一个汉字，也不一定是一个单词。即便是相同的字符串“你好世界”他在不同的大模型里面可能是不同的拆分方法，可能会拆成“你”，“好”， “世界”。也可能是“你”，“好”，“世”，“界”。也可能是“你好”，“世界”。甚至是“你好世界”。具体是如何切分，它是由Tokenizer（分词器）决定的。

chat completion

最早期的时候，这些大语言模型都是对话（也就是chat），而且方向是对话补全（也就是chat completion），比如“你叫____”，大模型会补全“你叫什么名字”。我们现在的大模型这么牛逼，也是从chat completion发展过来的。

streaming

大模型在给出他的答案的时候，最终答案肯定是一个很长很长的文本，但他在开始输出的时候，是一个token一个token输出的，比如“我是中国人”，会先生成“我是”，然后再生成一个“中国人”，如果是很长的字符串，就会看到字符一点一点的蹦出来。这是一种流式渲染，这也是比较好的方式。如果不用流式渲染，那就是大模型要卡很久，然后再给出一个最终结果，很慢，体验不好。

tool calling

早期的时候，大模型只能问答，所以他没法回答类似这样的问题：“今天的天气怎么样？”。因为天气需要实时数据，大模型都是预先训练好的，他不包含今天的天气数据。那要如何解决这个问题呢？大模型不知道今天的天气，但他可以去查去问，他可以调用提供天气的api就好。大模型会有一个类似这样的输出：

{
  "tool_calls": [
    {
      "name": "get_weather",
      "arguments": {
        "city": "东京"
      }
    }
  ]
}

当然这只是大模型处理的一个中间步骤，他在tool calling之后，会把拿到的结果再喂给大模型，然后再输出给用户

structured output

结构化输出指的是大模型的输出结果的格式，是结构化的。上古时代大模型输出就是直接纯文本，这个很不方便二次处理。比如我想让大模型给我洗一下数据，洗完了我想让他给我JSON，上古时代的话我只能类似告诉他“结果以JSON格式发给我”，然后他发给我了类似下面的JSON

{
  "name": "Calvin",
  "age": "38"
}

但我们一般会期望年龄是数字，这个如果不是结构化输出，就比较难实现。结构化输出其实是在推理阶段实现的，比如在"age": 这些token后面，如果我们有约束age后面跟数值的schema，那在决定下一个token是"38"还是38的时候，"38"会被当成错误token而不会生成，而数字则会被当成正确的。

system prompt

早期的时候，system prompt非常有用，非常有效果。因为那个时候大模型训练的时候类似迷迷糊糊的状态，不够智能，我们在给他输入的时候，输入越精确，他的输出也会越符合我们的预期。比如我问他前端性能如何优化，如果我告诉他让他作为一个资深前端软件开发工程师，再给他我现在使用的技术栈React，Next.js，用了CDN，用了tailwindcss。然后对话的时候我再给它输入blablabla，那他的输出肯定要比我一上来就直接问如何做前端优化，精确很多。我们的输入越少，他的回答就越宽泛，我们就得多轮对话，才能达到我们期望的效果。 现如今system prompt带来的提升已经远不如从前了，因为现在的大模型做的很智能，大模型的提供方也想方设法把尽可能多的信息注入进去。比如我之前跟他聊过前端开发问题，问他前端的各种技术栈相关问题，即便是我不告诉他他要作为前端开发专家，我在问他前端如何做性能优化的时候，他也会参考我们之前的聊天记录，然后给我生成相关的解答。

那我还需要学system prompt吗？答案是肯定的，打个比方就是类似之前学了能带来40%的提升，现在不行了，但也能带来15%的提升。长年累月，这可是很厉害的提升。

context window

上下文窗口，可以简单理解为大模型一次可以处理的文本的长度，比如context window是100KB的话，我们直接给他塞进去200KB的要处理的东西，他就没法处理，要么截掉前面100KB，要么截掉后面100KB。 这个context window并不好提升，因为处理难度是(context window)^2，所以这个目前一般都是200KB或者顶多250KB。

GPT

GPT是generative pre-trained transformer。 generative的意思是生成式的，他不是检索，匹配等等信息处理方式，而是从输入—>处理->输出。生成了新的内容。 pre-trained意思是预先训练好的。GPT需要预先用海量的数据去训练，然后才能那么智能的给我们回复。 transformer意思是变换。虽然GPT的核心机制是attention，但他的实现确实是通过transformer来做的，参考下面的流程：

Token
↓
Embedding
↓
Transformer
↓
更聪明的Embedding

这个transformer就是把embedding从一种形式变换到了另一种形式。

embedding

embedding的意思是把我们的输入做向量化，这是一种非常牛逼的做法，因为他是对输入文本的抽象，方便后续的处理。比如”拉翔“和”上大号“，他们语义类似，但用的词差别很大，而且词里面字，拆开的话，语义相差特别大。那我们把他们做成向量的话，我们用向量之间的距离表示他们语义的相近程度，这样在后续的检索的时候，就很容易做语义检索。生成也是类似的道理，挑选合适的token，token也是embedding。 embedding为什么不叫vector？因为他们本身就是用vector来表示的啊。简单来说就是

Embedding 确实是一个 Vector（向量），但 Vector 只是数据结构，Embedding 强调的是“语义映射过程和结果”。

embedding的实现

embedding的时候，是如何实现相近语义的文本用距离相近的vector来表示呢？embedding的规则不是人定的，不是下面的过程：

猫 → 人工规则 → Vector
狗 → 人工规则 → Vector

他是类似下面的过程：

海量文本
 ↓
预测任务
 ↓
反向传播
 ↓
Embedding矩阵不断调整
 ↓
相似语义自然聚集

比如训练的时候，我们最开的时候的这些vector都是随机的，然后根据训练的时候的材料，慢慢调整这些vector，使他们最终的结果能够符合训练材料。这也是为什么这些训练材料为什么这么重要的原因。举一个更加详细的例子，比如“小猫爱吃”，下一个token，我们应该用什么呢？也就是vector里面的某个数应该用1还是100？我们假设用30，但我们的材料是”小猫爱吃鱼“，也就是用的80，那我们就得调整下我们的vector，我们就用50吧（不能直接用80，因为每次都直接用目标向量的话，那么多材料，训练来训练去，跟猴子掰玉米一样，掰一个丢一个，到头来啥也没学会）。 然后再来个训练材料”小猫爱吃老鼠“，用的是40，我们之前用的是50，那我们再往下调整一点，用45吧。这样的话，这个45既离“鱼”很近，也离“老鼠”很近。

reasoning model

以前的大模型就是直接从输入处理一下得到答案，这样的流程在处理简单的问题的时候没问题，但遇到需要推理的问题的时候，就会出错。比如我有10个苹果，吃了1个，还剩几个，答案是9个。这很好算，但如果是我家鱼塘里有100条鱼，死了30条，鱼塘里还有几条鱼？答案是100条，因为我没说捞出来（狗头保命）。这个时候如果没有推理就会回答错误，但有了推理，他就可以给出各种回答，以及对应的条件。比如他可以回答70条（前提是提出30条死鱼捞出来了，否者在里面发臭活鱼也弄死了）。也可以回答100条，同时提醒我赶紧捞出来。类似下面的流程：

普通模型：
问题
 ↓
答案

Reasoning Model：
问题
 ↓
思考
 ↓
答案

reasoning model听起来很美好，但他的成本也很高，他是在多个阶段实现的优化，训练的时候就刻意强调这个推理的过程。类似你会推理我就奖励你，你不做推理我就给你扣分。那在真实的生成过程中，也会做“推理”，类似多轮transform，当然每一轮的目的是不一样的，一个简单的比喻就是，拆解问题->分析各个子问题->合并问题的答案->检查一下对不对->回答问题。 这一套流程下来，肯定耗费更多token。不带推理的模型用100token，这个带推理的可能得3000token。好家伙，好用是好用，就是费钱。

chunking

chunking就是把大块的文本切成多个小块，这个切割的粒度是有讲究的，太大了不方便处理。太小了效率太差。而且具体在哪里切割也有讲究，整体原则就是，尽量把聚合度高的内容放到一个chunk，不相关的拆开。 比如说公司的员工手册，可以分为各个主题，请假，考勤，报销，公司介绍。各个主体长度不一致，我们就尽量一个主题一个chunk，chunk略微小点也没事，太大的话就得切开。 切完chunk，这些chunk分别生成对应的embedding。注意这里是一对一的，之前一句话对应多个embedding，是在token embedding阶段。RAG embedding的话就是1对1。