企业官网建设流程全解析

1. 从一次检索需求说起：为什么普通数据库突然不够用了

前阵子帮一个做知识管理工具的朋友看架构问题。他们的产品早期用传统关系型数据库存文档元数据，搜索靠LIKE '%关键词%'硬扫，数据量小的时候一切正常。等到文档量爬到几十万条、用户开始用自然语言提问"帮我找去年关于预算调整的会议记录"时，整个检索链路直接崩了——响应时间从几百毫秒飙到十几秒，而且搜出来的东西驴唇不对马嘴。

这个场景其实特别典型。向量数据库和普通数据库的选型问题，本质上不是"哪个更好"的问题，而是"你的检索需求到底属于哪一类"的问题。普通数据库擅长的是精确匹配和结构化条件过滤，比如"找出所有状态为已发布、创建时间在某个区间、作者是某人的记录"，这类查询它闭着眼睛都能跑得飞快。但一旦你的需求变成"找出语义上和这句话最接近的十条内容"，普通数据库就彻底抓瞎了。

我写这篇东西，是想把这两类数据库的边界、各自的底层逻辑、以及实际选型时那些文档里不会写的坑，一次性讲清楚。不管你是刚接触向量检索的新手，还是已经在做架构决策的工程师，应该都能从中找到能直接用的判断依据。核心关键词就三个：向量数据库、普通数据库、选型，全文围绕它们展开。

先说结论性的判断框架，后面再逐层拆解：如果你的查询条件是"精确的、可枚举的、结构化的"，普通数据库是更优解；如果你的查询条件是"模糊的、语义的、相似度排序的"，向量数据库才是对的工具。而现实中大量场景其实是两者混合，这时候怎么组合才是真正考验功力的地方。

2. 两类数据库的底层逻辑差异：一个存值，一个存方向

2.1 普通数据库的索引本质：把值排好序，快速定位

普通数据库（这里主要指关系型和文档型）的核心能力是精确检索。它之所以快，是因为建立了 B+ 树、哈希索引、倒排索引这类结构，把数据按照某种确定的顺序组织起来。你查id = 12345，它通过 B+ 树几层就能定位到；你查name LIKE '张%'，它能利用索引的前缀特性快速缩小范围。

关键在于，这类索引的前提是值本身可以被比较和排序。数字能比大小，字符串能按字典序排，时间能按先后排。所以普通数据库处理的是"这个值等于/大于/小于/包含某个确定值"这类问题。

但语义相似度这个东西，它没法排序。你没法说"苹果"和"水果"哪个更大，也没法说"预算调整"和"财务规划"哪个排在前面。语义关系是一个高维空间里的距离问题，普通数据库的索引结构根本表达不了。

2.2 向量数据库的核心：把语义变成高维空间里的坐标

向量数据库做的事情，是先把文本、图片、音频这类非结构化内容，通过嵌入模型转换成一串浮点数，也就是向量。比如一段文本可能被转成 768 维或 1536 维的向量。这个向量可以理解为这段内容在语义空间里的"坐标"。

一旦内容变成了坐标，语义相似度就变成了向量之间的距离。两个向量夹角越小（余弦相似度越高），说明它们语义越接近。向量数据库的核心工作，就是在这个高维空间里快速找到离查询向量最近的若干个点，也就是ANN（近似最近邻）搜索。

这里有个很多人忽略的点：向量数据库并不"理解"语义，它只是高效地做高维空间的距离计算。真正赋予它语义能力的是那个嵌入模型。模型选得好不好，直接决定了检索质量的上限。数据库本身只负责"算得快"。

2.3 一张表看清两者的能力边界

这张表不是让你二选一，而是让你明白：它们解决的是完全不同的问题。把向量检索硬塞进普通数据库，或者指望向量数据库做复杂事务，都是在用错误的工具干错误的活。

3. 选型的第一道分水岭：你的查询到底长什么样

3.1 精确条件查询：普通数据库的主场，别犹豫

先看几个典型的查询语句，判断它们属于哪一类：

• "查询订单号 20240115001 的物流状态"
• "统计上个月华东区销售额超过 10 万的客户"
• "找出所有标签包含'紧急'且未处理的工单"

这些查询的共同点是：条件明确、结果确定、可以精确描述。这类需求用普通数据库，配合合适的索引，性能几乎没有对手。你要是拿向量数据库来做这些，不仅没必要，还会因为向量检索的近似特性导致结果不精确——ANN 搜索返回的是"近似最近邻"，它可能漏掉真正精确匹配的那一条。

我见过有团队为了"技术先进"把所有查询都往向量数据库上搬，结果连"按 ID 查用户"都要走一遍向量检索，延迟反而更高，还引入了结果不确定性。这是典型的过度设计。

3.2 语义相似查询：向量数据库不可替代

再看另一类查询：

• "帮我找和这段产品描述相似的其他商品"
• "根据这段故障描述，检索历史上处理过的类似问题"
• "用户上传了一张图，找出图库里风格相近的图片"

这类查询的特点是：你没法用精确条件描述，只能给出一个"参照物"，然后要求找相似的。这正是向量数据库的用武之地。

这里要强调一个实操经验：相似度阈值的选择比数据库选型更影响体验。余弦相似度 0.8 以上通常算高度相关，0.6 到 0.8 是弱相关，0.6 以下基本可以认为是噪声。但这个阈值不是固定的，它跟你的嵌入模型、数据分布强相关。我一般建议先用一批标注好的查询-结果对，跑一遍看看相似度分布，再定阈值，而不是拍脑袋设个 0.7。

3.3 混合查询：现实中最常见的形态

真实业务里，纯语义查询和纯精确查询都少见，混合查询才是主流。比如电商搜索："找出价格在 100 到 500 元之间、且和'轻便透气跑鞋'语义相近的商品，按相似度排序"。

这个查询里，"价格 100 到 500"是精确过滤，"语义相近"是向量检索。怎么处理？有两种主流方案：

方案一：先过滤后检索。先用普通数据库的条件筛出候选集，再对候选集做向量检索。优点是精确条件能大幅缩小检索范围，缺点是如果候选集太大，向量检索依然慢。

方案二：向量数据库内置过滤。现在主流向量数据库都支持在检索时附带元数据过滤条件（比如price BETWEEN 100 AND 500），它在遍历向量索引的同时应用过滤。这种方式实现简单，但要注意过滤字段的索引效率，否则可能退化成全量扫描。

我的经验是：过滤后候选集小于总量 10% 时，方案一更稳；候选集占比高时，方案二更合适。这个比例不是绝对的，得结合你的数据规模和硬件实测。

4. 向量数据库内部也不是铁板一块：索引类型决定性能天花板

4.1 HNSW：召回率高，但内存吃得凶

HNSW（分层可导航小世界图）是目前最主流的向量索引。它的思路是构建一个多层图结构，上层稀疏用于快速跳转，下层密集用于精细搜索。查询时从顶层开始逐层下降，像坐电梯一样快速接近目标区域。

它的优点是召回率高、查询延迟低，在百万级数据上通常能做到毫秒级响应。缺点是内存占用大，因为整个图结构要常驻内存。我实测过一个 100 万条 768 维向量的数据集，HNSW 索引大概要吃掉 3 到 4 GB 内存。数据量再往上走，内存成本会非常可观。

调参上，M（每个节点的连接数）和efConstruction（构建时的搜索宽度）是两个关键参数。M越大召回率越高但内存越大，一般设 16 到 64；efConstruction越大构建越慢但索引质量越好，一般设 100 到 500。查询时的efSearch则直接权衡延迟和召回率。

4.2 IVF 系列：用聚类换内存，适合超大规模

IVF（倒排文件）的思路是先对向量做聚类，分成若干个簇，查询时只搜索距离查询向量最近的几个簇。这样就不用扫描全部数据，大幅降低计算量。

它的优点是内存占用比 HNSW 小，适合千万级甚至亿级数据。缺点是召回率受聚类质量影响大，如果查询向量落在簇的边界上，可能漏掉相邻簇里的真正近邻。通常配合 PQ（乘积量化）进一步压缩向量，牺牲一点精度换大幅内存节省。

选 IVF 还是 HNSW，核心看你的数据规模和内存预算。百万级以内、内存充足，HNSW 是首选；千万级以上、内存紧张，IVF+PQ 更现实。

4.3 索引不是建完就完事：更新与重建的代价

这是文档里很少强调、但实际踩坑最多的地方：向量索引的更新代价远高于普通数据库索引。

普通数据库插入一条记录，B+ 树调整一下就好，代价很低。但向量索引，尤其是 HNSW，插入新向量时需要更新图结构，频繁插入会导致索引质量下降。很多向量数据库的做法是批量重建索引，这就意味着新数据不能立即被检索到，存在延迟。

如果你的业务是"数据频繁增删改 + 要求实时可检索"，这一点必须提前评估。有些场景下，用普通数据库存原始数据、定期批量同步到向量索引，反而是更稳的架构。我见过有团队没考虑这点，上线后才发现新上传的文档要等索引重建才能被搜到，用户体验直接崩了。

5. 那些选型时最容易踩的坑

5.1 坑一：以为向量数据库能替代全文检索

这是新手最常见的误解。向量检索擅长语义相似，但它在精确关键词匹配上反而不如传统全文检索。比如用户搜一个特定的产品型号"XYZ-2000"，向量检索可能返回一堆语义相近但型号不同的产品，而全文检索能精确命中。

正确做法是混合检索：向量检索负责语义召回，全文检索负责关键词召回，最后用 RRF（倒数排名融合）之类的算法合并结果。这样既有语义的广度，又有关键词的精度。很多成熟的检索系统都是这么做的，单靠一路召回很难覆盖所有查询意图。

5.2 坑二：忽略嵌入模型的成本与一致性

向量数据库本身不产生向量，向量来自嵌入模型。这里有两个隐藏成本：

一是调用成本。每次查询都要把查询文本转成向量，这需要调用嵌入模型。如果模型是远程 API，每次查询都多一次网络往返，延迟和费用都要算进去。数据入库时更是要对全量数据做一次嵌入，这个批量成本不小。

二是模型一致性。入库用的嵌入模型和查询用的嵌入模型必须是同一个，否则向量空间对不上，检索结果完全错乱。我见过有团队中途换了嵌入模型，但没重新嵌入历史数据，导致新旧数据检索结果割裂。换模型一定要全量重嵌，这是铁律。

5.3 坑三：把向量数据库当主库用

向量数据库的事务能力、数据一致性保障普遍弱于成熟的关系型数据库。把它当唯一数据源，风险很高。稳妥的架构是：普通数据库做主库，存全量原始数据和元数据；向量数据库做检索索引，存向量和必要的过滤字段。两者通过 ID 关联，向量库挂了可以从主库重建。

这个架构还有个好处：向量库的索引可以随时重建、换模型、调参数，不影响主数据。灵活性高很多。

5.4 坑四：没做召回率评估就上线

向量检索是近似的，它不保证返回的一定是真正的最近邻。上线前必须做召回率评估：拿一批查询，用暴力搜索（精确计算所有距离）得到真实 Top-K，再和向量索引返回的结果对比，看重合度。

如果召回率低于 90%，要么调索引参数（增大efSearch、M），要么换索引类型。这个评估不做，你根本不知道系统漏掉了多少本该返回的结果。我一般建议召回率目标定在 95% 以上，低于这个数就得优化。

6. 一套可落地的选型决策流程

6.1 第一步：把查询需求分类打标

拿一张纸，把你系统里所有的查询需求列出来，逐条打标：是精确条件查询，还是语义相似查询，还是混合查询。统计各类占比。

如果语义类查询占比低于 10%，老实说，可能暂时不需要向量数据库，先用普通数据库扛着，等需求明确了再上。如果语义类占比超过 30%，向量数据库基本是刚需。

6.2 第二步：评估数据规模与增长预期

数据规模直接决定索引选型和硬件预算。这里给个粗略的参考：

注意这个表是单机粗估，分布式部署要另算。而且维度越高内存越大，1536 维差不多是 768 维的两倍。

6.3 第三步：确定架构组合方式

基于前两步，基本能定下架构：

• 纯精确查询为主：普通数据库，别折腾。
• 纯语义查询为主、数据量中等：向量数据库单扛，但原始数据仍建议落普通库。
• 混合查询为主：普通数据库 + 向量数据库组合，或者用支持混合检索的向量数据库。
• 超大规模 + 成本敏感：IVF+PQ 压缩，配合普通数据库做元数据过滤。

6.4 第四步：小规模验证再全量

别一上来就全量导入。先拿 1 万到 10 万条数据做验证，跑通检索链路，评估召回率和延迟，确认嵌入模型效果。这一步能提前暴露大部分问题，成本却低得多。验证通过再逐步扩量，边扩边观察性能曲线。

7. 混合架构下的实操细节

7.1 ID 映射与数据同步

普通库和向量库之间靠唯一 ID 关联。写入流程一般是：先写普通库拿到 ID，再用这个 ID 和内容去生成向量、写入向量库。这里要注意写入顺序和失败处理：如果普通库写成功、向量库写失败，就会出现数据不一致。常见做法是加一个补偿队列，失败的重试，或者定期做全量对账。

同步延迟也要评估。如果是异步同步，新数据可能几秒后才可检索。对实时性要求高的场景，得用同步写入或者更快的同步机制。

7.2 过滤字段的设计

向量数据库里除了向量，通常还要存一些用于过滤的元数据字段，比如分类、时间、状态。这些字段的设计直接影响混合查询效率。原则是：把最常用于过滤、选择性最高的字段放进向量库，其他字段留在普通库。

比如电商场景，category和price是高频过滤字段，放向量库；而详细的商品描述、库存明细留在普通库。这样混合查询时，向量库能独立完成"过滤 + 相似度排序"，不用回普通库二次查询。

7.3 结果融合与重排

混合检索返回多路结果后，需要融合。最简单的是加权求和，但权重难调。更稳的是 RRF：对每路结果按排名给分，排名越靠前分越高，最后合并总分排序。RRF 的好处是不依赖各路分值的绝对大小，鲁棒性强。

如果对精度要求极高，还可以加一层重排模型（Rerank），用交叉编码器对候选结果重新打分。这一步精度提升明显，但计算成本高，一般只对 Top 50 到 100 的候选做重排。

8. 我个人的几条经验之谈

折腾了这么多项目，有几个体会是反复被验证的。

第一，别为了用向量数据库而用。它是解决特定问题的工具，不是架构升级的标配。我见过太多项目引入向量库后，实际语义查询占比不到 5%，纯属资源浪费。

第二，嵌入模型的选择比数据库选型更影响最终效果。同一个向量数据库，换个更好的嵌入模型，检索质量可能天翻地覆。预算有限时，优先把钱花在模型上，而不是堆数据库配置。

第三，召回率评估要常态化。数据分布会变，模型会更新，索引会老化。定期跑召回率评估，才能及时发现检索质量下滑。我一般建议至少每季度做一次。

第四，架构上永远留一条退路。向量库再方便，也要保证能从普通库全量重建。这样无论换模型、换数据库、还是索引损坏，都能快速恢复。这条退路，关键时刻能救命。

选型这件事，没有标准答案，只有适不适合。把查询需求摸清楚，把数据规模算明白，把成本评估到位，答案自然会浮现出来。