受控 SQL、獎牌式語義層，以及三種查詢引擎如何讓企業資料真正可查詢 — 而不會產生幻覺欄位名稱。

大多數 Text-to-SQL 示範在真正企業資料上測試之前看起來都很好。您詢問「上季前 10 名依營收排名之物料是哪些？」模型卻自信地回傳一個將 ORDERS 與 PRODUCTS 做 JOIN 的查詢 — 這些資料表在您的 SAP 系統中根本不存在。或者它虛構了一個叫 revenue 的欄位，而真正的欄位藏在 VBAK.NETWR 之中，這個欄位的意義只有當您擔任多年 SAP 顧問才會知道。

這就是我們著手解決 Onibex ASK — Agentic Semantic Knowledge 的問題。ASK 是一個開放平台，能將自然語言轉換成 SAP 資料上的受控 SQL。「受控」一詞在此承擔了大量工作，值得詳細說明其意義，以及為什麼它改變了一切。

LLM 應該是編譯器，而不是發明者

大多數 Text-to-SQL 系統給 LLM 一個資料庫結構描述，要求它「自己想辦法」。這對於簡單結構描述 — 少數資料表且名稱明顯 — 效果意外地好。但 SAP HANA 結構描述並不簡單。一個真正的 S/4HANA 系統可能有數千個資料表、隱晦的四字母欄位名稱，以及為了效能而非可讀性所設計的 JOIN 條件。

我們的做法不同：LLM 從不發明結構。它只將業務術語對應到經過策展的語義層。

語義層 — 我們稱為 Data Products 的一組 YAML 檔案 — 是單一真實來源。查詢中的每一個欄位都必須追溯到真實資料表中的真實欄位，並附上確切的 JOIN 條件。LLM 是一個編譯器：它接收自然語言問題，在語義層中查詢相符的業務術語，然後僅根據這些解析過的對應關係輸出 SQL。如果某個術語不在語義層中，代理程式會要求澄清，而不是猜測。

當使用者詢問「依物料分類的營收是多少？」ASK 會透過 synonyms 欄位將「revenue」對應到 VBAK.NETWR。它知道從 VBAK 到 VBAP 的 JOIN，因為 Data Product 定義了它。它絕不碰觸其他任何資料表。SQL 是可重現、可稽核且確定的 — 不是因為 LLM 特別聰明，而是因為它在嚴格的護欄內運作。

套用至 SAP 的獎牌模型

讓其他一切運作的結構性決策之一，就是針對語義層採用 Bronze / Silver / Gold 獎牌模型。

Bronze 是原始 SAP 資料表 — 僅有欄位與主鍵，沒有 JOIN 邏輯。VBAK（銷售訂單表頭）、VBAP（銷售訂單項目）、MARA（物料主檔）。這些資料表的存在是為了讓 ASK 了解實體結構描述。

Silver 是業務邏輯所在之處。Silver 實體會將多個 Bronze 資料表 JOIN 成一個連貫的業務概念，擁有該概念的完整 JOIN 拓撲，並定義欄位角色：量值、維度、識別碼、時間戳記。Silver 平面是代理程式的備援 — 如果沒有 Gold 實體涵蓋問題，ASK 會從 Silver 解析並計算 JOIN。

Gold 是反正規化分析 — 預先 JOIN、預先聚合的實體，代理程式可在一趟掃描中查詢。當 Gold 實體涵蓋問題所需確切的量值與維度時，ASK 僅從 Gold 查詢答案。無 JOIN、無規劃開銷、延遲最低。

問題：「依淨值排名前 10 名的物料，Q1」│ ▼ 是否有 Gold 實體涵蓋此問題？├─ 是 → 對 Gold 資料表執行單一查詢 └─ 否 → 透過 Silver 實體解析（VBAK + VBAP JOIN）

這種 Gold 優先的解析機制正是讓查詢延遲在規模化時保持合理的原因。建模良好的 Gold 實體涵蓋業務使用者實際詢問的 80% 問題。Silver 處理長尾問題。

三種引擎應對不同取捨

我們花最長時間思考的問題之一是：代理程式對每個查詢應該執行多少規劃？更多的規劃意味著更好的 SQL — 但也意味著更多的 LLM 呼叫、更多的延遲，以及更高的成本。我們最終發布了三種引擎，讓使用者與管理員能夠明確地做出取捨。

Flash
1 次 LLM 呼叫 · 約 15 秒 · 低成本

以自由文字區塊搜尋結構描述，一次完成 SQL 撰寫。無語義計畫、無 JOIN 驗證、無範圍檢查。快速且便宜 — 適合探索性問題。可重現性最低：同一個問題詢問兩次可能產生略有不同的 SQL。

Precise
3 次 LLM 呼叫 · 約 60 秒 · 高信心度

擷取語義計畫 IR，執行帶有 Medallion 重新排序的混合 kNN+BM25 搜尋，以 Dijkstra 演算法規劃 JOIN，產生 SQL，然後對允許的資料表集合進行稽核 — 若超出範圍則重試一次。完全確定的 Data Product 選取。適用於合規、稽核軌跡，或 Flash 失敗時使用。

Smart
2 次 LLM 呼叫 · 約 40 秒 · 預設

向 LLM 顯示精簡目錄，讓其挑選相關的 Data Products — 選取是由模型驅動。但選取後的 JOIN 規劃使用與 Precise 相同的 Dijkstra 圖。平衡速度與準確度，適用於日常生產使用。

此設計背後的洞見是：確定性放在哪裡很重要。Precise 讓 Data Products 的選取具有確定性。Smart 讓 JOIN 規劃具有確定性。Flash 則將兩者都交給模型。需要可稽核性的使用者使用 Precise；需要高吞吐量的使用者使用 Smart；需要速度的使用者使用 Flash。

當問題模稜兩可時會發生什麼？

真實企業資料存在詞彙問題。「Sales」可能指 SD 模組中的 VBAK，或 MM 模組中的 EKKO（從採購角度）。「Revenue」可能指毛額或淨額，取決於使用者是在財務或銷售部門。

ASK 透過 OpenSearch 中的語義字典索引，處理三層級的消歧系統。

第 1 層：若某術語只對應到一個實體，代理程式自動解析。不會中斷。

第 2 層：若某術語對應到跨不同 SAP 模組的多個實體，代理程式會顯示消歧訊息 — 「您指的是 SD 銷售訂單還是 MM 採購訂單？」 — 並等待。不會猜測。

第 3 層：若該術語完全沒有對應，代理程式會回傳明確訊息，引導使用者至其 Agentic Trainer。它絕不會幻覺出解析結果。

語義字典由管理員透過 ASK Configuration App 進行管理 — 這是一個 React SPA，讓您可以註冊標準欄位標籤、SAP 欄位對應、同義詞、情境線索，以及每個模組的消歧提示，全部索引至 OpenSearch 以進行混合檢索。

成品

成品是一個完整的業務文件 — 銷售報告、執行簡報、資料表包 — 完全由自然語言產生。使用者在四步驟對話式精靈中描述需求，涵蓋名稱、對象與目的、要包含的資料，以及格式。代理程式規劃並執行多個 SQL 查詢，從結果撰寫結構化敘述，並回傳內嵌資料表的格式化文件。

輸出可下載為 Excel 檔案 — 包含敘述性 Report 工作表、每個查詢結果一個 Data 工作表，以及一個 SQL 工作表 — 完全在瀏覽器中組裝，無需伺服器端 Excel 相依性。

這與「只是產生報告」不同之處在於：文件中的資料受與其他所有查詢相同的語義層管制。執行簡報中的「依物料分類營收」資料表，使用與聊天答案相同的 VBAK.NETWR 欄位。沒有需要同步的獨立報表層。

我們學到的教訓

01. 結構描述品質就是產品

ASK 的好壞取決於描述資料的 Data Products。新增的每個同義詞、字典中的每個消歧提示、每個 JOIN 條件的業務語言描述 — 所有這些都直接改善答案品質。工程是基礎設施；語義層才是產品。

02. 確定性是一項功能，而非限制

我們選擇讓 JOIN 規劃具有確定性 — 使用圖形上的 Dijkstra 演算法，而非由 LLM 選擇 JOIN — 因為使用者需要向稽核員解釋答案。「代理程式選擇此 JOIN 是因為它是這些兩個實體在關係圖中的最短路徑」，比「模型選擇了它」更容易作為辯護。

03. 三種引擎不是過度工程化

Flash 與 Precise 服務於截然不同的使用情境 — 沒有單一引擎能同時涵蓋兩者。Smart 成為 80% 情境的預設值。明確的模式也為使用者提供除錯工具：若 Smart 失敗，試試 Precise；若 Precise 太慢，試試 Flash。模式選擇器既是診斷功能，也是設定選項。

04. 管制需要儀式

dev → prod 推廣流程在我們設計時感覺像是額外負擔。實際上，使用者告訴我們這是最有價值的功能之一。糟糕的欄位描述可能破壞 dev 查詢，但它絕不會悄無聲息地破壞執行長週一早上正在查詢的生產資料。

試用 Agentic Semantic Knowledge

語義層規格、平台程式碼以及完整手冊已發布在 GitHub 上。如果您正在處理 SAP 資料 — 或任何具有複雜結構描述的企業資料 — Bronze/Silver/Gold 模型與受控 SQL 方法值得了解，無論您是否使用此平台。View on github。