这篇文章我构思了很久才动笔。写第一篇的时候很多读者反馈说终于有人把LLM的门槛讲得不那么高了也有朋友私信问我我每天都在用对话模型但遇到具体业务需求就不知道怎么调参数为什么同一个问题换个说法输出就完全不一样——这些困惑其实都指向同一个问题我们只知道模型能做什么但不太清楚它内部到底在发生什么所以一旦超出日常聊天的舒适区就抓瞎了。这一篇我打算把使用和浅层原理这两条线真正缝到一起先聊清楚调用模型时那几个核心参数到底在调节什么为什么值得在意然后往下走一层看看token、注意力机制、训练流程这些概念是怎么影响模型行为的。配合一个完整的实操案例给你一份可以直接照着做的调参排错手册。1. 先搞清楚一件事你在用的到底是什么在动笔之前我想先统一一下认知。很多人会把大语言模型理解成一个巨大的知识库——有问必答、什么都知道。这个理解不能说完全错误但会带来很多实际操作上的误判。你通过API或网页对话框触达的本质上是一套经过多阶段训练的文本概率系统。它不是在数据库里检索正确答案而是在给定你输入的这段文本之后逐字逐句地预测下一个最可能出现的词是哪个。所谓知识其实是它把大量训练数据里的统计规律压缩进了数千亿个参数里然后通过参数之间的相互作用涌现出看似理解、推理的能力。想明白这一点很多现象就解释得通了为什么同样的意思换一种表达答案质量差很多因为模型对字面的敏感度远超对意图的敏感度。为什么它有时一本正经地胡说八道因为它根本不是靠记忆在回答而是在生成概率上最合理的文本。为什么给它一段背景资料再提问准确率会明显提升因为你在输入上下文里直接提供了下一个词需要的线索大幅降低了模型的预测难度。所以我一直建议朋友用一句话给自己提个醒你面对的不是一个知识库而是一个超级接话王。它极擅长顺着你的话往下圆但所有输出都是生成出来的不是查找出来的。这个认知是所有后续实操的起点。2. 使用层那些参数到底在调什么我第一次接触模型API的时候面对一堆参数也是一头雾水。官方文档写得挺全但没告诉你为什么要这样调。我踩了不少坑之后把最核心的几个参数琢磨明白了这里系统说一说。2.1 温度控制胆子大小temperature控制了输出结果的随机性。它的取值范围通常是0到2不过在多数实际场景里0到1就够了。很多人的直觉是temperature越高回答越有创意。这个直觉方向对但机制值得更精确地理解模型在预测下一个词时每个候选词都会得到一个概率分数temperature的作用是把这些概率分布压扁或锐化——温度高时概率分布被拉平原本概率较低的词变得有机会被选中于是输出更加多样、跳脱温度低时概率分布趋向于集中模型几乎总是挑概率最高的那个词输出稳定、保守、可复现。实操建议是这样需要事实性答案、代码生成、抽取结构化信息时temperature设在0.2以下我甚至经常直接用0。这时候模型输出几乎确定适合跑批处理任务。需要头脑风暴、文案润色、创意类生成时设置在0.7到0.9之间能获得相对高质量又不至于过度发散的结果。尽量不要超过1.2。超过这个值输出往往开始出现明显的断裂、逻辑不连贯、乱造句。你想要的创意和模型失控之间的界线比想象中窄得多。2.2 top_p另一种随机性控制top_p核采样是另一个控制随机性的参数。它的逻辑是只从累计概率达到p的那部分候选词里选词。比如top_p0.9意味着先把按概率从高到低排列的词累加累加到总概率90%为止然后只从这个池子里采样。我经常听人问temperature和top_p有什么区别。简单说temperature改变的是所有候选词的权重分布是全局操作top_p是直接切掉概率分布里那根长尾是个截断操作。官方文档通常会建议不要同时大改两个参数固定一个调另一个。我的习惯是固定top_p1不启用只用temperature来控制随机性。因为temperature的语义更直觉更容易调出感觉。有些人习惯反过来这没有绝对对错只要你自己清楚在调什么就行。2.3 max_tokens不只是最大长度max_tokens限制的是模型生成的最大token数不是字数。1个token大约等于0.7到1个汉字或者0.3到0.4个英文单词具体取决于分词方式。这事儿直接关系到两个问题一是计费。模型API几乎全部按token数计费输入和输出各算各的。你设置的max_tokens只是输出上限不是实际消耗。如果你的提示词本身很长这部分token也要付钱且会占用上下文窗口。二是截断风险。如果max_tokens设置得过小模型生成到一个自然停顿点之前就被强行掐断输出会突然半截。排查这类bug时第一眼就该看输出结尾是不是断在某个词的中间。我的习惯是把max_tokens设置为预期答案长度的1.5倍。比如让模型生成一段200字左右的摘要max_tokens给300左右就稳了。宁可多给不能少给因为截断后的输出通常没法直接用反而浪费更多调用次数。2.4 system prompt和user prompt的分工多数模型API都区分系统提示system prompt和用户提示user prompt。很多新手会把所有指令一股脑塞进用户消息里也能用但会让后续管理变得混乱。按照我个人的经验这两个角色的分工应当清晰系统提示用来定义你是谁、你以什么风格回答、你有什么限制。它相当于给模型设定一个常驻身份和工作准则。比如你是一名技术文档编辑擅长用简洁的中文解释复杂概念回答时先给结论再给解释不输出任何与问题无关的内容。这部分约束会被模型在整轮对话中持续遵循权重比普通用户消息更高。用户提示则专注于你这次的具体任务任务目标、输入数据、输出格式要求等。实践中还有一个常见问题系统提示写得太长占用了大量上下文窗口。虽然有些模型架构对系统提示有特殊加权但整体来说系统提示超过必要长度并不会带来明显收益反而会挤压后续对话空间。尽量控制在100到300字之间把核心命令说清楚就够了。2.5 提示词工程的几个有效手段网上关于提示词工程的帖子多如牛毛什么花哨的模板祖传咒语满天飞。我自己试过一大堆之后沉淀下来几个真正有效且通用的手段第一Few-shot示例也就是在提示词里放上两三个输入输出的示例让模型照着这个样板来回答。这相当有效因为它直接告诉模型输出格式和内容深度。示例的质量决定了回答质量所以示例本身要精挑细选最好是真实的、能覆盖边界情况的。第二思维链引导。针对复杂推理任务直接告诉模型先分析已知条件再列出解题步骤最后给出结论。这比让模型直接给答案准确率高很多。不过我不建议在简单任务上使用因为思维链会让模型话变多增加token消耗和延迟。第三格式约束要写得像模板示例而不仅是描述。与其写请以JSON格式输出不如写请输出一个JSON对象结构如下{name: , score: 0}。模型对具体结构的遵循能力远强于抽象描述。第四上下文管理。长对话里模型只记得窗口内的内容窗口外的早被遗忘了。所以处理较长的多轮交互时你需要自己对历史消息做摘要、裁剪或滑动窗口处理而不是指望模型都记得。这是很多人在实际业务中忽略掉的一个大坑。3. 浅层原理模型内部到底在做什么有了使用层的手感接下来该往下钻一层看看大语言模型工作的几个核心机制。我不打算堆公式尽量用大白话讲清楚那些关键为什么。3.1 token模型世界的字符一切文本进入模型之前都要先被切成小碎片这些碎片就是token。你可能会觉得分词而已有什么好研究的但这里面的门道直接影响模型的行为边界。常用的分词算法是字节对编码BPE。它的核心逻辑很朴素先在大量语料上统计所有字节对的出现频率然后反复把最高频的相邻字节对合并成一个新的词条。不断重复这个过程最终得到一套覆盖常见词汇、常见字符组合的词典。之后遇到新文本时就能按照这套词典把文本切成token序列。为什么不能直接按字符切因为模型需要学习的是词与词的组合规律用字符会让序列变得太长模型难以捕捉远距离依赖。为什么不能单纯按词切因为词汇量太大且生僻词、新词无法处理。BPE方案刚好折中常见词成为一个token生僻词被切成若干个较小的token每个token仍然有对应的嵌入向量可以参与计算。我在实际工作中发现理解分词方式有两个实际用处一是估算长度。中文场景下一个汉字大约对应1到1.5个token具体要看算法实现。做API调用时如果不想频繁踩max_tokens的坑按这个系数估算比较靠谱。二是理解模型的拼写能力。有些模型在处理英文拼写任务时会出错比如反转单词、计算单词里的字母数根本原因就是模型看到的不是字母序列而是token碎片序列。它压根看不到单词的完整拼写自然容易搞错。这不是模型笨而是它的输入表示方式决定的。3.2 注意力机制一种动态加权的查询过程Transformer的核心组件是自注意力机制。这个机制不复杂但确实不是直觉上能自然萌生的想法所以我用一个例子来拆解。想象你在读一段话那只猫追着老鼠跑它跳上了桌子。读到它的时候你脑子里自然知道它指代的是猫因为你把注意力放在了前文中猫这个位置上并且建立了关联。注意力机制做的就是这件事——让模型在处理某个位置的token时自动去回看序列里的其他位置计算它们与当前token的相关程度然后按照相关程度把信息加权汇总。相关程度高的位置贡献大相关程度低的位置贡献小。这个相关程度不靠人工指定而是在训练过程中学出来的。模型内部有三组可学习的矩阵从每个token的向量表示出发通过矩阵运算得到查询向量Q、键向量K和值向量V。查询和键做一个点积得到的就是注意力权重——可以理解成我该把多少注意力放到你身上。再用这个权重去加权值得到最终的上下文表示。这套机制带来一个关键能力并行计算与长距离依赖。过去基于循环神经网络的模型必须一个词一个词地顺序处理长距离信息容易衰减。注意力机制让任意两个token之间可以直接建立关联无论它们在序列中相距多远。这也是GPT系列模型能高效处理长文本的根本原因。多头注意力是另一个值得说一嘴的设计它不只用一组Q/K/V矩阵而是同时用多组每组可以专注于不同类型的相关性——有的头关注语法角色有的头关注指代关系有的头关注位置远近。最后把多组结果拼接融合。这相当于同时从多个维度分析了文本结构表达能力和泛化能力都更强。3.3 预训练海量文本里的自监督填空大语言模型的核心训练方式叫自监督预训练。原理听起来简单得不像真的给模型一段文本遮住其中一部分让模型预测被遮住的内容更标准地说是用前面所有token预测下一个token。由于互联网上可以获取海量文本这个预测下一个词的任务可以无限生成训练样本而无需人工标注。模型在数万亿token上反复做这件事被迫学会语言中的语法、事实、逻辑推理模式甚至一些跨领域的常识。你可能会问预测下一个词而已为什么能学会这么多能力因为词与词之间的关联里被压缩进了人类文明写作中蕴含的几乎所有规律。要准确预测一个词模型需要理解前文的句法约束、语义倾向、常识背景、甚至逻辑关系。模型被迫把所有这些信息编码进参数之中以便提高预测准确率。随着模型规模增大、训练数据增多这些能力逐渐从量变引发质变——一些复杂的推理能力在小模型上并不存在但在大模型上自发涌现。这个现象至今是学术研究的热点。但预训练有一个重大缺陷就是你得到的模型输出虽然在语法和知识上相当可靠但行为上不太听话——它可能想到什么说什么时而冒犯、时而偏题、时而生成有害内容。这就到了后面两阶段出场的时机。3.4 对齐让模型懂规矩预训练之后的模型像一个学识渊博但不通人情世故的怪才。要把它调教成好用的助手需要额外两轮第一轮是监督微调SFT。方法是人工撰写大量高质量的问题-答案对让模型在这些样本上继续训练。这一步教会模型当我被问到时我应该按照这种形式回答比如给出礼貌的开场、分点列出的回答结构、承认自己不知道等。样本质量直接决定模型的上限因此这个环节非常昂贵也占用大量人工。第二轮是基于人类反馈的强化学习RLHF。做法是让模型针对同一个提示词生成多个候选回答由标注员按与人类偏好的一致性排序然后用这些排序信号训练一个奖励模型最后通过强化学习让生成模型学会优化这个奖励。这一步的直观效果是模型逐渐学会拒绝不安全的请求、承认信息不足、避免长篇大论地胡编。对齐的意义远远超出让回答更好看。它对安全性和可用性的影响是根本性的。一个没有经过对齐的基座模型虽然知识量可能很丰富但你会明显感觉到它野——答非所问、说话没有边界感。这也是为什么在普通应用开发中我强烈建议你直接用提供商做好的对话模型而不是拿一个开源基座模型裸奔。除非你有人力和算力做对齐否则基座模型的野性会让你的产品体验灾难级。3.5 幻觉为什么模型会一本正经地胡说所谓幻觉是指模型生成的内容与事实不符、但与上下文风格高度一致。明白原理之后会发现这是生成式模型的结构性副产品而非简单bug。核心原因还是那句老话模型在预测下一个最可能的词而不是在检索事实。当问题超出训练数据的覆盖范围或者问题本身存在歧义模型没有足够证据收紧概率分布于是只能沿着语言上最连贯的路径编下去。由于词与词之间的衔接太流畅了产出的内容在局部看起来完全可信——这正是幻觉最棘手的地方。我还想指出一个容易被忽略的因素上下文污染。往往幻觉不是模型自己编的而是被你的输入带偏的。假设你在提示词里写了一句错误的事实作为背景模型极可能顺着这个错误继续展开。很多模型乱讲的case把上下文一查问题的根源是用户先把错误的预设喂了进去。所以实操层面的防幻觉手段核心不是告诉模型别撒谎这招几乎没用而是给足上下文把必要的参考材料直接塞进输入中让生成目标从凭记忆猜变成基于材料改写。要求引用出处让它把答案对应到输入资料里的具体段落。这一步会大大削弱编造空间。逻辑上的验证环节在业务关键链路中加入人工抽查或规则校验别让模型输出直接落到最终结果。4. 实操案例做一个会议纪要摘要工具理论讲得再多不动手都是纸上谈兵。我拿一个真实做过的场景来演示全流程给一个团队内部做一个会议纪要摘要工具。需求很简单——传入会议转写文本输出三部分内容会议主题、决策事项、待办清单。4.1 第一版直接问模型最早的版本肯定是最朴素的把转写文本直接拼进user prompt让模型输出三个板块。这样做的结果大家都能猜到格式不稳定有时给列表有时给段落有些内容隔三差五丢掉关键决策容易被淹没在背景描述里。这个阶段我判断下来不是模型能力问题而是提示质量太低。输入没有给出明确的阅读重点也没有对输出格式做可执行的约束。4.2 第二版结构化提示词改进思路分三步第一步拆清系统提示与用户提示。系统提示定义为你是会议纪要整理助手你的输出必须忠于输入文本禁止补充输入中不存在的信息。如果信息不足注明未提及。用户提示里先给出完整转写文本再用一个明确的任务块描述输出要求。第二步加入few-shot示例。我挑选了一条真实的会议记录片段手工整理出标准的JSON输出作为示例放进用户提示里。这一步的效果立竿见影格式稳定了几乎不再输出游离文本。第三步要求先抽取后总结。提示词里明确写先从转写中抽取所有明确的决定和待办事项再对整段内容概括主题全部内容必须来自所给文本。这相当于把一个复杂任务拆成两个子任务让模型分步处理准确性明显上升。4.3 参数配置温度设置到0.1。摘要与抽取任务容不下创造性发挥接近0的温度最合适。max_tokens按会议文本长度动态算会议文本大约8000个token输出目标预计600到800字max_tokens给1500留出充分余量。另外我把输出格式明确为JSON结构并启用调用的结构化输出能力不同的服务商叫法不同本质都是约束输出符合指定的JSON Schema。这里有个经验点结构化输出让模型在生成JSON时不再纠结空格、引号、嵌套格式对下游程序解析非常友好。如果你还在用解析模型输出时先找个大括号的土办法强烈建议试试这个功能能省掉一整套防御性代码。4.4 效果与量化这版方案跑通之后我们拿一个月内的50条真实会议转写作了测试统计结果令人满意格式合法率100%结构化输出的功劳关键决策抽取的召回率从第一版的约六成提升到九成以上人工复核后认为需要修改的内容从每篇七八处降到了一两处。成本上平均一次会议文本大约消耗1.1万个token输入1万、输出0.1万单次花费很便宜。当年链路全自动跑下来一个月成本大概只是请人做摘要费用的零头。这种花小钱办大事的效果是推动我把更多流程迁移到LLM上的最大动力。5. 常见问题与排查技巧实录做LLM应用最磨人的不是模型不聪明而是问题复现难、定位难。我把自己踩过的坑整理成了一份速查表供你查阅。现象大概率原因排查思路与解法输出突然被截断max_tokens设置过小查看输出结尾是否断在半截词调大max_tokens至预期长度1.5倍同样的输入两次结果差异巨大temperature调得偏高或服务端负载导致的采样变化把temperature降到0.2以下检查是否开启了随机种子功能模型经常说我不知道这题上下文长度超出窗口早期信息被裁剪检查实际输入token数与窗口上限用文本摘要替换原始早期消息明明给了正确资料回答却引用错误内容上下文污染或注意力分散把资料和问题分离明确告诉模型基于引用块内容回答必要时调整资料顺序输出格式时好时坏提示词只描述了格式没给出示例用few-shot给一个标准示例优先使用结构化输出能力中文长文本出现乱语无逻辑温度过高时中文生成弱点被放大温度降到0.4以下拆分长任务为多步子任务执行幻觉严重问题超出知识覆盖或提示词嵌入错误预设补充参考材料要求模型逐段引用输入来源关键输出走人审再分享几个常规文档里不会写的独家经验。第一别一上来就调温度。大多数问题出在提示词结构和上下文管理上温度是最后的手段。我见过很多新手把输出不稳定归咎于温度然后反复改改完之后问题依旧其实根源是few-shot示例太随性。第二注意API的流式输出与整体输出的区别。流式输出streaming对交互体验友好但下游如果想做格式化解析需要在拼接完整结果后再进入解析流程而不是边收边解析。我在最初做流式接入时吃过亏解析器总报错后来才发现是半截JSON没法用。第三做好成本与延迟的平衡。模型尺寸越大质量越好但延迟和单位成本直线上升。实际问题里未必需要最大最强的模型——像摘要、分类、信息抽取这类任务用中等规模模型完全足够。我通常的做法是先拿能力最强的模型试出提示词和输出的上限然后用较小模型复刻同样的方案对比质量掉点是否可接受。很多任务的质量掉点不超过5%但成本能降一个量级。第四要在长对话中主动遗忘。模型为了维持上下文一致性会自动处理很长的历史但它的注意力有限大量细节会让真正重要的信息淹没。处理长会话时与其塞完整历史不如定期用模型生成阶段性摘要然后用摘要替代原始历史。这是工程上压减上下文、降成本、提质量的通用招数。6. 写在最后我的一点实在感受从最开始只会对着网页对话框聊一聊到后来能在自己的系统里稳定地调用模型、调参、排障这个过程走下来我最大的体会是LLM的底层原理并没有想象中那么不可触碰但也不是看两篇文章就能完全玩转。真正有用的是一边使、一边拆、一边试的循环——用使用层的直觉去验证原理层的理解再用原理层的认知去指导使用层的调优。过了几个月再回头看我发现这套技能和学习方法本质上就是理解工具的内部脾气。每个模型都有它的性格和软肋调试的过程中不能只靠玄学更不能只看一两次的成功案例得靠系统性的变量控制与复盘。后面如果有机会我想再聊聊更复杂的话题比如模型微调的具体实践、如何从零训练一个小型模型做垂直任务、多模型协作框架的搭建。如果你有特别想了解的方向也欢迎在评论区和我说说。路还长慢慢走。
