AI 数据产品避坑实录：自动生成的结论什么时候最不靠谱
AI 数据产品避坑实录：自动生成的结论什么时候最不靠谱
"AI 说的"这三个字正在成为新一代的数据迷信。朱大喜 7 月拆了 3 个 AI 数据产品的"自动结论"，发现有些场景下，AI 给的答案还不如猜的准。
一、当"自动生成"变成"自动误导"
7 月份我们团队上线了一个"AI 数据洞察"功能：每周一自动扫描各个业务线的核心指标，发现有异常就自动生成分析报告和业务建议。听上去很智能对吧？实际上线后的第一周，自动生成了 23 条"异常"提示，其中只有 4 条是真正的业务异常，其他 19 条要么是周期性波动，要么是统计口径差异，要么干脆就是幻觉。
这篇文章不聊"AI 能不能做数据分析"，而是聊"AI 生成的数据结论，在什么情况下你不能信"。
二、四个最不靠谱的场景
场景 1：周期性波动被误判为"异常"
背景：每周一早上 9 点，DAU 环比下降 15%，AI 自动判定为"重大异常"，要求运营立即排查。
真相：每个周末 DAU 都会下降，周一开始回升，周中达到峰值。这是一个完美的周期性模式，但 AI 只会看"环比"这一个维度。
import pandas as pd import numpy as np from scipy import stats # 模拟 7 月份的 DAU 数据（有明显的周末效应） np.random.seed(42) dates = pd.date_range('2026-07-01', '2026-07-27', freq='D') # 工作日 ~100000，周末 ~85000，加 5% 随机波动 base_dau = np.where(dates.dayofweek < 5, 100000, 85000) dau = base_dau + np.random.normal(0, 2000, len(dates)) df_dau = pd.DataFrame({'date': dates, 'dau': dau.astype(int)}) # ❌ AI 容易犯的错：只看环比，周一必报警 monday_idx = df_dau[df_dau['date'].dt.dayofweek == 0].index[0] sunday_dau = df_dau.loc[monday_idx - 1, 'dau'] monday_dau = df_dau.loc[monday_idx, 'dau'] change_pct = (monday_dau - sunday_dau) / sunday_dau * 100 print(f"周日 DAU: {sunday_dau}, 周一 DAU: {monday_dau}") print(f"环比变化: {change_pct:.1f}%") # 输出：环比变化: 17.8% — AI 会报警！ # ✅ 正确的异常检测：同比（上周一）+ 周期性分解 # 使用 STL 分解（季节-趋势分解）提取周期性成分 from statsmodels.tsa.seasonal import STL dau_series = pd.Series(df_dau['dau'].values, index=df_dau['date']) stl = STL(dau_series, period=7) # 7 天周期 result = stl.fit() # 残差才是真正的"异常" residual = result.resid threshold = 2.0 * np.std(residual) # 2 倍标准差 anomalies = np.abs(residual) > threshold print(f"真正的异常日（残差>2σ）: {df_dau.loc[anomalies, 'date'].tolist()}") # 周一不会再被误报，因为它实际上符合周期规律场景 2：统计口径不一致导致的伪结论
背景：AI 报告说"用户留存率环比下降了 8%"，业务方紧急开会。但实际核查后发现，是 7 月调整了"活跃用户"的定义（从"登录即活跃"改成了"有核心行为才算活跃"），分母变小了，留存率反而上升了。AI 完全不知道口径变了。
这是一个 AI 永远无法自动解决的问题：数据口径是人的共识，不是算法能推断的。
解决思路：给指标打上"口径版本"标签，AI 在分析前先检查两个周期的口径是否一致。
from dataclasses import dataclass from datetime import date from typing import Optional @dataclass class MetricDefinition: """指标元数据：记录口径变更""" metric_name: str definition_version: str # 口径版本号 valid_from: date valid_to: Optional[date] sql_template: str description: str # 留存率有两种口径，AI 分析时必须感知版本切换 RETENTION_DEFINITIONS = { 'v1.0': MetricDefinition( metric_name='user_retention', definition_version='v1.0', valid_from=date(2025, 1, 1), valid_to=date(2026, 7, 1), sql_template="COUNT(DISTINCT retained_users) / COUNT(DISTINCT active_users)", description="活跃定义：当日有登录记录的用户" ), 'v2.0': MetricDefinition( metric_name='user_retention', definition_version='v2.0', valid_from=date(2026, 7, 1), valid_to=None, sql_template="COUNT(DISTINCT retained_users) / COUNT(DISTINCT core_active_users)", description="活跃定义：当日有核心行为（浏览/下单/评论）的用户" ), } def check_metric_compatibility(metric: str, period1_end: date, period2_end: date) -> dict: """ 检查两个时间段的指标口径是否一致 不一致时，AI 应该标注"口径变更，不可直接比较" """ def get_version(d: date): for ver, md in RETENTION_DEFINITIONS.items(): if md.valid_from <= d and (md.valid_to is None or d < md.valid_to): return ver return None v1 = get_version(period1_end) v2 = get_version(period2_end) if v1 != v2: return { 'compatible': False, 'warning': f'⚠️ 口径变更：{v1} → {v2}，环比数据仅作参考', 'old_definition': RETENTION_DEFINITIONS[v1].description, 'new_definition': RETENTION_DEFINITIONS[v2].description, } return {'compatible': True, 'warning': None}场景 3：因果关系被"强行创造"
背景：AI 发现"天气温度"和"外卖订单量"高度相关（相关系数 0.82），自动得出结论："高温驱动了外卖增长，建议高温天加大补贴力度"。
问题：AI 把相关性当成了因果性。实际上 7 月气温上升和订单增长是同时发生的，因为 7 月本身就是旺季。AI 没有实验设计能力，它的"因果推断"是基于模式匹配的猜测。
# 一个经典的"伪因果"检测 import numpy as np # 7月：气温上升 AND 订单增长 — 混淆变量是"月份/暑假" temperature = np.array([28, 29, 31, 32, 33, 34, 35, 34, 33, 32, 31, 30]) # ℃ orders = np.array([1000, 1050, 1080, 1120, 1150, 1200, 1220, 1190, 1170, 1140, 1100, 1060]) corr = np.corrcoef(temperature, orders)[0, 1] print(f"相关系数: {corr:.2f}") # 输出: 0.82 — 高度相关！ # 但这能说明"高温 → 多订外卖"吗？ # 不能。因为存在混淆变量：暑假（7月人们放假，时间多，外卖多） # 要看因果关系，需要控制混淆变量后重算偏相关系数场景 4：AI 幻觉编织的有模有样的"假结论"
最离谱的一次：AI 报告里写"7 月 15 日 DAU 下降了 22%，原因是当天发生了系统故障。"我们查了运维日志，当天根本没有故障。AI 是"推断"了一个最符合它训练的文本模式的原因强行塞进去的。
这不是技术故障，这是 LLM 生成文本的根本特性：当它不确定原因时，它会创造一个听起来合理的原因。在数据分析这个领域，这种能力特别危险——因为数据本身是客观的，但 AI 的解释可能完全是编的。
三、AI 结论可信度分级
基于 7 月的实战经验，我给 AI 自动生成的结论分了三个信任等级：
具体落地规则
| 结论类型 | 信任度 | 处理方式 |
|---|---|---|
| 数值计算（求和/均值/比率） | 🟢 高 | 自动推送 |
| 简单同比/环比 | 🟢 高 | 自动推送 + 标注口径 |
| 异常检测（统计检验） | 🟡 中 | 人工确认波动来源 |
| 相关性分析 | 🟡 中 | 标注"相关≠因果" |
| 因果推断 | 🔴 低 | 必须有 A/B 实验或因果推断方法支撑 |
| 归因分析 | 🔴 低 | 必须有人工验证 |
| 业务建议 | 🔴 低 | 仅供启发，不作为决策依据 |
四、给 AI 数据产品加"刹车"
我的建议是三层防御：
- 结论分级：上面表格里的三级信任体系，AI 输出的每条结论都要标注等级
- 置信度压制：AI 说"确定"≠ 真的确定，按实际准确率给每条结论标置信度
- 人工抽样：🔴 低可信度结论不自动发布；🟡 中可信度结论随机抽 20% 人工核查
五、总结
AI 做数据分析最大的问题，不是它不聪明，而是它太会"编故事"了。你给它一组上升的数据，它能给你写一篇头头是道的增长归因分析，引经据典、逻辑自洽，但你追问两句"你这个归因的依据是什么"——它就开始支支吾吾。
7 月的教训很简单：把 AI 当"数据助理"而不是"数据分析师"。让它做数值计算、做格式整理、做初步的异常筛查。因果推断和业务建议，留给人来做。不是不信任 AI，而是这本来就不是它该做的活。