隨著人工智能技術(shù)在業(yè)務(wù)中的滲透，我們逐漸意識到：AI 不僅是提升效率的工具，更是重構(gòu)數(shù)據(jù)處理與消費(fèi)方式的核心驅(qū)動(dòng)力。在這一背景下，我們思考：能否構(gòu)建一款「AI + Data」一站式融合的數(shù)據(jù)引擎？它不僅能夠統(tǒng)一處理文本、音視頻等非結(jié)構(gòu)化數(shù)據(jù)與傳統(tǒng)結(jié)構(gòu)化數(shù)據(jù)，還能為算法工程師提供流暢的數(shù)據(jù)開發(fā)體驗(yàn)，實(shí)現(xiàn)數(shù)據(jù)處理與 AI 模型無縫銜接，并能確保數(shù)據(jù)處理負(fù)載與在線服務(wù)負(fù)載完全隔離。這是 2024 年末字節(jié)跳動(dòng)啟動(dòng) DataMind 項(xiàng)目的初衷。

本文整理自

在 Doris Summit 2025 中的演講內(nèi)容，并以演講者第一視角進(jìn)行敘述。

號外：Doris Summit 2025 全部回放及 PPT 資料現(xiàn)已就緒，可前往大會(huì)官網(wǎng)進(jìn)行資料下載 / 回放觀看：doris-summit.org.cn

1 DataMind：Doris + AI 一站式融合數(shù)據(jù)引擎

在項(xiàng)目啟動(dòng)前，我們評估了多種市面上的開源方案，但未能找到完全符合 AI + Data 引擎需求的產(chǎn)品。因此，我們決定選擇一款優(yōu)秀的 OLAP 數(shù)據(jù)庫，并在此基礎(chǔ)上融合和增強(qiáng) AI 功能。Apache Doris 憑借完善的功能、卓越的 OLAP 性能、豐富的生態(tài)體系、活躍的社區(qū)氛圍及良好的產(chǎn)品口碑吸引了我們的注意。

與此同時(shí)，我們了解到社區(qū)也在積極探索 Doris 與 AI 能力的結(jié)合，因此決定在 Apache Doris 基礎(chǔ)上二次開發(fā)，打造一站式引擎——DataMind。這些能力包括：

• Hybrid Search：將基于文本相似性、語義相似性、業(yè)務(wù)規(guī)則匹配這三種能力集成至 Doris 中，并在此基礎(chǔ)上補(bǔ)齊了向量檢索及 Tablet-level BM25 能力。(詳見章節(jié)二）。

• AI Function：基于 Doris 補(bǔ)齊了 AI_QUERY 和 TEXT_EMBEDDING ，并支持了 Python UDF。(詳見章節(jié)三）

• GraphRAG：在基于 Doris 的 DataMind 產(chǎn)品上構(gòu)建了 GraphRAG，應(yīng)用層研發(fā)團(tuán)隊(duì)能夠更便捷地接入新的 AI 能力，縮短研發(fā)周期。(詳見章節(jié)四）

目前，我們已將部分 AI 融合的實(shí)踐成果貢獻(xiàn)給開源社區(qū)，大家可從 Apache Doris 4.0 版本中關(guān)注。

這些能力不僅是 Datamind 的重要組成，也是構(gòu)建企業(yè)級 AI 問數(shù)平臺奠定了堅(jiān)實(shí)的技術(shù)基礎(chǔ)。后文將逐一展開其設(shè)計(jì)思路、實(shí)現(xiàn)路徑與優(yōu)化實(shí)踐。

2 Hybrid Search 能力集成

AI 場景下典型的混合搜索的架構(gòu)可以概括為三種搜索方式：基于文本相似性、語義相似性、業(yè)務(wù)規(guī)則的匹配。這三路的搜索結(jié)果會(huì)在后端統(tǒng)一排序，排序方法依賴自訓(xùn)練的模型，分為粗排和精排兩個(gè)階段。粗排模型可提高處理性能，精排模型實(shí)現(xiàn)更優(yōu)的重排序效果，平衡整體開銷。

我們希望將這三類搜索能力集成至基于 Doris 的 DataMind 引擎之中，讓用戶只需導(dǎo)入一份數(shù)據(jù)，并在完成必要的處理及索引構(gòu)建后，即可直接上線服務(wù)，無需介入其他三方工具。為實(shí)現(xiàn)這一目標(biāo)，團(tuán)隊(duì)基于 Doris 補(bǔ)充了向量索引和 BM25 打分函數(shù)這兩項(xiàng)核心能力。

2.1 向量索引

我們基于 Faiss （Facebook 開源的 AI 相似性搜索工具）實(shí)現(xiàn)了 HNSW 與 IVF_PQ 兩種 ANN 算法的向量索引。HNSW 在大規(guī)模數(shù)據(jù)集上性能表現(xiàn)更優(yōu)，但資源開銷較大； IVF_PQ 在大規(guī)模數(shù)據(jù)集上，成本與性能表現(xiàn)更加均衡。

向量索引支持與其他索引條件組合使用。比如，可將倒排索引的結(jié)果通過 Faiss 提供 IDSelector 接口傳遞到底層 ANN 算法實(shí)現(xiàn)上以控制搜索過程?；驹硎牵旱古潘饕紫葯z索匹配行號的 Bitmap，這一 Bitmap 被傳遞給 Faiss 庫。當(dāng)進(jìn)行向量搜索時(shí)，F(xiàn)aiss 會(huì)將搜索范圍限制，最終輸出 TopN 行號結(jié)果，代表融合后的結(jié)果集。當(dāng)?shù)古潘饕诘谝浑A段篩選出的數(shù)據(jù)量較少時(shí)，會(huì)跳過向量索引進(jìn)行暴力計(jì)算，這樣耗時(shí)更短、時(shí)間更精準(zhǔn)。

2.2 Tablet-level BM25

BM25 是一種用于信息檢索的排名函數(shù)，用于衡量查詢與文檔的相關(guān)性。它基于詞頻（t）和文檔長度進(jìn)行加權(quán)計(jì)算，同時(shí)考慮逆文檔頻率（IDF）以懲罰常見詞。在整個(gè)公式中，需重點(diǎn)關(guān)注總文檔數(shù) N 和文檔頻率 DF 等全局統(tǒng)計(jì)信息，這些信息直接影響實(shí)現(xiàn)的難度。（更多信息可自行搜索查閱）

在 Doris 的設(shè)計(jì)中，一個(gè) segment 對應(yīng)一個(gè)倒排索引的解決方案，因此在 segment 級別實(shí)施 BM25 較為簡單，系統(tǒng)可以基于每個(gè) segment 的統(tǒng)計(jì)信息（如總文檔數(shù) N 和文檔頻率 DF）計(jì)算每一行的得分。然而，合并小 segment 可能導(dǎo)致統(tǒng)計(jì)信息變化，從而影響 BM25 得分，造成用戶評分波動(dòng)，這在生產(chǎn)環(huán)境中不可接受。

為了避免此問題，團(tuán)隊(duì)將 BM25 公式提升至 tablet 級（tablet-level）。所有全局統(tǒng)計(jì)信息（包括 N 和 DF）需基于整個(gè) tablet 聚合，以保持得分結(jié)果的一致性。

以 Merge on Write / Merge on Write 為例：

• 在 Scan 算子初始化階段：系統(tǒng)會(huì)預(yù)先搜索用于 BM25 計(jì)算的 tablet 級統(tǒng)計(jì)信息。每個(gè) segment 會(huì)被依次掃描，并以流式方式輸出數(shù)據(jù)塊。

• 數(shù)據(jù)收集階段：在處理每個(gè) segment 之前，需計(jì)算完整的 tablet 級統(tǒng)計(jì)信息。Scan 算子初始化時(shí)，系統(tǒng)使用相應(yīng)搜索條件訪問每個(gè) segment 的解決方案。此過程中產(chǎn)生的文件操作、數(shù)據(jù)讀取和內(nèi)存命中等結(jié)果構(gòu)成搜索上下文信息。同時(shí)，與搜索相關(guān)的對象會(huì)被緩存，以避免重復(fù)產(chǎn)生 IO 開銷。

• 索引查找及數(shù)據(jù)讀取：當(dāng)正式進(jìn)入某個(gè)索引后，索引搜索將基于此前收集的 tablet 級統(tǒng)計(jì)信息，為命中的每一行計(jì)算分?jǐn)?shù)。最終，計(jì)算所得的分?jǐn)?shù)通過虛擬列的迭代器返回到 segment，隨數(shù)據(jù)塊輸出。

2.3 搜索框架優(yōu)化

在補(bǔ)充了向量索引和 BM25 能力后，我們面臨一個(gè)新問題：在混合搜索框架中，涉及的函數(shù)并非傳統(tǒng)意義上在計(jì)算層基于輸入直接進(jìn)行求值，而是必須在索引檢索的過程中計(jì)算出結(jié)果，因此需要設(shè)計(jì)一套特殊的投影下推流程，具體實(shí)現(xiàn)如下：

在執(zhí)行計(jì)劃層，我們將相關(guān)函數(shù)替換為虛擬列，并將這些虛擬列下推至 OlapScanNode。OlapScanNode 攜帶虛擬列的信息，將其傳遞到接近索引計(jì)算與查詢塊存儲(chǔ)邏輯的執(zhí)行路徑中。

在索引計(jì)算過程中，系統(tǒng)基于這些虛擬列計(jì)算向量距離分?jǐn)?shù)和 BM25 相似性分?jǐn)?shù)，并將結(jié)果填充回對應(yīng)的 block。最終，帶有虛擬列計(jì)算結(jié)果的 block 由 Scan 算子輸出，并傳遞至下游算子，以自然銜接的執(zhí)行計(jì)劃完成整個(gè)檢索流程。

3 AI Function 補(bǔ)齊

在 AI Function 上，主要基于 Doris 補(bǔ)齊了 AI_QUERY 和 TEXT_EMBEDDING 兩種函數(shù)。

3.1 AI_QUERY

該函數(shù)用于調(diào)用大模型并能較好地處理非結(jié)構(gòu)化文本這類數(shù)據(jù)，將其轉(zhuǎn)化為結(jié)構(gòu)化數(shù)據(jù)，再進(jìn)行傳統(tǒng)分析。例如，對于一張客戶評價(jià)表，可以讓大模型為每條評價(jià)打分并分類，如好評輸出 1、差評輸出 0，通過統(tǒng)計(jì)即可得出好評與差評的大致數(shù)量。

GROUP BY review_type

3.2 TEXT_EMBEDDING

該函數(shù)主要有兩個(gè)階段：

• 數(shù)據(jù)清洗階段：在 AI 清洗過程中生成對應(yīng)向量并構(gòu)建向量索引。

• 數(shù)據(jù)查詢階段：此階段提供兩種使用方式。第一種是由用戶的應(yīng)用層代碼自行生成查詢向量，并作為參數(shù)傳入 SQL 進(jìn)行搜索，該方式需傳入較長的向量 float 數(shù)組，會(huì)增加優(yōu)化器的解析開銷。第二種方式是直接調(diào)用 TEXT_EMBEDDING 函數(shù)，將查詢文本傳入并執(zhí)行搜索，這種方法更為便捷，且性能更佳。

LIMIT 7;

3.3 Python UDF 的實(shí)現(xiàn)

除上述標(biāo)準(zhǔn)函數(shù)外，我們基于 Doris 支持了 Python UDF，以滿足自部署模型的需求，包括 Rerank 模型、Embedding 模型、甚至大模型的訪問需求，以及依賴 Python 庫進(jìn)行非結(jié)構(gòu)化數(shù)據(jù)處理的需求場景。

Python UDF 的核心設(shè)計(jì)主要包含幾個(gè)關(guān)鍵點(diǎn)：

• 多進(jìn)程架構(gòu)：旨在解決 UDF 之間的隔離問題，避免 Python 的全局解釋器鎖（GIL）。每個(gè) Python UDF 能通過虛擬環(huán)境（venv）實(shí)現(xiàn)依賴隔離。

• 生命周期綁定：執(zhí)行 Python 的子進(jìn)程與 Doris 的 pipeline task 生命周期綁定。當(dāng)一個(gè) pipeline task 生成時(shí)，相應(yīng)的子進(jìn)程也會(huì)被創(chuàng)建，并在任務(wù)結(jié)束時(shí)進(jìn)行清理。這種設(shè)計(jì)使得并發(fā)模型與 Doris 的計(jì)算引擎密切結(jié)合，用戶只需調(diào)整 Doris 的并發(fā)參數(shù)即可管理 Python UDF 的執(zhí)行并發(fā)，簡化了維護(hù)工作。

• 數(shù)據(jù)傳輸和序列化：主進(jìn)程與子進(jìn)程之間的數(shù)據(jù)傳輸通過管道進(jìn)行。支持 Python 原生對象輸入輸出的版本采用 Python 的 Marshal 機(jī)制進(jìn)行序列化。

生命周期綁定示意圖

如下方代碼示例，示例中展示了混合搜索（向量 + 全文檢索）的應(yīng)用，兩個(gè)檢索通過用戶自研的 Python UDF 模型進(jìn)行重排序，最終使用 Hybrid Search 進(jìn)行數(shù)據(jù)攝取。在 AI Function 和 Python UDF 的加持下，用戶只需通過一條簡單的 SQL 語句即可串聯(lián)整個(gè)業(yè)務(wù)搜索流程及數(shù)據(jù)處理流程，使用十分便捷。

);

LIMIT 7;

4 GraphRAG on DataMind

4.1 GraphRAG

GraphRAG 是一種結(jié)合圖數(shù)據(jù)庫與 RAG（Retrieval-Augmented Generation）技術(shù)。推動(dòng) DataMind 集成 GraphRAG 功能的原因是，我們在推廣 AI 功能時(shí)發(fā)現(xiàn)多個(gè)業(yè)務(wù)團(tuán)隊(duì)對此有需求。與標(biāo)準(zhǔn) RAG 相比，GraphRAG 的實(shí)現(xiàn)過程更為復(fù)雜，需要在基礎(chǔ) AI 能力上進(jìn)一步構(gòu)建。

構(gòu)建階段：該階段的輸入為文檔或分割成的片段（chunk）。利用大模型（AI Function）進(jìn)行實(shí)體抽取——從文檔中提取出關(guān)鍵信息，實(shí)體之間的關(guān)系可以看作是圖中的邊，每條邊具有一定的權(quán)重，這些權(quán)重由大模型自動(dòng)識別，提取的實(shí)體及其描述經(jīng)過向量化后存儲(chǔ)，以構(gòu)建索引。

此外，圖結(jié)構(gòu)和邊的描述也會(huì)存儲(chǔ)在一張表中?；谠搱D，系統(tǒng)利用 Search 發(fā)現(xiàn)算法（如 Lighting）進(jìn)行聚類，將相似的實(shí)體歸類為一個(gè) Search，并生成 Search 報(bào)告。

查詢階段：在檢索過程中，首先將 Query 轉(zhuǎn)換為向量，該向量用于 Search 實(shí)體，以找到與之相關(guān)的 Top-K 實(shí)體。得到 TopK 實(shí)體后，系統(tǒng)將召回它們相關(guān)的邊，這些邊包含與實(shí)體相關(guān)的描述和信息，以及這些實(shí)體關(guān)聯(lián)的報(bào)告和原始文檔的片段。在有限的上下文內(nèi)，系統(tǒng)會(huì)按優(yōu)先級拼接相關(guān)內(nèi)容，形成最終上下文，隨后將其輸入 AI 以生成回答。

4.2 GraphRAG on DataMind

基于 Apache Doris 的 DataMind 產(chǎn)品上如何構(gòu)建 GraphRAG 呢？整體設(shè)計(jì)分為多層，如下圖所示：

最底層是表結(jié)構(gòu)的設(shè)計(jì)，包括實(shí)體表、Search 表以及用戶自定義的源數(shù)據(jù)表等。在此基礎(chǔ)上，通過一系列函數(shù)，包含用于文檔切分的函數(shù)、Leiden 聚合函數(shù)等等，最后結(jié)合 ETL SQL、Query SQL 等，共同實(shí)現(xiàn) GraphRAG 的構(gòu)建與查詢流程。

由于底層 SQL 相對復(fù)雜，團(tuán)隊(duì)在這些 SQL 上封裝了 Go、Python 與 Java 的 SDK，以方便用戶使用。用戶只需調(diào)用如 build 或 import 等接口即可完成數(shù)據(jù)導(dǎo)入與構(gòu)建，再通過 query 接口實(shí)現(xiàn)查詢能力。這樣一來，應(yīng)用層研發(fā)能夠更快速地接入新的 AI 能力。只需使用 Apache Doris 數(shù)據(jù)庫并結(jié)合團(tuán)隊(duì)提供的 SDK，即可直接將業(yè)務(wù)流程跑通并驗(yàn)證效果。

5 企業(yè)級 AI 問數(shù) Datamind 落地方案

企業(yè)級 AI 問數(shù)是當(dāng)前行業(yè)內(nèi)較為經(jīng)典且熱門的探索方向。行業(yè)內(nèi)普遍采用 NL2SQL 直接查詢 Apache Doris 等數(shù)據(jù)庫的模式。那么，字節(jié)是如何落地的呢？

5.1 企業(yè) AI 問數(shù)理想架構(gòu)

首先，我們基于 Doris 構(gòu)建了湖倉一體的數(shù)據(jù)架構(gòu)，以數(shù)據(jù)湖為中心，外部業(yè)務(wù)系統(tǒng)或企業(yè)內(nèi)部信息系統(tǒng)（如 RDS、API 取數(shù)），數(shù)據(jù)經(jīng)過 DTS 等工具攝入，最終沉淀在云存儲(chǔ)中，呈現(xiàn)為傳統(tǒng) Hive 的原生 Parquet 格式。隨后，數(shù)據(jù)通過 Spark 或 Flink 進(jìn)行 ETL 清洗，遵循標(biāo)準(zhǔn)的 Lambda 架構(gòu)，最終生成可供消費(fèi)的數(shù)據(jù)，并存儲(chǔ)至 OLAP 引擎 Apache Doris 以實(shí)現(xiàn)查詢加速。

若要利用 AI 進(jìn)行數(shù)據(jù)消費(fèi)，以實(shí)現(xiàn)類似企業(yè)智能體的功能，它需要訪問所有企業(yè)信息系統(tǒng)的數(shù)據(jù)。因此，我們期望的理想架構(gòu)處理流程應(yīng)如下圖：

具體流程：AI 問數(shù)應(yīng)用通過 Data Agent 調(diào)用 NL2SQL 這類外部工具，Data Agent 采用 Plan Execute 或 React 模型規(guī)劃執(zhí)行路徑，需要元數(shù)據(jù)以及依據(jù)業(yè)務(wù)自定義的語義模型——簡單理解為表字段的描述，基于這些信息，Data Agent 生成取數(shù) SQL，并發(fā)給 Apache Doris（即 DataMind） 加速執(zhí)行，最終將數(shù)據(jù)返回到 AI 問數(shù)應(yīng)用層。在這其中，Apache Doris 主要作用是將湖上的數(shù)據(jù)同步到其內(nèi)部進(jìn)行查詢加速。

而這種理想處理方式面臨數(shù)據(jù)安全性及查詢延遲等問題，比如：

• 數(shù)據(jù)湖中的數(shù)據(jù)量龐大，全部同步到 Apache Doris 并不現(xiàn)實(shí)，且敏感數(shù)據(jù)也不宜全量同步。

• 當(dāng)數(shù)據(jù)加速到 DataMind 后，Apache Doris 的內(nèi)表與外表存在差異。加速會(huì)影響 SQL 的 Catalog 語法，例如加速后，外表的 Catalog 名稱為 Hive，內(nèi)表則為 Internal。這對 AI 生成 SQL 產(chǎn)生一定影響，迫使 AI 必須感知是否存在加速。

5.2 企業(yè) AI 問數(shù)最終架構(gòu)

為解決上述問題，我們進(jìn)行了如下優(yōu)化，具體改進(jìn)為：

• 改進(jìn) Data Agent 查詢的路由機(jī)制：用戶只需書寫庫表名，系統(tǒng)將在優(yōu)化器階段自動(dòng)判斷路由、補(bǔ)全表名。用戶對于 Data Agent 的使用，只需理解數(shù)據(jù)湖中的 Schema，無需關(guān)注表是存儲(chǔ)在數(shù)據(jù)湖還是已加速至 Apache Doris。

• 數(shù)據(jù)湖權(quán)限系統(tǒng)的打通：我們的數(shù)據(jù)湖擁有獨(dú)立的權(quán)限管理系統(tǒng)，控制讀寫訪問。將數(shù)據(jù)加速至 Apache Doris 相當(dāng)于復(fù)制一份數(shù)據(jù)，可能導(dǎo)致安全管控失效。為解決這一問題，我們設(shè)計(jì)了機(jī)制：即使數(shù)據(jù)同步至 Apache Doris，其權(quán)限仍受 Triton 數(shù)據(jù)湖權(quán)限系統(tǒng)管控，且與 Apache Doris 的賬號密碼無關(guān)。這一設(shè)計(jì)確保應(yīng)用層在數(shù)據(jù)湖上申請的權(quán)限依然有效，加速后無需額外權(quán)限申請。此外，這一機(jī)制保證了即使數(shù)據(jù)同步到 Apache Doris，持有其賬號密碼的人員（如 DBA），未經(jīng)原數(shù)據(jù)湖系統(tǒng)申請的權(quán)限仍無法訪問。

6 結(jié)束語

Doris + AI 一站式融合數(shù)據(jù)引擎 DataMind 的實(shí)現(xiàn)，已在字節(jié)內(nèi)部應(yīng)用一段時(shí)間，并在持續(xù)推廣之中，典型應(yīng)用場景包括智能簡歷搜索、ByteRAG 平臺、CapCut 內(nèi)容治理等。且在 GraphRAG 上線后，團(tuán)隊(duì)與多方客戶合作實(shí)現(xiàn)了場景落地，例如廣告場景、代碼搜索的場景，以及近期業(yè)界關(guān)注的 PRD2Code 等研發(fā)提效場景 。

混合搜索 + AI 函數(shù)

混合搜索 + AI 函數(shù) + GraphRAG

未來，我們還會(huì)在 DATA + AI 上繼續(xù)探索，搭建更加完善的企業(yè) AI 問數(shù)架構(gòu)。此外，我們將保持與 Doris 開源社區(qū)的緊密聯(lián)系保持聯(lián)系，積極參與共建并為社區(qū)提供反饋。