想象你是一家集团公司的技术负责人，老板要求你为“企业知识助手”选一座记忆图书馆。这座图书馆的职责不是存放纸质书，而是存放 AI 的“知识记忆”——也就是文档被切分后生成的向量。你不需要关心书的内容，只需要关心四件事：图书能不能快速上架、读者能不能快速找到书、分馆能不能轻松扩建、年度预算够不够花。现在有四个候选团队来竞标：国家级大馆 Milvus、全托管外包馆 Pinecone、小区门口的书房 Chroma，以及灵活自主的独立书库 Weaviate。它们都能完成“按语义找资料”这个核心动作，但在性能、扩展性、部署方式和成本上各有性格。本文就用这个贯穿始终的“图书馆”比喻，带你看懂四者的对比测试数据，掌握一套可落地的选型决策方法。

岗位关联

在 RAG 项目中选对向量数据库，等于同时省下服务器成本、运维人力和线上事故率。这是架构师和 AI 工程师必须建立的判断力，也是从“能跑通 Demo”走向“能扛生产流量”的关键一步。

目录
  1. 可视化演示
  2. 四大数据库概览
  3. 功能特性对比
  4. 写入性能测试
  5. 查询性能测试
  6. 扩展能力考验
  7. 部署方式分析
  8. 成本模式拆解
  9. 选型决策指南
  10. AI 应用场景
  11. Python 演示
  12. 常见误区
  13. 面试题

可视化演示

通过多维度性能雷达对比、查询延迟随数据规模增长曲线、以及基于场景的选型决策树，展示Milvus/Pinecone/Chroma/Weaviate四大向量数据库的选型指南。

本节配有交互动效（进入视口后自动加载，约 3KB）。

四维向量数据库性能雷达 Milvus分布式架构十亿级向量支持高扩展性 Pinecone全托管低运维但成本较高 Score=Avg(QPS,Lat,Scl,Ease,Cost) 多维度雷达直观对比选型

四大数据库概览

想象你走进竞标现场，四座“图书馆”的代表依次起身。第一位是 Milvus，国家级大馆：由开源社区 Zilliz 主导，擅长容纳亿级向量，还配有 GPU 加速通道和多种索引工具，适合真正的大规模生产场景，但需要专职图书管理员团队来运维。第二位是 Pinecone，全外包的云上图书馆：你只需要把书单发过去，它替你完成扩容、备份、高可用，省心省力，但费用按用量结算，烧钱速度不低。第三位是 Chroma，小区门口的书房：一条命令就能搭起来，写原型、跑 Demo 极其顺手，可藏书一多、客人一多它就手忙脚乱。第四位是 Weaviate，独立书库：开源、灵活，自带分类过滤与多模态插件，是中小规模自控场景里平衡得最好的选手。

这四者的“馆藏容量”差异，我们可以用一个很简单的公式感受一下：裸数据量 = 向量条数 × 维度 × 单个数字占的字节数。

回到比喻：千万级向量的原始体积动辄几十 GB，所以“国图 Milvus”需要一栋藏书楼来装，而“小区书房 Chroma”的书架数量天然受限。理解了这一点，我们就能带着规模意识进入下一轮比较。

Mraw=N×d×4 bytesM_{\text{raw}} = N \times d \times 4\ \text{bytes}
这个公式计算的是“完全不打折”的原始向量所需内存，只是理解规模的基础门槛。
  1. N 向量条数N 是你要存储的向量总数。若你切分了 100 万段文本，则 N = 1,000,000。
    N=向量总数N = \text{向量总数}
  2. d 向量维度d 是每条向量的维度。常见的 text-embedding-3-small 等模型输出 1536 维，则 d = 1536。
    d=每维向量的长度d = \text{每维向量的长度}
  3. 4 字节存储float32 单精度浮点数在内存中占 4 字节，是向量数据库的默认数值精度。
    4 bytes=float32 单精度浮点大小4\ \text{bytes} = \text{float32 单精度浮点大小}

功能特性对比

图书馆选完馆舍，接下来要看“查书系统”的本事。四家图书馆都提供索引算法、标量过滤、元数据管理和生态扩展工具，但侧重完全不同。Milvus 的索引选项最多，既有主打高召回率的 HNSW 图索引，也有针对超大容量场景的 IVFPQ 量化索引；Pinecone 把复杂的索引参数封装成托管服务，你只需声明“要快还是要准”；Chroma 以简单取胜，底层索引开箱即用，但留给高级调参的空间很少；Weaviate 支持多种索引策略，还内置了对象属性过滤，可以像“按书的分类标签找书”一样对非向量字段做精确筛选。

衡量这些检索策略好坏，最常用的指标是召回率，它回答的问题是：“真正想要的 k 本书，系统真的找回来了几本？”

回到类比，如果你要“找齐主题相近的十本书”，一个优秀的检索系统至少要给你找回七八本。Milvus 在 HNSW 高召回配置下常能逼近 95% 以上，而追求极致速度的轻量配置会有所下降；Pinecone 和 Weaviate 默认表现也不错；Chroma 在小规模数据上召回可观，但在数据量膨胀后，索引压缩策略会影响命中率。功能对比没有绝对赢家，只有与你的“找书场景”是否匹配。

Recall@k=∣Gk∩Rk∣k×100%\text{Recall@k} = \frac{\left| G_k \cap R_k \right|}{k} \times 100\%
召回率越接近 100%，说明检索结果越完整。它不是唯一指标，但能一眼看出不同索引算法对检索质量的影响。
  1. G_k 真实邻居集合在测试数据集中提前算好的、真正与查询向量最相似的 k 个向量，相当于“标准答案”。
    Gk=真实最近邻集合G_k = \text{真实最近邻集合}
  2. R_k 检索结果集合向量数据库实际返回的前 k 个结果，即“系统交出的答卷”。
    Rk=系统返回的前 k 个结果R_k = \text{系统返回的前 k 个结果}
  3. 交集比 k取出两者重合的数量，再除以 k，得到命中比例。
    ∣Gk∩Rk∣=两者重叠的个数\left| G_k \cap R_k \right| = \text{两者重叠的个数}

写入性能测试

竞标第二项，是“图书上架”的速度。你可以想象一批新书运到馆门口，图书管理员需要把每本书扫描、分类、放上书架。Milvus 像一条分工明确的流水线，支持大批量导入，官方社区实测批量写入可达每秒数万到数十万条向量；Pinecone 作为托管服务，写入会被自动均衡到多个节点，吞吐表现稳定但单价高昂；Weaviate 紧随其后，批量写入也能维持不错的吞吐；Chroma 的写入就要佛系得多，它本质上是嵌入式单机方案，大批量写入时吞吐会明显下滑。

吞吐量的计算本身就说明问题：一段时间内完成的写入总量，除以总耗时。

值得注意的是持久化策略：Chroma 在嵌入式场景里常把数据保存在本地磁盘，写入快但安全冗余弱；Milvus 支持同步刷盘与数据多副本，写入吞吐虽受一定折损，却换来了更可靠的数据持久性。选型时若数据丢失会造成严重事故，千万别只盯瞬间吞吐数字。

Throughput=NvectorsTseconds\text{Throughput} = \frac{N_{\text{vectors}}}{T_{\text{seconds}}}
这个公式衡量“每秒能上架多少本书”。
  1. N_vectors 写入向量总数本次测试中总共写入的向量条数，例如 1,000,000 条。
    Nvectors=写入完成的向量条数N_{\text{vectors}} = \text{写入完成的向量条数}
  2. T_seconds 总耗时从第一条写入开始到最后一条完成所经过的秒数。
    Tseconds=总写入耗时（秒）T_{\text{seconds}} = \text{总写入耗时（秒）}
  3. 二者相除用总量除以时间，得到平均每秒吞吐量。
    Throughput=每秒写入速率\text{Throughput} = \text{每秒写入速率}

查询性能测试

图书馆最终的价值在于“读者能不能快速找到书”。我们考察两个维度：延迟和召回质量。延迟环节，Milvus 和 Pinecone 表现明显优于 Chroma，在百万级向量规模下，P99 延迟可以做到几十毫秒以内；Weaviate 居中。所谓 P99，就是把所有查询的耗时从小到大排序，排在 99% 位置的那个数值。它代表最慢的那一小撮请求有多慢。

用图书馆打比方，P99 就像最磨蹭的 100 个读者里那个最慢的还在前台排队的时间。很多 RAG 应用要求秒级响应用户，如果 1% 的检索请求要等 2 秒，体验就会被明显拖累。Chroma 在低并发下延迟尚可，但在高并发查询时，单机资源争抢会造成 P99 飙升；Milvus 与 Pinecone 作为分布式架构，能更好地摊平这种“长尾延迟”。因此，做线上高并发服务时，务必把 P95/P99 纳入评估清单。

P99=min⁡{t:P(latency≤t)≥0.99}\text{P99} = \min \{ t : P(\text{latency} \le t) \ge 0.99 \}
P99 是比平均值更有工程意义的指标：平均延迟好看没用，最慢的 1% 请求往往才会击穿业务。
  1. t 延迟阈值我们试图找到一个时间阈值 t。
    t=候选延迟阈值t = \text{候选延迟阈值}
  2. P（延迟≤t） ≥ 0.99要求“延迟不超过 t 的请求比例”至少要达到 99%。
    P(latency≤t)≥0.99P(\text{latency} \le t) \ge 0.99
  3. 最小的 t满足条件的最小阈值就是 P99。
    P99=满足条件的边界延迟\text{P99} = \text{满足条件的边界延迟}

扩展能力考验

当公司的知识库从 10 万篇文档涨到 1000 万篇，图书馆必须扩张。这就要看各家的“分馆扩建”能力。Milvus 天然是分布式的，数据可以切分到多个节点并行检索，水平扩容能力最强；Pinecone 作为全托管服务，扩容由平台自动完成，几乎不需要你操心；Weaviate 支持多节点集群，扩容体验顺滑度仅次于前两者；Chroma 是单进程嵌入式架构，跨节点扩容非常吃力，数据量超过千万级以后往往需要完全重建方案。

水平扩容的核心是数据分片：把大图书馆拆成若干分馆，每馆只存一部分书。

比如 1000 万向量、每片上限 200 万，那就需要 5 个分片。Milvus 可以自动管理分片再平衡，Pinecone 甚至把分片细节完全隐藏，而 Chroma 因为不支持真正水平分片，在千万级场景就失去了参赛资格。高可用方面，分布式方案还要考虑副本数和故障转移能力，Milvus 和 Weaviate 支持多副本容灾，这是生产环境不可妥协的底线。

Shards=⌈NMmax⌉\text{Shards} = \left\lceil \frac{N}{M_{\text{max}}} \right\rceil
分片数决定了你要开多少家分馆，也决定了扩容的弹性粒度。
  1. N 总向量数全馆所有藏书（向量）的总数。
    N=向量总数N = \text{向量总数}
  2. M_max 单分片容量上限一个分片节点最多能装下的向量数量。
    Mmax=单分片最大容量M_{\text{max}} = \text{单分片最大容量}
  3. 向上取整用小数结果向上取整，保证每个分片都不会超载。
    ⌈⋅⌉=向上取整\left\lceil \cdot \right\rceil = \text{向上取整}

部署方式分析

部署方式决定了你要“亲手盖图书馆”还是“直接租办公室”。自托管方案以 Milvus 和 Weaviate 为代表：你可以用 Docker Compose 快速拉起一个单机实例，也可以部署到 Kubernetes 集群，数据完全掌握在自己手里。全托管方案以 Pinecone 为典型：无需关心节点状态、索引分片或自动扩容，适合没有专职运维团队的创业团队。嵌入式方案则是 Chroma 的强项：pip 安装后在 Python 进程内运行，几行代码就能让 RAG 原型跑起来。

部署层面还有一个绕不开的“可用性”指标，它衡量系统有多少时间在正常服务。

自托管并不自动等于高可用：Milvus 部署到 Kubernetes 后，你需要自己配置副本、监控、备份和滚动升级，运维成本不低；Pinecone 则把这些全部包揽。反过来，自托管的数据主权和成本可控性，又是金融、政务等领域绕不开的硬需求。部署方式的选择，本质上是“控制权”与“省心度”之间的取舍。

Availability=MTTFMTTF+MTTR×100%\text{Availability} = \frac{\text{MTTF}}{\text{MTTF} + \text{MTTR}} \times 100\%
MTTF 是平均无故障时间，MTTR 是平均修复时间。两者共同决定一年 365 天里系统能正常服务多久。
  1. MTTF 平均无故障时间系统运行多久才会发生一次故障。
    MTTF=平均无故障时间\text{MTTF} = \text{平均无故障时间}
  2. MTTR 平均修复时间故障发生后，平均要花多久才能恢复。
    MTTR=平均修复时间\text{MTTR} = \text{平均修复时间}
  3. 占比计算无故障时间越长，或修复时间越短，可用性就越高。
    Availability=可用率百分比\text{Availability} = \text{可用率百分比}

成本模式拆解

预算永远是选型的一票否决项。账单主要来自三部分：内存、存储、运维人力。向量检索极度依赖内存，索引通常需要加载到内存才能低延迟响应。用我们第一节的公式粗算，1000 万条 1536 维向量裸数据就有约 60GB，加上索引膨胀，成本非常可观。Pinecone 这类全托管服务按使用量计费，看似省心，账单却可能随数据增长指数上升；Chroma 作为嵌入式方案，单机内存成本可控，但无法扩展到需要多节点堆叠的规模。

一个清晰的月度成本模型如下：

很多团队把成本账算错，是因为只盯着存储单价，忽略了索引占用的内存和运维工程师的薪资。自托管 Milvus 看起来“开源免费”，但一名能搞定 Kubernetes 集群和索引调优的工程师月薪远超云服务账单；Pinecone 单价高，却可能省下一整个运维团队。这就是“账要算总账”的道理。

Cmonth=rram×RGB+sdisk×SGB+CopsC_{\text{month}} = r_{\text{ram}} \times R_{\text{GB}} + s_{\text{disk}} \times S_{\text{GB}} + C_{\text{ops}}
月度成本 = 内存单价 × 内存用量 + 存储单价 × 存储用量 + 运维固定成本。
  1. r_ram 内存单价每 GB 内存每月的租用价格。
    rram=单位内存月价格r_{\text{ram}} = \text{单位内存月价格}
  2. R_GB 内存用量索引常驻内存的吉字节数。
    RGB=内存占用R_{\text{GB}} = \text{内存占用}
  3. s_disk 存储单价每 GB 磁盘每月的存储成本。
    sdisk=单位存储月价格s_{\text{disk}} = \text{单位存储月价格}
  4. C_ops 运维成本包含 DBA 人力、监控告警、故障处理等隐性费用。
    Cops=运维人力等固定成本C_{\text{ops}} = \text{运维人力等固定成本}

选型决策指南

竞标进入收官阶段，我们把四家候选放在一起打分。没有绝对的“最好的数据库”，只有“最适合你的数据库”。决策主要看四个变量：数据规模、性能需求、团队运维能力、预算约束。如果数据量在百万级以下且追求快速验证，Chroma 是首选；如果数据量大、并发高且有运维团队，Milvus 能带来极致的性价比；如果数据量大但团队小，Pinecone 用钱换时间；如果既要可控又要灵活性，Weaviate 是最稳的中间项。

将各项需求量化为权重，就能得到一套简单的加权评分模型：

把权重列成一张矩阵，就是“场景匹配矩阵”：100 万条以下、内部工具、快速原型 → Chroma；100 万到 1 亿条、有专职运维 → Milvus；1 亿条以上、团队精简 → Pinecone；千万级、预算中等、要数据自控 → Weaviate或 Milvus 自托管。这张矩阵不是懒人模板，而是一份让你站在全局视角做取舍的地图。

Score=wwriteTwrite+wqueryTquery+wscaleS+weaseE+wcostC\text{Score} = w_{\text{write}}T_{\text{write}} + w_{\text{query}}T_{\text{query}} + w_{\text{scale}}S + w_{\text{ease}}E + w_{\text{cost}}C
每个权重代表你对某个维度的重视程度，权重之和为 1。最终得分最高的选手就是当前场景的最优解。
  1. T_write 与 T_query 性能得分在写入和查询压测中得到的相对性能分。
    Twrite, Tquery=性能测试得分T_{\text{write}},\ T_{\text{query}} = \text{性能测试得分}
  2. S 扩展能力得分数据规模增长到目标值后，数据库仍能保持稳定运行的能力。
    S=扩容能力得分S = \text{扩容能力得分}
  3. E 易用性得分部署、升级、排查问题的顺畅程度。
    E=易用性得分E = \text{易用性得分}
  4. C 成本得分综合内存、存储与运维人力的整体成本评分，成本越低分越高。
    C=成本得分C = \text{成本得分}

AI 应用场景

企业 RAG 知识库选型

阶段：数据索引与检索增强生成（RAG）

解决的问题：传统关键词搜索无法理解语义，团队不知道应该选哪个向量数据库，导致线上检索延迟忽高忽低、运维事故频发。AI 方案是先按本文方法评估数据规模与团队能力，再选择匹配的数据库，建立稳定检索链路。

具体案例：某零售企业要把 50 万份产品手册、客服记录做成内部问答助手。选型小组先在测试环境用 10 万条向量对 Milvus、Pinecone、Chroma 做了 P99 延迟和导入吞吐压测，发现 Chroma 在高并发下 P99 飙升至 800ms，最终选定自托管 Milvus 并配置 3 副本，线上 P99 稳定在 30ms 以内。

初创产品快速验证

阶段：原型验证与 MVP 落地

解决的问题：初创团队没有专职运维，需求是尽快做出 RAG 效果给客户演示。AI 方案用 Chroma 的嵌入式能力在几天内完成业务验证，等用户量增长后再迁移到可水平扩展的数据库。

具体案例：一家法律科技创业公司在两周内用 Chroma 搭建了合同条款问答 Demo，验证了语义检索能帮律师快速定位相关判例。拿到种子轮投资后，数据量突破 1000 万条，团队将数据迁移到 Milvus，并使用官方工具完成全量重建索引，迁移期间服务保持可用。

金融级低延迟检索

阶段：在线推理与实时特征检索

解决的问题：风控系统需要在 50ms 内完成相似交易样本召回，且数据不能出域，无法使用纯 SaaS 方案。AI 方案采用自托管 Milvus 或 Weaviate，配合多副本与 GPU 加速，实现低延迟高可用。

具体案例：某支付公司用 Weaviate 构建跨账户交易模式检索，支持按商户、金额区间等元数据过滤，写入了 2000 万条交易向量。在双十一流量高峰时段，查询 P99 保持在 45ms，满足风控实时决策要求。

Python 演示

python41 行
"""向量数据库性能对比选型小助手"""import math  def main():    data_scale = float(input("预计向量规模(万条): "))    read_qps = float(input("峰值查询QPS: "))    latency_ok = float(input("可接受延迟(毫秒): "))    team = input("团队能力(入门/中等/资深): ").strip()    team_level = {"入门": 1.0, "中等": 0.6, "资深": 0.3}.get(team, 0.6)     # 五个维度: [写入能力, 查询能力, 扩容能力, 易用性, 成本友好]    db_scores = {        "Milvus": [95, 92, 95, 50, 55],        "Pinecone": [70, 88, 99, 90, 30],        "Chroma": [40, 55, 30, 95, 90],        "Weaviate": [60, 70, 65, 75, 65],    }     w_scale = 0.35 if data_scale > 100 else 0.15    w_query = 0.35 if latency_ok <= 20 else 0.20    w_write = 0.20 if read_qps > 100 else 0.10    w_ease = 0.25 * team_level    w_cost = 0.15     results = {}    for name, scores in db_scores.items():        write, query, scale, ease, cost = scores        score = write * w_write + query * w_query + scale * w_scale        score += ease * w_ease + cost * w_cost        results[name] = round(score, 2)     ranking = sorted(results.items(), key=lambda x: x[1], reverse=True)    print("综合评分排名:")    for name, score in ranking:        mark = " <- 推荐" if score == ranking[0][1] else ""        print("  {}: {}{}".format(name, score, mark))  if __name__ == "__main__":    main()
目的：根据向量规模、查询压力、延迟要求和团队能力，对四个候选数据库做加权评分排序。
  1. team_level = {"入门": 1.0, "中等": 0.6, "资深": 0.3}.get(team, 0.6)团队越强，易用性权重越低，因为你们有能力驯服复杂系统。
  2. db_scores = {把四个数据库在五个维度上的相对得分写成结构化字典，方便后续加权计算。
  3. w_scale = 0.35 if data_scale > 100 else 0.15数据规模越大，扩容能力在评分中的权重越高。
  4. w_query = 0.35 if latency_ok <= 20 else 0.20延迟要求越严格，查询性能的权重越高。
  5. score = write * w_write + query * w_query + scale * w_scale核心加权公式，与正文中的选型评分模型完全对应。
  6. ranking = sorted(results.items(), key=lambda x: x[1], reverse=True)按得分从高到低排序，输出推荐顺序。

常见误区

误区我本地用 Chroma 跑 RAG 效果很好，线上直接用不就行了，没必要换数据库。

正解Chromaa 的定位是嵌入式轻量级方案，就像小区书房，接待几位读者很轻松，但遇到几百人同时涌入就会瘫痪。线上生产通常要求高并发、可扩容、高可用，Chroma 在单机资源耗尽后 P99 延迟会急剧恶化，也不支持真正的水平扩容。正确做法是先用 Chroma 验证效果，再根据数据规模迁移到 Milvus 或 Pinecone。

为何常见：本地 Demo 的数据量和并发极低，掩盖了 Chroma 在资源瓶颈下的性能缺陷，让人误以为生产环境也足够。

误区Milvus 是开源的，部署到我们自己的服务器上，就不用再花数据库的钱了。

正解开源意味着免许可证费用，但不代表免运维。Milvus 落地到生产环境需要你配置 Kubernetes、对象存储、监控告警、备份恢复、索引调优和安全策略。一个专职运维工程师的月薪往往比商业 SaaS 账单还贵，这就是为什么很多小团队最终选择 Pinecone 等全托管服务。

为何常见：人们容易把“开源”直观理解为“不要钱”，忽略了软件生命周期中的基础设施和人力开销。

误区网上有人测过 Milvus 每秒能写 10 万条向量，我照这个标准做容量规划就行了。

正解性能数字强依赖硬件配置、向量维度、索引参数、批次大小和数据分布。别人用的是 32 核机器和 128 维向量，你的业务可能是 8 核机器和 1536 维向量。必须用真实数据和真实查询模式做一轮自己的压测，记录写入吞吐、P99 延迟和召回率，才能真正指导容量规划。

为何常见：社区和厂商公布的基准测试往往展示理想条件的最优表现，读者容易把“最高成绩”当成“平均表现”。

误区测试时发现 A 库查询延迟明显低于 B 库，那就直接选 A 库吧。

正解延迟只是其中一个维度。B 库可能用更激进的索引压缩换来了更快的速度，但召回率下降严重，用户会频繁搜不到相关内容。RAG 系统里，召回质量直接决定最终生成答案的质量。正确评估必须同时看延迟、召回率和并发吞吐，再结合数据规模与成本做综合判断。

为何常见：人们习惯用最容易观测的数字做决策，而召回率需要构造标准答案集，测试成本更高，于是被忽略。

面试题

Q1. 在 RAG 系统中，向量数据库的核心职责是什么？

单选题 · easy

  • A.对关键词做精确匹配索引
  • B.对文本做生成式内容摘要
  • C.对向量做近似最近邻检索← 正确答案
  • D.对用户做登录身份验证

答案：C。向量数据库的核心是“按语义找相似”，即对查询向量做近似最近邻检索。关键词匹配是传统搜索引擎的职责；生成式摘要是大模型的行为；身份验证与检索无关。可以理解为图书馆的“按主题找相似书籍”功能。

Q2. 下列哪项是向量数据库常用的距离度量？

单选题 · easy

  • A.欧氏距离← 正确答案
  • B.哈希碰撞率
  • C.编译执行耗时
  • D.JSON 字段嵌套层数

答案：A。欧氏距离衡量两个点在空间中的直线距离，是向量检索最常用的度量之一。哈希碰撞率、编译耗时和 JSON 嵌套层数都不是向量相似度度量。类比图书馆里比较两本书的主题相似度，就像测量它们在“语义空间”中相隔多远。

Q3. 某系统 P99 延迟为 20ms，最准确的理解是？

单选题 · mid

  • A.99% 的查询延迟超过 20 毫秒
  • B.1% 的查询延迟恰好等于 20 毫秒
  • C.99% 的查询延迟不超过 20 毫秒← 正确答案
  • D.所有查询的平均延迟等于 20 毫秒

答案：C。P99 的含义是把所有查询延迟排序，99% 的请求都不超过该值，只有最慢的 1% 可能超过它。平均延迟无法体现长尾状况，而 P99 才是保障用户体验的关键指标，就像关注图书馆里最慢的排队读者。

Q4. 下列哪个场景最适合选用 Chroma？

单选题 · mid

  • A.早期原型与示例代码开发← 正确答案
  • B.千万级向量在线高并发服务
  • C.企业内部数据权限统一管理
  • D.跨城市部署的容灾高可用集群

答案：A。Chroma 是嵌入式轻量级数据库，安装简单、上手快，适合原型验证和教学示例。千万级高并发、权限管理和跨城容灾都需要分布式能力，是 Milvus、Pinecone 等方案的领域，就像小区书房不适合承担国家级图书馆的职责。

Q5. Milvus 能在性能测试中表现突出的原因包括？

多选题 · mid

  • A.支持向量批量导入写入← 正确答案
  • B.采用分布式计算架构← 正确答案
  • C.提供 GPU 索引加速能力← 正确答案
  • D.完全禁止标量属性过滤

答案：ABC。Milvus 的批量导入提升写入吞吐，分布式架构让它可以水平扩容，GPU 加速则显著降低索引构建和查询延迟。选项 D 错误，Milvus 恰恰支持标量过滤。就像国图既有多个分馆并行，又有自动分拣机器，自然比小书房快得多。

Q6. 向量数据到达千万级以上时，选型最需要关注哪项能力？

单选题 · hard

  • A.数据分片策略是否可扩展← 正确答案
  • B.前端操作界面是否美观
  • C.数据模型是否采用 XML
  • D.用户密码是否用了加密

答案：A。千万级数据必须依赖分片把检索压力分散到多节点，分片策略决定了系统能否平滑扩容。界面美观、XML 数据模型和密码加密都与向量检索性能无关。类比图书馆扩建分馆时，关键在于书架如何分配，而不是装饰是否好看。

Q7. 对比全托管与自托管向量数据库，正确的说法包括？

多选题 · hard

  • A.全托管方案能降低运维负担← 正确答案
  • B.自托管方案需自行处理高可用← 正确答案
  • C.全托管方案通常按用量计费← 正确答案
  • D.自托管方案性能一定更差

答案：ABC。全托管把扩容、备份、告警都交给服务商，显著降低运维投入，但也意味着按资源用量付费。自托管需要自己配置多副本和故障转移才能实现高可用，但性能未必差，反而可能更优。把这个场景想成租用图书馆服务与自己盖馆的区别。

Q8. 在做向量数据库综合成本评估时，最容易被忽略的是？

单选题 · hard

  • A.索引向量占用的内存开销
  • B.跨地区部署的网络带宽
  • C.人员培训与迁移的隐性成本← 正确答案
  • D.批量导入消耗的磁盘空间

答案：C。工程师学习新数据库、改造代码、迁移数据和排障的时间成本，往往比硬件账单更难提前量化。内存、带宽和磁盘都是显性账单，而隐性人力成本经常在项目结束后才暴露。就像搬家时纸箱和运费算得清，但打包整理的时间却常被低估。

Q9. 某团队计划把 RAG 服务从 Chroma 迁移到 Milvus，正确的做法是？

多选题 · extreme

  • A.原样复制全部查询代码
  • B.按新环境重新构建索引← 正确答案
  • C.提前评估数据分片策略← 正确答案
  • D.忽略向量维度变化影响

答案：BC。迁移到新数据库必须重新构建索引，因为两家的存储格式和索引参数不同；同时要提前设计分片策略以应对数据增长。原样复制代码不可行，因为 API 和查询语法有差异；向量维度由嵌入模型决定，迁移本身不改变维度，但忽略维度会影响容量规划。

Q10. Recall@k 指标在向量检索中表示什么？

单选题 · mid

  • A.前 k 个结果中真实相关的占比← 正确答案
  • B.全部检索请求的平均耗时
  • C.索引占用的存储空间大小
  • D.单次写入操作的数据吞吐

答案：A。Recall@k 计算系统返回的前 k 个结果里，有多少是真正的相关项。它衡量的是“找到得全不全”。平均耗时是延迟指标，存储空间和吞吐量与召回率无关。类比借书时，你希望系统在前十本推荐里尽量多地包含真正想看的书。