Transcription
你有聊天机器人，AI 男友。这是一种类似，你知道的，消费者的角度。然后迄今为止影响最大的事情是编码代理。>> 似乎现在很明显，编码将是 AI 的第一个主导用例。这只是一个完美的游乐场，你知道，确定性的软件，它确实非常适合用来对冲 LMS 非确定性的缺点。>> 我们处理一个拥有 9000 万个 token 的 TypeScript 单体。在 Sweet Patch 中没有这样的东西。>> AUX 中的创新量简直令人尴尬。是的，>> 人们应该做得更多，如果你正在听这个，你应该做得更多。[音乐]>> 欢迎来到，你知道的，技术领域中从事代理框架或代理相关工作的秃头男士的第一次，你知道的，就职会议。很高兴来到这里。>> BGTN，类似这样的东西，对吧？那是缩写。>> 我有一个朋友，我认识他，有一次他说，“哦，是的，我认识 Jay，来自 JBBL。”是杰夫·贝佐斯模仿者俱乐部吗？我当时穿着背心之类的。>> 很好。这是一种恭维。我认为这意味着你也一直在健身房，你知道的。>> 没错。是的。而且我看起来像个亿万富翁。所以，我认为这是一个很好的起点。很高兴来到这里。感谢您的招待。你知道，我们有一个很棒的演播室。嗯，我们在 Twitter 上来回交流了大约两年，我想说，两年半，大概是从 GPT3 API 时代开始的。所以，我非常兴奋能听到你对许多与代理、记忆、存储有关的事情的看法，嗯，那些不是 AI 的东西，但更像是数据库构建。我也非常感兴趣听取你对此的看法，看看谈话会将我们引向何方。所以>> 也许一个好的起点是 AI 应用数据库。这是你网站上的术语。AI 数据库与 Postgress 或 MongoDB 或任何开发者更习惯的传统数据库有什么不同？>> 一种描述 Chroma 现代实例化的方式。你知道，显然你正在改变信息传递方式，以接触不同类型的开发者。Chroma 正在为 AI 构建现代搜索基础设施。现代与许多传统数据库和系统形成鲜明对比，后者很难扩展，成本很高。你需要考虑容量规划。你需要确定节点的规模，并进行大量的备份和热备工作，以及大量的运营开销。现在，许多现代分布式系统都抽象掉了所有这些复杂性，只是为开发者提供了一个更简单、更具成本效益的解决方案，同时仍然非常高效。所以，这是现代部分，然后对于 AI 来说，在某种程度上是这个对话中更有趣的部分。我们基本上认为有三件事意味着这一点。第一，它是为 AI 开发者设计的，与传统的搜索基础设施相比，传统的搜索基础设施需要一个尖头、尖头的搜索工程师才能设置、实施和维护。现在每个人都必须解决搜索问题，以带来正确的上下文代理。第二是 AI 工作负载，过去你只会索引和搜索某些数据池，这些数据池非常有价值，很多人需要经常查询。如果你考虑我们日常的工作，我们工作的大部分是信息检索。我敢打赌，你和我每天花费 15% 到 20% 的时间来检索信息。想象一下你接触过的所有不同的系统，你接触过的所有不同的数据，对吧？你有一个地图，一个索引，一个路由，你在弄清楚在哪里找到东西。所以，我认为当我们希望将越来越多的劳动力转移到代理时，情况也是如此，所有这些数据都需要对代理来说是可读的、可访问的、可搜索的。第三是 AI 功能，你可以从很多不同的方式来分解它，但我会给你一个简单的例子作为开始，那就是过去你的回忆，10 个蓝色链接或 10 个结果很重要，因为那是一个人类可以消化的全部。你的回忆很重要，但你的精确度也很重要。嗯，现在有了 LLM，精确度不太重要，但回忆实际上更重要。你知道，一个 LLM 可以轻松且廉价地消化数百个结果，但你需要确保在这数百个结果中，有正确的答案。我认为我们的客户和我们正在处理的许多其他非常有趣的事情是，你可以真正地将 LLM 用作查询规划器，这是一种思考方式。就像 LLM 可以决定并理解意图，然后它们可以构建查询来从系统中获取正确的信息。而且，你知道，这些都是现在才可能实现的，因为 LLM 存在。>> 这非常迷人。我看到一个应用是进行连续的 SQL 查询，这有点像一个非确定性的查询规划器，它会运行一个查询。它会查看 SQL 数据库的模式，然后它会决定，哦，基于此，我应该查询这个。>> 这有点像以一种确定性与非确定性交织的方式运行非确定性 SQL 查询，它决定下一步是什么。是的，这是一个非常令人兴奋的想法。是的，广义上说，大多数 AI 工程师的工作实际上是上下文工程。你需要弄清楚，你知道，如何连接你所有的系统，让代理能够访问正确的数据池，教它如何使用这些东西。你知道，在某些情况下，那将是关系数据库、数据仓库中的结构化数据。在其他情况下，那将是代理需要了解并能够访问、知道如何使用的工具和 API。在其他情况下，那将是非结构化数据。看看企业中非结构化数据的数量。它已经是结构化数据的 100 倍甚至 1000 倍，而且这种情况只会加速。你认为 LLM 会全天候运行。它们在摄取什么，输出什么？那是更多的非结构化数据。显然，我们在 Chroma 考虑了很多关于非结构化数据方面的事情。但是，你知道，这里没有万能药。而且，你知道，这是工程问题。我们必须做艰苦的工作。>> 所以，你提到了上下文工程。对我来说，在过去大约三年左右的时间里，它的含义有很多。嗯，你知道，一开始，你只能容纳大约 4K 个 token。我认为 GBT 最初是 4K，GBT3>> 是的，快进到现在，我们有百万 token 的云集，昨天宣布的。>> 所以你能否向我解释一下上下文工程的艺术是如何随着时间演变的，以及你如何看待它在未来的发展？>> 是的，一开始正如你所说，内容非常小，你可以做，你知道，很少的工作。嗯，你知道，现在我认为最大的商业可用模型是 llama for Maverick，它有 1000 万个 token 的上下文窗口，然后你知道，某些初创公司有时会声称他们有 1 亿个 token 或 10 亿个 token 或无限个 token。你知道，Chroma 在这方面做了很多工作，也为正在收听的人，你可以去看看我们的研究技术报告，关于上下文衰减，这个问题是，嗯，你说你给了我一百万个 token，但你实际上能用好这一百万个 token 吗？这是一个非常重要的问题，也是实验室不太愿意让你首先考虑这个问题，也不太愿意回答这个问题的问题。但我们做了这项工作，我们做了研究，我们有证据，你知道，大多数开发者，他们是每天都在构建东西的实践者，已经有了直觉。你经常听到开发者说，是的，当使用任何云模型超过 10 万个 token 时，事情就会变得有点棘手，所以，它是否触手可及？>> 是的。我们只是，我们不知道我们是否想要可靠和高性能的系统，我们通常不希望增加更多的非确定性。嗯，所以我们的研究表明，无论是在模型关注上下文窗口的大部分内容的能力方面，还是在模型推理这些上下文的能力方面，我们都看到，早在 5000 或 10000 个 token 时，就会出现相当大的退化。所以，再次，对于你的用例，它将改变和变化，你需要多少推理能力以及你需要多少注意力。但我认为这些问题不会消失。我认为这可能是 Transformer 的根本，也是这些模型如何训练的。我希望它会变得更好，因为它有点麻烦。嗯，但我想，你知道，对于任何今天构建东西的人来说，你需要既要看到未来趋势，也要理解现实。我想，总而言之，你知道，我们将对 GB5 进行分析。我们将对新的，你知道，一百万 token 的云模型进行相同的分析。我们将看看数字说明了什么。至少在未来三到五年内，开发人员确实需要拥抱并精通上下文工程，这是一个非常稳定的赌注。如果有什么的话，仅仅是为了速度和成本原因，甚至不仅仅是准确性原因，而是，你知道，你经典的层级结构是让它工作，让它快速，让它便宜。我们仍然非常处于“让它工作”的阶段，而且，你知道，我认为你必须工程化上下文才能让它工作。>> 当然。直观地说，你提到你不认为这个问题会消失。嗯，我记得看到你设置的“大海捞针”的设置，就像，我不知道，你把整个《指环王》系列放进去，然后有一句来自《哈利·波特》的话，你说，“你能找到我来自《哈利·波特》的那句话吗？”这似乎是我可以围绕它生成无限量合成数据的那种事情。所以，如果你想运行某种 RL 循环，你真的可以把它磨到绝对，你知道，它的核心。>> 如果你说为我找到《哈利·波特》的那句话。所以，你认为这实际上会达到上限，我们无法阻止这个问题，它将无法找到“大海捞针”？>> 有几件事。首先，那不是“大海捞针”。“大海捞针”实际上是强大的词汇匹配。嗯，你提出的例子更多的是语义匹配，甚至是分类匹配，比如，哦，这句话可能甚至没有说哈利·波特，对吧？或者甚至没有说伏地魔。它只是，我应该根据我的训练数据知道，那是来自哈利·波特。真正的“大海捞针”是其中一个例子是问题是，“我的大学教授说，要写好文章最好的方法是什么？”>> 然后针是我的大学教授说，要写好文章最好的方法是每天写。>> 有趣。>> 就像极端的词汇匹配一样，这是一个零推理任务。嗯，即使你消除了它，你只做一个简单的语义操作，比如你说，你知道，我如何写好故事，或者类似的东西，嗯，你实际上会看到退化。所以，“大海捞针”的强大词汇匹配在所有 token 窗口的上下文链接中都已解决，再次，它没有推理能力，而且注意力也非常有限，你只关注一个“针”。我想快速补充一点。嗯，回到关于 RL 的问题，显然 RL 现在非常热门。嗯，这是，你知道，似乎是每个人都在谈论的。嗯，我认为那里有两个问题。第一个问题是 RL 能做什么？第二个问题是模型能吸收什么？嗯，以及它们能吸收什么而不忘记？而且我认为还没有定论，对吧？从可解释性的角度来看，我们实际上并不真正理解这些东西的极限。嗯，如果你可能做一个模型，它非常擅长，你知道，将《指环王》内容与《哈利·波特》内容分类，你会失去其他所有东西吗？>> 对。>> 也许不是所有东西，但大部分。>> 所以，如果我们看看任何可能书籍的总体分布，然后里面有一句来自《哈利·波特》的话，也许你知道，我们能变得多好还不清楚。我认为当你通常查看我们今天在生产中看到的长时间上下文加载时，通常是非常长的代理执行。>> 正确。>> 我很好奇，你对这个特定子领域长期执行有什么看法？它是否更好，或者是否有任何证据表明我们更擅长记忆？我非常看好，你知道，在百分比基础上，微调模型、RL 或其他模型的百分比，由这些模型服务的百分比只会逐年增加，可能无限增加，你可能在未来 40 年都会如此，而今天它相当小，对吧？大多数人只是使用基础模型。嗯，我不是说基础模型，而是他们主要使用 RHF 的聊天模型。我不知道有多少模型是，你知道，针对特定任务进行微调的，但你知道，我认为它可能是个位数百分点，如果不是更低的话，也许是 1% 以下。嗯，但我认为它会逐年上升。所以，我实际上看好，你知道，专门构建的模型。我认为那是达到我们想要的可靠性水平的最佳方式。我更怀疑的部分是，那是一个万能药。嗯，我给你举个例子，我们正在进行一些实验。我们实际上继续与 bench 进行更多实验，我们研究了 bench 中的长上下文，你知道，代理执行，大量的迭代任务。如果我们让代理能够访问之前的成功案例或之前的失败案例，嗯，这会提高代理性能吗？直观上说是有道理的，对吧？就像人类一样，你有一个作弊表，如果你能弄清楚，啊，我以前遇到过这个问题。这就是我将如何解决它。这似乎会，你知道，很好，或者你知道，提示，对吧？哦，我以前见过 10 种类似的情况。这就是我所做的。这就是有效的。现在我可以复制它。所以，我们发现，再次，这是一个有限的测试，所以有很多免责声明，但我们发现的是，当我们让这个代理能够访问之前的失败时，它提高了模型性能，大约，你知道，百分点，它是显著的，它是，你知道，大约 25% 到 33% 左右，当我们只让代理访问之前的成功时，嗯，代理性能下降了。>> 真的，非常违反直觉。>> 我认为一旦我们解释清楚，它就不是违反直觉的。我们看看它是否符合直觉，我想一旦我们解释清楚。所以，我认为直觉是，嗯，模型是懒惰的。最阴险的干扰信息是那些看起来高度相关但由于微妙原因而不相关的信息，而模型并不总是能够欣赏这种微妙之处。想象一下你作为一个人类，对吧？你找一个不擅长做某事的人，然后你让他做一项任务，然后你给他提供了以前的例子语料库，他们也会陷入局部最小值，然后诉诸于复制粘贴。嘿，你已经为我做了这项工作。非常感谢。我现在不必思考了。我只是复制粘贴。嗯，是的，这就是我们发现的。>> 只是为了澄清一下，当你提到之前的成功案例库时，它是关于相关任务的成功案例，而不是完全相同的任务，因为你可以有一个复制粘贴机，它只会从成功案例中提取差异并应用它。>> 在某些方面，那将不是一个有趣的测试。那将是真正的作弊。是的。不，它是相似的，但又不完全相同。>> 明白了。好的。那是一个非常有趣的结果，我想知道它是否也适用于训练。你知道，我看到了一些结果表明，在将上下文打包到上下文内示例或少样本学习与实际进行微调之间存在一个连续体，而负样本在 sweet bench 上下文中是否比正样本更有价值？>> 百分之百万。嗯，这实际上是一种奇怪的方式，Chroma 的起点。嗯，我们对主动学习非常感兴趣，它基本上是关于“我接下来应该训练什么？”这个问题。而你想识别的是那些困难的、与你已知的内容不同的、但可学习的例子，也就是说，困难但可学习。你知道，有很多工具可以收集这种信号。嗯，实际上谷歌上周发布了一篇关于主动学习的新论文，关于分类例子，哪些是有帮助的。他们实际上使用了，我认为他们使用了嵌入空间来驱动这些事情。而且我们开始看到一些客户也在使用 Chroma 进行训练，这很酷。所以，我认为这仍然非常早期，但是的。>> 有没有一种方法可以将类似的东西嵌入到向量数据库本身中？所以你有了这些嵌入，然后你可以在 C++ 层面有一个内置于数据库的推理层，允许你投影到一个单一的标量值，你知道，它告诉你，这是有价值的，或者它不是，也许不仅仅是为了主动学习的目的，而是为了其他分类目的。>> 你知道，我一直讨厌“向量数据库”这个词，我将继续讨厌它。所以，我只是快速补充一下。我认为这是一种，这是一种大脑腐蚀的术语。它并没有真正描述这里的工作。嗯，但除此之外，我认为在数据库中运行的 LLM 确实很有趣。我认为大多数检索系统的过程，你可以大致了解它们是如何工作的，那就是你首先想要收集所有可能的相关信息。但正如我们已经讨论过的，你不能将所有这些信息都放入上下文窗口。它无法处理。所以你必须提炼它。你必须以某种方式集中它。排名器是常见的历史工具。这些是，你知道，专门的交叉编码器绑定模型，专门用于排名。我们看到越来越多的人直接使用 LLM 作为重新排名器，或者可以是二元分类器，比如，这是提示，这是一个块，这是相关的，是或否，你知道，输出 token 基本上是零，你可以直接使用 logist。但如果你扩展它，你可以做得更多。>> 是的，再来一个。>> 你可以做一些事情，比如，哦，也许它不仅仅是二元分类，比如，为什么你不能在这里进行动态块重写？这是上下文，这是块，将这个块聚焦到与此查询相关的内容，或者为什么你不能进行语义分析？它开始看起来更像一个非结构化查询引擎，你可以几乎用任何查询来查询一个数据池，然后让大规模并行 LLM 帮助你处理和理解这些数据。对我来说，这是一个非常令人兴奋的未来，我认为它将会实现。显然，我认为今天人们仍然认为推理成本很高，这显然是事实，如果你使用最新最好的模型的话。虽然 token 的成本可能不会真正归零，但那些在预提交的 GPU 上运行 Quen 2.5 的人等等，他们正在大幅降低成本。我认为它大约是每百万输入 token 一便士左右，所以它几乎感觉像是一种免费资源，你知道，这几乎就像使用你家里的电力一样，你不会去想它，你只是把电脑扔过去。是的。而且在关于运行 LLM 成本高昂的对话中，我认为人们没有真正提到的是，你已经在运行数据库上花费了很多钱。如果你能真正将 LLM 跨越这个血脑屏障，并将其融入数据库的基础，你实际上可能会减少你进行的查询总数，因为你会得到答案。>> 以更少的总查询次数。我非常看好这个想法，即你将拥有一个更智能的查询规划器，它实际上在某种程度上是非确定性的，运行在 GPU 上，它只是连接到数据库，而不是期望外部代理成为 Chroma 工作方式的专家。>> 我认为我们一直相信数据具有引力，并且计算工作负载最终会回家，因为它们会来到数据。嗯，这显然可能只是网络出口传输成本的原因，正如你所说，在未来，我们可能会构建一种，你知道，直接分页我们想要用于上下文或检索的数据，直接在 GPU 上，嗯，所以所有这些都生活在，你知道，一个芯片组上将非常有意义。>> 当然，而且可以推断出你可以对这些东西进行硬件级别的优化，这样它们在利用你的数据存储格式以更好地检索你的工具方面会更好，你可以训练一个非常轻量级的模型等等。你实际上能否带我们了解一下你们是如何思考这些问题的，以及迄今为止你们在这方面所做的任何实施工作？你们是否对与 Chroma DB 交互的 LLM 进行了微调？无论它们是在数据库内部还是外部，你们如何看待基本上是制作定制的 LM 工具来与 Chroma 交互？>> 我们做了一系列实验。嗯，其中许多都非常有希望。我认为，你知道，就小型公司而言，我们一直专注于做好一两件事。所以，我们一直专注于让数据库非常快速、非常经济高效、非常高效、非常可靠。你知道，这是我们的客户希望我们做的。现在，我们开始看到更多我们可以帮助客户的方法，比如数据摄取，可能还有嵌入模型推理。嗯，所以我们正在朝着这个方向迈出一些，你知道，可以说是小小的步伐。嗯，但我们还有很多计划，也想实现，但你知道，这是一个关于专注和时间的问题。>> 完全同意。是的。而且你可能会节省成本和时间，但对于许多这些应用程序来说，我们仍然处于“让它工作”的时代。所以，也许将它带过这个血脑屏障是没有意义的。>> 让我们谈谈代码搜索。我认为这是目前最迷人的领域之一。嗯，你知道，显然就 AI 应用产生的收入而言，你有 chatbt，AI 男友，这是一种整个，你知道，消费者角度。然后迄今为止影响最大的事情是编码代理，真的？我的意思是，我们看到 Cursor 产生了 6 亿美元的收入。Claude Code 紧随其后。编码有很多挑战。其中之一是找到正确的东西。你刚才提到了 Sweetbench。这些是相当大的代码库，但理想情况下，我们可以让这些东西在更大的代码库上工作。所以，你知道，我们处理一个拥有 9000 万个 token 的 TypeScript 单体。SweetBench 中没有这样的东西。让它工作的挑战是什么？嗯，Chroma 在做什么来提供帮助？以及你如何看待代码检索在未来的发展？我认为，回顾过去，现在似乎很明显，编码将是 AI 的第一个主导用例。这只是一个完美的确定性软件游乐场，它确实，我认为，非常适合用来对冲 LMS 本身非确定性的一些缺点。我总是回到 Andre Karpathy 的软件 1.0 软件 2.0 的想法，你知道，当互联网出现时我们做了什么？嗯，我们在互联网上放了电话簿，你知道，现在我们有了类似 AI 的软件 2.0 或 3.0，取决于你怎么算，我们主要用它来编写软件 1.0。就像今天的情况一样，这种情况将会改变，而且它是一个非常，显然是普遍存在的案例公司。关于如何做或不做代码检索，已经有太多的，我敢说，宣传。>> 这被称为反宣传。>> 反宣传。我喜欢这个。各位，你们在这里第一次听到。人们应该花更少的时间在 Twitter 上。人们应该花更多的时间在他们的基准测试和他们自己的评估上，并弄清楚什么有效。当然，曾经有一段时间，人们说向量搜索就是你所需要的一切。我从未说过。Chrome 也从未说过。但那确实是许多供应商在推广的东西。显然，我们不知道未来会怎样。也许最终，你知道，这些密集表示可以比稀疏表示更强大。嗯，但今天，它并不明显，这对于任何应用程序来说都是万能药。而且，代码搜索，众所周知，一些公司，你知道，无论是因为营销还是其他原因，都将其作为其差异化的关键点，那就是，不，我们只是 GP，当然 GP 只是 reax，你在文件集上进行 reax 搜索，当你有文本数据时，这会很好，或者可以很好。我认为实际上有助于稍微展开这一点，并帮助人们理解何时语义搜索与词汇搜索有意义，也区分索引，这实际上是在语义搜索或词汇搜索之上构建索引。你只是蛮力语义搜索。你可以在一定的数据规模上蛮力词汇搜索。它有意义地索引它，因为你在扩展时弯曲了曲线。我使用的一个简单的类比，它不是直接的代码类比，我将在稍后回到代码，就像你知道，在我的 Google Drive 中，如果我想搜索包含我所有投资者列表的电子表格。我知道它叫什么名字。我做的。它叫 cap table。所以，我只想输入 cap table。它就在那里。搜索结果就在那里。我点击它。很好。这很有意义，因为我是我自己数据的领域专家。我知道语法。我知道语言。我知道要搜索什么。如果我不是我自己的数据的领域专家，那么，好吧，我将搜索包含我所有投资者列表的电子表格。嗯，这在语义上自然会与 cap table 高度匹配。嗯，然后，你知道，我点击它，然后继续。所以，我认为你可以把它看作是，对于任何给定的用例或用户，或者两者兼有，都有一定程度的混合，你知道，代理或人类在你想搜索的内容的语法和词典方面的受教育程度。我认为，你知道，一些应用程序，在效用方面是 80/20。其他应用程序则相反。它是 20/80，取决于，你知道，这些技术中的哪一种将非常有用。嗯，人们发现，你知道，LLM 在代码方面非常出色。它们经过大量代码的训练，所以它们实际上在语法方面相当不错，而且它们在猜测要搜索的术语方面相当不错。它们能够准确地或非常接近地获得这些术语，因此，你知道，因此 reax 是一个非常有用的工具。我认为这是解开并思考这个问题的方式。我认为这是代码检索的广义范畴。嗯，我认为关于 reax 是否就是你所需要的一切，还没有定论。关于密集嵌入向量是否就是你所需要的一切，也还没有定论。我认为，很可能现实情况是，它将是一个混合体。嗯，而且，显然，何时以及如何使用什么是有趣的上下文工程部分。但再次，我认为，这确实区分了人们喜爱的工具和人们不喜爱的工具，那就是系统在提取相关上下文方面的能力有多好。你知道，人们我认为倾向于依赖“哦，你只需要让代理进行代理搜索，代理 RAG”的拐杖。我再也不想这么说了。你知道，只是不断地回到水井，直到你得到一些似乎有效的东西。但我认为你也有很多问题。比如，它怎么知道什么时候停止？嗯，如果它太早停止怎么办？嗯，在某些方面，你只是在系统中增加了更多的非确定性，而不是更少。所以，虽然这很有用，别误会，我们已经谈到 LLM 是很好的查询，你知道，它们可以是很好的查询规划器，代理查询 80 次直到找到你想要的东西，这不太可能是用户一年后喜爱的应用程序的主要功能。>> 那么，你对我们为 LLM 定制工具的看法是什么？比如说，它就像一个超级语言服务器，>> 类似的东西，它将领域的结构烘焙其中。所以它不仅仅是进行词汇搜索，而是允许你跳转到给定符号的引用，或者类似的东西。你认为这实际上能解决你描述的一些问题吗？>> 是的，百分之百。我的意思是，这正是许多顶级公司正在做的事情。所以，它们使用 reax 或简单的搜索作为两个非常关键的技术。嗯，它们还在某些特定情况下使用语义搜索。其中一些甚至走得更远，嗯，并推动了更高级的东西。再次回到“收集和提炼”的比喻。首先，你想收集所有可能的、相关的 token 或信息，然后你想提炼，然后聚焦到你所需要的。如果你考虑一下，你知道，即使是越来越复杂的方法来搜索，如果你愿意的话，它们会带来什么？它们可能会带来更快、更便宜的收集过程，但那可能是在边际上，并不那么重要。有可能在提炼阶段进行蛮力搜索，如果你愿意的话，这可能是大部分价值所在。而且，你知道，你总是可以使其在 10% 到 15% 的范围内变得更好、更便宜、更快，而用户可能会注意到或关心，也可能不关心，这取决于用户和情况。但我想，再次，你必须将其与用户体验的实际差异以及代理的能力联系起来。我不知道这是否会在长期内对代理的执行能力产生巨大影响，我想说的是。>> 我认为如果你做得好，你仍然会得到所有相关的 token。我认为它主要会使代理循环在边际上更快、更便宜。嗯，然后它是否对你的用户很重要是另一个问题。>> 当然。是的。在某种程度上，文件系统是一个数据库，它提供了各种搜索技术，包括 RIP GRP 或任何>> 可能的。而且，似乎这是它迄今为止获胜的一个巨大原因。所以，Cloud Code 只使用 RIPG。它不使用任何花哨的语言服务器或任何类似的东西。而且，据我所知，这是最先进的。>> 它非常容易设置。你不需要了解任何关于，你知道，特定的数据库或查询方法。只要你有一个 Linux VM，它就可以立即使用。但我很难相信未来会是这样。感觉代码的结构中有很多东西是你希望利用超智能 LM 来实现有效性的。语言服务器就是一个很好的例子。你可能不知道如何调用认证模块，但与其运行六个 rip grip 查询，不如运行一个语义搜索来检索它。创建实际的向量数据库存在明显的复杂性，但似乎是将在不久的将来得到解决的那种事情。>> 还有>> 搜索整个网络的代码量不是你可以在单个文件系统上完成的。>> 没错。是的。我认为我还会指出，如果你只是搜索文本，那么是的，reax 可以让你大部分时间都做到。再次，如果它只让你完成 80% 的工作，如果添加语义搜索、基于嵌入的搜索能让你再增加 8%，那可能意味着用户选择你的产品与竞争对手产品的区别，对吧？所以，这不一定是你必须考虑这些事情。文本搜索按定义只擅长搜索文本，>> 在代码的情况下，通常只有文本，但并非总是如此，对吧？嗯，很多多媒体最终会进入代码库的公共文件夹。嗯，所以，如何搜索图像？如何搜索视频？嗯，你知道，这也是一个重要的考虑因素，如果你希望代理真正达到最后的实用性和可靠性。我还会提到另一件事，比如，嗯，今天我不知道有任何代理这样做。我不是，我不是，你知道，完全了解每个人的最新功能，但今天似乎大多数人只搜索当前活动提交，你本地机器上任何活动的提交的当前脏状态。它们不引用其他分支，>> 不引用历史或其他开放分支。嗯，这似乎非常有用，尤其是如果你有两个代理在不同的分支上处理类似的功能。嗯，它们应该在某种程度上进行协调，你知道，不要在未来与人类产生一些荒谬的合并冲突，这需要你，顺便说一句，能够实时同时查询它们。那些是单独的搜索索引，你必须考虑如何做到这一点。我们构建了一些功能，其中一个功能叫做 forking，对于给定的集合，你可以在 100 毫秒内创建一个集合的副本，这使你能够跳过重新索引的成本和时间，然后你只需将脏状态的差异或你想要服务的任何提交，嗯，放到那个索引中。你还在存储方面节省了很多，因为你不需要为增量付费，你只为增量存储付费。嗯，所以我们看到很多 AI 编码公司使用 Chroma，特别是在这种方式下，它们进行了大量的 forking。它们创建了大量的集合副本进行搜索。我还会提到的另一件事是，不仅仅是搜索你正在处理的代码，而是搜索你的代码所依赖的开源依赖项。对吧？我们都见过那个著名的 XACD 漫画，对吧？依赖性塔，对吧？今天你可能，也许将来会通过 LSP 或其他方式，对吧？但今天似乎大多数 AI 编码代理都不喜欢点击引用并查看实际的 API 参考。所以，如果你使用的是那个版本的 fast API 或那个版本的 React，嗯，它会增加幻觉的可能性，因为，我不知道，模型，也许有像 fast API 和 react 这样的大型库，嗯，模型，如果你问它，在这个特定版本中，API 是什么？我认为它可能能够得到。我没试过。嗯，但我想长尾非常困难。所以，提高编码的代理可靠性。让它查看参考。让它查看开源依赖项，但你不想总是，你知道，get clone 并进行 npm install 并等待五分钟，嗯，为了你的代理，对吧？所以，我认为这些东西也需要预先索引，嗯，这样你就可以快速地进入并开始编写代码。>> 是的。而且有时它们已经被最小化了，所以如果你安装了，你就得不到好的文档。>> 是的。没错。>> 所以，这是 Chroma 正在进行的一项积极的努力吗？>> 是的。是的。什么时候会发布？>> 嗯，这可能需要一到两周的时间。>> 是的。我们实际上已经发布了>> 我们可以等到你发布这个。也许>> 我们称之为代码集合，我们已经索引了 npm、pi、crate 和 rust 的所有主要开源依赖项，以及 go>> 嗯，抱歉，cargo 和 go。>> 嗯，你可以跨各种发布标签搜索它们。>> 太棒了。所以，我可以固定一个版本，然后说告诉我这个晦涩难懂的包的这个版本支持什么 API？>> 是的。我的意思是，基本上你只是给了代理更多的工具。嗯，所以你说，好的，我想搜索这个确切的包，在这个发布标签下，你可以进行 reax 搜索，你可以进行语义搜索，你可以两者都做。嗯，你可以进行基于文件的搜索元数据。嗯，它都在里面。>> 太酷了。我想重新审视这个可 fork 的集合的想法。我认为这实际上是一种模式。我与许多人交谈过，嗯，你知道，在代理和编码领域，这个想法一直在出现，因为代理是一种似乎将来会是 RL 的东西，只是一个代理工具，它可以 fork 自己。它正在处理的任何类型的工件，如果该工件也是可 fork 的。所以，也许它是一个虚拟机，也许它是一个 git 状态，你知道，你显然有堆叠的 PR 等等，或者一个集合似乎很有意义。是的。所以，你在这里描述的是，你有一个情况，你想索引一个代码库，然后在不同的 git 分支上，你会有不同的集合可以搜索，这些集合在某种程度上是写时复制的，所以很容易启动一个新的副本。>> 是否有未来你会实际将其引入 git 本身，并拥有某种 git 扩展，就像一个可搜索的索引，为每个提交存储差异？>> 我不确定我是否想跨越 Linus 的领域。嗯，所以，我认为在那个级别的集成，>> 我们谈论的量级是多少？索引的大小是否远远大于实际代码本身？>> 有很多变量，对吧？就像你如何分块，你使用多大的嵌入模型，你是否对其进行量化。这是主要的区别或挑战。它是可配置的，我猜，取决于你想让它有多大或多小。>> 太酷了。>> 是的，我认为，你知道，正如我们所知，Git 在大型文件管理方面并不好，对吧？任何使用过 get LFS 的人>> 都会再也不想用它了。通常移动和可移植性很有意义，你确实想发送>> 索引和代码。你也不想在代理运行时在网络上传输大文件，因为这只会很慢而且很昂贵。你想远程搜索，然后只获取你需要的数据，而不是移动整个索引。所以我怀疑那不会成为一种主流模式。你提到的另一件事，我认为它相当发人深省，是跨不同提交进行搜索的想法。所以，你说得绝对正确。如果你让我去实现一个功能，Jay，作为一个开发者，我不会去看别人的东西。我只会开始，你知道，看看我今天机器上的代码。这似乎是你想要派人去为你做背景研究的那种查询，对吧？所以，也许有一个专业的代理，它只会查看代码库中的先前实例。你知道，它会做 git 考古，查看所有以前的分支，然后为你找到。哦，我们过去确实做过这个，但这实际上不会阻塞代理的前进主线程。而且这似乎是你实际上可以将其烘焙到数据库本身的那种事情。所以，我会说，嘿，你知道，找到我所有的 X 的实例，它会给我一个快速的响应。它说，嘿，今天的代码库，在这个提交上，这就是我们正在看的。但同时也有一个异步查询在后台运行。所以，我想知道，你是否考虑过像这样的应用，其中有>> 是的。这是一个好问题。我认为一种思考方式是预算。所以，对于某些查询，你想花很少的钱或很少的时间，或者两者兼有，并且你想非常快速、非常便宜地得到答案。对于其他查询，你愿意花很多时间或很多钱，概念上来说，去找到正确的答案。我认为这更属于这些背景搜索代理的范畴。我认为人们使用的术语是深度研究。这是一种深度研究类型的。>> 我不喜欢那个词，但人们就是这么称呼它的。>> 为什么不呢？深度研究有什么问题？>> 我不知道。这只是另一个愚蠢的词，没有任何意义。我认为第一个公司将其成功实现，就可以创造这个词，而不幸的是，深度研究>> 有人成功实现了吗？就像你可能使用过研究，对吧？嗯，如果你在你知道的东西上运行它，你会觉得这个结果非常普通，而且以一种微妙但有意义的方式错了，在 10 到 15 个不同的地方。而且，这应该让你非常怀疑将其用于你关心的任何其他任务，因为如果它对你了解的东西不好，那么为什么
你信任你不知道的好东西吗？我不知道我的经历是否相同。我的意思是，我想我并没有问它一些我期望有博士水平研究的问题。我更希望找到一些像快速书籍报告一样的东西，它能检索到，你知道的，来自CNN或，你知道的，Pi Pi包或任何东西的相关链接，并且当你查看输出时它是可验证的，就像你实际上可以看到它得到了正确的答案。但是，如果我问它一个困难的问题，我毫不怀疑它会无法解决。我认为那很快就会解决。是的，>> 我确实认为它是首批以全面消费者的方式推出的产品之一，它实际上尝试执行一项需要大约半小时的代理任务。>> 在此之前，你真的只有Chad GBT，它会运行你知道的5分钟或类似的时间。因此，出于这个原因，我想把它交给Chad GBT或Google或任何第一个推出它的人，并说深度研究很棒，你们可以起名字，我将称之为那个排序。但我想有深度研究，也有多层研究。所以，你应该能够指定，好吧，我希望这个东西能够回来，并用我所问问题的更新信息来打断我。>> 对。对。我的意思是，不仅仅是给你一些状态更新和报告，告诉你它进展如何以及它在想什么，以及将那些令牌流式传输回来，而且如果它需要额外的帮助，还可以向你询问澄清。我的意思是，即使是今天的深度研究任务也做不到。例如，我对Chad GBT的深度研究如何工作有一个理解，那就是如果你使用它，它实际上是显而易见的，但它被硬编码为问你一个问题。嗯。它总是先问你一个问题。你注意到它从不问你另一个问题，即使它可能或应该问。嗯，你知道那会改变。长话短说，我们将做客户希望我们做的一切。嗯，我认为今天这种模式还没有被发现足够普遍或流行，以至于人们希望我们这样做。而且我认为这可能主要与这些东西的成熟度有关，它们还不稳定，而且变化如此之大，以至于人们理所当然地希望将其直接保留在他们的视野中，非常直接，一旦它变得标准化和易于理解，就会有速度、成本、可靠性、操作复杂性的收益，可以用来“外包”它。嗯，这是我的猜测，但>> 是的，我可能会补充说，你今天看不到这个产品的原因之一是，代理可以运行并实际完成有价值的事情的最高水位线或最大长度在1到2小时之间，如果其中一半时间只是进行研究和生成一个子代理去寻找东西，那么你应该让主代理线程来做这件事。但也许当我们预期这些代理运行10小时或你知道的24小时或类似的时间时，实际上有意义的是生成一些小的深度研究代理，它们会带回可验证的信息给你。>> 是的，我喜欢这个。我认为是的，随着主线程的长度变长，它能支持的代理规模几乎肯定会增加，因为有很多事情要做，你可以真正地，是的，加以利用。>> 是的，是的，这与公司有直接的类比，感觉就像，也许这有一个明确的临界点，但就像，你知道你发现的是至少相关的，公司越大，他们声称能够看向的未来就越远，即使不是所有大公司都看向未来，但理论上是看向未来。>> 是的。>> 是的。所以，我们已经谈了很多关于检索代码或可能像Slack中的信息之类的工件，这显然会，你知道的，我认为这股浪潮还没有真正到来，而且这会带来巨大的生产力提升。>> 检索最常被引用的有趣用例之一是记忆。所以，它不仅仅是实际的读取部分，还有我首先决定记住什么部分的写入。我知道你们都花了很多时间思考这个问题。所以，我很想听听你们的想法。也许一个激励性的问题是，你认为今天有哪些真正好的记忆应用？它在哪里取得了成功，你认为这些应用未来会是什么，然后我们如何实现它？>> 我认为广泛来说，你可以分开，我的意思是，首先，记忆不是一种技术。嗯，记忆是一种技术的好处，这种技术对普通人来说是易于理解的。你，你的妈妈和我妈妈都能理解记忆是什么，意味着什么，以及为什么它在直觉上是有益的。对于那些正在实施这些东西的从业者来说，读取路径只是另一个上下文工程路径。你知道，去收集相关的历史信息，并决定什么重要，什么不重要，然后将其放入上下文窗口，然后使用它。写入路径很有趣。所以，系统应该记住什么？嗯，总的来说，系统应该记住任何能让它在当前任务上做得更好的东西。这是思考它的一个方法。所以，就像代理的持续在线学习，在我看来，记忆的目标就是这样的。我认为你可以将其分解。你知道，你开始分解事物，你可能会创造一些潜在的虚假层级和二分法，这些可能会导致更多的“脑腐”。我确实认为代理任务学习之间存在一些有用的区别。所以，这个代理如何能更好地完成特定任务，然后是用户个性化？代理如何能更好地服务于这个用户？当然，你知道，归根结底，服务用户也是一项任务。将它直观地分成这两个大类是有道理的。嗯，当我们谈论Sweetbench时，我们已经稍微谈论了代理任务学习。你实际上，那个实验是为了看看过去的成功，过去的失败，你知道的，代理能否参考它们并做得更好。而且很明显，这并不容易，对吧？你不能只是给它访问权限，然后就结束了，然后骑着夕阳去海滩。不，实际上比这难得多，至少今天如此。嗯，我认为它将继续非常困难。用户个性化在某种程度上感觉更易于处理，也更容易获得。嗯，所以，你知道，记住我想要我的TypeScript格式化成这样，或者那是编码的例子，对吧？或者，你知道，每次写一个新函数时，都要记得写一个测试。你知道，这些东西。用户个性化也就像用户指令一样，我的偏好。我不是。但是，你知道，理论上，我是乳糖不耐症，所以如果你计划去伦敦旅行，不要建议我去吃冰淇淋，对吧？就像，你知道，这些用户消费者故事，我认为也有真正的效用。嗯，你知道，HGBT的记忆功能在某种程度上是有争议的。有些人似乎把它逼入了一种深度的精神错乱状态，你知道的，他们真的会发疯。其他人，我想，包括我自己，只是把它关掉了，因为我只是想管理它，我不想泄露。声称它还没有做好还不是一个有争议的或反常的观点。>> 没有什么比我的AI妻子忘记了我昨天对她说过的话更让我生气了。所以，所以我同情他们。>> 我会避免开玩笑，那很有趣。是的，没错。是的，我认为，你知道，选择记住什么非常有趣。嗯，所以，在某种程度上，你可能不必选择。你可以在你的，你知道的，收集和提炼检索信息检索管道中记住一切。然后，你可以从我所知道的关于你的所有信息中决定，你知道的，我应该在这里提取什么，这可能对事实信息有效，特别是当用户明确地说“请记住X”或“请记住Y”时。我认为这就是风帆和光标目前所做的，它们都有这些“魔法词”，如果你说了什么，它就会记住它。我实际上认为，那没关系，对吧？就像教用户一点点用户教育，关于产品的用户体验，关于如何记住东西，即使是点击一个按钮，为什么不呢？从最终用户那里获得这种结构化数据，可以为你解决很多问题。完全在后台隐式地这样做，只是更难，而且可能没有比用户非常明确地表达他们的偏好更有价值了。这对于点事实和，你知道的，点信息来说效果很好。嗯，我们确实看到，你知道的，如果你只是用一个文本文件来存放所有这些偏好数据，然后你只是把那个东西放进每个提示的上下文中，那很蠢。不仅仅是蠢，而是它不起作用。这就是我的意思。所以，你不应该这样做。你仍然应该明智地选择你放入上下文的内容。>> 它最终会给它带来很多不相关的混乱，或者>> 是的。我使用的例子，也许我最终会找到一个更好的例子，就是如果我计划去巴黎旅行，上个月我去了布拉格，你知道的，在布拉格我去了弹球博物馆。也许我喜欢弹球，所以我现在要去巴黎，如果巴黎有弹球博物馆，它应该告诉我。显然，这是非常重要的事情，但如果我从小就去我奶奶在威斯康星州的湖边长大，现在我要去巴黎，你知道的，它不应该说，“哦，你应该去看看这个湖，因为你小时候去过一个湖。”不，那不重要。但我认为代理很难分辨什么重要，什么不重要。>> 是的。>> 对此的一个温和的反驳是，这不就是检索之后，我们已经，你知道的，得到了所有这些记忆。代理应该能够分辨并说，“好吧，这是一个湖边小屋，但他五岁时，现在他是个成年人了，他要去”>> 再说一次，你会希望如此，但今天似乎不是一个稳定的假设。>> 经验上，这实际上并没有实现。有趣。嗯，我要补充的细微之处是，我认为，你知道的，点事实信息很可能通过我们今天拥有的一些技术得到很好的服务，但长期分析不是OLTP而是OLAP，对吧？不是点查询而是聚合。我，我的代理已经做了类似的任务45次了，第46次。我如何做得更好？我应该如何调整我的系统指令？我应该如何调整我的系统指令？我应该如何调整我可访问的信息或我访问它的方式？甚至可能我应该如何修改我自己的权重，以便下次我能做得更好。嗯，我认为这个问题非常，你知道的，未被充分探索，并且没有解决。所以我只是想问，你知道的，我所知道的今天生产中的所有记忆实现，都是将它写到待办事项列表或存储在某个数据库中，以后再检索。你认为这有一个根本的好原因，为什么它没有被内置到模型中？>> 那会是什么样子？>> 我可以想象的一个例子是，你知道的，你想要可审计性。嗯，所以任何时候它记住什么，你应该能够在Notion文档中查看它，或者你可以在，你知道的，Postgress UI中查看它，说，“好吧，我可以去看看，我可以划掉不相关的东西。”所以，如果它，你知道的，实际上被内置到模型的权重中，那不是一个好主意。>> 嗯，然而，你知道的，我们正在谈论的是一种“凭感觉”理解如何完成任务。这似乎是你必须将其存储在外部数据库中，然后添加一堆额外的步骤。如果我们考虑这个的完全通用版本看起来像什么，并且会成功，它可能正在做我们所描述的这种终身学习，每次它完成一个任务，你给它某种类型的错误信号，它就能更新自己，不是仅仅是行为上的，而是实际上是记忆导向的。>> 我的意思是，那将是伟大的。可审计性问题相当重要。在广泛的应用AI领域，有一个研究领域。实验室非常专注于下一个大模型，它会爬坡并最大化所有可读的基准，因为这就是它们吸引眼球、金钱和人才的方式，以及这些基准是否真的有意义，以及它们是否真的有帮助，以及我们是否应该关心，这是一个重要的问题，但似乎没有人问。你有一群人在，你知道的，SaaS层，构建有用的AI产品，但没有时间或组织结构或技能来进行优秀的应用研究，所以我认为这里有一个差距，这是我想说的第一件事。我认为，你知道的，微调非常有前景，特别是当微调很容易回滚时，你知道的，更像LoRA形状的东西，我认为非常有前景。你几乎想要，你知道的，一个状态的树，你可以非常容易地回滚，也可以非常容易地热交换，你知道的，在生产中。>> 回到我们关于分叉代理的讨论，你可以有一个代理建立一些记忆，然后你可以回去。我认为这是非常关键的，应该有一个外部数据结构，而不是模型的参数，所以你很容易地，你知道的，像你提到的那样热交换。>> 记忆的应用呢？所以，我认为这是我注意到的一件显而易见的事情，我是一个狂热的代理用户。我认为ChatgBT和Claude今天推出，我想说的是，它将能够回应你之前说过的话，它会说，“哦，我看到你是一名软件工程师，因此它会给我一个答案。”它可能正在做某种形式的，你知道的，从之前的聊天中检索大量文档。也许它们被提炼出来并展示给它。>> 是的。>> 我在代理中看到的实际记忆的唯一其他应用是在几个编码代理中。所以，Cursor最近推出了一项功能，它会，就像你刚才提到的那样，它有一个次级模型，它会查看你的聊天并说，“这是值得记住的吗？”然后它会提议一个记忆。它很糟糕。我不会撒谎。你知道的，我用它有一段时间了。它提出的记忆是，“哦，你总是喜欢使用这个表情符号和日志。”我说，“嗯，我在这特定实例中确实做到了，而且我并没有声称这无法解决。”它绝对是那种通过适当的上下文管理和工程，你会得到一些好的东西，特别是如果人们点击按钮，你就会得到这种>> 具体反馈。你有没有什么例子，记忆实际上能改变用户与代理互动体验的方面？>> 我认为直觉上我们希望代理能够达到人类水平或更高。嗯，如果你只考虑如何教一个人做某事，写下整本用户手册和整本教科书，然后希望他们照做，这是不可能的。你知道的，在实践中，任何工作都是学徒制模式，并且有大量的，你知道的，隐性知识，这是必需的，就像在职培训，他们称之为，对吧？在那里，你正在给你的员工或你一起工作的人反馈，关于“多做这个，少做那个，这样做，那样做。”我认为，如果我们希望代理像人类一样可靠，那么这种东西也必须存在于代理领域。可以是代理自己给自己进行自我批评，自我纠正的反馈，或者，你知道的，我认为更可能的是，在目前，人类会给代理这种“迭代反馈”。“下次这样做。”这似乎是一个非常大且重要的问题要解决。嗯，但如果你能解决这个问题，我认为AI代理的可靠性将大大提高。>> 在多大程度上这是需要发展的消费者行为？我想，作为这个问题的前奏，我两年前开始研究编码代理。人们根本不知道如何有效地使用它们。他们会给它们任务，比如，“哦，修复我的代码。”而且我们已经看到，在GP3推出和现在之间，确实存在一种根深蒂固的客户行为，用户行为，即这是我可以分解并让代理去做的任务类型。在我看来，用户本身还没有这种能力，即知道“这是值得记住并建立这种能力，即主动知识管理。”所以，在多大程度上你认为这是成功部署记忆的瓶颈？>> 我不知道。等等看。>> 是的，我认为它肯定会变得更好。你知道的，无论是它是否会变得足够好，能够跨越界限，达到某种，你知道的，嗯，许多用例的激活点。待定。>> 我可以想象，如果ChatGPT有一个功能，它会说“记住”或“不要记住”，并且有一个普遍接受的用户体验机制。>> 是的。>> 然后我们会看到记忆得到更广泛的部署。>> 嗯，你可以预期，如果你推出新产品，你可以有一个内置的记忆功能。事实上，人们会期望如此。>> 我认为那是对的。我的意思是，想想OpenAI的理念，最少的，对吧？以及可能的DX或UX。嗯，我认为这可能是他们追求的大众消费者的正确选择。现在的问题是，他们也被认为是，你知道的，AI UX应该是什么样的“思想家”，结果是，每个人都只是把他们正在做的事情复制粘贴到他们的东西上。嗯，AI UX中的创新数量简直令人尴尬。是的。嗯，我认为人们应该做得更多，如果你正在听这个，你应该做得更多。>> 有趣的是，有一段时间人们说聊天不是代理人之间互动的最终范式，你知道的，人类代理互动或人类LLM互动，我们需要做，你知道的，做些更好的事情，我们骑着那股浪潮上来了，现在我们正在下来，人们说，“实际上聊天很不错，”我们在过去几年里尝试了很多其他东西，没有什么能以同样的方式真正落地，我很好奇为什么。你有什么想法吗？我认为聊天是一个很好的用户体验，因为人类能理解它，因为我们一直在聊天。>> 所以，你知道的，这是非常直观的。嗯，但并非所有强大的工具都直观。根据定义，强大的工具通常不直观。它们需要你学习它们才能解锁它们的力量，如果你愿意的话。而像编码这样的东西，它是强大工具的一个很好的候选者，也是一个很好的候选者，在那里，你知道的，基本的聊天可能不够。而且我认为你已经在某种程度上看到了这一点，对吧？你可以标记文件之类的东西。你可以给它额外的上下文。你可以编写工具或给它访问工具的权限。你可以做很多事情。人们通常首先想到的是，当他们说“聊天不够”时，他们会说，“我想要分支聊天。”现在，你突然在React中制作某种，你知道的，反应式节点图。>> 从来没起作用过。>> 它从来没起作用过。>> 历史上从未起作用过。>> 它从来没起作用过。你知道的，也许在2025年，等等，不，2035年。嗯，它会起作用，但它从来没起作用。我认为思考这个问题的一个方法是，你知道的，如何给一个专家人类提供关于代理在任何给定时间点正在做什么的更好信息，以及直觉，然后如何让人类能够实时地纠正、改进代理的行为，这取决于任何人对它应该是什么样的猜测。所以，是的。>> 当然。>> 是的。>> 是的。关于分支代理，这很有趣。我认为重要的是要澄清，分支代理肯定会成为现实。事实上，它已经存在了。Cloud Code就是一个很好的例子。但即使如此，人们仍然将其渲染成线性的聊天历史，因为这对人类来说更容易理解。正是如此。>> 所以，实际的可视化不是这些花哨的D3>> 图表，你可以在其中拖动和反应等等。>> 正是如此。>> 可能存在一个对人们有帮助的可视化，但它还没有流行起来。所以，嗯，我认为这是一个很好的结束点。所以，非常感谢你花时间。听到你们在Chroma所做的一切都非常有趣，我感谢你邀请我。>> 这太棒了。谢谢。