您好,AI 工程师们。在 2023 年的第一次 AI 工程师峰会上,我们听到有人说 Pydantic 就足够了。在 2024 年的世界博览会上,我们再次听到有人说 Pydantic 仍然足够了。从那时起,这种观点已成为共识,OpenAI 等公司在其 SDK 和文档中正式推荐 Pydantic,正如我们在关于 OpenAI 结构化输出的 Michelle Puckris 专辑中所介绍的那样。
现在是 2025 年,我们将与 Pydantic 和 Logfire 的创建者 Samuel Colvin 一起完成史诗般的三部曲,他刚刚推出了他的 Pydantic AI 框架,该框架将把 Pydantic 的原则和绝佳的开发者体验扩展到您构建代理的过程中。我们也非常自豪地宣布,在 2月22日于纽约市举行的第二届 AI 工程师峰会上,将新增工作坊环节。
我们新增了这一天,因为我们收到了很多工作坊报名,并且已经购买门票的每个人都可以免费参加。我们很荣幸 Samuel 将在那里与来自 OpenAI、Anthropic、DeepMind、Vercel、AWS、Neo4j、Letter、Solana 基金会等的杰出人士一起,教授他首个关于 Pydantic AI 的工作坊。
工作坊当天还剩 25 张门票。完整的日程安排现已发布。我们的新网站现在列出了来自 DeepMind、Anthropic、OpenAI、Meta、Jane Street、Bloomberg、BlackRock、LinkedIn 等的演讲者和演讲。赞助商席位已售罄,但您仍然可以申请晚些时候的门票,网址为 apply.ai.engineer。两周后见。请注意安全。
大家好,欢迎收听 Latent Space Podcast。我是 Alessio,Decibel Partners 的合伙人和 CTO,和我一起的是我的联合主持人 Swix,SmallAI 的创始人。早上好。今天我们非常高兴邀请到来自 Pydantic AI 的 Sam Colvin 加入我们。欢迎。非常感谢你们的邀请。很高兴来到这里。Sam,我听说 Pydantic 就足够了。这是真的吗?
我会说,你可能还需要 Pydantic AI 和 LogFire,但这已经足够你走很远了。Pydantic 几乎不需要介绍。12 月份的下载量接近 3 亿次。
而且显然,在我们之前与 Jason Liu 进行的播客和讨论中,他一直是 Pydantic 和 AI 的忠实粉丝和推广者。是的,这很奇怪,因为我最初创建 Pydantic 的目的并不是为了在 AI 中使用,它早于大型语言模型。但我们很幸运,它被这个社区采用并广泛使用。实际上,也许我们会直接从你这里听到。什么是 Pydantic,也许还有它的一些起源故事?
它最好的名字,虽然不太准确,是一个验证库。我们对这个名字有一些争议,因为它不仅仅是验证。它默认会进行强制转换。我们现在有严格模式,因此您可以禁用该强制转换。但默认情况下,如果您说需要一个整数字段,而您得到一个“1, 2, 3”的字符串,它会将其转换为 123 以及许多其他合理的转换。您可以想象,围绕何时转换以及何时不转换的语义非常复杂,
但正因为如此,它不仅仅是验证。2017 年,当我第一次开始使用它时,它与众不同的地方在于使用类型提示来定义您的模式。当时这很有争议。一些人确实对此表示反对。我认为 Pydantic 和在其之上构建的 FastAPI 等库的成功意味着今天这在 Python 中不再有争议。事实上,许多其他人也
采用了这种方法。但是的,它是一个数据验证库。它主要使用类型提示,并且显然还执行您想要的所有其他操作,例如在其之上的序列化。但是的,这就是核心。您是否有任何关于 JSON 模式如何成为大型语言模型结构化输出标准的有趣故事?您参与过这些讨论吗?因为我知道 OpenAI 是大型语言模型结构化输出标准的早期采用者之一。他们联系过你吗?是否有关于人们正在讨论的开源结构化输出控制台,还是仅仅是随机的?不,完全不是这样。所以
我最初并没有在 Pydantic 中实现 JSON Schema。然后 Sebastian Ramirez(FastAPI)出现了。我第一次听说他是在一个周末。我收到了他大约 50 封电子邮件,或者说在他提交到 Pydantic、添加 JSON Schema 的过程中,他发了 50 封电子邮件,这早于 1.0 版本。因此,添加它的原因是为了 OpenAPI,这显然与 JSON Schema 密切相关。
然后,是的,我不知道为什么是 JSON 被 OpenAI 采用并使用。这显然对我们来说非常方便,因为这意味着我们不仅可以进行验证,而且因为......
Pydantic 会生成用户 JSON 模式。它可以成为结构化输出和工具的单一事实来源。在我们进一步深入探讨 AI 方面的内容之前,我有点好奇的是,显然 JavaScript 中有 Zod。时不时地会出现一个新的流行验证库,它会流行好几年,然后也许会出现其他东西。Pydantic 完成了吗?就像核心 Pydantic 一样?是的。
我刚刚结束了一个电话会议,我们在重新设计一些内部组件。将来某个时候会发布 V3 版本,它不会像 V2 版本那样破坏人们的代码,因为 V2 版本是对 Rust 的大规模重写,同时也修复了从 0.x 版本开始就一直存在的问题,我们在 V1 版本中没有修复这些问题,因为它是一个副项目。我们计划将一些......
基本上在验证后将数据存储在 Rust 类型中,而不是将其转换为 Python 类型。因此,如果您进行验证然后进行序列化,则无需再通过 Python 类型。我们认为这可以使我们的速度提高三到五倍,甚至再提高三到五倍。这可能是最重要的事情。还包括更改扩展 Pydantic 和定义的难易程度
例如,NumPy 数组如何进行验证和序列化。但也有一些正在进行的事情,例如,Jitter(Rust 中的 JSON 库)执行 JSON 解析,目前仅对 AMD64 有 SIMD 实现。所以他们说,我们可以添加它。我们需要为其他指令集添加 SIMD。
因此,我们可以在性能方面做更多的事情。我认为我们不会彻底改变 Pydantic,但它会变得越来越快,并且希望能够......
允许人们做更多高级的事情。我们可能会添加像 CBOR 这样的二进制格式进行序列化,以便您只需将数据放入数据库中,然后可能再从 Pydantic 中加载它。因此,还有一些事情会发生变化,但总的来说,它只会变得更快、更简洁。从关注的角度来看,我想,作为一个创始人,你
是如何看待 AI 兴趣的上升的?然后你如何确定优先级,好吧,这值得投入更多精力,我们将讨论 Pydantic AI 以及所有这些。您早期使用 LLAMP 的经验是什么?您是什么时候发现,好吧,这是我们应该认真对待并投入更多资源的事情?我会回答这个问题,但我还会回答我认为是一个类似的问题,那就是,
Pydantic 很奇怪,因为 Pydantic 的存在显然早于我创建公司。我业余时间一直在研究它。然后在 22 年初,我开始使用 Rust 进行重写。我全职工作了一年半。然后在我们创建公司后,人们加入了进来。这是一个奇怪的项目,因为它永远不会在创业公司内部获得批准。就像,我们将离开,三名工程师将全职工作一年,使用 Python 和 Rust 编写大约 30,000 行 Rust 代码,只是为了发布一个开源免费的 Python 库。是的。
这对于我们公司来说非常有利,对吧?也就是说,它使我们保持了绝对的相关性。就像,Pydantic 不仅用于所有 AI 库的 SDK 中,但我不能说哪个,但其中一家大型基础模型公司在从 Pydantic v1 升级到 v2 时,他们的内部排名第一的模型......性能指标是第一个标记的时间。下降了 20%。
所以,想想内部进行的所有实际 AI 操作,然而至少有 20% 的 CPU 或至少请求中的延迟实际上是 Pydantic,这表明它的使用范围有多广。因此,我们从这项工作中受益匪浅,尽管它永远不会在大多数公司中具有经济意义。关于我们如何优先考虑 AI 产品的问题,
我的老实话是,我们在过去一年半的时间里投入了大量精力来构建 LogFire 中良好的通用可观察性,并使 Pydantic 适用于通用用例。AI 已经来到我们身边。并非我们想避开它,但 Pydantic 和 LogFire 中使用 AI 进行构建的热情非常高涨,因为......
这很有道理,对吧?如果您今天正在启动一个新的 Python Greenfield 项目,您使用 Gen AI 的几率是多少?假设在全球范围内是 80%。显然,在加利福尼亚州是 100%,但即使在全球范围内,也可能是 80%。因此,每个人都需要这些东西。还有很多东西有待发现,还有很多空间可以改进生态系统,以至于要实现一个比 Postgres 更好的数据库是一项......
不可能完成的任务,而构建比现在的一些工具更好的 Gen AI 工具则并非难事。将实际模型本身放在一边。与此同时,您最近发布了 Pydantic AI,这是一个,你知道的,代理框架。
在早期,我会说每个人,比如,你知道的,Langchain 和像 Pydantic 一样,某种程度上是一流的支持。许多这些框架都在试图利用你变得更好。我们应该开发我们自己的框架的决定是什么?您不同意的任何设计决策是什么?您认为人们没有很好地支持的任何工作负载是什么?这与其说是设计和工作流程,尽管我认为我们做了一些不同的事情,但我认为。
总的来说,看看代理框架的生态系统,其工程质量远低于 Python 生态系统的其余部分。在过去 20 年构建 Python 库和编写 Python 代码的过程中,我们已经学习了如何做很多事情,但在构建代理框架时,人们似乎放弃了这些事情。现在我可以理解这一点,尤其是在最早的代理框架(如 Langchain)中,他们实际上是在弄清楚如何去做这些事情,完全可以理解你会......
基本上跳过一些标准最佳实践来构建一些东西。我对最近一些知名人士发布的一些代理框架的质量感到震惊,这似乎只是机会主义,而我......
对此没有时间。但对于早期版本,我认为他们只是在弄清楚如何去做事情。正如许多人从 Pydantic 中学习一样,我们也能够从他们那里学习一些东西。我认为,从我们看到的差距和我们感到沮丧的事情来看,是生产就绪性。这意味着诸如类型检查之类的事情,即使类型检查会使它变得困难。就像 Pydantic AI 一样,我现在要举手承认,它有很多泛型。
如果您编写过一些 Rust 代码并且真正理解泛型,那么使用它可能会更容易。但就像,我们并不是说这使得它在所有情况下都最容易使用。
我们认为这使得它在类型检查在 Python 中是理所当然的大型系统中的生产应用程序中非常有用。但我们还从多年来维护 Pydantic 中学习到了一些东西,我们已经做到了。因此,Pydantic AI 文档中的每个示例都在测试中运行。并且每个示例中的每个打印输出都在测试期间进行检查。因此,它将始终是最新的。然后是一些事情,就像我说的那样,是 Python 生态系统中其余部分的标准最佳实践,但是
令人惊讶的是,一些 AI 库(如代码覆盖率、代码风格检查、类型检查等)并没有遵循这些标准,我认为这些都是理所当然的事情。但是,奇怪的是,一些其他库并没有遵循这些标准。您能否简单地概述一下该框架本身?我认为这有点像 LLM 调用框架。有一些多代理框架。有一些工作流程框架。Pydantik 做了什么?
当我听到所有不同类型的框架时,我会有点走神,但我喜欢,我会告诉你,当我构建 Pydantic、构建 Logfire 和构建 Pydantic AI 时,我的方法不是去......
并查看所有其他内容。我会弄清楚我想要什么,然后去构建它,然后反馈会来,我们会进行调整。因此,Pydantic AI 的基本构建块是代理。代理的确切定义以及您希望如何定义它们显然是模棱两可的,而我们的东西可能有点像代理精简版,并非我们想将其重命名为代理精简版,但关键是您可能需要将它们组合在一起才能构建某些东西,大多数人都会称之为代理。因此,在我们的例子中,代理具有诸如提示之类的功能,例如系统提示和代理,
一些工具以及您想要的结构化返回类型。这涵盖了绝大多数情况。在某些情况下,您可能需要进一步深入,以及在您需要图形的最复杂的工作流程中。我抵制图形很长时间了。我有点认为您不需要它们,您可以使用标准的 Python 流程控制来完成所有这些事情。我和一些人争论过几次,但我基本上已经接受了,是的,我完全可以理解为什么图形是有用的,但是然后我们遇到了一个问题,那就是默认情况下它们不是类型安全的。因为如果您有一个添加边的方法,您提供两个不同边的名称,则没有类型检查,对吧?即使您进行了一些......并非所有图形库都是特定于 AI 的。因此,有一个名为......的图形库。它基本上执行运行时类型检查,并且
具有讽刺意味的是,它使用 Pydantic 来弥补这样一个事实,即从根本上说,图形不是类型安全的。好吧,我喜欢 Pydantic,但这并不是一个真正的解决方案,需要运行代码才能查看它是否安全。静态类型检查如此强大的原因就在于此。
因此,我们从大量的迭代中最终提出了一种系统,该系统使用普通数据类来定义节点,您可以在其中返回要调用的下一个节点,并且我们能够检查节点的返回类型以基本构建图形。因此,该图形本质上是类型安全的。一旦我们做对了这一点,我就对图形感到非常兴奋。我认为它们在 Gen AI 和其他开发中都有大量的用例。但软件也都会与 Gen AI 交互,对吧?这将类似于 Web。公司中将不再有 Web 部门,对吧?所有开发人员都在为 Web 构建,使用数据库构建。对于 Gen AI 也是如此。是的,在我的文档中,我看到您将代理称为包含系统提示、函数工具、结构结果、依赖类型模型以及模型设置的容器。
在我看来,图形是不同的代理吗?它们是同一代理的不同提示吗?您脑海中的结构是什么?因此,一旦我们正确地使用了图形,我们就对其足够信服,以至于我们实际上在今天早上合并了 PR。这意味着我们的代理实现
在根本不更改其 API 的情况下,现在实际上是一个底层图形,因为它使用我们的图形库构建。因此,图形基本上是允许您构建这些复杂工作流程的低级工具。从技术上讲,我们的代理是我们可能构建的许多图形之一,而我们恰好为您构建了这个图形,因为它是一个非常常见的一个。但显然,在某些情况下,您需要更复杂的工作流程,
当前代理假设不起作用的地方。这就是您可以使用图形来构建更复杂的事物的地方。您说过您对图形持怀疑态度。具体是什么改变了您的想法?我想人们不断地向我提供他们想要使用图形的示例。而我的想法是,是的,但您可以在标准的 Python 流程控制中做到这一点,这对我来说越来越没有说服力,因为我已经维护了那些......
最终会产生意大利面条式代码的系统,我可以看出这种结构化方式来定义代码工作流程的吸引力,而且它真的很棒,就像仅仅从您的代码中,仅仅从您的类型提示中,您就可以得到一个 mermaid 图表,该图表准确地定义了可以发生的事情,对吧?是的,是的,您确实有一个非常简洁的......的实现,
我猜是从类型提示中推断出图形,是的,这就是我所说的,是的,我认为这个问题一直存在,我反复思考过这个问题,我曾经在 Temporal 工作过,我们实际上会花很多时间抱怨基于图形的工作流程解决方案,例如 AWS Step Functions,我们实际上会说我们更好,因为您可以使用您已经了解并使用过的普通流程控制,我认为您的方法是一种很好的折衷方案,就像......
它看起来像普通的 Pythonic 代码,但您只需要记住类型提示实际上做了什么,以及图形构造所做的所谓的“魔法”。是的,完全正确。如果您查看实际运行图形的内部逻辑,它非常简单。它基本上是调用一个节点,获取一个节点,调用该节点,获取一个节点,调用该节点。如果您得到一个结束节点,则表示完成。我们很快就会添加对......的支持,基本上是存储,以便您可以在运行的每个节点之间存储状态。然后,我们的想法是,您可以将图形分发并在计算机之间运行它。而且,我的意思是,另一个真正有价值的部分是跨时间。因为如果您查看 Claude 将为您提供的许多图形示例,如果它为您提供一个示例,它会为您提供一个非常漂亮的、巨大的 mermaid 图表,显示工作流程,例如,如果您是一家电子商务公司,则管理退货。
但是您会意识到,其中一些线条实际上是一个函数调用另一个函数。而其中一些线条是等待六天让客户打印他们的纸张并将其放入邮件中。如果您正在编写演示项目或概念验证,那很好,因为您可以说,现在我们调用此函数。但是当您构建时,当您在现实生活中时,这行不通。现在我们如何管理这个概念,以便能够在......中从其他地方开始,
在我们的代码中,好吧,这个图形实现使它变得非常容易,因为您只需传递作为继续图形的起点的节点,它就会继续运行。因此,就像我说的那样,我只能想象过去所做的事情如果使用图形来完成会更容易理解。您说想象一下,但是现在,Pydantic AI 实际上会在六天后恢复,就像您说的那样,还是这只是一个理论上的事情,我们将来可以做到?
我认为这基本上是问答。因此,有一个 AI 正在向用户提问。
实际上,您随后会再次调用 CLI 以继续对话,它基本上会实例化节点并再次使用该节点调用图形。现在,我们还没有有效地在数据库中存储各个节点之间状态的逻辑,我们很快就会添加。但是其余部分基本上都在那里。这确实让我想到,您不仅现在正在与 Langchain 和显然的 Instructor 竞争,而且现在您还进入了更像 Airflow、Prefects 之类的编排工具。
Dexter,那些家伙。是的,我的意思是,我们是 Prefect 的好朋友,Temporal 与我们有相同的投资者。我相信我的投资者 Bogomil 不会太高兴,如果我说,哦,是的,除了尝试接管 Datadog 之外,我们还将尝试接管 Temporal 和所有其他这样做的人。显然,我们还没有完成部署所有基础设施的工作,至少现在还没有。我们只是在构建一个 Python 库。而关于我们的图形实现令人疯狂的是
当然,在内省返回类型、从联合体中提取内容等方面有一些魔法,但是......
就像我说的那样,实际调用实际上是调用一个函数并返回一个东西并调用它。它非常简单,因此易于维护。问题是它有多有用?好吧,我还不知道。我认为我们必须去弄清楚。我们有一个整体,在过去几天里,有很多加入我们 Slack 的人说,告诉我 Pydantic AI 有多好。Pydantic AI 与 Langchain 相比有多好?我拒绝回答。这是你的工作,去弄清楚,不是我的。我们构建了一个东西。
我对此很感兴趣,但我显然有偏见。生态系统将确定哪些工具有用。当我还在 Temporal 时,Bogomil 是我的董事会成员。我认为,总的来说,作为工作流引擎的投资者和参与者,这是一个很大的领域。每个人都需要不同的编排风格。我想说的一件事是,就像你的,你知道的,作为一个库,你对基础设施的控制并不多。我喜欢这样的想法,
每个新的代理或任何东西,或者任何你称之为工作单元的东西都应该在其隔离的边界内启动。而我认为你周围的一切都在同一个进程中运行。
但是您理想情况下希望将其自己的小容器分离出来。我完全同意你的观点。而且我们会,它现在可以工作,对吧?从理论上讲,只要您可以序列化对下一个节点的调用,您只需要,所有不同的容器基本上都必须具有相同的代码。我的意思是,我对 Cloudflare worker 运行 Python 并......感到非常兴奋,
并且能够安装依赖项。如果 Cloudflare 只能给我邀请参加该私有测试版,我们现在就会开始探索它,因为我对它作为一种类似......的计算级别感到非常兴奋,
用于我们的一些东西,这正是您所说的,基本上。您可以将所有内容作为单个 worker 函数运行并进行分发,并且它对故障具有弹性,等等。它会同时启动数千个实例。您希望它能够一次性成为真正的无服务器。实际上,我知道有一些 Cloudflare 的朋友正在收听,所以希望他们能够排在前面。是的,
我上周在 Cloudflare 的办公室里对他们大喊大叫,抱怨让我沮丧的其他事情。我对 Cloudflare 又爱又恨。他们的技术很棒,但因为我一直在使用它,所以我感到沮丧。所以是的,我相信我会很快到达那里。这是一个关于 Cloudflare 的旁枝。Python 是否完全受支持?我实际上并不完全了解它的状态。
是的,所以 Pyodide(在浏览器中运行 Python 脚本的工具)现在受 Cloudflare 支持。他们基本上正在努力解决如何管理,具有讽刺意味的是,具有二进制文件的依赖项,特别是 Pydantic,因为这些 worker 可以在一台给定的金属机器上拥有数千个,您基本上希望能够拥有一个共享网络。
所有不同 Pydantic 安装的共享内存。这就是他们要解决的问题,他们正在解决的问题。但是 Hood(我的朋友,Pyodide 的主要维护者)在 Cloudflare 工作,这基本上就是他正在做的,就是弄清楚如何在 Cloudflare 的网络上运行 Python。
我的意思是,好的一面是你的二进制文件实际上是用 Rust 编写的,对吧?是的。它还可以编译 WebAssembly。所以也许有一种方法可以构建,您只需要一个不同的 Pydantic 版本,它与 Cloudfluffer worker 的任何发行版一起提供。是的,这正是......所以 Pydite 为......提供了构建版本......
对于 Pydantic Core 和 NumPy 等内容,以及基本上所有流行的二进制库。是的,它很简单。而你正在做同样的事情,对吧?您使用 Rust 编译 WebAssembly,然后从 Python 调用该共享库,并且
它非常复杂,但它有效。好的,让我们再谈谈图形,然后我想谈谈 Pydantic AI 中的其他一些功能。在我的文档中,我看到大约有四种级别的代理。有单个代理、代理委托、程序化代理移交,
这似乎就是 OpenAI swarms 的样子。然后是最后一个,基于图形的控制流。你会说这些是你认为这些事情如何进行的心理层次结构吗?是的,大致如此。好的。您对 OpenAI swarms 有些说法。好吧。
事实上,OpenAI 已经与我联系,基本上,也许我不应该这么说,但基本上说 Pydantic AI 看起来像是 swarms 如果准备好投入生产的话会变成什么样子。所以,是的。我的意思是,是的,这很有道理。太棒了。是的,我的意思是,事实上,正是试图让人们获得与 swarms 相同的感觉,这促使我们去实现图形;因为我的想法是,只是用 Python 代码调用下一个代理并不是一个令人满意的答案。所以就像,好吧,我们必须为此找到一个更好的答案。这并不是......导致我们使用图形。是的。
我的意思是,从某种意义上说,这是一个最小可行图形。人们应该了解哪些图形形状?我的说法是,我认为 Anthropic 做了一件非常好的公共服务,而且我认为他们的博客文章也具有令人惊讶的影响力,当他们撰写《构建有效的代理》时。我们实际上邀请了作者来参加我在纽约举办的会议,我认为您将在那里举办一个工作坊。是的。
告诉我如果你不来。是的,我的意思是,我认为这是第一个权威的观点,关于......存在哪些类型的代理图形,让我们为每个图形命名,以便每个人都在同一页面上。所以我很想知道您是否有社区名称或图形的五大模式。我没有图形的五大模式。我很想看看人们用它们构建了什么。但是,这仅仅是几周的事情。当然,关键在于。因为它们对您可以使用它们做什么相对不加限制,所以它们并不适合它们......您可以用它们做很多事情,但它们没有结构来拥有像其他一些系统那样的特定名称。我认为我们的代理有一个名称,我不记得是什么,但这基本上是一个系统,例如,决定调用哪个工具,返回中心,决定调用哪个工具,返回中心,然后退出。一种图形形式,正如我所说,我们的代理实际上是一种图形的实现,这就是为什么在底层它们现在使用图形的原因。在未来几年中,我们将看到我们最终是否会拥有这些预定义的图形名称或图形结构,或者它是否只是......是的,我构建了一个图形,或者图形是否最终与人们对他们想要的东西的心理形象不符而消失。我们将拭目以待。
0 这似乎就是OpenAI swarms的样子。最后一个是基于图的控制流。你会说这些是思考这些事情发展顺序的方式吗?是的,大致如此。你对OpenAI swarms有一些表达。嗯,事实上,OpenAI已经联系了我,也许我不应该这么说,但他们基本上说Pydantic AI看起来就像swarms如果它能投入生产的话会变成什么样子。所以,是的,我的意思是,是的,这很有道理。
太棒了。是的,事实上,他们特别是在说,我们如何才能让人们获得与swarms相同的感受,这促使我们去实现图?因为我的想法是,仅仅用Python代码调用下一个代理并不是一个令人满意的答案。所以,就像,好吧,我们必须找到一个更好的答案,这让我们想到了图。是的,我的意思是,从某种意义上说,这是一个最小可行的图。人们应该了解哪些图的形状?所以,
我的说法是,我认为Anthropic做了一件非常好的公共服务,并且写了一篇非常有影响力的博文,当他们写下《构建有效的代理》时。我们实际上邀请了作者来参加我在纽约的会议,我想你也会在那里做一个研讨会。是的。
我正在努力弄清楚,但是,是的,我认为是这样。如果你不是,告诉我。但是,是的,我的意思是,我认为这是第一个权威的观点,关于在代理中存在哪些类型的图,让我们为它们中的每一个命名,以便每个人都在同一页上。所以我很好奇你是否有社区名称或图的五大模式。是的。
我没有图的五大模式。我很想看看人们用它们构建了什么,但是,这仅仅是几周的事情。当然,关键是,因为它们对你可以用它们做什么相对不加限制,它们并不适合,你可以用它们做很多事情,但它们没有结构去拥有像其他系统那样具体的名称。我认为我们的代理是什么,它们有一个名字,我不记得是什么了,但这基本上是一个系统,比如,决定调用哪个工具,回到中心,决定调用哪个工具,回到中心,然后退出。一种图的形式,正如我所说,我们的代理实际上是一种图的实现,这就是为什么在底层它们现在使用图的原因。在接下来的几年里,我们将看到我们是否最终会得到这些预定义的图名称或图结构,或者它是否只是,是的,我构建了一个图,或者图是否最终不符合人们对他们想要的思维图像而消失。我们将拭目以待。我认为总是有吸引力。每个开发人员最终都会皈依图,然后说,哦,是的,一切都是图。然后他们可能会过度旋转,过度使用图。然后他们必须学习一堆DSL,然后他们会说,实际上,我不需要这个。他们会稍微缩减一下。我正处于这个过程的开始。我目前是一个图极大主义者,尽管我实际上还没有将任何图投入生产,但是,是的。这与
加州大学伯克利分校关于复合人工智能系统的其他工作有很多哲学上的联系。我不知道你是否知道或关心。这是Gartner的世界观,他们需要某种行业术语来
向企业销售?我不知道你是否了解这些。我没有。我可能应该。我可能应该这样做,因为我可能应该更擅长向企业销售。但是,不,不,我没有。现在没有。这实际上是在争论,与其将所有内容都放在一个模型中,不如说,如果你将所有内容分解成组合的小模型并将其组合在一起,你将拥有更多控制权,并且可能会有更多可观察性。你
显然需要一个编排框架来做到这一点。是的,这完全说得通。我们对代理的看法之一是,当它们工作良好时,它们工作良好,但是当它们,即使你通过log fire拥有可观察性,你可以看到发生了什么,如果你没有一个很好的挂钩点来说,等等,这一切都出错了,你有一个相对迟钝的工具,基本上是在你超过某种限制时出错。
但是,你需要能够做的是有效地迭代这些运行,以便你可以拥有你自己的控制流,就像,好吧,我们走得太远了。这就是我们图实现的一个巧妙之处,你可以基本上在一个循环中调用next,而不是仅仅运行完整的图。因此,你就有机会从中解脱出来。但是,基本上,这与要点相同,即如果你有两个更大的工作单元
在某种程度上,无论它是否涉及Gen AI,但在Gen AI中尤其成问题。你只有在花费大量时间或金钱之后,当它出错时,你才会发现。我会谈谈这个。我们不会在这里解决这个问题,但我先说这个,然后我们可以继续下一个话题。这是我们开发人员讨论这个问题的常见方式。然后机器学习研究人员看着我们,笑着说,这很可爱。然后他们只是训练一个更大的模型,然后在下一轮训练中将我们淘汰。
所以我认为我们正在一定程度上对抗这个痛苦的教训。我们正在对抗AGI。而且,你知道,当AGI到来时,这一切都会消失。显然,在Latent Space,我们并没有真正讨论这个问题,因为我认为AGI是一种含糊不清的概念,并不十分相关。但我认为我们必须尊重这一点。例如,你可以用图来进行一系列思考。
你可以手动编排一个很好的小图来进行反思。考虑一下你是否需要更多推理时间计算。这是现在的热门术语。然后再次思考并扩大规模。或者你可以训练Strawberry和DeepSeq R1。
我最近看到有人说,哦,他们对代理非常乐观,因为模型的速度呈指数级增长。我控制住了自己,没有说它不是指数级的。但我的要点是,如果模型像你说的那样快速发展,那么我们就不需要代理了,我们也不需要任何这些抽象层。我们可以只将我们的模型提供给互联网,祈祷一切顺利。
代理、代理框架、图,所有这些东西基本上都是为了弥补目前模型不够聪明的事实。就像如果你经营一家客户服务业务,并且有很多人坐在那里接听电话,他们训练得越差,你对他们的信任就越少,你就越需要给他们一个脚本让他们遵循,而......
如果你经营一家银行,并且有很多你不太信任的客户服务人员,那么你就告诉他们该说什么。如果你从事高净值银行业务,你只需要雇佣那些你认为会对其他富人有魅力的人,然后让他们去和人们喝咖啡,对吧?模型也是如此,对吧?它们越聪明,我们就越......
不需要告诉它们像结构一样它们做什么以及限制它们采取的路线。是的,是的。同意这一点。所以我乐意继续。Pydantic AI的其他部分值得评论。这是我最后一次抱怨,我保证。所以,显然,每个框架都需要做它自己的模型适配器层,也就是,哦,你可以很容易地从OpenAI切换到Cloud到Grok。你还有,我之前不知道,谷歌GLA。
我直到在你的文档中看到它之前才知道,它是生成语言API。我认为这是AI Studio?是的。谷歌没有给它起好名字。所以Vertex非常清楚。这似乎是某些东西使用的API,尽管它大约20%的时间返回503。所以......
Vertex?不,Vertex很好。但是语言API......是的,我同意这一点。所以,我们又有了一个例子,我认为我们在工程方面做得更远,我们在每次提交时,至少提交到主分支,我们都会针对实时模型运行测试。不是很多测试,而是少数几个。我们上周有一个点,是的,GLA1每次运行都会失败。他们的一个测试会失败。我认为我们现在甚至可能已经注释掉了那个。所以所有模型......
失败的频率比你想象的要高,但那个似乎特别容易失败。但是Vertex是相同的API,但更可靠。我的抱怨是,这个版本的LanChain中出现了,每个框架都必须有它自己的一小部分。我会告诉你,这在Pydantic AI中是不需要的。我更希望你采用像LightLLM这样的层
或者JavaScript中的另一个是什么?Portkey。那是他们的工作。他们专注于一件事,他们为你规范API。所有
新的模型都会自动添加,你不需要在你的框架中复制这个。例如,如果我想使用DeepSeq,我会很不幸,因为Pydance AI还没有DeepSeq。是的,它有。哦,它有。好吧,对不起。但你知道我的意思。这应该存在于你的代码中,还是应该存在于一个作为你定义的基础设施的API网关层中?我认为,如果一个众所周知、受人尊敬的公司在正确的时间出现并做到了这一点,也许我们应该在一年前就做到这一点,并说我们将成为......
通用的AI层。
那将是一件可信的事情。我听说过关于light LLM的不同说法,这是事实,它似乎没有我们需要的类型安全。此外,据我了解,而且我又一次没有详细研究过,他们业务模式的一部分是通过他们自己的系统代理请求来进行泛化。这对很多人来说将是一个巨大的障碍。老实说,事实是我认为统一模型并没有那么难。
我明白你的意思。我有点明白你的意思。我认为事实是,每个人都集中在OpenAI的API上,这是要做的。所以DeepSeek支持它。Grok也支持它。Ollama也支持它。我的意思是,如果现在有这个库,它或多或少就是OpenAI SDK。它质量很高。它经过了良好的类型检查。
它使用Pydantic,所以我有所偏见,但我的意思是,我认为它还是相当受人尊敬的。有不同的方法可以做到这一点。因为这不仅仅是规范API。你必须进行秘密管理等等。是的,还有,因为有Vertex和Bedrock,它们在某种程度上有效地托管多个模型,但它们并没有统一API,但它们确实统一了
Orth,据我了解。虽然我们正在进行MedRock,所以我对此不太了解,但它们有点奇怪的混合体,因为它们支持多个模型。但正如我所说,Orth是集中的。
是的,我很惊讶他们没有统一API。这似乎是我会做的事情。你知道,我们可以整天讨论这些。有很多API。我同意。如果有一个通用的API,我们不必去构建,那就太好了。我想,另一方面,你知道,路由模型和选择模型,比如evals,你如何确定应该使用哪个?我知道你有一个......
首先,你在单元测试中对模拟有很好的支持,这是许多其他框架没有的。所以,你知道,我最喜欢的Ruby库是VCR,因为它只是,你知道,它只是让我存储HTTP请求并重播它们。我会跳过这一部分。我认为你很忙,就像这个测试模型一样,就像......
通过Python,你试图弄清楚模型可能会在没有实际调用模型的情况下做出什么回应。然后你有了函数模型,人们可以自定义输出。从那里还有其他有趣的故事吗?或者只是你看到的就是你得到的?在这两点上,我认为你看到的就是你得到的。关于evals,我认为要关注这个领域。我认为这是一件......
我一段时间以来一直有点怀疑的事情,仍然对一些事情持怀疑态度,嗯,不幸的是,有很多不同的东西被称为evals。如果我们能就它们是什么以及它们不是什么达成一致就好了。但是,我认为这是一个非常重要的领域。我认为这是我们很快将在Pydantic AI和LogFire中努力改进的事情,因为它是一个未解决的问题。是的,你在你的文档中确实说过,任何声称确切知道你的eval应该如何定义的人都可以安全地被忽略。当我们告诉人们如何做他们的evals时,我们会删除这句话。
没错。我想,我们需要今天对此做一个快照。所以让我们谈谈eval。所以这有点像氛围evals,这是你在构建时所做的,对吧?因为你不能真正测试很多次来获得统计意义。然后是生产eval。所以你还有log fire,它有点像你的可观察性产品,我之前试过。非常好。
从为LLM构建可观察性工具中,你学到了什么?是的,当人们考虑evals时,甚至像应该测量什么?你需要多少样本才能开始做出决定?我不是最适合回答这个问题的人,这是事实。所以我不会来这里告诉你我认为我知道答案。
关于确切的数字。我的意思是,我们可以做一些信封背面的统计计算来计算出,拥有30个可能让你获得拥有200个的大部分统计价值,对于
根据定义,15%的工作。但是确切的,例如,你需要多少个例子,例如,这是一个更难回答的问题,因为它深入到模型如何运作。关于LogFire,我们以这种方式构建LogFire的原因之一,我们允许你直接对你的数据编写SQL,我们正在尝试构建强大的可观察性基础,正是因为
我们知道我们不知道答案。因此,允许人们对他们将如何使用这些东西以及如何处理这些东西进行创新,我们认为这是有价值的。因为即使我们出现并为你提供LogFire之上的evals框架,它也不会在所有方面都正确。我们希望人们能够进行创新,能够编写他们自己的SQL,连接到API,并有效地像使用SQL代码的数据库一样查询数据。
允许人们对这些东西进行创新。这就是我们也能做到这一点的原因。我的意思是,我们通过像任何用户一样直接对LogFire编写SQL来测试哪些是可能的。我认为可观察性中另一个真正有趣的部分是OpenTelemetry正在围绕GenAI的语义属性进行集中。所以这是一个相对较新的项目。目前还有很多东西正在添加,但基本上是这样的想法......
它们统一了SDK和/或代理框架如何将可观察性数据发送到任何OpenTelemetry端点。因此,再一次,我们可以这样做,这种统一使我们能够更好地比较不同的库,比较不同的模型。这些东西正处于发展的早期阶段。
我们很快将要进行的工作之一基本上是,我怀疑,Pydantic AI将是第一个正确实现这些语义属性的亚洲框架。因为,再一次,我们控制Pydantic AI,我们可以说这对可观察性很重要。而大多数其他亚洲框架并不是由试图进行可观察性的人维护的,除了Langchain,他们有可观察性平台,但他们选择不走OpenTelemetry路线。所以他们就像......
耕耘自己的土地。而且,你知道,他们甚至更远离标准化。你能否快速概述一下OTEL如何与AI工作流程结合?这有点像这样的问题,你知道,一个跟踪和一个跨度就像一个LLM调用?是代理吗?这有点像你正在跟踪的更广泛的事情。人们应该如何看待它?是的,他们有一个PR,我认为现在可能已经从IBM的某个人那里合并了,谈论远程代理和
并试图支持Gen AI中的远程代理概念,我对此并不特别感兴趣,因为我认为这根本不是常见的用例。但我认为它存在也没关系。OTAL中的大部分内容基本上都在定义你将如何检测给定的LLM调用。所以基本上是实际的LLM调用,你将发送到你的遥测提供商的数据,你将如何构建它。除了关于远程代理的这些略微奇怪的内容之外,大多数代理级别的考虑还没有在......还没有有效地决定,所以有一些模糊性。显然,OTAL的好处在于,最终你可以发送任何你喜欢的属性。但是,是的,在这个领域以及我们如何......
存储数据方面有很多变化。不过,我认为最有趣的事情之一是,如果你考虑传统的可观察性,当然,每个人都会说我们的可观察性数据非常重要,我们必须保护它。但实际上,公司非常努力地基本上不将任何敏感信息放在他们的可观察性数据中。所以,如果你是一家医院的医生,你搜索一种用于性病的药物,SQL可能会发送到可观察性提供商,但没有参数会。所以它不会有病人的号码、姓名或药物。对于Gen AI,这种区别不存在。
因为它只是混杂在文本中。如果你有同样的病人问LLM应该服用什么药或如何戒烟,你无法提取PII而不将其发送到可观察性平台。因此,最终将出现在可观察性平台中的数据的敏感性将基本上与你通常发送到Datadog的数据的数量级不同。
当然,你可以犯错,将某人的密码或银行卡号发送到Datalog,但这会被视为错误,而在Gen AI中,将发送大量数据。我认为这就是Langsmith等公司努力提供本地可观察性的原因,因为有很多公司很乐意让数据狗
数据狗进行云托管,但希望对Gen AI的这种可观察性进行自托管。你今天正在做这些吗?因为我知道在你的每个跨度中,你都有像令牌数量、上下文这样的东西,你只是存储所有内容,然后你将提供一种类似于平台的自托管功能,基本上是的,是的,我们将提供一些东西,所以我们有与其他可观察性平台大致相同的清理功能,所以如果我们,你知道,如果我们看到密码是密钥,我们不会发送值,但是......
正如我所说,这在Gen AI中并不适用。因此,我们接受我们将不得不存储大量数据,然后我们将为那些能够负担得起和需要的人提供自托管服务。然后我认为这是第一次,大多数工作负载的性能取决于第三方。你知道,如果你查看数据狗数据,通常是你的应用程序正在驱动延迟以及内存使用情况等等。在这里,你将拥有可能需要很长时间才能执行的跨度,因为GLA API无法工作,或者因为OpenAI有点像......
不堪重负。你是否做了任何事情,因为提供商在客户之间几乎相同,你知道,你是否正在尝试为人们呈现这些事情,并说,嘿,这是一个非常缓慢的跨度,但实际上所有现在使用OpenAI的客户都看到了相同的事情。所以也许不用担心,或者。还没有。我们做了一些人们通常不在OTA中做的事情。所以我们发送信息在跟踪的开始以及,对不起,在跨度的开始以及它结束时。默认情况下,OTA只在跨度结束时向你发送数据。所以如果你考虑一个可能需要20秒的请求,即使一些中间跨度较早结束,你也无法......
基本上将它们放在页面上,直到你获得顶级垃圾邮件。因此,如果你使用标准OTA,你无法显示任何内容,直到这些请求完成。当这些请求需要几百毫秒时,这并不重要。但是当你进行Gen AI调用或运行可能需要30分钟的批处理作业时,无法看到垃圾邮件的延迟就像削弱了对应用程序的理解。因此,我们做了一些稍微复杂的事情,基本上是在跨度开始时发送有关跨度的数据,这......
与......密切相关。是的。关于所有其他试图在不同的语言中构建OpenTelemetry之上的其他人,你有什么想法?例如OpenLEmetry项目,它并不朗朗上口。但你如何看待这种工具的未来?所以每个人都必须构建
为什么每个人都想构建他们自己的开源可观察性工具来出售?我的意思是,我们不会去尝试用新的语义属性来检测OpenAI SDK,因为......
在某些时候,这将会发生,它将存在于酒店内部,我们可能会提供帮助,但我们是一个小型团队。我们没有时间去做所有这些工作。所以OpenTelemetry,像一个有趣的项目,但我怀疑最终大多数语义,像SDK的大部分检测将像我说的那样存在于主要的OpenTelemetry存储库中。代理框架会发生什么?你基本上在框架级别需要什么数据来获取上下文尚不清楚。是的。
我认为我们还不知道答案。但是,我的意思是,我参加了——我认为这有点公开,因为我上周参加了关于Gen AI的OpenTelemetry电话会议,并且有一位来自Arise的人谈论了他们试图从Langchain中获取OpenTelemetry数据时遇到的挑战,而Langchain并没有——
像本地实现一样。显然,他们遇到了很大的困难。我意识到,之前没有真正意识到这一点,但是我们非常幸运,主要是在谈论我们自己的代理框架,我们拥有控制权,而不是试图去检测其他人的。对不起,我实际上不知道这个语义约定的事情。看起来,是的,它已合并到主OTEL中。人们应该了解什么?我以前从未听说过。是的,我认为这是一个很好的开始。我认为有一些......
一些关于你如何发送的未知数
来回的消息,这是所有事情中最重要的事情,它从属性移动到酒店事件,酒店事件反过来又从跨度移动到它们自己的顶级api,你可以在其中发送数据,所以有一些变化仍在进行中,我对OTEL社区在这个项目上的进展速度印象深刻。我想他们,像其他人一样,明白这一点很重要,而且这是人们渴望获得检测的东西。所以我对他们行动的速度感到惊喜,但这很有道理。我只是浏览一下规范。我已经可以看到,这基本上包含了之前的范例。所以现在他们有了genai.usage.prompt tokens和genai.usage.completion tokens。显然,现在我们也有推理令牌了。然后只有一种采样形式,那就是topp。你基本上是在烘焙或某种程度上具体化
你认为今天很重要的事情,但这并不是一个非常万无一失的方法,可以为未来做这件事。是的。
是的,我的意思是,OTel的巧妙之处在于,你总是可以去发送另一个属性,这很好。只是有一些是商定的。但我会说,你知道,回到你之前关于我们是否应该依赖一个集中的抽象层的问题,这些东西发展得如此之快,以至于如果你开始依赖别人的标准,你就有可能落后,因为你依赖别人来保持更新。或者你落后了,因为你有其他事情要做。
是的,是的,这很公平。这很公平。关于构建Logfire的任何其他观察结果?让我们谈谈这个。您宣布了Logfire。我之所以只熟悉Logfire,是因为您的A轮融资公告。我实际上以为您正在创建一家独立的公司。我还记得您在发布时的一些困惑。所以要明确一点,它是Pydantic Logfire,而该公司是一家拥有两种产品(开源产品和可观察性产品)的公司,对吗?是的。
我只是很好奇,构建Logfire的任何经验教训?例如,一个经典的问题是,您使用ClickHouse吗?这就像标准的持久层吗?这样做有什么经验教训吗?我们不使用ClickHouse。我们开始使用ClickHouse构建我们的数据库,然后从ClickHouse迁移到Timescale,这是一个用于执行分析数据库的Postgres扩展。哇。然后从Timescale迁移到DataFusion。我们基本上现在正在构建,它是DataFusion,但这是一种我们自己的数据库。
Bob和Will并不完全满意我们在选择一个数据库之前经历了三个数据库。我会这么说。但是,就像我们最终找到了正确的数据库一样。我认为我们可以意识到Timescale并不合适。我认为ClickHouse,它们都教会了我们很多东西,我们现在处于一个很好的位置。但是,是的,这在数据库上确实是一段真正的旅程。是的。
好的,作为一个数据库极客,我必须仔细研究一下,对吧?因此,ClickHouse应该成为任何此类事情的理想后端。然后从ClickHouse迁移到Timescale是另一个我没想到的反直觉举动,因为Timescale就像Postgres之上的一个扩展,并不非常适合高容量日志记录。但是,是的,告诉我们这些决定。
因此,当时ClickHouse对JSON的支持不好。我昨天跟某人说话时说ClickHouse对JSON的支持不好,结果被狠狠地批评了一顿,因为显然现在它支持了。因此,他们显然已经构建了他们合适的JSON支持。但是,当我们尝试使用它时,我想大约一年前或一年多以前,所有内容都是一个映射,而映射对于查找JSON类型数据来说很痛苦。而且显然所有这些属性,您在那里谈到的关于
您可以选择将它们设为顶级列,但最简单的方法就是将它们全部放入一个大型JSON堆中。这是ClickHouse的一个问题。此外,ClickHouse还有一些非常难看的边缘情况,例如默认情况下,或者至少在我多次抱怨之前,ClickHouse认为两纳秒比一秒长,因为它们只是通过数字而不是单位来比较间隔。而且
我对此抱怨了很多。然后他们导致它引发错误,并说您必须使用相同的单位。然后我又抱怨了一些。而且我认为,据我目前所知,他们有一些,他们会在单位之间进行转换。但是,像这样的东西,当您所查看的内容是当您所做的很多事情是比较跨度的持续时间时,确实很痛苦。还有像您不能减去两个日期时间来获得间隔一样的事情。您必须使用date sub函数。但是,根本原因是,因为我们希望我们的最终用户
编写SQL,SQL的质量,易于编写程度,对我们来说比您在顶部构建平台时开发人员将编写SQL更重要,并且一旦编写并运行,您就不会太在意。因此,我认为这是根本区别之一。我对ClickHouse和Impact Timescale的另一个问题是,最终架构,即附近某种缓存查询的对象存储中的二进制数据雪花架构。它们都有,但它是闭源的,只有当您使用它们的托管版本时才能获得它。因此,即使我们解决了Timescale或ClickHouse的所有问题,我们最终也会像,你知道的,他们会想要获得80%的利润。然后我们会想要获得这将基本上让我们减少利润空间。
而DataFusion,完全开源,所有相同的工具都是开源的。对于我们这个拥有大量Rust专业知识的团队来说,DataFusion(用Rust实现)可以让我们直接深入研究并进行更改。例如,我发现DataFusion的字符串比较内核在执行字符串包含时存在一些减速。这只是Rust代码,我可以去重写字符串比较内核以使其更快。
或者,例如,当我们开始使用DataFusion时,它没有JSON支持。显然,正如我所说,这是我们需要的东西。我能够在一个周末内使用我们为Pydantic Core构建的JSON解析器来实现它。因此,DataFusion对我们来说是构建数据库(而不是数据库)的工具箱的完美组合这一事实。
我们可以去在其之上实现一些东西,就像如果您尝试在Postgres或ClickHouse中这样做一样,我的意思是,ClickHouse会更容易,因为它使用C++,相对现代的C++。但是,作为一个并非C++专家的团队,这比DataFusion对我们来说要可怕得多。
是的,这是一次精彩的抱怨。这很有趣。大多数人认为他们对这些项目没有自主权。他们有点像,哦,我应该使用这个或那个。他们并不真正像,我应该选择什么才能最大限度地回馈它?你知道的,但是我认为你显然有一个
开源优先的思维方式。所以这很有道理。我认为如果我们可能是一家更好的初创公司,一家发展更快、并且像一心一意地尽快接触客户的公司,我们应该一开始就使用ClickHouse。我希望从长远来看,由于使用了DataFusion,我们处于一个更好的位置,嗯,
我们现在与DataFusion社区非常积极地参与。维护DataFusion的Andrew Lam是我们的顾问。我们现在处于一个非常好的位置,但是是的,这确实减缓了我们相对于仅仅构建在ClickHouse之上并尽可能快地移动的速度。好的,我们即将放大并......
执行Pydantic运行和所有其他内容。但是,你知道的,我对Logfire的最后一个问题是,你知道的,在某些时候,你用完了社区的善意,仅仅是因为,哦,我使用Pydantic。我喜欢Pydantic。我将使用Logfire。好的。然后你开始进入Datadogs、Sentrys和honeycombs的领域。是的。那么你将在哪里真正脱颖而出?这里有什么区别?
我2001年没有编写代码,但我假设当时人们正在谈论网络可观察性。然后网络可观察性不再是一回事,不是因为网络不再是一回事,而是因为......
所有可观察性都必须进行网络操作。如果您在2010年或2012年与人们交谈,他们会谈论云可观察性。现在这不是一个术语,因为所有可观察性都是云优先的。同样的事情也会发生在Gen AI上。因此,无论您是否试图与Datadog或Arise和Langsmith竞争,您都必须做到一流,您必须使用一流的AI支持来进行通用可观察性。据我所知,我们是唯一真正尝试这样做的人。我的意思是,我认为Datadog正在朝着这个方向发展。老实说,我认为Datadog更像
比AI专用可观察性平台更可怕的公司,因为在我看来,而且我也从许多客户那里听说过,AI专用可观察性(您看不到应用程序中发生的其他所有事情)实际上并没有那么有用。我们希望能够构建第一个具有AI一流支持的通用可观察性平台,并且我们拥有这种开源传统,将开发人员体验放在首位,这使得
其他公司没有做到。对于我来说,我是Datadog及其所做工作的粉丝,如果您搜索Datadog日志记录Python,并且您只是作为一个非可观察性专家来尝试使用Datadog和Python运行某些东西,这并不容易,对吧?这是Sentry做得非常出色的一件事,但在大多数可观察性方面,有巨大的空间可以更好地进行DX。
既然您提到了Sentry,我很想知道您是如何考虑许可证和所有这些的。显然,您是MIT许可的。您没有任何像Sentry那样的滚动许可证,您只能使用开源的,比如一年前的版本。这是一个艰难的决定吗?所以要明确一点,LogFire是共同来源的。因此,Pydantic和Pydantic AI是MIT许可的,并且像
你知道的,完全开源,然后,然后log fire现在是完全闭源的。事实上,世纪公司在许可方面遇到的困难以及当他们采用闭源的东西并使其成为可用的源代码时社区给出的奇怪的抵制,这意味着我们只是避免了整个问题。我认为另一种看待它的方式是,
就员工人数、收入或银行存款而言,我们公司所做的开源数量是,我们必须跻身最具生产力的开源公司之列,就像我说的那样,每人。因此,我们不觉得我们有道义上的义务使log fire开源。
我们有Pydantic。Pydantic是Python中的基础库。现在,Pydantic AI是我们对开源的贡献。然后LogFire就像公开盈利一样,对吧?也就是说,我们没有声称其他情况。我们并没有试图在它是否开源的情况下走一条线,但实际上我们想让部署变得困难。所以你可能想付钱给我们。我们试图直接说明这是......
付费的。我们将来可能会改变这一点,但这并非一项立即计划。好的。所以我第一次看到这个新的,我不知道这是否是你正在构建的pythantic.run产品,这是一个Python浏览器沙箱。
背后的灵感是什么?我们经常谈论LLAMP的代码解释器。我是E2B公司的一名投资者,这是一家用于远程执行的代码沙箱即服务公司。Pidentic.run的故事是什么?因此,Pidentic.run再次完全开源。我没有兴趣将其变成产品。
我们只需要一个沙箱来演示Logfire,特别是Pydantic AI。因此,它还没有,但我将基本上向打开AI和其他模型添加一个代理,以便您可以在浏览器中运行Pydantic AI,查看其工作方式,调整提示等。我们将对您每天可以花费的金额或支出金额设置某种限制。我们想要做的另一件事是,当您登录LogFire时,
我们有很多用户流失。许多人注册,发现它很有趣,然后没有去创建项目。我的直觉是,他们会想,哦,好吧,很酷,但是我现在必须打开我的开发环境,创建一个新项目,使用正确的令牌做一些事情。我不想费心。然后他们流失了,他们忘记回来了。因此,我们想要一种非常好的方法来告诉他们点击这里,您可以在浏览器中运行它。
并查看它的效果。我认为这发生在我们所有人身上,我大约在一周半前开始查看我是否可以做到这一点,得到了一些可以运行的东西,然后最终对其进行了改进。突然间,我花了一周时间来做这件事,但我认为它很有用。是的,我还记得大约一两三年前,有一些公司试图在浏览器终端中构建这个功能。就像,你去GitHub,看到一个有趣的项目,但是现在你必须克隆它并在你的机器上运行它,而且
有时可能会很麻烦。这很酷,特别是自从你已经......
使所有文档在你的文档中都可运行。就像你说的,你要测试它们。听起来你可能只是有。所以是的,计划是在Pydantic AI的每个示例中,都有一个按钮基本上说运行,它会带你进入Pydantic.run,那里有代码。根据我们想要推动多大的力度,我们还可以将其像自动连接到LogFire一样。所以就像,嘿,加入这个项目吧。您可以在LogFire中看到它的样子。
这太酷了。是的,我认为这对我个人来说是开源项目中最大的障碍之一。这有点像这样做,然后一旦出现问题,
我就放弃了。所以这需要一些自律,你知道的,就像在我的职业生涯中经历过很多这样的版本,你必须提取这段代码并运行它,它总是过时了。我们经常会有这种转录的概念,我们有一个单独的代码示例存储库,我们希望它成为那样,并且会被拉到我们的文档中,但它从未真正起作用。这需要很多自律。所以为你点赞。
而且多年来一直维护Pydantic,人们抱怨说,嘿,这个例子现在已经过时了,最终我们构建了PyTest示例,这是我们构建的最难搜索的开源项目,因为显然,正如您想象的那样,如果您搜索PyTest示例,您会得到如何使用PyTest的示例,但是PyTest示例基本上会遍历您的文档字符串中的代码以查找Python代码以及文档中的Markdown,并
提取该代码,然后为您运行它,并对其运行lint,很快就会对其运行类型检查。所以,这就是我们如何保持示例最新。但是现在,我们有数百个示例,所有这些示例都是可运行且独立的。或者,如果它们,如果它们引用了前面的示例,那么它的结构已经能够从前面的示例导入代码。所以,
为什么我们不给人们一个好地方,让他们能够使用OpenAI实际运行它并查看输出结果呢?- 好极了。- 好的,这就是关于它的内容。这里的注释,我只是喜欢浏览人们的X帐户,而不是Twitter。
所以四年来,你一直在说我们需要一个纯文本的Jupyter Notebook继承者。是的。我认为人们可能走了另一条路,这可能会变得更加武断,就像使用Axe和所有这些笔记本电脑公司一样。好吧,是的。因此,作为回应,有人回复说,Marimo就是这样。果然,Marimo非常令人印象深刻。我随后与Marimo的伙计们进行了交谈,并获得了对他们公司的天使投资。
我不记得了。我认为是Seaground。所以,Marimo非常酷。它正在这样做。Marimo笔记本电脑还在浏览器中运行,再次使用Pyodide。事实上,我几乎没有构建PyDantic.run,因为我们只是打算使用Marimo。但我的担心是,人们会认为LogFire只能在笔记本电脑中使用。我想要一些,就像讽刺地感觉更基本的东西,感觉更像终端,这样没有人会认为它是......
只是为了笔记本电脑。是的,有很多笔记本电脑讨厌者。确实,我对Jupyter笔记本电脑有非常强烈的看法,这种想法就像你必须按正确的顺序运行单元格一样。我的意思是,很多事情。它基本上就像比Excel更糟糕,或者与Excel一样糟糕。哦,所以你是一个讨厌笔记本电脑的人,却投资了一个笔记本电脑。是的。
我有一个名为Notebook的抱怨,它就像我尝试构建的替代方案,主要只是关于笔记本电脑与Excel一样糟糕的10个原因的抱怨。但是Marimo等,新的基于文本的笔记本电脑,至少解决了其中许多问题。我同意这一点。是的。我一直希望有一个更好的笔记本电脑。然后我看到了Marimo。我想,哦,是的,这些人领先于我。
我不知道我是否会做那种基于注释的事情。就像,你知道的,很多人喜欢,哦,注释这个函数,它只会增加魔力。我认为这与Jeremy Howard对他的东西所做的事情类似。它似乎仍然有点太神奇了,但是嘿,它比笔记本电脑有了很大的改进。是的。是的。太棒了。就像在LLM的使用上一样,像IPYMB文件一样,它只是不......
它不适合放入LLM中。所以仅此一点,我认为就应该......它不适合放入LLM中。它真的不行。它们会崩溃。它也不适合放入Gith中。我的意思是......好的,我们最终会取消iPyMb。
是的,还有其他看法吗?我本来想问你一下伦敦的情况。你知道的,在那里工作怎么样,你知道的,在大西洋彼岸?我是一个夜猫子。好消息是我可以晚起晚睡,因为我经常与美国的人交谈。
所以我今天早些时候被邀请参加在唐宁街10号与首相一起举行的关于人工智能的酒会。所以我对英国现在的人工智能感到乐观,但我认为,看,除了美国和中国以外的所有地方都知道我们在人工智能方面远远落后。我认为英国开始说这是一个机会,而不仅仅是一个风险,这很好。我一直被告知你应该参加更多活动。你应该像,你知道的,多和人工智能领域的人交往。我的本能是,
我宁愿坐在我的电脑前写代码。我认为这可能是吸引人们注意力的更有效方法。我有点觉得我应该坐在Twitter上,而不是在旧金山与人们聊天。我认为这可能是一种混合,我今年可能需要更多地待在美国。但我认为,如果你在一个每个人都想和你谈论代码但你没有写任何代码的地方,肯定存在风险。这是一个失败模式。
我会说肯定会的,肯定有一个场景,而真正失败的一种方法就是仅仅参与到那个场景中,让它占用你的时间。但要参加正确的活动。我希望我正在举办的活动是好的活动。
我说的是,利用这些东西来制作高质量的内容,这些内容可以通过你通常无法使用的不同媒介传播。因为有一些选择性,因为有一个广泛的、专注的社区关注这件事。他们会更多地发现你的作品。它将是高质量制作的。你知道的,这就是为什么至少我会举办会议的原因。
然后在与人们交谈方面,我一直认为这是一个三振出局的规则。所以过一段时间后它会变得重复,但也许就像你关于人们的前10次、20次谈话一样,如果同样的东西不断出现,这表明人们想要一样东西,它可以帮助你以比你在网上进行浅层互动所能获得的更长久的方式来确定优先级。对吧?所以面对面,面对面,就像我,
这是我在工作中的痛苦。你看到了痛苦,你就像,哦,好吧。就像如果我为你做这件事。你会喜欢我们的工具,而且......
你真的无法取代它。这真的是客户访谈。是的,我完全同意这一点。我认为你是对的,很多方面都是对的。我认为很容易被人们在Twitter和LinkedIn上所说的话分散注意力。那是另一回事。很难判断哪些人在大型公司中实际在生产中构建这些东西,而哪些人正在学习编码的第四天,因为他们有同样强烈的观点,而且在他们的......
几个字符中,它们看起来同样有效,但哪个是真的,哪个是假的,或者哪个来自真正了解自己工作的人很难知道
还有什么,Sam?你想说什么吗?没什么特别的。我认为我真的很享受我们的谈话。我会说,我认为如果任何看过Pydansk AI的人,我们知道它还不完整。我们知道还缺少很多东西。嵌入、存储、MCP和工具集等等。我们试图认真地做好事情,这包括尚未完成功能,但是
请在几个月后再来看看,因为我们非常决心要做到这一点。我们知道这些事情就像,无论你是否认为人工智能将成为下一个Excel、下一个互联网或下一次工业革命,它都将极大地影响我们所有人。因此,作为一家公司,我们认为将pedantic AI打造成最好的代理框架对我们来说至关重要。你也是第一个......
我看到的公司现在没有空缺职位,每个来到我们播客的创始人,行动号召都是,请来我们这里工作我们现在不招聘我想坦白地说,我希望Logfire在获得更多商业牵引力和更多收入之前,在我之前雇佣更多人这很好,拥有几年的跑道,而不是几个月的时间,所以我没有任何胃口去
在一夜之间通过雇佣另外10个人来摧毁这条跑道。即使整个团队都忙得不可开交,就像你说的那样,同时做三到四个初创公司。太棒了,伙计。感谢您的加入。非常感谢您。谢谢。