这篇文章我构思了很久才动笔。写第一篇的时候，很多读者反馈说"终于有人把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_p=0.9，意味着先把按概率从高到低排列的词累加，累加到总概率90%为止，然后只从这个池子里采样。

我经常听人问temperature和top_p有什么区别。简单说，temperature改变的是所有候选词的"权重分布"，是全局操作；top_p是直接切掉概率分布里那根"长尾"，是个截断操作。官方文档通常会建议：不要同时大改两个参数，固定一个，调另一个。我的习惯是固定top_p=1（不启用），只用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应用最磨人的不是模型不聪明，而是问题复现难、定位难。我把自己踩过的坑整理成了一份速查表，供你查阅。

再分享几个常规文档里不会写的独家经验。

第一，别一上来就调温度。大多数问题出在提示词结构和上下文管理上，温度是最后的手段。我见过很多新手把输出不稳定归咎于温度，然后反复改，改完之后问题依旧，其实根源是few-shot示例太随性。

第二，注意API的流式输出与整体输出的区别。流式输出（streaming）对交互体验友好，但下游如果想做格式化解析，需要在拼接完整结果后再进入解析流程，而不是边收边解析。我在最初做流式接入时吃过亏，解析器总报错，后来才发现是半截JSON没法用。

第三，做好成本与延迟的平衡。模型尺寸越大，质量越好，但延迟和单位成本直线上升。实际问题里，未必需要最大最强的模型——像摘要、分类、信息抽取这类任务，用中等规模模型完全足够。我通常的做法是先拿能力最强的模型试出提示词和输出的"上限"，然后用较小模型复刻同样的方案，对比质量掉点是否可接受。很多任务的质量掉点不超过5%，但成本能降一个量级。

第四，要在长对话中"主动遗忘"。模型为了维持上下文一致性，会自动处理很长的历史，但它的注意力有限，大量细节会让真正重要的信息淹没。处理长会话时，与其塞完整历史，不如定期用模型生成阶段性摘要，然后用摘要替代原始历史。这是工程上压减上下文、降成本、提质量的通用招数。

6. 写在最后：我的一点实在感受

从最开始只会对着网页对话框"聊一聊"，到后来能在自己的系统里稳定地调用模型、调参、排障，这个过程走下来我最大的体会是：LLM的底层原理并没有想象中那么不可触碰，但也不是看两篇文章就能完全玩转。真正有用的是"一边使、一边拆、一边试"的循环——用使用层的直觉去验证原理层的理解，再用原理层的认知去指导使用层的调优。

过了几个月再回头看，我发现这套技能和学习方法，本质上就是"理解工具的内部脾气"。每个模型都有它的性格和软肋，调试的过程中不能只靠玄学，更不能只看一两次的成功案例，得靠系统性的变量控制与复盘。

后面如果有机会，我想再聊聊更复杂的话题，比如模型微调的具体实践、如何从零训练一个小型模型做垂直任务、多模型协作框架的搭建。如果你有特别想了解的方向，也欢迎在评论区和我说说。路还长，慢慢走。