本文作者：OceanBase 资深技术专家 张易

摘要：
在 AI 时代，OceanBase 以混合搜索为核心的多模能力，从 AI Agent 的视角出发，为大模型提供高质量的上下文信息，在提升 AI 应用效果的同时显著降低运行成本，真正实现了技术与业务价值的统一。

在 AI 与数字化转型驱动的时代，企业正面临数据形态、处理速度与复杂性的剧增。近日，全球知名咨询机构 Forrester 在其最新报告《Multi-Model Data Platforms Landscape, Q4 2025》中指出，多模数据平台（MMDP）已成为应对现代应用复杂数据需求的关键趋势。报告将 MMDP 定义为“在一个数据库管理系统中支持多种数据模型”的统一平台，其核心价值在于简化技术栈、降低数据冗余并加速开发周期。

OceanBase作为“Notable Vendor”出现在该报告中，这不仅是对 OceanBase 多模一体化产品的认可，更预示着化繁为简、现代架构的数据时代即将来临。

在报告中，OceanBase 被认为是聚焦以下扩展用例的代表性厂商：

Agentic AI
Forrester 认为 MMDP 是 Agentic AI 的大脑与记忆。AI Agent 需要推理，它需要知道事实、拥有记忆并理解逻辑关系。MMDP 提供了向量检索（找相似）、图谱（找逻辑）、结构化数据（找事实）的统一平台，防止 AI 幻觉。

多模数据统一检索
Forrester 认为 MMDP 能为开发者提供一键“原子操作”。比如，用户修改资料，既要改结构化数据里的名字，又要改全文搜索里的索引，还要改图数据里的节点，过去这需要写很复杂的分布式事务代码，而 MMDP 允许用统一查询语言在一个步骤内完成跨模态的增删改查，保证数据一致性，极大简化开发。

推荐引擎
Forrester 认为 MMDP 能够提供比“猜你喜欢”更懂你的推荐。传统的推荐只看买了什么，现在的推荐要看用户的实时点击流（行为）、朋友买了什么（关系）、用户搜索的关键词（文本语义），结合了图计算（社交推荐）和多模态搜索（语义推荐），提供更精准的上下文感知推荐。

本文将深度解读 OceanBase 多模一体化能力，探讨其如何以原生一体化的架构，帮助企业架构师与 IT 决策者厘清正在面临的“架构之问”：是继续采用“烟囱式”的数据库组合，还是转向真正的一体化平台？

从“多”到“一”：终结架构碎片化，多模是 AI 时代的必然选择

长期以来，业界普遍采用“为专业场景选择专业工具”的理念，构建了所谓的“多语言持久化”（Polyglot Persistence）架构，即为不同数据模型部署独立的数据库系统。然而，这种模式在业务复杂性指数级增长的今天，其弊端日益凸显，逐渐演变为创新的沉重枷锁。

这种“数据库联邦”模式的困境，在许多积极拥抱 AI 的企业中表现得尤为突出。它们为了实现语义搜索、精确匹配与关系查询，被迫引入由关系数据库、搜索引擎与多种向量数据库构成的复杂技术栈。这不仅导致架构臃肿、运维成本高昂，更在稳定性、数据一致性与开发效率上带来了巨大挑战，形成了沉重的技术债务。

货拉拉在转型过程中的早期探索，便是一个深刻的例证，其面临的动态 Schema 变更、混合检索与多系统运维难题，正是这种碎片化架构的典型缩影。

这些痛点深刻揭示了“烟囱式”架构的本质缺陷——它将数据管理的复杂性转嫁给了应用和运维团队。正如 Forrester 报告所指出的，MMDP 的核心价值正是通过在一个数据库内部实现统一的数据存储、事务处理和治理，从根本上解决数据孤岛问题，降低总拥有成本（TCO）并提升业务敏捷性。

Forrester: MMDPs Enable Simpler Cross-Model Querying

解构 OceanBase：为 AI Agent 打造的混合搜索“大脑”

在 AI Agent 与大语言模型（LLM）引领技术浪潮的今天，数据库的角色正在被重新定义。它不再仅仅是数据的存储仓库，更是决定 AI 应用智能水平与运行成本的“上下文引擎”（Context Engine）。

正如 OceanBase CTO 杨传辉所言，“向量搜索只是 AI 数据库的初级阶段，最终所有向量搜索都会演进为混合搜索——能否支持混合搜索，正是衡量 AI 数据库核心实力的关键分水岭”。

OceanBase 的多模一体化实现混合搜索

OceanBase 的多模能力并非简单的“功能叠加”，而是根植于其原生一体化的分布式架构。这种架构将关系、向量、全文、JSON 等多种数据模型统一在单一引擎下，共享同一套存储、事务和查询优化器。其核心价值主张，正是从 AI Agent 的视角出发，通过强大的混合搜索能力，为大模型提供更高质量、更精准的上下文信息，从而在提升 AI 应用效果的同时，显著降低因 Token 消耗而产生的计算成本。

混合搜索：AI 时代的“上下文工程”基石

AI 应用，尤其是 RAG（检索增强生成）应用，其效果的优劣极大程度上依赖于提供给大模型的上下文质量。大模型虽然具备强大的计算能力，但缺乏长期记忆，这就需要数据库为其存储并管理上下文信息，同时精准输出大模型所需的上下文——这一过程被称为“上下文工程”（Context Engineering）。

一个典型的复杂查询，如“推荐附近 500 米内，人均消费低于 25 元，评价超过 4.5 分，且环境安静的咖啡厅”，单纯的向量或文本搜索都难以胜任。这需要一个能同时理解并处理多种数据维度的“大脑”。

OceanBase 的混合搜索能力，正是为解决这类多维度信息综合检索的难题而生。它将四种关键的搜索能力无缝融合在一个查询引擎中：

这种“多路召回，统一排序”的模式，让 OceanBase 能够先通过关系、标量数据进行高效过滤，大幅缩小检索范围，再在小范围内进行精准的向量或全文搜索。每一路检索都会产出部分结果，最终将各路结果融合，并经过全局重排序（Rerank），才能为大模型输出其真正需要的精准结果。

OceanBase 混合搜索机制

这种机制不仅极大地提升了查询的准确性（Recall）和精确率（Precision），更重要的是，它将最相关、最精炼的信息作为上下文喂给大模型，有效避免了无关信息对模型推理的干扰，并从根本上减少了昂贵的Token消耗，直接降低了AI应用的运行成本。

技术利器一：高性能向量搜索是混合搜索的基础

高性能且功能完备的向量搜索，是混合搜索的核心基础。目前，OceanBase 向量搜索性能已达到业界开源向量数据库的先进水平——无论是稠密向量还是稀疏向量，在向量数据库领域主流 Benchmark 测试中均表现突出。

在 VectorDBBench 的测试中，OceanBase 在不同过滤率下的性能全面占优。同时，OceanBase 的磁盘向量索引，在构建时间与存储占用两方面，也实现了业界领先。

OceanBase 向量性能测评

更重要的是，OceanBase 实现了向量搜索与全文搜索的深度融合，通过多路搜索显著提升召回效果。测试数据清晰呈现了不同搜索方式的召回表现：仅采用单一搜索路径（无论全文搜索、稠密向量还是稀疏向量），都难以达到最优召回效果；唯有将稀疏向量、稠密向量与全文搜索相结合，才能实现更优的召回表现，达成 1+1 > 2的协同效应。

OceanBase 多路召回评测

值得一提的是，这两大能力均构建于 OceanBase 数据库原生架构之上，天然继承了分布式架构的弹性扩展特性与对象存储的高效适配能力。

技术利器二：半结构化数据的高效处理（JSON）

在 AI 场景中，企业在处理海量 JSON 数据（如用户行为日志、订单轨迹、动态特征字段）时，普遍面临 Schema 重复存储导致空间浪费、按行存储导致压缩率低、查询性能低下等痛点。

OceanBase 针对性地设计了创新的存储方案。它采用 JSON 二进制存储，并创造性地实现了“列化拆分”。通过智能识别“高频列（Frequent Col）”与“稀疏列（Spare Col）”，将频繁访问的字段独立成列存储，稀疏字段则聚合存储。

OceanBase JSON 列化拆分机制

这种设计带来了显著的技术收益。首先是极致的压缩效率，拆分后的独立列可利用 OceanBase 成熟的列存编码能力进行高效压缩。在 TPCH-10G 数据集上的测试显示，其压缩比是传统文档数据库的 3 倍，直接降低了存储成本。

其次是查询性能的加速，查询特定字段时，只需读取对应列，极大减少了 I/O 开销。此外，用 JSON 格式动态扩展特征字段，还可帮助企业减少 30%-50% 的数据清洗成本。这一能力对于 AI 应用中频繁变化的特征工程尤为重要，使得企业无需频繁修改 Schema 即可灵活应对业务需求。

技术利器三：HTAP 能力支撑 AI 场景的元数据管理

在 AI 场景中，除了要开展多路搜索，还需妥善管理 AI 场景下的元数据。要做好 AI 数据库的元数据管理，不仅需要支持元数据的实时写入与事务一致性，还需实现元数据检索结果与多路搜索结果的 SQL 级联动。

在这方面，支持 HTAP 的关系型数据库是更优选择。通过将关系模型与向量、全文、JSON 能力深度融合，OceanBase 最终形成了全面的混合搜索能力。

OceanBase 如何解决 AI 场景元数据管理问题

例如，在知识库场景中，需要管理用户权限、文档分类、访问日志等大量元数据，同时还要进行文档的语义检索。传统方案需要在应用层协调关系数据库与向量数据库的查询结果，而 OceanBase 则可以通过一条 SQL 完成“先通过关系过滤确定用户可访问的文档范围，再在该范围内进行向量语义搜索”的复杂操作，极大地简化了开发逻辑并提升了查询效率。

一体化架构：从“数据库联邦”到“统一数据底座”

过去，企业为了实现类似的多模态处理能力，不得不拼凑一个由关系数据库、向量数据库、全文搜索引擎等多种产品组成的“数据库联邦”。这种“烟囱式”架构不仅运维复杂、成本高昂，更在数据一致性、开发效率和系统稳定性上带来了巨大挑战。

OceanBase 的一体化架构则试图改变这一局面，为企业 AI 应用提供坚实的统一数据底座。多个客户的成功实践，生动地诠释了这一价值。

蚂蚁集团“百宝箱”的智能体在线搜索就是一个典型案例。其复杂的地理位置、用户评分、消费水平和语义偏好混合查询需求，在 OceanBase 中通过一条 SQL 即可实现，完美替代了原先 Milvus + Zsearch + OceanBase 的复杂组合。这种将多路检索逻辑从业务层下沉到数据库内核的做法，极大地简化了业务实现，实现了在线高性能混合搜索。

蚂蚁集团百宝箱 Agent 在线搜索示例

货拉拉则基于 OceanBase 的混合搜索能力，构建了一站式的企业 AI 数据底座，支撑起包括知识库平台、AI Coding、Agent 平台、ChatBI、智能客服等多种 AI 应用。这不仅用单一技术栈取代了原有的 vsearch + Weaviate + Milvus 等多个开源组件，解决了系统的稳定性难题，还复用了 OceanBase 成熟的高可用能力，实现了 RPO=0、RTO<8 秒的金融级标准。

在具体应用中，货拉拉通过“资损代码识别”场景，利用历史案例向量化与实时代码相似度检索，有效规避了潜在的财务风险；在“数仓AI答疑助手”项目中，更是融合了向量、标量、全文关键字等多种检索方案，并结合重排序模型，显著降低了内部数据查询门槛和人力成本，提升了数据开发人员的效率。

货拉拉 AI 应用架构

中国联通利用 OceanBase 构建了拥有 10 亿级向量规模的公司级统一知识库平台。原先采用“关系数据库+Elasticsearch”的架构，在切换到 OceanBase 后，查询执行效率提升到原 Elasticsearch 方案的 2 倍，同时解决了复杂的用户-文档权限管理问题。通过融合关系查找与多路搜索，联通成功实现了知识库的精细化权限管控及灵活的用户间权限共享需求，支持公共文档与私有文档的统一管理。

中国联通 AI 应用架构图

飞猪也通过 OceanBase 统一了其智能体数据平台的后端，用一套系统替代了原先的分布式 KV + 分布式 Table + 搜索 + 向量的复杂架构。这不仅统一了技术栈，还实现了对知识库、Memory 等多种数据的统一支持，SQL 的简单易用性与稳定低延迟的特性，让开发团队能够更专注于业务创新。

飞猪 AI Agent 架构

这些案例共同证明，OceanBase 的一体化架构并非简单的功能聚合，而是通过在内核层面实现多模数据的统一管理与查询，从根本上解决了数据孤岛问题，降低了技术栈的复杂性，最终加速了AI应用的创新与落地。

从技术到业务：OceanBase 多模一体化的实践价值

技术的先进性最终需要通过业务价值来体现。从上述案例中，我们可以清晰地看到 OceanBase 多模一体化架构在 AI 时代所带来的三大核心价值：

第一，显著降低 AI 应用的运行成本。 通过混合搜索提供的精准过滤与排序机制，OceanBase 能够为大模型提供更高质量、更相关的上下文信息，从而大幅减少无效 Token 的消耗。在当前大模型推理成本居高不下的背景下，这种成本优化对企业而言具有直接的经济价值。

第二，简化技术栈，提升开发与运维效率。 一体化架构让企业无需在应用层协调多个异构数据库系统，开发者可以用熟悉的 SQL 语言完成复杂的多模查询，极大地降低了学习成本与开发复杂度。同时，统一的运维管理也减轻了 DBA 团队的负担，提升了系统的整体稳定性。

第三，加速 AI 应用的创新周期。 当数据基础设施变得简单、高效且可靠时，业务团队可以将更多精力投入到 AI 应用本身的创新上，而非陷入复杂的数据管道搭建与维护中。这种“基础设施即服务”的理念，正是 OceanBase 一体化架构的核心价值所在。

选择下一代数据基石，拥抱智能未来

Forrester 的报告揭示了多模一体化不仅是技术趋势，更是企业在 AI 时代保持竞争力的战略选择。面对日益复杂的数据环境，传统“烟囱式”的架构已难以为继。

OceanBase 提供的不仅是一个功能丰富的数据库，更是一个稳定、高效、面向未来的一体化数据基石。它通过在存储、查询、事务等层面的原生一体化设计，让企业能够更从容地应对数据融合的挑战，将宝贵的精力聚焦于业务创新本身。

特别是在 AI 时代，OceanBase 以混合搜索为核心的多模能力，从 AI Agent 的视角出发，为大模型提供高质量的上下文信息，在提升 AI 应用效果的同时显著降低运行成本，真正实现了技术与业务价值的统一。

对于正在寻求下一代数据架构的架构师和 IT 掌舵者而言，可以重新审视自身的技术栈，考虑 Forrester 倡导的多模数据处理平台，为企业的下一个十年发展奠定坚实基础。

欢迎访问 OceanBase 官网获取更多信息：https://www.oceanbase.com/

导读：面对海量多模态数据管理困境，思必驰通过构建以 Apache Doris 为核心的数据集平台，实现了数据从“散、乱、滞”到“统、明、畅”的转变。在关键场景中，存储占用下降 80%、查询 QPS 提升至 3w，不仅实现可量化的效率提升和成本优化，更系统化地提升了 AI 研发效率与模型质量。

本文整理自 思必驰数据中台架构师魏凯君在 Doris Summit 2025 中的演讲内容，并以演讲者第一视角进行叙述。

思必驰作为专注于对话式人工智能的平台型企业，围绕“云+芯”战略布局，致力于提供软硬件结合的全链路 AI 产品与服务。在长期服务智能车载、家居等终端场景中，我们积累了海量的多模态训练语料（包含音频、文本及人工标注）。

早期的数据管理方式逐渐成为 AI 研发的瓶颈。各业务团队的标注数据分散在不同的存储系统中，依赖人工进行维护和同步。随着数据规模快速增长至 PB 级别，传统方式在三个方面面临严峻挑战：

1. 数据一致性问题：同一份数据在不同团队中存在多个副本，且更新不同步，影响模型训练的一致性。
2. 协同效率低下：算法工程师难以快速查找、复用跨团队的数据资产，重复标注与数据准备浪费了大量时间。
3. 版本追溯困难：模型迭代时，无法精准关联训练所使用的数据版本，导致问题复现与效果归因困难。

这些问题使得数据资产化与高效协同成为制约 AI 研发规模化的关键。为此，我们决定构建一个统一的数据集管理平台，目标是将原始数据标准化、资产化，打造一个支持高效调用、可靠追溯、安全共享的“AI 数据基座”。

为何是 Apache Doris？

思必驰与 Apache Doris 的合作始于早期技术实践。在 Doris 0.12 版本时期，我们率先将其应用于内部实时数仓场景，并随业务发展，逐步建立起面向外部服务的 Doris 集群，支撑了包括实时看板、用户画像与自助分析在内的多项数据能力。

此外，Doris 在海量业务日志场景（容器日志）中也发挥了关键作用，替代了原有的 Elasticsearch，并基于 Doris 自建日志查询平台，服务智能座舱语音业务。在同等硬件资源下，日志写入性能从原来的 100w/s 提升至 300w/s，存储成本也降低了 50% 以上。

基于 Doris 在性能、成本、稳定性方面的综合优势，在构建数据集平台时，它自然成为数据底座的首选。我们的新场景对数据库提出了更高要求：

• 海量数据去重与高效查询：需处理 10 亿级样本的快速去重与复杂筛选。
• 完善的版本管理：需支持数据集的版本化存储、快速切换与对比。
• 支持向量检索能力：为后续的相似样本检索、特征比对提供支持。
• 高性价比存储：需利用高效压缩与冷热分离，降低 PB 级数据的存储成本。

综合评估，Apache Doris 在满足上述核心需求的同时，其简洁的架构、易用的运维以及活跃的社区，使其成为最优方案。

面向 AI 大规模训练的数据基座

我们采用类 MLOps 理念，设计了贯穿数据-模型-应用的标准化流水线。

• 数据预处理：原始的多模态数据（语音、文本等）通过采集、回流进入系统，经由专业的标注平台进行加工，再进入 AI 数据前台进行清洗与特征提取。
• 数据集管理系统：经过预处理的数据，汇入 基于 Apache Doris 构建的数据集管理系统（即本文核心） 。该系统是整个 AI 中台的关键，负责数据的版本化存储、管理与发布，为模型训练与测试提供数据支撑。
• 模型训练及管理：测试数据集进入模型训练系统进行训练，生成的模型经模型管理平台统一管理，最终部署上线，服务于业务应用。

由上图可知，数据集管理系统被囊括在 AI 中台这一架构中。纵观整个 AI 中台，主要包括三个部分：

• 数据管理系统：基于 Apache Doris 和 Elasticsearch 构建，提供页面、客户端和相应的 SDK；
• AI 平台：基于推理与训练框架，以及资源管理与任务调度框架构建；同样提供页面、客户端和 SDK。
• 底层基础设施：涵盖计算层、分布式存储体系及优化后的网络层。

为满足不同业务场景需求，数据集管理 系统设计了单中心和多中心两种部署架构：

• 单中心：面向核心研发场景，数据访问统一指向本中心的 Apache Doris、Elasticsearch、Kafka 及相关文件系统，保证最强的一致性与性能。

• 多中心：面向跨地域或异构计算资源场景， 采用分布式设计。主中心的数据层使用 Apache Doris，各分中心采用独立的分布式文件系统，这些存储之间可以实现数据的相互同步。针对各个中心的训练任务，系统能够读取这些分布式文件存储中的数据进行训练。

数据版本毫秒级切换，存储占用下降 80%

过去，我们依靠人工在文件系统中维护数据集目录，随着版本激增，混乱与错误难以避免。新平台需要实现类似代码库的版本管理能力（对比、切换、回滚）。

为此，我们利用 Doris 的特性进行改进：

1. 列式存储：将标注信息等结构化数据从文本文件迁移至 Doris 表，利用列式存储的高压缩特性，存储空间占用降低 80%以上。

• 分区表实现版本化：以数据集版本作为分区键。最新活跃版本存放在 SSD（热存储），历史版本自动迁移至 HDD（冷存储），SSD 使用率降低 30%以上。
• 表结构设计：核心围绕数据集表，关联文件表与标注表。通过分区机制，实现了毫秒级的历史版本数据检索与切换。

精准溯源检索，查询 QPS 提升至 3W

为解决模型训练后与原始数据脱节这一核心痛点，数据集平台内置了样本溯源能力。传统的流程在完成特征提取后，往往丢失了原始数据的属性与标注信息，导致两大问题：模型无法关联其“数据血缘”，以及不同模型版本间难以进行有效的对比调优。为此，我们确立了样本 ID 全局唯一的核心要求，以此支撑精准的溯源与检索。

在样本检索实现初期，团队采用 Apache Doris 的 IN 查询方式支撑相关能力，而面对瞬时并发的规模点查请求时，会有明显资源与性能开销，部分节点峰值可达 80%。

为此，团队基于 Apache Doris 的相关能力进行优化，主要采用两类改进：

• 首先，根据“高频点查”这一核心特征，切换至行式存储并优化 I/O 路径，使单次查询更快。
• 其次，通过全面启用预处理语句，将查询计划固定下来，避免了大量的重复计算开销。

优化后，在现有配置下，查询 QPS 提升至 3 万/秒；同时在高频点查询期间，CPU 占用由原先约 80% 降至约 10%，并持续稳定。

平台收益：可量化的效率提升与成本优化

在平台落地后，形成了可量化的建设成效：数据集规模超过 1 万个，数据总量超过 500TB，样本数量超过 10 亿，平台使用人数超过 200 人。通过新旧架构对比，新平台在三个维度带来了显著收益：

• 成本大幅优化：通过消除数据冗余拷贝，存储成本降低 20% 以上，网络成本节约超 3 倍。
• 效率全面提升：数据查询效率提升超 3 倍，数据同步效率提升超 2 倍。
• 研发显著提效：模型研发流程效率提升 20% 以上，且数据集使用得以全面规范。

更重要的是形成了不可替代的隐性价值：

• 统一了数据质量标准：公司内研发、测试、业务团队使用同一套数据和规范，从根本上保障了模型输入的一致性。
• 增强了问题复现能力：任何模型结果均可精准追溯至对应的训练数据集与版本，使得问题调试、效果归因有据可依。
• 实现了流程自动化闭环：结合自动标注系统，实现了从数据回流、清洗、标注到训练的数据闭环，极大提升了 Badcase 的定位与修复效率。

未来规划

基于当前的成功实践，未来我们将继续深化 Apache Doris 的应用，推动数据架构向更先进的方向演进：

1. 日志分析场景全面替换：已在 TPS 15 万量级场景完成验证，将加速推进用 Doris 替代 Elasticsearch，预计进一步降低日志处理总成本。
2. 拥抱 Doris 4.0 新特性：重点关注并计划升级至 Doris 4.0 版本，利用其向量检索能力，支持更复杂的相似性查询与 AI 原生应用。
3. 探索湖仓一体架构：打破数据孤岛，实现数据在数据湖（低成本存储）与数据仓库（高性能分析）间的自由流动与统一管理，支撑 SQL 查询、机器学习等多样化负载。
4. 推进存算分离落地：实现计算资源的按需弹性伸缩与负载隔离，并将冷数据沉降至对象存储，在提升资源利用率的同时，追求极致的存储成本效益。

引言：

随着大模型和多模态 AI 的快速发展，向量已成为文本、图像、音视频等多元数据的通用语义表示。在这种背景下，检索增强生成（RAG）技术成为连接私有知识与大模型的核心桥梁，而高效的向量检索则是其关键支柱。

与将向量检索视为独立外挂服务的方案不同，Apache Doris 4.0 选择将向量检索能力深度集成于其 MPP 分析型数据库内核。实现向量检索与 SQL 计算、实时分析和事务保障的无缝融合。

本文旨在深入剖析 Doris 向量检索的系统级设计与工程实践，展示其如何在性能、易用性与规模扩展之间取得的平衡。

1. ANN 索引核心设计

Apache Doris 的向量索引基于 ANN（近似最近邻）算法实现，并非独立的外挂组件，而是深度集成于存储、执行与 SQL 引擎中的原生能力。在 4.x 版本中，其核心 ANN 索引能力主要包括以下几方面：

1. 多索引类型与距离度量支持：支持主流的 ANN 索引类型（HNSW、IVF）及常见距离度量（L2 距离、内积）。用户可根据业务在构建速度、内存占用与召回率上的要求灵活权衡。
2. 原生 SQL 集成：向量检索以原生 SQL 算子形式提供，支持直接定义向量列、通过 ORDER BY distance LIMIT K 进行相似度搜索，并能与过滤、聚合、JOIN 等算子自由组合，天然支持混合检索与分析。
3. 构建与查询解耦：采用异步索引构建机制，数据导入后即可查询，索引在后台构建并加载，避免导入阻塞，保障查询高峰期的稳定低延迟写入。
4. 向量压缩优化：在导入与构建阶段支持标量量化（SQ）、乘积量化（PQ）等压缩技术，显著降低存储与内存开销，提升高维大规模向量场景的资源效率。
5. 分布式并行执行：依托于分布式架构，Doris 向量索引天然支持数据分片与索引分布式存储；查询可在各 BE 节点并行执行；Top-K 结果在上层进行合并与裁剪。随着节点数量增加，系统能够在数据规模与吞吐能力上实现近线性扩展。

2. Benchmark & Analysis

Apache Doris 的目标并非追求单一指标的极限表现，而是在真实生产负载下，实现性能的均衡性、系统稳定性与架构可扩展性。本次测试将围绕这一目标展开，所用工具为 ZillizTech 开源的向量搜索 BenchMark：https://github.com/zilliztech/VectorDBBench。

• 云服务商：阿里云
• CPU：Intel Xeon Platinum 8369B @ 2.70GHz (16 核)
• 内存：64GB

2.1 导入与构建性能

测试结果表明，在 Performance768D1M 数据集上，Apache Doris 在保证同等索引质量的前提下，导入性能显著优于对比系统。尤为重要的是，其导入速度的提升并未以牺牲图结构质量为代价。Doris 在 QPS 达到 895 的同时，仍保持了 97% 以上的召回率，在性能三角的三个维度上取得了出色的平衡。

2.2 查询性能

即便单独考量查询性能，Apache Doris 同样处于业界第一梯队。

在 Performance768D10M 数据规模上，当召回率要求高于 95% 时，Apache Doris 的 QPS 表现优于 OpenSearch 与 Qdrant。此结果为默认配置下的开箱性能，未针对 Segment 文件数量等进行专项调优。

这里比较的是开箱性能测试，即不做 segment 文件数量的优化时的性能对比。

Milvus 的 flat 版本以及 Cloud 版本会有更好的性能表现，但是其出品的 VectorDBBench 只提供了 SQ8 量化后的成绩。

3. 核心设计与性能优化

Apache Doris 采用 FE（协调节点）与 BE（计算节点）构成的分布式架构。BE 作为核心执行单元，承担查询计划执行与数据导入任务，负责几乎所有高负载计算与大规模数据吞吐，是系统高性能的基石。尤其在向量场景下，数据写入、索引构建与向量距离计算都属于典型的 CPU 与内存密集型工作。为充分发挥其性能、保障系统稳定运行，我们对 ANN 索引的写入、构建与查询路径进行了系统优化。

3.1 写入与构建路径优化

优化主要分为两类：功能优化与性能优化。

• 在功能层面，依托 Doris 成熟的分布式集群管理与存储管理能力，引入 LightSchemaChange 实现轻量级的索引管理机制，这是目前专用向量数据库普遍不具备的能力。
• 在性能层面，重点聚焦于索引构建流程的优化，以显著提升索引构建速度和整体吞吐能力。

3.1.1 异步索引构建机制

Apache Doris 针对 ANN 索引构建开销大的问题，提供了异步构建机制。用户可在数据导入后，选择业务低峰期触发索引构建；在查询高峰时，仅需将已建好的索引加载至内存即可快速检索，从而将密集的 CPU 消耗转移至成本更低的时段。

在 FE 侧，CREATE INDEX 与 BUILD INDEX 通过 SchemaChangeHandler 编排：

1. 为每个分区创建影子索引与影子 Tablet（IndexState.SHADOW），并建立 origin→shadow 的 Tablet 映射与影子副本（副本初始态为 ALTER）。
2. 生成新的 schema version/hash，保障新旧版本隔离。
3. 通过 FE→BE 的 AgentTask（Thrift）分发构建任务到各 BE，BE 在 Tablet 层面完成索引数据构建。
4. 构建成功后，FE 原子性地将影子索引切换为正式索引，更新元数据并清理旧工件。

该流程在保证线上业务可读写的同时，实现了索引构建的在线隔离与数据一致性。

3.1.2 导入性能优化

为在保障索引质量的前提下提升写入吞吐与稳定性，Doris 采用了 多层级分片、双层并行、SIMD 向量化计算 的组合方式进行优化。

A. 多层级分片

Apache Doris 将逻辑表在内核层拆分为多个 Tablet。每次数据导入会生成一个 Rowset，每个 Rowset 又包含若干 Segment，而 ANN 索引正是在 Segment 粒度上构建与使用的。这一设计将“全表数据量”与“索引超参数”解耦，用户只需根据单批次导入的数据规模来设定参数，无需因数据总量增加而反复重建索引。

以单 BE 单分桶的典型场景为例，我们从实际经验中总结出如下参数可供参考：

得益于 Apache Doris 的分片架构下，索引参数可稳定在合理的规模区间，不受全表数据总量增长的影响。换言之，索引超参数的设置只需基于单个 Tablet 单次导入的数据行数。即便集群规模扩大，也仅需根据机器与分桶数量相应调整批次大小（batch size）即可。

以 HNSW 索引为例，在单 BE 集群中，针对每批导入 25 万、50 万、100 万行的典型规模，分别选择 max_degree≈100/120/150、ef_construction≈200/240/300、hnsw_ef_search≈50~200，即可在延迟可控的同时平衡召回与构建成本。

经验上，召回率随 hnsw_ef_search 提高而改善，但查询延迟也会线性增加。max_degree 与 ef_construction 过小会导致图结构稀疏、查询不稳定；过大则会显著增加构建时间与内存占用。因此，建议结合业务对召回和延迟的要求，通过离线压测确定最佳参数组合。

B. 双层并行构建

集群层由多台 BE 并行处理导入批次；单机内再对同一批数据进行多线程距离计算和图结构更新。配合“内存攒批”（在内存中适度合并小批次），可避免过细分批导致的图结构稀疏与召回下滑，在固定超参数下获得更稳定的索引质量与构建速度。

以 768 维、1,000 万条向量为例：分 10 批构建的召回率约可达 99%，若切成 100 批则可能降至约 95%。适度的内存攒批既不显著抬高内存峰值，又能提升图连通性和近邻覆盖，从而减少查询阶段的回表与重复计算。

C. SIMD 加速

向量距离计算是典型的 CPU 密集型计算。Doris 在 BE 侧采用 C++ 实现距离计算，引入 SIMD（单指令多数据）并行计算。可以更少的指令、更少的访存，更快完成把同样的距离，从而显著提升向量索引构建和重排阶段的吞吐能力。具体来讲：

• 并行计算多个维度：利用 SSE / AVX / AVX-512 等指令集，同时加载和计算 8～16 个浮点数，而非逐维循环。
• 减少内存访问：在计算前对向量数据进行批处理和转置，使数据在内存中连续排列，优化 CPU Cache 访问模式。
• 合并计算步骤：使用 FMA（乘加融合）指令，把“乘法 + 加法”合并为一步，并通过水平求和快速聚合向量数据。
• 高效处理边界情况：对维度不对齐的尾部数据，使用掩码指令统一处理，避免额外分支和判断。

3.1.3 向量压缩技术

以 HNSW 为代表的高性能索引数据结构通常将向量与图结构常驻内存。在 RAG 场景中，文本/图片/音频等模态向量维度约为 1,000，若每维使用 FLOAT32 存储，一百万行占用 4 GB，千万行则约 40 GB。考虑到索引结构的额外占用（约 1.3 倍），一千万行整体接近 52 GB。以 16C64GB 机器为例，单机索引上限约为千万级，需预留空间以避免 OOM，并保障查询和构建的并行开销。

为了显著降低内存占用、扩展单机承载能力，向量压缩技术成为关键。Apache Doris 在此提供了两种主流的实现方案：标量量化与乘积量化。

A. 标量量化（Scalar Quantization，SQ）

标量量化通过用低精度类型替换高精度类型来压缩存储空间，Doris 支持 INT8 和 INT4 的标量量化，并在导入和构建阶段完成编码。

如若将 FLOAT32（4 字节）替换为 INT8（1 字节）可节省约 75% 存储，进一步压缩为 INT4 则节省约 87.5%。如果压缩后数据的分布形态保持一致，召回率在可控延迟内接近未压缩效果。

上图展示了在 128 维和 268 维向量上的测试结果。相比 FLAT（不编码，用完整 Float32 表示每个浮点数），SQ8 可实现接近 2.5 倍的压缩，而 SQ4 可实现接近 3.3 倍的压缩。

值得说明的是，引入 SQ 不可避免的会带来额外的压缩计算开销（索引构建阶段），且标量量化更适用于各维度近似均匀分布的数据。如遇分布呈高斯或更复杂形态时，标量量化误差增大，则可采用乘积量化方式。

B. 乘积量化（Product Quantization， PQ）

RAG 等场景中，由 Transformer 编码器生成的向量，存在明显的语义结构、分布不均匀。乘积量化通过子空间划分 + 子空间学习型量化，能够更好地适配。

PQ 将高维向量分割为多个子向量，并为每个子空间独立训练一个码本（例如通过 k-means 聚类学习质心）。这使得数据密集区域能用更精细的码本保持细节，从而在整体上用更短的码长维持原始的距离关系。查询时通过查表与累加来估算距离，大幅减少了计算与内存访问开销。

我们在 128 维与 268 维上对比 SQ 与 PQ，参数统一设定为 pq_m = dim/2、pq_nbits = 8。

从空间占用看，PQ（m=68/128， nbits=8）的内存占比与 SQ4 大致相当，可实现约 3× 压缩。

除构建更快外，PQ 还可依赖查表加速解码，体现在更优的查询速度上。

关于 PQ 的超参数，实际使用时建议结合数据分布进行针对性适配与调优。根据经验，将 pq_m 设为原始维度的一半，pq_nbits 设为 8，在多数场景下即可取得良好的效果，可作为初始调优的参考起点。

综合来看，对于用户来说， SQ 和 PQ 该如何选择呢？

• 从使用上来说，SQ 的优点是使用方式简单，只需要指定数据类型即可，而 PQ 的使用门槛更高，需要对其原理有较为深刻的理解才能在生产环境中发挥其优势。
• 从性能及开销上来说，SQ 在解码阶段存在额外计算开销，且随维度增加开销更高；PQ 则能在压缩的同时保持接近原始向量的查询性能。
• 从场景上来说，SQ 更适用于各维度近似均匀分布的数据。如遇分布呈高斯或更复杂形态时，标量量化误差增大，则可采用乘积量化方式。

3.2 查询执行路径优化

搜索场景对延迟极为敏感。在千万级数据量与高并发查询的场景下，通常需要将 P99 延迟控制在 200 ms 以内。这对 Doris 的优化器、执行引擎以及索引实现都提出了更高要求。Apache Doris 为此做了大量优化，这一章节对其中涉及到的部分能力做介绍。

3.2.1 虚拟列机制

Apache Doris 的向量索引采用外挂方式。外挂索引便于管理与异步构建，但也带来性能挑战：如何避免重复计算与多余 IO？

ANN 索引在返回行号时，会同步计算出向量距离。执行引擎在 Scan 算子阶段可直接利用该结果进行筛选和排序，无需在读取数据后重新计算。这一过程通过 “虚拟列” 机制自动实现，最终以 Ann Index Only Scan 的形式运行，完全消除了因距离计算而产生的数据读取 I/O。

未应用 Index Only Scan：

应用 Index Only Scan 后：

例如 SELECT l2_distance_approximate(embedding, [...]) AS dist FROM tbl ORDER BY dist LIMIT 100;，执行过程将不再触发数据文件 IO。

该优化不仅适用于 TopK 检索，也支持 Range Search、复合检索（Range + TopK）以及与倒排索引结合的混合检索场景，实现了全路径的 Index Only Search。

虚拟列机制并不局限于向量距离计算。对于正则抽取、复杂标量函数等 CPU 密集型表达式，若在同一查询中被多次引用，该机制也能复用中间结果，避免重复计算。以 ClickBench 数据集为例，以下查询统计从 Google 获得最多点击的 20 个网站：

set experimental_enable_virtual_slot_for_cse=true;

SELECT counterid,
       COUNT(*)               AS hit_count,
       COUNT(DISTINCT userid) AS unique_users
FROM   hits
WHERE  ( UPPER(regexp_extract(referer, '^https?://([^/]+)', 1)) = 'GOOGLE.COM'
         OR UPPER(regexp_extract(referer, '^https?://([^/]+)', 1)) = 'GOOGLE.RU'
         OR UPPER(regexp_extract(referer, '^https?://([^/]+)', 1)) LIKE '%GOOGLE%' )
       AND ( LENGTH(regexp_extract(referer, '^https?://([^/]+)', 1)) > 3
              OR regexp_extract(referer, '^https?://([^/]+)', 1) != ''
              OR regexp_extract(referer, '^https?://([^/]+)', 1) IS NOT NULL )
       AND eventdate = '2013-07-15'
GROUP  BY counterid
HAVING hit_count > 100
ORDER  BY hit_count DESC
LIMIT  20;

核心表达式 regexp_extract(referer, '^https?://([^/]+)', 1) 为 CPU 密集型且被多处复用。启用虚拟列优化（set experimental_enable_virtual_slot_for_cse=true;）后，端到端性能提升约 3 倍。

3.2.2 前过滤与谓词下推

在 ANN TopN 检索中，过滤谓词的应用时机是关键的设计权衡：

• 前过滤：在 TopN 之前应用谓词，能阻止无效行进入候选；但需在候选集维护过程中实时剔除不符合条件的行。
• 后过滤：先按相似度取出 TopN，再执行过滤，可能导致最终结果不足 N 条。虽然可通过扩大 N 来补偿，但会额外增加扫描与计算开销。

Apache Doris 在 Scan 算子内通过 row bitmap 实现自然的前过滤语义。每个谓词执行后即时更新 row bitmap。当 TopN 下推到 Scan 时，向索引传递一个基于 row bitmap 的 IDSelector，仅保留满足条件的行作为候选，从源头上避免无效候选进入 TopN。

为进一步提升效率，Doris 还会在扫描前借助分区、分桶、ZoneMap 等轻量元数据进行快速预过滤，并结合倒排索引进行精确的行号定位，多层次缩小候选集，能够显著提升查询性能与资源效率。

3.2.3 全局执行优化

在传统执行路径中，Doris 会对每条 SQL 执行完整优化流程（语法解析、语义分析、RBO、CBO）。这在通用 OLAP 场景必不可少，但在搜索等简单且高度重复的查询模式中会产生明显的额外开销。为此，Doris 进行了全局执行优化，充分发挥索引、过滤等性能。

A. Prepare Statement：

Doris 4.0 扩展了 Prepare Statement，使其不仅支持点查，也适用于包含向量检索在内的所有 SQL 类型。Prepare Statement 的原理是将 SQL 编译与执行分离，模板化检索复用计划缓存，Execute 阶段跳过优化器。查询计划按“标准化 SQL + schema 版本”构建指纹进行缓存，执行阶段校验 schema version，变化则自动失效并重建。对频繁且结构相同仅参数不同的检索，Prepare 能显著降低 FE 侧 CPU 占用与排队等待。

B. Scan 并行度优化：

为提升 ANN TopN 检索性能，Doris 重构了 Scan 并行策略。原策略基于行数划分任务，在高维向量场景下，单个 Segment 的实际行数常远低于划分阈值，导致多个 Segment 被分配至同一任务中串行扫描，制约性能。

为此，Doris 改为严格按 Segment 创建 Scan Task，显著提升了索引检索阶段的并行度。由于 ANN TopN 搜索本身过滤率极高（仅返回 TopN 行），后续回表阶段即使串行执行，对整体吞吐与延迟的影响也微乎其微。

以 SIFT 1M 数据集为例，开启 optimize_index_scan_parallelism=true 后，TopN 查询耗时从 230ms 降至 50ms，效果显著。

此外，4.0 引入动态并行度调整：每轮调度前根据 Scan 线程池压力动态决定可提交的任务数；压力大则减并行、资源空闲则增并行，以在串行与高并发场景间兼顾资源利用率与调度开销。

C. TopN 全局延迟物化：

典型的 ANN TopN 查询可分为两个关键阶段：局部检索与全局归并。在局部检索阶段，Scan 算子通过索引获取每个数据分片（Segment）中的局部 TopN 近似距离；随后在全局归并阶段，由专门的排序节点对所有分片的局部结果进行合并，筛选出最终的全局 TopN。

传统执行流程存在一个显著效率问题：若查询需要返回多列或包含大字段（如长文本），在第一阶段就会读取这些列的全部数据。这不仅会引发大量磁盘 I/O，而且绝大多数被读取的行会在第二阶段的排序竞争中被淘汰，造成计算与 I/O 资源的浪费。

为此，Doris 引入了 “全局 TopN 延迟物化” 优化。该机制将非排序所需列的读取推迟到最终结果确定之后，大幅减少了不必要的 I/O。

优化执行流程示例：

以 SELECT id, l2_distance_approximate(embedding, [...]) AS dist FROM tbl ORDER BY dist LIMIT 100; 为例：

1. 局部轻量扫描：每个 Segment 利用 Ann Index Only Scan 结合虚拟列技术，仅计算出局部 Top 100 的距离值（dist）及其对应的行标识（rowid），不读取其他列。
2. 全局排序筛选：系统汇总所有 M 个 Segment 的中间结果（共 100 × M 条候选），对其进行全局排序，从而确定最终的 100 个目标 rowid。
3. 按需延迟物化：最终的 Materialize 算子根据上一步得到的 rowid，精准地到对应的存储位置读取所需列（例如 id）的数据。

通过将完整数据的“物化”步骤推迟到最后，该优化确保了查询前期仅处理轻量的距离与行标识信息，彻底避免了在排序前读取非必要列所带来的 I/O 开销，从而显著提升了整体查询效率。

4. 实战：使用 Apache Doris 搭建企业知识库

企业级知识库是 RAG 的典型落地场景。因此，我们基于 LangChain + Apache Doris 搭建了一个以 Doris 官网文档为语料的最小可用知识库，用于验证 Doris 向量检索的端到端能力。完整示例代码见 GitHub。

（1）环境准备

• LLM：用于对话与答案生成，这里使用 DeepSeek。先在官网注册并创建 API Key，妥善保存，后续用于调用 DeepSeek API。
• 嵌入模型：用于生成检索向量，这里使用 Ollama + bge-m3:latest。bge-m3 是开源的通用检索向量模型，兼顾中英文检索效果，默认输出 1024 维向量，适合知识库检索场景。

（2）建库与建表（方式一：SQL）

CREATE DATABASE doris_rag_test_db;

USE doris_rag_test_db;

CREATE TABLE doris_rag_demo (
  id int NULL,
  content text NULL,
  embedding array<float> NOT NULL,
  INDEX idx_embedding (embedding) USING ANN PROPERTIES("dim" = "1024", "ef_construction" = "40", "index_type" = "hnsw", "max_degree" = "32", "metric_type" = "inner_product")
) ENGINE=OLAP
DUPLICATE KEY(id)
DISTRIBUTED BY HASH(id) BUCKETS 1
PROPERTIES (
"replication_allocation" = "tag.location.default: 1",
"storage_medium" = "hdd",
"storage_format" = "V2",
"inverted_index_storage_format" = "V3",
"light_schema_change" = "true"
);

说明：若计划使用 SDK 一键建表与导入（见 ⑤），本节可省略。

（3）演示语料

示例使用 Apache Doris 官网文档作为语料来源：https://github.com/apache/doris-website

（4）离线文档处理

• 切块（chunking）：采用重叠分割，将长文档切分为段落片段。

from langchain_text_splitters import RecursiveCharacterTextSplitter

text_splitter = RecursiveCharacterTextSplitter(
    chunk_size=400, chunk_overlap=100, length_function=len
)
chunks = text_splitter.split_text(text)

• 生成向量（embedding）：对每个片段生成嵌入向量。

from typing import List, Dict
from langchain_community.embeddings import OllamaEmbeddings

embeddings = OllamaEmbeddings(model='bge-m3:latest', base_url='http://localhost:11434')

docs: List[Dict] = []
cur_id = 1
for chunk in chunks:
    docs.append({"id": cur_id, "content": chunk})
    cur_id += 1

contents = [d["content"] for d in docs]
vectors = embeddings.embed_documents(contents)

（5）导入 Doris（方式二：SDK 一键建表与导入）

import pandas as pd
df = pd.DataFrame(
        [
            {
                "id": d["id"],
                "content": d["content"],
                "embedding": vec,
            }
            for d, vec in zip(docs, vectors)
        ])

from doris_vector_search import DorisVectorClient, AuthOptions, IndexOptions

auth = AuthOptions(
    host='localhost',
    query_port=9030,
    http_port=8030,
    user='root',
    password='',
)

client = DorisVectorClient('doris_rag_test_db', auth_options=auth)

index_options = IndexOptions(index_type="hnsw", metric_type="inner_product")
table = client.create_table(
            'doris_rag_demo',
            df,
            index_options=index_options,
        )

说明：若已通过 ② 使用 SQL 创建好表并定义索引，可仅使用 SDK 的导入接口（如 insert/load 等，视 SDK 能力而定）将数据写入既有表。

（6）在线查询过程

向量检索

query = 'Doris 支持哪些存储模型？'
query_vec = embeddings.embed_query(query)
df = (
    table.search(query_vec)
    .limit(5)
    .select(["id", "content"])
    .to_pandas()
)

答案生成

ctx = "\n".join(f"{r['content']}" for _, r in df.iterrows())
prompt =  "以下是检索到的 Doris 文档片段：\n\n{}\n\n请根据上述内容回答：{}".format(ctx, query)

from langchain_openai import ChatOpenAI
llm = ChatOpenAI(
            model='deepseek-v3-1-terminus',
            api_key='xxxx',
            base_url='https://xxx',
            temperature=float(1.0))
resp = llm.invoke(prompt)

返回的内容是：

'根据提供的文档内容，Apache Doris 支持以下三种存储模型：\n\n1.  明细模型（Duplicate Key Model）：适用于存储事实表的明细数据。\n2.  主键模型（Unique Key Model）：保证主键的唯一性，相同主键的数据会被覆盖，从而实现行级别的数据更新。\n3.  聚合模型（Aggregate Key Model）：相同键（Key）的数值列（Value）会被自动合并，通过提前聚合来大幅提升查询性能。\n\n此外，文档在“灵活建模”部分还提到，Apache Doris 支持如宽表模型、预聚合模型、星型/雪花模型等建模方式，这些可以看作是建立在上述三种核心存储模型之上的数据组织方法。'

5. 总结

本文从 AI 时代的数据形态演进出发，系统性地介绍了 Apache Doris 在 4.x 版本中引入的向量检索能力，并对其底层实现进行了深入剖析。从 ANN 索引的能力边界，到 FE / BE 架构下的写入、构建与查询路径，再到 SIMD、压缩编码与执行引擎层面的工程优化，Doris 的向量搜索并非简单接入一个索引库，而是围绕 性能三角（召回率 / 查询延迟 / 构建吞吐） 精心设计的系统级方案。未来，我们还会进一步强化，使其成为 AI 时代数据系统智能检索的基石。

以下内容来源于DataforAI社区，作者Data for AI

当 AI 遇见数据：一场面向工程实践的技术交流

大模型并没有直接带来 AI 应用的成熟。真正决定 AI 能否规模化落地的，正在从模型本身，转移到数据、上下文与基础设施。

与此同时，数据基础设施也正经历一轮深刻演进：从传统的数据湖仓，到多模态数据管理；从 SQL 查询引擎，到面向 AI 的数据解析与治理能力。这些变化，正在重新定义我们构建 AI 应用的方式。

1 月 24 日（周六）下午 ，Data for AI 社区 将携手 ALC Beijing (Apache Local Community Beijing) 举办 Data for AI Meetup Beijing，邀请来自产业、开源社区与学术界的一线实践者，围绕 AI 时代的数据基础设施演进 展开深入交流。

本次 Meetup 汇聚了来自 字节跳动火山引擎 / Daft 社区、OceanBase社区、北京大学、Datastrato / Apache Gravitino 社区、Zilliz / Milvus 社区的技术专家，深度剖析 AI 时代数据基础设施的技术演进路径。

📍 本次 Meetup 核心看点

• 多模态数据处理引擎实践：

  Daft 在 AI 数据预处理与训练加载中的工程经验

• AI 原生元数据平台：

  Apache Gravitino 1.1.0 的关键能力与治理实践

• Agent 数据基座设计：

  记忆、检索与数据统一的工程解法

• Data-centric AI 方法论：

  面向大模型的数据准备与质量体系

• 混合检索实践：

  向量 + 全文检索在真实业务中的优化路径

• 开源探索：

  Skill 驱动的上下文工程平台化可能性

• 圆桌讨论：

  下一代面向 AI 应用的数据基础设施如何设计与落地

多模态数据处理的新范式

AI 训练对数据处理提出了全新挑战。火山引擎 AI 数据湖服务架构师 琚克俭 将分享 Daft 在多模态数据处理上的工程实践，聚焦图像、视频、文本等异构数据在统一处理、预处理与训练加载阶段的性能与架构挑战。

这一分享直面当前 AI 工程的核心痛点：传统数据引擎已难以支撑多模态 AI 工作负载，而 Daft 通过全新的架构设计，在数据预处理和训练加载环节实现了显著的性能提升。

元数据治理进入 AI 原生时代

Datastrato VP of Engineering 史少锋 将深度解析 Apache Gravitino 1.1.0 的核心升级，包括 Lance REST 支持、Generic Lakehouse Catalog、Iceberg 安全增强等关键特性。

当 AI 团队需要在多个集群间管理训练数据、推理数据和模型元数据时，传统的元数据工具往往各自为政。Apache Gravitino 1.1.0 通过统一的元数据治理架构，让跨引擎、跨存储的数据协同变得标准化、可管理，大幅降低 AI 工程中的数据协同成本。

上下文工程：Agent 落地的数据基座

OceanBase 技术专家 汤庆 将深度解析当下最热的「上下文工程」话题。他指出，企业级 Agent 面临三大核心挑战：如何让 Agent 拥有可靠的「记忆」（记忆管理）、如何让 Agent「理解」复杂文档（知识检索），以及如何统一处理向量、文本、结构化数据（数据统一）。

这三款 AI 产品的协同设计给出了答案：PowerMem 基于艾宾浩斯遗忘曲线构建智能记忆系统并支持多智能体隔离，PowerRAG 提供多引擎 OCR 与向量 + 全文的混合检索能力，seekdb 则作为 AI 原生数据库统一管理多模态数据并兼容 MySQL 生态。这套方案的核心价值在于：用数据架构的确定性，对抗 Agent 行为的不确定性。

面向大模型时代的 Data-centric AI 基础设施

北京大学助理教授 张文涛 将从学术与工程结合的视角，系统阐述 AI 从「模型为中心」到「数据为中心」的范式转变。当大模型能力趋同，数据质量正在成为决定模型性能的关键变量。

张文涛团队主导开发的 DataFlow 数据准备系统已在大模型预训练、企业知识库构建等场景得到验证。本次分享将深入解析 LLM 数据工程的完整流程：如何获取数据（爬取、解析、合成、标注），如何处理数据（过滤、改写、配比），以及如何评估数据质量。这套开源工具链与方法论，正在为 AI 开发者降低数据工程的门槛。

从向量检索到混合查询：Context Engineering 实践

Zilliz 资深解决方案架构师 刘汉卿 将系统回顾从 Prompt Engineering 到 Context Engineering 的演进路径。随着 RAG 技术从单一向量检索发展到 GraphRAG 与全文检索的混合查询阶段，检索系统已经从「找到相似内容」进化到「理解查询意图并精准召回」。

在这个演进过程中，一个关键趋势是：用向量计算代替多轮LLM推理，通过检索层的优化来提升 AI 应用的性能与稳定性。刘汉卿将结合企业知识库、推荐系统、智能助理等场景，分享混合查询的工作流搭建经验，以及在金融、医疗、法律、教育等行业的实际落地案例。

上下文工程的平台化探索

独立开源开发者 袁怿（Sam Yuan）将从前瞻视角探讨 2026 年上下文工程的技术趋势。如果说 2025 是 Agent 元年，那么随着上下文工程的快速演进，一个关键问题正在浮现：上下文能力是否应该从「各自实现」走向「横向平台化」？

袁怿将上下文工程拆解为三个维度：工具调用（空间维度）、RAG（信息密度维度）与 Memory（时间维度）。他将以最近进入 AAIF 的 Skill 机制为切入点，对比 Skill 与传统 Function Call 的本质差异，并结合他在开源社区贡献的 StructuredContextLanguage 项目，展示以渐进式加载为代表的平台化思路——让 AgentOS 像操作系统管理进程一样，统一管理上下文资源。

圆桌论坛：下一代面向 AI 应用的 Data Infra 的设计和落地

从多模态数据处理到 AI 原生元数据平台，从上下文工程到混合检索系统——本次 Meetup 的所有分享指向同一个命题：在 Agent 时代，数据不再只是「被调用的资源」，而正在成为被理解、被约束、被治理的核心能力。

越来越多团队在实践中遇到相似挑战：Agent 需要访问的数据分散在不同系统中，权限、语义与上下文边界不清；模型可以生成「看似合理」的请求，却难以保证结果的安全性与一致性。这些问题往往无法通过 Prompt 或单点优化解决。

我们特邀到前 Apple 数据与机器学习平台负责人 谭涛（Kwaai AI Lab 顾问）、Datastrato 创始人 CEO 堵俊平、北京大学助理教授 张文涛 三位圆桌嘉宾，围绕三个核心问题展开讨论：

• 意图与执行解耦：如何让 Agent 的数据请求既灵活又可控？
• 访问规则原生化：能否在系统层面保证数据访问的安全性与一致性？
• 上下文边界管理：如何让 Agent Builder 在不理解底层架构的前提下获取「该拿的数据」？

这些讨论并不立马给出最终答案，而是帮助我们勾勒下一代面向 AI 应用的数据基础设施轮廓——一个更开放、更可治理、也更适合 Agent 时代的技术底座。

活动信息

时间：

2026 年 1 月 24 日（周六）13:10 – 18:00

地点：

北京 · 原点学堂（东升大厦 A 座 10 层）（不提供线上直播）

立即报名：

👉 访问链接：https://www.huodongxing.com/event/3843480320400

⚠ 名额有限，需审核通过（请详实填写报名信息，并通过主理人的微信添加请求，确认审核状态）

这是一场面向 AI & Data 工程实践者的技术深度交流。

无论你是正在构建企业级 Agent 系统的架构师，

还是关注 Data-centric AI 的研发工程师，

都能在这里找到有价值的技术洞察和落地经验。

Community Over Code，期待与你在北京相聚。

阅读更多 Voice Agent 学习笔记：了解最懂 AI 语音的头脑都在思考什么

​