veDB-Search 实战:多路召回,文搜万物

veDB MySQL 版是火山引擎自研的云原生关系型数据库产品,100% 兼容原生 MySQL。而 veDB-Search,则是基于 veDB MySQL 版的技术底座,拓展出的一站式混合检索的全新服务:用户仅使用 SQL ,即可完成对向量+全文+标量数据的存储和混合检索。
更多详细内容可阅读综述篇:veDB-Search:AI 混合检索,懂 SQL 就行
本文为实战篇,首先介绍业务如何基于 veDB-Search 使用一条 SQL 高效解决真实场景的多路召回问题,解锁更多功能以解决业务痛点。然后介绍内置的 In-DB Embedding 功能,体现将向量嵌入逻辑从业务侧全透明下沉到数据库内的优势。最后以电商业务案例演示 veDB-Search 如何支持文搜万物。
多路召回:一条 SQL 完成多路向量+文本+标量召回
传统多路召回的架构之痛
架构复杂: 需要同时维护向量数据库、全文搜索引擎(如 ES)和关系型数据库。且向量数据库内不止维护一路 embedding。
数据同步: 需构建复杂的 ETL 或 CDC 链路保证数据一致性。
业务逻辑沉重: 业务层需要分别调用不同系统的 SDK,进行结果召回、聚合、去重和排序,代码复杂,维护难度大。
veDB-Search 的破局之道
一条 SQL 实现多路召回
多路召回的执行流程
解析标准 SQL
优化器自动选择最优索引,生成最优计划
调度器将各路检索下推到向量索引上执行过滤
根据权重进行分数融合与排序
返回最终结果集
veDB-Search 核心优势
开发提效: 将复杂的多系统交互代码简化为一条 SQL 语句。
运维减负: 只需维护一个 veDB 实例,无需关心数据同步。
性能保障: 内置优化器选择最优执行路径,分布式架构保障性能。
三路召回实战示例
下面以电商场景为例,演示如何使用 veDB-Search,通过一条 SQL 语句来高效完成多路向量召回+条件过滤。
【STEP 1】在
products表上创建包含多个向量列的混合索引
【STEP 2】一条 SQL 语句完成三路向量召回+文本检索+标量过滤
解锁更多高阶功能
过滤条件
veDB-Search 支持使用标准 SQL 的 WHERE 语法,在召回时进行精准过滤。用户只需要按业务需求编写各种过滤条件,veDB-Search 会自动优化以选择 per-filter/post-filter 策略。在极端情况下,如果标量过滤性极强,优化器会采用 KNN 暴搜反而带来更优的执行效果。用户可按标准 SQL 进行复杂过滤,例如:
文本匹配
veDB-Search 支持使用增强的 MATCH AGAINST 语法,支持布尔查询、短语查询、模糊查询等。veDB-Search 会对目标列构建倒排索引,实时更新新写入的数据,支持与其它过滤条件混合使用。例如:
倒数排序融合(RRF)
veDB-Search 支持对多路召回结果进行加权,既能确保标量和全文检索的精确性,同时也能保障向量搜索的语义理解能力。
RRF 计算公式:
RRF_score = (1 / (k + 在列表1中的排名)) + (1 / (k + 在列表2中的排名)) + ...rank_i:文档在第 i 个搜索结果列表中的位置(第 1 名,第 2 名...)。k:一个可调节的常数,通常 >= 60,用于控制排名的影响程度。
例如:
RRF 对多路召回结果加权具有重要实际作用,如平衡不同召回路径的优势,提高结果相关性,提供统一排序标准。
如果用户不想使用 RRF,或是想获取具体 score 值,可以使用 veDB-Search 提供的 similarity 函数,此函数返回已经范式化的 score 值,可直接参与 ORDER BY 排序。
距离或相似度过滤
veDB-Search 支持指定最大距离,在搜素过程中过滤掉相似度不高(距离远)的数据点,以进一步提高精确率。
In-DB Embedding:支持端到端“文搜万物”
前面介绍了如何使用单条 SQL 语句高效实现多路召回。在本章节,我们将探讨另一个高阶功能 —— In-DB Embedding,即将向量嵌入过程从业务侧全透明地下沉至 veDB-Search 内。最后以电商业务为例,演示 veDB-Search 如何支持“文搜万物”能力。
veDB-Search 支持两种 In-DB Embedding 功能:
提供
to_embedding()函数,用户直接调用,即可对传入的文本/图像生成 embedding支持
embedding_pipeline()函数,在混合索引中设置,即可透明地完成从原始数据到 embedding 的隐式转换,无需用户显式调用上述功能的特点,以及适用场景如下:
to_embedding()函数
功能定位:将文本、图像等数据转换为 embedding,以支持跨模态向量检索。
技术实现
文本向量化:支持无缝对接火山方舟提供的模型(如
Doubao-embedding-large),将商品标题、描述等转换为 embedding。图像向量化:支持无缝对接火山方舟提供的模型(如
Doubao-embedding-vision),将商品主图 URL 转换为 embedding。
函数签名
to_embedding('model_id', 'model_key', 'user_input','model_type')
model_id:火山方舟模型 IDmodel_key:火山方舟模型密钥user_input:用户需要生成 embedding 的原始数据(文本/图片 URL)model_type:支持三种取值 content:文本类模型,适配原始数据为文本的场景 image:多模模型,适配原始数据为图片 URL 的场景 text:多模模型,适配原始数据为文本的场景
使用示例
在 veDB-Search 中创建一张document_asset表,通过调用to_embedding()函数将原始文本数据转换为 4096 维的 embedding,存入 VECTOR 列。然后根据用户提出的问题,基于该向量列进行 topk 相似性检索,最终给用户召回内容贴切的帮助文档。
embedding_pipeline函数
功能定位
透明易用:在表上建索引时,为索引设置 embedding_pipeline,即可对文本/图像 URL 列的数据在底层引擎自动生成 embedding 并写入索引结构。
成本友好:在 veDB 表上不存储具体的 embedding 数据,仅存储原始数据(文本/图像 URL),大大降低了存储成本。
函数签名
embedding_pipeline('user_input','model_type')
user_input:用户需要生成 embedding 的原始数据(文本/图片 URL)model_type:支持三种取值 content:文本类模型,适配原始数据为文本的场景 image:多模模型,适配原始数据为图片 URL 的场景 text:多模模型,适配原始数据为文本的场景
使用示例
电商选品实战案例
【Case 1】以文搜图:文本描述匹配商品图像
场景需求:用户输入文本“三合一冲锋衣”,需要召回与文本描述相似的商品。
实现步骤
创建商品表和混合索引:索引指定 emb_pipeline,设置多模态 embedding 模型
数据写入:将产品图片 URL 和其他商品元数据信息写入 veDB-Search 中的商品表
结果过滤:结合销量、价格等标量条件,根据用户的输入信息筛选优质商品
SQL 示例
【Case 2】以图搜图:根据用户购物车的内容,进行相似产品的推荐
场景需求:用户上传一张商品图,结合其他商品元数据信息,返回平台内同款或相似商品。
实现步骤:
创建商品表和混合索引:索引指定 emb_pipeline,设置多模态 embedding 模型
数据写入:将产品图片 URL 和其他商品元数据信息写入 veDB-Search 中的商品表
结果排序:按图片相似度、销量、价格综合排序。
SQL 示例:
最佳实践技巧
veDB-Search 通过一条 SQL 实现多路召回和 In-DB Embedding 两大能力,直接支撑了业务“文搜万物”的需求,同时大幅降低开发复杂性和运维成本。
更多技巧:
路径设计:根据业务核心维度(如商品图、描述、标签)设计召回路径。
权重调优:通过 A/B Test 持续调整多路召回 SQL 语句中各路的权重分数,以优化召回效果。
索引优化:创建混合索引,把 embedding 列和常用的标量列都包含在索引内。且在大数据规模下,利用 veDB 的云原生能力实现弹性扩缩容。
veDB-Search 正将数据库从被动的“数据容器”转变为主动的“认知引擎”,是构建下一代 AI 应用的关键基础设施。
基于 veDB MySQL 版的强大技术底座,veDB-Search 混合检索功能在火山引擎目前已支持开通测试白名单,欢迎点击【阅读原文】提交工单参与试用。







评论