第一卷大模型 基础篇第3章 模型能力认知第4节为什么同一个问题AI每次回答都不一样——大模型的随机性、Temperature与采样机制引言你有没有遇到过这样的情况第一次问AI请推荐一个适合初学者学习的编程语言。AI回答Python。 它语法简单、生态丰富非常适合初学者。你什么都没改再问一次请推荐一个适合初学者学习的编程语言。它可能回答JavaScript。 它可以直接在浏览器运行而且能够覆盖前端和后端开发。再问一次Go。 它语法简洁非常适合学习现代后端开发。同一个问题、同一个模型、甚至完全一样的Prompt为什么答案却不一样很多开发者第一次接触大模型时会产生一个疑问AI到底是不是在“随机回答”答案是某种意义上是的。但如果简单理解成“AI随机选择一个答案”又是不准确的。真正发生的事情更加有意思用户Prompt ↓ Transformer ↓ 计算下一个Token的概率 ↓ 形成概率分布 ↓ Temperature调整概率分布 ↓ Sampling采样 ↓ 得到下一个Token ↓ 继续预测下一个Token ↓ …… ↓ 生成完整回答因此大模型不是从一个固定答案库里取答案而是在每一步根据概率分布生成下一个Token。而这正是理解Temperature Sampling Top-K Top-P 模型随机性 Agent稳定性的基础。更重要的是对于Agent开发工程师来说这不仅仅是一个模型参数问题。它直接影响Agent是否稳定 Tool是否正确调用 Workflow是否可控 RAG回答是否一致 Agent是否容易测试 企业系统是否敢于上线所以本节我们不仅要理解为什么AI每次回答不一样还要进一步理解如何在“随机性”和“确定性”之间找到工程上的平衡一、先理解一个最根本的问题LLM不是传统程序如果你是一名传统软件开发工程师对下面的代码应该非常熟悉def add(a, b): return a b调用add(1, 2)得到3再调用100次3 3 3 3 ……只要输入相同 程序相同 运行环境没有变化通常就会得到相同结果。这是一种典型的确定性计算Deterministic Computing也就是Input ↓ Function ↓ Output但是大语言模型不是这样工作的。例如用户 请写一句关于春天的句子。模型并不是简单地查询数据库 ↓ 找到一句标准答案 ↓ 返回它更接近Prompt ↓ Transformer ↓ 计算Token概率 ↓ 选择一个Token ↓ 加入上下文 ↓ 再次计算Token概率 ↓ 再次选择 ↓ …… ↓ 生成完整回答也就是说LLM的核心任务并不是直接找到“答案”而是不断预测“下一个Token最可能是什么”。这就是Next Token Prediction二、大模型究竟在预测什么假设我们输入今天天气模型需要预测下一个Token。它可能得到类似这样的概率分布很好 42% 不错 25% 晴朗 15% 很冷 8% 如何 3% ……这里最重要的不是具体数字而是理解模型得到的不是一个答案而是一组概率。也就是说模型内部更接近Token A → 42% Token B → 25% Token C → 15% Token D → 8% ……而不是答案 Token A这意味着模型已经知道“最可能出现什么”但还需要决定“这一次到底选择什么”。这个过程就是Sampling——采样。三、为什么一个Token的变化会导致整段回答发生变化这是理解大模型随机性的关键。假设模型生成今天天气下一步可能选择很好于是今天天气很好接下来模型继续预测。可能生成今天天气很好适合出去散步。但如果这一次选择的是不错那么上下文已经变成今天天气不错后面的概率分布也会随之改变。于是可能继续生成今天天气不错适合进行户外活动。如果一开始选择阴沉后面的回答又可能变成今天天气阴沉可能会下雨出门最好带把伞。于是Token 1 ↓ 改变Context ↓ 影响Token 2概率 ↓ 影响Token 3概率 ↓ …… ↓ 最终影响整个回答这就是一个非常重要的概念大模型生成具有路径依赖。早期一个Token的差异有可能被不断放大最终形成完全不同的回答。四、如果每次都选择概率最高的Token会怎么样假设模型得到Python 45% Java 20% Go 15% Rust 10% JavaScript 7% 其他 3%最简单的做法是永远选择概率最高的Token。也就是选择Python下一步继续计算。然后继续选择概率最高的Token不断重复。这种方式叫Greedy Decoding——贪心解码。流程可以理解为Prompt ↓ 最高概率Token ↓ 最高概率Token ↓ 最高概率Token ↓ 最高概率Token ↓ ……它最大的优点是稳定。但是它也有一个问题可能过于保守。五、为什么AI不能永远只选择第一名假设让AI写一句关于秋天的句子。如果每次都选择概率最高的Token很容易得到类似秋天来了树叶变黄了天气渐渐变凉。这当然没错。但是如果每次都这样秋天来了…… 树叶变黄…… 天气变凉……AI的输出就容易机械 重复 缺乏变化 缺乏创造性而大模型最有价值的能力之一恰恰是生成具有多样性的内容。所以实际生成时并不一定每次都选择第一名。而是按照概率分布进行采样。六、SamplingAI不是“随便选”而是“按概率选”还是刚才的例子Python 45% Java 20% Go 15% Rust 10% JavaScript 7% 其他 3%如果采用概率采样那么Python最容易被选中。但Java Go Rust也存在被选择的可能。这就是Sampling。非常重要的一点是Sampling不是完全随机。它不是Python 20% Java 20% Go 20% Rust 20% ……而是概率高 → 更容易被选择 概率低 → 更难被选择所以模型概率 采样策略 最终Token七、Temperature到底是什么理解Sampling以后就可以理解Temperature了。Temperature通常翻译成温度参数。它并不是Temperature高 → 模型更聪明 Temperature低 → 模型更笨这种理解是错误的。更加准确的理解是Temperature控制概率分布的“尖锐程度”从而影响模型探索不同Token的程度。简单理解低Temperature ↓ 更集中 ↓ 更保守 ↓ 更稳定 高Temperature ↓ 更分散 ↓ 更开放 ↓ 更多样八、Temperature低的时候发生了什么假设原始概率A60% B25% C10% D5%当Temperature较低时A ████████████████████ B ██ C D概率会更加集中。于是A几乎总是占据绝对优势。结果就是输出更加稳定九、Temperature高的时候发生了什么提高Temperature以后概率分布会变得更加平坦。例如可以直观理解成A40% B30% C18% D12%这时候A B C D都有更大的机会被采样。于是输出更多样 表达更加丰富 创造性更强但与此同时错误概率 不确定性 不可重复性也可能增加。所以Temperature本质上是在稳定性和探索性之间调节。十、Temperature背后的数学原理如果只是做AI应用开发可以先把Temperature理解成控制随机程度但是作为Agent开发工程师最好进一步理解它背后的数学机制。模型经过Transformer以后会得到一组Logits假设A 5.2 B 4.1 C 3.8 D 2.5然后经过Softmax转换成概率。简化表示P(i) softmax(logit_i / T)其中T Temperature当T 1概率分布更加尖锐。当T 1保持原始概率分布。当T 1概率分布更加平坦。因此Logits ↓ Temperature ↓ Softmax ↓ Probability Distribution ↓ Sampling ↓ Next Token这就是Temperature最核心的技术机制。十一、Temperature不是“随机开关”这是一个非常重要的认知纠正。很多开发者会简单理解Temperature 0 → 没有随机性 Temperature 1 → 有随机性 Temperature 2 → 随机性更强虽然这个理解适合入门但从技术上并不严谨。更加准确的是Temperature ↓ 改变概率分布 ↓ Sampling ↓ 产生不同Token也就是说Temperature负责改变“概率长什么样”Sampling负责“从概率里选什么”。十二、Top-K限制候选Token数量除了Temperature还有一个常见采样机制Top-K Sampling假设模型得到A35% B25% C15% D10% E5% F4% G3% H3%如果K 3那么只保留A B C其他Token直接排除D ❌ E ❌ F ❌ G ❌ H ❌于是概率分布 ↓ Top-K ↓ 候选Token缩小 ↓ Sampling十三、Top-P动态限制候选Token范围Top-P又叫Nucleus Sampling它与Top-K不同。Top-K是固定保留K个Top-P则是按照概率从高到低累加直到达到P。例如A40% B30% C15% D8% E4% F3%如果Top-P 0.85那么A 40% A B 70% A B C 85%于是保留A B C后面的D E F不参与采样。十四、Temperature、Top-K、Top-P到底有什么区别可以把三者理解成三个不同层面的控制机制参数核心作用直观理解Temperature调整概率分布控制探索程度Top-K固定候选数量只看前K名Top-P动态候选范围看累计概率达到P的候选Greedy只选第一名最大确定性简单记忆Temperature ↓ 改变概率分布 Top-K ↓ 限制候选数量 Top-P ↓ 限制候选概率范围 Sampling ↓ 最终选择Token十五、为什么Temperature 0也不一定意味着绝对一致这是开发Agent时经常遇到的问题。很多开发者会认为temperature 0就意味着每次调用必须100%得到完全相同的结果。实际上不能简单这么认为。原因很多。原因一底层计算可能存在非确定性现代大模型运行在大规模GPU集群上。涉及并行计算 浮点数计算 GPU Kernel 分布式推理在某些实现下底层计算可能存在微小差异。原因二模型服务实现不同不同模型平台对于Temperature 0的处理方式可能不同。有的平台可能更接近Greedy有的平台可能仍然保留某些采样机制。因此不能把Temperature 0简单理解成绝对确定性。原因三Context可能已经发生变化开发者经常认为我发送的是同一个问题。但是实际上模型收到的可能是System Prompt 历史对话 用户问题 RAG Context Tool Result Memory其中任何一个Token变化都可能影响最终输出。所以用户看到的Prompt一样 ≠ 模型收到的完整Context一样原因四模型服务版本可能发生变化即使Prompt一样 Temperature一样如果模型版本 推理框架 服务实现 System Prompt发生变化也可能导致输出变化。所以企业级AI系统需要关注Model Version而不是只记录model xxx十六、真正决定AI输出的不只是Temperature现在可以建立一个更加完整的公式最终输出 ≈ Model System Prompt User Prompt Context Sampling Parameters Tool Results Model Version Runtime Environment因此“同一个问题”并不等于“同一个模型输入状态”。这也是为什么后面学习Context Memory RAG State Tool Calling Agent时会不断遇到状态管理问题。十七、这个问题为什么对Agent尤其重要普通聊天机器人可能只是用户 ↓ LLM ↓ 回答但Agent不是。Agent可能是用户 ↓ Agent ↓ LLM ↓ Planning ↓ Tool Calling ↓ Tool Result ↓ Context Update ↓ LLM ↓ 下一步决策 ↓ Tool Calling ↓ …… ↓ 最终答案这里每一步都可能存在概率决策。例如应该调用哪个Tool ↓ Tool A / Tool B / Tool C 应该查询什么参数 ↓ 参数A / 参数B 查询结果出来以后怎么办 ↓ 继续调用 / 结束 / 重新规划所以Agent的非确定性远比普通LLM聊天复杂。十八、Agent随机性可能导致什么问题举一个企业真实业务场景。假设你开发了一个企业销售数据分析Agent用户问帮我分析一下今年华东地区的销售情况。Agent可能需要理解问题 ↓ 识别地区 华东 ↓ 识别时间 今年 ↓ 调用销售数据库 ↓ 查询数据 ↓ 计算同比 ↓ 分析异常 ↓ 生成报告如果模型的决策不稳定第一次调用SalesQuery第二次调用CustomerQuery第三次调用OrderQuery甚至可能先查客户 → 再查订单 → 再查销售结果可能是执行路径不同 ↓ Tool调用次数不同 ↓ 成本不同 ↓ 执行时间不同 ↓ 最终结果可能不同这就是Agent工程中非常典型的Non-Determinism——非确定性。十九、Agent工程不是消灭随机性而是控制随机性这是本节最重要的工程思想之一。很多初学者第一反应是“那就把Temperature调成0。”这并不是完整答案。因为Agent真正的问题不是随机性 坏事而是随机性 应该出现在哪里 应该有多大 哪些地方必须确定 哪些地方可以探索例如聊天 ↓ 可以有随机性 内容创作 ↓ 可以有更多随机性 RAG问答 ↓ 应该适当降低 SQL生成 ↓ 应该高度约束 数据库写操作 ↓ 必须验证 支付 ↓ 必须确定所以成熟的Agent系统不是消灭随机性。而是把随机性控制在合适的边界内。二十、不同任务应该如何使用Temperature没有一个适用于所有模型、所有任务的固定数字。更重要的是理解任务类型。场景随机性倾向工程目标代码生成低准确、稳定SQL生成低可执行JSON结构化输出低格式一致数据抽取低字段稳定企业知识库问答低中忠于事实RAG摘要低中准确概括普通聊天中自然表达文案创作中高表达丰富小说/诗歌高创造性Brainstorming高探索空间可以记住一个简单原则越需要确定性越应该控制随机性越需要探索性越可以允许随机性。二十一、为什么代码生成通常需要更低的随机性例如请生成一个用户登录API。我们通常希望结构稳定 参数稳定 代码规范 逻辑一致而不是第一次使用Spring Boot 第二次使用FastAPI 第三次自己设计一个框架尤其是企业Agent。假设Agent负责生成SQL高随机性可能导致SELECT * FROM user;下一次SELECT id,name FROM user;再下一次甚至SELECT * FROM users;如果数据库中根本不存在users就会导致执行失败。因此LLM ↓ 生成SQL ↓ SQL Parser ↓ SQL Validator ↓ Permission Check ↓ Database比单纯LLM ↓ Database可靠得多。二十二、这就是“概率系统 确定性系统”Agent工程有一个非常重要的架构原则LLM 概率系统 Tools 确定性系统LLM擅长理解 推理 规划 语言表达 意图识别工具擅长计算 查询 执行 验证 数据处理所以用户 ↓ Agent ↓ LLM ↓ 理解任务 ↓ 选择Tool ↓ Tool ↓ 获得真实结果 ↓ LLM ↓ 解释结果 ↓ 用户这比让LLM自己“猜答案”更加可靠。二十三、为什么RAG也需要控制随机性假设企业知识库中有一份制度2026年差旅报销标准 经济舱……用户问出差可以报销什么如果直接让模型回答用户问题 ↓ LLM ↓ 生成模型可能根据自己的语言知识产生一个“听起来合理”的答案。但是听起来合理 ≠ 企业制度真实规定所以使用RAG用户问题 ↓ Retriever ↓ 知识库 ↓ 相关文档 ↓ Context ↓ LLM ↓ 回答这时候模型的主要任务变成基于检索到的事实组织回答。而不是凭自己的语言概率猜答案。因此Sampling解决的是输出为什么可能不同。而RAG解决的是输出是否有事实依据。这是两个不同的问题。二十四、随机性与幻觉是什么关系很多人会把随机性和幻觉完全等同起来。这是不准确的。即使Temperature 0模型依然可能产生幻觉。因为模型概率最高的Token不一定对应真实世界中的事实。例如某个不存在的人 某篇不存在的论文 某个不存在的API 某个错误的技术参数都可能在语言上非常合理。所以高概率 ≠ 真实这是大模型非常重要的认知。而RAG、Tool Calling、外部验证等机制就是在解决这个问题。二十五、Agent中的四层随机性如果进一步从Agent架构看可以把随机性分成四层。第一层Token随机性Token Probability ↓ Sampling ↓ Next Token第二层生成路径随机性Token 1不同 ↓ Context不同 ↓ Token 2概率不同 ↓ Token 3不同 ↓ 最终回答不同第三层Agent决策随机性选择哪个Tool 选择什么参数 下一步做什么 什么时候停止第四层系统级随机性Model Version Context RAG结果 Memory Tool Result Runtime System Prompt最终Token随机性 ↓ 生成路径差异 ↓ Agent决策差异 ↓ 系统执行差异 ↓ 最终结果差异二十六、企业级Agent为什么必须做“确定性边界设计”假设一个企业Agent负责订单处理用户说把订单A123取消掉。如果整个流程完全交给LLM用户 ↓ LLM ↓ 理解 ↓ 生成 ↓ 调用API风险非常高。更合理的架构用户 ↓ LLM ↓ 识别意图 ↓ 生成结构化Action ↓ 权限验证 ↓ 参数验证 ↓ 业务规则验证 ↓ 用户确认 ↓ 执行API ↓ 返回结果也就是说LLM可以决定“应该做什么”但真正执行高风险操作之前必须经过确定性系统验证。这就是企业级Agent与Demo级Agent之间的重要区别。二十七、Agent可靠性不能只靠Temperature一个成熟Agent至少需要Prompt Context Model Sampling Tool Validation Permission Monitoring Evaluation其中Temperature只是其中非常小的一部分。因此不要把“Agent不稳定”简单归因于“Temperature太高。”真正需要分析的是Prompt稳定吗 Context稳定吗 RAG稳定吗 Tool结果稳定吗 模型版本稳定吗 输出格式稳定吗 业务规则验证了吗二十八、如何提高Agent输出的一致性方法一合理降低随机性对于SQL JSON 数据抽取 工具参数 企业知识库问答通常应该倾向于更低的随机性。方法二固定System Prompt不要每次动态产生完全不同的规则。例如你是企业销售分析Agent。 必须遵循 1. 只能使用销售数据库数据。 2. 不允许虚构数据。 3. 所有金额必须通过Calculator计算。 4. 最终输出必须使用JSON格式。方法三控制Context保证System Prompt History RAG Memory Tool Result具有明确的结构和优先级。方法四结构化输出例如{ intent: sales_analysis, region: east_china, period: 2026, action: query_sales }比请自由决定下一步。更加容易控制。方法五Tool参数验证例如LLM ↓ Tool Call ↓ Schema Validation ↓ Permission Check ↓ Business Validation ↓ Execute方法六增加验证模型或规则引擎例如LLM生成SQL ↓ SQL Validator ↓ 通过 ├── Yes → Execute └── No → Reject / Repair二十九、不要试图让LLM承担“计算器”的工作举一个最简单的例子10086 × 2387LLM理论上可以计算。但是工程上为什么还应该使用Calculator Tool因为LLM 概率生成 Calculator 确定性计算更加合理的架构User ↓ Agent ↓ LLM识别 这是数学计算 ↓ Calculator Tool ↓ 准确结果 ↓ LLM组织语言 ↓ User这就是让模型做它擅长的事让程序做它擅长的事。三十、从“随机性”进一步理解Agent为什么需要Workflow如果所有任务都让LLM自由决定LLM ↓ 决定下一步 ↓ LLM ↓ 再决定下一步 ↓ LLM ↓ 继续决定那么系统自由度非常高。自由度越高灵活性 ↑ 不可控性 ↑所以企业Agent通常会引入Workflow——工作流。例如用户请求 ↓ 意图识别 ↓ 参数提取 ↓ 权限验证 ↓ 数据查询 ↓ 数据计算 ↓ 结果校验 ↓ 生成报告其中只有需要理解 需要规划 需要生成的地方交给LLM。其他步骤尽可能确定化。于是LLM Workflow Tools Rules形成更加可靠的Agent系统。三十一、最终理解Agent就是概率与确定性的结合到这里我们可以把Agent重新定义一次传统软件 确定性逻辑 LLM 概率性智能 Agent 概率性智能 确定性执行也就是Agent │ ┌────────────┴────────────┐ ↓ ↓ LLM Tools 概率系统 确定系统 │ │ 理解/推理/规划 查询/计算/执行 │ │ └────────────┬────────────┘ ↓ Workflow ↓ State ↓ Final Result这也是为什么Agent不是简单地给LLM套一个Prompt。真正的Agent工程需要解决模型能力 Context Memory State Tool Workflow Permission Evaluation Monitoring Cost Security三十二、面试题问题1为什么同一个Prompt大模型每次可能返回不同答案参考答案因为大语言模型采用概率生成机制。模型首先计算下一个Token的概率分布然后通过Sampling选择Token。不同生成过程中可能选择不同Token而早期Token的差异又会影响后续概率分布因此最终可能形成不同的生成路径和回答。问题2Temperature的作用是什么Temperature越高是不是模型越聪明参考答案不是。Temperature主要用于调整Token概率分布的尖锐程度。低Temperature → 概率更集中 → 输出更加稳定 高Temperature → 概率更加平坦 → 输出更加多样它控制的是生成过程中的探索程度并不会直接提高模型的智力。问题3Top-K和Top-P有什么区别参考答案Top-K按照固定数量限制候选Token例如K5表示只保留概率最高的5个Token。Top-P则按照累计概率动态选择候选Token例如P0.9表示保留概率从高到低累计达到90%的候选Token。因此Top-K → 固定候选数量 Top-P → 动态候选范围问题4Temperature设置为0以后是否可以保证Agent每次完全一致参考答案不能绝对保证。因为最终输出不仅受Temperature影响还可能受到模型版本 System Prompt Context RAG结果 Tool结果 底层推理实现 运行环境等因素影响。另外不同模型平台对Temperature0的实现也可能存在差异。因此企业级Agent如果要求稳定不能只依赖Temperature0而应该建立完整的确定性控制和验证机制。问题5为什么企业Agent不能让LLM直接完成所有任务参考答案因为LLM属于概率系统而企业中的很多任务需要确定性和可验证性。例如计算 数据库操作 权限判断 订单处理 支付 库存修改应该交给Calculator Database API Rule Engine Permission System等确定性组件。比较合理的架构是LLM 负责理解、推理、规划 Tool 负责查询、计算、执行 Validation 负责验证 Workflow 负责控制流程这样可以兼顾模型智能和系统可靠性。三十三、本节小结本节从一个最简单的问题开始为什么同一个问题AI每次回答都不一样最终我们得到了完整的知识链路。✅ 核心概念LLM 概率生成模型模型不是直接返回一个固定答案而是在不断预测Next Token✅ 底层原理Prompt ↓ Transformer ↓ Logits ↓ Temperature ↓ Softmax ↓ Token Probability ↓ Top-K / Top-P ↓ Sampling ↓ Next Token然后不断循环。✅ Temperature低Temperature → 概率集中 → 更稳定 高Temperature → 概率分散 → 更多样Temperature控制的是概率分布而不是模型智力。✅ SamplingSampling并不是完全随机而是按照概率分布进行采样。✅ Agent影响在Agent中随机性不仅存在于Token还可能进一步影响Generation ↓ Planning ↓ Tool Calling ↓ Workflow ↓ 最终执行结果✅ 工程解决方案企业级Agent不能简单地Temperature 0然后认为问题解决了。真正需要建立LLM Context Workflow Tools Validation Permission Monitoring Evaluation最终形成概率模型 确定性系统最重要的一句话大模型的随机性并不是一个需要彻底消灭的缺陷而是一种需要被工程化控制的能力优秀的Agent不是让LLM变得完全确定而是让概率模型负责“智能”让确定性系统负责“可靠”。下一篇下一节我们继续解决一个比“AI为什么每次回答不同”更加重要的问题《第3章 第5节AI到底怎么知道自己回答得好不好——从大模型评测到Agent Evaluation》我们将开始进入一个真正的Agent工程核心领域LLM ↓ Evaluation ↓ Agent Evaluation ↓ 准确率 ↓ Faithfulness ↓ Tool Calling准确率 ↓ Task Success ↓ 成本 ↓ 延迟 ↓ 企业级Agent质量体系因为当你真正开始开发Agent以后问题就不再是“AI能不能做”而会变成“AI做得到底好不好100次运行有多少次成功出了问题怎么定位模型升级后有没有变差”这将是从AI应用开发真正迈向Agent工程化的关键一步。