为何要用向量数据库？成本，成本，成本！
01
全量存储成本
向量数据库搜索的一大特点是相似性匹配，而不是精确匹配。
以文本搜索引擎为例，向量数据库可以支持语义关联的搜索，但文本搜索引擎只能支持精确匹配的文本搜索。也就是说，文本搜索引擎只能用“树袋熊”关键字搜索到“树袋熊在树上爬”，却不能用“澳大利亚的动物”关联到这句话，而向量数据库就能够做到。
因为，在向量数据库用来表示词汇的数学空间也就是向量空间里，“澳大利亚的动物”和“树袋熊在树上爬”是在距离上很接近的两个点。
文本搜索引擎要实现这一点，理论上需要无限庞大的数据库，存储世界上所有可能的文本，才能保证“树袋熊”能关联到“树袋熊在树上爬”。换言之，传统文本搜索引擎的信息存储是全量的，而向量数据库的信息存储是压缩的，知识即信息压缩，向量数据库拥有知识。
用全量信息还是知识来引导搜索，其成本比较非常明显。
02
专业学习成本
在大模型生成应用中，为了保证生成效果，prompt的正确性、表述专业性常常是一大关键。为此，可以利用向量数据库，将表述一般的prompt输入向量数据库，查询出语义相近、表述正确的prompt，再将新的prompt输入大模型进行推理，就能大大提高生成效果，此即RAG（检索增强生成）。
这相当于将向量数据库作为知识查询库使用，省去了大量的专业知识学习成本，通常用在比情感分析、命名实体识别更复杂的知识密集型任务。
03
规模化成本
向量那么好用，看起来使用方式也没那么复杂，为何一定要使用向量数据库呢？平时存在一个已有的数据库里，甚至放在excel里，建个索引，设置一个匹配算法，是不是就可以了？
原则上，这种做法没有错误，比如一些技术研发就曾表示用大模型开发应用不需要向量数据库，只需要用Python库中的np.array就可以了。
然而，一旦向量数量达到了一定规模，索引规模和检索计算量就会爆炸性增长。
检索是通过建立被检索对象之间的某种局部关联实现的，比如字典的按字母顺序的目录，字母不能代表其中的词汇的语义，只是一种局部关联。
但向量之间存在的是语义关联，这些语义关联还不能很好地分解为更简单的基本组成。
原则上，任何向量之间都潜在地存在一些或大或小的语义关联，可以通过任何一个向量关联到其它任何向量，来实现相似性检索。为向量建立索引的方式，必须和其完整语义相关，而不是像传统数据库那样只需要关注主键等语义简单的变量就行。
所以，这些向量潜在地存在全连接的可能，如果是这样，连接数将是指数级增长的。为提高检索速度，就必须在向量空间中采用能简化向量关联路径的算法。
在这种限制下，检索速度、准确率变得无法兼顾。
为了精准表示对象，向量数据一般维度很高，以聚类算法为例，随着向量维度的增长，向量距离计算急剧增长，导致需要维持的聚类中心的数量呈指数级增长。这些算法不可能依靠表达能力很有限的传统数据库索引结构来实现。即便能够实现，计算的成本差异也是极大的。
而且，如今各种数据的数据量动辄千亿量级，数据量会使得向量连接数指数级增长。
在这个条件下，一味追求精确度只会使得检索速度越来越低。为此需要采用多种加速算法来提速。
针对维度灾难问题，一般采用将高维空间拆分为子空间的方式，这其实也是减少维度之间的关联的方式，维度只在子空间之内进行关联，比如PQ算法，加快检索速度的同时可以显著减少内存占用。
针对数据量暴涨问题，不管是HNSW还是LSH算法，本质上都是将向量数据表示成层级关联的方式，以此限制全连接比率带来的成本暴涨，提升检索速度。
最后，虽然向量数据是非结构化的，但也会经常和结构化数据进行关联，为此结合另一套结构化数据的元数据索引，也可以加快检索速度。
总之，大即复杂。
04
大数据成本
随着向量规模的增大，可扩展性是一大挑战，向量更新如果不是实时的、增量的也会变得延迟很大，这些都是大数据领域常见的问题。
大数据带来的成本，就用大数据的方式解决。
也就是说，在大数据量场景下，向量数据库也必须进行分布式改造，解决可扩展性、实时更新问题，并添加包括存储、CRUD、备份、迁移等基础支持，这些都是传统数据库的标配，可以说，传统数据库+向量索引，就等于向量数据库。
向量数据库一开始是存算一体的，也就是说存储和计算部署在同一台机器上。但是在业务使用中，很快也出现了同一份数据产生不同类型、不同级别的需求的情况，这时就需要对同一份存储数据建立不同的候选集、索引等计算策略，如果为每种计算策略建立一套存储数据，成本损耗是巨大的，从而存算分离改造无法避免。
进而，随着不同的使用向量数据库的业务系统都开始进行存算分离改造，一个独立的存算分离层级——云原生架构应运而生。
自此，向量数据库完成了从初级文件存储到专业数据库的发展历程。
05
大模型局限性成本
上面提到，向量数据库存在的一大必要性在于大模型的使用体验，即优质prompt的生成。这其实还包含了更多方面，包括推理速度、模型幻觉、数据泄露、知识更新、上下文记忆等方面的考虑。我们以类似RAG的使用框架来解答。
大模型使用的一大槽点就是推理速度太慢，往往回答一个问题需要十几秒到几十秒的时间，难以跟上这个时代的快速消费和内卷的需求，时间即成本。
向量数据库在这时就充当了一个缓存层，缓存了过去已回答的问题的优质答案，在下一次相同或相似提问中，可以直接绕过大模型从向量数据库中提取答案。
模型幻觉往往出现在对正常prompt的微妙改动中，幻觉的出现对于用户的体验影响非常大，是智能与智障的分界线，不少大模型产品都是因为幻觉问题被喷下线。这个问题解决不好，付出的就是一个用户的成本。用户成本在互联网下半场有多高，大家都知道。
在这个场景下，向量数据库可以作为标准化的prompt词典，来限制prompt输入的随机性，从而抑制幻觉出现的概率。
出于对数据安全合规的考虑，企业业务数据是不能用于模型训练的，否则会导致用户使用大模型推理时难以避免的业务数据泄漏问题，这是万万不能出现的事故。一旦出现，成本可能是一家公司。
为此，可以将业务数据存储在向量数据库中，当有相关提问输入时，从向量数据库匹配出对应的业务数据，再导入大模型中，利用大模型学习到的基本常识，进行一次性推理。
对于知识更新，由于大模型微调的时间、资金成本也是很高的，但信息化时代的知识更新速度极快，使用大模型微调来随时更新模型知识，不仅在成本上，在用户体验上也不可行。
为此，可以采用类似的方式，将更新的知识存储在向量数据库中，在模型推理时提取更新知识进行一次性推理。
最后，大模型或者深度学习历来的一大毛病就是前后不一致，上一秒还在聊工作，下一秒就在聊怎么摸鱼，这在聊天机器人中还当做是人性，但在B端软件或客服中出现这样的问题，问题就大了，成本损失可能是一个大客户。尽管大模型如今可输入的token长度越来越大，但为了保证可控性，还是需要用向量数据库作为记忆模块进行辅助。
以销售易为例，其在智能客服系统中嵌入了向量数据库，从而极大提升了多轮对话中的一致性，可以结合多轮对话中的上下文来判断客户只言片语背后的意思。
总之，向量数据库为何那么热的一大原因，就是大模型应用的需求如此旺盛，但大模型本身又还存在很多限制，向量数据库就是为解决这些限制而生的。
那这是否意味着，随着大模型的各项问题解决，向量数据库就没有存在的必要了呢？
06
向量数据库的未来
从数据架构的层面来看，大模型负责计算，向量数据库负责存储，两者都是必要的组成。很大程度上，存储本身就是为了解决计算存在的诸多限制而存在的。
随着大模型愈发成熟，隐去神经网络的复杂细节后，它也将变成一个常规意义上的计算引擎，在扩展更复杂的业务功能时，比如大规模模型知识融合、关联，也肯定会遇到更多的问题，也将仍然需要存储引擎也就是向量数据库，来帮忙解决。
在未来，范围查询、最近邻查询等高级查询功能，也将成为向量数据库的必备功能。
而到目前为止，大部分的向量数据库仍然在多向量查询、批量查询、查询优化器等方面处于初级阶段。所以还有很多坑等着大模型去踩，等着向量数据库去填。
而即便向量数据库的评测维度如此复杂，腾讯云向量数据库仍然表现优异，在信通院首批向量数据库基础能力测试中，通过了全部必选测试项，性能方面，腾讯云向量数据库可支持千亿级数据规模，在线场景读写混合超500万QPS。
腾讯云向量数据库也完美符合一个传统数据库所需的企业级能力，通过技术升级将上述所有成本项：规模化成本、大数据成本、大模型局限性成本等等全方位压缩，比如Embedding推理加速节省90%成本，128维向量的单QPS成本相比行业低了85%，并做到随开随用，为用户最大程度隐去上述技术复杂性，保证了产品易用性。