图：复杂系统中的决策路径——确定性与非确定性的交汇

---

前言

这周我们聊了 AI Agent 入门、多智能体系统、大前端性能优化、金融科技应用……今天收尾，聊一个更底层的问题：

当你在设计一个 AI 系统时，你到底在设计什么？

答案是：你在设计一套决策机制。而所有决策机制，本质上都落在一个光谱的两端——确定性（Deterministic） 和 非确定性（Non-deterministic）。

搞清楚这两者的边界，是做好 AI 架构的第一步。

---

一、什么是确定性系统？

确定性系统的定义很简单：相同输入，永远产生相同输出。

f(x) = y  // 任何时候，x → y 都不变

传统软件几乎全是确定性的：

• 排序算法：给定数组，输出固定
• 数据库查询：SQL 语句 + 数据不变 → 结果不变
• REST API：同一请求 → 同一响应（幂等设计）

优点：

• 可测试、可预期、可调试
• 出了问题，能复现、能追溯
• 适合审计、合规场景

缺点：

• 灵活性差，处理不了模糊输入
• 规则爆炸：边界情况越来越多，维护成本指数级上升

---

二、什么是非确定性系统？

非确定性系统：相同输入，可能产生不同输出。

LLM（大语言模型）是最典型的非确定性系统：

# 同一个 prompt，两次调用结果可能不同
response_1 = llm.chat("解释一下量子纠缠")
response_2 = llm.chat("解释一下量子纠缠")
# response_1 ≠ response_2（大概率）

这不是 bug，是设计——temperature > 0 引入了随机采样，让模型更"有创意"。

优点：

• 处理模糊、开放性问题能力强
• 泛化能力好，不需要穷举规则
• 创造性输出（写作、代码生成、方案设计）

缺点：

• 难以测试（你怎么断言一个"好的回答"？）
• 幻觉（Hallucination）风险
• 不可复现，线上问题难排查

---

三、真实 AI 系统：两者的混合体

现实中没有"纯确定性"或"纯非确定性"的 AI 系统。好的架构是在合适的地方用合适的机制。

来看一个典型的 AI 客服系统架构：

用户输入
    │
    ▼
[意图识别] ← 非确定性（LLM 分类）
    │
    ├─ 查询订单 → [订单系统 API] ← 确定性
    ├─ 投诉处理 → [规则引擎] ← 确定性
    ├─ 闲聊     → [LLM 对话] ← 非确定性
    └─ 退款申请 → [审批流程] ← 确定性 + 人工审核

关键原则：

🔑 用非确定性处理"理解"，用确定性处理"执行"。

理解用户意图 → LLM（非确定性，容错）
执行业务操作 → 规则/代码（确定性，可靠）

---

四、架构决策矩阵

场景	推荐机制	原因
金融交易、支付	确定性	零容错，必须可审计
内容生成、创意写作	非确定性	多样性是价值
用户意图理解	非确定性	自然语言天然模糊
数据提取、格式转换	确定性优先 + LLM 兜底	结构化优先，模糊时降级
代码执行、工具调用	确定性	副作用不可逆
推荐系统	混合	召回确定性，排序可引入随机
医疗诊断辅助	确定性为主 + LLM 解释	决策可追溯，解释可灵活

---

五、LLM 的"伪确定性"陷阱

很多工程师第一次用 LLM 时会这样做：

# 以为设置 temperature=0 就是确定性了
response = llm.chat(prompt, temperature=0)

这是个陷阱。

temperature=0 只是让模型每次选概率最高的 token，但：

1. 模型版本更新 → 输出变了
2. 上下文窗口截断 → 输出变了
3. 并发请求的 batch 策略 → 输出可能变
4. 底层硬件浮点精度 → 极端情况下输出变

所以，LLM 永远不是真正的确定性系统，即使 temperature=0。

工程上的正确姿势：

# 不要依赖 LLM 输出的精确一致性
# 而是设计对"语义等价"的容忍

def extract_intent(text: str) -> Intent:
    raw = llm.chat(f"提取意图，返回JSON: {text}", temperature=0)
    try:
        return Intent.parse(raw)  # 结构化解析
    except:
        return Intent.UNKNOWN      # 降级处理，不崩溃

---

六、非确定性系统的工程化策略

既然 LLM 是非确定性的，怎么让它"工程上可靠"？

6.1 输出结构化

# ❌ 让 LLM 自由发挥
"请分析这段代码的问题"

# ✅ 约束输出格式
"请分析这段代码，以JSON格式返回：
{
  'issues': [{'type': str, 'line': int, 'description': str}],
  'severity': 'low|medium|high',
  'suggestion': str
}"

6.2 置信度 + 降级

result = llm_classify(text)
if result.confidence < 0.8:
    # 低置信度 → 转人工 or 规则引擎
    return fallback_handler(text)

6.3 幂等性设计（对外部调用）

# LLM 决定"要不要发邮件"是非确定性的
# 但"发邮件"这个动作必须幂等
def send_email_if_needed(task_id: str, ...):
    if already_sent(task_id):  # 幂等检查
        return
    send_email(...)
    mark_sent(task_id)

6.4 可观测性

非确定性系统更需要日志：

logger.info("llm_call", extra={
    "prompt_hash": hash(prompt),
    "model": model_name,
    "temperature": temperature,
    "output_preview": output[:200],
    "latency_ms": latency,
    "tokens": token_count
})

---

七、一个真实的架构演进案例

场景： 某电商平台的商品描述自动生成系统

v1.0（纯非确定性）：

商品信息 → LLM → 描述文案

问题：质量不稳定，有时生成违禁词，有时格式乱

v2.0（加确定性约束）：

商品信息 → LLM（生成草稿）→ 规则过滤（违禁词/格式）→ 文案

问题：过滤太严，很多好内容被误杀

v3.0（混合架构）：

商品信息
    │
    ├─ 结构化字段提取（确定性）
    │       │
    │       ▼
    │   [品类/价格/规格]
    │       │
    ├─ LLM 创意生成（非确定性，temperature=0.7）
    │       │
    │       ▼
    │   [创意文案草稿]
    │       │
    └─ 合规检查（确定性规则引擎）+ 人工抽检
            │
            ▼
        最终文案

结果： 质量稳定性提升 40%，人工干预减少 60%。

---

八、2026 年的趋势：确定性回归

有意思的是，随着 AI 系统越来越多地进入生产环境，行业正在经历一次**“确定性回归”**：

1. Structured Outputs（结构化输出） 成为标配
   OpenAI、Anthropic 都在强化 JSON Schema 约束能力

2. Workflow 编排框架崛起
   LangGraph、Temporal + LLM 的组合，把非确定性 LLM 嵌入确定性工作流

3. AI 测试工具成熟
   Promptfoo、Braintrust 等工具让 LLM 输出的"语义测试"成为可能

4. Guardrails 标准化
   NVIDIA NeMo Guardrails、Llama Guard 等，在 LLM 外层加确定性护栏

核心趋势： 不是抛弃非确定性，而是用确定性的工程手段驯化非确定性的 LLM。

---

总结

	确定性	非确定性
代表	传统代码、规则引擎	LLM、神经网络
优势	可预期、可测试、可审计	灵活、泛化、处理模糊
劣势	规则爆炸、不够灵活	难测试、幻觉、不可复现
适用	执行层、合规场景	理解层、创意场景

一句话总结：

🍊 让 LLM 负责"想"，让代码负责"做"。在两者之间，建好护栏。

这不是技术选择，是架构哲学。

---