企业官网建设流程全解析

最近好几个做AI应用的朋友跑来问我："是不是应该赶紧把向量库接上？不接是不是就落后了？"我一般先反问一句：你的应用里到底哪一环需要向量库？如果答不上来，那就先把钱和服务器预算省下来。这个问题不是抬杠，而是我在实际项目中见过太多"为了用向量库而用向量库"的案例，最后要么性能没提升、要么运维成本翻倍，甚至悄悄拖垮了整个应用。

先说结论：向量库不是AI应用的入场券，它是一个特定场景下的"相似性搜索"工具。用得好的话，它能让你的AI应用在语义检索、推荐、去重、多模态匹配这些地方如虎添翼；用不好的话，它就是一个吃内存、占CPU、让团队加班的无底洞。所以这篇文章不劝你上向量库，也不劝你别上，而是分享一套我自己判断"是否需要向量库"的框架，以及踩过的坑，希望能帮你少做几个深夜决策。

1. 别被"上向量库"的风吹晕：先搞清它解决什么问题

1.1 向量库到底是什么，为什么最近这么火

很多人一听到向量库，第一反应是"新数据库"。其实它的核心能力就两个字：召回。你把一段文本、一张图片、一段音频，通过嵌入模型变成一个几百维甚至上千维的向量，然后向量库帮你在海量向量里快速找到"最相似"的那一批。什么是相似？在向量空间里，两个向量距离越短，语义就越接近。"苹果"和"梨"的距离，比"苹果"和"路由器"的距离要近得多。

为什么这两年它变得特别火？因为大模型应用爆发了。大模型本身"记不住"你的私有数据，所以就有了RAG（检索增强生成）这种套路：先把你的文档切块、向量化、存进向量库，等用户提问时，先从向量库检索出最相关的几块内容，塞给大模型，让它基于这些内容回答。这个流程跑通后，"文档问答""智能客服""私有知识库"这些应用一夜之间全起来了，向量库作为其中关键一环，自然被推到了风口浪尖。

再加上多模态模型的发展，图片、音频、视频都能被编码成向量，产品经理一听"能用自然语言搜图搜视频"，立刻就想上向量库。热度一高，就容易泥沙俱下。很多人还没想清楚业务场景，就先照着教程搭了一套Milvus或者Qdrant，给自己营造了一种"技术先进"的安全感，但等问起"你的索引参数怎么配的、召回率多少、延迟能不能扛住"，就答不上来了。

1.2 你的AI应用里，到底哪一步需要"相似性搜索"

我们需要把AI应用拆开看，它到底由哪些环节组成。现在的AI应用，主要分三层：输入理解、逻辑处理、输出生成。输入理解靠大模型或小模型做意图识别、实体抽取；逻辑处理靠代码、工作流、Agent；输出生成靠大模型写文字、画图、语音合成。那么向量库插在哪？它插在"逻辑处理"和"输入理解"之间：当输入进来后，你要从已有知识中找出"和它最相关的信息"，这需要相似性搜索。

如果你的应用不需要从一堆历史数据里捞出"最相关内容"，那就暂时不需要向量库。比如一个AI聊天机器人，如果只是把用户问题直接转发给API，然后返回结果，这根本用不上向量库，你需要的是API网关、缓存、限流。再比如一个简单的表单识别，图片进来后通过OCR变成文字，然后规则提取字段，也无须向量检索。所以先做功能梳理，标出"检索/匹配/推荐"这一步，再谈要不要上向量库。

很多所谓的"AI智能体应用"也一样。智能体本质是规划、调用工具、编排流程，它的核心其实是一个调度器。只有在某个工具需要"在知识库里找最相关内容"的时候，才需要向量库。其它环节，比如选择工具、生成回复、判断下一步动作，用大模型本身的能力就够了。如果整个智能体没有一处涉及"从历史数据中找相似"，那向量库就不是它的必备件。

1.3 一个例子：客服问答机器人的"记忆"到底放哪

我拿最常见的客服问答机器人来说。很多人说："我想让机器人记住用户之前问过什么，所以我要用向量库。"注意，这个想法本身就有问题。对话历史需要的是"记忆"，不是"相似性搜索"。"记住上一个问题是什么"这属于状态管理，用一个简单的Redis或数据库表就能解决。只有当你希望"根据用户当前这句话的语义，从几千篇文档里找出最匹配的答案片段"时，向量库才有用。前者是KV存取，后者是ANN检索，别混为一谈。

举个反例：有个团队做了一个"ChatGPT+帮助文档"的客服机器人，最开始只是拿正则在FAQ里匹配关键词，用户问"怎么退款"，FAQ里写的是"退款流程"，正则配不上，机器人就瞎了。后来他们把FAQ和产品文档全部向量化，接到向量库，用户用自然语言提问，也能从文档里捞出一段靠谱的答案。在这个例子里，向量库解决了"同义改写后的语义匹配"问题。如果你手头只是几十条FAQ，完全用不上向量库，写个关键词映射表就够了；但如果是几千篇文档、几万条历史工单，那才是向量库的主场。

所以，判断要不要上向量库，第一步不是去安装它，而是问：我手里到底有没有"需要靠语义来找答案"的数据？如果没有，强行上也不会带来业务提升，只会让系统多一个故障点。

2. 自检清单：用这5个问题判断你是否需要向量库

别上来就选型，先做一次体检。我把判断维度浓缩成五个问题，全部问完，你基本就有答案了。

2.1 问题一：你的数据是"非结构化"且量大吗

向量库擅长处理的是几乎无法用规则穷举的内容：自由文本、图片、音频、视频、源代码、日志。如果你的数据原本就是一张表里的"产品名称""订单状态"，那SQL查询已经够了，强行embedding反而丢失精确性。判断标准很简单：你是否需要"根据语义去查找"，而不是"根据某个字段去等值匹配"？同时，这个数据的量级是否达到几千条以上？或者单条内容长度是否超过几百字？

如果只有几百条数据，说实话，直接在内存里遍历计算余弦相似度也就几十毫秒，根本不需要引入索引。等数据量到了几十万条，线性遍历会延迟到秒级，这时向量索引的优势才真正体现。量小用numpy暴力算，量大才需要专门的库，这是很多新手的盲区。很多团队拿一个几百条数据的Demo跑出了"惊艳效果"，于是信心满满上线，结果一接真实数据，索引构建慢、内存吃紧、查询延迟飙升，才回过味来。

另外，你的数据是否"脏"也很关键。如果文本是OCR出来的乱码、日志里大量的拼接噪声，纯向量检索的效果会大打折扣。因为嵌入模型对"语义完整"的文本更敏感，乱码没太多语义可学。这种情况下，先在前面加一道清洗流程，可能比上向量库更重要。

2.2 问题二：你的查询是"模糊匹配"还是"精确匹配"

什么叫模糊匹配？用户说"我的订单没发货"，文档里写的是"物流状态为运输中"，这两句话没有一个共同关键词，但语义等价。这种场景适合向量检索，它能把"没发货"和"运输中"映射到相近的语义空间。什么叫精确匹配？查订单号、查身份证、查用户是否存在于黑名单。这种绝不能交给向量检索，因为向量检索是"近似正确"，它可能把"110108"和"110109"当成邻居，但业务上这两个号完全不同。

最理想的做法是混合检索：先用关键词精确命中，再用向量召回补足语义。如果你的业务里90%的查询都是精确匹配，那你真不需要为那10%的模糊查询搭一套向量库，直接用搜索引擎或关系型数据库的全文索引就够了。反之，如果查询几乎全是口语化、没固定模板的表达，那向量检索的价值就很高。

这里面有个容易被忽略的技术细节：向量检索的"距离"和业务意义上的"相关性"不一定是一回事。比如用户搜"便宜的手机"，向量库里可能会把"价格低"和"质量差"拉得很近，因为它们在语料里经常共现。所以你不能只依赖语义相似度，还要结合业务规则做二次过滤。

2.3 问题三：实时性要求有多高

这里的实时性包含两层：一是写入实时性，二是查询实时性。很多AI应用要求文档上传后立刻能被检索到，这就需要向量库支持增量索引、实时更新。传统的一些向量库，新增数据要构建新的索引，甚至需要全量重建，那就没法满足"秒级可见"的需求。如果你的场景是每天定时同步一次，那离线批量构建索引完全足够，用轻量级方式就行。

查询实时性也要想清楚：用户在页面上输入关键词，你给多少毫秒的响应？如果容忍200ms以上，很多方案都可以；如果要求50ms以内，那就要上专业的HNSW、PQ索引。但这里有个隐含成本：向量检索常常需要把向量加载到内存里才能保证速度，数据量一大，内存开销就是天文数字。实时性要求越高，越要评估硬件成本是否值得。很多团队只算了CPU和GPU的钱，忘了算内存的钱，结果月底账单出来傻眼。

如果对实时性要求很高，另外一个替代思路是把检索结果缓存起来。热门问题在第一次检索后，直接把答案或检索出的文档ID存到缓存里，后续进来直接命中缓存，这能大幅降低向量库的QPS压力。向量库做"冷启动"和"长尾查询"，缓存做"高频查询"，两者配合比单纯堆向量库副本要省钱得多。

2.4 问题四：团队有没有能力运维一个分布式存储

这是最容易被忽略的问题。向量库本质上是一个数据库系统，你一旦上了生产环境，就要面对部署、扩容、备份、监控、版本升级、故障恢复这一大堆事。如果你的团队只有一个后端工程师，平时还要兼顾前端和运维，那我建议你尽量找托管服务，或者选择那些本身就在现有数据库里的向量插件，避免再引入一个需要单独维护的组件。

我见过太多小团队一开始用开源向量库，兴致勃勃搭起来，跑了两个月，突然某个节点挂了，因为没有备份机制，索引丢了，得重新全量灌数据。这种事故在非核心场景还能忍，在核心业务上就是灾难。所以先问自己：如果向量库凌晨3点挂了，你能在30分钟内恢复吗？不能，就考虑托管或简化方案。

还有一点容易被忽略：数据从业务库到向量库的同步。你不可能只写一份数据，通常业务库一份、向量库一份，中间可能还有别的存储。这就会出现"两套系统间数据不一致"的问题。埋点、补偿任务、幂等写入，都是额外的工程活。要是没有同步链路设计，很快你就会遇到"向量库里搜到了已经删除的文档"这种诡异问题。这种工程复杂度，往往比跑通一个Demo多出十倍。

2.5 问题五：你的业务场景是"一次性"还是"持续演进"

如果你的AI应用只是一个Demo、一个比赛项目、一次内部技术验证，那我不建议为一个可能下个月就不维护的原型搭正式向量库。你完全可以用开源的轻量方案在本地跑通，甚至直接在内存里做暴力检索。反过来说，如果你的目标是把某个场景做成长期产品，每天都有新数据进来、查询模式会变化，那才值得认真地选型、设计索引、建立监控。

持续性还有一个含义：你的向量化Schema会不会变？嵌入模型的版本会升级、文本切分策略会调参、业务数据的字段会增加。一旦这些变了，已经存储的向量可能就"失效"了，需要重新embedding。这个成本非常隐蔽，很容易在迭代两三个版本后爆发。如果你的业务迭代节奏很快，就要考虑设计好版本管理，或者干脆等业务稳定了再上向量库。

我有个前同事做内容推荐，一开始用某个开源嵌入模型给文章打向量，半年后效果不如新出的模型，于是他们决定切换。结果一算，全量120万篇文章要重新编码，按当时GPU的吞吐量，要跑三天，还得暂停写入。这事让他们痛苦了很久。后来他们学乖了，在文章表里加了一个embedding_version字段，每次切换模型都不动线上库，而是后台分批重算，验证好了再切换读取路径。这就是典型的"持续演进"思维。

3. 不需要向量库时，你其实有更轻的替代方案

判断完发现不需要向量库，这是好事。我见过太多人不知道除了向量库之外还有一堆简单方案，下面几个是我常用的。

3.1 关键词搜索 + 倒排索引：很多场景足够

一说到搜索，很多人只想到向量。其实传统的倒排索引在很多场景下依然能打。比如Elasticsearch，基于Lucene的倒排索引，支持分词、同义词、正则、模糊匹配。它虽然不理解语义，但可以通过同义词扩展、n-gram切分来近似实现"一定的语义匹配"。我做过一个内部工具文档搜索，文档量大概5万篇，用ES默认标准分析器，用户搜索"如何重置密码"，能命中"重置口令？修改密码？"这样的变体，靠的就是同义词过滤器和ngram。

关键点在于：倒排索引不需要额外生成向量，不需要训练的嵌入模型，索引构建和维护都成熟稳定。如果你的文本是技术文档、FAQ这种术语相对固定的，关键词搜索配上同义词典，完全够用。很多人骨子里没去过这个选项，直接跳到向量库，然后写了一堆embedding代码，纯属绕路。

不过也要说清楚，倒排索引的"同义词"需要人工维护。如果你们的业务词表更新很频繁，比如新系统、新功能的上线会带来大量新词，那么维护一个高质量同义词典也是一份持续的运营工作。从这个角度看，词表小、变更慢的场景，倒排索引非常划算；词表巨大且不断膨胀的场景，向量库反而省心。

3.2 关系型数据库的全文索引或JSON字段

如果你本身就在用PostgreSQL或MySQL，那么可以先试试它们的全文索引。PostgreSQL的tsvector不仅支持全文检索，还支持一些简单的加权和排名，配合pg_trgm插件甚至能做模糊匹配。很多AI应用的表就是一张消息记录表，客户发来一条文本，你要在历史消息里找出类似句子。如果量级不超过10万行，pg_trgm+gist索引的相似度搜索其实能扛住。

再退一步，如果你连全文索引都不需要，只是要把查询出来的结果喂给大模型，那关系型数据库存原始文本就够了。很多AI应用的"知识库"就是几百条帮助内容，放在一张表里，先按分类筛选，再用关键词粗筛，最后全部塞给大模型重新整理输出，效果也不差。别被"RAG一定要有向量库"的叙事绑架。

PostgreSQL还有一个潜在的好处：它自带SQL支持，你可以轻松实现"向量检索 + 业务过滤"的组合查询。比如"找10条和这个客户投诉内容最相似的工单，但只查询本月、高级会员、未解决"这些条件，如果数据量不大，一个SQL就都搞定了。而独立的向量库往往首先要做一次粗召回，再做标量过滤，逻辑串起来复杂很多。

3.3 简单规则、缓存和外部服务

有些场景甚至连索引都不用建。比如某种AI智能体应用，它需要根据用户指令触发不同的工具调用。很多人习惯把所有指令embedding，然后在向量库里找最接近的"意图模板"。但如果你的指令模板只有十几个，那你完全可以用一个规则引擎、或者直接让大模型做一次意图分类。大模型本身的分类能力已经相当强，让它输出一个JSON意图标签，简单可靠。

再比如热门话题缓存：用户问题中的高频重复项，可以先做一个相似度阈值判断，命中缓存就直接返回。这个判断甚至可以用本地哈希+编辑距离，不必推向量。我在做运维AI助手时，就先用大模型做意图分类，然后走workflow分发，最多用字典匹配，根本没用向量库，系统稳定性和响应速度都让人满意。

外部服务也是一个突破口。如果你的应用短期内离不开语义检索，却又不想自己维护索引，那就直接用云上托管的搜索服务，它们往往已经内置了向量检索能力。这类服务的优点是：索引的扩缩容、备份、滚动升级都由平台方负责，你只管API调。缺点是：可能面临供应商锁定、成本更贵、数据合规问题。因此，如果业务对数据主权要求很高，托管方案就要慎重考虑。

3.4 什么时候该用"专业搜索服务"而不是自己搭

如果你的确需要"语义检索"能力，但团队不想背着运维包袱，那就别自己搭。现在很多云服务商都有现有搜索引擎的向量扩展能力，或者独立的向量检索托管服务。还有一类是融合了关键词+向量的"混合搜索服务"，对中小企业来说性价比很高。

我的建议是：上线初期，能托管就托管，先把业务跑通。等数据量和QPS证明自建是值得的，再考虑把组件迁到自己机房或K8s集群。这个"先租后建"的思路能让你避免在项目初期就把精力耗在基础设施上。我不是说自建不好，而是说，上不上自建向量库，必须由业务数据而不是技术潮流决定。

当然，托管服务也不是没坑。我就遇到过托管服务在深夜发工单说索引状态异常，问客服半天没回应，最后发现是底层维护把所有索引重建了一遍。这件事耽误了我们一个上午。所以在选托管服务前，一定要看它的SLA承诺，以及是否支持一键导出全部数据。别等到迁移的时候才发现数据被锁在里头。

4. 真正需要向量库时，怎么选型和落地（实操）

如果五道自检题都说明你需要向量库，那就认真对待。这一节我会讲一下选型思路和落地时容易踩的坑。

4.1 三种常见架构：独立向量库、数据库内置向量、搜索服务集成

第一种，独立向量库。代表有开源的Milvus、Qdrant、Weaviate，以及轻量的Chroma等。它们专门为向量检索而生，性能好、索引类型多，支持HNSW、IVF、PQ等，还能做标量过滤。缺点是又要多运维一套系统，数据同步链路也可能变得复杂。

第二种，数据库内置向量。比如PostgreSQL的pgvector、SQLite的sqlite-vec，以及Redis的向量搜索模块。这种方案适合中低并发、数据量在几十万级以内的场景。优点是可以复用数据库的事务和备份能力，缺点是索引构建和高级查询能力有限，超大容量下性能不如独立向量库。

第三种，搜索服务集成向量。比如Elasticsearch从8.0开始原生支持kNN向量检索，OpenSearch也有对应插件。这类方案适合你原本就有全文搜索需求，同时想加上语义召回的场景。能统一处理关键词和向量混合检索，但要注意ES的向量索引是基于segment的，删除更新很频繁时会产生过多残余，影响性能。

我建议：中小团队优先选pgvector或ES托管服务，先不要把系统搞得太复杂。等业务验证真的需要更大规模、更低延迟，再迁移到独立向量库。选型不是选"最强"，而是选"最配"。配你的规模、配你的团队、配你的运维能力。

4.2 从0开始做一个RAG问答应用的向量检索配置示例

这里我写一个最简的pgvector配置过程，带大家过一遍核心步骤。前提是你已经有PostgreSQL，并安装了pgvector扩展。

-- 安装向量扩展 CREATE EXTENSION vector; -- 创建文档表，content存原文本，embedding存向量 CREATE TABLE documents ( id BIGSERIAL PRIMARY KEY, content TEXT, embedding VECTOR(768) ); -- 创建IVFFlat索引（以余弦距离为例） CREATE INDEX ON documents USING ivfflat (embedding vector_cosine_ops) WITH (lists = 100);

这里的768维需要和你选的嵌入模型对齐，比如常见的text-embedding-ada-002是1536维，bge-m3是1024维，768用的是一些开源模型如sentence-transformers的all-MiniLM系列。维度过高时，IVFFlat的lists数量应该根据数据量调，一般取sqrt(N)附近。比如数据量10万条，lists可以取300左右。索引创建后，查询时用：

SELECT id, content, 1 - (embedding <=> query_embedding) AS similarity FROM documents ORDER BY embedding <=> query_embedding LIMIT 5;

这里<=>是余弦距离运算符，相似度排序取出前5条。注意在查询前最好设置SET ivfflat.probes = 20;，增加探针数量能提高召回率，但会牺牲一定速度。还有一个大坑：IVFFlat索引的分簇是基于已有数据构建的，如果你的表初始数据很少，索引效果会很差。最佳实践是先灌入足够的数据再建索引，或者用HNSW索引（在pgvector 0.5.0+可用）避免这个问题。

-- HNSW索引在数据稀疏时更健壮 CREATE INDEX ON documents USING hnsw (embedding vector_cosine_ops);

如果要把这个流程做成应用，还需要写一个后台任务，把文档切块、调用embedding模型、把内容+向量写入表。切块大小我在实践中常用256~512个token，重叠20~50个token，保证上下文不撕裂。向量写入最好批量插入，不要一条条地循环commit，不然性能极差。我自己踩过坑：一开始也是逐条insert，结果6000条数据写了半小时；改成批量之后，几秒钟就完成了。这个小问题很容易被忽略，但在数据量大时差距是质变。

另外，不要忘了建立"内容去重"机制。向量化本身不会帮你识别重复文档，两条内容高度重复的文档，向量也很相似，查询时可能返回一堆重复结果。你可以在写入前先算一次相似度，和库里已有文档比较，超过某个阈值就跳过，或者把内容哈希存起来做精排。

4.3 数据量、维度、召回率评估的实用指标

在落地向量检索时，不能只看"能用"，还要看"能不能稳定好用"。我建议关注三个指标：召回率、QPS、内存占用。先做小样本测试，真实业务数据里取几百条带标签的问题，比如一个问题对应一个正确文档。跑查询后看Top-5命中率。常用做法：构造1000个问题，每个问题知道标准答案文档ID，然后看向量检索返回的Top-5里是否包含标准答案。如果召回率低于70%，先别急着调库，去看看你的文本切分、嵌入模型选型是不是出了问题。

QPS方面，如果是低并发（并发小于10），主要瓶颈在网络和模型推理，而不是向量检索本身。如果是高并发（100以上），就要考虑缓存热点查询、做前置标量过滤缩小候选集、或者加索引副本。内存占用则是选参数时的硬约束。HNSW索引在内存中的开销大概是向量的1.5倍，加上原始向量本身。一个100万条768维的float数组，光向量就占3GB左右，实际需要预留7GB以上。如果服务器内存小，你就得用PQ量化来压缩，但会损失召回率。

我通常会在评估报告里加一列"成本/召回收益比"。所谓收益，就是召回率提升了多少百分点；所谓成本，就是额外增加的硬件、运维和延迟。很多方案从70%提到75%，但硬件成本翻了一倍，那就不如不做。这个"够用即可"的原则能帮你拦住很多性能优化上的冲动。

4.4 常见误区：向量库不是万能的，代价是成本和运维

最后说一下心态。如果你以为上了向量库就一劳永逸，那大概率要失望。向量库的维护比普通数据库更精细，因为向量索引消耗内存大、更新维护复杂、版本升级可能不兼容。而且嵌入模型一变，全量数据都要重新embedding。这个"重灌"成本，我在项目里至少见过三次。第一次是换模型，第二次是切分策略调整，第三次是数据字段增加。

另外，向量检索并不保证100%正确，它给的是一个"近似集合"，所以在业务上必须设置阈值。就像搜索返回"相关"结果，但不一定就是"唯一正确"结果。如果业务不能容忍近似错误，你要在向量检索之后加规则过滤或人工确认环节。有很多企业做合规审查，偏偏想在敏感信息上搞向量匹配，结果匹配错了，只能背锅。总之，把向量库当成一个组件，而不是一个许诺，它会忠实为你服务；把它当成万能钥匙，它就会用一堆隐形成本给你上课。

再补充一点成本的事：向量库不是"买来就能用"的软件，它还需要配套的数据管道、向量生成服务、监控告警。很多时候整个系统里最耗CPU的环节是embedding模型，而不是向量库本身。如果你用GPU服务器来跑embedding，那GPU的利用率也要纳入成本评估。别只盯着数据库软件本身的授权费或服务器费用。

5. 我的踩坑实录：那些"上了向量库"最后又拆掉的案例

光讲理论不过瘾，我拿几个真实项目说事。这几个案例分别对应不同"不该上"的现象，希望能让你少走弯路。

5.1 案例A：小团队做了个内部知识库，其实Elasticsearch就够了

有一年一个朋友公司要做一个内部文档问答，文档量大概8万篇。他们看网上都在说RAG，直接就上了Milvus + OpenAI embedding，写了一整套同步脚本。结果发现文档每次更新后要重新embedding，一个批处理要跑4个小时；背景任务时不时把生产库拖慢；还要专门维护Milvus和etcd。后来我帮他们梳理，发现真正需要的场景是"搜索文档标题和内容里的关键词"，而不是"根据语义找回同义句"。于是他们改回Elasticsearch，用关键词搜索+简单的同义词映射，检索质量几乎没下降，运维直接砍掉了一半。

这个案例的教训是：你要先分析用户是怎么查的。如果用户基本知道文档里的术语，那关键词搜索就够；只有在用户不知道自己该用什么词时，向量检索才变成优势。内部知识库这种场景，用户往往会用专业术语搜，所以关键词优先。

另一个隐藏问题是他们一开始把embedding模型跑在CPU上，每次都慢吞吞。改用ES后，不说别的，光是省掉那台跑embedding的机器，一年就省了几万块。很多团队上了AI相关项目就习惯性考虑加GPU，其实在检索这个环节，数据量不大的话，更强的算力大概率用不上。

5.2 案例B：用向量库做了聊天记录标签，最后换成了规则

另外一个项目，团队想根据客服聊天记录自动给对话打标签，比如"退货""投诉""咨询物流"。他们把这些标签的样例文本都embedding了，然后用向量检索比对相似度来给新对话打标签。结果发现，打标签准确率只有60%，原因是有大量口语化表达跟样例对不上，而且标签经常是多个意图叠加，向量检索很难同时匹配多个语义。后来他们把标签改成了：先用大模型做多标签分类，输出意图列表；再用规则映射到业务标签。准确率直接到90%以上。大模型本身就是少样本分类器，用它做意图识别远比向量库合适。

这个案例的关键在于：向量检索适合"召回相似内容"，不适合"做精确分类"。分类问题，尤其是标签数量不多时，直接用大模型或内置分类器更可靠。向量库不是用来做分类的，你非要用，就只能接受一个F1意义不大的结果。

后来他们还测试过把标签数量扩到几百个，大模型的分类准确率下降得很厉害。这时他们才考虑要不引入向量检索作为候选选择，再用分类器做精排。所以如果一个分类体系特别庞大、且每条文本可能要同时归属多个类别，那么混合方案是合理的。但这是后话，不是一开始就该做的。

5.3 案例C：多模态图像搜索，终于值得上向量库

反过来也有个正面案例。一个做设计素材管理的朋友，手里有几百万张图片，用户常常用文字描述来找图，比如"一张夕阳下的城市天际线"，而图片没有友好的文本标签。这种情况，关键词检索根本无法工作，因为用户描述的是"语义"而不是"标签"。他们最后上了向量库，用CLIP模型把图片和用户查询映射到同一个向量空间，效果立竿见影。图片入库时编码一次，查询时编码一次，向量库处理相似度检索。到这一步，向量库才算是物尽其用。

你发现没有：这个案例和前面几个的区别，在于"数据模态"和"查询方式"。多模态检索天然需要向量编码，因为图片/音频没有天然的文本反射，没法用倒排索引搞定。而文本场景，倒排索引仍能发挥巨大作用。所以如果你要处理的是纯文本，向量库不一定是必选项；但如果你要处理的是图片、音视频，它往往是唯一务实的选项。

这个案例也告诉我们：embedding模型的选择决定了最终效果上限。一开始他们用的是某个通用视觉模型，搜"蓝色椅子"经常出来一堆"穿蓝衣服的人"，后来换了CLIP类模型，并做了几个业务领域的微调，效果才真正稳定下来。向量库只负责存储和检索，不负责"理解"，理解全靠模型。这个边界如果没拎清，后期排查问题会非常痛苦。

5.4 从这些案例你能学到什么判断标准

综观这些案例，我的判断标准可以归结为三句话：第一，用户是否能预定义查询词？能，优先倒排索引；不能，才考虑向量。第二，数据的"语义"是否能够被简单的规则或关键词捕获？能，用规则；不能，才考虑向量。第三，你的系统是否允许"近似结果"？完全不允许，就不要上向量库；允许，才需要考虑。

当然，这三个标准不是绝对的，实际业务往往是混合的。比如用户能预定义一部分，语义查询一部分，那就做混合检索。这并不可怕，可怕的是不管三七二十一直接上向量库，最后连查询日志都没分析过。我每次做技术方案前，都会要求看至少一周的查询日志，统计出高频查询、中间查询、长尾查询的分布。没有这个基础数据，任何选型都等于拍脑袋。

6. 结尾：一张决策表和一句真心话（个人经验收尾）

6.1 一张决策表：什么时候绝不建议、什么时候可以考虑、什么时候强烈建议

我直接把判断结果做成一个表，方便你保存后对着看。

这张表不可能覆盖所有情况，但能帮你过滤掉最明显的高风险选择。重点不是表格本身，而是你在填表时，必须写出业务里的真实数据规模、查询方式、错误容忍度和运维资源，而不是拍脑袋。我每次填这张表，都会发现自己一开始以为"需要向量库"的场景，其实在第一步"数据规模"就被否决了。

6.2 如果你还在犹豫，先做这个最小验证

如果你看了前面的自检，仍然拿不定主意，我推荐你用两天时间做一个最小验证：找100条真实业务数据，用任意嵌入模型生成向量；用Python写一个最简单的暴力搜索（for循环算余弦相似度）；然后让业务同事给出20个典型问题，看Top-5的命中率。如果命中率超过80%，你再考虑要不要上正式向量库；如果连80%都不到，那就先别碰向量库，回去优化切分策略、换模型、或者想想是否真的需要语义检索。

这个验证一分钟就能写完，但能帮你省下好几周的架构折腾。别小看暴力搜索，数据量在10万以内，它完全能扛住低并发，而且没有运维成本。等你验证好了，再把这段暴力搜索替换成pgvector或Milvus，逻辑几乎不用改。我在自己的项目里就是这么做的：先用Python算了一遍，确认收益足够大，才动手搭索引；没确认之前，我不允许团队把时间花在配置分布式集群上。

具体代码非常简单，如果你还没写过，我把它贴一下。先装一个sentence-transformers或者直接用OpenAI的embedding接口，把100条文本转成向量，然后把查询文本也转成向量，用numpy算余弦相似度，取前5个：

import numpy as np from sentence_transformers import SentenceTransformer model = SentenceTransformer("all-MiniLM-L6-v2") docs = [...] # 100条业务文本 doc_vecs = model.encode(docs) query_vec = model.encode([query])[0] sims = np.dot(doc_vecs, query_vec) / ( np.linalg.norm(doc_vecs, axis=1) * np.linalg.norm(query_vec) ) top5 = np.argsort(sims)[-5:][::-1]

这只是验证，不是生产代码。等验证通过，你再决定用什么方案来落地。整个验证过程要注意：你的查询最好来自真实用户，而不是自己拟的几个漂亮句子。我曾经见过有人拿标准问法测出了95%的命中率，一上真实用户口语，掉到50%。所以测试集合要尽量"脏"，不要怕难堪，测试阶段暴露问题，总比上线后暴露好。

6.3 我的个人体会：技术选型是"匹配"不是"追新"

最后分享一句我自己的体会：最近两年AI技术迭代特别快，多模态模型、智能体框架每天都在冒新东西，但越是这样，技术选型越要回归到业务匹配。向量库只解决"相似性搜索"一个问题，它不该成为所有AI应用的默认标配。我做过的项目里，有的用SQL查得飞快，有的用ES就很稳，有的上一套pgvector完全够用，而真正需要上大规模独立向量库的，只是其中少数。

所以别急着上向量库。先把你的查询日志翻出来看看，把数据量数一数，把"到底要解决什么"写下来。如果确定需要，那就好好选型、好好测试；如果不需要，省下来的钱和精力，拿去调模型效果、优化产品体验，收益会大得多。我的建议从来都是：让技术去适配场景，而不是让场景去迁就技术。