很多 RAG 项目在本地开发阶段用嵌入式向量库跑通检索链路后，直接迁移到生产环境，结果检索延迟从毫秒级升到秒级，索引构建时间从分钟级变成小时级，内存占用也远超预期。问题通常不在检索算法本身，而在于本地开发与生产部署在数据规模、并发模型、持久化方式和资源隔离上的根本差异。
本地开发与生产部署的四个核心差异
数据规模与索引结构。本地开发通常用几千到几万条向量验证流程，嵌入式向量库默认参数下就能获得可接受的召回率和延迟。生产环境的数据量可能达到百万甚至千万级，此时索引结构的选择直接决定性能。以 HNSW 为例，M、efConstruction、efSearch 三个参数分别影响图连接度、构建质量和查询精度。本地小规模数据下用默认值即可，生产环境若沿用默认值，要么召回率不足，要么查询延迟随数据量线性上升。
并发写入与查询。嵌入式向量库通常以单进程方式运行，写入和查询共享同一份内存资源。本地开发时串行操作不会暴露问题，生产环境如果同时有批量写入和在线查询，就会出现写操作阻塞查询、查询延迟抖动的情况。独立向量服务通过分离写入路径和查询路径、引入段合并策略来缓解这一问题，但需要额外配置连接池和超时参数。
持久化方式。嵌入式向量库一般将索引文件存储在本地磁盘，进程重启后重新加载。生产环境需要考虑索引文件的大小、加载时间、备份策略以及多副本一致性。独立向量服务通常提供快照、副本和持久化日志机制，但也会引入网络开销和运维复杂度。
资源隔离。本地开发时向量库与应用程序共享 CPU 和内存，不会互相干扰。生产环境中，如果向量库与业务服务部署在同一节点，索引构建或大规模查询可能耗尽内存，导致业务服务被 OOM Kill。独立向量服务可以独立扩缩容，但需要评估网络延迟对检索链路的影响。
选型时应提前确认的工程约束
索引参数配置。不要依赖默认值上线。需要根据数据规模、召回率要求和延迟预算，提前确定 HNSW 的 M、efConstruction、efSearch，或 IVF 的 nlist、nprobe。这些参数一旦确定，后期调整往往需要重建索引，代价很高。
批量写入与查询连接管理。嵌入式向量库通常不需要连接管理，但独立向量服务需要配置连接池大小、写入批次大小和重试策略。批量写入时要注意批次过大会导致内存峰值，批次过小则写入吞吐不足。查询侧要设置合理的超时和重试，避免个别慢查询拖垮整个检索链路。
避免后期迁移返工的设计建议。在应用层抽象向量库接口，将索引创建、写入、查询、删除等操作封装为独立模块，避免业务代码直接依赖具体向量库的 SDK。这样在从嵌入式向量库迁移到独立向量服务时，只需替换实现层，而不需要重写检索逻辑。同时，在开发阶段就用生产级别的数据量和并发模型做压测，提前暴露索引参数和资源隔离问题。
工程取舍
嵌入式向量库适合数据量小、并发低、部署简单的场景，优势是零网络开销、运维成本低。独立向量服务适合数据量大、并发高、需要弹性扩缩容的场景，代价是额外的网络延迟和运维复杂度。选型时不要只看本地开发体验，要结合生产环境的数据增长预期、并发模型和资源预算综合判断。如果短期内无法确定，优先选择接口抽象层，为后续迁移留出空间。