传统数据库擅长精确匹配；向量数据库擅长按「意思相近」找邻居。
这篇带你由浅入深：它是什么、用在哪、主流库怎么选。
模型可以把文本、图片等变成一串数字——叫向量（embedding）。你可以把它想成高维地图上的一个点：意思相近的内容，点会靠得更近。
「苹果手机」和「iPhone 充电器」可能离得很近；「苹果派」「香蕉牛奶」则在另一片区域——关键词会被字面的「苹果」骗到，坐标通常不会。
示意：内容 → 嵌入模型 → 向量数字 → 语义地图上的一个点（真实维度远高于 2）
降维示意：相近意思抱团；「苹果手机」靠近充电器，而不是「苹果派」
比较两个向量远近，常用欧氏距离（直线距离）或余弦相似度（夹角像不像）。业务里两者都常见；关键是整库用同一种尺子，不要混用。
看两点之间的直线长短
从原点看两向量的夹角（不太看长短）
查询句变成向量、文档变成向量，必须用同一个 embedding 模型，得到同样长度（维度）的数字串。换了模型或维度对不上，所谓「近」就失去意义——这是自学时最常踩的坑。
关系型库、全文检索擅长：等于、包含、布尔条件。搜「苹果手机」时，它们很会找含这些字的行；但对「iPhone」这种同义说法，常常要靠同义词表或人工规则硬补。反过来，关键词还容易被字面的「苹果」带偏，把水果食谱也捞进来。
查询：「苹果手机」
查询：同样的一句话 → 变成查询向量
向量数据库：专门存向量（常附带原文片段、标签等元数据），并提供高效的「找最近的 K 个」查询能力的系统。
不是取代 MySQL，而是补上「按语义相似查找」这一环。很多系统两者一起用：精确字段走传统库，相似内容走向量库；需要时再做混合搜索（关键词命中 + 向量近邻一起打分）。
文本/图片 → embedding 模型 → 向量
存向量 + 原文/ID + 元数据
用户问题同样变成查询向量
返回最相近的 K 条结果
真实系统几乎总会带上：
长文通常不会整本塞成一个向量，而是先切成小段（chunk）再分别嵌入——段太长会糊成一团，段太碎又缺上下文，实践里要折中。
向量检索给出的是候选列表（Top-K）。后面常接重排序、业务规则，或交给大模型去「读完再答」——向量库负责把相关材料快速捞出来。
存：同模型、同维度的向量 + 原文/ID + 元数据。
查：问题也用同一模型变成查询向量，找 Top-K 邻居（可加过滤）。
快：规模大了靠近似近邻索引，而不是每次扫完全库。
不强绑单一故事——下面四类都很常见，向量扮演的角色略有不同。
文档、客服知识库、站内搜：用户用口语提问，系统按意思找相关段落。
「看了这个还看了那个」：物品或用户行为被编码成向量，近邻即候选。
大模型外挂知识库：先检索相关片段，再让模型基于片段生成回答，减少胡编。
以图搜图、以文搜图：图像与文本映射到共享或可对齐的向量空间。
数据量小（比如几万条）时，把查询向量和库里每一条都算一遍距离完全可行。到了百万、千万级，每次查询都全量扫描，延迟和算力都会爆炸。
不保证每次都是「绝对最近」，但用索引结构快速找到「足够近」的一批邻居。多数业务更在乎速度，以及「该找到的相关结果有没有漏掉」（常说的召回），而不是数学意义上的绝对精确。
找离你最近的咖啡馆，不必量遍全城每一家：可以先看片区、主干道、熟悉商圈。向量索引也在做类似的事——先缩小搜索范围，再精比。
科普层面记住即可：向量库 = 存储 + 近似近邻索引 +（可选）过滤/混合检索。HNSW、IVF 等具体算法名，选型时再按文档深入；本篇不展开公式。
向量数据库的价值，不在于「会算距离」（那谁都会），而在于大规模时仍然查得快，还能把元数据过滤、混合搜索等工程能力打包好。
没有万能第一名。下面是直觉地图，不是跑分评测；生态演进很快，落地前请用自己的数据试：相关结果找得全不全、查询快不快。
对 Python 很友好，本机/笔记本最快上手。小规模 RAG 演示、教学实验的常见默认选项。
用列式文件格式存数据，常跑在进程内；适合本地或云端对象存储、多模态，以及「不想起独立数据库服务」的工作流。
Rust 实现；按标签/权限等附加信息过滤（常叫 payload）做得清楚。单机 Docker 起步，也能走向集群。很多团队的自建默认。
混合搜索（关键词命中 + 向量近邻一起打分）、可插拔的向量化模块是亮点；适合把检索链路尽量收拢在库侧。
面向大规模分布式与丰富索引选择；真到上亿级、且团队能承担运维复杂度时再重点考虑。
| 库 | 怎么跑 | 体量直觉 | 上手印象 | 过滤 / 混合 | 更适合 |
|---|---|---|---|---|---|
| ChromaDB | 内嵌进程；也可单独起服务 | 万～十万级原型 | Python 极好上手 | 够用的元数据过滤 | 快速验证、教学、小应用 |
| LanceDB | 内嵌；数据在磁盘/对象存储 | 本机到较大本地集 | 偏数据分析工作流 | 随场景增强 | 不想起服务、多模态本地管线 |
| Qdrant | 独立服务 / 云 | 百万～千万常见 | 接口清晰 | 强项：附加信息过滤 | 自建生产默认、过滤条件多 |
| Weaviate | 独立服务 / 云 | 百万～千万常见 | 模块丰富 | 强项：混合搜索 | 要关键词+向量一体化 |
| Milvus | 分布式组件较多 | 千万～亿级 | 企业/云原生场景多 | 分区等大规模手段 | 真大规模、有运维能力 |
先跑通？优先内嵌进程的库（Chroma / LanceDB）。要多服务共享、独立扩缩？选 Qdrant / Weaviate / Milvus 这类独立服务。
万～十万：内嵌往往够用。千万以上：认真评估独立服务与运维成本；上亿级再重点看 Milvus 一类分布式方案。
查询常带权限、标签、租户条件，或要「关键词 + 向量」一起打分：更关注 Qdrant、Weaviate；超大且按分区裁剪，再看 Milvus。
你可以试试：点选「苹果手机」，看邻居是充电器还是苹果派；拖动 K，感受邻居圈变大变小；再切换过滤，体会「向量 + 元数据」一起用。
同模型同维度的语义坐标 + 原文/ID + 元数据；查的是近邻 Top-K，不是唯一精确键。
语义搜索、推荐、RAG、多模态——共性是「先嵌入，再近邻」；也会捞错，常和关键词/规则一起用。
先问：内嵌原型还是独立服务？多大规模？要不要强过滤/混合搜索？再用直觉地图缩小范围。