AI Requirements Engineering / GQM / Eval Contracts 解读

面向对象: AI Product Lead / AI Architect / Senior BA / CBAP / Model Risk / QA Lead。 核心问题: 很多 AI 项目失败不是因为模型不够强, 而是因为需求仍停留在“做一个智能助手”“提高效率”“减少人工”这类愿望层。没有把业务目标拆成可测问题、指标、样本、阈值、上线门禁和运营反馈, AI 团队就只能用 demo 感觉替代工程证据。 学习目标: 用 Goal Question Metric (GQM) 的思想, 把 AI idea 转成 eval contract, 并让 PRD、架构评审、风险接受、上线门禁和生产监控共享同一套度量语言。

---

Source Anchors

一句话:

AI 需求工程不是把用户故事写得更细, 而是把业务目标、AI 行为、风险边界和上线证据绑定成可验证的 eval contract。

---

1. 为什么 CBAP 之后还需要升级

CBAP 能力已经覆盖需求获取、分析、建模、验证、干系人管理和价值交付。但 AI 系统引入了几个传统需求方法不擅长的问题:

对高级 BA / PM 来说, 重点不再是“会不会写 user story”, 而是能不能回答:

• 这个 AI 功能的业务目标能否被测量？
• 哪些问题必须被回答后才能上线？
• 哪些指标是产品成功指标, 哪些是模型质量指标, 哪些是风险控制指标？
• eval 样本是否代表真实工作流, 而不是只覆盖 demo happy path？
• 哪些错误可接受, 哪些错误必须人工拦截或禁止自动化？
• 生产中出现什么信号会触发暂停、回滚、重新训练或策略调整？

---

2. GQM 的核心思想

GQM 的基本结构是:

Goal -> Question -> Metric

在 AI 项目中需要扩展成:

Business Goal
  -> Decision Question
  -> Product / Model / Risk Metric
  -> Eval Dataset
  -> Acceptance Threshold
  -> Release Gate
  -> Monitoring Signal
  -> Ownership and Review Cadence

这就是 eval contract。它不是单独的测试文档, 而是连接需求、架构、数据、模型、风险和运营的契约。

2.1 Goal

Goal 不是“使用 AI”。Goal 要说明业务对象、改进方向、范围和约束。

弱目标:

用 AI 提高客服效率。

更强目标:

在信用卡争议交易场景中, 用 AI Copilot 帮助一线客服更快定位政策、交易证据和下一步动作, 在不降低合规准确率和客户信任的前提下, 将平均处理时长降低 15%。

2.2 Question

Question 把目标变成必须回答的判断问题:

• AI 是否能正确识别客户意图和争议类型？
• AI 引用的政策是否来自最新、授权、可审计的知识源？
• AI 建议是否减少处理时长, 还是只把认知负担转移给客服？
• AI 在不确定时是否会升级给人工或提示置信边界？
• AI 是否在高风险交易、投诉、监管敏感话术中保持保守？

2.3 Metric

Metric 需要分层:

---

3. AI Eval Contract

Eval contract 是 AI 需求的可执行版本。它回答“什么叫满足需求”。

Use Case:
  信用卡争议交易客服 Copilot

Goal:
  降低平均处理时长, 同时保持合规准确率和客户权益保护。

Decision Questions:
  Q1: Copilot 是否能识别争议类型和所需证据?
  Q2: Copilot 是否能从授权政策库引用正确依据?
  Q3: Copilot 是否能识别必须人工升级的场景?
  Q4: Copilot 是否会输出不允许的承诺、误导性话术或未经授权的退款建议?

Metrics:
  - dispute_type_accuracy >= 0.92
  - citation_precision >= 0.95
  - high_risk_escalation_recall >= 0.98
  - prohibited_claim_rate <= 0.01
  - p95_latency <= 4s
  - average_handle_time_reduction >= 15% in pilot

Eval Data:
  - 400 historical cases, stratified by dispute type, risk tier, channel, language
  - 80 adversarial / edge cases
  - 60 policy freshness cases
  - 50 human-written gold responses

Release Gate:
  - offline eval passes all critical thresholds
  - red-team high-risk failures remediated
  - pilot group shows no increase in complaint rate
  - compliance and operations sign-off recorded

Monitoring:
  - weekly regression eval
  - production sample review 5%
  - incident trigger if prohibited_claim_rate > 0.02 for any week
  - rollback if high-risk escalation recall drops below 0.95

Owner:
  PM: business outcome
  Architect: system controls
  Model Risk: eval adequacy
  Ops: review process

---

4. AI Requirement Taxonomy

高级 AI 需求不能只分 functional / non-functional。更有用的是按 AI 行为链条分类。

---

5. 从 PRD 到 Eval 的链路

AI PRD 中每个关键需求都应能追到 eval。

关键原则:

• 没有 eval 的 AI 需求只是愿望。
• 没有风险指标的 eval 只是性能测试。
• 没有生产监控的 release gate 只是一次性审查。
• 没有 owner 的 threshold 无法形成治理。

---

6. 金融零售场景

6.1 AML Alert Triage Copilot

Goal:

在不降低 SAR 风险识别质量的前提下, 帮助 AML analyst 更快聚合客户、交易、规则命中和历史处置依据, 将低风险 alert 的初审时间降低 20%。

Decision Questions:

• Copilot 是否正确总结 alert 触发原因？
• 是否能区分事实、推断和建议？
• 是否引用正确交易、客户档案和历史 case？
• 是否遗漏高风险 typology signal？
• analyst 是否因为 AI summary 降低必要调查深度？

Metrics:

6.2 Customer Service Copilot

重点不是“回答更自然”, 而是:

• 政策引用正确。
• 不承诺未经授权补偿。
• 不暴露内部风险规则。
• 不把复杂投诉错误降级。
• 能在信心不足时建议人工升级。

6.3 Credit Decision Support

信贷 AI 不能只看 prediction accuracy。需求要覆盖:

• adverse action reason 是否一致、可解释、合规。
• 模型建议是否被人工理解和适当挑战。
• 低收入、薄文件客户、特定地区客户是否出现系统性不利影响。
• override 是否被记录和复盘。
• 模型漂移是否会触发 credit policy review。

6.4 Wealth Advisor Assistant

财富/投顾 AI 的 eval contract 要区分:

• 教育性解释。
• 产品信息检索。
• 组合摘要。
• 个性化建议。
• 受监管的投资建议。

不同任务对应不同 automation level 和 risk gate。

---

7. 模板: AI Requirement Brief

# AI Requirement Brief: [Use Case]

## 1. Business Outcome
- Target business process:
- Current pain:
- Expected improvement:
- Non-negotiable constraints:

## 2. AI Task Boundary
- AI will:
- AI will not:
- Automation level: assist / recommend / decide / act
- Human control point:

## 3. Data and Knowledge Scope
- Authorized sources:
- Excluded sources:
- Freshness requirement:
- PII / sensitive data handling:
- Source owner:

## 4. GQM
| Goal | Question | Metric | Threshold | Owner |
|---|---|---|---|---|

## 5. Eval Contract
- Golden set composition:
- Edge cases:
- Red-team cases:
- Human review method:
- Release gate:

## 6. Production Monitoring
- Metrics:
- Alert thresholds:
- Review cadence:
- Rollback trigger:

## 7. Risk Acceptance
- Residual risk:
- Mitigation:
- Approver:
- Expiry / review date:

---

8. 常见反模式

---

9. 面试回答

Q1: 你如何把一个模糊的 AI 需求变成可交付项目？

30 秒版本:

我会先拒绝把“做 AI 助手”当需求, 用 GQM 把业务目标拆成必须回答的问题和指标, 再形成 eval contract: 样本、阈值、上线门禁、风险 owner 和生产监控。这样 PRD、架构、模型和风险团队讨论的是同一组证据。

2 分钟版本:

• 先定义业务 outcome 和 AI task boundary。
• 再用 GQM 找到关键 decision questions。
• 把问题映射到 business、product、model、risk、operation 指标。
• 定义 golden set、edge cases、red-team cases 和 human review 方法。
• 把阈值写成 release gate, 把漂移和异常写成 monitoring gate。
• 对金融场景, 我会特别关注客户权益、合规准确率、人工控制点和残余风险批准。

Q2: AI 产品的验收标准和普通软件有什么不同？

30 秒版本:

普通软件验收偏 deterministic pass/fail, AI 验收要覆盖概率行为、长尾错误、风险边界、人机协作和上线后漂移, 所以必须把 eval 和 monitoring 纳入需求本身。

追问准备:

---

10. 作品集交付物

如果要展示高级 AI PM / AI BA / AI Architect 能力, 可以做一套:

1. AI Requirement Brief。
2. GQM Matrix。
3. Eval Contract。
4. Golden Set Card。
5. HITL Matrix。
6. Release Gate Checklist。
7. Production Monitoring Dashboard Mock。
8. Risk Acceptance Note。
9. ADR: why this AI pattern is acceptable。

这套作品比“我会写 PRD”更有辨识度, 因为它说明你能把 AI 的不确定性转化为可治理的交付系统。