AI Requirements Mining / Process Knowledge Extraction Architecture 解读

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

重要说明: 本文是学习和内部架构训练材料, 不构成法律意见、合规结论、监管解释、审计意见、记录保留结论、模型验证报告或采购建议。正式项目必须由 Legal、Compliance、Privacy、Records Management、Information Security、Model Risk、Operational Risk、Internal Audit、Business Owner、Data Owner 和 Architecture 结合机构类型、司法辖区、产品、客户影响和内部政策确认。访问日期按 2026-06-30 记录。

Source Anchors

核心导读

AI Requirements Mining 不是把 PRD、SOP、工单和会议纪要丢给大模型生成 user stories。高成熟做法是把它设计成 requirements and process intelligence control plane：在权限、来源权威、证据引用、领域词表、流程变体、冲突检测、质量评分、traceability graph、验收/eval contract 和人工确认机制约束下，把分散材料转化为可审查的候选需求与流程知识。

核心价值不是“自动替代需求判断”，而是扩大 evidence surface：让团队系统性看见文档、日志、代码、测试、控制证据和实际流程之间的不一致，并把每一条候选需求的来源、权威等级、冲突、影响范围和验证条件清楚暴露出来。

问题定义

低成熟度需求挖掘通常是：

上传文档
  -> 让模型总结需求
  -> 生成 user stories
  -> 组织评审

这个流程的问题在于它把“语言生成”误认为“需求治理”。金融零售系统的真实需求分布在多个材料层：

问题不是“AI 能不能读材料”，而是系统能不能区分来源权威、材料新旧、证据类型、访问权限、事实与推测、设计流程与实际流程、候选需求与已批准基线。

核心原理/方法

需求挖掘的基本单位应该是 claim，而不是段落摘要。每个 claim 都要携带来源、引用、权威等级、时间、冲突关系、质量评分和验证条件。

Source authority ladder 示例：

核心知识对象：

抽取方法要组合使用：LLM 做语义抽取、归类和冲突提示；规则和 schema 做字段标准化；process mining 做实际路径发现；静态分析和 API schema 做实现约束；人工确认机制负责把候选内容提升为基线。

系统/架构模型

参考架构：

artifact connectors
  -> permission and retention filter
  -> document parsing, chunking and canonical metadata
  -> source authority and version resolver
  -> domain vocabulary and ontology service
  -> claim extraction and ambiguity detection
  -> process variant discovery
  -> traceability graph
  -> validation workbench
  -> baseline promotion and change impact engine
  -> evidence pack, monitoring and audit trail

关键组件：

Traceability graph 的最小 schema：

StakeholderNeed -> RequirementCandidate -> ApprovedRequirement
ApprovedRequirement -> BusinessRule / ProcessStep / DataObject / ControlRequirement
ApprovedRequirement -> SystemComponent / API / Model / Prompt / Policy
ApprovedRequirement -> AcceptanceCriterion / EvalCase / TestCase
EvidenceArtifact -> Claim -> RequirementCandidate
ChangeRequest -> impacted_by -> graph nodes

边类型要区分 supports、conflicts_with、derived_from、supersedes、implements、tests、controls、requires_review。没有边类型的“知识库”无法支持变更影响和审计。

关键机制与取舍

来源权威与材料新鲜度经常冲突。最新工单可能反映生产真实痛点，但未必有权改变已批准政策；批准政策可能权威更高，但过期或与实际流程偏离。系统应输出冲突，而不是自动合并成看似流畅的结论。

领域词表不是文档装饰，而是需求架构。金融零售中的 “customer”“account”“available balance”“settlement date”“case closed”“verified income” 等词往往跨系统含义不同。没有 vocabulary service 和 synonym/term boundary，AI 会把同词异义或异词同义混在一起。

流程挖掘要区分 designed process 与 actual process。SOP 说明应当怎么做，event logs 显示实际上怎么做，工单说明哪里经常坏，控制证据说明某次是否被复核。需求挖掘的价值在于暴露这些差异，而不是选一个来源当真相。

验收条件要从文本转成可观察 contract。成熟输出不应停在 “system shall improve user experience”，而应绑定输入、状态、规则、输出、时限、异常、证据和 eval case。对 AI 功能，还要定义 groundedness、引用完整性、拒答、隐私泄露、偏差、可重复性和人工覆盖条件。

变更影响分析应从 graph traversal 开始，而不是凭会议经验。一个政策阈值变化可能影响流程步骤、表单字段、API validation、模型特征、提示模板、测试用例、控制证据、报告和培训材料。AI 可以生成候选 impact set，但最终要由对应 owner 确认。

证据与控制

最小证据包：

Hallucination control 的重点不是让模型“更谨慎”，而是让系统拒绝无证据 claim：

no citation -> not promotable
low authority source -> requires confirmation
conflicting sources -> requires resolution
restricted source -> cannot be exposed downstream
generated synthesis -> candidate only
approved baseline -> versioned and auditable

记录管理和隐私控制要前置到 ingestion 与 retrieval。系统不能在生成后再想办法删敏感信息，因为模型输出和日志已经可能扩大数据暴露面。

金融零售/AI产品场景

数字开户流程改造中，系统可从 PRD、KYC policy、工单、call transcripts、drop-off logs、API errors 和控制证据中抽取需求和流程断点。成熟输出应包括身份验证失败路径、人工复核触发条件、资料缺口、客户沟通边界、模型/规则依赖、验收条件和证据链。

支付 exception workbench 的需求挖掘可以从 SOP、repair tickets、processor files、core posting logs 和审计发现中提取 exception taxonomy、cut-off risk、dual control、suspense aging 和 evidence requirements。AI 不应只生成页面功能清单，而要生成流程、数据、控制和测试的 trace graph。

AML investigation 工具升级时，系统可从 alert notes、SAR QA findings、CDD policy、case outcomes、调参记录和独立测试发现中提取证据缺口、常见误判、必填字段、升级条件和 narrative quality requirements。所有候选需求必须保留来源与适用边界。

AI copilot 本身的需求也要被 mining：哪些回答必须引用证据，哪些问题必须拒答，哪些工具调用需要审批，哪些输出要进入 audit ledger，哪些 eval case 阻止上线。需求挖掘系统与 AI 治理系统应共享 evidence 和 eval contract。

反模式

最终心智模型

AI Requirements Mining 的成熟度不在于生成多少需求条目，而在于能否把分散证据转成可治理的需求知识系统：

authorized artifacts
+ source authority
+ claim-level extraction
+ vocabulary and ambiguity control
+ process variant discovery
+ traceability graph
+ validation workbench
+ eval and acceptance contract
+ change impact and audit replay

一句生成文本不能成为需求；带来源、权威、冲突、owner、验收条件、影响路径和审批记录的 claim，才有资格进入基线。AI 的角色是扩大证据面、暴露不一致和降低分析摩擦，而不是替代业务责任与架构取舍。

---

SOTA 状态标注 (2026-07-01)

本篇属于第二、三遍深读池（参考架构/深读笔记），未列入 12 周主线必读。时效基线为写作时点；引用前请按 CLAUDE.md 全局时效性硬规则复查最新进展。模块级 SOTA 对照见 docs/AI_SYSTEMATIC_LEARNING_ROADMAP_2026.md 各周「2026 SOTA 对照」行与文末「SOTA 检查」。