ReaderMX.
Z Potentials

喝点VC｜a16z：LLM正革新SQL查询，但在处理复杂数据时仍面临挑战；AI与SQL查询结合转向更高效、灵活的数据处理方式

Za16z约 20 分钟

Image

图片来源：a16z

Z Highlights

  • DuckDB作为一个开创性的进程内分析数据库，通过强大的CSV解析器等功能改善了用户体验。MotherDuck利用DuckDB的单节点架构提升性能并降低数据分析的成本。许多组织可以通过较小的本地化数据解决方案来满足需求。本地AI模型的部署与小数据策略非常契合，在优化资源的同时保持高效性。
  • 数据可视化和AI应用的未来依赖于DuckDB的向量搜索功能和混合执行模型。大型语言模型（LLMs）正在通过语法修正和基于自然语言的查询生成来革新SQL查询，但在处理复杂数据时仍面临挑战。
  • AI可以完成一些令人惊叹的任务，但目前还不能完全取代数据分析师，特别是在复杂的编程和数据处理过程中。
Derrick Harris：欢迎再次收听a16z AI播客。我是Derek Harris，本周和我一起的是a16z的合伙人Jennifer Li以及MotherDuck的联合创始人兼CEO Jordan Tigani。如果你对Jordan和MotherDuck还不熟悉，简单来说，MotherDuck是基于非常受欢迎的开源项目DuckDB的商业数据库服务。Jordan曾在谷歌构建了BigQuery，并且他现在也是“小数据”运动的非正式代言人。在本期节目中，我们讨论了DuckDB以及从“大数据至上”时代向其他方向的转变，还探讨了数据库技术如何在AI应用中发挥作用，例如用于向量搜索等。Jordan还谈到了文本转SQL的未来，以及如果你想让大型语言模型处理数据，保持数据干净的重要性。另外值得一提的是，MotherDuck将于9月24日在旧金山举办“小数据SF”会议，注册信息可以在节目说明中找到。介绍完这些内容后，请准备好与我们一起听Jordan、Jennifer和我讨论数据的相关话题。提醒一下，这里的内容仅供参考，不应被视为法律、商业、税务或投资建议，也不应用于评估任何投资或证券，也不针对任何a16z基金的投资者或潜在投资者。更多详情，请参见a16z.com/disclosures。

DuckDB的崛起与小数据时代的技术转型

Jordan Tigani：我第一次接触到DuckDB这个新兴数据库，是在一些基准测试报告中看到它的表现。当时我在SingleStore工作，我们一直以卓越的性能为傲。突然，我们开始被拿来与这个由几位阿姆斯特丹学者创建的、此前几乎默默无闻的数据库进行比较。我开始对它进行了一些探索，发现它真的很有趣。它能够实现我们在谷歌和SingleStore时一直想要实现的目标，同时也能满足客户在可扩展性和缩减规模方面的需求。延迟极低。我当时就想，应该有人把这个数据库做成SaaS服务并部署到云端，而这个人或许就是我。我已经构建了两个数据库SaaS服务项目。当我开始认真考虑这个想法时，我联系了DuckDB的联合创始人，想了解他们是否有类似的计划。他们表示没有，他们只是专注于构建核心数据库，但他们认为我的想法很好，并表示非常愿意与我合作，充分利用我的背景。于是，我们迅速筹集了资金，围绕这个想法组建了团队，并迅速凝聚成我们要构建的项目。我们相信，我们手中有一个非凡的数据库，能够将其部署到云端，且发展速度非常快，能够处理低延迟的工作，成为一个数据仓库，还可以像DuckDB一样，在数据科学应用以及其他许多领域发挥作用。
另一个让我印象深刻的地方是，DuckDB团队真正关注数据库用户最关心的事情。很多时候，在数据库工作中，我们花了大量时间关注从数据库接收到查询到完成查询所需的时间，但这并不是用户实际体验到的全部时间。首先，有一个获取查询并返回结果的时间，还有分页结果的时间，这只是查询机制的一部分。然后，当你退一步来看，还有从提出问题到得到答案的整个过程。DuckDB团队在这一点上做得非常出色。一个很好的例子就是DuckDB中的CSV解析器。在BigQuery中，CSV解析器只是一个事后才考虑的功能。我们曾让一位刚入职的大学毕业生来处理这个任务，他是一位优秀的工程师，但我们当时只是觉得，CSV解析器搞定了，可以继续下一个任务了。而在DuckDB，他们有专门人员负责这一问题，并为此撰写了研究论文。我可以说，这是世界上最好的CSV解析器。对用户来说，它的好处在于，我只需要指向一个CSV文件，无论里面有多么奇怪的内容、错误、奇怪的分隔符或空字符。CSV文件有各种各样可能出错的地方，但用户只需直接查询它，它就能工作，速度快，并行运行，无需担心任何问题。对我来说，这真的很吸引人，因为我觉得整个数据库领域在这方面真的错失了一个让技术更易用、更以用户为中心的机会。
Jennifer Li：你刚才已经提到了一些内容，但我想退一步，为那些不太熟悉DuckDB的听众提供一个概述。在DuckDB之前，已经有很多内存数据库，比如SQLite以及其他类似的，还有许多分析数据库，如Druid和Clickhouse。BigQuery也是其中之一，而你曾参与过它的开发。那么，你认为DuckDB真正的亮点是什么？为什么你觉得它能迅速在数据库生态系统中引起巨大反响？是因为像你提到的CSV解析器这样的长尾质量改进，改善了用户体验，还是因为有某种根本性的设计理念，让DuckDB能够在今天被广泛采用？
Jordan Tigani：实际上，我认为它是第一个进程内的分析数据库，或者至少是我所知道的第一个。另一个众所周知的进程内数据库是SQLite，而SQLite是世界上最常用的数据库。我想在我的手机上，它可能每天运行了数百次。几乎每个应用程序都有一个SQLite副本。然而，如果你想运行更复杂的分析查询，想要对数据集进行深入探索，而不仅仅是简单的查找或更新数据，那么分析数据库才更适合。而DuckDB最初就是为数据科学领域的用户设计的。因为它是进程内的，所以你无需将数据移动来移动去，这一点非常出色——数据已经在进程中。如果你使用的是 Python，并且在使用pandas处理数据帧，pandas非常适合用户操作数据，但并不适合实际的数据处理优化。数据库则不同，它们已经解决了获取用户意图（即查询）并在后台进行优化的问题。因此，我们能够很好地处理这些数据科学的使用场景，你可以直接操作已经使用的数据帧和数据结构，执行SQL查询并存储结果。
数据科学家不喜欢数据库的原因之一是数据库的设置过程过于繁琐。你需要弄清楚如何将数据导入导出，遇到问题时也不知该怎么办。而DuckDB则解决了这个问题。他们还在保持简洁的同时使其易于扩展。我认为正是因为这些原因，DuckDB的进步速度非常快。可以想象，当我们两年前刚开始使用DuckDB时，它还存在一些不足之处，有些功能并不完善。但是大约每三个月他们就会发布一个新版本，每次发布都会带来改进。这种快速迭代的速度令人惊叹。
当你选择一项技术时，你需要选择符合当前需求的技术。但技术并不是一成不变的，所以选择那些进步最快的技术往往是有帮助的。这一点在DuckDB身上得到了充分体现。我们也预见到了这一点，并且得到了回报。过去两年，DuckDB变得越来越好。我们已经看到了即将发布的版本以及更多新功能的预览，对此我们非常期待。

小数据与AI的结合：重新定义数据处理与应用

Jennifer Li：是的。去年你发布了几篇我称之为对数据领域产生剧变影响的文章。其中一篇叫Big Data is Dead，另一篇则是关于scaling up （“纵向扩展”）与scaling out（“横向扩展”）的探讨。
Jordan Tigani：作为BigQuery的产品经理，以及在SingleStore工作期间与业内人士交流时，我注意到大多数客户实际上并没有海量数据。他们中的很多人数据总量不到1GB或10GB。拥有超大数据量的情况非常罕见。我们确实有一些全球最大的数据用户，比如沃尔玛、汇丰银行、家得宝、Equifax等非常庞大的客户。当然，他们拥有海量数据，达到数PB（拍字节），甚至接近EB（艾字节）。但当我们实际查看他们所使用的数据时，发现他们只用到其中很小的一部分。你可以想象，用户获取了海量数据，不断进行压缩和再压缩，最后从这些压缩后的数据中生成报告。因此，人们用来分析这些数据的工具通常是为处理巨量数据而设计的，但如果你只处理一小部分数据，实际上并不需要如此强大的工具。
当你构建或使用这些系统时，所有事情都会变得更加复杂。比如，你想向数据库写入数据，那么你需要将数据写入日志文件和数据文件，但同时可能还要处理在多个节点之间发生的分布式事务，这会让一切变得更加棘手。你想进行一次关联查询，这意味着要将数据从一台机器移到另一台机器，确保键在同一个位置，同时还要应对节点故障或重启的问题。这些问题非常麻烦，而在一个更简单的系统中，尤其是在单节点系统中，这些问题根本不存在。当然，在单节点系统中，你会遇到扩展的限制，对吧？所有操作都必须在一台机器上运行。而这正是扩展带来的简单好处。
实际上，15年前我们开始构建这些系统时，几GB的数据和几个处理器已经算是非常强大的配置了。如今，在AWS上的普通机器已经拥有几十TB的存储和数百个核心，并且可以随时启动和关闭。很少有工作负载不能在这些大型机器上运行。所以，如果你能够构建一个针对这种扩展的系统，你的工作会变得更加轻松。正如我之前所说的，你可以更快地迭代，进步得更快。这也是DuckDB能够快速提升的原因之一，因为它采用了单节点架构。而这也是MotherDuck所利用的一个优势：我们不需要花费大量时间去构建复杂的分布式系统。我们只需要构建一个可以扩展、自动伸缩的系统，它可以缩减到零，DuckDB可以在100MB内运行，也可以在浏览器中运行。你可以做很多令人兴奋的事情，同时它也能在最大型的EC2实例上运行。是的，当你这么做时会遇到一些挑战，扩展也不总是线性的，但这些都是工程问题，解决它们比起在复杂的分布式系统中要容易得多。而且，你只需要解决一次，而不是每次添加新功能时都要重新解决。
Derrick Harris：“扩展”这个词过去有点带有贬义。
Jordan Tigani：是的，没错。它几乎等同于“不可扩展”。我以前的一位同事曾经说过，如果你不使用分布式数据库，别人会嘲笑你。这让我意识到，也许如果你不害怕被嘲笑，反而可以构建出一些非常了不起的东西。
Jennifer Li：这也是数据库领域思维的一种范式转变。你说得对，当人们谈到扩展数据库时，首先想到的就是如何进行分片，如何将数据分布到多台机器上。然而，如今即便是个人笔记本电脑或计算机也非常强大，云端托管的机器也同样强大。回过头来看，特别是结合你在BigQuery的经验和历程，你认为大数据在那个时间点上本质上是错误的方向吗？还是因为谷歌、Meta这样的大公司已经这样做了，能够扩展其数据平台的企业也纷纷跟随？或者当时是否存在一些真正实际且有用的应用场景？小数据与大数据之间的平衡点在哪里？
Jordan Tigani：我写的Big Data is Dead那篇文章的早期草稿是以“我责怪谷歌”开头的，基本上是在抱怨他们有点影响了人们的思维。谷歌发布了一系列研究论文，包括MapReduce、GFS、BigTable和Dremel论文。这些论文提倡将计算任务分解成小块，在多台机器上运行，从而获得更好的性能，因为大数据时代即将到来，你需要为此做好准备。大家有一种假设是，未来每个人的数据量都会像谷歌一样庞大。但15年过去了，这种情况并没有成为现实。我记得几年前，谷歌有大约九个产品拥有十亿用户。作为一家SaaS公司，一家B2B企业，不可能有十亿个目标销售客户。你可能有6000家企业客户，向这些客户销售时所需的数据规模和谷歌差异巨大。如果你假设自己需要应对这种巨大的规模，反而会限制自己。为了达到这种假想中的规模，你必须改变操作方式，把工作负载拆分成Map和Reduce阶段，同时还得应对Hadoop带来的各种麻烦。这种思维影响了人们，让他们觉得必须用不同的方法来处理这些问题。然而，那个时代并没有真正到来。其实有更简单的方法可以完成工作。
Jennifer Li：这是一个非常有启发性的观点。如果我们考虑到人们在追逐大数据梦想时所做的取舍，可以想象，大量工程工作都花在了维护一个庞大且分布式的系统上，而这类系统非常难以调试和维护。当人们投资于一个单节点、速度极快且易于设置的系统时，在用户体验方面会带来什么收获呢？你提到它的响应速度更快。那么在小数据的世界中，我们还能获得哪些优势？
Jordan Tigani：其中一个优势是简化。当我们开始构建BigQuery时，我们遵循了一个信条，这是来自图灵奖得主Jim Gray的观点“在大数据场景中，你应该将计算移到数据所在的位置，因为移动数据的成本非常高。但如果你接受一个数据规模并不庞大的世界，那么这就为你在哪进行计算提供了更多的选择”。如今，越来越多的人拥有家庭光纤网络，工作场所也配备了光纤网络，他们的网络速度达到100Gbps或更快。尽管他们在云端投入大量资金购买昂贵的硬件，但他们也拥有非常强大的笔记本电脑。那么，为什么不在本地完成一些工作呢？DuckDB的一个优势就是帮助你将数据下载到本地，并在本地完成所有工作。Fivetran的CEO George Fraser曾在他的笔记本电脑上进行了一些基准测试。他使用的是一台三年前的笔记本电脑，和一个云数据仓库（出于保密原因不便透露）进行对比，结果发现笔记本电脑使用DuckDB运行这些行业标准基准测试时速度更快。如果你能够在本地运行任务，就会带来许多机会。
但这也会带来一些挑战，比如如何避免产生高昂的出站费用，避免多次移动数据，管理数据缓存，并确保数据是最新的。实际上，这些都是MotherDuck正在解决的问题。我们既可以在本地运行DuckDB，也可以在云端运行DuckDB，这就是我们所说的“双执行”。基本上，我们可以将工作负载移动到客户端，包括在网页浏览器中运行。我们的浏览器通过Wasm（即WebAssembly扩展）运行DuckDB，这使得我们能够在浏览器中进行高效的数据操作。你可以做到每秒60帧的游戏风格数据飞行和数据可视化，如果需要频繁与云端交互，这是根本不可能实现的。因为每次与云端的交互都需要100到200毫秒的延迟，这就给操作的速度设定了一个物理限制。但如果你能将更多的操作移到本地，就能实现非常低的延迟，从而为以不同方式处理问题提供了更多的可能性。
Jennifer Li：这非常有趣。结合Column Explorer，我可以想象这对数据科学家和数据分析师在本地和混合模式下处理数据的方式带来了多大的改变。从小数据到AI的过渡中，能否帮助我们理解小数据在AI世界中的作用？今天有很多本地模型或本地推理引擎。你认为DuckDB和MotherDuck在AI世界中会扮演什么角色？
Jordan Tigani：有一些AI公司会说：“看看在云端运行这些高级GPU的费用有多高，而且甚至很难获得这些GPU。”然而，你的本地笔记本电脑上可能就有一个高级GPU，为什么不在笔记本电脑上运行呢？所以，我们正在解决的问题在某种程度上是一致的，只是领域略有不同。你可以将这些技术组合在一起，就像花生酱和巧克力那样相得益彰。因此，我们很期待与其中一些公司合作。当你缩小模型的规模，并随着模型的改进需要更少的参数和存储需求时，这些模型就能适应在笔记本电脑上运行并仍能提供良好的结果，而这时DuckDB和MotherDuck就派上了用场。
当人们构建应用程序时，有一波令人兴奋的开发者正在利用这些机会，他们想利用AI和大型语言模型带来的新可能性。当他们仍然需要访问数据时，我们通常会关注查找案例、向量查找等内容，但有时你也需要聚合数据，理解整体背景，而这需要不同类型的数据库。像DuckDB这样的数据库在构建AI支持的应用程序时非常有用，能够展示数据、生成图表等。早期的AI用例往往集中在狭窄的领域，但随着人们尝试让AI应用程序变得更加实用，越来越多的场景会需要将分析型数据库与大型语言模型、向量和嵌入结合起来。向量数据库领域已经迅速发展，现在几乎每个人都有了自己的向量数据库。

数据可视化与SQL查询的未来：与LLM和语义层的结合

Jordan Tigani：现在有pgvector，以及许多事务型数据库也增加了对向量的支持。如果你稍微模糊地看一下，为进行向量相似性搜索或向量搜索所需的计算类型，它其实更接近分析型数据库，而不是事务型数据库。当你创建事务型数据库时，形式因素非常重要，比如你需要多少内存、CPU的需求、它的突发性表现如何，以及缓存发挥的作用。而对于进行向量搜索来说，它更像是分析型数据库的任务。所以，在分析型数据库中增加向量支持比在事务型数据库中更有效。DuckDB已经支持向量搜索功能，内置了余弦相似度计算，还提供了向量搜索扩展。我们有一些客户正在将其用于分析型的RAG（检索增强生成）应用程序中。
Jennifer Li：你认为有哪些特定类型的应用程序更适合使用DuckDB的向量搜索和全文搜索功能，并构建在这个分析引擎之上？还是说我们仍然处于探索这些用例的早期阶段？
Jordan Tigani：你说得对，我们确实还处在早期阶段。在某些应用程序中，使用AI来帮助确定展示给用户的内容，并且不仅仅是查看单一结果，而是跨多个结果进行分析，会是非常有用的，但我目前还很难准确指出具体会是什么应用程序。
Jennifer Li：是的，从我们早期构建应用程序的经验中，如果有一个重要的启示，那就是当给定相关的上下文和个性化的背景时，模型的表现会好得多。我想到我的Oura Ring戒指，它根据我过去七天和上个月的睡眠数据给出建议，告诉我今晚或明晚的睡眠情况可能会如何；Strava也是类似的应用。很多此类处理实际上都是在本地完成的，同时也处理了大量的分析数据负载。所以我可以预见，不仅是面向消费者，未来还会有更多面向企业的此类应用程序出现。
Jordan Tigani：是的。这是一个很好的例子。现在我们看到上下文窗口越来越大，利用分析型查询来填充这些上下文窗口非常有帮助。
Jennifer Li：你怎么看待数据栈在围绕小数据理念的范式转变中发生的变化？过去围绕Hadoop和大数据建立了如此强大的势头和生态系统。那么上下游的参与者，像是ETL、可视化或其他工具和流程，是否也需要改变他们的思维方式？谈谈你的看法。
Jordan Tigani：如果你考虑现代数据栈，里面有摄取工具、查询工具和BI工具。摄取工具和BI工具早已属于小数据的范畴，因为数据到达的速度并不快。大多数时候，你不会每秒摄取数GB的数据，大多数摄取内容是相对独立的。我曾与George和Tristan（dbt Labs 的创始人兼CEO）讨论过这个问题。他们的世界在小数据的背景下并没有太大变化。在BI和数据可视化方面，我们本来就在处理小数据。他们将大量的工作推给查询引擎。虽然查询引擎有时会慢一点，但Looker的创新之一就是依赖于云查询引擎，这让性能相当不错。而像Power BI和Tableau这样工具，它们依赖将所有数据导入本地内存，实际上是单节点的小数据引擎，处理速度很快。
有趣的问题是，你能否在可视化方面推送更多工作负载，同时保持相同的速度？你能否将DuckDB和混合执行整合到数据可视化中，整合到展示给用户的内容中，提供更好的低延迟体验？我知道Omni在他们的前端使用了DuckDB，Hex也在使用。所以有许多初创公司正在大量使用DuckDB构建有趣的应用。一个值得关注的点是，是否会出现更多小数据专家，但我猜对于大数据的世界来说，变化可能不像查询引擎那样显著。
Jennifer Li：另一个问题是，在AI世界中，用户与数据的互动方式正在发生怎样的变化？你怎么看待使用LLM来编写SQL查询的趋势？你在日常分析中使用它吗？你认为它的未来会如何发展？
Jordan Tigani：我第一次真正意识到LLM正在改变人们使用数据的方式，是在我们不久前推出MotherDuck时。你当时提到，你在ChatGPT和我们的查询UI之间进行复制粘贴，这让我意识到这个变化的开始。
Jennifer Li：这也反映了我的SQL技能还比较初级。
Jordan Tigani：每个人都会忘记各种SQL调用的语法，这就像编程一样。有些人记住了所有的代码库，所以他们不需要自动补全、“副驾”工具，甚至不需要IDE，直接在记事本中编写代码。但对于我们其他人来说，这些工具非常有帮助。我们已经看到这些工具正在改变人们与数据的互动方式，以及他们编写SQL查询的方式。
在MotherDuck，我们做了一件事，就是专注于改善编写查询的体验。我们发现一个非常有用的做法是，当有人在运行查询时出现错误，我们会将出错的那一行输入GPT-4，让它修复错误，效果非常好。我们提供了丰富的上下文，而它实际上能够给出非常准确的答案。这样做的好处是，如果你忘记了某些语法，比如忘记了date_diff函数的参数顺序，或者你不确定是要返回小时数还是其他时间单位，你只需输入你认为是对的内容，它会自动修正并显示结果，问你“是这样吗？”你点击“是”即可。这让你能够保持编写查询的流畅性，同时享有真正的交互性，而不需要中途打断思路去查找文档、来回翻找再返回查询。
我们在这方面还有很多可以做的，比如提供更多关于模式的上下文。我觉得自动补全功能就像GitHub Copilot那样，在这些基础上继续构建会有巨大的机会。PECS已经做了很多这样的事情，比如你可以自动生成可视化。而在数据上进行可视化是非常有趣的，通常也是你想要实现的目标。这些东西如今可以相对轻松地构建。过去，如果你想实现这些功能，可能需要一个专家团队工作多年。而现在，一个对这些东西感兴趣的实习生，利用周末的时间就能搞出一些惊人的东西。千万不要低估有动力的实习生的力量。
另一个有趣的事情是，是否有一个更进一步的世界，不只是帮助你编写查询，而是让你可以直接用自然语言编写内容？已经有很多很棒的演示展示了如何用英文编写查询，然后将其转换为SQL。超越这些演示是有难度的，因为在典型的分析中有太多内容是特定于某个组织或数据布局的。例如，如果我说：“上个季度按地区和销售代表划分的收入是多少？”那么“地区”和“季度”可能会根据不同组织有不同的定义。“收入”更是一个复杂的概念，因为可能涉及到未注册用户的数据，或者涉及货币转换问题。此外，可能三个月前的数据中还有个错误需要修正。回答这些看似简单的问题，实际上可能非常复杂。
因此，我对在一般场景中应用这类技术并不抱太大希望，但在某些特定情况下，尤其是在应用程序开发中，这确实可能会有用。我们有一些客户已经在这样做了，他们正在构建应用程序。因为他们的每个用户使用的模式几乎是相同的，数据结构非常简单干净，并且每个字段都有详细的元数据，因此在将英语文本转换为SQL时能够获得不错的结果。
这个领域很有前途。对我来说，另一个有前途的方向是通过某种语义层进行处理。语义层一直以来都让我觉得很有趣，通过语义层你可以做出非常酷的东西。语义层基本上定义了什么是收入、什么是季度，并且定义了你的数据模型如何互操作。有了这些，当你做文本到SQL的转换时，或者进行更复杂的操作时，会更加得心应手，因为你只需将自然语言映射到模型中的内容，而不是物理数据库中的描述。

AI在数据分析中的变革作用

Jennifer Li：听起来你认为AI分析师暂时还不会取代真正的数据分析师。在数据集非常干净、并且有语义层的情况下，可能会有更多的自动化实现。但要让AI分析师在广泛的情况下解析数据并给出准确结果，我们还有很长的路要走。
Jordan Tigani：是的，我目前还不是一个AI的极端支持者。AI可以做一些非常酷、非常惊人的事情，但它仍然有一些局限性。不过，很多过去认为AI有限的人后来都被证明是错的，所以我们还是拭目以待吧。
Derrick Harris：我们已经讨论了十多年如何尝试取代数据分析师或使这项技能更加民主化，但似乎进展不大，所以也许你是对的。Copilot也是类似的情况，正如程序员们所说的那样，它是一个非常好的增强工具，但你仍然需要知道自己在做什么，了解你实际在构建什么，或者在这种情况下，了解你正在处理的数据。
Jordan Tigani：是的，我觉得在Copilot方面，有些人认为编码更像是写作，或者像是一种意识流的过程，你只需要不停地写，然后可能测试一下就完成了。但大多数软件工程更像是编辑的过程，你在这里添加一些关键短语，在那里添加一些重要的部分，然后将它们连接并转换。AI或许会在这方面变得擅长，但它离真正胜任这些任务还有很长的路要走，而这正是工程师们大部分时间都在做的事情。
Derrick Harris：是的，我还记得，数据科学曾经一度非常流行，至少作为一个术语，被认为是世界上最性感的工作之一。然而，当你与那些拥有这个头衔的人交谈时，他们会说：“我大部分时间都在处理和准备数据。”我们在这方面有进展吗？这是AI可能真正帮助数据处理和数据科学工作流程的一个领域吗？比如在程序化清理数据的意义上？
Jordan Tigani：绝对是这样。我之前提到过DuckDB的CSV解析器，虽然这个例子并没有实际应用AI，但我猜测，AI被应用于推断结构不良数据（例如CSV文件）的模式，并解决其中的问题，这将是一个非常有趣的研究方向。毕竟，有许多启发式方法最终会被用上。但我也认为，这正是为什么数据科学家们喜欢使用DuckDB的原因之一，因为它帮他们减少了大量繁琐的工作。当然，这并不意味着AI无法让这一过程变得更好。
Derrick Harris：好了，我想大家会觉得这次对话既有趣又富有洞察力。
原文：AI, SQL, and the End of Big Data
https://a16z.com/podcast/ai-sql-and-the-end-of-big-data/
编译：Yudan Mao
-----------END-----------
🚀 我们正在招募新一期的实习生
Image
🚀 我们正在寻找有创造力的00后创业者
Image
Image
Image
关于Z Potentials
Image

KEEP THE THREAD GOING

更多来源文章