简介《Developing Apps with GPT-4 and ChatGPT》是一份 O’Reilly 出版的英文电子书 PDF面向希望把大模型能力落地到实际产品的开发者、技术负责人以及生成式 AI 爱好者重点讨论如何基于 GPT-4 与 ChatGPT 构建智能聊天机器人、内容生成器和其他应用。全书从模型与对话系统的基础概念切入逐步过渡到应用开发所需的关键思路适合具备一定编程基础、希望系统理解接口调用、提示设计与场景落地的中级读者。压缩包内只有 1 个 PDF 文件大小约 2.86MB轻量便携便于离线阅读、全文检索和随时查阅。目前已有 1133 人学习说明该英文原版在 AI 应用开发方向具有一定参考价值。读者可从中了解模型能力边界、聊天机器人构建流程、内容生成场景拆解以及工程实践中的注意事项也能把它作为梳理开发路径、设计产品原型和查阅专业术语的案头资料。1. 一句话说清GPT-4 和 ChatGPT 到底是什么你大概遇到过这种时刻有人张口就是“我们用 ChatGPT 做了个客服机器人”你点头心里却在想——它到底是个啥一套软件一个网站还是某种更底层的零件更让人犯迷糊的是紧接着又冒出个 GPT-4听起来像同一个东西的两个名字。先把定义摆出来GPT-4 和 ChatGPT 都属于大语言模型LLM也就是在海量文本上训练出来的机器学习模型能识别、也能生成接近人类写法的文字。通俗地说它是一个“接话高手”——你丢给它一段话这段输入叫 prompt它算出最可能跟在后面的内容再一个词一个词地吐出来。“GPT-4”指模型本身“ChatGPT”指把这套模型包装成对话形态的产品两者是发动机和整车的关系。搞懂这条线你才知道后面那些 API、token、上下文窗口到底在说什么。2. 从 AI 到 token一条层层嵌套的技术栈2.1 AI、机器学习、NLP、大语言模型到底谁包着谁这几个词最容易被混着用其实它们是一层套一层的。最外面是人工智能AI让计算机去干那些通常需要人类智能才能完成的事。这个定义很宽宽到 GPS 里的路况预测、策略游戏里的规则系统都能算进去——从外面看机器好像“动了脑子”。往里面一层是机器学习ML属于 AI 的子集。区别在于做法机器学习不直接把人定的判断规则写进程序而是让系统自己从例子里学。这条路从 1950 年代就开始了学术文献里积累了大量算法。再往里深度学习是机器学习里很有名的一类而 GPT-4 和 ChatGPT 用的是一种特定的深度学习算法叫 transformer。NLP自然语言处理不是这条“深度”线上的层级它是 AI 的一个应用方向专门管计算机和人类自然语言文本之间的交互。现代 NLP 方案基本都建立在机器学习算法之上。而大语言模型是机器学习模型里专攻“文本生成”这一类任务的那批。打个比方AI 是一整个工具箱ML 是里面那套“会自己学”的工具深度学习是这套工具里最锋利的几把transformer 是其中一把具体的刀LLM 是拿这把刀专门切“文本生成”这道菜的成品。别把它们当成并列的四个东西它们是父子关系。2.2 语言模型要解决的四种活儿NLP 的目标说起来朴素让计算机看懂自然语言文本。但“看懂”落到具体任务上至少有四类。第一类是文本分类把输入的文字塞进预先定好的类别里情感分析这段话是夸还是骂和主题归类这条留言属于售后还是物流都是它。第二类是自动翻译把一种语言的文字转成另一种。第三类是问答给定一段材料回答基于这段材料的问题。第四类是文本生成根据一段输入也就是 prompt产出一段连贯、相关的输出文字。这里有个容易被忽略的变化早几年的模型往往是“一个任务一个模型”做分类的不会翻译。而近一段时间发布的新一代语言模型规模足够大、喂的文本足够多已经能直接干大部分 NLP 任务——分类、翻译、问答都能上手。GPT-4 和 ChatGPT 就是这批模型里在文本生成上表现突出的两个。这个变化的实际意义在于你不需要为每个功能单独训一个模型一个模型配上不同的 prompt 就能覆盖多种场景。这也是为什么“用 GPT 做应用”这件事在工程上突然变得可行——门槛从“训练模型”降到了“写好输入”。2.3 为什么“预测下一个词”能变成聊天大语言模型的工作方式说到底就是一句话给定前面的文字预测最可能接上来的是什么。它靠分析、训练海量文本数据学到词与词之间的模式和关系然后把这种关系反过来用于生成。看个具体例子。输入是“今天天气不错所以我决定去”模型给出的续写可能是“散步”。听起来简单但要做到“听起来像人说的”背后得先判断这段输入的语境、抓住关键信息再在候选词里挑一个最合适的。关键在于这个过程不是查表。模型不是背下了“今天天气不错”后面该接什么而是基于概率打分——给每个可能的候选词算一个分数选分数高的那个作为下一个词。选定之后把它接到输入后面新的整段文字又成为下一轮的输入如此滚动。所以同样一句开头你多问几次得到的续写可能不一样。这套机制解释了两个常见现象。一是模型偶尔会“一本正经地胡说”因为它在挑“最像话”的接法而不是在核对事实。二是它的输出质量高度依赖你给的开头——prompt 写得含糊它就只能往最平庸的方向接。写 prompt 这件事的玄学感根子就在这里。3. 注意力机制Transformer 凭什么成为分水岭3.1 从 n-gram 到 RNN老办法卡在哪在 transformer 之前语言模型走了一段不短的路。最早的一类叫 n-gram思路很直白统计训练文本里跟在某几个词后面出现频率最高的词是哪个就预测那个。这条路能跑通但短板明显——它对上下文和语法的理解很有限生成出来的句子经常前言不搭后语。为了改善后来又引入了更复杂的算法包括循环神经网络RNN和长短期记忆网络LSTM。这类模型能学到更长的序列对上下文的分析比 n-gram 强不少。但它们有一个工程上的硬伤处理海量数据的效率不够。很长一段时间里循环类模型就是最有效的方案也因此被大量用在机器翻译这类工具里。真正的转折点出现在 2017 年transformer 架构被提出来。它大量使用了两样新东西——交叉注意力cross-attention和自注意力self-attention两者都建立在更早提出的注意力机制之上。它们让模型更容易看清一段文字里词与词之间的关系。还有一点常被忽略但极其关键和循环架构不同transformer 天然容易并行化。它可以同时处理输入文本的多个部分而不是排队一个接一个地算。这意味着训练更快也就意味着能在更大的数据集上训模型——大语言模型能“大”起来靠的就是这个前提。3.2 自注意力与交叉注意力两个例子讲透这两个词听着唬人其实就是两种“划重点”的方式。先看交叉注意力。它的作用是帮模型判断输入文本里哪些部分是准确预测下一个词的关键。像一束追光打在输入文本的相关词上把不重要的细节留在暗处。举个翻译的例子把一句“她很喜欢那座城市晴朗的天气”译成法语聚焦到“晴朗”对应的法语词 ensoleillé 时交叉注意力会把更高的权重给“晴朗”和“天气”这两个词——因为它们共同决定了 ensoleillé 的准确性。权重给对了译文这一小段就对了。再看自注意力。它指的是模型在处理输入时关注输入内部不同部分的能力。用 NLP 的话说模型能评估一句话里每个词相对于其他词的重要性从而更好地理解词间关系并从多个词里组合出新的概念。举个例子一句“她收到了同事们的称赞”。模型在处理“她”这个词时自注意力会给句子里不同的词分配不同权重把与“她”相关的词挑出来——这里权重更高的是前文出现的那个人名和“同事们”。于是“她的同事们”这个原本并不存在于任何一个单独词里的组合概念就浮现出来了。这就是原文说的“从多个词构建新概念”。用一句人话来概括这两者的分工交叉注意力管“输出这个词该回头看输入的哪几个词”自注意力管“输入内部谁跟谁是一伙的”。理解这两句话你就理解了 transformer 的核心。3.3 编码器与解码器GPT 只拿了一半标准的 transformer 由两个主要部件组成编码器encoder和解码器decoder两者都重度依赖注意力机制。分工是这样的编码器负责处理输入文本识别其中有用的特征生成这段文字的有意义表示这个表示叫 embedding解码器拿这份 embedding 去产出输出比如一段译文或一份摘要把编码过的信息有效解读出来。跨语言、跨模态的这种“序列到序列”任务里交叉注意力扮演关键角色——它让解码器能用上编码器生成的 embedding。一句话概括编码器负责“读懂”解码器负责“写出”。而 GPT 的选择很有意思它基于 transformer 架构但只用了原架构里的解码器部分。因为没有编码器也就不需要交叉注意力去整合编码器的输出GPT 完全依赖解码器内部的自注意力来生成带上下文的表示和预测。这个取舍不是孤例。另一个知名模型 BERT基于 transformer 的双向编码器表示走的是相反的路——基于编码器那一半。所以当有人把 BERT 和 GPT 放在一起比别以为是两个品牌它们是同一套架构的两个不同切法一个偏“理解输入”一个偏“生成输出”。知道这条分界线很多模型选型的争论就不用再绕了。4. token 与上下文窗口模型眼里的文字长什么样4.1 tokenization 到底在切什么模型并不按“字”或“词”看文本它看的是 token——把输入切成更小的片段这些片段可能是完整的单词也可能是单词的一部分。看个实际例子。输入是“The weather is nice today, so I decided to”切出来的结果大概是[The, wea, ther, is, nice, today, ,, so, I, de, ci, ded, to]。你会发现 weather 被劈成了 wea 和 therdecided 被劈成了 de、ci、ded连逗号都单独算一个 token。每个语言模型都自带自己的 tokenizer切法不通用。这一点在工程上很要命你在 A 模型上算好的长度换到 B 模型上不成立。所以别拿“字数”去估计模型的输入长度量纲根本不对。4.2 上下文窗口模型一次能“看见”多少切完 token模型靠前面讲的注意力和 transformer 架构去处理这些片段解读它们之间的关系和整段输入的语义。因为注意力机制的存在模型能把上下文当成一个整体来考虑而不是像循环模型那样在长输入上吃紧。接着是预测模型给每个可能的候选 token 打一个概率分按分数挑一个作为下一个 token。这个动作重复下去但每次的上下文都在变长。举个直观的第一轮在“今天天气不错所以我决定去”后面定下了“散步”第二轮要预测的时候上下文已经变成了“今天天气不错所以我决定去散步”如此往前滚。那模型一次能看多长的上下文这就是上下文窗口。GPT-4 有两种版本窗口分别是 8,192 个 token 和 32,768 个 token。这两个数字不是凑出来的规格它直接决定了你能塞进去多长的资料——一份长文档、一段多轮对话记录、一批参考资料都在这笔账里。4.3 100 tokens ≈ 75 words这个换算怎么用有一个流传很广的经验法则英文文本里100 个 token 大约等于 75 个单词。反过来估一个英文单词平均约 1.3 个 token。这个换算不是精确公式但足够用来做三件事。第一估算 prompt 长度看离窗口上限还有多大余量。第二估算调用成本很多服务是按 token 计费的输入输出都算。第三判断一份资料能不能一次性塞进去还是得分段处理。看一段示意代码感受一下“算 token”这件事在工程里怎么落地# 估算英文文本的 token 数量经验法则版非精确值 def estimate_tokens(text: str) - int: words text.split() # 按空白切成单词 return int(len(words) * 1.33) # 1 个英文单词约 1.33 个 token prompt Summarize the following document about language models ... est estimate_tokens(prompt) # 上下文窗口设为 8192预留一半给输出 window 8192 budget window // 2 print(f输入约 {est} tokens可用预算 {budget} tokens) if est budget: print(超预算需要分段处理)这段代码里window对应模型的上下文窗口上限budget是你给输入预留的额度之所以只取一半是为了给模型生成的输出留空间——输出也是要占 token 的。estimate_tokens用的是 1.33 的系数它只对英文大致成立中文的切分粒度不同系数得重新估这是很多人第一次算成本时翻车的地方别直接套用。提示这个估算只适合做粗筛。真正上线前请用对应模型自带的 tokenizer 精确计数尤其是处理长文档、要卡成本边界的场景。5. 常见易混概念把 GPT-4、ChatGPT、BERT 分清楚5.1 误区一ChatGPT 和 GPT-4 是同一个东西易混点在于两个名字里都有 GPT日常说话时大家也经常混着叫。为什么混因为对外呈现的时候用户接触到的界面永远叫 ChatGPT而底下跑的可能是不同代的模型。界面没变内核换了感觉就像同一个东西升了个级。怎么区分把 GPT-4 理解成模型把 ChatGPT 理解成产品。模型负责“接话”这个能力本身产品负责对话界面、上下文管理、历史记录这些外壳。判断一个需求该聊哪个层面很简单——你在讨论“它生成的文字质量如何”说的是模型你在讨论“它能不能记住上一轮说了什么、界面怎么用”说的是产品。做应用开发的人尤其要分清这条线你调的是模型你设计的是产品。5.2 误区二模型“理解”了文字易混点在于模型输出的句子太像人话很容易让人以为它读懂了意思。为什么混因为流畅本身就是一种极强的暗示。一段语法通顺、逻辑自洽的回答看上去就像出自一个真的懂了的对象。怎么区分回到机制上。模型做的事情是基于概率预测最可能的下一个 token它学到的是词与词之间的模式和关系而不是在核对事实、建立世界模型。所以它会给出听起来天衣无缝却完全错误的答案。这个区别在做产品时非常实际凡是需要事实准确性的地方都不能只靠模型自觉得在外面接一层校验、检索或者人工确认。把它当“最像话的接话者”而不是“知道答案的人”很多设计决策就顺了。5.3 误区三BERT 和 GPT 只是名字不同易混点在于两者都基于 transformer名字又都带大写字母缩写看着像两个同类竞品。为什么混因为它们确实同源。2017 年那篇 transformer 架构是两者共同的祖先。怎么区分看它们各自用了架构的哪一半。GPT 只取解码器没有编码器也就不需要交叉注意力全靠解码器内部的自注意力来生成上下文表示并做预测天生偏“往下写”。BERT 基于编码器那一半天生偏“读懂输入”。所以在选型上如果你的任务是分类、抽取、判断一段文本的性质编码器路线通常更贴如果是续写、对话、生成内容解码器路线更贴。别把它们当同一类工具的不同品牌它们是同一套架构的两个不同切法。5.4 误区四token 就是单词易混点在于英文里很多 token 看起来就是一个完整单词容易让人直接画等号。为什么混因为简单句子里确实大量出现“一个词一个 token”的情况看着就像按词切的。怎么区分回到那个切分例子——weather 变成 wea therdecided 变成 de ci ded标点也单独占位。token 是模型自己的切分单位跟语言学意义上的“词”没有一一对应关系。这条区别的实用价值在于两处一是算长度和成本时不能用字数代替二是理解模型为什么会拼错生僻词、为什么对某些字符组合特别敏感——那往往是切分方式导致的。中文场景下这个差异更明显一个汉字不一定等于一个 token做预算时务必实测。5.5 误区五上下文窗口越大越好直接上最大的易混点在于 8,192 和 32,768 摆在一起直觉就是选大的。为什么混“能装更多”听起来永远是优势何况大窗口确实解决长文档的痛点。怎么区分窗口大解决的是“装得下”不解决“用得好”。窗口越长你要处理的输入 token 越多成本和延迟跟着涨而且塞进去的内容越多真正关键的那几句越容易被淹掉。合理的做法是先想清楚这个任务到底需要多长的上下文——一段多轮对话、一份合同、一整本书需求差着量级。够用就好剩下的精力放在怎么把关键信息放进 prompt 里收益比盲目拉满窗口大得多。这是我见过的、新手最容易在上面烧钱又不自知的坑之一。6. 什么时候该用它、什么时候别用一份边界判断把前面几章串起来其实就为回答一个问题这个技术该用在哪儿。适合的场景判断标准是“输出是一段自然语言且允许有一定的不确定性”。原文列的方向很有代表性会学习和适应用户的客服系统、按每个学生学习风格调整的个性化教育工具、内容生成器、问答与翻译。这些场景的共同点是价值来自“把话说到位”而不是“把数算准”。模型在文本分类、机器翻译、问答、文本生成这几类任务上已经能直接上手一个模型配不同 prompt 就能覆盖多种需求不需要为每个功能单独训模型。不适合的场景标准反过来要求确定性、要求可核查、要求精确计算的地方。比如账目核对、库存扣减、权限判断这类活儿规则明确用规则系统又便宜又稳硬塞一个语言模型进去等于给自己埋雷。原文里提到 GPS 的路况预测和策略游戏的规则系统也属于 AI 范畴——但它们不需要语言模型这恰好说明“属于 AI”不等于“该用 LLM”。还有一类是“看起来适合其实要加壳”的需要事实准确性的问答。模型是在挑最像话的接法不是在校对事实所以答案流畅但不一定对。这类场景要么在外面接检索要么加人工复核要么把答案限定在给定材料范围内。判断维度适合用别用或要加壳输出形态自然语言段落、摘要、改写精确数值、状态变更容错空间允许人工再过一遍一步错就不可接受任务性质生成、分类、翻译、问答规则明确的流程判定上下文需求一段对话或一份文档需要长期精确记忆的结构化数据有一个具体的例子可以说明这个边界怎么划。假设要做一个内部知识查询工具员工问“差旅报销的标准是什么”让模型直接答它可能给出一个听起来非常合理的数字但那个数字是编的。正确做法是先把相关文档检索出来再把文档片段和问题一起交给模型要求它只依据给到的材料作答。同样是这个模型前面加一道检索答案的可信度就是两回事。这道壳不是可选项是设计的一部分。我自己在这件事上吃过教训。早年做一个内容整理的小工具图省事直接把用户的一段自由文本丢给模型让它输出结构化的分类结果没做任何输入约束也没做输出校验。测试时一切正常上线后遇到几句表述含糊的输入模型开始给出前后矛盾的结果而我在日志里完全看不出问题出在哪——因为整条链路的中间状态我都没留。从那以后我形成了一个习惯凡是模型参与的处理链路输入怎么切、prompt 长什么样、输出怎么解析、失败时回退到什么这四步必须在动手写业务代码之前先用最小样例跑一遍跑通了再往上堆功能。这四步花的时间比起事后在线上排查一个说不清道不明的错误便宜太多了。希望这些能帮你在动手之前先把边界想清楚。至于具体怎么把模型接进一个真实应用、prompt 怎么设计、上下文怎么管、代码怎么组织更细的实操内容都整理在这份资料里需要的可以自己去取来对着看。本文还有配套的精品资源点击获取
简介《Developing Apps with GPT-4 and ChatGPT》是一份 O’Reilly 出版的英文电子书 PDF面向希望把大模型能力落地到实际产品的开发者、技术负责人以及生成式 AI 爱好者重点讨论如何基于 GPT-4 与 ChatGPT 构建智能聊天机器人、内容生成器和其他应用。全书从模型与对话系统的基础概念切入逐步过渡到应用开发所需的关键思路适合具备一定编程基础、希望系统理解接口调用、提示设计与场景落地的中级读者。压缩包内只有 1 个 PDF 文件大小约 2.86MB轻量便携便于离线阅读、全文检索和随时查阅。目前已有 1133 人学习说明该英文原版在 AI 应用开发方向具有一定参考价值。读者可从中了解模型能力边界、聊天机器人构建流程、内容生成场景拆解以及工程实践中的注意事项也能把它作为梳理开发路径、设计产品原型和查阅专业术语的案头资料。1. 一句话说清GPT-4 和 ChatGPT 到底是什么你大概遇到过这种时刻有人张口就是“我们用 ChatGPT 做了个客服机器人”你点头心里却在想——它到底是个啥一套软件一个网站还是某种更底层的零件更让人犯迷糊的是紧接着又冒出个 GPT-4听起来像同一个东西的两个名字。先把定义摆出来GPT-4 和 ChatGPT 都属于大语言模型LLM也就是在海量文本上训练出来的机器学习模型能识别、也能生成接近人类写法的文字。通俗地说它是一个“接话高手”——你丢给它一段话这段输入叫 prompt它算出最可能跟在后面的内容再一个词一个词地吐出来。“GPT-4”指模型本身“ChatGPT”指把这套模型包装成对话形态的产品两者是发动机和整车的关系。搞懂这条线你才知道后面那些 API、token、上下文窗口到底在说什么。2. 从 AI 到 token一条层层嵌套的技术栈2.1 AI、机器学习、NLP、大语言模型到底谁包着谁这几个词最容易被混着用其实它们是一层套一层的。最外面是人工智能AI让计算机去干那些通常需要人类智能才能完成的事。这个定义很宽宽到 GPS 里的路况预测、策略游戏里的规则系统都能算进去——从外面看机器好像“动了脑子”。往里面一层是机器学习ML属于 AI 的子集。区别在于做法机器学习不直接把人定的判断规则写进程序而是让系统自己从例子里学。这条路从 1950 年代就开始了学术文献里积累了大量算法。再往里深度学习是机器学习里很有名的一类而 GPT-4 和 ChatGPT 用的是一种特定的深度学习算法叫 transformer。NLP自然语言处理不是这条“深度”线上的层级它是 AI 的一个应用方向专门管计算机和人类自然语言文本之间的交互。现代 NLP 方案基本都建立在机器学习算法之上。而大语言模型是机器学习模型里专攻“文本生成”这一类任务的那批。打个比方AI 是一整个工具箱ML 是里面那套“会自己学”的工具深度学习是这套工具里最锋利的几把transformer 是其中一把具体的刀LLM 是拿这把刀专门切“文本生成”这道菜的成品。别把它们当成并列的四个东西它们是父子关系。2.2 语言模型要解决的四种活儿NLP 的目标说起来朴素让计算机看懂自然语言文本。但“看懂”落到具体任务上至少有四类。第一类是文本分类把输入的文字塞进预先定好的类别里情感分析这段话是夸还是骂和主题归类这条留言属于售后还是物流都是它。第二类是自动翻译把一种语言的文字转成另一种。第三类是问答给定一段材料回答基于这段材料的问题。第四类是文本生成根据一段输入也就是 prompt产出一段连贯、相关的输出文字。这里有个容易被忽略的变化早几年的模型往往是“一个任务一个模型”做分类的不会翻译。而近一段时间发布的新一代语言模型规模足够大、喂的文本足够多已经能直接干大部分 NLP 任务——分类、翻译、问答都能上手。GPT-4 和 ChatGPT 就是这批模型里在文本生成上表现突出的两个。这个变化的实际意义在于你不需要为每个功能单独训一个模型一个模型配上不同的 prompt 就能覆盖多种场景。这也是为什么“用 GPT 做应用”这件事在工程上突然变得可行——门槛从“训练模型”降到了“写好输入”。2.3 为什么“预测下一个词”能变成聊天大语言模型的工作方式说到底就是一句话给定前面的文字预测最可能接上来的是什么。它靠分析、训练海量文本数据学到词与词之间的模式和关系然后把这种关系反过来用于生成。看个具体例子。输入是“今天天气不错所以我决定去”模型给出的续写可能是“散步”。听起来简单但要做到“听起来像人说的”背后得先判断这段输入的语境、抓住关键信息再在候选词里挑一个最合适的。关键在于这个过程不是查表。模型不是背下了“今天天气不错”后面该接什么而是基于概率打分——给每个可能的候选词算一个分数选分数高的那个作为下一个词。选定之后把它接到输入后面新的整段文字又成为下一轮的输入如此滚动。所以同样一句开头你多问几次得到的续写可能不一样。这套机制解释了两个常见现象。一是模型偶尔会“一本正经地胡说”因为它在挑“最像话”的接法而不是在核对事实。二是它的输出质量高度依赖你给的开头——prompt 写得含糊它就只能往最平庸的方向接。写 prompt 这件事的玄学感根子就在这里。3. 注意力机制Transformer 凭什么成为分水岭3.1 从 n-gram 到 RNN老办法卡在哪在 transformer 之前语言模型走了一段不短的路。最早的一类叫 n-gram思路很直白统计训练文本里跟在某几个词后面出现频率最高的词是哪个就预测那个。这条路能跑通但短板明显——它对上下文和语法的理解很有限生成出来的句子经常前言不搭后语。为了改善后来又引入了更复杂的算法包括循环神经网络RNN和长短期记忆网络LSTM。这类模型能学到更长的序列对上下文的分析比 n-gram 强不少。但它们有一个工程上的硬伤处理海量数据的效率不够。很长一段时间里循环类模型就是最有效的方案也因此被大量用在机器翻译这类工具里。真正的转折点出现在 2017 年transformer 架构被提出来。它大量使用了两样新东西——交叉注意力cross-attention和自注意力self-attention两者都建立在更早提出的注意力机制之上。它们让模型更容易看清一段文字里词与词之间的关系。还有一点常被忽略但极其关键和循环架构不同transformer 天然容易并行化。它可以同时处理输入文本的多个部分而不是排队一个接一个地算。这意味着训练更快也就意味着能在更大的数据集上训模型——大语言模型能“大”起来靠的就是这个前提。3.2 自注意力与交叉注意力两个例子讲透这两个词听着唬人其实就是两种“划重点”的方式。先看交叉注意力。它的作用是帮模型判断输入文本里哪些部分是准确预测下一个词的关键。像一束追光打在输入文本的相关词上把不重要的细节留在暗处。举个翻译的例子把一句“她很喜欢那座城市晴朗的天气”译成法语聚焦到“晴朗”对应的法语词 ensoleillé 时交叉注意力会把更高的权重给“晴朗”和“天气”这两个词——因为它们共同决定了 ensoleillé 的准确性。权重给对了译文这一小段就对了。再看自注意力。它指的是模型在处理输入时关注输入内部不同部分的能力。用 NLP 的话说模型能评估一句话里每个词相对于其他词的重要性从而更好地理解词间关系并从多个词里组合出新的概念。举个例子一句“她收到了同事们的称赞”。模型在处理“她”这个词时自注意力会给句子里不同的词分配不同权重把与“她”相关的词挑出来——这里权重更高的是前文出现的那个人名和“同事们”。于是“她的同事们”这个原本并不存在于任何一个单独词里的组合概念就浮现出来了。这就是原文说的“从多个词构建新概念”。用一句人话来概括这两者的分工交叉注意力管“输出这个词该回头看输入的哪几个词”自注意力管“输入内部谁跟谁是一伙的”。理解这两句话你就理解了 transformer 的核心。3.3 编码器与解码器GPT 只拿了一半标准的 transformer 由两个主要部件组成编码器encoder和解码器decoder两者都重度依赖注意力机制。分工是这样的编码器负责处理输入文本识别其中有用的特征生成这段文字的有意义表示这个表示叫 embedding解码器拿这份 embedding 去产出输出比如一段译文或一份摘要把编码过的信息有效解读出来。跨语言、跨模态的这种“序列到序列”任务里交叉注意力扮演关键角色——它让解码器能用上编码器生成的 embedding。一句话概括编码器负责“读懂”解码器负责“写出”。而 GPT 的选择很有意思它基于 transformer 架构但只用了原架构里的解码器部分。因为没有编码器也就不需要交叉注意力去整合编码器的输出GPT 完全依赖解码器内部的自注意力来生成带上下文的表示和预测。这个取舍不是孤例。另一个知名模型 BERT基于 transformer 的双向编码器表示走的是相反的路——基于编码器那一半。所以当有人把 BERT 和 GPT 放在一起比别以为是两个品牌它们是同一套架构的两个不同切法一个偏“理解输入”一个偏“生成输出”。知道这条分界线很多模型选型的争论就不用再绕了。4. token 与上下文窗口模型眼里的文字长什么样4.1 tokenization 到底在切什么模型并不按“字”或“词”看文本它看的是 token——把输入切成更小的片段这些片段可能是完整的单词也可能是单词的一部分。看个实际例子。输入是“The weather is nice today, so I decided to”切出来的结果大概是[The, wea, ther, is, nice, today, ,, so, I, de, ci, ded, to]。你会发现 weather 被劈成了 wea 和 therdecided 被劈成了 de、ci、ded连逗号都单独算一个 token。每个语言模型都自带自己的 tokenizer切法不通用。这一点在工程上很要命你在 A 模型上算好的长度换到 B 模型上不成立。所以别拿“字数”去估计模型的输入长度量纲根本不对。4.2 上下文窗口模型一次能“看见”多少切完 token模型靠前面讲的注意力和 transformer 架构去处理这些片段解读它们之间的关系和整段输入的语义。因为注意力机制的存在模型能把上下文当成一个整体来考虑而不是像循环模型那样在长输入上吃紧。接着是预测模型给每个可能的候选 token 打一个概率分按分数挑一个作为下一个 token。这个动作重复下去但每次的上下文都在变长。举个直观的第一轮在“今天天气不错所以我决定去”后面定下了“散步”第二轮要预测的时候上下文已经变成了“今天天气不错所以我决定去散步”如此往前滚。那模型一次能看多长的上下文这就是上下文窗口。GPT-4 有两种版本窗口分别是 8,192 个 token 和 32,768 个 token。这两个数字不是凑出来的规格它直接决定了你能塞进去多长的资料——一份长文档、一段多轮对话记录、一批参考资料都在这笔账里。4.3 100 tokens ≈ 75 words这个换算怎么用有一个流传很广的经验法则英文文本里100 个 token 大约等于 75 个单词。反过来估一个英文单词平均约 1.3 个 token。这个换算不是精确公式但足够用来做三件事。第一估算 prompt 长度看离窗口上限还有多大余量。第二估算调用成本很多服务是按 token 计费的输入输出都算。第三判断一份资料能不能一次性塞进去还是得分段处理。看一段示意代码感受一下“算 token”这件事在工程里怎么落地# 估算英文文本的 token 数量经验法则版非精确值 def estimate_tokens(text: str) - int: words text.split() # 按空白切成单词 return int(len(words) * 1.33) # 1 个英文单词约 1.33 个 token prompt Summarize the following document about language models ... est estimate_tokens(prompt) # 上下文窗口设为 8192预留一半给输出 window 8192 budget window // 2 print(f输入约 {est} tokens可用预算 {budget} tokens) if est budget: print(超预算需要分段处理)这段代码里window对应模型的上下文窗口上限budget是你给输入预留的额度之所以只取一半是为了给模型生成的输出留空间——输出也是要占 token 的。estimate_tokens用的是 1.33 的系数它只对英文大致成立中文的切分粒度不同系数得重新估这是很多人第一次算成本时翻车的地方别直接套用。提示这个估算只适合做粗筛。真正上线前请用对应模型自带的 tokenizer 精确计数尤其是处理长文档、要卡成本边界的场景。5. 常见易混概念把 GPT-4、ChatGPT、BERT 分清楚5.1 误区一ChatGPT 和 GPT-4 是同一个东西易混点在于两个名字里都有 GPT日常说话时大家也经常混着叫。为什么混因为对外呈现的时候用户接触到的界面永远叫 ChatGPT而底下跑的可能是不同代的模型。界面没变内核换了感觉就像同一个东西升了个级。怎么区分把 GPT-4 理解成模型把 ChatGPT 理解成产品。模型负责“接话”这个能力本身产品负责对话界面、上下文管理、历史记录这些外壳。判断一个需求该聊哪个层面很简单——你在讨论“它生成的文字质量如何”说的是模型你在讨论“它能不能记住上一轮说了什么、界面怎么用”说的是产品。做应用开发的人尤其要分清这条线你调的是模型你设计的是产品。5.2 误区二模型“理解”了文字易混点在于模型输出的句子太像人话很容易让人以为它读懂了意思。为什么混因为流畅本身就是一种极强的暗示。一段语法通顺、逻辑自洽的回答看上去就像出自一个真的懂了的对象。怎么区分回到机制上。模型做的事情是基于概率预测最可能的下一个 token它学到的是词与词之间的模式和关系而不是在核对事实、建立世界模型。所以它会给出听起来天衣无缝却完全错误的答案。这个区别在做产品时非常实际凡是需要事实准确性的地方都不能只靠模型自觉得在外面接一层校验、检索或者人工确认。把它当“最像话的接话者”而不是“知道答案的人”很多设计决策就顺了。5.3 误区三BERT 和 GPT 只是名字不同易混点在于两者都基于 transformer名字又都带大写字母缩写看着像两个同类竞品。为什么混因为它们确实同源。2017 年那篇 transformer 架构是两者共同的祖先。怎么区分看它们各自用了架构的哪一半。GPT 只取解码器没有编码器也就不需要交叉注意力全靠解码器内部的自注意力来生成上下文表示并做预测天生偏“往下写”。BERT 基于编码器那一半天生偏“读懂输入”。所以在选型上如果你的任务是分类、抽取、判断一段文本的性质编码器路线通常更贴如果是续写、对话、生成内容解码器路线更贴。别把它们当同一类工具的不同品牌它们是同一套架构的两个不同切法。5.4 误区四token 就是单词易混点在于英文里很多 token 看起来就是一个完整单词容易让人直接画等号。为什么混因为简单句子里确实大量出现“一个词一个 token”的情况看着就像按词切的。怎么区分回到那个切分例子——weather 变成 wea therdecided 变成 de ci ded标点也单独占位。token 是模型自己的切分单位跟语言学意义上的“词”没有一一对应关系。这条区别的实用价值在于两处一是算长度和成本时不能用字数代替二是理解模型为什么会拼错生僻词、为什么对某些字符组合特别敏感——那往往是切分方式导致的。中文场景下这个差异更明显一个汉字不一定等于一个 token做预算时务必实测。5.5 误区五上下文窗口越大越好直接上最大的易混点在于 8,192 和 32,768 摆在一起直觉就是选大的。为什么混“能装更多”听起来永远是优势何况大窗口确实解决长文档的痛点。怎么区分窗口大解决的是“装得下”不解决“用得好”。窗口越长你要处理的输入 token 越多成本和延迟跟着涨而且塞进去的内容越多真正关键的那几句越容易被淹掉。合理的做法是先想清楚这个任务到底需要多长的上下文——一段多轮对话、一份合同、一整本书需求差着量级。够用就好剩下的精力放在怎么把关键信息放进 prompt 里收益比盲目拉满窗口大得多。这是我见过的、新手最容易在上面烧钱又不自知的坑之一。6. 什么时候该用它、什么时候别用一份边界判断把前面几章串起来其实就为回答一个问题这个技术该用在哪儿。适合的场景判断标准是“输出是一段自然语言且允许有一定的不确定性”。原文列的方向很有代表性会学习和适应用户的客服系统、按每个学生学习风格调整的个性化教育工具、内容生成器、问答与翻译。这些场景的共同点是价值来自“把话说到位”而不是“把数算准”。模型在文本分类、机器翻译、问答、文本生成这几类任务上已经能直接上手一个模型配不同 prompt 就能覆盖多种需求不需要为每个功能单独训模型。不适合的场景标准反过来要求确定性、要求可核查、要求精确计算的地方。比如账目核对、库存扣减、权限判断这类活儿规则明确用规则系统又便宜又稳硬塞一个语言模型进去等于给自己埋雷。原文里提到 GPS 的路况预测和策略游戏的规则系统也属于 AI 范畴——但它们不需要语言模型这恰好说明“属于 AI”不等于“该用 LLM”。还有一类是“看起来适合其实要加壳”的需要事实准确性的问答。模型是在挑最像话的接法不是在校对事实所以答案流畅但不一定对。这类场景要么在外面接检索要么加人工复核要么把答案限定在给定材料范围内。判断维度适合用别用或要加壳输出形态自然语言段落、摘要、改写精确数值、状态变更容错空间允许人工再过一遍一步错就不可接受任务性质生成、分类、翻译、问答规则明确的流程判定上下文需求一段对话或一份文档需要长期精确记忆的结构化数据有一个具体的例子可以说明这个边界怎么划。假设要做一个内部知识查询工具员工问“差旅报销的标准是什么”让模型直接答它可能给出一个听起来非常合理的数字但那个数字是编的。正确做法是先把相关文档检索出来再把文档片段和问题一起交给模型要求它只依据给到的材料作答。同样是这个模型前面加一道检索答案的可信度就是两回事。这道壳不是可选项是设计的一部分。我自己在这件事上吃过教训。早年做一个内容整理的小工具图省事直接把用户的一段自由文本丢给模型让它输出结构化的分类结果没做任何输入约束也没做输出校验。测试时一切正常上线后遇到几句表述含糊的输入模型开始给出前后矛盾的结果而我在日志里完全看不出问题出在哪——因为整条链路的中间状态我都没留。从那以后我形成了一个习惯凡是模型参与的处理链路输入怎么切、prompt 长什么样、输出怎么解析、失败时回退到什么这四步必须在动手写业务代码之前先用最小样例跑一遍跑通了再往上堆功能。这四步花的时间比起事后在线上排查一个说不清道不明的错误便宜太多了。希望这些能帮你在动手之前先把边界想清楚。至于具体怎么把模型接进一个真实应用、prompt 怎么设计、上下文怎么管、代码怎么组织更细的实操内容都整理在这份资料里需要的可以自己去取来对着看。本文还有配套的精品资源点击获取
