### 第2章 技术可行性边界检查：算法成熟度、算力需求、数据获取
本章聚焦于「技术可行性」这一核心评审环节，确保AI产品需求在算法、算力和数据三个维度上具有坚实的落地基础，避免因技术预判失误导致项目陷入“做不出来”或“做出来也没法用”的困境。
---
#### 2.1 适用场景
- 产品经理提交的《AI产品需求原型》包含新型或高复杂度算法模块（如大语言模型、多模态模型、强化学习、GAN网络等）。
- 当前团队需评估是否自研核心算法，或采用开源/商业API方案。
- 需求原型中涉及大量实时推理、高并发或边缘端部署，需确认算力资源是否匹配。
- 模型训练或推理依赖尚未明确的第三方数据源、数据标注或隐私合规数据。
---
#### 2.2 前置条件
- 已具备《AI需求原型文档》（版本≥1.0），其中明确算法模块功能描述、性能指标（准确率、召回率、延迟、吞吐量）。
- 已有初步的《数据词典》和《数据源清单》，包含数据字段、规模、更新频率及可用权限。
- 团队或外部合作伙伴已提供《算力资源配置清单》（云/本地/混合），包括GPU型号、显存、CPU核数、内存、带宽。
---
#### 2.3 操作步骤
| 步骤 | 动作描述 | 输出物 | 负责人 |
|------|----------|--------|--------|
| S1 | 算法成熟度评估 | 《算法可行性分析表》 | AI架构师 |
| S2 | 算力需求估算 | 《算力预算与资源规划》 | 基础设施负责人 |
| S3 | 数据获取可行性审查 | 《数据可用性评估报告》 | 数据工程师 |
| S4 | 风险整合与Checklist签署 | 《技术可行性Checklist（签字版）》 | 产品经理、技术负责人 |
**S1：算法成熟度评估**
- 查证目标算法是否为**已公开验证**的成熟方案（如ResNet、BERT、GPT系列），记录论文/开源仓库地址。
- 若算法为**自研/未公开**，要求提供原理验证（POC）结果或最小可行实验数据。
- 检查算法对输入数据的**鲁棒性**：是否对噪声、缺失值、分布偏移敏感。
- 评估算法**可解释性**：是否需要可解释AI（XAI）输出，如决策树可视化或注意力热图。
**S2：算力需求估算**
- 根据模型参数量、输入数据尺寸、推理延迟要求，计算单次推理所需算力（FLOPS）。
- 推算**峰值并发数**场景下的总算力需求，并与当前资源清单对比。
- 区分**训练阶段**与**推理阶段**的算力需求，训练往往需要更高算力且耗时更长。
- 记录**显存/内存水位**：若单卡显存不足以容纳模型，需评估模型并行或流水线并行方案。
**S3：数据获取可行性审查**
- 核实所需数据是否为**公开数据集**、License是否允许商业使用。
- 若需**自采/购买**数据，评估数据成本、标注人力投入及合规风险（个人信息保护法、GDPR）。
- 检查**数据质量**：数据是否包含缺失值、不一致标签、异常分布等。
- 确认**数据更新频率**是否适配模型训练/推理周期，避免数据过期导致模型退化。
---
#### 2.4 输入输出物
| 输入物 | 输出物 | 模板/格式 |
|--------|--------|------------|
| AI需求原型文档 | 《算法可行性分析表》 | XLSX / Markdown |
| 数据词典、数据源清单 | 《数据可用性评估报告》 | PDF / Confluence |
| 算力资源配置清单 | 《算力预算与资源规划》 | PDF / 在线表格 |
| 技术团队能力矩阵 | 《技术可行性Checklist（签字版）》 | 带有签名的PDF或电子签 |
---
#### 2.5 责任边界
| 角色 | 责任范围 | 不允许的行为 |
|------|----------|--------------|
| 产品经理 | 提供需求原型的算法场景描述、性能指标红线、数据需求与合规要求 | 替代技术团队做技术选型或算力估算 |
| AI架构师 | 主导算法成熟度评估、算力估算、提供架构建议 | 忽视数据风险或合规约束 |
| 数据工程师 | 数据可用性审查、数据质量检查、数据获取计划 | 负责算法选型或预算审批 |
| 基础设施负责人 | 提供当前算力资源详情、评估扩容方案与成本 | 承诺未经核实的第三方算力资源 |
---
#### 2.6 记录材料
- **《技术可行性Checklist》**：逐项勾选并记录结论、风险等级、缓解措施。
- **《评审会议纪要》**：记录争议点、漏评估项、待办事项及排期。
- **《变更控制表》**：若需求原型因技术不可行调整算法或降级性能指标，需记录变更原因与影响范围。
---
#### 2.7 异常处理
| 异常类型 | 典型场景 | 应对策略 | 触发下一个环节条件 |
|----------|----------|----------|-------------------|
| 算法成熟度不足 | 需求依赖未验证的GAN或强化学习模型 | 要求提交POC结果；若POC失败，切换到已验证的替代算法 | POC成功或替代方案通过评审 |
| 数据获取不可行 | 所需数据版权不明确或许可费用过高 | 探索合成数据生成或与数据合作方签订数据共享协议 | 数据获取计划获得法务和合规批准 |
| 算力资源严重不足 | 模型参数量过大，当前GPU仅1024 GB显存 | 评估模型压缩、量化、剪枝、知识蒸馏；或申请预算扩容 | 模型优化或扩容方案通过财务评审 |
| 关键数据质量极低 | 标注错误率超过30%，或数据分布严重不均衡 | 要求数据工程师/标注团队重新清洗或采样；标注预算追加 | 重新清洗后二次通过数据质量检查 |
---
#### 2.8 验收标准
- [ ] 《算法可行性分析表》中所有算法均有成熟度标记（已量产验证✅ / 公开论文✅ / 内部POC完成✅ / 待验证❌）。
- [ ] 《算力预算与资源规划》中训练/推理峰值算力需求与实际可用资源相差不超过±20%。
- [ ] 《数据可用性评估报告》中至少90%的所需数据源已获得可用性确认或获取计划。
- [ ] 技术可行性Checklist中无高风险栏位未分配缓解措施。
- [ ] 所有责任人在《技术可行性Checklist（签字版）》上完成电子签字。
> **提示**：本章所有评估结论应作为下一章「系统架构边界」的输入。若算法、算力或数据任一维度出现不可解封风险，建议先输出《技术不可行性报告》并触发需求变更或项目中止评审，再进入后续章节。
---
#### 技术可行性边界概览