AI Optimization / Operations Research Decision Playbook

适用对象: AI Product Architect、AI PM、Decision Intelligence Lead、Risk Product、Retail Operations Product、Platform Architect、Model Risk / Governance Partner。 核心问题: 当 AI 已经能预测需求、风险、意图和优先级时，如何把预测结果转成满足约束、可审计、可解释、可运行的最优业务决策。 一句话定位: 这是一份把 operations research、linear / integer programming、CP-SAT、routing、scheduling、AI decisioning 和金融零售运营场景连接起来的高级产品架构手册。 边界说明: 本文不是 BA 入门、数学教材、供应商选型报告、法律意见或模型验证报告；正式落地必须结合业务 owner、risk、legal、compliance、data、security、architecture review 和 model risk governance。

---

Source Anchors

这些来源作为术语、架构和治理锚点。本文把它们转成 AI 产品、金融零售运营和企业架构可执行的工作语言。

---

1. 一句话定位

AI 决策系统的成熟表达不是“模型给一个分数”，而是:

AI predicts.
Optimization allocates.
Policy constrains.
Workflow escalates.
Audit remembers.

中文表达:

AI 负责预测和生成候选方案，优化模型负责在约束下选择行动组合，策略层负责边界控制，工作流负责例外升级，审计层负责复盘证据。

这份 playbook 关注的不是“如何写一个算法题”，而是如何把优化问题产品化为可上线的 decision service:

• 输入来自预测模型、业务规则、库存、人员、渠道、风险、合同和 SLA。
• 输出是可执行的排班、分流、定价、库存、催收、审核、路由或资源分配方案。
• 中间有 objectives、constraints、scenario analysis、sensitivity、exception workflow、human override 和 audit trail。
• 结果必须在金融零售场景中满足客户公平性、合规边界、操作韧性和业务可解释性。

---

2. 为什么重要

很多 AI 产品到生产阶段会卡在同一个问题:

模型知道“可能发生什么”，但业务需要决定“现在该怎么分配有限资源”。

金融零售里，真实决策通常不是单点预测，而是受约束的组合优化:

如果没有 OR / optimization 层，AI 产品容易退化成三种低成熟形态:

高级 AI 产品架构要把“预测”推进到“可执行决策”:

forecast / score / candidate
-> optimization model
-> feasible action plan
-> decision service
-> workflow execution
-> outcome feedback
-> model and constraint improvement

---

3. 优化决策服务架构

3.1 参考架构

flowchart TB
  E[Business events<br/>transactions, applications, cases, demand, inventory] --> F[Feature and state layer]
  F --> M[AI / forecasting services<br/>risk score, demand forecast, elasticity, response propensity]
  F --> C[Constraint registry<br/>capacity, policy, labor rules, SLA, risk appetite]
  M --> D[Decision request builder]
  C --> D
  D --> S[Solver decision service<br/>LP / MILP / CP-SAT / routing / scheduling]
  S --> P[Policy and guardrail check<br/>eligibility, fairness, compliance, authorization]
  P --> W[Workflow execution<br/>assign, schedule, price, route, queue, escalate]
  W --> A[Audit and evidence store]
  W --> O[Outcome feedback<br/>actual demand, handling time, fraud loss, recovery, SLA]
  O --> M
  O --> C
  S --> X[Scenario and sensitivity service]
  X --> B[Business review<br/>tradeoff, capacity, risk appetite]

关键设计原则:

3.2 Solver Decision Service 的产品边界

一个生产级 solver decision service 至少包括:

3.3 在线、准实时、离线三类运行模式

---

4. 问题建模

4.1 优化问题的基本结构

一个可落地的 optimization decisioning problem 通常由 7 类对象组成:

4.2 线性规划、整数规划、CP-SAT 的区别

4.3 建模语言示例

以 fraud review queue 为例:

Sets
  C = fraud cases
  R = reviewers
  T = review time buckets

Parameters
  p_c = fraud probability predicted by AI
  loss_c = estimated loss if case is not reviewed
  friction_c = customer friction cost if case is held
  a_r,t = reviewer availability
  skill_r,k = reviewer skill coverage
  handle_c = estimated handling time
  sla_c = latest acceptable review time

Decision variables
  x_c,r,t = 1 if case c is assigned to reviewer r in time bucket t, else 0
  y_c = 1 if case c is auto-released or deferred, else 0

Objective
  maximize expected prevented loss
  minus customer friction
  minus operational cost
  minus SLA penalty

Constraints
  each case assigned at most once
  reviewer capacity per time bucket
  skill eligibility
  high-risk cases reviewed before SLA
  fairness and customer harm guardrails

这段建模语言比“AI 按风险排序”更成熟，因为它明确表达了容量、技能、SLA、摩擦和风险取舍。

---

5. 目标与约束

5.1 Objectives: 优化什么

高级 AI + OR 产品必须把 objective 从口号改成可计算函数。

5.2 Constraints: 什么不能突破

约束不是“业务补充说明”，而是决策系统的控制面。

5.3 Hard constraints 与 soft constraints

不要把所有约束都设成 hard。生产系统如果过度硬化，会频繁 infeasible；如果过度软化，会把风险藏进 penalty 权重。成熟做法是:

不可违反的法律、资质、安全、授权边界 = hard constraint
可业务协商的体验、偏好、次级 SLA = soft constraint
需高层设定 appetite 的风险、成本、公平性 = governed tradeoff

5.4 Multi-objective tradeoffs

金融零售 AI 决策几乎都不是单目标问题。常见 tradeoff:

• Fraud loss vs customer friction
• Collections recovery vs customer harm
• Contact center SLA vs staffing cost
• Inventory availability vs markdown risk
• Pricing margin vs market share
• Workforce fairness vs operational efficiency

多目标处理方式:

成熟表达不是“我们优化综合得分”，而是:

主目标是什么。
哪些指标是不可突破 guardrail。
哪些指标可用权重交易。
权重由谁批准。
不同权重下的业务结果如何变化。
生产中如何监控 tradeoff 是否偏离预期。

5.5 Sensitivity 与 shadow prices

Sensitivity analysis 用来回答:

如果多 1 个审核员、多 1 小时门店工时、多 1 万预算、多 5% 库存容量，业务价值会增加多少。

Shadow price 在连续 LP 或 LP relaxation 中更有解释价值，它描述某个约束右侧资源增加一个单位时，目标函数的边际变化。对于 MILP / CP-SAT，整数性和逻辑约束会让 shadow price 不再直接等同真实边际价值，需要用 scenario analysis、relaxation、local re-solve 或 controlled experiment 来解释。

---

6. AI + OR 协同

6.1 Forecast-to-optimization

Forecast-to-optimization 是把预测模型的输出转成优化模型参数的过程。

Demand forecast
-> demand distribution by time / location / segment
-> staffing or inventory optimization
-> schedule / replenishment plan
-> actual demand and service outcome
-> forecast calibration and constraint update

关键不是“预测越准越好”这么简单，而是预测误差如何影响最优决策:

6.2 Agent proposes / solver decides

LLM Agent 在优化决策系统里有价值，但边界必须清楚。

推荐架构:

Agent reads context and proposes structured candidate:
  proposed objective changes
  proposed constraints
  proposed scenario
  explanation and assumptions

Validation layer checks:
  schema
  allowed fields
  policy compatibility
  data lineage
  owner approval requirement

Solver decides:
  feasible solution
  objective value
  binding constraints
  tradeoff summary

Policy and workflow decide execution:
  allowed action
  escalation
  audit event

6.3 AI + Optimization 的常见组合模式

---

7. 场景分析

7.1 Retail Workforce / Staffing Optimization

高级产品洞察:

• staffing 不是简单的“按预测客流配人”，而是技能、合同、偏好、法规、成本和体验之间的组合优化。
• 最有价值的 PM 输出不是班表本身，而是 capacity business case: 哪些时段的 shadow value 最高，哪类技能的边际价值最大。
• 如果 AI 只预测客流，不连接 solver 和 workforce management 系统，业务仍然要手工排班，产品价值会被消耗在操作层。

7.2 Fraud Review Queues

高级产品洞察:

• “按风险分从高到低审核”不是最优，因为它忽略了损失金额、处理时长、SLA、客户影响和 reviewer 技能。
• 如果两个 case 风险相同，预期损失更高、处理更快、SLA 更紧的 case 可能更优先。
• 误拦截成本必须进入 objective 或 guardrail，否则优化会倾向于过度保守。

7.3 Credit Collections Optimization

高级产品洞察:

• collections 的优化目标不能只看短期回款；客户保护和监管风险必须作为 hard constraint 或高优先级目标。
• AI 可以预测响应倾向，但不应把“最容易被联系成功”误解为“最应该联系”。
• 优化系统应能说明为什么选择短信、电话、人工、宽限、暂停或升级。

7.4 Inventory / Pricing Optimization

高级产品洞察:

• pricing 与 inventory 应联动优化。单独降价可能消化库存，却破坏毛利和品牌；单独补货可能增加滞销风险。
• AI 价格弹性模型必须进入 scenario，而不是单一确定值。高不确定性商品应设置更保守的价格动作。
• 对金融零售交叉场景，例如信用卡权益、积分兑换、保险附加服务，也可用库存 / pricing 思路优化额度、权益成本和客户价值。

7.5 Contact Center Scheduling

高级产品洞察:

• contact center 不只是排班问题，还涉及技能路由、渠道迁移、callback 策略和客户风险分层。
• AHT 预测误差会直接影响 capacity。需要把 AHT uncertainty 进入 scenario analysis。
• AI Agent 上线后，如果降低 AHT 但增加 repeat contact，优化目标就必须引入 downstream quality guardrail。

7.6 Routing / Scheduling for Field and Branch Operations

---

8. 例外工作流

Optimization decision service 必须把例外当成一等产品对象。生产系统真正危险的不是“求不到完美最优解”，而是求解失败后系统沉默、误执行或让运营人员无证据地手工修补。

8.1 例外类型

8.2 约束放松顺序

例外处理不能让一线人员临场猜测。应提前定义 relaxation hierarchy:

第一层: 可放松的体验偏好
  员工偏好、低优先级任务顺序、非关键渠道覆盖

第二层: 可批准放松的运营目标
  低风险 SLA、加班预算、外包使用量、低影响促销频率

第三层: 高层批准后才可调整的风险偏好
  fraud hold threshold、collections contact intensity、关键客户 service level

第四层: 不可放松的边界
  法规、授权、资质、客户保护、数据权限、资金安全

8.3 人工 override 不是失败，而是学习信号

每一次 override 都应该进入 analytics:

---

9. 治理与审计

9.1 NIST AI RMF 映射

9.2 Decision audit event

每一次优化决策至少要记录:

9.3 Model risk 不只在预测模型

AI + OR 系统至少有四类风险:

9.4 Release gate

上线前至少回答:

• 决策是否被分类为 customer-impacting、employee-impacting、financial-impacting 或 regulated。
• 每个 objective 和 constraint 是否有 owner。
• 权重、优先级和 guardrail 是否被批准。
• 是否有 baseline、challenger、scenario 和 stress test。
• infeasible、time limit、data failure 是否有明确 fallback。
• 是否能复现任意一次决策的输入、版本、输出和人工改动。
• 是否能监控客户伤害、公平性、SLA、成本、override 和 business value。
• 是否定义了 rollback 条件和责任人。

---

10. 模板

10.1 Optimization Problem Canvas

10.2 Objective / Constraint Table

10.3 Solver Architecture Template

Decision API
  receives business context, entity ids, time horizon, requested objective profile

Input assembler
  loads features, forecasts, resource state, policy version, constraint version

Validation layer
  checks schema, data freshness, permissions, missing values, scenario id

Model builder
  creates sets, parameters, variables, objective, hard constraints, soft penalties

Solver adapter
  calls OR-Tools / SciPy / PuLP-CBC / Gurobi with approved configuration

Result validator
  checks feasibility, policy compatibility, output completeness, reason codes

Explanation layer
  summarizes objective value, binding constraints, tradeoffs, scenario deltas

Workflow publisher
  sends executable actions to WFM, CRM, case management, pricing or queue system

Audit publisher
  writes trace id, versions, solver status, input hash, output, override hooks

Monitoring
  tracks latency, infeasible rate, solution quality, business KPI, guardrails

10.4 Scenario Analysis Template

10.5 Sensitivity / Shadow Price Template

使用原则:

• LP shadow price 可作为边际价值语言。
• MILP / CP-SAT 场景要用 re-solve、relaxation 和离散增量解释。
• 不把 shadow price 单独作为预算审批结论，必须结合实际可雇佣性、服务质量、客户影响和执行约束。

10.6 Exception Workflow Template

10.7 30-Day / Interview Output Template

---

11. 30 天训练计划

Week 1: OR for AI Decisioning 基础到建模

Week 2: LP / MILP / CP-SAT / Routing 方法选择

Week 3: AI + Optimization 产品架构

Week 4: Scenario、Sensitivity、Governance、Interview

---

12. 面试答案

12.1 为什么 AI 决策系统需要 operations research / optimization

30 秒回答

AI 负责预测风险、需求、响应概率和候选动作，但金融零售的真实决策通常受容量、SLA、合规、预算、技能和客户保护约束。Operations research 把这些约束和目标转成可求解、可审计、可执行的优化问题，让 AI 从“给分数”升级为“在约束下做最优行动组合”。

2 分钟回答

如果 fraud 模型给每个交易一个风险分，按分数排序只能解决优先级的一小部分。实际运营还要考虑审核员容量、技能、预计处理时长、客户误拦截成本、SLA 和监管要求。优化层可以把这些因素放进 objective 和 constraints，输出可执行的审核队列和分配方案。

架构上，我会把它设计成 forecast-to-optimization decision service: 模型输出预测参数，constraint registry 提供容量和政策，solver service 求解 LP / MILP / CP-SAT 或 routing 问题，policy gate 做最终控制，workflow 执行动作，audit store 记录版本、输入、约束、求解状态和人工 override。这样 AI 决策系统不仅更有效，也更可治理。

12.2 LP、MILP 和 CP-SAT 怎么选

30 秒回答

如果变量连续、目标和约束线性，用 LP；如果有是否选择、是否分配、整数数量，用 MILP；如果是复杂排班、互斥、覆盖、时间窗和逻辑约束很多，CP-SAT 往往更合适。选择不是看算法名，而是看决策变量、约束结构、求解时间和生产解释需求。

2 分钟回答

比如预算在渠道间连续分配，可以用 LP 做 baseline，也方便做 shadow price 和 sensitivity。Fraud case 分配给 reviewer 是 binary assignment，更适合 MILP。Retail workforce 和 contact center scheduling 有大量班次、休息、技能、互斥、偏好和覆盖规则，CP-SAT 的表达力会更好。Routing 则要考虑路径、容量和时间窗，通常用专门的 routing solver。

产品上还要考虑 SLA。如果在线同步只能给 200 毫秒，就不适合每次求大规模 MILP；可以用预计算策略、heuristic、缓存或分层求解。离线周排班可以给更长时间，追求更高质量方案和 scenario analysis。

12.3 如何处理 multi-objective tradeoffs

30 秒回答

我会先区分不可交易的 hard constraints、可交易的 business objectives 和上线后监控的 guardrails。多目标可以用 weighted sum、lexicographic priority、epsilon constraints 或 Pareto scenarios。关键不是把所有东西揉成一个分数，而是让权重、优先级、风险偏好和业务影响被 owner 明确批准并可审计。

2 分钟回答

以 fraud review 为例，目标至少包括预期挽损、客户摩擦、审核成本和 SLA。客户保护、授权和监管要求是 hard constraints；挽损和成本可以进入 objective；误拦截率、投诉率和 segment impact 是 guardrail。

如果风险团队要求先守住客户摩擦上限，我会用 epsilon constraint: 在 false positive impact 不超过阈值的前提下最大化挽损。如果高层要比较不同风险偏好，我会输出 Pareto scenario，让他们看到每降低一点摩擦会损失多少挽损。这样 tradeoff 是透明的，而不是藏在模型分数里。

12.4 怎么解释 forecast-to-optimization

30 秒回答

Forecast-to-optimization 是把 AI 预测结果作为优化模型参数，再由 solver 在约束下选择行动。比如预测每半小时呼入量和 AHT，然后优化坐席排班、技能覆盖和休息安排。预测告诉我们可能发生什么，优化决定我们该如何配置资源。

2 分钟回答

关键是预测输出必须带时间粒度、实体粒度、置信区间和版本。Contact center 里，呼入量预测、AHT 预测、转人工率预测会转成每个时段的 capacity demand。优化模型再考虑坐席技能、班次、休息、SLA、外包容量和成本，生成班表和溢出策略。

如果预测不确定性高，我不会只用一个点预测，而会做 base、upper band、lower band 和 stress scenario，观察方案是否稳定。生产上还要把实际呼入、等待时间、abandon rate、repeat contact 回流给预测模型和 constraint registry。

12.5 Agent proposes / solver decides 为什么重要

30 秒回答

Agent 擅长理解上下文、生成候选方案和解释，但不应该直接决定受约束的高影响行动。成熟架构应该让 Agent 提出结构化 proposal，solver 检查目标和约束并选择可行方案，policy gate 决定能否执行，workflow 和 audit 负责落地与留证。

2 分钟回答

例如门店运营 Agent 发现周五下午客流异常，提出“增加两名兼职并延长营业支持”。这个建议必须转成结构化输入: 哪些门店、哪些时段、哪些技能、成本上限和服务目标。Solver 再检查员工可用性、劳动规则、预算和最低覆盖，输出可行排班。Policy gate 再确认是否符合授权和审批要求。

这样可以保留 Agent 的解释能力和运营洞察，同时避免 prompt 直接覆盖劳动法规、预算、资质或客户保护约束。

12.6 Solver 找不到可行解怎么办

30 秒回答

不可行不是简单报错，而是产品工作流。系统应输出冲突约束、影响范围和可批准的 relaxation options，并按预设层级处理: 先放松体验偏好，再调整运营目标，高风险偏好需要批准，法规和授权边界不可放松。

2 分钟回答

以 contact center scheduling 为例，如果某天高峰双语技能不足，solver 可能 infeasible。系统需要说明是哪几个时段、哪类技能、哪些 SLA 约束冲突。可选动作包括启用 callback、调整休息、使用外包、批准加班、降低非关键队列 SLA，或将部分咨询引导到异步渠道。

但是不能放松敏感业务授权或合规边界。所有 relaxation 都要有 owner、审批和审计记录。长期看，不可行率本身是 capacity planning 的信号。

12.7 Shadow price 在业务里怎么讲

30 秒回答

Shadow price 可以解释一个资源约束多增加一单位时目标值的边际变化，适合 LP 或 LP relaxation。业务上可以说“多 1 小时高技能审核能力大约带来多少预期挽损”。但对 MILP 和 CP-SAT，不能机械套用，要用场景重求解和离散增量解释。

2 分钟回答

我会把 shadow price 用作 capacity business case 的起点，而不是最终结论。比如 fraud queue 的 LP relaxation 显示高技能 reviewer 小时的边际价值很高，说明这个约束是瓶颈。然后我会做 scenario re-solve: 增加 1 人、2 人、不同班次和不同技能组合，观察实际挽损、SLA、误拦截和成本变化。

这比只说“我们缺人”更有说服力，因为它把 headcount 或外包预算和可量化业务价值连接起来。

12.8 如何把优化决策系统做成可审计架构

30 秒回答

每次决策都要记录 trace id、输入数据版本、预测模型版本、约束版本、目标权重、solver 配置、求解状态、输出、policy check、人工 override 和最终结果。治理上按 NIST AI RMF 做 Govern、Map、Measure、Manage，确保 owner、风险、监控和整改闭环清楚。

2 分钟回答

金融零售里，优化决策可能影响客户权益、员工排班、信贷催收、欺诈拦截和定价。因此不能只保存最终结果。我们要能复现“当时为什么这么决定”。

我会建立 decision audit event，并在 release gate 检查: objective 和 constraint 是否有 owner，权重是否批准，scenario 是否覆盖压力情况，infeasible 和 data failure 是否有 fallback，客户伤害和公平性是否监控，人工 override 是否有原因和审批。这样 solver 才不是黑箱，而是可治理的 decision service。

---

13. 高级作品集表达

如果把本 playbook 转成作品集，可以用一个金融零售案例贯穿:

Case: AI-assisted fraud review queue optimization

Business problem
  Fraud model can score cases, but reviewer capacity is limited and customer friction is high.

Product architecture
  Feature service + risk model + constraint registry + MILP solver service + policy gate + case workflow + audit store.

Optimization model
  Variables: assign / release / hold / escalate.
  Objective: maximize expected prevented loss minus friction and SLA penalty.
  Constraints: reviewer capacity, skill, SLA, high-risk mandatory review, customer protection.

AI + OR collaboration
  AI predicts fraud probability, loss, handling time and friction.
  Solver chooses feasible action mix.
  Agent explains bottlenecks and proposes scenario narratives.

Governance
  NIST AI RMF mapping, audit event schema, override review, scenario stress test, rollback criteria.

Business value
  Higher prevented loss per reviewer hour, lower false positive friction, clearer capacity investment case.

面试中最强的表达不是“我懂 OR-Tools”，而是:

我能把 AI 预测、业务约束、风险偏好、solver 服务、工作流执行和治理审计连接成一个可上线的决策系统。