向量数据库被神化了，它的问题比你想象的多

2026年，向量数据库几乎成了AI基础设施的标配。每篇RAG文章都在讲"先用向量数据库做语义检索"，好像它就是万能的。但过去一年，我看到了太多"用了向量数据库反而更差"的案例。

某电商客服系统，用向量数据库做FAQ匹配。用户问"我的订单什么时候到？"，向量数据库匹配到了"如何查看物流信息"——语义上确实相关，但用户要的是具体时间，这需要查订单数据库。这就是向量数据库的第一个致命局限：它只能告诉你"哪些文档相关"，不能告诉你"答案是什么"。

局限一：精确匹配，向量数据库比传统数据库差100倍

向量数据库的核心能力是"模糊匹配"——找相似的内容。但很多场景需要的是精确匹配。

某法律合规系统，需要查询"劳动合同法第39条"。向量数据库返回了"劳动合同法第38条"、“劳动合同法第40条”、“关于解除劳动合同的若干规定”——都是相关的，但用户要的就是第39条。传统数据库用WHERE article_id = '39'，1ms出结果。向量数据库花了30ms，给了用户不想要的答案。

金句：向量数据库解决的是"我不知道关键词是什么"的问题，不是"我知道关键词，帮我查一下"的问题。

解决方案：混合搜索。先用元数据过滤（精确匹配），再在过滤后的结果中做向量搜索（模糊匹配）。而不是反过来。

局限二：结构化查询，向量数据库是"瞎子"

某数据平台想用向量数据库做"找出去年销售额超过1000万且客户满意度低于3星的销售代表"。这个查询在SQL里是：

SELECT * FROM sales WHERE year = 2025 AND revenue > 10000000 AND satisfaction < 3;

在向量数据库里？你没法做。因为向量数据库的核心查询方式是"相似度搜索"，它对数值比较、范围查询、聚合统计的支持非常弱。即使有标量过滤，也远不如SQL灵活。

金句：如果你的查询中有大量的>、<、BETWEEN、GROUP BY、JOIN，你应该用传统数据库，而不是向量数据库。

局限三：数据新鲜度，向量数据库的"实时"是个伪命题

某舆情监控系统，需要实时追踪热点事件。但向量数据库的索引构建不是实时的——新增数据需要先写入，再构建索引，这个过程中数据是"不可搜索"的。

以Milvus为例，新写入的数据在segment被flush之前（默认1秒或1MB），无法被检索到。即使flush后，也需要等待索引构建完成（取决于数据量和索引参数）。对于100万向量的数据，HNSW索引构建可能需要几分钟到几十分钟。

金句：向量数据库的"实时"是准实时，延迟通常是秒级到分钟级。如果你需要毫秒级的新鲜度，传统的全文搜索引擎（如Elasticsearch）比向量数据库更好。

局限四：可解释性，向量数据库是"黑盒中的黑盒"

某医疗AI系统，需要解释"为什么推荐这个治疗方案"。向量数据库给出的答案是"这两条记录的余弦相似度是0.92"。但医生不可能接受这个解释。他们需要知道"因为这个病人的症状、年龄、既往病史与这3个病例高度匹配"。

传统数据库的查询是可解释的（WHERE age > 60 AND symptom = ‘chest_pain’），向量数据库的查询是黑盒的。这在医疗、金融、法律等合规要求高的场景中，是一个致命问题。

解决方案：将向量搜索的结果作为"候选集"，再用规则引擎或可解释的模型做精排。向量的分数只用于排序，不用于解释。

局限五：成本不可预测，向量数据库的账单是"惊喜"

传统数据库的查询成本是相对可预测的——一个查询消耗多少CPU和IO，可以根据索引结构估算。向量数据库的ANN查询成本取决于向量的分布、索引参数、并发量，很难精确预估。

某SaaS产品用Pinecone做搜索，上线第一个月查询量只有预期的30%，账单$800。第二个月产品上了推荐位，查询量暴涨到预期的500%，账单$14,000。CTO差点被CEO开除。

解决方案：设置查询量上限和告警，使用Serverless版本（按查询计费但更可控），或者自托管（固定成本）。

什么情况下你根本不需要向量数据库？

  1. 你的查询中精确匹配占比>80%：传统数据库+全文索引更合适
  2. 你的数据量<10万条：暴力搜索（numpy+faiss）毫秒级出结果，不需要专门的向量数据库
  3. 你需要复杂的结构化查询：SQL是你的朋友
  4. 你需要真正的实时搜索：Elasticsearch的向量能力虽然弱，但实时性更好
  5. 你的场景需要完全可解释的结果：规则引擎+传统搜索
  6. 你的预算有限且不可预测：向量数据库的SaaS定价模型对突发流量不友好

金句：向量数据库是工具，不是信仰。用对了场景它是神器，用错了场景它是负担。

正确的使用姿势：向量数据库不是RAG的全部

向量数据库在RAG系统中的正确角色是"粗筛"——从海量文档中快速找出Top-100个候选。然后交给Reranker做精排，交给LLM做最终判断。它不是"一搜定乾坤"的银弹。

金句：把向量数据库当成搜索引擎，把Reranker当成推荐系统，把LLM当成答案生成器。三者各司其职，你的RAG系统才能稳定工作。