这两年做AI应用，用了很多向量数据库（也就是大家说的AI数据库）。从最开始的Milvus，到后来的Pinecone、Weaviate、Qdrant，大大小小的坑踩了不少。

有些坑，让我熬了好几个通宵才解决。这篇文章我想记录一下这些踩坑的经历，分享问题的现象、原因和解决方案。如果你也在用或者准备用AI数据库，希望能帮你少走弯路。

坑一：向量维度不匹配

第一个坑，也是最基础的坑，就是向量维度不匹配。

刚开始用向量数据库的时候，我用的是一个开源的embedding模型，输出的向量维度是768。我建索引的时候，也是按768维建的。一切都很正常。

后来，我换了一个效果更好的embedding模型，这个模型输出的向量维度是1024。我换了模型之后，直接就往原来的索引里写数据，结果报错了，说维度不匹配。

这个问题其实很简单，但当时我没注意，查了半天才发现是维度的问题。解决方案也很简单，要么重建索引，用新的维度；要么把新模型的向量降维到768。

但重建索引很麻烦，数据量大的话，要重新导入所有数据，花很长时间。所以后来我就学乖了，换embedding模型之前，先确认维度，然后提前规划好索引的重建。

经验：换embedding模型的时候，一定要注意向量维度的变化，提前做好索引重建的计划。

坑二：索引参数设置不当

第二个坑是索引参数设置不当。

向量数据库的索引，有很多参数可以调，比如索引类型、相似度度量方式、nlist、nprobe等。这些参数对查询性能和准确率影响很大。

刚开始的时候，我用的是默认参数。数据量小的时候，没什么问题。但数据量涨到几百万条之后，查询就变得很慢了，一次查询要好几秒。

我查了很多资料，才发现是索引参数的问题。默认的nlist太小，导致每个簇里的向量太多，查询的时候要扫描很多数据。

我把nlist调大之后，查询速度快了很多。但调得太大之后，准确率又下降了。后来反复测试，才找到一个性能和准确率的平衡点。

还有相似度度量方式，我最开始用的是内积，但我的向量没有做归一化，导致结果不准确。后来改成了余弦相似度，或者先把向量归一化再用内积，结果就正常了。

经验：索引参数不要用默认的，要根据数据量和查询需求进行调优。不同的参数组合，性能和准确率差别很大。

坑三：数据导入太慢

第三个坑是数据导入太慢。

我们有几千万条数据要导入向量数据库，最开始用单条插入的方式，每秒只能插几百条，照这个速度，要插好几天。

后来我改成了批量插入，每次插几千条，速度提升了不少。但还是不够快，而且插入的时候，数据库的CPU和内存占用很高，影响了正常的查询。

我又研究了一下，发现可以用并行导入的方式，开多个线程同时插入。这样速度又提升了几倍。但要注意，并行度不能太高，不然会把数据库压垮。

还有一个技巧是，导入的时候先不建索引，等数据全部导完之后再建索引。这样导入速度会快很多，因为建索引是很耗资源的操作。

另外，导入数据的时候，要注意数据的质量。有些数据的向量是null，或者维度不对，会导致导入失败。最好在导入之前做一次数据清洗。

经验：大批量导入数据的时候，用批量插入+并行导入+延迟建索引，能大大提升导入速度。

坑四：内存占用过高

第四个坑是内存占用过高。

向量数据库很吃内存，特别是用HNSW索引的时候，索引会占用大量内存。我们的数据量到了几千万条之后，服务器的内存就不够用了，经常OOM。

最开始我以为是数据量太大，想加内存。但加内存很贵，而且数据还在增长，加了也迟早不够用。

后来我研究了一下，发现可以用一些方法来降低内存占用。

第一个方法是用更低精度的向量。比如把float32的向量转成float16或者int8，内存占用能减少一半甚至更多，准确率损失很小。

第二个方法是用磁盘索引。有些向量数据库支持把索引存在磁盘上，查询的时候再加载到内存。这样内存占用会少很多，但查询速度会慢一些。

第三个方法是数据分片。把数据分散到多个节点上，每个节点只存一部分数据，这样每个节点的内存压力就小了。

第四个方法是定期清理无效数据。我们的数据里有很多过期的、无用的向量，定期清理能减少数据量，降低内存占用。

经验：向量数据库很吃内存，要提前做好内存规划。用低精度向量、磁盘索引、数据分片等方法，能有效降低内存占用。

坑五：查询结果不准确

第五个坑是查询结果不准确。

有一段时间，用户反馈说搜索结果不准，搜出来的东西和查询的内容不相关。我查了很久，发现了几个原因。

第一个原因是embedding模型的问题。我们用的embedding模型，对某些领域的内容理解不好，导致向量的区分度不够。后来我们换了一个在这个领域微调过的模型，准确率就提升了。

第二个原因是数据预处理的问题。我们的数据里有很多噪声，比如HTML标签、特殊字符、无关的内容。这些噪声会影响embedding的质量。后来我们加了数据清洗的步骤，把噪声去掉之后，准确率提升了不少。

第三个原因是查询的预处理不够。用户的查询有时候很随意，比如只有一两个词，或者有很多错别字。这样的查询，embedding的质量不高，搜出来的结果自然不准。后来我们加了查询扩展、纠错等预处理步骤，效果好了很多。

第四个原因是索引参数的问题。nprobe设得太小，导致查询的时候只扫描了很少的簇，漏掉了一些相关的结果。把nprobe调大之后，准确率提升了，但查询速度变慢了。需要在性能和准确率之间做平衡。

经验：查询结果不准确，不要只怪数据库，要从embedding模型、数据质量、查询预处理、索引参数等多个方面排查。

坑六：并发查询性能差

第六个坑是并发查询性能差。

我们的系统上线之后，用户量增长很快，并发查询量也越来越大。最开始的时候，几个并发查询还没问题，但到了几十个并发的时候，查询延迟就明显上升了。

我查了一下，发现数据库的CPU和IO都很高，已经成为瓶颈了。

解决方案有几个。第一个是读写分离，用主从架构，写操作走主节点，读操作走从节点。这样查询的压力就分散到多个从节点上了。

第二个是加缓存。很多查询是重复的，把查询结果缓存起来，相同的查询直接返回缓存，不用查数据库。我们加了Redis缓存之后，数据库的压力小了很多。

第三个是查询降级。当并发量很高的时候，可以自动降低查询的精度，比如减小nprobe，用更粗糙的搜索方式。这样能牺牲一点准确率，换来更高的吞吐量。

第四个是水平扩展。如果以上方法都不够，就只能加节点了，把数据分片到多个节点上，查询的时候并行查询，提升并发能力。

经验：并发查询性能差，要从读写分离、缓存、降级、水平扩展等多个方面来优化。

坑七：数据更新和删除的问题

第七个坑是数据更新和删除的问题。

很多向量数据库，对数据的更新和删除支持得不好。有些数据库，更新数据其实是先删后插，效率很低。有些数据库，删除数据之后，空间不会立刻释放，需要手动压缩。

我们就遇到过这个问题。删除了一批数据之后，数据库的占用空间没有减少，反而还在增长。查了半天才发现，删除的数据只是标记为已删除，物理空间没有释放。需要定期做optimize，才能回收空间。

还有更新的问题。我们有一些数据需要频繁更新，每次更新都要重新计算embedding，然后更新到数据库里。这个过程很耗资源，而且如果更新不及时，就会出现数据不一致的问题。

后来我们的解决方案是，对于需要频繁更新的数据，用增量更新的方式，只更新变化的部分。对于删除操作，定期做optimize回收空间。同时，做好数据的一致性校验，确保数据的准确性。

经验：向量数据库的更新和删除，和传统数据库不一样，要了解它的机制，做好空间回收和一致性校验。

给准备用AI数据库的朋友的建议

最后给准备用AI数据库的朋友几个建议。

第一，先想清楚需求。你的数据量有多大，查询并发有多高，对准确率和延迟的要求是什么。不同的需求，适合不同的数据库和配置。

第二，做好调研。现在向量数据库很多，开源的、商业的都有。不要盲目跟风，根据自己的需求，选择最适合的。有条件的话，做一下POC测试，实际用一用。

第三，从小规模开始。不要一上来就把所有数据都导进去，先用一小部分数据测试，验证性能和准确率，再逐步扩大。

第四，做好监控。向量数据库的状态很重要，要监控内存、CPU、查询延迟、准确率等指标。出现问题的时候，能快速定位。

第五，留好退路。不要把所有希望都寄托在一个数据库上。做好数据的备份，设计好抽象层，这样如果要换数据库，也不会太麻烦。

写在最后

AI数据库是一个很新的技术，发展很快，但也有很多坑。这两年用下来，我踩了不少坑，也学到了很多。

但总的来说，AI数据库是AI应用中不可或缺的一部分。虽然有坑，但只要了解了它的特性，做好规划和调优，就能很好地用起来。

如果你也在用或者准备用AI数据库，希望我的这些踩坑经历能帮到你。少踩一个坑，就能少熬一次夜。

最后用一句话来结束这篇文章："踩坑不可怕，可怕的是踩了坑不总结。每一个坑，都是一次成长的机会。"

愿每一个做AI应用的工程师，都能少踩坑，系统稳定运行。