什麼是上下文圖？為什麼它們對企業人工智慧至關重要？

首页 » 蟒蛇 » 什麼是上下文圖？為什麼它們對企業人工智慧至關重要？

上下文圖譜正迅速成為企業人工智慧領域最熱門的話題之一這並非沒有道理：它們有望為人工智慧代理提供在真實業務流程中可靠運作所需的關鍵要素——關於決策如何隨時間推移而實際發生的、可查詢的真實上下文。傳統的記錄系統告訴你發生了什麼，而上下文圖譜則旨在捕捉事件發生的更豐富的細節，包括人員、工具和策略，以及事件發生的原因和方式。

同時，人們對這種炒作也日益增長且健康的懷疑態度。一些專家認為，上下文圖將原始決策軌跡與真實的組織知識混淆了，或者鑑於大多數公司目前的實際情況，構建上下文圖實在太難了。理解這種矛盾——價值萬億美元的承諾與混亂的現實——對於確定上下文圖是否應該納入你的發展路線圖至關重要，無論你是現在、將來還是永遠不考慮它。

什麼是上下文圖（以及它們不是什麼）

從本質上講，上下文圖是以圖表形式表示決策及其相關上下文。大多數企業系統——CRM、ERP、HRIS、ITSM——都會忠實地記錄結果：折扣已批准、發票已支付、索賠已拒絕、候選人已錄用。但它們很少儲存導致這些結果的推理過程：檢查了哪些輸入、檢查了哪些策略、申請了哪些例外情況、誰簽字、簽字順序如何以及簽字理由是什麼。

Foundation Capital 將上下文圖定義為「跨越實體和時間縫合在一起的決策軌蹟的鮮活記錄，從而使先例可搜尋」。決策軌跡並非簡單的日誌記錄，而是情境如何轉化為行動的結構化記錄。具體而言，一條完整的決策軌跡可以包含從不同系統收集的事實、所應用策略的確切版本、任何被觸發的例外情況、帶有時間戳和渠道的審批記錄、寫回記錄系統的變更，以及最終的下游結果。

這使得上下文圖與你的模型的私有思維鏈有著本質上的差異。思路鍊是指LLM（生命週期管理）內部針對單一查詢的短暫推理過程；而情境圖則是外在的、持久的、組織範圍內的記憶，記錄了決策在現實世界中的實際執行過程。它不僅僅是線性的、以使用者為中心的聊天記錄。上下文圖旨在處理客戶、工單、策略、人工審核者、時間和工具之間的多對多關係。

重要的是，上下文圖並非“僅僅是一個向量資料庫”，也並非“僅僅是一個知識圖譜”。向量非常適合模糊語義相似性分析——例如「找到與此類似的段落」——但它們本身並不編碼來源、時間或諸如「例外」、「批准人」或「取代」之類的顯式關係。另一方面，知識圖譜通常著重於相對靜態的實體和關係（客戶、產品、地點、政策）。大多數知識圖譜部署都未能對完整的流程執行路徑和決策沿襲進行建模，而這些正是實現操作可審計和可重播的關鍵。

正確的思考模型是，情境圖是決策及其情境的圖形化記憶。它將決策沿襲（誰、什麼、何時、為什麼以及依據哪個先例）視為一流數據，而不是事後考慮而埋沒在日誌、Slack 討論串或人們的回憶中。

上下文圖作為人工智慧代理的結構化問題空間

除了作為企業記憶庫之外，上下文圖還可以被視為人工智慧代理可以導航的複雜問題空間的地圖。在某些智能體框架中，上下文圖被描述為核心編排組件之一：它們編碼了問題的「形狀」——包括問題的邊界、典型的解決方案路徑、關鍵決策點、反思機會以及已知的死胡同。它不再是僵化的流程圖，而是一個兼具結構性和彈性的拓樸場。

這種拓樸視角之所以重要，是因為它允許智能體執行具有明確置信度評分的量化推理。智能體並非給出單一的整體答案，而是經歷離散的推理狀態或“量子”，每一步都會評估自身的置信度，決定下一步走哪條分支，以及當前問題在現有上下文中是否可解。這通常被稱為熵感知推理：在圖的高確定性區域，智能體的行為是確定性的；在模糊區域，它會進行更多探索，並依賴於身份識別、直覺或外部工具。

人類專家一直以來都在這種結構化但又靈活的空間中潛移默化地運作。例如，資深臨床醫生不會遵循單一的僵化診斷流程；他們能夠識別模式，了解高風險決策點，知道何時應該停下來思考，以及何時病例開始偏離指南，需要依靠主觀判斷。上下文圖試圖將這種隱含的拓撲知識明確化，使其可被機器讀取，從而使智能體能夠智能地遍歷它，而不是每次都憑空想像一個過程。

實際上，這意味著不僅要對可能的步驟進行編碼，還要對哪些轉換是典型的、哪些轉換雖然罕見但允許、哪些轉換是禁止的進行進行編碼。隨著時間的推移，決策軌跡不斷積累，上下文圖可以完善：新的異常路徑湧現，失效模式被剔除，更優路徑被推廣。這使得上下文圖成為一個鮮活的模型，展現了組織如何實際解決其反覆出現的問題。

從臨床方案和標準作業規程到便利的服務

上下文圖最切實的應用之一是在高度結構化的領域，例如醫療保健和其他流程密集型服務。想想臨床方案、分診流程或持續照護管理項目：紙上，它們是冗長而靜態的文件；但在實踐中，臨床醫生會根據患者的實際情況不斷調整這些方案，例如合併症、數據缺失或非典型表現等。上下文圖可以將這些方案轉換為可導航的結構，其中每個步驟、分支和異常情況都得到了明確的建模。

與其提供需要人工解讀的 PDF 指南，不如提供一份代理人可以遵循的服務藍圖。這張圖編碼了服務提供的核心組成部分—接診、分診、診斷、治療選擇、監測、升級、記錄、出院計劃、後續追蹤等等。每個節點可以代表行動狀態（做某事）、決策狀態（選擇路徑）或反思狀態（評估是否仍在安全軌跡上）。

這使得人工智慧代理能夠在提供高度一致的照護的同時，也能適應患者的具體情況。例如，在高風險藥物劑量調整中，上下文圖可以強制執行一條緊密、低熵的微路徑，幾乎沒有即興發揮的空間。相較之下，在治療性對話或輔導中，同樣的脈絡圖可以打開低密度區域，只要不超出既定規則，主體在提問或探討話題時就擁有更大的自由。

至關重要的是，上下文圖彌合了靜態協議和動態實踐之間的差距。它們可以記錄臨床醫生實際上如何偏離「理想」方案，哪些例外情況常見且安全，哪些例外情況會導致後續問題，以及這些偏差與結果之間的關聯。隨著時間的推移，決策追蹤會揭示一些表面模式，這些模式應該逐步發展成為正式的政策或標準作業規程（SOP），而不是僅僅作為臨時性的權宜之計。

一些批評者在此劃定了一條重要的界線：僅憑原始決策軌跡本身並不是一個好的出發點。如果僅挖掘 Slack 討論串或電子病歷日誌來產生上下文圖，則存在編碼不一致的風險。十位醫生對類似病例做出十種不同的選擇並不能提供智慧，只會導致可重複的混亂。成熟且經過精心整理的標準操作規程 (SOP) 仍然是正確的基礎，而基於這些整理過的記錄構建的上下文圖應該完善這些 SOP，而不是完全取代它們。

上下文密度和熵管理

在上下文圖的討論中，經常出現一個強而有力的概念，那就是「上下文密度」──本質上是指圖中某個區域的約束程度。高密度區域對應低熵：智能體幾乎沒有自由度，必須遵循精確的步驟順序。低密度區域對應高熵：許多選項都是可接受的，允許實驗和創造，智能體的個人風格可以展現。

管理上下文密度本質上就是管理操作熵。在安全至關重要的指令中——例如臨床用藥或財務合規操作——你需要高密度：幾乎零歧義、明確的驗證步驟和非常窄的分支。在指導或探索性策略會議中，你需要低密度：使用者可以自由探索、提出開放式問題、比較不同方案，並且只需偶爾回到結構化的檢查點即可。

這種刻意熵分層的方法能讓你兼得兩者之長。這樣既能獲得高度結構化流程的可靠性（在這些流程中，任何錯誤都代價高昂），又能獲得適應性強、類似人類的靈活性（在這些流程中，細微差別和創造力至關重要）。上下文圖本身就成為了一種機制，透過這種機制，您可以逐個區域地調節約束強度，而不是試圖全局地「越獄」一個模型。

具體例子能讓人更容易理解。高密度區域可能對應於“按流程注射胰島素”，其中每個微觀決策都被嚴格限制。中等密度區域可能模擬“職業輔導”，其中存在建議的對話路徑，但也存在許多可接受的路徑。低密度區域可能涵蓋“探索未來目標”，其中圖僅定義了幾個大致的路徑點，並允許智能體在這些路徑點之間進行即興發揮。

從設計的角度來看，你可以把密度理解為預算。你願意承擔的風險越大，你賦予智能體在該情境圖中的自由度就越高。你的合規性和安全性要求越嚴格，你就越會將路徑壓縮成一條狹窄且完全佈滿監控設備的隧道。

多狀態遍歷和智能體的“隱藏旅程”

上下文圖的一個常被低估的功能是，它們能夠實現用戶回合之間豐富的內部遍歷。使用者看到的是簡單的來回對話或代表他們執行的單一操作；在幕後，代理可能會遍歷數十種內部狀態，查閱多個記憶，並完善內部計劃——所有這些都在圖表中完成——然後才會顯示回應。

許多框架都強制執行「動作狀態保證」：從使用者的角度來看，智能體總是從某個動作狀態開始和結束。中間發生的一切都——推理、假設生成、工具調用、策略評估、反思——都由更小的處理單元組成，這些處理單元透過上下文圖連接起來。這確保了每一次可見的互動都對應於底層結構中一條連貫且可追溯的路徑。

想像一下，一位用戶對治療師說：“我覺得我的職業生涯停滯不前。”表面上的回應可能只是一個充滿同理心的訊息，後面跟著幾個探究性的問題。然而，在系統內部，智能體可能會經歷多個階段：評估情緒基調、檢查風險因素、選擇相關的治療框架、提取類似的先例、制定多輪對話計劃，最後才產生下一則資訊。使用者體驗到的是自然流暢的對話；上下文圖保留了整個互動過程，雖然不可見，但完全可檢查。

設計師通常會從三個解析度等級來考慮這種遍歷。在全局層面，智能體可以看到圖中的大範圍區域，例如「評估」、「規劃」、「執行」和「審查」。在中層層面，它可以看到對應於特定工作流程或操作手冊的更詳細的子圖。在局部層面，它會推理單一回合內的微小狀態轉換。這種多解析度導航模擬了人類專家如何在宏觀框架和逐步執行之間切換視角。

關鍵在於，所有這些內部跳轉都可以作為決策追蹤的一部分進行記錄。這意味著風險、合規和品質團隊不僅可以重建代理向使用者輸出的內容，還可以重建它考慮的上下文、它應用的規則，以及它的路徑與過去成功或失敗的軌跡相比如何。

脈絡圖、記憶、知識和推理

只有將情境圖與功能性記憶和動態行為連結起來，才能充分發揮其潛力。記憶、知識和推理（通常縮寫為M-K-R）構成一個循環：記憶儲存過去的互動和痕跡，知識編碼關於世界的更穩定的事實和本體論，而推理則協調如何將兩者應用於新的情境。上下文圖位於這三條路徑的交會點。

在設計良好的智能體架構中，上下文圖提供了記憶和知識被提取或更新的路徑和決策點。當代理程式處理新案例時，它可能會從內容圖譜中檢索相關文檔，從知識圖譜中提取實體關係，然後將自身操作記錄為上下文圖中的新決策軌跡。每個成功或失敗的結果都會回饋給系統，更新系統對強先例和需要避免的反模式的判斷。

隨著時間的推移，你會從靜態的「載入一些文檔，然後祈禱 RAG 系統能正常運作」的心態，轉變為高頻寬的回饋循環。智能體不僅會消耗上下文訊息，還會產生結構化的上下文資訊。這些新的上下文資訊隨後可供後續推理步驟使用，既適用於同一智能體，也適用於在相鄰工作流程中運行的其他智能體。記憶體組織、本體設計或推理策略的改進會波及整個上下文圖，反之亦然。

這也是自動化優化工具發揮作用的地方。像「Agent Forge」（以及類似的編碼代理）這樣的系統可以從圖論層面分析現實世界的性能數據：哪些遍歷模式與成功相關，代理會在哪些地方卡住，認知負荷會在哪些地方飆升，哪些密度校準過緊或過鬆。編碼代理程式無需手動調整圖，即可透過程式調整狀態、邊和密度，並根據可衡量的結果來演化圖。

長遠願景是建構一個自我完善的生態系統。智能體在上下文圖上運行，產生軌跡，優化智能體基於這些軌跡優化上下文圖，更新後的上下文圖能夠幫助使用者做出更優的決策。本質上，它是在工作流程上進行強化學習，以上下文圖作為共享基礎。

脈絡圖、知識圖譜和基於三元組的世界

要全面理解上下文圖，必須將其置於更廣泛的圖技術體系中來考察。該領域許多混亂都源自於「知識圖譜」、「GraphRAG」和「本體論」等術語的過度使用，每個術語都有其自身的發展歷程和擁護者。上下文圖譜吸收了所有這些概念的思想，但又無法被簡化為任何單一概念。

經典的知識圖譜將實體及其關係表示為三元組。：主詞 → 謂詞 → 受詞。例如，「Alice → isMotherOf → Bob」或「Ticket123 → governed_by → Policy_v4」。這些三元組通常儲存在 RDF 三元組儲存庫或屬性圖資料庫中。 RDF 提供了一系列豐富的標準——RDFS 用於模式，OWL 用於本體——而像 Neo4j 中的屬性圖則強調節點、邊和屬性，並使用 Cypher 或最近的 GQL 等對開發者更友好的查詢語言。

關於知識建模「正確方法」的爭論已經持續了幾十年。RDF 的支持者強調其強大的表達能力和透過 URI 實現的互通性；屬性圖的擁護者則更青睞節點-邊建模的簡潔性以及邊上屬性的統一性。 OWL、SKOS 或 Schema.org 等本體則加入了領域詞彙表、限制和層級結構，從而能夠為實體和關係定義機器可讀的含義。

上下文圖通常位於這些結構的上方或旁邊，而不是取代它們。您可以使用知識圖譜來表示您的客戶、產品、合約和政策，並使用內容圖譜來組織文件、工單和記錄。然後，上下文圖譜透過儲存決策軌跡將這些實體和文件按時間順序連結起來，例如：“該政策的例外情況”、“該人員的批准”、“該事件中使用的操作手冊”，並包含時間戳和結果。

LLM 時代的一個有趣變化是，模型現在可以流暢地讀取和寫入人類可讀格式和機器可讀格式。實驗表明，即使RDF或Cypher格式的上下文資訊在詞元數量上更為冗長，但與非結構化文字或粗糙的CSV檔案相比，它們可以產生更好的結果。結構本身就清楚地傳達了節點、邊和屬性的概念，從而減輕了模型動態推斷模式的負擔。

超越 RAG：GraphRAG、本體與時間上下文

從簡單的紅黃綠圖到情境圖的演變過程要經歷幾個中間階段。首先，我們使用普通的邏輯學習模型（LLM）來回答訓練資料中的問題。然後出現了RAG：它將文件分塊，將它們嵌入為向量，並將最相似的區塊填入提示中。 GraphRAG在此基礎上進行了擴展，使用基於圖的表示（通常是源自LLM的知識圖譜）來捕獲實體之間的關係，並利用這些關係進行檢索。

基於本體的 RAG 透過引入更明確的模式和關係更進一步。與其讓模型隨意產生謂詞，不如為您的領域定義一個受控詞彙表（本體），例如「客戶」、「合約」、「事件」、「政策」、「批准」以及特定的關係類型。這樣，檢索過程就能遵循這些語義，從而提高準確率和召回率。

上下文圖建立在以上所有要素之上，並增加了兩個關鍵要素：時間和決策。它們與事件溯源的理念相符，事件溯源將狀態變化表示為一系列可重播的事件。差異在於重點：事件溯源著重於狀態轉換（什麼發生了變化以及何時發生了變化），而上下文圖則著重於決策轉換（哪些推理、例外情況、審批和策略證明了這些變化的合理性）。

時間關係對於信任和治理尤其重要。諸如「這項政策是否仍然有效？」或「這項例外是在風險偏好改變之前還是之後授予的？」之類的問題，取決於對事實、政策和行為如何隨時間演變的理解。時間性紅黃綠圖和時間性知識圖譜探索了這一領域，而上下文圖譜則可以利用這些技術來追蹤資訊在長期內的新鮮度、穩定性和可驗證性。

隨著層級模型（LLM）在處理動態本體方面變得越來越出色，我們或許最終能夠看到語意網路的一些長期願景得以實現。與其在編寫檢索演算法之前試圖凍結一個完美的本體，不如讓本體隨著智能體在決策軌跡中遇到新模式而演化，並使用模型本身來解釋和適應不斷變化的模式。

營運與決策背景：為什麼僅靠 RAG 系統會停滯不前

從管理者的角度來看，上下文圖可以解釋為什麼「我們將 RAG 系統連接到文件中」常常令人失望。大多數企業都缺少兩個層面的背景資訊：營運背景和決策背景。營運背景涉及所有權歸屬、實體間關係、哪些記錄系統至關重要以及現狀如何。決策背景則涉及決策是如何隨著時間而實際做出的，包括先例和可審計性。

普通的 RAG 向量只能提供內容片段，而不能提供操作結構或決策沿襲資訊。您可以查閱政策文件，其中規定超過 10% 的折扣需要審批，但您看不到的是，實際上，當存在未解決的升級問題且之前發生過服務中斷時，財務部門通常會批准某些特定客戶群享受 15% 的折扣。您可以查閱入職清單文件，但您看不到的是，業績優秀的員工會跳過步驟 4、7 和 9，因為這些步驟對他們來說沒有價值。

上下文圖透過使先例可搜尋來解決這個問題。你可以詢問“我們之前是否遇到過類似的情況？”或者“過去十次批准此類例外情況時發生了什麼？”，從而獲得結構化的追蹤記錄，而不僅僅是文件。這使得工作人員能夠按照政策和實踐相結合的方式行事，或指出兩者有分歧、需要人工幹預的地方。

至關重要的是，這使得治理從純粹的把關轉變為學習系統。與其試圖事先預測並阻止所有極端情況，不如允許極端情況在可控條件下發生，將其作為痕跡進行記錄，然後根據觀察到的情況改進策略和圖結構。隨著時間的推移，您的上下文圖將成為組織風險承受能力和營運智慧的簡潔體現。

也正是在這裡，質疑的聲音至關重要。如果天真地將過去發生的事情當作既定政策，只會將不一致和偏見合法化。決策軌跡需要精心整理；它們只是原始素材，而非最終真理。經過整理的標準作業程序 (SOP) 和驗證的行動指南才是基石。精心設計的脈絡圖譜有助於識別值得轉化為新政策的例外情況，並揭示組織本身規章制度被忽視之處。

為什麼在現實世界中建構情境圖很困難

這一切聽起來都很美好，但實際操作起來卻存在巨大差距。大多數組織仍在努力實現基本的數據統一——即如何使客戶關係管理 (CRM)、支援、分析和產品數據保持一致。許多組織才剛開始在諸如一級支援或內部知識搜尋等特定領域嘗試使用半自主代理。

一個深刻而實際的問題是，大多數工作並沒有可以輕易記錄的明確的「決策時刻」。折扣審批是一個清晰明確的事件，可以記錄下來。但兩位處理人員之間理賠處理時間相差 6 倍，往往源自於工作流程中一些細微的選擇：誰負責驗證什麼，驗證順序如何，使用哪些工具，通過哪些管道。這些微小的決策很少以獨立事件的形式出現，它們存在於執行路徑中——電子郵件往來、Slack 討論串、電子表格核對以及臨時電話會議中。

傳統分析和流程挖掘工具只能看到系統中記錄的內容。他們可以告訴你一張發票「待審批」狀態停留了10天，但他們看不到其中7天都花在了追查丟失的PDF文件、在Excel中核對供應商資訊以及透過Slack協調例外情況上。真正的原因——「為什麼花了28天而不是8天」——就存在於不同的系統之間。

這就是為什麼一些建構者認為上下文圖必須從執行層面向上構建，而不是從文件層面向下構建。你需要一套位於執行路徑中的基礎設施，它能夠跨工具解析身份（例如，john.smith@company.com = @jsmith = 員工編號 12345），並即時捕捉工作在各個渠道間的流動情況。只有這樣，你才能從觀察到的行為推斷決策，並將其轉化為可靠的決策軌跡。

在此基礎上，也存在代理採納問題。許多雄心勃勃的上下文圖願景都假設智能體已經執行了大部分工作流程，因此能夠自然地產生豐富且結構化的軌跡。然而，在現實中，大多數企業的智能體仍處於早期階段，功能有限，且受到嚴格的監管。要求企業在尚未信任智能體執行核心工作流程之前就建造完整的決策軌跡基礎設施，就好比要求企業在尚未擁有任何車輛的情況下就建造一個可停放三輛車的車庫一樣荒謬。

架構模式與務實採納

儘管有許多障礙，但一些架構模式正在湧現，可供那些希望朝這個方向發展而又不想付出巨大代價的組織參考。首先，不要再把上下文圖看作是一個學術資料建模項目，而應該從一個高價值的工作流程開始，在這個工作流程中，代理的可靠性和可審計性是不可妥協的。

優秀的候選人通常具備三個特質。：這類問題涉及許多例外情況，跨越多個系統，任何錯誤的決策都可能帶來真正的風險。例如，交易台的折扣​​和批准、支援升級和根本原因分析、供應商入駐和安全例外情況，以及由政策驅動的人力資源案例（如休假和住宿安排）。在所有這些案例中，客服人員都需要了解營運背景（誰負責什麼，何時發生了哪些變更）和決策背景（之前如何處理類似案例，誰批准了偏差，哪些方法有效）。

實際的出發點是刻意選擇一個較小的方案。您可以定義 8-15 種核心實體類型（客戶、產品、合約、策略、工單、事件、批准、異常、所有者）和 15-25 種關係類型（受管轄、例外、批准、引用、影響、類似、取代）。請使用業務語言，而非學術術語。目標是實現清晰的溝通，而非追求本體論上的純粹性。

從技術上講，你攝取了一些高價值的儲存庫。 從工單系統、CRM 備註、政策文件、運行手冊等數據中提取實體和元數據，並將關係儲存在您選擇的圖資料庫中，同時保持原始文件可存取以便引用。此外，您還可以對代理或工作流程引擎進行配置，使每個重要操作都能產生結構化的追蹤記錄：包括帶有時間戳記和權限的輸入、帶有版本號的規則、帶有理由的異常處理、請求和授予的審批，以及寫回記錄系統的操作。

在此基礎上，您可以將業務成果作為衡量指標。與其吹噓“節省了多少令牌”，不如追蹤支援部門的故障轉移率和解決品質、交易部門和採購部門的周期時間和異常率、法律和安全部門的政策合規性和審計結果，以及營運部門的返工率和升級率。隨著圖譜覆蓋率和追蹤品質的提高，您應該會看到更好的異常處理、更少的不必要的人工升級以及更一致的結果。

隨著時間的推移，諸如跨圖導航之類的其他層級可能會發揮作用。您可以按領域劃分圖——一個用於操作上下文，一個用於內容，一個用於決策——並允許代理在不同圖之間跳轉，而無需創建單個龐大且難以管理的圖。這種「圖的圖」方法使您能夠在不損失模組化的情況下對嵌套問題空間（電影《全面啟動》中的「夢中夢」隱喻）進行建模。

這一切只有在你將決策傳承和出處視為同等重要的情況下才能奏效。每個智能體的操作都應該有風險團隊認可的「操作步驟」記錄，並且檢索到的每一個事實都應該有明確的來源：文件、系統記錄或特定的追蹤事件。這樣才能將人工智慧治理從一系列令人不適的審查會議轉變為架構本身固有的結構性能力。

綜上所述，上下文圖代表了數十年來圖論研究、語意網願景、事件溯源和現代LLM能力的融合。它們並非萬能靈藥，而且炒作往往掩蓋了數據品質、執行可見性和代理採用率方面存在的許多實際差距。但隨著企業不再滿足於表面功夫，而是開始追求可問責、可重複的AI驅動運營，圖狀的、時間性的、以決策為中心的記憶層這一概念，不再僅僅是一個流行語，而更像是技術棧中不可或缺的一部分——前提是我們基於精心設計的策略、真實的執行數據和務實的預期來構建它，而不是基於原始數據和關於萬億美元的空洞。