Transformer 架构通识（AI产品经理 必须掌握的程度）

进阶的小梁
64 阅读5分钟

⛳Transformer概要

1️⃣ 核心定义：它是图纸，不是房子

  • Transformer = 发动机图纸（底层架构）。
  • 大模型 (LLM) = 造好的赛车（基于架构训练好的模型）。
  • 推理 = 赛车在跑（模型使用过程）。
  • 结论：Transformer 是让大模型“能理解人话”的底层技术架构。

2️⃣ 核心魔法：自注意力机制 (Self-Attention)

它改变了 AI 读文章的方式：

  • 以前 (RNN)：像小学生读课文，逐字阅读。读了后面忘前面，慢且笨。
  • 现在 (Transformer)：像速读大师，一眼看完。能同时看到整句话，并算出哪个词和哪个词有关系。

3️⃣ 三大核心价值

  • 1.并行计算 (快)：不需要排队读，所有字一起算，所以能训练出千亿参数的大模型。
  • 2.长距离依赖 (记性好)：这是审核产品的命门。它能记住 50 页之前的“定义”，解决长合同“读到后面忘前面”的问题。
  • 3.语义深度 (懂逻辑)：能算出“其”指代“甲方”，能分清“意思”是“含义”还是“有趣”。

4️⃣代码逻辑

  • 1.输入：把字变成数字向量 (Embedding)。
  • 2.处理：进入 Transformer 层，计算词与词的关联度权重 (比如算出“违约”和“罚款”强关联)。
  • 3.输出：输出下一个字出现的概率 (比如 80% 概率是“金”，组成“违约金”)。

5️⃣ 一句话总结

  • Transformer 是大模型的底层架构，其核心的自注意力机制，让AI产品能够理解跨段落、跨页面的长文本逻辑关联，这是传统 NLP 技术做不到的

⛳Transformer+Token+上下文窗口 三者的关系

1️⃣ Transformer、Token、上下文窗口——三者是一体的

  • Transformer (架构) = 胃 (消化系统)。
  • Token (词元) = 嚼碎的食物 (胃只能消化碎块，不能消化整只鸡)。
  • Context Window (上下文窗口) = 胃容量 (一次吃太多会撑破)。

2️⃣ Transformer、Token、上下文窗口——三者核心关系

这三者是“机器-原料-容量”的物理绑定关系：

1、Transformer 决定了必须用 Token：

  • 因为 Transformer 内部只做数学运算，不认识字。所以架构设计强制要求把“文本”转化为数字代号，这个代号就是 Token。

2、Transformer 决定了窗口有上限：

  • 因为 Transformer 的核心机制（自注意力）要计算每一个 Token 和其他所有 Token 的关系。
  • Token 数量一翻倍，计算量呈平方级爆炸。显卡装不下，所以必须设定 Context Window 物理上限。

3️⃣ 一句话总结

  • Transformer 是这一套规则的制定者（架构），它规定了输入必须切成 Token（单位），也因为其计算复杂度过高，导致了 Context Window（容量）必须有限制。

⛳LLM原理

1. 逻辑推理能力 (Emergent Abilities)

  • 原理：量变引起质变。参数够大，模型就从“背书”变成了“懂逻辑”。
  • 审核实战：不仅能查关键词，还能查逻辑矛盾。
  • 例子：文章前文说“不可撤销”，后文说“随时终止”。传统模型查不出，LLM 能靠推理发现。

2. prompt指令遵循 (Instruction Following)

  • 原理：经过 RLHF（人类反馈）训练，模型学会了“听指挥prompt”而不是瞎续写。
  • 审核实战：能强制模型按标准格式工作。
    • 例子：在 Prompt 要求“输出 JSON 格式”，模型就能乖乖输出结构化数据，方便后端代码直接用。

3. 参数Temperarure可控 (Temperature Control)

  • 原理：LLM 本质是概率模型，但可以通过参数（Temperature）控制随机性。
  • 审核实战：金融审核要求零随机、高稳定。
    • 例子：必须将 Temperature 设为 0。确保同一份合同，今天审和明天审，结果一模一样。

⛳Token

1. 换算逻辑

  • 原理 ：Token 是 AI 的计费货币， 汉字 ≠ Token 。
  • 经验值 ：中文语境下，通常 1 个汉字 ≈ 1.3 ~ 1.5 个 Token （估算成本时按 1.5 算）。
    • 注意 ：不仅原文算 Token，你写的 Prompt（提示词）也要算 Token，模型的输出结果也要算 Token。

2. 实战算账

  • 场景：企业每天 30 份合同，每份 3 万字。
  • 计算公式：
    1. 单份-文件 Token：30,000 字×1.5=45,000 Token
    2. 每天-日均总量：45,000×30=1,350,000 (135万) Token
    3. 每天-预估成本：
      1. 假设使用智谱 GLM-4-Air（比如 1元/百万Token）：1.35×1=1.35 元/天
      2. 若使用高性能版（如 50元/百万Token），则约 67.5 元/天。

3. 成本陷阱

  • 原理：输入（Input）和输出（Output） 价格通常不一样（输出通常更贵）。
  • 审核实战：
    • 大头在输入：合同原文（Input）虽然长，但价格便宜。
    • 小头在输出：审核报告（Output）虽然短，但价格贵。
    • 策略：AI产品经理 要学会“精简输入”（通过 RAG 只传相关片段），而不是傻傻地把全文传进去烧钱。

⛳上下文窗口

1. 概念解析

  • 解释：上下文窗口是模型的“短期工作内存”。
  • 量级：例如 128k 窗口，意味着模型一次性最多能“阅读”并处理约 10 万个汉字（相当于一本 300 页的中篇小说）。
    • PM 视角：窗口越大，能读的文档越长，但推理速度会变慢，成本会变高。

2. 审核痛点

  • 场景：审核几百页的超长信贷报告或招股说明书。
  • 现象： “首尾关注，中间丢失” (Lost in the Middle) 。
    • 即使模型能吃进 200 页文档，实验证明，模型往往只记得开头（如借款人信息）和结尾（如总结），却很容易忽略中间第 102 页的一条关键违约记录。
  • 后果：在金融审核中，这意味着漏审（漏召回） ，是绝对的红线事故。

3. 解决方案 (The Fix: RAG)

  • 策略：不能把整本书硬塞进去。

  • 实战：必须使用 RAG（检索增强生成） 技术。

    1. 切片：先把长文档切成小段。

    2. 召回：根据审核规则（如“查找违约记录”），只检索出最相关的 5 个片段。

    3. 推理：只把这 5 个片段喂给模型。

    • 优势：既节省了 Token 成本，又避免了模型“注意力涣散”，确保中间的关键信息被抓取。

💡 一句话总结：

“虽然现在的模型支持长窗口，但在金融审核中，为了解决 ‘中间丢失 的幻觉问题，采用 RAG 切片策略，只给模型投喂高相关片段，从而在降低成本的同时，将风险条款的召回率提升到了 95% 以上。”

avatar
文章
阅读
粉丝