数据集评估实战：用 NYC 出租车小费数据验证冬季与夏季消费差异（Data-Science-For-Beginners 课程作业解析）-酒店常州论坛

数据集评估实战：用 NYC 出租车小费数据验证冬季与夏季消费差异（Data-Science-For-Beginners 课程作业解析）

【免费下载链接】Data-Science-For-Beginners10 Weeks, 20 Lessons, Data Science for All!项目地址: https://gitcode.com/GitHub_Trending/da/Data-Science-For-Beginners

本篇技术指南围绕微软开源课程 Data-Science-For-Beginners 第 14 课《数据科学生命周期导论》的课后作业展开，完整还原「数据集评估（Assessing a Dataset）」这一经典任务：在数据科学生命周期的 Capturing（数据采集）阶段，如何评估一份 NYC 黄色出租车行程数据（data/taxi.csv）是否足以回答客户的业务问题——纽约市黄色出租车乘客在冬季还是夏季给司机的小费更多。读完本文，你将掌握数据集可行性评估的标准流程、字段级数据剖析方法、补充数据集的选型思路，以及向业务方提出澄清问题、收敛问题边界的实战技巧。

任务背景：从业务问题到数据问题

课程作业（见 4-Data-Science-Lifecycle/14-Introduction/assignment.md）设定了一个典型的数据科学项目开局：某客户请求团队协助研究 NYC 出租车乘客的季节性消费习惯，核心问题是：

纽约市黄色出租车乘客在冬季还是夏季给司机的小费更多？

此时团队正处在数据科学生命周期的Capturing（采集）阶段。根据第 14 课讲义 4-Data-Science-Lifecycle/14-Introduction/README.md 的定义，Capturing 实际上是两个子阶段的合并：获取数据与明确项目要解决的问题。生命周期共分为五阶段：

Capturing（采集）
Processing（处理）
Analysis（分析）
Communication（沟通）
Maintenance（维护）

其中第 14 课重点讲解 Capturing、Processing 与 Maintenance 三个环节，而本次作业聚焦于最前端的 Capturing——数据科学家在这个阶段必须先回答「数据是否足以支撑决策」，而不是直接进入建模。

作业的负责人（即读者扮演的角色）拿到两样东西：一个 Python 笔记本 notebook.ipynb 和一份行程数据 data/taxi.csv。作业要求完成三件事：

评估这份数据集是否能帮助回答客户的问题；
探索 NYC Open Data 数据目录，找出一个可能对回答问题有帮助的补充数据集；
写出3 个需要向客户澄清的问题，以更好地理解问题本身。

数据集解剖：taxi.csv 的 18 个字段与样本结构

作业提供的 data/taxi.csv 并非完整的城市级海量数据，而是一个经过裁剪的教学样本。通过实际读取文件可确认（该文件共200 条记录 + 1 行表头）：

100 条来自 2019 年 1 月（冬季代表月）；
100 条来自 2019 年 7 月（夏季代表月）。

这种「冬夏各半」的样本设计本身就是为了对比季节性差异，与客户的问题直接对应。全部 18 个字段如下：

字段名	含义说明	与问题的相关性
`VendorID`	数据提供方/计费系统编号	低（技术标识）
`tpep_pickup_datetime`	上车时间（如`2019-07-15 16:27:53`）	高（用于划分冬夏、季节与时段）
`tpep_dropoff_datetime`	下车时间	中（可推算行程时长）
`passenger_count`	乘客人数	中（人数可能影响支付行为）
`trip_distance`	行程距离（英里）	中（距离与车费正相关）
`RatecodeID`	费率代码	中（标准价/机场价等）
`store_and_fwd_flag`	是否离车后转发记录（Y/N）	低
`PULocationID`/`DOLocationID`	上下车地点编号	中（可关联区域天气/消费特征）
`payment_type`	支付方式（1=信用卡、2=现金等）	高（现金支付在数据中往往无小费记录）
`fare_amount`	基础车费	中（小费的基数）
`extra`	附加费（如高峰附加）	低
`mta_tax`	MTA 州税	低
`tip_amount`	小费金额（目标变量）	核心
`tolls_amount`	过路费	低
`improvement_surcharge`	改善附加费（固定 0.3）	低
`total_amount`	总金额	低（小费的包含项）
`congestion_surcharge`	拥堵附加费（2019 样本中冬夏记录分别为 2.5 与 0.0）	低

对样本做初步统计可以发现：200 条记录中138 条小费大于 0、62 条小费为 0。这一现象与payment_type字段直接相关——现金支付的行程通常记录不到小费，这将是评估数据质量时必须注意的偏差来源。此外注意congestion_surcharge在 2019 年 1 月与 7 月的取值不同，说明该数据集跨越了政策调整期，评估时需意识到收费结构并非完全同质。

核心评估：这份数据能回答客户的问题吗？

数据科学家的职责是客观判断，而非直接给结论。围绕「冬季还是夏季小费更多」这一问句，可从四个维度逐项评估：

1. 目标变量是否存在tip_amount字段直接量化了小费金额，问题所需的「因变量」具备。这是回答问题的先决条件。

2. 季节维度是否可划分tpep_pickup_datetime覆盖 2019 年 1 月（冬季）与 2019 年 7 月（夏季），能够支撑「冬季 vs 夏季」的分组对比。但需注意：两个月仅代表「两个时点」，而非完整的季节分布，结论的外推性有限。

3. 样本量是否充分200 条记录是教学级样本量，可以用于练习 EDA 与统计对比，但不足以支撑稳健的业务结论。样本量小意味着置信区间宽、结论易受个别离群值影响——这一点在向客户交付结论时必须声明。

4. 数据质量与潜在偏差这是评估中最易被忽略、也最影响结论可靠性的一环：

payment_type为 2（现金）的记录中tip_amount几乎为 0，若不区分支付方式直接比较冬夏小费均值，会被现金记录严重稀释；
缺失值、极端值（如异常大的小费）需要结合数据字典中的取值范围核对；
仅凭两个月样本难以排除「月份特殊性」（如 1 月暴雪影响出行结构）对结论的干扰。

综合评估结论是：这份数据具备回答问题的核心字段与季节对比结构，可用于开展探索性分析（EDA），但其样本量与时间覆盖不足以给出严谨的业务级结论，需要在后续分析阶段结合补充数据与统计检验进一步验证。这也正是课程将分析工作留到第 15 课 Exploring for answers 的原因——该课作业中继续使用同一份 200 条数据，引导学习者思考「哪些字段最可能不需要」「数据中是否已出现季节性小费行为的证据」。

动手实践：用 notebook 加载并探查数据

作业目录中的 notebook.ipynb 已经给出最小可运行的数据加载流程，核心代码只有三步：

# 1. 安装依赖（笔记本内以魔术命令执行） !pip install pandas # 2. 导入 pandas 并读取 CSV import pandas as pd path = '../../data/taxi.csv' # 笔记本位于 4-Data-Science-Lifecycle/14-Introduction/ 下 df = pd.read_csv(path) # 3. 打印整个 DataFrame 进行初步目检 print(df)

运行后输出[200 rows x 18 columns]，与文件实际结构一致。在此基础上，建议继续追加以下探查步骤来支撑「数据能否回答问题」的判断：

# 检查缺失值与基本统计 print(df.info()) print(df.describe()) # 验证冬夏样本数量是否均衡 print(df.groupby(df['tpep_pickup_datetime'].str[:7]).size()) # 区分支付方式后对比小费（识别现金记录导致的偏差） print(df.groupby('payment_type')['tip_amount'].agg(['count', 'mean', 'sum']))

df.info()可快速暴露列级缺失情况；groupby按月计数可确认 100/100 的均衡设计；按payment_type分组统计小费则能直接验证前述「现金记录小费为 0」的偏差假设。这些操作都不需要额外数据，仅凭仓库内的 data/taxi.csv 即可完成，是向客户交付评估结论前的标准自检步骤。

补充数据集选型：弥补当前数据的盲区

作业的第二项任务要求探索 NYC Open Data 数据目录，找出一个可能有助于回答客户问题的补充数据集。选型时应围绕当前样本的两个明显短板展开：

天气与季节特征：冬季与夏季的出行与小费行为差异可能受天气（降雪、气温、降雨）驱动。可考虑补充历史天气/气候数据集（按日期的温度、降水、降雪记录），与tpep_pickup_datetime做日期级关联，从而把「季节」从简单的月份分组细化为可解释的天气变量——这也是后续分析阶段可以做 join 的关键补充维度。
区域消费特征：PULocationID/DOLocationID仅记录了地点编号，缺少区域语义。可考虑补充街区级社会经济或商业活动数据（如人口密度、餐厅分布、机场客流量），以解释「为什么某些区域的小费更高」。

选型评估标准可归纳为三条：键是否可关联（是否有日期或地点编号能与 taxi.csv 连接）、时间范围是否覆盖 2019 年 1 月与 7 月、字段是否能解释小费差异而非重复已有信息。注意不要选择与tip_amount直接同源的记录数据集，那会造成信息冗余而非补充。

向客户提问：3 个澄清问题的设计思路

作业要求写出 3 个向客户澄清的问题。设计问题的目标不是刁难客户，而是把模糊的业务问句收敛为可操作的分析定义。以下是按课程讲义中「消除歧义、明确约束、定义可量化结果」原则设计的示例：

「冬季」和「夏季」的精确定义是什么？是按自然月份（如 12–2 月为冬）划分，还是按气象定义，或是按客户的业务周期（如假日季）划分？这直接决定tpep_pickup_datetime的分组逻辑，而不同定义可能得出不同结论。
「小费更多」的度量口径是什么？是绝对小费金额、小费占车费的百分比（小费率），还是无小费行程的比例？口径不同，评估指标（均值/中位数/占比）与分析结论都可能不同——例如现金支付占比高的月份，绝对小费均值会被系统性压低。
结论将用于什么决策？客户是否准备依据结论调整司机激励政策、制定季节性运营策略，还是仅作消费者画像参考？明确用途才能确定所需的置信水平与数据规模，也能帮助判断 200 条样本是否够用、是否需要购买更大规模的数据。

这三个问题分别对应课程讲义 Capturing 阶段提出的三个关键点：目标是否可量化（问题 2）、是否存在歧义（问题 1）、约束与产出预期（问题 3）。讲义中列出的典型问题清单（「这个问题之前是否被解决过？发现了什么？」「所有相关方是否理解目标？」「可用的资源有多少？」）可作为扩展提问池继续挖掘。

权威参考：数据字典与用户指南

作业明确要求参考 TLC 官方发布的两份文档来理解字段语义：行程记录数据字典（data dictionary for yellow trip records）与行程记录用户指南（trip record user guide）。这两份材料是核对字段取值范围、单位与历史口径的第一手依据，例如RatecodeID的费率代码表、payment_type的枚举含义、extra附加费的历史定义等，均可从中查证。在做缺失值处理与异常值剔除之前，务必先对照数据字典确认字段语义，避免把「合理取值」误判为「脏数据」。

评估标准（Rubric）与自我检查

本作业的评分维度如下，可作为交付自查清单：

优秀（Exemplary）	合格（Adequate）	待改进（Needs Improvement）
对数据能否回答客户问题给出有理有据的完整评估，识别出支付方式、样本量等关键偏差	能给出基本判断，但论证不充分	仅给出结论，缺少字段级与质量层面的分析依据

对照该标准，一份合格的交付应至少包含：字段与问题目标变量的映射说明、样本覆盖（月份/数量）的客观描述、潜在数据偏差（现金无小费记录、样本量限制）的识别，以及「数据可以支撑 EDA、尚不足以支撑严谨业务结论」的审慎判断。

与后续课程的衔接：从评估到探索

本次作业输出的评估结论并非终点，而是下一课的输入：第 15 课 Exploring for answers 使用同一份 200 条数据开展 EDA，引导学习者继续回答「数据中还有哪些因素影响小费」「哪些列最可能用不上」「数据是否已呈现季节性小费行为的证据」。这种「先评估、后深挖」的课程设计，正是真实数据科学项目中 Capturing 与 Analysis 两个阶段衔接方式的缩影——先确认数据值得分析，再投入精力去分析。如果你还想进一步对照生命周期的其他实现视角，可继续阅读第 14 课讲义 README.md 中关于 TDSP 与 CRISP-DM 两种生命周期模型的对比挑战，其中配图 tdsp-lifecycle2.png 与 CRISP-DM.png 展示了不同方法论对阶段划分的异同。

【免费下载链接】Data-Science-For-Beginners10 Weeks, 20 Lessons, Data Science for All!项目地址: https://gitcode.com/GitHub_Trending/da/Data-Science-For-Beginners

创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考

企业官网建设流程全解析