向量数据库教程

刚上手 RAG 的人常卡在同一处：文档切好了、向量模型也调通了，但不知道该把向量存哪、怎么建索引、检索结果为什么总不对。这篇把向量数据库的选型判断、写入前准备、检索参数调试整理成可照着做的顺序，不吹某一款产品，只给能落地的检查项。

刚上手 RAG 的人常卡在同一处：文档切好了、嵌入模型的接口也调通了，但不知道该把向量存哪、索引怎么建、检索回来为什么总是不对。这时候缺的不是模型，而是一套能照着走的顺序。

这篇不吹某一款产品，只把向量数据库的选型判断、写入前准备、检索参数调试整理成可执行的检查项。你按顺序走一遍，基本能定位问题出在哪一环，也能知道自己到底需不需要上向量数据库。

先搞清楚它替你干了什么

向量库里存的东西很朴素：一串数字（向量）、一条主键、外加一堆元数据。它真正解决的问题只有一个——在海量向量里快速找出最接近的几个。别指望它顺手把文本切好、把问题答好，那些是切块策略和上层逻辑的事。

写入和检索是两条独立链路。写入决定库里数据长什么样，检索决定你拿到什么。结果不对时，先分清是写入时数据就有问题，还是检索参数没配好，别一上来就怪数据库。

• 数据量很小，每次全量扫一遍也能忍——先用内存数组或本地文件就够；
• 只是本地试玩、验证思路——嵌入式库比起一个服务省事得多；
• 需要跨团队共享、有权限隔离和备份要求——这时候才值得上正经的向量数据库。

选型只看几个能落地的维度

选型第一步不是比功能表，而是先定部署形态。托管服务、可自托管服务、嵌入式库，这三者的运维成本和将来迁移的难度差得很远。形态定了，剩下的才是在同类里挑。

别只盯着各家榜单的名次，排行口径不一样，参考价值有限。到 向量数据库目录（/stacks/vector-dbs） 按你自己的场景逐项对照更靠谱。兜底思路是：优先选过滤和导出做得扎实的，因为将来换库时，这两项决定了你跑路的成本。

写入：先对齐向量模型再灌数据

写入前必须定死三件事：用哪个嵌入模型、向量多少维、距离度量是什么。这三个参数一变，已有数据基本得整库重来，没有捷径。定之前先去站内的模型资料库把口径核对清楚，别凭印象。

1. 定参数确定嵌入模型、维度和距离度量，写进项目配置，后续所有写入和查询都读同一个配置。
2. 试批次从几百条一批开始试，逐步加大到几千条。观察一次写入的失败率和耗时，哪个体量开始频繁超时，就往回收一档。
3. 带元数据每条记录都带上来源、时间、权限、文档类型这类可过滤字段。等数据灌完再补，代价会大很多。
4. 抽样验证写完后随机抽几条，用同一条文本的向量去查，看能不能召回自己。查不到说明写入链路有问题。

批次大小没有万能值，取决于你的网络、单条向量大小和服务端限制。判断标准很简单：一次写入的失败率明显抬头，或者单批耗时超过你的接受范围，就是批次太大。

检索：先能查到，再谈查得准

第一次跑通只需要三件事：用同一个模型生成的 query 向量、top-k 取多少、要不要带元数据过滤。这个阶段先别看相似度分数的绝对值，它跨模型、跨库都不可比，看排序就够了。

结果不对，按下面这个顺序排查，基本能从最可能的原因排到最少见的。

• 切块是不是把一句完整的话拆成了两半，导致语义被割裂；
• 过滤条件是不是写得过死，把本该命中的结果挡在外面；
• top-k 是不是太小，正确答案排在后面根本没进来；
• 距离度量和索引类型是否和写入时一致，不一致会安静地给你错结果。

想提升相关性，优先级是加重排，而不是盲目把 top-k 调大。top-k 调大只会带进更多噪声，重排能把真正相关的顶上来。具体思路可以看 rag-rerank-guide，先攒一批真实问题做小样本评测，再动手调参数。

新手最容易踩的几个坑

还有一个容易忽略的点：向量模型和数据库是两套独立的东西，升级任意一边都要先小范围验证，确认维度和语义没变，再全量推进。别在深夜一次性改完，出了事很难回滚。