代码语言

知识点思维导图

29 个知识节点

Prompt Engineering(02) - 理解大模型如何处理提示词

读完后,你应能完成以下任务:

  • 绘制“Prompt Engineering(02) - 理解大模型如何处理提示词 / 为什么要懂一点「原理」”的关键对象与数据流,解释“你不需要会造汽车才能开车,但懂一点「油门、刹车、方向盘」的原理,能让你开得更稳、更不容易出事。”,并用源码位置、日志或 Trace 标注证据。
  • 为“Prompt Engineering(02) - 理解大模型如何处理提示词 / Token:模型眼里的「字」不是你以为的字”设计正常与异常输入,验证“费用按 Token 算。 几乎所有按量付费的大模型 API,都是数 Token 收钱的(输入 + 输出一起算)。你发的提示词越长、它回答得越长,花的钱越多。 -> 长度限制按 Token 算。”,输出首个偏差位置与回归测试结果。
  • 实现“Prompt Engineering(02) - 理解大模型如何处理提示词 / 模型不是一个字一个字读的”的最小代码或配置,检验“我们读中文是一个字一个字读,读英文是一个单词一个单词读。”,输出命令、结果与 Diff,并说明不适用边界。

本章目标:用大白话理解大模型是怎么工作的,搞懂 Token、上下文窗口、「预测下一个词」、temperature、System/User 这几个关键概念。不讲数学,只讲直觉。


一、为什么要懂一点「原理」

你不需要会造汽车才能开车,但懂一点「油门、刹车、方向盘」的原理,能让你开得更稳、更不容易出事。

提示词也是一样。你不需要懂神经网络的数学,但如果你知道模型「大概是怎么想的」,你就能明白:

  • 为什么长对话聊着聊着它就「忘」了前面说过的话?
  • 为什么它有时候会非常自信地编造一个根本不存在的事实?
  • 为什么同样一句话,它这次这么答、下次那么答?
  • 为什么「给例子」「分角色」这些技巧真的管用?

这一章,我们就把模型的「脑子」拆开看看。放心,全程大白话。


二、Token:模型眼里的「字」不是你以为的字

2.1 模型不是一个字一个字读的

我们读中文是一个字一个字读,读英文是一个单词一个单词读。但模型读的东西,叫 Token(词元)

你可以把 Token 理解成:模型处理文字的最小积木块。 它可能是一个词、半个词、一个字,甚至一个标点。

  • 英文里,一个常见单词往往是 1 个 Token,长一点的词会被拆成几块。比如 apple 是 1 个,unbelievable 可能被拆成 un believ able 3 块。
  • 中文里,常见的情况是 1 个汉字约等于 1~2 个 Token(不同模型切法不同)。

举个直观的对比:

英文:I love prompt engineering   → 大约 4~5 个 Token
中文:我爱提示词工程             → 大约 6~10 个 Token

同样表达一个意思,中文往往比英文消耗更多 Token。

2.2 为什么你要在乎 Token

两个非常现实的原因:

  1. 费用按 Token 算。 几乎所有按量付费的大模型 API,都是数 Token 收钱的(输入 + 输出一起算)。你发的提示词越长、它回答得越长,花的钱越多。
  2. 长度限制按 Token 算。 模型能「一次性看多少字」,限制的单位也是 Token,不是字数。

所以当你听到「这个模型支持 128K 上下文」,意思是它一次最多能处理大约 12.8 万个 Token,而不是 12.8 万个汉字——换算成中文,差不多是 6~9 万字。

小心得:写提示词时不用斤斤计较每个 Token,但要有个意识——话说清楚的前提下,能短就短。 又臭又长的提示词既费钱,又容易让模型抓不住重点。


三、上下文窗口:模型的「短期记忆」是有限的

3.1 它没有真正的「记忆」

很多人以为,跟 AI 聊天就像跟一个人聊天,它会「记住」你们聊过的一切。其实不是。

模型每次回答,都是把当前能看到的全部内容重新读一遍再作答。这个「它一次能看到的全部内容」,就叫 上下文窗口(Context Window)

打个比方:模型像一个没有长期记忆、但桌面很大的人

  • 你跟它说的每句话,都写在便利贴上贴到桌面。
  • 它每次回答,都是把桌面上所有便利贴扫一遍。
  • 但桌子大小有限(就是上下文窗口)。贴满了,最早的便利贴就会被挤掉。

3.2 这解释了一个经典现象:长对话「失忆」

为什么一段超长的对话聊到后面,模型会忘记你开头说过的设定?

因为开头那些话,已经被挤出上下文窗口了。它不是「忘了」,是根本看不到了

这也解释了几个实用技巧为什么有效:

  • 重要信息往后放 / 适时重复。 关键约束如果在很久以前说过,临到用的时候不妨再说一遍。
  • 长任务要「喂重点」而不是「喂全部」。 与其把一本书全塞进去,不如先提炼要点再让它处理。
  • 新开一个对话往往更干净。 当一段对话被各种跑题内容塞满,模型的注意力会被稀释,这时重开一个、只给必要信息,效果反而更好。

四、模型的本质:它在玩「预测下一个词」的接龙游戏

这是整章最重要的一节。理解了它,很多奇怪现象就都通了。

4.1 它本质上是个「超级接龙高手」

大模型的核心能力,说穿了只有一件事:

根据前面已有的内容,预测下一个最可能出现的 Token,然后一个接一个地往下写。

就像你玩文字接龙。我说「天空是」,你大概率会接「蓝色的」,因为在你见过的海量句子里,「天空是」后面跟「蓝色的」最常见。

模型就是把这件事做到了极致——它读过的文本多到惊人,所以它对「这句话后面最可能跟什么」的判断非常准。它写出一篇通顺、像样的文章,靠的就是一次又一次地预测下一个词。

4.2 关键认知:它追求的是「像」,不是「对」

这里有个特别重要的点:

模型预测的是「最像样的下一个词」,而不是「最正确的下一个词」。

大多数时候,「像样」和「正确」是一致的,所以它答得又好又对。但当它不知道答案时,它不会说「我不知道」——因为「我不知道」在它学过的文本里,往往不是一个「像样」的接续。它会顺着语感,编一个听起来最合理的答案出来。

这就是大名鼎鼎的 幻觉(Hallucination)

  • 你问它一本不存在的书的作者,它能一本正经地给你编一个名字。
  • 你问它某个 API 的参数,它可能拼出一个根本不存在但「看起来很对」的参数名。
  • 你问它一个法条,它能编出条款号和内容。

它不是在骗你,它只是在「接龙」,而它的目标从来都是「通顺像样」,不是「事实正确」。

4.3 这给提示词的启示

明白了「预测下一个词」和「追求像样」,你就懂了这些技巧为什么有效:

  1. 给上下文 = 给它更好的「开头」。 接龙时开头给得越具体,后面接得越准。你提供的背景越充分,它「猜」的空间就越小,幻觉就越少。
  2. 关键事实自己提供,别让它凭空想。 涉及具体数字、名称、引用时,把资料喂给它,而不是指望它「记得」。
  3. 让它「先想再答」。 要求它分步骤推理(而不是直接给结论),相当于让它把接龙过程拉长,每一步都更稳,结论也更可靠。这是后面章节会讲的「思维链」。
  4. 重要内容必须自己核实。 既然它会一本正经地胡说,那么凡是关键事实,永远不要不加核对就采信。

五、Temperature:控制模型「放飞」程度的旋钮

5.1 它在调什么

前面说模型每一步都在预测「下一个最可能的词」。但其实,每一步它心里都有一张候选词的概率表

天空是 → 蓝色的(60%)  灰色的(20%)  晴朗的(10%)  ...

Temperature(温度)就是一个旋钮,决定它在挑词时有多「听话」还是多「放飞」。

  • 温度低(接近 0):它几乎总是挑概率最高的那个词。结果稳定、保守、可复现——同一个问题问多次,答案都差不多。
  • 温度高(比如 1 以上):低概率的词也有机会被选中。结果多样、有创意、有惊喜,但也更容易跑偏、出错、胡说。

打个比方:温度低像一个严谨的会计,每次都给你最标准的答案;温度高像一个爱发散的创意人,常常给你意想不到的点子,但偶尔不靠谱。

5.2 取值建议(拿来即用)

任务类型 建议温度 为什么
事实问答、代码、数据提取、翻译 0 ~ 0.3 要的是准确稳定,不要它自由发挥
日常写作、总结、改写 0.3 ~ 0.7 兼顾准确和一点灵气
头脑风暴、起名、文案创意、写故事 0.7 ~ 1.0+ 要的就是多样和惊喜

注意:不是所有产品都让你调温度。网页版聊天工具通常帮你定好了(一般是中等偏低);只有在用 API 时你才直接控制它。但理解这个概念能帮你判断:当你要严谨答案时它却在「放飞」,可能就是温度太高了。


六、System 和 User:给模型「分角色」说话

用 API 时,你会发现发给模型的内容是分「角色」的,最常见的两个是:

  • System(系统提示):相当于给模型立的「人设」和「总规矩」。比如「你是一名资深中医,回答要严谨、引用经典、不下诊断结论」。它定的是整场对话的基调和边界
  • User(用户提示):就是你每一轮具体说的话、提的问题。

打个比方:

  • System 像剧本里给演员的「角色设定」:你演一个冷静的侦探,全程要保持这个性格。
  • User 像导演每一场喊的具体指令:这场戏,你去审问这个嫌疑人。

为什么要分开?因为这样人设稳、指令活:你在 System 里把「它是谁、要守什么规矩」一次说清,之后每轮 User 只管提具体需求,不用反复重申身份,模型也不容易「跑出人设」。

在网页版聊天工具里,虽然你看不到这两个角色框,但「自定义指令」「系统提示」之类的设置,本质就是在写 System。

这套「角色 + 任务 + 约束」的思路,正是第 04 章「五要素框架」的雏形。


七、常见错误(新手最容易踩的坑)

  1. 以为它「记得」一切。 它只看得到当前上下文窗口里的内容,超出的就是看不见了,不是忘了。
  2. 把它的胡说当真。 尤其是具体的数字、人名、书名、法条、API 参数——它最擅长一本正经地编。关键事实必须自己核实。
  3. 要严谨答案却用了高温度。 比如让它提取数据、写代码,却开着很高的 temperature,结果飘忽不定还容易错。
  4. 把超长资料一股脑塞进去。 既费 Token 又稀释重点,不如先提炼再喂。
  5. 指望它「无中生有」。 涉及你特有的信息(你的项目、你的数据、最新的事),不给它就只能靠编。

八、最佳实践(理解原理后的心法)

  • 把模型当成一个「读过海量书、但记不住你私事、还会脑补」的接龙高手。 你给的开头越好,它接得越准。
  • 关键事实,自己喂、自己核。 别赌它「正好知道」。
  • 按任务选温度:要准就调低,要点子就调高。
  • 长对话注意「失忆」:重要约束适时重复,必要时重开干净对话。
  • 能短则短:清楚是第一位,啰嗦只会费钱又分散注意力。

九、本章小结

  • Token 是模型处理文字的积木块,中文通常比英文更费 Token;费用和长度限制都按它算。
  • 上下文窗口 是模型的「短期记忆」,有上限,所以长对话会「失忆」。
  • 模型的本质是 预测下一个最「像样」的词,它追求通顺而非正确,所以会产生幻觉——会一本正经地胡说。
  • Temperature 是放飞旋钮:低=稳定保守,高=多样有创意,按任务选值。
  • System 立人设定规矩,User 提具体需求,分开写让人设稳、指令活。

懂了模型怎么「想」,下一章我们就正式动手,写出你的第一个明显更好的提示词。


十、配套 Demo

提示词工程-demo/02-demo/:一个纯 Python 标准库的小脚本 temperature_demo.py,给定一组词的概率分布,用不同 temperature 做采样并打印结果分布,让你亲眼看到温度如何改变随机性;另外还有一个简单的「Token 估算」小函数,直观演示中英文长度差异。运行方式和预期结果见该目录的 README。

十一、动手实践:demo:用代码看懂 temperature 和 Token

这个 Demo 配合小册 02 章,用一个纯 Python 标准库的小脚本,让你亲眼看到两件事:

  1. temperature(温度) 怎么改变模型挑词的随机性。
  2. 同样意思,中文为什么比英文更费 Token

不联网、不装包、不调任何 API。只要你电脑里有 Python 3 就能跑。

11.1 怎么运行

打开终端,进到本目录,执行:

python3 temperature_demo.py

(脚本里固定了随机种子,所以你每次跑结果都一样,方便对照。)

11.2 你会看到什么

第一部分:温度对采样的影响

脚本模拟「天空是____」后面,模型的 5 个候选词及其打分,然后分别用 温度 0.2 / 0.7 / 1.5 各采样 2000 次,打印每个词被选中的比例(带字符条)。

你会观察到一个清晰的规律:

  • 温度 0.2(低):几乎 100% 都选了打分最高的「蓝色的」,非常稳定保守。
  • 温度 0.7(中):「蓝色的」仍占大头,但其他词开始有零星机会。
  • 温度 1.5(高):分布明显变平,连「奇怪的」这种冷门词都频繁冒出来,随机性大增。

这就是小册里说的:温度越低越稳,温度越高越放飞。

第二部分:中英文 Token 估算

脚本用一个粗略的估算函数,对几组中英文对照文本算 Token 数。你会看到: 表达同一个意思,中文通常比英文更费 Token——这正是为什么中文调用 API 往往更贵、也更容易触达长度上限。

注意:这里的 Token 估算只是「找感觉」用的经验规则,不是任何真实模型的精确切分。真实切分由各模型的分词器决定,这里只为帮你建立「中文更费 Token」的直觉。

11.3 动手改一改

想加深理解,试试改脚本里的参数(都在 main() 函数里):

  • scores 改得更接近(比如全改成 [3, 2.8, 2.6, 2.4, 2.2]),看低温度下是不是也开始分散了。
  • 把温度列表 [0.2, 0.7, 1.5] 加一个 3.0,看分布是不是几乎变成「平均乱选」。
  • samples 里加你自己的中英文句子,对比它们的 Token 估算。

改完再跑一遍 python3 temperature_demo.py,对照结果,你对温度和 Token 的感觉会越来越扎实。

十二、总结

  • Token:模型眼里的「字」不是你以为的字:费用按 Token 算。 几乎所有按量付费的大模型 API,都是数 Token 收钱的(输入 + 输出一起算)。你发的提示词越长、它回答得越长,花的钱越多。 -> 长度限制按 Token 算。
  • 上下文窗口:模型的「短期记忆」是有限的:模型每次回答,都是把当前能看到的全部内容重新读一遍再作答。
  • 模型的本质:它在玩「预测下一个词」的接龙游戏:给上下文 = 给它更好的「开头」。 -> 关键事实自己提供,别让它凭空想。 -> 让它「先想再答」。 要求它分步骤推理(而不是直接给结论),相当于让它把接龙过程拉长,每一步都更稳,结论也更可靠。这是后面章节会讲的「思维链」。 -> 重要内容必须自己核实。 既然它会一本正经地胡说,那么凡是关键事实,永远不要不加核对就采信。
  • Temperature:控制模型「放飞」程度的旋钮:Temperature(温度)就是一个旋钮,决定它在挑词时有多「听话」还是多「放飞」。
  • System 和 User:给模型「分角色」说话:比如「你是一名资深中医,回答要严谨、引用经典、不下诊断结论」。
  • 常见错误(新手最容易踩的坑):以为它「记得」一切。 它只看得到当前上下文窗口里的内容,超出的就是看不见了,不是忘了。 -> 把它的胡说当真。 尤其是具体的数字、人名、书名、法条、API 参数——它最擅长一本正经地编。关键事实必须自己核实。 -> 要严谨答案却用了高温度。 比如让它提取数据、写代码,却开着很高的 temperature,结果飘忽不定还容易错。 -> 把超长资料一股脑塞进去。 既费 Token 又稀释重点,不如先提炼再喂。

学完自测

选择所有正确答案;提交后逐项核对判断依据。

1在“理解大模型如何处理提示词”中,需要同时满足“为什么要懂一点「原理」”与“模型不是一个字一个字读的”。给定正文约束“你不需要会造汽车才能开车,但懂一点「油门、刹车、方向盘」的原理,能让你开得更稳、更不容易出事。”,哪些判断保持了原有处理机制?多选
2“理解大模型如何处理提示词”出现偏差:“在“理解大模型如何处理提示词 / 为什么你要在乎 Token”中,即使不满足“模型能「一次性看多少字」,限制的单位也是 Token,不是字数”,结果与副作用仍会保持不变。”已成为实际行为。围绕“为什么你要在乎 Token”与“它没有真正的「记忆」”,哪些判断能定位被改变的职责或边界?多选
3评审“理解大模型如何处理提示词”方案时,验收条件包含“因为开头那些话,已经被挤出上下文窗口了。”。关于“这解释了一个经典现象:长对话「失忆」”与“它本质上是个「超级接龙高手」”的哪些决策符合正文机制?多选