07_Doris AI 能力企业级实践：字节跳动 DataMind 案例深度剖析

07_Doris AI 能力企业级实践：字节跳动 DataMind 案例深度剖析

关键字：Apache Doris、字节跳动DataMind、企业级AI、Hybrid Search实战、IVF_PQ、Faiss IDSelector、Python UDF、GraphRAG、BM25全局统计、大规模向量检索

标签：Apache Doris字节跳动DataMind企业级AI向量检索实战混合搜索GraphRAG

前言

技术选型的第一个问题往往是：这个技术在大规模生产环境里真正跑过吗？

对于 Doris 的 AI 能力来说，字节跳动 DataMind 就是这个问题的回答。DataMind 是字节跳动内部的一站式 AI 知识检索引擎，目前服务于抖音、今日头条、飞书等多条业务线。

更重要的是，DataMind 团队将他们在字节内部验证过的核心能力——包括基于 Faiss 的 HNSW/IVF_PQ 双算法支持、Tablet-level BM25 全局统计、Bitmap 与 IDSelector 集成等——贡献给了 Doris 开源社区，成为了 Doris 4.0 AI 能力的重要技术基础。

本文深度剖析 DataMind 的技术架构和关键实现细节，这些内容对于理解 Doris 4.0 为什么这样设计有直接帮助。

一、DataMind 的选型背景

1.1 字节的痛点

2023 年底，字节跳动的知识管理需求快速膨胀：飞书的 Wiki、Lark Docs、内部知识库系统累积了海量非结构化数据，需要支持语义检索。原有的技术栈是 Elasticsearch（全文检索）+ 自研向量服务（ANN 检索），双系统维护成本高，更严重的问题是两路检索结果在应用层融合时数据一致性难以保证。

团队调研了当时主流的方案：

DataMind 选型评估矩阵 Milvus Weaviate Qdrant pgvector Doris ────────────────────────────────────────────────────────────── 向量检索性能 ◎ ◎ ◎ ○ ◎ 全文检索能力 ✗ ○ ✗ ✗ ◎ 结构化分析能力 ✗ ✗ ✗ ○ ◎ 统一存储/免同步 ✗ ✗ ✗ ○ ◎ 水平扩展能力 ◎ ◎ ○ ○ ◎ 运维成本 中 中 低 低 已有 社区开放度 好 好 好 一般 好 ────────────────────────────────────────────────────────────── ◎极好 ○一般 ✗不支持

Doris 胜出的关键点是统一存储和团队内部已有深厚积累（字节是 Doris 最大的工业用户之一）。

1.2 DataMind 的定位

DataMind 定位为字节内部的"一站式 AI 数据智能引擎"，核心目标是：

DataMind 能力全景 ┌─────────────────────────────────────────────────────────────┐ │ DataMind 一站式引擎 │ │ │ │ ┌──────────────┐ ┌──────────────┐ ┌──────────────┐ │ │ │ Hybrid Search│ │ AI Function │ │ GraphRAG │ │ │ │ 混合语义检索 │ │ SQL内大模型 │ │ 知识图谱推理 │ │ │ └──────────────┘ └──────────────┘ └──────────────┘ │ │ │ │ ──────────── Apache Doris 4.0 统一存储与计算 ──────────── │ └─────────────────────────────────────────────────────────────┘

二、Hybrid Search 技术实现

2.1 双算法 ANN 支持

DataMind 在 Doris 中实现了两种 ANN 算法的并行支持，这也是 Doris 4.0 官方版本中向量索引支持双算法的技术来源：

HNSW（在线高性能查询）

HNSW 在 DataMind 的部署参数（实测调优结果） 数据规模：5000 万条文档，768 维向量 ────────────────────────────────────────────────────────── 参数 生产值 说明 max_degree 48 比默认 32 高，提升召回率，内存可接受 ef_construction 100 索引质量高，构建耗时约 6 小时 ef_search 60 P99 延迟 < 20ms，召回率 98% quantizer sq8 内存从 150GB 压缩到 50GB ──────────────────────────────────────────────────────────

IVF_PQ（大规模内存受限场景）

对于超过 1 亿条向量、内存严重受限的场景，DataMind 团队贡献了 IVF（Inverted File Index）算法的实现：

IVF_PQ 索引原理 训练阶段： 1. 用 K-means 将全量向量聚类为 N 个质心（nlist 个 cluster） 2. 每个向量记录它所属的 cluster ID 查询阶段： 1. 计算查询向量与所有质心的距离 2. 选取最近的 nprobe 个 cluster（nprobe 越大，召回率越高） 3. 在这 nprobe 个 cluster 内精确搜索 关键参数： nlist = 4096 # cluster 数量（通常设为 sqrt(N) 左右） nprobe = 64 # 查询时检索的 cluster 数量（越大越慢越准） m = 8 # PQ 子向量数（768/8 = 96 个子向量） nbits = 8 # 每个子向量的量化位数 内存特性： IVF_PQ 只需加载倒排列表，不需要全量数据驻留内存 1 亿条 768 维向量：FLAT 需要 ~300GB，IVF_PQ 只需 ~8GB

2.2 Tablet-level BM25 全局 IDF 统计

这是 DataMind 最重要的技术贡献之一，解决了长期困扰分布式全文检索的 IDF 不准确问题。

问题背景：Doris 数据按 Tablet 分片存储，每个 Tablet 包含若干 Segment。在标准 BM25 中，IDF（逆文档频率）需要基于全局文档数计算，但在分布式环境里，每个 Tablet 只知道自己的局部文档数，导致分数不可比。

DataMind 的解决方案：

Tablet-level BM25 全局 IDF 统计方案 写入时： 每个 Tablet 的 Compaction 完成后，统计本 Tablet 内的： - 总文档数（N_local） - 每个 Term 的文档频率（df_local） 并将统计信息上报到 FE 的全局元数据存储 查询时： FE 聚合所有 Tablet 的统计信息： N_global = Σ N_local（各 Tablet） df_global = Σ df_local（各 Tablet） 计算全局 IDF： IDF(t) = log((N_global - df_global + 0.5) / (df_global + 0.5) + 1) 将全局 IDF 下推给各 BE 节点，BE 用全局 IDF 计算本地文档的 BM25 分数

这个方案使得 Doris 的 BM25 分数达到了与 Elasticsearch 单节点相当的准确性，是混合搜索中 BM25 路可以和向量路做可靠融合的前提条件。

2.3 Bitmap 与 Faiss IDSelector 集成

DataMind 实现的预过滤机制是 Doris 混合搜索架构的核心基础设施：

# IDSelector 集成的伪代码（内核实现简化版）classDorisANNWithFilter:defsearch(self,query_vector,where_conditions,top_k):# Step 1: 执行结构化+倒排过滤，生成 Bitmapbitmap=self.inverted_index.evaluate(where_conditions)# bitmap = {23, 45, 89, 156, ...} 满足条件的 doc_id 集合# Step 2: 将 Bitmap 转换为 Faiss IDSelectorid_selector=faiss.IDSelectorBatch(list(bitmap))# Step 3: HNSW 搜索，仅在 IDSelector 范围内search_params=faiss.SearchParametersHNSW(efSearch=60,sel=id_selector# 关键：传入过滤掩码)distances,indices=self.hnsw_index.search(query_vector,k=top_k,params=search_params)returndistances,indicesdef_should_brute_force(self,bitmap_size,total_docs):"""当候选集极少时，暴力计算比 HNSW 更高效"""ratio=bitmap_size/total_docsreturnratio<0.01# 候选集不足 1% 时降级为暴力计算

何时降级为暴力计算：DataMind 的经验是当过滤后候选集占总文档数的比例小于 1-5% 时，暴力遍历候选集的成本反而低于 HNSW 的图遍历成本，此时自动降级。这个阈值已被内置到 Doris 4.0 的实现中。

三、AI Function 生产实践

3.1 TEXT_EMBEDDING 在 DataMind 的使用

DataMind 面临的 Embedding 规模是：每天新增 50 万+ 文档，需要实时生成并写入向量。他们的方案：

-- DataMind 的 Embedding 写入管道（简化版）-- 通过 Doris 的物化视图，当 raw_documents 有新数据时自动触发向量生成CREATEMATERIALIZEDVIEWmv_doc_embeddings BUILD IMMEDIATE REFRESHONDEMANDASSELECTdoc_id,chunk_id,content,TEXT_EMBEDDING('bytedance_embed_model',content)ASembedding,NOW()ASembed_timeFROMraw_doc_chunksWHEREembedded=0;-- 定时刷新（每 15 分钟一次）-- 字节内部的 Embedding 服务通过 openai.endpoint 适配器暴露

3.2 Python UDF 多进程架构

DataMind 还贡献了 Doris 的 Python UDF 功能，解决了在 Doris 内部运行 Python 机器学习模型的工程问题。

核心挑战：Python 的 GIL（全局解释器锁）使得多线程无法利用多核，大模型推理本质上是 CPU/GPU 密集型任务。

解决方案：多进程架构 + Marshal 序列化：

Python UDF 多进程架构 Doris BE 主进程 │ │ 任务分发（分片数据） ▼ ┌─────────────────────────────────────────────┐ │ Python UDF 管理进程 │ │ │ │ ┌──────────┐ ┌──────────┐ ┌──────────┐ │ │ │ Worker-1 │ │ Worker-2 │ │ Worker-N │ │ │ │（独立进程）│ │（独立进程）│ │（独立进程）│ │ │ │ 各自持有 │ │ 各自持有 │ │ 各自持有 │ │ │ │ 模型副本 │ │ 模型副本 │ │ 模型副本 │ │ │ └──────────┘ └──────────┘ └──────────┘ │ │ │ │ 数据传输：Marshal 序列化（比 pickle 快 3x） │ └─────────────────────────────────────────────┘

使用示例（在 Doris 中注册 Python UDF 进行自定义推理）：

# 注册到 Doris 的 Python UDF 脚本importtorchfromtransformersimportAutoModel,AutoTokenizer# 模型在进程启动时加载一次，避免每次调用重载MODEL_NAME="BAAI/bge-large-zh-v1.5"tokenizer=AutoTokenizer.from_pretrained(MODEL_NAME)model=AutoModel.from_pretrained(MODEL_NAME)defprocess_batch(texts):"""批量处理，提高 GPU 利用率"""inputs=tokenizer(texts,return_tensors='pt',padding=True,truncation=True)withtorch.no_grad():outputs=model(**inputs)# 取 [CLS] token 的向量embeddings=outputs.last_hidden_state[:,0,:].numpy().tolist()returnembeddings

-- 在 Doris SQL 中调用 Python UDFSELECTdoc_id,content,custom_embedding(content)ASembedding-- 调用 Python UDFFROMraw_documentsLIMIT1000;

四、GraphRAG 的探索

DataMind 在 2025 年开始探索 GraphRAG 与 Doris 的结合，将知识图谱的多跳推理能力嫁接到 RAG 系统上。

4.1 为什么需要 GraphRAG？

标准 RAG 的弱点在于多步推理：

标准 RAG vs GraphRAG 处理复杂问题 问题："飞书的研发负责人的前任老板现在在哪家公司任职？" 标准 RAG（单次检索）： 搜索 "飞书研发负责人" → 找到人名 A 搜索 "A 的经历" → 可能找不到 结果：无法回答 GraphRAG（多跳推理）： Step1: 实体识别 → "飞书"、"研发负责人" Step2: 图查询 → 飞书 -[研发负责人]→ 人名 A Step3: 图查询 → 人名 A -[前任上级]→ 人名 B Step4: 图查询 → 人名 B -[当前任职]→ 公司 C 结果：给出完整推理链

4.2 DataMind 的 GraphRAG 实现

DataMind 的 GraphRAG 采用 Doris + 图数据库的混合架构：

DataMind GraphRAG 架构 文档/实体 │ ▼ 实体抽取（NER + AI_EXTRACT） 实体关系三元组（主体-关系-客体） │ ├──▶ Doris：存储实体属性和向量（语义检索） └──▶ 图数据库：存储实体关系图（图遍历查询） 查询时： │ ├── 语义检索（Doris 混合搜索）→ 候选文档 └── 图推理（图数据库路径查询）→ 关系链 │ ▼ 结果融合 LLM 生成综合回答

这套架构的核心优势是：用 Doris 处理文档级别的语义检索（速度快、召回准），用图数据库处理实体间的多跳关系查询（专门优化图遍历）。两者各取所长，通过应用层融合。

五、规模化落地经验

5.1 性能数据

DataMind 在字节内部的实测数据（2025 年 Q4 生产数据）：

DataMind 生产环境性能指标 数据规模：2 亿条文档，768 维向量 集群规模：20 台 BE（每台 64 核 256GB 内存） ────────────────────────────────────────────────────────── 场景 P50 P99 QPS 纯向量检索 8ms 22ms 5000+ BM25 全文检索 5ms 15ms 8000+ 混合检索（RRF） 15ms 45ms 3000+ 带预过滤的向量检索 12ms 35ms 4000+ AI_SENTIMENT 批量 - - 2000条/分钟 ──────────────────────────────────────────────────────────

5.2 成本优化策略

向量内存成本：

• 2 亿条 768 维向量，FLAT 模式需要约 600GB 内存
• 采用 SQ8 量化后降至约 200GB，单机 256GB 内存可以承载
• 配合 IVF_PQ（超热数据用 HNSW，冷数据用 IVF_PQ），整体内存降至 80GB

LLM 调用成本：

• AI 函数不放在实时查询路径
• 批量任务（如每日新文档的情感分析、分类）统一在低谷期（凌晨 2-6 点）执行
• 优先使用字节内部自研的轻量模型，仅在复杂任务时调用大模型

5.3 坑和教训

坑1：HNSW 内存估算不准导致 OOM

DataMind 早期曾因低估 HNSW 图结构的内存开销而出现 BE OOM。图结构的开销不只是向量本身，还包括每个节点的邻居列表（约max_degree × 4 bytes × N）。

坑2：Compaction 期间 BM25 IDF 统计不准确

在 Compaction 进行时，部分 Segment 的统计信息可能暂时失效，导致 BM25 分数出现抖动。解决方案是在 Compaction 完成后强制触发 IDF 全局刷新。

坑3：Python UDF 进程泄漏

早期 Python UDF 的多进程管理存在进程泄漏问题，长时间运行后系统出现 CPU 异常高。后来通过进程池 + 健康检查 + 定期轮替机制解决。

六、对社区的贡献

DataMind 团队向 Doris 社区贡献的关键功能（已合入 Doris 4.0 主线）：

小结

DataMind 案例对于我们理解 Doris 4.0 AI 能力有几个重要启示：

1. 这些能力已在生产级大规模场景验证：2 亿文档、3000+ QPS 混合检索，不是 paper 数据
2. 双算法策略很实用：在线场景用 HNSW，超大规模用 IVF_PQ，不同场景用不同工具
3. BM25 全局 IDF 是混合搜索的基础：没有这个保证，BM25 和向量分数根本无法融合
4. AI 函数做批量，向量做实时：混合使用才是最优策略

下一篇讲全文搜索的进阶细节，BM25 算法原理 + SEARCH 函数 DSL + 自定义分词器，Doris 全文搜索能力全貌。