去年开始，但凡做大模型应用，RAG架构里必定塞一个向量数据库。Milvus、Pinecone、Weaviate、Qdrant，名字轮番出现在技术方案里，仿佛不上向量库就不算AI原生。但到今年二季度，很多团队的复盘会变成了吐槽会：上了向量库，检索效果并没有预期的好，延迟、成本和运维复杂度反而先上来了。向量数据库正在从“大模型应用基础设施”变成“大模型应用新瓶颈”。
向量检索的核心假设是“语义相近的向量在空间中距离近”，但这个假设在真实业务里经常失灵。一个做工业设备手册问答的客户告诉我，他们用OpenAI的text-embedding-3-large把五千页手册向量化，用户问“液压泵异响怎么处理”，返回的前三条结果里有一条是“液压泵安装尺寸图”，cosine similarity都在0.85以上，但内容完全不相关。更隐蔽的是漏召：新品文档入库后，因为描述口吻和老文档不同，用户的口语化查询根本排不进Top-K。最后他们不得不在向量检索后再套一层重排序模型，推理成本直接翻倍，端到端延迟从800毫秒涨到了2.4秒。
向量数据库的硬件账单很少被放在方案PPT里细算。以OpenAI text-embedding-3-small输出的1536维、float32精度向量为例，单条占用约6KB。如果一个电商平台的商品SKU超过两千万，仅原始向量就需要120GB内存。为了做到50毫秒以内的延迟，通常要建HNSW索引，索引膨胀率再翻1.5到2倍，这意味着一套集群轻松吃掉300GB以上的内存。如果是云端托管服务，千万级向量的月费用往往在三千到五千美元级别。更麻烦的是写入放大：每次基础模型升级或维度调整，全量重新嵌入和重建索引的过程，能让一个八节点的集群满载跑上整整两天，期间查询性能波动极大。
很多人直觉上认为向量维度越高，语义表达能力越强，检索越准。但几何事实正好相反。当维度从384升到1536，向量点之间的距离分布会急剧收敛，最大内积搜索的区分度被稀释，出现所谓的“维度灾难”。我们内部用同一批十万条问答语料做过对照测试：用384维模型和1536维模型分别建库，前者的Top-5精确率反而高出4.2个百分点。高维空间里的“最近邻”概念，在数学上和人类理解的“最相关”已经不再是同一件事。盲目追高新维度，本质上是在用更贵的存储买更差的区分度。
向量数据库本质上是一个只读的异步副本库。商品下架了、价格改了、文档过期了，业务数据库里的UPDATE语句执行只需几毫秒，但同步到向量库却要经历“捕获变更→重新嵌入→删除旧向量→写入新向量→重建索引段”的漫长链条。一个金融客户遇到过典型生产故障：业务库里的理财产品收益率已经下调，但向量库里的旧摘要仍被RAG召回，大模型基于过时信息生成了回答，险些引发合规风险。他们后来不得不自己维护一套CDC链路加上延迟校验机制，这套代码的维护成本比业务库本身还高。
真正的问题不是向量数据库本身，而是“上来就先向量化一切”的误区。向量检索解决的是语义模糊匹配，不是精确查询。如果你的场景是“根据订单号查物流状态”，或者“筛选库存大于100且品类为母婴的商品”，传统B+树索引或倒排索引在延迟、一致性和成本上完胜。即便在RAG里，先用Elasticsearch做关键词过滤和权限裁剪，把候选集从百万级压到千级，再做向量召回，往往是更务实的分层架构。我们内部有一条朴素的经验法则：只有当用户query与目标文档存在显著的“同义不同词”鸿沟，且传统检索的漏召率超过15%时，才值得把向量检索作为第一级入口；否则，把它当成传统检索的补充品，而不是替代品。
向量数据库是大模型时代的重要工具，但它不是水电煤那样可以无差别接入的基础设施。当团队把向量库当成默认选项，而不去审视召回质量、硬件成本、维度选择和数据同步代价时，它就从应用的加速器变成了瓶颈。好的架构师会在白板上先画清楚业务数据流和查询模式，再决定哪一部分真的需要被“向量化”，而不是先拍脑袋上一个向量库，再硬着头皮填坑。
