招聘：AI工程师 vs. 数据工程师

AI编程/Vibe Coding 遇到问题需要帮助的，联系微信 ezpoda，免费咨询。

数据工程师应该处于你AI团队的核心。不是支持他们。不是"帮助处理基础设施"。从第一天起就是核心团队成员，拥有同等权威。AI行业把这个搞反了。你的产品在生产数据上崩溃，而这些数据看起来与你的测试集完全不同。部署导致系统瘫痪。你的AI团队盯着他们无法诊断的吞吐量问题。行业构建这些团队的方式有问题。你的AI产品每周处理数TB的新数据——来自用户、来自生产、来自你的测试集从未想象过的上下文。而你在没有懂得如何构建大规模处理数据而不崩溃的专家的情况下处理它。这就是AI优先陷阱：为AI会议所庆祝的东西优化，而你的产品在他们忽视的东西上崩溃。

本文最初发表于我的newsletter。如果你只有5分钟：以下是关键要点

• 今天的AI团队缺乏生产级数据专业知识。 大多数AI工程师在模型开发和软件部署方面很强——但在处理真实世界、不断演进、大规模数据方面却不强。
• 数据工程师应该是核心团队成员，而不是支持。 他们必须从第一天起就参与其中，拥有同等权威和决策权。
• 供应商过度推销了抽象。 Databricks和Snowflake等平台说服公司可以跳过雇佣数据专家。这创造了容易遭受数据相关失败的脆弱AI系统。
• 真正的失败不在模型中——而是在数据管道中。 系统因规模问题、无效输入、模式漂移和缺乏监控而崩溃——AI工程师通常未受过处理这些问题的培训。
• 最好的AI团队像数据工程师一样思考。 早期构建数据基础设施的团队往往拥有稳定、可扩展的AI产品。
• 为战争故事而招聘，而非技术栈。 寻找调试过真实失败的数据工程师，而不是那些只关注框架或架构图的人。

数据平台出售了工具，而非你需要的专业知识

数据平台供应商制造了这场灾难。他们说服公司跳过懂得如何处埋生产数据的人，从而赚了数十亿。

这是他们承诺的：

• Databricks： "湖仓架构消除了数据工程复杂性"
• Snowflake： "零管理数据仓库——无需专家"
• Azure： "无服务器数据处理——专注于洞察，而非基础设施"
• Supabase： "后端即服务——交付产品，而非基础设施"

每个供应商都兜售同样的幻想：我们的平台抽象了复杂性，你只需专注于模型。数据工程成为每个人都学会绕开的瓶颈。太慢、太官僚、阻碍交付。AI团队等待本应该几天完成的基础设施需要几周。高管们看着竞争对手交付更快并要求速度。供应商提供了一个答案：跳过专家，使用我们的平台，快速行动。

结果：整整一代AI工程师——学习机器学习的软件工程师——在构建生产服务方面技能卓越，但对生产数据管道完全没有准备。他们可以大规模部署服务，但从未构建过处理数据漂移的系统。他们可以处理每秒10K请求，但没有验证数TB不断演进输入数据的框架。他们懂生产软件工程，但不懂生产数据工程。

这些平台出色地处理存储和计算。但它们不解决生产数据的独特挑战：模式演进、TB级验证、处理真实世界数据表现出的无限种类的损坏。供应商出售了工具。他们没有出售专业知识。

LinkedIn招聘紧随其后。"AI工程师"职位激增——具有ML技能的软件工程师。"数据工程师"职位从初创公司招聘板上消失，或作为支持角色出现——基础设施团队，向工程汇报，在需要时提供帮助。

你继续为模型优化和生产软件技能而招聘。你的产品在生产数据挑战上继续崩溃。AI优先陷阱正在上演。

以下是实际崩溃的内容：

失败1：当数据量增加时，你的产品瘫痪

你的模型在测试集上工作。你部署。流量增加3倍。管道崩溃。你的产品瘫痪。

你的AI团队无法诊断数据管道中的吞吐量问题。他们知道如何扩展服务——添加实例、负载均衡、优化API。但他们从未学习过设计在未知输入数据上扩展的数据管道。他们在为笔记本内存大小精心策划的数据集上优化模型。当生产数据增长时，管道无法处理负载。

他们尝试添加计算。增加批大小。尽可能并行化。问题持续存在，因为这不是计算问题——而是数据架构。模式不能有效分区。转换逻辑不能流式处理。验证产生背压。

数据工程师在几分钟内看到这一点。他们构建了数十个处理TB级数据的管道。他们知道哪些操作可扩展，哪些会产生瓶颈。他们从第一天起就为10倍增长设计，因为他们曾眼睁睁看着系统在成功下崩溃。

失败2：糟糕的输入数据导致你的产品崩溃

模型期望的值处出现null。期望数字处出现字符串。超出范围的值打破假设。生产事故。

你的AI团队从未为生产数据构建验证层。他们知道如何验证API输入——类型检查、边界检查、标准软件验证。但生产数据验证不同。用户数据演进。模式漂移。新的边缘情况不断出现，没有测试套件预料到。

每个边缘情况都是惊喜。每个惊喜都是生产事故。他们被动地修补——处理这个null，捕获那个异常，包装那个转换。代码库变成意大利面条。

数据工程师从第一天起构建验证基础设施。在数据接触模型之前拒绝畸形数据的模式契约。摄取时的健全性检查。当分布偏移时发出警报的监控。他们见过数据可能损坏的每一种方式。

失败3：每次部署都是俄罗斯轮盘赌

你30%的部署会损坏某些东西。你在客户投诉时才发现。

你的AI团队没有数据系统的登台基础设施。他们知道如何部署服务——蓝绿、金丝雀、回滚策略。但他们将模型部署到生产环境并祈祷数据表现得像测试集。它从不如此。

数据工程师构建影子模式、分阶段推出、数据回归时自动回滚。他们见过足够的灾难，永远不会在没有它的情况下部署。

基础设施优先陷阱：当数据工程师成为瓶颈时

并非所有数据工程师都优先考虑生产。有些会想要花6个月时间在架构图上，然后再向客户交付任何东西。这就是基础设施优先陷阱——与AI优先陷阱同病，不同的职称。

这就是高管们最初学会绕开数据工程师的原因。

优先考虑生产的数据工程师操作不同。他们在第一周就交付到生产环境，配备三个关键部分：基本验证、对数据异常发出警报的监控、分阶段推出基础设施。不完美。只是足够在客户看到之前捕获问题。然后他们在了解生产环境中实际损坏的内容时添加基础设施。

基础设施优先的数据工程师想要为想象的问题构建。优先考虑生产的数据工程师为他们实际看到摧毁系统的问题构建。你想要后者。

我以为Unite的ML工程师是正常的

你知道什么有趣吗？当我第一次到达Unite时，我以为ML工程师就像我见过的其他每个ML团队一样。五名工程师为数千客户构建生产ML系统，与许多其他团队对接。他们持续交付。系统只是运行。没有每周生产事故。没有紧急调试会议。一切都很好地集成到生产级基础设施中。

直到后来我才意识到这不正常。

为什么？他们的成长经历不同。

他们加入时ML工作不够。所以他们第一年为700人制作生产ETL——处理真实数据失败、凌晨3点调试数据管道、学习在负载下什么会损坏数据系统。来自几十个来源的混乱数据。学习系统化验证而不是被动反应。学习在不赌博的情况下部署数据管道。

到他们转向ML工作时（其中一些人拥有博士学位！），他们像数据工程师一样思考，只是碰巧构建模型。他们从第一天起就为数据规模设计。他们在首次部署前构建验证层。他们为数据管道设置登台和监控基础设施。他们将数据质量视为基础，而非可选。

AI行业会称他们的第一年为浪费——没有论文，没有模型，只是无聊的数据基础设施。那"浪费"的一年就是为什么他们的产品从未崩溃，而其他人的崩溃了。行业衡量了错误的东西。

将数据工程师作为拥有否决权的平等人员招聘

你的产品每周都崩溃。停止招聘更多AI工程师。

你知道优先考虑生产的数据工程师来自哪里吗？他们有战斗伤疤。

从第一天起将他们置于核心。不是作为支持。作为与AI工程师一起设计系统的平等人员。他们拥有数据架构、验证基础设施、部署管道、监控。他们参与每个设计讨论。他们对无法随生产数据扩展的方法拥有否决权。

你的面试应该测试战争故事，而非理论：

问题1： "带我经历一次生产数据管道失败。什么坏了？你怎么找到它的？你构建了什么来防止它再次发生？"

问题2： "我即将部署一个每秒处理100K事件的模型。我们的验证目前同步运行。什么首先崩溃，你的修复是什么？"

问题3： "描述一次你在生产失败发生前阻止它的时间。"

红旗：

• 希望在交付任何东西之前花一个月在架构图上
• 简历强调技术和框架而非生产系统
• 无法描述他们阻止的具体生产失败
• 在询问你的数据量之前询问你的技术栈

绿旗：

• 告诉你关于凌晨3点调试管道失败的具体细节，关于什么坏了以及为什么* 以客户影响的术语描述数据管道失败
• 首先询问你的生产数据量和增长率
• 可以为你的特定用例解释模式演进策略

数据工程师应该是第3-5号员工，而不是第15号。到你意识到你需要他们时，你已经积累了需要6个月才能解开的技术债务。在你奠定基础时雇佣他们，而不是在它已经损坏之后。

停止为基准优化

AI优先陷阱是通过模型性能衡量成功，而客户因数据失败而离开。

你可以继续为行业所庆祝的而招聘——模型优化、生产软件工程、API设计。你的产品将每周因数据问题而继续崩溃。

或者你可以将数据工程师置于核心。构建大规模处理生产数据而不崩溃的基础设施。设计系统化捕获数据问题的验证。创建不赌客户惊喜的数据管道部署实践。

AI行业庆祝什么能让你获得会议演讲。你的产品在他们忽视的东西上崩溃。停止为基准招聘。开始为生产招聘。

数据工程师在核心，从第一天起。或者继续想知道为什么你的产品每周都崩溃。

原文链接：Stop Hiring AI Engineers. Start Hiring Data Engineers.

汇智网翻译整理，转载请标明出处