AI 产品经理产品开发全流程解析
本文以智能文档审阅系统（IDP）和工业互联网数字孪生—故障预测为例，介绍 AI 产品经理在产品开发全流程过程中，每一阶段的工作内容、工作流程及注意事项。结合具体案例帮助对 AI 产品经理感兴趣的同学深入理解。文中尽量避免使用特征向量、归一化、RNN 等专业词汇，确保内容通俗易懂。
一、需求定义
1. 核心目标
这一初始阶段集中在从业务角度理解项目的目标和要求，然后把理解转化为模型能力的定义和一个初步执行计划。不仅要有整体技术研判力（可行性、技术难度、关键技术点），还要有业务洞察力，可以定义出可执行有价值的好问题。
2. 关键流程
- 业务目标拆解：将模糊的业务痛点转化为具体的 AI 任务。
- 技术可行性评估：判断现有技术能否支撑业务目标。
- 资源预估：初步估算数据、算力及人力成本。
3. 注意事项
AI 产品经理在本阶段要特别注意模型能力边界和模型类型确定。明确哪些问题是 AI 能解决的，哪些是规则逻辑能解决的，避免过度依赖 AI。
4. 案例分析
这里说的模型类型除了回归、分类、聚类、序列之外，还要基于具体业务考虑其他情形，比如在线还是离线。因为如果目标客户比较注重数据安全，可能就会要求私有化部署，不允许连接外网调用模型接口。AI 产品经理在需求分析阶段明确模型基础要求，也方便工程师在后续模型预研及成本分析方面提前有所考虑。
关于模型能力边界。请看这一条业务需求'系统自动抽取合同签订日期、中标通知书通知日期并进行时序性校验，合同签订日期不能早于中标通知书通知日期'。AI 产品经理需要将此条业务需求的实现分解成先由模型执行抽取任务后，再由系统（平台）进行时序性比较。因为不同类型模型可执行的下游任务不同，仅以自然语言处理任务层级举例，我们这里提到的模型能力边界指的是第三次，即信息抽取、情感分析、问答系统、机器翻译和对话系统等。
二、模型预研
1. 核心目标
需求确定之后，AI 产品经理需要和工程师进行沟通，要判断目前积累的数据和沉淀的算法，是否可以达到我们的业务需求。以及对原始数据的初步理解，发掘值得关注的数据子集以形成对隐藏信息的假设。
2. 关键流程
- 数据盘点：确认现有数据量、质量及覆盖度。
- 算法选型：根据任务类型选择基准模型。
- POC 验证：小范围验证技术路线的可行性。
3. 注意事项
在这个环节中，可能还需要根据算法工程师的预估，对上一阶段的需求内容进行调整。若发现数据不足或技术瓶颈，需及时与业务方沟通调整预期。
4. 案例分析
此阶段往往需要 AI 产品经理跟算法工程师经过多轮沟通，根据业务目标及原始数据质量的预估，确定模型预研的可行性等问题。比如以智能文档分析（IDP）系统举例，因为文档类型及业务规则的多样性往往需要多个模型共同完成一项业务需求。比如对一份合同的审核既需要对合同基本信息的抽取（如甲方、乙方、签订日期），也需要对合同中建设内容的相似性进行判断，还需要对合同中的表格数据进行分析。这就需要 AI 产品经理与工程师多次沟通，确定模型融合等解决方案的设计。
三、数据准备
1. 核心目标
数据和特征决定了机器学习的上限，而模型和算法只是逼近这个上限。'数据准备'阶段往往会占用整个工程 60% 以上的时间。产品经理基于对业务的理解，帮助工程师判断哪些数据集更具备代表性，以及明确数据来源、数据质量处理措施。
2. 关键流程
- 数据清洗：去除噪声、异常值及重复数据。
- 数据标注：制定标注规范，组织标注团队。
- 数据增强：通过技术手段扩充样本多样性。
3. 注意事项
'数据质量'问题除了数据模式层面，还要关心应用场景下的数据质量问题，应用场景相关的数据质量问题，与研究问题的范畴和业务上下文有关，通常不容易发现，有一定规律但不存在通用的方法。
4. 案例分析
'数据异常'也许是被忽略的一些'正常场景'。 【业务背景】风电机组大部分采用同步变桨，在正常情形下，三个桨距角应该非常接近。因此，在变桨驱动系统异常研判中，常常会将三个桨距角的不一致性（如角度差或短期时序相关度）作为一个重要特征。 【数据现象 1】如下图所示，某个风电机组在 2013 年 8 月 9 日 21:45—21:47 的表现。三个桨距角的初始值都在 87.5°左右，然后三个桨距角逐步变为 0°。 【业务解读】这个过程实际上是调试过程中，变桨控制系统逐个重启造成的。在 2013 年 8 月 9 日 21:45:40 左右，第一个变桨控制电路进行了人工重启，然后依次对第二个、第三个进行了重启。 【对数据准备的启发】对于关键数据、关键结果要做必要的数据探索（画图或者看统计分布），数据中包含的内容超过我们的'预设'和'专家经验'。
