“它是不是把整个互联网都存在硬盘里了”这是我一个朋友第一次接触某款对话助手时问我的问题。我说不是。“那它怎么知道我昨天问过什么的”我说它没记住它只是把我们的聊天记录又塞回了输入框而已。那顿饭剩下的时间他一直在追问我“为什么”最后我答应他写点什么把这个问题讲明白。这个系列就是干这件事的。语言模型这个词大家听得多了但大多数人接触它的入口还是“聊天机器人”这个界面。聊天只是表面形态真正值钱的、真正影响你判断的是聊天框背后那套“训练—推理—对齐”的运行逻辑。这一期我先不聊具体怎么搭服务也不推进阶的调参技巧先把一件最基础的事讲透语言模型到底靠什么工作、它的能力从哪来、它又为什么会在某些场合一本正经地胡说八道。适合所有对AI有好奇心的人读不管你是写代码的、做产品的还是单纯在用各种AI工具的用户。1. 语言模型的“本职工作”一次只猜下一个词1.1 把文字切成小积木Token到底是个什么东西很多教程一上来就讲神经网络容易把人吓跑。我们先不谈网络结构只谈输入输出。语言模型说实话不认识“字”它认识的是一个一个的数字编号。中文一句话进来会被切成若干小段每个小段叫做一个Token有人翻译成“词元”。比如“苹果很好吃”可能被切成“苹果”“很好”“吃”三块也可能按词表切得更碎。每个Token对应一个编号模型拿到的是编号序列输出的也是下一个编号的预测概率。这个切分过程叫Token化。它听起来像预处理其实直接影响模型的表现切得太粗生僻词被合并成少数几个Token模型学不到细粒度规律切得太细输入占用长度暴涨成本上升。不同公司、不同时期的模型都有自己的分词器切分习惯不一样所以有些模型写中文要消耗的Token数量会明显不同。你在聊天界面里看到的“字数”和API账单上的Token数从来不是一回事这一点做产品的人要提前有数。1.2 条件概率上下文决定下一个字模型的核心任务用数学语言说就一句话给定一段上文预测下一个Token的概率分布。用大白话说你说“今天天气真”模型要算的是“好”的概率高还是“差”的概率高还是“冷”“热”这些词更高。这就是一个条件概率问题P(下一个词 | 前面所有词)。模型读了天量的文字之后会把这种“什么词通常接在什么词后面”的规律压缩进自己的参数里。你可以粗暴地理解成它学了一本超级大的“词组搭配概率手册”但注意这是一本统计手册不是字典也不是数据库。它不会像搜索引擎那样去“查出”一个答案它只是在每一步都挑选最合适的下一个词。你看到的整段回答其实是它从第一个字开始一个词一个词“猜”出来的。1.3 为什么“猜词”能猜出推理能力到这里你可能会想一个只会猜下一个词的模型凭什么能写代码、做数学题、总结文档这看起来匪夷所思却是语言模型最迷人的地方。人类语言本身就携带了大量的逻辑模式和知识结构。当模型在几千亿字的文本上做过预测练习之后它学到的不只是词语搭配还包括了“如果…那么…”“因为…所以…”“第一步…第二步…”这类思维框架的统计规律。你给它一道数学题它可能没有真正理解算术但它见过几百万道“解题步骤答案”的格式知道这类问题的答案长什么样子、推理链条怎么铺。它生成的每一步都来自概率但整体路径恰好在语义上吻合逻辑。这种现象被称作“涌现能力”在模型规模达到一定水平之前小模型怎么训练都没有这种表现一旦规模跨过某条线总结、翻译、基础推理这些能力突然就出现了。当然“涌现”并不是魔法而是海量数据、算力和参数容量共同堆出来的统计结果。你需要记住的是语言模型的底层机制极其简单——预测下一个Token上层表现极其复杂——能聊天、能编程、能扮演角色。这两个印象都不完整它们只是同一个硬币的两面。2. 能力从哪来一次关于“训练”的完整旅程2.1 预训练在几十亿页文本里找规律语言模型的开端是预训练这一步的本质是拿海量无标注文本喂给模型让它自己玩“猜下一个词”的游戏。所谓无标注意思是文本不需要人工整理成“问题—答案”对互联网上任何一个完整句子、段落、文档都可以拿来当训练素材。模型读过大半个网络的公开内容后词汇、语法、常识和大量事实性知识的统计规律都被吸收进参数里。这一步成本极其高昂需要数千块芯片连续跑上几个月普通人基本不会触碰这个环节。但理解预训练的价值有助于判断一个模型靠不靠谱预训练语料过于偏科模型在某些领域就会表现出明显短板。如果你的应用场景以中文数据为主却选了一个英文语料占绝对优势的模型那它在处理中文隐语、俗语、文化背景时会明显不如国产模型。选型时第一件事不是比参数量而是了解训练语料里你目标语言或行业的占比。2.2 监督微调从“会说话”到“会回答”预训练结束后的模型其实是个“文字接龙选手”你问它“11等于几”它可能接一句“是一个数学问题”而不是给你答案“2”。因为它学到的规律是“顺着上文把话补完”不是“针对用户问题给出解答”。想要变成能用的助手就需要第二步监督微调。这一步做的事情很朴素人工整理大量“用户提问—理想答复”的配对数据让模型学着在这些示例上调整自己。比如用户问“帮我写一封请假邮件”理想答复是“尊敬的XX因X事需请假X天望批准”。模型见过几万条这种样的配对之后才慢慢学会“哦原来人问了问题我要用回答的方式接着往下写而不是继续问问题”。你可以把它理解成一个学徒跟着师傅学话术师傅一遍遍示范“这种问题应该这么回”学徒逐渐模仿得到位。监督微调用的数据集质量直接决定了模型风格的基调。市面上有些模型聊天很亲切、有些很正式大部分差异都是在这个阶段被注入的。实际使用中如果某个模型回答过于啰嗦或过于客气你说“简化回答”“不要客套”通常能暂时压制住这些风格因为提示词本质上也是在改变模型的条件概率。2.3 偏好优化给模型装上一把“标准尺”第三步通常是最少被提及、却最能拉开模型体验差距的环节偏好优化业内术语叫基于人类反馈的强化学习口语常叫RLHF。这一步的逻辑很简单同一个问题让模型生成多个候选回答然后由一批评估员或另一个自动系统来打分排序——哪一个更像人类愿意看到的回答。模型记住这些排序朝着“更受欢迎的方向”持续调整参数。这一步解决的是什么问题光是模仿示例模型的回答可能正确但形式呆板可能说一堆正确废话也可能会礼貌过头。偏好优化给了模型一把“好坏标尺”让它能从几个候选里学会简洁明确的输出优于绕圈子的输出承认不知道优于瞎编引导用户补充信息优于猜测。举一个典型的例子你问模型一个医疗问题优秀的偏好数据会让模型说“建议咨询专业医生以下信息仅供参考”而不是直接开药方。这把“尺子”就是模型安全性和体验感的主要来源。2.4 三个阶段的协作关系像极了“学徒制”把三步放在一起看像极了培养一个资深员工的完整路径。预训练是“通读万卷书”没有任何人告诉它什么有用什么没用全靠自己从无尽文本里吸收知识这个过程给它的是广博。监督微调是“跟师傅学话术”师傅给出大量标准案例让它知道面对各种场景时的规范应答方式这个过程给它的是得体。偏好优化是“主管在背后把关”试错之后明确告诉你哪种风格更受认可这个过程给它的是分寸。三个阶段缺一不可。只在预训练阶段停下来的模型无法直接对话只有前两个阶段、跳过偏好优化模型可能能力不差但答非所问、语气僵硬、拒绝策略混乱。我经常见到一些私人部署的模型表现糟糕最后排查下来根本不是推理配置问题而是模型只做了预训练加简单微调缺少了偏好优化这个“定调”步骤。所以下次对比两个模型时别光看参数和跑分多问问它的微调和偏好数据是怎么做的——那个信息量通常更大。3. 它为什么“一本正经地胡说八道”能力的边界3.1 幻觉的根源不是笨是“生成”而不是“查库”只要用语言模型稍久一点所有人都遇到过幻觉现象模型用非常自信的语气给出了完全错误甚至荒谬的答案。为什么因为我在第一部分就强调过——模型每一步都是在“猜”下一个字。它没有内嵌数据库没有在你提问时去检索事实。它只是在庞大的参数中找到一条“语言上最顺”的生成路径。比如你问“某位历史人物的出生年份”如果这位人物在训练语料里的出场频率很低、相关描述又互相矛盾模型就会“想当然”地把最接近的几个模式拼在一起产出一个听起来很流畅但不准确的年份。由于人类语言本身就偏好肯定句式模型在引导下会越来越自信。对齐环节只能缓解这个问题无法根除它。理解了这一点你会对幻觉有一个很关键的认知它不是你用错了提示词而是生成式模型的固有属性。3.2 知识截止时间和上下文窗口两条硬边界模型还有一个绕不开的铁边界知识截止时间。它的训练语料本身有一个时间范围超出这个范围的事情它完全没学过只能靠猜测或者靠你提供的资料。所以问“某产品最新版本是什么”这类时效性问题时别指望模型凭空给准。正确做法是把最新信息放进上下文里让它读。另一条边界是上下文窗口也就是模型一次能处理的最大Token数量。很多人觉得上下文窗口越大越好实际不是线性的。即使名义上支持超长上下文模型对中段内容的记忆和注意力也远不如开头和结尾来得可靠。这是自注意力机制的天然倾向——开头几句话影响“定调”结尾几个词距离生成位置最近夹在中间的内容最容易丢失。真让模型读一份两百页的报告再谈细节它很可能记住首尾、漏掉中段。长文本场景必须配合分段处理和定向提取别指望它“通读”之后事无巨细。3.3 推理误差也会积累一步错步步错推理错误是另一个容易被忽视的边界。模型在解决多步问题时每一步都是概率采样早期的微小偏差会随着步骤推进被放大。就像一个口算能力一般的人做三位数乘法——第一行算错了后面步骤再整齐结果也是错的。模型没有“回溯纠错”的默认机制它不会因为后面算不下去就重新检查前面的过程而会硬着头皮继续生成一个看起来合理的续写。这也是为什么让模型“自己检查一遍”往往会得到“检查后确认没有问题”这种无效答案——它是在同一套概率路径上再走一遍而不是真的用另一个独立逻辑去校对。实用的缓解方法是人为切断长链路把一个大任务拆成几个小步骤每步独立验证再把结果拼接起来。我在项目里经常用这个思路让模型先列大纲、再逐段产出、最后单独做一轮合法性校验准确率明显比一次生成到底高出不少。3.4 判断模型可靠性的实用框架经历过若干次幻觉之后我自己总结了一套判断模型输出靠谱程度的办法核心就是一句话先判断这是一道“语言题”还是“事实题”。语言题比如润色文案、翻译、改写风格、提取关键词模型表现通常很可靠可以放心用事实题比如时间地点人物事件、数字计算结论、政策法规细节模型表现必须默认存疑尤其在你不了解该领域的答案时。存疑不是不用而是建立验证机制。有明确来源的事比如“根据某篇文档总结内容”一定要把文档内容放进上下文模型基于给定材料输出幻觉率会大幅下降没有来源的事比如网站上的即时价格直接让模型去查本身就难为它不如交给插件或代码去请求一个数据接口。记住这个分界线并让团队都形成习惯比任何工程技巧都更能帮你少踩坑。4. 把模型用明白提示词与上下文工程4.1 提示词的本质是“搭脚手架”不是咒语很多入门者把提示词当成玄学觉得有万能模板。实际上提示词的作用机制很简单你给出了一段新的上文模型在这个上文约束下调整后续的生成概率。你要求“用表格输出”表格结构相关的Token概率就被提高了你指定“面向小学生解释”那些通俗词汇和类比句式的概率就升上来了。提示词不是咒语它是在给模型临时搭建一条概率通道。理解了这一点你就会知道好的提示词不是越长越好而是约束信息越明确越好。让模型“生成一个活动方案”远不如“生成一个面向企业客户的线下产品发布活动方案时间半天预算五万以内输出包含流程表、物料清单、分工建议三个部分”来得有效。判断提示词是否合格就看它是否把足够的约束信息塞进了上下文。有时候你觉得模型“不听指挥”其实只是约束给得太模糊它只能按自己的习惯猜。4.2 几个立竿见影的提示词套路先说结构化输出。需要程序处理时明确指定输出JSON并给出字段示例。比如输出JSON字段包括title、date、itemsitems为数组。模型会尽力贴合因为你提供的格式本身进入了上下文。如果解析时偶尔失败给它一个“输出必须严格为合法JSON不要包含其他文字”的补充约束有效率高很多。第二个是少样本示例也就是few-shot。与其反复强调“要简洁”不如直接给它一条“简洁版本”和“啰嗦版本”的对照。模型在几个示例之间会自动归纳你要的模式。一次生成不顺照着这个思路补上一两条例子通常比更换提示词措辞更加直接有效。第三个是角色设定。让模型扮演某个角色本质是在激活它语料中的特定风格区域——律师、老师、资深架构师各自对应的措辞和思维模式都被压缩在不同概率区域里。角色设定做好了能同时影响语气、信息密度和价值取向。但它不是万能的如果任务本身需要实时数据或专业深知识任何角色扮演都变不出事实来。4.3 用检索把外部知识“塞进”上下文缓解幻觉最有效的手段不是反复叮嘱“别瞎编”而是检索增强生成简称为RAG。做法是把外部文档先切成若干小段存进向量索引里用户提问时先在索引里找出与问题语义最接近的几段原文把它们连同问题一起放进模型的上下文让模型“读着材料答问题”。我在一个模拟项目X里试过用这个办法处理某个公司的内部规章制度查询效果提升非常明显。之前模型全靠训练记忆回答答错率大概三成接入检索之后回答基本都以给定文档为依据哪怕资料本身有不完善的地方模型也会如实引用而非自行补全。这类做法是当前最稳妥的“私有知识库问答”落地路线值得每一个打算做文档问答产品的开发者深入了解。4.4 同一模型、不同提示输出差异有多大我做过一次粗浅的对比测试同一模型、同一个问题、三种提示策略。第一种直接问“什么是内存对齐”回答专业但有些教科书腔第二种要求“用类比方式解释给非专业朋友”回答突然变成了水管工和马路上的故事第三种给出一个背景——“用户是一名嵌入式开发请结合栈分配的常见坑来解释”回答的深浅和术语密度立刻又不同了。这说明一个道理模型的能力上限确实由参数和训练决定但你能挖掘到多少能力取决于你给出的上下文质量。同样一个模型有人用得顺手有人总觉得不好用差距一大半在提示词与上下文工程上。下一章我们就顺着这条思路把它从聊天界面搬到真实的生产流程里。5. 从聊天框到生产流程把语言模型嵌入真实系统5.1 调用接口一次“提问”本质是一个消息数组在代码里跟语言模型交互跟聊天界面里打字没有本质区别核心就是一个消息数组。数组里的每条消息都有role字段常见的是system、user、assistant三种角色。system的作用是设定全局规则比如“你是一个客服助手回答要简洁、不得编造”user是你提的问题assistant通常用来存放模型历史回复。整个数组拼起来就是模型看到的全部上文。调用的时候把整个消息数组发出去模型返回的也是一个消息对象developer的内容就是它的回复。要注意的是每次对话都携带了全部历史记录这条对话越长发送的Token越多费用也越高。想控制成本就要主动截断历史只保留最近几轮加一个“系统级摘要”而不是把三个月前的聊天记录都一股脑带上去。5.2 流式输出为什么响应要一个字一个字蹦出来接口有两种返回模式一次性返回全部文字或者流式返回。流式输出的体验更像真人敲字首字几百毫秒就出现然后逐句输出。它不只是体验优化还能让“中途停止生成”成为可能——用户看到方向不对点一下“停止”后端立刻断掉生成请求节省Token消耗。实现流式输出时业务上要处理一个麻烦语义完整性。模型还没说完接收端拿到的文本是残缺的如果你在旁边做关键词识别或实时翻译效果会很差。我建议把“展示”和“加工”分离展示层直接显示流式文本加工层等完整文本落地后再异步处理。比如关键词高亮、格式整理这些操作在线做容易闪跳异步做更稳定。5.3 多轮对话的状态归属后端持有还是客户端持有真实产品里消息数组存哪里是个容易踩坑的决策。最省事的做法是客户端持有完整的消息历史每次请求把整个数组发给后端后端原样转给模型接口。适合内部工具和演示。但到了正式多用户产品这种做法有两个问题一是容易被用户绕过前端篡改历史消息导致“越权”内容混入上下文二是消息存储在端侧换设备聊天记录就断片了。稳妥的做法是让后端管理真正的会话状态。前端只传用户当前输入和会话ID后端从存储中读出历史消息、拼接上下文、做长度截断、调用模型、保存模型回复最后才把结果返回给前端。听上去多了一道存储的功夫但安全性、可审计性、跨端一致性全都有了。权限控制也能在这里统一做用户改了角色设定数据直接在后端过滤掉。5.4 一个极简的“AI助手服务”设计示例下面用一段伪代码演示上面这套思路的骨架语言用通用的Python风格不依赖任何具体服务商import json def build_context(session_id, new_message, max_tokens4000): # 从存储读取历史消息实践中会从数据库或缓存里读取 history load_history(session_id) truncated truncate_history(history, max_tokens) return truncated [{role: user, content: new_message}] def call_model(messages): payload { model: your-model-name, messages: messages, temperature: 0.3, # 低温度适合事实类任务 max_tokens: 800, } return post_json(https://api.example.ai/v1/chat/completions, payload) def assistant_reply(session_id, user_text): # 后端统一管理状态构造上下文、调用模型、持久化 messages build_context(session_id, user_text) reply call_model(messages) save_messages(session_id, [{role: user, content: user_text}, reply]) return reply session demo-session-001 print(assistant_reply(session, 帮我梳理一段文档的要点))三段函数各管一件事构建上下文、调用模型、管理状态。看起来简单但它是我见过很多中型项目通用的核心骨架。你要加工具调用就在call_model的payload里附上可用函数列表要加检索增强就在build_context阶段把检索到的文档片段插进去要加安全控制就在调用前加一层过滤。所有进阶能力都是从这个最小骨架长出来的。6. 一段并不啰嗦的阶段性体会关于“超越聊天机器人”这件事我道出了自己经常跟朋友唠叨的一句话语言模型不是数据库查询器它是世界上最高效的文字续写器——它最擅长把话说得漂亮、说得通顺、说得像那么回事但它不保证说的话一定符合事实。这两点是同一件事的两面接受它你才不会在和模型相处时产生不切实际的期待。把它当“起草者”“翻译官”“概括员”来看它强得惊人把它当“百科全书写手”且不做校对它一定会让你在关键时刻栽跟头。把提示词理解成搭脚手架、把历史消息当成上下文、把检索当作事实补给这三件基本功比你会用多少个花哨的提示词模板重要得多。下一期我打算聊聊模型本身重点解释参数的秘密、同一系列里的不同尺寸该怎么选以及推理成本到底是怎么算出来的。如果你最近也遇到过模型输出翻车的案例或者有自己的一套提示词心得欢迎在评论区留个脚印。