淺談DeepSeek與Lakehouse的跨越式融合

作者 | 蘇郡城

各位好，我是果誠，一個在網際網路大廠摸爬滾打多年的資料從業者。最近 DeepSeek 這股風颳得太猛了，本週末的大事莫過於騰訊於 2025 年 2 月 15 日晚開始灰度測試在微信中接入 DeepSeek-R1 模型。作為一個月活將近 14 億的國民級 app，表達一個開放的意願就已經能夠讓股價火箭上天。而另一面，筆者的朋友圈也都很躁動，眾多企業朋友們都在熱情入局 DeepSeek。

今天想跟大家聊聊最近比較火的 DeepSeek 私有部署 + Lakehouse 方案。作為一名資料從業者，我想結合自己的經驗，跟大家聊聊我的看法。

1 為什麼是 DeepSeek：開放共享與技術演進的雙重印證

說到大語言模型，不得不提 OpenAI。作為行業的開創者，OpenAI 用 ChatGPT 展示了大語言模型的驚人潛力。但有趣的是，在技術發展道路上，OpenAI 選擇了一條相對封閉的路線。

DeepSeek 選擇了一個與眾不同的姿態——開放共享。當筆者深入研讀 DeepSeek 的技術文件時，不禁為其披露技術細節的誠意所打動。相比之下，回想前幾年研究 OpenAI 釋出的論文時，核心技術細節往往語焉不詳。

對技術感興趣的朋友，筆者推薦這個材料：逐篇解讀 DeepSeek 關鍵 9 篇論文的播客，相信能幫助我們更好地理解大模型的技術發展路徑。（連結放在文章底部）

技術的真正意義，不在於被少數人掌握，而在於能為更多場景創造可能。

回想 2016 年，圖靈獎得主 Yann LeCun 在 NeurIPS 會議上提出了著名的"蛋糕比喻"，將大型語言模型的發展比作一個三層蛋糕：自監督學習是基礎，指令監督微調是提升，而強化學習則是最佳化。這個洞見在今天看來依然深刻。DeepSeek 在強化學習方面取得了顯著進展，並因此獲得了效能提升，這可以被視為對 LeCun 路徑的一種印證。(當然，DeepSeek 的成功是多種因素共同作用的結果，LeCun 的路徑也並非 LLM 發展的唯一道路，但它提供了一個有價值的參考框架。)

而說到知識記憶能力這個關鍵維度，Yann 的另一個洞見是，在通往 AGI 的道路上，語言表達能力、知識記憶能力和邏輯推理能力是三個關鍵維度。

語言表達能力 – 例如 ChatGPT 3.5
邏輯推理能力 – 例如 DeepSeek R1
知識記憶能力 – RAG這正是我們接下來要探討的 RAG（檢索增強生成）技術……

2 為什麼企業應建立 RAG 知識庫：讓 LLM 擁有“外掛大腦”

在企業級 AI 應用中，如何讓 LLM 更好地理解和利用企業內部知識，是一個關鍵問題。這時，RAG（Retrieval-Augmented Generation，檢索增強生成）知識庫就派上了用場。簡單來說，RAG 就像是給 LLM 配備了一個“外掛大腦”，讓它在生成答案之前，先從知識庫中檢索相關資訊，然後再結合自身知識進行生成。這種方式可以有效提高 LLM 的準確性和可靠性，減少“胡說八道”的情況。

RAG 知識庫的簡單架構示意：

RAG 知識庫特別適用於需要訪問最新資訊、重視透明度和可解釋性的應用場景。但同時，RAG 也存在一些侷限性，

RAG 知識庫的優勢與侷限性

點選圖片可檢視完整電子表格

目前，RAG 知識庫的構成主要還是以文件和一些半結構化資料為主。那麼問題來了，企業的結構化資料又該如何成為 RAG 的一部分，讓大模型也能“消費”這些資料呢？特別是那些經過企業數倉 ETL 加工處理過的“可信賴”的資料，如何才能更好地融入 RAG 流程，為 LLM 提供更全面、更準確的知識來源呢？這正是我們接下來要探討的重點。

3 新正規化：選用湖倉架構作為企業的資料基礎底座，讓廣泛的資料和 AI 結合起來

企業價值密度最高的資料通常是結構化資料！

DeepSeek+RAG+Lakehouse，或是釋放資料價值的新思路，前邊談過 DeepSeek 和 RAG，這裡我們重點看一下 Lakehouse（一體化湖倉）。很多企業的資料都散落在各個系統裡，格式五花八門，想用的時候找不到或很難做統一管理。這就像是蓋房子，建材零散混亂彼此隔絕，自然無法有效利用。

一體化湖倉架構的出現，就是為了解決這個資料基建的“資源對接管理”問題。資料湖倉可以把你的結構化資料（比如資料庫裡的表格）、半結構化資料（比如 JSON 檔案）和非結構化資料（比如文件、圖片、影片）統統整合起來，形成一個統一的資料平臺；它可以把離線任務、即時分析、流式資料處理有機結合在一起；新一代資料湖倉甚至可以把傳統的資料分析計算引擎和 AI 也作為資料處理引擎統一起來，對資料進行分析處理。

湖倉架構的演進過程，受篇幅所限筆者這裡不展開，只提一個關鍵點：在選擇湖倉架構的時候，建議考察架構的儲存是否是必須多套還是統一、元資料管理是多套還是統一。

最新一代的湖倉架構的主張是統一儲存和統一元資料管理，面向多種負載應用，包括傳統資料分析和機器學習，都用同一套資料。這樣才能保證資料質量和資料可被信賴，也能大幅減少資料孤島、資料不一致、資料煙囪等問題。

4 讓湖倉一體 Ready for RAG，建立具備“可信資料”的企業 RAG 知識庫

前面說了那麼多，可能有些同學還是覺得有點抽象。接下來，筆者就結合具體的方案，跟大家聊聊如何基於 Lakehouse 架構來構建一個具備“可信資料”的企業 RAG 知識庫。

這張圖展示了 Lakehouse+RAG 構建的知識庫架構，以及基於該知識庫的 AI 產品功能，例如對話式資料分析工具 DataGPT。

整個流程可以概括為以下幾個步驟：

資料入湖倉：來自多源、多型別的資料透過各種方式進入 Lakehouse 。在這個過程中，元資料會被統一管理，並且會按照數倉的許可權體系進行訪問控制，確保資料的安全性。同時，資料會透過 Lakehouse 的一體化引擎（Single Engine）以及 AI 引擎進行轉換和資訊提取。
資料處理與儲存：透過資料與 AI 處理引擎，從結構化、非結構化資料中提取關鍵資訊，並以以下三種形式儲存在 Lakehouse 系統中：

表（Table）：儲存結構化資料，方便進行查詢和分析。
向量（Vector）：將文字、影像等非結構化資料轉化為向量形式，用於語義搜尋和相似度計算。
倒排索引（Inverted Index）：用於快速查詢包含特定關鍵詞的文件。

RAG 就緒層：這也是整個架構的關鍵所在。在這一層，透過語義引擎進行自動化的資料特徵分析、知識圖譜構建、指標自動化提取等操作。簡單來說，就是為 RAG 做好資料準備，讓 LLM 能夠更好地理解和利用這些資料。關於向量和倒排索引的使用方法，可以參考相關文件（向量：https://www.yunqi.tech/documents/vector-search 、倒排索引：[https://www.yunqi.tech/documents/inverted-index]）。

在這個流程中，DeepSeek 等 AI 模型的能力被充分利用，助力資料平臺處理各種型別的資料，為 RAG 知識庫的構建奠定堅實的基礎。

筆者認為，這個架構的亮點在於它將資料處理和 AI 能力緊密結合，可以實現了“資料 Ready for AI”。透過 Lakehouse 的統一資料管理和 AI 引擎的智慧處理，企業可以構建一個高質量、可信賴的 RAG 知識庫，為 LLM 提供更全面、更準確的知識來源，從而提升 AI 應用的效果。

5 DeepSeek+RAG+Lakehouse 結合實現企業自有的 AI 函式、對話式分析、文件問答

透過與 DeepSeek 等 AI 模型深度整合，Lakehouse 還可以實現企業自有的 AI 函式

AI 函式：讓“大模型”批次處理資料

將 DeepSeek 作為函式整合到資料處理流程中，實現 AI 輔助的資料清洗、轉換、分析等功能。這就像是給資料處理流程裝上了一個可以批處理的“大模型”計算引擎。

舉個例子，企業可以批次使用 DeepSeek 對客戶評論進行情感分析，自動識別正面、負面和中性評論。然後，將情感分析結果新增到客戶資料中，為後續的客戶關係管理提供更精準的支援。

為了讓大家更直觀地瞭解 AI 函式的用法，下面筆者將展示如何使用 SQL AI 函式，呼叫 DeepSeek R1 來處理一道數學題。眾所周知，大模型有相對更強的語言能力，但數學能力偏弱，DeepSeek R1 作為推理模型，能夠有更好的數學能力提升，比如解決經典的 9.11 和 9.9 哪個數更大的問題：

將下面的程式，以及依賴包（Python 3.10）打包成 zip，並按照文件描述上傳至物件儲存如 OSS，再建立函式即可。具體步驟請參考（https://www.yunqi.tech/documents/RemoteFunctionDevGuidePython3）

實現功能的程式程式碼為（呼叫阿里雲百鍊平臺的 DeepSeek r1 滿血版）

Pythonimport sysfrom openai import OpenAIfrom cz.udf import annotate# 百鍊透過 OpenAI SDK 或 OpenAI 相容的HTTP方式快速體驗DeepSeek模型。client = OpenAI( api_key='xxxxx', # 請替換為有效的 API Key base_url="https://dashscope.aliyuncs.com/compatible-mode/v1")@annotate("string,string->string")classfc_deepseek:defevaluate(self, service_type, input_text):if service_type != "math_problem":return"Invalid Service Type"try: completion = client.chat.completions.create( model="deepseek-r1", messages=[{'role': 'user', 'content': input_text}] )return completion.choices[0].message.content if completion.choices else"無法獲取答案"except Exception as e:returnf"計算錯誤: {e}"

如企業想使用私有化部署模型，可以採用模型託管和推理服務如 Ollama，它可以讓你在私有化環境執行 DeepSeek，並允許透過 API 方式呼叫它們，它提供了一個相容 OpenAI API 格式的 HTTP 伺服器，比如 http://IP:11434/v1/chat/completions。我們只需要修改 evaluate 方法。

當然，在 SQL 環境用大模型處理數學問題，屬實是在以計算擅長的傳統資料引擎面前班門弄斧了。在實踐中，我們更希望透過大模型的能力，補充解決傳統資料引擎不擅長的問題。

另外，AI 函式的強大之處在於其靈活性和可擴充套件性。它不僅可以呼叫 DeepSeek 等大模型，還可以根據不同的場景需求，呼叫其他各種型別的模型。例如，下面的函式就是呼叫視覺模型進行車型識別：

這意味著，企業可以根據自身的業務需求，靈活地選擇合適的 AI 模型，構建各種各樣的 AI 函式，從而實現更加智慧化、個性化的資料處理流程。

資料對話式分析：讓資料分析像聊天一樣簡單

筆者長期關注資料分析領域，我看到對話式分析已經成為了企業數字化轉型的一個重要方向。隨著知識庫 + 推理模型的發展，這個方向又迎來了新的可能性。

採用推理模型 + Multi-Agent 架構的 ChatBI 系統，有比較好的語義理解和執行能力

比如想了解"2020 年，北京哪個區的房價同比增長最大？"這樣的問題，系統能直接理解意圖並給出分析結果。

DeepSeek R1 作為推理模型，對 ChatBI 的推理能力也有進一步加強。

本圖呈現了 DeepSeek R1 基於 Multi-Agent 架構的創新性推理流程。在接收到使用者查詢後，系統首先透過意圖識別 Agent 精準解析問題本質，隨後由指標提取、時間範圍解析、維度拆解三大 Agent 並行協作，完成結構化資料的深度挖掘。為保障決策精準度，過濾條件識別 Agent 會動態構建資料約束，能保障自然語言的靈活度。最後透過總結歸納 Agent 生成層次分明的結構化回答。

這種推理模型 + Multi-Agent 架構不僅實現了複雜問題的全鏈路智慧解析，更透過各 Agent 的靈活組合顯著提升了系統在商業分析、資料決策等場景下的自適應能力，較傳統單執行緒處理模式效率有大幅提升。

文件問答：DeepSeek 大模型的基礎操作

文件問答是大模型非常成熟的應用場景，透過 RAG 可以將企業自有資料餵給大模型，並結合湖倉內的資料做文件和企業自有資訊的問答，下面是簡單的展示

總結 DeepSeek+RAG+Lakehouse 這套方案的價值

從最初企業受限於資料合規、定製化和成本等問題，對大模型只能遠遠觀望，到如今企業可以基於 DeepSeek 大模型入局，打造屬於自己的“AI 大腦”和 AI 應用。RAG 為“AI ”提供了個性化資訊支撐，讓企業能夠充分利用自身的數字資產。

而 DeepSeek 等私有部署 LLM + Lakehouse 架構的結合，未來或是一種全新的企業級 AI 正規化。它不僅解決了合規的問題，還統一了資料要素管理，降低了 AI 應用的門檻；更重要的是，它真正實現了“資料 Ready for AI”，讓資料不再是沉睡的資源，而是能夠驅動業務增長的強大引擎。

在可以預見的未來，AI 大模型等能力必將愈加普惠，成本將持續降低，使用什麼大模型未來將不再是門檻，而擁有關鍵入口的資料場景，和資料資源將是企業的核心價值。

（附錄）

詳解 DeepSeek 大模型關鍵的 9 篇論文的播客，這是目前筆者看到的最好材料之一，由商業訪談錄節目製作，強烈推薦歡迎收聽收藏