数据智能工程师的黎明

数据智能工程师 Sql AI 的黎明 2026 年 11 月 11 日 · 阅读 12 分钟 我问我们的首席数据工程师（兼 MotherDuck 联合创始人） Nick Ursa，人工智能如何改变了他的工作。他的回答是：“这是我职业生涯中第一次没有积压。”你可能认为这会让他有充足的时间，但他比以往任何时候都更忙。虽然积压已经消失，但答案仍然必须是正确的，并且人类仍然必须决定要进行多少质量控制。以前他的工作是确保他计算的数字是正确的，现在他的工作是确保法学硕士或代理人得出的数字是正确的。这与处理票务队列是不同的工作。 11 月 4 日，在 Data Outpost，我为这个新角色提议了一个名称：数据智能工程师。我认为它现在是人工智能数据团队中的新兴角色，我想分享一下原因。数据团队的用途是什么？数据团队只有一项工作：帮助企业做出正确的决策。他们根据对正在发生的事情的更准确的了解，做出决策的速度越快，决策就越好。困难的部分是如何将问题转化为答案。它像继电器一样移动。一位营销主管周一上班，发现上周客户流失率激增。为什么会发生这种事？他们向数据团队提交了一张罚单以进行调查。一位分析师拿起票据，当他们深入研究时，他们意识到一些关键数据并未从其中一个数据源导出。他们提交了一张票，要求数据工程师进行调查。这需要对其中一个数据管道进行更改，因此数据工程师进行更改、测试、运行回填、测试回填并解决问题单。然后球又回到分析师的手中，分析师可以构建所需的仪表板。当产品发货时，营销人员已经不记得他们最初问的原因了。几周后，客户流失率自行恢复。这并不是说任何人没有有效或紧急地运作；该中继中没有人做错任何事。但每次交接都意味着等待，上下文会丢失，并且有效地对问题答案采取行动的能力的半衰期会慢慢衰减。顺便说一句，我们应该注意到，有一整代支持人工智能的工具并没有真正起到帮助作用。副驾驶时代使一些周转速度更快，但问题是交接次数太多，无法足够快地采取行动。这次有所不同 在 2025 年 12 月之前，反对人工智能进行分析的理由很容易提出。 LLM 写的 SQL 很糟糕。业务逻辑是不可知的。明智的结论是这永远不会起作用。事实上，我曾经谈论过数据团队如何或多或少地免受其他软件领域发生的破坏的影响。然后，突然间，地面动了。新模型在 SQL 方面变得更好。事实证明，业务逻辑是代理可以通过一些有用的上下文来弄清楚的。而且特工会进行多次轮换，这意味着他们不必第一次就把事情做好。他们可以尝试查询，查看返回的内容，然后重试，就像人类分析师所做的那样。把它们放在一起，它……就……起作用了。自助式 BI 已经面世数十年，有何不同之处？好吧，作为存在性证明，这里有一个例子；我在 Data Outpost 上所做的演示并不是作为幻灯片或 Google 幻灯片创建的，它是我使用 MotherDuck 和 Claude 构建的应用程序。我使用来自四个不同数据源的实时数据集，构建了许多交互式和动画可视化。我所做的任何事几乎任何人都可以做；我没有看一行代码或 SQL。需要强调的是，这不仅仅是自动构建仪表板的一种方法。 BI 通常是相当静态的，可能需要进行一些深入分析。但借助人工智能，您可以构建更丰富的可视化效果。更重要的是，如果您可以构建带有提示的仪表板，您就可以超越它并构建一个成熟的应用程序。允许业务利益相关者自己用数据回答问题比仅仅缩短数据团队的积压工作具有更广泛的好处；它实际上可以让他们做出更好的决定。通过减少所需的时间和涉及的交接次数，他们可以提出更多问题。他们可以在头脑中保留所有上下文的同时提出后续问题。这意味着他们可以更快地做出自信的决定。以下哪些工作可以作为提示？人工智能正在极大地改变信息工作者的工作方式。软件工程师经常发现他们的时间花在照顾 Claude 会话和橡皮图章代理编写的代码上。数据团队的传统角色又如何呢？说得有点挑衅的话，他们的哪些工作可以成为提示？尽管答案可能令人不舒服，但通过提示可以完成很多工作。在不远的将来，我们