奇链 奇链
← 文章 / AI技术
产品经理AI转型日记 1小时前 · 2026-10-02 21:09:22 · 2 阅读

【AI实验室02】大模型的＂思考方式＂:Token、注意力机制与上下文窗口

AI实验室 02 / 领域一 · AI技术通识

大模型的"思考方式"：Token、注意力机制与上下文窗口

不写代码也能理解大模型。用产品经理的语言拆解Transformer架构的核心思路——建立对大模型能力边界的直觉判断。

LLM原理Token注意力机制上下文窗口阅读约 15 分钟

你不需要会推导反向传播公式，但你需要知道：为什么同一句话在不同模型里消耗的Token数不同、为什么128K上下文窗口不等于能处理128K的业务、为什么模型有时候会"一本正经胡说八道"。这些判断直接影响你写PRD时的技术选型、做成本测算时的准确性、以及评估产品可行性时的直觉。这篇文章拆解五个核心概念，每个都配上金融场景的真实案例。

Token：模型的最小计费单位

大模型不读"字"也不读"词"，它读的是Token。Token是模型处理信息的最小单元——你可以把它理解成大模型的"像素"。一段文字被切分成Token的过程叫Tokenization，这个过程直接决定了你调用API时的费用和模型对语义的理解精度。

不同语言的Token消耗差异很大。英文中一个Token大约是4个字符，或者3/4个单词（比如"hello"是一个Token，"extraordinary"会被拆成"extra"和"ordinary"两个）。中文更"贵"——一个汉字通常需要1-2个Token，因为分词器要在表意文字和词义之间找平衡。

同一段文字的Token化对比

原文："2026年第三季度，沪深300指数上涨8.7%"

2026年第三季度，沪深300指数上涨8.7%

中文词 数字 标点/符号

上面这句话被切分为15个Token。如果用英文表达同样的意思——"In Q3 2026, the CSI 300 index rose 8.7%"——大约只需要11个Token。这意味着中文场景的API调用费用通常比英文高30-50%。

Token如何影响你的产品成本

以金融场景为例：一份50页的研报大约包含3-4万汉字，换算成Token约5-7万。如果每天用GPT-4o处理100份这样的研报，仅输入端就要消耗500-700万Token。

模型输入价格
($/百万Token)		输出价格
($/百万Token)		100份研报/天
输入成本
GPT-4o$2.50$10.00$15-17.5
Claude 3.5 Sonnet$3.00$15.00$18-21
DeepSeek V3$0.27$1.10$1.35-1.89

DeepSeek V3的价格只有GPT-4o的十分之一。如果你的产品需要高频处理大量中文文档——比如每日研报摘要、合同审查、舆情监控——模型选择直接决定成本结构是每月几百元还是几万元。

PM行动指南

在做成本测算时，不要按"字数"估算，要按Token数。一个实用的经验法则：中文1000字大约等于1300-1800个Token（取决于分词器和文本类型）。先用目标模型的分词工具实际计算一遍，再做财务模型。

注意力机制：模型如何决定"关注什么"

Transformer架构的核心创新是自注意力机制（Self-Attention）。通俗地说，它让模型在处理每个Token时，能够"回头看"整段文本，决定哪些Token与当前任务最相关。

想象你在读一份基金招募说明书，需要回答"这只基金的投资范围是什么"。你的眼睛不会逐字扫描——你会跳过大段的法律条款，直接锁定"投资范围""资产配置""持仓比例"这些关键词周围的段落。注意力机制做的事情类似：它为每个Token计算一组"注意力权重"，权重高的Token对输出影响更大。

但注意力机制有一个关键缺陷：它不是均匀分配的。Softmax函数要求所有注意力权重之和为1，当上下文变长时，每个Token分到的注意力就被"稀释"了。这就像一束手电筒的光——照得越远，每个点分到的光就越弱。

"Lost in the Middle"：长文档的致命问题

斯坦福大学Liu等人在2023年的研究中揭示了一个反直觉的现象：当关键信息出现在长文档的中间位置时，大模型的召回率会大幅下降。

这组数据的含义很直接：如果你把一份100页的基金合同喂给模型，然后问一个关键条款的细节——而这个条款恰好在第50页左右——模型"看到"它的概率比条款在第1页或第100页时低一半。

2026年的最新基准测试进一步验证了这个问题。在最严格的MRCR v2测试中（要求在长文本中找到8个相似信息中的特定一个），当上下文达到100万Token时，表现最好的GPT-5.5准确率也只有74%，而部分模型跌至26%。

PM行动指南

在设计长文档处理产品时，不要把关键信息"埋"在中间。把核心指令放在Prompt的开头或末尾；对于合同审查、研报分析等场景，用RAG（检索增强生成）先提取相关段落，再喂给模型——而不是把整份文档一股脑塞进去。

上下文窗口：标称值 vs 有效值

上下文窗口（Context Window）是模型一次能处理的最大Token数。它是你在产品架构中做"切分策略"时的硬约束——超过这个长度，模型根本看不到后面的内容。

2026年，主流模型的标称上下文窗口已经很大了：

128K

GPT-4o
上下文窗口

200K

Claude 3.5 Sonnet
上下文窗口

128K

DeepSeek V3
上下文窗口

1M

Gemini 2.5 Pro
上下文窗口

但"标称值"和"有效值"之间有一条巨大的鸿沟。行业测试数据显示，模型实际能有效利用的上下文通常只有标称值的50-65%。超过这个阈值，模型的检索准确率开始明显下降——业界称之为"上下文腐烂"（Context Rot）。

标称窗口 vs 有效窗口（多信息点检索准确率 > 75%）

GPT-4o (128K)~83KClaude 3.5 (200K)~116KDeepSeek V3 (128K)~64KGemini 2.5 Pro (1M)~128K

有效利用区域 准确率不可靠区域

这意味着什么？以金融场景为例：

  • 128K窗口的GPT-4o：有效利用约8万Token，相当于处理一份60-70页的中文研报。对于大多数单篇研报分析够用，但如果你试图让它同时对比10份研报，超出部分的信息会被"遗忘"。
  • 1M窗口的Gemini 2.5 Pro：标称可以处理100万Token，但实测在128K以上准确率就开始大幅下降。真正可靠的容量大约和GPT-4o相当。
  • DeepSeek V3：128K窗口，有效利用约64K Token。但它的价格只有GPT-4o的十分之一——如果你的场景可以接受RAG预处理，用DeepSeek处理检索后的片段反而更划算。

PM行动指南

做产品规划时，按"标称值 x 50%"估算有效上下文。如果你的场景需要处理的信息量超过有效窗口，不要赌模型能"看到"——用RAG、分块处理、或者摘要压缩来兜底。在PRD里写清楚技术约束，避免上线后出现"模型漏看关键条款"的事故。

温度参数：控制模型的"创造力"与"确定性"

Temperature（温度）是调用大模型API时最重要的可调参数之一。它控制的是模型输出时的"随机性"——或者说，模型在多个可能的下一个Token之间做选择时的"大胆程度"。

直觉理解：温度低（接近0），模型总是选概率最高的那个Token，输出稳定、可预测、适合精确任务；温度高（接近1或更高），模型会冒险选概率较低的Token，输出更多样、更有创意、但也更不可控。

Temperature行为特征适用场景金融案例
0 - 0.2高度确定，几乎可复现数据提取、分类、合规检查从研报中提取PE/PB数值
0.3 - 0.5较稳定，偶有变化摘要、翻译、格式化输出生成每日市场摘要
0.6 - 0.8平衡创造与一致文案、方案设计、头脑风暴撰写投资者教育文章
0.9 - 1.2高度多样，不可预测创意写作、广告语、发散思维基金产品营销创意
> 1.2接近随机，连贯性下降通常不建议在生产环境使用-

2026年ICLR的一项研究给出了一个反常识的发现：在多选题问答任务中，Temperature从0到1.0的范围内，准确率其实保持稳定；只有超过1.0之后才开始急剧下降，到1.6附近文本基本失去连贯性。这意味着对于"判断对错"类任务，Temperature在0-1之间的影响没有想象中那么大——但超过1之后就是悬崖。

在金融场景中，Temperature的选择本质上是一个业务决策：你需要的是"稳定可靠"还是"灵感迸发"？风控报告生成用0.2，营销文案用0.8——这不是技术偏好，是产品定位。

PM行动指南

在PRD中明确Temperature的默认值。很多团队把Temperature留给开发随意设置，结果同一类任务的输出质量忽高忽低。建议：信息提取类任务统一设为0，内容生成类任务设为0.7，并在评测体系中纳入"输出一致性"指标。

幻觉：为什么模型会"一本正经胡说八道"

幻觉（Hallucination）是大模型最让产品经理头疼的问题。它指的是模型生成的内容看起来流畅、自信，但实际上是编造的——引用不存在的论文、捏造数据、虚构法律条款。

幻觉的成因可以从三个层面理解：

1. 训练目标的固有缺陷

大模型的训练目标是"预测下一个Token"——它优化的是语言的流畅性和连贯性，而不是事实的准确性。模型并不"知道"什么是真的，它只知道什么"看起来像真的"。当训练数据中某个模式出现频率很高时，模型会倾向于生成符合该模式的内容，即使具体内容是错的。

2. 知识的模糊边界

模型的知识来自训练数据，但它没有"我记得"和"我猜的"之间的区分能力。当被问到一个训练数据中没有明确答案的问题时，它不会说"我不知道"——它会根据已有模式"推理"出一个看起来合理的答案。这在金融场景中尤其危险：模型可能会把A公司的财务数据"嫁接"到B公司上，或者把过时的政策当作现行政策来引用。

3. 长上下文加剧幻觉

前面的"Lost in the Middle"问题在幻觉层面有另一个表现：当上下文很长时，模型对中间部分的信息记忆模糊，但它不会承认"我没看清"——它会根据上下文的其他部分"脑补"出一个答案。研究表明，100K Token上下文的幻觉率比10K上下文高出约5倍。

上下文长度事实准确率幻觉率覆盖率
10K Token95%~2%90%
50K Token82%~12%73%
100K Token71%~23%58%

PM如何在产品设计中防范幻觉

  • 要求模型引用来源：在Prompt中明确要求"只基于提供的文本回答，如果文本中没有相关信息请说'未找到'"。这不能消除幻觉，但能显著降低概率。
  • 结构化输出：让模型输出JSON格式而不是自由文本，减少"自由发挥"的空间。金融数据提取场景中，定义好字段名和取值范围。
  • 交叉验证：关键数据用两个模型分别提取，对比结果。如果GPT-4o和DeepSeek给出不同的PE数值，人工复核。
  • 设置置信度阈值：让模型对每个输出给出置信度评分，低于阈值的结果标记为"需人工审核"。
  • 限制上下文长度：与其把100页文档全塞给模型，不如先用检索工具找到最相关的5页。上下文越短、越聚焦，幻觉越少。

PM行动指南

在PRD中写清楚幻觉的应对策略，而不是把"AI可能出错"当作一句免责声明。具体做法：定义哪些字段是"AI直出"（低风险），哪些是"AI提取+人工确认"（高风险），哪些是"必须人工录入"（零容忍）。金融场景中，涉及金额、日期、合规条款的信息，永远不要100%信任模型。

代码实操：LLM参数实验室

理论讲完了，动手环节。下面的静态展示可以帮你直观感受不同模型在相同任务下的Token消耗和费用差异。假设场景：处理一份50页的中文研报（约6万Token输入），生成结构化摘要，Temperature = 0.7，Max Tokens = 1024。

LLM 参数实验室

调整参数，观察不同模型在相同任务下的Token消耗和费用差异。假设场景：处理一份50页的中文研报（约6万Token输入），生成结构化摘要。

TEMPERATURE

0.7

MAX TOKENS

1,024

输入 TOKEN

60,000

约50页中文研报

预估输出 TOKEN

717

摘要长度适中

GPT-4O 费用

$0.16

基于当前模型定价

同一任务，不同模型费用对比

GPT-4o
$0.16Claude 3.5
$0.19DeepSeek V3
$0.02

这个工具的核心逻辑并不复杂。每种模型有固定的输入/输出单价，费用 = 输入Token x 输入单价 + 输出Token x 输出单价。Temperature不影响价格，但会影响输出的多样性和质量。Max Tokens设定了输出的上限——实际输出可能更短。

下面是调用API的核心代码。如果你用TraeWork跑这段代码，改改Temperature和Max Tokens参数，就能看到输出变化：

# 调用 OpenAI API 的核心代码（Python）from openai import OpenAI  client = OpenAI(api_key="your-api-key")  response = client.chat.completions.create(     model="gpt-4o",     messages=[         {"role": "system",          "content": "你是金融研报分析助手。"},         {"role": "user",          "content": report_text}  # 约6万Token的研报     ],     temperature=0.7,     # 试试改成 0 或 1.5     max_tokens=1024,     # 试试改成 256 或 4096 )  # 查看实际消耗的Token usage = response.usage print(f"输入: {usage.prompt_tokens} Token") print(f"输出: {usage.completion_tokens} Token") print(f"费用: ${"usage.prompt_tokens * 2.5 / 1_000_000 + usage.completion_tokens * 10 / 1_000_000:.4f}")

这段代码不到20行，但它包含了调用大模型API的全部核心要素：模型选择、消息结构（system + user）、参数控制（temperature、max_tokens）、以及Token用量的追踪。作为PM，你不需要自己写这段代码，但你需要理解每个参数的含义——因为它们直接影响产品质量和运营成本。

不同参数下的输出对比

以同一段研报摘要任务为例，Temperature设为0和1.5时的输出差异：

维度Temperature = 0Temperature = 1.5
核心观点（相同——都准确提取了研报的核心结论）
措辞风格简洁、结构化、接近原文修辞丰富、有主观判断
数据引用精确引用原文数值可能出现"约""近"等模糊表述
额外内容严格基于原文可能添加原文没有的"分析"
可复现性多次调用结果一致每次调用结果不同

对于金融研报摘要，Temperature = 0是更合适的选择——你需要的是精确提取，不是创意发挥。但如果是写投资者教育文章或者基金营销文案，Temperature = 0.7-0.9反而能产出更有吸引力的内容。

小结：PM需要记住的五条判断准则

这篇文章拆解了大模型的五个核心概念。作为产品经理，你不需要记住技术细节，但需要把以下五条准则内化为直觉：

1

Token = 钱

每个产品决策都直接影响Token消耗。中文比英文贵30-50%，长Prompt比短Prompt贵数倍。做成本测算时按Token算，不要按字数算。

2

注意力有偏好

模型对文档开头和末尾的信息记忆更好，中间部分容易被"遗忘"。设计Prompt时把关键指令放在首尾，不要埋在中间。

3

上下文窗口要打五折

标称128K的窗口，有效利用约64-83K。产品架构设计时按标称值的50-65%规划，超出部分用RAG兜底。

4

Temperature是业务决策

精确任务（数据提取、合规检查）用0-0.2，创意任务（文案、头脑风暴）用0.7-0.9。在PRD中明确默认值。

5

幻觉是设计问题，不是技术问题

幻觉无法消除，但可以通过产品设计管控：结构化输出、交叉验证、置信度阈值、人工兜底。在PRD中分级处理。

这五条准则会在后续文章中反复出现。理解RAG时你会用到第2和第3条，做评估体系时你会用到第5条，制定产品策略时每一条都相关。它们是底盘知识，不是看完就忘的概念科普。

上一篇：AI正在重新定义产品经理

下一篇：从Prompt到RAG：大模型的三种"用法

金融PM的AI日记 · AI实验室专题 · 2026年10月

原始来源： 产品经理AI转型日记

评论 (0)