垂直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，结果不是稳定的吗？这个问题需要分两层看。

第一，temperature=0 通常会让模型走贪心解码，也就是每一步都选概率最大的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，再在这个子集内采样。

虽然大多数平台默认推荐temperature=0来追求确定性，但它并不能完全保证结果可复现。一方面，部分推理框架在实现贪心解码时仍可能存在浮点数舍入差异；另一方面，如果应用层有多个模型调用，任何一层的参数不同，都会导致最终结果不同。更合理的做法是把“temperature=0”当成一种尽力而为的稳定性优化，而不是银弹。

3.2 同一个Prompt多次调用输出的差异

我们可以用一个最简单的实验来观察这种差异。假设你调用同一个聊天模型，同一个system prompt和user prompt，设置temperature=1.0，调用5次，结果很可能会看到不同的表述和不同的结论。即使设置temperature=0，如果改用了不同的推理后端，结果也可能出现差异。

这个现象本身并不可怕，真正可怕的是产品层没有意识到它。比如客服工单系统根据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中锁定你实际使用的版本。

openai>=1.0.0 pydantic>=2.0.0 python-dotenv>=1.0.0

安装依赖：

pip install -r requirements.txt

还需要准备环境变量：

export OPENAI_API_KEY="你的API Key" export OPENAI_BASE_URL="https://你的模型服务地址"

注意，如果你的模型服务不需要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_key=OPENAI_API_KEY, base_url=OPENAI_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( model=os.getenv("LLM_MODEL", "gpt-4o-mini"), messages=messages, temperature=temperature, 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_human=True, reason=f"模型连续输出异常，已自动转人工。错误：{last_error}")

这里有几个关键点：

• parse_result做了两层兜底，先尝试去除代码块标记，再尝试JSON解析。
• 如果输出格式不合法，会向模型追加一条“请重新输出JSON”的消息，而不是直接把错误抛给上层。
• 如果重试仍然失败，返回一个need_human=True的安全结果。在客服场景中，宁可人工多看一条，也不要漏掉投诉。

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, cases=EVAL_CASES, repeat_times=10): """多次运行同一个评测集，输出准确率与稳定性指标。""" 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}

如果你的评测集足够严苛，结果可能会出现accuracy=0.8甚至更低的情况。这并不一定说明模型能力差，而是说明当前提示词、采样参数和业务边界还没有调到最合适的状态。我们可以通过调整系统提示词、增加少样本示例、修改temperature、或者引入二次校验来改善指标。

这里还要特别强调一点：不要只看准确率，一定要看一致性。如果准确率很高但一致性很低，说明模型在不同表述之间摇摆，这在垂直AI中依然是一个高风险信号。

5. 垂直AI落地的常见问题与排查思路

在实际项目中，垂直AI团队踩过的坑通常可以归类为以下几类。下面用表格给出一个快速排查清单。

排查这类问题时，建议按照“输入不变、输出变了”的方向出发：

1. 先确认模型服务、版本、参数是否有变化。
2. 再确认Prompt模板是否有改动，是否有动态变量被错误拼接。
3. 然后确认上游链路，比如RAG检索召回、向量库数据更新、上下文顺序。
4. 最后再考虑模型本身的随机性，通过多次运行同一个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从泡沫走向真正落地的关键能力。