向量数据库这两年被反复提起，但很多介绍停在一句「存向量的数据库」。这没说到点上——**存数组谁都会，难的是在千万级向量里快速找出最相似的几个。** ## 传统数据库做不了什么 假设你想在自己几万篇笔记里找「怎么给 Docker 容器限制内存」。 用 SQL 是这么查的： ```sql SELECT * FROM notes WHERE content LIKE '%内存%'; ``` 这条语句找不到写的是 `--memory=512m` 但没出现「内存」两个字的那篇；反过来，它又会命中一堆讲数据库内存调优、跟容器毫无关系的文章。 根本原因是：**关键词匹配比较的是符号，不是意思。** 同义词、改写、跨语言表达，它都处理不了。 ## 向量检索的思路 换个思路：如果能把每段文本映射成一个高维向量（embedding），让**意思相近的文本在向量空间里距离也近**，那「按意思找」就变成了「找最近邻」。 流程是三步： 1. 用 embedding 模型把文档转成向量（常见维度 768 / 1024 / 1536，看模型）； 2. 把这些向量存进向量库，库内部建立近似最近邻索引（HNSW、IVF 这类）； 3. 查询时把问题也转成向量，取距离最近的 K 条。 注意第 2 步的「近似」——**ANN（近似最近邻）是用极小的精度损失换数量级的速度提升**。精确检索在百万级数据上慢到不可用，所以向量库普遍做近似。这也意味着调参会影响召回率。 ## 它替代不了关键词检索 这是个常见误解。向量检索有明确的短板： - **精确匹配差**：找错误码 `ERR_CONNECTION_REFUSED`、找函数名 `docker_system_prune`，向量检索经常输给 LIKE； - **稀有词弱**：训练语料里少见的专业术语、内部代号，embedding 表示不好； - **不可解释**：为什么相关说不清楚，排查困难。 所以生产上普遍用**混合检索**：向量召回 + BM25 关键词召回，再把两路结果融合排序。这不是凑合，是实际效果更好。 ## 什么时候你不需要向量数据库 这一点可能比前面都重要： - **数据量小**（几千到几万条）：直接加载进内存用 numpy 暴力算相似度就够了，毫秒级，还省掉一个组件； - **已经在用 PostgreSQL**：装 `pgvector` 扩展即可，百万级以内完全够用，还能和关系数据做 JOIN、带过滤条件查询，**运维成本远低于再引一个独立数据库**； - **数据结构化**：如果只是按标签、分类、时间过滤，那是普通索引的活。 引一个新组件就要多一份备份、监控、升级和故障排查的负担。对中小项目来说，`pgvector` 往往是最务实的选择。 ## 真正决定效果的不是数据库 做了 RAG 项目的人大多会有同一个体会：**效果差的时候，瓶颈几乎不在向量库，而在切分。** 如果文档被切得支离破碎（比如按固定字数硬切，把一段完整的配置说明切成两半），那检索到的永远是不完整的片段，换任何向量库都救不回来。 优先级排序大概是： 1. **切分策略**（按语义、按结构、保留标题层级） 2. **embedding 模型选择**（中文场景要选中文表现好的，别默认用英文模型） 3. **是否加重排（rerank）** 4. 最后才是向量库本身的参数调优 ## 小结 向量数据库解决的是「按语义在高维空间里快速找最近邻」这个具体问题，它**不是**传统数据库的替代品，而是补充。 选型建议倒过来说更清楚：先看数据量和已有技术栈——小数据量用内存，有 PostgreSQL 用 pgvector，真到千万级且查询复杂再考虑独立向量库。省下来的运维精力，花在切分和重排上，收益大得多。