AI Requirements Engineering / GQM 与 Eval Contracts

配对阅读：本篇的操作手册版（模板/RACI/门禁/runbook）是 docs/AI_REQUIREMENTS_ENGINEERING_GQM_EVAL_CONTRACTS_PLAYBOOK.md。第一遍读本篇建立原理与架构判断；第二遍做案例时再用 playbook 查表落地，两者不需要重复精读。

本篇为经典论文精读（历史回顾/经典打底定位），机制正文以原论文为锚点；最新进展见文末「SOTA 检查」。

Source Anchors

核心导读

AI 需求工程的难点不是把用户故事写得更细，而是把模糊业务愿望转成可验证的 AI 行为、风险边界和上线证据。GQM 的价值在于把 Goal 拆成必须回答的 Question，再把 Question 绑定到可收集的 Metric；用于 AI 时，这条链还必须延伸到 eval dataset、acceptance threshold、release gate、monitoring signal、owner 和 review cadence。

成熟的 AI 需求不是“做一个智能助手”，而是一份 eval contract。它说明系统要改善什么业务结果，AI 负责哪类任务，哪些错误不可接受，用什么样本证明可上线，以及生产中哪些信号会触发暂停、回滚或重新评估。

核心问题

很多 AI 项目失败，不是因为模型完全做不到，而是因为需求一开始就不可验证。“做一个智能客服助手。”“提高 AML 分析效率。”“用 AI 降低欺诈损失。”“让信贷解释更清楚。”这些表达都是愿望，不是可交付需求。普通软件中，需求可以较多依赖确定性流程。点击按钮，系统创建记录。输入字段，系统校验格式。状态变更，系统触发通知。AI 系统不同。它的输出是概率性的，依赖数据分布和上下文，错误类型不止一个，用户会过度信任，模型和知识会变化，生产环境会漂移。因此，AI 需求如果仍然停留在功能描述，就会出现几个问题。第一，demo 很好看，但没有证明覆盖真实任务分布。第二，模型指标提升，但业务流程没有变好。第三，准确率看似不错，却隐藏高严重度错误。第四，UAT 通过，但上线后投诉、人工负载、漂移和合规风险暴露。第五，没人知道什么情况下应该暂停或回滚。AI 需求工程要解决的核心问题是：如何把业务目标、AI 行为、数据样本、错误边界、评测指标、上线门禁和生产监控绑定成一份契约。这份契约就是 eval contract。

方法贡献：GQM 为什么适合 AI

Goal Question Metric 的基本思想很简单：

Goal -> Question -> Metric

它反对直接从指标开始。指标必须服务于某个目标。目标必须通过一组问题变得可判断。问题必须通过指标和证据回答。这个方法适合 AI，是因为 AI 项目的最大风险恰好是“目标听起来正确，但没人知道怎么证明”。例如，“提高客服效率”不是一个足够好的 AI 目标。它需要变成：

Goal:
  在信用卡争议交易场景中，帮助一线客服更快定位政策、交易证据和下一步动作，
  同时不降低合规准确率、客户信任和人工可控性。

Questions:
  Copilot 是否能正确识别争议类型？
  是否能引用当前授权政策？
  是否能识别必须人工升级的场景？
  是否会输出未经授权的退款承诺？
  是否真正减少处理时长，而不是增加复核负担？

Metrics:
  dispute_type_accuracy
  citation_precision
  high_risk_escalation_recall
  prohibited_claim_rate
  average_handle_time
  complaint_rate

GQM 的价值是把模糊目标拆成判断问题。AI 场景还要继续扩展：

Business Goal
  -> Decision Questions
  -> Product / Model / Risk / Operation Metrics
  -> Eval Dataset
  -> Acceptance Threshold
  -> Release Gate
  -> Production Monitoring
  -> Owner and Review Cadence

这条扩展链就是 AI eval contract。

从需求到 Eval Contract

eval contract 是 AI 需求的可执行版本。它不是测试团队后期补的验收表。它应该在需求阶段就形成，驱动数据准备、架构选择、模型方案、风险评估、发布门禁和生产监控。一个 eval contract 要回答：

• 业务目标是什么。
• AI 在工作流中承担什么任务。
• 哪些任务明确不属于 AI。
• 目标用户和高风险场景是什么。
• 需要哪些数据和知识来源。
• 哪些错误类型可接受，哪些不可接受。
• 用什么样本证明能力。
• 指标和阈值是什么。
• 上线前必须通过哪些门禁。
• 上线后看哪些信号。
• 谁拥有指标、风险和复盘。

这让 AI 需求从“功能承诺”变成“证据承诺”。如果一个需求没有 eval contract，它本质上还只是 idea。

AI 需求与传统需求的差异

CBAP 或传统 BA 能力已经覆盖需求获取、流程建模、干系人分析、规则梳理和价值评估。AI 项目不是否定这些能力，而是要求在几个地方升级。

这意味着 AI 需求不能只描述 happy path。它必须描述错误、边界、拒答、升级、人工接管、长期监控和责任。

Goal：业务目标必须带约束

AI 目标不能写成“使用 AI”或“提高效率”。好的目标要说明业务对象、改进方向、范围和不可牺牲的约束。弱目标：

用 AI 提高客服效率。

更好的目标：

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

这个目标包含四个关键点。业务流程是信用卡争议交易。AI 任务是定位政策、证据和下一步动作。业务收益是平均处理时长降低。约束是合规准确率、客户信任和人工可控性不能下降。目标中的约束非常重要。AI 项目常见失败是单点优化。只优化 AHT，可能牺牲合规和客户体验。只优化 fraud loss，可能增加误拦截和投诉。只优化 AML 处理时长，可能降低调查深度。Goal 必须把“不能牺牲什么”写进去。

Question：把目标拆成可判断问题

Question 是 GQM 中最容易被低估的一层。它把目标变成必须回答的判断。如果目标是客服争议交易 Copilot，问题可以包括：

• Copilot 是否能正确识别争议类型和客户意图。
• 是否能从授权知识源引用正确政策。
• 是否能找到交易证据和状态。
• 是否能识别必须人工升级的场景。
• 是否会输出未经授权的退款承诺。
• 是否能降低处理时长，而不是把负担转移到复核。
• 是否在低置信或证据冲突时澄清或拒答。

好的 Question 有几个特点。它们连接业务目标。它们可以被证据回答。它们覆盖价值、质量、风险和运营。它们能暴露架构选择。例如，“是否能引用正确政策”会推动 RAG、source authority、document version 和 citation eval。“是否能识别必须人工升级的场景”会推动 risk classifier、escalation workflow 和 high-risk recall。“是否降低处理时长而不增加返工”会推动 pilot measurement 和 workflow analytics。

Metric：指标必须分层

AI 项目不能把所有问题都压缩成 accuracy。金融零售 AI 至少需要五类指标。

指标要区分 gate metric、supporting metric 和 diagnostic metric。gate metric 决定能否上线。supporting metric 帮助理解整体表现。diagnostic metric 用于排查原因。例如，客服 RAG 的 prohibited_claim_rate 可以是 gate metric。引用点击率可能是 supporting metric。不同文档类型的召回率可能是 diagnostic metric。如果不区分这些层次，团队容易被指标淹没，或者用错误指标做上线判断。

Eval Dataset：样本是需求的一部分

AI 需求必须定义 eval dataset。不定义样本，就无法知道指标代表什么。一个好的 eval dataset 应覆盖真实任务分布和高风险长尾。以信用卡争议交易 Copilot 为例，eval data 可以包括：

400 historical cases:
  stratified by dispute type, channel, risk tier, language and customer segment

80 adversarial / edge cases:
  policy conflict, stale policy, ambiguous request, missing evidence, angry customer

60 policy freshness cases:
  old fee policy vs current fee policy, effective date changes

50 human-written gold responses:
  approved wording, escalation decision and evidence references

样本集还要记录来源、时间范围、标注方法、代表性、排除条件、敏感属性处理和更新策略。否则，eval 很容易变成 demo 样本。金融零售尤其要注意高严重度低频样本。这些样本数量少，但上线风险大。例如信贷 adverse action、vulnerable customer、投诉升级、制裁命中、可疑交易 typology、投资建议边界和 PII 泄露。它们可能不适合用平均指标覆盖。需要作为 critical test 或 red-team set 独立门禁。

Threshold 与 Release Gate

指标只有绑定阈值和动作才有治理意义。“citation precision 要高”不是 gate。“客户可见政策回答的 citation precision >= 0.96，且任何高风险意图不得出现 unsupported final answer”才接近 gate。阈值应结合风险等级。低风险内部草稿工具可以容忍较高错误率，只要用户能编辑和不自动执行。高风险客户权益场景必须设置更严格阈值，并要求人工控制。release gate 还应说明失败动作。如果 high-risk escalation recall 未达标，是不能上线，还是只能内部 pilot，还是必须强制人工复核。如果 latency 超过目标，是降级模型，还是缩小范围。如果投诉率上升，是暂停 ramp，还是回滚 bundle。AI 需求中的阈值不应孤立存在。它必须连接 release decision。

metric + threshold + risk tier + action = release gate

Monitoring：需求要延伸到生产

AI 验收不能止于上线前。生产数据分布会变化，知识库会更新，模型会升级，用户会形成新行为，运营负载会波动。因此，eval contract 需要定义 production monitoring。监控不仅看模型质量，还要看业务、产品、风险和运营。例如客户服务 Copilot 上线后应看：

• answer groundedness。
• unsupported claim。
• high-risk escalation。
• user feedback。
• complaint。
• average handle time。
• manual edit rate。
• policy freshness。
• p95 latency。
• cost。

监控也要定义触发动作。

if prohibited_claim_rate > 0.02 in any week:
  freeze expansion, route high-risk intents to human, start incident review

if high_risk_escalation_recall < 0.95:
  rollback intent classifier or enforce manual review

if knowledge freshness SLA missed:
  disable answers for affected policy domains

这样，需求才真正覆盖 AI 系统的生命周期。

Owner 与 Review Cadence

AI eval contract 还必须有 owner。没有 owner 的指标没有治理意义。业务 owner 负责收益和流程影响。技术 owner 负责系统可靠性和版本。数据 owner 负责数据质量、权限和血缘。模型或 AI owner 负责评测、漂移和模型行为。风险或合规 owner 负责控制要求和残余风险。运营 owner 负责人工队列、SLA、纠错和培训。owner 的目的不是组织政治，而是保证每个 gate 和 monitoring signal 出现异常时有人行动。review cadence 同样重要。高风险系统可能需要每周生产抽样、每月模型表现复盘、每季度管理评审。低风险内部工具可以轻一些。没有复盘节奏，eval contract 会在上线后过期。

为什么有效

GQM 和 eval contract 有效，是因为它们把 AI 项目从 demo-driven 转成 evidence-driven。demo 展示的是几个样本上的可能性。eval contract 定义的是系统在任务分布、风险边界和生产环境中需要达到的条件。它还让不同团队在同一语言上协作。业务团队能看到目标和收益约束。产品团队能看到任务边界和用户行为指标。模型团队能看到评测样本、指标和阈值。架构团队能看到数据、知识、系统和监控需求。风险团队能看到 high-risk errors、残余风险和控制证据。运营团队能看到人工接管、复核负载和 SLA。这比“模型准不准”更接近真实交付。它也能防止局部优化。如果只优化模型 accuracy，可能牺牲可解释性、延迟、成本、人工负载或客户公平。eval contract 把这些约束放在同一张图里。

局限和误用

第一类误用是指标堆砌。指标越多不代表需求越清楚。每个指标都应能追溯到 Goal 和 Question。第二类误用是把 prompt 当需求。prompt 是实现 artifact，不是需求本身。需求应描述任务、边界、证据和验收条件。第三类误用是 eval after build。如果系统建完才想怎么评估，架构、数据和产品流程可能已经错位。第四类误用是只测 happy path。AI 产品真正的风险在边界、冲突、长尾和高严重度错误。第五类误用是平均指标掩盖风险。总体 groundedness 很高，不代表 vulnerable customers、非英语客户、薄文件客户或特定渠道没有问题。第六类误用是把 LLM judge 当唯一验收。LLM judge 可以帮助扩展评测，但高风险场景需要 human calibration、golden set 和错误分析。第七类误用是上线后不更新 contract。eval contract 应随着业务政策、数据分布、模型版本和生产事件更新。

架构和产品价值

AI 需求工程的架构价值在于提前暴露系统能力需求。如果 eval contract 要求 citation precision，架构必须支持 source authority、document version、retrieval logging 和 claim grounding。如果 contract 要求 high-risk escalation recall，架构必须有 intent/risk classifier、human handoff 和 case workflow。如果 contract 要求 monitoring 和 rollback，架构必须有 observability、release bundle 和 incident trigger。如果 contract 要求 segment analysis，数据和模型 pipeline 必须保留必要 slice 信息，并处理隐私与公平要求。产品价值在于把 AI 能力边界说清楚。“AI Copilot 帮助客服处理争议交易”太宽。eval contract 会逼团队说明：

• 哪些争议类型纳入第一版。
• 哪些客户意图必须人工。
• AI 输出是建议、草稿还是最终答复。
• 用户或员工如何纠错。
• 错误会造成什么 harm。
• 价值如何测量。

这使产品范围更稳，架构选择更可解释，风险讨论更具体。

金融零售系统案例

信用卡争议交易客服 Copilot

目标可以写成：

在信用卡争议交易场景中，
帮助一线客服更快定位政策、交易证据和下一步动作，
在不增加投诉和合规错误的前提下，
将平均处理时长降低 15%。

关键问题包括：

• 是否正确识别争议类型。
• 是否引用当前政策。
• 是否找到交易状态和可用证据。
• 是否识别必须人工升级或投诉流程的场景。
• 是否避免未经授权的退款承诺。
• 是否降低 AHT 且不增加返工。

指标可以包括 dispute_type_accuracy、citation_precision、high_risk_escalation_recall、prohibited_claim_rate、AHT、complaint_rate 和 manual_edit_rate。上线门禁可以要求 critical risk metric 全部通过，pilot 期间投诉率不升高，人工编辑不显示系统性错误。

AML Alert Triage Copilot

AML 场景的目标不是“自动判断 SAR”。更合理的目标是：

在不降低可疑活动识别质量的前提下，
帮助 analyst 聚合客户、交易、规则命中、历史 case 和 typology 线索，
将低风险 alert 初审时间降低 20%。

关键问题包括：

• 是否正确总结 alert 触发原因。
• 是否区分事实、推断和建议。
• 是否引用正确交易和客户资料。
• 是否遗漏高风险 typology signal。
• analyst 是否因 AI summary 降低必要调查深度。

指标包括 critical_fact_omission_rate、citation_precision、high_risk_typology_recall、analyst_edit_quality、triage_time 和 QA finding rate。这里的 high-risk omission 应作为 gate，而不是被平均准确率掩盖。

Customer Service RAG

客户服务 RAG 的需求重点不是“回答更自然”。它应围绕政策正确、引用可追溯、边界清晰和人工升级。eval contract 要覆盖：

• 当前政策与过期政策冲突。
• 产品类型差异。
• 投诉、争议、信贷、投顾等高风险意图。
• 客户情绪激烈或问题含糊。
• 文档缺失和知识库权限限制。

指标包括 groundedness、citation_precision、answerability_refusal、high_risk_escalation、unsupported_claim、customer_feedback 和 complaint。如果知识库 freshness SLA 未满足，系统应禁用相关域回答，而不是继续猜。

Credit Decision Support

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

• adverse action reason 是否来自受控 decision record。
• 客户解释是否与政策一致。
• 人工是否能理解和挑战模型建议。
• 特定客户群体是否出现系统性不利影响。
• override 是否记录并复盘。
• 模型漂移是否触发 policy review。

eval dataset 应按产品、渠道、客户类型、收入证明状态、薄文件客户、地区和决策结果分层。高风险门禁应包括 reason correctness、fair lending slice、appeal path completeness 和 prohibited wording。

Wealth Advisor Assistant

财富和投顾 AI 的需求必须先区分任务层级。教育性解释、产品信息检索、组合摘要、一般市场观点、个性化建议和受监管投资建议不是同一类任务。每一类任务对应不同 automation level、证据要求和人工控制。eval contract 要说明：

• 哪些输出只是教育信息。
• 哪些输出需要 suitability 数据。
• 哪些场景必须转人工顾问。
• 哪些话术构成受监管建议。
• 如何记录客户风险承受能力和产品披露。

如果没有任务分层，系统很容易在自然语言中越过监管边界。

Eval Contract 示例

下面是一个压缩结构，用于理解字段之间的关系。

Use Case: Credit card dispute service Copilot
Goal: reduce AHT by 15% in pilot without increasing complaints or compliance errors.
Boundary: classify dispute type, retrieve policy, summarize transaction evidence, draft next-step guidance for agent review.
Not allowed: authorize refunds, resolve formal complaints, or send customer communication without agent confirmation.
Questions: dispute type? current policy? high-risk escalation? prohibited promises? handling time without rework?
Metrics and gates: dispute_type_accuracy >= 0.92; citation_precision >= 0.96; high_risk_escalation_recall >= 0.98; prohibited_claim_rate <= 0.01; p95_latency <= 4s; no complaint increase in pilot.
Eval data: stratified historical cases, stale-policy edge cases, missing-evidence cases, angry-customer cases, red-team cases for unauthorized refund promises.
Release gate: critical metrics pass, compliance review signs off, pilot has no complaint increase, rollback and human escalation workflow tested.
Monitoring: weekly regression eval, 5% production sample review, incident trigger for prohibited claim spike, rollback trigger for escalation recall drop.

这个示例的重点不是格式，而是链条。业务目标、任务边界、问题、指标、样本、门禁和监控是一体的。

学习验证

读完这一篇后，应能完成以下验证任务：

1. 把“做一个智能客服助手”改写成一个带约束的 Business Goal。
2. 为该目标写 8 个 Decision Questions，覆盖价值、质量、风险、用户控制和运营。
3. 将每个问题映射到 business、product、model/system、risk 或 operation metric，并区分 gate、supporting 和 diagnostic。
4. 设计 eval dataset，包含正常样本、edge cases、red-team cases、policy freshness cases 和 high-severity low-frequency cases。
5. 为 AML Alert Triage Copilot 写 eval contract，明确哪些错误是 critical gate。
6. 为 Credit Decision Support 设计 monitoring trigger，说明什么情况下暂停、回滚或进入 policy review。
7. 检查一个已有 PRD，标出哪些 AI 需求没有 eval、没有 owner、没有生产监控或没有风险边界。
8. 写一条 ADR，说明为什么某个 AI use case 的 release gate 选择 human-calibrated eval，而不是只用 LLM judge。

关键结论

AI 需求工程的核心是把不确定的 AI 行为变成可验证、可监控、可治理的交付契约。GQM 提供从目标到问题再到指标的推导方法。eval contract 将这条链扩展到样本、阈值、发布门禁、生产监控、owner 和复盘节奏。金融零售 AI 项目不能只写功能需求和用户故事，还要定义数据覆盖、错误边界、人工控制、风险指标、残余风险和上线后触发动作。掌握这套方法的标志，不是会写更多需求文档，而是能把一个模糊 AI idea 转成团队可以设计、开发、验证、上线、监控和问责的系统契约。

---

SOTA 检查 (2026-07-01)

• 本篇的「eval contract」框架已成为业界主流实践：2026 年这一做法有了通用名字——Eval-Driven Development（先定义 evals 再构建应用），学术侧有配套过程模型与参考架构论文《Evaluation-Driven Development of LLM Agents》(arXiv 2411.13768, 2024-11)。当前生产评测的典型形态是：200-500 条 golden dataset + 分阶段自动质量门禁 + 生产抽样监控，与本篇「样本→阈值→release gate→monitoring」链条一致。主流评测框架（2026 年现役）：DeepEval、Promptfoo、MLflow Evaluation、Arize Phoenix、LM Evaluation Harness。
• LLM-as-judge 已是规模化评测的默认手段（2026 现状），但本篇「不能把 LLM judge 当唯一验收」的警告依然成立：行业共识仍要求高风险场景配 human calibration 与 golden set。库内配套实操见 docs/aipa/day16-llm-as-judge-rubric.md（judge rubric 设计）与 docs/aipa/day17-judge-calibration.md（judge 与人工标注校准），CI 阻断式 eval gate 落地见 docs/aipa/day19-blocking-ci-eval-gate.md。
• NIST AI RMF 锚点仍有效但需配新 Profile 阅读：AI RMF 1.0 之后，NIST 于 2024-07 发布 Generative AI Profile（NIST-AI-600-1，覆盖 confabulation、数据隐私、有害偏见等 GenAI 特有风险的 govern/map/measure/manage 动作）；2025-03 更新强调模型来源（provenance）、数据完整性与第三方模型评估；RMF 1.1 补充指南预计持续到 2026 年发布。读本篇的 Govern/Map/Measure/Manage 循环时应以 GenAI Profile 为落地入口。
• GenAI 需求工程本身成为活跃研究方向：系统性综述《Generative AI for Requirements Engineering》(arXiv 2409.06741, 2024-09) 覆盖 2019-2025 共 238 篇文献；面向 GenAI 软件的人工监督需求（human oversight requirements）研究见 arXiv 2511.13069 (2025-11)——与本篇「人工升级/接管必须写入需求」的主张同向。
• 不随版本过时的框架性结论：GQM 的 Goal→Question→Metric 推导链、指标分五层（business/product/model/risk/operation）并区分 gate/supporting/diagnostic、risk-tiered release gate（metric+threshold+risk tier+action）、监控触发动作与 owner/review cadence——这些是治理结构，不依赖任何具体模型或评测框架版本。本篇操作化版本见库内 docs/AI_REQUIREMENTS_TO_EVAL_COOKBOOK.md 与 docs/AI_REQUIREMENTS_ENGINEERING_GQM_EVAL_CONTRACTS_PLAYBOOK.md。