当我们和豆包进行对话的时候，我们会发现豆包非常聪明，她似乎是一个会思考的机器。实际上，我们输入一句话给到大模型的时候，大模型并没有真正意义上的“思考”，它做的事情就是：根据你给的内容，预测“下一个最可能出现的 token 是什么”，然后一个接一个地生成下去。简单理解，也就是做极其复杂的模式匹配和概率计算。（这里是可以理解为一个概率性文本接龙机器，也就是平常所说的概率模型）。
理解了上面的情况后，就理解了同样的问题每次回答略有不同（概率采样，它只关心像不像正确答案，而不是“是不是正确答案”）的原因了。所以，更多信息 = 更准确的概率预测，就解释了更多上下文效果会更好。
而LLM在输入和输出的过程中呢，就会消耗token，token是 LLM 处理文本的最小单位，不完全等于一个字或一个词，是介于两者之间的语言碎片。在这些模型训练和推理的过程中，看到的不是原始字符串，而是一段被切分好的token序列（被分词器所切分），同样，一句话的token量并不会是完全固定住的，这和分词算法的设计有关，以目前主流的 BPE（Byte Pair Encoding）算法为例，它的工作方式是从最基础的字符出发，不断合并高频相邻字节对，直到词表达到目标大小。
举个例子，假设语料中 “p”和“r” 经常连续出现，BPE 就会把它们合并为一个 token “pr”；如果 “pr”和“o” 又经常一起出现，就进一步合并为 “pro”；以此类推，最终 “prompt” 可能作为一个完整的 token 存在于词表中——因为它出现的频率足够高。而一个生僻的专业术语，比如 “defenestration”，可能会被拆成好几个碎片。 这也解释了几个实际使用中的现象：常见词消耗的 token 更少（因为被合并成了更大的单元），生僻词或专有名词消耗更多；中文通常比等量英文消耗更多 token（因为大多数模型的训练语料以英文为主，中文字符的合并频率较低）；代码中的常见关键词如 “function”、“return” 往往是单个 token，而变量名可能被拆成多个。
当然这里的token也引出来一个名词，就是上下文窗口，上下文窗口就是 LLM 一次能“看到”的文本总量上限（上下文窗口本质就是token数量的上限），单位就是token，比如：Claude 目前的上下文窗口是 200K token。对话超过了上下文窗口后，模型会丢失对话信息，也就是模型失忆了。LLM 没有真正的记忆。每次你发消息，系统其实是把之前的对话历史一起打包发送给模型。所以当对话太长超出窗口限制时，早期的内容就会被截掉，这就解释了为什么模型会忘的原因。
补充：
- 关键参数：temperature（温度）。温度越高，模型选择低概率 token 的可能性越大，输出越随机和有创意；温度越低，输出越确定和保守。这也是为什么 API 调用时可以通过调节 temperature 来控制输出风格——写代码时用低温度求准确，写故事时用高温度求创意。
- 窗口大不等于利用率高。研究发现，即使在窗口范围内，模型对中间位置的信息关注度往往低于开头和结尾，这被称为 “lost in the middle” 现象。所以写 prompt 时，重要信息尽量放在开头或结尾，而不是埋在中间。
版权声明：本文内容由互联网用户自发贡献，该文观点仅代表作者本人。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如发现本站有涉嫌侵权/违法违规的内容，请联系我们，一经查实，本站将立刻删除。
如需转载请保留出处：https://51itzy.com/kjqy/228284.html