最近 AI 圈有一句讨论度很高的话“垂直 AI 的泡沫是因为我们总是忘记 LLM 本质是在掷骰子。”这句话听起来很刺耳但作为经常和 LLM 应用打交道的人我觉得它点中了一个被反复忽略的工程事实LLM 的输出不是一个确定性的函数结果而是对概率分布的采样。同样一个问题你可以用 temperature0 让它尽量稳定但只要模型参数量足够大、输入分布稍微偏移它依旧会给出不一样的答案。很多垂直 AI 项目在 Demo 阶段看起来非常好用一旦进入生产环境就开始“抽风”。这篇文章不打算唱衰 AI而是想认真拆解几个问题LLM 到底为什么会“掷骰子”垂直 AI 的泡沫是怎么被预期撑起来的作为开发者我们应该用什么样的工程方法来应对这种随机性以及最关键的如果你的团队正在评估“要不要在这个垂直场景里引入 LLM”应该先做哪些判断。文章会从模型机制讲到工程实践包含可复现的代码示例、自动评估思路、Agent/RAG 的边界以及一套落地的可行性检查清单。适合正在做 LLM 应用开发、技术选型或产品设计的人阅读。1. 核心认知速览先给一张速览表把本文反复出现的几个概念和工程影响放在一起方便后面阅读时对照。概念一句话理解对垂直 AI 的工程影响LLM通过预测下一个 token 的概率来生成文本的模型输出天然带有随机性不能当作确定性函数温度采样控制概率分布尖锐程度的参数temperature 越高输出越发散越低越接近 greedyTop-P / Top-K截断采样候选集合的常见策略影响生成多样性也影响长文本稳定性fp16 / bf16模型推理时常用的低精度表示会带来极小的数值差异但不会改变“随机性”本质RAG检索增强生成先取回文档再生成用外部知识框定答案范围是压缩随机性的重要手段Agent 编排让 LLM 调用工具、多步决策的框架单次随机性被多步放大需要校验、重试、人工兜底结构化输出让模型按 JSON / Schema 输出解决了解析问题但不解决事实正确性问题垂直 AI面向特定行业或场景的 AI 应用行业越垂直用户对“确定性”的期望越高矛盾越突出自动评估用评估集和指标代替“肉眼看好不好”是应对不可复现的核心工程手段不能靠拍脑袋验收从这张表能看出来垂直 AI 项目真正的问题不是“模型不够聪明”而是“大家默认它应该像传统软件一样稳定输出但它底层并不是这么设计的”。下面展开讲。2. 为什么说 LLM 本质是在掷骰子2.1 next-token prediction 决定了随机性今天的 LLM无论是 GPT 系列、Llama 系列还是 Qwen 系列核心训练目标基本都是“根据上下文预测下一个 token 的概率分布”。模型内部会对词表里的每一个 token 算出一个 logit再通过 softmax 转成概率最后决定生成哪个 token。这里的关键点是模型在决策新 token 时不是从所有候选里选“唯一正确答案”而是按照概率分布采样。即使某个 token 的概率高达 0.9只要不是 1.0采样器依然可能选到剩下那 0.1 里的 token。也就是说同一个 prompt模型每次生成都可能不一样。很多刚接触 LLM 的开发者会做一个简单实验# 伪代码示例展示不同 temperature 下的重复调用差异 import random def generate_with_temperature(prompt: str, temperature: float) - str: # 实际应调用本地或云端 LLM 接口这里只表达调用逻辑 response llm_client.chat( messages[{role: user, content: prompt}], temperaturetemperature, ) return response.content for temp in [0.0, 0.3, 0.8]: outputs [generate_with_temperature(请用一句话介绍 LLM, temp) for _ in range(3)] print(ftemperature{temp}:) for out in outputs: print( -, out)temperature0 时输出基本稳定temperature0.8 时三次结果很可能完全不同。这个实验几乎每个做过 LLM 开发的人都见过。2.2 温度、Top-P 和采样策略为了控制随机性模型服务通常会开放 temperature、top_p 等参数。temperature缩放 logits 后再做 softmax。温度越低高概率 token 的优势越明显温度趋近 0 时等价于总是选最高概率的 token也就是 greedy decoding。top_p只从累计概率达到 p 的最小 token 集合里采样。top_p0.9 意味着丢掉那些概率很低的尾部 token。top_k只保留概率最高的 k 个 token 参与采样。需要注意的是把 temperature 调到 0 并不能让模型变得 100% 可复现。一方面浮点运算、并行推理、显存状态都可能带来微小差异另一方面即使同一个输出序列模型也未必在“逻辑正确”的意义上稳定。greedy 只会让生成过程的随机性变小不会让模型变成一个确定性符号计算器。2.3 fp16 / bf16 精度会改变“骰子”吗很多关注本地大模型的人会讨论 fp16、bf16、fp32 的精度差异。这个讨论本身有意义因为它会影响推理时的数值稳定性和生成效果。fp32精度最高但显存占用和计算量也最大。fp16表示范围有限容易出现溢出或舍入误差。bf16指数范围和 fp32 一致但尾数精度更低在训练和推理中越来越常见。低精度推理会让 logits 产生极小的数值扰动。这种扰动在极端情况下会改变某个 token 的排序最终影响输出。但真正让 LLM“像掷骰子”的不是低精度本身而是模型天生的概率采样机制。即使全部使用 fp32只要采样策略存在输出依然会随机。所以在工程上可以先把精度问题放到“性能优化”这个维度而不是“如何让模型不随机”这个维度。2.4 高智商不等于高可靠LLM 能写出看起来很有逻辑的文本能通过很多考试题这让很多人误以为它“理解”了规则。但模型本质上是在做序列预测它没有在内部运行一套严格的业务规则。举个例子让模型做一个简单的加法“123456 654321”它也许能答对但如果把数字换成更长的位数或者故意制造一些容易混淆的格式模型可能就会出错。这并不意味着 LLM 不能用而是说垂直 AI 场景往往需要的是“高可靠”而 LLM 给的是“高能力但概率性正确”。这两者之间的差距就是泡沫形成的地方。3. 垂直 AI 泡沫是怎么形成的3.1 垂直 AI 的诱惑垂直 AI 指的不是通用聊天助手而是针对某个具体行业或岗位的 AI 应用比如法律合同审查、医疗问诊辅助、金融文档分析、工业质检报告生成等。这类场景的吸引力很明显数据更聚焦不需要模型掌握所有领域的知识。用户痛点明确付费意愿也更强。如果真能落地价值可以量化为节省了多少人力。于是大量创业公司选择“垂直 AI”作为切入点在融资 PPT 里写“AI 替代 50% 的初级律师工作”之类的故事。3.2 错误预期把 LLM 当成数据库和规则引擎泡沫的核心来自预期错位。垂直行业用户最需要的是“稳定、可审计、可复现”的系统。但 LLM 是一个“概率文本生成器”。常见的错误期待包括“我问它一个事实它应该给我一个准确的答案”——但 LLM 没有内置事实数据库它靠参数记忆幻觉无法根除。“同一个流程今天跑和明天跑应该一样”——但采样策略决定了它可能不一样。“它应该按照业务规则严格判断”——但业务规则如果只写在 prompt 里模型随时可能漏掉或误读。这些期待放在传统软件里非常合理但放在 LLM 上就变成了“把骰子当计算器用”。3.3 Demo 成功与生产可用之间的鸿沟很多垂直 AI 产品在 Demo 阶段演示的是精挑细选过的案例。开发者也确实可以通过调 prompt、调 few-shot、调后处理让某几条数据表现得非常完美。但到了生产环境输入分布根本没有边界。用户可能上传格式奇怪的表格、带口音的语音、生僻词极多的合同、模糊不清的图片。模型在训练数据里见过的分布和线上真实分布一旦出现偏移输出质量就会断崖式下降。更麻烦的是这种下降不是每次都发生。它可能一周出现一次但每次出现都直接影响业务而你又无法用“重试一次”来向客户解释。3.4 叙事、资本与同质化过去两年AI 应用层的叙事吸引了很多资本垂直 AI 几乎是标准答案之一。于是大量团队涌进同一个赛道用相似的模型、相似的 prompt 模板、相似的 RAG 流程。这类产品在早期很难拉开差距最后拼的往往是销售渠道和成本控制而不是技术壁垒。当大家用同一个基础模型做垂直应用时模型本身的随机性问题不会消失只会从模型层传导到应用层。一旦某个环节出问题用户会觉得“这个 AI 产品不行”而不是“prompt 该调了”。4. 对 LLM 应用开发的工程影响4.1 不可复现冲击测试体系传统软件开发里同一份代码、同样的输入几乎一定会得到相同的输出。测试用例可以稳定回归。而 LLM 应用天然不具备这种确定性这导致两个问题线下验收时“这次通过了”上线后可能失败。回归测试时上一次跑过的用例这次未必能通过。因此LLM 应用不能只准备几个“冒烟测试”用例而应该建立评估集、指标和统计回归机制。你不能只用一条 prompt 判断“效果好不好”而要用几十条、几百条覆盖正常值和边界值的样本观察整体通过率。# 一个非常简单的自动化评估脚本示例 import json from statistics import mean def evaluate(prompts, expected, llm_call): results [] for prompt, exp in zip(prompts, expected): output llm_call(prompt) ok exact_match_rule(output, exp) # 换成实际校验逻辑 results.append(ok) pass_rate mean(results) if results else 0.0 print(fpass_rate: {pass_rate:.2%}, total: {len(results)}) return pass_rate这里的 exact_match_rule 需要结合业务定义比如 JSON 合法、关键字段存在、数值在合理范围内。4.2 结构化输出与校验层为了让 LLM 的输出能被下游系统消费主流方案是让它返回 JSON配合 function calling 或 JSON mode。这能很大程度解决“解析失败”的问题但并不能解决“字段值不对”的问题。模型可以输出一个格式完美的 JSON但里面的金额、日期、人名是错的。所以工程上必须再加一层校验包括字段是否存在、类型是否正确、值是否在合理范围、是否符合业务规则。from pydantic import BaseModel, ValidationError class ContractInfo(BaseModel): party_a: str party_b: str amount: float signed_date: str def validate_llm_output(raw: str) - ContractInfo: data json.loads(raw) try: info ContractInfo(**data) except ValidationError as e: print(schema 校验失败:, e) raise # 这里还应该继续检查业务规则比如金额 0 if info.amount 0: raise ValueError(金额必须大于 0) return info4.3 RAG 的真正作用压缩答案空间很多人对 RAG 的理解是“让模型拥有实时知识”这没错但更本质的作用是压缩模型的答案空间。当模型只能基于检索出的几篇文档来回答时它“发挥”的范围会小很多。因为没有相关文档模型就少了很多胡乱编造的依据。在垂直 AI 场景里RAG 不是可选项而是降低随机性的重要手段。但要注意RAG 并没有消除随机性它只是把答案约束到一个更窄的上下文里。如果检索到的文档本身不相关模型依然可能一本正经地胡说八道。所以 RAG 系统还需要单独的检索质量评估。4.4 Agent 框架的兴起是因为单次调用不够可靠最近一两年Agent 和编排框架非常火。从早期的 LangChain到后来的 LangGraph、MCP再到各种云平台自带的工作流本质都是在解决一个现实问题单次 LLM 调用不可靠所以需要把任务拆成多次调用中间插入工具、记忆、校验和人工审批。例如一个合同审查 Agent可以先调用抽取模型提取关键信息再调用规则引擎检查条款风险最后交给人工复核。每一步模型只做一个小任务出错的影响范围被限制了。MCPModel Context Protocol这类标准化协议的兴起也说明行业正在把“模型能力”和“工具能力”解耦。LLM 负责理解和生成外部工具负责确定性的计算和数据查询。这本身就是对随机性的一种对冲。4.5 成本、延迟与人工兜底增加校验、重试、多轮 Agent 调用必然带来成本上升和延迟增加。这是垂直 AI 落地时必须算的账。一次调用改三次调用token 成本可能上升 2~3 倍。加入重试机制后P99 延迟会明显增加。注入人工审批环节意味着不能做到“全自动”但可以换来可靠性和审计能力。很多团队在 Demo 里能跑通是因为没有算这些账一上线就因为成本或延迟被业务部门 pass 掉这种情况并不少见。5. 工程上如何应对“掷骰子”5.1 通过参数降低随机性最直接的方法是把 temperature 调低。在生产环境里如果任务偏向抽取、分类、结构化输出建议从 temperature0 开始测如果需要创意写作、头脑风暴再适度调高。此外可以做多次采样投票。让同一个 prompt 生成 N 个结果再用规则或另一个模型挑选最一致的答案。这种方式能提高稳定性但代价是 token 成本线性上涨。def generate_consistent(prompt: str, n: int 3) - str: outputs [llm_client.chat(prompt, temperature0.2) for _ in range(n)] # 简单策略返回出现次数最多的结果 from collections import Counter counter Counter(outputs) return counter.most_common(1)[0][0]不要以为 temperature0 就万事大吉。它只能减少随机性不能解决事实性错误也不能保证模型在边界输入上做出正确判断。5.2 让 LLM 只当“生成器”不当“决策器”高可靠场景里的 LLM 应用最稳的架构是LLM 生成候选内容规则引擎 / 数据库 / 人工来做最终决策。比如一个客服工单分类系统可以让 LLM 从工单里抽取关键词和问题描述然后用规则确定类别。再比如医疗问诊LLM 可以整理患者主诉但诊断决策必须由医生完成。把“生成”和“决策”分离能用最少的成本换最大的可靠性。5.3 建立自动化评估与回归垂直 AI 项目上线后一定要有持续评估机制。建议至少准备三种测试集黄金样本集几十条经过人工验证的高质量样本。边界样本集包含缺字段、格式错误、语义模糊等异常情况。线上回流集从真实日志里抽样定期补充进评估集。每次升级 prompt、换模型、调参数都要跑一遍评估集对比通过率。如果没有明显提升不要贸然上生产。5.4 输出约束与格式校验用约束解码可以提高格式稳定性。像 Outlines、Guidance 这类库可以在解码阶段限制输出必须符合某个 JSON Schema 或正则。这样模型不会产生“JSON 尾巴上多一个逗号”之类的低级错误。# 概念示例使用约束解码库时的大致写法 # 实际代码需按所选库的 API 调整 import outlines model outlines.models.transformers(your_model_path) schema { type: object, properties: { name: {type: string}, amount: {type: number} }, required: [name, amount] } generator outlines.generate.json(model, schema) result generator(从这段文本里提取合同双方和金额) print(result)但再次强调约束解码只保证格式合法不保证业务正确。5.5 校验-重试-升级循环在生产代码里我会把 LLM 调用封装成“校验-重试-升级”的循环。第一次调用如果输出没通过 schema 或业务校验就带着错误信息重新让 LLM 生成一次连续失败超过 N 次则转人工处理或返回系统异常。def call_with_retry(prompt: str, validator, max_retries: int 2) - str: last_error None for i in range(max_retries 1): raw llm_client.chat(prompt, temperature0.2) try: data json.loads(raw) validator(data) return data except Exception as e: last_error e print(f第 {i 1} 次校验失败: {e}) # 把错误信息回填给模型让它自我修正 prompt f{prompt}\n前一次输出无法通过校验错误: {e}请重新生成。 raise RuntimeError(f重试 {max_retries} 次后仍失败: {last_error})这个模式非常简单但能挡住很多低级错误。5.6 不确定性感知与转人工更高级的做法是让系统“知道自己不确定”。可以通过让模型输出置信度或者设计一致性检测让同一个 prompt 生成两次如果两次结果差异很大说明模型在这个输入上不够确定此时自动转人工。这对于银行、法律、医疗等高合规场景特别重要。永远不要在高风险场景里做“全自动无人值守”至少要留一个“不确定就转人工”的开关。6. 垂直 AI 项目的可行性评估框架6.1 自检问题清单在立项之前建议先回答下面几个问题这个任务是否真的需要“生成新文本”还是仅仅需要“检索已有答案”如果答案是唯一的能否用规则、数据库、查找表直接实现任务允许出错的概率是多少如果一次错误导致几万元损失是否还能接受是否可以用 RAG 明确限定答案范围是否有足够的测试集来验证效果而不是靠几条 Demo是否有人工复核环节人工复核的成本是否低于“全自动错误修正”的成本模型的输出是否会被第三方审查如果需要解释“为什么给出这个结论”LLM 是否满足要求如果答案大多是“不能接受随机性”和“不能提供人工兜底”那这个场景可能不适合 LLM至少不适合用 LLM 做核心决策。6.2 风险分级表风险等级典型场景LLM 角色建议方案低风险客户评论摘要、内部周报生成、会议纪要初稿生成初稿允许随机性可人工修改中风险客服回复草稿、文档抽取、辅助编程生成候选加规则校验、RAG 限定、人工抽查高风险合同审核、医疗建议、金融交易决策绝不直接决策模型只做信息抽取和建议最终由专业人员审批垂直 AI 产品想要落地通常是把高风险任务拆成低风险的任务序列而不是让模型一步到位做最终决策。7. 常见误区与排查方法很多垂直 AI 项目翻车不是模型不行而是工程预期和手段出了问题。下面把高频问题整理成一张排查表。误区 / 问题现象可能原因排查方向解决方向加了“必须准确”后依然出错prompt 不是约束机制模型无法严格遵守指令检查错误是否集中在某些边界输入引入 RAG、约束解码、规则校验而不是继续调 prompt测试时效果好上线后变差测试集太小或者没有覆盖真实输入分布统计线上失败样本对比与测试集差异建立线上回流集持续补充评估数据同一段代码多次请求返回不同结果温度或 top_p 设置过高检查推理参数和采样策略生产场景调低 temperature必要时固定 seed输出格式经常解析失败缺少结构化输出约束检查是否开启 JSON mode 或 function calling使用 JSON Schema 约束增加解析失败重试RAG 检索到的内容不相关检索链路有问题或知识库切分不合理单独评估检索 Top-K 命中率优化 embedding 模型、切分策略、重排序Agent 多步任务经常死循环每步决策都有随机性错误被放大查看中间步骤日志定位决策错误点为 Agent 步骤增加强校验、最大步数限制、人工审批模型输出的内容看起来合理但事实错误LLM 幻觉无法完全消除用“事实一致”指标做专项评估增加外部知识源和引用溯源高风险场景只做辅助低精度推理后效果波动fp16/bf16 带来数值扰动对比 fp32 与低精度的输出差异若波动影响业务降低量化程度或增加后校验排查时先分清楚问题出在模型层、检索层还是应用层。不要一上来就换模型先把输入输出日志、评估集和重试机制补齐。8. 垂直 AI 不是泡沫但要换一种建法8.1 成功项目的共性那些真正跑起来的垂直 AI 项目往往有几个共同特征场景范围非常窄已经预设了明确的答案空间。有结构化的知识库或数据库兜底。有严格的校验和人工复核流程。把“AI 替代人”改成了“AI 增强人”。比如法律科技里最常用的不是“让 AI 帮你打赢官司”而是“让 AI 先快速定位相关法条和过往案例”。这本质上是用 LLM 做信息筛选而不是做最终决策。医疗 AI 也一样能落地的多是辅助分诊、病历结构化整理而不是自动诊断。8.2 垂直 AI 真正的壁垒很多人以为垂直 AI 的壁垒是“我有一套精心设计的 prompt”其实 prompt 太容易被复制了。真正的壁垒是行业数据的积累和清洗能力。与现有业务系统的深度集成。完整的数据反馈闭环每次人工修正都能反哺评估和微调。对安全、合规、审计要求的理解和落地能力。模型一直在变但行业工作流和信任关系不会轻易变。谁能在 LLM 的随机性和业务确定性之间架好一座桥谁才能把垂直 AI 真正变成可持续的产品。8.3 最小可运行的落地清单如果你现在正要启动一个垂直 AI 项目建议按这个顺序走先定义一个极其具体的单点任务不要一开始就做“全能助手”。准备 30~50 条覆盖正常和异常情况的测试样本。写一个简单的自动评估脚本统计通过率。先尝试纯 prompt 方案评估通过率不达标就加 RAG。加结构化输出和 schema 校验确保下游能稳定消费。加上重试机制和人工兜底再小范围灰度上线。上线后持续回流线上数据定期回归评估迭代 prompt 和检索策略。这套流程没有人能一步到位但能让你在“AI 掷骰子”的现实下依然交付一个可用的系统。垂直 AI 的泡沫不会因为批判而消失但工程化的严谨可以让它少一点也让你做出来的产品更扎实一点。