数据有缺失、有脏值，还能做 AI 问数吗？

很多企业想做 AI 问数时，会先担心一个问题：

我们的数据还不够干净，是不是不能开始？

如果要求所有数据都整理到完美再启动，项目往往很难推进。

但如果完全不管数据质量，AI 问数又会放大错误。

正确的做法，是先识别风险，再分层治理。

数据质量问题有哪些

常见问题包括：

• •字段缺失，例如会员等级为空；
• •格式不一致，例如日期、手机号、门店编码写法不同；
• •异常值，例如订单金额为负数或极端大；
• •重复记录，例如同一订单被导入多次；
• •口径不一致，例如退款、取消、赠品是否计入销售额；
• •维表不完整，例如门店归属区域没有维护。

这些问题在传统报表里已经存在。

AI 问数不会自动让它们消失。

先分清哪些问题影响回答

不是所有脏数据都同样严重。

如果用户问“本月全国销售趋势”，少量会员字段缺失可能影响不大。

如果用户问“高价值会员复购率”，会员等级缺失就会直接影响结论。

因此 AI 问数需要结合问题判断数据质量风险，而不是机械地说数据可用或不可用。

答案里要暴露风险

当数据存在明显缺失或异常时，系统不应该假装没有问题。

更合适的做法是告诉用户：

• •本次分析排除了哪些异常数据；
• •哪些字段存在缺失；
• •缺失可能影响哪些结论；
• •是否需要先做数据清洗；
• •后续可以如何修正。

这会让业务用户更信任系统。

数据质量治理要和问数闭环

AI 问数上线后，用户的问题会暴露很多数据问题。

例如问某个渠道 ROI 时发现成本字段缺失。

问门店毛利时发现原料成本没有同步。

问会员复购时发现会员 ID 关联不上订单。

这些都应该进入数据治理清单，而不是只在一次问答里结束。

BuildTable 的角色

BuildTable 适合承担数据接入、清洗、统一存储和建模工作。

它把原始数据整理成 AI 更容易理解、查询和解释的数据基础。

AskTable 再在这个基础上完成自然语言问数、追问、归因和报告。

如果发现数据质量问题，应该能回到 BuildTable 层持续优化。

结论

数据不完美，不代表不能做 AI 问数。

但企业不能让 AI 在脏数据上给出看似确定的结论。

更务实的路径是：先从高价值场景开始，标记质量风险，逐步治理数据，让 AI 问数和数据质量改进形成闭环。

参考来源

• •AWS Glue：Getting started with AWS Glue Data Quality
• •Databricks：Monitor data quality
• •Microsoft Fabric：Create a Fabric data agent