数据科学家的复仇

img.img-fluid { border: 1px solid rgba(255, 255, 255, 0.25); border-radius: 4px; } data scientist 的黄金时代结束了吗？Harvard Business Review 曾称其为“The Sexiest Job of the 21st Century”。1 在科技行业，data scientist 岗位常常是薪酬最高的岗位之一。2 这份工作还要求一种少见的技能组合：Data Scientist（名词）：统计学比任何 software engineer 都强，software engineering 又比任何 statistician 都强的人。— JosH100 ( @josh_wills ) May 3, 2012 除了制造很高的入门门槛，这些技能也让 data scientist 能够构建 predictive model、衡量 causality，并在数据中发现模式。其中，predictive modeling 的回报最高。后来，公司把这部分工作拆分出来，变成了一个新头衔：Machine Learning Engineer（“MLE”）。3 多年来，交付 AI 意味着 data scientist 和 MLE 必须处在关键路径上。到了 LLM，这不再是默认情况。Foundation-model API 现在让团队可以独立集成 AI。我认识的 data scientist 和 MLE 被排除在流程之外后都感到不安。如果公司不再需要你来交付 AI，那么怀疑这份工作的上升空间是否还和过去一样，是合理的。人们对自己讲述的更严酷版本是：除非你在 foundation-model lab 做 pretraining，否则你就不在事情发生的中心。我反而有相反的理解。训练模型从来都不是这份工作的主体。大部分工作是搭建实验，测试 AI 对未见数据的 generalization 能力，调试 stochastic system，并设计好的 metric。通过 API 调用 LLM 并不会让这些工作消失。我最近在 PyAI Conf 做了一场题为“The Revenge of the Data Scientist”的演讲，用例子而不只是断言来说明这一点。下面是这场演讲的注释版。Harness 就是 Data Science OpenAI 发布过一篇关于 harness engineering 的 blog post，我建议阅读。他们描述了 Codex 如何在一个软件项目上自主工作数月，由 agent 在由测试和 specification 构成的 harness 约束下开发代码。那篇 blog post 中有一个细节很容易被忽略。这个 harness 包含一个 observability stack：logs、metrics 和 traces 会暴露给 agent，让它能判断自己何时偏离轨道。除了测试和 specification 之外，还有 metrics。这是系统的关键组成部分。Andrej Karpathy 的 auto-research 项目展示了同样的模式：模型根据 validation loss metric 进行迭代优化。同一个想法，不同的 harness。我想说服你的是，harness 的很大一部分就是 data science。让我们退一步，看看我们现在处在什么位置。多年前，从业者会花几个小时检查数据、检查 label alignment、设计 metrics。今天，我们基于“vibes”构建，问模型它是不是做得好，然后直接拿现成的 metric library，而不看数据。这一点在 retrieval 和 evals 上表现得最明显。没有数据背景的工程师会害怕自己不理解的东西。他们声称“RAG is dead”或“evals are dead”，却构建依赖这些概念的系统。本文其余部分会走过我反复看到的五个 eval 陷阱，以及 data scientist 在每种情况下会如何不同地处理。Generic Metrics 第一个陷阱是 generic metrics。很容易想直接拿一个 eval framework，并使用它的现成 metrics。问题是：你完全不知道实际坏在哪里。大多数团队会搭一个 dashboard，上面有 helpfulness score、coherence score、hallucination score。这些听起来合理。它们也足够 generic，以至于无法诊断你的应用失败。data scientist 不会直接采用现成 metrics。他们会探索数据，探索 traces，问“这里到底坏在哪里？”，并找出最有价值的起步测量对象。可以测量的东西有无穷多个。你必须形成 hypothesis 并迭代。这个陷阱的最佳解药是看数据。实践中，“看数据”是什么意思？意思是阅读 traces。自己写一个自定义 trace viewer，以便降低摩擦，并根据你所在领域的特殊性定制展示方式。记录你发现的问题。做 error analysis：对失败分类，找出优先级，决定要处理什么。当你查看自己的数据时，最终会走向 application-specific metrics。ROUGE 或 BLEU 这类现成 similarity metrics 很少适合 LLM outputs。真正重要的 metrics 看起来像“Calendar Scheduling Failure”或“Failure to Escalate To Human”。如果本文只能带走一件事：看数据。如何看是另一个问题，需要练习。这是你能投入的最高 ROI 活动，却经常被跳过。Unverified Judges 第二个陷阱是 unverified judges。很多团队用 LLM 作为 judge，判断他们的 AI 是否有效。大多数时候，没人能很好地回答“你如何信任这个 judge？”默认做法是：让 LLM 按某个尺度给 outputs 打分，然后使用这些数字。data scientist 会把 judge 当作 classifier。你有一个黑盒在给出 prediction。你如何信任它？获取 human labels，把数据划分为 train/dev/test，并衡量这个 classifier 是否可信。从 training set 中抽取 few-shot examples。针对 dev set 对 judge 的 prompt 做 hill-climb。留出 test set，确认你没有 overfit。如果你以前做过 machine learning，这很无聊。但人们并没有这么做。在现代 AI 中，验证 classifier 已经成了一门失传的技艺。在报告结果时，也要像对待 classifier 一样对待你的 judge。我走到哪里都看到有人报告 accuracy。如果某个 failure mode 只在 5% 的时间发生，accuracy 会掩盖系统的真实表现。使用 precision 和 recall。Bad Experimental Design 第三个陷阱是 experimental design。这里有很多维度。下面是最常见的两个。第一个是构造 test sets。大多数团队通过 prompt 一个 LLM 来生成 synthetic data：“Give me 50 test queries.” 他们得到的是 generic、没有代表性的数据。data scientist 会先查看真实 production data，用 hypothesis 判断哪些维度重要，然后沿这些维度生成 synthetic examples。让 synthetic data 建立在真实 logs 或 traces 之上。弄清楚要变化哪些维度。注入 edge cases。基于真实数据生成 synthetic data。第二个是 metric design。团队把整套 rubric 打包进一次 LLM call，并默认使用 1-5 Likert scales。data scientist 会降低复杂度，让每个 metric 都可行动，并把它和 business outcome 绑定。用限定标准下的二元 pass/fail 取代主观尺度。Likert scales 会隐藏歧义，并把关于系统性能的艰难决策推迟到以后。Bad Data and Labels 第四个陷阱是 bad data and labels。data scientist 不信任数据。不信任 labels。不信任任何东西。他们受训练后就是 skeptical 的。总体来看，AI engineers 还没有练出这块肌肉。在 labeling 上，大多数团队会把它变成别人的问题。Labeling 看起来不够光鲜，所以被委派给 dev team 或外包。data scientist 会坚持让 domain experts 标注数据，对 labels 保持 skeptical，并查看数据。但 labeling 之所以重要，还有比 label quality 更深层的原因。如果不看数据，就不可能知道你想要什么。有一个概念叫“criteria drift”，由 Shreya Shankar 及其同事的一篇论文验证：用户需要 criteria 来给 outputs 评分，但给 outputs 评分又会帮助用户定义自己的 criteria。人们在看到 LLM 的 outputs 之前，并不知道自己想要什么。labeling process 本身会揭示什么才重要。data scientist 会推动这件事：让 domain experts 和 product managers 面对 raw data，而不是 summary scores。Automating Too Much 第五个陷阱是 automating too much。所有这些都是人的工作。诱惑在于把它自动化掉。LLM 可以帮助把东西接起来、编写 plumbing、生成 evaluations 的 boilerplate。它们不能替你看数据，原因正是我们刚刚讨论过的：在看到 outputs 之前，你不知道自己想要什么。Other Pitfalls 我们没有时间覆盖每一个陷阱。下面快速过一遍其余部分。误用 similarity scores。向 judge 提 vague questions，比如“is it helpful?” 让 annotators 阅读 raw JSON。报告未校准且没有 confidence intervals 的 scores。Data drift、overfitting、sampling 不正确、看不懂的 dashboards。The Mapping 如果拉远来看，上面每个陷阱都有同一个根因：缺少 data science fundamental。阅读 traces 并对失败分类是 Exploratory Data Analysis。用 human labels 验证 LLM judge 是 Model Evaluation。基于 production data 构建有代表性的 test sets 是 Experimental Design。让 domain experts 标注 outputs 是 Data Collection。监控你的产品在 production 中是否有效是 Production ML。这些都不新。名称变了，工作没变。这是一个 Python conference，所以：Python 仍然是查看数据和处理数据的最佳工具集。我构建了一个 open-source plugin，会更深入地处理这些问题。把它指向你的 eval pipeline，它会告诉你哪里做错了，或者至少尽力而为。永远看数据。如果你喜欢这场演讲里的 memes，我的网站上还有更多。如果你想更深入了解这些主题，slides 和 video 在下面。感谢 Shreya Shankar 和 Bryan Bischof，多次对话塑造了这场演讲。Video & Slides slides 链接 Footnotes https://hbr.org/2012/10/data-scientist-the-sexiest-job-of-the-21st-century↩︎ https://www.forbes.com/sites/louiscolumbus/2018/01/29/data-scientist-is-the-best-job-in-america-according-glassdoors-2018-rankings/↩︎ https://www.mckinsey.com/about-us/new-at-mckinsey-blog/ai-reinvents-tech-talent-opportunities↩︎