veDB-Search：AI 混合检索，懂 SQL 就行

1. AI 混合检索：困难与复杂性

混合检索，在当前的 AI 应用中极其关键。在部分 AI Agent 场景中，开发者需要同时开发向量召回（图片相似度匹配）、全文检索（文字内容匹配）、标量过滤/聚合功能（条件约束），才能满足业务层丰富的检索需求。

例如，在电商场景，一个负责商品选品的 AI Agent 需要对商品做多路混合检索：

“帮我找出 SKU 首图跟这双运动鞋类似、最近 7 天销量不为零、商家提交过资质证书、用途是户外登山溯溪、材料速干透气、支持的最大尺码至少 47 码的商品。最后按商品 id 聚合平均售价，结果显示前 50。”

在上述例子的场景中，应用开发者如果基于传统数据基础设施进行开发，往往会遇到很多开发难点。同时，传统方案中复杂的系统架构还会带来更长远的问题和挑战。据观察，主要的困难与复杂性包括：

1. 【业务复杂性】组合使用多个不同系统，需要使用不同的 SDK 与查询语言。从各系统独立完成向量召回、全文检索、标量过滤/聚合后，需要业务层编写跨系统回表与聚合计算逻辑，大幅增加业务层代码的复杂性。

2. 【运维复杂性】需要部署多个独立系统，且系统间需要构建数据同步链路（DTS/ETL），组件数多带来了高部署成本，较重的运维负担，还有较低的问题定位效率。

针对混合检索的刚需场景，火山引擎 veDB MySQL 版作为火山引擎的核心数据基础设施，推出了 veDB-Search 服务，一站式满足用户的混合数据管理 & 检索。veDB-Search 的核心能力，可助力开发者在实现向量 + 全文 + 标量多路混合检索时开发提效、运维减负。

2. veDB-Search：SQL is Everything

veDB MySQL 版是火山引擎自研的云原生关系型数据库产品，100% 兼容原生 MySQL。

而 veDB-Search，则是基于 veDB MySQL 版的技术底座，拓展出的一站式混合检索的全新服务：用户仅使用 SQL，即可完成对向量 + 全文 + 标量数据的存储和混合检索。

其核心优势包括：

① 插拔式服务按需开启，透明智能索引加速

• veDB MySQL 版存量用户，插拔式按需开启混合检索功能

• 兼容标准 SQL，存量业务无需变更，新业务可使用扩展语法完成混合检索

• 自动识别混合索引，自动优化查询路径，加速混合检索

② 10 亿级规模，支持多种主流算法，分布式并行检索

• 云原生分布式架构，秒级扩展只读能力，轻松管理 10 亿级数据

• 支持多种 SOTA 索引、量化、检索算法，以支持不同业务场景的检索需求

• 支持前台高并发读写，分布式处理支撑高吞吐的混合检索

③ 企业级能力，高性价比，高可用

• 内置毫秒级的索引 CDC 功能，索引下推后秒级构建，省去额外配置 ETL 的成本

• 亿级规模下，0.95 召回率，毫秒级的 P99 召回时延

• 完善的服务监控告警，支持负载均衡、高可用故障切换

3. 字节跳动实战案例：AIGC 混合检索

veDB MySQL 版在字节跳动集团内多个大流量关键业务，以及火山引擎上多个行业经典场景都久经考验，为所有企业客户提供安全可靠、性能优越、功能丰富的数据库服务。

在此基础上，veDB-Search 也支持了很多复杂混合查询的场景。在本节，我们将通过一个字节跳动内部的实战案例，直接体现 veDB-Search 在混合检索场景的业务价值。

以下是一个真实的 AIGC 资产管理的业务场景。业务会对同一份数字资产实现多维度的 embedding，在检索时要对多个维度做 topk 相似召回，再结合部分元数据（图片 tag、权重等）过滤得到最终结果。整体业务数据规模千万级，日增数据十万级。其技术架构非常经典，需要组合多个不同的存储系统 & 数据库，再辅以业务层的复杂计算逻辑来完成混合检索。

AIGC 资产管理业务的数据链路

在上述架构中，业务侧遇到的实际问题有：

1. 组件过多，数据链路长，运维负担重

2. 跨向量存储 & 元数据存储的多个组件做混合检索，需要在业务层接入多个 SDK，并开发复杂的回表、过滤、聚合代码，大幅增加业务复杂度。

为了解决这些问题，我们在此数据链路上采用 veDB-Search 的解决方案，在一张数据表上同时管理多个向量列 & 标量列，一站式地支持业务管理元数据、数据底表、特征向量，并支持使用一条 SQL 语句召回多路向量 + 标量过滤、聚合。veDB-Search 方案对于业务的价值有：

1. 业务从管理至少三套系统（k-v 存储 + rds + 向量存储），到只管理 veDB-Search 一套系统，架构复杂度下降，减少 2/3 的运维成本。

2. 业务层不需要接入多个 SDK，也不需要在业务代码里编写复杂的回表、过滤、聚合代码。SQL is Everything，简化了业务层复杂度，为开发提效，同时也增加了代码的可维护性。

在混合检索的实战案例外，下面我们将介绍如何基于 veDB-Search 的混合检索能力为 AI Agent 构建 RAG 模块。

4. AI Agent RAG 接入示例

随着在线系统的规模扩大，必然会出现越来越多的运维工作。而运维工作宏观上可以分为：

1. 【日常运维】有计划发起的高频低风险运维项，例如版本升级、机器扩缩容、故障机器替换等；

2. 【紧急运维】由紧急告警触发的突发运维项，例如瞬时机房大面积断电需要流量切换；

对于紧急运维场景，要求的是：操作精准、迅速止损。且对于突发的问题，原因大概率无法提前预知，无法被 SOP 覆盖。所以紧急运维事件并不是很适合使用 LLM + AI Agent + RAG 的方案来规模化提效。

因此，我们可尝试在日常运维场景（可预知、可规划、SOP 较全的场景）落地 Devops AI Agent，结合 SOP RAG 提高准确率，为日常运维提效。

基于传统架构，要实现 SOP RAG 需要多个系统各完成一部分的检索需求（SOP 图片相似度、SOP 文本内容匹配、SOP 文档元数据过滤），最终再由业务层逻辑做聚合。现在使用 veDB-Search，只需一条 SQL 即可完成混合检索。

第一步：数据预处理。需将原始富文本类型的 SOP（如飞书文档、markdown 文档）转换为切分好的段落。

第二步：写入数据库

/* 建表，包含SOP文档元数据、图片embedding、文字内容 *//* 同时创建混合索引，包括content_emb, content, img_emb, censored列 */CREATE TABLE devops_sop( id          INT NOT NULL AUTO_INCREMENT, content     TEXT NOT NULL, content_emb VECTOR(1024) NOT NULL, img_url     TEXT NOT NULL, img_emb     VECTOR(1024) NOT NULL, censored    TINYINT NOT NULL, env         ENUM('cn-north', 'cn-south', 'cn-east', 'cn-west', 'others'), ANN KEY sop_hybrid_idx (content_emb, content, img_emb)  SECONDARY_ENGINE_ATTRIBUTE = '{"distance": "cosine", "scalar_fields": "censored"}');  /* 写入SOP数据 */INSERT INTO devops_sop(content, content_emb, img_url, img_emb, censored, env)VALUES ("线上扩容教程，首先说明各运维动作前后所必须的检查逻辑，包括...",         TO_VECTOR('[0.1, 0.2, ...]'), "http://img1", TO_VECTOR('[0.05, 0.06, ...]'), 1,         'cn-north');

第三步：混合检索，多路召回目标内容。例如：“找到适用于华北机房环境，xx 型号机器缩容的步骤。教程需要经过 review 审核，且步骤中包含请求图里的操作平台界面。需要最相关的前 10 个结果。”

SELECT content from devops_sopWHERE env = 'cn-north' AND censored = 1 AND MATCH(content) AGAINST ('xx硬件型号缩容')ORDER BY COSINE_DISTANCE(img_emb, TO_VECTOR('[0.1, 0.3, 0.02, ...]'))LIMIT 10;

上述 RAG 实战案例介绍了如何在 veDB-Search 中仅使用一条 SQL 完成较复杂的混合检索。基于 veDB-Search，开发者只需定义好知识表的 schema 结构，创建混合索引，写入知识库数据。在检索过程中的索引下推、混合查询加速，由 veDB-Search 透明完成。对于开发者，SQL is Everything，真正为开发提效，运维减负。

veDB-Search 在实战案例中展现的混合索引与检索能力，其技术架构将在下面一节展开介绍。

5. 技术架构：智能索引加速

veDB-Search 能够支撑高效的多路混合检索，其核心技术是混合索引与深度优化的查询引擎。在索引实现上，veDB-Search 实现了新的混合二级索引类型，并打通了火山引擎 Cloud Search，将向量与全文索引透明下推。

• 创建索引

veDB MySQL 版 100% 兼容原生 MySQL，支持原生的所有二级索引类型。veDB-Search 在原生的二级索引类型之外，新增 ANN 混合索引类型，支持向量列 & 全文列下推至火山引擎 Cloud Search。

• 在 Cloud Search 侧，对于向量数据，默认使用自研 DiskANN 索引 + RabitQ 量化算法；对于全文数据，支持分布式的倒排索引。

• 在 veDB 侧，标量列仍然以 B+ 树结构组织索引。

用户可以根据业务的高频查询场景，对数据表上的向量列、全文列、标量列创建 ANN 混合索引。单个 ANN 混合索引可包含纯向量列、纯文本列，或向量 + 文本 + 标量多列。

• 索引透明同步

用户在数据表上创建了 ANN 混合索引后，对应列的数据会由 veDB 全透明地同步到 Cloud Search，用户无感。体验如同使用普通的 B+ 树索引一样，用户无需感知一行数据如何插入多株 B+ 树构成索引。

veDB-Search 支持索引透明同步的技术核心是透明内置的 binlog CDC。应用程序通过 SQL 对数据写、改、删的同时，会产生对应的 binlog。veDB 内部实现了 CDP 模块，其核心功能包括：

1. 在线同步，捕获数据变化，根据系统 LSN 顺序转化为 Cloud Search DSL bulk 写入远端 Cloud Search。

2. 元数据管理，将流式同步的位点在后台定期持久化为实例元数据，从而支持 Crash Recovery 在混合检索的传统架构中，binlog CDC 也是必要的流程。开发者往往需要自行构建基于 binlog 的 DTS/ETL 链路，将 binlog CDC 的数据导入向量存储（embedding 后）、搜索引擎。由此可见，veDB-Search 的索引透明同步可以给用户带来开发减负与运维减负的显著价值。

• 索引扫描与加速

在查询链路上，veDB-Search 支持一条 SQL 完成向量 + 全文 + 标量的混合检索，技术要点在于智能选择检索路径 & 远端高性能索引加速召回。

优化器路径选择，veDB-Search 支持三大类检索路径：

1. Pre-filter：如果当前查询同时带有标量过滤条件 + 向量 topk 召回，且对应的标量列 selectivity 很高，意味着可以走 B+ 树索引筛选掉绝大部分的数据行。这种情况下可以先执行标量过滤，再基于标量过滤的少量结果去执行向量的 KNN 召回，在保证极高召回率的同时，检索速度也很快。

2. Post-filter：相反，如果标量列 selectivity 较差，需要先走远端 Cloud Search 的 DiskANN 索引，召回相似向量对应的 primary key。然后再在标量列的 B+ 树索引上执行过滤，得到最终目标 primary key set，再回表得到投影列。当然，post-filter 在实战中最大的问题是读放大，因为极端情况下可能经过标量过滤后，通过向量相似度得到的 primary key set 被置空，需要循环且放大 topk 向量召回请求。

3. 全下推（KNN-Filtered Query）：如果混合索引中包含了少数标量列，且标量列数据天然有序，可以考虑将标量列也下推至远端 Cloud Search 进行索引。在这种情况下，涉及标量 + 向量的混合检索，就可以全量转化为 Cloud Search 的 KNN-Filtered Query，直接全下推召回，得到最终目标 primary key set，再回表得到投影列。

6. AI 生态：开放集成、无缝接入

目前，veDB-Search 支持 LangChain 和 Eino 框架无缝对接。开发者使用 AI Agent 框架开发应用时，可以直接将 veDB-Search 作为标准 VectorStore 组件使用。未来，veDB-Search 在 AI 生态方面， 会持续实现：

1. 接入更多 AI 开发框架 & 工具，致力于简化 AI 应用开发流程，降低上线运维负担。

2. 打通火山引擎模型能力、其他标准开源模型能力，让 AI 赋能数据库功能（如：在线多模透明 embedding、in-DB 自然语言数据分析），把数据库从数据容器打造为新一代的认知引擎。

关于产品

veDB MySQL 版是字节跳动自研的基于计存分离架构的云原生分布式数据库，100% 兼容 MySQL 5.7、MySQL 8.0。支持一主多备部署，具备高弹性、高并发、高可用的企业级数据库能力，历经字节跳动内部业务与外部的丰富场景与海量流量打磨。在字节跳动内部，veDB MySQL 在关系型数据库领域占比超过 70%，总实例数 10 万级，数据量百 PB 级，支撑所有业务线（抖音/电商/财经/广告/番茄小说/懂车帝/豆包/飞书等），覆盖全球 7 个服务区。在春晚红包雨活动中，全国一共发起了 703 亿次红包雨互动，veDB MySQL 集群承接读写 QPS 峰值超过 800 万。

基于 veDB MySQL 版的强大技术底座，veDB-Search 混合检索功能在火山引擎目前已支持开通测试白名单，欢迎提交工单参与试用。