在AWS上使用Stardog和Amazon Bedrock AgentCore構建用於代理式AI的語義層

企業分析二十年來一直追求同一個目標：縮短從業務問題到可信答案的時間。預定報告讓位給儀表盤，儀表盤又讓位給自助式商業智能（BI）。然而，即使自助式分析也依賴於數據工程師預先為特定問題構建正確的模型，而人類分析師仍然是準備數據集之外的瓶頸。生成式AI代理是下一步。它們不是可視化數據，而是對數據進行推理。它們自主規劃、編寫查詢、評估結果、優化，並根據需求在公司實時數據上進行迭代。代理式分析就是這個轉變的術語：每個業務用户身邊都有一個自主代理，無需等待請求隊列即可完成分析師的工作。

難點不再是基礎模型。Amazon Bedrock上可用的基礎模型已經能夠規劃多步驟工作流，推理模式，並生成足以勝任初級分析師的SQL。難點在於模型推理的數據。企業數據分散在各系統中，這些系統對相同事物的定義不同。客户關係管理（CRM）系統中的“客户”與計費系統中的“客户”不是同一條記錄。北美團隊計算的“收入”與歐洲團隊產生的數字不同。AI代理直接訪問這些碎片化數據將編寫技術上有效但返回錯誤、衝突或無法解釋答案的查詢。當兩個代理對同一問題返回兩個不同數字時，信任就會崩潰。

在AWS上，這些數據分佈在常見的混合環境中。運營記錄存儲在Amazon Aurora和其他Amazon RDS引擎中。分析歷史存儲在Amazon Redshift中。非結構化數據存儲在Amazon S3中，通過Amazon Athena查詢，並且越來越多地採用開放表格式，如Apache Iceberg，在Amazon S3 Tables上，Athena、Amazon EMR和Amazon Redshift都可以讀取。每層都是針對其存儲內容而構建的，大多數企業將保持這種結構。挑戰在於幫助AI代理同時跨所有這些進行推理，就像高級人類分析師對同一問題的流暢度一樣。

基礎模型提供語言，AWS數據應用程序提供事實。今天連接它們的常見方式是檢索增強生成（RAG）：將政策文檔、手冊和支持工單索引到Amazon Bedrock知識庫中，並在查詢時將匹配段落拉入模型的上下文。當答案存在於搜索可找到的文本中時，RAG效果良好。但對於分析性問題，答案取決於跨系統連接實時記錄、一致應用業務規則以及遵守行級或列級訪問策略，RAG效果不佳。

介於語言和事實之間且通常缺失的是業務上下文和業務指標。以典型的零售示例為例：對客户是什麼的共同定義，訂單如何與客户關聯，什麼算作大額支出者或高風險賬户，哪個系統擁有哪些事實，以及業務報告的數字如何計算。相同的差距也出現在其他領域（保險中的索賠和保單，醫療保健中的患者和就診，供應鏈中的零件和發貨），只是名稱不同。語義層一次捕獲該上下文，並讓每個代理和工具重用。有了它，AI代理可以從多個來源組合答案，併為其返回的數字提供支持。語義層並不取代RAG，而是補充它。大多數生產系統兩者都需要，並通過同一個代理可訪問。

語義層是企業數據的本體驅動視圖。本體捕獲對業務重要的概念、關係、屬性和規則。映射聲明這些概念如何從每個實時來源的行中映射。代理查詢該層，層在運行時將每個查詢轉換為針對底層系統的SQL。數據保留在原處，含義被捕獲一次並重用。

當語義層像Stardog那樣實現時（本體、每個實體的穩定標識符、派生新事實的規則以及驗證數據是否符合本體的約束），結果就是知識圖譜。數據作為業務實體的圖而不是表中的行連接，每個實體都有一個稱為IRI的穩定URL式唯一標識符，查詢通過一種稱為SPARQL的W3C定義、基於標準的查詢語言遍歷這些連接。文中反覆出現兩個術語：命名圖是圖的標記子集，由它自己的IRI標識；虛擬圖是內容不存儲在Stardog中的命名圖，它們存在於外部系統（Aurora、Redshift、Athena）中，Stardog使用映射按需獲取行。

通過本文，您將瞭解：語義層如何與RAG配合以及何時選擇每種；如何跨Amazon Aurora和Amazon Redshift聯邦Stardog，並擴展到其他AWS數據源；為什麼推薦AgentCore運行時、網關和身份用於生產中的代理；從代理到Stardog的兩種集成路徑：直接SPARQL工具和Stardog Cloud MCP服務器作為網關工具目標；關於治理、部署以及GA與測試版的權衡。

代理所需的三個層 給出可靠、業務上下文感知答案的AI代理依賴於三個協同工作的組件。每個組件解決其他組件無法解決的問題。

1. 模型層：能夠規劃並編寫代碼的基礎模型。Amazon Bedrock提供單一API訪問多個模型系列。我們使用Anthropic Claude Sonnet 4.6。模型懂語言，不懂您的業務。
2. 含義層：為模型提供對業務問題背後數據的可信、受控訪問的語義層。本體聲明概念和從它們派生新事實的規則，聯邦在查詢時從每個來源拉取實時行。該層完成工作：確定哪些數據相關，將SPARQL查詢重寫為每個來源的SQL，並在共享標識符上連接行。模型的任務更窄：讀取用户問題，在需要數據時調用該層，並用通俗英語編寫答案。實際的數據推理，如在聯邦源上應用Big_Spender規則，保留在Stardog內而不是提示中。我們使用Stardog在Aurora和Redshift上的聯邦知識圖譜實現這一層。
3. 代理運行時層：託管代理、終止入站請求、管理工具憑證並提供安全與治理操作表面的計算。在AWS上，您有一系列選擇：一端是Amazon Bedrock AgentCore等託管運行時，另一端是Amazon ECS、Amazon EKS或AWS Lambda等自管理選項。正確的選擇取決於您希望擁有多少代理操作。我們使用Amazon Bedrock AgentCore，因為它是AWS上生產代理中最具規範性的選項。

在這三個層中，含義層是本文要解決的缺口，其餘的演練構建了它。代理運行時層是大多數團隊低估的：代理如何被調用，如何認證，其語義層憑證在哪裏，以及如何擴展。AgentCore將這些問題打包到一個託管服務中，這就是我們在此使用它的原因。

示例用例：跨Aurora和Redshift的客户360代理 我們選擇客户360（C360）用於本文的其餘部分，因為它展示了AI代理在執行真正分析工作時遇到的每一個缺口，並讓我們展示語義層如何在幾百行映射和規則中關閉每個缺口。在典型的零售設置中，客户資料、地址、信用卡和獎勵信息存在於運營數據庫中。訂單、產品、類別和供應商存在於數據倉庫中進行分析。每一方都針對其功能進行了優化。任何一方都無法單獨回答關於客户整體的問題。試圖回答“我們最有價值的客户是誰，他們在買什麼？”的代理必須協調兩個數據庫、兩個模式、兩個“客户”定義和一個衍生概念（“最有價值”），該概念不存在於任何列中。C360使這些缺口具體化。

C360代理為分析團隊運行。它接受來自銷售負責人、營銷人員或欺詐分析師的普通英語問題。它編寫查詢，跨公司數據運行，並回復簡短的敍述答案和支持數據。用户看不到SQL或SPARQL，代理看不到它不允許看到的數據。

用户用普通英語問C360代理：“威斯康星州的大額支出者是誰？”客户資料和地址在Aurora中。訂單總額在Redshift中。代理必須在穩定的客户標識符上連接它們，而該連接是語義層添加的三件事之一：

1. 通過共享含義跨系統連接。語義層使用共享業務鍵將Aurora和Redshift的客户記錄映射到共同客户身份。這使得連接可以通過語義模型表達，而不是物理集成管道。沒有它，該連接通常需要維護一個管道，該管道物化數據的第三份副本，並且每次任一源發生更改時都必須保持同步。
2. 作為規則而非查詢的派生事實。像“大額支出者”這樣的定義可以作為規則存在於本體中，而不是在每個查詢中重新表達，並且每個提到它的查詢獲得相同的答案。沒有它，該定義會在儀表盤、筆記本和報告中重複。當閾值更改時，副本會漂移，同一問題開始返回不同答案。
3. 圖級別訪問控制。命名圖安全性在圖形級別控制訪問，因此不同角色看到企業知識圖譜的不同子集。對於更細粒度的保護，您可以指定敏感屬性，如:ssn和:cardNumber作為受保護屬性。有權限的用户看到實際值，而其他人默認看到掩碼值。通過這種方法，不同角色可以運行相同查詢，而知識圖譜對訪問它的每個應用程序強制執行一致的安全策略。

我們採用了Stardog的C360知識工具包，它最初加載本地CSV，並改編為跨Aurora PostgreSQL（客户方）和Amazon Redshift（訂單方）進行聯邦。該工具包包含本體、映射和規則，全部使用Stardog的語法。我們部署了Stardog服務，配置了虛擬圖指向Aurora和Redshift，並測試了代理查詢。結果證明，語義層成功地將來自兩個源的客户數據整合在一起，正確識別了大額支出者，並提供了支持數字。代理能夠回答原本不可能的問題，而無需預先構建的集成數據管道。