We're sunsetting PodQuest on 2025-07-28. Thank you for your support!
Export Podcast Subscriptions
cover of episode AI Data Engineers - Data Engineering After AI // Vikram Chennai // #309

AI Data Engineers - Data Engineering After AI // Vikram Chennai // #309

2025/4/25
logo of podcast MLOps.community

MLOps.community

AI Deep Dive AI Chapters Transcript
People
V
Vikram
Topics
Vikram: 我是Ardent AI的创始人兼CEO,我们正在构建AI数据工程师,这是一种利用LLM技术来简化数据工程流程的AI代理。数据工程师是这项技术的最佳用户,因为他们能够理解并利用AI工具来提高效率。AI数据工程师可以连接到你的数据栈,并通过自然语言指令执行各种数据工程任务,例如构建数据管道、进行模式迁移等。它可以自动完成许多繁琐的工作,例如查找API端点、编写代码、将其推送到GitHub仓库并创建拉取请求。它还可以访问并理解各种数据库的模式,从而在构建管道时做出更明智的决策。为了应对复杂数据系统带来的挑战,我们专注于特定领域、上下文和结果的专业训练,并通过创建轻量级且短暂的暂存环境来提高准确性。我们还创建了一个基准来评估AI数据工程师的性能,并通过数据质量检查和其他测试来验证其结果。为了解决上下文不足的问题,我们添加了一个检查步骤来判断任务的可行性,并在任务不可能完成时发出警告。我们还将大型任务分解成较小的任务,以提高可靠性和准确性,并允许用户更好地控制流程。我们利用GitHub仓库和数据库上下文来提供必要的背景信息,并使用检索增强生成技术来去除不必要的上下文信息。我们还允许用户附加文档作为上下文信息,以帮助AI数据工程师理解公司内部的特定术语和流程。我们的定价模式是基于订阅费和信用额度分配的,以满足不同客户的需求。AI数据工程师的计算资源消耗包括运行代码和与各种服务交互所需的计算资源。我们已经看到AI数据工程师成功地完成了跨多个服务的复杂数据处理任务,例如使用Airflow作为编排器并调用Databricks进行Spark代码执行。这表明我们的技术具有很大的潜力。 Demetrios: 作为主持人,我与Vikram讨论了AI数据工程师的构建过程、面临的挑战以及未来的发展方向。我们探讨了AI数据工程师的概念、功能以及如何与现有的数据工程工具和流程集成。我们还讨论了如何处理复杂的数据系统、如何进行评估和验证,以及如何确保AI数据工程师能够在各种场景下可靠地工作。此外,我们还探讨了定价策略、计算资源的分配以及如何平衡AI的自动化能力和人工干预的必要性。通过与Vikram的对话,我们深入了解了AI数据工程师的优势和局限性,以及它如何帮助数据工程师提高效率和解决实际问题。

Deep Dive

Chapters
Vikram Chennai, founder of Ardent AI, introduces AI Data Engineers, AI agents performing data engineering tasks. They integrate with existing stacks (like Airflow and GitHub) to build pipelines, handle schema migrations, and automate tasks usually done manually by data engineers. The AI agent interacts via a terminal, understanding API outputs and database schemas to build and push pipelines as PRs.
  • Introduction of AI Data Engineers as AI agents for data engineering tasks.
  • Integration with existing data engineering stacks (Airflow, GitHub).
  • Automation of pipeline building, schema migrations, and other tasks.
  • Agent interaction via a terminal interface.

Shownotes Transcript

我的名字是维克拉姆。我正在创建Ardent AI。我是创始人兼首席执行官,我喜欢喝拿铁。欢迎回到MLOps社区播客。我是你的主持人德米特里奥斯,今天我的朋友维克拉姆正在做一些疯狂的事情,将大型语言模型带入数据工程管道的用例。我喜欢这个,因为它融合了这两个世界,并且希望……

为那些你认识的、总是处于压力之下的数据工程师节省一些时间。让我们和他谈谈他是如何做到的,以及在构建他的产品过程中遇到了哪些挑战。和往常一样,如果你喜欢这一集,请与朋友分享。或者,如果你真的想做一些有帮助的事情,请留下评论。在Spotify上给我们一些星级评价。即使不是五星也没关系,四星我也很满意。

但你也可以在Spotify本身发表评论,这会触发算法,给我们带来更多互动。让我们开始这段对话吧。但在开始之前,如果你是在Spotify或其他播客播放器上收听节目的朋友们,我有一个惊喜要送给你。下一个音乐推荐来自……

一位刚刚加入社区并告诉我科斯莫·谢尔德雷克的人。我以前从未听说过他,现在我爱上他了。传说苔藓生长在树的北侧。传说当雨水落下时,所有的蠕虫都会上来呼吸。传说当阳光照射时,所有的植物都会用它们的叶子与阳光同在。

好吧,我们不要说世界绕着23度的轴自转。但你有没有想过我们是植物里的兔子?它快速地向上攀登山脉,同时匆忙地演奏着曲调。办公室想做什么?你知道,我喜欢很多东西,但很多东西都来自那个住在鞋子里面的老妇人。那个晚上用手唱歌的女孩,她吃了他的汤。

顺便问一下,你在哪里?你现在在旧金山吗?嗯哼。在旧金山。你一直在参加聚会吗?嗯,不是……

太多嗯,我实际上六个月前才搬到这里,所以我开始在一些联合办公空间工作,然后逐渐融入社区,所以现在聚会少了。我刚来的时候参加了很多黑客马拉松,这是一个结识人们的好地方,但之后一旦你有了,你知道,一群人,那么你认识的人就会自然而然地扩展,就不需要再自己出去结识人了,更多的是他们只是

进入轨道。进入轨道。我喜欢。我一直在想,你与哪些人交谈,将他们视为你的产品的用户?对我们来说,数据工程师是主要用户。

这可能看起来有点违反直觉,特别是考虑到我们正在构建AI数据工程师。但我们发现,数据工程师确实是那些了解如何在他们的技术栈中完成工作的人。他们知道使用哪个管道工具,知道哪些小事情可能会出错。因此,当他们能够控制一个可以为他们进行数据工程的工具时,那么他们

就能更快地完成更多工作。到目前为止,他们一直是我们最好的用户。我们看到他们做出了令人难以置信的事情。所以我想看看你创建的东西的内部结构。但你刚才略过了某些内容,我们需要深入探讨。什么是AI数据工程师?

是的,它是一个连接到你的技术栈的AI代理,可以执行数据工程任务,例如构建管道或使用句子进行模式迁移。它与Devin非常相似,只是我们垂直化并只专注于数据工程。

并真正与该技术栈深度集成。例如,你设置了带有GitHub的Airflow,这就是你控制数据管道代码的方式,并且你想构建一个新的数据管道。通常情况下,你必须克隆该仓库,找到你存储DAG(有向无环图)、你的

数据管道的位置,然后编写所有代码,然后检查数据库,然后确定要编写的内容,以及所有内容的结构、模式和所有映射。或者,如果你从API端点调用,你必须了解该端点将输出什么。

所以你必须完成所有这些工作,然后才能推送管道并测试它是否有效。对我们来说,我们的代理有一个终端,因此它连接了一台计算机,它可以为你完成所有这些工作。你只需要告诉它,嘿,我想要一个执行此操作的管道。它会查看网络,查看该API端点,弄清楚,哦,这个东西是如何输出的,然后为你构建整个管道,将其推送到你的GitHub仓库,并

作为一个PR。因此,你无需执行任何工作。你只需要说,嘿,去做这件事。它会为你完成。这主要与数据管道有关。是的。你是否还在数据库中做一些事情,例如尝试查询数据库的乐趣?或者只是你正在转换,或者你正在做,你见过它变得多么复杂?

是的,我们有数据库的上下文。因此,当我们的用户设置好后,

他们会使用任何管道服务进行设置。如果是Airflow,如果是Dagster或Prevector,无论他们使用什么。但是你也可以访问所有数据库的上下文。因此,你可以连接Postgres、Snowflake、Databricks SQL、MongoDB或你使用的任何数据库。因此,我们的代理实际上具有关于其外观的上下文。

它允许你,我们专门关注管道,但是当它编写代码时,它就会知道模式。如果你想将数据放入某个表中,它不会尝试猜测或创建新表。它知道你已经拥有这三个表。将新信息放入表一是最有意义的。这就是我们将如何转换它来做到这一点。我听到很多人谈论的一件事是这种

使用AI进行编码,或者我敢说氛围编码,在事情很简单的时候非常有用。但是一旦事情变得非常复杂,它就会失效。当你在企业级别并且查看一个可以追溯到20年前的技术栈时,让……

AI真正能够在编码和代码生成方面提供帮助变得非常非常困难。你是否也看到过类似的情况,如果你试图进行一、二、三步管道,它在这方面做得很好。但是一旦你开始引入这个非常混乱的数据系统,

来自各处,并且在转换10次之前,或者你要求它转换10次才能获得你想要的确切数据,它就会失效。

当然,我们也看到了一些这种情况。但我认为我们尝试解决这个问题的两种主要方法,我认为这也是一个普遍的原则。一个是管理上下文。例如,我们与几家公司(一些企业公司)交谈,他们拥有大约15000个管道。

现在,显然,你无法将所有这些都输入上下文窗口。不可能。首先,上下文窗口无法扩展到这种程度。其次,即使它可以,它也会对你的请求感到非常困惑。因此,生成真正真正好的上下文是一个很大的部分,这几乎是试图简化代理的问题。所以这是你试图做的事情的很大一部分。我认为另一部分是特定训练。

对于更通用的编码代理,我认为他们面临的一个问题是,它们并非为特定任务流程而设计。他们试图一次做所有事情。因此,由于语言模型的工作方式,它们是概率引擎。因此,如果你的概率分布实际上是所有内容,那么你将难以完成特定的事情。但是,如果你围绕特定垂直领域、特定上下文和特定结果设计产品……

那么你将获得更高质量的结果。但我认为,像氛围编码和在大规模出现错误的问题实际上永远不会消失。

但我认为这就是你必须构建专门的基础设施以确保能够解决这些问题的地方。因此,我们现在在我们下一个版本中正在探索的是为他们默认连接的所有内容创建暂存环境,并尝试使它们非常轻量级且短暂。假设你对数据库进行了更改。

它不会直接进入你连接的任何数据库,假设你可能没有暂存环境,或者如果你有暂存环境,它只会说,这是我们将要进行的更改。这就是它的样子。但这同时也允许代理进行反思,并说,嘿,这就是系统将如何改变。这是正确的吗?因此,即使它在第一次或第二次或第三次或任何时候,甚至10次都搞砸了,

它也不会提交到你的实际代码库或数据库或任何其他地方。它有能力反思这一点。因此,它可以自我纠正。并且在许多不同试验中的准确性会大大提高。哇。好的。现在,你是否还创建了某种评估反馈循环,以便了解哪些是成功的,哪些是不成功的?嗯哼。

我们实际上创建了一个基准,因为数据工程方面确实不存在一个好的基准。好吧,我甚至要说它可能必须是

个案基础上的?或者你发现它可以用更通用的数据管道评估基准来进行?是的,我认为它实际上可以更通用,但我认为这正是由于数据工程的工作方式。它并不完全通用。这是因为人们使用的工具非常标准。例如,他们使用Airflow、Prefect、Dagster、Databricks或其他工具。你可以实际说出所有流行工具的名称,并且

由于数据对公司非常重要,人们不太可能使用某种未知的工具,而这种工具没有人真正进行过测试。因为如果你在数据库中出现错误,并且由于某种原因,他们,你知道,编写代码非常糟糕,并且它删除了所有内容,那么你就完蛋了。你永远不会冒这个险。

因此,人们总是,你知道,倾向于使用标准。这为我们能够进行测试创造了一个很好的框架,我们可以说,只要它能够很好地操作这些工具,我们就会给它数百甚至数千个任务来进行优化,并且它正在变得越来越好,那么我们非常有信心,大多数人都会从中受益。好的。你提到了暂存,对吧?

环境允许代理几乎可以预见如果我们进行了第一个代理推荐的操作会发生什么,这几乎就像以某种方式看到未来,然后反思这是否是正确的举动

你能多谈谈你有哪些类型的验证检查吗?这完全是通过代理进行的吗?还是其中也涉及一些确定性?它主要通过代理本身进行。

但我们也可以引入你正在运行的数据质量检查和其他测试。我们的目标是尽可能多地复制你的实际环境。因此,它编写一个管道,然后运行任何测试(如果你有的话),我们将把它们引入。代理本身将能够查看错误日志和所有这些内容,以了解,嘿,我的代码语法是否错误或是否出现幻觉?或者输出是否符合预期?

它将所有这些都考虑在内,然后它就可以循环直到它把事情做好。这真的很酷。很多时候,人们谈论到与代理互动时很难做到正确。这……

如果代理没有足够的上下文,它询问问题的能力,你如何解决这个问题,因为我可以说,是的,为我设置一个Airflow管道并使用我的数据库,代理可能会去设置一个带有随机数据库的随机Airflow管道,并说这就是你要求的,或者当它没有正确的上下文和正确的想法时,它可能会产生幻觉,所以

你在做什么来确保代理在第一时间没有足够的资料就不会开始工作?是的。因此,我们实际上在我们任务流程中添加的内容,实际上专门针对的是任务是否可行。我们的一个测试用例,一个非常简单的用例是,我们不会向它提供Postgres凭据。

我们只会告诉它,在Postgres中构建一些东西,例如添加此表并查看它会做什么。一开始,它就像你说的那样尝试去做。我们,你知道,基本上训练了这种行为。因此,我们在其规划阶段添加了一个检查步骤,它将尝试确定任务是可能的还是不可能的。因此,我们只是试图训练这种行为,它会告诉你这是不可能的。你可能不应该这样做。这是另一个LLM调用吗?

它是原始调用的一部分。我们设置的流程是,你发出请求,代理将收集上下文、搜索网络,所有这些内容,它会给你一个计划,例如,这就是我将要做的。你同意吗?你可以来回进行编辑。因此,如果它犯了错误,这就是你详细查看它将要执行的所有内容并说该步骤错误或该步骤错误的机会。或者实际上我想要这个表或类似的东西。然后

让它自己继续。但在那个阶段,有一个检查试图说,这是否不可能?如果是,那么它会说,请修改一下。是的。你是如何看待非常大的任务与尝试分解任务并使它们更小?当你设计你的代理时,

试图理想地拥有更小的任务,以便你拥有更高的可靠性?我认为分解任务绝对是可行的。我只是认为你无法从更大的任务中获得足够的信息,并且在我们规划步骤中将其分解。因此,它不会只说,嘿,我将为你构建一个管道。它会说,这是我将要执行的步骤。这是对的吗?

它允许对你要执行的操作进行更细粒度的控制。是的,你可以从中获得更高的准确性。但它也有助于用户端,因为他们可以准确地看到正在进行的哪些小步骤。因此,他们也有控制权。因此,特别是如果我们的用户是数据工程师,他们非常了解需要做什么。因此,他们可以真正进行编辑,例如,嘿,步骤三是错误的,或者有点偏离,或者你推断出了错误的表,对吧?

让我们纠正一下。因此,它不会将所有责任都放在代理身上,至少现在还没有。总会有少许不匹配,对吧?因为你不可能将所有东西完美地复制到你的大脑中,然后将其转储到上下文中。你是否也使用组织的GitHub仓库作为上下文来帮助创建不同的管道?是的。

因此,人们倾向于存储管道的主要方式是通过某种版本控制软件,这通常是GitHub。因此,是的,代理将连接进来,扫描并理解该仓库,查找重要的特定文件夹,例如,如果你有一个DAGs文件夹,这是Airflow对数据管道的名称,以及其中的所有文件。因此,它会知道这是我编写管道代码或从中提取代码的地方。

但你并没有专门尝试将其中的所有内容向量化。你只是按字面意思接受它。你不需要通过说,好吧,让我们向量化我们拥有的所有内容来使事情过于复杂。让我们把它扔进一个向量数据库中。然后希望它能给我们更好的检索。而且它也会知道……

在语义上更好地理解所提出的问题,这些实际上都不重要,你是在谈论代码吗?

是的,或者你作为上下文提供给它的任何内容。因此,我们实际上确实进行了一些RAG(检索增强生成)和检索。我们进行此操作的主要地方几乎是在所有上下文层。如果你询问Postgres和MongoDB,我们将要做的是尝试尽可能多地去除不必要的上下文。因此,这实际上更少的是提供正确上下文的问题,

至少对于数据工程代理或我认为通常的编码代理来说,你要做的是尽可能多地提供,因为我们有可实现结果的策略。

因此,如果你不提供数据库凭据,我不提供我的Postgres凭据,那么在任何可以想象的宇宙中,你都无法进入该数据库并了解其中的内容。因此,我们试图做的是只提供足够的信息,但删除所有不必要的信息。例如,如果它进行检索搜索并说,好的,我们不需要Databricks,我们不需要所有这些其他内容,但我们提供足够的信息,以便如果它确实需要Databricks,

那么它就可以开始提取该上下文或将其作为规划步骤的一部分,嘿,我需要提取这个东西,我需要提取那个东西,那么它仍然可以做到。因此,我们在顶部添加了一个搜索层,但这更多是为了去除不必要的信息,例如你认为的15000个管道。是的。不可能,对吧?因此,你确实需要索引所有这些内容,并了解对于用户查询要提取哪些内容以及不要提取哪些内容。因此,如果我理解正确的话,这更多的是关于

我如何告诉代理在提出特定问题时在哪里查找?我在上下文中拥有该信息,它知道,哦,酷,Airflow。我去这个区域查看,然后它会给我更多关于如何处理Airflow的信息。

是的,完全正确。因此,它是一种混合方式,它将直接提取内容。对于管道和代码,我们确实对其进行了索引,以便它可以提取,好的,管道三,它看起来像这样。这是所有代码,去编辑该代码。这就是它在GitHub中存储的方式。去做吧。但是假设它想要的信息是我们从向量搜索中决定不相关的信息。我们仍然有足够的信息,然后它就可以找到它自己的方法。

我明白了。因此,以防万一它稍后出现,那么它就不会像,什么是Databricks?是的,完全正确。在这种情况下,你有点麻烦。这非常有意义。现在,我们大约两个月前与一个正在创建数据分析师代理的团队谈论过一件事,他们确保……

数据分析师代理直接连接到不同的数据库。如果代理用于营销,则只为特定营销数据库及其在类似封闭花园中进行的所有分析提供范围。你是否看到这种方法有效,或者它有什么不同?是的。

我认为对于某些公司来说,这是有意义的,特别是对于大型企业来说,我认为这很可能与安全有关。如果按照我的方式,并且我可以访问我想要的所有内容,我会说,好的,给我尽可能多的上下文。我会索引你拥有的所有内容。

嗯,你知道,我在其之上设计了一些自定义嵌入,这是我们为确保其在所有方面都非常准确而做的一些事情。嗯,我认为这里存在一种权衡,我认为更多的上下文通常更好。

实际上,在这种情况下。但同样,你希望保持它相当精简,对吧?例如,你不需要关于所有内容的所有内容。你只需要关于所有内容的足够信息,特别是如果你有某种跨上下文流程。现在对于管道来说,它类似于某种调用结构,其中你拥有

一个管道将触发数据处理服务来完成所有繁重的工作。因此,你不会在你的Airflow实例中处理数百万或数十亿行数据,这会爆炸,例如你将其放在Databricks或其他地方。因此,你需要该上下文,对吧?因此,在企业规模下,将其隔离是有意义的。它也可能会改进代理。但我倾向于

引入大量上下文并保持这种理解,以便当你拥有那些窥视的流程时,你知道在错误的地方或使用错误的工具处理数据会发生什么,这会导致某些东西爆炸或事后变得非常昂贵

你是否设置了警报,或者你是否有某种方法来估计?正如你所说,我们有那个暂存环境。我们可以估计这是否有效,这是一个向量。但我认为另一个向量是这将花费多少?是的。我们实际上发现,特别是对于现有客户来说,他们实际上知道他们的成本是多少。

因为很多时候工作不是,我不知道我在做什么。告诉我如何做得更好。这是我知道我需要做什么,但我希望有十个我。例如,我只是不想花这么长时间。是的,是的。这很麻烦。这项工作非常麻烦。完全正确。因此,他们将这项工作提供给我们的代理。例如,嘿,这个管道需要10分钟,它需要1分钟。我现在知道如何做到这一点。

但我真的不想这样做。那么这个东西可以自动扩展管道吗?好的,酷。它会这样做。他们可以向它提供如何执行此操作的具体说明。因此,我们还没有看到这种情况。但是是的,你将能够从暂存环境中提取这些内容。我们正在考虑未来要做的事情是

你知道,能够在这样的级别上进行自动优化,例如,嘿,如果你只是这样更改所有内容,我们可以为你节省20% 的账单。我们的代理知道你的成本是如何设置的,所有这些内容。我一直在考虑的另一件事是,你主要通过Slack与代理互动,还是通过Web GUI?是什么?所以它主要是通过网络应用程序。

他们可以,是的,他们可以将任何更改推送到代理。它只是一个聊天界面。然后我们有了终端样式。因此,你可以看到它在执行操作时正在做什么。然后你有很多选项,你想让它更像副驾驶还是全代理,诸如此类。因此,你看到大多数交互都是通过那里进行的。但我们也构建了SDK和API。

因此,你实际上可以将代理反应式地构建到你的流程中。例如,一个很好的例子是,凌晨3点,你的数据管道失败了,你不想为此起床,因为这太荒谬了。因此,与其不得不醒来,然后找出哪里出了问题并编写更多代码,或者如果它真的很简单,只需重新启动管道。例如,你为什么要在凌晨3点这样做?我想睡觉。

你可以直接将代码放入你的错误处理程序或其他内容中,它会自动触发代理运行,你可以输入你想要的任何文本。因此,它与你在Web UI中执行的操作相同,但现在你可以在代码中执行此操作。这允许这些流程成为,嘿,凌晨3点出现错误,代理在你仍然试图起床并摆脱睡意时已经运行了。它正在执行所有工作,并且它说,嘿,

我找到了解决方案。这是它。例如,这是一个更改的PR,你知道,正在发生什么错误。或者你只需要重新启动管道。我已经准备好这样做。你想这样做吗?只需说“是”或“否”。因此,它实际上并没有完全自主,就像你之前所说的那样。你正在努力达到这一点。但在目前,它仍然需要来自某种用户的干预或绿灯。是的。

是的,老实说,我不知道我们是否会达到完全自主。这主要是因为,例如,即使你将其置于这样的角色中,好的,我们正在招聘一名初级开发人员,你真的会希望他们像这样推送到生产环境吗?没关系,推送到生产环境,就这样吧?在某些情况下,没问题,是的,你可能想要这样做,对吧?但是,你知道,你可能有一些比最初的更改更大的重大更改,你并不真正希望这些更改被推送。所以

我认为让人们保留控制权非常重要,特别是对于代理来说,它们处于这样的状态。我认为我们已经达到了它们有用的程度,但它们远非完美。因此,在我看来,仅仅说,为我做所有事情,我只是闭上眼睛让你做所有事情,这并不是一个好主意。是的,这个想法……

代理的认知负荷,如果最终它们帮助你减轻一定的认知负荷,那么这太棒了,我认为更好的问题可能是关于认知负荷以及你如何看待不增加最终用户的额外负担,因为很多时候我们可能都感受过,我们与AI的互动

并不好。我们从中得到的结论是,如果我自己做的话,那会更快。是的。我认为在这种情况下,我们能做的最好的事情就是

让产品更好。更好地训练它。在各种场景中提高其准确性。我认为构建面向工作流程的产品的另一个好处是,您可以从客户那里获得大量反馈。因此,当某些事情对他们造成影响时,您会得到一个跟踪,例如,以下是步骤,以及在此过程中发生故障的所有内容。因此,随着越来越多的人使用它,您可以为每个人做得更好,因为现在您只需……

您知道,它从数千个增加到数十万个,再到数百万个流程涌入,好的,发生了这种情况,这是评估结果。是或否。是或否。您可以用它来改进它。因此,我认为最好的方法是让它变得更好。然后,您知道,构建这些暂存位和上下文位,允许代理实际完成良好的工作。

因为我认为这是唯一真正的解决方案,对吧?就像您可以用创可贴来修复它,并说,它不会影响任何真实的东西。但真正重要的是您希望它能做好工作。这就是您购买它的原因。这就是您使用任何这些工具的原因。所以我认为这是唯一真正的解决方案。代理采取的建议或行动领域很明确是有益的。

评估指标。它有效,它运行,例如数据正在流动或没有流动。对于其他代理任务,我认为我从一些非常优秀的人那里听到的是,您越接近运行/不运行,对代理来说就越好,因为您可以清楚地判断它是否成功。

我完全同意这一点。这实际上是我们进行训练的一部分,就像基准训练集,无论您想称之为什幺。所以它就像一个评估和训练集。我们确实有确定性的结果。我们从非常简单的事情开始,例如训练。

只是测试代理是否理解数据库,对吧?例如,将某些内容放入数据库中,将姓名和年龄作为记录添加到我们的 Postgres 数据库中。非常简单,去做吧。或者创建此表。然后您验证,这些东西实际上是否存在?它们在那里吗?您在其之上添加诸如花费多长时间之类的层。然后您将所有这些都拉回。因此,当您进行优化时,您不仅仅是在优化

最简单的,例如,也许是一个 llm 来评估代码是否正确,是否存在错误,就像我们实际上看到数据最终到达它需要去的地方,我们看到了花费多长时间,我们看到了实际查询运行的速度,例如这太慢了,这太快了,尤其是在您训练时,这非常有用的反馈,是的,我们有我的朋友 Willem 在这里,大概

我不知道什幺时候,几个月前。他谈到他们正在做非常相似的事情,但对于 SRE 和根本原因分析问题以及分类问题。他们使用正在发生的 Slack 消息设置了一个知识图谱。他们还用代码设置了它,我认为他们还用 JIRA 设置了它,以便您可以更全面地了解

当某个产品出现问题时,这很有意义。我想知道您是否考虑过尝试做类似的事情,或者您是否认为您获得代理上下文窗口中所需上下文的方式和能力现在已经足够了,您是如何做到这一点的。我认为现在,我们关注的是所有

这就是它需要工作的东西。因此,所有编码部分,例如,提取 GitHub,提取数据库上下文,这就是它的工作原理。我认为下一级,以及这里的所有 Slack 和 JIRA 等等,只是,它会变得更好。因为本质上,人们现在正在做的是将已经存在的上下文放入他们的脑海中,然后将其放入提示中。

因此,人们正在自己进行转移,但这可能是我们正在考虑的事情。所以,嗯,

一些客户要求附加文档,他们可以在其中放入文档,因为他们显然已将所有联系人和所有实践存储在一个巨大的文档中。我们听说过很多人这样做,他们说,这是我们编写所有内容的母版文档。我认为他们将其用于培训新员工的组合,但也只是一个文档。就像我们公司就是这样做的,尤其是在数据工程方面。因此,他们希望能够将其附加为永久性功能。

固定装置,例如,这就是您应该执行所有操作的方式。因此,我们已经走了一段路了,但我绝对认为这是尝试提取更多内容的正确方法。再次,您会遇到上下文平衡问题。但我认为如果做得正确,并且做得很好,那么黄金标准是,如果做得完美,那么您获得的收益将远远超过您可能损失的任何东西。

说到文档附件,这不是我第一次听到它。它在稍微不同的场景中,但整个想法是如何创建一个某种词汇表?

让代理在谈论我们公司特有的术语时或当我们希望以公司的方式完成事情时理解我们,因为也许每个公司的做法都不同,或者当我们说我需要从数据库中获取 MQL 时我们的意思是什么。什幺是 MQL?它不一定是列中标记为 MQL。所以或者说它不是

清晰明了的事情,代理需要知道如何创建该 SQL 语句来弄清楚什幺是 MQL,或者他们需要理解这实际上意味着什幺以及它与哪个列相关。不,我完全同意这一点。实际上,我认为我们的核心原则之一是我们不会让您迁移任何东西。因此,这不仅仅是关于数据库或

代码级别的东西。就像,我们希望以您的方式工作。我们不想告诉您如何做事。我认为在整个 AI 热潮之前,尤其是在过去,有一些产品试图为您做出决定,因为存在真正的权衡。他们说,这是一个更好的方法,您将节省大量时间。但现在我们处于这样一个位置,

您知道,也许切换会更容易一些,或者您可以拥有跨上下文工具。但仍然,迁移,改变您的做事方式,就像您可以要求别人做的最糟糕的事情。在我看来,如果您说,嘿,切换您的数据库,他们会看着您,您疯了吗?就像您的 AI 很好,但我们不会为了它而切换我们的数据库。就像,请离开。因此,我们非常发现,是的,以人们的方式工作就像

这就是你如何做的。这就是你正确地做的方式。您基本上允许他们,即使您试图稍微改进它,您也会说,好吧,您正在这样做,您可以通过这种轻微的方式做得更好。但这并不意味着我们会介入并告诉您该怎幺做。实际上,您必须,您知道,拆除您的管道服务并使用我们用 AI 构建的自定义管道工具。就像,不,只使用您的东西。这件事会解决你的问题。嗯哼。

顺着这个思路,您是否有像常见的请求或常见的模式、代理的常见请求那样,您已经将其编纂并弄清楚,好的,此管道有效。

每天或每小时被请求两次。因此,也许我们可以将其变成一键式点击,而不是每次都必须有人提示。嗯,我们没有直接看到很多这样的情况。

实际上,我认为这与我们追求的理念有点不同。因为通常对于管道来说,它们只设置一次,然后进行管理。因此,很少像反复重新创建它那样,而更多的是我们已经创建了它,现在我们必须确保它不会中断,并确保其他所有东西也不会同时中断。所以很多。然后我认为我们的很多方法也是

LLM 擅长的是不确定性和解决各种各样的问题。因此,即使我们在其中看到一种模式,这可能更容易作为一键式操作,

我认为这实际上不是添加到代理的好做法,因为您试图自己指导它而不是在数据上进行训练。因此,应该发生的是,如果您看到这种情况经常发生并且您不断将其添加为训练反馈,它应该会变得非常擅长。因此,他们可能必须提示并请求它,尽管通常他们不会要求六次重新创建管道。嗯,

但它会变得擅长这些类型的任务。对。或者,如果您愿意,您可以只使用 API。如果您真的想连续六次重新创建管道,您有一个 API,您有一个 SDK,只需编写一个 for 循环,它就会连续执行六次。我正在考虑 Uber 提示工程工具包,因为我们上周刚刚就 AI 在生产中的剧集进行了讨论。

我们所做的会议,他们谈到他们将如何呈现好的提示或所谓的好的提示,例如人们可以创建提示模板,我们可以说,所以也许这与被询问的内容并不完全相同,但它是

您已经准备好提示的精华部分。您单击它,然后它就在那里,您可以更改一些内容或将其推断出来。我还考虑了我们与 Linus Lee 进行的另一次谈话,他曾在 Notion 工作,他的整个事情都与 Notion AI 相关,我们只希望您能够单击并通过单击完成您需要完成的工作,并且

无需承担试图弄清楚我究竟需要什幺的认知负担。因为至少在 Notion 中有六件事,而且我明白这对您来说是一个完全不同的场景。当它在 Notion 中时,您可能想详细说明某些内容,您想总结一下,您想写得更好,清理语法。因此,他们只需点击几下即可为您提供这种类型的 AI 功能。

我认为我们的版本可能是特定于用户的提示建议或聊天建议。因此,如果您经常请求管道或使用 XYZ 管道,那么它将能够从中学习并为您提供类似于 Google 或任何服务的搜索建议。它会说,嘿,您是否考虑过询问这个或那个或那个?然后,你知道,就这样。这可能是我们最好的版本。是的。

但这肯定会有所帮助,你知道,人们不必六次请求同一件事。是的,就像六次一样。它会开始学习。就像,也许您确实想谈论管道,因为这就是您一直在谈论的内容。简单的人类。你在做什么?

不,跟我谈谈定价,因为我知道这对于这个领域的创始人来说可能很麻烦。具体来说,因为像传统的基于席位的定价方式那样,对于公司来说可能真的没有用或没有利润。如果一切都基于使用情况定价,那么您就会冒这样的风险,

最终用户在使用产品之前会三思而后行。就像,哦,如果这要花我 1 美元或 2 美元,也许我应该自己动手。我的意思是,希望人们对时间的重视程度远高于 2 美元。但我知道我曾身处这种情况,我想,我现在想花 2 美元吗?我不知道。那么您如何看待定价?您目前是如何做的?你认为像

正如您从客户那里了解到的和与客户交谈一样。因此,通常当我们与新客户签约时,通常是我们给予他们的固定订阅费。所以,我们通常会评估他们的需求。然后,我们基本上会想出一个,你知道,我们有一个规模,这里有多少积分是,你知道,任何美元金额。

然后我们通常会根据此向他们提供订阅,尤其是因为,你知道,他们通常想要构建新的管道或维护现有的管道。因此,他们希望消除这种工作。

积分就像代币或积分是……

像花钱一样,这些是你的,请把它降到零,你知道,如果你想要更多,那么我们会在其之上提供一种代币基础,所以就像,嘿,你已经用完了这个月的所有积分,如果你想续费,请将比特币发送到这个钱包地址,然后好,是的,不,是的,不完全是比特币,没有那么远,但是是的

哦,是的,虽然这不会很好,我想,哦,这太搞笑了,但是,嗯,这说得通,这是我见过的定价模式之一,因为它会帮助人们,所以您在查看他们的数据管道有多糟糕或有多少时,您正在

给他们更大的配额,或者认为他们将使用更大的配额。因此,您将给予他们的估计值大于只有一个数据工程师需要运行几个管道的估计值。没错。我们的主要目标,就像我们在这些电话中一样,不是说,你知道,这并不是说你有三个席位,就像,好的,你的问题是什么?我们如何解决它?

对。并且确保您拥有实际完成工作的资源分配。我们不希望的是有人进来并说,好吧,好的,我们,你知道,让我们说我们有不同的 100 个积分,它并没有真正做到这一点。就像,是的,那是因为您要求的任务不适合该确切场景。就像我们没有。

一切都没有为您可以按照自己想要的方式做到这一点而正确设置。或者我们已经设置了一个每三天运行一次并进行数据质量检查或只是检查新更改和内容的运行。并且,你知道,代理是否有什么问题?无论您希望代理执行什幺操作,对吧?我们已在 SDK 中对其进行了设置,并且它停止运行了。就像,好吧,是的,因为那不是您的实际需求。所以我认为这在客户方面有很多帮助,他们只需要担心完成工作。

就是这样。这是您唯一需要考虑的事情。然后,随着事情开始扩展,您就会说,好吧,您可以重新获得积分,或者也许我们可以更改为一种,你知道,不同的订阅或什幺类似的东西。但至少目前加上未来的一段时间,他们不必担心。是的。您还提到了计算。计算为什幺包含在其中?您是否也正在抽象化管道本身?你是像……

添加计算还是自己进行计算?因此,计算来自代理实际运行事物,例如运行代码以完成您的工作。它的基本工作方式是一个编码代理。我们的论点似乎正在奏效,那就是编码就像编码是我们已经创建的与那里每个服务交互的语言。那幺我们为什幺要重写它呢?

就像它已经在一个盒子里了。你想与 Databricks 交互吗?他们有 SDK 和 API。你想与 Postgres 交互吗?就像他们为你准备好了。你为什幺要重写它呢?

因此,代理的工作方式是它实际上会像人类一样编写代码来完成工作。因此,如果您设置了 GitHub 存储库,它将克隆存储库并在 DAG 文件、Airflow 的正确位置进行更改,然后为您推送 PR。或者,如果只是在我的 MongoDB 数据库中进行更改,它将编写代码来完成此操作,然后将其推送。因此,所有这些都需要计算来运行代理获得的 VM。因此,这会传递下去。

哦,我明白了。所以这不仅仅是 LLM 调用,还有 VM 以及沙箱中发生的一切。太棒了。现在,在我们离开之前,我觉得我想确保我能够问你所有问题,因为这些东西对我来说非常吸引人。我喜欢您采用这种 AI 优先方法来处理数据工程师,因为上帝知道,

每天都是拥抱您的数据工程师日。他们经历了如此多的痛苦,承受了如此多的压力,我认为这是一个他们张开双臂欢迎的工具。我想另一部分是,我想你……

可能是出于乐趣或出于对构建此产品的热情,查看了许多日志或查看了代理能够完成的许多内容。代理执行的一个运行或某些内容让您感到惊讶,因为它实际上能够完成它吗?我们进行了一系列测试,让它编写 Spark 代码和 Databricks,并调用 Airflow 中的协调器模式,触发 Databricks 中的内容。许多公司都这样做,他们纯粹将 Airflow 用作协调器,这通常是一个很好的模式。我们只是让它,它是一件非常简单的事情

例如,我们想要进行的数据帧计算。但事实是它能够同时使用多种服务,一次性正确处理代码,例如在其他地方处理数据,然后将其全部整合到不会出错的 airflow 管道中。我想,那东西不可能正常工作,对吧?就像,太疯狂了。

所以我认为这可能是最重要的事情,你知道,这不仅仅是编写管道的复杂性。就像,您必须调用不同的数据处理服务,这意味着您需要了解您正在运行的集群以及需要包含的所有这些内容。然后,您还需要正确编写 Spark 代码以确保不会出错。它就像完成了所有这些。我想,哦,好吧,我想我们有所发现。就像,这太棒了,这令人印象深刻。是的。

它工作了一次,你就像,不要碰任何东西。没有人动。我们现在需要向 LLM 神祈祷,希望它能再次工作。是的。

我记得我立即给我的朋友发短信,就像,这东西不可能正常工作,这太疯狂了。然后,你知道,当你经历训练循环时,它只是崩溃、崩溃、崩溃,然后它开始工作,然后它越来越好,它不再失败了,你只是看着它,哇,我的天哪,哇,这太棒了,这太棒了,这太不真实了。就像你三年前会想

机器人,你可以说去做这个超级复杂的任务,你还需要代码,你还需要理解整个 Databricks 环境,哦,你,你知道,你应该在一两次尝试中就做到这一点,这太不真实了。