為什麼我們的AI代理需要因果圖,而不僅僅是RAG數據庫
本文描述了AI代理ARIA從平面記憶數據庫向因果圖的轉變,以推理後果和依賴關係。作者回憶了一個具體失敗案例,其中ARIA無法連接配置更改的各個環節,從而意識到單純的事實檢索不足以進行規劃。因果圖使用類型化邊(原因、需要、矛盾)實現了反事實推理、預測和矛盾檢測。儘管仍有侷限,但它代表了質的飛躍。
從平面記憶到世界模型:ARIA為何需要理解而非僅僅記住
在AI代理的發展中,一個關鍵的轉變往往源於一次具體的失敗。對於ARIA而言,這個時刻發生在嘗試規劃一個多步驟操作時。Phase 01賦予了ARIA持久記憶庫,它能記住操作系統是Windows、數據庫是SQLite、存在自定義模型提供者等事實。然而,當需要修復自定義提供者配置時,問題浮現了。
斷裂時刻
改變config.py會引發連鎖反應:.env文件中的默認Gemini設置與新提供者衝突,數據庫中存儲的連接參數會變得過時,而連接測試失敗的原因其實在於環境變量,而非提供者代碼本身。ARIA的記憶中存有三條事實:“用户有自定義提供者”、“.env文件有默認Gemini設置”、“連接測試失敗”。但在平面記憶列表中,這三者毫無關聯。ARIA知道齒輪是什麼,卻不懂轉動一個齒輪會如何影響另一個。
列表只是數據庫
平面事實列表本質上是數據庫,而世界模型意味着理解。當你説“草是濕的”,數據庫只知道這個事實,但若理解原因(下雨或灑水器),就能進行反事實推理(如果沒下雨,草地會是乾的)、預測(走在草地上鞋會沾泥)和規劃(應該走鋪好的路)。純檢索無法回答“給定這個事實,接下來會發生什麼?”或“想要這個結果,應執行什麼行動?”。這正是ARIA被困住的邊界。
因果圖的實際作用
Phase 02引入了基於NetworkX的因果實體圖,並在SQLite中鏡像。每個事實成為節點,每對關係成為類型化邊。邊的類型至關重要:“原因”不同於“需要”也不同於“矛盾”。當ARIA學習到更改環境變量會導致數據庫連接參數過時,這是“原因”邊;自定義提供者需要先更新.env文件,這是“需要”邊;默認Gemini設置與自定義設置矛盾,這是“矛盾”邊。
這個圖不僅是更豐富的存儲格式,而是一種可遍歷的對象。你可以問:“如果我改變這個節點,哪些其他節點會受影響?”沿着“原因”邊向前追蹤預測後果,沿着“需要”邊向後識別前提條件,檢測“矛盾”邊發現不一致。在config.py案例中,因果圖讓ARIA不只是知道.env文件存在,而是明白自定義提供者需要更新.env、環境變量會導致數據庫參數變化、現有默認配置與新配置衝突。在修改任何代碼之前,它就能追蹤完整的後果鏈。
矛盾檢測器
因果圖的一個有趣後果是矛盾變得可見。在平面記憶列表中,“自定義提供者已配置”和“默認Gemini設置活躍”同時存在卻無任何衝突提示。而在因果圖中,當新觀察與現有節點矛盾時,矛盾檢測器會標記它們。兩個事實都被保留——並非因為兩者都正確,而是因為矛盾本身提供信息。“這兩者不能都對——哪個正確?”這個問題系統現在可以提出。答案來自上下文、新證據以及哪個因果鏈與後續觀察更一致。
這改變了ARIA處理不確定性的方式。平面記憶會靜默地用新信息覆蓋舊信息,而圖則顯式地保持張力並等待解決。這更接近細心推理的實際過程。
仍存在的侷限
世界模型並非Judea Pearl所描述的嚴格因果引擎。圖中的邊是語言模型聲稱的,非驗證的因果關係。模型可能誤識因果鏈接,也可能遺漏明顯的。實體解析依然脆弱:當ARIA在不同對話中遇到“config.py”和“配置文件”時,這兩者應為同一節點。精確字符串匹配失敗過多,模糊匹配又引入錯誤合併。我們使用詞重疊相似度,這是一種折中方案。
為何仍重要
儘管存在這些侷限,因果圖代表了與平面記憶列表質的區別。一個能在行動前追蹤依賴鏈的代理,與一個檢索孤立事實並生成響應的代理是不同工具。在簡單對話中差異不明顯,但在行動有後果、系統需要推理而非檢索的關鍵時刻,差異顯現。那是大多數AI助手暴露出只是快速模式匹配器的時刻,也是擁有世界模型的代理開始與眾不同的時刻。
我們仍在向那目標邁進。圖是真實的,邊是真實的,矛盾檢測是真實的。但世界模型當前能力與真正因果推理之間的差距仍然很大。方向正確,距離誠實。我們正在打造手錶,而不僅僅是移動齒輪。