掘金上一篇企业 RAG（Retrieval-Augmented Generation，给大模型外挂知识库）实战帖抛出一个数：90% 的团队搭 AI 知识库时，第一步就走错——架构师先拍板上一套分布式专用向量数据库（Milvus、Pinecone 等），配上云端托管和运维，上线第一天就崩在精度、运维、账单三个问题上。这篇文章的判断很直接：千万级数据量以下，企业根本不需要单独买向量数据库，一套 PostgreSQL 配 pgvector（向量检索扩展）和 BM25（经典关键词匹配算法）的「混合检索」，30 毫秒就能出高精度结果。
这是什么
企业做 AI 知识库，本质是让 AI 从公司内部文档、产品手册、工单里「查到资料再回答」。这事听起来简单，但检索环节最容易出问题。
过去一年流行的做法是「纯向量检索」：把每段文字转成一串数字（Embedding），靠数字相似度找答案。这种方法擅长「理解意思」——你搜「汽车坏了」，它能找到「发动机故障」。但碰到产品型号（GTX-4090-D）、人名（张伟民）、错误代码（Err-502）这种必须精确匹配的字符串，就抓瞎——要么召回一堆看似相关的废话，要么直接漏掉正确答案。
解决方案叫「混合检索」：一条路用向量做语义召回，另一条路用 BM25 做精确召回，最后融合排序。PostgreSQL 这款老牌数据库原本就能跑全文检索，加上 pgvector 扩展就能同时存向量，一套数据库搞定，省去「向量库 + 关系数据库」双写一致性的麻烦。
行业怎么看
支持方认为，这篇文章戳破的是企业 IT 圈的「工具崇拜」：不少架构师把「上分布式向量数据库」当成技术先进的标志，实际上大部分企业（数据量在千万级以内）根本用不到那个规模。这种「用牛刀杀鸡」的做法，不仅拉高账单，还带来运维负担和数据一致性问题。
但反对意见同样成立：这套方案的适用边界很硬——千万级以内可以，再往上走单机 PostgreSQL 撑不住，分布式向量数据库仍是必要的；同时「混合检索」听起来美好，实际需要团队同时懂 Embedding 调优、BM25 中文分词（要配 jieba）、RRF 倒数排名融合算法（把两路结果按名次合并打分），对传统行业 IT 团队门槛不低。换句话说，省下的不是技术债，是把这笔债挪到了「模型与算法调优」上。
对普通人的影响
对企业 IT：被供应商推销专用向量数据库时，先问一句「咱们的数据量级是多少」。千万级以内，PostgreSQL + pgvector + BM25 这条路值得先评估，省下的不只是钱，还有运维和合规复杂度。
对个人职场：RAG、向量检索、混合检索这些词，正在从算法工程师的专属词汇，扩散到产品经理、运营、IT 管理者的视野里。不需要懂实现，但下次和 IT 同事聊 AI 项目，至少能问出「咱们用的是纯向量还是混合检索」这种问题。
对消费市场：以后接 AI 客服、查产品手册，遇到「型号匹配不上」「错误代码搜不到」这类吐槽会变少——前提是企业 IT 真的把检索这层做对了。