AI賦能數據治理能力的十大模式
介紹
在數據驅動決策的時代,數據治理已從單純的法規遵及數據質量從發展成為推動明智決策的戰略舉措。在之前的探索中,我們深入研究了 OpenAI API 的潛力,以自動填充術語定義,從而提高數據治理任務的效率。今天,我們踏上了超越傳統的旅程,來到數據治理 3.0時代,我們將數據治理工具與大型語言模型 (LLM) 無縫集成,它們具有理解和生成類似人類文本的能力,處于這場革命的前沿,自動執行大量任務并增強用戶體驗。
LLM(例如 OpenAI 的 GPT-3)徹底改變了我們對自動化的看法。憑借其理解和生成類似人類的文本的能力,它們為自動化傳統上手動且耗時的任務開辟了無數機會。讓我們深入研究 LLM 如何重新定義數據治理格局。
治理 3.0 代表了組織管理和治理數據方式的范式轉變。它不是要取代傳統的治理方法,而是要增強它們。治理 3.0 利用現有治理系統提供的大量 API 和 SDK 來擴展其基本功能。結合大型語言模型和人工智能的強大功能,這種方法使組織能夠自動執行任務、集成系統并提高效率。治理 3.0 的優點在于它能夠增強現有系統、確保法規遵從性、提高數據質量并促進高效的數據管理,而無需進行顛覆性改變。
向數據資產所有者推薦:人工智能視角
LLM 可以分析使用模式和訪問權限,以推薦最合適的數據資產所有者。此過程涉及分析誰經常訪問和修改數據資產、誰擁有必要的權限以及誰根據其角色或過去的項目擁有相關專業知識。
例如,如果某個用戶經常訪問和更新數據資產,并且他們在組織中的角色與數據的性質相符,LLM 可能會推薦他們作為數據資產所有者。然后,數據管理員或經理可以審查和批準此建議,確保最終決策由人參與。
這種由人工智能驅動的數據資產所有權分配方法可確保問責制并促進負責任的數據管理。它還有助于保持數據治理框架的最新狀態,因為隨著角色的變化或新數據資產的創建,可以重新評估和更新數據資產所有權。這不僅可以提高數據治理流程的效率,還可以確保數據資產由最合適的個人管理,從而提高數據質量和信任度。
保護數據:自動審查訪問和策略
LLM 可以解釋安全策略,使其能夠自動審查和標記潛在的訪問違規行為。這涉及分析用戶角色、訪問模式和數據資產的敏感度,以確定訪問權限是否符合既定的安全策略。
例如,如果用戶的角色通常不需要訪問敏感數據資產,但用戶經常訪問它,LLM 可能會將此標記為潛在違規行為。同樣,LLM 可以根據觀察到的訪問模式和不斷變化的業務需求建議修改安全策略。
這種主動方法不僅可以增強數據安全性和合規性,還有助于維護最小權限原則,確保用戶只能訪問他們需要的數據。通過自動審查訪問權限和策略,我們可以在不斷變化的數據格局和監管要求下維護強大而安全的數據治理框架。
語境感知翻譯:利用人工智能跨越語言障礙
在數據治理領域,語言障礙可能帶來重大挑戰,尤其是對于在不同地區運營的全球組織而言。這時大語言模型 (LLM) 的強大功能便得以發揮,它能夠實現超越逐字逐句翻譯的上下文感知翻譯。通過理解文本的上下文,大語言模型 (LLM) 可以提供更準確、更有意義的翻譯,確保保留原文的本質和細微差別。例如,大語言模型 (LLM) 可以將復雜的技術定義翻譯成多種語言,同時保持技術術語和概念的完整性并考慮任何必要的元數據。這種能力可以顯著增強組織內的跨文化協作和理解,使數據治理更具包容性和有效性。
通過自動定義豐富詞匯表術語
基于我們之前的工作,我們可以擴展 LLM 的使用范圍,為大量詞匯表術語生成定義和其他類型的元數據。利用 OpenAI API 自動填充術語定義,不僅減少了數據管理員所需的手動工作量,而且還確保了整個組織的一致理解。
自動實體鏈接:連接術語和數據資產
大型語言模型在數據治理中最強大的應用之一是自動實體鏈接。此過程涉及識別詞匯表術語和數據資產之間的相關聯系,從而創建更全面、更互聯的數據治理框架。
通過自動實體鏈接,LLM 可以分析數據資產的上下文和內容,并將其鏈接到適當的詞匯表術語。這不僅可以增強數據資產的元數據,還可以通過現實世界的示例和應用豐富詞匯表術語。
例如,包含客戶交易信息的數據資產可以自動鏈接到“客戶 ID”、“交易金額”或“購買日期”等詞匯表術語。這為詞匯表術語的理論定義與其在數據資產中的實際實施提供了直接聯系。
這種自動化程度大大減少了維護和更新這些鏈接所需的人工工作量,確保數據治理框架在創建新數據資產和更新現有數據資產時保持最新和相關性。此外,它還為用戶提供了對其數據格局的更全面了解,促進更有效、更明智的數據使用和決策。
追溯血統:從代碼到見解
LLM 可以理解代碼,這項技能可以用來識別自定義應用程序的血統。這可以簡化跨管道和記錄來跟蹤數據轉換的復雜任務。
例如,考慮一個 SQL 存儲過程,它從多個表中提取數據,執行轉換,然后將結果加載到另一個表中。傳統上,了解此過程的沿襲需要手動檢查代碼并深入了解數據庫架構。
CREATE PROCEDURE update_customer_orders
AS
BEGIN
-- 從 Customers 和 Orders 表中提取數據
SELECT Customers.CustomerName, Orders.OrderID
INTO #TempTable
FROM Customers
JOIN Orders ON Customers.CustomerID = Orders.CustomerID;
-- 對數據執行轉換
UPDATE #TempTable
SET CustomerName = UPPER (CustomerName);
-- 將結果加載到 CustomerOrders 表中
INSERT INTO CustomerOrders(CustomerName, OrderID)
SELECT CustomerName, OrderID FROM #TempTable;
DROP TABLE #TempTable;
END ;以下是 Azure OpenAI 如何提取血緣信息并以 JSON 格式呈現的示例:
{
“Stored_Procedure” :“update_customer_orders” ,
“Data_Sources” :[
{
“表” :“客戶” ,
“字段” :[ “客戶名稱” , “客戶ID” ]
} ,
{
“表” :“訂單” ,
“字段” :[ “訂單ID” , “客戶ID” ]
}
] ,
“轉換” :[
{
“操作” :“UPPER” ,
“字段” :“客戶名稱” ,
“Source_Table” :“#TempTable”
}
] ,
“Data_Destination” :{
“表” :“客戶訂單” ,
“字段” :[ “客戶名稱” , “訂單ID” ]
}
}借助 LLM,我們可以自動化此過程。該模型可以讀取和理解任何類型的代碼,識別正在訪問哪些表、正在應用哪些轉換以及結果存儲在何處。然后,它可以生成數據沿襲的人類可讀描述,甚至可以生成顯示數據流的可視化圖表。
自動沿襲跟蹤,特別是在許多基于代碼的操作等無法直接提取沿襲的場景中,可以改變數據治理的游戲規則。雖然目前的工具擅長跟蹤結構化、基于模式的數據源中的沿襲,但它們通常難以處理基于代碼的操作,如存儲過程、腳本或自定義應用程序。利用 LLM 的強大功能可以彌補這一差距,減少手動工作量并確保隨著代碼的演變而準確跟蹤沿襲。這種全面的數據沿襲方法涵蓋基于模式和基于代碼的數據操作,是數據治理 3.0 的一個關鍵方面,可提供完整而準確的數據整體視圖。
整理數據資產:人工智能驅動的方法
LLM 可以分析和生成數據資產的描述性元數據,從而改變我們管理數據的方式。這涉及了解數據資產的內容、背景和用途,然后生成相關元數據,例如定義、摘要、關鍵字或標簽。
例如,大語言模型 (LLM) 可以分析客戶交易數據集,識別交易日期范圍、最常見的交易類型和平均交易金額等關鍵特征,然后為數據集生成摘要描述和相關標簽。
這種自動化的管理流程不僅減少了數據管理所需的人工工作量,還提高了數據資產的可發現性。通過生成豐富、準確且最新的元數據,LLM 使用戶更容易搜索和發現相關數據,從而提高數據可訪問性并促進數據驅動的決策。
對齊本體:人工智能橋梁
LLM 可以協調組織內的不同本體或分類法,這項任務在醫療保健、制造業、金融等領域至關重要,因為這些領域經常使用多個復雜的本體。
在醫療保健領域,組織可能會在不同的系統中同時使用醫學系統命名法 - 臨床術語 (SNOMED CT) 和邏輯觀察標識符名稱和代碼 (LOINC)。LLM 可以識別這些本體中的術語之間的等價性,例如 LOINC 代碼“2160-0”和 SNOMED CT 代碼“27113001”,均指“血清肌酐”。
在制造業中,本體可能包含針對零件和工藝的不同分類系統。例如,一個系統可能將某個零件分類為“螺栓,六角,M8,鋼制”,而另一個系統將同一零件稱為“鋼制六角螺栓,8 毫米”。大語言模型可以理解這些術語指的是同一零件,并將它們排列在統一的本體中。
在金融領域,不同的系統可能會對相同的金融概念使用不同的術語,例如“凈收入”、“凈收益”。LLM 可以將這些術語視為等同術語,并在統一的本體中對其進行對齊。
這種無縫集成提供了數據環境的一致視圖,增強了數據互操作性。它確保所有系統中都一致地引用相同的概念,從而減少混亂并提高數據分析和報告的準確性。通過自動化本體對齊過程,LLM 可以幫助各個部門的組織更有效地管理其數據,從而做出更明智的決策并改善結果。
超越關鍵詞:語義搜索時代
LLM 可以在數據治理工具中啟用語義搜索功能。這使用戶能夠根據查詢的含義和上下文找到相關的數據資產,從而超越基于關鍵字的搜索的限制。
為了讓這些概念變得生動,讓我們深入研究一個非常簡單的例子,了解如何通過 Atlas API 將任何問題轉換為搜索查詢,并根據 API 響應生成答案。
LLM 可在數據治理工具中啟用語義搜索功能,開啟數據發現的新時代。與傳統的基于關鍵字的搜索(僅查找搜索詞的精確匹配)不同,語義搜索可以理解查詢的含義和上下文。這樣,即使用戶不知道這些資產中使用的確切術語,他們也可以找到相關的數據資產。
假設有用戶查詢“我們的銷售數據庫中與‘CustomerID’列關聯的業務術語表定義是什么?”在傳統的基于關鍵字的搜索中,系統可能很難返回有意義的結果。但是,由 LLM 提供支持的語義搜索可以理解用戶正在尋找與特定數據資產關聯的業務術語表術語。然后,它可以查詢銷售數據庫中的‘CustomerID’列的數據治理工具,找到關聯的業務術語表術語,并返回其定義。
為了將這些概念付諸實踐,讓我們深入研究一個非常簡單的示例,說明如何通過 Atlas API 將任何問題轉換為搜索查詢,并根據 API 響應生成答案。這種方法利用 LLM 的強大功能來理解用戶的意圖,將該意圖轉化為 API 可以理解的查詢,然后解釋 API 響應以生成用戶友好的答案。
導入streamlit作為st
導入pandas作為pd
導入openai
導入請求
導入json
從azure.purview.catalog導入PurviewCatalogClient
從azure.purview.administration.account導入PurviewAccountClient
從azure.identity導入ClientSecretCredential
從azure.core.exceptions導入HttpResponseError
導入os
openai.api_key = os.environ.get( 'OPENAI_API_KEY' )
openai.api_base = os.environ.get( 'OPENAI_API_ENDPOINT' ) # 您的端點應如下所示 https://YOUR_RESOURCE_NAME.openai.azure.com/
openai.api_type = 'azure'
openai.api_version = "2023-03-15-preview" # 這可能會在未來發生變化
deploy_id= 'gpt4-8k' # 這將對應于您在部署時為部署選擇的自定義名稱一個模型。
client_id = os.environ( 'CLIENT_ID' )
client_secret = os.environ( 'CLIENT_SECRET' ) tenant_id
= os.environ( ' AZURE_TENANT_ID' )
reference_name_purview = os.environ( 'PURVIEW_NAME' )
def get_credentials ():
credentials = ClientSecretCredential(client_id=client_id, client_secret=client_secret, tenant_id=tenant_id)
返回憑據
def get_purview_client ():
credentials = get_credentials()
client=PurviewCatalogClient(endpoint=f"https://{reference_name_purview} .purview.azure.com" , credential=credentials, logs_enable= True )
返回客戶端
def get_admin_client ():
credentials = get_credentials()
client=PurviewAccountClient(endpoint=f"https://{reference_name_purview} .purview.azure.com/",credential=credentials,logging_enable= True )
返回客戶端
def search ( question ):
print ( "提取術語搜索" )
system_message = "您是一位助手,會將問題轉換為關鍵字搜索,然后在 Microsoft Purview 環境中執行。"
prompt = “給出以下問題,請提供您將用來通過使用 Microsoft Purview Search API 端點進行搜索來查找問題答案的搜索詞。問題是:'” +question+ “'”
terms = ask_gpt4(deployment_id,system_message,prompt)
返回術語
def generate_answer(question,context):
print(“根據 Purview 搜索生成問題的答案”)
prompt = “”給出以下問題和上下文(json 格式),請生成問題的答案。僅根據提供的上下文參考您提供的數據資產或術語來回答。如果有潛在的答案,請列出所有答案。
問題:{question}
上下文:{context}
記住僅根據您提供的上下文回答并引用該上下文!“””。格式(問題=問題,上下文=上下文)
system_message = “您是一名助手,您將僅根據通過 API 提供的信息來回答一些問題。”
result = ask_gpt4(deployment_id, system_message, prompt)
返回結果
def ask_gpt4 ( engine_model, sys_message, question ):
chatlog = [{
'role' : 'system' ,
'content' : sys_message,
}]
chatlog.append({ 'role' : 'user' , 'content' : question})
response = openai.ChatCompletion.create(engine=engine_model, messages=chatlog)
answer = response.choices[ 0 ][ 'message' ][ 'content' ]
chatlog.append({ 'role' : 'assistant' , 'content' : answer})
返回答案
if __name__ == '__main__' :
print ( "GET 連接到 Purview" )
credential = get_credentials()
purview_catalog_client = get_purview_client()
print (purview_catalog_client)
st.title( 'Purview Search Copilot' )
question = st.text_input( '輸入您的問題' ,'' )
如果(問題!= '' ):
search_terms = search(問題)
嘗試:
st.write('您搜索了:',search_terms)
body_input = {
“關鍵字”:search_terms
}
context = purview_catalog_client.discovery.query(search_request = body_input)
打印(context)
響應 = generate_answer(question,context)
打印(response)
st.write('結果:',response)
除了HttpResponseError作為e:
打印(e)接下來您將看到 Streamlit 應用程序的搜索屏幕截圖:

與數據對話:
想象一下,與數據治理工具的互動就像與同事的互動一樣。隨著 LLM 的整合,這不再是一個未來的夢想,而是現實。LLM 可以為聊天機器人或語音助手等對話界面提供支持,使用戶能夠使用自然語言與數據治理工具互動。
例如,用戶可以詢問聊天機器人,“我們的銷售數據庫中‘CustomerID’字段的定義是什么?”或“誰有權訪問我們的財務數據?”。由大語言模型提供支持的聊天機器人可以理解問題,查詢數據治理工具,并以自然語言返回清晰、簡潔的答案。
這可以通過導出實例的備份并將該數據索引到認知搜索中并利用其中一個存儲庫來輕松實現。
這種轉換可以通過一個簡單的過程實現,該過程利用工具套件的功能。首先,您將導出實例的備份。此備份將包含收集和組織的所有有價值的元數據和數據目錄信息。
接下來,您將這些數據索引到認知搜索中,這是一項功能強大的 AI 搜索服務,可讓您以多種方式搜索這些復雜的結構化和非結構化數據。認知搜索可以處理自然語言查詢,使其成為與大型語言模型集成的理想平臺。
最后,為了簡化此過程并確保最佳實踐,您可以利用存儲庫之一。這些加速器是預先構建的解決方案,旨在幫助您快速啟動和實施項目。它們提供代碼示例、腳本和其他資源,可以顯著加快開發和部署速度。
通過遵循這些步驟,您可以創建一個強大的、由人工智能驅動的數據治理工具,該工具可以理解和響應自然語言查詢,從而使所有用戶(無論其技術專長如何)都可以更輕松地訪問和使用數據治理。

這種對話式方法使數據治理更加民主化,使其更易于訪問和用戶友好。它允許用戶以更直觀和自然的方式與數據治理工具交互,從而縮短學習曲線,并使非技術用戶更容易找到所需的信息。通過將自然語言處理的強大功能引入數據治理,我們可以使數據治理成為日常業務運營中更不可或缺的一部分。
結論
治理 3.0 由大型語言模型和創新數據目錄解決方案提供支持,可以改變組織管理和治理數據的方式。隨著我們的前進,我們可以期待數據治理繼續發展,利用 LLM 和其他先進技術來滿足組織不斷變化的數據治理需求。




























