自 ChatGPT 發布以來，大語言模型 (LLM) 已進入主流，促使各行各業和公司紛紛探索其在業務轉型中的潛力。此后，許多技術應運而生，幫助團隊構建更強大的 AI 系統：RAG、向量數據庫、重排序器、推理模型、工具使用、MCP、代理框架等等。這些工具和技術顯然很有用；然而，提升 AI 系統業務影響力的最有效方法依然是數據。

人工智能系統需要訪問公司數據

在企業中，AI需要輸入數據才能發揮作用。這催生了RAG（檢索增強生成）架構。根據不同用例，輸入數據可以是任何內容；可以是合同、采購訂單、工程文檔、制造流程等等。

現在假設我們想要實現一個在航空公司提供客戶服務的人工智能聊天機器人，這是一個典型的用例。讓我們從這個用例的基本 RAG 架構開始，并將其分解為主要步驟：

通過收集執行客戶服務所需的文件（如公司退款政策、航班重新安排指南以及規則或客戶忠誠度計劃）來構建知識庫。

• 索引和分塊文檔，生成嵌入并將其存儲在向量數據庫中
• 根據與用戶查詢的相似性，在推理時檢索前 k 個文檔塊
• 使用這些文檔塊來增強提示并生成顯示給用戶的響應

你需要管理這些數據，以確保高質量的人工智能輸出和數據保護

我們上面解釋的 RAG 流水線非常簡單。你可以添加許多花哨的功能來讓它更加精美，這從 AI 工程的角度來看非常誘人。然而，從業務角度來看，在數據層工作更為合理和有效。以數據為先的方法構建企業級 AI，將打造一個對最終用戶和整個企業都有用的系統。知識存儲可能是許多 AI 響應質量低下的根本原因，如下圖所示。

從該圖中我們可以看到，知識庫中提供的文檔可能存在幾個問題，即：

所提供的文檔可能與用例/任務無關，對用戶查詢毫無價值，只會提供噪音。這種情況可能發生在文檔批量提供且未經用例和數據部門業務團隊細粒度審查的情況下。

相反，可能會缺少解決當前任務所需的文檔，但這些文檔并未包含在知識庫中。這種情況通常發生在構建知識庫的業務團隊對公司或特定業務領域內可用/使用的文檔缺乏詳盡的了解時。

文檔可能已經過時，這種情況經常發生在特定文檔有版本控制，并且舊版本沒有系統地從知識庫中刪除時。

由于版本控制或公司政策和規則不一致，文檔可能會發生沖突。

文檔可能包含敏感信息，這是迄今為止最糟糕的故障模式，因為它涉及數據保護問題。如果相同的知識存儲用于不同的領域和用戶角色，且缺乏適當的索引和權限管理，則可能會發生這種情況（例如，財務文檔和制造文檔存儲在同一個知識存儲中）。

數據治理角色正在不斷發展壯大，以支持人工智能系統治理和非結構化數據治理

下面的例子說明了建立強有力的治理的重要性。

數據治理將確保企業內部開發的人工智能系統實用且真實，并確保公司數據得到保護。傳統上，數據治理主要關注結構化數據、表格和數據庫，而較少關注 PDF 文件、PPT 演示文稿和圖像等非結構化數據。但 GenAI 的出現正在改變和擴展這一角色，使其涵蓋非結構化數據和大規模人工智能系統治理。通過與用例的業務負責人、人工智能技術和數據團隊協同工作，數據治理可以對構建安全、準確且可擴展的人工智能系統產生重大影響，從而真正實現業務運營的轉型。

我們使用關系數據庫已經很久了。您可能是關系數據庫設計和建模方面的專家。我見過大多數設計師/開發人員在建模No SQL數據庫時都使用關系型方法。甚至在為NoSQL數據庫建模時，對我來說，改變關系型思維模式也有點困難。

是的，如果你用關系型數據庫建模，那沒什么壞處。但如果這樣做，那就錯了。據你所知，NoSQL 數據庫有多種類型，每種類型都有各自的用途。在設計特定類型的數據庫時，務必仔細考慮。