最近公司里，向量数据库的需求越来越多。前几天请aws的诸位专家一起来开会讨论了一下，学到了不少知识。以下是我的心得和收获，仅代表我个人观点：
1. 知识库，图片识别，图片或视频近似度搜索，电商推荐等是很多公司的应用场景。
2. 向量计算，这其实每个数据库都可以拥有这个功能，向量近似度计算的方法：余弦夹角，欧几里得距离，内积等等……知道了向量近似度算法，那么凡是数据库都可以根据算法写自己的实现过程，操作函数。
3. 向量适合“语义模糊”的近似度检索，虽然左右两个百分号是模糊检索，但他其实还是精准检索，比如like ‘%深圳%’看上去是模糊检索，但是它还是需要精确匹配“深圳”关键字，它没办法搜索出来“当年在香港旁边画了一个圈的小渔村”。语义的近似查找，是向量数据库的主战场。
4. 向量数据库，离开了模型是没有意义的。离开了模型，向量数据库中存在的只是一堆无意义的多维数组（但是最近有安全方面的论文说可以实现逆向工程）。模型+向量数据库，才是向量数据的生命周期。另外，更新了模型，原来存放的向量数据可能也没有意义了。
5. 模型对原始数据的spliting，embedding，非常重要。常见模型有aws泰坦模型，Claude模型，stable diffusion模型，等等。
6. RAG中的LLM如果数据不完善，可以通过外部多模数据的embedding，存入到向量数据库中进行修正输出结果。也就是说我们可以对模型进行微调。
7. 有没有必要引入一个“专属”的向量数据库。我觉得在规模还没达到一定的程度下（上千维度，上百TB数据），没必要引入。因为：
（1）向量计算，本来就是一种计算，知道了向量近似度的算法，我算盘都能算出来，只是效率上的差异。所以没必要在运维人力和运维能力的矛盾中，增加难度。
（2）你可能会认为专门一件事情，会比较高效，传统数据库比较“重”，专属数据库比较“轻”，Oracle支持in memory option，还是打不过redis，Oracle支持json，还是打不过Mongodb，但是redis和mongodb不仅仅是“轻”，而且架构还简单，只有数据库组件，所以才能和传统数据库的竞争中能占有一席之地，但专属的向量数据库里面的组件非常多（虽然可以写好yaml通过k8s部署，但是出问题时的诊断链路会很长）。这个意义上来说，专属向量数据库不“轻”。
（3）数据库不仅仅是存放数据，还有高可用，监控，备份，升级，迁移，安全，审计，可观测性等等方面，目前还没看到专属向量数据库，特别是开源的专属向量数据库在这方面做的很好。
（4）大模型只是通用型的，无法获取到最新最近的数据，也获取不到私域流量的数据。因此RAG时所以要加向量数据库，来进行微调。而目前一些专属向量数据库，走的路线是cloud native，如果获取私域流量数据会是个问题。
（5）传统数据库加向量插件，不仅仅可以进行向量近似度的计算，还能查询常规数据，做到数据在同一个实例中处理，不出库，提高效率。阿里云的lindorm的介绍中，也有提到这个优势。数据不出库，混合处理。
（6）专属向量数据库，利用GPU进行高并发的计算，这个确实是优势，但是传统数据库也不是说不行，比如pg-storm。
（7）OpenAI已经把上下文长度的限制，从4k增加到128k，另外，推出了他们的Assistants，官方亲自下场做RAG，那么是否还要考虑专属的向量数据库？
当然，并不是说专属向量数据库没有未来，相反，我还是非常看好在经历了cloud native之后的ai native时代，专属向量数据库在大规模数据下的应用场景。我只是说，基于目前的现状，我倾向用传统数据库加向量插件。pg+pgvector（支持最多1.6万向量维度，和支持2000向量维度的索引），elasticsearch 8（支持k-nn检索和ELSER），基本能解决大部分的场景了。
ps：本文完成于公司地下停车场。对于技术的执着，让我有点停不下来，在手机上完成了此文。
参考文档：
【大模型带火的下一个风口：向量数据库】
【技术分享｜浅谈向量数据库】
【人工智能】万字通俗讲解向量数据库
【上集】向量数据库技术鉴赏】
【下集】向量数据库技术鉴赏】