想象你是一家快速成长公司的物流主管——仓库里堆着上千万件“语义货物”（文本、图片、音频转化成的向量）。顾客不再报出精确货号，而是描述“我想要一个红色的、适合露营的保温杯”，你要在一秒内找到最像的那几件。普通数据库像只认条形码的账本，没法按“意思”找货；于是你需要在 Milvus、Pinecone、Weaviate、Qdrant、pgvector 这些“物流仓库”里挑一家。它们的货架系统（索引算法）不同、计费方式（部署与成本）不同、擅长领域（生态）也不同。本文就像一份选厂考察报告：从向量库的底层原理、五大引擎横评、索引算法、性能指标到选型决策框架逐一拆解，最后落到 RAG、推荐、搜索等真实场景，帮你学会为业务挑选最合适的“仓库”。

岗位关联

向量库选型是 RAG、推荐、搜索等上层应用的地基工程，选错返工成本高，选对则性价比与扩展性兼得。掌握这套选型方法论，是 AI 应用架构师绕不开的核心技能。

目录
  1. 可视化演示
  2. 向量库全景认知：语义货物的专属仓库
  3. 主流引擎对比：五家物流商的货架横评
  4. 索引算法内幕：仓库里的智能货架系统
  5. 关键性能指标：仓库体检的四张报表
  6. 选型决策框架：四问锁定合适仓库
  7. 场景适配指南：不同业务匹配不同运力
  8. AI 应用场景
  9. Python 演示
  10. 常见误区
  11. 面试题

可视化演示

动态演示向量数据库选型与场景适配的核心机制，通过输入/处理/存储/输出四种模式展示关键概念与交互流程。

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

向量数据库选型与场景适配：主流向量 主流向量数据库的架构与索引算法 Milvus 与 Pineco 核心机制可视化 向量数据库选型与场景适配整体架构与关键组件

向量库全景认知：语义货物的专属仓库

想象你是一家仓储公司的老板，货架上堆着上亿件“语义货物”——每一件都不是普通纸箱，而是一串写满数字的标签。这些标签来自 Embedding 模型：把一段文本、一张图片、一首歌各自压缩成一个 128 维、768 维甚至 1536 维的浮点坐标。顾客来买货时说不出货号，只会说“我要和这条推文的感觉差不多的商品”。此时，货箱上的数字坐标就是唯一线索。

普通数据库像按条形码找货的账房：物品必须被一个主键精确命中，“感觉差不多”这句话会让它彻底宕机。而向量数据库这间“语义仓库”天生为模糊检索而生——它知道如何把每一个浮点向量存进内存、建好索引，并在收到查询向量后，用距离算法把库里的向量按“相近程度”排个序，返回最像的 TopK。这套能力，业界称为近似最近邻搜索（ANN）。

判断两个向量“像不像”最常用的尺子是余弦相似度。它忽略向量长度，只看方向的夹角是否接近，非常适合文本语义场景——“猫”和“抓老鼠”在语义空间里方向趋近，即使它们的模长完全不同。另一把尺子是欧氏距离，适合图像特征等对“绝对距离”敏感的场景；内积则常用于推荐系统中用户向量与物品向量的打分。

所以选仓库前先问自己：我要放什么货（数据形态），用什么尺子量（距离函数），用户能等多久（延迟预算）。这三个问题，直接决定了你最后在货架系统（索引）上的选择。

cos⁡(θ)=∑i=1DAi×Bi∑i=1DAi2×∑i=1DBi2\displaystyle \cos(\theta) = \frac{\sum_{i=1}^{D} A_i \times B_i}{\sqrt{\sum_{i=1}^{D} A_i^2} \times \sqrt{\sum_{i=1}^{D} B_i^2}}
余弦相似度把两个向量的方向一致性换算成 −1 到 1 之间的分数，越接近 1 表示越相似。
  1. 分子（向量内积）把两个向量的每一维分别相乘再累加，值越大说明同方向分量越多。
    分子=∑i=1DAi×Bi\displaystyle \text{分子} = \sum_{i=1}^{D} A_i \times B_i
  2. 分母（长度归一化）分别算出两个向量的 L2 范数并相乘，消除“长度不同导致分数虚高”的影响。
    分母=∑i=1DAi2×∑i=1DBi2\displaystyle \text{分母} = \sqrt{\sum_{i=1}^{D} A_i^2} \times \sqrt{\sum_{i=1}^{D} B_i^2}
  3. 整体（夹角余弦）结果落在 $[-1, 1]$，接近 1 意味着语义方向几乎一致，是向量库最常用的排序分数。
    cos⁡(θ)∈[−1,1]\displaystyle \cos(\theta) \in [-1, 1]

主流引擎对比：五家物流商的货架横评

如果把向量库比作物流公司，你会看到五种画风完全不同的“仓库”。Milvus 是自建全功能仓，从 LF AI 基金会孵化而来，目标是撑起十亿级向量；Pinecone 是云上开箱即用的托管仓，你只负责把货送进门，剩下全交给它；Weaviate 自带 AI 分拣助手，内置向量化 pipeline，文本图片进库前自动生成向量；Qdrant 是用 Rust 焊成的极速小仓，单机性能出色；pgvector 则是直接塞进 PostgreSQL 里的货架，让老库房秒变向量仓。

横评要抓住四个维度：管理形态（自建还是托管）、扩展能力（能不能水平分片）、索引与过滤（纯向量搜索还是支持标量过滤）、后端生态（是否兼容你已有的技术栈）。Milvus 胜在分布式架构与存储计算分离，适合超大规模；Pinecone 胜在零运维、按量付费；Weaviate 和 Qdrant 在中等规模下性能亮眼；pgvector 则让 Postgres 用户零迁移成本获得向量能力。

在对比之前，先用一个公式估算你的“货物体积”。以最常用的 OpenAI embedding 为例，每条文本变成一个 1536 维的 float32 向量，每维度占 4 字节。记住这个算式，你会发现 100 万条文档的原始向量就有约 6.1 GB，还没算索引和副本。

五家没有绝对王者，只看你的“仓库”是建在城市中心（自建 Milvus）还是租用云上专柜（Pinecone），是给老库房加装货架（pgvector）还是买一套智能分拣线（Weaviate/Qdrant）。先量货，再选仓。

存储量=N×D×4 bytes\displaystyle \text{存储量} = N \times D \times 4 \ \text{bytes}
原始向量存储量约等于向量条数 × 向量维度 × 4 字节，选型前先算清数据库要装下多少个“集装箱”。
  1. N（向量条数）你要存多少条“语义货物”，它直接决定仓库是货架还是库房。
    N=数据条数\displaystyle N = \text{数据条数}
  2. D（向量维度）每条货物由 D 个浮点数描述，例如文本常用 1536 维。
    D=向量维度\displaystyle D = \text{向量维度}
  3. 4（单精度字节）每个浮点数用 float32 存储固定占 4 字节，这是内存与磁盘成本的最小单位。
    4 bytes / 元素\displaystyle 4 \ \text{bytes / 元素}

索引算法内幕：仓库里的智能货架系统

走进任何一家向量仓库，你会看到三种货架系统。最朴素的是 FLAT：所有货物平铺在地面，找货时从第一箱翻到最后一箱，一定找得准，但速度极慢。第二种是 IVF：先把仓库划成几十个区域，每区立一块导航牌，查询时先看导航牌找到离你最近的几个区，再进去翻找。第三种是 HNSW：它更像城市里的“小世界”地铁网——从任意入口上车，沿着邻居关系逐段跳转，几跳之后就精准抵达目标所在的车站。

FLAT 是精确检索的基准线：复杂度 O(N)，数据量一大就扛不住。IVF 的思路是聚类：训练阶段用 K-means 把向量分成 nlist 个桶，插入时把向量放进最近的桶；查询时只搜离查询向量最近的 nprobe 个桶。nlist 越大，每桶越小，但桶数太多会导致“边界误判”风险上升；nprobe 越大，搜的桶越多，召回越稳但延迟越高。

IVF 的计算量可以用一个公式直观看出：它把全库扫描缩小成“先做一次 nlist 路导航，再在 nprobe 个分区内精查”。如果 nlist=1024、nprobe=8，你能把搜索范围缩小到千分之八，速度提升百倍以上。

HNSW 则更进一步：它构建多层图，上层是稀疏的“高速公路”，下层是稠密的精确连接，查询从顶层出发，每层快速滑到最接近目标的节点再深入下一层。代价是图结构常驻内存，构建时间也比 IVF 长。索引就是在仓库布局上花心思，让大部分查询不用翻遍全库——生意越大，货架设计越值钱。

TIVF≈O(Nnlist×nprobe)\displaystyle T_{\text{IVF}} \approx O\left(\frac{N}{n_{\text{list}}} \times n_{\text{probe}}\right)
IVF 的查询开销约等于每个分区平均向量数乘以探测分区数，nprobe 是关键调参旋钮。
  1. nlist（分区数）把仓库划分为多少个“进货区”，越多每个区越小，检索越精细。
    nlist=聚类数量\displaystyle n_{\text{list}} = \text{聚类数量}
  2. N / nlist（每区平均货量）总货物摊到每个区后，每个区大约有多少条向量。
    N/nlist=每个聚类平均向量数\displaystyle N / n_{\text{list}} = \text{每个聚类平均向量数}
  3. nprobe（探测数）查询时最多进去翻找几个区，它决定了召回率与延迟的平衡点。
    nprobe=探测的聚类数量\displaystyle n_{\text{probe}} = \text{探测的聚类数量}

关键性能指标：仓库体检的四张报表

选仓库不能只凭直觉，要看四个仪表盘：找得准不准（召回率）、出货快不快（延迟与 QPS）、占地大不大（内存占用）、烧钱多不多（成本）。召回率衡量的是“正确答案被找回的比例”。假设用暴力搜索算出真正的 10 个最近邻，召回率越高，说明 ANN 索引进来的名单和金牌名单重叠越多。

延迟看 P50 和 P99：P50 是普通订单的响应时间，P99 代表最差 1% 的体验，线上服务通常盯 P99。QPS（每秒查询数）则是吞吐层面的指标：单机 QPS = 1000 / 平均延迟（毫秒），但并发上来后，锁竞争和内存带宽会成为新的瓶颈。内存占用更直接——HNSW 索引往往需要常驻内存，用户今天省下的延迟，明天会加倍在服务器账单上还回来。

召回率用集合公式定义：分子是“真实近邻与检索结果的重叠数”，分母是 K。这个指标可以量化你为速度到底牺牲了多少准确性。

没有“最好”的仓库，只有指标之间的取舍。高召回但 P99 飙到 5 秒的仓库，对线上交互场景就是灾难；反之，追求极致速度把召回率压到 0.5 以下，业务方又会在搜索结果里骂娘。体检懂指标，选型不踩坑。

Recall@K=∣真实近邻集合∩检索结果集合∣K\displaystyle \text{Recall}@K = \frac{\left| \text{真实近邻集合} \cap \text{检索结果集合} \right|}{K}
Recall@K 表示真正的 K 个最近邻中，有百分之多少被检索算法成功找回，数值越高说明索引越接近暴力搜索。
  1. 真实近邻集合用暴力搜索穷举算出的“金牌名单”，是评估 ANN 的基准答案。
    真实近邻=Brute Force 的前 K 个结果\displaystyle \text{真实近邻} = \text{Brute Force 的前 } K \text{ 个结果}
  2. 检索结果集合实际线上索引返回的“候选名单”，可能比金牌名单少人。
    检索结果=ANN 返回的前 K 个结果\displaystyle \text{检索结果} = \text{ANN 返回的前 } K \text{ 个结果}
  3. 交集占比两份名单重叠越多，说明近似索引找得越准，逼近 1 表示几乎无损。
    ∣真实∩返回∣K\displaystyle \frac{\left| \text{真实} \cap \text{返回} \right|}{K}

选型决策框架：四问锁定合适仓库

现在到了拍板时刻。别急着看排行榜，先问四个问题。第一问：货多不多？百万级以下，pgvector 加个 HNSW 索引完全够用；百万到千万级，Qdrant 或 Weaviate 的单机性能就能扛；上亿级，必须考虑 Milvus 或云托管的分布式分片能力。第二问：急不急？交互式搜索要求毫秒级延迟，批处理任务可以容忍秒级，两者对索引和硬件的选择完全相反。

第三问：预算多少？自建 Milvus 需要买服务器、雇运维、搭监控；Pinecone 这类托管服务虽然单价高，但把人力成本外包了出去。第四问：生态是否打通？如果公司已经在重度使用 PostgreSQL，pgvector 是零学习成本；如果团队熟悉 Kubernetes 和云原生，Milvus Operator 能无缝接入现有运维体系。

把四问数字化，就是一张 TCO（总拥有成本）公式。自建方案要同时算机器费、存储费和运维工时；托管方案则把运维工时折进 API 单价里。

四问的答案交汇处，就是你的那间仓库。所有纠结最后都会落到一行代码和一张月度账单上。

TCO=C机器×n+C存储×S+C运维×h\displaystyle \text{TCO} = C_{\text{机器}} \times n + C_{\text{存储}} \times S + C_{\text{运维}} \times h
总拥有成本 = 单台机器月租 × 机器数 + 每 GB 存储月费 × 数据量 + 运维时薪 × 工时，自建与托管的差距最后都落在这一张表上。
  1. 机器成本自建需要采购或租赁算力节点，数量 n 由分片和副本数决定。
    C机器×n=算力成本\displaystyle C_{\text{机器}} \times n = \text{算力成本}
  2. 存储成本向量数据、索引、WAL 日志都要占用磁盘，S 是总存储量（GB）。
    C存储×S=存储费用\displaystyle C_{\text{存储}} \times S = \text{存储费用}
  3. 运维成本升级补丁、故障恢复、扩缩容消耗的工程师工时，托管方案中这一项趋近于零。
    C运维×h=运维成本\displaystyle C_{\text{运维}} \times h = \text{运维成本}

场景适配指南：不同业务匹配不同运力

选仓库的最终目的是服务业务。RAG 知识库是当前最火的场景：用户提问先转成向量，在知识库里检索最相关的段落，再拼进 Prompt 交给大模型回答。推荐系统则是另一个典型：每个用户向量去库中召回最相似的物品向量，再进精排模型打分。语义搜索与混合检索则考验引擎在延迟、过滤、多路召回上的综合能力。

RAG 项目建议从 pgvector 起步：数据量小、团队熟悉 Postgres，一条 SQL 就能完成向量检索，最快验证业务价值；当数据涨到几百万段、并发上来后，再平滑迁移到 Milvus 或 Qdrant。推荐系统更看重吞吐与过滤：Qdrant 以 Rust 实现、支持 payload 过滤，能在召回时直接排除已购商品；Milvus 则在十亿级场景下提供成熟的分布式方案。语义搜索对延迟极其敏感，HNSW 是默认选择，配合 GPU 或高主频 CPU 能把 P99 压到几十毫秒。

混合检索正在成为搜索系统的标配：BM25 抓精确关键词，向量抓语义近义，两路分数加权融合。权重 α 是超参数，RAG 场景一般偏重语义，取 0.6~0.7；代码搜索等强专业词汇场景，则要调高关键词权重。

仓库选定不是终点。上线之后，新一轮调参循环才刚刚开始：HNSW 的 ef 值、IVF 的 nprobe、分片数、缓存命中率、监控告警——每个数字都在提醒你，选型不是一次性的买卖，而是持续运营的长期工程。

score=α×svector+(1−α)×skeyword\displaystyle \text{score} = \alpha \times s_{\text{vector}} + (1 - \alpha) \times s_{\text{keyword}}
混合检索最终得分是向量相似度与关键词命中的加权和，α 越大越依赖语义理解，越小越依赖字面匹配。
  1. 向量分查询向量与文档向量的余弦相似度，负责理解“意思相近”。
    svector=cos⁡(query,doc)\displaystyle s_{\text{vector}} = \cos(\text{query}, \text{doc})
  2. 关键词分BM25 等词法模型打分，负责锁定“字面一致”的强信号。
    skeyword=BM25 Score\displaystyle s_{\text{keyword}} = \text{BM25 Score}
  3. 权重 α两路信号的信任配比，在语义理解和精确匹配之间取平衡。
    α∈[0,1]\displaystyle \alpha \in [0, 1]

AI 应用场景

智能客服 RAG 知识库选型

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

解决的问题：传统客服系统用关键词搜索 FAQ，用户说“我的订单怎么还没到”时命中率极低；改用向量检索后，系统能理解意图并召回语义一致的答案片段，大模型再组织成自然语言回答。

具体案例：某电商客服系统有 50 万段 FAQ，最初用 pgvector 在 PostgreSQL 中做向量检索，零迁移成本快速上线；半年后数据涨到 800 万段，并发 QPS 翻了十倍，团队将数据迁移到 Milvus 集群并启用 HNSW 索引，P99 从 120ms 降到 35ms，召回率稳定在 98%。

电商推荐系统向量召回

阶段：召回 / 排序（粗排前的候选生成）

解决的问题：传统协同过滤面对冷启动商品无能为力，词匹配又无法理解“类似 style”这类语义；用向量召回后，用户实时行为向量与百万商品向量做 TopK 检索，召回覆盖面显著扩大。

具体案例：某跨境电商把 200 万商品图经 CLIP 模型转成向量存入 Qdrant，用户点击序列实时产出行为向量，每次请求召回 500 个候选商品再送精排模型，单机 QPS 达到 3000，p99 延迟 48ms，CTR 提升 23%。

多语言工单语义检索引擎

阶段：检索引擎（混合检索）

解决的问题：跨国企业工单经常中英混杂、缩写频出，BM25 字面匹配经常“查无此单”；加入向量语义检索后，用户用任何语言描述问题都能命中相关历史工单。

具体案例：某 SaaS 公司用 Elasticsearch 存 BM25 索引，同时用 Qdrant 存工单向量，双路召回后按 α=0.3 加权融合（偏关键词），搜索满意度提升 40%，“解决时长”缩短 15%。

Python 演示

python78 行
import mathimport randomimport time  def l2(a, b):    return math.sqrt(sum((x - y) ** 2 for x, y in zip(a, b)))  def build_dataset(n=1000, dim=16, seed=42):    random.seed(seed)    return [[random.gauss(0, 1) for _ in range(dim)] for _ in range(n)]  class BruteForce:    def __init__(self, vectors):        self.vectors = vectors     def search(self, q, k=10):        scored = sorted(enumerate(self.vectors), key=lambda item: l2(item[1], q))        return [idx for idx, _ in scored[:k]]  class SimpleIVF:    def __init__(self, vectors, nlist=8, nprobe=2):        self.nlist = nlist        self.nprobe = nprobe        self.centroids = random.sample(vectors, min(nlist, len(vectors)))        self.lists = [[] for _ in range(nlist)]        for idx, vec in enumerate(vectors):            cid = self._assign(vec)            self.lists[cid].append((idx, vec))     def _assign(self, vec):        return min(range(self.nlist), key=lambda j: l2(vec, self.centroids[j]))     def search(self, q, k=10):        order = sorted(range(self.nlist), key=lambda j: l2(q, self.centroids[j]))        cands = []        for cid in order[:self.nprobe]:            cands.extend(self.lists[cid])        cands.sort(key=lambda item: l2(item[1], q))        return [idx for idx, _ in cands[:k]]  def recall_at_k(gold, pred, k=10):    return len(set(gold[:k]) & set(pred[:k])) / k  def main():    data = build_dataset(n=1000, dim=16, seed=42)    queries = build_dataset(n=50, dim=16, seed=7)    k = 10    bf = BruteForce(data)    ivf = SimpleIVF(data, nlist=8, nprobe=2)     golds = [bf.search(qq, k) for qq in queries]    preds = [ivf.search(qq, k) for qq in queries]    avg_recall = sum(recall_at_k(g, p, k) for g, p in zip(golds, preds)) / len(queries)     t0 = time.perf_counter()    for qq in queries:        bf.search(qq, k)    bf_time = time.perf_counter() - t0     t0 = time.perf_counter()    for qq in queries:        ivf.search(qq, k)    ivf_time = time.perf_counter() - t0     print(f"BruteForce 耗时 = {bf_time:.4f}s")    print(f"SimpleIVF  耗时 = {ivf_time:.4f}s")    print(f"IVF 平均召回率 = {avg_recall * 100:.1f}%")    print(f"加速比 = {bf_time / ivf_time:.2f}x")  if __name__ == "__main__":    main()
目的：用纯 Python 实现暴力搜索和简化版 IVF 索引，对比百万级以下数据的召回率与查询加速比。
  1. class SimpleIVF:用约 30 行代码实现一个可运行的 IVF 分区索引。
  2. self.centroids = random.sample(...)随机抽 8 个中心点代表“货区导航牌”，实际工程会用 K-means 迭代优化。
  3. self.lists[cid].append((idx, vec))每条向量按最近中心进入对应“货区”，构建倒排式桶结构。
  4. order[:self.nprobe]查询时只看最近的 2 个货区，而不是全部 8 个，这正是加速的关键。
  5. recall_at_k(gold, pred, k)用集合交集计算“金牌名单”和“实际名单”的重叠比例。

常见误区

误区听说向量数据库很火，以后所有数据都该换它来存，直接替换 PostgreSQL。

正解向量数据库擅长高维相似度检索，但事务、复杂 JOIN、报表统计仍是传统数据库的领地。数据量低于十万级时，pgvector 甚至全表暴力扫描都绰绰有余。杀鸡不要用宰牛刀：选型第一步永远是估算规模，而不是追逐时髦。绝大多数业务数据仍然留在传统数据库里，只有 Embedding 这类“语义查找”才值得进向量库。

为何常见：因为行业讨论铺天盖地，容易被“新东西一定更好”的直觉带偏，忽略了业务实际需求。

误区衡量索引好不好，就要召回率无限接近 100%，调参时把 nprobe 或 ef 往死里拉满。

正解召回率 100% 等于退化回暴力搜索，索引也就失去了意义。生产环境通常目标在 0.95~0.99 之间，把余量换成交互延迟和硬件成本。调高 nprobe/ef 的收益呈边际递减，而代价线性上涨；与其追求完美召回，不如把预算留给容量规划和缓存优化。

为何常见：测试集上追求指标完美是工程师本能，却忘了线上 P99 延迟也是需要背书的 SLO。

误区Milvus 是开源的，所以自建部署成本为零，比 Pinecone 这种付费服务划算得多。

正解开源免的是软件授权费，不是运维费。自建你要自己买服务器、搭监控、做备份、扛大促扩容，半夜还要响应故障告警。一个中级运维工程师的月薪足够买下 Pinecone 几个月的用量。小团队、短周期项目用托管服务往往 TCO 更低；只有当规模大到月账单显著超过人力成本时，自建才真正划算。

为何常见：只对比了 license 价格表，没有把人力、机房、故障的时间成本算进总账。

误区看 benchmark 都是 HNSW 拿第一，所以闭眼选 HNSW 就对了。

正解HNSW 速度虽快，但图结构通常常驻内存，内存占用可能是 IVFFlat 的数倍；批量加载数据时构建时间也长，且删除用标记删除、索引空间不会立刻回收。如果你的数据是流式高频写入、存量又特别大，IVF 系或磁盘友好的方案可能更合适；如果数据量小到几千条，FLAT 暴力搜索根本不吃亏。索引选择永远是场景权衡，不是单项冠军。

为何常见：公开 benchmark 只报速度和召回，不报内存和构建成本，容易让人只看一面。

面试题

Q1. 向量数据库最核心的检索能力是什么？

单选题 · easy

  • A.存 JSON 文档
  • B.执行 SQL 聚合
  • C.向量相似度搜索← 正确答案
  • D.清理磁盘空间

答案：C。向量数据库围绕“按语义相近程度排序”设计，核心能力是高维向量的相似度检索。JSON 存储是文档数据库（如 MongoDB）的强项，SQL 聚合属于关系型数据库，磁盘清理与检索无关，因此选 C。

Q2. 想把现有 PostgreSQL 升级成轻量向量库，首选方案是？

单选题 · easy

  • A.Milvus
  • B.Pinecone
  • C.pgvector← 正确答案
  • D.Weaviate

答案：C。pgvector 是 PostgreSQL 的扩展插件，在已有库上加一个货架即可获得向量检索能力，零迁移成本。Milvus 和 Pinecone 是独立引擎，Weaviate 是独立向量数据库，都不是“在 Postgres 内部加扩展”的方案，因此选 C。

Q3. HNSW 索引的平均查询复杂度最接近以下哪一项？

单选题 · mid

  • A.O(log N)← 正确答案
  • B.O(N)
  • C.O(N²)
  • D.O(1)

答案：A。HNSW 构建多层小世界图，查询时从顶层逐层下钻，平均跳转次数与层数相关，接近对数复杂度 O(log N)。O(N) 是暴力扫描 FLAT 的复杂度，O(N²) 是训练聚类时的计算量，O(1) 是哈希表的理想复杂度，因此选 A。

Q4. IVF 索引中，将 nprobe 从 2 调到 8 之后，通常会发生什么？

单选题 · mid

  • A.召回率更高延迟也更大← 正确答案
  • B.召回率更低延迟更小
  • C.召回率和延迟都下降
  • D.召回率和延迟都上升

答案：A。nprobe 是查询时探测的分区数，探测越多，覆盖的真实近邻概率越大，召回率自然更高；但需要比较的候选向量也增多，延迟随之上升。B 和 D 描述的搭配方向错误，C 中两者同时下降不可能，因此选 A。

Q5. 移动端离线 RAG 应用，最适合采用哪类向量库方案？

单选题 · mid

  • A.自建 Milvus 集群
  • B.嵌入式 sqlite-vec← 正确答案
  • C.全托管 Pinecone
  • D.远程 Qdrant 服务

答案：B。移动端离线场景要求库随 App 打包、不依赖网络，嵌入式向量库（如 sqlite-vec、Chroma 本地模式）是标准答案。Milvus 和 Qdrant 需要独立服务端，Pinecone 是云端 API，三者都依赖网络或服务器，不适合离线环境，因此选 B。

Q6. 进行向量数据库选型时，以下哪些是必须考虑的核心因素？

多选题 · hard

  • A.数据规模与分片← 正确答案
  • B.延迟与吞吐要求← 正确答案
  • C.成本与运维人力← 正确答案
  • D.团队薪资水平

答案：ABC。数据规模决定是否需要分布式，延迟与吞吐决定索引和硬件选型，成本与运维人力决定自建还是托管——这三项构成选型决策框架。团队薪资是内部管理问题，不直接影响数据库技术选型，因此 D 不选。

Q7. 某系统报告 Recall@10 = 0.6，正确的理解是？

单选题 · mid

  • A.检索结果中 60% 与查询相关
  • B.真正的 10 个最近邻找回了 6 个← 正确答案
  • C.系统准确率恰好为 60%
  • D.查询平均耗时 6 毫秒

答案：B。Recall@K 的定义是“真实 K 近邻与检索结果的重叠数 ÷ K”，Recall@10 = 0.6 表示真正的 10 个最近邻里有 6 个被成功找回。它衡量的是召回而非精确率，也与延迟无关，因此选 B。

Q8. 下列属于全托管向量数据库服务的是哪些？

多选题 · easy

  • A.Pinecone 全托管← 正确答案
  • B.pgvector 自托管
  • C.本地自建 Milvus
  • D.Azure AI Search← 正确答案

答案：AD。Pinecone 是典型的 SaaS 全托管向量服务，Azure AI Search 提供云上托管的向量检索能力。pgvector 是 PostgreSQL 扩展，需要自己运维数据库；自建 Milvus 更是完全自托管，因此 B 和 C 不选。

Q9. 混合检索中，将向量分数与关键词分数融合的计算公式是？

单选题 · hard

  • A.score = max（两个分数）
  • B.α·向量分 + (1−α)·关键词分← 正确答案
  • C.向量分 × 关键词分
  • D.两个分数随机抽一个

答案：B。加权求和是业界最常用的融合方式：α 控制语义与字面的信任配比，两路分数互补。取最大值忽略了另一路信号，乘法会让任一低分直接拖垮结果，随机抽取完全不可控，因此选 B。

Q10. 关于 HNSW 索引，以下说法正确的有哪些？

多选题 · extreme

  • A.平均查询 O(log N)← 正确答案
  • B.ef 越大召回率越高← 正确答案
  • C.图结构常驻内存← 正确答案
  • D.只能做精确搜索

答案：ABC。HNSW 多层图查询平均复杂度接近 O(log N)；查询参数 ef 控制搜索宽度，越大候选越多、召回越高；图结构必须常驻内存保证随机访问性能。HNSW 是近似最近邻（ANN）算法，牺牲部分精度换取速度，并非精确搜索，因此 D 错误。