这次我们聊一个判断问题也是一个工程问题垂直 AI 产品为什么总在“演示很惊艳”和“生产不敢用”之间反复摇摆很多人会归因于模型能力不够、数据不够干净、Prompt 没写好。但有一个更基础、也更容易被忽略的原因——我们把 LLM 当成了一台确定性计算器却忘了大模型本质上是在掷骰子。题目叫《The Vertical AI Bubble: We Keep Forgetting That LLMs Roll Dice》翻译过来就是“垂直 AI 泡沫我们总是忘记 LLM 在掷骰子”。这个观点点破了一件事大量面向客服、法律、金融、医疗、招聘、代码审查等场景的垂直 AI 产品商业叙事建立在一个隐含假设上——同一句话问一百次模型应该给出稳定、可靠的答案。可实际上LLM 是概率模型同样的输入、同样的参数多跑几次可能得到不同的 Token 序列。当这种随机性进入真实业务流程轻则答案不一致重则谎报数据、编造工单、错误分类甚至触发合规风险。这篇文章不从融资角度聊泡沫只从技术角度把这件事拆开LLM 的“骰子”到底从哪来、对垂直 AI 应用有什么影响、在工程上怎么降低这种随机性、怎么设计评估和兜底机制。全文会包含通用的 API 调用示例、Agent 与 RAG 场景下的风险分析以及一套可以直接照做的验证流程。1. 本文关键点速览项目说明核心观点LLM 是概率模型输出天然具有随机性垂直 AI 产品不能把它当作确定性计算器随机性来源采样温度、top-p、随机种子、推理后端实现、并发请求调度、量化与精度差异最容易受影响的应用客服自动答复、法律/医疗/金融问答、代码生成、数据抽取、Agent 多步任务常见缓解手段低温度、固定 seed、结构化输出、多候选投票、评估回归集、人工复核工程落地优先级先做随机性度量再决定技术选型最后做人工兜底适合读者LLM 应用开发者、AI Agent 开发、RAG 系统设计者、技术决策者先说结论了解 LLM 的随机性不是让你不用 LLM而是在架构设计、产品承诺、评估方式上给“不确定性”留出足够的冗余。2. 为什么说 LLM 是“掷骰子”2.1 大模型的生成本质是采样LLM 的推理过程可以简化成“根据已有上下文预测下一个 Token 的概率分布”。比如输入“中国的首都是”模型可能给出“北京”0.85“北京。”0.10“北京市”0.03其他0.02这是概率分布。真正生成文本时模型并不总是选概率最高的 Token而是按照某种采样策略从这个分布中抽取。温度调高低概率 Token 被抽中的可能性变大top-p 会截断一部分过小的候选随机种子不同采样结果也会不同。所以LLM 的输出天然不是“查字典”而是“掷骰子”。骰子权重由模型参数和上下文决定但结果带有随机性。2.2 随机性的工程来源除了模型采样工程链路也会引入不确定性推理参数temperature、top_p、top_k、seed 设置不一样结果不一样。模型部署版本同一个模型v1 和 v2 微调版本差异输出不同。量化精度FP16、BF16、FP32、INT8、INT4 推理数值精度不同表现有差异。推理后端vLLM、TensorRT-LLM、transformers 原生推理算子实现不同采样结果可能不同。并发请求批处理会对不同请求做 padding极端情况下影响上下文位置编码导致个别输出变化。随机种子与硬件CUDA 算子在某些 GPU 上存在非确定性执行固定 seed 也未必能完全复现。也就是说即便你设置了temperature0也不能保证百分百稳定。很多接口在默认情况下并不使用固定 seed后端可能仍会做采样。temperature0通常会把采样变成贪心解码但工程实现中仍存在非确定性因素。2.3 随机性不等于“不聪明”需要强调随机性是 LLM 的能力来源之一。正是采样机制让模型能生成多样化的回答、给出创造性的文案也让它具备更强的探索能力。问题是垂直 AI 应用场景常常需要稳定、一致、可审计的结果这时随机性就成了风险。所以“LLM 在掷骰子”这个说法本质是在提醒很多产品架构建立在“LLM 是确定性数据库”的错误假设上。3. 垂直 AI 场景里的“不确定性放大”垂直 AI通常指针对特定行业或特定业务场景的 AI 系统比如智能客服、医疗分诊、法律文书审查、金融风控、招聘简历筛选、代码缺陷检测、企业知识库问答。这些场景有一个共同特征输出必须可靠、可解释、可追责。当 LLM 的随机性进入这类系统会出现几个层面的问题。3.1 单次输出的不稳定性最简单的情况同一个用户问题客服机器人第一次回答“可以退款”第二次回答“需要核实订单状态”第三次回答“抱歉无法退款”。用户会直接认为产品有问题。在非垂直的通用聊天场景这种差异可以被容忍。但在客服、医疗、法律场景这种不稳定直接影响体验和信任。3.2 多步骤 Agent 的错误累积现在很多垂直 AI 被设计成 Agent 形态先调用工具、再查询数据库、再生成回复、再执行一个动作。每一步都依赖 LLM 的判断而每一步都有可能“掷骰子”。一个典型流程LLM 判断用户意图选择工具。调用检索接口输入 query。对检索结果做摘要。根据摘要生成最终回复。如果第 1 步的意图分类结果不稳定后面所有步骤都会跑偏。Agent 的任务链越长随机性累积的偏差就越大。这也是很多团队发现“单个 Prompt 测试表现很好组合成 Agent 后经常出错”的原因之一。3.3 RAG 的检索与生成双重不确定性RAG 是垂直 AI 最常见的落地形态。它同样存在两层不确定性检索层query 改写是否准确、召回结果是否稳定生成层即使检索到同样的文档LLM 生成摘要或回答时仍可能选择不同的表述甚至遗漏关键信息。尤其是做“基于知识库的问答”时用户希望答案能对应到具体文档。如果 LLM 两次回答引用的内容不同就很难做归因和审核。3.4 合规与审计问题金融、医疗、法律场景要求每一步操作都有记录、可复核。LLM 的随机性意味着即使输入完全相同两次处理结果也可能不同。如果没有输出日志、版本记录和人工审核环节一旦出问题很难追溯。这也是垂直 AI 领域“落地难”的一个技术性原因不是模型不聪明而是系统架构没有消化不确定性。4. 怎么度量 LLM 的随机性在做工程缓解之前先要回答一个问题你的系统到底有多不稳定建议用一个简单的一致性测试来度量。4.1 最小验证流程准备一组测试输入覆盖典型场景和边界场景。对每个输入在相同参数下重复调用 N 次比如 10 次统计输出的一致性指标精确一致率输出完全相同的比例。语义一致率输出含义相同但表述不同的比例。关键字段准确率如果输出是 JSON检查核心字段是否一致。这组数字可以帮助你判断当前的模型参数、Prompt、下游任务到底能不能接受。4.2 通用测试代码示例下面是一个通用 Python 脚本以 OpenAI 风格 API 为示例。实际项目中需要替换 endpoint、API key、模型名和请求参数。import openai import json # 这里需要替换成实际服务的 endpoint、api_key、model client openai.OpenAI( api_keyyour-api-key, base_urlhttps://your-llm-endpoint.example.com/v1, ) def call_llm(prompt: str, temperature: float 0.2, seed: int 42) - str: resp client.chat.completions.create( modelyour-model-name, messages[ {role: system, content: 你是客服助理回答必须简洁。}, {role: user, content: prompt}, ], temperaturetemperature, seedseed, max_tokens512, ) return resp.choices[0].message.content def consistency_test(prompt: str, times: int 10): outputs [] for i in range(times): outputs.append(call_llm(prompt)) # 统计精确一致 unique_outputs set(outputs) exact_consistency len(unique_outputs) / times print(f本次测试运行次数: {times}) print(f唯一输出数量: {len(unique_outputs)}) print(f精确一致率: {1 - exact_consistency:.2%}) for idx, out in enumerate(outputs): print(f--- 第 {idx 1} 次 ---) print(out)注意seed不是所有后端都支持且部分服务即使支持 seed也不能保证完全复现。实际测试时先确认服务端是否支持该参数。4.3 指标怎么看如果精确一致率很低但语义一致率很高说明模型回答稳定只是表述有差异。这种情况可以通过输出后处理或固定模板改善。如果语义一致率也很低说明问题出在“理解层面”。比如用户问“退货流程是什么”模型一次回答“7 天无理由”一次回答“需要联系客服”那就需要检查 Prompt、检索结果或模型选型。如果结构化输出里的关键字段不一致比如 JSON 里status一会儿是approved一会儿是rejected这是危险信号必须做枚举约束或规则校验。5. 降低随机性的工程手段5.1 调整推理参数最常见的做法是降低temperature、设置较小的top_p并固定seed。但要注意这不是银弹。temperature0在多数后端意味着贪心解码输出相对稳定但部分后端在并发或量化场景下仍有不确定性固定seed能提升复现概率但不能跨后端、跨硬件保证完全一致。更稳妥的做法是在服务端统一推理参数不允许调用方随意修改。很多垂直 AI 产品都是多端接入如果每个调用方设置的参数不同出问题很难排查。5.2 使用结构化输出与 JSON Schema垂直 AI 经常需要把 LLM 输出接入下游系统比如 CRM、工单系统、数据库。建议优先使用结构化输出能力让模型只生成 JSON并严格遵循预设 Schema。常见实现方式有两种API 原生支持 JSON Mode 或 Structured Output在 Prompt 中要求 JSON 格式并用代码做解析和校验。推荐优先使用前者。下面是一个通用示例resp client.chat.completions.create( modelyour-model-name, messages[{role: user, content: 判断这个用户的退款请求是否符合政策}], temperature0.1, response_format{type: json_object}, seed42, ) content resp.choices[0].message.content data json.loads(content) # 校验必需字段 required_fields [status, reason, refund_amount] for field in required_fields: if field not in data: raise ValueError(fmissing field: {field})这里的关键点是让 LLM 只负责“理解和生成结构化字段”而不是直接生成最终的自然语言话术。字段层面的稳定性比整段文字稳定性更容易控制。5.3 多候选采样与投票对关键决策类任务可以用“多次采样 投票”的方式降低单次随机性的影响。也就是同一问题生成 3 到 5 次取多数结果。这种方法适合二分类、多分类、字段抽取等任务不太适合开放式长文本生成。投票逻辑要设定明确规则比如结果一致率达到 3/5采用该结果结果不一致触发人工审核或降级到规则引擎。示例from collections import Counter def get_majority_result(prompt: str, times: int 5): results [call_llm(prompt, temperature0.2) for _ in range(times)] counter Counter(results) winner, count counter.most_common(1)[0] if count max(3, times // 2 1): return winner else: return None # 交给人工或规则系统这种方式会增加推理成本和时间不适合所有环节。建议只对高影响、低频率的操作使用。5.4 规则引擎与 LLM 混合垂直 AI 不应该让 LLM 做所有事。很多业务逻辑其实是确定的例如金额校验、日期计算、订单状态判断。正确的思路是能用规则解决的不用 LLMLLM 只处理语义理解和内容生成LLM 输出必须经过规则校验不符合就拒绝或重试。比如客服机器人需要判断“是否满足 7 天无理由退货”可以让 LLM 抽取订单号和商品名称再用规则引擎去查订单是否符合退货条件。而不是让 LLM 直接给出“可以退”或“不可以退”的结论。这种混合架构把随机性限制在可控范围内是垂直 AI 落地最可靠的方式。5.5 输出后处理与兜底无论怎么控制参数LLM 都可能出错。因此下游系统要默认“输出不可信”并增加兜底逻辑对 JSON 输出做异常捕获和字段校验对关键字段做枚举值映射不在枚举内则拒绝对数字、日期做格式校验设置单次输出重试次数超过后降级为人工流程记录完整输入输出日志方便回溯。def safe_json_parse(content: str): try: data json.loads(content) except json.JSONDecodeError: # 尝试截取第一个 { 到最后一个 } start content.find({) end content.rfind(}) 1 if start 0 and end start: try: data json.loads(content[start:end]) except json.JSONDecodeError: return None else: return None return data这类代码很多团队都有但很少把它放在 LLM 调用链路的最前端。建议所有底层封装里直接内置解析和校验而不是在业务代码里到处重复处理。6. Agent 场景下的随机性管理6.1 先做动作原子化Agent 的每一步都可能是“掷骰子”所以第一步是减少单个动作的复杂度。比如不要在一个 Prompt 里让模型同时做“意图识别 信息抽取 情绪判断 回答生成”每个工具调用尽量只负责一个简单动作工具参数尽量用结构化格式而不是自由文本。动作拆得越细单个动作的稳定性越高出了问题也更容易定位。6.2 工具调用增加校验环节LLM Agent 常见的错误是“工具参数生成错误”。比如模型想调用create_order但缺少order_id或把日期格式写错。建议在工具执行前加一层参数校验器def validate_order_query(params: dict): required [order_id] if not all(k in params for k in required): return False, 缺少 order_id if not isinstance(params[order_id], str): return False, order_id 必须为字符串 if len(params[order_id]) 64: return False, order_id 长度超限 return True, 参数校验通过后再真正执行工具。这样即使 LLM 生成偶尔出错也会被拦截在系统边界内。6.3 重试策略要按任务类型区分Agent 的多步任务中某一步失败后直接重试同一 Prompt 可能还是得到同样错误。更有效的做法是把错误信息追加到 Prompt 里引导模型修正限制重试次数避免死循环重试仍然失败则终止流程并转人工。def run_agent_with_retry(task: str, max_retries: int 3): last_error for attempt in range(max_retries): prompt task if last_error: prompt f\n\n上次执行失败错误信息{last_error}\n请修正后重新执行。 result call_agent_once(prompt) if result.success: return result last_error result.error return None这里call_agent_once是伪代码实践中要替换成实际 Agent 执行逻辑。6.4 引入评估回归集Agent 系统迭代很快今天修的 Bug下次改 Prompt 可能又出现。建议维护一组“回归测试用例”每次改动后自动跑一遍固定输入用例 50 到 100 条记录每个用例是否成功、是否有工具调用错误、输出是否符合预期对比历史结果发现准确率下降就阻塞发布。回归集是垂直 AI 工程里最容易忽略、也最重要的一环。7. 评估与验收不能只看“示例没翻车”很多垂直 AI 项目的评估方式是拿十几个样例让模型跑一遍看起来结果正常就上线。这在确定性系统里没问题但 LLM 是随机系统小样本验证没有统计学意义。7.1 建立评估指标体系建议至少关注几个指标指标说明任务成功率最终输出是否满足业务要求关键字段准确率结构化字段是否完全正确输出一致性同一输入多次运行的一致程度异常率JSON 解析失败、工具调用失败比例人工接管率需要人工干预的比例响应延迟与成本P95 延迟、Token 消耗7.2 评估集设计评估集要覆盖正常输入边界输入超长文本、缺失字段模糊表达恶意输入或对抗样本多轮对话场景不同用户语气。每个场景至少 20 到 50 条测试用例。每条用例要预先标注“标准输出”。评估时可以通过 LLM 作为裁判也可以用代码做精确匹配但关键字段必须人工复核一部分。7.3 灰度与回滚上线时不要把流量一次性切到 LLM 方案。建议先内部小流量测试对比规则引擎和 LLM 方案的效果设置回滚开关一旦指标异常立刻切回旧版。LLM 系统的回滚策略比传统系统更重要因为模型行为可能随版本、参数、下游数据变化而漂移。8. 资源消耗与性能观察随机性还带来一个隐性成本同样的任务因为每次输出不同可能导致重试次数增加和 Token 消耗上升。在多候选投票方案中成本会成倍增加。性能观察的重点包括相同输入、不同参数下平均响应时间是否有明显波动多候选投票方案下P95 延迟是否满足业务要求结构化输出解析失败后重试带来的额外 Token 成本Agent 多步任务中随机性导致执行路径分叉是否增加了工具调用次数。建议在日志里记录每次请求的模型参数、响应内容、耗时、Token 用量以及是否命中重试。这些数据是后续优化参数和架构的依据。如果团队使用本地部署并关心量化对随机性的影响可以对比 FP16/BF16/INT8 三组条件下的同一测试集观察一致率和任务成功率差异。这在模型选型阶段很有价值因为某些场景下量化收益带来的成本节省可能被重试率和错误率上升掩盖。9. 常见问题与排查方法问题现象可能原因排查方式解决方案同一输入多次调用结果差异大temperature 过高或未固定 seed查看请求参数确认服务端是否支持 seed降低 temperature固定 seed启用结构化输出设置了 temperature0 仍不稳定服务端实现非贪心解码或并发批处理导致对比单请求和并发请求结果后端统一采样策略升级推理框架JSON 输出偶尔无法解析模型生成了额外文本或输出被截断检查原始响应全文和 max_tokens 设置使用 JSON Mode增加 max_tokens做容错解析Agent 工具调用参数错误模型对工具说明理解不足检查工具 Prompt 是否清晰参数是否复杂简化工具定义增加参数校验器失败重试时反馈错误业务结果不一致但单次输出看起来正常评估集覆盖不足或对随机性没有度量建立一致性测试和回归集增加多候选投票和人工复核上线后错误率上升模型版本、上下文数据、Prompt 发生漂移对比新旧版本日志灰度发布建立监控和回滚机制10. 最佳实践与工程建议10.1 把 LLM 当“实习生”需要复核和边界在垂直 AI 系统里LLM 更适合做“初稿生成者”而不是“最终决策者”。关键业务动作必须经过规则校验、人工审批或二次模型验证。10.2 默认使用结构化输出只要是接入业务流程输出格式尽量用 JSON Schema 或枚举约束。自然语言输出只用于用户可见的最终内容并且要做好模板化处理。10.3 建立随机性基线每换一个模型、每改一次 Prompt都跑一遍一致性测试和回归集。不要凭感觉判断“这次稳定了”。10.4 区分高风险与低风险场景不是所有场景都需要追求零随机性。比如推荐语、文案生成多样性反而是优点。要按场景划分策略高影响、可审计场景低 temperature、固定格式、多候选投票、人工审核中影响场景结构化输出 规则校验低影响场景允许一定多样性只做基本过滤。10.5 日志是一切的基础所有 LLM 调用都必须记录输入内容推理参数模型版本输出内容后处理结果是否重试是否人工介入。没有日志的 LLM 系统出问题时根本无法定位是模型问题、参数问题还是业务逻辑问题。10.6 合规与隐私提醒如果垂直 AI 涉及个人数据、人脸、声音、医疗记录、法律文书等敏感内容必须确保数据来源合法并在处理前获得必要授权。LLM 输出不应直接作为医疗、法律、金融决策依据。生产环境部署时要限制接口访问范围避免未授权调用。11. 总结与后续方向垂直 AI 的价值不需要否定。真正的问题在于很多人把 LLM 当成一个“稳定的函数”然后用传统软件的确定性思维去构建产品。结果就是Demo 很丝滑上线就翻车然后归咎于“模型不聪明”。实际上LLM 的随机性是一个可以被度量、被管理、被约束的工程问题。先从简单的测试开始找出 20 个核心输入跑 10 次看一致率把关键输出改成结构化 JSON给 Agent 的每一步加上参数校验给高风险流程加上人工复核。这些动作做下来垂直 AI 的可靠性会明显提高。后续可以继续深入的方向包括本地部署 LLM 时的量化精度对一致性的影响、RAG 检索链路的不确定性分析、基于多候选投票的成本优化、以及 LLM 应用的自动化评估框架。这篇文章里的思路可以作为你搭建垂直 AI 系统时的第一版检查清单。建议收藏备用下一次准备把 LLM 接进业务流程时先问自己一句系统能接受 LLM 掷骰子吗如果不能请做好上面的所有工程防护。 LLM的随机性：垂直AI从演示到落地的关键工程挑战
这次我们聊一个判断问题也是一个工程问题垂直 AI 产品为什么总在“演示很惊艳”和“生产不敢用”之间反复摇摆很多人会归因于模型能力不够、数据不够干净、Prompt 没写好。但有一个更基础、也更容易被忽略的原因——我们把 LLM 当成了一台确定性计算器却忘了大模型本质上是在掷骰子。题目叫《The Vertical AI Bubble: We Keep Forgetting That LLMs Roll Dice》翻译过来就是“垂直 AI 泡沫我们总是忘记 LLM 在掷骰子”。这个观点点破了一件事大量面向客服、法律、金融、医疗、招聘、代码审查等场景的垂直 AI 产品商业叙事建立在一个隐含假设上——同一句话问一百次模型应该给出稳定、可靠的答案。可实际上LLM 是概率模型同样的输入、同样的参数多跑几次可能得到不同的 Token 序列。当这种随机性进入真实业务流程轻则答案不一致重则谎报数据、编造工单、错误分类甚至触发合规风险。这篇文章不从融资角度聊泡沫只从技术角度把这件事拆开LLM 的“骰子”到底从哪来、对垂直 AI 应用有什么影响、在工程上怎么降低这种随机性、怎么设计评估和兜底机制。全文会包含通用的 API 调用示例、Agent 与 RAG 场景下的风险分析以及一套可以直接照做的验证流程。1. 本文关键点速览项目说明核心观点LLM 是概率模型输出天然具有随机性垂直 AI 产品不能把它当作确定性计算器随机性来源采样温度、top-p、随机种子、推理后端实现、并发请求调度、量化与精度差异最容易受影响的应用客服自动答复、法律/医疗/金融问答、代码生成、数据抽取、Agent 多步任务常见缓解手段低温度、固定 seed、结构化输出、多候选投票、评估回归集、人工复核工程落地优先级先做随机性度量再决定技术选型最后做人工兜底适合读者LLM 应用开发者、AI Agent 开发、RAG 系统设计者、技术决策者先说结论了解 LLM 的随机性不是让你不用 LLM而是在架构设计、产品承诺、评估方式上给“不确定性”留出足够的冗余。2. 为什么说 LLM 是“掷骰子”2.1 大模型的生成本质是采样LLM 的推理过程可以简化成“根据已有上下文预测下一个 Token 的概率分布”。比如输入“中国的首都是”模型可能给出“北京”0.85“北京。”0.10“北京市”0.03其他0.02这是概率分布。真正生成文本时模型并不总是选概率最高的 Token而是按照某种采样策略从这个分布中抽取。温度调高低概率 Token 被抽中的可能性变大top-p 会截断一部分过小的候选随机种子不同采样结果也会不同。所以LLM 的输出天然不是“查字典”而是“掷骰子”。骰子权重由模型参数和上下文决定但结果带有随机性。2.2 随机性的工程来源除了模型采样工程链路也会引入不确定性推理参数temperature、top_p、top_k、seed 设置不一样结果不一样。模型部署版本同一个模型v1 和 v2 微调版本差异输出不同。量化精度FP16、BF16、FP32、INT8、INT4 推理数值精度不同表现有差异。推理后端vLLM、TensorRT-LLM、transformers 原生推理算子实现不同采样结果可能不同。并发请求批处理会对不同请求做 padding极端情况下影响上下文位置编码导致个别输出变化。随机种子与硬件CUDA 算子在某些 GPU 上存在非确定性执行固定 seed 也未必能完全复现。也就是说即便你设置了temperature0也不能保证百分百稳定。很多接口在默认情况下并不使用固定 seed后端可能仍会做采样。temperature0通常会把采样变成贪心解码但工程实现中仍存在非确定性因素。2.3 随机性不等于“不聪明”需要强调随机性是 LLM 的能力来源之一。正是采样机制让模型能生成多样化的回答、给出创造性的文案也让它具备更强的探索能力。问题是垂直 AI 应用场景常常需要稳定、一致、可审计的结果这时随机性就成了风险。所以“LLM 在掷骰子”这个说法本质是在提醒很多产品架构建立在“LLM 是确定性数据库”的错误假设上。3. 垂直 AI 场景里的“不确定性放大”垂直 AI通常指针对特定行业或特定业务场景的 AI 系统比如智能客服、医疗分诊、法律文书审查、金融风控、招聘简历筛选、代码缺陷检测、企业知识库问答。这些场景有一个共同特征输出必须可靠、可解释、可追责。当 LLM 的随机性进入这类系统会出现几个层面的问题。3.1 单次输出的不稳定性最简单的情况同一个用户问题客服机器人第一次回答“可以退款”第二次回答“需要核实订单状态”第三次回答“抱歉无法退款”。用户会直接认为产品有问题。在非垂直的通用聊天场景这种差异可以被容忍。但在客服、医疗、法律场景这种不稳定直接影响体验和信任。3.2 多步骤 Agent 的错误累积现在很多垂直 AI 被设计成 Agent 形态先调用工具、再查询数据库、再生成回复、再执行一个动作。每一步都依赖 LLM 的判断而每一步都有可能“掷骰子”。一个典型流程LLM 判断用户意图选择工具。调用检索接口输入 query。对检索结果做摘要。根据摘要生成最终回复。如果第 1 步的意图分类结果不稳定后面所有步骤都会跑偏。Agent 的任务链越长随机性累积的偏差就越大。这也是很多团队发现“单个 Prompt 测试表现很好组合成 Agent 后经常出错”的原因之一。3.3 RAG 的检索与生成双重不确定性RAG 是垂直 AI 最常见的落地形态。它同样存在两层不确定性检索层query 改写是否准确、召回结果是否稳定生成层即使检索到同样的文档LLM 生成摘要或回答时仍可能选择不同的表述甚至遗漏关键信息。尤其是做“基于知识库的问答”时用户希望答案能对应到具体文档。如果 LLM 两次回答引用的内容不同就很难做归因和审核。3.4 合规与审计问题金融、医疗、法律场景要求每一步操作都有记录、可复核。LLM 的随机性意味着即使输入完全相同两次处理结果也可能不同。如果没有输出日志、版本记录和人工审核环节一旦出问题很难追溯。这也是垂直 AI 领域“落地难”的一个技术性原因不是模型不聪明而是系统架构没有消化不确定性。4. 怎么度量 LLM 的随机性在做工程缓解之前先要回答一个问题你的系统到底有多不稳定建议用一个简单的一致性测试来度量。4.1 最小验证流程准备一组测试输入覆盖典型场景和边界场景。对每个输入在相同参数下重复调用 N 次比如 10 次统计输出的一致性指标精确一致率输出完全相同的比例。语义一致率输出含义相同但表述不同的比例。关键字段准确率如果输出是 JSON检查核心字段是否一致。这组数字可以帮助你判断当前的模型参数、Prompt、下游任务到底能不能接受。4.2 通用测试代码示例下面是一个通用 Python 脚本以 OpenAI 风格 API 为示例。实际项目中需要替换 endpoint、API key、模型名和请求参数。import openai import json # 这里需要替换成实际服务的 endpoint、api_key、model client openai.OpenAI( api_keyyour-api-key, base_urlhttps://your-llm-endpoint.example.com/v1, ) def call_llm(prompt: str, temperature: float 0.2, seed: int 42) - str: resp client.chat.completions.create( modelyour-model-name, messages[ {role: system, content: 你是客服助理回答必须简洁。}, {role: user, content: prompt}, ], temperaturetemperature, seedseed, max_tokens512, ) return resp.choices[0].message.content def consistency_test(prompt: str, times: int 10): outputs [] for i in range(times): outputs.append(call_llm(prompt)) # 统计精确一致 unique_outputs set(outputs) exact_consistency len(unique_outputs) / times print(f本次测试运行次数: {times}) print(f唯一输出数量: {len(unique_outputs)}) print(f精确一致率: {1 - exact_consistency:.2%}) for idx, out in enumerate(outputs): print(f--- 第 {idx 1} 次 ---) print(out)注意seed不是所有后端都支持且部分服务即使支持 seed也不能保证完全复现。实际测试时先确认服务端是否支持该参数。4.3 指标怎么看如果精确一致率很低但语义一致率很高说明模型回答稳定只是表述有差异。这种情况可以通过输出后处理或固定模板改善。如果语义一致率也很低说明问题出在“理解层面”。比如用户问“退货流程是什么”模型一次回答“7 天无理由”一次回答“需要联系客服”那就需要检查 Prompt、检索结果或模型选型。如果结构化输出里的关键字段不一致比如 JSON 里status一会儿是approved一会儿是rejected这是危险信号必须做枚举约束或规则校验。5. 降低随机性的工程手段5.1 调整推理参数最常见的做法是降低temperature、设置较小的top_p并固定seed。但要注意这不是银弹。temperature0在多数后端意味着贪心解码输出相对稳定但部分后端在并发或量化场景下仍有不确定性固定seed能提升复现概率但不能跨后端、跨硬件保证完全一致。更稳妥的做法是在服务端统一推理参数不允许调用方随意修改。很多垂直 AI 产品都是多端接入如果每个调用方设置的参数不同出问题很难排查。5.2 使用结构化输出与 JSON Schema垂直 AI 经常需要把 LLM 输出接入下游系统比如 CRM、工单系统、数据库。建议优先使用结构化输出能力让模型只生成 JSON并严格遵循预设 Schema。常见实现方式有两种API 原生支持 JSON Mode 或 Structured Output在 Prompt 中要求 JSON 格式并用代码做解析和校验。推荐优先使用前者。下面是一个通用示例resp client.chat.completions.create( modelyour-model-name, messages[{role: user, content: 判断这个用户的退款请求是否符合政策}], temperature0.1, response_format{type: json_object}, seed42, ) content resp.choices[0].message.content data json.loads(content) # 校验必需字段 required_fields [status, reason, refund_amount] for field in required_fields: if field not in data: raise ValueError(fmissing field: {field})这里的关键点是让 LLM 只负责“理解和生成结构化字段”而不是直接生成最终的自然语言话术。字段层面的稳定性比整段文字稳定性更容易控制。5.3 多候选采样与投票对关键决策类任务可以用“多次采样 投票”的方式降低单次随机性的影响。也就是同一问题生成 3 到 5 次取多数结果。这种方法适合二分类、多分类、字段抽取等任务不太适合开放式长文本生成。投票逻辑要设定明确规则比如结果一致率达到 3/5采用该结果结果不一致触发人工审核或降级到规则引擎。示例from collections import Counter def get_majority_result(prompt: str, times: int 5): results [call_llm(prompt, temperature0.2) for _ in range(times)] counter Counter(results) winner, count counter.most_common(1)[0] if count max(3, times // 2 1): return winner else: return None # 交给人工或规则系统这种方式会增加推理成本和时间不适合所有环节。建议只对高影响、低频率的操作使用。5.4 规则引擎与 LLM 混合垂直 AI 不应该让 LLM 做所有事。很多业务逻辑其实是确定的例如金额校验、日期计算、订单状态判断。正确的思路是能用规则解决的不用 LLMLLM 只处理语义理解和内容生成LLM 输出必须经过规则校验不符合就拒绝或重试。比如客服机器人需要判断“是否满足 7 天无理由退货”可以让 LLM 抽取订单号和商品名称再用规则引擎去查订单是否符合退货条件。而不是让 LLM 直接给出“可以退”或“不可以退”的结论。这种混合架构把随机性限制在可控范围内是垂直 AI 落地最可靠的方式。5.5 输出后处理与兜底无论怎么控制参数LLM 都可能出错。因此下游系统要默认“输出不可信”并增加兜底逻辑对 JSON 输出做异常捕获和字段校验对关键字段做枚举值映射不在枚举内则拒绝对数字、日期做格式校验设置单次输出重试次数超过后降级为人工流程记录完整输入输出日志方便回溯。def safe_json_parse(content: str): try: data json.loads(content) except json.JSONDecodeError: # 尝试截取第一个 { 到最后一个 } start content.find({) end content.rfind(}) 1 if start 0 and end start: try: data json.loads(content[start:end]) except json.JSONDecodeError: return None else: return None return data这类代码很多团队都有但很少把它放在 LLM 调用链路的最前端。建议所有底层封装里直接内置解析和校验而不是在业务代码里到处重复处理。6. Agent 场景下的随机性管理6.1 先做动作原子化Agent 的每一步都可能是“掷骰子”所以第一步是减少单个动作的复杂度。比如不要在一个 Prompt 里让模型同时做“意图识别 信息抽取 情绪判断 回答生成”每个工具调用尽量只负责一个简单动作工具参数尽量用结构化格式而不是自由文本。动作拆得越细单个动作的稳定性越高出了问题也更容易定位。6.2 工具调用增加校验环节LLM Agent 常见的错误是“工具参数生成错误”。比如模型想调用create_order但缺少order_id或把日期格式写错。建议在工具执行前加一层参数校验器def validate_order_query(params: dict): required [order_id] if not all(k in params for k in required): return False, 缺少 order_id if not isinstance(params[order_id], str): return False, order_id 必须为字符串 if len(params[order_id]) 64: return False, order_id 长度超限 return True, 参数校验通过后再真正执行工具。这样即使 LLM 生成偶尔出错也会被拦截在系统边界内。6.3 重试策略要按任务类型区分Agent 的多步任务中某一步失败后直接重试同一 Prompt 可能还是得到同样错误。更有效的做法是把错误信息追加到 Prompt 里引导模型修正限制重试次数避免死循环重试仍然失败则终止流程并转人工。def run_agent_with_retry(task: str, max_retries: int 3): last_error for attempt in range(max_retries): prompt task if last_error: prompt f\n\n上次执行失败错误信息{last_error}\n请修正后重新执行。 result call_agent_once(prompt) if result.success: return result last_error result.error return None这里call_agent_once是伪代码实践中要替换成实际 Agent 执行逻辑。6.4 引入评估回归集Agent 系统迭代很快今天修的 Bug下次改 Prompt 可能又出现。建议维护一组“回归测试用例”每次改动后自动跑一遍固定输入用例 50 到 100 条记录每个用例是否成功、是否有工具调用错误、输出是否符合预期对比历史结果发现准确率下降就阻塞发布。回归集是垂直 AI 工程里最容易忽略、也最重要的一环。7. 评估与验收不能只看“示例没翻车”很多垂直 AI 项目的评估方式是拿十几个样例让模型跑一遍看起来结果正常就上线。这在确定性系统里没问题但 LLM 是随机系统小样本验证没有统计学意义。7.1 建立评估指标体系建议至少关注几个指标指标说明任务成功率最终输出是否满足业务要求关键字段准确率结构化字段是否完全正确输出一致性同一输入多次运行的一致程度异常率JSON 解析失败、工具调用失败比例人工接管率需要人工干预的比例响应延迟与成本P95 延迟、Token 消耗7.2 评估集设计评估集要覆盖正常输入边界输入超长文本、缺失字段模糊表达恶意输入或对抗样本多轮对话场景不同用户语气。每个场景至少 20 到 50 条测试用例。每条用例要预先标注“标准输出”。评估时可以通过 LLM 作为裁判也可以用代码做精确匹配但关键字段必须人工复核一部分。7.3 灰度与回滚上线时不要把流量一次性切到 LLM 方案。建议先内部小流量测试对比规则引擎和 LLM 方案的效果设置回滚开关一旦指标异常立刻切回旧版。LLM 系统的回滚策略比传统系统更重要因为模型行为可能随版本、参数、下游数据变化而漂移。8. 资源消耗与性能观察随机性还带来一个隐性成本同样的任务因为每次输出不同可能导致重试次数增加和 Token 消耗上升。在多候选投票方案中成本会成倍增加。性能观察的重点包括相同输入、不同参数下平均响应时间是否有明显波动多候选投票方案下P95 延迟是否满足业务要求结构化输出解析失败后重试带来的额外 Token 成本Agent 多步任务中随机性导致执行路径分叉是否增加了工具调用次数。建议在日志里记录每次请求的模型参数、响应内容、耗时、Token 用量以及是否命中重试。这些数据是后续优化参数和架构的依据。如果团队使用本地部署并关心量化对随机性的影响可以对比 FP16/BF16/INT8 三组条件下的同一测试集观察一致率和任务成功率差异。这在模型选型阶段很有价值因为某些场景下量化收益带来的成本节省可能被重试率和错误率上升掩盖。9. 常见问题与排查方法问题现象可能原因排查方式解决方案同一输入多次调用结果差异大temperature 过高或未固定 seed查看请求参数确认服务端是否支持 seed降低 temperature固定 seed启用结构化输出设置了 temperature0 仍不稳定服务端实现非贪心解码或并发批处理导致对比单请求和并发请求结果后端统一采样策略升级推理框架JSON 输出偶尔无法解析模型生成了额外文本或输出被截断检查原始响应全文和 max_tokens 设置使用 JSON Mode增加 max_tokens做容错解析Agent 工具调用参数错误模型对工具说明理解不足检查工具 Prompt 是否清晰参数是否复杂简化工具定义增加参数校验器失败重试时反馈错误业务结果不一致但单次输出看起来正常评估集覆盖不足或对随机性没有度量建立一致性测试和回归集增加多候选投票和人工复核上线后错误率上升模型版本、上下文数据、Prompt 发生漂移对比新旧版本日志灰度发布建立监控和回滚机制10. 最佳实践与工程建议10.1 把 LLM 当“实习生”需要复核和边界在垂直 AI 系统里LLM 更适合做“初稿生成者”而不是“最终决策者”。关键业务动作必须经过规则校验、人工审批或二次模型验证。10.2 默认使用结构化输出只要是接入业务流程输出格式尽量用 JSON Schema 或枚举约束。自然语言输出只用于用户可见的最终内容并且要做好模板化处理。10.3 建立随机性基线每换一个模型、每改一次 Prompt都跑一遍一致性测试和回归集。不要凭感觉判断“这次稳定了”。10.4 区分高风险与低风险场景不是所有场景都需要追求零随机性。比如推荐语、文案生成多样性反而是优点。要按场景划分策略高影响、可审计场景低 temperature、固定格式、多候选投票、人工审核中影响场景结构化输出 规则校验低影响场景允许一定多样性只做基本过滤。10.5 日志是一切的基础所有 LLM 调用都必须记录输入内容推理参数模型版本输出内容后处理结果是否重试是否人工介入。没有日志的 LLM 系统出问题时根本无法定位是模型问题、参数问题还是业务逻辑问题。10.6 合规与隐私提醒如果垂直 AI 涉及个人数据、人脸、声音、医疗记录、法律文书等敏感内容必须确保数据来源合法并在处理前获得必要授权。LLM 输出不应直接作为医疗、法律、金融决策依据。生产环境部署时要限制接口访问范围避免未授权调用。11. 总结与后续方向垂直 AI 的价值不需要否定。真正的问题在于很多人把 LLM 当成一个“稳定的函数”然后用传统软件的确定性思维去构建产品。结果就是Demo 很丝滑上线就翻车然后归咎于“模型不聪明”。实际上LLM 的随机性是一个可以被度量、被管理、被约束的工程问题。先从简单的测试开始找出 20 个核心输入跑 10 次看一致率把关键输出改成结构化 JSON给 Agent 的每一步加上参数校验给高风险流程加上人工复核。这些动作做下来垂直 AI 的可靠性会明显提高。后续可以继续深入的方向包括本地部署 LLM 时的量化精度对一致性的影响、RAG 检索链路的不确定性分析、基于多候选投票的成本优化、以及 LLM 应用的自动化评估框架。这篇文章里的思路可以作为你搭建垂直 AI 系统时的第一版检查清单。建议收藏备用下一次准备把 LLM 接进业务流程时先问自己一句系统能接受 LLM 掷骰子吗如果不能请做好上面的所有工程防护。