AI 架构设计思考：确定性 vs 非确定性，你的系统该怎么选？

weixin_43922565

340人浏览 · 2026-03-20 08:45:58

weixin_43922565 · 2026-03-20 08:45:58 发布

AI架构设计封面
图：复杂系统中的决策路径——确定性与非确定性的交汇

前言

这周我们聊了 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，但：

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

所以，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 系统越来越多地进入生产环境，行业正在经历一次**“确定性回归”**：

Structured Outputs（结构化输出） 成为标配
OpenAI、Anthropic 都在强化 JSON Schema 约束能力
Workflow 编排框架崛起
LangGraph、Temporal + LLM 的组合，把非确定性 LLM 嵌入确定性工作流
AI 测试工具成熟
Promptfoo、Braintrust 等工具让 LLM 输出的"语义测试"成为可能
Guardrails 标准化
NVIDIA NeMo Guardrails、Llama Guard 等，在 LLM 外层加确定性护栏

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

总结

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