4. 数据可行性评估：数据源盘点、数据质量检查、标注可行性、数据隐私与合规初筛
数据是 AI 解决方案的燃料。数据可行性评估的目的，是在投入大量工程资源之前，系统性地判断现有数据是否足以支持模型训练与业务目标。评估结论将直接决定后续的技术选型和架构边界。本章从数据源、质量、标注、合规四个维度展开，给出可落地的检查框架。
4.1 数据源盘点
首先需要构建完整的数据源清单。盘点并非简单的文件罗列，而是要明确每个数据源在架构中的角色——是训练集、验证集、还是实时推理的输入流？
| 数据源类型 | 典型示例 | 系统边界与组件职责 | 常见接入风险 |
|---|---|---|---|
| 内部业务数据库 | CRM、ERP、订单日志 | ETL 模块从 OLTP 抽取，经过清洗层后写入特征存储 | 表结构频繁变更；权限隔离不足 |
| 日志/事件流 | Clickstream、IoT 传感器、App 埋点 | 流式管道（Kafka → Flink → 对象存储）作为实时特征入口 | 时间戳漂移；字段缺失；数据量突增导致背压 |
| 第三方 API / 爬虫数据 | 天气、交通、社交舆情 | 通过网关适配器注入数据湖，有独立的降级与缓存策略 | 响应延迟不可控；授权过期；数据格式变更无通知 |
| 人工标注 / 外部标注平台 | 语音转录、图像框选、NLP 实体 | 标注结果经质检流水线后写入标注存储，触发版本管理 | 标注一致性差；交付周期长；隐私协议覆盖不全 |
| 公有数据集 / 开源语料 | ImageNet、Common Crawl、权威统计年鉴 | 作为预训练或增强数据，需经过数据溯源与合规审查模块 | 版权与使用条款限制；领域漂移严重 |
盘点避坑： 不要只统计数据量（TB 数）。必须记录 时间范围、更新频率、字段级 schema、生产者/消费者系统。缺少这些元信息，后续质量检查将无从下手。
4.2 数据质量检查
质量检查应覆盖四个核心维度：完整性、一致性、准确性、时效性。每个维度需要预设可量化的指标与接受阈值。
4.2.1 典型质量检查项与决策阈值
| 维度 | 检查项 | 典型指标 | 红黄绿灯阈值参考 |
|---|---|---|---|
| 完整性 | 缺失率检查 | 每列空值占比 | 🟢 < 5% / 🟡 5% ~ 15% / 🔴 > 15% |
| 一致性 | 主键重复率 | 重复行数 / 总行数 | 🟢 < 0.1% / 🔴 ≥ 0.5% |
| 一致性 | 跨表外键匹配率 | 无法关联的孤立记录占比 | 🟢 < 1% / 🟡 1% ~ 5% / 🔴 > 5% |
| 准确性 | 离群值检测 | Z-score > 3 或 IQR 外数据点占比 | 🟢 < 1% / 🔴 ≥ 3% |
| 准确性 | 规则校验失败率 | 邮箱格式、日期范围等业务规则违反比例 | 🟢 < 0.5% / 🟡 0.5% ~ 2% / 🔴 > 2% |
| 时效性 | 数据新鲜度延迟 | 最近一次记录时间与当前时间差 | 按业务 SLA 设定（如超过 24 小时为红灯） |
落地建议： 质量检查不是一次性活动。应在数据湖/特征存储入口部署自动化质量门禁，使用 Great Expectations 或 Deequ 等开源工具定义测试套件，每次数据摄入自动触发检查并生成质量报告。
4.3 标注可行性
无论使用监督学习还是基于少样本的微调，标注资源的可获得性与质量都是核心瓶颈。标注评估需要回答三个问题：谁来标？、标多少？、怎么保证质量？
4.3.1 标注方案对比
| 方案 | 适用场景 | 成本基准 | 质量控制难度 | 推荐阶段 |
|---|---|---|---|---|
| 内部专家标注 | 医疗、法律、金融等强领域知识场景 | 高（人力时薪 × 专家系数） | 中（小样本高精度） | 种子集构建与验收测试 |
| 众包平台 / 服务商 | 图像分类、文本分类、实体抽取 | 中低（按条计费） | 高（需设计交叉验证与黄金样本陷阱） | 大规模产线标注 |
| 主动学习 + 半自动预标注 | 语义分割、命名实体识别 | 低（仅人工修正模型低置信度样本） | 中（依赖预标注模型稳定性） | 迭代优化阶段 |
| 合成数据生成 | 目标检测、异常检测、隐私敏感场景 | 低（算力成本） | 低（但存在域迁移风险） | 数据增强或冷启动 |
4.3.2 标注量估算原则
- 下限估算： 基于任务复杂度与期望精度，参考公开基线（如 ImageNet 1M/类，BERT 使用 BookCorpus + Wikipedia）。对于分类任务，每类至少需要 1,000 ~ 5,000 样本作为起点。
- 上限约束： 预算、标注周期、质检人力三者取最小值。
- 标注一致性： 随机抽取 10% ~ 20% 样本进行二次标注，计算 Cohen's Kappa 或 Fleiss' Kappa，低于 0.7 必须重新培训标注员或修订标注规范。
4.4 数据隐私与合规初筛
隐私与合规是信任链路的起点。初筛不通过，模型和系统可能面临法律风险、品牌损害乃至禁止上线。本阶段聚焦于识别红线问题，而非完成全面合规审计。
检查清单：
- 数据中是否包含个人身份信息（PII），如姓名、身份证号、手机号、邮箱、精确地理位置？
- 是否涉及《个人信息保护法》（PIPL）定义的敏感个人信息，如生物识别、医疗健康、金融账户？
- 数据来源是否获得用户明确同意？同意授权范围是否覆盖当前 AI 使用目的？
- 是否存在跨境数据传输需求？数据是否将存储或处理在境外服务器？
- 是否使用了受版权保护的第三方数据或商业数据，且无授权协议？
初筛后，针对红灯项制定初步应对策略：匿名化 / 脱敏 / 差分隐私、获取专项授权、替换数据源、或与人合作将数据隔离在合规沙箱内。
4.5 数据可行性风险矩阵
将四个维度的评估结论汇总到风险矩阵中，作为技术选型的输入。
| 风险类别 | 低风险（🟢） | 中风险（🟡） | 高风险（🔴） |
|---|---|---|---|
| 数据源风险 | 全部内网系统，schema 稳定，有灾备 | 部分依赖第三方 API，有降级方案但无冗余源 | 唯一数据源来自第三方，SLA 无保障 |
| 质量风险 | 所有检查项绿灯，门禁工具已就位 | 部分黄灯，有手动修复流水线 | 核心特征列缺失率 > 20%，无回滚方案 |
| 标注风险 | 内部专家可完成种子集，众包渠道已签合同 | 需探索主动学习，标注工具集成未完成 | 领域无标注人员，合成数据模型预研为零 |
| 合规风险 | 无 PII，无跨境，授权覆盖完整 | 有 PII 但可通过脱敏处理，法律团队已介入 | 涉及跨境 + 敏感个人信息 + 无用户同意 |
决策原则： 任何一个维度出现 🔴 高风险，项目应暂停架构设计，优先投入资源解决该风险再继续推进。
4.6 数据流与信任链路视图
下图展示了数据可行性评估阶段，数据从源端到模型训练管道的信任链路，以及质量与合规检查点的位置。
4.7 数据可行性评估验收标准
本章评估完成后，交付件应包含以下内容，作为后续技术选型阶段的输入。
| 验收项 | 交付物 | 责任人 |
|---|---|---|
| 数据源清单 | 详细的数据源描述表（包含 schema、时间范围、接入方式、SLA） | 数据工程师 + 业务分析师 |
| 质量门禁报告 | 自动生成的质量仪表盘，包含所有检查项的红黄绿灯结果 | 数据工程师 |
| 标注可行性分析 | 标杆分析：标注方案对比、成本估算、质检流程设计 | 算法工程师 + 项目经理 |
| 合规初筛报告 | PII 扫描结果、授权协议审查结论、风险项与缓解计划 | 法务 / 隐私合规团队 |
| 综合决策文档 | 数据可行性风险矩阵，以及明确的通过 / 有条件通过 / 不通过结论 | AI 架构师 |