向量存储不是你的新数据库信仰

RAG 项目先挑向量库再建数据模型的顺序通常倒置

每个 RAG 原型在确定数据模型前就先要向量数据库，这种顺序通常是反的。信号指出，真正棘手的问题不是 ANN 索引的基准图表，而是嵌入必须多新鲜、删除由谁负责、租户边界放在哪里、元数据过滤如何测试、模式变更后重建什么，以及源文档是否仍是真实来源。数据库选型重要，但它不是信仰。

很多团队在做 RAG 时，第一反应是选 Pinecone、Weaviate 还是 Milvus。他们把精力花在对比 QPS、召回率和向量维度支持上，却很少先问清楚业务数据到底长什么样。这种做法把技术选型当成了起点，把数据建模当成了后续补丁。

正确顺序应该先定义数据模型。需要哪些实体？它们之间有什么关系？哪些字段会用于过滤，哪些只用于向量检索？这些问题决定了向量只是整个系统的一小部分。数据模型定下来后，向量存储才知道自己该扮演什么角色，是辅助索引还是核心存储。

如果先选了向量库，再发现业务需要强一致性的事务或者复杂的 JOIN，就会陷入尴尬。向量数据库大多在 ACID 支持上较弱，强行把所有逻辑塞进去会导致后续大量重构。生产环境中，数据模型的清晰度直接影响系统能否长期演进，先建模型再选库能避免很多后期痛苦。

这一判断不是理论推演，而是来自大量 RAG 项目复盘。原型阶段向量库能快速出 demo，但进入生产后，80% 的问题都出在数据模型没想清楚导致的边界模糊上。把向量当成银弹，只会让团队在后续迭代中不断还债。

嵌入新鲜度、删除权责和租户边界是首要硬问题

向量存储不是你的新数据库信仰：嵌入新鲜度、删除权责和租户边界是首要硬问题

嵌入新鲜度直接决定检索质量。在新闻推荐场景中，如果 embeddings 24 小时才更新一次，用户看到的“相关文章”可能已经是昨天的热点。生产系统必须明确 freshness SLA，是秒级、分钟级还是小时级，这会直接影响向量更新管道的设计复杂度。

删除权责同样关键。用户删除一篇文档后，是只删向量还是连原始文档一起删？谁来保证两者最终一致？很多团队把这个责任扔给向量数据库自身，结果发现向量库的 delete 操作并不保证原子性，出现向量已删但原始数据还在的情况，导致隐私合规风险。

租户边界在多租户 SaaS 中尤其重要。不同客户的向量是否要物理隔离？还是只靠 metadata 过滤？隔离能防止噪声干扰，但成本更高；共享则需要极强的过滤机制，否则一个租户的坏数据可能污染全局索引。中国团队在服务企业客户时，常因租户边界设计不清晰，导致一个客户的数据泄露到另一个客户的检索结果中。

这些问题没有标准答案，必须在项目早期就和业务方、合规团队一起定义。把它们当成向量数据库选型前的必答题，而不是上线后再补救，能大幅降低生产事故概率。

元数据过滤测试与模式变更后的重建决定长期可维护性

元数据过滤是向量检索里最容易出 bug 的地方。过滤条件写得再漂亮，如果测试不充分，上线后很容易出现召回结果不符合过滤规则的情况。生产环境中需要建立完整的测试套件，包括边界值、组合过滤、大小写敏感等场景，不能只靠人工抽样验证。

模式变更后的重建更是长期维护的痛点。假设业务新增了一个分类字段，所有历史文档的向量是否需要重新生成？如果向量维度发生变化，整个索引要不要重建？重建成本可能高达数小时甚至几天，期间服务可用性如何保证？这些问题直接影响系统能否跟上业务迭代速度。

很多中国团队在早期使用向量库时忽略了 schema evolution，导致每次产品经理改一个字段，后端都要花一周时间重新灌数据。成熟的做法是把向量当成可重建的衍生数据，建立自动化 pipeline，在 schema 变更时能快速回放历史文档重新生成 embeddings。

可维护性不是锦上添花，而是生产系统的核心指标。元数据过滤测试覆盖率和 schema 变更重建时间，应该成为评估向量存储方案是否可用的硬性标准。

源文档仍是真实来源，向量仅为衍生表示

源文档必须始终是真实来源。向量只是对文档 chunk 的某种数学投影，丢失了原始文本就等于失去了可解释性和可验证性。生产系统中，任何检索结果最终都应该能追溯到原始文档，否则无法进行人工审核和纠错。

不少团队把向量库当成主要存储，把 chunk 后的文本只保存在向量 metadata 里。这种做法风险极高。一旦向量索引损坏或需要迁移，原始内容就可能丢失。正确做法是把源文档保存在关系型数据库或对象存储中，向量库只存向量和指向源文档的 ID。

这种从属关系也影响更新逻辑。当源文档修改后，必须触发向量重新生成。如果把向量当成独立实体，就容易出现向量与源文档不一致的情况，用户检索到的“最新”内容实际上是旧版本。

强调源文档的主导地位，能让整个系统保持可审计性。在金融、医疗等强合规场景中，这一点尤其重要。向量是工具，不是真相本身。

向量存储与关系型、图数据库是互补而非替代

向量数据库擅长模糊匹配和语义搜索，但在事务、一致性、复杂关联查询上远不如关系型数据库。生产系统中两者应该是明确分工：PostgreSQL 或 MySQL 负责核心业务数据和事务，向量库负责高维相似性检索，通过外键或文档 ID 实现关联。

图数据库在推荐和知识图谱场景中也有独特价值。向量能捕捉语义相似性，图数据库能捕捉显式关系。很多中文团队在做商品推荐时，同时使用 Neo4j 维护商品-属性-用户的关系图，再用向量检索捕捉“看起来相似但没有直接关系”的商品，两种技术协同工作效果远好于只用一种。

在搜索场景中，常见架构是 Elasticsearch 负责关键词匹配和结构化过滤，Milvus 或 Qdrant 负责向量召回，最后用 reranker 融合结果。这种混合架构在中国互联网公司中已经相当普遍，单纯用向量库替代所有存储的尝试大多以失败告终。

边界很清晰：向量解决“找相似的”问题，关系型解决“找确定的”问题，图数据库解决“找关联的”问题。三者结合才能构建可靠的生产系统。

中文团队在 RAG 与搜索场景下的选型经验与踩坑

国内团队在 RAG 项目中常用 Milvus 作为向量存储，因为它支持大规模集群和混合检索。但不少团队在初期没有做好 shard 规划，导致单个 collection 过大后查询延迟显著上升。经验是根据租户或业务域提前做好 partition 设计，避免后期痛苦迁移。

在企业搜索场景中，部分团队尝试只用向量检索替代传统全文搜索，结果发现专有名词和精确匹配效果很差。后来调整为向量+关键词混合召回，效果才稳定下来。另一个常见踩坑是忽略了向量维度和量化方式的选择，在 768 维和 1536 维之间选错，导致召回率下降 15 个百分点以上。

推荐系统领域，阿里和腾讯的部分团队采用向量+图的混合方案。向量捕捉用户兴趣的隐式表示，图数据库维护商品类目和品牌关系。踩过的坑包括向量更新频率跟不上用户行为变化，导致推荐结果滞后，最终通过引入实时特征更新 pipeline 解决。

整体经验是不要把向量数据库当成万能方案。在生产环境中，选型时必须同时考虑现有技术栈、团队运维能力、数据规模和更新频率。很多团队后来发现，把向量只作为辅助索引，反而比全面替换原有数据库更稳妥。

向量数据库的真实边界仍有多个未定论问题

目前生产实践中仍有多个边界问题缺乏共识。比如向量索引在高并发写入下的一致性保证，不同向量库给出的答案差异很大。一些团队选择最终一致性换取性能，另一些则要求强一致但接受更高延迟。

删除传播也是开放问题。源文档删除后，向量如何高效清理？全量重建太重，增量删除又可能留下垃圾数据。目前还没有公认的最佳实践，不同场景下的取舍仍在探索。

多模态场景下，向量边界更模糊。文本、图像、视频的向量是否要放在同一个索引？不同模态的相似性如何统一度量？这些问题在中国多模态 RAG 项目中越来越常见，但成熟方案仍不多。

向量数据库很重要，但它解决不了所有数据问题。团队需要保持清醒，持续评估哪些问题适合用向量，哪些必须依赖其他技术。把向量当成宗教只会蒙蔽判断，把它当成工具才能真正发挥价值。

参考来源