知识库做到 100 万条以后，约六成企业的 RAG 项目开始暴露同一个症状：AI 答非所问、答得不全、甚至胡编乱造，但底层大模型毫无问题。问题出在哪？我们本周读了一份主流向量数据库的横向对比长文，结论是 — 大多数企业用错了基础设施。

这是什么

RAG（让大模型先检索公司文档再回答的方案）是当下企业 AI 落地的标配：先把文档切成段落，转成「向量」（一串代表语义的数字）存进专用数据库，提问时找出最相关的几段，再喂给大模型生成答案。

文章给出一个反常识判断：向量数据库「跑得快」不等于「答得准」。真正决定回答质量的指标是 Recall@K（前 K 条结果里命中真实相关内容的比例），而不是厂商宣传的 QPS（每秒查询数）。一个 3 毫秒响应的数据库，如果只召回了 70% 的相关内容，对企业来说就是灾难。

文章对比了 Milvus、Qdrant、Weaviate、pgvector、Pinecone 五大方案，把企业选型最容易踩的坑总结为：只看 QPS、忽略 P95/P99 延迟（最慢的那部分请求的响应时间）、不做混合检索、缺 Reranker（对初筛结果二次精排的小模型）。

行业怎么看

支持方判断直接：Milvus、Qdrant 在千万级数据、混合检索、高并发场景下，比 PostgreSQL 自带的 pgvector 稳定得多。一家金融知识库厂商实测，把 pgvector 换成 Milvus，召回率从 71% 提到 89%。

但反对意见同样值得听。一位长期做企业落地的架构师直言：「向量数据库被过度神化。」理由是：决定 RAG 质量的，是文档切分、Embedding（把文本转成向量的模型）选择、Prompt 设计这「老三样」，向量数据库只承担初筛环节。还有开发者认为，对 90% 的中小企业，pgvector 加一个轻量 Reranker 已经够用，花几十万年费上 Pinecone 是「用大炮打蚊子」。

对普通人的影响

对企业 IT：若公司正在采购或升级 AI 中台，建议把「召回率」和「尾延迟」写进招标需求文件，而不是只问「支持多少并发」。这两个指标直接决定员工愿不愿意用。

对个人职场：AI 产品经理、解决方案架构师岗位正从「懂 Prompt」升级到「懂检索链路」。理解召回与排序逻辑，会成为下一轮涨薪的硬通货。

对消费市场：短期无直接影响。但企业级 AI 客服、AI 助手准确率持续提升后，消费者遇到「答非所问的机器人客服」的频率，会在未来 12-18 个月明显下降。