跳到正文
阿里雲開發者社區 AI·· 3 小時前AI 評分52

AI 場景數據就緒度評估:四問四答

场景的数据就绪度评估:四问四答

AI 導讀

文章提出一套評估 AI 場景數據就緒度的四問法,檢查所需欄位、數據來源及口徑、歷史數據代表性,以及數據能否持續供給。配套評分模型將結果分為可直接立項、需先補數據及場景不成立三檔,分別對應 80 分以上、50–79 分及低於 50 分。文中並指出,數據就緒度須由業務與 IT 共同確認,不能只向 IT 部門查問。

正文

2026-11-03 1

版权

版权声明:

本文内容由阿里云实名注册用户自发贡献,版权归原作者所有,阿里云开发者社区不拥有其著作权,亦不承担相应法律责任。具体规则请查看《 阿里云开发者社区用户服务协议》和 《阿里云开发者社区知识产权保护指引》。如果您发现本社区中有涉嫌抄袭的内容,填写 侵权投诉表单进行举报,一经查实,本社区将立刻删除涉嫌侵权内容。

简介: 本文提出判断AI场景数据可行性的“四问法”:一问所需字段是否明确;二问数据源位置与口径是否清晰;三问历史数据是否具代表性;四问数据能否持续供给。辅以打分模型,量化评估场景落地成熟度,避免盲目立项。

场景选定的第一个门槛是数据。但"数据够不够"这个问题,问法很容易滑过去。问"有没有数据",会得到一个让人乐观的答案;问"数据能不能用",才是真问题。我用一个四问的结构来判断。

第一问:这个场景需要哪些字段,能列出来吗?

能列字段,才说明场景想清楚了。
判断方法:让业务方写出这个场景处理时需要看的每一项信息。不是"需要订单信息"这种,是"订单号、下单时间、金额、支付方式、履约状态"这种。
列不出来,说明场景还停在概念层。
REQUIRED_FIELDS = {
"费用报销/单据审核": [
"发票代码", "发票号码", "开票日期", "金额", "税额",
"销方名称", "销方税号", "购方抬头",
"报销单号", "费用科目", "城市", "职级",
],
}

第二问:每个字段现在在哪,口径是什么?

这一问要问到具体的人。
"数据在财务系统里"不是答案。要问:哪个表哪个字段、多久更新一次、字段的业务含义、有没有多个版本。
最容易被漏的是"多个版本"这个情况。 很多企业里,同一个概念在 HR 系统、OA 系统、报销系统里各存一份,格式还不一样。这时候"有没有数据"的答案是"有",但"能不能用"的答案是"要先做主数据对齐"。
@dataclass
class FieldSource:
field: str
system: str
table_column: str
update_freq: str # 实时 / 日 / 月
semantics: str # 业务含义一句话
conflicts_with: List[str] # 与哪些字段口径冲突
conflicts_with 这个字段是重点。它非空的字段越多,数据准备工作量越大。

第三问:历史数据够用吗?

不同场景对历史数据的需求不一样:
场景类型
历史数据要求
规则校验类
不需要历史,但需要样本(用于验证规则)
异常检测类
需要覆盖至少 3 个月,最好 1 年(含季节性)
预测类
需要 1-2 年,且要覆盖季节波动
归集对账类
需要历史数据的口径一致性证明
"够用"的标准不是时间长度,是分布代表性。 三个月的数据如果只覆盖旺季,预测模型学到的季节性是错的。
def check_representativeness(dates: List[date], min_months: int = 3) -> bool:
months_covered = {d.month for d in dates}
return len(months_covered) >= min_months and len(dates) >= 90
简单但有效的一个检查:评估集能不能覆盖全年的月份。 不能覆盖,就不要做预测类场景。

第四问:这批数据能用多久?

很多数据有生命周期。
"曾经有数据"和"现在还有数据"是两回事。 系统上线一年后,数据源可能已经改版、字段可能已经废弃、接口可能已经下线。
@dataclass
class DataDurability:
source: str
stability: str # stable / evolving / volatile
contract_exists: bool # 有没有数据契约(接口/字段约定)
migration_plan: Optional[str]
contract_exists 特别值得问。 有数据契约的系统组,改字段之前会通知;没有的系统组,改了你就知道——因为数据不对了。
没有数据契约的场景,要在方案里预留适配层。

一个打分模型

def readiness_score(scene: dict) -> dict:
s = 0

# Q1 字段清单完整
s += 25 if len(scene.get("required_fields", [])) >= 5 else 0
# Q2 数据源明确且无口径冲突
s += 25 if scene.get("conflict_count", 0) == 0 else 10
# Q3 历史数据充足
s += 25 if scene.get("history_months", 0) >= 6 else 0
# Q4 数据可持续
s += 25 if scene.get("contract_exists") else 5
return {"score": s, "verdict":
    "可直接立项" if s >= 80 else
    "需先补数据" if s >= 50 else "场景不成立"}

三档的划分逻辑很清楚:80 分以上数据基本就绪;50-79 分要先补一段;50 分以下说明这个场景现在的条件根本不具备。

一个常见误区

问数据的时候,只问IT部门。这是很多项目卡住的原因。业务方说"数据都有",IT 部门说"这个字段在我们这边没有"——两边说的都是真话。数据就绪度是业务和 IT 共同的责任:业务知道业务含义,IT 知道系统现状。缺一方,答案都不完整。

结论

四问的核心是把"有没有数据"这个模糊问题,变成四个可回答的具体问题:要什么字段、在哪、够不够长、能不能持续。答完这四问,一个场景的数据可行性基本清楚了。 答不清的,不要立项——先补数据,或者换个场景。
——以上为《智能体建设地图》的第三方解读。该地图由 CXOU® AI 研究院出品,是一份持续更新的企业智能体落地图谱。数智化转型网将持续以独立视角解读其中的重点场景与共性规律。如需查看完整地图可关注 CXOUNION 官方渠道。

來源:阿里雲開發者社區 AI · developer.aliyun.com