把"要不要给这个用户发优惠券""这条工单转给谁"交给大模型，听起来美好——直到它在生产跑了三天：同一输入昨天返回 JSON、今天返回一段散文；置信度 0.98 的决策依据是一段它编出来的用户画像。本文给一套在生产站得住的三层决策架构，重点是两个比模型选型更重要的工程细节。
三个必踩的坑，一个共同根因
| 坑 | 表现 | 根因 |
|---|---|---|
| 输出漂移 | 同一输入格式/结论随机变化 | 自然语言生成天然非确定 |
| 幻觉决策 | 高置信度但依据不存在 | 模型补全倾向压过事实约束 |
| 无法审计 | 业务问"为什么批了这笔"答不出 | 决策过程是黑盒 token 流 |
共性只有一个：把大模型当"决策系统"用，而它只是"决策信号源"。定位摆正，方案自然出来——模型给信号，规则做决策，日志保审计。
三层架构：规则层在前不在后
请求 → [规则层] 命中硬规则？→ 是 → 直接出决策（可解释、可审计）
↓ 否
[模型层] 结构化输出 → 校验通过 → 决策 + 置信度
↓ 校验失败/低置信
[兜底层] 保守默认值 / 转人工
关键设计是规则层在前：黑名单、阈值、白名单这类能被确定性规则覆盖的决策绝不进模型——既省调用成本，又让这部分决策 100% 可审计。模型层只处理规则覆盖不了的灰度地带。顺序反了（先过模型再兜底），成本和不可审计面都会放大。
两个比选型更重要的细节
结构化输出不是"提示词里说请返回 JSON"——那不叫约束。用 schema 硬约束加严格校验：
class Decision(BaseModel):
approve: bool
confidence: float # 0~1
reason_code: str # 枚举：reason_*，禁止自由文本
evidence: list[str] # 必须引用输入里的事实
细节一：reason_code 用枚举。理由必须落在预定义码表里。自由文本的理由等于没有理由——审计时要按原因聚合统计（这个月多少单因为低活跃被拒），散装字符串没法聚合，"为什么批了这笔"就永远答不利索。
细节二：evidence 必须回指输入。要求模型引用输入 payload 里真实存在的字段值。这个约束的妙处在于它利用了模型的惰性：编造一段不存在的画像比从输入里摘两个字段费劲，幻觉率因此显著下降。校验时顺手检查 evidence 里的值是否真出现在输入中，不匹配直接进兜底。
兜底层：宁可保守，不可玄学
校验失败、置信度低于阈值、超时，一律走兜底：保守默认值或转人工。不要让模型"再试一次"——重试只是在采样另一个随机数，失败的成本（一笔错误决策）远高于兜底的成本（少自动决策一笔）。这条反直觉的原则是决策类系统的安全底线。
选型与验收
决策类场景选模型服务，除了兼容性和延迟，重点看两条：结构化输出是否硬约束（JSON mode / schema 约束）——决定校验层的工作量；用量明细能否按请求回溯——审计的原料。验收这套架构的标准就一句话：随机抽 N 条历史决策，每条都能回答"走了哪层、依据什么、谁批的"。四件事都做齐——规则挡确定性、模型接灰度、枚举锁输出、兜底接异常——业务信任不是靠模型更聪明，是靠每一层都可解释。
评论0