构建 RAG(检索增强生成)应用时,向量存储的选型常被过早复杂化。不少团队在 MVP 阶段就引入 Pinecone 或 Milvus,却发现大部分能力用不上;也有团队用内存硬撑到数据膨胀才发现重构成本高昂。本文从工程实践角度给出决策框架。
三种存储方案的适用边界
内存存储(如 NumPy 数组 + FAISS)适合原型验证与小规模场景。假设你在做一个企业内部知识库,文档总量 5000 篇,每篇切分后平均生成 20 个 chunk,总计 10 万条向量(维度 1536 的 OpenAI embedding 约占 600MB 内存)。这个规模下,冷启动加载耗时可控,单机内存足够,用 FAISS 的 IndexFlatIP 做暴力检索延迟在 10ms 级别,完全够用。
SQLite + 向量扩展(如 sqlite-vss)是被低估的中间方案。它解决了内存方案的持久化问题,同时保持部署简单——单个文件、零运维、事务支持。当数据增长到几十万条,但查询 QPS 仍在个位数(典型的内部工具场景),SQLite 能撑住。它的局限在于:ANN(近似最近邻)索引能力弱于专用方案,单机扩展性到百万级向量会遇到瓶颈,并发写入性能受限于文件锁。
专用向量数据库(Pinecone / Qdrant / Weaviate 等)在三个条件同时满足时成为必选项:向量规模百万级以上、查询 QPS 需要两位数起步、需要多租户隔离或分布式扩展。它们提供的 HNSW / IVF 等索引、查询优化、集群能力,是前两种方案达不到的。代价是引入了额外的基础设施依赖和学习成本。
决策时需要回答的四个问题
1. 数据增长曲线是什么?
如果是固定语料(如产品手册库),内存方案配合定期重建索引即可。如果是用户 UGC 持续增长,需要评估 6 个月后的量级——假设当前 10 万条、月增 20%,半年后将达到 30 万条,这时 SQLite 仍在舒适区。
2. 查询模式是批量还是实时?
离线批处理(如每晚更新推荐列表)可以容忍秒级延迟,内存方案足够。用户交互式查询要求亚秒级响应,且 QPS 波动大,这时需要考虑专用数据库的查询缓存和负载均衡能力。
3. 是否需要混合查询?
纯向量相似度检索可以用简单方案,但如果需要「在特定时间范围内查找相似文档」这类过滤条件,SQLite 的 SQL 表达能力是优势;专用向量库虽然也支持 metadata filtering,但查询语法各家不同,迁移成本高。
4. 团队的运维能力如何?
托管服务(Pinecone)省心但按用量计费,自建开源方案(Qdrant)需要处理备份、监控、版本升级。小团队在早期应优先选择能减少认知负担的方案——SQLite 的零配置特性在这一点上很有价值。
渐进式演进路径
推荐的演进策略是:先用最简单的方案验证业务逻辑,在遇到明确瓶颈时再升级。
- 阶段一(MVP):内存 + pickle 持久化,或直接用 LangChain 的
Chroma本地模式。重点是快速验证检索效果与业务闭环。 - 阶段二(小规模生产):迁移到 SQLite-vss,补齐事务与并发支持。此时应建立监控,记录 P99 延迟和索引构建时间。
- 阶段三(规模化):当监控显示查询延迟超过 SLA 或数据量逼近百万,切换到专用向量库。选型时优先考虑支持导出标准格式(如 Parquet)的产品,降低未来迁移成本。
关键是在每个阶段都保持存储层抽象:用 Repository 模式封装向量操作,使得底层存储可替换。这比一开始就选"最强"方案更符合工程理性。
Taylent Labs 在 AI 应用开发中积累了从原型到生产的全栈经验,如果你的团队在 RAG 架构选型或 LLM 应用落地上需要支持,欢迎联系我们探讨具体场景。