AI, SQL, and the End of Big Data
33:08 Share

我第一次真正意识到大型语言模型实际上正在改变人们使用数据的方式，是在我们公司产品发布不久后，你使用MotherDuck，并提到你当时在ChatGPT和我们的查询UI之间进行复制粘贴。我的SQL技能很生疏。是的。

不，我认为这是每个人都会忘记各种SQL调用的语法的情况。这就像编码一样。有些人能记住所有的代码库，所以他们不需要自动完成，不需要任何副驾驶，不需要IDE，他们可以直接在记事本里输入。但对于我们其他人来说，我认为这些工具非常有用。

再次欢迎收听A16Z AI播客。我是德里克·哈里斯，本周与我一起的是A16Z普通合伙人詹妮弗·李和Motherduck联合创始人兼首席执行官乔丹·塔加尼。如果您不熟悉乔丹和Motherduck，简而言之，Motherduck是一个基于非常流行的DuckDB开源项目的商业数据库产品。乔丹过去的成就包括在谷歌构建BigQuery，他现在也是非官方的“小数据”运动发言人。

在本集中，我们讨论了DuckDB以及摆脱“所有数据都是大数据”的趋势，以及数据库技术在生产AI应用程序（例如向量搜索等）堆栈中的位置。乔丹还谈到了文本转SQL的未来以及如果您想在其上使用大型语言模型，干净数据的的重要性。值得注意的是，MotherDuck将于9月24日在旧金山举办Small Data SF会议，我们在节目说明中提供了注册信息。

言归正传，准备好听乔丹、詹妮弗和我谈论数据吧。提醒一下，此处的內容仅供参考，不应视为法律、商业、税务或投资建议，也不应用于评估任何投资或证券，并且并非针对A16Z基金的任何投资者或潜在投资者。更多详情，请访问a16z.com/disclosures。

我在这些基准测试报告中看到DuckDB这个新兴数据库时，它开始出现。我当时在SingleStore工作，我们引以为傲的是性能，突然之间，我们被拿来与这个由阿姆斯特丹的几位学者创建的、突然冒出来的数据库进行比较。我开始仔细研究它，感觉它非常有趣。你可以做一些我在谷歌工作时想做的事情，我在SingleStore工作时想做的事情。

以及客户在可扩展性和可缩减性以及以极低的延迟执行操作方面提出的要求。有人应该利用它构建一个SaaS服务并将其放到云端。好吧，也许那个人应该是我。我已经构建了两个数据库SaaS服务。当我开始考虑这个问题时，我联系了DuckDB的联合创始人，想看看他们是否会做类似的事情。

他们说，不，他们真的只想专注于构建核心数据库，但他们认为这是一个好主意。他们说，我们很乐意与您合作，鉴于您的背景，与您合作将非常棒。然后我就开始行动了。因此，我们很快筹集了资金，组建了一个团队来围绕这个想法工作，很快就在我们正在构建的内容上达成了一致。

我们的想法是，我们拥有这个非凡的数据库，我们可以将其放到云端，它运行速度很快，我们可以做低延迟的事情，它可以是一个数据仓库，也可以以DuckDB可以工作的许多其他方式工作，例如，用于数据科学用例，以及许多其他细分领域。让我真正对DuckDB印象深刻的另一件事是，

他们专注于数据库用户真正关心的问题。很多时候，我在数据库方面工作，我们花费大量时间专注于改进从我们作为数据库获取查询，

到我们完成该查询的时间。但这实际上并不是用户体验到的时间。首先，获取查询并获取结果需要时间，还需要分页显示结果。这只是实际的查询机制。然后你退一步，就会发现，我有一个想要解决的问题。我制定了这个问题。我有一个想要的想法。我有一个业务问题。我想了解我的数据的一些情况。从我得到答案到我得到答案需要多长时间？

这实际上是DuckDB团队做得非常出色的一件事。一个很好的例子是DuckDB中的CSV解析器。CSV解析器在BigQuery中就像一个事后才想到的东西。我们让一个应届毕业生来做这个工作。他们很棒，是一位优秀的工程师，但有点像，“好吧，我们完成了CSV解析。好了，我们继续下一个任务。”而DuckDB有一个专职人员在做这件事。他们撰写了关于它的研究论文。我想说，这是世界上最好的CSV解析器。

对用户的优势在于，我只是指向一个CSV文件，它是否包含奇怪的东西、错误或具有奇怪的分隔符或奇怪的空字符并不重要。CSV文件出错的方式有很多种。

但对用户的影响是，嘿，它可以正常工作。我可以直接查询它，它可以正常工作，速度很快，并且并行运行，我不必担心任何事情。对我来说，这非常吸引人，因为我觉得这是整个数据库社区真正错失良机的领域，并且有机会让某些东西更容易使用，让某些东西更以用户为中心。

你已经稍微谈到了这一点，但我希望退一步，向不熟悉DuckDB的观众做一个概述。在DuckDB出现之前，就已经存在内存数据库，从SQLite到其他数据库，以及从Druid到ClickHouse的其他分析数据库。BigQuery就是其中之一，你也在上面工作过。你认为DuckDB在哪些方面真正脱颖而出，你为什么认为它已经接管了数据库生态系统？

势如破竹，这是像你提到的CSV解析器那样的长期质量改进，还是某种基本的设计原则使DuckDB能够在今天得到如此广泛的采用？实际上，我认为它是第一个进程内分析数据库，或者是我知道的第一个进程内分析数据库。另一个众所周知的进程内数据库，事务数据库是SQLite。SQLite是世界上最

最常用的数据库。我认为在我的手机上，它可能运行了100次。每个应用程序都有一个SQLite副本。但是，如果您想运行更多分析查询，这些查询会询问有关数据集的问题，而不是查找或更新此内容，那么它更像是我的用户有多少，以及它如何随时间变化？分析数据库更适合回答这些问题。

他们最初我认为是针对数据科学家，因为它是在进程中的，你不需要移动数据，这非常好。数据已经在进程中了。如果您使用的是Python，并且您正在使用Pandas，并且您有Pandas数据帧，并且您正在对Pandas数据帧中的数据进行切片和切块，

附录实际上并没有为实际的数据操作做好准备，或者它为用户做好准备，但对计算机来说并不容易，而且很难优化。而数据库，它们已经解决了这个问题，即，好的，你得到了用户的意图，也就是我们的查询，然后他们可以在幕后对其进行优化。

因此，我能够利用这些数据科学用例，您可以直接指向您正在使用的数据帧、数据结构，并从中获得SQL答案，然后将其存储起来。因此，数据科学家不喜欢数据库的原因有很多，因为您必须设置它。你必须如何将我的数据导入？我如何导出我的数据？这里发生了什么？那里发生了什么？

DuckDB只是解决了这个问题。他们做的另一件事是，我的意思是，他们做得非常好。而且他们使它变得简单易于扩展。我认为正因为如此，DuckDB改进的速度才非同寻常。所以你，你会想到，好吧，当我们两年前第一次开始使用DuckDB时，它有一些差距，它有一些它不擅长的事情。它就像，好吧，三个月后，他们发布了下一个版本。三个月后，他们发布了下一个版本。它变得更好的速度

令人惊叹。如果您考虑一下，当您选择一项技术时，是的，您需要根据今天适合您的技术来选择一项技术。您选择的东西不是静态的。因此，选择移动速度最快的东西通常会有所帮助。

我认为这也非常有效。我们之前已经预见到了这一点，而且这已经得到了回报，因为两年来，DuckDB一直在变得越来越好。我们有下一个版本和下一个版本的预览，那就是，你知道，所有这些其他东西都在被添加。我们期待着。是的，你发布了几篇……

我会称之为地震式转变类型的文章，发表在去年的数据领域。一篇是《大数据已死》。另一篇是关于向上扩展与向外扩展的。向观众简要介绍一下这些帖子的背后思想，以及这与MotherDuck和DuckDB有何关系？我们注意到的一件事

作为BigQuery的产品经理，当我还在SingleStore时，以及与业内人士交谈时，我注意到，我们的大多数客户首先并没有大量数据。他们中的许多人拥有低于千兆字节的数据

你知道，总数据大小低于10GB。拥有海量数据的情况非常罕见。我们也有一些，我们有一些世界上最大的数据用户。我们有沃尔玛、汇丰银行、家得宝、Equifax，一些非常非常大的客户。当然，他们拥有大数据。他们拥有PB级的数据，其中一些接近EB级的数据。

但我们查看了他们实际使用的数据，他们只使用了其中的一小部分。如果您考虑一下获取数据的方式，您会获取大量数据，然后对其进行压缩，压缩，压缩，然后根据压缩后的数据运行报告。因此，人们用来分析这些数据的工具，他们使用的是为海量数据设计的工具。但是，如果您只查看这薄薄的一层数据，您实际上并不需要那么强大的功能。而且，

并且，构建了，你知道，在这些系统上工作过，这些分布式数据库系统，你做的几乎所有事情都包含如此多的复杂性，事情变得越来越难。你想向数据库写入一些内容。好吧，你把它写入日志文件，然后写入数据文件。但是你会有分布式事务，以及在多个节点中，以及，你知道，生活变得如此艰难，或者你需要……

你会加入，你必须将数据从一台机器移动到另一台机器，以便密钥位于同一位置，你必须处理其中一台机器发生故障并重新启动的情况。而且，有很多混乱的事情必须发生。而在一个更简单的系统中，一个单节点系统中，这些都不重要。当然，在单节点系统中，你会遇到扩展限制，对吧？它必须适合一台机器。

因此，这就是向上扩展的简单乐趣发挥作用的地方，那就是，实际上，当我们15年前开始构建这些系统时，几GB和几个处理器是一台相当强大的机器。现在，你知道，AWS在您可以随意启动和关闭的商品机器中拥有数十TB和数百个内核。

很少有工作负载不适合这些非常大的机器。这就像，如果您能够构建一个针对向上扩展的系统，您的生活就会变得轻松得多。正如我之前所说，您可以更快地移动，可以更快地变得更好。我认为这是使DuckDB能够如此快速地变得如此之好的原因之一，他们只是拥有这种单节点架构。

因此，MotherDuck真正利用的是这一点，例如说，嘿，如果我们不必花费所有时间来构建这个非常复杂的分布式系统怎么办？如果我们只构建这个可以向上扩展的东西，我们可以自动扩展它，我们可以将其缩减，缩减到零，DuckDB可以扩展，例如可以在100MB中运行，可以在浏览器中运行。有很多这样的事情，你可以做，但它也可以在最大的EC2实例上运行，

是的，这样做会遇到一些挑战，而且事情并不总是线性扩展，但这些都是工程问题，这些问题比试图解决更容易解决。你知道，你解决一次的事情，而不是每次添加新功能时都必须解决，这就是当你拥有复杂的分布式系统时会发生的事情。向上扩展曾经是一个有点脏的词。

是的，完全正确。它与“不可扩展”同义。我过去与之合作过的人说，如果你不在分布式数据库中，人们会嘲笑你。这实际上是一种触发器，就像，是的，如果你不害怕被嘲笑，你实际上可以构建一些非常惊人的东西。这在思考数据库世界方面也是一种范式转变，因为你是对的。当人们考虑扩展数据库时，首先想到的是如何进行分片，如何在……

几台机器上进行分布，而现在即使是个人笔记本电脑或计算机也超级强大，而你拥有所有这些由云托管的非常强大的机器。我想现在回想起来，特别是结合你的BigQuery经验和历程，你认为

大数据在当时从根本上来说是错误的方向，还是人们在追逐，因为谷歌已经这么做了，Meta已经这么做了，那些有能力扩展其数据平台来做到这一点的大公司，而市场上的其他公司也纷纷效仿，或者实际上存在一些务实和实用的合法用例。小数据和大量数据范式之间的平衡点在哪里？

大数据已死博客文章的早期草稿开头是，我责怪谷歌。

然后基本上就是一顿抱怨，说它毒害了人们的大脑。你知道，所以谷歌有一系列研究论文。有MapReduce论文。有GFS论文。有BigTable论文。有Dremel论文。你知道，通过将计算机科学问题分解开来，在许多不同的机器上运行，你能够获得更好的性能，因为，嘿，大数据来了，你需要做好准备。我认为这种假设是

总有一天，每个人的数据都会像谷歌的数据一样。但15年后，事实并非如此。我认为谷歌，我记得几年前，有大约9个产品拥有10亿用户。

作为一家SaaS公司，你知道，这就像你是一家B2B公司。你无法向10亿家企业销售产品。大约有6000家企业。你向企业销售产品，你大约有6000个潜在客户。您需要数据的规模大相径庭。如果您假设我需要这种巨大的规模，那么您就会阻碍自己，因为为了达到您认为自己将拥有的规模，您将必须拥有大量数据。

你最终不得不改变你的做事方式，你必须像将你的工作负载分成映射和归约阶段。然后是你在Hadoop中必须做的所有这些笨拙的事情，它仍然有点毒害了人们的大脑，他们认为他们必须以不同的方式做这些事情。事实证明，你知道，那个世界从未真正到来。有更简单的方法来完成这项工作。

这是一个非常有帮助的观点。如果我们甚至将其带到人们在追求大数据梦想时所做的权衡，我可以想象，你知道，大量的工程工作都花在了维护一个非常繁重且分布式系统上。

很难调试和维护。人们在投资时会得到什么，比如说，单节点，非常快速且易于设置的用户体验方面，你已经提到了这一点。它只是快得多，速度快得多。我们从小数据世界还能得到什么？

是的，我认为这是一种简单性。我认为当我们开始BigQuery时，我们有一个座右铭，我认为这来自图灵奖得主吉姆·格雷。对于大数据，你想将计算移动到数据，因为移动数据非常昂贵。现在，如果您接受一个世界，您的数据可能不会很大，那么……

它为实际进行计算的地方打开了更多机会。越来越多的人拥有光纤到户、光纤到工作场所。他们拥有100Gbps甚至更快的速度。我正在花费所有这些钱购买昂贵的云硬件。我有一条非常快速的互联网管道，我有一台非常快的笔记本电脑。为什么我不在本地做一些这些事情呢？

因此，你知道，我认为，这是DuckDB真正擅长的一件事，它可以帮助你，你可以将数据拉下来，你可以在本地完成所有工作。Fivetran的首席执行官乔治·弗雷泽在他的笔记本电脑上进行了一些基准测试。他有一台三年前的笔记本电脑，与……

一个不能说名字的云数据仓库相比。他的笔记本电脑使用DuckDB运行这些行业标准基准测试的速度比运行云端快。因此，如果您可以在本地运行东西，它就会打开很多机会。它会带来一些挑战，例如确保您没有非常高的出口费用，多次移动数据，数据管理，缓存管理，确保数据新鲜。

因此，这些实际上是一些其他鸭子正在做的事情。因此，我们在本地运行duck TV，我们在云端运行duck TV。我们称之为双重执行。因此，我们基本上可以允许工作负载移动到客户端，包括在Web浏览器中。因此，我们的Web浏览器在一个Wasm扩展中运行，WebAssembly扩展可以在Web浏览器中运行duck TV。因此，您可以进行类似于60帧每秒的视频游戏风格的飞行浏览数据、数据可视化。

如果您必须来回访问云端，这实际上是不可能的。因为你基本上来回访问云端，你只是没有做100到200毫秒。因此，这会对您可以执行操作的速度设置物理限制。但是，您可以移动的东西越多，就可以使延迟变得非常非常低。因此，这为以不同的方式做事打开了一些机会。

这非常引人入胜。结合Column Explorer，我可以想象这在多大程度上改变了数据科学家、数据分析师使用数据的方式，无论是在本地还是以混合方式。

转向小数据和AI，帮助我们了解小数据在这个AI世界中如何发挥作用？如今，有很多本地模型或本地推理引擎。你认为DuckDB和MotherDuck如何在AI世界中发挥作用？

有很多有趣的AI公司都在说，嘿，如果你看看在……

这些昂贵的GPU上运行的成本有多高，即使很难拿到这些GPU，你的本地笔记本电脑上也有一个高级GPU，为什么不在你的笔记本电脑上运行呢？所以我认为这确实是一种一致性，我们正在解决的是同一个问题，只是领域略有不同。而且，你知道，把这些放在一起，我们可以认为它就像花生酱和巧克力一样，

因此，你知道，我们很高兴与其中一些人合作，以及当您拥有AI时，当您拥有这些大型语言模型时，会发生什么，有时甚至会变得容易。

他们仍然需要访问数据。我们倾向于关注查找案例、向量查找和RAG，但也有一些情况需要聚合数据并了解全局上下文。这需要不同类型的数据库。像DuckDB这样的数据库对于构建AI支持的应用程序非常有用，在这些应用程序中，您可以显示数据、显示图表等。

AI的许多早期用例都更侧重于狭窄的领域，但我认为，随着人们试图使他们的AI应用程序真正有用，我认为将分析数据库与大型语言模型以及大型语言模型的输出或向量和嵌入相结合的情况将越来越多。

向量数据库领域已经爆炸式增长，现在每个人都有自己的向量。有PG向量，许多事务数据库都添加了向量支持。如果您眯起眼睛看执行向量相似性搜索、向量搜索所需的计算形状，

看起来更像分析而不是事务。我认为，当您创建事务数据库时，表单因子很重要。您需要多少内存，您将需要多少CPU，它往往有多尖锐，缓存会发挥多大作用。对于执行向量启动，这都更接近分析数据库而不是事务数据库。所以我认为添加向量，我认为只是不知道……

关于该行业的其他任何事情，例如向分析数据库添加向量，我认为这将比向事务数据库添加向量更有效，因此，你知道，duck db有，你知道，向量搜索，它有嵌入式余弦相似性，但它有一个向量搜索扩展，你知道，我认为我们有，我们有客户正在使用它进行某种分析RAG应用程序

你认为使用DuckDB的向量搜索以及全文搜索并在其分析引擎之上构建的特定类型的应用程序是否比其他应用程序更合适？或者我们仍然处于探索这些用例的早期阶段？我认为你是对的。我认为这还为时过早。我认为只是在……

你想使用AI来帮助塑造你向用户展示的内容的情况下。你不仅仅是在查看一个结果，而是在查看多个结果。

我认为这些将非常有用，但很难确定这些应用程序将是什么。是的。如果我们学到了一件事，那就是在构建AI应用程序的早期阶段，当提供相关的上下文和个性化的上下文时，模型的效果会好得多。我想到我的aura环以及它给我的建议，它汇总了过去七天和上个月的睡眠数据，它将如何，或者它将为我提供什么样的建议。

今晚或明晚的睡眠，Strava也是如此。很多这种处理能力都驻留在本地，但也提供了巨大的分析数据负载。我绝对可以想象越来越多的此类应用程序不仅会面向消费者，也会面向企业。是的，绝对如此。这是一个很好的例子，现在我们看到越来越大的上下文窗口，您可以使用

使用分析类型的查询来填充这些上下文窗口。随着我们围绕小数据理念塑造范式，您如何看待数据堆栈的整体变化？围绕Hadoop和大数据构建了如此多的势头和生态系统。上游和下游参与者是否也需要改变他们的思维方式，无论是ETL、可视化还是其他工具和流程？

告诉我们你是如何考虑这个问题的。因为如果你考虑一下现代数据堆栈，你知道，你有摄取工具，你有查询工具，你有BI工具，摄取工具和BI工具，我们总是有点已经在小数据世界中了，因为你，你知道，数据的到达率，

它并不庞大。它并不巨大。你大多数时候并没有每秒摄取GB级的数据。大多数时候，你正在摄取的东西是相对独立的。我已经与Fivetran的乔治和DBT的特里斯坦就此进行了讨论。在较小的数据世界中，他们的世界并不一定有任何不同。然后在BI方面，你知道，数据可视化方面，

我们本来就将世界视为小数据。他们将大量内容推送到查询引擎。是的，这可能会很慢。我的意思是，Looker 的一项创新就是依赖实际上非常快速的云查询引擎。因此，与 Power BI、Tableau 相比，您可以获得合理的性能。它们依赖于实际将所有数据、所有重要数据都拉入本地内存。它们实际上是这些单节点小数据应用程序。

引擎，因此它们可以快速执行操作。我认为有趣的事情是，您能否将更多工作负载下推，并在可视化方面仍然保持同样快速？您能否将 DuckDB 和混合执行整合到您的实际数据可视化中？

到您向用户展示的内容中，为他们提供更好、更低的延迟体验。我知道，例如，Omni 正在其前端使用 DuckTB。您知道，Hex 也使用 DuckTB。因此，很多人都在构建使用 DuckTB 的有趣的初创公司。看看是否会出现其他类型的

小数据专家很有趣，但我猜想，对于那些人来说，大数据的世界变化并没有像查询引擎那样大。另一个问题是您如何看待用户与数据本身的交互方式

在 AI 世界中发生变化。您对在编写 SQL 查询中使用大型语言模型的看法是什么？您在日常分析中使用它吗？您认为它会走向何方？我第一次真正意识到大型语言模型实际上正在改变人们使用数据的方式是在我们不久前推出 MotherDuck 时，您提到您在 ChatGPT 和我们的查询 UI 之间进行剪切和粘贴。任务是，我的 SQL 技能非常生疏。

每个人都会忘记各种 SQL 调用的语法。这就像编码一样。因此，有些人会记住……所有代码库。因此，他们不需要自动完成。他们不需要任何副驾驶。他们不需要 IDE；他们只需在记事本中输入即可。但对于我们其他人来说，我认为这些工具非常有用。我认为我们已经看到这些工具已经改变了人们与数据交互的方式，以及他们编写 SQL 查询的方式。

我们已经在 MotherDuck 中所做的一件事是，我们专注于改进编写查询的体验。因此，我们发现的一件非常有用的事情是，当有人运行查询时出现错误，

我们会将错误行馈送到 GPT-4 并要求它进行修复。事实证明它非常好。我们会提供大量上下文，但事实证明它实际上会给你非常好的答案。这样做的优点是，如果您忘记了语法，如果您忘记了 date diff 函数的参数顺序，则有一个 date_diff，然后您会告诉您是否想要小时或如何操作。有很多东西很麻烦，您只需输入您认为它会是什么

然后，它就会修复它。然后它会显示给你，好的，是这样吗？然后你点击是。但这是一种让你保持编写查询流程并具有真正交互性的好方法，而不是必须像这样：

哦，糟糕，我不记得那个参数了。然后你去看文档，然后你浏览文档，然后你再回来。我认为在这方面你可以做得更多。您可以提供有关模式等的更多上下文。我认为自动完成类似于您在 GitHub Copilot 中所做的事情，我认为有一个很好的……

继续构建这些的机会。然后，我认为 PECS 做了很多这样的事情，您可以自动将其可视化。在这个数据上，一个有趣的可视化是什么？而且很多时候，这将是您想要实际执行的事情，并且您可以相对轻松地构建这类东西。过去，如果您想构建这些类型的功能，您需要一个专家团队工作数年。相反，你有一个

对这些东西非常兴奋的实习生，他们在周末工作并想出了一些令人惊奇的东西。你永远不会低估积极主动的实习生的力量。另一种有趣的事情是，是否存在一个世界，您可以更进一步，而不是仅仅帮助您编写查询，而是用类似自然语言的东西编写？

您可以展示很多关于如何用英语编写并将其转换为良好的 SQL 的很好的演示。我认为很难超越演示，因为在典型的分析中，有很多内容实际上是特定于该组织的，并且特定于数据的布局方式和数据的使用方式。如果我说，我上个季度的收入按地区和代表细分是多少？

什么是地区？什么是季度？其他人可能会使用不同的财政季度，但是，你知道，收入就像，哦，这难以计算，因为就像存在另一列，它就像欺诈，或者，你知道，一些数据就像实际上还没有注册的用户。或者还有货币问题，好的，三个月前数据中存在错误。就像你必须为此进行修复一样。要真正回答简单的问题，还有各种非常复杂的事情必须进行。

所以我对在一般情况下这样做并不十分乐观。我认为可能有一些情况，这实际上可能适用于应用程序。我们有客户正在这样做，他们正在构建应用程序

因为他们基本上为每个用户都具有相同的模式，并且他们具有相对简单、非常干净的数据模式，并且它不是海量数据，并且他们可以很好地命名所有内容，并且他们可以添加有关所有字段的非常好的元数据，然后他们实际上可以获得相当好的性能来执行英语文本到 SQL 的转换。这是一个很有前景的领域。

对我来说，另一个有前景的领域是，我认为您需要经历某种语义层。语义层长期以来一直让我很感兴趣。但我认为您可以使用语义层做一些非常酷的事情。语义层基本上……您可以定义收入是什么。您定义季度是什么。您定义数据模型如何互操作。我认为有了这些，您可以更好地完成文本到 SQL 的转换以及更多任意的事情，因为……

您只需要将英语文本映射到模型中的内容，而不是将英语文本映射到数据库中描述的事物的物理层。听起来您属于 AI 分析师不会很快取代真正的真实数据分析师的阵营，前提是 AI

有一个非常干净的数据集需要分析，并且还需要一个语义层需要布局。可能会有更多自动化，但在使用 AI 分析师解析数据的广义定义中，我们距离获得准确的结果还有很长的路要走。

是的，我还不是一个 AI 极大主义者。我认为 AI 可以做一些非常酷的事情和令人惊奇的事情，但也会有一些限制。也就是说，许多说过 AI 能力有限的人都是错的。所以我们会拭目以待。我们一直在讨论尝试替换数据分析师或使

这种能力民主化已经超过十年了，感觉就像，而且似乎并没有太多进展。所以也许你发现了什么。我认为副驾驶也是如此。就像听起来程序员们一样，你知道，这是一个很好的增强工具，但你仍然需要知道你在做什么，并且知道你实际构建的内容的来龙去脉，或者在这种情况下，你正在处理的数据。是的。我认为在副驾驶方面，我认为因为有些人认为编码更像是写作或

写作是一种意识流，你只是写，写，写，好吧，你完成了。也许你测试一下，然后你就完成了。但我认为大多数软件工程更像是编辑。你在这里添加一些关键词，在这里添加一些关键部分，你将这些东西联系在一起，你转换这些东西。这是 AI……

你知道，也许你会擅长这一点，但这与那种事情相差甚远。这就是工程师花费大部分时间做的事情。是的，我记得在数据科学成为其时刻的时候，至少作为一个艺术术语，它是地球上最性感的工作，所有这些东西。但是，然后你会和拥有这个职位的人交谈，并且会说，好吧，我的大部分时间都花在了处理数据和数据准备上。

我们在这方面取得了进展吗？这是否是 AI 实际上可以帮助数据处理工作流程并帮助数据科学工作流程的领域，从程序上清理这些数据？我认为绝对可以。正如我提到的 DuckDV CSV 解析器。我的意思是，这是一种实际上不应用 AI 的示例，但我猜想将 AI 应用于推断数据中的模式将是一个有趣的科研项目

结构不良的数据，如 CSV，并且能够解决问题，因为有一堆启发式方法最终会被使用。但我认为这也是数据科学家喜欢 DuckDB 的原因之一，我认为，因为它只是帮助他们减少了很多繁琐的工作。但这并不意味着我不能让它变得更好。就是这样。希望您觉得这是一个有趣且有见地的对话。请记住，您可以在 9 月 24 日在旧金山查看小型数据旧金山会议。

如果您喜欢这个播客，请对其进行评分、评论，以及您觉得如何在社交媒体和您选择的平台上推广它。