別死磕百萬上下文了！Neo4j CEO 詳解知識圖譜：如何把大公司的“隱性知識”塞進 AI 的腦子？

“專用向量數據庫的生存空間已經快沒了！”

編譯 | 王啟隆

出品丨AI 科技大本營（ID：rgznai100）

這兩年，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：很高興來到這里。

主持人：這一刻我期待已久。你是第一屆世界博覽會（World's Fair）上最受歡迎的演講嘉賓之一。去年我們又和你的團隊一起辦了完整的 GraphRAG 專場，今年我們再次聚焦這個話題。如今，你會如何向大家介紹 Neo4j？

Emil：這取決于聽眾是誰。我想我們最廣為人知的身份是一個數據庫，確切地說，是圖數據庫。但時至今日，它已經演變成一個遠超數據庫范疇的廣闊平臺。

我通常會這樣開場：我們將數據煉成知識。這是一個實現該愿景的平臺。

當然，這自然會引出一個問題：你說的“知識”到底指什么？畢竟這是一個定義模糊的詞。

我會解釋說，知識的本質是從噪音中提取信號，并以一種“知識高密度”的方式呈現出來，而“圖”正是其中一種絕佳形式。毋庸置疑，其核心依然是數據庫，但如今這個平臺已經包羅萬象了。

主持人：你們已經深耕這個領域有一陣子了。現在幾乎所有人都在用你們的產品，甚至包括倫敦交通局。這挺有意思的，因為這本身就非常“圖”——等你親自去那里就會發現，倫敦的地鐵網絡就是一個天然的圖結構。

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 家公司的天使投資人，加上我通過 Cognition（AI 編程公司）看到的內部數據，每一張算力消耗圖表都在飆升，每一張數據庫使用圖表都在飆升，所有 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。這真是一場酣暢淋漓的對話。

（投稿或尋求報道：zhanghy@csdn.net）

加入AMD AI 開發者計劃與全球極客共筑開源

加入即領 50 小時免費云算力

進群抽顯卡、AIPC，好運不停

活動與工作坊，早鳥名額優先鎖定

AMD Al Academy 官方課程，加速