数据科学家
数据科学家把一个含糊的商业问题，转化成证据能够回答的问题，然后诚实地回答它——包括当诚实的结论是：证据并不支持某些人期待的那个答案。价值来自问题的界定方式和推理的严谨程度，而不是过程中可能顺带产出的某个模型。本指南说明这一学科具体包含哪些工作，以及如何评估它。
数据科学家做什么？
数据科学家用数据回答问题。工作从把一个含糊的业务问题转化为具体且可度量的问题开始，然后选择一种足以支撑目标结论的方法：描述性分析、设计好的实验、把假设明确写出来的观察性研究，或者用来给出估计值的预测模型。它还包括量化结果的不确定程度，识别那些会让结论产生误导的混杂因素与选择效应，以及把发现以一种能支撑决策、又不夸大实际证明了什么的形式呈现给决策者。
问题界定贡献了大部分价值，得到的注意却最少。“客户为什么在流失”按原样是回答不了的：它没有人群范围，没有时间范围，没有比较对象，也没有对“流失”的定义。把它转化成一个可回答的问题——哪一批客户、在多长的观察窗口内度量、与谁比较、什么样的结果会改变计划——决定了后续工作到底值不值得做。一位立刻开始写查询的分析师当然会产出些什么；至于那些产出与决策有没有关系，是另一回事。
反复出现的技术问题是：一个观察到的关系，是否足以支撑正在考虑的那个行动。有些问题可以通过随机分组然后等待来解决；很多问题不行，因为变更会同时作用于所有人，或者随机分组不符合伦理，或者事件已经发生了。对这些问题，实践者必须选定一种设计——可比人群之间随时间的差异、工具变量、准入门槛处的断点、按可观测特征做匹配——并把结论所依赖的假设明确说出来，因为那些假设正是这个发现最脆弱的地方，而这个地方应该被指给别人看。
在这个角色里，沟通是一项技术能力，而不是所谓的软技能。一个置信区间在幻灯片上被压成单个数字，丢掉的恰恰是决策真正敏感的那部分信息。判断哪一种不确定性对当下的选择是重要的，并把它传达到让非专业人士既不被误导、也不被卡住的程度，属于分析工作本身，而不是汇报环节的收尾。
团队在什么时候需要这项能力
报表告诉一个组织发生了什么。以下这些压力，出现在它需要知道“为什么”，或者“换一种做法会发生什么”的时候。
决策建立在没有人质疑的看板上
一张图动了，计划就跟着改，没有人追问这个变动是否大于噪声、人群构成是否发生了变化，或者指标背后的口径是否还是当初写下时的那个含义。
实验在跑，但没有人相信结果
实验一看到好结果就停下，多个指标轮番检查直到有一个达到显著，样本量小到根本检测不出任何人真正在意的效应，分组之间还存在串组。这套机制以相当高的频率产出结论，而组织已经悄悄不再相信它们。
一个指标变成了目标
某个数字进入了薪酬方案或董事会材料，于是所有行为都围绕把它推高重新组织了一遍。需要有人把它捕捉到了什么、没有捕捉到什么，以及为了推动它正在牺牲什么，清楚地讲出来。
一个观察性结论即将驱动预算
某个渠道、某个功能或某场活动，仅凭看板上的一个相关性，就被说成是带来了某个结果。在预算跟进之前，需要有人弄清楚这个效应是真实存在的，还是那些被触达的人本来就会转化。
要回答的是“为什么”，而不是“是什么”
埋点准确地上报了事件，却什么也解释不了。理解原因要么需要一个事先设计好的实验，要么需要一个有意选定的观察性设计，而这两者都不会因为把图表看得更仔细一些就自动出现。
需要做预测，而虚假的精确是危险的
需求、容量或人员规划都需要一个预测值。单个数字自带一种没有人核验过的隐含把握，而在没有区间的情况下据此做规划，意味着冗余量是由乐观情绪而不是由证据决定的。
核心能力
问题界定
把一个含糊的请求转化成带有人群范围、时间范围、比较对象和对应决策的问题——并且事先确定：哪些可能的结果会真正改变某个人的行动。
实验设计
选择随机化的单元，计算为检测出值得据以行动的效应所需的样本量与实验时长，选定护栏指标，并在观测数据开始进来之前就把决策规则定下来。
基于观察数据的因果推断
在无法随机化的场景中运用相应的设计——组间趋势的比较、工具变量、准入阈值处的断点、按可观测特征做匹配——并把每一种设计各自需要的假设直白地写出来。
统计严谨性
抽样及其偏差、多重比较、幸存者偏差与选择效应、显著的结果与有意义的结果之间的差别，以及主动检验假设，而不是从教科书的例子里照搬过来。
对数据本身的审视
在使用一份数据集之前，先弄清楚它是怎么来的：埋点实际记录了什么、某个口径是在什么时候变的、缺失值说明了什么过程，以及哪些记录被无声地排除在外。
以理解为目的的建模
用模型估计某个量，或者刻画某种关系，关注模型设定、共线性、样本外表现与可解释性——用在输出是给人看的场景，而不是用来响应线上请求的场景。
指标定义
构建那些真正反映组织想要的结果、经得起被人为操纵、能区分先行指标与滞后指标，并且在产品或人群发生变化之后仍然可比的指标。
不确定性的量化
为每一个估计值附上区间和明确写出的假设，把未知的部分讲清楚，并把抽样波动与设计选择本身带来的、大得多的不确定性区分开。
面向决策者的呈现
选择合适的图形与叙述方式，让结论及其局限在决策者愿意给出的那点时间里就能读懂，既不把注意事项埋掉，也不躲在它们后面。
可复现的分析
代码纳入版本控制，记录下查询与数据输入，并写明运行环境，使得一个结论在情况发生变化之后，仍然可以被重跑、被质疑和被重新审视。
技术生态
以下列出数据科学领域常见的技术。这描述的是该学科在业界的一般实践，而不是对任何特定工程师技术栈的说明。在这个角色上，工具恰恰是区分度最低的一项，因为让一份分析值得信任的那套推理，无论用哪种语言表达都是同一套。
编程语言
- 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
How this role works with your team
Engineers work inside your team, on your priorities, to your standards. You direct the work; Talent.ID carries the employment. The division below is the whole arrangement.
You keep
- 产品
- 业务优先级
- 路线图
- 架构
- 冲刺优先级
- 工程标准
- 日常技术协作
Talent.ID handles
- 雇佣关系
- 薪资发放
- 员工福利
- 人才管理
- 持续的员工关系
招聘时应该关注什么
针对这个角色的面试筛选，往往考的是容易考的东西——库用得熟不熟、教科书统计学记不记得——而错过了真正决定这次招聘值不值的两项特质：他们是否界定出了正确的问题，以及当证据不支持某些人想要的那个答案时，他们会不会把这一点说出来。
先界定问题，再做分析
给候选人一个真正含糊的问题，看他们怎么处理。值得关注的反应，是一连串关于人群范围、时间范围、比较对象和后续影响的澄清性提问。一个直接跳到方法上的候选人，其实已经告诉了您头半年会是什么样子。
- 先把问题重述成一个可以被回答的形式，然后才去回答
- 会追问哪个决策依赖这个结果
- 会确认什么样的发现会改变计划，什么样的不会
- 曾经拒绝过做某项分析，并能讲清楚理由
因果推理
给出一个相关性，以及基于它提出的行动方案。强的候选人会立刻把“被随机化的部分”和“只是被观察到的部分”分开，点出说得通的具体混杂因素，并提出一个设计方案，而不是补一句注意事项。
- 能点出具体的混杂因素，而不是泛泛地提醒要当心混杂
- 能描述一种准实验设计，以及它所依赖的假设
- 在没有充分理由的情况下，把前后对比视为弱证据
- 能区分“是什么样的人选择了这个行为”和“这个行为本身带来的效应”
实验纪律
问他们在一个实验上线之前会做什么。有价值的习惯全都在准备阶段：估计值得检测的最小效应量，据此确定样本规模，并且在还没有人对结果产生利害关系的时候，就把决策规则写下来。
- 事先计算所需的样本量与实验时长
- 在上线之前就把主指标和停止规则定死
- 能具体解释反复查看结果会对假阳性率造成什么影响
- 用护栏指标捕捉主指标之外的负面影响
对数据保持怀疑
问他们如何确认一份数据集的含义确实如它的列名所示。吃过一次亏的实践者会条件反射地去做这件事；没吃过亏的，往往默认数仓里的东西可信。
- 在分析之前先弄清楚数据是怎么被记录下来的
- 曾经发现过一个让某项工作作废的埋点缺陷
- 把缺失值看作关于某个过程的线索，而不是可以直接丢掉的行
- 会用一个独立来源交叉核对重要数字
不确定性的沟通
请他们把一个结果解释给非专业人士听。要找的是这样的人：给出一个区间，并说明它对当下这个选择意味着什么，而不是只丢出一个孤零零的点估计，或者堆一大段限定条件，让听的人听完仍然不知道该怎么办。
- 用业务的语言把假设直白地讲出来
- 给出区间，并说明它对眼前这个决策意味着什么
- 当证据不足以定论时，会明确地说出来
- 根据听众调整深浅，但不改变实质内容
压力之下的独立性
问一个不受欢迎的结论。有信息量的是之后发生了什么：分析是不是被反复重构，直到它与那个更受偏好的结论一致；以及当他们被要求再看一遍时，是怎么处理的。
- 交付过与高层预期相反的结果
- 把发现本身和由此得出的建议区分开
- 乐于重新检查方法，但不轻易改变结论
- 能讲清楚在这种情况下他们是如何维持住工作关系的
与代价相称
严谨程度应当与这件事的赌注相称。一个可以撤回的决定，需要的是本周就能给出、站得住脚的估计，而不是下个季度才完成、无可挑剔的研究；分辨自己身处哪一种情形，是在业务团队里能否发挥作用的很大一部分。
- 让工作的深度与判断错误的代价相匹配
- 在粗略答案已经够用时，愿意给出它并附上局限说明
- 能识别出哪些决策值得一项正式设计的研究
- 会把分析做完，而不是无止境地打磨
值得一问的面试问题
以下问题供您自己的面试流程参考，如何使用由您决定。做出评估和判断的是您；之所以收录这些问题，是因为它们奖励真实的推理过程，仅靠读书很难答得让人信服。
一位业务负责人问上个月流失率为什么上升了。您首先会做什么？
What a strong answer shows
问题界定的本能。强的候选人会先问：哪些客户、什么时间范围、与什么基线相比、正在考虑采取什么行动——在打开任何东西之前。弱一些的会立刻开始描述一套同期群分析。
使用某个功能的客户，留存明显好于不使用的客户。这个功能起作用了吗？
What a strong answer shows
是否无需提示就能识别出选择效应。那些本就活跃的用户大概率也会留下来；有价值的回答会提出如何把这一点弄清楚，无论是通过实验，还是通过一个直接处理选择效应的设计。
一个实验在第三天显示出显著提升。您会上线吗？
What a strong answer shows
面对诱人结果时的纪律。关注他们是否提到事先约定的实验时长、反复查看的代价、新奇效应、星期几的构成，以及这个效应量在商业上是否大到值得在意。
请讲一个没有人想要的结论。之后发生了什么？
What a strong answer shows
独立性与组织沟通能力同时在场。最好的回答会描述他们如何守住这个发现、认真回应对方法提出的质疑，并在不稀释结论的前提下把关系维持住。
这个变更会同时影响所有客户，因此无法做随机分组。您会如何评估它？
What a strong answer shows
方法储备的广度。期待他们提到与一个未受影响的相似人群做比较、合成控制、中断时间序列，或者按地区分批放量——并且说明每种做法各自需要的假设。
请描述一次底层数据本身就是错的经历。您是怎么发现的？
What a strong answer shows
他们是否会核查自己的输入。关注这类线索：与另一来源对不上、分布不合常理、某个阶跃变化恰好对上一次发版日期，或者某个口径在统计期间被悄悄改过。
面对一个只想要单个数字的人，您如何呈现一个确实不确定的结果？
What a strong answer shows
沟通上的判断力。最好的回答会给出那个数字，同时给出区间，并把区间翻译成它对这个决策意味着什么——而不是拒绝回答，也不是假装自己拥有并不具备的精度。
下个季度要用一个指标来考核一个团队，您会怎么选？
What a strong answer shows
对激励机制的理解。关注这个指标是否与业务真正想要的结果一致、是否经得起被人为操纵、先行与滞后指标的搭配是否合理，以及他们是否清楚这个指标会扭曲什么。
What this looks like in practice
A hypothetical scenario, written to show how the working model applies. It does not describe a Talent.ID client or a completed project.
- Challenge
- 某个业务团队正在决定把预算集中投向哪里。手上可用的证据是：一组从看板里取出的相关性、一套结果前后不一致且内部已不再采信的实验机制，以及一个以单个数字呈现、没有附带任何区间的预测。
- Approach
- 新增的分析力量在团队已有的实践之内工作——他们的评审约定、他们的工具、他们的报告节奏，以及他们已经确立的分析标准。业务优先级以及研究什么问题的决定权仍然属于内部团队；新增的力量与他们一起参与研究设计、分析和结果呈现，而不是作为一个独立的职能存在。
- What this adds to the team
- 团队可以把更多问题认真地做下去，同时不必让渡“哪些问题重要”这一判断。研究什么，以及什么样的证据足以支撑行动，始终由对决策负责的人来决定。
Related disciplines
Frequently asked questions
- 数据科学家和数据分析师有什么区别？
- 分析师主要关心描述发生了什么：报表、看板、指标口径，以及回答那些形式已经确定的问题。数据科学家承接的是形式尚未确定的问题——设计一项研究、把真实效应与巧合区分开、量化人们究竟应该有多大把握。这条边界在不同组织之间会移动，而职位名称对它的反映很不准确，因此在岗位说明里描述实际要做的工作，比依赖头衔更可靠。
- 数据科学家与机器学习工程师有什么不同？
- 数据科学家确定应该度量什么，以及一个被声称存在的效应是否真实；机器学习工程师构建并维护那套训练模型、并把模型提供出去的系统。大量有价值的数据科学工作根本不产出模型，而大量机器学习工程的工作关心的是管道、服务与模型衰减，而不是问题的选择。指望一个人同时覆盖两边的团队，通常会发现有一半被忽略了，而具体是哪一半，取决于这个人的兴趣在哪里。
- 数据科学家会构建生产环境的模型吗？
- 他们经常会做出最初的版本，而那个版本的用途一般是判断这条路子是否成立，而不是承接线上流量。一旦某个东西必须持续运行、满足延迟预算、被监控是否衰减，并按周期重新构建，它就成了工程侧的责任。把一个原型当作生产系统，是一个常见且代价不小的错误，而且通常是由组织犯下的，而不是由写出它的那个人。
- 我们需要的是数据科学家，还是更好的报表？
- 如果悬而未决的问题是发生了什么、发生在谁身上，那么答案是更好的埋点、更清晰的口径和分析师的时间——而为了应付看板需求去招一个做研究的人，是在一年之内失去这位同事的可靠方式。如果问题是某件事为什么发生、某项干预是否起了作用，或者换一套方案会发生什么，那么需要的就是这项能力，而报表无论做得多好，都无法回答它们。
- 业务领域知识有多重要？
- 相当重要，因为问题界定依赖它：知道哪种比较是公平的、哪种季节性波动属于正常、哪种解释从运营角度看根本说不通。它同时也是所有要求里最容易补上的一项。一位方法严谨、并把最初几周花在与经营业务的人交谈上的实践者，通常会胜过一位行业很熟但方法松散的人。
- 为什么数据科学方向的招聘常常令人失望？
- 原因很少出在技术上。反复出现的模式是离决策太远：工作是以工单而不是以问题的形式派下来的，结论在选择已经做出之后才到达，底层数据被证明不可靠，而且从一个结论到一个行动之间没有既定的通路。一位有能力的实践者被放进这样的安排里，会产出不错却什么也改变不了的分析，然后通常会离开。
- 数据科学家如何与现有的工程团队协作？
- 在技术团队扩展的模式下，工作的方向仍然由您掌握：您的分析标准、您的评审惯例、您的优先级和您的路线图，决定研究哪些问题以及按什么顺序展开，协作也发生在您自己的团队内部。Talent.ID 负责雇佣关系、薪资发放和员工福利，以及人才管理和持续的员工关系。
Tell us what your team needs
Describe the gap — the work, the stack, the way your team runs — and we will tell you what we can support. If it is not something we can help with, we will say so.