在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，並測試了代理查詢。結果證明，語義層成功地將來自兩個源的客戶資料整合在一起，正確識別了大額支出者，並提供了支援數字。代理能夠回答原本不可能的問題，而無需預先構建的整合資料管道。