完整题目
在构建基于大模型的检索增强系统时，如何评估和选择合适的向量数据库？请从性能、可扩展性、支持的索引类型、查询延迟、与现有技术栈的集成等方面进行详细说明。
本文目录
选型核心维度
1. 性能与索引类型
- HNSW：图索引，召回率高、查询快（1-10ms），但内存占用大，适合百万-千万级稠密向量
- IVF+PQ：倒排+乘积量化，内存省、支持十亿级，查询稍慢（10-50ms），适合大规模稀疏访问
- DiskANN：内存+SSD混合，平衡成本与性能，十亿级首选
2. 可扩展性
- 水平扩展能力：是否支持分片（sharding）和动态扩缩容
- 写入吞吐：批量导入速度、实时更新延迟（部分库写放大严重）
3. 延迟与成本权衡
| 场景 | 推荐方案 |
|---|---|
| 在线QPS>1万、延迟<5ms | 纯内存HNSW（Milvus/Zilliz） |
| 成本敏感、延迟可接受50ms | DiskANN或IVF_PQ（Weaviate、Pinecone） |
| 超大规模（>10亿） | 自研或Elasticsearch 8.x的dense_vector |
4. 技术栈集成
- 优先选有成熟Python/Go SDK、支持LangChain/LlamaIndex的
- 云原生：是否支持K8s operator、Serverless计费模式
京东场景建议
电商搜索对延迟极敏感，推荐Milvus/Zilliz或阿里自研Proxima：
- 商品向量千万级，用HNSW保证<10ms响应
- 结合商品属性做过滤查询（hybrid search），需数据库支持标量过滤下推
学习建议
深入理解排序学习中pointwise与listwise的区别，结合信息检索场景分析训练与评估目标的差异。
换一种问法，检查是否真正理解
场景切入
假设我们做一个电商搜索系统，每天千万商品向量要实时检索，用户点一下就要结果。你选向量数据库会重点看哪些指标？比如性能、延迟、扩展性这些，怎么权衡？
层层追问
你觉得向量数据库选型主要看什么？……如果查询量很大，比如每秒上万次，延迟必须5ms以内，你优先考虑什么？……那数据量上亿了，内存放不下，怎么平衡成本和速度？
直球架构
你负责给一个RAG系统选向量数据库，要求支持十亿级向量、查询延迟<10ms、能水平扩展。请从索引类型、性能、可扩展性、技术栈集成这几个维度，说说你的选型思路和理由。
练习口述回答 · 约4分钟
- 这道题本质在问：如何在延迟、规模、成本和集成之间做工程取舍
- 核心维度：索引类型决定性能基线，扩展性决定能扛多大业务
- 业务场景举例：电商搜索的延迟敏感与混合检索需求
- 落地风险：索引重建、写放大、成本失控，上线前要压测
- 总结：没有万能方案，选型是 trade-off，我倾向先用成熟方案再优化
这道题其实不是在问[[向量数据库]]的功能列表，而是在问一个工程取舍问题：当你的业务有延迟要求、有规模预期、有成本约束的时候，你怎么在这么多向量数据库里选一个合适的。本质上是在做 trade-off。
我会从三个维度来考虑。先说索引类型，它直接决定了性能基线。[[HNSW]] 是最常用的图索引，查询快，1到10毫秒，召回率高，但内存占用大，适合百万到千万级。[[IVF-PQ]] 是倒排加[[乘积量化]]，内存省很多，能撑十亿级，但查询慢一些，10到50毫秒。还有 DiskANN，内存加 SSD 混合，平衡成本和性能，十亿级的首选。所以没有绝对的好坏，要看你的数据量和延迟要求。
第二个维度是可扩展性。说白了就是业务涨了能不能加机器。要关注数据库支不支持分片、动态扩缩容。另外写入吞吐也很关键，批量导入快不快，实时更新延迟高不高。有些库写放大很严重，频繁增删改会导致索引质量下降，这是一坑。
还有就是和技术栈的集成。优先选有成熟 Python 或 Go SDK 的，最好原生支持 LangChain 和 LlamaIndex，省得自己封装。云原生场景下，支不支持 K8s operator、有没有 Serverless 计费模式，这些对运维成本影响很大。
举个例子，电商搜索场景。商品向量千万级，用户查商品延迟必须控制在10毫秒以内，否则转化率掉。这时候我会选 Milvus 或 Zilliz，用 HNSW 索引，纯内存跑。但光向量不够，商品还有品牌、价格、库存这些标量属性，需要做[[混合检索]]，也就是向量相似度加标量过滤。这就要求数据库支持标量过滤下推到存储层，而不是先全量向量检索再过滤，否则延迟扛不住。
这里有个风险点：索引构建和更新。HNSW 构建很吃内存，如果数据频繁更新，直接原地动图索引会导致召回率下降。我的做法是增量更新走软删除加异步重建，用双缓冲影子索引，构建完用固定 query 集回放对比 Recall@K 和延迟，达标才原子切换，不达标回滚。上线后还要监控内存和查询 P99，防止 OOM 或者慢查询打满。
所以我的选型思路是：先明确业务对延迟和规模的容忍度，再挑索引类型，然后看扩展性和生态集成。没有万能方案，我更倾向先用成熟的开源方案比如 Milvus 快速跑通，等规模真到了瓶颈再针对性优化，而不是一开始就自研。
另外，选型时还要考虑一个容易被忽略的点：如果业务需要[[多模态]]向量，比如文本和图片用不同模型编码，能不能在同一个库中做跨模态检索？有些库支持多向量字段，有些不行，这会直接影响架构设计。