当前位置：首页 > news >正文

Milvus×OPPO：如何构建更懂你的大模型助手

news 来源：原创 2025/5/9 14:11:14

01.

背景

AI业务快速增长下传统关系型数据库无法满足需求。

2024年恰逢OPPO品牌20周年，OPPO也宣布正式进入AI手机的时代。超千万用户开始通过例如通话摘要、新小布助手、小布照相馆等搭载在OPPO手机上的应用体验AI能力。

与传统的应用不同的是，在AI驱动的应用中，数据库面临的数据处理需求已经发生了根本性的变化。高维数据（如图像、文本和音频）的快速积累和使用场景的多样性，要求数据库不仅需要存储海量数据，还需要可以高效地进行复杂的数据检索。然而，传统关系型数据库由于其设计初衷是为结构化数据服务，因此在处理非结构化和高维数据时，逐渐暴露出其局限性。这直接导致它们在应对现代AI业务需求方面显得捉襟见肘，难以满足实时数据写入、大规模并发查询以及快速相似性搜索等要求。

02.

万物皆可Embedding

非结构化数据的种类和使用场景复杂，几乎无法定义，让计算机程序理解都非常困难，更不用说数据库了。为了能够统一处理和表达非结构化数据，业界通用的方法是使用Embedding。Embedding 是一种将高维稀疏数据转换为低维稠密向量的技术，广泛应用于自然语言处理（NLP）、图像处理、推荐系统等领域。通过 Embedding，复杂的输入数据可以被编码成固定长度的向量，使得这些数据可以在向量空间中进行高效计算和处理。

在Embedding的基础上，由非结构化数据引入的挑战演变为了如何对向量数据进行存储和检索的问题。

03.

OPPO对向量检索的探索

在业务初期，由于数据量较小、使用场景较为简单，数据存储使用本地文件，数据检索就是把全量数据加载在内存中完成。配合上HNSW, Faiss等开源库，可以很好解决问题。

但是当业务开始快速增长，上面这一条玩法很快就出现了问题：

数据容量：单个服务节点的内存无法承载全量向量数据；
查询性能：单机性能无法满足查询需求；
数据持久化：数据从加载到内存，直到生命周期结束后释放，没有被很好的持久化；
文件管理：数据、索引等文件难以被统一管理。

很自然的，向量检索开始从单机向分布式的方向进行演进，根据上面的问题提出的解决方法就是：

数据分片：对向量数据根据某一规则切分后加载在不同的节点上；
服务发现：能够对整个集群内的节点、数据进行统一管理。

基于上述思想，OPPO提出并实践了一套分布式向量检索服务：

整个系统在简化后可以被分为Master和ShardServer两个部分：其中Master负责整个集群的元数据管理和调度管理，存放集群的数据分布信息和整体的路由结构信息等；ShardServer负责具体的向量数据存储和检索服务。

节点管理：Master本身是一个至少3节点的高可用组件，集群中的其他节点会向Master进行服务注册，由Master进行节点的管理；
数据分片：数据分片在系统中是一个Shard的逻辑概念，其中每个Shard中会包含该数据分片的向量数据、标量数据等，其底层使用RocksDB进行数据持久化，并且通过Raft Group实现每个Shard的高可用。ShardServer是物理上承载Shard的角色，每个ShardServer会保存若干个Shard，不同的ShardServer之间完成Raft Group的数据交换。

04.

Why Milvus?

上述的分布式向量检索实际上已经把向量检索这一功能服务化了，但是这个系统中还是存在一些不足，例如数据和节点绑定在了一起，虽然对数据做了分片但是对集群的扩展不是那么丝滑。另外，对于向量检索结果的合并、检索过程中的失败处理等都是非常棘手的问题，所以，OPPO决定引入更加稳定的开源解决方案 — Milvus。

在对向量数据库做选型的时候，我们考虑的主要的点是：