“专用向量数据库的生存空间已经快没了”编译 | 王启隆出品丨AI 科技大本营IDrgznai100这两年AI 圈里有一个越来越明显的错位。一边大家还在为上下文窗口越做越大兴奋100 万、200 万仿佛只要能往模型里塞进更多东西问题就会自动消失。另一边真正开始把 AI 系统往生产环境里推的人越来越容易撞上一堵墙问题从来不只是信息够不够多而是这些信息彼此到底是什么关系。一个 chunk 为什么会被捞出来每一段话是谁写的一条权限对谁生效这份文档为什么重要这个答案到底是沿着什么路径长出来的如果这些东西始终只是散落的文本那么上下文再长很多时候也只是更大的噪音池。可一旦信息开始带着实体、关系、权限、作者、来源和历史进入系统问题就完全变了。AI 要的也许不是更多文本而是一层能把文本重新组织起来的结构。这也是为什么图Graph在这个时间点重新变得重要。最近一期 Latent Space 播客请来了 Neo4j 首席执行官Emil Eifrem。Neo4j 是图数据库领域最有代表性的公司之一Emil 则是过去很多年里持续推动这套技术路线的人。放在今天的语境里这已经不只是数据库圈子的旧话题了因为图数据库正重新卷进 GraphRAG、知识图谱、智能体记忆、上下文图谱这些 AI 系统里越来越核心的问题。这场对话最有意思的地方在于它没有把图说成一种神秘的新答案反而把一件事讲得越来越具体AI 系统需要的不只是 top-K chunks而是带结构的上下文。GraphRAG 也不是把向量检索替换成另一个流行词而是让系统先从语义相近处起步再沿着真正有意义的关系继续展开。这样得到的东西不只是更准也更容易追问更容易调试更容易解释。Emil 在这场对话里一路讲到 Neo4j 的来路讲到图数据库和向量数据库的关系讲到知识图谱、Agent memory、context graph也讲到一个越来越清楚的判断未来很多 AI 应用也许都需要一层图状的上下文底座。名字可以很多但背后的方向其实正在变得越来越一致。要点速览AI 缺的未必是更多上下文很多时候缺的是上下文之间的关系。top-K chunks 可以把文档捞出来但解释不了它们为什么重要、彼此为什么相连。向量搜索解决的是“像不像”图更擅长回答“为什么是它”。GraphRAG 不是替代向量检索而是让检索命中之后还能顺着关系继续往下走。当 AI 开始进入权限、历史、作者、决策轨迹这些复杂地带纯文本上下文很快就会不够用。图数据库重新变重要不是数据库品类回潮而是 AI 系统开始需要一层更像知识结构的上下文底座。为什么“图”在当下至关重要主持人大家好我们今天在远程演播室连线了 Neo4j 的首席执行官 Emil Eifrem。欢迎你的到来。Emil很高兴来到这里。主持人这一刻我期待已久。你是第一届世界博览会Worlds Fair上最受欢迎的演讲嘉宾之一。去年我们又和你的团队一起办了完整的 GraphRAG 专场今年我们再次聚焦这个话题。如今你会如何向大家介绍 Neo4jEmil这取决于听众是谁。我想我们最广为人知的身份是一个数据库确切地说是图数据库。但时至今日它已经演变成一个远超数据库范畴的广阔平台。我通常会这样开场我们将数据炼成知识。这是一个实现该愿景的平台。当然这自然会引出一个问题你说的“知识”到底指什么毕竟这是一个定义模糊的词。我会解释说知识的本质是从噪音中提取信号并以一种“知识高密度”的方式呈现出来而“图”正是其中一种绝佳形式。毋庸置疑其核心依然是数据库但如今这个平台已经包罗万象了。主持人你们已经深耕这个领域有一阵子了。现在几乎所有人都在用你们的产品甚至包括伦敦交通局。这挺有意思的因为这本身就非常“图”——等你亲自去那里就会发现伦敦的地铁网络就是一个天然的图结构。Emil哈哈那当然。不过话说回来这取决于你的“图式思维”有多深——在图的视角下万物皆是图。主持人确实如此我自己也曾在这个“兔子洞”里沉迷过。十年前我刚开始学编程时参加了一个编程训练营。后来在某个大会的工作坊上我第一次接触到了 Cypher 查询语言和 Neo4j。我想很多人的 Neo4j 启蒙也是如此。今天我们想聊聊自那以后发生了什么广义上的“图智能”究竟是什么你们后来又构建了怎样的一套生态系统Emil我们先来谈谈背后的“为什么”。如果从 AI 工程师的视角来看你刚才提到了 GraphRAG 这个词现在人们很喜欢用它来描述检索过程——也就是在 R检索这个环节中引入知识图谱。这样做有很多理由。我从用户那里听到最多的呼声是它能带来更高的准确率因为你拥有了极其丰富的数据表征。其次出乎很多人意料的是它还能显著提升开发者的生产力。这里有一个潜在的前提那就是你得先有一个“图”我们待会儿可以细聊这个。但当你拥有了图并把它与向量空间进行对比时你会发现向量空间非常像一个黑盒。如果你搜索并找到了排名前 K 的文档你根本不知道为什么是它们。系统只会告诉你在某个余弦或欧几里得空间里它们的相似度是 0.7。相比之下图结构是极其明晰的你甚至可以直观地审视它。比如我有一个苹果和一个橘子它们之所以关联是因为它们都属于“水果”。但在欧几里得空间里一个苹果和一个网球的相似度可能也是 0.7仅仅因为它们都是圆的或者都是绿色的。你无从知晓原因。这就是第二个优势。然后我们听到的第三个强烈诉求是关于可解释性。人们非常看重一点与不透明的向量空间相比他们现在可以真正去审查系统究竟为什么选出了这 K 篇文档。主持人我好像没听到你提查询速度我猜这应该也是优势之一吧。但我思考图数据库时总觉得人们之所以想用它是因为你可以顺着图去游走、去遍历这大概比做一堆传统查询和表连接Joins要高效得多。这是不是一种比较老派的理解方式还是说这其实就是把你刚才的话换了种说法Emil我认为速度的优势其实已经内化到“准确率”里了。因为很多时候正是得益于极快的处理速度你才能在极短的时间内覆盖广阔的范围遍历并触及海量的文档或节点。你这个观察很有意思虽然我们现在确实很少听到客户把它拿出来单说。从 AI 工程师的角度或者在 AI 相关的应用场景中大家可能已经习惯了大模型本身就会吃掉大量的延迟时间所以“查询速度快”反而很少成为首要关注点。但正是因为速度快我们才有可能实现更高的准确率。所以我认为它们是息息相关的。主持人也就是说只要你有速度优势你完全可以多花一点时间去换取更高的准确率。Emil没错。Neo4j 的破局与向量数据库的余辉主持人酷。那么接下来我觉得大家经常会问的一个问题是作为一位保持中立的数据库 CEO你认为向量数据库怎么了为什么它没能成为一个……我该怎么形容呢持久的、或者说独立的品类现在每家数据库都有向量索引功能了我想说“作为独立品类的向量数据库已经终结”应该不算过分吧Emil我不知道这说法可能有点夸张了。几年前我就公开表示过我不认为它会是一个长青的数据库品类。至少不能作为一个纯粹的“数据库”品类存在它给人的感觉更像是“搜索”。这是我几年前的论断。不过让我惊讶的是目前似乎还存在某种长尾效应——我们依然看到很多早期的实验项目在尝试使用向量数据库。而且在极其高端的需求场景下某些专用向量数据库的表现依然优于其他数据库自带的向量搜索功能。你刚才说我是中立方其实我在这件事上并不中立因为 Neo4j 也内置了向量搜索功能。坦白说它目前还比不上那些专用的向量数据库。但随着每个季度、每一年的迭代这条及格线在不断提高。因此留给专用向量数据库的生存空间越来越少了。几周前你们采访了 Turbopuffer 公司我记得他把自己的产品描述为一个搜索平台或者说搜索工具。我认为这正是那些曾经自称为向量数据库的公司目前的转型方向。随着所有人都把向量搜索作为标配功能加入自己的产品“够用就好”的水平已经足以应对绝大多数场景了这进一步挤压了它们的生存空间。主持人我也觉得是这样。我认为大家在做宣传时都应该诚实地说明到底在多大的数据规模、多高的数据复杂度和基数下你们的产品才是真正卓越的在哪些场景下由于你们特殊的架构设计你们的解决方案能把竞争对手远远甩在身后如果在小规模数据下谁会在乎呢随便用什么工具都能跑通。但一旦达到规模化这些差异就变得至关重要了。Emil我同意。对我们来说向量搜索是这样融入体系的你有一个 RAG 语料库并且有一套数据管道将这些数据处理成可查询的状态最终喂给大模型。我们会利用这套摄取管道和向量搜索索引中的嵌入embeddings来填充我们的图数据库。然后在查询时我们通常会用向量搜索来找到图中的“起始节点”接着从那里开始进行图遍历。举个经典的客服场景Swyx 刚买了一台新笔记本发现权限设置有问题于是你去苹果的售后网站输入了你的疑问。面对这段自然语言系统通常会先跑一次向量搜索往往还会结合类似 BM25 的关键词搜索。这步操作可能会捞出比如说 100 篇文档。接着你从这些文档节点出发进行图遍历去获取完整的上下文。最后系统会进行综合判断它不仅仅看这些文档是否被向量搜索命中还会发现“原来这些文档是某位高权重作者写的”——这个权重可能是通过 PageRank 算法算出来的也可能只是简单的星级评分或类似信号综合这些因素你最终得到了最精准的前 K 篇文档。所以这从来不是“图搜索”与“向量搜索”的二选一而是向量搜索与图遍历的珠联璧合。这是我们目前看到的最典型的模式。主持人而且这里的工程实现其实极其困难因为你必须在无数的利弊中做权衡、权衡、再权衡。如果你有无限的预算当然无所不能但现实并非如此。所以抛开 Neo4j 不谈我认为业界有一个大趋势大家都在试图从数据摄取管道中榨取更多的信号以优化后续的查询……你可以称之为预处理总而言之就是在把数据丢进向量搜索之前尽可能多地提取出有价值的信号。Emil在向量数据库的语境里你们通常把这叫作“元数据”但它的本质其实就是结构化数据。我们也是这股大趋势的一部分。你可以把“图”视为一种极其丰富的结构化数据。我认为这才是正确的认知方式。你在上游下的功夫越深在运行时或查询时的负担就越轻。欺诈、身份与实时上下文主持人让我们聊聊应用场景吧。我觉得去年最让人惊喜的案例之一就是辉瑞Pfizer的演讲那真的很酷。你们有如此庞大的客户群在那些走在 AI 前沿的客户中有哪些是大家万万想不到会使用图数据库或者用 Neo4j 来做某些事情的Emil这里面可聊的太多了。其中一个巨大的跨越是人们现在已经真正将它投入生产环境了。两年前一切还处于非常早期的阶段。你提到了辉瑞。我们看到图数据库在生命科学领域得到了广泛应用。广义上讲这就是这些大型生命科学公司的研究员们每天都在使用的“科学智能”。它不仅能接入内部的同行研究还能检索专利、外部发表的学术论文等等。这是我们公开的案例之一超过 6000 万份文档数十亿个节点和关系。他们使用了大量精巧的命名实体识别NER和实体解析技术。顺便说一句实体解析在目前的 AI 工程界严重被低估和忽视了我完全不理解为什么会这样但这正是他们从海量数据中理出头绪的关键。你想想一家生命科学公司可是博士扎堆的地方。这套系统绝对是他们提升生产力和科研产出的核心命脉。这就是一个典型例子。就在 2026 年我们在银行业迎来了爆发式的增长。举个例子今年到目前为止我们关于 AI 的业务洽谈中有 30% 都是和全球性银行进行的这非常惊人。其中一个案例我不知道我们官网上有没有放是一家巨型抵押贷款公司。他们雇佣了大量的银行业务员他们管这些人叫“Agent”这在现在的语境下很容易让人误解但他们确实是活生生的人类。这些人类业务员大多是二十出头的年轻人人员流失率极高平均任期不到一年。因此这场游戏的核心挑战就是如何让他们快速上手。当他们向客户推销时你如何能让业绩垫底的四分之一员工迅速提升水平于是他们构建了一个庞大的系统审视了过往所有成功的销售路径分析了过去真正促成转化的因素并将这些经验汇总起来。他们其实在公开场合分享过这个案例虽然没提 Neo4j 的名字但他们明确表示这套系统让转化率提升了 20%。这些都是最近发生的事。主持人如果把这 20% 换算成真金白银那是多大一笔钱啊Emil我不知道具体数字但肯定比他们付给我们的软件费多得多不过真正酷的是今年他们开始将这个流程自动化了。以前系统只是给业务员提供话术草稿再由人工发送短信或邮件。现在他们自然而然地把“人”从这个闭环中移除了系统直接自动发送。看到人们如此迅速地将这些技术投入到直面客户的生产环境中真的非常震撼。去年夏天我们盘点客户案例时几乎还没有人敢把这些技术用在直面客户的生产线上。但在过去的三个月里风向发生了极其剧烈的转变。主持人你提到“过去的三个月”这刚好印证了我一直在研究的一个猜想。2025 年 12 月肯定发生了一些事当时随着 Claude Opus 4.5 等模型的发布许多数据曲线都出现了拐点。你们也观察到这个现象了吗Emil我们确实看到了。不过我不太相信这仅仅是因为 Opus 4.5 的发布感觉这背后还有别的推手。主持人当然还有 GPT。但无论是在哪种数据库里每一张图表的走势都惊人的一致……显然我能看到很多全行业的数据和统计。作为大约 30 家公司的天使投资人加上我通过 CognitionAI 编程公司看到的内部数据每一张算力消耗图表都在飙升每一张数据库使用图表都在飙升所有 AI 编程代理的图表也都在飙升。绝对有大事在发生。Emil确实有大事发生。对我们而言我不确定这是否纯粹是模型质量提升带来的但我们确实感受到了这股浪潮。一个重大的转变就像我刚才说的过去人们的诉求是“帮我起草信息”现在变成了“替我发送信息”。这种直面客户的完全自动化显然在“信任度”上达到了某种临界点所以企业才敢放手去做。还有一个例子如果说刚才聊的是企业宏观层面的动向那我们现在把视角切到微观层面看看单个开发者、单个应用是怎么做的——这也是我两年前那场 GraphRAG 演讲所探讨的边界。你可以想想人们现在是如何编写基于图的 Agent 应用的。图数据库是一个工具向量数据库可能也是一个工具。然后系统接收到一段英文或者说一段自然语言。过去业界的最佳实践是把你最常收到的高频问题提取出来。再拿客服系统举例这是最直观的当然还有很多其他场景比如 Swyx 去苹果官网提问。开发者会把这些高频问题直接封装成 Cypher 查询语言的函数或工具。只有当这些预设工具失效时才会把通用的“自然语言转 Cypher”作为兜底方案。客户以前通常是怎么干的呢他们会坐下来死死盯着那些触发了兜底方案的日志。找出那些没能成功解析的查询然后把它们单独抽离出来写成一个新的函数或工具调用。这曾经是大家的常规操作。大约一年前你在其他数据库和 Agent 应用里也能看到类似的打法。但在过去的三个到六个月里游戏规则被颠覆了。过去是“优先使用专用函数通用大模型兜底”现在完全反过来了。现在的做法是直接用通用的自然语言转 Cypher 开局只有当它搞不定时你才把那些边缘场景提取出来写成专用函数。我认为在整个技术栈上下发生了一系列质变促成了这三到六个月以来的大反转。主持人因为现在大模型基本上可以一次性single-shot搞定大部分查询了。Emil没错。主持人这让我想起了我经常聊的一个关于“大模型编程”的话题。当年我参加完那个 Cypher 工作坊后就再也没怎么用过它最大的原因在于它是一门领域特定语言DSL。我当时就想我真的有必要再去学一门 DSL 吗但现在看来DSL 的存在是有充分理由的它们为特定场景做到了极致优化语法极其精炼而且能精准地处理各种复杂逻辑。唯一的缺点就是学习成本高。但现在你根本不需要亲自去学了。你们的 Cypher 恰好是一门拥有海量训练数据的 DSL。所以你们成功跨过了那道门槛——你们在这个行业扎根足够久熬过了周期的起伏积累了足够的数据现在人们完全可以零门槛地自由使用你们的产品。当然如果需要的话他们依然可以手动优化。但除此之外大部分时候你只需要丢给大模型一次提示词就能搞定这体验简直太棒了。Emil我完全同意。我再补充几点想法。首先我们得益于成为了一个真正的 ISO 国际标准。它在 2015 年最初名为 openCypher在经历了无数次的拉锯和繁琐的标准制定流程后最终演变成了 GQL这也是 SQL 诞生以来的第一门“兄弟语言”。我认为这为 LLM 的训练数据提供了一个非常强烈的质量信号。这是一方面。话虽如此在我们内部的产品矩阵中依然运行着许多自研的自然语言转 Cypher 工具就像那种老派的 Copilot 辅助工具。如果你打开 Neo4j 的浏览器控制台准备手敲 Cypher 查询时你当然可以呼出 Copilot 帮你翻译自然语言。你也可以在我们的架构上运行各种 Agent所以我们必须把这种能力作为平台的底层原语。实际上我们至今仍在对这些内部模型进行微调即使我们在默认情况下调用了 Gemini 模型我们依然会做一些针对性的微调甚至加入一些后处理步骤。主持人你说的“微调”是指你们微调了一个专门生成自然语言转 Cypher 的自定义模型还是说你们只是在输出端的游乐场playground做一些提示词层面的调整Emil不我们是在微调一个真正的底层模型。主持人据我所知外部用户应该是没法直接微调 Gemini 模型的吧Emil这方面我们内部可能使用的是某个开源的衍生模型。具体是哪个我也不太清楚。但随后我们甚至会加一步后处理写一些真正的指令式代码比如用正则表达式去纠正代码里的箭头方向。你知道的在 Cypher 语法里你得用不同的箭头方向来描述关系的走向。现实情况其实比想象的要杂乱一些……目前的开箱即用模型还不足以完美应对所有情况。我当然希望——哪怕这像是一剂苦药——随着时间的推移大模型最终能搞定 99% 的场景但目前我们还没到那一步。GraphRAG 与智能体记忆主持人我觉得这正是专家发挥价值的地方也是拥有一个成熟生态系统的意义所在。至少在当下这依然是人类专家的领地。我想把话题拉回到应用场景聊聊大家正在做的那些酷事。显然在传统的推荐系统、欺诈检测等领域图数据库已经大展拳脚了。去年我开了一个关于“大模型推荐系统”的专栏看起来大模型正在吞噬传统的推荐系统而且我认为图数据库在其中也有非常巧妙的用武之地。据说现在整个 YouTube 的推荐系统都是基于大模型驱动的。他们把每一个视频都转化为 token 存进密码本里然后用它来训练一个大模型。就像使用普通大模型一样系统会把你的历史上下文喂进去让它预测你接下来该看哪些“视频 token”。这简直太疯狂了。Emil这确实相当酷。我之前都不知道。主持人我认识的推荐系统专家比如业内大牛 Eugene Yan极其看好这个方向。显然X推特的新算法以及 Pinterest 的推荐引擎背后也是这套逻辑在驱动。这在他们的圈子里已经火得一塌糊涂了确实很酷。不过这种体验有时也挺让人不适的。我的推荐流里确实出现过一些极其诡异的内容那是传统系统绝对不会推给我的。但无所谓了这是一个全新的世界所有人都在拼命挖掘数据信号。而且我敢肯定如果这世上有一家公司把 A/B 测试做到了极致那绝对是 YouTube。所以说回正题你目前观察到了哪些新的工作负载或应用场景是你特别想推荐大家去尝试的Emil现在行业里有大量的新奇尝试我非常喜欢这种氛围。在过去的十年里我们一直将火力集中在“全球 2000 强”企业上。我刚才也举了几个例子比如生命科学、金融服务这类案例我能给你讲上一整天。但在过去的一两年里我们也开始有些“回归初心”了。我们现在推出了一个初创企业扶持计划。我们的云服务 Aura无论是在产品形态还是价格门槛上都非常适合创业公司。这是个极好的转变。当然现在最火爆的一个场景就是“智能体记忆Agentic Memory”。很多人都想在图结构上构建记忆系统。很少有人注意到一点最初发布的 MCP模型上下文协议里其实内置了一个微型的内存图数据库。主持人才 200 行代码。我印象中也就 300 行左右的 Python 代码吧。Emil是的差不多就是那样。所以它只是个玩具非常简陋而且是纯内存实现的。但它的底层逻辑是图结构的这就很酷了。我当然喜闻乐见。现在有很多人自然而然地开始往这个方向探索。然后当然就是过去三个月里圈内热议的“上下文图谱Context Graphs”。我们看到很多人正在尝试构建这类系统我认为这也是图数据库的一个绝佳应用场景。主持人好的“记忆”完全可以单开一个大话题了。我不知道今天有没有时间深入聊。简单说说我的浅见理论上图数据库简直是构建记忆的完美载体。但在实践中这可能有点杀鸡用牛刀了。大多数人的记忆根本追溯不到那么远而且我认为我们至今还没摸透那种能跨越超长时间维度的“记忆”到底该是什么结构。弄不好一个单文件就装得下毕竟我个人也产出不了那么多 token。但说到“上下文图谱”那是另一码事。我常说我根本不在乎你的大模型上下文窗口有多长。我们花了三年时间才让所有前沿模型的上下文从 10 万突破到 100 万。但我们不可能做到十亿、万亿级的硬塞你必须依靠上下文图谱和上下文链接。你是怎么看待最近关于上下文图谱的讨论的这个话题真的彻底出圈了。我们之前和论文作者录过一期简短的播客。我觉得他们其实是在“留白”任由大家去解读。我想接下来会有很多人去构建上下文图谱系统我们在摸着石头过河中自然会定义它。但作为早期观察者你有什么见解Emil我的看法是它补全了我脑海中“数据源四象限”的最后一块拼图。我一直强调Agent 要想在生产环境中达到“逃逸速度”真正爆发必须依赖这四个象限的数据源。我认为所需的数据源不多不少刚好四种如果你能想出第五种或第六种我洗耳恭听。但我坚信核心就是这四种。倒不是说你非得集齐四颗龙珠才能召唤神龙但在某种程度上自然是多多益善。我认为 Agent 的第一种数据源是业务数据库。这是记录系统的基石。我把它们视为“记录当下的系统”。比如我现在有多少客户某个特定客户当下的价值是多少在平时的讨论中我们有时会把架在业务数据库之上的应用层叫做记录系统——比如我们会说 Salesforce 是记录系统有时又会把底层数据库本身称为记录系统。但无论怎么称呼业务数据库绝对占据了第一象限。第二象限我认为是云数据仓库。有人说数仓算不上记录系统我倒觉得它们也是。它们是“记录过去的系统”。如果说业务数据库记录的是当下那数仓记录的就是历史。比如我们在第三季度从拉美地区获得了多少营收诸如此类。然后第三象限在我看来就是“记忆”。主持人就是 OLAP联机分析处理对吧所以前两个是 OLTP联机事务处理和 OLAP。你刚才提到了 DSL这也是个数据领域的术语领域特定语言。不过对它主要是个编程术语。Emil然后第三象限就是智能体记忆。或者叫智能体状态你可以把它理解为记录智能体状态比如短期状态、长期状态的系统。最后第四象限就是上下文图谱。那它到底是什么呢它其实是在回答第一和第二象限里那些冷冰冰的数据背后的“为什么”。举个经典例子我以某个价格把产品卖给了客户这个价格是在目录价基础上打了八折但公司的红线是最多打九折。那么“为什么”能破例呢原因可能是我想借此打入这个垂直行业或者这片地域市场而且我得到了销售副总裁的特批——这个批准可能是在电话里、Slack 上或者是邮件里发生的。它并没有被正式记录在任何系统里。这些所谓的“决策轨迹”最终交织成了一张网络这就是他们所说的上下文图谱。如果我们目前的大方向是努力将决策权从人类的大脑转移到 Agent 的大脑中——过去我们说这是从“湿件人脑”向软件的转移现在我甚至不知道该怎么称呼大模型了也许是从“湿件”向“隐空间”的转移——那么能够获取这些机构内部的隐性知识了解大企业里事情到底是怎么运转的、决策究竟是怎么做出的就显得极其宝贵了。这就是我说的四个象限。关于上下文图谱我还能聊很多但首先你认同这四个象限的划分吗你能想到第五或者第六个吗主持人这四个里有三个我是举双手赞成的。但说实话智能体记忆——我觉得它稍微有点站不住脚或者说还不够成熟体量也偏小。第一、第二和第四象限业务库、数仓、上下文图谱都是极其强大、极其庞大的品类我闭着眼睛都知道该怎么去架构它们。但第三个象限感觉就只是一句含糊其辞的“某种记忆”。我觉得这背后应该还有更深的东西。当我们在构建二维四象限矩阵时OLAP 和 OLTP 是一组完美的对立面它们代表了查询广度和事务吞吐量的维度。那么另一个坐标轴应该与它是正交的但我目前还看不透那个轴到底是什么。所以它并不完全契合传统的四象限模型这通常意味着这里面可能还混入了一个我们没有察觉的第三维度。因为所谓的智能体记忆很可能更多是偏向个人的最多带点组织属性而上下文图谱则是彻头彻尾的组织级资产。这是我的直觉反应不过除非你还有别的想补充我们大可以只聊上下文图谱。Emil听到你这么说很有意思。我认为智能体记忆的本质是“我想弄清楚过去在这个特定个体身上到底发生了什么。” 我相信在许多应用场景中它会成为一个极其重要的检索源尽管可能不是全部。主持人那让我用自己的话来总结一下智能体记忆记录的是你和 Agent 之间发生的交互而上下文图谱记录的是你和其他所有人之间发生的故事。因为我看到现在所有的 Agent 公司都在拼命研究如何查询模型自身的历史轨迹、如何记忆知识并以此来实现自我进化这其实跟上下文图谱八竿子打不着。它的核心诉求纯粹就是这个 Agent 应该越用越顺手。Emil确实我觉得你说的完全正确。现在我们专门聊聊上下文图谱。我认为将企业的隐性知识以某种数字化的形式进行编码是非常有战略意义的。这又回到了我们常说的那个比喻你招了一个拥有博士智商的实习生大模型但他每天醒来都会失忆对公司的过去一无所知。所以这套系统很有必要。但真正的难点在于你如何通过技术手段去“埋点”你的组织从而获取这些数据我想大家都能预见到那个美好的未来我的 Agent 已经在生产线上跑起来了就像我刚才举的例子我有一套智能化的流程能自动联系客户并给他们提供房贷折扣。当系统在做这些事时它理应被全程监控记录将整个决策链路保存下来作为未来自我进化的养料。你能清晰地感觉到这种复利效应或者说飞轮效应。理想很丰满但我们现在还没到那一步。目前我们根本没有这些数据的数字化载体。最典型的现实场景是一个销售员坐在车里给老板打电话申请折扣老板随口答应了单子签了最后顶多在 Salesforce 里留个底。这就是当下的常态。那么问题来了我们该如何冷启动这个上下文图谱呢这几乎是我近期与所有大型企业客户和初创公司交流时绕不开的核心话题。对于初创公司来说上下文图谱的冷启动依赖于用户对他们产品的使用。所以对他们而言图谱不是问题问题是如何让用户用起来。但在大型企业的语境下——一语双关哈——问题最终变成了我到底该如何开始这套“埋点”工作才能积攒足够的决策轨迹从而冷启动整个流程这才是真正耐人寻味的博弈。建模、工具链与开发者体验主持人初创公司对你们来说到底有多大价值你们手里握着财富 100 强里的 80 家你们的靶心一直是全球 2000 强企业。至于初创公司哪怕有免费档之类的他们也提供不了多少真金白银吧。Emil也许我可以从创始人兼 CEO 的双重身份来回答这个问题。十年前我们审视公司的营收结构发现它是三分天下的估值十亿美元以上的大客户占三分之一中端市场占三分之一初创公司占三分之一。但我们敏锐地发现那“十亿美元以上”客户群体的所有底层商业指标都碾压其他两块。接着我们又研究了所有形成规模的数据库巨头——主要就是甲骨文当然还有 DB2——他们 80% 以上的营收都来自全球 2000 强。很显然这才是数据库公司真正的变现池。我们综合了这些信息最后拍板决定必须 100% 全力进军企业级市场。事后证明这是一个极其正确的商业决策。作为 CEO 来说我爱死这个决定了它获得了空前的成功这也是我今天能坐在这里侃侃而谈的原因。一切都很完美。但作为创始人我又有些失落因为创业者才是我的同路人他们代表着未来。所以当新一代 AI 原生初创公司如雨后春笋般涌现时我们意识到将 Neo4j 嵌入他们的底层架构对我们来说至关重要。这倒不是指望他们能立刻贡献海量的年度经常性收入。我从美国银行身上赚到的钱永远会更多——这只是个泛泛的例子没泄露什么机密我只能透露北美最大的 20 家银行全都是我们的客户剩下的你们自己品。总之我永远会从企业级市场赚到大头。但我认为融入这个时代的精神浪潮是极其重要的。从这个角度来看让下一代初创公司在 Neo4j 上生根发芽具有不可估量的战略意义。主持人按理说初创公司的历史包袱比大企业轻得多所以应该更容易上手。那么到目前为止你们总结出了哪些最佳实践你可以挑任何一个客群来聊说实话我对两者都很感兴趣。他们到底该如何迈出第一步Emil这取决于你所处的飞行高度。如果是一家初创公司那就不单单是做一个产品的问题了产品就是公司的全部。那就是孤注一掷。但这在大型企业的语境下是截然不同的在企业里我们通常在两个层面上展开合作。一个是聚焦于单一应用、单一项目的微观层面另一个则是横跨整个企业的宏观层面。我先着重聊聊后者吧因为这也是自两年前那场 GraphRAG 演讲以来发生的一个巨变。我们观察到一个非常清晰的趋势我们通常将其称为“知识层”。我们接触了许多企业发现大家面临着一个共同的痛点他们内部的每一个数据源未来都会暴露出某种 MCP 接口。企业希望让他们的 Agent 能够接入这些数据。那该怎么做呢一种简单粗暴的做法是直接把所有 MCP 接口的权限都扔给 Agent让它自己去摸索。但这会带来一个致命问题系统确实能跑通但不同数据源里的数据是会打架的。我们刚才提到过我们的云服务。哪怕是我自己当我想弄清楚我们的云服务到底有多少客户时我去问底层的云平台它告诉我比方说有 3000 个客户。这里的口径是“有多少个活跃的、正在运行数据库的账户”。然后我转头去问财务系统它却告诉我只有 2800 个客户因为它的口径是“绑定了信用卡的账户”。你该如何理清这其中的逻辑我们正在吸取一个教训大模型永远会信誓旦旦地给你一个答案但你根本不知道它是对是错而且查证起来极为困难。所以我们现在和很多大企业探讨的方案是他们需要自己掌控一个中间层在这个层面上将企业内部所有数据的元数据整合起来。这才能为你提供一致性、信任度以及可解释性。那么他们究竟想掌控哪些元数据呢本质上就是整个企业的数据资产全景图。你的关系型数据库里有哪些表结构你的 S3 里有哪些存储桶等等。将这些信息以图的形式表达出来并与面向业务的本体论相结合。比如什么是“客户”“客户”与“供应商”之间是什么关系我的业务线里到底有哪些核心概念主持人这太难了。你问五个人能得出六种答案。Emil一针见血。这正是过去一直阻碍这项工程推进的死穴。但现在情况变了为了让 Agent 在特定场景下成功落地企业被逼着必须解决这个问题。这种倒逼机制迫使他们在内部达成某种“只要够 Agent 用就行”的共识。然后第三块拼图就是这两者之间的映射关系。有人管这叫语义层有人叫上下文层。我个人偏爱“知识层”这个词。它们指代的意思大同小异但又略有区别这绝对是我们当下最火爆的应用场景。如果你去我们官网或者直接谷歌搜索“leading media company”加上 Neo4j你会看到一个案例。页面往下拉有一张漂亮的绿色架构图。最底层是各自为战的数据孤岛中间是他们所说的“语义层”最顶层则是运行其上的 Agent 群。这里有几种不同的玩法比如你可以做零拷贝。在这种模式下知识层只负责提供一张“寻宝图”告诉 Agent 到底该去哪里查数据或者在某些情况下我们会将部分高频数据直接内联到知识层里这样 Agent 就能在这一层直接完成查询。主持人“零拷贝”具体是指什么来着我记得是 Salesforce 发明或者至少是带火了这个词。意思是不是说你不再需要把数据在 Snowflake 和各种系统之间搬来搬去而是建立一个虚拟化层直接把指针打到原始数据源上Emil也就是外部数据封装器Foreign Data Wrapper。完全正确。主持人你听得出来我是个重度 Postgres 玩家。Emil哈哈听出来了。所以顺着查询链路你最终会到达这个中间层由它来弄清数据到底藏在哪里。有时候数据也会被物化到这一层这样你就能直接查询了。所以这是目前企业级市场里极其抢手的一个场景。不过我想你的原问题是新手入坑的最佳实践是什么我们刚才聊了上下文图谱。最近出了一个非常精妙的 Python 封装工具叫UVX create-context-graph它开箱即用地为你提供了我没记错的话22 个不同行业的上下文图谱模板。这玩意儿几天前刚发布它能一键拉起一个带有前端界面的完整 Neo4j 实例。而且它的设计灵感——你肯定会爱死这个——毫无疑问是借鉴了create-react-app。所以你能获得一种极其丝滑的交互体验……它不仅能帮你处理你自己的数据你还可以直接从预设的行业模板里挑。主持人哇哦。Emil没错。而且它已经无缝集成了八九个不同的 Agent 平台。主持人唯一遗憾的是我最想要的那一个偏偏不在里面。Emil哪个主持人社交媒体。Emil有意思行我们可以把它加上。未来的“图状”互联网主持人我的观点是每一个 SaaS 软件最终都会在其账号认证体系内孕育出一个社交图谱。你需要团队协作你需要用户互发消息你需要推送通知。社交媒体的元素会渗透进每一个细分领域。它甚至都不算是一个垂直领域它就是一套基础特性。我以前其实研究过把这个做成一门生意后来发现别人试过但没跑通。但其核心诉求就是把“社交网络”作为一个插件直接空投到我的用户库里。因为我的每一个用户都在团队中工作他们有关注关系他们想要信息流想要通知想要私信甚至想写博客。这些全都是社交功能他们自己绝对懒得从头开发但他们又实打实地需要。不管怎么说这个工具真的很酷。Emil所以这个工具的作用就是帮你扫平起步的障碍它还能自动生成一些合成数据。它同样集成了许多 SaaS 工具。我看到你最近对 Claude Code 的命令行工具极其兴奋是吧主持人谁看了不兴奋啊。我之所以对 Claude Code 如此上头是因为我终于可以用它来替我操纵谷歌云GCP的控制台了。我当时的反应是我再也不想亲手点那个控制台了那体验简直反人类Emil对所以它可以帮你抓取真实数据也能生成合成数据。它内置了一套 Agent 记忆工具包既包含短期记忆——也就是对话状态之类的东西也包含长期记忆——涵盖了该领域内的所有实体和核心概念。同时它还记录了决策轨迹也就是上下文图谱。它把这些全打包在一起还附带了一个小巧的图谱可视化界面。所以这绝对是新手上路的绝佳途径。主持人这个点子绝了。我真不敢相信之前居然没人做过。更不敢相信这玩意儿才发布了六天。你们绝对应该狠狠地推广它。Emil你大概能猜到背后的老套剧情那是我们办一场关于上下文图谱的线下聚会之前他在某个周日下午随手敲出来的结果大家爱死它了。主持人如果看了这个项目我非要提一个建议的话那就是它似乎做得“太多”了。它的边界在哪我的应用的边界又在哪这里面塞了太多东西。光看这个 Readme 文档我已经开始觉得有些信息过载了。有时候保持克制是非常可贵的。就像 OpenCode 的 CEO Dax 说过的那样看吧在这个任何功能你都能在几天内凭感觉“搓”出来的时代克制、专注和恰如其分反而成了一种稀缺品质。因为是的你什么都能往里塞但它真的创造了增量价值吗还是仅仅在白白消耗我的注意力带宽我只想知道你到底要帮我解决什么核心痛点然后把那一点做到极致就行了。我觉得这又回到了乔布斯的那句名言“我是产品的总编辑”。而作为一名编辑最重要的工作就是说“不”就是大刀阔斧地做减法。这真是一次干货满满的快速巡游。显然在你们的图谱世界里还有很多值得我们去挖掘的宝藏。在节目的最后抛开你官方的 CEO 身份作为一个骨子里的黑客你还有什么想分享的吗最近还有什么让你心潮澎湃、极其兴奋的事物Emil怎么说呢我们所处的这个时代既是最让人热血沸腾的时代也是最令人胆战心惊的时代。我们今天完全没聊所谓的“SaaS 末日”之类的话题但戴上 CEO 这顶帽子我必须对这些暗流保持警觉。毫无疑问我们正身处前线目睹着企业在“买采购 SaaS”与“造自己用 AI 写”之间的重心偏移。Klarna 就是最早的案例之一他们尝试了用 AI 替代外购软件后来又部分回调了——至少外界看到的是这样。我不代表 Klarna 发言但我认为舆论对“买”和“造”两边的说法可能都有些夸大了。不过这种范式的转移是确凿无疑的。但就我个人而言我每年要花 20 万美元去买一款我恨得牙痒痒的会议管理软件。主持人也许花个两千块钱自己搓一个喜欢的会更好。真不敢相信你们这么牛的人居然还没把这个痛点解决掉。我现在正忙着东奔西跑、打印胸牌、算计请魔术师的预算。自己开发软件根本排不进我的优先级列表。而且我的团队并不像我这样是“Agent 原生”的。作为一个 CEO我不能一拍脑袋就决定“好我们全公司现在都要改用 AI 自己写软件了”然后指望每个员工都能无缝衔接。不可能的他们需要培训。事实上有时候那些我们用惯了的、充满 Bug、运行缓慢的破系统反而更靠谱。这就又回到了那个问题这些工具的真正价值是什么很大一部分价值在于它们固化了某些业务流程并对这些流程给出了规范性的指导。要让 AI 迭代到那一步我们还需要时间。如果你倾注全部精力你确实能自己用 AI 搓出来但在那之前你还是得乖乖给那些破工具掏钱。所以我完全理解你的处境。Emil所以这是让人感到恐惧或震惊的一面。但硬币的另一面是老天现在我们拥有的创造能力太惊人了。要知道我已经算是“半退役”的技术人员了。我脑子里还懂那些比较并交换CAS的底层逻辑但我已经有整整十年没当过正儿八经的现代程序员了。但现在我又行了。软件再一次变得如黏土般柔软可塑这简直让人兴奋到极点。主持人但我认为像你我这种“半退役”的技术管理者很容易陷入一种失败模式你以为 AI 无所不能于是你凭感觉“搓”出了一坨代码直接甩给你的员工指望他们能完美接盘。绝对不可能。所以我真的想提醒一下在座的各位领导者请尊重现实不是所有东西都能靠 AI 随便“搓”出来的。如果你非要这么干你的员工很多时候还得跟在屁股后面给你擦屁股。Emil举双手赞成。尤其我们还是一家数据库公司那里面可是需要真正的工匠精神的。主持人但你们的测试体系做得太扎实了。数据库的测试绝对是顶配级别的。绝大多数软件根本享受不到这种待遇。所以其实我知道正是因为你们有如此严密的测试网你才敢更放肆地去用 AI “搓”代码因为一切都有测试在兜底。不管怎样非常感谢你Emil。这真是一场酣畅淋漓的对话。投稿或寻求报道zhanghycsdn.net推荐阅读达梦图数据库GDMBASE V4.0在千亿级原生图底座上让AI真正学会推理AI协作新范式openJiuwen社区首发Coordination Engineering全栈技术体系不做加法做融合DM9 给出数据库的下一代答案加入AMD AI 开发者计划与全球极客共筑开源加入即领 50 小时免费云算力进群抽显卡、AIPC好运不停活动与工作坊早鸟名额优先锁定AMD Al Academy 官方课程加速立即扫码加入⬇️⬇️