垂直AI的确定性难题：LLM随机性与稳定输出工程实践

垂直AIVertical AI这个词现在几乎成了创投圈和技术圈共同追逐的方向医疗、法律、金融、工业制造似乎每个细分领域都在用大模型重新包装一套软件。但如果你真把这些系统放到生产环境里跑上一周大概率会遇到一个很劝退的场景同一份合同同一个模型同样的提示词上午审查出三条风险下午就变成了另外三条。这不是玄学也不是偶发bug——因为LLM本质上是一个概率系统它每一次回答都相当于掷了一次骰子。所以在我看来当前这轮垂直AI泡沫最危险的并不是融资估值而是我们悄悄把LLM当作了一个100%确定性的数据库来用。模型越强大这种“确定性幻觉”越容易被放大。这篇文章想聊清楚三件事第一LLM的随机性到底从哪里来是不是把temperature调成0就万事大吉第二垂直AI应用应该怎么围绕这种随机性做架构设计第三怎么评估一个垂直AI系统到底能不能上线。如果你是AI应用开发者、技术负责人或者正准备投身某个垂直领域做AI产品这篇内容可以给你一个比较冷静的参考。1. 这篇文章真正要解决的问题先从身边最常见的现象说起。做AI产品的人大多经历过“同一个问题模型答得不一样”。产品经理把它当成bug提给算法同学算法同学看了一眼采样参数说这是正常的大模型本来就有随机性。然后产品经理陷入困惑如果它每次答案都不一样我怎么敢拿给客户用这种困惑在垂直AI里会被放大一百倍。垂直AI的目标不是做一个通用聊天机器人而是在特定行业里完成特定任务。合同审核、法律检索、医疗分诊、数据分析、代码审查这些都是“任务”不是“闲聊”。任务型系统天然要求稳定、可复现、低风险。但LLM的文本生成过程恰恰是一个采样过程。这就形成一个结构性冲突业务要确定性模型给概率。更麻烦的是现在很多垂直AI创业公司的demo演示非常顺畅。演示时demo只跑一遍客户验收时可能要跑一千遍。只要有一遍输出离谱整套系统的信任就没了。这也是我判断“垂直AI泡沫”到来的技术依据泡沫不在模型能力层而在确定性预期层。整个行业对LLM随机性的正视程度远低于它进入生产环境的速度。这篇文章不是劝退也不是让你不用LLM。相反我认为垂直AI依然是未来但前提是工程上必须把LLM重新定义为“一个概率函数”然后用校验、重试、评估、人工兜底这些传统软件手段把它封装成一个确定性的服务。下面先解决第一个问题LLM到底是怎么掷骰子的。2. LLM是怎么“掷骰子”的概率分布与采样2.1 从Logits到概率要理解随机性得先看大模型生成文本时的内部过程。简单说模型在预测下一个词时会先给一批候选token打一个原始分这个分数称为logits。这些分数没有归一化需要通过Softmax函数变成概率。概率越高代表模型认为这个词越可能出现在当前位置。但真正生成的时候模型并不是永远选择概率最高的那个词。它通常会根据这个概率分布去采样。也就是说某个词哪怕概率只有15%也有一定机会被选中。这就像掷骰子只不过每个面被抽中的权重不同。下面用一个极简的Python示例来模拟这个过程# 模拟LLM的token概率采样 import math import random # 假设模型给出的原始分数logits logits { 继续: 3.2, 终止: 1.5, 暂停: 1.8, } def softmax_with_temperature(logits, temperature): exp_vals {k: math.exp(v / temperature) for k, v in logits.items()} total sum(exp_vals.values()) return {k: v / total for k, v in exp_vals.items()} probs softmax_with_temperature(logits, temperature0.7) print(采样概率:, probs) # 按概率采样一次 choice random.choices(list(probs.keys()), weightslist(probs.values()))[0] print(本次采样结果:, choice)这里的关键是temperature参数。temperature越低Softmax分布越尖锐高概率词被选中的可能性越大temperature越高分布越平滑低概率词被选中的可能性也越大。所以当你在生产环境里把temperature调得很高同一个问题得到完全不同的回答是完全正常的。2.2 采样带来的不确定性真实场景里一个LLM生成几百个token每一步都这样采样所以组合出来的回答自然五花八门。即便把temperature调成0很多模型会采用贪心解码看起来稳定但这里有两个容易忽略的坑。第一不少云API在服务端仍然存在随机性seed参数只能降低变化不能保证不同请求在分布式环境下完全复现。第二模型版本更新、推理框架不同、部署环境不同都可能改变输出。所以temperature0和seed只是控制随机性的手段并不能像数据库事务一样提供强一致性保证。核心结论是LLM不是纯函数同一个输入可能对应多个输出。这个特性不是bug而是模型设计的一部分。垂直AI工程要解决的问题不是消灭随机性而是管理随机性。3. 垂直AI应用的典型场景与不确定性风险理解随机性之后我们看几个垂直场景。先看内容生成类营销文案、招聘JD、行业摘要。这类任务对随机性容忍度较高只要风格一致、事实正确每次换一种说法反而可能是优点。再看规则类任务合同审查、法律问答、金融风控报告、医疗预问诊。这类任务输出直接影响决策随机性可能是致命的。最后是代码和数据类自动生成SQL、生成代码、测试用例。这类任务看起来“能运行就行”但LLM生成的逻辑可能在不同批次里产生不同实现如果没有测试覆盖隐患非常大。场景随机性影响可接受程度工程对策营销文案生成同一产品介绍每次不同高反而需要多样性temperature设0.7~1.0人工挑选合同风险审查高风险条款漏检低必须稳定结构化输出校验人工复核客服自动问答相似问题不同回复中需要兜底话术RAG会话状态降级到FAQ医疗预问诊症状理解偏差低不能直接诊断限定角色规则流程结果仅参考代码生成逻辑非确定性实现中依赖测试单测覆盖静态检查代码评审数据分析问答生成的SQL结果不同低需要准确限定表结构SQL验证人工确认这里特别想提醒一个现象我把它称为“Demo陷阱”。很多垂直AI演示都只准备了三五个暖场案例而这些案例往往都被精心调过提示词。一旦上线真实输入比demo复杂得多模型就会在概率空间里“自由发挥”。所以评估一个垂直AI应用第一件事不是看它聪明不聪明而是看它稳不稳。4. 控制随机性的基础采样参数与结构化输出4.1 采样参数先从最直接的手段讲起采样参数。这是每个AI应用开发者都应该掌握的旋钮。temperature采样温度。范围一般0到2越低越保守。top_p核采样概率。控制候选token的累计概率范围越小越保守。max_tokens限制生成长度避免输出被截断。stop停止词让输出更收敛。seed随机数种子尽量复现结果但不要完全依赖。response_format/json_schema结构化输出这是当前最实用的稳定性手段。如果你的业务并不需要创意发挥那么默认建议把temperature调低尤其是合同审查、医疗问答、数据查询这类任务。很多团队把temperature默认值留在0.7甚至更高等于主动给生产环境埋雷。4.2 结构化输出与固定随机种子下面是一个使用OpenAI兼容API的示例。代码里同时启用了temperature0和seed42并强制返回JSON格式这样业务系统可以直接解析结果。# 文件路径llm_stable_call.py # 需要先安装 openai 库pip install openai from openai import OpenAI client OpenAI(api_keyyour-api-key) resp client.chat.completions.create( modelgpt-4o-mini, temperature0, seed42, response_format{type: json_object}, messages[ { role: system, content: ( 你是合同风险审查助手。只输出JSON不要额外说明。 JSON格式{\risks\:[{\description\:\风险描述\, \level\:\high|medium|low\}]} ) }, { role: user, content: 请审查这份合同是否存在风险甲方应在合同签订后10日内向乙方支付全部款项逾期视为违约。 } ] ) content resp.choices[0].message.content print(content)这段代码里response_format{type: json_object}会让模型尽量输出JSON极大降低了解析失败的概率。temperature0和seed用来减缓随机性。但注意就算你把这套代码重复执行几十次仍然可能看到风险描述的措辞有差异只是整体结构会稳定很多。如果你需要在本地达到更强的可复现性可以考虑本地部署开源模型并固定随机种子。即便如此模型版本、推理框架vLLM、llama.cpp等的不同也会影响输出。所以生产环境一定要把模型版本和推理框架版本一起锁定。目前主流的LLM应用开发框架比如LangChain、Spring AI也都在做同一件事把模型输出变成可消费的业务数据。它们提供的结构化输出能力本质上就是用来对冲LLM随机性的。5. 从“一次调用”到“可验证流程”稳定输出的工程链路把采样参数调好只解决了第一层问题。真正的生产系统需要把LLM调用包在一条可验证、可重试、可兜底的流程里。核心思想是LLM是生成器不是真理机。业务系统要建立防线防止错误输出直接落到用户头上。5.1 验证、重试、兜底的最小流程下面是一个较为完整的示例函数。它的职责是调用LLM审查合同风险解析JSON做业务校验失败重试最后兜底。# 文件路径llm_verified_flow.py import json from openai import OpenAI client OpenAI(api_keyyour-api-key) def extract_contract_risks(contract_text: str, max_retries: int 2): system_prompt ( 你是合同风险审查助手。 只输出JSON不要输出其他内容。 JSON格式{\risks\:[{\description\:\风险描述\, \level\:\high|medium|low\}]} ) messages [ {role: system, content: system_prompt}, {role: user, content: contract_text} ] for attempt in range(1, max_retries 1): try: resp client.chat.completions.create( modelgpt-4o-mini, temperature0.1, response_format{type: json_object}, messagesmessages, ) data json.loads(resp.choices[0].message.content) # 业务校验 risks data.get(risks, []) if not isinstance(risks, list): raise ValueError(risks must be a list) for r in risks: if description not in r or r.get(level) not in (high, medium, low): raise ValueError(risk item schema invalid) return data except Exception as exc: print(f第 {attempt} 次尝试失败: {exc}) # 兜底返回安全默认值而不是直接抛异常 return {risks: [], warning: llm_output_invalid} if __name__ __main__: result extract_contract_risks(甲方应在合同签订后10日内向乙方支付全部款项逾期视为违约。) print(result)这段代码看起来简单但已经是生产级的最小骨架。有三个关键点需要展开。第一校验必须紧跟解析。不要相信模型输出的JSON一定符合业务schema尤其要注意字段是否存在、枚举值是否合法。第二重试不是无限重试。网络抖动或偶发格式错误可以重试但如果模型始终产生非法输出就要快速失败进入兜底。第三兜底不能是简单的空值而是业务系统能安全处理的默认结果同时要记录日志和告警方便后续定位。5.2 更进一步RAG与Agent如果场景更严肃比如医疗、金融还可以在验证重试之上加一层多模型投票多个模型或多次采样比对结果如果分歧超过阈值就转人工队列。这种思路本质上还是在对冲不确定性。RAG和Agent架构也能降低随机性带来的风险。RAG把事实检索从参数记忆里分离出来让模型基于给定文档回答会显著减少“胡编”但不会完全消除随机性。Agent则把一次大调用拆成多步小调用每步之间用代码检查中间结果等于在每个决策点都加校验器。这里要提醒架构团队不要把Agent做成“prompt里塞一百条规则”的巨无霸。步骤越多随机性叠加越明显。要尽量让每一步输出可验证把不确定的地方交给流程引擎或人工来处理。6. 怎么科学评估垂直AI系统的稳定性很多团队评估LLM就是拿几个case试试然后拍脑袋说“效果不错”。这在垂直AI里远远不够。我们需要一套可重复的评估流程。6.1 建立Golden Set第一步建立golden set也就是一批有标准答案的问题样本。根据业务场景不同每个样本带上输入和期望输出类型。注意不一定要有逐字的标准答案但要有可判定的标准比如“风险等级是否合理”“输出是否包含某个关键点”。6.2 多次运行与指标第二步多次运行。由于有随机性每个样本至少要跑3到5次收集结果。第三步统计指标。常见的有格式合法率、字段填充率、语义相似度、人工通过率。对于分类或提取任务可以算准确率和召回率。下面是一个简化的评估脚本用来演示“重复运行并观察稳定性”的流程# 文件路径eval_stability.py # 演示版真实场景中把 llm_call 替换为你的模型服务 import random def llm_call(prompt, seed): # 这里用随机结果模拟LLM输出用于演示评估流程 candidates [ 合同缺少违约金条款, 合同缺少保密期限, 付款期限过短 ] return random.choice(candidates) golden_set [ {id: case_001, prompt: 审查这份合同风险, expected: 至少包含付款期限或违约金}, {id: case_002, prompt: 审查这份合同风险, expected: 至少包含保密条款}, ] repeat_k 5 results [] for case in golden_set: for seed in range(repeat_k): output llm_call(case[prompt], seed) results.append({case_id: case[id], output: output, seed: seed}) for case_id in [case_001, case_002]: outputs [r[output] for r in results if r[case_id] case_id] unique_ratio len(set(outputs)) / len(outputs) print(f{case_id}: 共 {len(outputs)} 次输出种类 {len(set(outputs))}随机度 {unique_ratio:.2f})真实场景中你需要把llm_call替换为真实模型服务并且要对输出做归一化和语义比对。比如两个完全不同的文案可能表达同一个意思这时候不能简单用字符串相等来判断是否一致。6.3 让评估进入CI/CD这个环节直接决定垂直AI系统的生死。很多项目上线前只测了10个case上线后用户数据一进来问题立刻暴露。比较务实的做法是把评估集做成一个自动化任务每次修改prompt、换模型、更新RAG知识库之后都自动跑一遍输出对比报告。被业内反复讨论的“AI工程师”本质上就是能把这套评估闭环跑起来的人。不要把评估当成上线前的一次性动作而要当成持续回归的工程能力。7. 常见问题与排查方法在垂直AI落地过程中下面几个问题出现频率很高这里列一个排查清单。问题现象可能原因排查方式解决方案相同提示词结果不同采样温度偏高seed未生效服务端多机部署检查请求参数重复调用20次统计输出分布调低temperature约定seed固定模型版本必要时本地部署输出JSON解析失败模型未遵守格式输出被max_tokens截断打印原始返回检查error和finish_reason使用response_format增大max_tokens增加解析兜底与重试偶尔输出明显错误信息模型幻觉缺少检索上下文对照输入检查prompt看是否缺少RAG补充RAG增加事实校验高风险场景人工复核业务指标不稳定时好时坏测试集过小只测试了单次输出检查评估集规模和重复次数建立golden set多次运行取平均模型更新后行为变化云厂商对模型升级prompt对模型版本敏感对比回归测试结果锁定模型版本快照升级前走评估流水线Agent任务中途失败子任务输出校验失败上下文过长查看每一步的日志和token消耗增加中间结果校验分步重试拆分任务排查时有一个基本原则先看原始返回内容不要只看最终渲染结果。很多问题在请求日志里就能看到原因比如截断、字段缺少、模型返回了空数组等。把这些日志结构化后面会省很多时间。8. 最佳实践与工程建议在泡沫里做“确定性优先”的垂直AI如果你准备做一个垂直AI产品这里有七条比较务实的建议。第一先想清楚这个问题是否必须要用LLM。很多垂直领域的自动化用规则、正则、统计分类器就能解决而且稳定、可解释。让LLM做它擅长的事而不是让它做所有事。第二给LLM定义契约。包括输入输出schema、错误码、超时和默认行为。不要允许自由文本满天飞更不要在业务核心链路里直接拼接模型返回的原始字符串。第三把“低随机性”当作默认配置。除非业务需要多样性否则优先使用temperature0、结构化输出、多轮校验。创意的优先级要排在稳定性之后。第四建立评估和观测体系。除了CPU、内存这些常规指标还要记录prompt、输出、耗时、token用量、用户反馈。每次迭代都跑回归测试。第五设计降级链路。规则系统、兜底文案、人工工单任何一个环节都能在模型异常时接管。千万不要让用户直接面对模型出错时的“白屏”。第六重视安全与合规。LLM输出不能直接用于医疗、法律、金融等高影响决策需要人工审核时不要省。数据要按最小权限访问敏感数据建议脱敏后再调用外部API。涉及生产环境变更先备份、再灰度、后回滚。这些不是形式主义而是在不确定性之上做兜底。第七团队心智同步。要让产品、销售、客户都理解“AI不是100%准确”在服务协议和产品说明里明确人工复核边界。很多项目最后不是死在模型效果上而是死在预期管理上。如果你要做垂直AI产品我建议从“最好的模型最稳的工程”切换到“足够好的模型最强的校验”。很多时候稳定性和可维护性比单次效果更重要。在泡沫期能够稳定交付比什么都值钱。9. 总结与后续学习方向回到标题为什么是垂直AI泡沫不是因为LLM不强大而是因为我们在忘记一个事实——LLM会掷骰子。模型能力越强人们越容易相信它的输出是确定答案工程链路越简陋这种错误信任爆雷的概率就越高。真正能穿越周期的垂直AI公司不是把模型调得多聪明而是把随机输出管理得多稳定。如果你正在做这类项目下一步可以按这个顺序实践先把一个业务场景跑通记录它最不稳定的输出然后加上结构化输出和校验重试再建一个20条样本的评估集重复跑几次看稳定率最后把评估接入CI让每次prompt或模型更新都留下可对比的记录。做完这四步你对“LLM随机性”的理解会比大多数只在demo上见过AI的人深得多。后续值得深入的方向包括RAG与知识库增强、Agent可观测性、多模型路由、特定业务的局部微调、评估框架的二次开发。这些内容都可以在真实项目里继续验证。如果你在生产中遇到过最离谱的LLM输出欢迎在评论区写出来那会是最好的反面教材。