开篇先亮个态度搞 LLM 应用的人如果只会在调用接口时改改 Top P不知道 Token 是怎么切出来的不理解上下文窗口为什么写着 200K 却还会“失忆”那项目一跑起来就会到处撞墙。我这两年接过不少本地部署和 Agent 相关的项目最深的体会是——几乎所有看起来“玄学”的生成问题追到底都能落在这三件事上Token 的切分方式、上下文的管理策略、采样参数的配合逻辑。这篇文章就把它们拆开揉碎结合我实测过的 case讲清楚每个环节背后的原理、常见坑以及可以直接照抄的调参和工程方案。1. TokenLLM 眼中的文字碎片1.1 先理解模型不认字只认 ID很多人第一次接触 LLM 时会有一个直觉误解模型是不是把我的中文句子当整体理解不是。所有主流 LLM 都是先把文本切分成一小块一小块的“片”再把每块映射成一个整数 ID最后把这些 ID 丢进神经网络里去计算。这个“片”就是 Token。举个例子说明。你输入“我爱编程”这四个字在不同的 Token 化方案下结果可能完全不同。比如用字节对编码BPE这类子词方案它可能把“我”“爱”“编”“程”分别切成 4 个 Token也可能把“编程”合成一个 Token甚至把“我爱”合成一个 Token取决于训练语料里这些字符共现的频率。模型不关心这些 Token 代表什么意义它只关心这批 ID 的序列规律。你输入的中文对它来说就是一堆形如[23, 145, 89, 1002]的数字数组。我见过不少做 RAG 的朋友为了控制成本在调用接口之前先用自己的工具给文本做字数统计然后根据中文字符数估算 Token 数结果一算一个不准。原因很简单Token 化器不是按“字”切的是按“训练时的统计规律”切的。不同模型甚至同一公司不同版本的模型Token 化器都可能不一样。所以严谨的做法是拿对应模型的 Tokenizer 做离线统计而不是自己拍脑袋。1.2 从字符到 Token 的完整流程抛开复杂算法Token 化的核心流程可以概括为三步。第一步是归一化。把全角空格转为半角、统一大小写英文场景、处理 Unicode 变体等。中文场景里这一点容易被忽略比如全角引号“”和半角引号“”如果预处理不到位会被切分成不同的 Token影响模型理解的稳定性。第二步是切分。主流方案有两种一种是全词切分比如早期模型会把pytorch当作一个整体 Token另一种是子词切分比如把pytorch切成py、tor、ch等多个 Token。目前绝大多数开源模型使用 BPE 或 Unigram 这类子词算法因为全词表太大无法覆盖所有词汇而子词既能控制词表规模又能保证任意新词都能被切分。第三步是映射。每个子词单元在词表里都有一个序号模型接收的输入就是这一串序号。注意这里会涉及“未登录词”问题——像中文里的专业术语、生僻人名、自造词可能被切得稀碎。比如“熵增定律”如果语料里没出现过Tokenizer 可能切成“熵”“增”“定律”每个字分别映射。这不一定是坏事因为单个字在词表里大概率存在只是表达效率低了消耗的 Token 数会上升。我还想强调一个被低估的细节Token 化器不只有切分功能它对标点、空格、换行的处理也影响巨大。比如英文里Hello world和Hello world两个空格在不少 Tokenizer 下会切成不同结果。这意味着你的应用在做数据清洗时随便规范化空格和换行都可能改变 Token 的统计特征进而影响生成质量。我自己的项目里凡是做文本预处理都会先跑一遍 Tokenizer 对比“清洗前 vs 清洗后”的切分结果确保没有意外破坏语义相关的片段。1.3 Token 数量直接决定你的调用成本商业 API 供应商的计费规则很简单输入 Token 数 × 单价 输出 Token 数 × 单价。所以搞清楚 Token 计数是控制成本的第一课。中文文本的 Token 消耗量通常比我们直觉要多因为单个汉字经常会被切成 1 到 2 个 Token取决于模型词表设计。比如 GPT 系列模型中常见估计是 1 个汉字约等于 1 到 1.5 个 Token英文大概是 1 个单词约等于 1.3 个 Token。整句下来500 字的中文可能消耗 600 到 750 个 Token。实际操作中我最常用的成本优化手段有三个第一离线统计。写一小段脚本用目标模型的 Tokenizer 把你的长文档全部切一遍得到精确的 Token 总数而不是靠字数推断。这样在批量调用前就能算清预算。第二缓存高频模板。很多 Agent 应用会把系统提示词写得很长而这些系统提示词在每轮对话里都会重新发送这是一种浪费。如果平台支持对话级缓存把不变的 System Prompt 放在请求头部能显著降低重复计费。第三控制检索片段。做 RAG 时一次检索出 8 个文档块每块 500 字看起来不多但算上重叠部分四个块可能就超过 2000 Token。更合理的做法是先做重排序把 Top 3 个最相关的块塞进上下文而不是把 Top 8 全部塞进去。我不是说 Token 越少越好——信息完整性永远是第一位。但搞清楚“我的文档到底会吃掉多少 Token”是每个 LLM 应用工程师都要养成的习惯。2. 上下文模型的记忆边界2.1 上下文窗口的本质与限制上下文窗口指的是模型在一次生成过程中能“看到”的 Token 范围。这既包含用户输入的 Prompt也包含模型输出的内容。比如窗口是 8000 Token你输入了 5000 Token那模型最多还能输出 3000 Token输出一旦触及这个上限就会截断或报错。为什么需要窗口两个原因一是计算复杂度。Transformer 的自注意力机制复杂度是 O(n²)序列长度翻倍计算量翻四倍。所以上下文越长推理成本越高延迟越大。二是内存限制。如果显存不足超长序列根本无法加载。这也是为什么本地部署时有人强行把 4K 上下文拉长到 8K速度会掉到没法用的原因之一。那为什么有些模型宣传 200K 上下文它们用的是稀疏注意力、滑动窗口注意力、FlashAttention 等优化手段让模型在“有限度的全局注意力”下处理长文本。但注意这是工程上的折中模型并没有对所有历史内容都保有同等强度的注意力。实测下来很多模型在中段位置的记忆相当模糊你问它开头提到的细节它可能胡编一个答案。这不是模型“笨”是注意力权重分布天然偏向开头和结尾中间内容很容易被稀释。2.2 头部效应和尾部效应我做过一个实验给一个 32K 窗口的模型喂一篇 20000 字的分析报告在三个不同位置埋入完全相同的事实陈述分别在开头、中间、结尾各放一条。然后让模型回答三个问题。结果是结尾那条记得最准开头那条次之中间那条回答错误率最高。这就是常说的头部效应和尾部效应。为什么自注意力层里每个 Token 都会和前面的 Token 计算信息关联位置靠后的 Token 在解码时天然能聚合更多信息。而位置靠前的 Token 拥有一个“位置优势”它作为起始部分在很多训练样本中是摘要或主题句所以模型也学会了对开头保持较高关注。中间的 Token 两头不靠容易成为“被忽略的信息带”。这对应用层有直接指导意义。如果你要做长文档问答最忌讳的就是直接把整个文档原封不动塞进 Prompt 让模型找答案。真正该做的是把关键内容通过检索或重排移到 Prompt 的开头段或结尾段把不太重要的中间段落删掉或合并。我自己在做合同审查的时候会把核心条款和风险点提取后放在 Prompt 末尾重新组织一遍准确率有明显提升。2.3 上下文管理的三种实操技巧第一按优先级排布 Prompt 内容。最前面放“任务描述 输出格式”最末尾放“待处理的强证据片段”中间放背景材料。如果背景材料过长宁可分段处理也不要一次性硬塞。第二利用摘要压缩历史。多轮对话场景里把前 N 轮的对话内容实时压缩成几条带时间戳的摘要放入下一轮请求。摘要本身可以由模型生成但要注意别让摘要生成过程引入幻觉。我习惯让摘要只保留叙事事实“用户提出要修改登录接口”“模型建议采用 OAuth2”不保留扩展解释减少失真风险。第三显式提示模型关注某个片段。虽然这招不是万能的但在很多模型上有实际效果。比如在文档结尾加一句“请特别注意上面第 3 条提到的限额条款回答时以该条款为准。”这相当于人为制造一个注意力锚点指引模型去查那个片段。还有一个很多人不知道的技巧输出长度也属于上下文的一部分。如果模型输出过长可能在写到一半时把窗口占满导致结尾部分缺失。所以我做长回答配置时会在 Prompt 里明确限制输出字数同时在请求参数里设定max_tokens二者都要覆盖缺一个都容易出问题。3. 采样参数控制模型输出的方向盘3.1 从概率分布说起模型每生成下一个 Token都会计算一个概率分布——所有候选 Token 各有一个得分。采样参数的作用就是决定我们如何从这个分布中挑选一个 Token 作为实际输出。如果没有采样每次都选概率最高的 Token那生成结果会非常“死板”重复度极高就像复读机。采样的根本目的是引入合理的随机性让输出更多变、更自然。理解这一点非常重要。很多人说“我调大 temperature 来增加创造力”这是对的但只看到了表面。temperature 改变的是概率分布的“锐利度”。温度越高分布越平缓低概率词被选中的机会变大温度越低分布越尖锐高概率词的优势被放大。当温度趋近 0 时就退化为贪心解码每次都选最大概率输出几乎确定。3.2 五个核心参数的详细拆解第一个是temperature。取值范围通常在 0 到 2部分模型支持更大范围。0 到 0.3 适合代码生成、数据抽取、判题等需要确定性的任务0.7 到 0.9 适合文案创作、头脑风暴、对话聊天1.0 以上就是高风险随机容易跑火车。我的经验是中文内容生成时温度设到 0.8 左右比较合适再多就容易被模型带偏开始说一些语法通顺但逻辑混乱的话。第二个是top_p也叫核采样。它做的事情是把候选 Token 按概率从高到低排序累加概率直到超过top_p这个阈值然后只在这个截断集合里做采样。比如top_p0.9意味着我们只考虑累计概率达到 90% 的那一小撮 Token剩余的长尾概率全部被丢弃。它的作用类似“范围钳制”防止模型突然选中一个概率极低但有风险的词。第三个是top_k。这个更简单粗暴只从概率排名前 K 个 Token 中采样。K50 就是每次只在前 50 个最高概率词里选。注意top_k和top_p是叠加生效的很多框架里两个都设等于先砍到前 K 个再按累计概率截断。我实测后的体感是top_p对结果风格影响更细腻top_k更适合在某些场景里强制排除“冷门输出”。第四个是repetition_penalty重复惩罚。它的实现是在计算概率时对已经出现过的 Token 施加一个惩罚系数降低它们再次出现的概率。当模型陷入“不断重复同一句话”的死循环时这个参数是最直接的解药。不过要注意惩罚系数不是越大越好我见过有人设到 1.5结果模型连正常的人称代词都拒绝输出因为“我”“你”早就出现过被惩罚得太厉害整段话变得别扭不堪。第五个是presence_penalty和frequency_penalty。这两个是 OpenAI 系 API 中的参数前者对“是否出现过”进行惩罚后者对“出现频率”进行惩罚。功能上和repetition_penalty类似但实现路数不同。presence_penalty可以鼓励讨论新话题frequency_penalty则抑制高频重复词。在实际项目中我很少同时打开这两个因为它们很容易打架让输出风格变得生硬。下面这张表是我在不同任务里常用的参数模板仅供参考不同模型特性不一样需要微调任务类型temperaturetop_ptop_krepetition_penalty代码生成 / 格式抽取0.1 - 0.30.9401.0常规问答 / 文档总结0.3 - 0.50.95501.05文案创作 / 头脑风暴0.7 - 0.90.92501.1多轮对话 / 角色扮演0.8 - 1.00.95601.1 - 1.23.3 参数协同的实战观察单独理解每个参数不难难的是它们协同工作。我举一个实际踩过的坑。某次做营销文案生成我把temperature拉到 1.2想让它写点有创意的东西结果模型开始输出一些语序混乱、关联词乱用的句子。我以为温度太高降回 0.8结果文案又变得平庸。后来我发现问题其实出在top_p——当时我把它设成了 0.8等于只在一小撮高概率词里挑即使温度升高可选的词也已经被钳制住了。改成temperature1.0、top_p0.95之后风格明显灵动了很多逻辑也还保持在主线范围内。另一个常见误区是盲目相信“temperature 越低 正确率越高”。在某些任务上比如数学推理、事实问答确实如此。但在开放生成任务中过低的温度会导致模型过度自信输出那些“概率高但未必正确”的常见套话。比如你问它一个模糊问题温度 0.2 时它很可能给你一个听起来很顺的答案那答案可能是从语料里高频拼凑出来的并不准确温度 0.8 时它有更多机会去思考低概率但更贴切的内容。所以做评测的时候不要只看单次输出要跑多次观察分布情况。还有一点和上下文联动如果你在 Prompt 末尾写了一句“请直接给出最可能的答案”模型内部相当于被引导到低温度区域。即使你的采样参数设得偏高它也可能因为提示词本身的压力走向保守。这就是为什么很多人觉得“怎么设参数都不灵”的原因——提示词里的隐性引导会覆盖采样参数的显性设置。解决思路是把规范、指令放在说话方式里把随机性控制交给参数。比如你要创意就明确写“请随意发挥不要拘泥于常见结论”同时把温度调高效果最稳定。4. 常见问题与排查实录4.1 输出重复、死循环怎么办这是本地部署模型时常碰到的问题自己跑一个 7B 模型不设置任何参数让它写一段故事它可能写到第三句就开始循环同一句话。原因有两层第一小模型的上下文能力本来就弱忘了前面说了什么只能不断用高概率词填充第二没有加任何重复惩罚模型理所当然地认为重复上次的输出是最“安全”的选择。解决办法有优先级。第一步检查上下文长度是否即将耗尽。如果你已经把 4K 窗口撑满模型会进入一种“强行收尾”的状态用重复内容来凑字数。这种场景下先削减 Prompt 长度或者改用更长窗口的模型比调任何参数都管用。第二步增大repetition_penalty从 1.1 开始往上试到 1.3 还压不住的话就要考虑模型本身太弱或者训练语料有问题。第三步尝试调低temperature到 0.6 左右。注意很多人以为调高温度能增加多样性从而破坏重复循环实际上高温会让模型更随意反而容易陷入一个“自嗨”的怪圈——先出现一个怪词然后又把它重复几遍。反而低温配合重复惩罚更容易打破循环。4.2 幻觉到底能不能消除答案非常清醒完全消除做不到只能缓解。幻觉的根本原因是模型在生成时不是在“查资料”而是在做概率预测。哪怕某些高概率预测不对只要它符合语料里的共现规律模型就敢说。针对幻觉我总结出三个实测有效的手段。第一在 Prompt 里强制加入“证据绑定”指令要求模型在回答时引用给定上下文的原文或者明确标注“如果上下文中没有相关信息请回答‘未找到’”。这能把一部分幻觉引导到“不编造”的方向上。第二降低temperature但别降到 0。降到 0 时模型容易被高频模板带偏反而会说出看似权威的废话。0.3 到 0.5 之间是个折中点。第三把大问题拆成带验证的小步骤。比如问“这个合同里第三方的违约金上限是多少”模型可能直接编一个数字。但如果你分成两步先让模型摘录所有与违约金相关的句子再让它从摘录的句子中提取数值后者出错率大幅下降。本质上是把生成问题简化成抽取问题。我还想强调一点有些幻觉其实来自 Token 切分导致的语义歧义。比如某个专业术语被切成多个 Token 后模型在重建含义时会受到上下文中其他高频词的干扰。排查这种问题时把出错的输入跑一遍 Tokenizer多看几个切分片段往往能找到异常点。4.3 参数调整避坑速查表很多人在开始调参时没头苍蝇一样乱试我根据实际项目经验整理了这份避坑清单可以直接抄。修改任何参数前先固定基线用默认参数跑多次记录输出质量和失败模式这样你才知道改参数到底修了什么。调参一次只改一个变量。同时改temperature和top_p出了问题你根本不知道是哪个参数导致的。注意框架默认值差异。不同推理框架如 vLLM、llama.cpp、Transformers 原生接口对采样参数的默认行为不完全一致尤其top_k和repetition_penalty是否默认开启差异很大。跨框架迁移配置时一定要显式设置所有参数而不是依赖默认值。采样参数和 API 请求体中的其他字段有耦合关系。比如设了max_tokens很小模型还没完成结构化表达就被截断表现就会像“胡言乱语”其实和采样参数无关。多个候选回复批量生成时种子seed不要设置成固定值。如果你在同一 Prompt 下做 A/B 测试固定 seed 可以保证变量只有你的参数但在正式应用里固定 seed 会丧失随机性让“创造性”任务失去意义。以下是我最近做评测时常用的问题排查表遇到异常输出直接对照着找原因现象大概率原因优先排查动作输出内容很短就停止max_tokens 不足或上下文窗口将满检查请求体和窗口统计输出充满重复句重复惩罚过低或上下文过长提高惩罚系数简化上下文输出错别字多、语法乱temperature 过高降到 0.7 以下再测输出过于教条化top_p 偏低适当提高 top_p 至 0.95同一个问题答案每次波动巨大采样概率偏高 提示词约束不够降低温度强化格式指令长文本后段内容质量暴跌上下文位置效应对关键片段做重排或摘要重写最后再分享一个小技巧。无论你是做 Agent 还是做内容生成我都会建议你在对话日志里同时记录当时的采样参数、上下文 Token 数量以及模型输出全文。这个习惯让我在反查线上问题时省了大量时间。人往往会高估自己对模型的直觉但历史数据不会骗人。当新一次改动出了问题翻一眼上次成功时的完整配置问题通常立刻就清楚了。我个人在实际操作中的体会是Token、上下文、采样参数这三者从来不是独立变量。你加的每个 Token 都会占用上下文空间进而影响采样概率的分布你调的每个采样参数又会影响模型如何利用有限的上下文信息。真正成熟的 LLM 应用是把这三者放在同一个设计框架里通盘考虑的。下次再遇到生成效果不如预期别急着怪模型笨先检查这三个环节里是哪个石头把水堵住了。
开篇先亮个态度搞 LLM 应用的人如果只会在调用接口时改改 Top P不知道 Token 是怎么切出来的不理解上下文窗口为什么写着 200K 却还会“失忆”那项目一跑起来就会到处撞墙。我这两年接过不少本地部署和 Agent 相关的项目最深的体会是——几乎所有看起来“玄学”的生成问题追到底都能落在这三件事上Token 的切分方式、上下文的管理策略、采样参数的配合逻辑。这篇文章就把它们拆开揉碎结合我实测过的 case讲清楚每个环节背后的原理、常见坑以及可以直接照抄的调参和工程方案。1. TokenLLM 眼中的文字碎片1.1 先理解模型不认字只认 ID很多人第一次接触 LLM 时会有一个直觉误解模型是不是把我的中文句子当整体理解不是。所有主流 LLM 都是先把文本切分成一小块一小块的“片”再把每块映射成一个整数 ID最后把这些 ID 丢进神经网络里去计算。这个“片”就是 Token。举个例子说明。你输入“我爱编程”这四个字在不同的 Token 化方案下结果可能完全不同。比如用字节对编码BPE这类子词方案它可能把“我”“爱”“编”“程”分别切成 4 个 Token也可能把“编程”合成一个 Token甚至把“我爱”合成一个 Token取决于训练语料里这些字符共现的频率。模型不关心这些 Token 代表什么意义它只关心这批 ID 的序列规律。你输入的中文对它来说就是一堆形如[23, 145, 89, 1002]的数字数组。我见过不少做 RAG 的朋友为了控制成本在调用接口之前先用自己的工具给文本做字数统计然后根据中文字符数估算 Token 数结果一算一个不准。原因很简单Token 化器不是按“字”切的是按“训练时的统计规律”切的。不同模型甚至同一公司不同版本的模型Token 化器都可能不一样。所以严谨的做法是拿对应模型的 Tokenizer 做离线统计而不是自己拍脑袋。1.2 从字符到 Token 的完整流程抛开复杂算法Token 化的核心流程可以概括为三步。第一步是归一化。把全角空格转为半角、统一大小写英文场景、处理 Unicode 变体等。中文场景里这一点容易被忽略比如全角引号“”和半角引号“”如果预处理不到位会被切分成不同的 Token影响模型理解的稳定性。第二步是切分。主流方案有两种一种是全词切分比如早期模型会把pytorch当作一个整体 Token另一种是子词切分比如把pytorch切成py、tor、ch等多个 Token。目前绝大多数开源模型使用 BPE 或 Unigram 这类子词算法因为全词表太大无法覆盖所有词汇而子词既能控制词表规模又能保证任意新词都能被切分。第三步是映射。每个子词单元在词表里都有一个序号模型接收的输入就是这一串序号。注意这里会涉及“未登录词”问题——像中文里的专业术语、生僻人名、自造词可能被切得稀碎。比如“熵增定律”如果语料里没出现过Tokenizer 可能切成“熵”“增”“定律”每个字分别映射。这不一定是坏事因为单个字在词表里大概率存在只是表达效率低了消耗的 Token 数会上升。我还想强调一个被低估的细节Token 化器不只有切分功能它对标点、空格、换行的处理也影响巨大。比如英文里Hello world和Hello world两个空格在不少 Tokenizer 下会切成不同结果。这意味着你的应用在做数据清洗时随便规范化空格和换行都可能改变 Token 的统计特征进而影响生成质量。我自己的项目里凡是做文本预处理都会先跑一遍 Tokenizer 对比“清洗前 vs 清洗后”的切分结果确保没有意外破坏语义相关的片段。1.3 Token 数量直接决定你的调用成本商业 API 供应商的计费规则很简单输入 Token 数 × 单价 输出 Token 数 × 单价。所以搞清楚 Token 计数是控制成本的第一课。中文文本的 Token 消耗量通常比我们直觉要多因为单个汉字经常会被切成 1 到 2 个 Token取决于模型词表设计。比如 GPT 系列模型中常见估计是 1 个汉字约等于 1 到 1.5 个 Token英文大概是 1 个单词约等于 1.3 个 Token。整句下来500 字的中文可能消耗 600 到 750 个 Token。实际操作中我最常用的成本优化手段有三个第一离线统计。写一小段脚本用目标模型的 Tokenizer 把你的长文档全部切一遍得到精确的 Token 总数而不是靠字数推断。这样在批量调用前就能算清预算。第二缓存高频模板。很多 Agent 应用会把系统提示词写得很长而这些系统提示词在每轮对话里都会重新发送这是一种浪费。如果平台支持对话级缓存把不变的 System Prompt 放在请求头部能显著降低重复计费。第三控制检索片段。做 RAG 时一次检索出 8 个文档块每块 500 字看起来不多但算上重叠部分四个块可能就超过 2000 Token。更合理的做法是先做重排序把 Top 3 个最相关的块塞进上下文而不是把 Top 8 全部塞进去。我不是说 Token 越少越好——信息完整性永远是第一位。但搞清楚“我的文档到底会吃掉多少 Token”是每个 LLM 应用工程师都要养成的习惯。2. 上下文模型的记忆边界2.1 上下文窗口的本质与限制上下文窗口指的是模型在一次生成过程中能“看到”的 Token 范围。这既包含用户输入的 Prompt也包含模型输出的内容。比如窗口是 8000 Token你输入了 5000 Token那模型最多还能输出 3000 Token输出一旦触及这个上限就会截断或报错。为什么需要窗口两个原因一是计算复杂度。Transformer 的自注意力机制复杂度是 O(n²)序列长度翻倍计算量翻四倍。所以上下文越长推理成本越高延迟越大。二是内存限制。如果显存不足超长序列根本无法加载。这也是为什么本地部署时有人强行把 4K 上下文拉长到 8K速度会掉到没法用的原因之一。那为什么有些模型宣传 200K 上下文它们用的是稀疏注意力、滑动窗口注意力、FlashAttention 等优化手段让模型在“有限度的全局注意力”下处理长文本。但注意这是工程上的折中模型并没有对所有历史内容都保有同等强度的注意力。实测下来很多模型在中段位置的记忆相当模糊你问它开头提到的细节它可能胡编一个答案。这不是模型“笨”是注意力权重分布天然偏向开头和结尾中间内容很容易被稀释。2.2 头部效应和尾部效应我做过一个实验给一个 32K 窗口的模型喂一篇 20000 字的分析报告在三个不同位置埋入完全相同的事实陈述分别在开头、中间、结尾各放一条。然后让模型回答三个问题。结果是结尾那条记得最准开头那条次之中间那条回答错误率最高。这就是常说的头部效应和尾部效应。为什么自注意力层里每个 Token 都会和前面的 Token 计算信息关联位置靠后的 Token 在解码时天然能聚合更多信息。而位置靠前的 Token 拥有一个“位置优势”它作为起始部分在很多训练样本中是摘要或主题句所以模型也学会了对开头保持较高关注。中间的 Token 两头不靠容易成为“被忽略的信息带”。这对应用层有直接指导意义。如果你要做长文档问答最忌讳的就是直接把整个文档原封不动塞进 Prompt 让模型找答案。真正该做的是把关键内容通过检索或重排移到 Prompt 的开头段或结尾段把不太重要的中间段落删掉或合并。我自己在做合同审查的时候会把核心条款和风险点提取后放在 Prompt 末尾重新组织一遍准确率有明显提升。2.3 上下文管理的三种实操技巧第一按优先级排布 Prompt 内容。最前面放“任务描述 输出格式”最末尾放“待处理的强证据片段”中间放背景材料。如果背景材料过长宁可分段处理也不要一次性硬塞。第二利用摘要压缩历史。多轮对话场景里把前 N 轮的对话内容实时压缩成几条带时间戳的摘要放入下一轮请求。摘要本身可以由模型生成但要注意别让摘要生成过程引入幻觉。我习惯让摘要只保留叙事事实“用户提出要修改登录接口”“模型建议采用 OAuth2”不保留扩展解释减少失真风险。第三显式提示模型关注某个片段。虽然这招不是万能的但在很多模型上有实际效果。比如在文档结尾加一句“请特别注意上面第 3 条提到的限额条款回答时以该条款为准。”这相当于人为制造一个注意力锚点指引模型去查那个片段。还有一个很多人不知道的技巧输出长度也属于上下文的一部分。如果模型输出过长可能在写到一半时把窗口占满导致结尾部分缺失。所以我做长回答配置时会在 Prompt 里明确限制输出字数同时在请求参数里设定max_tokens二者都要覆盖缺一个都容易出问题。3. 采样参数控制模型输出的方向盘3.1 从概率分布说起模型每生成下一个 Token都会计算一个概率分布——所有候选 Token 各有一个得分。采样参数的作用就是决定我们如何从这个分布中挑选一个 Token 作为实际输出。如果没有采样每次都选概率最高的 Token那生成结果会非常“死板”重复度极高就像复读机。采样的根本目的是引入合理的随机性让输出更多变、更自然。理解这一点非常重要。很多人说“我调大 temperature 来增加创造力”这是对的但只看到了表面。temperature 改变的是概率分布的“锐利度”。温度越高分布越平缓低概率词被选中的机会变大温度越低分布越尖锐高概率词的优势被放大。当温度趋近 0 时就退化为贪心解码每次都选最大概率输出几乎确定。3.2 五个核心参数的详细拆解第一个是temperature。取值范围通常在 0 到 2部分模型支持更大范围。0 到 0.3 适合代码生成、数据抽取、判题等需要确定性的任务0.7 到 0.9 适合文案创作、头脑风暴、对话聊天1.0 以上就是高风险随机容易跑火车。我的经验是中文内容生成时温度设到 0.8 左右比较合适再多就容易被模型带偏开始说一些语法通顺但逻辑混乱的话。第二个是top_p也叫核采样。它做的事情是把候选 Token 按概率从高到低排序累加概率直到超过top_p这个阈值然后只在这个截断集合里做采样。比如top_p0.9意味着我们只考虑累计概率达到 90% 的那一小撮 Token剩余的长尾概率全部被丢弃。它的作用类似“范围钳制”防止模型突然选中一个概率极低但有风险的词。第三个是top_k。这个更简单粗暴只从概率排名前 K 个 Token 中采样。K50 就是每次只在前 50 个最高概率词里选。注意top_k和top_p是叠加生效的很多框架里两个都设等于先砍到前 K 个再按累计概率截断。我实测后的体感是top_p对结果风格影响更细腻top_k更适合在某些场景里强制排除“冷门输出”。第四个是repetition_penalty重复惩罚。它的实现是在计算概率时对已经出现过的 Token 施加一个惩罚系数降低它们再次出现的概率。当模型陷入“不断重复同一句话”的死循环时这个参数是最直接的解药。不过要注意惩罚系数不是越大越好我见过有人设到 1.5结果模型连正常的人称代词都拒绝输出因为“我”“你”早就出现过被惩罚得太厉害整段话变得别扭不堪。第五个是presence_penalty和frequency_penalty。这两个是 OpenAI 系 API 中的参数前者对“是否出现过”进行惩罚后者对“出现频率”进行惩罚。功能上和repetition_penalty类似但实现路数不同。presence_penalty可以鼓励讨论新话题frequency_penalty则抑制高频重复词。在实际项目中我很少同时打开这两个因为它们很容易打架让输出风格变得生硬。下面这张表是我在不同任务里常用的参数模板仅供参考不同模型特性不一样需要微调任务类型temperaturetop_ptop_krepetition_penalty代码生成 / 格式抽取0.1 - 0.30.9401.0常规问答 / 文档总结0.3 - 0.50.95501.05文案创作 / 头脑风暴0.7 - 0.90.92501.1多轮对话 / 角色扮演0.8 - 1.00.95601.1 - 1.23.3 参数协同的实战观察单独理解每个参数不难难的是它们协同工作。我举一个实际踩过的坑。某次做营销文案生成我把temperature拉到 1.2想让它写点有创意的东西结果模型开始输出一些语序混乱、关联词乱用的句子。我以为温度太高降回 0.8结果文案又变得平庸。后来我发现问题其实出在top_p——当时我把它设成了 0.8等于只在一小撮高概率词里挑即使温度升高可选的词也已经被钳制住了。改成temperature1.0、top_p0.95之后风格明显灵动了很多逻辑也还保持在主线范围内。另一个常见误区是盲目相信“temperature 越低 正确率越高”。在某些任务上比如数学推理、事实问答确实如此。但在开放生成任务中过低的温度会导致模型过度自信输出那些“概率高但未必正确”的常见套话。比如你问它一个模糊问题温度 0.2 时它很可能给你一个听起来很顺的答案那答案可能是从语料里高频拼凑出来的并不准确温度 0.8 时它有更多机会去思考低概率但更贴切的内容。所以做评测的时候不要只看单次输出要跑多次观察分布情况。还有一点和上下文联动如果你在 Prompt 末尾写了一句“请直接给出最可能的答案”模型内部相当于被引导到低温度区域。即使你的采样参数设得偏高它也可能因为提示词本身的压力走向保守。这就是为什么很多人觉得“怎么设参数都不灵”的原因——提示词里的隐性引导会覆盖采样参数的显性设置。解决思路是把规范、指令放在说话方式里把随机性控制交给参数。比如你要创意就明确写“请随意发挥不要拘泥于常见结论”同时把温度调高效果最稳定。4. 常见问题与排查实录4.1 输出重复、死循环怎么办这是本地部署模型时常碰到的问题自己跑一个 7B 模型不设置任何参数让它写一段故事它可能写到第三句就开始循环同一句话。原因有两层第一小模型的上下文能力本来就弱忘了前面说了什么只能不断用高概率词填充第二没有加任何重复惩罚模型理所当然地认为重复上次的输出是最“安全”的选择。解决办法有优先级。第一步检查上下文长度是否即将耗尽。如果你已经把 4K 窗口撑满模型会进入一种“强行收尾”的状态用重复内容来凑字数。这种场景下先削减 Prompt 长度或者改用更长窗口的模型比调任何参数都管用。第二步增大repetition_penalty从 1.1 开始往上试到 1.3 还压不住的话就要考虑模型本身太弱或者训练语料有问题。第三步尝试调低temperature到 0.6 左右。注意很多人以为调高温度能增加多样性从而破坏重复循环实际上高温会让模型更随意反而容易陷入一个“自嗨”的怪圈——先出现一个怪词然后又把它重复几遍。反而低温配合重复惩罚更容易打破循环。4.2 幻觉到底能不能消除答案非常清醒完全消除做不到只能缓解。幻觉的根本原因是模型在生成时不是在“查资料”而是在做概率预测。哪怕某些高概率预测不对只要它符合语料里的共现规律模型就敢说。针对幻觉我总结出三个实测有效的手段。第一在 Prompt 里强制加入“证据绑定”指令要求模型在回答时引用给定上下文的原文或者明确标注“如果上下文中没有相关信息请回答‘未找到’”。这能把一部分幻觉引导到“不编造”的方向上。第二降低temperature但别降到 0。降到 0 时模型容易被高频模板带偏反而会说出看似权威的废话。0.3 到 0.5 之间是个折中点。第三把大问题拆成带验证的小步骤。比如问“这个合同里第三方的违约金上限是多少”模型可能直接编一个数字。但如果你分成两步先让模型摘录所有与违约金相关的句子再让它从摘录的句子中提取数值后者出错率大幅下降。本质上是把生成问题简化成抽取问题。我还想强调一点有些幻觉其实来自 Token 切分导致的语义歧义。比如某个专业术语被切成多个 Token 后模型在重建含义时会受到上下文中其他高频词的干扰。排查这种问题时把出错的输入跑一遍 Tokenizer多看几个切分片段往往能找到异常点。4.3 参数调整避坑速查表很多人在开始调参时没头苍蝇一样乱试我根据实际项目经验整理了这份避坑清单可以直接抄。修改任何参数前先固定基线用默认参数跑多次记录输出质量和失败模式这样你才知道改参数到底修了什么。调参一次只改一个变量。同时改temperature和top_p出了问题你根本不知道是哪个参数导致的。注意框架默认值差异。不同推理框架如 vLLM、llama.cpp、Transformers 原生接口对采样参数的默认行为不完全一致尤其top_k和repetition_penalty是否默认开启差异很大。跨框架迁移配置时一定要显式设置所有参数而不是依赖默认值。采样参数和 API 请求体中的其他字段有耦合关系。比如设了max_tokens很小模型还没完成结构化表达就被截断表现就会像“胡言乱语”其实和采样参数无关。多个候选回复批量生成时种子seed不要设置成固定值。如果你在同一 Prompt 下做 A/B 测试固定 seed 可以保证变量只有你的参数但在正式应用里固定 seed 会丧失随机性让“创造性”任务失去意义。以下是我最近做评测时常用的问题排查表遇到异常输出直接对照着找原因现象大概率原因优先排查动作输出内容很短就停止max_tokens 不足或上下文窗口将满检查请求体和窗口统计输出充满重复句重复惩罚过低或上下文过长提高惩罚系数简化上下文输出错别字多、语法乱temperature 过高降到 0.7 以下再测输出过于教条化top_p 偏低适当提高 top_p 至 0.95同一个问题答案每次波动巨大采样概率偏高 提示词约束不够降低温度强化格式指令长文本后段内容质量暴跌上下文位置效应对关键片段做重排或摘要重写最后再分享一个小技巧。无论你是做 Agent 还是做内容生成我都会建议你在对话日志里同时记录当时的采样参数、上下文 Token 数量以及模型输出全文。这个习惯让我在反查线上问题时省了大量时间。人往往会高估自己对模型的直觉但历史数据不会骗人。当新一次改动出了问题翻一眼上次成功时的完整配置问题通常立刻就清楚了。我个人在实际操作中的体会是Token、上下文、采样参数这三者从来不是独立变量。你加的每个 Token 都会占用上下文空间进而影响采样概率的分布你调的每个采样参数又会影响模型如何利用有限的上下文信息。真正成熟的 LLM 应用是把这三者放在同一个设计框架里通盘考虑的。下次再遇到生成效果不如预期别急着怪模型笨先检查这三个环节里是哪个石头把水堵住了。
平方复杂度无法被常规优化消除｜TaoToken 统一 Key 通道实测)
