2、大模型技术基础速通：Transformer架构核心概念、Token与上下文窗口、预训练与微调的区别
好，咱们直接进入正题。这一章我打算用最接地气的方式，把大模型底层的几个硬核概念给你讲透。你不需要成为算法专家，但作为AI产品经理，这些是你跟工程师battle、跟客户吹牛、以及设计产品时的底气。
2.1 Transformer架构：大模型的“心脏”
说白了，现在所有你能叫得上名字的大模型——GPT、BERT、LLaMA、文心一言——它们的底层都是Transformer。这玩意儿2017年由Google提出来，当时是为了做机器翻译。结果大家发现，这架构太能打了，直接统治了NLP领域。
我刚开始接触Transformer时，也被那些“自注意力”、“多头注意力”搞得头大。后来我换了个角度想：你就把它想象成一个超级高效的“信息筛选器”。
2.1.1 自注意力机制（Self-Attention）
这是Transformer最核心的发明。为什么它这么牛？
传统模型处理一句话时，是一个词一个词地看，看完前面忘后面。但自注意力机制不一样——它让每个词都能“看到”句子里的所有其他词，然后决定哪些词跟它关系最密切。
举个例子，句子是：“那只猫追了一只老鼠，它跑得很快。” 这里的“它”指的是猫还是老鼠？人一眼就能看出来，但机器不行。自注意力机制就是让模型在处理“它”这个词时，去计算“它”跟“猫”和“老鼠”的关联度。如果上下文是“追”，那大概率“它”指的是老鼠。
产品经理理解要点：
- 自注意力让模型有了“全局视野”，不再是瞎子摸象
- 计算量跟序列长度的平方成正比——这就是为什么长文本处理那么贵
我在项目中遇到过，有产品经理非要让模型处理10万字的合同。我跟他说，不是不能做，但你要准备好烧钱。因为自注意力的计算复杂度是O(n²)，10万字比1万字的计算量大了100倍，不是10倍。
2.1.2 多头注意力（Multi-Head Attention）
这个更好理解。一个头看问题可能片面，那就搞8个头、16个头，让它们从不同角度去看。
比如处理“苹果”这个词：一个头可能关注它的颜色属性，另一个头关注它的水果属性，还有一个头关注它作为品牌时的含义。最后把这些信息综合起来，模型就能准确判断当前语境下“苹果”到底是什么意思。
嗯，这里要注意：头数不是越多越好。我见过一些团队盲目堆头数，结果模型没变聪明，反而更耗显存。一般12-16个头是比较常见的配置。
2.1.3 位置编码（Positional Encoding）
Transformer有个“先天缺陷”——它天生不区分词的顺序。你想想看，“我打你”和“你打我”，词是一样的，但意思完全相反。如果没有位置信息，模型会认为这两句话是一样的。
所以工程师们想了个办法：给每个词的位置打上一个“编码标签”，告诉模型这个词是第几个出现的。这就是位置编码。
避坑指南： 我曾经见过一个团队，在微调时忘了调整位置编码的维度，结果模型在长文本上表现极差。后来排查了两天才发现是位置编码跟模型维度不匹配。这种低级错误，你作为PM也要心里有数，别被工程师一句“技术问题”糊弄过去。
2.2 Token与上下文窗口：大模型的“视力”和“记忆力”
这两个概念你几乎每天都会遇到。我建议你把它理解成人的眼睛和短期记忆。
2.2.1 Token：模型眼中的“字”
模型不是直接看中文汉字的。它会把文本切分成一个个小片段，这些片段就叫Token。
一个Token可以是一个完整的词，也可以是半个词，甚至是一个标点符号。比如“人工智能”这个词，在有些模型里是一个Token，在另一些模型里可能被切成“人工”和“智能”两个Token。
| 文本 | Token切分示例 | Token数量 |
|---|---|---|
| 你好世界 | ["你好", "世界"] | 2 |
| I love AI | ["I", " love", " AI"] | 3 |
| ChatGPT是神器 | ["Chat", "GPT", "是", "神器"] | 4 |
为什么你要关心这个？因为大模型是按Token收费的！你让用户输入1000个汉字，可能实际消耗了1500个Token。我建议你在设计产品时，一定要搞清楚你用的模型是怎么切Token的，否则预算算不准。
注意： 不同模型的中文Token切分效率差异很大。有些模型一个中文词占2-3个Token，有些只占1个。这直接影响到你的成本。选模型时，记得让算法团队给你做个Token效率测试。
2.2.2 上下文窗口：模型的“工作记忆”
上下文窗口就是模型一次能“看到”的最大Token数量。比如GPT-3.5的上下文窗口是4096个Token，GPT-4是8192或32768，Claude 2是100K。
这决定了你的产品能处理多长的对话或多大的文档。我举个例子：
- 4096 Token ≈ 3000个中文词，大概够聊20-30轮对话
- 32768 Token ≈ 24000个中文词，可以处理一篇完整的论文
- 100K Token ≈ 75000个中文词，差不多是一本短篇小说的长度
我个人习惯在设计产品时，给上下文窗口留30%的余量。为什么？因为模型在处理接近窗口上限的输入时，性能会明显下降，就像人记太多东西会忘一样。你想想看，让模型在最后100个Token里做精确推理，它可能已经忘了开头说了什么。
产品设计原则： 上下文窗口不是越大越好。窗口越大，计算成本越高，响应速度越慢。你要根据实际场景选择合适的大小。做客服机器人，4096就够了；做文档分析，至少需要8192。
2.3 预训练与微调：从“通才”到“专才”
这两个概念是产品经理必须分清楚的。我见过太多人把微调当成万能药，结果花了大价钱效果却不好。
2.3.1 预训练：培养一个“通才”
预训练就是让模型在海量数据上“自学”。这个过程极其烧钱——GPT-3的预训练据说花了1200万美元。模型读完了互联网上大部分公开文本，学会了语法、常识、推理能力，但这时候它还是个“什么都会一点，什么都不精”的通才。
预训练的特点：
- 数据量巨大：TB级别，甚至PB级别
- 计算成本极高：需要成千上万张GPU跑几周甚至几个月
- 产出的是“基础模型”：比如GPT-3、LLaMA、BERT
- 你作为产品经理，基本不需要参与预训练——这是大厂和实验室的事
2.3.2 微调：打造一个“专才”
微调就是在预训练模型的基础上，用你的业务数据再训练一下。成本低得多，效果却可能非常好。
我举个例子：你做一个法律咨询AI。预训练模型知道法律是什么，但它不知道如何回答用户的法律问题。你拿几万条法律问答数据去微调，模型就学会了“法律专家”的说话方式和知识体系。
| 对比维度 | 预训练 | 微调 |
|---|---|---|
| 数据量 | TB级 | 千条到百万条 |
| 成本 | 百万到千万美元 | 几百到几万美元 |
| 时间 | 数周到数月 | 几小时到几天 |
| 目标 | 通用能力 | 特定任务 |
| 谁来做 | 大厂/研究机构 | 你的团队 |
我的经验： 很多产品经理一上来就想微调，其实没必要。你先试试Prompt Engineering（提示词工程），很多时候调调提示词就能解决80%的问题。微调是锦上添花，不是雪中送炭。我曾经有一个项目，团队花了两周微调模型，效果提升不到5%。后来我让他们回去优化提示词，一天就搞定了，效果提升了15%。
2.3.3 什么时候该微调？
我总结了几条判断标准：
- 你的任务需要特定格式的输出——比如必须输出JSON，或者必须遵循某种报告模板
- 你的领域知识非常专业——比如医疗诊断、法律条文、金融风控，通用模型搞不定
- 你需要模型学习你的用户习惯——比如客服机器人要模仿特定品牌的语气
- 提示词已经优化到极限了——你再怎么调提示词，效果都不再提升
如果以上四点都不满足，我建议你先别碰微调。用现成的API加上好的提示词设计，足够应付大多数场景。
一个常见的坑： 微调不是数据越多越好。我见过有人塞了100万条低质量数据进去，结果模型反而变笨了。微调数据的质量远比数量重要。1000条精心标注的数据，效果可能好过10万条随便爬的数据。
好了，这一章的核心内容就这些。你掌握了Transformer的基本原理、Token和上下文窗口的概念、以及预训练和微调的区别，就已经比80%的产品经理懂技术了。下一章我们聊聊怎么把这些知识落地到产品设计中。