数据科学家
数据科学家把一个含糊的商业问题，转化成证据能够回答的问题，然后诚实地回答它——包括当诚实的结论是：证据并不支持某些人期待的那个答案。价值来自问题的界定方式和推理的严谨程度，而不是过程中可能顺带产出的某个模型。本指南说明这一学科具体包含哪些工作，以及什么情况下需要它。
数据科学家做什么？
数据科学家用数据回答问题。工作从把一个含糊的业务问题转化为具体且可度量的问题开始，然后选择一种足以支撑目标结论的方法：描述性分析、设计好的实验、把假设明确写出来的观察性研究，或者用来给出估计值的预测模型。它还包括量化结果的不确定程度，识别那些会让结论产生误导的混杂因素与选择效应，以及把发现以一种能支撑决策、又不夸大实际证明了什么的形式呈现给决策者。
问题界定贡献了大部分价值，得到的注意却最少。“客户为什么在流失”按原样是回答不了的：它没有人群范围，没有时间范围，没有比较对象，也没有对“流失”的定义。把它转化成一个可回答的问题——哪一批客户、在多长的观察窗口内度量、与谁比较、什么样的结果会改变计划——决定了后续工作到底值不值得做。一位立刻开始写查询的分析师当然会产出些什么；至于那些产出与决策有没有关系，是另一回事。
反复出现的技术问题是：一个观察到的关系，是否足以支撑正在考虑的那个行动。有些问题可以通过随机分组然后等待来解决；很多问题不行，因为变更会同时作用于所有人，或者随机分组不符合伦理，或者事件已经发生了。对这些问题，实践者必须选定一种设计——可比人群之间随时间的差异、工具变量、准入门槛处的断点、按可观测特征做匹配——并把结论所依赖的假设明确说出来，因为那些假设正是这个发现最脆弱的地方，而这个地方应该被指给别人看。
在这个角色里，沟通是一项技术能力，而不是所谓的软技能。一个置信区间在幻灯片上被压成单个数字，丢掉的恰恰是决策真正敏感的那部分信息。判断哪一种不确定性对当下的选择是重要的，并把它传达到让非专业人士既不被误导、也不被卡住的程度，属于分析工作本身，而不是汇报环节的收尾。
团队在什么时候需要这项能力
报表告诉一个组织发生了什么。以下这些压力，出现在它需要知道“为什么”，或者“换一种做法会发生什么”的时候。
决策建立在没有人质疑的看板上
一张图动了，计划就跟着改，没有人追问这个变动是否大于噪声、人群构成是否发生了变化，或者指标背后的口径是否还是当初写下时的那个含义。
实验在跑，但没有人相信结果
实验一看到好结果就停下，多个指标轮番检查直到有一个达到显著，样本量小到根本检测不出任何人真正在意的效应，分组之间还存在串组。这套机制以相当高的频率产出结论，而组织已经悄悄不再相信它们。
一个指标变成了目标
某个数字进入了薪酬方案或董事会材料，于是所有行为都围绕把它推高重新组织了一遍。需要有人把它捕捉到了什么、没有捕捉到什么，以及为了推动它正在牺牲什么，清楚地讲出来。
一个观察性结论即将驱动预算
某个渠道、某个功能或某场活动，仅凭看板上的一个相关性，就被说成是带来了某个结果。在预算跟进之前，需要有人弄清楚这个效应是真实存在的，还是那些被触达的人本来就会转化。
要回答的是“为什么”，而不是“是什么”
埋点准确地上报了事件，却什么也解释不了。理解原因要么需要一个事先设计好的实验，要么需要一个有意选定的观察性设计，而这两者都不会因为把图表看得更仔细一些就自动出现。
需要做预测，而虚假的精确是危险的
需求、容量或人员规划都需要一个预测值。单个数字自带一种没有人核验过的隐含把握，而在没有区间的情况下据此做规划，意味着冗余量是由乐观情绪而不是由证据决定的。
核心能力
问题界定
把一个含糊的请求转化成带有人群范围、时间范围、比较对象和对应决策的问题——并且事先确定：哪些可能的结果会真正改变某个人的行动。
实验设计
选择随机化的单元，计算为检测出值得据以行动的效应所需的样本量与实验时长，选定护栏指标，并在观测数据开始进来之前就把决策规则定下来。
基于观察数据的因果推断
在无法随机化的场景中运用相应的设计——组间趋势的比较、工具变量、准入阈值处的断点、按可观测特征做匹配——并把每一种设计各自需要的假设直白地写出来。
统计严谨性
抽样及其偏差、多重比较、幸存者偏差与选择效应、显著的结果与有意义的结果之间的差别，以及主动检验假设，而不是从教科书的例子里照搬过来。
对数据本身的审视
在使用一份数据集之前，先弄清楚它是怎么来的：埋点实际记录了什么、某个口径是在什么时候变的、缺失值说明了什么过程，以及哪些记录被无声地排除在外。
以理解为目的的建模
用模型估计某个量，或者刻画某种关系，关注模型设定、共线性、样本外表现与可解释性——用在输出是给人看的场景，而不是用来响应线上请求的场景。
指标定义
构建那些真正反映组织想要的结果、经得起被人为操纵、能区分先行指标与滞后指标，并且在产品或人群发生变化之后仍然可比的指标。
不确定性的量化
为每一个估计值附上区间和明确写出的假设，把未知的部分讲清楚，并把抽样波动与设计选择本身带来的、大得多的不确定性区分开。
面向决策者的呈现
选择合适的图形与叙述方式，让结论及其局限在决策者愿意给出的那点时间里就能读懂，既不把注意事项埋掉，也不躲在它们后面。
可复现的分析
代码纳入版本控制，记录下查询与数据输入，并写明运行环境，使得一个结论在情况发生变化之后，仍然可以被重跑、被质疑和被重新审视。
技术生态
以下列出数据科学领域常见的技术。这描述的是该学科在业界的一般实践，而不是对任何特定工程师技术栈的说明。在这个角色上，工具恰恰是区分度最低的一项，因为让一份分析值得信任的那套推理，无论用哪种语言表达都是同一套。
编程语言
- Python
- R
- SQL
分析库
- pandas
- Polars
- NumPy
- SciPy
- statsmodels
- scikit-learn
因果推断与贝叶斯方法
- DoWhy
- EconML
- CausalImpact
- PyMC
- Stan
Notebook 与报告
- Jupyter
- Quarto
- R Markdown
- Streamlit
可视化
- matplotlib
- seaborn
- plotly
- ggplot2
- Vega-Lite
数据访问
- dbt
- BigQuery
- Snowflake
- DuckDB
- Databricks
实验平台
- GrowthBook
- Statsig
- Eppo
- Optimizely
这个角色如何与您的团队协作
工程师在您的团队内部工作，遵循您的优先级和标准。日常开发方向由您掌握，Talent.ID 负责雇佣关系。下面的分工就是全部安排。
由您掌握
- 产品
- 业务优先级
- 路线图
- 架构
- 冲刺优先级
- 工程标准
- 日常技术协作
由 Talent.ID 负责
- 雇佣关系
- 薪资发放
- 员工福利
- 人才管理
- 持续的员工关系
实际协作大致是这样
这是一个假设场景，用于说明协作方式如何落地。它并不描述 Talent.ID 的客户或已完成的项目。
- 挑战
- 某个业务团队正在决定把预算集中投向哪里。手上可用的证据是：一组从看板里取出的相关性、一套结果前后不一致且内部已不再采信的实验机制，以及一个以单个数字呈现、没有附带任何区间的预测。
- 做法
- 新增的分析力量在团队已有的实践之内工作——他们的评审约定、他们的工具、他们的报告节奏，以及他们已经确立的分析标准。业务优先级以及研究什么问题的决定权仍然属于内部团队；新增的力量与他们一起参与研究设计、分析和结果呈现，而不是作为一个独立的职能存在。
- 为团队带来什么
- 团队可以把更多问题认真地做下去，同时不必让渡“哪些问题重要”这一判断。研究什么，以及什么样的证据足以支撑行动，始终由对决策负责的人来决定。
常见问题
- 数据科学家和数据分析师有什么区别？
- 分析师主要关心描述发生了什么：报表、看板、指标口径，以及回答那些形式已经确定的问题。数据科学家承接的是形式尚未确定的问题——设计一项研究、把真实效应与巧合区分开、量化人们究竟应该有多大把握。这条边界在不同组织之间会移动，而职位名称对它的反映很不准确，因此在岗位说明里描述实际要做的工作，比依赖头衔更可靠。
- 数据科学家与机器学习工程师有什么不同？
- 数据科学家确定应该度量什么，以及一个被声称存在的效应是否真实；机器学习工程师构建并维护那套训练模型、并把模型提供出去的系统。大量有价值的数据科学工作根本不产出模型，而大量机器学习工程的工作关心的是管道、服务与模型衰减，而不是问题的选择。指望一个人同时覆盖两边的团队，通常会发现有一半被忽略了，而具体是哪一半，取决于这个人的兴趣在哪里。
- 数据科学家会构建生产环境的模型吗？
- 他们经常会做出最初的版本，而那个版本的用途一般是判断这条路子是否成立，而不是承接线上流量。一旦某个东西必须持续运行、满足延迟预算、被监控是否衰减，并按周期重新构建，它就成了工程侧的责任。把一个原型当作生产系统，是一个常见且代价不小的错误，而且通常是由组织犯下的，而不是由写出它的那个人。
- 我们需要的是数据科学家，还是更好的报表？
- 如果悬而未决的问题是发生了什么、发生在谁身上，那么答案是更好的埋点、更清晰的口径和分析师的时间——而为了应付看板需求去招一个做研究的人，是在一年之内失去这位同事的可靠方式。如果问题是某件事为什么发生、某项干预是否起了作用，或者换一套方案会发生什么，那么需要的就是这项能力，而报表无论做得多好，都无法回答它们。
- 业务领域知识有多重要？
- 相当重要，因为问题界定依赖它：知道哪种比较是公平的、哪种季节性波动属于正常、哪种解释从运营角度看根本说不通。它同时也是所有要求里最容易补上的一项。一位方法严谨、并把最初几周花在与经营业务的人交谈上的实践者，通常会胜过一位行业很熟但方法松散的人。
- 为什么数据科学方向的招聘常常令人失望？
- 原因很少出在技术上。反复出现的模式是离决策太远：工作是以工单而不是以问题的形式派下来的，结论在选择已经做出之后才到达，底层数据被证明不可靠，而且从一个结论到一个行动之间没有既定的通路。一位有能力的实践者被放进这样的安排里，会产出不错却什么也改变不了的分析，然后通常会离开。
- 数据科学家如何与现有的工程团队协作？
- 在技术团队扩展的模式下，工作的方向仍然由您掌握：您的分析标准、您的评审惯例、您的优先级和您的路线图，决定研究哪些问题以及按什么顺序展开，协作也发生在您自己的团队内部。Talent.ID 负责雇佣关系、薪资发放和员工福利，以及人才管理和持续的员工关系。
告诉我们您的团队需要什么
描述一下缺口——工作内容、技术栈、团队的运作方式——我们会告诉您能支持到什么程度。如果这不是我们能帮上忙的事情，我们会直说。