数据科学到底在做什么：从业务问题到可计算问题

很多人第一次听到“数据科学”时，脑海里浮现的是算法、模型、代码、黑箱预测。但在真实业务里，数据科学更像一门“翻译术”：把含糊的业务诉求翻译成可计算、可验证、可迭代的问题，再把计算结果翻译回可执行的决策。你会发现，真正困难的往往不是“用什么模型”，而是“到底在解决什么问题、用什么来衡量、如何证明真的有用”。

> 本章核心观点：数据科学的起点不是数据，也不是模型，而是决策。所有分析与建模最终都要服务于某个“要不要做/做多少/做哪个”的选择。

<!-- tags: 数据思维, 问题定义, 指标体系, 可计算问题, 评估与迭代 -->

业务问题与可计算问题：差的不是技术，是“可操作性”

业务问题的典型表达

业务方常见的提法通常长这样：

• “能不能提升用户活跃？”
• “我们想减少投诉。”
• “想让销量更好一点。”
• “能不能做个智能推荐/智能风控？”

这些话方向正确，但对计算机来说信息不足：活跃怎么定义？投诉减少多少算成功？销量提升靠促销还是靠选品？推荐的目标是点击还是留存？风控的代价是误杀还是放过？

可计算问题的三个必要元素

把业务问题变成可计算问题，至少要补齐三块：

1. 决策动作（Action）：系统或团队要做什么改变？（例如：给哪些用户发券、是否拦截交易、把哪个内容排到前面） 2. 衡量指标（Metric）：用什么量化“好/坏”？（例如：次日留存、投诉率、GMV、拦截召回率） 3. 边界与约束（Constraint）：成本、时效、合规、体验底线是什么？（例如：误杀率不能超过0.3%，发券预算每周不超过50万）

> 定义：可计算问题 > 能被明确输入输出、可用数据验证、可在约束下优化的任务描述。它不一定是“机器学习问题”，但一定是“可评估的问题”。

一个最小示例：从“提升活跃”到可计算问题

• 业务问题：提升活跃
• 追问与澄清：
• 活跃指什么？日活（DAU）还是使用时长？
• 提升多少？一周内还是一个季度内？
• 我们能做什么？推送、活动、功能改版、内容供给？
• 可计算版本（示例）：
• **决策动作**：对过去7天未启动App的用户，是否发送“功能亮点+优惠券”的推送
• **指标**：推送后48小时内启动率（primary），以及7日留存（guardrail）
• **约束**：推送频次≤每周2次；优惠券成本≤每周30万；投诉率不升高

注意：这里仍未写“用XGBoost还是深度学习”。因为在你把问题写清楚之前，模型选择没有意义。

数据科学在做什么：一条从“问题”到“结果”的流水线

你可以把数据科学看成一条稳定的工作流：先把问题写成“可计算的”，再用数据与实验去验证，最后把结果嵌入业务流程。常用的行业框架是 CRISP-DM（跨行业数据挖掘标准流程），它的核心精神就是：业务理解在前，建模只是中段。

```mermaid graph TD A[业务目标与决策] --> B[问题翻译: Action/Metric/Constraint] B --> C[数据盘点与口径统一] C --> D[探索分析EDA: 现状/分布/异常] D --> E[方案选择: 规则/报表/实验/模型] E --> F[离线评估: 指标与成本收益] F --> G[线上验证: A/B或灰度] G --> H[上线与监控: 漂移/反馈/迭代] H --> B ```

四类“方案”，不一定都要上模型

很多初学者误以为“数据科学=机器学习”。更现实的分层是：

• **描述（Descriptive）**：发生了什么？（报表、看板、指标体系）
• **诊断（Diagnostic）**：为什么发生？（分群、漏斗、相关分析、因果推断）
• **预测（Predictive）**：接下来会怎样？（回归/分类/时间序列预测）
• **处方（Prescriptive）**：该怎么做更好？（实验设计、优化、策略、强化学习）

对同一个业务目标，往往“更简单的方案”就足够。比如“投诉上升”，先把口径统一、按渠道/产品/版本拆分，可能就直接定位到问题版本；此时建一个复杂模型反而会拖慢响应。

> 提示（侧边栏）：先问三个问题 > 1）如果我明天就必须做决定，我会怎么做？ > 2）我缺的到底是“信息”还是“执行手段”？ > 3）用数据后，这个决定会改变吗？如果不会，别做模型。

指标：把“感觉”变成“算得清”的尺度

指标不是数字，而是“对齐机制”

指标的价值不在于“能算出来”，而在于把团队对“成功”的理解对齐。一个好指标应满足：

• **可解释**：业务方能理解“为什么它代表成功”
• **可控**：通过某些动作确实能影响它
• **可计算**：口径明确、可复现、可审计
• **不易被钻空子**：至少要有护栏指标防止“刷指标”

领先指标与滞后指标

• **滞后指标**（结果）：收入、留存、流失率、投诉率

优点：接近业务目标；缺点：反馈慢、噪声大

• **领先指标**（过程/代理）：点击率、加购率、关键路径完成率

优点：反馈快、可迭代；缺点：容易“优化错方向”

这两类指标通常要配对使用：一个主指标（Primary）+若干护栏指标（Guardrail）。

> 重要概念：代理指标（Proxy Metric） > 当真正目标难以快速衡量时，用一个可观测的指标做近似。例如用“次日留存”作为“长期价值”的短期代理。

一个常用的指标写法：用公式锁定口径

以“转化率”为例，很多争论来自分母分子不一致。把口径写成公式能减少误解：

$$ \text{转化率} = \frac{\text{完成支付的用户数}}{\text{访问商品详情页的去重用户数}} $$

然后再补充：

• 统计窗口：自然日还是滚动24小时？
• 去重粒度：按用户ID还是设备ID？
• 过滤规则：是否排除内部账号/异常流量？
• 延迟归因：访问后7天内支付算不算？

当你能把这些写清楚，你就已经完成了大量“数据科学”工作。

指标陷阱：古德哈特定律

当一个指标被当作目标，它就不再是好指标（Goodhart’s Law）。比如把“点击率”当目标，可能导致标题党；把“处理时长”当目标，可能导致客服草率结案。

解决方式不是放弃指标，而是：

• 用**多指标组合**（主指标+护栏）
• 定期做**指标健康检查**（是否与长期目标仍相关）
• 通过**抽检与质检**补足不可量化部分

可参考：古德哈特定律的简要介绍（英文） <https://en.wikipedia.org/wiki/Goodhart%27s_law>

数据：不是“拿来就用”，而是“定义出来”的

先确定分析对象与粒度

同一个业务问题，不同粒度会导致完全不同的结论：

• 粒度=用户：适合留存、流失、复购
• 粒度=订单：适合客单价、退款、履约
• 粒度=曝光/点击：适合推荐、广告、搜索
• 粒度=设备/传感器读数：适合预测性维护

> 例子：你想做“流失预测”。 > 如果粒度写成“用户-周”，你预测的是下周是否流失；写成“用户-天”，你预测的是明天是否回来。标签定义会直接影响模型与策略。

数据从哪里来：理解“数据生成过程”

初学者常把数据当作客观事实，但数据是系统与流程的产物。比如：

• “投诉”取决于用户是否知道入口、是否愿意投诉、客服是否记录
• “成交”取决于支付链路、风控拦截、库存与物流
• “点击”取决于曝光位置、UI、加载速度、埋点是否丢失

因此数据科学常见的第一步不是建模，而是做数据盘点：

• 关键字段是否存在？
• 缺失值比例多少？缺失是随机的吗？
• 是否存在口径变化（版本迭代、埋点改动）？
• 是否存在选择偏差（只记录了“发生了某事”的人）？

相关与因果：你想要的是“解释”还是“预测”？

• 如果你要**做决策**（例如“发券是否有效”），你关心因果：发券导致复购提升了吗？
• 如果你要**提前预警**（例如“谁要流失”），你关心预测：哪些人更可能流失？

两者方法不同、评估方式不同、失败的代价也不同。把它们混在一起，是很多项目走偏的根源。

> 提示（侧边栏）：因果问题的信号 > 只要你的句子里出现“如果……会不会……”“做A比做B好吗”，通常就是因果问题；优先考虑实验（A/B）或准实验设计，而不是直接用相关性下结论。

三个案例：把“数据科学在做什么”落到地上

下面用三个场景，展示从业务问题到可计算问题的完整翻译过程。每个案例都刻意包含“指标、数据、评估、落地”，你可以把它当作模板套用。

案例一：电商提升复购——先做分群，再谈模型

业务问题：复购下降了，能不能提升？ 常见误解：直接做“复购预测模型”，给高概率人群发券。

第一步：写清楚决策

• 决策动作：给哪些用户发券？发什么券？什么时候发？
• 约束：预算固定；不能伤害利润；不能引起“老客不满”

第二步：定义可计算指标

• 主指标：30天复购率（去重用户）
• 护栏：毛利率、退货率、客服投诉率
• 过程指标：加购率、收藏率、支付转化率

第三步：用数据回答“先验问题”

先做探索分析（EDA），问三个更基础的问题： 1. 是“所有人都在下降”，还是“某类人下降”？ 2. 是“新客质量变差”，还是“老客回不来”？ 3. 是“某些品类/渠道/版本”导致？

一个常用工具是队列分析（Cohort）：按首单月份分组，看后续复购曲线是否整体右移/下移。很多时候你会发现：不是复购变差，而是新客结构变了（例如活动引入了更价格敏感的人群）。

第四步：选择方案（不一定上模型）

• 如果主要问题是“某品类履约变差导致体验差”：优先修履约，而不是发券
• 如果主要问题是“沉默老客可唤回”：可以先做规则策略（比如7天未访问且历史高价值）
• 如果要规模化与精细化：再做模型（例如流失风险/优惠敏感度）

第五步：评估要以“增量”为准

发券这类动作必须看增量效果，否则会误把“本来就会买的人”当作“券带来的复购”。常见做法：

• A/B 测试：随机分组，比较复购率差异
• 或者用 uplift/因果模型（更复杂，但本质仍是估计增量）

> 小结：这个案例里，数据科学的贡献很可能是“分群+指标口径+实验评估”，模型只是可选项。

---

案例二：工厂预测性维护——用成本矩阵定义“好模型”

业务问题：设备停机损失大，能不能提前预警？ 这听起来像典型机器学习问题，但关键在于：误报与漏报哪个更贵？

第一步：把业务损失写成可计算代价

设定二分类：预测“未来7天会故障/不会故障”。

• 漏报（把会坏预测成不会坏）：一次停机损失 20 万
• 误报（把不会坏预测成会坏）：一次不必要检修成本 1 万
• 真实故障比例：假设每周1%（稀有事件）

如果你只看准确率，模型“全预测不会坏”也能有 99% 准确率，但完全没用。更好的评估方式是引入期望成本：

$$ \text{期望成本} = C_{FN}\cdot FN + C_{FP}\cdot FP $$

其中 $C_{FN}$、$C_{FP}$ 分别是漏报/误报的单位成本。

第二步：数据与标签的工程细节

• 粒度：设备-天（或设备-小时）
• 标签：未来7天内是否发生故障（需要维护记录对齐）
• 特征：温度、振动、压力、电流、工况、最近检修时间
• 关键问题：故障记录是否完整？检修是否会“掩盖”真实故障（选择偏差）？

第三步：从“预测”走向“可执行策略”

即使模型能预测，也要回答：

• 预警后怎么做？立即停机检修还是安排下次保养？
• 资源是否足够？检修人员与备件是否能跟上？
• 预警频率是否会导致“狼来了”效应？

> 小结：这里的数据科学不只是训练分类器，而是用成本与流程把“预测”嵌入“维护决策”。

---

案例三：内容平台推荐——线上指标与离线指标为什么会打架

业务问题：想让用户“更喜欢”，做推荐系统。 常见困惑：离线AUC更高的模型，上线后点击反而下降，甚至留存变差。

第一步：目标拆解：短期与长期

• 短期代理：CTR（点击率）、观看时长、互动率
• 长期目标：7日留存、订阅率、付费转化、内容生态健康

CTR 往往反馈快，但过度优化会带来同质化、低质内容、信息茧房等副作用。于是需要护栏指标与多目标权衡。

第二步：理解“数据偏差”来源

推荐日志本质上是“系统已经做过选择后的结果”：

• 你看见的是被曝光的内容，而不是所有内容
• 你看见的是被推荐策略影响后的点击，而不是“自然偏好”

这会导致典型的曝光偏差/反馈回路：模型越推荐某类内容，这类内容数据越多，模型越确信它“有效”。

第三步：用实验闭环而不是迷信离线指标

离线指标（如AUC、NDCG）适合筛选候选模型，但最终要用线上实验验证增量。一个实用做法是：

• 离线：保证基本正确性与稳定性（不崩、不明显退化）
• 小流量灰度：观察主指标与护栏指标
• 全量：建立长期监控与漂移报警

```plantuml @startuml actor PM as 产品 actor DS as 数据科学 actor Eng as 工程 database Log as 日志 产品 -> 数据科学: 提出目标(留存/时长) 数据科学 -> 工程: 定义埋点与口径 工程 -> 日志: 采集曝光/点击/停留 数据科学 -> 数据科学: 训练/离线评估 数据科学 -> 工程: 灰度策略与参数 工程 -> 日志: 线上A/B实验数据 数据科学 -> 产品: 增量结果与建议 @enduml ```

> 小结：推荐场景的难点常常不在模型结构，而在目标定义、偏差控制与实验闭环。

常见误区清单：新手最容易踩的坑

• **先建模后问问题**：模型是手段，不是目标；先写清 Action/Metric/Constraint。
• **指标口径不一致**：同名指标不同口径，会让团队在“假争论”里消耗。
• **只看单一指标**：没有护栏指标，就等于允许系统“钻空子”。
• **把相关当因果**：相关性可以用于预测，但不能直接指导“做不做某动作”。
• **迷信复杂模型**：复杂度带来维护成本、解释成本与上线风险；能用规则解决就先规则。
• **用准确率评价稀有事件**：正例很少时，准确率会失真；优先用召回、精确率、PR曲线或成本函数。

> 自检问题：如果明天上线后指标变差，我能快速判断是 > 口径变了、数据变了、分布漂移了、还是策略真的有问题吗？ > 不能的话，你缺的可能是“监控与可解释性”，而不是更强的模型。

一页纸模板：把业务问题写成可计算问题

你可以把下面模板当作“项目立项的最低标准”。写完它，往往就能判断这个项目该不该做、怎么做。

> 问题定义（Problem Statement）

• 背景：现在发生了什么？影响多大？（用现有数据描述现状）
• 决策：我们要做的决策是什么？谁来用结果？多久用一次？
• 动作：系统/团队将采取什么动作？可控变量有哪些？
• 主指标：成功用什么衡量？公式与口径是什么？
• 护栏指标：哪些底线不能破？（体验、合规、成本、生态）
• 数据：需要哪些表/字段/埋点？缺口在哪里？数据质量风险是什么？
• 方法：优先方案（报表/规则/实验/模型）；为什么不是别的？
• 评估：离线怎么评？线上怎么验证增量？样本量与周期预估？
• 上线：灰度策略、回滚方案、监控项、报警阈值
• 风险：潜在偏差、伦理与合规、误伤用户的可能性与应对

把“可计算”写在纸面上，是数据科学最朴素也最强大的能力。

本章小结：你正在学习一门“把问题变清楚”的技术

到这里，你应该能回答“数据科学到底在做什么”：

• 它从业务目标出发，把问题翻译成可执行的决策与可验证的指标。
• 它通过口径统一与数据盘点，保证讨论建立在同一套事实之上。
• 它选择合适的方法（从报表到实验到模型），并用增量与成本来评估价值。
• 它把结果嵌入流程，形成监控与迭代闭环，而不是一次性“交付一个模型”。

下一章将进一步展开“数据从哪里来、如何被可靠地记录与组织”，把你从“会问对问题”带到“拿得到、用得稳、算得准”的数据基础能力上。

[^1]: CRISP-DM 是跨行业数据挖掘的经典流程框架，强调业务理解与迭代闭环。