向量检索是否应成为独立基础设施，关键不在于“能否查到相似内容”，而在于它是否已经形成独立的工程约束：需要单独保障性能、数据更新、权限治理、故障恢复和扩展能力。若向量检索只是关系数据库中的辅助条件，且数据规模、并发和实时性要求有限，贸然拆分往往只会增加同步、监控、备份和运维成本。
判断独立建设的四个信号
第一，向量查询已经与事务查询、报表分析和在线写入争抢资源。此时，独立检索服务可以隔离计算、存储和扩展节奏，避免业务高峰相互影响。
第二，团队开始持续调节近似最近邻索引、分片、压缩、召回率和延迟，并需要专门处理索引构建、重建与数据导入。这说明向量能力已不再是数据库中的普通字段。
第三，业务对数据新鲜度有明确要求。知识删除、权限撤销、商品下架或用户行为变化，都要求索引及时生效。如果现有系统无法稳定处理新增、修改和删除，独立向量层才具备现实价值。
第四，多个业务系统需要共享统一的向量检索能力。知识库、客服助手、内部搜索和智能体应用若各自维护索引，容易造成重复存储、重复计算和治理口径不一致。
独立不等于全面拆分
向量数据库适合承担近似最近邻检索、向量索引管理以及向量与元数据过滤，但不应替代业务主数据和事务系统。较稳妥的职责划分是：对象存储保存原始文件，关系数据库保存文档状态、租户、权限和版本信息，向量数据库保存嵌入向量及索引，搜索引擎负责关键词或混合检索，应用层负责召回融合、重排和权限复核。
不过，组件越多，数据同步和故障恢复越复杂。选型时应比较现有关系数据库扩展、搜索引擎承担混合检索，以及独立向量数据库三类架构，而不是直接追逐“更专业”的产品。
先验证，再拆分
测试不能只看平均响应时间。应使用真实脱敏向量和查询样本，分别观察召回率、业务命中率、P95/P99 延迟、写入与删除生效时间、权限过滤准确性，以及节点故障后的恢复能力。对于检索增强生成，向量检索只是链路一环，切分策略、嵌入模型、过滤条件和重排同样会影响最终效果。
因此，独立建设的分界线很清晰：当向量检索的性能、更新、扩展和治理问题已经成为业务系统的独立约束时，才值得建设专门基础设施；在此之前，应优先采用边界清晰、可迁移、可观测且成本可控的渐进方案。