最近参与的向量数据的技术分析项目什么的基本告一段落了,简单总结一下,在Edge侧实现向量数据的应用场景以及一些问题挑战。

背景

问题:

  • 手机上需要不需要一个向量数据?
  • 如果需要,需要什么样的数据库?支持哪些算法,有哪些约束?

是不是需要?

对于第一个问题显然是成立的。近年来各大手机手机厂商在AI能力上的探索越来越深入,AI算法所涉及的业务范围也从最开始的camera场景的计算摄影逐渐扩散到更多的业务。从技术上讲主要有下面几个场景:

  • 多模态搜索
  • LLM大模型

多模搜索

多模搜索(图文搜索)业务源于CLIP模型提出和发展。CLIP模型如何去做的,这里就不展开了。通过CLIP模型,可以把图片和文本在同一语义空间内对齐,这就使得通过描述搜图变成可能了。相较于原始的基于Tag搜索,就极大地增强了可能性。

这里扩展一下,目前看起来,文档搜索反而在多模搜索以后得到应用,就有点奇奇怪怪了。

考虑到未来算法演进,以及手机侧信息的数字化管理的需求,后面肯定是更多模态数据可以相互搜索。向量数据库在其中肯定也要发挥更大的作用。

LLM大模型

LLM模型大热,确实吸引了不少人的注意力。但是如果仅仅只能在云测跑,受限于隐私安全的考虑,个性化的需求就很难满足,而模型又很难在本地通过训练来更新知识信息。这就引入了端侧RAG框架的需求。根据当前RAG的技术演进程度来看,向量检索是Retriaval阶段必不可少的一环,特别是未来LLM到LMM演进上,更是如此。因为传统数据库并不是为了多模态数据设计的。

至于其他场景,以后遇到再补充了。

需要什么样的向量数据库

手机侧不同于云侧,有下面的几个特点。

  • ROM空间有限且珍贵,哪个应用(小而美)用着用着占用越来愈大了还容易引发舆情信息
  • RAM空间就更金贵了,不能随便说只服务你一个业务就可以
  • 功耗电量消耗也是需要考虑的
  • 还有上面业务场景决定,召回率、准确度的要求也是越高越好
  • 删改实时性有要求,不能一直不加、也不能一直不删

简单说就是:资源要节省、准确度要高、时延倒是重要但没那么重要的部分了

算法怎么选

  • 从上面的约束可以看出,云侧用的多的NSW、HNSW等基于图的算法就不是很能满足要求了,构建、删除成本高、内存占用大。
  • PQ这类量化算法内存占用虽然低了,如果bit数选取太低了,掉点严重,能不用尽量别用
  • LSH、kNN-Tree这些,效果也不咋地
  • IVF-算法,牺牲一点时间,降低计算量和内存。可以考虑
  • NN降维、PCA降维等算法,可以考虑组合使用。

理论上来说,这里量化策略选择接近与NN模型的量化,底库向量等价于权重。但是还没有实验验证了。

向量数据库计算

既然需要了,那就可以来实现一个向量数据库了。下面就看下,向量数据计算的特点吧。

检索

传统意义上来看,检索就是一个向量和一个矩阵做一个相似度计算。是一个sgemv 的计算过程。属于一种计算密度比较低的计算场景,适合vector计算单元发挥作用。

在LLM交互的场景结果略有不同,从用户对话的角度来看,很多时候用户一次的问题是片面的,仅仅凭借这一个query向量,召回的相关信息不不太足的。这就涉及到了query rewrite,经过rewrite以后就成了一个multi-query 场景了,这样计算密度就大大增加。变成一个比较适合NPU计算的场景了。

这里参考一下,langchain 的MultiQueryRetriever

构建

这里把构建过程单独拿出来说,主要是构建算法会涉及到k-means聚类,这时候参与计算的向量就多了,计算密度也大了。

降维

降维算法包括非NN类的,比如SVD、PCA这种,也有NN类的,比如VAE这类。

向量计算库 需要什么样的ASIC

  • 上面可以看出来,当前大多数调用频繁的场景来看,实际的计算密度并不高,gemv的计算走CPU的neon也足够了,只有在大计算量的情况下,走专用的计算单元才有优势。
  • 不可否认的一点就是,专用计算单元在能效是有优势的
  • 如果从计算时延上来,Android系统架构下,必须ION内存;从CPU到专用的计算单元之间也会引入额外的时延开销;这就要求走ASIC的话,需要在这中间做好文章,才好有优势