设想你是一位即将开张的餐厅老板——只不过这家餐厅卖的不是饭菜，而是知识。顾客抛来一个问题，后厨要在几秒钟内从上万份食材里找出最匹配的几份配料，拼成一盘回答。这份“食材库”，就是 RAG（检索增强生成）架构里的向量数据库。市面上的 Faiss、Milvus、Chroma、Pinecone、Weaviate，就像有人卖专业刀具、有人卖便携饭盒、有人整租后厨、有人干脆做云上代厨。Faiss 便宜灵活但得自己砌灶台，Chroma 拆箱即用却装不下大客流，Milvus 能扛亿级食客但装修成本高，Pinecone 和 Weaviate 则把厨房搬到云端按量收费。这篇文章带你挨个参观这五间“储藏室”，看清容量、厨具、开销和运维门槛，最后学会按自己的客流和手艺做选型。

岗位关联

对 AI 从业者而言，向量数据库选型是 RAG 系统的地基工程。学完本文，你能依据数据规模、延迟预算与团队运维能力做出有据可依的架构决策，避免上线后推倒重来。

目录
  1. 可视化演示
  2. 向量库基础
  3. Faiss 灵活之选
  4. Milvus 生产之选
  5. Chroma 轻量之选
  6. 托管服务之选
  7. 选型决策之道
  8. AI 应用场景
  9. Python 演示
  10. 常见误区
  11. 面试题

可视化演示

展示Faiss/Milvus/Chroma/Pinecone/Weaviate五大向量数据库的功能矩阵、性能基准和选型决策框架。切换模式探索最优向量DB选型。

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

主流向量数据库功能矩阵 Faiss是高性能检索库非数据库，Milvus是分布式向量数据库支持持久化 Chroma轻量易用适合原型，Pinecone全托管云服务，Weaviate支持混合检索 features: persistence | GPU | distributed | hybrid_search | managed 功能矩阵是选型的第一维度

向量库基础

开一家餐厅，最怕的不是菜不会做，而是要用时找不到料。好大厨会把切好的食材按“味道”分装——生姜、大蒜、辣椒虽然都是调味品，但和牛腩放在一起的必须是八角桂皮。向量数据库做的事，就是把每份文档切成小段、榨成酱汁（embedding 向量），再按“味道相似度”摆进储藏室。你不用告诉它“这是川菜”，它自己知道水煮鱼和毛血旺味道接近。

这个“酱汁”其实是一串几百位的数字列表，专业上叫向量，每个数字代表食材在某个“风味维度”上的强度。判断两罐酱汁像不像，算法会计算它们之间的夹角——夹角越小，余弦相似度越高。这就是向量检索最核心的度量方式，RAG 靠它在大海一样的文档库里秒级捞回最相关的段落。

除了算相似度，储藏室还要解决“快”。几百万个罐子挨个拧开尝一遍显然不现实，于是有了各种索引结构：暴力扫描（Flat）最精确但费时；聚类索引（IVF）先把罐子分成几百个隔层，只翻最可能的那几层；图索引（HNSW）在罐子之间拉起导航线，沿着线走几步就能到目的地。索引越聪明，召回越准，但建索引的内存和耗时也越高。

理解了酱料怎么相似、怎么加速翻找，你就能看懂各家储藏室的差别了——有的只卖刀具，有的送整套冷库，关键看你的食材规模和后厨人手。下面我们一间一间逛。

similarity(A,B)=cos⁡(θ)=A⋅B∥A∥×∥B∥=∑i=1nAiBi∑i=1nAi2×∑i=1nBi2\displaystyle \text{similarity}(\mathbf{A}, \mathbf{B}) = \cos(\theta) = \frac{\mathbf{A} \cdot \mathbf{B}}{\|\mathbf{A}\| \times \|\mathbf{B}\|} = \frac{\sum_{i=1}^{n} A_i B_i}{\sqrt{\sum_{i=1}^{n} A_i^2} \times \sqrt{\sum_{i=1}^{n} B_i^2}}
酱料夹角越小，味道越接近。余弦值从 1（完全一样）到 -1（完全相反），0 则表示毫不相关。
  1. 分子点积两个向量的每个维度相乘后全部加起来，衡量方向一致程度。
    A⋅B=∑i=1nAiBi\displaystyle \mathbf{A} \cdot \mathbf{B} = \sum_{i=1}^{n} A_i B_i
  2. 分母模长向量自身的长度，等于所有分量平方之和再开根号。
    ∥A∥=∑i=1nAi2\displaystyle \|\mathbf{A}\| = \sqrt{\sum_{i=1}^{n} A_i^2}
  3. 余弦比值点积除以两个模长的乘积，结果落在 -1 到 1，越接近 1 越相似。
    cos⁡(θ)=A⋅B∥A∥×∥B∥\displaystyle \cos(\theta) = \frac{\mathbf{A} \cdot \mathbf{B}}{\|\mathbf{A}\| \times \|\mathbf{B}\|}

Faiss 灵活之选

Faiss 就像你从刀具行抱回来的一套绝版双立人：锋利、便宜、想怎么切就怎么切，但它只是一套刀——没有灶台、没有冰箱，更没有帮你收拾的帮厨。你需要自己找厨房（写服务）、自己冻肉（管内存）、自己设计菜单（写接口）。它是 Meta 开源的向量检索算法库，不是完整数据库：不负责持久化，不提供网络接口，数据在内存里“裸奔”。

好在它的强项是把各种索引算法（Flat、IVF、HNSW、乘积量化 PQ）做成极致优化的 C++ 模块，GPU 加速随便上。对离线批量计算、自研检索服务、以及想深度控制索引细节的团队来说，它是自由度最高的选择。代价是——你得自己当服务员、传菜员和洗碗工。

用 Faiss 前，最该算清楚的是内存账。float32 向量每条 768 维占 3KB，存 100 万条就是 3GB 内存，1000 万条直接冲到 30GB。算完这笔账，再决定要不要用乘积量化（PQ，一种把向量压缩成码本编号的省内存技术）——压缩能省约 90% 内存，但会牺牲一点精度。

一句话：如果你是大厂后厨，有专门团队砌灶台，Faiss 是把性价比拉满的刀。但如果你只想开个小面馆，这套刀可能连案板都没有——下一间储藏室也许更适合你。

Memory=N×d×4 bytes\displaystyle \text{Memory} = N \times d \times 4 \text{ bytes}
这条“内存账”告诉你：选 Faiss 前先把数据规模换算成内存成本。100 万条 768 维向量就要吃掉约 3GB 内存。
  1. 元素总数向量条数与维度的乘积，表示所有向量的总元素个数。
    Nelements=N×d\displaystyle N_{\text{elements}} = N \times d
  2. 单元素字节float32 浮点数每个占 4 个字节，这是向量存储的默认精度。
    bytes per element=4\displaystyle \text{bytes per element} = 4
  3. 总容量元素总数乘以单元素字节数，得到裸向量占用的内存。
    Memory=N×d×4 bytes\displaystyle \text{Memory} = N \times d \times 4 \text{ bytes}

Milvus 生产之选

Milvus 像你租下来的整套中央后厨：不锈钢灶台、冷藏库、洗碗间、传菜电梯一应俱全。开张那天不用再到处买菜刀，缺点是进场要装修（部署运维），房租也贵。它是开源的分布式向量数据库，把向量数据落到磁盘，支持持久化、多副本、水平扩展，内部把查询拆到多个 worker 节点并行处理，亿级向量不在话下。

这是它和 Faiss 最本质的区别：Faiss 是库，你得自己当服务员；Milvus 是餐厅，你只管接待客人。它还支持混合查询——先按标签过滤再比相似度。比如“只找川菜里和水煮鱼味道像的”，系统先划掉非川菜，再在剩下的罐子里找近邻，既快又准。

衡量这种检索质量，业界常用 Recall@k：系统返回前 k 个候选里，有多少比例是真正相关的。比如后厨有 10 道预定菜，第一轮传菜只端对了 7 道，Recall@10 就是 0.7。线上系统常在召回率和延迟之间做权衡：索引更激进，召回率下降、延迟下降；索引更保守，召回率上升、延迟上升。

如果图省事选轻量方案，等数据量涨到千万级再迁移，就像面馆突然接到婚宴包场，灶台根本转不过来。Milvus 适合一开始就按“可能会火”来装修的餐厅。

Recall@k=∣Rrelevant∩Rretrievedk∣∣Rrelevant∣\displaystyle \text{Recall@}k = \frac{|R_{\text{relevant}} \cap R_{\text{retrieved}_k}|}{|R_{\text{relevant}}|}
相当于后厨抽查：一共 10 道预定菜，第一轮传菜只端对 7 道，Recall@10 就是 0.7，越高说明传菜员找得越准。
  1. 相关集合$R_{\text{relevant}}$ 是标准答案里与提问真正相关的文档全集，分母是它的总数。
    Rrelevant\displaystyle R_{\text{relevant}}
  2. 召回集合$R_{\text{retrieved}_k}$ 是系统返回的前 k 个候选文档，分子取两者交集的大小。
    ∣Rrelevant∩Rretrievedk∣\displaystyle |R_{\text{relevant}} \cap R_{\text{retrieved}_k}|
  3. 比值评估交集大小除以相关总数，得到前 k 个结果对相关文档的覆盖比例。
    Recall@k=∣Rrelevant∩Rretrievedk∣∣Rrelevant∣\displaystyle \text{Recall@}k = \frac{|R_{\text{relevant}} \cap R_{\text{retrieved}_k}|}{|R_{\text{relevant}}|}

Chroma 轻量之选

Chroma 是那个塞在双肩包里的保温饭盒：打开盖子就能吃，不用灶台不用电。它适合昨天刚想通要做 RAG、今天就想看到检索效果的你。它是个轻量级嵌入式向量数据库，pip install 一条命令装好，跑在本地进程里，Python 接口友好得像在操作一个字典。

它还天然支持元数据过滤：给每份文档打个“菜系”“辣度”标签，检索时先筛标签再比味道。对早期的 RAG 原型验证来说，这是迭代速度最快的组合——你可以一边调 Embedding 模型，一边看检索效果，几乎零成本。

但它的取舍也很清晰：默认 Flat 暴力扫描，数据量在几千到几百万时都够用，一旦超过这个量级，性能和持久化能力就开始吃紧，也不适合多实例高并发。过滤逻辑可以看成一个分段打分函数：标签不符的食材直接打入冷宫，分数负无穷；标签合格者才按余弦相似度竞争出线。

但保温饭盒终究不能当婚宴后厨。Chroma 适合快速试菜，等你验证了口味和方向，再考虑把菜谱搬进 Milvus 这样的正厨房。

score(d)={cos⁡(q,d),if meta(d)∈filter−∞,otherwise\displaystyle \text{score}(\mathbf{d}) = \begin{cases} \cos(\mathbf{q}, \mathbf{d}), & \text{if } \text{meta}(\mathbf{d}) \in \text{filter} \\ -\infty, & \text{otherwise} \end{cases}
这等于储藏室的“先筛后比”规则：标签不符的食材直接出局，只有合格者才按味道相似度排序竞争名额。
  1. 合格打分当文档的元数据通过过滤器时，分数等于查询向量与文档向量的余弦相似度。
    cos⁡(q,d)\displaystyle \cos(\mathbf{q}, \mathbf{d})
  2. 不合格即弃标签不过关的文档分数设为负无穷，在排序时永远不会入选。
    score=−∞\displaystyle \text{score} = -\infty
  3. 分段统一用分段函数把两种情形写进同一个打分规则，这就是元数据过滤的实现逻辑。
    score(d)={cos⁡(q,d),if meta(d)∈filter−∞,otherwise\displaystyle \text{score}(\mathbf{d}) = \begin{cases} \cos(\mathbf{q}, \mathbf{d}), & \text{if } \text{meta}(\mathbf{d}) \in \text{filter} \\ -\infty, & \text{otherwise} \end{cases}

托管服务之选

Pinecone、Weaviate 这类托管服务，相当于你连厨房都不租，直接喊中央厨房代工：把菜谱交给它，它负责采购、切配、翻炒、出餐，你只按订单付费，偶尔打开手机看一眼监控数据。Pinecone 是纯 SaaS 托管向量数据库，不用部署、不用调参，控制台上传数据就能查，适合不想碰基建的团队。

Weaviate 则是开源可自托管、也可以上云的方案，内置了自动向量化（把文本直接交给它，它自己调用模型编码）和 GraphQL 查询，甚至自带多模态插件。两者共同点是：免运维、弹性伸缩、用量付费。对小团队或快速上线场景，托管服务能省掉一个专职运维工程师。

选托管服务的核心是算成本账。总成本不只是按小时计价的账单，还包括存储费用、查询费用、网络流量，以及人工运维的隐形开销。自建看起来便宜，但一个能 7×24 小时值班的运维工程师，一年工资都能买下好几年的云服务。另一个关键是数据合规：如果客户数据不能出公司网络，托管服务再香也只能眼馋。

云上代厨解决了“不会做饭”的问题，代价是把厨房钥匙交给了别人。数据敏感、预算敏感、网络隔离要求高的场景，还是得请回自家大厨。

Ctotal=Cstorage+Ccompute+Cnetwork+Cops\displaystyle C_{\text{total}} = C_{\text{storage}} + C_{\text{compute}} + C_{\text{network}} + C_{\text{ops}}
这张“成本单”提醒老板：账单不只是云服务商的月租，还有仓储费、火力费、传菜快递费和每晚值班的厨师工时费。
  1. 存储与算力$C_{\text{storage}}$ 是向量数据与索引的存储开销，$C_{\text{compute}}$ 是每次查询消耗的 CPU/GPU 费用。
    Cstorage+Ccompute\displaystyle C_{\text{storage}} + C_{\text{compute}}
  2. 网络与运维$C_{\text{network}}$ 是流量传输费用，$C_{\text{ops}}$ 是排查故障、扩缩容、值班维护折算的人力成本。
    Cnetwork+Cops\displaystyle C_{\text{network}} + C_{\text{ops}}
  3. 总成本求和四类费用相加才是完整拥有成本（TCO），自建与托管谁划算，必须以它为基准。
    Ctotal=Cstorage+Ccompute+Cnetwork+Cops\displaystyle C_{\text{total}} = C_{\text{storage}} + C_{\text{compute}} + C_{\text{network}} + C_{\text{ops}}

选型决策之道

现在你面前有六套方案，最终拍板的不是厨师，是老板。老板只看四件事：客流（数据规模）、翻台率（延迟要求）、预算（成本）和自家团队的厨艺（运维能力）。从规模出发：十万级以下、追求快速原型，选 Chroma；百万级、要算法可控，选 Faiss；千万级起步、要持久化和高可用，选 Milvus；不想管服务器且数据合规允许，选 Pinecone 或 Weaviate。

规模之外的隐藏维度是延迟预算——从用户提问到拿到答案的端到端时间。这个时间由三部分构成：索引查询耗时、网络传输耗时、重排序精排耗时。比如业务要求 200ms 内出结果，你就得倒推：索引花 80ms，网络花 70ms，精排只能剩 50ms，超了就要换更快的索引或加缓存。

生态也不能忽略：Faiss 有最丰富的算法社区，Milvus 与 Kubernetes 集成成熟，Chroma 与 LangChain 开箱即用，Pinecone 有最省心的控制台。最后还有迁移成本——向量库不是 Excel，导出导入不是拧两下就能完成，所以第一次选型要当作一次性承诺来认真对待。

选型没有银弹，只有取舍。就像餐厅老板最后会写下：“两口灶、三张桌，先用保温盒试菜；如果下个月翻台过百，就上整套中央后厨。”你的向量数据库选型，也可以有这样一张清晰的后厨规划图。

Lindex+Lnetwork+Lrerank≤Lbudget\displaystyle L_{\text{index}} + L_{\text{network}} + L_{\text{rerank}} \le L_{\text{budget}}
这就像顾客等菜的心理底线：翻索引、传数据、精排重排三段耗时之和，必须小于顾客愿意等待的秒数，否则再好吃的菜也留不住人。
  1. 索引查询耗时$L_{\text{index}}$ 是向量库在索引中定位候选集所花的时间，受索引类型与数据量影响。
    Lindex\displaystyle L_{\text{index}}
  2. 网络与精排$L_{\text{network}}$ 是跨节点传输的时间，$L_{\text{rerank}}$ 是拿到候选后做重排序精排的时间。
    Lnetwork+Lrerank\displaystyle L_{\text{network}} + L_{\text{rerank}}
  3. 预算约束三段耗时之和必须小于业务设定的延迟预算，选型和索引调优都以满足这条不等式为目标。
    Lindex+Lnetwork+Lrerank≤Lbudget\displaystyle L_{\text{index}} + L_{\text{network}} + L_{\text{rerank}} \le L_{\text{budget}}

AI 应用场景

智能客服知识库问答

阶段：检索增强生成（RAG 在线检索）

解决的问题：传统关键词搜索搜不到同义表达，用户问“怎么退款”，文档里写的是“退货流程”，词面不匹配就查不到。用 Milvus 把客服文档向量化，按语义召回同义说法，几周内就能搭出扛得住大促并发的高可用知识库。

具体案例：某电商公司把 2000 万条 FAQ 和售后政策文档切成 50 万段灌入 Milvus，业务高峰期 500 QPS 下 P99 延迟 80ms，先召回 Top5 再交给大模型生成回答，人工客服转接率下降四成。这就是“中央后厨”接住了年节客流。

个人本地知识助手

阶段：Embedding 入库与本地检索

解决的问题：个人笔记、PDF、网页收藏混杂，普通文件搜索只能按文件名匹配。用 Chroma 就像带一个保温饭盒出门，数据全在本地，不泄露隐私。

具体案例：一位数据科学家把 3000 篇论文笔记向量化存入本地 Chroma，每天早上让 AI 按研究主题召回相关内容生成综述，全程离线运行。数据量小、追求迭代速度的场景，正是 Chroma 的主场。

电商相似图片检索

阶段：向量化与离线索引

解决的问题：电商平台商品图去重，人工审核几千张图效率低。用 ResNet 把图片抽成 512 维特征向量，再交给 Faiss 建索引，就是“买一套好刀自己切配”。单机内存 2GB 左右就能扛住百万级图库，检索延迟在毫秒级。

具体案例：某服装电商对 100 万张商品图离线抽取向量存入 Faiss 索引，线上自建 2 个副本服务，收到查询图后转成向量、查索引、返回相似图，每日去重拦截盗图数千次。

Python 演示

python71 行
import numpy as np  class SimpleVectorStore:    """Chroma style: embedded store, ready to use"""     def __init__(self, dim=8):        self.dim = dim        self._vecs = []        self._ids = []        self._metas = []     def add(self, doc_id, vector, meta):        self._ids.append(doc_id)        self._vecs.append(np.array(vector, dtype=np.float32))        self._metas.append(meta)     def search(self, query_vec, k=3, meta_filter=None):        """cosine similarity + metadata filter"""        q = np.array(query_vec, dtype=np.float32)        q = q / (np.linalg.norm(q) + 1e-9)        results = []        for i in range(len(self._vecs)):            if meta_filter and not meta_filter(self._metas[i]):                continue            v = self._vecs[i] / (np.linalg.norm(self._vecs[i]) + 1e-9)            score = float(np.dot(q, v))            results.append((score, self._ids[i], self._metas[i]))        results.sort(key=lambda x: -x[0])        return results[:k]  def flat_matrix_search(query_vec, vectors, k=3):    """Faiss style: batch matrix dot product"""    q = np.array(query_vec, dtype=np.float32)    q = q / (np.linalg.norm(q) + 1e-9)    norms = np.linalg.norm(vectors, axis=1, keepdims=True)    matrix = vectors / (norms + 1e-9)    scores = matrix @ q    top = np.argsort(-scores)[:k]    return [(float(scores[i]), int(i)) for i in top]  def main():    rng = np.random.default_rng(42)    store = SimpleVectorStore()    docs = [        ("d1", "红烧肉做法", "家常"),        ("d2", "水煮鱼配方", "川菜"),        ("d3", "提拉米苏教程", "甜品"),        ("d4", "梅菜扣肉做法", "家常"),        ("d5", "番茄意面做法", "家常"),    ]    for doc_id, title, cuisine in docs:        store.add(doc_id, rng.normal(size=8), {"cuisine": cuisine})     query = rng.normal(size=8)    hits = store.search(query, k=2, meta_filter=lambda m: m["cuisine"] == "家常")    print("Chroma style (filter + cosine) hits:")    for score, doc_id, meta in hits:        print(" ", doc_id, "score", round(score, 4))     vecs = np.array(store._vecs, dtype=np.float32)    fast = flat_matrix_search(query, vecs, k=2)    print("Faiss style (batch matrix) hits:")    for score, idx in fast:        print(" ", store._ids[idx], "score", round(score, 4))  if __name__ == "__main__":    main()
目的：用 numpy 分别模拟 Chroma 式（逐条过滤+余弦相似度）和 Faiss 式（矩阵批量点积）的向量检索，演示两类库在实现层面的核心差异。
  1. store = SimpleVectorStore()创建一个“Chroma 风格”的小型向量仓库，开箱即用。
  2. store.add(doc_id, rng.normal(size=8), {"cuisine": cuisine})把文档 ID、向量和元数据标签三件套入库存。
  3. store.search(query, k=2, meta_filter=lambda m: m["cuisine"] == "家常")检索前先按“菜系”过滤，再算余弦相似度。
  4. q = q / (np.linalg.norm(q) + 1e-9)查询向量归一化，长度变 1，只保留方向信息，加 1e-9 防止除零。
  5. scores = matrix @ q一次矩阵乘法算出查询向量与全部向量的点积，这是 Faiss 批量加速的数学基础。
  6. np.argsort(-scores)[:k]按相似度从大到小排序，取前 k 个作为最近邻结果。

常见误区

误区我以为把文档丢给向量数据库，它就能自动分词、自动索引，像 Elasticsearch 一样输入一句话就出结果，根本不用管什么向量。

正解向量数据库只认向量，不认文字。必须先有一个 Embedding 模型把文本变成数值向量，检索时还要把用户提问用同一个模型编码成查询向量，再比相似度。这就像储藏室只认“酱料编号”不认“菜名”，你进门得先把菜谱翻译成编号卡片，翻译器就是那个 Embedding 模型。

为何常见：产品宣传常把“向量检索”和“语义搜索”混在一起讲，初学者容易忽略中间那层不可见的 Embedding 编码环节。

误区大家都说 HNSW 快，那我不管数据多少，一律上 HNSW，肯定又快又准，何必用笨办法暴力扫描。

正解索引本质是精度和速度的交换。HNSW 内存开销大、建索引慢，数据只有几千条时，Flat 暴力扫描反而更简单可靠，还省内存。正确的做法是拿自己的数据和查询分布做基准测试，而不是跟风选最热门的索引。

为何常见：技术文章总是放大新索引的优点，很少讲适用边界，导致“手里有锤子，看什么都像钉子”。

误区反正都是向量检索，趁还没上线，把 Chroma 换成 Milvus 不就是改一行连接字符串的事吗？接口应该差不多吧。

正解不同产品的数据模型、索引配置、过滤语法、持久化机制都不同。迁移涉及重新灌数据、重新调索引参数、改写查询代码，甚至要换 Embedding 模型重新编码全库，成本远比想象高。选型要当作一次承诺来做，而不是临时决定。

为何常见：开源项目都宣称支持标准接口，让人误以为底层同构、随时可换，实际上“兼容”和“可无缝迁移”是两回事。

误区开源的 Faiss、Milvus 都不要钱，专有云每个月账单那么贵，肯定自己搭最省钱。

正解自建要算上服务器、带宽、备份、安全补丁和运维人力。一个能 7×24 小时值班的工程师，年成本轻松超过云账单。对十几人小团队或非核心业务，托管方案的隐性成本往往更低。判断标准是那张四合一成本单，而不是“是否付费”。

为何常见：人们只看见“免费”标签，忽视隐性运维成本，忘了服务器宕机那晚工程师的加班费没人写进账单。

面试题

Q1. 向量数据库中存储的核心对象是什么？

单选题 · easy

  • A.原始文本文件
  • B.特征向量编码← 正确答案
  • C.关系数据库表
  • D.人工标注标签

答案：B。向量数据库以 embedding 向量为基本存储单元，文本必须先用模型编码成向量才能入库。A 是语料而非存储对象，C 是关系数据库的概念，D 只是可选的附加标注。

Q2. RAG 检索时，用户提问是如何被处理的？

单选题 · easy

  • A.分词后直接查字典
  • B.用关键词规则匹配
  • C.编成查询向量比对← 正确答案
  • D.随机抽取一段文档

答案：C。RAG 管线把提问文本交给与文档同一个 Embedding 模型，得到查询向量，再到向量库中做相似度检索。类比：点单后帮厨按“口味编号”去找酱料，而不是翻菜名目录。

Q3. Faiss 最准确的定位是什么？

单选题 · mid

  • A.全托管云数据库
  • B.开源向量算法库← 正确答案
  • C.分布式关系存储
  • D.图计算框架系统

答案：B。Faiss 是 Meta 开源的向量检索算法库，不负责持久化和网络服务，需要自己封装。它像一套专业刀具而不是完整后厨，A 是托管服务的定位，C/D 与向量检索无关。

Q4. 下面哪个属于全托管 SaaS 向量数据库？

单选题 · mid

  • A.Faiss 开源算法库
  • B.Chroma 轻量级库
  • C.Milvus 分布式库
  • D.Pinecone 托管服务← 正确答案

答案：D。Pinecone 是典型的 Serverless 托管产品，免部署、按量付费。Faiss、Chroma、Milvus 都需要自己管理运行环境，属于自建阵营。

Q5. 1000 万条 768 维 float32 向量直接暴力检索需要多少内存？

单选题 · hard

  • A.约 768 MB
  • B.约 3.07 GB
  • C.约 30.7 GB← 正确答案
  • D.约 307 GB

答案：C。1000 万 × 768 × 4 字节 ≈ 3.07 × 10^10 字节 ≈ 30.7GB。这是选型前必算的“内存账”：超过单机承受就要考虑 PQ 压缩、分片或分布式方案。

Q6. 下列哪项最能描述 HNSW 索引的工作方式？

单选题 · mid

  • A.逐条遍历全部向量
  • B.按哈希值均匀分桶
  • C.多层图结构导航近邻← 正确答案
  • D.用 B+ 树组织主键

答案：C。HNSW 是分层可导航小世界图，查询从顶层开始逐层向下，沿边逼近目标点。A 是 Flat 暴力扫描，B 是 LSH 的思路，D 是关系数据库的索引组织方式。

Q7. 关于 Recall@k 的正确理解是？

单选题 · hard

  • A.与检索阈值无关的常数
  • B.相关文档中被召回的比例← 正确答案
  • C.返回结果与查询夹角
  • D.索引构建所需的内存

答案：B。Recall@k = 被召回的真正相关文档数 / 全部相关文档数，衡量检索对相关内容的覆盖程度，受 k 和索引质量影响。C 是相似度概念，D 是内存概念，A 说它是常数显然是错的。

Q8. 下列哪些场景更适合选择 Milvus？

多选题 · mid

  • A.亿级向量业务库← 正确答案
  • B.需要持久化与多副本← 正确答案
  • C.仅少量本地实验数据
  • D.生产环境高并发查询← 正确答案

答案：ABD。Milvus 是分布式向量数据库，适合大规模、持久化、多副本、高并发的生产场景。几十条数据用 Chroma 更轻，不必上重基建，所以 C 不选。

Q9. Chroma 的主要优势有哪些？

多选题 · mid

  • A.零配置本地启动← 正确答案
  • B.支持亿级向量分布式
  • C.开发接口方便简洁← 正确答案
  • D.内置元数据过滤← 正确答案

答案：ACD。Chroma 定位轻量嵌入式库，本地秒开、API 友好、支持元数据过滤，适合原型验证。它不支持分布式扩展到亿级，B 是明显的干扰项，选它就会踩“大材小用或小材大用”的坑。

Q10. 做向量库选型时应该重点评估哪些维度？

多选题 · extreme

  • A.数据规模与增长预期← 正确答案
  • B.端到端延迟预算← 正确答案
  • C.团队运维与迁移成本← 正确答案
  • D.各家品牌宣传热度

答案：ABC。选型看数据规模、延迟预算、全成本（含运维）、生态成熟度和数据合规，这是“老板拍板清单”。D 是营销噪音，不应进入技术决策清单——选工具不是选偶像。