想象你经营一家大型图书电商，每天有上千万本书进出仓库。为了把每一本订单书快速准确地拣出来，你需要一套聪明的仓库管理系统。面前有三家供应商：A 公司提供全托管云仓，你只管下单，剩下的运维、扩容、防潮防火全都交给它，省心但按件收费；B 公司卖给你一套自带扫码、自动分拣、库存报表的智能仓配设备，功能齐全，但要自己学着用；C 公司则给你一套超高效率的自动化分拣线，开源开放、性能强悍，却需要你的团队亲手搭建和调优。三套系统都能管书，但你的订单规模、预算和团队能力不同，答案自然不同。本文就用这个“挑仓库”的视角，把三套存储系统的差异摊开：谁更快、谁能扩展、谁完全开放、谁更容易部署、谁的取货方式更丰富，最后给你一张决策地图，让选型不再靠感觉。

岗位关联

掌握这套选型逻辑，能帮你把模型推理链路真正落到生产环境，是 RAG 工程师与架构师最实用的差异化技能之一。

目录
  1. 可视化演示
  2. 性能基准
  3. 扩展能力
  4. 开源协议
  5. 部署方式
  6. 混合检索
  7. 生态工具
  8. 选型决策
  9. AI 应用场景
  10. Python 演示
  11. 常见误区
  12. 面试题

可视化演示

动态演示Pinecone、Weavi的核心机制，通过总览/传输/转换/输出四种模式展示关键概念与交互流程。

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

Pinecone、Weavi：Pine Pinecone/Weavia 三款数据库的性能基准与水平扩展 核心机制可视化 Pinecone、Weavi整体架构与关键组件

性能基准

先看“发货速度”。同样是拣一单货，有的仓库十分钟出库，有的要半小时，顾客体验完全不同。在向量数据库里，查询延迟就是拣货时间，QPS 就是同时能接多少订单。仓库主管最关心的永远是：高峰期，系统会不会掉链子。

三家供应商的“速度”风格不同：Pinecone 像全托管云仓，基础设施成熟，P99 延迟稳定，适合流量忽高忽低的线上业务；Qdrant 像自建的高速分拣线，单节点延迟极低，配合 HNSW 索引可以在高并发下保持超高吞吐；Weaviate 则像功能齐全的智能仓配设备，速度处于中游，但胜在开箱即用、功能全面。

只看快不够，还要看“有没有拣漏”。如果一个查询真正相关的书有 100 本，系统只返回了 90 本，就会漏掉顾客真正想要的。这个指标叫召回率，公式如下：

其中 R 是与查询真正相关的向量集合，S_k 是系统返回的前 k 个结果。

回到仓库的比喻：性能评测就像同时验收“拣货速度”和“拣错率”。有的仓库快但容易漏件，有的慢但从不漏单，所以成熟团队会把 p99 延迟、QPS 和召回率放在同一张压测报表里看，而不是只看某一项数字。

Recall@k=∣R∩Sk∣∣R∣\displaystyle \text{Recall@k} = \frac{|R \cap S_k|}{|R|}
召回率衡量“该找到的有没有被找到”，是比延迟更重要的质量指标。
  1. 定义相关集合把 R 定义为所有与当前查询真正相关的向量集合，相当于仓库里所有符合订单条件的书。
    R={v1,v2,…,vm}R = \{v_1, v_2, \dots, v_m\}
  2. 定义返回集合把 S_k 定义为系统按照相似度从高到低返回的前 k 条结果，相当于拣货员优先拿出的 k 本书。
    Sk={s1,s2,…,sk}S_k = \{s_1, s_2, \dots, s_k\}
  3. 计算交集大小分子统计 R 与 S_k 中重复的元素个数，也就是系统从相关集合里真正捞出来多少本。
    ∣R∩Sk∣|R \cap S_k|
  4. 计算比例用命中的相关数量除以总相关数量，得到 0 到 1 之间的召回率，越接近 1 说明漏检越少。
    ∣R∩Sk∣∣R∣\frac{|R \cap S_k|}{|R|}

扩展能力

仓库总有装满的一天。当图书数量从十万涨到一亿，货架不够用时，就要考虑扩建。有的供应商能按需租临时仓，比如 Pinecone 的云托管会自动扩容；有的供应商要求你自己规划货架布局，比如 Qdrant 的分片和副本要预先设计；Weaviate 则介于两者之间，支持分片和集群，但多租户隔离需要更多规划。

水平扩展的核心是“加节点”。单台机器内存装不下全部向量时，数据要被切分成多个分片分散到不同节点，同时每个分片再复制几份作为副本，防止某台机器宕机导致整个仓库瘫痪。Pinecone 把这一切藏在云服务背后，你只看到容量数字在增长；Qdrant 和 Weaviate 则需要你理解分片键、副本因子这些底层概念。

扩展能力的上限可以用总容量公式理解：

其中 C_total 是集群总容量，N_nodes 是节点数量，C_node 是单个节点能承载的向量容量。这个公式说明：扩展就是“多雇几个仓库、每个仓库多放几种货”。

仓库比喻的妙处在于：托管云仓像“按需租赁”，你不用关心货架数量；自建仓库则要把未来半年的订单增长估算清楚，提前规划分片。选型时先问自己：团队能接受多大的运维复杂度？

Ctotal=Nnodes×Cnode\displaystyle C_{\text{total}} = N_{\text{nodes}} \times C_{\text{node}}
总容量由节点数和单节点容量共同决定，水平扩展的核心是把 N_nodes 做大。
  1. 确定单节点容量先看一台机器能装多少向量，相当于一个分仓库能放多少本书。
    CnodeC_{\text{node}}
  2. 确定节点数量再数整个集群有多少台机器，对应租了多少个分仓库。
    NnodesN_{\text{nodes}}
  3. 相乘得到总容量两个值相乘就是整个系统能容纳的向量总数。
    Nnodes×CnodeN_{\text{nodes}} \times C_{\text{node}}
  4. 映射到实际需求当数据量逼近总容量时，就必须增加节点或调整分片策略，否则查询会变慢甚至失败。
    Ctotal=Nnodes×CnodeC_{\text{total}} = N_{\text{nodes}} \times C_{\text{node}}

开源协议

选仓库还有一个维度：这块地是“买断”还是“租用”。开源协议决定你能不能看到仓库图纸、能不能自己改装、能不能不受厂商限制地无限扩建。Pinecone 是纯商业托管服务，源代码不公开，但换来的是“只管用，不用管”；Qdrant 采用 Apache 2.0 开源协议，代码完全开放，允许自由使用、修改和商用；Weaviate 也开源，但商业云版本提供更完整的企业级服务。

开源不等于免费，它更像是“买地自建”：土地不要钱，但建材、工人、维护都要投入。商用限制也需要关注，有些开源协议虽然开放源码，却限制了云厂商直接拿去卖服务。Apache 2.0 是比较宽松的协议，对自建和二次开发都很友好。

成本维度可以用总拥有成本来刻画：

TCO 代表总拥有成本，C_sub 是订阅费用，C_ops 是自建运维的人力成本，C_mig 是从其他系统迁移数据的成本。

回到仓库的比喻：租云仓时你付高额月租但不用雇水电工；买地自建时地价虽低，但砌墙、布线、招人都要花钱。开源协议就像地块产权，决定你的自主权，而 TCO 决定你的钱包受不受得了。

TCO=Csub+Cops+Cmig\displaystyle TCO = C_{\text{sub}} + C_{\text{ops}} + C_{\text{mig}}
TCO 是选型最容易低估的一项：开源省了订阅费，但运维人力往往更贵。
  1. 计算订阅成本托管服务按存储量和请求量收费，相当于云仓的月度租金。
    CsubC_{\text{sub}}
  2. 计算运维成本自建需要有人负责部署、监控、扩容和故障恢复，这部分人力成本很容易被忽略。
    CopsC_{\text{ops}}
  3. 计算迁移成本从旧的存储方案迁移到新系统，需要写脚本、做校验、灰度切换，是一次性投入。
    CmigC_{\text{mig}}
  4. 三项求和把经常性费用和一次性费用加在一起，才是真正要付的总账单。
    TCO=Csub+Cops+CmigTCO = C_{\text{sub}} + C_{\text{ops}} + C_{\text{mig}}

部署方式

部署方式决定仓库建在哪里。Pinecone 只提供云端托管，数据存放在厂商的云环境中，好处是开箱即用，坏处是数据主权交给了别人；Qdrant 支持 Docker、Kubernetes 和云托管等多种方式，你可以在自己的服务器上搭一套完全私有化的向量仓库；Weaviate 同样提供云服务和自托管两种选择，灵活性居中。

对金融、医疗等合规要求高的企业，数据不能出内网，只能选自托管方案；对初创团队，可能连运维工程师都没有，选托管服务才能把精力放在业务上。还有一些团队采用混合部署：测试环境用云托管快速验证，生产环境迁回自建集群。

部署密度可以用资源利用率来衡量：

其中 η 是资源利用率，P_load 是实际负载，P_alloc 是分配给数据库的总资源。

回到仓库场景：云仓按实际件数计费，空置成本低；自建仓无论有没有订单，房租和电费照付。选部署方式前，先用资源利用率公式估算一下，你的业务曲线是平稳还是剧烈波动。

η=PloadPalloc\displaystyle \eta = \frac{P_{\text{load}}}{P_{\text{alloc}}}
资源利用率反映你为仓库配了多少货架、实际用了多少，比值太低说明浪费。
  1. 定义实际负载P_load 是当前实际消耗的计算或存储资源，比如 100 个并发查询占用的 CPU 用量。
    PloadP_{\text{load}}
  2. 定义分配资源P_alloc 是你给数据库配置的总资源，比如集群总共分配了 8 核 CPU。
    PallocP_{\text{alloc}}
  3. 计算利用率实际负载除以分配资源，得到 0 到 1 之间的比值。
    η=PloadPalloc\eta = \frac{P_{\text{load}}}{P_{\text{alloc}}}
  4. 解读结果利用率长期低于 30% 说明资源浪费；高于 90% 则随时可能成为瓶颈，需要扩容。
    PloadPalloc→1\frac{P_{\text{load}}}{P_{\text{alloc}}} \rightarrow 1

混合检索

仓库拣货有两种方式：一种是顾客报出精确的书号 ISBN，靠扫码枪精准定位；另一种是顾客描述“一本关于量子计算的科普书”，靠记忆和常识模糊匹配。混合检索就是把这两种能力结合：用稠密向量捕捉语义，用 BM25 捕捉精确关键词，最后把两份结果融合成一份最终答案。

三家的做法不同：Qdrant 原生支持稠密向量与稀疏向量共存，让两类检索在同一套存储上运行；Weaviate 内置混合检索能力，一条查询同时触发向量搜索和关键词搜索；Pinecone 也提供混合检索功能，但部分高级特性需要企业版支持。融合阶段最常用的算法是 RRF（Reciprocal Rank Fusion，倒数排名融合），公式如下：

其中 R_d 是文档 d 在多个结果列表中出现的排名集合，k 是平滑常数（通常取 60），r 是文档在某个列表中的排名。

混合检索就像让两位拣货员同时干活：一位按货号精确找，一位凭描述模糊找，最后由主管根据两位的“推荐顺序”而不是“打分绝对值”来拍板。RRF 的美妙之处在于它只看排名，所以哪怕两种检索的分数尺度完全不同，也能公平融合。

RRFd=∑r∈Rd1k+r\displaystyle \text{RRF}_d = \sum_{r \in R_d} \frac{1}{k + r}
RRF 不看具体分数，只看排名，因此不需要归一化就能融合不同量纲的检索结果。
  1. 收集排名集合把文档 d 在语义检索和关键词检索两个结果列表中的排名都收集起来。
    Rd={r1,r2,…,rm}R_d = \{r_1, r_2, \dots, r_m\}
  2. 设置平滑常数k 通常取 60，避免排名靠后的文档贡献几乎为零，也能防止分母为零。
    k=60k = 60
  3. 计算单次贡献对每个排名 r 计算 1 除以 (k + r)，排名越靠前贡献越大。
    1k+r\frac{1}{k + r}
  4. 对所有列表求和把同一文档在不同检索列表中的贡献相加，得到最终融合分数。
    ∑r∈Rd1k+r\sum_{r \in R_d} \frac{1}{k + r}

生态工具

仓库除了货架，还需要叉车、扫码枪、库存管理系统。向量数据库的生态工具就是这些“配套设施”，决定开发效率。Pinecone 的 Python SDK 简洁直观，与 LangChain 等框架深度集成，文档和社区示例丰富；Qdrant 提供高性能的 Python 和 TypeScript 客户端，还带 Web UI 方便查看数据和调试；Weaviate 自带 GraphQL API 和模块化插件体系，内置向量化模块可以省掉一部分外部接入工作。

生态的完整程度可以用集成指数来衡量：

其中 F 是所需框架工具的集合，w_f 是每个工具的集成权重，0 代表没有官方支持，1 代表开箱即用。

回到仓库比喻：同样是租仓库，如果供应商连叉车和扫码枪都配好了，团队上手就快；如果只有空荡荡的货架，团队就得自己买工具、写对接代码。选型时打开官方文档数一数集成列表，比看宣传数据更可靠。

Ecosys=∑f∈Fwf\displaystyle E_{\text{cosys}} = \sum_{f \in F} w_f
集成指数越高，开发时踩坑越少；权重为 0 的集成往往要自己封装一层适配器。
  1. 列出所需框架先枚举项目中用到的工具，比如 LangChain、LlamaIndex、FastAPI 等。
    F={f1,f2,…,fn}F = \{f_1, f_2, \dots, f_n\}
  2. 为每个框架赋权根据官方支持程度给每个工具打分，完整的官方集成记 1 分，需要自己封装的记 0.5 分。
    wf∈{0,0.5,1}w_f \in \{0, 0.5, 1\}
  3. 对权重求和把各项权重相加，得到生态集成指数，数值越高说明开发越省力。
    Ecosys=∑f∈FwfE_{\text{cosys}} = \sum_{f \in F} w_f
  4. 对比三家数据库分别计算三个候选的 E 值，就能直观看出与现有技术栈的匹配程度。
    ∑f∈FwfPineconevs∑f∈FwfQdrantvs∑f∈FwfWeaviate\sum_{f \in F} w_f^{\text{Pinecone}} \quad \text{vs} \quad \sum_{f \in F} w_f^{\text{Qdrant}} \quad \text{vs} \quad \sum_{f \in F} w_f^{\text{Weaviate}}

选型决策

最后一步是拍板。把前面的维度放进一个决策漏斗：团队有没有专职运维？对数据主权的要求有多强？业务是否需要混合检索？预算允许订阅制还是更倾向一次性投入？这三个问题的答案基本能圈定候选范围。

一张简洁的决策树是这样生长的：如果是初创团队、希望两周上线、不想管服务器，选 Pinecone 最稳妥；如果公司有成熟运维团队、数据不能出内网、想要极致性能和开源可控，选 Qdrant；如果团队希望开箱即用、需要内置模块和混合检索、又不想被单一厂商绑定，选 Weaviate。

为了把多个考量维度整合成可比较的分数，可以用加权评分模型：

其中 v 是候选数据库，w_i 是第 i 个需求维度的权重，s_i(v) 是候选 v 在该维度上的得分。

仓库选型的最后一步从来不是看哪家广告最响，而是拿着需求清单逐项打分。Pinecone、Weaviate、Qdrant 没有绝对的优劣，只有与你的团队条件、数据规模和场景组合最匹配的一个。选型是一门平衡的艺术，把权重表拉出来，答案自然浮现。

Scorev=∑i=1nwi×si(v)\displaystyle \text{Score}_v = \sum_{i=1}^{n} w_i \times s_i(v)
加权评分把模糊的直觉变成清晰的数字，是技术选型评审会上最实用的沟通工具。
  1. 定义候选与维度v 可以是 Pinecone、Weaviate 或 Qdrant，维度包括性能、扩展性、开源、部署、混合检索和生态。
    v∈{Pinecone,Weaviate,Qdrant}v \in \{\text{Pinecone}, \text{Weaviate}, \text{Qdrant}\}
  2. 为每个维度设置权重根据业务场景对维度赋权，比如合规企业把“开源可控”权重调高。
    wi∈[0,1],∑i=1nwi=1w_i \in [0, 1], \quad \sum_{i=1}^{n} w_i = 1
  3. 给候选打分s_i(v) 表示在某个维度上给候选库的打分，范围从 0 到 10。
    si(v)∈[0,10]s_i(v) \in [0, 10]
  4. 加权求和把每个维度的权重和得分相乘再累加，得到总分后排序，选出最合适的方案。
    Scorev=∑i=1nwi×si(v)\text{Score}_v = \sum_{i=1}^{n} w_i \times s_i(v)

AI 应用场景

企业级 RAG 客服知识库

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

解决的问题：传统客服系统依赖人工维护关键词库，无法理解用户五花八门的口语化表达。接入向量数据库后，用户问题先转成向量，再从海量知识库中检索最相似的片段，交给大模型生成回复。初创团队没有专职 DBA，选择全托管的 Pinecone 可以把部署和扩容压力降到零。

具体案例：一家电商 SaaS 公司把产品文档、工单记录、FAQ 全部切分成块并生成向量存入 Pinecone。每日 50 万次客服查询中，系统先通过语义检索召回 Top20 候选，再由大模型生成答案，人工介入率下降 70%。

医疗数据私有化混合检索

阶段：数据索引与检索

解决的问题：医院需要同时支持“按诊断编码精确查询”和“按症状描述模糊匹配”，还要求所有数据不出内网。Qdrant 的 Apache 2.0 开源协议和自托管能力让它成为首选，搭配 RRF 融合算法，把结构化编码检索与语义检索结果合并。

具体案例：某三甲医院科研团队在院内 GPU 服务器上用 Docker 部署 Qdrant，存储 2000 万条脱敏病历向量。医生输入“反复咳嗽伴胸痛”时，系统既匹配语义相近的病历，又通过关键词命中带“咳嗽”“胸痛”标签的记录，检索召回率提升 35%。

电商多语言商品搜索

阶段：向量化召回与重排

解决的问题：跨境电商的商品描述同时包含中文、英文和少量小语种，单一关键词搜索难以覆盖。Weaviate 内置向量化模块和多语言支持，无需额外搭建 embedding 服务，配合其混合检索能力实现“语义 + 关键词”双通道召回。

具体案例：一家出海电商平台使用 Weaviate 的 Cloud 版本，为 500 万商品生成多语言向量。用户用英文搜索“wireless earphones”，系统能召回中文描述但功能一致的商品，跨语言搜索点击率提升 52%。

Python 演示

python71 行
import numpy as npimport timefrom abc import ABC, abstractmethod  class VectorBase(ABC):    """统一的向量存储接口, 真实项目中替换为各厂商 SDK"""     def __init__(self, dim=64):        self.dim = dim        self.vectors = np.zeros((0, dim))        self.doc_ids = []     @abstractmethod    def upsert(self, ids, vectors):        pass     @abstractmethod    def search(self, query, top_k=10):        pass  class MockPinecone(VectorBase):    """模拟 Pinecone 的托管检索核心逻辑"""     def upsert(self, ids, vectors):        self.vectors = np.vstack([self.vectors, vectors])        self.doc_ids.extend(ids)     def search(self, query, top_k=10):        scores = self.vectors @ query        idx = np.argsort(scores)[-top_k:][::-1]        return [(self.doc_ids[i], float(scores[i])) for i in idx]  class MockQdrant(MockPinecone):    """模拟 Qdrant, 实际项目中使用其 Python 客户端"""  class MockWeaviate(MockQdrant):    """模拟 Weaviate, 实际项目中使用其 Python 客户端"""  def generate_corpus(n=3000, dim=64, seed=7):    rng = np.random.default_rng(seed)    vectors = rng.normal(size=(n, dim))    vectors /= np.linalg.norm(vectors, axis=1, keepdims=True)    ids = [f"doc-{i}" for i in range(n)]    return ids, vectors  def run_benchmark(store, ids, vectors, queries=100, top_k=10):    store.upsert(ids[:1000], vectors[:1000])    query = vectors[0]    start = time.perf_counter()    for _ in range(queries):        store.search(query, top_k)    avg_ms = (time.perf_counter() - start) * 1000 / queries    hits, _ = zip(*store.search(query, top_k))    return len(hits), avg_ms  if __name__ == "__main__":    ids, vectors = generate_corpus()    for name, store in [        ("Pinecone(模拟)", MockPinecone()),        ("Qdrant(模拟)", MockQdrant()),        ("Weaviate(模拟)", MockWeaviate()),    ]:        cnt, ms = run_benchmark(store, ids, vectors)        print(f"{name}: top_k 命中 {cnt} 条, 平均延迟 {ms:.2f} ms")
目的：以统一的抽象接口模拟三款向量数据库的写入与检索流程，演示如何在同一个数据管线上无缝切换存储层。真实项目中只需替换每个类的内部实现为对应官方 SDK 即可。
  1. class VectorBase(ABC):定义统一的向量存储接口，让上层业务代码与具体厂商解耦。
  2. self.vectors = np.zeros((0, dim))初始化一个空矩阵，后续用 np.vstack 不断追加向量。
  3. def upsert(self, ids, vectors):实现“写入或更新”方法，模拟真实数据库的 upsert 语义。
  4. scores = self.vectors @ query用矩阵乘法一次性算出所有已存向量与查询向量的相似度。
  5. idx = np.argsort(scores)[-top_k:][::-1]对得分排序并取出前 top_k 的索引，对应数据库的 TopK 检索。
  6. hits, _ = zip(*store.search(query, top_k))解包检索结果，只取命中文档 ID 数量用于统计。
  7. avg_ms = (time.perf_counter() - start) * 1000 / queries计算平均单次查询耗时，作为性能对比指标。
  8. for name, store in [...]用同一套接口分别构造三个“供应商实例”，体现无缝切换的设计思路。

常见误区

误区看到 Qdrant 和 Weaviate 采用开源协议就觉得完全免费，连服务器和运维成本都没算，直接选开源方案。

正解开源协议只是免了软件授权费，但部署、监控、扩容、备份、故障恢复都要人力投入。TCO 公式里 C_ops 常常超过 C_sub。开源是“买地自建”，土地虽免，建材和人工都是钱；全托管更像“按月租仓”，看着贵，但省了养团队的钱。

为何常见：因为“免费”是最直观的信息，而隐性的运维成本需要有一定实战经验才能体会，新手很容易只看字面价格。

误区压测时只关注 QPS 和延迟，几万 QPS 看着很爽，就断定一个数据库更强。

正解向量检索是速度与精度的权衡，HNSW 等索引通过调低召回率来换取速度。如果召回率从 0.98 掉到 0.82，再高的 QPS 也无法弥补用户搜不到结果的糟糕体验。选型报告必须同时包含 p99、QPS 和 Recall@k 三个指标。

为何常见：因为速度指标最容易被量化、最直观，而召回率依赖标注数据集，构造成本高，很多人就干脆省略了。

误区以为混合检索就是同时跑语义搜索和关键词搜索，然后把两拨结果合并去重就完事了。

正解两套搜索引擎的分数分布完全不同，直接硬拼接会导致某一方的结果永远排前面。RRF 按排名倒数融合，不看原始分，才能让两边公平发言。真正的混合检索是“两个拣货员分别推荐，主管按推荐顺序而不是打分高低来拍板”。

为何常见：因为“拼接”是人类最自然的直觉，而 RRF 这种按排名融合的反直觉设计需要理解后才接受。

误区既然向量数据库能存“数据”，是不是可以把所有内容都放进去，传统关系库可以扔掉了？

正解向量数据库擅长的是高维向量的近似最近邻检索，虽然支持标量过滤，但事务处理、复杂关联查询并不是它的强项。真实系统里通常是 PostgreSQL 存订单状态，向量库存语义索引，两者配合使用。仓库里既有冷藏区又有干货区，不能因为冷藏区好用就把所有货都塞进去。

为何常见：因为向量数据库的“数据库”三个字容易让人联想它什么都能干，混淆了专用引擎与通用存储的边界。

误区谁在某篇测评里拿了第一就用谁，完全忽略团队条件、数据规模、部署环境等上下文。

正解性能第一的方案可能因为闭源或部署复杂而无法落地，生态最全的方案可能超出预算。选型必须用加权评分模型，把性能、扩展、协议、部署、混合检索、生态六个维度按权重综合打分。没有最好的数据库，只有最匹配的组合。

为何常见：因为测评榜单用醒目的大数字制造了“秒杀感”，而真实业务中的约束条件需要复盘式思考才能看见。

面试题

Q1. 以下哪个是纯托管型向量数据库？

单选题 · easy

  • A.自建 Qdrant 集群
  • B.Pinecone 托管服务← 正确答案
  • C.本机安装 Milvus
  • D.手动部署 Weaviate

答案：B。Pinecone 是商业托管服务，用户不直接管理底层集群；Qdrant、Milvus、Weaviate 都有自托管模式。理解这个区别能帮你判断什么场景需要精简运维、什么场景优先数据可控。平时不做容器管理就应选托管方案。

Q2. Qdrant 采用哪种开源许可证？

单选题 · easy

  • A.Apache 2.0 协议← 正确答案
  • B.GNU GPL v3 协议
  • C.闭源商业软件协议
  • D.MIT 宽松开源协议

答案：A。Qdrant 采用 Apache 2.0，允许自由使用、修改和商用，对二次开发友好。GPL 是 Copyleft 协议、MIT 更简短宽松，但不能混淆。Apache 2.0 是最适合企业自建向量存储的许可证之一。

Q3. RRF 融合时，K 常量通常取多少？

单选题 · mid

  • A.常数 0 表示不缩放
  • B.常数 60 平滑排名差距← 正确答案
  • C.常数 1000 覆盖全排序
  • D.常数随查询数据变化

答案：B。RRF 中 k 是平滑常数，常见取值为 60。k 过小会让排名靠后的文档贡献趋近为零，k 过大则会让所有结果贡献接近，失去排名区分度。60 是社区经验值，能够均衡深浅排名的权重，这也是“选型要理解算法细节”的典型例子。

Q4. 自托管向量数据库的特点是什么？

单选题 · mid

  • A.数据可控且成本可预期← 正确答案
  • B.永远不需要运维人员
  • C.性能一定优于托管服务
  • D.自动获得厂商技术支持

答案：A。自托管的最大价值是数据主权和可控成本，但前提是团队具备运维能力。它并不会自动比托管更快，也不包含企业支持服务。选择自托管就像买地自建仓库，地价虽省但水电人工仍要自己负责。

Q5. HNSW 索引的主要作用？

单选题 · mid

  • A.全局暴力扫描全部向量
  • B.分层图加速近似近邻检索← 正确答案
  • C.将数据做成关键词倒排表
  • D.仅对元数据建立普通索引

答案：B。HNSW 通过构建多层次近邻图，让查询从顶层粗筛逐步下沉到底层精搜，大幅降低检索复杂度。它不是关键词倒排，也不做暴力扫描。理解 HNSW 就明白为什么召回率和速度之间需要权衡，也就能读懂各家压测报告中的术语。

Q6. 在 RRF 公式中，排名 r=5 且 k=60 时的贡献分值？

单选题 · hard

  • A.1 除以 65← 正确答案
  • B.1 除以 5
  • C.5 分之 60
  • D.60 除以 5

答案：A。RRF 的贡献是 1/(k + r)，代入 k=60、r=5 得到 1/65。分母是平滑常数与排名的和，排名越靠前贡献越大，但差距被 k 平滑。这道题考察的是对融合公式的精确记忆，而不是概念性的“越靠前越好”。

Q7. 选型时团队条件最关键的是？

单选题 · easy

  • A.团队具备相应运维能力← 正确答案
  • B.数据库名字听起来很潮
  • C.演示视频视觉效果好看
  • D.同事推荐且不使用开源

答案：A。是否有专职运维决定了能不能选自托管方案。名字、演示效果和同事推荐都是加分项，但都不构成核心的工程决策依据。先把团队的“看店能力”估算清楚，再决定租云仓还是自建仓。

Q8. 混合检索通常结合哪些信号？

多选题 · mid

  • A.稠密向量的语义相似度← 正确答案
  • B.关键词 BM25 得分← 正确答案
  • C.结构化标签过滤
  • D.模型自动生成摘要

答案：AB。混合检索的核心是“语义 + 关键词”双通道，加上可选的标量过滤，才能同时照顾模糊语义和精确匹配。生成摘要是大模型的任务，不属于检索信号。RRF 的融合前提就是存在至少两个相互独立的检索结果列表。

Q9. 从托管迁移到自托管需要考虑？

多选题 · hard

  • A.集群搭建与监控职责← 正确答案
  • B.数据迁移与灰度切换← 正确答案
  • C.索引参数调优能力← 正确答案
  • D.领导是否喜欢新名字

答案：ABC。迁移自托管意味着接管集群生命周期、数据搬迁和参数调优三件事，任何一个环节出问题都会直接影响线上检索质量。把迁移成本直接纳入 TCO 公式才能避免事后发现“省了订阅费、赔了人天”。团队没有这些能力时，托管反而是性价比更高的选择。

Q10. 向量数据库在 RAG 中承担哪些作用？

多选题 · easy

  • A.存储语义化 embedding 向量← 正确答案
  • B.快速检索最相似内容片段← 正确答案
  • C.提供标量元数据过滤能力← 正确答案
  • D.替代大模型的文本生成功能

答案：ABC。RAG 依赖向量库完成存储、召回和过滤，这三者构成检索增强的基础。文本生成由大模型完成，向量数据库只负责“找到对的内容”而不是“生成答案”。理解这条边界才不会被“向量数据库无所不能”的传言带偏。