Bridging the Gap Between AI and Business Data // Deepti Srivastava // #325
57:13 Share

如果你可以在所有数据系统（数据库、数据仓库等）和你的LLM系统之间放一个盒子，然后用直线连接它们，那该多好。哦，你需要Salesforce的数据？我们会帮你获取。你需要Postgres的数据？哦，我们会帮你获取。你需要Snowflake或Databricks的数据？我们会帮你获取。

我叫Deepti Srivastav，我是Snow Leopard AI的CEO/创始人，我们正在构建一个智能数据检索平台。我喜欢加牛奶和糖的咖啡，你可以为此来批评我。

你刚才提到，在大流行期间，你参加了我们的一次虚拟在线会议，主题是MLflow。我想我 точно知道你指的是哪一个，因为它后来上传到YouTube后成为观看次数最多的剧集之一。我认为这是因为它触及到了痛点。这期节目讨论的是Kubeflow和MLflow的区别。哦，很有趣。是的，也许吧。

这非常令人困惑，尤其是在2020年那个时候，人们并不真正理解这两个工具，也不知道何时使用哪个。Byron参与了讨论，他解释说，Kubeflow像一把大锤，而MLflow像一把小镐。所以，它们都是很棒的工具，只是取决于你想完成什么任务。所以，我觉得这太棒了。听到你在那些日子里就关注了MLOps社区，这真的非常酷。当时我并没有那么兴奋，或者说我并没有真正参与其中，实际上，我对这个社区很兴奋，但我当时甚至还没有加入。我想，哦，这很有趣。将来我应该查一下。结果，五年后，四年半后？我们在这里见面了。这太令人兴奋了。

这是一个完整的循环。我认为非常酷的一点是，正如你所说，即使在那些日子里，我们也在讨论你一直在听取和与人们讨论的这个问题。你能解释一下这个问题是什么吗？然后我们可以讨论不同的论点。是的。有很多方法可以谈论这个问题，但问题的核心是，

在这个新的LLM时代，我们期望AI成为一个万亿美元级的全新产业，一个新的平台转变。顺便说一句，我对此深信不疑，这就是我为什么来Snow Leopard的原因，对吧？就像，我对此深信不疑，大约在ChatGPT真正爆火的时候……

当ChatGPT真正爆火的时候。是的，当炒作发生的时候，我就像，因为我不喜欢炒作。我是一个系统。所以，退一步说，我是一个分布式系统工程师。我一生都在从事基础设施工作。我们反对炒作。只是，你知道，我们就像，我们是早期采用者的对立面。让我们这么说，嗯，

因为我们关心生产和99.999%的可用性以及所有这些东西。你不能只是说，“哦，是的，让我们尝试新事物，看看一切是否顺利”。是的，让我们扼杀这种想法。是的。所以我来自这个领域。我认为这很重要，因为正如我所说，我不相信炒作。但是当我看到它并尝试使用它时，我只是觉得，不，这确实是一个平台的转变。我以前也辅修过人工智能，在本科的时候。我想，这是炒作。是的。所以问题是……

我的意思是，这确实是一个平台的转变。LLM使许多我们以前认为不可能的事情成为可能。但是，我认为问题的核心在于，

为了让LLM成为它们所是的平台转变，为了让生成式AI，为了让AI应用真正改变人们的生活、工作和行为方式，你需要将它们连接到任何企业或任何用户情境的“皇冠上的明珠”，对吧？那就是

运营数据。运营数据指的是结构化数据。我的意思是SQL、NoSQL、基于API的信息，对吧？今天，运营数据和基于LLM的应用程序之间仍然存在巨大的差距。这正是我创建Snow Leopard时想要解决的问题。

所以，A，我100%同意这个观点，

为了让AI实现其炒作的承诺，我们需要将其连接到所有这些数据。我认为这并不是最辛辣的观点。每个人都在这么说，他们几乎在所有不同的社交网络上都在不停地说。我们必须拥有自己的数据，我们必须拥有自己的模型。这就是我们看到的理论。我，

另一方面，我认为你所说的真正令人着迷的是，我们需要能够将其连接到目前我们不一定连接到的数据。除非是，我们已经看到了一些用例，例如文本到SQL代理，或者你有你的数据分析师，所以你使用LLM来查询你的数据库，诸如此类。但是我觉得我们……

看到的更多情况是，构建全新的生成式AI应用程序，这些应用程序位于你的结构化数据之外。所以它正在将生成式AI和LLM连接到你的Notion或你的文档，或者试图让Jira与之协同工作。它并没有真正考虑将其连接到你所说的数据库或API。是的，那是对的。所以

你说得对，每个人都在谈论你的数据应该被摄取，对吧？我们应该连接它等等。但我认为我们正像你所说的那样，重点一直放在与你的PDF聊天，对吧？是的。这是一种在之前不容易实现的事情，但是，

我认为你提到了非常重要的一点，那就是在你的关键路径之外构建应用程序，永远不会真正产生新的用例、用户价值、业务价值等等。所以你必须使其成为你关键路径的一部分，以便它真正地

正如你所说，实现其炒作的承诺，对吧？所以今天一切都在边缘，对吧？其中一件事是，你知道的，当我开始与人交谈时，所以在创建Snow Leopard之前，我就验证了这个问题。我知道这有点违反直觉，但这正是我做事的风格。但是当我开始与平台副总裁或像所有这些公司（企业公司、中小型企业）的人工智能主管，以及我网络中的人交谈时，他们都说，你知道的，我们没有一个好方法，

将它放入我们的真正堆栈中，对吧？正如你所说，有很多讨论说一个新的堆栈正在出现。就像，每当出现一个新的堆栈时，它都超出了现有堆栈的范围，老实说，对吧？根据我20年来为企业构建数据基础设施和系统的经验，对吧，生产级数据系统，你必须……

所有东西都存在于生态系统中。它存在于一个上下文中。如果你想获得价值或创造新价值，无论是对用户还是对企业，对吧，你实际上必须成为这个独特生态系统的一部分。你必须融入其中。你不能只是说这是个很酷的新事物，然后让我们在这里采用它。但是你的整个世界都在这里。是的。是的。

我认为这是关键，对吧？我们可以深入讨论这个问题，但我确实相信还有一点，虽然人们说，你知道的，你应该将你的LLM、你的代理和你的助手连接到这些数据，但我根本上相信人们目前采用的方法无法解决这个问题。

这很有趣，因为我立刻想到了这个画面，我住在德国，前几天我开车走在街上。你猜怎么着？有一队摩托车，上面装有边车。感觉上，我们对生成式AI的处理就像摩托车（生产系统）的边车。是的。嗯，

你知道的，让我们深入讨论辛辣的观点。我有很多，但是就这样吧。嗯，但我认为人们今天做这件事的方式是，嗯，RAG（检索增强生成），这个概念听起来不错。对。嗯，还有你所说的另一件事，你知道的，你训练你自己的LLM，你做所有这些事情。对。这两种选择实际上都不能让你到达你想要到达的地方。对。所以，嗯，

辛辣观点一：进行ETL并将所有数据放入湖、仓或海中实际上并不能解决问题。辛辣观点二，这是更重要的辛辣观点，那就是

我们谈论的是智能将解决这个问题。代理将变得自我意识等等。我们会出去做事。这很酷。我不反对。但问题是，今天最智能的机器——人类——并不能做出正确的决定。无论他们多么聪明，无论他们的推理能力多么强大，无论他们多么擅长推理，所有这些东西。今天的智能……

不知道如何用坏数据做出正确的决定。顺便说一句，坏数据也等于陈旧数据。如果我问你，如果你昏迷了六个月，我问你，美国总统是谁，或者另一个国家的首相是谁？在我告诉你这个信息之前，在你谷歌搜索、Perplexity搜索、OpenAI搜索之前，你不知道答案。你无法做出决定。

对吧？所以如果今天的智能，今天最好的智能做不到这一点，对吧，无法在正确的时间获得正确的数据做出正确的决定，这些词很重要，正确的数据，正确的地方，正确的时间，对吧？在你做到这一点之前，人工智能将无法做出正确的决定，对吧？就像，我们只需要，推理并不能解决所有问题，这就是我想表达的观点。我知道这是一个

这是一个反文化观点，特别是对于这个听众来说。但我真的想帮忙。我真的很想让这种智能更智能，对吧？更有用。是的。我不认为说推理不能解决所有问题是反直觉的。因为我们一次又一次地看到，你提供给模型的上下文越多，

你越有可能完成任务或得到你想要的答案。所以，再次强调，如果你无法以上下文的形式提供正确的数据，

即使你提供了大量数据，但它不是正确的东西，那么结果就会很糟糕。我们经常谈论幻觉。是的，在LLM的构建方式中存在固有的原因会导致幻觉。我同意这一点。但老实说，很多幻觉都是因为你没有获得正确的数据。它只是试图像人类一样回答问题，人类也会产生幻觉。如果我们在错误的时间获得错误的信息，

我们会产生幻觉，对吧？我要说的另一件事是，你刚才说，对吧，上下文越多，如果给它太多数据，它也会得出错误的结论，对吧？因为它不知道该关注什么，这对人类来说非常直观，对吧？就像，如果你向我扔一堆数据或信息，而我不知道该关注什么，我的意思是，我可能会选择错误的东西，对吧，然后开始走错路。所以，

再次强调，这些都是非常……正如你所说，它们并不性感，但在我看来，它们非常重要，再次强调，作为一个无聊的基础设施人员，要让所有很酷的东西都能被构建，对吧？我们仍然只是在边缘徘徊，直到我们像，

真正地将正确的数据从正确的地方在正确的时间带到这些系统中，无论它们是助手、代理还是下一件大事，对吧，在推理和人工智能方面。就像我们不会真正地，我们只是触及了皮毛。是的，这是真的。大约三个月前，我们邀请了Dane来这里，她谈到了

让代理说“不”或说它没有获得所需的信息或它不理解你要求的任务有多么困难，这与你所说的幻觉问题有关，因为你要求它做某事，然后如果它没有完全理解或你使用的术语含糊不清，那么它就会返回什么

一种解释，这种解释可能与你想要得到的解释相同，也可能不同。然后你会想，这完全是胡说八道。所以你必须弄清楚如何解决这个问题。他们所做的是，他们说，我们将创建一个我们正在使用的所有术语的词汇表。我们需要确保没有含糊不清之处。

这些词和这些关键术语的定义不能含糊不清。它根本不能含糊不清，当人类阅读它时，他们会认为，哦，这很好。然后当你尝试对其输出进行评估时，你会看到，哦，是的，我想它并没有真正理解我的意思

创建一个好的摘要。什么是好的？这是对的。主观的。对。我，就像，我认为这里有两件事是我，我相信是关键，对吧？一个是，想象一下，就像，想想他们做了多少工作，它仍然没有产生正确的答案，对吧？因为它们本质上是某种程度上，所以，所以这就是我认为我们正在做的事情

对我来说很有趣的原因，因为LLM实际上非常擅长对事物进行模糊解释，对吧？就像它们实际上非常擅长总结，就像，你知道的，分类，那些本质上需要一些推断的事情，如果你愿意的话。但是它们不擅长点查找、点解决方案、所有情况下的特定是非答案，对吧？现在，是的，你可以，你可以

微调它们，你可以进行强化学习，它们会越来越接近你想要的结果，对吧，但首先，并非每个人都有时间、金钱和专业知识来做到这一点，其次，如果你再次给他们提供正确的信息，他们实际上会做得很好，我会不断回到这一点，让他们做出决定，这就是我认为LLM在某种程度上受到批评的原因，因为

因为最终每个人都在使用RAG来做这件事。今天RAG的执行方式是将大量数据放入向量存储中，然后使用向量存储在查询时构建上下文。但是向量存储本身就是模糊匹配系统。它们不是点查找系统。它们不是精确答案系统。

它们的目标是进行模糊匹配，对吧？就像，无论你是否用S或Z拼写Demetrios，它们都会得到相同的……它们可能会给出两个答案，因为它们，你知道的，对它们来说，它们就像，哦，这些很相似。你想要相似性搜索。就像，这里，这两个很相似。现在你弄清楚吧，对吧？所以，就像，我们正在……

首先，所有真正有助于实现这一目标的信息，正如我一直在说的那样，“皇冠上的明珠”都在你的数据库、数据仓库、你的Salesforce、HubSpot等基于API的系统中，对吧？如果你提取它们，你改变了它们的性质，你失去了业务上下文，然后你将它们放入这个向量存储中，对吧？

所以现在它们实际上已经失去了所有结构，那些精心设计的信息已经存在于这些系统中。就像你完全失去了它，对吧？它在某个blob中，在某个本质上是模糊匹配的系统中。

然后你从那里提取它。所以它不仅陈旧，而且还遭受所有ETL和反向ETL问题的影响，它还遭受了你将其从存在的上下文中移除的影响。你把它放在一个与其他数据不同的上下文中。然后你把它提供给LLM，然后你说，好吧，除了“好”的定义之外，它根本不知道是否以及如何回答这个问题。所以我想……

在微调方面有一些说法，例如，给我一个是非答案。但是，你知道的，模型的发展方向是，如果你只是告诉它们不要，就像，如果你不知道，就告诉我，我不知道。就像它们今天会告诉你那样。模型在这方面越来越聪明了。对。所以你需要做的是，无论如何，再次强调，无论它们变得多么聪明，如果它们不知道你在问什么，它们就无法给你答案。是的。

我确实喜欢这种几乎……我认为这就像压缩损失，当你提取它，进行ETL处理以及所有这些事情时。我还认为这让我想到了一件事，我已经思考了一段时间了，那就是你最近很少听到关于RAG的消息，因为代理很流行。是的。下一波潮流。是的。

炒作，没错。你只需将它们连接到你的MCP服务器，你就可以了。然后我们都会对结果感到满意。它改变了世界和我们的工作方式。但是，当我谈到RAG或我们如何使用LLM来创建有价值的产品时，我一直在反复思考的一件事是，

使用它们和新产品，本质上是新产品。这不像我们抓取一个LLM并将其放入我们传统上使用ML的欺诈检测系统中。对于RAG，我一直有点觉得好笑，因为我会想，我们只是……

过度设计了这个东西。我们只是直接地，我们正在创建所有这些不同的技巧。所以一开始是幼稚的RAG，然后它变成了高级RAG。然后我们说，不，我们必须做图RAG，因为在每个阶段，在我看来，我们都达到了这个阶段，我们认为这将帮助我们创建

创建一个更好的系统，并提高输出的可靠性和一致性。然后在某个时候你看到了……

结果，你意识到，我的意思是，它很好，是的，它很好，但它真的是我们需要的吗？也许让我们尝试新的技术，也许那里有更好的技术，或者也许我们可以对它进行更多设计，以尝试获得更好的结果，这是

因为模型所处的阶段。我确实认为，随着新的推理模型的出现，我们可能会看到由于这些原因而产生的巨大飞跃。但这总是让我觉得好笑，哦，感觉上我们不得不费尽心思才能让它真正发挥作用。我还觉得好笑，因为我们所做的所有工作，所有费尽心思去创建一个可以告诉你公司人力资源政策的聊天机器人，都是不值得的。这一点非常清楚。我很高兴你提到了这一点，因为这，

高兴，但就像它只是与我产生共鸣，这就是我的意思，因为是的，我已经在这个世界里待了这么久，忘记AI吧，就像

哦，我们现在需要这个数据。所以现在我们将创建一个复杂的数据管道来从A点到B点。但是，哦，我们忘记了这个N+1筒仓。对。现在我们必须像创建一个全新的管道。对。以及一种全新的ETL方式等等。首先，这需要几个月的时间，如果不是几个月的话，肯定需要几个月的时间。

然后，哦，顺便说一句，我们稍微改变了一下仪表板或用例，或者现在在AI世界中，稍微改变了一下问题，这需要调动整个团队来重新调整整个事情。就像，你说得对。我很伤心看到这些复杂的事情。

到处都是电线和管道。如果你看一个数据架构图，一个真正的数据架构图，而不是为了向某个决策者展示而制作的图。就像这样，它是由弯弯曲曲的线条组成的。我知道有一个播客，你看不到我像疯了一样比划，但是

它是弯弯曲曲的线条，有时你甚至无法分辨线条为什么存在，它通向哪里，发生了什么，对吧？它只是过度设计了，老实说，我的心都为那些试图维护、构建和增强这些系统的开发人员感到难过，对吧？因为你需要立即得到新报告的答案。由于你提到的许多原因，这些系统的设计方式就是这样，对吧？模型不够好。

数据系统不够好。它们的可扩展性不够好。它们不像任何到任何的连接。所以，是的，如果我们只用橡皮擦擦掉呢？这正是我在最初设计SnowRiver架构时试图做的事情。我只是想，擦掉，擦掉。如果你可以在所有数据系统（数据库、数据仓库等）和你的LLM系统之间放一个盒子，然后用直线连接它们，那该多好。

然后用直线连接它们。哦，你需要Salesforce的数据？我们会帮你获取。你需要Postgres的数据？哦，我们会帮你获取。你需要Snowflake或Databricks的数据？我们会帮你获取，对吧？不需要这种疯狂的事情，因为……

根据我的经验，再次强调，在谷歌、甲骨文，甚至在Observable，观察人们如何在这些堆栈之上构建应用程序，他们花费了，开发人员、数据分析师、业务分析师，所有这些，整个数据工程师，花费了70%到80%的时间来做这件事，这意味着你没有花那么多时间来构建这些应用程序

新的价值创造应用程序、新的业务创造、新的，你知道的，用户价值机会，因为你把所有时间都花在了这件事上，那么如果你不必这样做，你可以花时间想出新的创造性方法来做事呢？

几周前，我和一位数据工程朋友聊天，他提到了他现在面临的困境，那就是在过去的三年里，他们的公司大力推动自助分析。所以这太不可思议了，你知道的，整个数字化转型的事情。他是一名数据工程师，所以他说，所以我现在加入了这家公司，我们有

超过11000个数据资产，工程团队必须维护或服务这些资产。所以他说，我们正在重新考虑整个自助服务的事情，并想知道我们可以炸掉什么，或者我们可以用橡皮擦擦掉什么，以及什么实际上是有价值的，或者它

超过了一定的价值阈值并且仍在使用，因为很多这些都是由某人构建的，那个人离开了，然后就没有关于这些仪表板是如何创建的知识共享。有一天它坏了，砰，那个人走了，你再也无法得到它了。如果你

它是自助服务的，所以它几乎就像，好吧，我并不真正喜欢那个仪表板，所以我将创建一个新的。我有一个更好的方法来做这件事，对吧？当然。所以你会遇到这些情况。但是，在这个你正在规划的世界中，你拥有所有数据源之上的抽象层，是什么阻止它也陷入这种蔓延呢？是的。

因为开发人员没有构建这种蔓延，对吧？我认为这里有两件事。一个是，我们不是说这是魔术，但我们说的是，与其让每个开发人员和数据工程师团队等等一遍又一遍地这样做，不如我们以通用的方式为他们做这件事，这样他们就不必构建、维护或构建管道了。所以我们实际上说的是，所以这再次是一个辛辣的观点，也许，

我认为这是，就像，你必须以不同的方式想象这个世界，然后看看你是否能够以某种方式到达那里，对吧？因为很多这种蔓延的情况来自，坦率地说，我所处的这个数据世界，就像，你知道的，数据增长速度超过了能够支持它的系统，对吧？所以然后就有了所有这些，就像，把它放在一个湖里，然后把它放在一个海洋里，把它放在一个房子里，对吧？所有这些事情都发生了。而且

说实话，ETL 很有用，尤其是在商业分析中，比如历史趋势分析之类的。但是现在人们已经有地方可以做这件事了，对吧？就像方孔圆钉一样，所有东西都放进去，所有东西都需要从那里出来，对吧？这是一种方法，会导致这种情况，比如，

我们有这种最终的孤岛吗？我们是否已经把它放入这个湖泊式数据仓库或数据湖中了？如果没有，我们就必须去构建它。对。然后正如你所说，有很多这些随机的仪表板。但我们想说的是，我在这里试图做的是，如果你不必移动数据会怎样？如果你可以在你提出问题时直接从源获取数据会怎样？

所以没有管道。我们并不是在构建管道。没有管道。只是连接到数据源，你需要时就去那里获取数据。这就像我问你一个问题，你去查阅

你最喜欢的搜索引擎并找到答案。你不会保留所有这些数据，下载它，像筛选它，过滤它。这些都没有发生。你只是说，嘿，你知道，我的出生日期是什么？哦，去你喜欢的数据库，你知道，一些社会保障数据库或其他什么东西，然后去获取它。是的。那么你如何处理诸如，好吧，我需要

很多关于我需要知道有多少客户做了 xyz 的数据点，但在源数据中

你需要在其之上应用几种不同的转换才能得到答案。我的意思是，这是一个经典的数据仓库问题。所以这些数据仓库已经建好了。我只是说你不需要构建新的管道、新的数据源和新的连接。因此，如果你正在做一些对你的业务很重要的工作，这就是原始数据仓库概念的来源，我们可以从该数据仓库中获取它。

但是我们也可以做到，而这正是今天通过复杂的软件或复杂的管道完成的，我们也可以做一些事情，或者我们应该能够做一些事情，比如，嘿，你知道，例如，如果你问我，

我经常这么说。我不在乎终结者会发生什么，对吧？例如，如果我在线订购了东西，我会关心我的订单在哪里，对吧？哦，说到这个，我前几天订购了一些该死的咖啡。结果，由于某种原因，我的旧西班牙房子的地址在谷歌上。所以现在西班牙的某个人得到了一些好咖啡。我不能这么说。

这太搞笑了。大约到第 10 天，我想，咖啡在哪里？我现在真的很需要它。但无论如何，对不起，我离题了。但这是一个很好的例子。就像在某个地方，某些东西应该更新了你的数据。是的。就像它没有发生一样。对吧？因为有人去了某个地方最终失败了。但关键是，我们说的是，如果你必须查找你的订单，就像问一下，对吧，你最喜欢的助手，我的咖啡在哪里？

所以，咖啡，它需要做两件事。你需要查找你的咖啡订单是在哪里下的，对吧？是的。无论是浓缩咖啡还是其他一些花哨的东西，对吧？然后它被运送到哪里，这意味着你现在基本上是在查看 Postgres 数据库或某种 CRM 系统，对吧？然后你也在查看你的跟踪系统，比如 UPS 或类似的东西。这意味着你应该进行连接。

两个外部数据源之间。所以数据库、数据仓库、数据湖都很擅长内部连接。如果你今天需要连接两个数据源，你必须将数据转储到一个地方，以便它们可以进行跨门连接。但我想说的是，你实际上需要做的事情，一个人会做的事情是，基本上从你的订单管理系统中查找你的跟踪号码，然后在交付系统中查找跟踪历史记录。

是的。Snow Leopard 可以做到。Snow Leopard 的目标是你可以从这两个地方提取数据并给你一个答案。所以你不需要构建任何管道。如果你正在构建助手或代理流程，你不需要创建任何新的回答这个问题的方法。你只需要向 Snow Leopard 提问，Snow Leopard 就会说，哦，我需要。所以它正在进行智能路由。它说，哦，我需要去这两个不同的来源。对。然后它正在进行智能路由。

查询构建，就像，哦，对于 UPS，我需要编写这种类型的查询，因为它是一个 API，而对于……

你知道，Salesforce，我需要编写一个 SoCal 查询，而对于 Postgres，我需要一个 Postgres SQL 查询，对吧？这与 Snowflake SQL 查询不同，与数据库查询、Databricks 查询不同。所以它实时构建了它。然后它直接从这些来源获取数据。这意味着数据是新鲜的，这意味着如果，你知道，如果咖啡在过去半个小时内被送到了西班牙，你应该能够获得该信息，而不是它仍在运输中。然后你第二天再回去查看它，因为，你知道，

是的。数据转储已经过时了。这就是我们所说的世界。这就是我们想象的世界。这就是我最近与 Salesforce 的 C2 交谈的地方。我和宝洁的亚洲数据和人工智能主管谈过。就像你刚才谈到的那些事情，他们也在处理同样的问题，对吧？比如 8000 个数据孤岛。

哪个仪表板支持什么，对吧？让我们简化一下，因为我们需要弄清楚如何维护它，对吧？而且我们的数据工程师正在为此而苦苦挣扎，我们的数据科学家也在为所有这些而苦苦挣扎。所以，是的。

是的，我们甚至没有触及数据质量部分，比如，哦，上游发生了一些变化，现在数据完全没有价值了，因为这些仪表板的构建方式。我想知道这种工作方式的愿景中的一件事是，仪表板在这个世界中是否仍然发挥作用？还是只是问题？我现在必须知道我问的是什么类型的问题。

我才能得到答案？因为我认为有时当我查看仪表板时，它会在我心中引发问题。我认为这是一个非常有趣的人生哲学问题。我认为对此有不同的阵营。同样，作为一个基础设施人员，我不喜欢预测未来。但是我在 Observable 的工作，这是一个数据可视化平台，我们都是视觉型人。所以

对。像图表上的数据点比一千个数据点更容易理解。我们只是知道这一点。那么仪表板会消失吗？不，我不这么认为。我认为数据可视化将永远存在，因为这是人类理解信息的最简单方法。但是如果你可以用问所有在你查看仪表板时出现在你脑海中的问题来增强它会怎样？

因为你可以获取数据（如果数据存在的话），所以你不需要……我举个例子，当我查看谷歌产品的流失率时，对吧，我首先必须……首先，我没有……我没有合适的仪表板，我必须构建仪表板，所以我提出了一种关于我们需要什么类型的数据的解决方案，等等，然后我必须与我的

商业分析师朋友交谈，顺便说一句，他很疲惫，因为他实际上负责 10 种不同的产品。我必须进入他的事情，进入他的工作流程，比如，嘿，我想构建这个流失率仪表板，需要从这里、这里、这里提取数据。你能帮我构建它吗？现在，在他三个星期后为我构建它之后，我看了看，我想，哦，我实际上需要知道像

按地理位置划分的流失率，东南亚的流失率，美国、加拿大市场的流失率。事实上，更深一层的是，你知道，行业的流失率也是如此。

所以每次出现这个问题时，都需要几周时间才能得到答案。他要么必须将其构建到数据仓库中，要么必须花时间将其提取出来并给我。但是如果我可以在你有了仪表板之后，如果我可以与，让我们假设它是 BigQuery，所有数据都存在的地方。我可以与我的 BigQuery 聊天，我也可以将其连接到所有包含

最新客户信息的 Salesforce 数据？如果我可以做到这一点，并且系统会为我处理这件事会怎样？对。顺便说一句，我们在这里也在谈论代理流程。对。像代理流程一样有同样的问题。第三个辛辣的观点是，虽然 MCP 非常棒，并且它是一个伟大的开始，开源的连接器问题开始。

它没有解决。对。我相信它也具有前几代解决方案所遇到的所有相同问题，那就是它并没有真正解决问题的最难部分。而问题的最难部分总是智能路由。

更重要的是，业务逻辑。我之前提到过我们这里有 Doneon，她构建了一个数据分析师代理。他们用来控制代理的方法，我们可以说，是……

他们为不同的代理设置了不同的 Slack 频道，这些代理可以访问某些数据库。你将拥有一个营销 Slack 频道，它可以访问营销数据库，并且在那里进行营销类型的查询。这几乎是他们能够硬编码的方式。是的。

嘿，代理，你说这种 SQL 方言。你可以访问这里的这种类型的数据库。这是你的词汇表，正如我们之前提到的那样。因此，如果出现任何这些关键词，你就知道它们是什么，并且知道在哪里获取它们并获取该信息。因此，他们能够做一些很酷的事情，并且

该代理可以创建 SQL 语句，并且可以说可以完成很多琐碎的工作。我想我记得他们说它像杠铃一样。大多数提出的问题都是那些不太复杂的问题，但它们并不是那些对数据一无所知的人会问的问题。它就像那些中等程度的问题。无论如何，整个故事是因为我想知道你如何确保代理或你的系统与正确的数据库使用正确的语言？是的，这是一个很好的问题。

事实上，你刚才描述的一切都是人们试图做到的事情。硬编码部分就像……这就是今天的工作方式。你必须硬编码，你必须分开，否则将 MySQL 方言的查询与 Snowflake 方言的查询混合在一起，即使它们都是 SQL，并且它们都遵循 ANSI SQL 标准。

会把所有东西，系统，整个系统，包括 LLM，搞得一团糟，对吧？这实际上也是为什么文本到 SQL 也无法工作的原因，对吧？除了它会产生幻觉和所有那些东西之外，它只是哪种方言以及在哪个方言中允许什么。这对于开源数据库来说效果更好，因为 LLM 已经经历了这一点。但是对于闭源数据库来说，这就像一场噩梦。我知道，因为我们一直在做这件事，对吧？所以我们正在做的是

我们正在使用已知的数据基础设施技术来做本质上是系统问题的事情。我们不试图将系统问题塞进推理 AI 预测世界。正如我之前所说，LRM 擅长分类、总结和那些类型的任务。确定性系统擅长

如果你以正确的方式编写它们。它们擅长点查找，并且能够完成精确和确定性的工作。当你为正确的方言构建 SQL 查询时，你正在进行精确和确定性的工作。所以我们基本上使用的是数据检索技术，不是在 IR 中，而是在数据检索技术中。所以我们正在构建

例如 SQL，如果你在谈论 SQL，对吧？就像我们正在为正确的方言构建 SQL 一样，对吧？根据查询需要去哪里。我们以确定性的方式进行操作，这意味着我们使用的是像数据或某种查询构建技术。查询构建技术是存在的。像数据库使用查询构建器一样，对吧？数据仓库使用查询构建器。许多数据检索系统使用查询构建器。我们正在做

使用这些技术，并使用现有的方法，例如，ORM 非常擅长这样做，对吧？所以我们使用这种现有的方法来构建像 PostgreSQL 查询与 Snowflake 查询。我们今天正在做这件事。我们有一个设计合作伙伴，其数据存储在某种

专有数据仓库中，我们只是为其即时构建查询，对吧？那么你需要在哪里进行这种智能检索呢？哦，你知道，根据这个问题以及我对业务逻辑的理解，我们知道查询需要转到 Postgres，并且还有一个单独的查询需要转到，比如说 BigQuery

有趣。我们构建了这两个。一旦我们知道了，对吧，那么其余的就是确定性的，对吧？就像其余的是，哦，构建一个 PostgreSQL 查询，构建一个 BigQuery SQL 查询。所以我们这样做。这就是我认为令人兴奋的地方，我们正在使用数据系统和确定性编程技术来完成这部分工作。我们正在使用

你知道，AI 和代理工作用于路由中的智能和我们需要获取哪些数据。理解。如果我理解正确的话，那就是 AI 达到了某个点，它获取查询，然后说，好吧，很酷。

为了回答这个问题，我需要使用这些工具。然后砰的一声，当它将其发送到工具时，它就会退回。它实际上并没有创建 SQL。我认为这是一个非常好的方法，因为你从 LLM 中承担了很多责任。任何处理过 LLM 的人都知道，你给它们的责任越少越好。

除非你做一些非常孤立的事情，就像我说的那样，捐赠创建的地方，你在营销渠道中，我知道这个代理只能访问营销数据库，它直接去那里，他们选择让 LLM 执行 SQL 查询，但他们也有很多

调用 LLM 来像仔细检查查询并执行此操作，因此它会稍微回到那种笨拙的状态，好吧，很酷，是的，我们这样做，然后当返回某些内容时，他们也会仔细检查它，以确保嘿，根据这个问题，这个 SQL 查询和检索到的数据是否合理，因此你将拥有一个批判性代理来仔细检查所有这些，但在你的情况下，你正在说

LLM 只用于理解查询，然后启动它需要的不同工具。对。这有点像你今天在 MCP 代理世界中描述它的方式，对吧？但我们不仅仅是在启动工具调用。我们也对该工具的创建方式和该工具的准确性负责，对吧？例如，当我们进行内部基准测试时，

我们使用的是一个较旧的、有点破旧的系统，大多数这些东西都是这样工作的。就像我们有 99.98% 的准确率一样。这是在我们没有对我们自己的情报进行任何微调的情况下。我们比较的系统对于这种基于 SQL 的查找的准确率只有 6%，对吧？因为它要么不知道如何构建正确的 SQL，要么没有获取正确的数据，要么它在产生幻觉。所有这些事情都不会。

就像你一样。但除此之外，我想回到 Donae 正在构建的用例，对吧？我们为这里的设计合作伙伴所做的事情就像那个 Slack 频道实际上可以被销售和营销人员使用一样，对吧？如果你可以拥有它会怎样？因为

事实证明，销售和营销人员围绕管道部分以及一直到销售和售后部分提出的问题类型有很多重叠，对吧？围绕客户数据以及所有这些类型的事情。如果他们两个都可以提问，那么我们就不必了。而且你不需要硬编码任何东西，对吧？然后你实际上……

打开这个全新的世界，他们甚至可以互相交谈，并为达成销售制定更好的活动和更好的端到端工作流程，对吧？所以我认为我所想象的是在这个临时提问和临时信息需求的世界中，为什么不使信息检索临时呢？为什么不使数据检索临时呢？对吧？

所以我们正在做的是，我们有一个自然的，你知道，在数据世界中，对吧？所有这些都像单个 API 来获取所有内容一样，这从未奏效，因为，对吧？你刚才谈到了众多问题之一，那就是在这个单个 API 的末尾构建哪个 SQL？但是如果 API 是自然语言，这就是它所变成的样子，但它会转换为精确的，就像你所说的工具一样，对吧？它会转换为这些工具使用的精确方言。所以工具不会做任何猜测，对吧？

对吧？API 不会做任何猜测，对吧？你将智能用于需要使用的地方，理解和，哦，我认为它需要去这里并这样做。然后你将其余部分留给知道如何做它的部分，这再次导致更高的准确性。我不太明白。你如何区分工具调用部分和

对结果负责，好吧，我们正在进入任何数据库，无论是 Airtable 还是你选择的 CRM，我们都确保它将正确收集数据。或者我认为你说过类似的话，我们对其进行身份验证或授权，它将是正确的。哦，是的。我认为我们只是对准确性负责。对。所以

所以 Snow Leopard 是一种三部分的工作流程。第一部分，更具体地说，让我们深入研究一下，对吧？第一部分就是你所说的。你有一个问题，我们进行自然语言理解。这里没有火箭科学，对吧？或者这里主要是 AI。然后下一部分是，我们结合数据基础设施逻辑、你的业务逻辑，来确定需要进行哪些 API 调用。这是我们专有的做事方式。

或者更确切地说，这是我们正在构建的智能，对吧？然后一旦我们确定，或者它需要获取用户 ID，例如，在你的情况下，它需要从一个地方获取你的姓名、地址和订单号，对吧？这是你的，让我们假设，CRM 系统。它需要从交付系统中获取订单信息和运输信息，对吧？

对。一旦我们知道了这两件事，这就是智能告诉我们的。然后构建正确的查询，就像我们没有进行文本到 SQL 一样，对吧？所以那里没有模糊性。我们实际上是在说直接为这个特定的方言构建 SQL 语句，我们去构建它。

对。所以我们基本上使用的是像常规编程一样，像系统编程来做这件事。然后我们去在那个系统上运行它。所以，你知道，如果你在一个 PG SQL 数据库上运行一个 PG SQL 查询，它会给你信息。对。这是已知的。是的。然后，是的，我们可以通过评估系统运行它等等。对。这再次是人们已经做过的一些已知的事情。

但是没有像，哦，它是否获得了正确的数据？我们有这一列，但是这一列是否存在？我不知道。当你进行文本到 SQL 或某种代理流程时，你会这样做。工具必须……你将很多责任交给工具，工具开发人员必须承担责任。而且你不知道工具开发人员是谁，对吧？第一。第二，不同的工具开发人员。所以 Postgres 的 MCP 服务器可以由任何人构建。

对。所以因为没有像你必须这样构建它一样，MCP，协议和 MCP，某种开源框架并没有告诉你必须这样做，这意味着不同的人可以解释该框架并构建不同的 MCP 服务器。

对。所以要么你，就像任何其他开源软件一样，要么你使用某人的 MCPC 服务器，然后你强化它，你测试它，你按照你想要的方式修复其中的东西。对。或者你只是依赖他们做正确的事情，任何在开源世界中的人，比如

对吧？这只是最后的 20% 是所有 80% 的工作所在，对吧？在强化它。这里还有一点是，我们正在承担理解你告诉我们的业务逻辑的责任，对吧？而 NCP 服务器只是一个连接器，对吧？是的。所以它只会做，如果你给我

像 SQL 查询一样，我会在 Postgres 上运行它。但是像运行哪个 SQL 查询？这是要运行的正确的 SQL 查询吗？它是否理解大写 O 的列订单 ID 与小写 O 的列订单号是否不同？它会下降到这种混乱和复杂性的程度，对吧？这就是我们试图做的事情。是的，MCP 服务器的缺点就是这样。我很感激你这么快就指出了这一点，因为它非常……

很容易建立一个 MCP 服务器。这就像福与祸一样。是的，100%。这可能是它现在如此受欢迎的原因，因为人们可以在几个小时内建立一个 MCP 服务器。没错。但正如你所说，如果你不了解并且非常了解你的 Postgres 数据库的来龙去脉，你就会建立一个有很多工具的服务器

而这些是关于工具如何工作的你的观点。你可能会给自己带来麻烦。或者如果我来获取你的 MCP 服务器，我认为，好吧，很酷，这是一个 Postgres MCP 服务器。我将……

把它扔到我的研究生实例中，是的，可能会发生一些线路交叉，是的，我同意你的观点，我认为这是一种福与祸，对吧？就像我一样，我并不是想贬低它，我只是想指出，因为人们会将自己情感上依附于下一件大事，下一波炒作，然后他们会非常失望，对吧？我，我

我希望人们只是理解并敞开心扉，对吧？就像，如果存在 MCP 服务，对于 Snow Leopard 来说实际上是很棒的，因为如果一个变得流行，它实际上会帮助我们，因为我们不必再构建连接器了。所以它实际上加快了我们的用户交付速度，老实说，对吧？但我只是希望人们知道，就像，

你知道，有一些你想要注意的盲点。你想要睁大眼睛。玩起来很有趣，但在我的经验中，构建像那些高可用性、高可靠性生产系统需要比，你知道，在几个小时内将某些东西组合在一起更多，对吧？那不是难点。难点是，再次，从 POC 到生产，对吧？我认为这仍然是工程领导者、CTO 向我谈论的问题，你知道，我们构建了这个很酷的东西。我们无法将其投入生产，因为可靠性、准确性和，你知道，性能现在甚至都不是问题，它只是可靠性和准确性。就像我需要在我需要回答问题时以相当准确的方式回答问题一样。

是的，只要答案正确，我们不介意等待 15 分钟才能得到这个答案。那么，在我们离开之前，你还想谈谈其他什么吗？我只是认为我们现在生活在一个非常令人兴奋的世界中。我认为 MCP 的存在以及围绕工具等所有这些讨论的事实意味着人们终于开始理解

真正开始理解我所说的内容。我脸色发青。如果你查看我去年在 LinkedIn 上发布的内容，你会发现，但是你需要你的结构化数据系统。你需要它们。所以我个人非常兴奋地看到人们开始注意到这个问题，并开始关注这个问题，因为我相信这将导致真正的 AI 浪潮，让人们的生活变得更好。但是是的，我真的很兴奋能与那些面临这个问题的人交谈，他们

我想，例如，Danae，听到你谈论他们在那里所做的事情非常令人兴奋，因为我实际上只想了解人们是如何解决这个问题的。他们有这个问题吗？他们是如何解决这个问题的？对。我们可以帮忙吗？这是一个非常令人兴奋的时刻，在这个领域中。我一直在说的最后一句话是，

你知道，我一直告诉我的系统朋友们，嘿，来 AI 方面吧。没关系。我知道它是非确定性的，我知道你讨厌它。就像，哦，绝对不行。来吧。这里很有趣。我真的很……我觉得有些人开始注意到了，这让我很兴奋，因为我希望 AI 世界和系统世界能够走到一起，因为这就是我们将要解决这些问题的方式。

是的，我得把你介绍给多内。对于任何想查看它的人来说，网址是snowleopard.ai。我喜欢你在做的事情。我认为它超级酷。我很高兴看到它的进展，并生活在一个拥有无限连接到所有这些不同数据库的世界里。所以我可以，我现在实际上有一个正在考虑的用例，我昨天一直在问自己很多不同的问题。而且我

我必须去收集Airtable和Salesforce之间的数据。我真的很不擅长Salesforce。所以它花费的时间比应该花费的时间长得多。然后你就会陷入……

哦，我不知道我是否有权访问这些数据，这肯定不会被Snow Leopard解决。但我必须去和某人谈谈，说，嘿，我的报告需要这个，等等。所以是的，数据很有趣。数据确实很有趣。我很期待Snow Leopard能够消除大部分痛苦的世界。是的，谢谢你。和你交谈真开心，迪米特里奥斯。非常感谢你邀请我。是的，我认为人们应该谈论这类事情。这非常令人兴奋。还有更多的事情。