您好,我是TIMEWELL的濱本隆太。
有人給我看了一則在X上流傳的貼文截圖。內容把一句話歸給參與創建Google Brain的吳恩達(Andrew Ng):「提示詞六個月內會消失,取而代之的是迴圈與圖。」註記說是出自史丹佛的兩小時演講。
圖是我們的核心技術,所以這句話對我們來說太好用了。正因為如此,我先去確認出處。結果先寫在前面。這句話,我找不到一手資料。
追查出處,卻走不到源頭
相同旨趣的貼文出自多個帳號。但把它們並排來看,文字並不一致。
「提示詞六個月內會消失。優秀的AI工程師早已在打造自我改善的迴圈。」「提示詞六個月內會消失,取而代之的是圖。」「三到六個月內所有人都會使用自我改善迴圈,不再有提示詞。」
**被取代的對象,每則貼文各不相同,時而是迴圈、時而是圖、時而兩者都提。**如果是同一場演講的聽眾引用同一句話,通常不會這樣分歧。我判斷這是傳話遊戲的徵兆。我查了吳恩達本人的帳號、DeepLearning.AI的發布,以及史丹佛方面的公告,都找不到對應這句話的一手資料1。
這裡要謹慎地寫。**找不到,不等於證明他沒說過。**只是在我能查到的範圍內沒有,如此而已。但把無法確認的東西當作已確認來引用,後面整段論述都會站不穩。
寫可以確認的事實。DeepLearning.AI確實有一門「Agentic Knowledge Graph Construction」課程,與Neo4j共同開發,講師是該公司的Andreas Kollegger。吳恩達不是這門課的講師2。內容是使用Google的Agent Development Kit,設計多個代理,從結構化與非結構化資料中抽取節點與關係,建構出用來找出產品問題根因的知識圖譜。長度3小時8分,12支影片課2。
能確認為吳恩達本人主張的,是他在2024年整理的代理式工作流四種設計模式:Reflection(反思)、Tool use(工具使用)、Planning(規劃)、Multi-agent collaboration(多代理協作)3。
也就是說,撇開流傳那句話的真偽,用圖來組建系統的潮流確實存在,這一點是查得到的。接下來談內容。
圖工程到底是什麼
一句話說明:把資料設計成節點(事物)與邊(關係),讓關係本身成為檢索與推論的對象。
請先想像一般的RAG。把問句轉成向量,找出相似的文字。這是設計良好的機制,但這個做法少了一樣資訊:文件與文件之間的連結。
用例子比較快。假設你問「A公司的母公司的母公司是誰」。向量檢索會回傳含有「母公司」一詞、看起來相似的文件。運氣好的話剛好命中寫著答案的那份,但**從A走到B、再從B走到C這兩段追溯的動作本身,並不存在於相似度計算的任何地方。**相似與相連,是兩種不同的資訊。
圖在這裡不一樣。從A公司這個節點出發,沿著「是母公司」這條邊走到B公司,再走一次到C公司。答案不是找出來的,而是組出來的。實務上,這個差異決定能不能拿到答案的場合相當多。
工作的核心是綱要設計。要放哪些節點型別(公司、人、產品、案件、法規條文),要放哪些關係型別(出資、供應、核准、引用)。這裡草率的話,之後不管疊上多好的模型都出不了答案。前面那門課之所以以「讓代理抽取節點與關係」為主題,我想也是因為這個設計與抽取才是最耗工的部分。
跳過綱要會怎樣。常見的失敗是把關係型別全部併成一種「相關」。只記下A與B相關,就分不出是出資、是供應,還是單純出現在同一份文件裡。**邊沒有意義的圖,說到底和一堆點沒有差別。**反過來說,把關係型別確實分開的那一刻起,能走的問題就會大幅增加。
另一個容易被忽略的是時間。出資關係與供應關係都有起訖,什麼時候問,答案就不同。邊上沒有帶效期,就會用三年前已經解除的股權結構來做今天的判斷。事後一定會有人要求回到過去某個時點的狀態來確認,一開始就放進去比較便宜。
想先確認自家的出口管制體制現況,可以用出口管制體制免費檢測看一下,後半段讀起來會比較有實感。
「迴圈與圖」其實是兩個不同的層
流傳的貼文之所以令人困惑,在於它把迴圈與圖並排講。這兩者不是同一層的東西。
圖講的是知識的結構,也就是系統以什麼形式保有「什麼與什麼如何相連」。迴圈講的是執行的控制,也就是不以一次輸出為終點,而是評估結果再跑一次。用吳恩達的四種模式來說,Reflection接近迴圈那一側,Planning接近圖那一側3。
兩者並用的設計當然存在,但「提示詞會被迴圈與圖取代」這種說法,把層級不同的兩件事收進了同一個主詞。就我個人而言,提示詞不會消失,改變的是提示詞被放在哪裡,這樣理解比較貼近實作。人不必每次在對話框裡打長文,圖的結構與迴圈的控制承接了大部分工作。提示詞本身留在系統內側。
出口管制原本就是圖的問題
接下來是我們實際動手的領域。
出口管制的往來對象查核,本質上就是圖的問題。這不是比喻,是制度本身長成這個形狀。
最清楚的例子是美國BIS的50%規則。它不只看列入名單的事業體直接持有50%以上的子公司,而是合計受控關係來判斷。也就是說,眼前的往來對象即使不在名單上,只要往上追溯股東時出現名單上的事業體,影響就會及於此。這正是沿著股東的邊、檢查是否可達的作業。制度細節與計算範例整理在BIS 50%規則完整解析。
實質受益人的辨識也是同樣結構。要一路追溯到法人背後的自然人,因此會往上走好幾層。
兩者都無法用文件相似度檢索解決,這是原理上的限制。問「這家公司危險嗎」而拿回相似的文件,股權的連鎖依然沒有被追溯。只能沿著邊走。
本公司的出口管制AI代理TRAFEED以知識圖譜為基礎,原因就在這裡。它擁有涵蓋論文9,000萬件、專利1億件、研究人員30萬人在內、超過2億件的知識圖譜,5秒內把往來對象的疑慮程度可視化。與岡山大學共同實證,使用約3萬件過往審查資料,確認AI判定準確度95%以上(自家調查)。取得日本專利第7862062號,已有20個以上組織採用。惟依日本外匯及外國貿易法,最終做出鑑定的是貴公司的出口管制負責人,輸出結果請作為判定的佐證資料使用。這條界線在制度上無法移動。
企業內部的知識,本來也是相連的
出口管制看起來也許是極端的例子。但企業內部文件也一樣。
某份規格書屬於哪個案件、綁在哪個客戶、由誰撰寫、通過哪次審查、連到哪份不良報告。**在寫下的當下,這些全部是相連的。**把它放進資料夾、做成向量的那一刻,線就消失了。相似的文件會出來,但「過去有沒有同樣根因的案件」答不出來。
和製造業客戶談的時候,最常聽到的就是這個形狀的困擾。「同樣的不良,五年前好像別的事業部解決過。」承辦人有這個感覺,檢索卻找不出來。當年的報告還在,但把那份報告與現在這件案子連起來的線,哪裡都沒有記錄。也有人說過,人一離職,線就跟著消失。
ZEROCK採用GraphRAG,就是為了把這些線留下來。在日本國內的AWS伺服器上運作,管好誰能存取哪些知識,並以可追溯關係的形式保有。存取管控與圖其實相當合拍,因為**誰可以看哪個節點,這件事本身就能用邊來表達。**部門與權限,說到底也是關係。
今天就能試的兩件事
寫了這麼長,起手式其實很樸素。舉兩個。
**第一,在紙上畫一次綱要。**寫出自家業務中出現的五個「事物」,以及它們之間的五種「關係」。公司、產品、案件、人、法規。出資、供應、核准、引用、違反。光是這樣,就能看出目前持有的資料在哪些地方沒有記錄關係。大多數公司裡,關係只存在於郵件、會議,和某個人的腦袋裡。
第二,做十個問「關係」的問題,丟給現在的檢索。「把用到這個零件的產品全部列出來」「這個客戶所在產業裡,發生過類似不良的案件有哪些」「追溯這家往來對象的股東,上面有沒有名單上的事業體」。答不出來的問題,就是需要圖的地方。
回到開頭那句引言。我沒能查證那句話。即使如此,我仍然認為用圖來組建這件事是真的。**懷疑一句爆紅的話,與正面評價它背後的技術,這兩件事可以並存。**尤其是在法遵領域出產品的公司,兩件都得做。拿無法查證的說法當根據去改設計,才是最糟的做法。
不論是把企業內部知識重新用圖來保有,或是用圖來組建出口管制,聽到具體狀況會比較快。歡迎從個別諮詢與我們聯繫。
Footnotes
-
本文查證的對象,是2026年7月至8月間由多個帳號擴散、主張提示詞將在六個月內消失的貼文。被取代的對象在各貼文之間並不一致,有的寫「self-improving loops」,有的寫「graphs」,有的兩者都列。截至本文撰寫時(2026年8月9日),在吳恩達本人的帳號、DeepLearning.AI的發布,以及史丹佛大學方面的公告中,均未能確認對應這句話的一手資料。這是查證失敗的事實記載,並非主張該發言不存在。擴散來源的貼文因含有以互動量為目的的轉載,此處不逐一列出網址。 ↩
-
DeepLearning.AI「Agentic Knowledge Graph Construction」。與Neo4j共同開發的課程,講師為該公司 Lead for GenAI Innovation 的 Andreas Kollegger。使用Google的Agent Development Kit(ADK)、Cypher與Neo4j,設計從結構化與非結構化資料中抽取節點與關係的多代理系統,建構用來找出產品問題根因的知識圖譜。難度 Intermediate,長度3小時8分,影片課12支、程式範例8個、評分作業1份。吳恩達並非本課程的講師。https://www.deeplearning.ai/courses/agentic-knowledge-graph-construction/ 同一課程目錄另有 Andreas Kollegger 講授的「Knowledge Graphs for RAG」,以及吳恩達講授的「Agentic AI」 https://www.deeplearning.ai/courses ↩ ↩2
-
吳恩達2024年3月在自己的帳號上提出的代理式工作流四種設計模式(Reflection、Tool use、Planning、Multi-agent collaboration)。https://x.com/AndrewYNg/status/1773393357022298617 ↩ ↩2






