數據分析與AI丨Graph+LLM 如何重塑傳統 BI 的未來

ALTAIR

導讀隨著企業數據復雜度的指數級增長，傳統 #BI 工具在動態關系分析、多模態數據處理及自然語言交互等方面的缺陷日益凸顯。本文提出一種基于#圖數據庫（Graph Database）與#大語言模型（LLM）深度融合的新型數據分析架構，通過引入#語義增強技術（RDFS/OWL）與動態關系建模能力，實現從靜態報表到智能推理的范式躍遷，為企業在供應鏈優化、知識圖譜構建等場景提供可落地的解決方案。

文章將從以下幾個方面展開介紹：

1. 選擇圖數據而不是關系型數據

2. 關系型數據如何變成圖數據

3.LLM 如何從圖中查詢數據

分享嘉賓｜趙帥 Altair 數據分析高級應用工程師

編輯整理｜蘇磊

內容校對｜李瑤

出品社區｜DataFun

選擇圖數據而不是關系型數據

首先來探討為什么選擇#圖數據而不選擇關系型數據作為底層存儲。

圖數據的優勢主要在于：

靈活的數據模型：圖數據在定義表結構時，無需事先定義結構，而是可根據業務需求靈活進行節點和邊的拓展。
擅長處理復雜的關系數據：在存儲過程中，圖數據庫將數據看作由節點和邊組成的圖形結構，便于查詢和理解數據。
更高的查詢效率：利用圖遍歷算法，可快速找到節點和節點之間的關系路徑，因此更擅長解決長鏈、復雜、深度查詢等問題。比如查詢數據超過 6 ~ 7 層的表關聯情況，關系型數據庫很難應對如此復雜的多層次查詢。
支持非結構化數據：圖數據庫可以通過圖模型來存儲半結構化數據和非結構化數據，比如文檔、圖片、視頻等。

基于這些優勢，圖數據庫能夠更好地與大模型進行結合。接下來將介紹如何在圖數據庫中表征關系型數據。

關系型數據如何變成圖數據

1.圖數據的表現形式

RDF（Resource Description Framework），即資源描述框架，是一種描述數據文件存儲的數據模型，該數據模型通常由三個部分組成，稱為三元組。例如，要描述足球運動員羅納爾多的信息，可以用以下 RDF 三元組來表示：

主語（Subject）：Person（指代羅納爾多）

謂語（Predicate）：Chinese Name

賓語（Object）：羅納爾多

類似地，還可以描述他的英文名、出生地、身高、生日等信息。這些三元組共同構成了一張知識圖譜，宛如一幅數據的星圖，清晰地勾勒出實體之間的關聯網絡。在這張圖中，每個節點代表一個實體（如“羅納爾多”或“巴西”），每條邊則象征著實體之間的關系（如“出生于”或“身高”）。通過這種方式，圖數據庫不僅記錄了數據本身，還捕捉了數據之間的深層語義。

然而 RDF 的表達能力有限，缺乏抽象能力，無法對同一類別的事物進行定義和描述。基于此，引入 RDFS。RDFS 為 RDF 提供了一種簡單的模式語言，在RDF的基礎上增加了 schema 的概念，使得我們能夠對實體類和屬性類進行定義。

rdfs:class 定義實體類，如下圖中的“Person”和“Place”，類似于關系型數據庫中的表。
rdfs:property 定義屬性，例如 Person 的生日、身高等，類似于表中的列。
rdfs:domain 表示該屬性屬于哪個類別，例如 career 屬于 Person 表。
rdfs:range 描述該屬性的取值類型。

RDFS 的表征能力仍然有限，所以在此基礎上進一步做了擴充，引入了 OWL。OWL（Web Ontology Language）基于 RDS 和 RDFS，在語義表征推理和擴展性上都做了提升，能夠更精確地描述知識結構和語義關系。

例如，在 OWL 中對屬性進一步細化，將一個類的內部屬性（如“身高”、“職業”）定義為 DatatypeProperty，而將類之間的關系（如“出生地”）定義為 ObjectProperty。

OWL 為復雜的數據建模提供了強大的工具。

2.關系型數據轉換為圖數據

前面介紹了如何在圖數據庫中表征結構化數據，接下來將講解如何將關系型數據轉換為圖數據。這一過程通常包括以下四個步驟：

數據建模：需要根據業務需求設計圖數據庫的節點和邊模型。例如，確定哪些實體需要作為節點，哪些關系需要作為邊。這一步驟就像繪制一幅地圖，明確每一座城市（節點）和道路（邊）的位置與連接方式。
數據導出：從關系型數據庫中提取數據，并對其進行必要的清洗和轉換，以確保數據質量。這一步驟猶如淘金，需去除雜質，留下最純凈的寶藏。
格式轉換：關系型數據轉換成 OWL 格式數據（RDF/OWL）。
數據導入：將清洗后的數據加載到圖數據庫中。這一步驟可能需要編寫 ETL 腳本或使用專門的工具，如同將精煉后的黃金鑄造成藝術品。驗證數據加載的正確性，并根據實際查詢需求對圖數據庫進行優化。

通過以上步驟，便可高效地將傳統關系型數據遷移到圖數據庫中，為后續的大模型查詢和可視化奠定堅實基礎。

3.Altair Graph Studio 數據編織平臺

在企業將關系型數據轉換為圖數據庫時，通常更傾向于借助成熟的商業平臺來高效完成這一過程。為此，Altair 推出了 Graph Studio 數據編織平臺。該平臺底層采用自研的圖數據庫，能夠自動將用戶加載的結構化、非結構化或半結構化數據轉換為圖數據格式，無需用戶進行編程或依賴其他開源工具。

Graph Studio 的架構包含數據編織平臺和 Graph LakeHouse 兩大部分。Graph LakeHouse 是 Altair 自主研發的高性能圖數據庫，兼具性能與特色優勢，技術核心聚焦于三大創新點：

MPP（大規模并行處理）架構，從設計之初便支持高并發、分布式集群部署。在需要擴展至大規模集群時無需額外付費，充分滿足企業級需求。
內存常駐計算引擎，數據可完全駐留在內存中。這一特性尤其適合對查詢響應速度要求極高的場景，能夠顯著降低延遲，提供卓越的實時計算能力。
對外提供了通用的OLAP 查詢接口。這意味著用戶可以直接將其作為關系型數據庫使用，無縫對接大模型、BI 工具及 AI 軟件等多樣化應用。

性能方面，在 200 節點集群的極限測試中，能夠在 1 小時 45 分完成 1.065 萬億三元組數據加載，查詢響應時間控制在1.67 至 189.18 秒之間，展現了強大的規模化處理能力。

基于圖數據庫開發了 Graph Studio 可視化數據編織平臺。通過該平臺，用戶可以輕松加載結構化與非結構化數據，無需編寫代碼即可完成數據查詢、轉換及向圖數據庫的導入操作，讓用戶能夠高效實現從關系型數據到圖數據的轉換過程。

在 Graph Studio平臺上，數據編織分為四個關鍵步驟：

數據加載（On-board）：支持配置慣性數據或非結構化數據源，平臺能夠自動讀取這些數據。
模型構建：自動識別關系數據庫中的表字段及表間關系，并在圖數據庫中自動生成對應的圖模型，整個過程完全自動化。
數據融合：針對多數據源場景，支持將不同來源生成的小規模圖模型融合為全域模型，實現數據的統一整合。
數據訪問與應用：提供多樣化的數據訪問方式，包括可視化看板構建、OLAP 接口供第三方系統調用，以及自然語言對話查詢接口，便于與大模型聯動。

數據編織流程如下圖所示，從左到右，讀取不同來源的數據，自動生成對應數據源的圖模型。基于這些獨立的圖模型，我們可以實現數據融合。如果分析業務需要從整體圖模型中抽取部分數據進行專題分析，提供圖數據集市功能。最終，通過通用接口對外暴露，方便您的

AI 系統、BI 工具或大模型對數據進行訪問與調用。

下圖展示了上述操作的界面，以下是關鍵環節的簡要說明：

數據源定義：用戶可通過界面定義多種數據源，包括關系型數據庫（如 MySQL、Oracle）或大數據平臺的數據。
自動生成圖結構與數據加載：系統會自動識別指定 schema 中的表、字段及表間關系，構建圖結構，并將原始數據源中的數據讀取并加載至該圖結構中。
數據融合：若需整合不同來源的數據，可在第三步完成。例如，將 MFG 模型與 Tube Order 模型融合，生成新的圖模型，并加載對應數據。新圖模型生成：基于融合后的數據，系統生成新的圖模型并完成數據加載。
數據訪問：最后一步提供數據訪問功能，包括快速構建儀表板和通用訪問接口，便于用戶對生成的圖模型進行數據查詢與分析。

若結構化數據本身較為規范（如來自數倉），整個流程從數據連接到圖模型生成僅需 5 至 10 分鐘即可完成。

數據存儲完成后，提供三種訪問方式：第一，通過自帶的 dashboard 工具，在平臺上構建可視化看板，進行數據分析；第二，支持標準的 SPARQL 查詢語言，作為圖數據庫的通用查詢語言，可對模型數據進行查詢；第三，提供標準的 OData 訪問協議，包括 ODBC 和 JDBC 接口，便于其他軟件（如 BI 或 AI 工具）查詢圖數據庫中的數據。

LLM 如何從圖中查詢數據

接下來介紹如何利用大模型，通過自然語言對話的方式，實現對圖數據庫中圖數據進行查詢。

大模型的核心能力在于能夠精準理解用戶的自然語言提問，并具備上下文記憶功能，從而連貫地處理多輪對話。不僅能理解單一模態信息，如文本、語音和圖像，還能將不同模態的信息聯合起來，比如理解一張圖片中的內容并用文字描述它。

1.RAG-檢索增強生成

RAG 技術已日趨成熟，其核心流程為將非結構化文檔分割為文本塊，通過嵌入模型將其向量化，并存儲至向量數據庫。當用戶提問時，問題同樣被轉化為向量，用于檢索數據庫中與之最相似的回答，隨后由大模型對這些回答進行總結并反饋給用戶。

然而，RAG 技術也存在不足之處，為了增強其性能，GraphRAG 被引入以提升回答能力。但無論是 RAG 還是 GraphRAG，它們主要聚焦于非結構化數據（如 Word 文檔、PPT 等），而對結構化數據（如表格數據）的支持則相對薄弱。

2.Text-To-Query

基于結構化數據的問答，主要采用 text to query 的方式。無論是將用戶問題轉化為關系數據庫的 SQL 查詢，還是轉換為針對知識圖譜或圖數據庫的查詢，均屬于這一范疇。在 Altair 的實踐中，選擇了知識圖譜與圖數據庫結合大模型的方式。這種方式能夠高效解決針對關系型數據的問答需求。由于 Text-To-Query 的技術架構特性，查詢結果具有高度精確性——前提是生成的查詢語句無誤。一旦查詢成功，基于圖數據庫的特性，返回的數據一定是準確的。這種機制在很大程度上緩解了大模型在企業知識問答或數據問答場景中的“幻覺問題”。這也是采用 Text-To-Query 技術的核心原因。

3.Altair Copilot 如何回答企業用戶問題

Altair Copilot 通過大模型與知識圖譜結合，幫助企業內部用戶高效解答問題。其流程分為四個關鍵步驟：

主體與關系提取。大模型從用戶提問中解析出核心主體及其潛在關系。例如，在問題中識別“supplier”（供應商）和“distribution center”（分發中心）等主體，并捕捉它們之間的關系（如分數大于 0.7、位于某國家等）。此步驟確保問題中的語義信息被精準拆解。
映射到知識圖譜。大模型將提取的主體與關系映射至知識圖譜或圖數據庫中的實體與關系。例如，“supplier”可能對應圖數據庫中的“PRM supplier”，而“located in”可能映射為“HQ_located_in”。通過這種映射，用戶問題被轉化為圖數據庫可理解的查詢語言。
生成查詢并獲取結果。基于映射結果，大模型生成針對知識圖譜的查詢語句，并將其傳遞給圖數據庫執行查詢。這一過程確保返回的結果精確且無誤。
生成答案。大模型基于查詢結果組織語言，形成自然流暢的回答，直接回應用戶的原始問題。

4.ChatBI 優勢

與傳統 BI 報表相比，Altair ChatBI 展現出以下核心優勢：

效率提升：傳統模式下，IT 或 BI 團隊需預先構建分析型報表，而 ChatBI 解決方案使業務用戶能夠通過自然語言對話直接查詢數據并生成可視化結果，無需預先構建報表，顯著提高了業務用戶的操作效率。
應用性增強：業務用戶無需深入了解業務系統或數倉中的數據結構，僅需以自然語言提問即可獲取所需數據，極大降低了使用門檻，提升了系統的易用性。
成本節約：通過減少 IT 人員在預定義和構建BI報表上的工作量，企業能夠顯著降低相關人力成本，實現資源的更高效配置。