我经常在开发者社区看到一类问题“现在是不是有个聊天机器人就能解决所有问题了”或者“语言模型是不是就是那种对话工具”每次看到这种问题我都挺替它们可惜的。把语言模型等同于聊天机器人就像把计算器当成打字机——都接收输入、给出输出但本质上是完全不同的东西。这篇文章我打算从底层开始拆解把语言模型到底是什么、内部怎么运作、能做什么不能做什么一次性讲清楚。它适合所有想真正理解这轮AI浪潮的开发者、产品经理和技术爱好者。这是系列第一篇重点放在“模型本身如何工作”后续再聊怎么把它接进真实业务、怎么做评测、怎么控制成本。1. 语言模型的底层逻辑一场概率接龙游戏1.1 从“预测下一个词”说起语言模型最朴素的定义就是“根据上文预测下一个词”的系统。给它一段文字它会为词表里的每个候选词打一个概率分挑一个输出然后把这个输出接在上文后面继续预测下一个。你在聊天窗口里看到的连贯回答其实是这个“接龙”循环跑了几十上百次的结果。我拿“今天天气真好我们一起去”做个实验。模型可能会给“公园”打 0.3 的概率给“爬山”打 0.2给“吃饭”打 0.15给“打游戏”打 0.1。它并不“理解”你是想散步还是想约会它只知道在这些词里“公园”在这段语境下出现的次数最多。听起来很傻对不对但把这一步重复一万遍把预测范围从“一个词”扩展到“一段话”甚至扩展到“一次完整的代码提交”傻乎乎的概率统计就变成了看起来有理解力的文本生成。这里的关键在于接龙玩得多了模型必须把语法、事实、逻辑关系全部编码进参数才能把概率猜准。于是“为了猜对下一个词”这个朴素目标逼迫它学到了大量关于语言和世界的知识。这个目标一直没变过从最早的统计语言模型到现在的神经网络模型本质上都是在做同一件事——只是一遍做得比一遍好。1.2 Token模型眼中的“字”和人类不一样模型看到的文本不是按“字”或者“词”切的而是按 token 切。token 是什么你可以理解成模型自定义的“字母表”上的基本单元。常用的切分算法是 BPE字节对编码它先把语料里最常见的字节组合合并成一个个子词再根据需要继续合并。于是 “language” 可能被切成 [“language”] 一个 token也可能被切成 [“lan”, “guage”] 两个 token取决于这个词在语料里出现的频率。频率越高通常越有机会成为一个独立 token。这个细节在实战中非常影响成本和效果。API 的计费是按 token 计的上下文窗口的容量也是按 token 算的。中文环境下一个汉字通常对应 1 到 2 个 token所以同样一段中文占用的 token 数大约是英文单词数的 1.5 到 2 倍。你在规划上下文预算的时候千万别拿“字符数”当“token 数”去估否则很容易超窗。我见过不少项目在第一次上线时栽在这上面预估能塞进一万个问答对的文档结果一换算成 token连一半都放不进去。所以无论是做长文本问答还是做批量处理第一步都是先统计语料的真实 token 数再倒推预算和成本而不是凭感觉拍脑袋。1.3 温度与采样“创造力”其实是个随机参数接龙里说的“挑一个输出”听起来简单但“怎么挑”是决定模型风格的关键。如果永远挑概率最高的那个词模型会输出最稳妥、最平淡的文本这叫贪心解码如果每次都从概率分布里随机抽模型就会有点“发挥”这叫采样。temperature 就是控制这个随机程度的旋钮温度越低分布越尖锐输出越稳定温度越高分布越平坦低概率词也有机会被选中输出更多样。我做信息提取任务时通常把 temperature 调到 0.1 甚至 0因为我要的是可复现的结构化结果写营销文案时调到 0.8 以上试试因为稳定的输出反而显得干巴巴。下面这张表是我平时选择温度的经验值不同场景差异很大但一般不会在这几条之外。场景推荐温度原因结构化抽取、代码生成0 到 0.2要求格式稳定、逻辑一致不容许随机发挥分类、问答、翻译0.3 到 0.5在稳定和自然之间取平衡文案、创意写作、头脑风暴0.7 到 1.0需要多样性和惊喜能接受偶尔跑偏角色扮演、风格模仿0.8 以上追求语气丰富度允许更自由的表达除了 temperature还有 top-p 和 top-k 这类采样参数也在控制“从哪些词里抽”。top-k 是只从概率最高的前 K 个词里抽top-p 是只从累计概率达到 P 的最小子集里抽。理解它们不需要读论文记住一个直觉就够了temperature 管的是“随机程度”top-p 和 top-k 管的是“候选范围”。这两者配合使用比单独调 temperature 更能精准控制模型的行为。2. 为什么神经网络能“读懂”上下文词向量与注意力机制2.1 词向量把词语放进数学空间要让神经网络处理语言第一步是把文字变成数字。早期做法是 one-hot 编码一个词对应一个超长的 0/1 向量。这种表示最大的问题是词与词之间没有任何距离概念“猫”和“狗”的距离跟“猫”和“汽车”的距离一样远模型什么相似性都学不到。后来有了词向量embedding把一个词映射到一个低维稠密向量训练之后语义相近的词在向量空间里靠得很近。有一类经典实验是词类比把“国王”的向量减去“男人”加上“女人”结果往往落在“女王”附近。这说明模型真的把“语义关系”编码进了向量方向——不只是词义连“性别转换”这种抽象关系都能用向量的加减表示出来。但静态词向量有个硬伤同一个词在不同语境下意思完全不同。“我 24 小时没合眼”和“相机镜头没合上”这两句话里的“合”静态词向量无法区分。于是出现了上下文相关的表示——同一个词在不同句子里经过编码后得到不同的向量。这就是为什么后来的模型都叫“上下文表示”模型它给每个词的向量是结合了整句话信息之后的结果。这一小步是语言模型从“查字典”走向“阅读理解”的转折点。2.2 注意力机制一次全员参与的讨论会Transformer 的核心是注意力机制它解决的是“每个词应该怎么从上下文里收集信息”的问题。我常用一个图书馆类比来解释假设有一句话“小王把球踢进大门裁判判定进球有效”。模型处理“门”这个词的时候要决定把自己和哪些词关联起来。注意力机制里有三个角色Query你要查的问题、Key每本书的标签、Value书的内容。当前词负责生成一个 Query其他词生成各自的 Key 和 Value然后 Query 跟所有 Key 做相似度打分分数越高对应词的 Value 就对当前词的表示影响越大。所以当模型处理“门”时它会给自己的 Query 匹配到“球”因为球是踢进去的物体、“裁判”因为裁判在判断这个门算不算数、“进球”语义直接相关这些 Key然后把它们的信息加权汇总。一次打分就是一次讨论会每个词都在观察其他所有词再更新自己的立场。Transformer 里这样的讨论会会开很多层、很多次每一次都会让表示更精准。为什么需要多头注意力因为一句话里不同的关系是多样的“球”和“踢”是动作关系“进球”和“有效”是判定关系“裁判”和“门”是事件的参与者关系。单个打分只能捕捉一种角度的相似性多头注意力让模型可以同时从多个子空间去捕捉不同关系最后再拼接起来。你可以把它理解成开讨论会时有人专门关注动作关系有人专门关注因果逻辑有人专门关注指代对象最后把所有人的笔记汇总成一份完整纪要。2.3 深度与参数层数越多抽象越深Transformer 的深度体现在“层”上每一层都会把上一层的表示再抽象一次。浅层可能还在琢磨词性、部分句法中层开始捕捉递进关系、指代关系深层往往体现出更抽象的语义推理。这也是为什么小模型在很多细节上表现还行、但在长链条推理上很快露馅——层数不够抽象深度不够。模型参数量里面Embedding 层和每一层的权重矩阵占了绝大多数。7B、13B、70B 里的 “B” 指的是参数量billion而参数量的实际意义是模型可以“记住”多少种模式的容量。一个可以接受的类比是参数像大脑的神经元连接数量越多能同时调用的“经验模式”就越多处理复杂句式的余地也就越大。但参数多不代表一定好用数据质量、训练充分度同样关键。这也是为什么同样规模的模型不同团队训练出来的水平可能差出一大截。3. 训练一台语言模型数据、算力和三阶段3.1 预训练拿整个互联网当预习题集预训练阶段的思路特别朴素拿几万亿 token 的文本让模型做同一件事——预测下一个词。数据来源五花八门公开网页、书籍、论文、代码仓库、论坛帖子都在其中但“拿原始语料直接喂”是不行的。原始语料里大量重复、噪声、广告、乱码直接训练会导致模型重复性变差、学到的知识分布很歪。数据清洗是预训练里最被低估的环节去重通常要在文档级和段落级分别做、语言筛选、质量过滤、隐私信息筛查每一步都在影响最终模型的上限。业内有个说法模型好坏七成取决于数据三成取决于工程这话在预训练阶段尤其成立。训练过程中模型不需要人工标注因为“下一个词”本身就是标签——这叫做自监督学习。整个过程就像学生拿着一本无穷无尽的填空题练习册做着做着为了把题答对不得不把语法规则、事实常识、推理模式全背下来而这些“背下来的东西”最终都沉淀在参数里。3.2 指令微调把“接龙选手”变成“回答问题的人”预训练出来的模型只会“续写”。你给它“法国的首都是”它能接上“巴黎”但你直接问它“法国的首都是哪”它可能不按你的格式回答而是继续写“法国是欧洲一个历史悠久的国家……”因为它的训练目标从来不是“回答问题”而是“接续文本”。指令微调SFT就是把模型从“接龙选手”改造成“回答问题的人”准备大量“指令 期望回答”这样的配对数据让模型在监督下学会“用户问到这个格式时应该用这种格式回应”。这一步不需要几万亿 token几万到几十万条高质量指令就够了但数据质量要求极高——错误的、前后矛盾的、有毒的样本都会被模型不加分辨地学走。我见过有人为了凑数量用模型自动生成一万条指令数据直接丢进去微调结果模型学会了“一本正经地绕弯子”因为训练数据里模板化的废话太多。指令微调阶段数据质量永远比数量重要。3.3 人类偏好对齐RLHF 与它的简化替代指令微调之后模型已经能回答了但“能回答”和“回答得好”之间还有巨大距离。于是有了人类偏好对齐。思路是先让人对同一问题的多个回答排序训练一个奖励模型来预测“哪个回答更受人类喜爱”然后让语言模型在这个奖励模型的指导下进一步优化自己的输出。经典做法是 RLHF基于人类反馈的强化学习用强化学习的框架去最大化奖励。这套流程有效但工程复杂度高于是又出现了更轻量的 DPO直接偏好优化等方案不绕道奖励模型直接在偏好数据上优化。不管哪种方法目的都是为了给模型灌输“潜规则”面对不知道的问题要诚实、不要帮用户做危险的事、语气要友好、不要啰嗦。这一步非常烧钱因为它需要大量人类标注员的劳动而且标注一致性本身也难保证。但它是模型从“什么都能接”到“什么该说、什么不该说”的关键一跳。你日常感受到的“这个模型很有分寸”多半就是对齐阶段的工作成果。3.4 算力与成本为什么训练是“烧钱”的事训练一个中等规模的模型比如 70 亿参数通常需要几千张主流训练卡跑几十天电费、硬件折旧、人工成本堆起来是一笔非常可观的数字动辄几百万甚至更高。这还没算数据清洗、实验调试、坏一次 checkpoint 重来的时间成本。所以业界大多数人并不需要自己训练模型。拿一个开源基座做微调、或者直接调用商用 API是绝大多数项目更理性的选择。预训练是“核电站在发电”你只是要给手机充电没必要自己建电站。这件事放到产品决策里就是先想清楚你的核心壁垒到底在数据、在场景、还是在模型本身。如果只是需要一个“能用的文本生成器”那么从零训练大概率是亏的。4. “涌现能力”为什么模型变大后会突然“开窍”4.1 规模法则损失随规模下降的确定性有一个反直觉的事实模型的性能随规模增长的规律比大多数人想象的要确定。研究者系统性地实验了不同参数规模、不同数据量组合后发现最终损失和参数规模、数据量、计算量之间存在近似幂律关系——也就是说在合理范围内你知道把模型扩大几倍、数据增加几倍大概能换来多少性能提升。这种可预测性是预训练工程敢大规模砸钱的前提。没人会花几百万训练一个不知道会不会变好的模型。这个规律也直接影响了参数分配策略不是只无脑加参数而是让参数和数据量按比例同步增长才能把算力用在刀刃上。对普通开发者来说知道这一点就够了——它解释了为什么市面上开源模型的参数规模总在“游戏规则”允许的范围内互相追赶大家的增长路径其实都受同样的数学规律约束。4.2 涌现现象小模型不会、大模型会的事但有时候性能提升又不是平滑的。有些能力在小模型上完全不存在一旦模型规模超过某个阈值突然就出现了。比如多步算术、类比推理、少数样本学习这些能力在小模型上得分可能趋近于零迈过某个规模后却急剧上升像一个相变。研究者把这种突然出现的能力叫“涌现能力”。为什么会有这种非连续性目前还没有完全统一的解释。主流观点认为复杂任务通常可以被拆解成多个子能力每个子能力随规模平滑提升但当所有子能力都弱时整体表现趋近于零一旦每个子能力都过了及格线它们一配合整体能力就起飞了。打个比方一个乐队里每个乐手单独看都只会几个音符合奏起来也乱七八糟但等每个人的技巧都过了一个临界点同一首曲子突然就能演奏得像模像样了。涌现的本质是“子能力配合”的临界点。4.3 上下文学习与思维链涌现的两个典型表现涌现能力最典型的代表是上下文学习。你不需要调整模型任何参数只需要在提示词里给几个例子它就能照葫芦画瓢完成新任务。比如你给它两个“电影评论 → 情感标签”的例子再给它第三条评论它就知道要输出“正面”或“负面”。小模型也能勉强做一点但大模型的稳定性、泛化性完全是另一档。另一个代表是思维链当你要求模型“一步一步想”时它在中间推理步骤上花费的 token 越多最终答案越准。这本质上是把“接龙”玩得更深——中间步骤给了模型更多机会把隐藏知识调用出来而不是一口气跳到答案。我在项目里实测让模型先列推理步骤再给结论比直接逼它给答案的错误率能降一半以上。当然涌现不等于万灵。不是所有能力都会在大模型上凭空出现有些能力无论多大都不会来有些则是“时灵时不灵”。设计产品时不要假设一个能力“模型大了自然会有”每个关键能力都应该在目标规模的模型上实测过再立项。5. 聊天之外语言模型在真实项目里的几种用法5.1 信息提取把乱糟糟的文本变成结构化数据我接过不少“从非结构化文本中抽信息”的需求。传统做法是写正则、写词典、写规则遇到格式稍微变化就崩。语言模型的做法是把抽取需求定义成输出格式比如 JSON把未处理文本丢给它让它严格按格式输出。我常用的提示词结构是角色定义 抽取字段说明 输出 JSON 的示例 目标文本。模型被训练过要遵守格式所以只要提示词写得清楚它可以稳定把客户订单邮件、文档里的实体关系、客服对话里的问题类别抽取成结构化数据。下面是我实际用过的一个简化模板你是一个信息抽取引擎。从下面的邮件中提取订单信息只输出 JSON。 字段 - order_id: 字符串 - customer_name: 字符串 - amount: 浮点数单位美元 - due_date: 日期格式 YYYY-MM-DD 输出示例 {order_id: SO-1024, customer_name: 张三, amount: 599.0, due_date: 2024-05-30} 邮件 您好订单 SO-1024客户张三已确认金额 599 美元 请于 2024 年 5 月 30 日前完成付款。实测中只要格式说明清楚、给一个示例模型的准确率就相当可观。比正则方案省掉大量规则维护比训练一个小模型省掉大量标注成本。这是我把语言模型接入业务时最先推荐尝试的场景。5.2 分类与路由用模型做智能分发分类任务里语言模型最值钱的一点是“零样本/少样本”能力。传统文本分类需要先标注几千条数据、训练一个小模型效果还受限于领域词表。用语言模型做分类你只需要在提示词里写清楚几个类别定义再给两三个例子就能达到一个可用的基线。这是产品原型期特别好的选择先用模型验证“这个分类边界到底成不成立”等确认了再考虑是不是要上一个小模型降本。更重要的是模型分类的“判断理由”是可以输出的——让它先给一句理由再给标签调试时你能看到它为什么分错比黑盒子式的小模型好排查得多。我做过一个工单路由系统初期全部交给大模型分流确认了 30 多个类别的边界之后才逐步把高频类别切到规则和轻量模型上成本直接降了一个数量级。5.3 检索增强给模型配上“外挂知识库”语言模型的知识截止于训练数据它也不会因为时间推移自动更新。如果你要做企业知识库问答、需要回答实时数据、或者对事实准确性敏感就不能只靠模型本身。检索增强生成RAG是目前最主流的答案先把文档切块、做向量化存进向量数据库用户提问时用问题向量做相似度检索取回最相关的几个文本块再把文本块和问题一起交给模型让它“拿着资料回答问题”。模型不再凭空发挥而是在给定资料范围内总结幻觉率大大降低。这也是“超越聊天机器人”最典型的落地方式之一——聊天机器人是封闭的而接上检索的模型是开放的。RAG 的工程细节很多切块大小怎么定、向量模型怎么选、取回多少块合适、怎么让模型只引用资料而不是编造。这些在系列后续我会单独展开讲。这里先记住一个原则RAG 不是为了“让回答更酷”而是为了“让回答有依据”。凡是业务上有“答错要负责”的场景都应该优先考虑它。5.4 代码与数据处理模型当生产力工具用代码生成是另一个被低估的场景。我很早就把模型用在“写一次性脚本”上给我一段 CSV我要按某个字段分组统计以前要么用 Excel、要么手动写 Python现在直接让模型生成脚本跑一遍验证输出改两个边界条件几分钟搞定。数据处理同理格式转换、字段清洗、正则生成模型的产出虽然偶尔要修但比从零写快得多。更进一步有人用模型批量生成合成数据来训练小模型、补充测试集或者做数据增强这也是个非常实用的路子。比如把已有的客服对话换个说法扩充数据集让小模型也能学到更丰富的表达。这类用途最容易被忽视的价值是语言模型是一个“全天候的初级工程师”它不擅长一次写对最复杂的系统但特别擅长把重复性较高的编码和数据处理任务干完第一版剩下的修正成本远低于从零开始。6. 幻觉、边界与风险给模型做一次“体检”6.1 幻觉模型为什么敢一本正经地胡说幻觉是指模型生成的内容听起来无比流畅、结构严谨但事实是编的。为什么会有幻觉根本原因在于语言模型的训练目标是“正确接续文本”不是“检索事实”。它学到的知识以参数分布的形式存在不是数据库里的一条条记录。回答时它做的是“基于概率的即时发挥”而不是“查询再输出”。加上采样带来的随机性同一个问题输两次可能得到两个答案其中一个是编的。实测经验遇到专业领域的精确要求比如药物剂量、法律条文引用、财报数据把模型当“文字整理工具”而不是“事实来源”。用 RAG 把事实框住、用提示词要求模型标注出处、最后让人工复核关键数字。不要试图用“提示词魔法”消除幻觉提示词只能缓解不能根治。任何宣称“我们彻底解决了幻觉”的方案都需要留个心眼。6.2 上下文窗口看得长不等于记得牢现在模型的上下文窗口越来越长几万 token 甚至几十万 token 都有。但“看得长”不等于“用得好”。研究里有个现象叫“lost in the middle”信息放在输入的正中间时模型最容易漏掉开头和结尾注意力更高。另外窗口越长计算压力越大响应变慢、成本升高是必然的。所以做长文档问答时健壮的策略仍然是切块 检索 汇总而不是把整本书一股脑塞进窗口。把上下文窗口当“应急能力”用别当“常规策略”用。我见过有人把全套产品文档塞进一次请求里回答倒是没超窗但每次请求的延迟和费用都让人肉疼而且模型对中段的细节问题回答得并不好。正确的做法是先检索再生成把窗口留给“最相关的那几百个 token”。6.3 评测怎么知道一个模型到底行不行很多团队评测模型的方式是“感觉一下”。这非常危险因为模型对提示词措辞极其敏感同一个任务换个问法效果可能从“还不错”变成“完全崩”。负责任的评测至少要建一个领域测试集至少几十条真实场景样本固定好提示词和评分标准每次换模型、换版本都跑一遍。如果你在选型别只看基准测试排行榜那些题目往往被模型见过甚至被刻意优化过用你自己业务的样本做盲测才是真正的裁判。我习惯从几个维度同时看每条都打分评测维度关注什么常见的坑正确性关键事实和数字是否准确只看流畅度忽略内容错误指令遵循是否真的按给定格式和限制输出模型“差不多”的样子骗过人工检查稳定性同一问题多次回答是否一致只看一次结果忽略随机性上下文利用给到资料时是否引用、没给到时会否乱编用不相关的示例数据测试效率延迟和 token 成本只评估效果不算成本账这套思路不复杂但它能拦住绝大多数“我觉得还行但一上线就翻车”的悲剧。6.4 上线之前安全、隐私与合规的现实问题把业务数据发给外部 API 之前必须先问这些数据能否离开公司是否包含个人信息服务协议里怎么规定数据留存很多团队栽在“图方便”上。敏感场景的正确姿势是私有化部署开源模型或者走不落盘的私有化网关方案原则都一样能不出域的数据就不出域。另外模型生成的输出要过内容安全过滤器尤其是面向外部用户的产品。这方面没有捷径别因为觉得“模型已经对齐过了”就省略上线前的审查流程。最后提醒一句模型不是确定性的软件哪怕评测全过也要在线上留日志、做抽检、有降级开关。把语言模型当成一个有能力的“实习生”来管理——给它明确边界、定期检查产出、随时能收走权限——这才是工程上稳妥的态度。写到这里模型本身的那点事基本讲完了。我自己的体会是语言模型的原理并不玄乎它是一台建立在概率接龙之上的、规模巨大的模式匹配引擎真正玄乎的是规模带来的质变以及那些意想不到的边界。下一篇我会把重心转回工程侧聊聊把语言模型接进真实业务时怎么设计提示词、怎么搭评测集、怎么控制成本——到时候见。 
长河君 · 2026/10/20 17:04:58 · 阅读 1.2k 语言模型不是聊天机器人：从概率接龙到工程落地
我经常在开发者社区看到一类问题“现在是不是有个聊天机器人就能解决所有问题了”或者“语言模型是不是就是那种对话工具”每次看到这种问题我都挺替它们可惜的。把语言模型等同于聊天机器人就像把计算器当成打字机——都接收输入、给出输出但本质上是完全不同的东西。这篇文章我打算从底层开始拆解把语言模型到底是什么、内部怎么运作、能做什么不能做什么一次性讲清楚。它适合所有想真正理解这轮AI浪潮的开发者、产品经理和技术爱好者。这是系列第一篇重点放在“模型本身如何工作”后续再聊怎么把它接进真实业务、怎么做评测、怎么控制成本。1. 语言模型的底层逻辑一场概率接龙游戏1.1 从“预测下一个词”说起语言模型最朴素的定义就是“根据上文预测下一个词”的系统。给它一段文字它会为词表里的每个候选词打一个概率分挑一个输出然后把这个输出接在上文后面继续预测下一个。你在聊天窗口里看到的连贯回答其实是这个“接龙”循环跑了几十上百次的结果。我拿“今天天气真好我们一起去”做个实验。模型可能会给“公园”打 0.3 的概率给“爬山”打 0.2给“吃饭”打 0.15给“打游戏”打 0.1。它并不“理解”你是想散步还是想约会它只知道在这些词里“公园”在这段语境下出现的次数最多。听起来很傻对不对但把这一步重复一万遍把预测范围从“一个词”扩展到“一段话”甚至扩展到“一次完整的代码提交”傻乎乎的概率统计就变成了看起来有理解力的文本生成。这里的关键在于接龙玩得多了模型必须把语法、事实、逻辑关系全部编码进参数才能把概率猜准。于是“为了猜对下一个词”这个朴素目标逼迫它学到了大量关于语言和世界的知识。这个目标一直没变过从最早的统计语言模型到现在的神经网络模型本质上都是在做同一件事——只是一遍做得比一遍好。1.2 Token模型眼中的“字”和人类不一样模型看到的文本不是按“字”或者“词”切的而是按 token 切。token 是什么你可以理解成模型自定义的“字母表”上的基本单元。常用的切分算法是 BPE字节对编码它先把语料里最常见的字节组合合并成一个个子词再根据需要继续合并。于是 “language” 可能被切成 [“language”] 一个 token也可能被切成 [“lan”, “guage”] 两个 token取决于这个词在语料里出现的频率。频率越高通常越有机会成为一个独立 token。这个细节在实战中非常影响成本和效果。API 的计费是按 token 计的上下文窗口的容量也是按 token 算的。中文环境下一个汉字通常对应 1 到 2 个 token所以同样一段中文占用的 token 数大约是英文单词数的 1.5 到 2 倍。你在规划上下文预算的时候千万别拿“字符数”当“token 数”去估否则很容易超窗。我见过不少项目在第一次上线时栽在这上面预估能塞进一万个问答对的文档结果一换算成 token连一半都放不进去。所以无论是做长文本问答还是做批量处理第一步都是先统计语料的真实 token 数再倒推预算和成本而不是凭感觉拍脑袋。1.3 温度与采样“创造力”其实是个随机参数接龙里说的“挑一个输出”听起来简单但“怎么挑”是决定模型风格的关键。如果永远挑概率最高的那个词模型会输出最稳妥、最平淡的文本这叫贪心解码如果每次都从概率分布里随机抽模型就会有点“发挥”这叫采样。temperature 就是控制这个随机程度的旋钮温度越低分布越尖锐输出越稳定温度越高分布越平坦低概率词也有机会被选中输出更多样。我做信息提取任务时通常把 temperature 调到 0.1 甚至 0因为我要的是可复现的结构化结果写营销文案时调到 0.8 以上试试因为稳定的输出反而显得干巴巴。下面这张表是我平时选择温度的经验值不同场景差异很大但一般不会在这几条之外。场景推荐温度原因结构化抽取、代码生成0 到 0.2要求格式稳定、逻辑一致不容许随机发挥分类、问答、翻译0.3 到 0.5在稳定和自然之间取平衡文案、创意写作、头脑风暴0.7 到 1.0需要多样性和惊喜能接受偶尔跑偏角色扮演、风格模仿0.8 以上追求语气丰富度允许更自由的表达除了 temperature还有 top-p 和 top-k 这类采样参数也在控制“从哪些词里抽”。top-k 是只从概率最高的前 K 个词里抽top-p 是只从累计概率达到 P 的最小子集里抽。理解它们不需要读论文记住一个直觉就够了temperature 管的是“随机程度”top-p 和 top-k 管的是“候选范围”。这两者配合使用比单独调 temperature 更能精准控制模型的行为。2. 为什么神经网络能“读懂”上下文词向量与注意力机制2.1 词向量把词语放进数学空间要让神经网络处理语言第一步是把文字变成数字。早期做法是 one-hot 编码一个词对应一个超长的 0/1 向量。这种表示最大的问题是词与词之间没有任何距离概念“猫”和“狗”的距离跟“猫”和“汽车”的距离一样远模型什么相似性都学不到。后来有了词向量embedding把一个词映射到一个低维稠密向量训练之后语义相近的词在向量空间里靠得很近。有一类经典实验是词类比把“国王”的向量减去“男人”加上“女人”结果往往落在“女王”附近。这说明模型真的把“语义关系”编码进了向量方向——不只是词义连“性别转换”这种抽象关系都能用向量的加减表示出来。但静态词向量有个硬伤同一个词在不同语境下意思完全不同。“我 24 小时没合眼”和“相机镜头没合上”这两句话里的“合”静态词向量无法区分。于是出现了上下文相关的表示——同一个词在不同句子里经过编码后得到不同的向量。这就是为什么后来的模型都叫“上下文表示”模型它给每个词的向量是结合了整句话信息之后的结果。这一小步是语言模型从“查字典”走向“阅读理解”的转折点。2.2 注意力机制一次全员参与的讨论会Transformer 的核心是注意力机制它解决的是“每个词应该怎么从上下文里收集信息”的问题。我常用一个图书馆类比来解释假设有一句话“小王把球踢进大门裁判判定进球有效”。模型处理“门”这个词的时候要决定把自己和哪些词关联起来。注意力机制里有三个角色Query你要查的问题、Key每本书的标签、Value书的内容。当前词负责生成一个 Query其他词生成各自的 Key 和 Value然后 Query 跟所有 Key 做相似度打分分数越高对应词的 Value 就对当前词的表示影响越大。所以当模型处理“门”时它会给自己的 Query 匹配到“球”因为球是踢进去的物体、“裁判”因为裁判在判断这个门算不算数、“进球”语义直接相关这些 Key然后把它们的信息加权汇总。一次打分就是一次讨论会每个词都在观察其他所有词再更新自己的立场。Transformer 里这样的讨论会会开很多层、很多次每一次都会让表示更精准。为什么需要多头注意力因为一句话里不同的关系是多样的“球”和“踢”是动作关系“进球”和“有效”是判定关系“裁判”和“门”是事件的参与者关系。单个打分只能捕捉一种角度的相似性多头注意力让模型可以同时从多个子空间去捕捉不同关系最后再拼接起来。你可以把它理解成开讨论会时有人专门关注动作关系有人专门关注因果逻辑有人专门关注指代对象最后把所有人的笔记汇总成一份完整纪要。2.3 深度与参数层数越多抽象越深Transformer 的深度体现在“层”上每一层都会把上一层的表示再抽象一次。浅层可能还在琢磨词性、部分句法中层开始捕捉递进关系、指代关系深层往往体现出更抽象的语义推理。这也是为什么小模型在很多细节上表现还行、但在长链条推理上很快露馅——层数不够抽象深度不够。模型参数量里面Embedding 层和每一层的权重矩阵占了绝大多数。7B、13B、70B 里的 “B” 指的是参数量billion而参数量的实际意义是模型可以“记住”多少种模式的容量。一个可以接受的类比是参数像大脑的神经元连接数量越多能同时调用的“经验模式”就越多处理复杂句式的余地也就越大。但参数多不代表一定好用数据质量、训练充分度同样关键。这也是为什么同样规模的模型不同团队训练出来的水平可能差出一大截。3. 训练一台语言模型数据、算力和三阶段3.1 预训练拿整个互联网当预习题集预训练阶段的思路特别朴素拿几万亿 token 的文本让模型做同一件事——预测下一个词。数据来源五花八门公开网页、书籍、论文、代码仓库、论坛帖子都在其中但“拿原始语料直接喂”是不行的。原始语料里大量重复、噪声、广告、乱码直接训练会导致模型重复性变差、学到的知识分布很歪。数据清洗是预训练里最被低估的环节去重通常要在文档级和段落级分别做、语言筛选、质量过滤、隐私信息筛查每一步都在影响最终模型的上限。业内有个说法模型好坏七成取决于数据三成取决于工程这话在预训练阶段尤其成立。训练过程中模型不需要人工标注因为“下一个词”本身就是标签——这叫做自监督学习。整个过程就像学生拿着一本无穷无尽的填空题练习册做着做着为了把题答对不得不把语法规则、事实常识、推理模式全背下来而这些“背下来的东西”最终都沉淀在参数里。3.2 指令微调把“接龙选手”变成“回答问题的人”预训练出来的模型只会“续写”。你给它“法国的首都是”它能接上“巴黎”但你直接问它“法国的首都是哪”它可能不按你的格式回答而是继续写“法国是欧洲一个历史悠久的国家……”因为它的训练目标从来不是“回答问题”而是“接续文本”。指令微调SFT就是把模型从“接龙选手”改造成“回答问题的人”准备大量“指令 期望回答”这样的配对数据让模型在监督下学会“用户问到这个格式时应该用这种格式回应”。这一步不需要几万亿 token几万到几十万条高质量指令就够了但数据质量要求极高——错误的、前后矛盾的、有毒的样本都会被模型不加分辨地学走。我见过有人为了凑数量用模型自动生成一万条指令数据直接丢进去微调结果模型学会了“一本正经地绕弯子”因为训练数据里模板化的废话太多。指令微调阶段数据质量永远比数量重要。3.3 人类偏好对齐RLHF 与它的简化替代指令微调之后模型已经能回答了但“能回答”和“回答得好”之间还有巨大距离。于是有了人类偏好对齐。思路是先让人对同一问题的多个回答排序训练一个奖励模型来预测“哪个回答更受人类喜爱”然后让语言模型在这个奖励模型的指导下进一步优化自己的输出。经典做法是 RLHF基于人类反馈的强化学习用强化学习的框架去最大化奖励。这套流程有效但工程复杂度高于是又出现了更轻量的 DPO直接偏好优化等方案不绕道奖励模型直接在偏好数据上优化。不管哪种方法目的都是为了给模型灌输“潜规则”面对不知道的问题要诚实、不要帮用户做危险的事、语气要友好、不要啰嗦。这一步非常烧钱因为它需要大量人类标注员的劳动而且标注一致性本身也难保证。但它是模型从“什么都能接”到“什么该说、什么不该说”的关键一跳。你日常感受到的“这个模型很有分寸”多半就是对齐阶段的工作成果。3.4 算力与成本为什么训练是“烧钱”的事训练一个中等规模的模型比如 70 亿参数通常需要几千张主流训练卡跑几十天电费、硬件折旧、人工成本堆起来是一笔非常可观的数字动辄几百万甚至更高。这还没算数据清洗、实验调试、坏一次 checkpoint 重来的时间成本。所以业界大多数人并不需要自己训练模型。拿一个开源基座做微调、或者直接调用商用 API是绝大多数项目更理性的选择。预训练是“核电站在发电”你只是要给手机充电没必要自己建电站。这件事放到产品决策里就是先想清楚你的核心壁垒到底在数据、在场景、还是在模型本身。如果只是需要一个“能用的文本生成器”那么从零训练大概率是亏的。4. “涌现能力”为什么模型变大后会突然“开窍”4.1 规模法则损失随规模下降的确定性有一个反直觉的事实模型的性能随规模增长的规律比大多数人想象的要确定。研究者系统性地实验了不同参数规模、不同数据量组合后发现最终损失和参数规模、数据量、计算量之间存在近似幂律关系——也就是说在合理范围内你知道把模型扩大几倍、数据增加几倍大概能换来多少性能提升。这种可预测性是预训练工程敢大规模砸钱的前提。没人会花几百万训练一个不知道会不会变好的模型。这个规律也直接影响了参数分配策略不是只无脑加参数而是让参数和数据量按比例同步增长才能把算力用在刀刃上。对普通开发者来说知道这一点就够了——它解释了为什么市面上开源模型的参数规模总在“游戏规则”允许的范围内互相追赶大家的增长路径其实都受同样的数学规律约束。4.2 涌现现象小模型不会、大模型会的事但有时候性能提升又不是平滑的。有些能力在小模型上完全不存在一旦模型规模超过某个阈值突然就出现了。比如多步算术、类比推理、少数样本学习这些能力在小模型上得分可能趋近于零迈过某个规模后却急剧上升像一个相变。研究者把这种突然出现的能力叫“涌现能力”。为什么会有这种非连续性目前还没有完全统一的解释。主流观点认为复杂任务通常可以被拆解成多个子能力每个子能力随规模平滑提升但当所有子能力都弱时整体表现趋近于零一旦每个子能力都过了及格线它们一配合整体能力就起飞了。打个比方一个乐队里每个乐手单独看都只会几个音符合奏起来也乱七八糟但等每个人的技巧都过了一个临界点同一首曲子突然就能演奏得像模像样了。涌现的本质是“子能力配合”的临界点。4.3 上下文学习与思维链涌现的两个典型表现涌现能力最典型的代表是上下文学习。你不需要调整模型任何参数只需要在提示词里给几个例子它就能照葫芦画瓢完成新任务。比如你给它两个“电影评论 → 情感标签”的例子再给它第三条评论它就知道要输出“正面”或“负面”。小模型也能勉强做一点但大模型的稳定性、泛化性完全是另一档。另一个代表是思维链当你要求模型“一步一步想”时它在中间推理步骤上花费的 token 越多最终答案越准。这本质上是把“接龙”玩得更深——中间步骤给了模型更多机会把隐藏知识调用出来而不是一口气跳到答案。我在项目里实测让模型先列推理步骤再给结论比直接逼它给答案的错误率能降一半以上。当然涌现不等于万灵。不是所有能力都会在大模型上凭空出现有些能力无论多大都不会来有些则是“时灵时不灵”。设计产品时不要假设一个能力“模型大了自然会有”每个关键能力都应该在目标规模的模型上实测过再立项。5. 聊天之外语言模型在真实项目里的几种用法5.1 信息提取把乱糟糟的文本变成结构化数据我接过不少“从非结构化文本中抽信息”的需求。传统做法是写正则、写词典、写规则遇到格式稍微变化就崩。语言模型的做法是把抽取需求定义成输出格式比如 JSON把未处理文本丢给它让它严格按格式输出。我常用的提示词结构是角色定义 抽取字段说明 输出 JSON 的示例 目标文本。模型被训练过要遵守格式所以只要提示词写得清楚它可以稳定把客户订单邮件、文档里的实体关系、客服对话里的问题类别抽取成结构化数据。下面是我实际用过的一个简化模板你是一个信息抽取引擎。从下面的邮件中提取订单信息只输出 JSON。 字段 - order_id: 字符串 - customer_name: 字符串 - amount: 浮点数单位美元 - due_date: 日期格式 YYYY-MM-DD 输出示例 {order_id: SO-1024, customer_name: 张三, amount: 599.0, due_date: 2024-05-30} 邮件 您好订单 SO-1024客户张三已确认金额 599 美元 请于 2024 年 5 月 30 日前完成付款。实测中只要格式说明清楚、给一个示例模型的准确率就相当可观。比正则方案省掉大量规则维护比训练一个小模型省掉大量标注成本。这是我把语言模型接入业务时最先推荐尝试的场景。5.2 分类与路由用模型做智能分发分类任务里语言模型最值钱的一点是“零样本/少样本”能力。传统文本分类需要先标注几千条数据、训练一个小模型效果还受限于领域词表。用语言模型做分类你只需要在提示词里写清楚几个类别定义再给两三个例子就能达到一个可用的基线。这是产品原型期特别好的选择先用模型验证“这个分类边界到底成不成立”等确认了再考虑是不是要上一个小模型降本。更重要的是模型分类的“判断理由”是可以输出的——让它先给一句理由再给标签调试时你能看到它为什么分错比黑盒子式的小模型好排查得多。我做过一个工单路由系统初期全部交给大模型分流确认了 30 多个类别的边界之后才逐步把高频类别切到规则和轻量模型上成本直接降了一个数量级。5.3 检索增强给模型配上“外挂知识库”语言模型的知识截止于训练数据它也不会因为时间推移自动更新。如果你要做企业知识库问答、需要回答实时数据、或者对事实准确性敏感就不能只靠模型本身。检索增强生成RAG是目前最主流的答案先把文档切块、做向量化存进向量数据库用户提问时用问题向量做相似度检索取回最相关的几个文本块再把文本块和问题一起交给模型让它“拿着资料回答问题”。模型不再凭空发挥而是在给定资料范围内总结幻觉率大大降低。这也是“超越聊天机器人”最典型的落地方式之一——聊天机器人是封闭的而接上检索的模型是开放的。RAG 的工程细节很多切块大小怎么定、向量模型怎么选、取回多少块合适、怎么让模型只引用资料而不是编造。这些在系列后续我会单独展开讲。这里先记住一个原则RAG 不是为了“让回答更酷”而是为了“让回答有依据”。凡是业务上有“答错要负责”的场景都应该优先考虑它。5.4 代码与数据处理模型当生产力工具用代码生成是另一个被低估的场景。我很早就把模型用在“写一次性脚本”上给我一段 CSV我要按某个字段分组统计以前要么用 Excel、要么手动写 Python现在直接让模型生成脚本跑一遍验证输出改两个边界条件几分钟搞定。数据处理同理格式转换、字段清洗、正则生成模型的产出虽然偶尔要修但比从零写快得多。更进一步有人用模型批量生成合成数据来训练小模型、补充测试集或者做数据增强这也是个非常实用的路子。比如把已有的客服对话换个说法扩充数据集让小模型也能学到更丰富的表达。这类用途最容易被忽视的价值是语言模型是一个“全天候的初级工程师”它不擅长一次写对最复杂的系统但特别擅长把重复性较高的编码和数据处理任务干完第一版剩下的修正成本远低于从零开始。6. 幻觉、边界与风险给模型做一次“体检”6.1 幻觉模型为什么敢一本正经地胡说幻觉是指模型生成的内容听起来无比流畅、结构严谨但事实是编的。为什么会有幻觉根本原因在于语言模型的训练目标是“正确接续文本”不是“检索事实”。它学到的知识以参数分布的形式存在不是数据库里的一条条记录。回答时它做的是“基于概率的即时发挥”而不是“查询再输出”。加上采样带来的随机性同一个问题输两次可能得到两个答案其中一个是编的。实测经验遇到专业领域的精确要求比如药物剂量、法律条文引用、财报数据把模型当“文字整理工具”而不是“事实来源”。用 RAG 把事实框住、用提示词要求模型标注出处、最后让人工复核关键数字。不要试图用“提示词魔法”消除幻觉提示词只能缓解不能根治。任何宣称“我们彻底解决了幻觉”的方案都需要留个心眼。6.2 上下文窗口看得长不等于记得牢现在模型的上下文窗口越来越长几万 token 甚至几十万 token 都有。但“看得长”不等于“用得好”。研究里有个现象叫“lost in the middle”信息放在输入的正中间时模型最容易漏掉开头和结尾注意力更高。另外窗口越长计算压力越大响应变慢、成本升高是必然的。所以做长文档问答时健壮的策略仍然是切块 检索 汇总而不是把整本书一股脑塞进窗口。把上下文窗口当“应急能力”用别当“常规策略”用。我见过有人把全套产品文档塞进一次请求里回答倒是没超窗但每次请求的延迟和费用都让人肉疼而且模型对中段的细节问题回答得并不好。正确的做法是先检索再生成把窗口留给“最相关的那几百个 token”。6.3 评测怎么知道一个模型到底行不行很多团队评测模型的方式是“感觉一下”。这非常危险因为模型对提示词措辞极其敏感同一个任务换个问法效果可能从“还不错”变成“完全崩”。负责任的评测至少要建一个领域测试集至少几十条真实场景样本固定好提示词和评分标准每次换模型、换版本都跑一遍。如果你在选型别只看基准测试排行榜那些题目往往被模型见过甚至被刻意优化过用你自己业务的样本做盲测才是真正的裁判。我习惯从几个维度同时看每条都打分评测维度关注什么常见的坑正确性关键事实和数字是否准确只看流畅度忽略内容错误指令遵循是否真的按给定格式和限制输出模型“差不多”的样子骗过人工检查稳定性同一问题多次回答是否一致只看一次结果忽略随机性上下文利用给到资料时是否引用、没给到时会否乱编用不相关的示例数据测试效率延迟和 token 成本只评估效果不算成本账这套思路不复杂但它能拦住绝大多数“我觉得还行但一上线就翻车”的悲剧。6.4 上线之前安全、隐私与合规的现实问题把业务数据发给外部 API 之前必须先问这些数据能否离开公司是否包含个人信息服务协议里怎么规定数据留存很多团队栽在“图方便”上。敏感场景的正确姿势是私有化部署开源模型或者走不落盘的私有化网关方案原则都一样能不出域的数据就不出域。另外模型生成的输出要过内容安全过滤器尤其是面向外部用户的产品。这方面没有捷径别因为觉得“模型已经对齐过了”就省略上线前的审查流程。最后提醒一句模型不是确定性的软件哪怕评测全过也要在线上留日志、做抽检、有降级开关。把语言模型当成一个有能力的“实习生”来管理——给它明确边界、定期检查产出、随时能收走权限——这才是工程上稳妥的态度。写到这里模型本身的那点事基本讲完了。我自己的体会是语言模型的原理并不玄乎它是一台建立在概率接龙之上的、规模巨大的模式匹配引擎真正玄乎的是规模带来的质变以及那些意想不到的边界。下一篇我会把重心转回工程侧聊聊把语言模型接进真实业务时怎么设计提示词、怎么搭评测集、怎么控制成本——到时候见。