最近参与的向量数据的技术分析项目什么的基本告一段落了，简单总结一下，在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的话，需要在这中间做好文章，才好有优势