我从第一次接触语言模型到现在最大的认知变化就是别再叫它聊天机器人了。不是因为名字好听不好听而是因为一旦你用聊天机器人这个框去套它你能想到的应用场景就全被限制在我问一句、你答一句里了。今年我做了一个特别小的试验把一份散到不能再散的会议记录丢给模型让它按待办事项、责任人、截止时间抽成表格再让它直接把结果输出成JSON格式交给下游脚本。它一次就成功了。那一刻我突然意识到我们天天挂在嘴边的大语言模型本质是一个藏在对话面具底下的语言引擎——对话只是它最常见的一种使用方式远远不是它的能力边界。这篇是整个系列的开篇。我会从语言模型的工作原理、三个绕不开的关键概念token、上下文窗口、幻觉到怎么把它从聊天框改造成工作流引擎再到我自己平时怎么评估一个模型到底行不行一层层把发动机盖掀开。不管你是开发者、内容从业者还是单纯对AI感兴趣但已经被各种术语劝退过的人这篇都能帮你建立一个能落地的认知框架。1. 聊天机器人这顶帽子把多少人的思路给堵死了1.1 对话只是默认外壳不是能力上限每次我在线下分享时问听众你觉得语言模型是什么收到的答案高度一致能聊天的、会写作文的、能翻译的、可以当搜索引擎用的。这些回答全都建立在一个共同前提上——你看到它的时候它是一个对话框。这个界面印象太强了。某对话产品大火之后全球用户都习惯了在输入框里打字、按回车、等待流式输出的那一行行文字。于是大家默认这东西就是一个更聪明的聊天机器人。但如果你只用聊天的视角去理解它你永远想不到几件事:让它直接输出一段符合指定数据结构的JSON而不是自然语言让它从100条客户反馈里抽取出情绪倾向、提及产品线、建议优先级三个维度让它把一段口语变成SQL查询去查数据库让它调用你写好的函数去查天气、算利息、搜文档。这些操作没有一个发生在聊天的自然语境里但它们全部是语言模型极其擅长的事。对话界面只是产品经理给模型做的默认外壳——模型本身是一台通用的文本理解与生成引擎外壳和引擎之间不能画等号。1.2 认知错位带来的连锁反应我见过不少在业务里折腾了很久语言模型的团队产品和运营提需求时张口就是做一个能聊我们公司业务的机器人。开发接需求时也就老老实实做了个对话框把知识库文档一股脑塞进提示词然后面对超长文档、胡说八道、答非所问等问题束手无策。问题出在哪出在需求方把对话当成了目标而不是把完成任务当成目标。同样的模型换个用法效果完全不同。我曾经给一个模拟项目配置过一个小模块用户丢进来一段任意格式的报销单据描述模型负责抽取金额、日期、类别、是否缺材料并输出固定schema的JSON。界面根本没有聊天框就是一个上传按钮加一个结果面板。结果稳定性和实用性比我之前见过的所有行业问答机器人都好。这就是我想强调的第一课先别纠结模型像不像人先想清楚你要的是一个会聊天的外壳还是一个能替你处理语言任务的引擎。后者能覆盖前者反之则不行。1.3 用发动机类比重新理解语言模型拿发动机来打比方。一台四缸发动机可以装进轿车跑通勤可以接上发电机给野营供电可以带动水泵浇地也可以装进割草机。你把发动机装进轿车时不必说这是一台会跑的发动机——它明明能驱动更多东西。语言模型也是这个道理。它在预训练阶段学会的是语言的统计规律、知识结构和推理范式这些都是通用的扭矩。至于最终是变成聊天机器人、文档分类器、代码补全插件还是客服工单路由系统取决于你给它装什么传动装置。我把这个认知转变视为使用语言模型的第一道分水岭。跨过去之后你会开始问这个任务能不能用语言模型来做而不是能不能跟这个机器人聊出结果。2. 预测下一个词的魔法语言模型的工作原理拆开看2.1 自回归生成一个字一个字往外蹦的概率接龙语言模型最核心的任务目标听上去甚至有点无聊给定前文预测下一个词的概率分布。训练时喂进去海量文本让模型反复做同一件事——看到一句话的前半段猜后半段猜错就调整参数猜对就强化。这就导致模型的生成方式是自回归的它不是一个字一个词读完整篇文章再给你答案而是每次都根据已经生成的那部分内容再挑下一个最合适的token。你看到的一大段话其实是它一个词一个词接龙接出来的每接一个新token上下文就增加一点再基于这点预测下一个。维持这种复读机式的简单目标在大规模数据和参数量的前提下会涌现出什么语法、事实关联、逻辑推演、风格模仿、代码结构……预测下一个词这个任务本身逼着模型学会了大量隐含在文本背后的规律。就像学外语最好的方式是大量阅读然后尝试续写——续写被迫让你理解前文的风格和逻辑。我在实际用模型时这个机制给我最大的启发是既然它是续写式的那么你给它什么开头基本决定了它朝哪里续。你给一段残缺的需求它就给你一段残缺的答案你给一份结构清晰的规范它就更可能还你一份同样结构清晰的输出。2.2 注意力机制模型怎么知道该重视谁预测下一个词之前模型必须回答一个问题前面那么多词我该重点看哪些比如那只猫追着老鼠跑虽然它很累但还是……——它到底指猫还是老鼠人类能结合常识判断模型靠的是一个精妙的机制注意力Attention。Transformer架构的核心之一就是让输入序列里的每个token和序列里的其他所有token两两计算关联权重。生成累这个字的时候模型会自动分配高权重给猫追跑这些相关词低权重给无关信息。所有词的表示其实是带上下文的动态理解而不是孤立的字面含义。再加上位置编码模型就知道词与词的先后顺序。这个设计解决了老一代循环神经网络处理长距离依赖时容易忘事的毛病——一句绕了80个词的话早期模型很容易把它读断注意力机制却可以让那个猫和一个80词以外的累直接建立强关联。理解注意力机制对实际应用有一个很直接的好处长文本里真正有用的关键句越多、越集中模型的表现往往越好。反过来一堆噪声段落会让注意力被稀释生成质量明显下降。这也是为什么提示词里总强调给精炼的背景而不是把整份文档全塞进去。2.3 预训练与微调发动机和方向盘语言模型的能力结构来自两个完全不同的阶段很多人混在一起讲搞出不少误解。预训练阶段模型在海量公开文本上完成预测下一个词的任务。这个阶段决定了模型肚子里有多少知识、推理能力怎么样、语言风格有多丰富——可以说发动机的排量是在这里定下的。微调阶段包括基于人类反馈的强化学习这类后续工作则是在预训练基础上用标注好的对话数据把模型的输出习惯调整成更像一个有用的助手不会句句都只接个最短的续写而是能回答问题、能拒答风险内容、能遵循指令。这个阶段更像方向盘和刹车——它改变的是驾驶风格不是发动机排量。这一点务必要清楚如果你需要一个擅长写代码的模型它必须在预训练阶段就见过足够多的代码光靠微调是无法让一个根本没学过代码的模型突然变成高手的。反过来说如果你只想让它输出风格更幽默那就别指望重训模型——换一套提示词往往更高效。我见过的不少项目做了一堆微调实验效果却不如精心设计提示词原因就在这他们想用方向盘去换发动机。3. 三个绕不开的坎token、上下文窗口与幻觉3.1 token不是字而是运算单元几乎所有接触语言模型的人都会遇到这个概念。token是模型处理文本的最小单元语义上可能是单词、子词、几个字符甚至一个中文字旁边的半个词组。我见到最多的误区是有人按字数去估算模型费用或上下文占用结果和实际计费差出一大截。一条规则英语里一个单词大概对应1到1.5个token中文则看分词器通常一个汉字可能对应半个到两个token不等。不同模型的分词方案差异很大实战中需要按token数而不是字数做估算。为什么要专门提这个因为我踩过坑。当时给某个长文档处理模块设计上下文我以为两万字的文档放进窗口没问题结果实际token数远远超出预期模型被截断摘要质量直线下降。后来配置脚本时统一按token统计长度再没出过这类问题。token的另一个影响是分词边界一些罕见的专业术语、代码片段、生僻词可能被切得很碎影响模型理解。遇到这类内容用更高层次的表达方式比如给术语加解释往往比直接丢一堆碎片进来更有效。3.2 上下文窗口它是放不下不是记不住经常有人抱怨模型怎么聊着聊着就把前面忘了。准确的做法是别用记忆来描述这个问题——模型确实没有长期记忆它每次预测能参考的只有当前上下文窗口内放着的token。窗口有限就像一个临时桌面能摊开的文件就那么多摊不下的东西它想看也看不见了。处理超长文档时网上常说的滑动窗口分段摘要思路本质就是给这个桌面做整理先把厚文档切成小块逐块让模型洗净提炼再把提炼结果重新拼成一份能塞进窗口的浓缩版。实测下来还有两个容易被忽略的现象。一是越接近窗口上限模型找不着重点的概率越高——信息太多时注意力被稀释二是如果你把关键信息放在很靠后的位置它会比放在开头更容易被忽略。所以我做长文档任务时一般会把最重要的指令放开头、要处理的内容放中间、对输出格式的要求再在结尾强调一遍。这种三明治式排布在实践中比随手一糊的提示词稳定得多。3.3 幻觉不是BUG是概率的副产品语言模型是概率接龙不是数据库查询。当它不知道一个事实时它不会像数据库一样返回未找到而是会按最像样的方式把答案续写完——这就是幻觉的来源之一。它不是撒谎而是太擅长说像话的话。幻觉在实际使用中主要有三类表现知识盲区被强行补全比如编造不存在的书籍或数据、知识截止日期之后的信息被过时认知覆盖、以及复杂推理过程里张冠李戴。还有一个隐蔽场景让它生成参考文献或数字时它可能生成出来格式完美但完全不存在的条目。降低幻觉不是靠换一个更聪明的模型就能一劳永逸操作层面我常用的组合拳:给可信参考片段要求答案必须基于参考内容提示词里写明如果信息不在参考中请明确回答不知道对重要事实做交叉验证不把模型单次输出当唯一依据让模型输出结构化JSON减少自由发挥空间对知识密集型场景直接上检索增强这个下一节会展开。理解幻觉是概率副产品之后你就不太容易对它一本正经地胡说八道感到愤怒——你会把它当成一个需要设计约束来管理的系统特性。4. 把语言模型当引擎使从聊天走向工作流的四个实操4.1 结构化输出让模型说机器听得懂的话聊天场景里模型输出自然语言就够了但工程场景里我们需要它输出JSON、XML、SQL甚至一段符合特定schema的配置文件。这个时候提示词的写法要变明确要求只输出JSON不要多余解释并在提示词里贴出期望的字段结构。我用一个简单例子说明。假设有一段客户反馈你们这个APP登录太慢了等了半天一直转圈我用的是安卓手机版本号好像是12。我让接口返回如下JSON{ channel: APP, os: android, version: 12, issue_type: performance, priority: high, summary: APP登录慢安卓12机型长时间转圈 }实操时我会在系统消息里给出一段示例JSON并在用户消息里强调严格按照给定schema输出缺失字段用空字符串。效果比干巴巴地说请提取关键信息稳定太多。这里的关键原则是不要依赖模型猜你想要什么格式而是把格式作为唯一正确的解法示范给它看。4.2 函数调用给模型装上手和脚纯文本模型再聪明也没法自己查数据库、算算式、触发接口。但只要模型支持函数调用function calling你就可以定义一组工具函数让模型在回答时先决定该调用哪个工具、参数是什么然后把工具返回的结果组织成最终答案。我做过一个模拟演示给模型注册了查询天气和查询日历两个函数。用户说周五我想爬山帮我看看天气合适吗模型并不会直接编一个天气答案而会输出一个调用天气函数的请求参数是周五对应的日期和城市。程序执行完函数、拿到真正的天气数据后再交回给模型组织成自然语言回复。这套机制的意义在于模型不再是一个只能说的引擎而是一个可以做的调度的中枢。你可以把计算器、数据库查询、订单系统、搜索API全部挂上去让模型根据用户意图决定调哪个。应用层就能用模型工具集拼装出无数条自动化工作流。4.3 检索增强在参数之外找知识模型参数里装的知识是静态的有截止日期也有覆盖盲区。要让它回答私有文档、实时数据或最新政策这类问题更稳妥的路线是检索增强生成RAG外部准备一个知识库用户提问时先把问题转成向量表示在知识库里做语义相似度检索找出最相关的若干片段再把这些片段连同问题一起塞进上下文让模型基于给定材料作答。这套方案的工程效力我自己的体会是方案听起来不复杂难点全在细节。80%的工作量在文档清洗和切块策略而不是向量库选型。文档里一个章节该怎么切、小块还是大块、要不要保留标题层级、检索到的片段要不要做重排去重——这些细节直接决定用户看到的是精准回答还是驴唇不对马嘴。我在一个模拟项目里踩过切块太碎的坑。一份产品操作手册被机械地每200字切一块导致付款失败这类跨章节问题检索不到完整上下文模型只能根据残缺片段生搬硬套。后来改成按章节层级语义完整句切块效果立刻不一样。所以如果你准备做知识库问答先把文档结构研究明白比研究向量数据库重要得多。4.4 完整示例批量整理100条客户反馈把上面几个能力拼在一起我写过一个很实用的脚本用来批量处理客户反馈。思路特别简单但效果比把所有反馈一次性发给模型好上数倍。import csv import json from some_api import chat_completion def extract_feedback(text: str) - dict: sys_prompt ( 你是一个反馈分析助手。请从用户反馈中提取字段 只输出JSON不要输出多余内容。 缺失字段填空字符串。 ) user_prompt f 请解析以下反馈 {text} 按如下JSON schema输出 {{ contact_time: , channel: , issue_type: , sentiment: , priority: , summary: }} resp chat_completion( messages[ {role: system, content: sys_prompt}, {role: user, content: user_prompt}, ], temperature0, response_format{type: json_object}, ) return json.loads(resp) with open(feedback.csv, encodingutf-8) as f: rows list(csv.DictReader(f)) results [] for row in rows: parsed extract_feedback(row[content]) parsed[id] row[id] results.append(parsed) with open(feedback_parsed.json, w, encodingutf-8) as f: json.dump(results, f, ensure_asciiFalse, indent2)这段脚本没什么高深技术但它展示了一个关键转折模型不再是聊天对象而是数据流水线上的一环。每条反馈进来输出固定结构的JSON下游可以直接聚合统计高频问题类型情绪分布。温度参数设为0是为了让抽取结果尽量稳定、不发挥。如果你也想让模型进入生产流水线这就是最简单的起步样板。5. 建立自己的评测坐标系怎么判断一个模型强不强5.1 别让聊天答得好不好骗了你评测语言模型最误事的做法是拿几个日常闲聊问题去试聊得顺畅就说这模型很强。聊得顺畅只能说明它的对话界面做得好不能说明它在抽取、推理、结构化输出、长文档处理这些生产任务上表现如何。我在做方案选型的时候会针对任务类型分别测试。模型A聊天可能比模型B更有人味但在结构化输出评测里可能合格率反而低。每个模型都有自己的能力分布光有一把聊天标尺没法衡量。稍微过分一点说模型评测应该像招人一样看岗位匹配度。你是找一个客服前台还是找一个数据标注员用的考卷完全不是一回事。5.2 我常用的土评测四件套公开榜单当然可以参考但具体到你自己的业务场景还是得自己出题。我总结了四组很土但很可靠的测试方法:固定提示词、固定输出格式同一个问题跑3次看结构稳定性和字段提取准确率。判断它适不适合当数据流水线工人。构造一组存在知识盲区的可疑事实问题看它会不会坦诚说不知道还是硬编一个答案。这直接关系幻觉风险高低。丢一篇长文3000字以上让它摘要再人工对照原文查漏点。看它在大窗口下的注意力分配能力。反向测试明确要求如果条件不满足只输出无法处理不要解释。看它能不能克制住自己继续说话的冲动。四组测完一个模型在你业务里的画像基本就清晰了。我自己的经验是很多口碑很好的通用模型在土评测第三、第四项上会露馅——要么摘要漏掉关键结论要么控制不住要额外解释。这类问题在聊天评测里完全发现不了。5.3 温度、系统提示词和输出格式的控制评测之外控制输出稳定性还有一个容易被忽略的维度生成参数。拿温度temperature来说取值越低输出越保守、可复现性越强取值越高越有创造力但代价是稳定性下降。生产环境里做抽取、分类、格式化这类任务我基本固定在0到0.2之间只有做文案润色、头脑风暴这类偏创意的活才敢把温度往上调到0.7左右。系统提示词是另一个被浪费的控制位。很多人只在用户消息里丢问题系统提示词空着不用。合理的做法是在系统层把身份任务约束输出格式一次性说清楚用户消息只负责给具体内容。这样一来同一个模型在客服助手数据抽取器代码解释器之间切换就像换文件头一样干净。最后再分享一个我自己的真实体会。用了两三年语言模型之后最大的转变不是掌握了什么复杂框架而是彻底改变了和它协作的心态——从问它问题变成给它派活。你把它当成一个需要验收、需要管理、需要明确边界和交付格式的协作对象很多本事自然就长出来了。这个系列的下一篇我会专门拆解提示词设计的底层原则以及怎么用系统提示词把一个普通模型调教成稳定、靠谱的工作模块。 
长河君 · 2026/10/13 11:28:23 · 阅读 1.2k 从聊天机器人到语言引擎：大模型工作流化实践指南
我从第一次接触语言模型到现在最大的认知变化就是别再叫它聊天机器人了。不是因为名字好听不好听而是因为一旦你用聊天机器人这个框去套它你能想到的应用场景就全被限制在我问一句、你答一句里了。今年我做了一个特别小的试验把一份散到不能再散的会议记录丢给模型让它按待办事项、责任人、截止时间抽成表格再让它直接把结果输出成JSON格式交给下游脚本。它一次就成功了。那一刻我突然意识到我们天天挂在嘴边的大语言模型本质是一个藏在对话面具底下的语言引擎——对话只是它最常见的一种使用方式远远不是它的能力边界。这篇是整个系列的开篇。我会从语言模型的工作原理、三个绕不开的关键概念token、上下文窗口、幻觉到怎么把它从聊天框改造成工作流引擎再到我自己平时怎么评估一个模型到底行不行一层层把发动机盖掀开。不管你是开发者、内容从业者还是单纯对AI感兴趣但已经被各种术语劝退过的人这篇都能帮你建立一个能落地的认知框架。1. 聊天机器人这顶帽子把多少人的思路给堵死了1.1 对话只是默认外壳不是能力上限每次我在线下分享时问听众你觉得语言模型是什么收到的答案高度一致能聊天的、会写作文的、能翻译的、可以当搜索引擎用的。这些回答全都建立在一个共同前提上——你看到它的时候它是一个对话框。这个界面印象太强了。某对话产品大火之后全球用户都习惯了在输入框里打字、按回车、等待流式输出的那一行行文字。于是大家默认这东西就是一个更聪明的聊天机器人。但如果你只用聊天的视角去理解它你永远想不到几件事:让它直接输出一段符合指定数据结构的JSON而不是自然语言让它从100条客户反馈里抽取出情绪倾向、提及产品线、建议优先级三个维度让它把一段口语变成SQL查询去查数据库让它调用你写好的函数去查天气、算利息、搜文档。这些操作没有一个发生在聊天的自然语境里但它们全部是语言模型极其擅长的事。对话界面只是产品经理给模型做的默认外壳——模型本身是一台通用的文本理解与生成引擎外壳和引擎之间不能画等号。1.2 认知错位带来的连锁反应我见过不少在业务里折腾了很久语言模型的团队产品和运营提需求时张口就是做一个能聊我们公司业务的机器人。开发接需求时也就老老实实做了个对话框把知识库文档一股脑塞进提示词然后面对超长文档、胡说八道、答非所问等问题束手无策。问题出在哪出在需求方把对话当成了目标而不是把完成任务当成目标。同样的模型换个用法效果完全不同。我曾经给一个模拟项目配置过一个小模块用户丢进来一段任意格式的报销单据描述模型负责抽取金额、日期、类别、是否缺材料并输出固定schema的JSON。界面根本没有聊天框就是一个上传按钮加一个结果面板。结果稳定性和实用性比我之前见过的所有行业问答机器人都好。这就是我想强调的第一课先别纠结模型像不像人先想清楚你要的是一个会聊天的外壳还是一个能替你处理语言任务的引擎。后者能覆盖前者反之则不行。1.3 用发动机类比重新理解语言模型拿发动机来打比方。一台四缸发动机可以装进轿车跑通勤可以接上发电机给野营供电可以带动水泵浇地也可以装进割草机。你把发动机装进轿车时不必说这是一台会跑的发动机——它明明能驱动更多东西。语言模型也是这个道理。它在预训练阶段学会的是语言的统计规律、知识结构和推理范式这些都是通用的扭矩。至于最终是变成聊天机器人、文档分类器、代码补全插件还是客服工单路由系统取决于你给它装什么传动装置。我把这个认知转变视为使用语言模型的第一道分水岭。跨过去之后你会开始问这个任务能不能用语言模型来做而不是能不能跟这个机器人聊出结果。2. 预测下一个词的魔法语言模型的工作原理拆开看2.1 自回归生成一个字一个字往外蹦的概率接龙语言模型最核心的任务目标听上去甚至有点无聊给定前文预测下一个词的概率分布。训练时喂进去海量文本让模型反复做同一件事——看到一句话的前半段猜后半段猜错就调整参数猜对就强化。这就导致模型的生成方式是自回归的它不是一个字一个词读完整篇文章再给你答案而是每次都根据已经生成的那部分内容再挑下一个最合适的token。你看到的一大段话其实是它一个词一个词接龙接出来的每接一个新token上下文就增加一点再基于这点预测下一个。维持这种复读机式的简单目标在大规模数据和参数量的前提下会涌现出什么语法、事实关联、逻辑推演、风格模仿、代码结构……预测下一个词这个任务本身逼着模型学会了大量隐含在文本背后的规律。就像学外语最好的方式是大量阅读然后尝试续写——续写被迫让你理解前文的风格和逻辑。我在实际用模型时这个机制给我最大的启发是既然它是续写式的那么你给它什么开头基本决定了它朝哪里续。你给一段残缺的需求它就给你一段残缺的答案你给一份结构清晰的规范它就更可能还你一份同样结构清晰的输出。2.2 注意力机制模型怎么知道该重视谁预测下一个词之前模型必须回答一个问题前面那么多词我该重点看哪些比如那只猫追着老鼠跑虽然它很累但还是……——它到底指猫还是老鼠人类能结合常识判断模型靠的是一个精妙的机制注意力Attention。Transformer架构的核心之一就是让输入序列里的每个token和序列里的其他所有token两两计算关联权重。生成累这个字的时候模型会自动分配高权重给猫追跑这些相关词低权重给无关信息。所有词的表示其实是带上下文的动态理解而不是孤立的字面含义。再加上位置编码模型就知道词与词的先后顺序。这个设计解决了老一代循环神经网络处理长距离依赖时容易忘事的毛病——一句绕了80个词的话早期模型很容易把它读断注意力机制却可以让那个猫和一个80词以外的累直接建立强关联。理解注意力机制对实际应用有一个很直接的好处长文本里真正有用的关键句越多、越集中模型的表现往往越好。反过来一堆噪声段落会让注意力被稀释生成质量明显下降。这也是为什么提示词里总强调给精炼的背景而不是把整份文档全塞进去。2.3 预训练与微调发动机和方向盘语言模型的能力结构来自两个完全不同的阶段很多人混在一起讲搞出不少误解。预训练阶段模型在海量公开文本上完成预测下一个词的任务。这个阶段决定了模型肚子里有多少知识、推理能力怎么样、语言风格有多丰富——可以说发动机的排量是在这里定下的。微调阶段包括基于人类反馈的强化学习这类后续工作则是在预训练基础上用标注好的对话数据把模型的输出习惯调整成更像一个有用的助手不会句句都只接个最短的续写而是能回答问题、能拒答风险内容、能遵循指令。这个阶段更像方向盘和刹车——它改变的是驾驶风格不是发动机排量。这一点务必要清楚如果你需要一个擅长写代码的模型它必须在预训练阶段就见过足够多的代码光靠微调是无法让一个根本没学过代码的模型突然变成高手的。反过来说如果你只想让它输出风格更幽默那就别指望重训模型——换一套提示词往往更高效。我见过的不少项目做了一堆微调实验效果却不如精心设计提示词原因就在这他们想用方向盘去换发动机。3. 三个绕不开的坎token、上下文窗口与幻觉3.1 token不是字而是运算单元几乎所有接触语言模型的人都会遇到这个概念。token是模型处理文本的最小单元语义上可能是单词、子词、几个字符甚至一个中文字旁边的半个词组。我见到最多的误区是有人按字数去估算模型费用或上下文占用结果和实际计费差出一大截。一条规则英语里一个单词大概对应1到1.5个token中文则看分词器通常一个汉字可能对应半个到两个token不等。不同模型的分词方案差异很大实战中需要按token数而不是字数做估算。为什么要专门提这个因为我踩过坑。当时给某个长文档处理模块设计上下文我以为两万字的文档放进窗口没问题结果实际token数远远超出预期模型被截断摘要质量直线下降。后来配置脚本时统一按token统计长度再没出过这类问题。token的另一个影响是分词边界一些罕见的专业术语、代码片段、生僻词可能被切得很碎影响模型理解。遇到这类内容用更高层次的表达方式比如给术语加解释往往比直接丢一堆碎片进来更有效。3.2 上下文窗口它是放不下不是记不住经常有人抱怨模型怎么聊着聊着就把前面忘了。准确的做法是别用记忆来描述这个问题——模型确实没有长期记忆它每次预测能参考的只有当前上下文窗口内放着的token。窗口有限就像一个临时桌面能摊开的文件就那么多摊不下的东西它想看也看不见了。处理超长文档时网上常说的滑动窗口分段摘要思路本质就是给这个桌面做整理先把厚文档切成小块逐块让模型洗净提炼再把提炼结果重新拼成一份能塞进窗口的浓缩版。实测下来还有两个容易被忽略的现象。一是越接近窗口上限模型找不着重点的概率越高——信息太多时注意力被稀释二是如果你把关键信息放在很靠后的位置它会比放在开头更容易被忽略。所以我做长文档任务时一般会把最重要的指令放开头、要处理的内容放中间、对输出格式的要求再在结尾强调一遍。这种三明治式排布在实践中比随手一糊的提示词稳定得多。3.3 幻觉不是BUG是概率的副产品语言模型是概率接龙不是数据库查询。当它不知道一个事实时它不会像数据库一样返回未找到而是会按最像样的方式把答案续写完——这就是幻觉的来源之一。它不是撒谎而是太擅长说像话的话。幻觉在实际使用中主要有三类表现知识盲区被强行补全比如编造不存在的书籍或数据、知识截止日期之后的信息被过时认知覆盖、以及复杂推理过程里张冠李戴。还有一个隐蔽场景让它生成参考文献或数字时它可能生成出来格式完美但完全不存在的条目。降低幻觉不是靠换一个更聪明的模型就能一劳永逸操作层面我常用的组合拳:给可信参考片段要求答案必须基于参考内容提示词里写明如果信息不在参考中请明确回答不知道对重要事实做交叉验证不把模型单次输出当唯一依据让模型输出结构化JSON减少自由发挥空间对知识密集型场景直接上检索增强这个下一节会展开。理解幻觉是概率副产品之后你就不太容易对它一本正经地胡说八道感到愤怒——你会把它当成一个需要设计约束来管理的系统特性。4. 把语言模型当引擎使从聊天走向工作流的四个实操4.1 结构化输出让模型说机器听得懂的话聊天场景里模型输出自然语言就够了但工程场景里我们需要它输出JSON、XML、SQL甚至一段符合特定schema的配置文件。这个时候提示词的写法要变明确要求只输出JSON不要多余解释并在提示词里贴出期望的字段结构。我用一个简单例子说明。假设有一段客户反馈你们这个APP登录太慢了等了半天一直转圈我用的是安卓手机版本号好像是12。我让接口返回如下JSON{ channel: APP, os: android, version: 12, issue_type: performance, priority: high, summary: APP登录慢安卓12机型长时间转圈 }实操时我会在系统消息里给出一段示例JSON并在用户消息里强调严格按照给定schema输出缺失字段用空字符串。效果比干巴巴地说请提取关键信息稳定太多。这里的关键原则是不要依赖模型猜你想要什么格式而是把格式作为唯一正确的解法示范给它看。4.2 函数调用给模型装上手和脚纯文本模型再聪明也没法自己查数据库、算算式、触发接口。但只要模型支持函数调用function calling你就可以定义一组工具函数让模型在回答时先决定该调用哪个工具、参数是什么然后把工具返回的结果组织成最终答案。我做过一个模拟演示给模型注册了查询天气和查询日历两个函数。用户说周五我想爬山帮我看看天气合适吗模型并不会直接编一个天气答案而会输出一个调用天气函数的请求参数是周五对应的日期和城市。程序执行完函数、拿到真正的天气数据后再交回给模型组织成自然语言回复。这套机制的意义在于模型不再是一个只能说的引擎而是一个可以做的调度的中枢。你可以把计算器、数据库查询、订单系统、搜索API全部挂上去让模型根据用户意图决定调哪个。应用层就能用模型工具集拼装出无数条自动化工作流。4.3 检索增强在参数之外找知识模型参数里装的知识是静态的有截止日期也有覆盖盲区。要让它回答私有文档、实时数据或最新政策这类问题更稳妥的路线是检索增强生成RAG外部准备一个知识库用户提问时先把问题转成向量表示在知识库里做语义相似度检索找出最相关的若干片段再把这些片段连同问题一起塞进上下文让模型基于给定材料作答。这套方案的工程效力我自己的体会是方案听起来不复杂难点全在细节。80%的工作量在文档清洗和切块策略而不是向量库选型。文档里一个章节该怎么切、小块还是大块、要不要保留标题层级、检索到的片段要不要做重排去重——这些细节直接决定用户看到的是精准回答还是驴唇不对马嘴。我在一个模拟项目里踩过切块太碎的坑。一份产品操作手册被机械地每200字切一块导致付款失败这类跨章节问题检索不到完整上下文模型只能根据残缺片段生搬硬套。后来改成按章节层级语义完整句切块效果立刻不一样。所以如果你准备做知识库问答先把文档结构研究明白比研究向量数据库重要得多。4.4 完整示例批量整理100条客户反馈把上面几个能力拼在一起我写过一个很实用的脚本用来批量处理客户反馈。思路特别简单但效果比把所有反馈一次性发给模型好上数倍。import csv import json from some_api import chat_completion def extract_feedback(text: str) - dict: sys_prompt ( 你是一个反馈分析助手。请从用户反馈中提取字段 只输出JSON不要输出多余内容。 缺失字段填空字符串。 ) user_prompt f 请解析以下反馈 {text} 按如下JSON schema输出 {{ contact_time: , channel: , issue_type: , sentiment: , priority: , summary: }} resp chat_completion( messages[ {role: system, content: sys_prompt}, {role: user, content: user_prompt}, ], temperature0, response_format{type: json_object}, ) return json.loads(resp) with open(feedback.csv, encodingutf-8) as f: rows list(csv.DictReader(f)) results [] for row in rows: parsed extract_feedback(row[content]) parsed[id] row[id] results.append(parsed) with open(feedback_parsed.json, w, encodingutf-8) as f: json.dump(results, f, ensure_asciiFalse, indent2)这段脚本没什么高深技术但它展示了一个关键转折模型不再是聊天对象而是数据流水线上的一环。每条反馈进来输出固定结构的JSON下游可以直接聚合统计高频问题类型情绪分布。温度参数设为0是为了让抽取结果尽量稳定、不发挥。如果你也想让模型进入生产流水线这就是最简单的起步样板。5. 建立自己的评测坐标系怎么判断一个模型强不强5.1 别让聊天答得好不好骗了你评测语言模型最误事的做法是拿几个日常闲聊问题去试聊得顺畅就说这模型很强。聊得顺畅只能说明它的对话界面做得好不能说明它在抽取、推理、结构化输出、长文档处理这些生产任务上表现如何。我在做方案选型的时候会针对任务类型分别测试。模型A聊天可能比模型B更有人味但在结构化输出评测里可能合格率反而低。每个模型都有自己的能力分布光有一把聊天标尺没法衡量。稍微过分一点说模型评测应该像招人一样看岗位匹配度。你是找一个客服前台还是找一个数据标注员用的考卷完全不是一回事。5.2 我常用的土评测四件套公开榜单当然可以参考但具体到你自己的业务场景还是得自己出题。我总结了四组很土但很可靠的测试方法:固定提示词、固定输出格式同一个问题跑3次看结构稳定性和字段提取准确率。判断它适不适合当数据流水线工人。构造一组存在知识盲区的可疑事实问题看它会不会坦诚说不知道还是硬编一个答案。这直接关系幻觉风险高低。丢一篇长文3000字以上让它摘要再人工对照原文查漏点。看它在大窗口下的注意力分配能力。反向测试明确要求如果条件不满足只输出无法处理不要解释。看它能不能克制住自己继续说话的冲动。四组测完一个模型在你业务里的画像基本就清晰了。我自己的经验是很多口碑很好的通用模型在土评测第三、第四项上会露馅——要么摘要漏掉关键结论要么控制不住要额外解释。这类问题在聊天评测里完全发现不了。5.3 温度、系统提示词和输出格式的控制评测之外控制输出稳定性还有一个容易被忽略的维度生成参数。拿温度temperature来说取值越低输出越保守、可复现性越强取值越高越有创造力但代价是稳定性下降。生产环境里做抽取、分类、格式化这类任务我基本固定在0到0.2之间只有做文案润色、头脑风暴这类偏创意的活才敢把温度往上调到0.7左右。系统提示词是另一个被浪费的控制位。很多人只在用户消息里丢问题系统提示词空着不用。合理的做法是在系统层把身份任务约束输出格式一次性说清楚用户消息只负责给具体内容。这样一来同一个模型在客服助手数据抽取器代码解释器之间切换就像换文件头一样干净。最后再分享一个我自己的真实体会。用了两三年语言模型之后最大的转变不是掌握了什么复杂框架而是彻底改变了和它协作的心态——从问它问题变成给它派活。你把它当成一个需要验收、需要管理、需要明确边界和交付格式的协作对象很多本事自然就长出来了。这个系列的下一篇我会专门拆解提示词设计的底层原则以及怎么用系统提示词把一个普通模型调教成稳定、靠谱的工作模块。