紫木祀水向量数据库在AI技术栈里算是最被低估的底层组件之一。很多人聊大模型、聊RAG，开口就是模型怎么选、Prompt怎么写，但真正到了上线阶段，卡住你的往往是检索那一环——数据存哪里、怎么召回、延迟能不能压住。我做向量检索相关项目这几年，最深的感触就是：向量数据库和AI技术根本不是单向依赖，而是互相拉扯着往前走的一对双生子。AI模型每一次进化，都会逼着存储和检索侧升级；反过来，向量数据库的每一次突破，又让更复杂的AI应用变得可落地。
今天就把我理解中的这段“共生史”拆成三个阶段来讲，顺便聊聊每个阶段背后真正驱动变化的技术原因，以及现阶段我们做选型和架构时应该怎么参考这段演进史。
1. 为什么说向量数据库和AI是“共生”关系
不先把这层关系说透，后面看三个阶段你会觉得只是在看时间线。其实向量数据库从诞生到爆发，节奏几乎完全被AI技术的几个关键拐点牵着走，但每次数据库侧的能力升级，又会反向解锁新的AI玩法，这是一种典型的相互成就。
1.1 向量数据库到底解决了什么问题
先对齐一下概念。传统数据库管理的是结构化数据，比如姓名、年龄、订单金额，查询靠的是精确匹配或范围过滤，核心是布尔逻辑。而向量数据库管理的是“向量”，也就是一组浮点数序列。
这组浮点数通常是AI模型对文本、图片、音视频等内容做推理后生成的向量化表示。你可以把它理解成给每个东西“算了个高维指纹”。比如一句话“今天天气不错”，经过Embedding模型转换，会落到一个几百维甚至上千维的浮点数组里。语义相近的句子，高维空间里的距离就相近；语义完全无关的，距离就很远。
向量数据库的核心工作，就是在海量这类高维向量里，快速找到与某个查询向量“距离最近”的那一批。这个动作通常叫近似最近邻搜索（ANN）。注意“近似”这两个字很关键，因为在高维空间里精确找最近邻的计算量是灾难级的，工业界普遍接受用极小的精度损失换取几个数量级的性能提升。
1.2 AI在哪一步依赖了向量数据库
以现在最火的RAG（检索增强生成）架构为例。大模型虽然知识量惊人，但它的知识截止训练时间、且无法覆盖企业内部私有数据。RAG的思路是先建一个“企业知识库”，把文档切片后转成向量存进向量数据库，等用户提问时，先从库里检索出最相关的几个片段，再连同问题一起交给大模型生成回答。
这个流程里，向量数据库承担的是“外挂记忆”的角色。模型本身不存储任何具体业务数据，所有事实性内容都靠实时检索喂进去。这种架构的核心依赖就是：向量数据库必须够快、够准，毫秒级响应，并且能支撑海量数据。没有数据库侧的支撑，RAG这种应用模式根本不可能在真实业务里跑起来。所以你说两者是什么关系——AI负责“理解”，向量数据库负责“记忆”，缺了谁，故事都讲不完整。
1.3 “相辅相成”四个字具体体现在哪
体现在三个层面。技术层面，模型能力的提升让向量数据质量更高、应用场景更广，倒逼数据库在算法、存储、分布式架构上持续变革；而数据库能力的增强，又让更复杂的AI应用（比如多模态搜索、实时推荐、Agent记忆）从实验室走进生产环境。商业层面，AI基础设施的军备竞赛让资本涌入向量数据库赛道，产品形态快速成熟；反过来，成熟的产品又降低了开发者使用AI技术的门槛。生态层面，Embedding模型、大模型框架、向量数据库三者之间的适配和标准化越来越完善，形成了一个互相增强的循环。
需要模型API调用？ 免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。
2. 第一阶段：AI早期探索，向量检索的“史前时代”
这个阶段大致对应2012年之前。当时的AI还停留在传统机器学习和早期神经网络阶段，没有深度学习带来突破性进展，也没有真正意义上的向量数据库产品，但很多关键算法思想已经开始萌芽。
2.1 传统数据库的局限是源头
我在2010年前后做过一段时间的文本检索系统，当时的需求其实已经接近今天的“语义搜索”——用户想问“怎么退换货”，但文档里写的是“退货流程”，纯关键词匹配根本兜不住。
传统数据库的LIKE查询只能做字符匹配，Elasticsearch这类搜索引擎能够做分词和BM25相关性打分，本质上还是“词语匹配”的范畴。遇到同义词、不同表述、跨语言场景，效果就崩。这种局限性，恰恰是后来向量检索的突破口。用一个生活化的类比：传统数据库像是图书馆的书目卡片索引，只能通过作者名、书名去找；但如果你要问的是“画面里有红色气球的书”，书目卡片就完全帮不上忙，必须换一种组织信息的方式。
2.2 词向量萌芽：Word2Vec的贡献
2013年Word2Vec的提出，是我认为这个阶段最具标志性的事件。虽然它严格意义上已经是深度学习兴起前后的产物，但它提出了一个颠覆性思路：把词语映射到连续向量空间里，语义相近的词在空间位置上接近。国王减去男性加上女性，结果约等于女王——这个经典例子当年给我带来的震撼到现在还记得。
但Word2Vec时代，向量化只是模型做辅助任务时产生的“副产品”，大家会直接把词向量拿来算相似度，但是数据规模不大、场景也不够复杂，用暴力计算加简单索引就能对付。当时没有人会专门设计一套系统来存储和检索向量，因为需求远没到那个量级。整个阶段的特点，可以概括成“算法先行，基础设施缺席”。
2.3 为什么第一阶段没有诞生向量数据库
核心原因是当时的AI技术主要还是学术驱动，工业界大规模落地场景少。向量数据的规模停留在百万级以下，暴力遍历加内存缓存完全能扛住。再就是索引算法还不成熟，HNSW这类现代向量索引是十几年后才提出的，当时的近似最近邻算法比如LSH（局部敏感哈希）虽然理论优美，但实际效果和工程化程度都比较有限，要做成产品级系统火候不够。
这就像电力刚发明的时候，大家只是拿它照明，不会想着建设一个“电网基础设施”。只有当用电设备越来越复杂、用电量越来越大，电网才成为必需品。向量数据库的诞生，本质上也是AI从实验室走向生产环境后，渐渐被“逼”出来的产物。
3. 第二阶段：深度学习引爆向量检索，专用数据库应运而生
第二阶段大致从2013年持续到2021年前后。深度学习全面崛起，让向量数据的数量和质量都发生了质变。这一阶段是向量数据库真正从“算法idea”走向“独立产品”的时期。
3.1 Embedding模型的普及让“万物皆可向量”
深度学习时代最核心的变化，是Embedding技术从词级别扩展到了句级别、段落级别、甚至图级别。2018年BERT出现之后，文本向量化的效果大幅提升，相似的句子在向量空间里聚集得越来越紧。与此同时，图像、音频等其他模态也都能被统一编码到同一个向量空间里。
这带来的直接后果就是：向量数据的来源爆炸了。推荐系统需要给每个用户每个商品算向量，搜索引擎需要给每个网页算向量，图片检索需要给每张图算向量。我做过的一个图片相似度项目，几千万张商品图都变成向量之后，第一反应就是：以前那套暴力遍历完全行不通了，每查一次要遍历全部数据做内积计算，单机根本扛不下来。
3.2 索引算法的成熟：HNSW和IVF的登场
数据量暴涨之后，工业界急需高效的向量索引算法。这一阶段两个里程碑式的算法开始大面积落地。
IVF（倒排文件）的思路是先把全量向量做聚类，比如聚成1000个簇，查询时只扫描距离最近的几个簇，用降低精度换效率，原理上有点像图书馆先按学科分类，再在特定区域找书。HNSW则基于跳表思想构建多层图结构，上层图稀疏、跨度大，能快速定位到目标区域，下层图稠密，做精细化搜索，效果类比社交网络里先找几个“关键人脉”，再靠他们快速接触到目标圈子。
2019年Meta开源的Faiss是这一阶段最重要的工程推动者。它把IVF、PQ（乘积量化）、HNSW等算法统一实现并做了极致优化，让开发者可以在普通服务器上建立千万级、亿级向量索引。很多早期向量数据库的底层，本质上都是先基于Faiss做二次封装，再把存储、分布式、高可用这些数据库该有的能力补上。
3.3 专用向量数据库产品的出现与爆发
2019年前后，Milvus、Qdrant、Weaviate、Pinecone等一批专门处理向量数据的数据库产品陆续发布。它们做的事情从“提供一个索引算法库”变成了“提供一个数据库系统”，具备数据持久化、实时增量更新、标量过滤、多副本、分布式扩展这些企业级功能。
我印象很深刻的是Milvus早期版本对“标量过滤”的支持还不成熟，复杂业务场景里要先查向量再拿ID去关联元数据，连表查询性能极差。后来产品迭代，逐渐支持了向量检索和标量过滤的混合查询，这才真正把向量数据库从“玩具”变成了生产工具。这个阶段里，AI技术对向量数据库的驱动是决定性的——没有BERT带来的高质量向量，就不可能有足够多的落地场景来验证数据库产品的价值。
3.4 真正让向量数据库跑起来的两个AI场景
这一阶段最经典的落地场景，一个是推荐系统。电商平台把用户行为和商品内容分别编码成向量，线上实时计算“哪个商品向量和用户兴趣向量最接近”，然后把TopN推给用户；另一个是图片和视频搜索，版权平台和社交App大量使用向量检索做以图搜图、相似内容去重。
这些场景对性能的要求极其苛刻。在线推荐通常要求几十毫秒内返回结果，而且并发量动辄上万甚至更高。向量数据库为了解决这个问题，逐步发展出了GPU加速、索引分片、内存计算等能力。可以说，没有这些AI场景产生的持续压力，向量数据库很难在一两年内从原型演进成靠谱的产品。
4. 第三阶段：大模型时代，向量数据库成为基础设施
第三阶段从2022年到现在，也是大家最熟悉的阶段。大模型的爆发让向量数据库从小众基础组件一跃成为AI应用的标准配置。现在聊AI架构，不聊向量数据库反而显得奇怪。
4.1 RAG架构成了最大的“催化剂”
2022年底ChatGPT发布之后，整个行业用最快速度从“用大模型做单轮对话”切换到了“用RAG做知识库问答”。原因很简单：大模型存在幻觉问题，对实时信息和企业私有知识一无所知，直接把用户问题丢给模型，答案可能看起来头头是道，实际内容完全是编的。
RAG的解决方案是“先查后答”。企业把内部文档事先做好切片和向量化，然后当用户提问时，第一步先在向量数据库里执行相似度检索，把最相关的几个片段抽出来，第二步把这些片段作为上下文，和用户问题一起提交给大模型。这套思维瞬间让大模型从“知识渊博但容易乱编的专家”变成了“手里拿着你的业务手册、边翻边答的顾问”。
实测下来，RAG对答案准确率的提升是质的飞跃，尤其是涉及产品规格、售后政策、内部流程这类强事实性问题。而这套架构中，向量数据库承担了最核心的检索环节。这也解释了为什么大模型火了之后，各家向量数据库的关注度同步暴涨。
4.2 开源生态大爆发：Milvus、Chroma、Qdrant、pgvector
这个阶段向量数据库的产品形态越来越多元，技术路线也出现了分化，这是其他数据库品类少见的。选型时不再只看性能，还要看部署方式、开发上手难度、生态集成成熟度。
4.2.1 Milvus：面向大规模生产环境
Milvus目前是开源社区里最活跃的分布式向量数据库之一。它的核心优势在于云原生架构，支持存储与计算分离、水平扩展、多租户。如果你的数据量到了千万级甚至亿级以上、对高可用和弹性扩缩容有硬性要求，Milvus是比较稳的选择。它的IndexNode、QueryNode、DataNode等组件拆分，更像一个完整的分布式数据库系统，部署和运维复杂度相对较高，但胜在架构上限高。
4.2.2 pgvector：应用团队最友好的“轻量入场券”
pgvector给PostgreSQL加了向量类型和索引支持，它不改变你已有的数据库架构，只要在现有PostgreSQL里创建一个extension，就能建向量列、建IVFFlat或HNSW索引，直接跑相似度查询。对大多数中小团队来说，这是零成本起步的最佳选择——不用额外引入新组件，不用学新API，SQL就能完成所有操作。
一个常见的务实路线是：数据量在几百万条以下用pgvector；等真到了需要更大规模、更强性能时，再把数据迁移到Milvus、Qdrant这类专用系统。很多团队一开始就上分布式向量数据库，反而是过度设计。
4.2.3 Chroma：轻量级、面向本地和原型验证
Chroma的定位非常明确，就是轻量、简单、易用的嵌入式向量数据库，特别适合做本地开发调试和小型个人项目。它的API设计得很直观，几行代码就能把文档切好、向量化、存库、跑查询。我自己做原型验证时经常用Chroma，因为它跟LangChain、LlamaIndex等框架的集成做得很完善，几乎做到了即插即用。
不过生产环境用Chroma需要谨慎，它不太适合大规模并发访问和数据持久化要求高的场景。它更像一个“开发体验极佳、生产能力有限”的工具。对于做Demo或课程项目来说很合适，真正上线要考虑迁移到更强壮的产品。
4.2.4 Qdrant：Rust实现的性能派
Qdrant是这一阶段极具竞争力的开源向量数据库，底层用Rust开发，性能表现非常优秀。它提供了丰富的高级特性，比如Payload过滤（向量检索时同时按结构化字段过滤）、内置向量量化、分布式部署等。Qdrant的稳定性口碑在社区里一直很好，而且它的API设计比较现代化，对开发者友好。如果你对性能有要求，又不想被Milvus的分布式复杂度吓到，Qdrant是一个值得重点考虑的选择。
4.3 向量数据库反向推动AI应用的三个方向
第三阶段最值得注意的，是向量数据库不再是“被动等需求”，而是开始主动影响AI应用的架构设计，我认为有三个方向比较明显。
首先是Agent记忆系统。大模型应用正从“单轮问答”走向“多步骤自主任务”，Agent需要记住历史状态、过去探索过的路径、用户的长期偏好，这些都是典型的长周期记忆需求。向量数据库在这类系统里承担的不只是“知识检索”，还承担了“记忆存取”，这改变了Agent的系统设计方式——不再需要把所有上下文都塞进Prompt，而是按需从向量数据库里捞取。
其次是多模态搜索。文本、图片、音频、视频统一编码到同一个向量空间后，可以实现“用一句自然语言搜图片”“用一段旋律搜相似歌曲”“用商品图搜索同款”等跨模态检索。这些能力在过去需要单独搭建多个系统，现在一个向量数据库就能同时承接，应用设计的想象空间大了很多。
第三是推荐和广告系统的升级。传统推荐系统主要依赖标签匹配和协同过滤，向量检索可以做真正的语义匹配。比如我做过的新媒体内容推荐，用向量召回“用户可能感兴趣”的文章，再配合业务规则精排，整体点击率提升效果非常显著。
4.4 大模型长上下文是否会让向量数据库“失业”
这个问题我经常被问到，我的答案是：短期不会，反而会形成共存关系。大模型的上下文窗口确实在越做越大，从4K、32K、128K一路涨到百万级，理论上确实可以把整个知识库都塞进上下文里。但这么做有两个现实问题，一是成本，每次请求都把几十万字塞给模型，Token费用会高到让你怀疑人生；二是精度，模型注意力在超长上下文里会显著下降，反而检索召回关键片段的效果更好。
所以我的看法是，长上下文更多地解决了“一篇超长文档的理解”问题，而向量数据库仍然负责“海量文档中最相关内容的召回”。两者在未来长期是互补关系，甚至大模型能力越强，检索结果越能转化为更有价值的回答，向量数据库的价值也会更凸显。
5. 实操选型建议：没有最好的向量数据库，只有最合适的
聊了这么多历史和技术演进，最后落到实际的选型和运维问题上。以我自己的项目经验来看，这个阶段选向量数据库，要优先想清楚几个问题。
5.1 从四个维度做选型决策
数据规模是第一位的。如果你的向量数据量在百万级以下，pgvector或者Chroma完全够用，不必为了用新技术而引入新组件；达到千万级，就要考虑Qdrant或Milvus这样的专用系统；如果到了亿级或更高，分布式架构基本就是必选项了。
实时性要求是第二位。离线批处理场景对延迟不敏感，在线实时检索则需要高性能的索引结构和内存计算能力。HNSW索引在查询性能上表现优异，但构建索引的内存开销大；IVF倒排类索引构建更快，查询速度相对慢一些，适合数据更新频繁、实时性要求不那么极端的场景。
团队技术栈是第三位。团队熟悉PostgreSQL，那pgvector的学习成本最低；团队对云原生和容器化部署经验丰富，Milvus的Kubernetes部署就不算大难题；团队需要快速验证产品原型，Chroma可能是最快的选择。
业务场景是第四位。是做纯相似度检索，还是需要向量检索与标量过滤配合？是否需要多租户能力？是否要求高可用和灾备？这些需求直接决定了你要选择哪个产品层级。
5.2 索引参数调优的几条实用心得
以HNSW为例，实际使用中最重要的三个参数是M、efConstruction和efSearch。M是每个节点的最大连接数，值越大召回率越高但内存占用也越大，我在生产环境通常从16开始调；efConstruction是建索引时的动态候选集大小，值越大索引质量越高但建库越慢，一般取200左右；efSearch是查询时的候选集大小，直接决定查询精度，线上通过压测动态调整，通常在64到256之间。
调参的核心原则是：先粗调找到合理区间，再细调做性能与精度的平衡。我做过一个500万条数据的场景，M从16调到32，内存涨了将近50%，但召回率只提升了不到2%，最终还是要回归业务指标来决定取舍。距离度量方面，文本向量用余弦相似度比较多，但要特别注意向量是否做了归一化——归一化之后，内积和余弦等价，某些索引计算会有优化空间。
5.3 我踩过的一些坑
第一个坑是“索引不等于万事大吉”。有一次我为了压测性能把HNSW的efSearch调得很大，召回率是高了，但P99延迟从30毫秒飙到了200毫秒，完全不可用。后来采取分级策略，线上用低延迟配置，离线评测用高召回配置，才把问题解决。
第二个坑是标量过滤和向量检索的组合顺序。很多向量数据库的标量过滤能力实现方式不一样，有的先过滤后检索，有的是先检索后过滤，两者在性能上差距巨大。特别是过滤条件非常严格时，如果数据库是先向量后过滤，实际上是在浪费时间做大量无意义的计算。
第三个坑是向量维度选择。同样一批文本，不同Embedding模型输出的向量维度可能从384到1536不等。维度越高，语义表达能力通常越强，但存储量和计算量也同步上升。不要盲目追求高维度，结合业务效果和成本，选择合适维度的模型也是一种工程能力，比如有的场景用轻量级模型输出384维就已经够用，非要上1024维，纯属浪费资源。
5.4 当前阶段比较推荐的“起步组合”
如果你是第一次在项目里引入向量检索，我比较推荐一条务实的路径：先用Chroma做技术验证、跑通RAG流程；验证有结果后，把存储层换成pgvector，利用已有PostgreSQL基础设施，支持几百万条数据的线上服务；等数据量和并发量进一步上涨，再平滑迁移到Milvus或Qdrant这类专用系统。这条路每一步的成本都不高，踩坑的影响也可控。
另外，搭建好向量检索环节之后，一定要回头验证检索质量。一个很常见的误区是只关注向量数据库的性能指标，忽略了召回内容的准确性。实际测试时，要从业务库里抽样一批真实问题，人工判断Top10结果是否与问题语义相关，如果相关度不高，就要排查是Embedding模型选型问题、切片粒度问题，还是索引参数问题。这一步才是RAG系统效果好坏的关键，很多人忽略了这个“反向调优”的过程。
我在实际项目里踩过不少坑之后，最深的体会是：向量数据库的选型和调优不是一锤子买卖，而是一个持续迭代的过程。数据规模在增长，Embedding模型在升级，业务场景在扩展，向量数据库的配置和架构也需要跟着演进。建议团队在初期就留好数据和索引的版本管理机制，建立检索质量的离线评测集。这样不管是升级模型、调整参数，还是迁移数据库，都能有量化指标做依据，不至于靠感觉拍脑袋。阶段式演进、小步快跑，是应对这个快速变化领域最务实的策略。