最近看了不少AI应用的技术分享和架构推演发现一个很有意思的现象很多团队还没跑通一个完整的对话流程就已经在规划“向量库选型”了。有人因为“别人都在用Milvus”而选了Milvus有人因为“Qdrant快”就上了Qdrant还有人直接让运维去搭一套Elasticsearch再加向量插件。我每次看到这种场景都会问一句你现在的业务真的需要向量检索吗你知道你要解决的到底是“语义匹配”问题还是一个普通的“查表”问题吗这篇文章不劝退任何人只想说清楚一件事向量数据库是一个好工具但它有自己的适用边界。很多AI应用在最早期阶段根本用不上它甚至上线后很长一段时间内传统数据库加上一点简单的检索技巧就能解决90%的问题。先搞明白这一点再决定动不动架构能帮你省下一大笔基础设施成本也省掉不少运维层面的麻烦。1. 先搞清楚向量库究竟在解决什么问题很多人把向量库想得太玄了。它本质上做的事情还是“搜索”。只不过传统数据库用关键字精确匹配向量库用向量做近似匹配。它的核心能力是把一句话、一张图、一段音频转成一组高维数值然后在这组数值附近找最相似的邻居。常见场景包括文档问答的召回、以图搜图、语义搜索、推荐系统里的相似商品匹配等。但要注意向量库解决的只是“相似度检索”这一环。它不管你的文本是怎么被切成块的不管你的向量是怎么算出来的更不管你召回之后有没有做重排。很多AI应用的关键瓶颈根本不在“相似度检索”上而在内容本身的质量、切分策略和召回后的处理流程上。把向量库当成AI应用的地基其实是一种认知错位。还有一个容易被忽略的事实向量检索是一种“模糊匹配”它天生就有不确定性。用户明明搜的是“iPhone 15价格”你召回的可能是一堆“iPhone 15评测”因为语义上它们足够相似但对用户来说结果就是不对。很多业务场景要的是“确定性的精确匹配”这时候向量库不但帮不上忙反而会因为召回了“看似相关”的结果把准确率拉低。所以第一步永远是想清楚自己的需求属于哪种类型。如果需求本质上是精确匹配、规则过滤、区间查询那这就不是向量问题你需要的可能只是一条SQL。这个是后面所有决策的基础。2. 用四类场景自测你的核心是不是“向量难题”判断一个AI应用是否真的需要向量库我通常用四类经典场景来对照大家也可以拿来自测。2.1 RAG问答切分和检索只是表面问题文档问答是向量库最常见的宣传场景。事实上RAG大模型检索增强生成确实需要把文档切成片段转成向量然后检索出最相关的内容喂给大模型。但这个流程里真正决定回答质量的因素是先天的你喂给大模型的文档内容是否准确、切片是否合理、提示词是否清晰。向量检索只是中间的搬运工。很多人的文档总共就几百页片段也就几千个完全可以在推理时把问题扔给大模型做关键词抽取再走一次全文检索甚至直接让大模型读一遍整份文档在上下文窗口允许的范围内效果往往也不差。只有当文档规模大到超过模型上下文窗口且问答延迟有要求时向量检索才有不可替代的优势。2.2 语义搜索用户要的可能只是“搜索框”做电商和内容社区搜索时很多人觉得“必须上语义搜索”于是把商品标题、描述全部向量化。但实际上用户在搜索框里的输入大多数是品牌名、品类名、型号这类确定性的词。比如搜“小米空气净化器”用户期望的是精确返回小米那个净化器而不是“空气净化器推荐”。这种情况下传统的关键词匹配加上同义词映射已经能覆盖绝大多数需求。语义搜索真正有价值的场景是用户输入和库内内容“字面上完全不一样”时。比如搜“适合送女朋友的礼物”库里的商品标题全是“永生花礼盒”“香薰蜡烛”关键词完全对不上。这种场景才需要语义匹配。如果你的搜索词和业务数据之间本来就存在明确的对应关系向量检索就是过度设计。2.3 推荐系统别把“相似度计算”等同于“向量库”做“猜你喜欢”类功能时优化点往往在特征工程和候选召回策略上。向量库可以做召回但召回不等于推荐。一个简单的协同过滤基于用户历史行为去重排效果通常就比单纯向量相似推荐要好。尤其是用户行为数据累积之后传统推荐算法已经足够稳定没有必要为了引入向量而引入。2.4 去重与聚类数据量不够大时暴力算法足够相似文章去重、日志聚类、异常检测这类场景是做向量相似度匹配的传统优势区。但这里有个线性复杂度的问题几百条文本千级别聚类用简单的TF-IDF加余弦相似度跑一遍全量计算大概也就几百毫秒到一两秒完全没有性能压力。只有当数据量到达百万级全量计算变成分钟级甚至小时级时向量索引才真正体现价值。你看四类常见的AI应用场景里至少有两到三类在早期阶段都承载不起“向量库”这三个字。它们缺的更可能是数据质量、搜索策略和特征工程而不是一个专门的向量存储系统。3. 不引入向量库也能跑的平替方案我实际测试过我自己在项目里做过几组对比实验在不引入任何专门向量库的情况下用传统手段解决AI应用里的召回问题效果超出预期。下面列出三种方案大家可以根据自己的技术栈对号入座。3.1 SQLite自带全文检索FTS5轻量场景的扫地僧如果你的数据量在几十万条以内应用又是单机或轻量服务SQLite的FTS5完全够用。它是基于BM25算法的全文检索配合中文分词或拼音转换对产品名、文章标题、FAQ问答对这类短文本的召回效果非常扎实。我做过一个测试三千多条产品FAQ把问题和答案拼接成一条文本建立FTS5索引。用户提问的时候先把问题里面的语气词、停用词洗干净再交给FTS5检索。测试下来Top3答案里能命中正确答案的情况大概在75%左右。对于一个预算有限的MVP来说这个反馈比上向量库快得多而且几乎零运维成本。3.2 PostgreSQL普通索引 trigram中等规模的首选数据量到了几十万条到百万级SQLite开始吃力这时候我通常会转向已有技术栈里往往已经存在的PostgreSQL用它自带的pg_trgm扩展做模糊匹配。pg_trgm本身是三元组索引它支持基于字符串相似度的like查询优化对英文场景尤其友好对中文场景配合分词也能用。另外更推荐的做法是在PostgreSQL里直接为关键列建全文搜索索引tsvector或者用ILIKE加pg_trgm索引。多数应用的关键词搜索用这一层已经能扛住很高并发。我在一次数据清洗项目中用PostgreSQL的pg_trgm索引在八十万条商品记录里做模糊匹配单次查询耗时在30毫秒以内而当时的业务只是需要一个“用户输了近似关键词也能找到商品”的功能。3.3 规则过滤加关键词解析最“笨”但最稳的方案有些场景连全文检索都过度了。比如用户输入的是“温度调到25度”“把客厅的灯关掉”这类智能家居控制指令本质上是意图识别加实体抽取不需要任何相似度匹配。直接做规则解析、意图分类命中准确率能做到95%以上。还有个常见场景是智能客服的“问句命中”。很多企业客服系统里的问题其实是有限的客户问来问去就那么几十个问题。你完全可以把常见问题抽象成几个pattern用代码硬匹配甚至用大模型做一次性离线分类生成一个“问题到标准问法”的映射表。线上请求来了做精确查询就够了。这听起来很土但它快、准、容易排查可解释性还强。这三个方案的共同点是它们都能在你现有数据库里直接实现不需要额外引入任何基础组件。对一个项目初期尽量少加独立组件是控制复杂度的第一原则。4. 到底该不该上用四个信号做判断如果你拿不准自己的项目处在哪个阶段我总结了一套更简单的判断法则从四个维度给自己打个分。其中任何一个维度亮了红灯都说明你应该暂缓上向量库的心。4.1 数据量一万条以下别谈索引优化一个很实在的数字参考一万条记录每条一个1500维的向量在内存里全量暴力扫描一次查询的耗时大概在几十毫秒量级这还是在单台普通机器上实现的。如果你的数据量只有这个规模根本不需要任何索引结构。直接用内存数组存向量循环计算余弦相似度就是最简单可靠的方案。数据量到几十万条量级内存扫描开始有压力但依然可以在应用启动时构建一次内存索引后续增量更新放后台。只有到达数百万条且必须支持在线低延迟查询时向量索引的选择才变得不可回避。很多做成“每天跑一次全量计算”的场景实际上连内存方案都不需要。4.2 实时性凌晨跑任务还是用户正在等你如果向量索引是异步构建的对索引更新的实时性没有秒级要求那Batch方案就完全能应付。比如“每天凌晨重算一遍库里的文章向量白天提供检索”这种场景用离线任务加内存索引就够了根本用不上分布式向量库。很多团队引入大规模向量基础设施但业务真正的实时性需求只是“几分钟内能看到新内容”这其实和向量库无关。如果你的应用要求秒级写入并且马上能被检索到对索引写入和查询的并发度都有硬性要求这时候向量索引的工程复杂度才开始显现。记住一点实时性要求越高系统的所有环节都要配合升级成本是成倍涨的。4.3 召回准确率模糊匹配能接受吗有些业务对召回结果的“确定样式”要求极高。比如账单查询用户输入“上个月的水电费”你返回了“上上个月的煤气费”即使语义相似这也是一次失败查询。这种业务应该用结构化查询加约束条件而不是向量相似度召回。反过来如果业务本身是内容推荐、资料查找这类“有一定模糊度也不影响体验”的场景向量检索才有发挥空间。你可以在上线前准备一百条典型查询分别用向量召回和传统关键词召回跑一遍准确率对比。谁更匹配业务预期一目了然。4.4 团队维护成本没人是全职调参的最后一个维度也最容易被忽视你们的团队有没有人能长期维护这套系统向量库不是装完就完事的。索引参数HNSW的M值、EF值、向量维度选择、相似度度量余弦、内积、欧氏距离、离线评估集这些都需要有人长期调优和监控。小而精的团队与其花精力维护这套东西不如把时间花在业务数据清洗和提示词设计上ROI高得多。这四个维度之间不是孤立的。比如数据量大但精确性要求高你首先该考虑的是怎么把“精确过滤”做在“向量召回”之前而不是直接把模糊匹配当唯一手段。数据量中等但实时性要求高选一个带HNSW索引的嵌入式方案即可没必要上分布式。为了更直观一点我把常见组合和推荐做法整理成一张对照表场景数据规模精确性预期推荐做法小型FAQ / 文档问答1千~5万片段中全文检索 规则解析或纯上下文窗口中型商品搜索10万~100万商品高品牌/型号Postgres全文索引 pg_trgm内容社区语义推荐10万~500万内容低允许模糊内存向量索引或pgvector HNSW大规模多模态检索500万以上中专用向量数据库 分层召回日志/异常聚类不限低离线Batch 聚类算法无需在线索引智能控制指令数千条规则极高规则解析 / 意图分类这张表不是绝对标准但它能帮你在做技术选型前先给自己一个踏实的定位。5. 如果你确实要上选一条最轻量的路排除那些纯为了赶时髦的情况确实还有一部分场景是必须上向量检索的比如几百万条内容的语义搜索或者多模态素材库查找。那我的建议是从最轻量的方案开始一点一点增量演进不要第一天就上一整套专用向量数据库。5.1 在现有PostgreSQL里直接启用pgvector如果你已经在用PostgreSQLpgvector是绝对的首选。你不需要为它多部署一个服务只需要在数据库里启用扩展加一张带向量列的表格再建一个HNSW索引就行。如果你的数据量在几十万到几百万量级pgvector完全够用维护成本几乎为零查询语句也和普通SQL没有区别。我在一个二手商品的语义搜索项目里用pgvector存了大概三十万条商品描述向量HNSW索引构建时间大约花了三分多钟单次查询耗时在20毫秒上下生产环境稳稳跑了大半年。这个量级如果当初上了Milvus或者Weaviate光运维成本就够我们团队喝一壶的了。5.2 只在服务端做轻量嵌入计算另外注意向量库解决的是存储和检索问题它不负责计算向量。嵌入模型embedding model的选择和调用往往占用的成本和复杂度比向量库本身还高。在一个轻量方案里你可以把嵌入模型跑在内部服务上甚至用LLM接口做嵌入计算每一次插入和检索的时候实时算向量。这样做的额外好处是你不需要事先把所有内容做离线向量化检索前动态计算一个查询向量再交给pgvector索引去召回即可。这套架构对“小数据集、需要语义匹配”的场景非常友好扩展升级时只需要换一列向量维度。5.3 专用向量库的入场条件专用向量库Milvus、Weaviate、Qdrant等适合什么样的场景大数据量千万级以上、高并发在线检索、多租户隔离、托管式运维需求并且团队已经配备处理分布式系统的人。如果你的项目还没到这一步可以先继续用轻量方案等技术选型时发现架构瓶颈再来迁移。“先跑起来再演进”这条原则不只是用在向量库上对所有基础设施都适用。你完全可以在产品验证阶段用最简单的方式支撑起全部功能等用户规模和数据量逼着你升级时再上更复杂的系统。那样你升级前的数据积累也会让你的检索效果验证更有底气。6. 我亲历的三次“没有向量库就卡住”的错觉讲了这么多方法论我还是想用一个老项目的三次经历来终结这个疑问。6.1 第一次意图路由我差点用向量库当时做智能客服需要区分用户是想查订单、退款还是投诉。一开始我下意识以为要做“语义匹配”把所有问题文本向量化然后查最近邻。结果调试了几天发现准确率总是卡在70%上下因为用户表达的变体太多了向量空间里的区分度根本不够。后来我换了个思路把问题类型从接到的工单数据里统计出来人工梳理出每种类型的核心关键词和句式再用规则引擎先匹配匹配不到的才交给大模型做一次分类并返回置信度。上线之后规则引擎包住了85%的流量准确率做到了97%剩下的大模型兜底也几乎不会犯错。这个系统跑了一整年没有一行向量检索代码。那次我体会最深的一点是如果规则能解决就不用模型如果精确匹配能解决就不用模糊匹配。向量检索是最后一道闸不是第一道门。6.2 第二次电商搜索关键词先赢了另一个项目是给一个自营电商平台做搜索优化。当时数据分析显示用户搜索词里有超过60%是带有明确品牌名或商品型号的比如“飞利浦剃须刀PQ206”“2023款iPad”。这类词做向量匹配召回一堆外观相似的“飞利浦”或者“iPad保护壳”用户立刻流失。我最终的做法是在原有SQL检索基础上增加品牌、型号、分类的精确过滤再叠加一个同义词表。测试下来核心搜索词的结果准确率从原来的62%提升到了91%这个数字在没有引入任何向量索引的情况下就完成了。后来为处理一些“送女友”“适合跑步”这类泛意图查询才补了一个轻量级的向量召回分支但它的流量占比只有不到10%。6.3 第三次多模态素材库发现用户根本不需要“相似”还有一次做企业内部知识库检索领导说“要用多模态检索员工上传的图片和视频”。我们都往多模态方向想结果测试用户反馈是他们搜索的时候根本不需要“感知相似”的图片他们想要的是“知道图片里有什么内容”的精确查找比如搜“去年年会合影”“市场部Q3报告”。这种需求实际上是对标签和元数据的检索不是向量相似度。最终我们用传统的OCR加标签系统给每个素材人工自动打上内容、部门、时间标签然后做精确过滤和全文检索体验远超预想。所谓“多模态”的诉求被我们拆解成了一个“元数据管理”需求。这三个例子都在说同一个道理我们太容易在碰到问题的时候给自己找一个“听起来很技术”的解决方案却忽略了对业务本身的深层理解。向量库是工具箱里的一把好扳手但你得先确认自己面对的是螺丝而不是已经生锈的铁钉。我的体会是选型这件事最后拼的不是谁的方案更先进而是谁的方案更合身。多问自己几次“这一环真的需要向量库吗”比盲目跟风架构升级更能带给你长期收益。如果你的项目正好在犹豫先拿一张纸把上面那四个维度过一遍很多答案会自己浮出来。