Optimization / Operations Research / OR-Tools / AI Decisioning 解读

面向对象: AI Product Architect / Operations Strategy Lead / Platform PM / Enterprise Architect。 核心问题: 很多企业 AI 系统不缺预测，而是缺“在约束下做出可执行决策”。优化和运筹学把 AI 的预测、规则和业务目标转成排班、路由、库存、额度、审核队列和资源分配方案。 学习目标: 理解线性规划、整数规划、CP-SAT、routing/scheduling、目标函数、约束、多目标权衡、Google OR-Tools、SciPy linprog、Gurobi、PuLP，并映射到 AI 决策服务架构。

---

Source Anchors

一句话:

Optimization 是 AI 产品从“预测和建议”走向“可执行运营方案”的关键层，它要求产品经理和架构师显式定义目标、约束、例外和人工覆盖。

---

1. 为什么 AI 决策需要优化层

预测模型回答:

可能会发生什么？

优化模型回答:

在资源、规则、成本、风险和服务承诺约束下，我们应该怎么做？

金融零售常见场景:

如果没有优化层，AI 往往只能停留在 dashboard 或 copilot 建议，无法变成一致、可复盘、可审计的决策。

---

2. 基本建模语言: 决策变量、目标、约束

优化问题最重要的不是求解器，而是建模。

例子:

Minimize: labor cost + SLA penalty + overtime penalty
Subject to:
  staff assigned >= forecast demand by interval and skill
  each employee works <= allowed hours
  required breaks are respected
  high-risk queue has certified reviewers

这就是 AI 产品需求和运筹建模之间的桥。

---

3. LP、MIP、CP-SAT 的产品含义

高阶架构判断:

• 如果决策必须解释和审计，优先显式优化模型。
• 如果实时性极强且规模巨大，可能需要启发式或预计算策略。
• 如果约束频繁变化，建模层要产品化，而不是硬编码。
• 如果风险高，求解器输出不能绕过 policy guardrail。

---

4. Forecast-to-Optimization

很多 AI 决策链路是:

forecast -> scenario -> optimization -> execution -> monitoring

关键点:

例子: 客服排班不应只用 P50 进线量做成本最小化。高投诉窗口可能要用 P90 需求并加 SLA penalty，否则模型会系统性低配人力。

---

5. Agent Proposes, Solver Decides

在 Agentic AI 场景里，一个安全架构模式是:

LLM/Agent proposes options -> policy checks -> solver optimizes -> human approves exceptions -> workflow executes

LLM 适合:

• 解释业务约束。
• 生成候选方案。
• 汇总异常原因。
• 帮运营理解求解结果。
• 起草 decision memo。

Solver 适合:

• 保证约束满足。
• 搜索组合空间。
• 输出最优或近似最优方案。
• 生成可复盘的 objective value 和 constraint status。

不要让 LLM 直接“安排排班”或“分配额度”。它可以帮助建模和解释，但约束满足应交给显式求解器和 policy engine。

---

6. 多目标权衡

企业优化很少只有一个目标。

处理方式:

• Weighted objective: 给不同目标权重。
• Constraint first: 把风险和合规设为硬约束。
• Lexicographic optimization: 先满足安全，再优化成本。
• Pareto frontier: 展示不同方案 tradeoff。
• Scenario comparison: 在不同业务假设下比较方案。

产品上要把这些权衡暴露给决策者，而不是隐藏在一个“推荐方案”按钮后面。

---

7. 决策服务架构

data and forecasts
  -> scenario builder
  -> optimization model registry
  -> solver runtime
  -> policy guardrail
  -> recommendation API
  -> workflow execution
  -> exception and override
  -> outcome monitoring

关键组件:

---

8. 无解和例外工作流

优化系统必须设计 infeasible path。无解不是系统失败，而是业务约束冲突的证据。

无解处理:

产品界面要显示:

• 哪些约束冲突。
• 放宽哪个约束会产生什么影响。
• 推荐的人工决策选项。
• 谁有权限批准例外。
• 例外是否影响下次模型参数。

---

9. 金融零售案例映射

Case A: 欺诈审核队列优化

• 预测: 每笔交易欺诈概率、金额、误伤风险、审核时长。
• 目标: 最大化风险减少，最小化客户摩擦和 SLA breach。
• 约束: 审核员容量、高风险必须复核、VIP 摩擦上限。
• 输出: case priority、reviewer assignment、自动放行/强认证/人工审查。

Case B: 催收联系策略

• 预测: 还款概率、投诉风险、联系成功率。
• 目标: 最大化回收，控制投诉和合规风险。
• 约束: 联系频次、时间窗口、渠道同意、人工容量。
• 输出: 每个客户的下一最佳联系动作。

Case C: 零售库存和价格

• 预测: SKU-门店需求、缺货风险、价格弹性。
• 目标: 毛利最大、缺货最少、库存成本最低。
• 约束: 仓库容量、供应商 MOQ、运输时效、价格政策。
• 输出: 订货量、调拨计划、促销库存保护。

Case D: AI 平台容量和模型路由

• 预测: 调用量、token、latency、成本。
• 目标: 满足 SLO 并控制预算。
• 约束: 模型配额、GPU 容量、风险等级、数据驻留。
• 输出: 模型路由、缓存策略、限流、容量采购。

---

10. Architecture Checklist

---

11. 面试表达

30 秒版本

AI 决策不能只靠预测模型。预测告诉我们可能发生什么，优化告诉我们在约束下该怎么做。我会把目标函数、决策变量、约束和政策规则显式建模，用 OR-Tools、Gurobi、PuLP 或 SciPy 求解，再接 policy guardrail、人工例外和结果监控。

2 分钟版本

以客服排班为例，预测模型给出每半小时进线量和 P90 区间，但真正的产品决策是如何安排不同技能组的人力，同时控制成本、SLA、加班、休息规则和外包限制。这是优化问题。架构上我会用 forecast-to-optimization 链路: 预测服务输出场景和分位数，scenario builder 管理假设，solver runtime 求解排班，policy engine 检查合规和风险，workflow 执行并允许人工覆盖。结果进入 monitoring，比较计划、执行和实际。LLM 可以解释方案和生成 memo，但约束满足必须由 solver 和规则引擎保证。

CTO 追问

如果 CTO 问为什么不让 Agent 直接决策，我会回答: Agent 可以提出方案，但组合约束、合规硬规则和容量限制需要显式求解和可审计证据。更安全的模式是 agent proposes, solver decides, policy gates, human approves exceptions。

---

12. Portfolio Task

做一个 “AI Optimization Decision Service”:

最终要能讲清楚: 高阶 AI 产品不是把模型分数展示出来，而是把预测、约束、策略和人类审批组合成可执行决策系统。