数据科学家的复仇

数据科学家的黄金时代是否已经结束？《哈佛商业评论》曾将其称为“21世纪最性感的职业”。1 在科技行业，数据科学家的薪资往往名列前茅。

2 这一岗位还要求从业者具备一套不同寻常的技能组合：

数据科学家（名词）：既比任何软件工程师更懂统计，又比任何统计学家更懂数字化工程的人。 — JosH100 (@josh_wills) 2012年5月3日

这些技能不仅设置了较高的准入门槛，也让数据科学家能够构建预测模型、评估因果关系并从数据中发现规律。其中，预测建模带来的收益最为可观。

后来，企业将这部分工作独立出来，形成了一个新的职位——机器学习工程师（MLE）。3

多年来，部署人工智能始终离不开数据科学家和 MLE 的参与。然而，随着大语言模型的出现，这种局面已不再是常态。如今，基础模型的 API 使团队能够独立地集成 AI 技术。

被排除在核心流程之外，令我认识的数据科学家和 MLE 感到不安。如果公司不再需要你来推动 AI 的落地，那么这份工作的前景是否依然如故，确实值得思考。

更严峻的看法是：除非你在某家基础模型实验室从事预训练工作，否则你就不是这场变革的主角。

但我持相反观点。训练模型从来都不是数据科学家工作的全部。他们的主要职责在于设计实验，以检验 AI 对未见数据的泛化能力；调试随机性系统；以及制定合理的评价指标。

通过 API 调用大语言模型，并不能让这些工作消失。

不久前，我在 PyAI 会议 上发表了题为“数据科学家的反击”的演讲，试图用实例而非空洞的论断来阐明这一观点。以下是该演讲的注释版。

“约束机制”就是数据科学

OpenAI 发布了一篇博客文章，网址为 线束工程，强烈推荐大家阅读。文中描述了 Codex 如何在一个软件项目中持续数月自主运行，其代码开发完全受测试与规范所构成的“约束机制”限制。

这篇博客中有一个细节容易被忽视：该约束机制包含一套可观测性栈——日志、指标与追踪信息，供代理判断自身是否偏离轨道。除了测试与规范，还有指标体系，这是整个系统的关键组成部分。

安德烈·卡帕西的 汽车研究项目 也展现了同样的模式：模型会基于验证损失指标进行迭代优化。思路一致，只是约束机制有所不同。

我想强调的是，这套约束机制的很大一部分正是数据科学的体现。

让我们退后一步，审视当前的状况。

过去，从业者会花大量时间检查数据、核对标签一致性，并精心设计评价指标。而如今，我们更多地凭“感觉”行事，直接询问模型是否做得好，然后随手套用现成的指标库，却很少真正去看数据。

这种情况在检索与评测环节尤为突出。缺乏数据背景的工程师往往畏惧自己不理解的东西，于是宣称“RAG 已死”或“评测已死”，却仍在构建依赖这些概念的系统。

接下来，我将逐一剖析我在工作中反复遇到的五个评测误区，并说明数据科学家在每种情况下会如何改进。

通用型指标

第一个误区是使用通用型指标。

人们很容易直接采用某个评测框架及其现成指标。但问题在于：你根本不清楚哪里出了问题。大多数团队都会搭建一个仪表盘，上面显示“有用性得分”、“连贯性得分”、“幻觉率”等指标。

这些听起来似乎合理，但实际上过于笼统，难以用于诊断应用的具体故障。

数据科学家绝不会照搬现成指标。他们会深入探索数据与追踪记录，追问“到底是什么出了问题？”并确定最有价值的观测点。可测量的内容无穷无尽，必须先提出假设，再逐步迭代。

应对这一误区的最佳良方，就是直面数据。

所谓“直面数据”，具体来说就是查看追踪记录。自定义一个追踪可视化工具，消除操作障碍，并根据领域特点定制展示方式。记录发现的问题，开展错误分析：归类失败案例，明确优先级，决定下一步的工作方向。

当你真正去观察数据时，往往会逐渐聚焦于针对特定应用的指标。诸如 ROUGE 或 BLEU 等通用相似度指标，通常并不适用于大语言模型的输出。

真正重要的指标可能是“日程安排失败”或“未能转交人工处理”之类。

如果说本文能带给你的唯一启示，那就是：一定要看数据。至于如何看数据，则是另一个问题，需要实践积累。这是最具投资回报的活动，却常常被忽视。

未经验证的评判者

第二个误区是使用未经验证的评判者。许多团队直接用大语言模型来判断自己的 AI 是否有效。但几乎没有人能回答：“我们凭什么相信这个评判者？”

最常见的做法是让大语言模型按某个尺度打分，然后直接使用这些数值。数据科学家则会把评判者当作分类器来对待。面对一个给出预测结果的黑箱，该如何信任它？

获取人工标注，将数据划分为训练集、验证集和测试集，并评估该分类器是否可靠。

从训练集中选取少量示例，在验证集上不断优化评判者的提示词，同时保留测试集以确保没有过拟合。如果你有过机器学习经验，这一切都显得平淡无奇。

但在当下，这类工作却鲜有人做。在现代 AI 领域，验证分类器的能力正逐渐失传。

在报告结果时，也要像对待分类器一样对待你的评判者。到处都能看到只报告准确率的情况。如果某种故障模式的发生率只有 5%，准确率就会掩盖系统的实际表现。

应改用精确率和召回率。

糟糕的实验设计

第三个误区是实验设计不当。这涉及多个方面，这里重点谈两个常见问题。

首先是测试集的构建。大多数团队通过向大语言模型提问来生成合成数据：“给我 50 个测试查询。”得到的往往是缺乏代表性的通用数据。

数据科学家则会先研究真实的生产数据，基于假设确定哪些维度至关重要，然后再沿着这些维度生成合成样本。

让合成数据扎根于真实日志或追踪记录，明确需要变化的维度，注入边界情况，确保合成数据源自真实数据。

其次是指标设计。团队往往将整套评分标准打包进一次大语言模型调用，默认采用 1–5 点的李克特量表。数据科学家则会简化复杂度，让每个指标都切实可用，并与业务目标挂钩。

用有明确范围的二元通过/失败标准取代主观量表，因为李克特量表会掩盖模糊性，把关于系统性能的艰难决策一再推迟。

不良的数据与标签

第四个误区是数据与标签质量不佳。数据科学家对数据、对标签乃至一切都不轻信，他们天生就抱有怀疑态度。而大型企业的 AI 工程师们尚未养成这种习惯。

在标注环节，多数团队把它推给他人。标注工作看起来不够光鲜，于是要么交给开发团队，要么外包出去。数据科学家则会坚持由领域专家来标注数据，对标注保持警惕，并亲自查看原始数据。

但标注的重要性远不止于标签质量本身。只有看过数据，才能知道自己真正想要什么。有一种现象被称为“标准漂移”，已在 由施蕾亚·尚卡尔及其同事撰写的论文 中得到验证：用户需要标准来评价输出，而评价输出的过程反过来又帮助用户明确自己的标准。

人们往往要看到大语言模型的输出，才知道自己究竟想要什么。标注过程本身就能揭示关键所在。

数据科学家倡导的做法是：让领域专家和产品经理直接接触原始数据，而不是只看汇总分数。

过度自动化

第五个误区是过度自动化。所有这些工作本质上都需要人的参与，但人们总是倾向于用自动化来替代。

大语言模型可以帮助搭建流程、编写底层代码、生成评测的模板。但它无法替你看数据，原因也正是我们刚才提到的：不到看到输出，你就不知道自己想要什么。

其他误区

由于时间有限，我们无法一一列举所有误区。以下简要列出其余几项：

误用相似度指标；向评判者提出诸如“是否有帮助”之类的模糊问题；让标注人员阅读原始 JSON 数据；报告未经校准的分数且不提供置信区间；数据漂移、过拟合、采样不当，以及毫无意义的仪表盘。

整体映射

从宏观来看，上述每一个误区都有同一个根源：缺失了数据科学的基本功。

查看追踪记录并归类故障属于探索性数据分析；用人标签验证大语言模型的评判结果属于模型评估；从生产数据中构建具有代表性的测试集属于实验设计；让领域专家标注输出属于数据采集；监控产品在生产环境中的表现则属于生产环境下的机器学习。

这些内容并非新事物，只是名称变了，本质没变。

这里是 Python 大会，所以我要强调：Python 仍然是查看和处理数据的最佳工具。

我开发了一个 开源插件，可以更深入地分析问题。只需指向你的评测流水线，它就能告诉你哪里出了错，或者至少尽力给出建议。

永远不要忘记看数据。

如果你喜欢本次演讲中的梗，我的网站上还有更多相关内容。

如果你想深入了解这些话题，幻灯片和视频都在下方。

感谢 施雷亚·尚卡尔 和 布莱恩·比肖夫 提供的诸多讨论，它们为本次演讲的成型提供了重要启发。

视频与幻灯片

幻灯片链接

脚注

1. https://hbr.org/2012/10/data-scientist-the-sexiest-job-of-the-21st-century↩︎
2. https://www.forbes.com/sites/louiscolumbus/2018/01/29/data-scientist-is-the-best-job-in-america-according-glassdoors-2018-rankings/↩︎
3. https://www.mckinsey.com/about-us/new-at-mckinsey-blog/ai-reinvents-tech-talent-opportunities↩︎