向量数据库基础

向量数据库悄悄成为了AI系统的基础，而大多数团队因为错误的原因抢着接入一个——或者因为同样错误的原因避开它。向量存储不是魔法检索引擎；它是一个专门为一件任务调优的索引：足够快地找到一个嵌入向量的最近邻来服务实时查询。什么时候用、怎么定容量、用Qdrant、Pinecone、Milvus还是干脆用pgvector——这就是你在承诺之前值得搞懂的对比。

为什么你的SQL数据库回答不了语义问题

你的应用能告诉你哪个用户点了订阅按钮、周二发了多少订单、每一行status = 'refunded'的记录。但它答不了"哪条客服消息和'我的账单出错了但我不确定为什么'在语义上最相似"，因为经典关系型存储匹配的是精确值，不是含义。向量数据库就是来回答第二种问题的。它存嵌入向量——机器学习模型产出的稠密数值表示——按相似度而不是相等来搜索。这正是支撑推荐引擎、语义搜索、异常检测和检索增强生成的那块拼图，也解释了为什么向量搜索在短短几年内从研究冷门变成了主流基础设施议题。

从数字到含义：嵌入向量怎么工作

一个嵌入向量是一串浮点数，通常几百到几千个，模型把它们分配给一段文本、一张图或一个商品。训练时模型学会把相似的东西在数学空间里放得更近，所以"狗"和"幼犬"挨在一起，而"犬科牙医"落得远一些。向量搜索的任务就是：给定一个查询向量，找出距离最小的已存向量。欧氏距离和余弦相似度是你最常遇到的两种度量；对文本而言余弦相似度是更安全的默认值，因为它忽略模长、只看方向，贴合人类判断主题相似度的方式。

嵌入向量要花多少钱

嵌入向量强大但并非免费，成本要在设计期算清楚。生成它们需要一个嵌入模型，要么调API（按token计费），要么自己跑模型（有GPU和内存成本）。存储它们耗内存：一个1536维的float32向量，每条6KB，还没算原始文本。如果你嵌入100万篇文档，那就是约6GB的纯向量存储叠加到其他一切之上。教训是思考总成本，而不只是语义理解的美妙之处，这个权衡练习正是数据分析基础教的内容。选存储类型本身就是一个设计问题，它决定你是否该把向量隔离到一个专用存储，用AI数据分析(中文)里讲的合理索引策略把查询控制在答应用户的延迟预算内。想补齐底层关系数据功底，也可读英文站Database Design Basics（英文）。

近似搜索：那个大家心照不宣接受的对价

在高维空间对几百万向量找精确最近邻，数学上很贵，所以真实系统用近似最近邻（ANN）技术。像HNSW（分层可导航小世界）和IVF（倒排索引）这类ANN索引，用极小的准确率换取巨大提速。一个调优过的HNSW索引，能在几千万个向量上毫秒级回答top-k查询，而结果和精确扫描相比也有99%的还原度。你控制的参数——每层检查的邻居数、候选结果数——成为让你在召回率和延迟之间权衡的旋钮。懂召回率和延迟怎么互动，是"快但错"的搜索和一个达到质量线的系统之间的差别，这正是数据库索引原理（英文）能直接迁移到向量负载上的原因。

进入生产：数据接入与ML生命周期

向量数据库的好坏取决于填它的流水线。典型生产闭环长这样：文档到达、分块器把它切成可消化的片段、嵌入模型把每块转成向量、向量连同元数据和原文一起upsert进库，然后查询来取邻居。对一个真实产品，接入流水线必须处理换模型时重新嵌入、给嵌入版本化（让新旧向量不会带着不兼容的含义并存）、以及源文档更新或删除时的对账。

要可靠地运营这个闭环，周边的机器学习运维和数据库本身同样重要。模型版本化、嵌入漂移、可复现流水线，是Data Engineering Basics（英文）的核心关切。把向量搜索当成更广数据与ML平台的一部分，而不是孤立烟囱，才是区分"快速交付并调试"的团队和"每个月重建索引"的团队的东西。源头数据在哪、怎么转换、向量索引怎么和它同步，这些都要想清楚。想从查询取数开始攒底层能力，可看数据分析基础。

检索增强生成（RAG）用例

2026年向量搜索最热的应用是检索增强生成，也就是RAG。不是每次提问都把整个语料喂给模型，而是从向量库里检索出最相关的几个分块，把它们连同问题一起喂给模型。这个做法大幅降低成本和幻觉风险，因为模型手边有真实的源材料。一个RAG系统的质量几乎完全取决于检索质量，而检索质量取决于分块策略、嵌入选择和索引调优。分块太小丢上下文；分块太大稀释信号；接入时分块和运行时查询不匹配，会产生莫名奇妙的错误答案。

怎么选存储：市场实际长什么样

厂商格局拥挤，正确选择取决于规模、托管还是自建、以及你已经在跑什么专用搜索。重要的是认识到你很少必须选"向量数据库"：很多选项要么是专用向量引擎，要么是加了向量索引的现有数据库。Qdrant或Weaviate这类专用引擎从一开始就给你一流的向量特性，而带pgvector扩展的PostgreSQL和Elasticsearch让你在已经运营的基础设施里获得向量搜索。

如果你已经跑Postgres、而且向量量在几百万以内，就从pgvector开始，因为省掉整个运维层，还能把向量结果和你现有的关系数据join。需要专用、可扩展、带高级过滤和托管运维的存储，Qdrant、Milvus或Pinecone更有吸引力。如果你的搜索需要和整文档关键词搜索共存，Weaviate和Elasticsearch提供把稠密向量和BM25式词法检索结合的混合模式。

向量数据库哪里会掉链子

值得诚实面对局限，因为过度推销向量搜索会导致项目失败。向量搜索不按人类的方式理解语义；它只是找到模型学到的嵌入空间里的邻居，一个训练差或任务不匹配的模型，即使索引完美也会产生垃圾邻居。对元数据的精确过滤往往比想象中慢，因为过滤器跟ANN索引配合不好。冷启动也是真实的：小数据集给不出值得做产品的相似度信号。这些是运营层面的告诫，不是避开技术的原因，但它们是一个注重评估的工程师在做架构决策前会权衡的细节。

测量你的系统是不是真的好

别凭感觉上线一个向量搜索系统。把召回率定义为真实相关结果出现在你top-k里的比例，追踪高分位的查询延迟，对RAG用自动化指标加人工评审看端到端答案质量。调优前先建一个带已知正确答案的黄金查询集；没有它，每次旋钮调整都是瞎猜。早一点建起仪表盘，这样你换模型、换分块器或换索引参数时，能靠数据而不是某个演示查询的轶事看到对质量的影响。

常见问题

我需要单独的数据库，还是用Postgres里的pgvector就行？

对很多团队，pgvector是对的答案，因为它免去加一层基础设施，还能把向量相似度和普通关系查询结合。经验法则：当你向量量在低百万级且已经在运营Postgres时，从pgvector开始；需要几百万向量以上的规模、高负载下的高级过滤、或完全托管服务的运维卸载时，再上专用引擎。

该用哪个嵌入模型？

取决于领域和预算。流行的通用模型在质量和延迟上有不错的平衡，但选对最快的路是实证：用两三个候选模型嵌入一个有代表性的测试集，在你的查询上测量检索召回率。别假设最大的模型最好；一个更小、更便宜、贴合你数据的模型，通常成本和延迟都更优。

该用余弦相似度还是欧氏距离？

文本嵌入从余弦相似度开始，因为它比较方向而不是模长，对各模型出现的规模差异更稳健。如果你的向量已经归一化到单位长度，余弦和欧氏距离变成单调相关，选择就没那么重要。只有当你有理由在意模长时——比如长度编码了置信度或强度——才切到欧氏距离。

嵌入模型变了，向量更新怎么处理？

全部重新嵌入，但要版本化、分阶段做。让旧索引继续服务查询，同时用新模型构建新索引，然后切换并监控黄金集上的召回率和延迟。把模型ID存进每个向量的元数据来给嵌入版本化，这样你能审计某个结果是哪个模型产出的，并检测漂移。

向量数据库除了语义搜索还能干别的吗？

能。异常检测用嵌入标记离邻居远的点；推荐系统用向量做item到item的相似度；去重用嵌入找近似重复的文档或图片。每种情况机制相同，变的是你嵌入什么、以及相似度阈值设在哪。