之前在看垂直AI方向的项目方案时最常听到的一句话是“用大模型把XX流程自动化”。这句话本身没有问题但很多团队在实际落地时会把大模型当成一个“只要提示词写得好输出就稳定可靠”的确定性组件。等到系统上线后才发现同一个问题换一天问结果可能完全不一样同一个用户问题换个说法模型给出的答案可能从正确直接退化成离谱。更麻烦的是这类问题往往没有堆栈、没有异常日志只会表现为“线上准确率莫名下降”。这篇文章想围绕一个核心观点展开我们一直高估了垂直AI的确定性却低估了LLM的随机性。LLM在推理时本质上是在“掷骰子”——从概率分布中采样token来生成结果。垂直AI泡沫之所以会出现不是因为大模型能力不够强而是因为很多产品在工程上假装它不会出错把一个概率行为当成了可以承诺的规则引擎来交付。文章会先从概念上拆解“LLM Roll Dice”到底指什么再分析垂直AI泡沫是如何形成的然后给出一套可以落地的工程方案包括评测集、结构化输出、人机回环、可观测性等内容最后附上完整示例代码和常见坑点。无论你是刚开始接触LLM应用开发还是已经在做RAG、Agent、客服质检等垂直AI项目这篇文章都能帮你避免一些非常昂贵的返工。1. 背景为什么说LLM在“掷骰子”1.1 概率语言模型的基本直觉要理解“LLM Roll Dice”这个比喻需要先抛开“模型很聪明”这层直觉。一个大型语言模型在结构上其实是一个参数规模很大的概率分布模型。它做的事情是给定一段文本作为上下文然后计算“下一个token”的概率分布。举个例子输入“中国的首都是”模型内部会计算所有候选词的概率比如“北京”可能是0.8“南京”可能是0.05“上海”可能是0.03。模型并不是从知识库里检索出答案而是在这个概率分布上采样一个token接着把新token接到上下文里继续预测下一个token。整个过程循环往复直到生成结束符。这个过程的每一步都有概率性。即使是同一个Prompt只要采样策略不同最终生成的句子就可能不同。温度越高低概率token被选中的机会越大输出越“发散”温度越低模型越倾向于选择高概率token输出相对稳定。但“相对稳定”不等于“永远一致”这一点对垂直AI产品影响极大。1.2 “Roll Dice”到底指什么很多技术文章会用“掷骰子”来形容LLM的随机性但它并不是完全均匀随机的意思。更准确地说LLM是在一个极其复杂的高维概率分布上做随机采样每次生成相当于从一个“巨大骰子”里掷出结果。这个骰子的各个面并不是等概率的哪些面更容易出现取决于训练数据、模型参数、提示词、采样参数和推理后端。“Roll Dice”的关键含义是同样的输入模型可能给出多个合法答案。其中有些答案符合预期有些答案偏离预期甚至有些答案是凭空编造的。这就是我们在生产环境中经常遇到的“非确定性”问题。对于搜索引擎、API网关这类传统系统相同的请求几乎必然返回相同结果但LLM没有这个保证。只要产品逻辑里默认了“结果唯一且可复现”那么线上迟早会出现不符合预期的输出。尤其是垂直AI场景业务方常常要求系统必须给出“正确的”“唯一的”结论。比如保险理赔初审、银行对公材料抽取、医疗问诊辅助用户不会接受模型偶尔换个说法。但如果我们没有在系统层面处理随机性那么产品效果就真的像在掷骰子。1.3 从“生成”到“对话”的不稳定性有些开发者会问我使用的时候把temperature设置为0结果不是稳定的吗这个问题需要分两层看。第一temperature0 通常会让模型走贪心解码也就是每一步都选概率最大的token因此大多数时候输出是确定的。但在实际部署中推理框架往往做了并行计算、批处理、KV Cache、浮点算子优化等不同GPU、不同batch、不同推理引擎之间仍然可能出现微小数值差异。此外部分模型支持top_p、top_k、重复惩罚、频率惩罚这些参数叠加后会让概率分布再次变化。第二很多产品不是只跑一次模型调用而是先做意图识别再做RAG检索再让模型生成答案。RAG检索结果本身就可能因为向量化模型的随机性、召回阈值、重排策略而不同。即使LLM输出固定前面的检索结果变了后面生成的内容也会跟着变。所以“掷骰子”不仅存在于模型生成层也存在于整个AI应用链路的多个环节。2. 垂直AI泡沫是如何形成的2.1 垂直AI的典型定义与商业叙事垂直AI通常指针对某个具体行业或场景定制的大模型应用。比如法律文书审查、企业财务问答、客服工单自动分类、医疗报告解读、招聘简历筛选等。相比于通用AI助手垂直AI强调“业务纵深”和“可落地”往往会把行业知识、私有数据、业务规则和大模型组合在一起形成一套解决方案。这种商业模式本身是有价值的但市场上很多垂直AI产品在叙事上会走同一个套路先用一个漂亮的Demo证明大模型能理解行业术语然后对外宣称“我们解决了行业痛点”最后在交付阶段才发现真实业务数据远比Demo复杂模型输出稳定性也不达标。于是项目从一个“AI创新项目”变成一个“数据清洗和人工标注项目”成本直线上升ROI很难算过来。2.2 三根支柱API包装、提示词、向量库从工程结构看目前很多垂直AI产品都建立在三根支柱上。第一根是API包装。团队通过调用外部大模型API或部署开源模型的推理服务把LLM当作一个黑盒能力自己只负责封装输入输出和业务逻辑。这种方式上手快但很难对模型内部的随机性做深入控制。第二根是提示词工程。团队把行业知识、规则约束、少样本示例写进Prompt希望模型“按照要求”输出。提示词确实能显著影响模型行为但它的效果高度依赖模型版本和上下文模板。一旦模型版本升级同样的提示词效果可能变差一旦用户问题的表达方式超出模板覆盖范围模型就很容易跑偏。第三根是向量库和RAG。团队把业务文档切片、向量化后存入向量数据库检索相关片段再交给模型生成答案。这解决了部分知识实时更新的问题但也引入了检索质量的变量。切片大小是否合理、召回片段是否相关、拼接后上下文是否冲突都会影响最终输出。这三根支柱本身没有错问题是很多团队只用了这三根支柱却没有配套的评测、监控、降级和人工复核机制。于是产品在Demo阶段看起来很聪明在样本集上准确率也很高但真实流量一进来所有隐藏的随机性问题都会暴露。2.3 泡沫的源头把随机结果当确定性API垂直AI泡沫的源头我认为不是“模型不够强”而是“工程假设错了”。团队把一个概率模型抽象成了“确定性API”来使用进而向客户承诺了不该承诺的稳定性。传统软件系统的接口是确定性的传入同样的参数返回同样的结果这是可以写进测试用例和SLA的。即使遇到异常系统也会抛出一个明确的错误。但LLM不会抛“Not UnderstandException”它会一本正经地生成一段合理但错误的回答。更麻烦的是这种错误还可能是随机的上一轮正确下一轮错误没有明确规律。当产品对外承诺“准确率达到95%”时如果没有先定义清楚评测集、测试方法和多次运行的波动范围这个数字本身就是不可靠的。同样的100条测试数据今天跑可能是97%准确率明天跑可能变成91%单次测试结果完全没有统计意义。垂直AI泡沫正是建立在这样的“单点评测”之上一次Demo效果好就被误认为模型能力已经达标。2.4 容易被忽略的退化场景除了基础的随机性垂直AI还容易在几个特殊场景下“退化”。第一个场景是长尾用户输入。业务用户在真实使用时并不会按测试集说话他们可能输入错别字、口语化表达、行业黑话、中英文混用。模型如果只见过标准表述遇到长尾输入后输出质量可能明显下降。第二个场景是提示词被污染。如果系统允许用户输入自由文本并且把用户输入直接拼进Prompt就存在提示词注入的风险。恶意用户可以通过构造输入让模型忽略系统指令输出越狱内容或执行意外操作。第三个场景是知识冲突。RAG检索回来的文档片段可能包含过时信息、错误信息或者与模型内置知识相矛盾。模型不知道应该相信哪一边于是可能两边内容混在一起生成一个看似通顺但事实混乱的答案。第四个场景是上下文超长。当多轮会话或大文档被压缩到上下文窗口时模型会遗忘早期关键信息或者把不相关的信息误当成约束条件。此时系统表现出的“不稳定”表面上像随机问题实际上是上下文管理不当。3. 从工程角度理解LLM的概率性3.1 temperature、top_p与采样过程在LLM推理服务中最常调整的采样参数是temperature和top_p。temperature用于缩放token概率分布数值越低分布越尖锐模型越倾向于高概率token数值越高分布越平滑低概率token被采中的可能性越大。top_p则用于截断候选集只保留累积概率超过阈值的token再在这个子集内采样。虽然大多数平台默认推荐temperature0来追求确定性但它并不能完全保证结果可复现。一方面部分推理框架在实现贪心解码时仍可能存在浮点数舍入差异另一方面如果应用层有多个模型调用任何一层的参数不同都会导致最终结果不同。更合理的做法是把“temperature0”当成一种尽力而为的稳定性优化而不是银弹。3.2 同一个Prompt多次调用输出的差异我们可以用一个最简单的实验来观察这种差异。假设你调用同一个聊天模型同一个system prompt和user prompt设置temperature1.0调用5次结果很可能会看到不同的表述和不同的结论。即使设置temperature0如果改用了不同的推理后端结果也可能出现差异。这个现象本身并不可怕真正可怕的是产品层没有意识到它。比如客服工单系统根据LLM判断“用户是否强烈要求投诉”如果模型十次里有两次判断为“是”五次判断为“否”还有三次判断为“需要人工确认”那这个自动分类就是不可用的。要想让系统变得可靠不能只靠改Prompt还要从评估指标和业务决策上引入容错机制。3.3 不同模型版本与推理后端导致的差异除了采样参数模型版本和推理引擎也会影响输出稳定性。商用模型API经常做后台升级同一套Prompt在上个月和这个月可能产生不同答案本地部署的开源模型如果从Transformers切换到vLLM、TensorRT-LLM等推理框架由于算子实现和批处理方式不同输出也会出现微小差异。在垂直AI工程中这种差异经常会表现为“为什么昨天还好好的今天突然不行了”。排查时要注意把问题拆开是先检查提示词被修改了还是检查模型API版本变了再做线上和测试环境的结果比对。如果不把模型版本、推理参数、依赖包版本都固定下来问题排查就会非常困难。3.4 概率性在评估中的意义正因为LLM是概率模型做评估时就不能使用“跑一遍测试集得到准确率”这种简单方式。应该把每次调用看作一次采样用多次运行的结果来评估系统的稳定性和期望质量。评估一个垂直AI系统时至少要分成两个维度质量维度生成的答案是否正确、是否满足业务要求。稳定性维度多次运行时答案是否保持一致关键字段是否稳定。质量维度可以用精确匹配、语义相似度、人工评分、LLM-as-Judge等方式量化。稳定性维度则需要记录同一输入多次运行的结果计算差异率、字段级一致性、推荐结果波动性等指标。只有两个维度都达标系统才适合被嵌入生产流程。4. 完整实战构建一个“防骰子”的垂直AI接口4.1 需求与设计为了把上面的概念落实到代码里这里我们设计一个简化的垂直AI场景客服质检助手。输入一段用户与客服的对话由系统判断“用户情绪类别”和“是否需要人工介入”并返回结构化JSON结果。这个场景足够简单但包含了垂直AI的核心问题输出不稳定模型可能把“愤怒”识别成“焦虑”。格式不稳定模型可能输出多余解释导致JSON解析失败。业务错误模型可能漏掉需要人工升级的情况。我们的目标是构建一个可运行的服务具备三个能力统一调用LLM并设置较低温度。使用JSON Schema或Pydantic模型校验输出。增加重试和降级策略当模型连续输出非法结果时自动转人工处理。4.2 环境准备与版本说明本文示例使用Python 3.10及以上版本以OpenAI Python SDK调用一个OpenAI兼容接口。实际项目中你可以换成任何支持OpenAI协议的大模型服务比如本地的vLLM、Ollama、国内云厂商的兼容网关等。版本方面为了避免误导这里不写死具体版本号建议在requirements.txt中锁定你实际使用的版本。openai1.0.0 pydantic2.0.0 python-dotenv1.0.0安装依赖pip install -r requirements.txt还需要准备环境变量export OPENAI_API_KEY你的API Key export OPENAI_BASE_URLhttps://你的模型服务地址注意如果你的模型服务不需要API Key可以传一个占位字符串。4.3 项目结构为了便于理解我们使用一个小型项目结构vertical-ai-guard/ ├── requirements.txt ├── .env ├── main.py # 入口简单示例 ├── evaluator.py # 评测脚本 └── ai_guard.py # 核心业务逻辑这里的文件不算多但足够展示“业务逻辑、模型调用、评测脚本”分离的思想。4.4 核心代码带结构化输出与降级策略的服务先编写核心业务文件ai_guard.py。它负责调用模型并确保输出能够被解析成我们需要的结构化对象。# 文件路径vertical-ai-guard/ai_guard.py import json import os from typing import List from openai import OpenAI from pydantic import BaseModel, Field, ValidationError # 读取环境变量 OPENAI_API_KEY os.getenv(OPENAI_API_KEY, dummy) OPENAI_BASE_URL os.getenv(OPENAI_BASE_URL, https://api.openai.com/v1) client OpenAI(api_keyOPENAI_API_KEY, base_urlOPENAI_BASE_URL) # 定义我们希望模型输出的结构化结果 class QAResult(BaseModel): emotion: str Field(description用户情绪只允许取值为正常、焦虑、愤怒、失望) need_human: bool Field(description是否需要人工介入) reason: str Field(description判断理由不超过50字) SYSTEM_PROMPT 你是一个客服质检助手。 请根据用户与客服的对话内容判断用户的情绪类别并决定是否需要人工介入。 要求 1. 只输出JSON对象不要输出任何解释。 2. JSON必须包含 emotion、need_human、reason 三个字段。 3. emotion只能取正常、焦虑、愤怒、失望。 4. 如果用户表现出明显的愤怒、重复投诉或威胁退款need_human必须为true。 def build_user_prompt(dialogue: str) - str: return f对话内容\n{dialogue} def parse_result(content: str) - QAResult: 尝试解析模型输出并做一次兜底清理。 text content.strip() # 去除可能出现的 json 代码块标记 if text.startswith(): text text.strip() if text.startswith(json): text text[4:] text text.strip() # 尝试找到JSON部分 try: data json.loads(text) return QAResult(**data) except (json.JSONDecodeError, ValidationError) as exc: raise ValueError(f模型输出格式非法: {content[:200]}) from exc def ask_guard(dialogue: str, temperature: float 0.0, max_retries: int 2) - QAResult: 调用模型并做格式校验和重试。 如果模型连续max_retries次都无法输出合法JSON则返回一个安全的降级结果。 在实际业务中这个降级结果应该触发告警并将该条会话转人工处理。 messages [ {role: system, content: SYSTEM_PROMPT}, {role: user, content: build_user_prompt(dialogue)}, ] last_error None for attempt in range(max_retries 1): try: resp client.chat.completions.create( modelos.getenv(LLM_MODEL, gpt-4o-mini), messagesmessages, temperaturetemperature, response_format{type: json_object}, # 如果模型支持则保留 ) content resp.choices[0].message.content return parse_result(content) except ValueError as exc: # 格式解析失败重试 last_error exc messages.append({role: user, content: 上一轮输出不是合法JSON请重新只输出JSON对象。}) except Exception as exc: # 网络、限流等异常 last_error exc break # 降级返回宁可转人工也不能误判 return QAResult(emotion正常, need_humanTrue, reasonf模型连续输出异常已自动转人工。错误{last_error})这里有几个关键点parse_result做了两层兜底先尝试去除代码块标记再尝试JSON解析。如果输出格式不合法会向模型追加一条“请重新输出JSON”的消息而不是直接把错误抛给上层。如果重试仍然失败返回一个need_humanTrue的安全结果。在客服场景中宁可人工多看一条也不要漏掉投诉。4.5 评测脚本用Mini评测集追踪随机性与准确性核心服务写好后还需要一个评测脚本用来回答我们最关心的问题“这个垂直AI在多次调用下到底稳不稳定”。我们设计一个非常小的评测集包含三个典型场景。实际项目中建议至少扩展到几百条覆盖不同用户情绪和边界条件。# 文件路径vertical-ai-guard/evaluator.py import statistics from ai_guard import ask_guard, QAResult # 一个简化的评测集 EVAL_CASES [ { name: 正常咨询, dialogue: 用户请问我的订单什么时候发货\n客服您好您的订单预计明天发货。\n用户好的谢谢。, expected_emotion: 正常, expected_human: False, }, { name: 愤怒投诉, dialogue: 用户你们什么破公司没到货也不退款我要投诉\n客服非常抱歉我帮您查询一下。\n用户不用查了我再也不买你们了。, expected_emotion: 愤怒, expected_human: True, }, { name: 焦虑等待, dialogue: 用户我的快递已经丢在外面三天了会不会丢啊\n客服我帮您联系快递网点。\n用户那能尽快吗我有点担心。, expected_emotion: 焦虑, expected_human: False, }, ] def evaluate(predict_func, casesEVAL_CASES, repeat_times10): 多次运行同一个评测集输出准确率与稳定性指标。 total_correct 0 total_samples 0 consistency_scores [] for case in cases: emotion_results [] human_results [] for _ in range(repeat_times): result: QAResult predict_func(case[dialogue]) emotion_ok result.emotion case[expected_emotion] human_ok result.need_human case[expected_human] total_samples 1 if emotion_ok and human_ok: total_correct 1 emotion_results.append(result.emotion) human_results.append(result.need_human) # 一致性同一case多次运行去重结果种类数占比 emotion_consistency len(set(emotion_results)) / len(emotion_results) human_consistency len(set(human_results)) / len(human_results) consistency_scores.append((emotion_consistency human_consistency) / 2) accuracy total_correct / total_samples avg_consistency statistics.mean(consistency_scores) return { accuracy: accuracy, avg_consistency: avg_consistency, total_samples: total_samples, } if __name__ __main__: metrics evaluate(ask_guard) print(评测结果) print(metrics) # 如果稳定性过低可以进一步打印每个case的多轮结果这个脚本的逻辑很简单对每一条评测数据重复运行10次计算整体准确率和平均一致性。通过这两个指标你就能直观地看到“模型是否真的稳定”。4.6 运行与验证运行方式python evaluator.py预期输出大致如下评测结果 {accuracy: 0.9667, avg_consistency: 0.9333, total_samples: 30}如果你的评测集足够严苛结果可能会出现accuracy0.8甚至更低的情况。这并不一定说明模型能力差而是说明当前提示词、采样参数和业务边界还没有调到最合适的状态。我们可以通过调整系统提示词、增加少样本示例、修改temperature、或者引入二次校验来改善指标。这里还要特别强调一点不要只看准确率一定要看一致性。如果准确率很高但一致性很低说明模型在不同表述之间摇摆这在垂直AI中依然是一个高风险信号。5. 垂直AI落地的常见问题与排查思路在实际项目中垂直AI团队踩过的坑通常可以归类为以下几类。下面用表格给出一个快速排查清单。问题现象常见原因解决思路同一个Prompt多次调用结果不一致采样参数过高或推理后端存在非确定性降低temperature固定采样参数多次采样取多数票线上准确率远低于DemoDemo评测集过小覆盖不到真实长尾输入建立分层评测集加入对抗样本和边界条件模型输出合法但不满足业务规则Prompt只限制格式没有限制业务边界在Prompt中增加硬性规则并在代码里做规则校验JSON解析偶发失败模型输出带解释或Markdown标记使用结构化输出约束增加重试与解析兜底模型版本升级后行为变化依赖外部API后台升级未固定版本关注模型版本变更通知升级前先跑回归评测用户输入导致提示词注入直接拼接用户输入缺少隔离对用户输入做转义或内容过滤使用权限隔离检索知识冲突导致错误答案RAG召回片段相互矛盾模型无法取舍增加文档版本管理在Prompt中要求标注依据必要时拒绝回答成本开销不可控错误重试无上限长上下文反复拼接设置重试次数上限采用缓存控制上下文长度人工复核成本高系统把所有结果都发给人工设置置信度阈值只对低置信度和高危场景转人工缺少线上监控只看了离线评测没看真实分布变化记录每次调用的输入、输出、延迟、token数建立告警排查这类问题时建议按照“输入不变、输出变了”的方向出发先确认模型服务、版本、参数是否有变化。再确认Prompt模板是否有改动是否有动态变量被错误拼接。然后确认上游链路比如RAG检索召回、向量库数据更新、上下文顺序。最后再考虑模型本身的随机性通过多次运行同一个Prompt来验证。6. 最佳实践与工程建议6.1 用评测集对抗随机回归垂直AI项目最应该先做的一件事就是建设一个可持续运行的评测集。这个评测集不是随便找几十条问题而是要根据业务场景分层设计标准样例覆盖最常见的用户输入和业务规则。边界样例覆盖极端输入、超长输入、空输入、多轮上下文。对抗样例覆盖提示词注入、误导性提问、模糊表达。回归样例记录线上历史问题防止模型升级后旧问题复发。评测集的生命周期需要和业务一起更新。每发现一个新的失败模式就把它加入评测集每次升级模型或修改Prompt都先跑一遍完整评测再决定是否上线。6.2 把随机性隔离在业务边界之外一个很有效的方法是让LLM只负责“生成候选结果”而不是直接“执行最终业务逻辑”。比如客服质检场景可以让LLM生成“情绪判断理由”但在把它作为最终决定之前先用规则引擎做一次硬校验。如果用户对话中包含“我要投诉”“退款”等关键词即使LLM输出说“情绪正常”系统也要强制转人工。结构化的输出约束也很重要。尽量让模型只输出JSON对象然后通过Pydantic、JSON Schema等工具做反序列化验证。只有验证通过的数据才能进入下游业务。这样可以把模型输出的“自由文本风险”限制在一个可控边界内。6.3 人机回环与置信度机制在垂直AI领域完全自动化往往不是最优解。更稳妥的方式是“机器处理大部分人工处理小部分”。关键是设计置信度机制。可以通过多次采样让模型给出多个候选答案从中计算一致性得分也可以额外让模型输出一个confidence字段并配合规则判断是否需要人工介入。比如某条工单被判定为高情绪激烈度但模型置信度不高系统就可以把它送去人工复核。对用户来说人工复核的延迟是可以接受的远好过模型给出一个错误且自信的结论。6.4 成本、延迟与概率护栏治理随机性不是无限增加重试次数而是要在成本、延迟和成功率之间找平衡。建议从架构上做几件事给所有模型调用设置超时时间和重试上限。对高重复性的请求做结果缓存。在Prompt中限制输出长度和结构化字段数量。对低风险场景使用更快、更小的模型对高风险场景才调用大模型。建立调用链路的日志记录模型版本、温度参数、token消耗、返回结果。当模型因为随机性出现错误时护栏要能“接住”错误而不是让错误直接进入用户界面。这也是垂直AI系统与普通Demo最大的区别。6.5 什么时候不需要LLM最后一条最佳实践可能有些反直觉不是所有地方都要用LLM。在垂直AI产品中如果某个判断可以被规则、正则、决策树或传统机器学习完全覆盖就不要引入大模型的随机性。比如“用户是否提到退款”用规则匹配可能快速且准确“用户是否表达强烈不满”才需要LLM来做语义理解。把确定性问题交给确定性系统把开放性问题留给大模型整体系统的稳定性会大幅提升。7. 总结与下一步先跑一百次实验垂直AI泡沫并不会因为某一家公司失败而消失它本质上是一种技术理解和工程投入之间的错配。我们被大模型的惊艳表现吸引却忘了它内部仍然是一个概率采样系统。要让LLM真正进入生产环境必须承认它“会掷骰子”然后围绕这个事实设计评测、监控、降级和人工复核机制。如果你正在做一个垂直AI项目我的建议很直接不要停留在Demo阶段先把你业务里最关键的一个Prompt跑一百次把每一次的输出原样记录下来。统计一下有多少次结果完全一致、有多少次关键字段波动、有多少次结果明显错误。这个实验不需要复杂工具只要几条测试数据和一段几十行的Python脚本但它会告诉你你的垂直AI到底是“已经稳定”还是“只是看起来稳定”。接下来可以继续学习的方向包括RAG检索质量评估、LLM-as-Judge的评测设计、Agent多步调用的评测与追踪、模型微调对随机性的影响以及结构化输出约束在不同推理框架中的实现差异。这些内容都是围绕同一个核心问题展开的我们怎样把一个概率模型安全地封装成一个可预测的业务组件。这也是垂直AI从泡沫走向真正落地的关键能力。
垂直AI落地陷阱：为什么说大模型在“掷骰子”，以及如何工程化应对
之前在看垂直AI方向的项目方案时最常听到的一句话是“用大模型把XX流程自动化”。这句话本身没有问题但很多团队在实际落地时会把大模型当成一个“只要提示词写得好输出就稳定可靠”的确定性组件。等到系统上线后才发现同一个问题换一天问结果可能完全不一样同一个用户问题换个说法模型给出的答案可能从正确直接退化成离谱。更麻烦的是这类问题往往没有堆栈、没有异常日志只会表现为“线上准确率莫名下降”。这篇文章想围绕一个核心观点展开我们一直高估了垂直AI的确定性却低估了LLM的随机性。LLM在推理时本质上是在“掷骰子”——从概率分布中采样token来生成结果。垂直AI泡沫之所以会出现不是因为大模型能力不够强而是因为很多产品在工程上假装它不会出错把一个概率行为当成了可以承诺的规则引擎来交付。文章会先从概念上拆解“LLM Roll Dice”到底指什么再分析垂直AI泡沫是如何形成的然后给出一套可以落地的工程方案包括评测集、结构化输出、人机回环、可观测性等内容最后附上完整示例代码和常见坑点。无论你是刚开始接触LLM应用开发还是已经在做RAG、Agent、客服质检等垂直AI项目这篇文章都能帮你避免一些非常昂贵的返工。1. 背景为什么说LLM在“掷骰子”1.1 概率语言模型的基本直觉要理解“LLM Roll Dice”这个比喻需要先抛开“模型很聪明”这层直觉。一个大型语言模型在结构上其实是一个参数规模很大的概率分布模型。它做的事情是给定一段文本作为上下文然后计算“下一个token”的概率分布。举个例子输入“中国的首都是”模型内部会计算所有候选词的概率比如“北京”可能是0.8“南京”可能是0.05“上海”可能是0.03。模型并不是从知识库里检索出答案而是在这个概率分布上采样一个token接着把新token接到上下文里继续预测下一个token。整个过程循环往复直到生成结束符。这个过程的每一步都有概率性。即使是同一个Prompt只要采样策略不同最终生成的句子就可能不同。温度越高低概率token被选中的机会越大输出越“发散”温度越低模型越倾向于选择高概率token输出相对稳定。但“相对稳定”不等于“永远一致”这一点对垂直AI产品影响极大。1.2 “Roll Dice”到底指什么很多技术文章会用“掷骰子”来形容LLM的随机性但它并不是完全均匀随机的意思。更准确地说LLM是在一个极其复杂的高维概率分布上做随机采样每次生成相当于从一个“巨大骰子”里掷出结果。这个骰子的各个面并不是等概率的哪些面更容易出现取决于训练数据、模型参数、提示词、采样参数和推理后端。“Roll Dice”的关键含义是同样的输入模型可能给出多个合法答案。其中有些答案符合预期有些答案偏离预期甚至有些答案是凭空编造的。这就是我们在生产环境中经常遇到的“非确定性”问题。对于搜索引擎、API网关这类传统系统相同的请求几乎必然返回相同结果但LLM没有这个保证。只要产品逻辑里默认了“结果唯一且可复现”那么线上迟早会出现不符合预期的输出。尤其是垂直AI场景业务方常常要求系统必须给出“正确的”“唯一的”结论。比如保险理赔初审、银行对公材料抽取、医疗问诊辅助用户不会接受模型偶尔换个说法。但如果我们没有在系统层面处理随机性那么产品效果就真的像在掷骰子。1.3 从“生成”到“对话”的不稳定性有些开发者会问我使用的时候把temperature设置为0结果不是稳定的吗这个问题需要分两层看。第一temperature0 通常会让模型走贪心解码也就是每一步都选概率最大的token因此大多数时候输出是确定的。但在实际部署中推理框架往往做了并行计算、批处理、KV Cache、浮点算子优化等不同GPU、不同batch、不同推理引擎之间仍然可能出现微小数值差异。此外部分模型支持top_p、top_k、重复惩罚、频率惩罚这些参数叠加后会让概率分布再次变化。第二很多产品不是只跑一次模型调用而是先做意图识别再做RAG检索再让模型生成答案。RAG检索结果本身就可能因为向量化模型的随机性、召回阈值、重排策略而不同。即使LLM输出固定前面的检索结果变了后面生成的内容也会跟着变。所以“掷骰子”不仅存在于模型生成层也存在于整个AI应用链路的多个环节。2. 垂直AI泡沫是如何形成的2.1 垂直AI的典型定义与商业叙事垂直AI通常指针对某个具体行业或场景定制的大模型应用。比如法律文书审查、企业财务问答、客服工单自动分类、医疗报告解读、招聘简历筛选等。相比于通用AI助手垂直AI强调“业务纵深”和“可落地”往往会把行业知识、私有数据、业务规则和大模型组合在一起形成一套解决方案。这种商业模式本身是有价值的但市场上很多垂直AI产品在叙事上会走同一个套路先用一个漂亮的Demo证明大模型能理解行业术语然后对外宣称“我们解决了行业痛点”最后在交付阶段才发现真实业务数据远比Demo复杂模型输出稳定性也不达标。于是项目从一个“AI创新项目”变成一个“数据清洗和人工标注项目”成本直线上升ROI很难算过来。2.2 三根支柱API包装、提示词、向量库从工程结构看目前很多垂直AI产品都建立在三根支柱上。第一根是API包装。团队通过调用外部大模型API或部署开源模型的推理服务把LLM当作一个黑盒能力自己只负责封装输入输出和业务逻辑。这种方式上手快但很难对模型内部的随机性做深入控制。第二根是提示词工程。团队把行业知识、规则约束、少样本示例写进Prompt希望模型“按照要求”输出。提示词确实能显著影响模型行为但它的效果高度依赖模型版本和上下文模板。一旦模型版本升级同样的提示词效果可能变差一旦用户问题的表达方式超出模板覆盖范围模型就很容易跑偏。第三根是向量库和RAG。团队把业务文档切片、向量化后存入向量数据库检索相关片段再交给模型生成答案。这解决了部分知识实时更新的问题但也引入了检索质量的变量。切片大小是否合理、召回片段是否相关、拼接后上下文是否冲突都会影响最终输出。这三根支柱本身没有错问题是很多团队只用了这三根支柱却没有配套的评测、监控、降级和人工复核机制。于是产品在Demo阶段看起来很聪明在样本集上准确率也很高但真实流量一进来所有隐藏的随机性问题都会暴露。2.3 泡沫的源头把随机结果当确定性API垂直AI泡沫的源头我认为不是“模型不够强”而是“工程假设错了”。团队把一个概率模型抽象成了“确定性API”来使用进而向客户承诺了不该承诺的稳定性。传统软件系统的接口是确定性的传入同样的参数返回同样的结果这是可以写进测试用例和SLA的。即使遇到异常系统也会抛出一个明确的错误。但LLM不会抛“Not UnderstandException”它会一本正经地生成一段合理但错误的回答。更麻烦的是这种错误还可能是随机的上一轮正确下一轮错误没有明确规律。当产品对外承诺“准确率达到95%”时如果没有先定义清楚评测集、测试方法和多次运行的波动范围这个数字本身就是不可靠的。同样的100条测试数据今天跑可能是97%准确率明天跑可能变成91%单次测试结果完全没有统计意义。垂直AI泡沫正是建立在这样的“单点评测”之上一次Demo效果好就被误认为模型能力已经达标。2.4 容易被忽略的退化场景除了基础的随机性垂直AI还容易在几个特殊场景下“退化”。第一个场景是长尾用户输入。业务用户在真实使用时并不会按测试集说话他们可能输入错别字、口语化表达、行业黑话、中英文混用。模型如果只见过标准表述遇到长尾输入后输出质量可能明显下降。第二个场景是提示词被污染。如果系统允许用户输入自由文本并且把用户输入直接拼进Prompt就存在提示词注入的风险。恶意用户可以通过构造输入让模型忽略系统指令输出越狱内容或执行意外操作。第三个场景是知识冲突。RAG检索回来的文档片段可能包含过时信息、错误信息或者与模型内置知识相矛盾。模型不知道应该相信哪一边于是可能两边内容混在一起生成一个看似通顺但事实混乱的答案。第四个场景是上下文超长。当多轮会话或大文档被压缩到上下文窗口时模型会遗忘早期关键信息或者把不相关的信息误当成约束条件。此时系统表现出的“不稳定”表面上像随机问题实际上是上下文管理不当。3. 从工程角度理解LLM的概率性3.1 temperature、top_p与采样过程在LLM推理服务中最常调整的采样参数是temperature和top_p。temperature用于缩放token概率分布数值越低分布越尖锐模型越倾向于高概率token数值越高分布越平滑低概率token被采中的可能性越大。top_p则用于截断候选集只保留累积概率超过阈值的token再在这个子集内采样。虽然大多数平台默认推荐temperature0来追求确定性但它并不能完全保证结果可复现。一方面部分推理框架在实现贪心解码时仍可能存在浮点数舍入差异另一方面如果应用层有多个模型调用任何一层的参数不同都会导致最终结果不同。更合理的做法是把“temperature0”当成一种尽力而为的稳定性优化而不是银弹。3.2 同一个Prompt多次调用输出的差异我们可以用一个最简单的实验来观察这种差异。假设你调用同一个聊天模型同一个system prompt和user prompt设置temperature1.0调用5次结果很可能会看到不同的表述和不同的结论。即使设置temperature0如果改用了不同的推理后端结果也可能出现差异。这个现象本身并不可怕真正可怕的是产品层没有意识到它。比如客服工单系统根据LLM判断“用户是否强烈要求投诉”如果模型十次里有两次判断为“是”五次判断为“否”还有三次判断为“需要人工确认”那这个自动分类就是不可用的。要想让系统变得可靠不能只靠改Prompt还要从评估指标和业务决策上引入容错机制。3.3 不同模型版本与推理后端导致的差异除了采样参数模型版本和推理引擎也会影响输出稳定性。商用模型API经常做后台升级同一套Prompt在上个月和这个月可能产生不同答案本地部署的开源模型如果从Transformers切换到vLLM、TensorRT-LLM等推理框架由于算子实现和批处理方式不同输出也会出现微小差异。在垂直AI工程中这种差异经常会表现为“为什么昨天还好好的今天突然不行了”。排查时要注意把问题拆开是先检查提示词被修改了还是检查模型API版本变了再做线上和测试环境的结果比对。如果不把模型版本、推理参数、依赖包版本都固定下来问题排查就会非常困难。3.4 概率性在评估中的意义正因为LLM是概率模型做评估时就不能使用“跑一遍测试集得到准确率”这种简单方式。应该把每次调用看作一次采样用多次运行的结果来评估系统的稳定性和期望质量。评估一个垂直AI系统时至少要分成两个维度质量维度生成的答案是否正确、是否满足业务要求。稳定性维度多次运行时答案是否保持一致关键字段是否稳定。质量维度可以用精确匹配、语义相似度、人工评分、LLM-as-Judge等方式量化。稳定性维度则需要记录同一输入多次运行的结果计算差异率、字段级一致性、推荐结果波动性等指标。只有两个维度都达标系统才适合被嵌入生产流程。4. 完整实战构建一个“防骰子”的垂直AI接口4.1 需求与设计为了把上面的概念落实到代码里这里我们设计一个简化的垂直AI场景客服质检助手。输入一段用户与客服的对话由系统判断“用户情绪类别”和“是否需要人工介入”并返回结构化JSON结果。这个场景足够简单但包含了垂直AI的核心问题输出不稳定模型可能把“愤怒”识别成“焦虑”。格式不稳定模型可能输出多余解释导致JSON解析失败。业务错误模型可能漏掉需要人工升级的情况。我们的目标是构建一个可运行的服务具备三个能力统一调用LLM并设置较低温度。使用JSON Schema或Pydantic模型校验输出。增加重试和降级策略当模型连续输出非法结果时自动转人工处理。4.2 环境准备与版本说明本文示例使用Python 3.10及以上版本以OpenAI Python SDK调用一个OpenAI兼容接口。实际项目中你可以换成任何支持OpenAI协议的大模型服务比如本地的vLLM、Ollama、国内云厂商的兼容网关等。版本方面为了避免误导这里不写死具体版本号建议在requirements.txt中锁定你实际使用的版本。openai1.0.0 pydantic2.0.0 python-dotenv1.0.0安装依赖pip install -r requirements.txt还需要准备环境变量export OPENAI_API_KEY你的API Key export OPENAI_BASE_URLhttps://你的模型服务地址注意如果你的模型服务不需要API Key可以传一个占位字符串。4.3 项目结构为了便于理解我们使用一个小型项目结构vertical-ai-guard/ ├── requirements.txt ├── .env ├── main.py # 入口简单示例 ├── evaluator.py # 评测脚本 └── ai_guard.py # 核心业务逻辑这里的文件不算多但足够展示“业务逻辑、模型调用、评测脚本”分离的思想。4.4 核心代码带结构化输出与降级策略的服务先编写核心业务文件ai_guard.py。它负责调用模型并确保输出能够被解析成我们需要的结构化对象。# 文件路径vertical-ai-guard/ai_guard.py import json import os from typing import List from openai import OpenAI from pydantic import BaseModel, Field, ValidationError # 读取环境变量 OPENAI_API_KEY os.getenv(OPENAI_API_KEY, dummy) OPENAI_BASE_URL os.getenv(OPENAI_BASE_URL, https://api.openai.com/v1) client OpenAI(api_keyOPENAI_API_KEY, base_urlOPENAI_BASE_URL) # 定义我们希望模型输出的结构化结果 class QAResult(BaseModel): emotion: str Field(description用户情绪只允许取值为正常、焦虑、愤怒、失望) need_human: bool Field(description是否需要人工介入) reason: str Field(description判断理由不超过50字) SYSTEM_PROMPT 你是一个客服质检助手。 请根据用户与客服的对话内容判断用户的情绪类别并决定是否需要人工介入。 要求 1. 只输出JSON对象不要输出任何解释。 2. JSON必须包含 emotion、need_human、reason 三个字段。 3. emotion只能取正常、焦虑、愤怒、失望。 4. 如果用户表现出明显的愤怒、重复投诉或威胁退款need_human必须为true。 def build_user_prompt(dialogue: str) - str: return f对话内容\n{dialogue} def parse_result(content: str) - QAResult: 尝试解析模型输出并做一次兜底清理。 text content.strip() # 去除可能出现的 json 代码块标记 if text.startswith(): text text.strip() if text.startswith(json): text text[4:] text text.strip() # 尝试找到JSON部分 try: data json.loads(text) return QAResult(**data) except (json.JSONDecodeError, ValidationError) as exc: raise ValueError(f模型输出格式非法: {content[:200]}) from exc def ask_guard(dialogue: str, temperature: float 0.0, max_retries: int 2) - QAResult: 调用模型并做格式校验和重试。 如果模型连续max_retries次都无法输出合法JSON则返回一个安全的降级结果。 在实际业务中这个降级结果应该触发告警并将该条会话转人工处理。 messages [ {role: system, content: SYSTEM_PROMPT}, {role: user, content: build_user_prompt(dialogue)}, ] last_error None for attempt in range(max_retries 1): try: resp client.chat.completions.create( modelos.getenv(LLM_MODEL, gpt-4o-mini), messagesmessages, temperaturetemperature, response_format{type: json_object}, # 如果模型支持则保留 ) content resp.choices[0].message.content return parse_result(content) except ValueError as exc: # 格式解析失败重试 last_error exc messages.append({role: user, content: 上一轮输出不是合法JSON请重新只输出JSON对象。}) except Exception as exc: # 网络、限流等异常 last_error exc break # 降级返回宁可转人工也不能误判 return QAResult(emotion正常, need_humanTrue, reasonf模型连续输出异常已自动转人工。错误{last_error})这里有几个关键点parse_result做了两层兜底先尝试去除代码块标记再尝试JSON解析。如果输出格式不合法会向模型追加一条“请重新输出JSON”的消息而不是直接把错误抛给上层。如果重试仍然失败返回一个need_humanTrue的安全结果。在客服场景中宁可人工多看一条也不要漏掉投诉。4.5 评测脚本用Mini评测集追踪随机性与准确性核心服务写好后还需要一个评测脚本用来回答我们最关心的问题“这个垂直AI在多次调用下到底稳不稳定”。我们设计一个非常小的评测集包含三个典型场景。实际项目中建议至少扩展到几百条覆盖不同用户情绪和边界条件。# 文件路径vertical-ai-guard/evaluator.py import statistics from ai_guard import ask_guard, QAResult # 一个简化的评测集 EVAL_CASES [ { name: 正常咨询, dialogue: 用户请问我的订单什么时候发货\n客服您好您的订单预计明天发货。\n用户好的谢谢。, expected_emotion: 正常, expected_human: False, }, { name: 愤怒投诉, dialogue: 用户你们什么破公司没到货也不退款我要投诉\n客服非常抱歉我帮您查询一下。\n用户不用查了我再也不买你们了。, expected_emotion: 愤怒, expected_human: True, }, { name: 焦虑等待, dialogue: 用户我的快递已经丢在外面三天了会不会丢啊\n客服我帮您联系快递网点。\n用户那能尽快吗我有点担心。, expected_emotion: 焦虑, expected_human: False, }, ] def evaluate(predict_func, casesEVAL_CASES, repeat_times10): 多次运行同一个评测集输出准确率与稳定性指标。 total_correct 0 total_samples 0 consistency_scores [] for case in cases: emotion_results [] human_results [] for _ in range(repeat_times): result: QAResult predict_func(case[dialogue]) emotion_ok result.emotion case[expected_emotion] human_ok result.need_human case[expected_human] total_samples 1 if emotion_ok and human_ok: total_correct 1 emotion_results.append(result.emotion) human_results.append(result.need_human) # 一致性同一case多次运行去重结果种类数占比 emotion_consistency len(set(emotion_results)) / len(emotion_results) human_consistency len(set(human_results)) / len(human_results) consistency_scores.append((emotion_consistency human_consistency) / 2) accuracy total_correct / total_samples avg_consistency statistics.mean(consistency_scores) return { accuracy: accuracy, avg_consistency: avg_consistency, total_samples: total_samples, } if __name__ __main__: metrics evaluate(ask_guard) print(评测结果) print(metrics) # 如果稳定性过低可以进一步打印每个case的多轮结果这个脚本的逻辑很简单对每一条评测数据重复运行10次计算整体准确率和平均一致性。通过这两个指标你就能直观地看到“模型是否真的稳定”。4.6 运行与验证运行方式python evaluator.py预期输出大致如下评测结果 {accuracy: 0.9667, avg_consistency: 0.9333, total_samples: 30}如果你的评测集足够严苛结果可能会出现accuracy0.8甚至更低的情况。这并不一定说明模型能力差而是说明当前提示词、采样参数和业务边界还没有调到最合适的状态。我们可以通过调整系统提示词、增加少样本示例、修改temperature、或者引入二次校验来改善指标。这里还要特别强调一点不要只看准确率一定要看一致性。如果准确率很高但一致性很低说明模型在不同表述之间摇摆这在垂直AI中依然是一个高风险信号。5. 垂直AI落地的常见问题与排查思路在实际项目中垂直AI团队踩过的坑通常可以归类为以下几类。下面用表格给出一个快速排查清单。问题现象常见原因解决思路同一个Prompt多次调用结果不一致采样参数过高或推理后端存在非确定性降低temperature固定采样参数多次采样取多数票线上准确率远低于DemoDemo评测集过小覆盖不到真实长尾输入建立分层评测集加入对抗样本和边界条件模型输出合法但不满足业务规则Prompt只限制格式没有限制业务边界在Prompt中增加硬性规则并在代码里做规则校验JSON解析偶发失败模型输出带解释或Markdown标记使用结构化输出约束增加重试与解析兜底模型版本升级后行为变化依赖外部API后台升级未固定版本关注模型版本变更通知升级前先跑回归评测用户输入导致提示词注入直接拼接用户输入缺少隔离对用户输入做转义或内容过滤使用权限隔离检索知识冲突导致错误答案RAG召回片段相互矛盾模型无法取舍增加文档版本管理在Prompt中要求标注依据必要时拒绝回答成本开销不可控错误重试无上限长上下文反复拼接设置重试次数上限采用缓存控制上下文长度人工复核成本高系统把所有结果都发给人工设置置信度阈值只对低置信度和高危场景转人工缺少线上监控只看了离线评测没看真实分布变化记录每次调用的输入、输出、延迟、token数建立告警排查这类问题时建议按照“输入不变、输出变了”的方向出发先确认模型服务、版本、参数是否有变化。再确认Prompt模板是否有改动是否有动态变量被错误拼接。然后确认上游链路比如RAG检索召回、向量库数据更新、上下文顺序。最后再考虑模型本身的随机性通过多次运行同一个Prompt来验证。6. 最佳实践与工程建议6.1 用评测集对抗随机回归垂直AI项目最应该先做的一件事就是建设一个可持续运行的评测集。这个评测集不是随便找几十条问题而是要根据业务场景分层设计标准样例覆盖最常见的用户输入和业务规则。边界样例覆盖极端输入、超长输入、空输入、多轮上下文。对抗样例覆盖提示词注入、误导性提问、模糊表达。回归样例记录线上历史问题防止模型升级后旧问题复发。评测集的生命周期需要和业务一起更新。每发现一个新的失败模式就把它加入评测集每次升级模型或修改Prompt都先跑一遍完整评测再决定是否上线。6.2 把随机性隔离在业务边界之外一个很有效的方法是让LLM只负责“生成候选结果”而不是直接“执行最终业务逻辑”。比如客服质检场景可以让LLM生成“情绪判断理由”但在把它作为最终决定之前先用规则引擎做一次硬校验。如果用户对话中包含“我要投诉”“退款”等关键词即使LLM输出说“情绪正常”系统也要强制转人工。结构化的输出约束也很重要。尽量让模型只输出JSON对象然后通过Pydantic、JSON Schema等工具做反序列化验证。只有验证通过的数据才能进入下游业务。这样可以把模型输出的“自由文本风险”限制在一个可控边界内。6.3 人机回环与置信度机制在垂直AI领域完全自动化往往不是最优解。更稳妥的方式是“机器处理大部分人工处理小部分”。关键是设计置信度机制。可以通过多次采样让模型给出多个候选答案从中计算一致性得分也可以额外让模型输出一个confidence字段并配合规则判断是否需要人工介入。比如某条工单被判定为高情绪激烈度但模型置信度不高系统就可以把它送去人工复核。对用户来说人工复核的延迟是可以接受的远好过模型给出一个错误且自信的结论。6.4 成本、延迟与概率护栏治理随机性不是无限增加重试次数而是要在成本、延迟和成功率之间找平衡。建议从架构上做几件事给所有模型调用设置超时时间和重试上限。对高重复性的请求做结果缓存。在Prompt中限制输出长度和结构化字段数量。对低风险场景使用更快、更小的模型对高风险场景才调用大模型。建立调用链路的日志记录模型版本、温度参数、token消耗、返回结果。当模型因为随机性出现错误时护栏要能“接住”错误而不是让错误直接进入用户界面。这也是垂直AI系统与普通Demo最大的区别。6.5 什么时候不需要LLM最后一条最佳实践可能有些反直觉不是所有地方都要用LLM。在垂直AI产品中如果某个判断可以被规则、正则、决策树或传统机器学习完全覆盖就不要引入大模型的随机性。比如“用户是否提到退款”用规则匹配可能快速且准确“用户是否表达强烈不满”才需要LLM来做语义理解。把确定性问题交给确定性系统把开放性问题留给大模型整体系统的稳定性会大幅提升。7. 总结与下一步先跑一百次实验垂直AI泡沫并不会因为某一家公司失败而消失它本质上是一种技术理解和工程投入之间的错配。我们被大模型的惊艳表现吸引却忘了它内部仍然是一个概率采样系统。要让LLM真正进入生产环境必须承认它“会掷骰子”然后围绕这个事实设计评测、监控、降级和人工复核机制。如果你正在做一个垂直AI项目我的建议很直接不要停留在Demo阶段先把你业务里最关键的一个Prompt跑一百次把每一次的输出原样记录下来。统计一下有多少次结果完全一致、有多少次关键字段波动、有多少次结果明显错误。这个实验不需要复杂工具只要几条测试数据和一段几十行的Python脚本但它会告诉你你的垂直AI到底是“已经稳定”还是“只是看起来稳定”。接下来可以继续学习的方向包括RAG检索质量评估、LLM-as-Judge的评测设计、Agent多步调用的评测与追踪、模型微调对随机性的影响以及结构化输出约束在不同推理框架中的实现差异。这些内容都是围绕同一个核心问题展开的我们怎样把一个概率模型安全地封装成一个可预测的业务组件。这也是垂直AI从泡沫走向真正落地的关键能力。