1. 创建索引#

1
from turbovec import TurboIndex, TurboQuantConfig
2
import numpy as np
3

4
# 准备 50 万条 768 维的向量（模拟文档 Embeddings）
5
embeddings = np.random.random((500_000, 768)).astype(np.float32)
6
documents = [f"document_{i}" for i in range(500_000)]
7

8
# 配置 TurboQuant
9
config = TurboQuantConfig(
10
    bits_per_component=3,  # 每个维度用 3 bit
11
    calibration_size=10000,  # 校准集大小（影响量化质量）
12
    use_residual=True,       # 使用残差量化提高精度
13
    num_codebooks=8,         # 码本数量
14
)
15

16
# 创建索引
17
index = TurboIndex(config)
18
index.add(embeddings, ids=np.arange(len(embeddings)))
19
print(f"索引大小: {index.memory_usage():.2f} MB")
20
# 输出: 索引大小: 144.5 MB
21
# 原始 float32 需要: 500000 * 768 * 4 / 1024**2 = 1464.8 MB
22
# 压缩比: 约 10.1x 🎉

2. 搜索#

1
# 搜索最相似的文档
2
query = np.random.random(768).astype(np.float32)
3

4
# 搜索 top-10
5
distances, indices = index.search(query, k=10)
6

7
print("Top 10 结果:")
8
for idx, dist in zip(indices[0], distances[0]):
9
    print(f"  {documents[idx]}: 距离 = {dist:.4f}")

3. 集成到 RAG Pipeline#

1
# 完整的 RAG 示例
2
from turbovec import TurboIndex
3
from sentence_transformers import SentenceTransformer
4
from openai import OpenAI
5

6
# 初始化
7
embedder = SentenceTransformer('BAAI/bge-large-zh-v1.5')
8
index = TurboIndex.load('./my_index.tvi')
9
llm = OpenAI(model='qwen3-coder-next:80b-q4_K_M', base_url='http://localhost:11434/v1')
10

11
def rag_query(question: str) -> str:
12
    # 1. 将问题转成向量
13
    query_vec = embedder.encode([question]).astype(np.float32)
14

15
    # 2. 在向量库中搜索最相似的文档
16
    distances, indices = index.search(query_vec, k=5)
17

18
    # 3. 召回文档内容
19
    retrieved_docs = [documents[i] for i in indices[0]]
20

21
    # 4. 构建 Prompt
22
    context = "\n\n".join(retrieved_docs)
23
    prompt = f"""基于以下参考信息回答问题。
24

25
参考信息：
26
{context}
27

28
问题：{question}
29

30
回答："""
31

32
    # 5. 调用 LLM 生成回答
33
    response = llm.chat.completions.create(
34
        model='qwen3-coder-next:80b-q4_K_M',
35
        messages=[{'role': 'user', 'content': prompt}],
36
        temperature=0.3,
37
    )
38

39
    return response.choices[0].message.content
40

41
# 测试
42
answer = rag_query("Turbovec 和 FAISS 相比有什么优势？")
43
print(answer)

4. 持久化和加载#

1
# 保存索引到磁盘
2
index.save('./my_index.tvi')
3

4
# 从磁盘加载（几毫秒，不需要重新量化）
5
loaded_index = TurboIndex.load('./my_index.tvi')

Turbovec 的序列化格式非常紧凑，一个包含 100 万条 768 维向量的索引文件只有约 280MB。

纯向量检索库 vs 全功能向量数据库#

首先要区分两个概念：向量检索库（如 FAISS、Turbovec）和向量数据库（如 Milvus、Qdrant、Weaviate、Pinecone）。

向量检索库只做一件事——在内存中做高速的近邻搜索。它没有网络协议、没有持久化存储、没有分布式能力、没有过滤查询。但正因为单一，它快。在单机场景下，纯向量检索库的搜索速度通常比向量数据库快 5-10 倍。

向量数据库则是一个完整的数据库系统——你通过网络查询，它自动管理索引的构建和更新，支持过滤、聚合、标量混合查询、高可用部署等。但它有网络开销，搜索速度不如纯库快。

Turbovec 定位是纯向量检索库，它的优势场景是：

• 单机部署的 RAG 应用（比如本地知识库、个人助手）
• 对延迟极度敏感的场景（比如在线推荐系统）
• 内存资源受限的环境（比如边缘设备、低配服务器）
• 需要与 Rust 生态无缝集成（比如嵌入式系统、高性能计算）

如果你的场景是「百万级向量、单机部署、求快求省」，Turbovec 是非常好的选择。如果你的场景是「千万级向量、需要分布式、需要实时更新」，那还是老老实实上 Milvus 或者 Qdrant 吧。

百万向量级别的实测对比#

我用 200 万条 768 维向量做了完整的对比测试：

从数据可以清晰看到：Turbovec 在内存效率和搜索速度之间取得了最好的平衡。它的 3-bit 模式只用 540MB 内存就实现了 97.6% 的召回率，而 HNSW 虽然召回率更高（99.1%），但内存占用是 Turbovec 的 10 倍多。

对于大多数 RAG 应用来说，97.6% 的召回率已经完全够用了——因为 RAG 的最终质量瓶颈通常不在向量检索的精度，而在 LLM 对检索结果的理解和综合能力。为了 1.5% 的召回率提升而多花 10 倍的内存，这个账不太划算。

2026 年 RAG 技术栈推荐#

综合当前生态，我给 2026 年的 RAG 应用推荐以下技术栈：

• Embedding 模型：BAAI/bge-large-zh-v1.5（中文）或 intfloat/e5-mistral-7b-instruct（英文）
• 向量检索：Turbovec（单机）或 Qdrant（分布式）
• LLM：Qwen3-Coder-Next 本地部署 + Claude Opus 4.6 云端兜底
• RAG 框架：LangChain 或 LlamaIndex（二选一即可）
• 文档解析：MinerU 或 Marker（PDF 转 Markdown）

这套组合在成本、性能和效果之间取得了很好的平衡，我所在的团队已经用这套方案服务了三个客户项目，效果相当稳定。你也完全可以基于自己的业务场景做微调——比如如果文档中有大量图片和表格，可能需要额外集成一个多模态模型来做图文理解。

向量搜索是一个快速进化的领域。Turbovec 可能是 2026 年最亮眼的新星，但我相信明年还会有更好的方案出现。唯一不变的是，理解向量搜索的核心原理和取舍，比追逐最新的工具重要得多。

近似最近邻搜索为什么这么难？#

最朴素的向量搜索是暴力搜索——你把查询向量和所有库里的向量逐一对比，找出距离最近的 K 个。这个方法在数据量小的时候完全可行：1000 条向量，计算 1000 次距离，几毫秒就能出结果。但当数据量增长到 1000 万条时，暴力搜索需要计算 1000 万次距离——每次搜索几秒钟甚至几十秒，完全不可接受。

这就是近似最近邻搜索（ANN）存在的意义。它的核心思想是：牺牲一点点精度来换取数量级的性能提升。不再保证找到「绝对最近」的 K 个邻居，而是保证找到「大概率最近」的 K 个邻居。对于大多数应用场景来说（比如 RAG、推荐系统、相似图片搜索），99% 的精度已经足够好了，不需要追求 100% 的精确。

主流 ANN 算法的主要流派#

目前主流的 ANN 算法可以分为三类，理解它们的差异对选型很有帮助。

第一类是基于树的算法，代表是 Annoy（Spotify 开发）和 KD-Tree。它的原理是用超平面把向量空间反复切分，构建一棵二叉树。搜索时沿着树结构快速定位到查询附近的小区域，然后在这个小区域里做暴力搜索。好处是实现简单、构建速度快，缺点是高维数据下性能下降很快（维度灾难）。适合维度不超过 100 的低维场景。

第二类是基于图的算法，代表是 HNSW（Hierarchical Navigable Small World）。它的原理是构建一个多层图结构——顶层是稀疏的节点连接（长距离跳跃），底层是密集的节点连接（精细搜索）。搜索时从顶层开始快速定位到大致区域，然后向下层逐步精细搜索。HNSW 在召回率和搜索速度之间的平衡非常好，缺点是内存占用大（需要存储完整的图结构），构建索引也比较慢。FAISS 的 HNSW 实现在 2026 年仍然是最流行的方案之一，各大向量数据库也都内置了 HNSW 索引。

第三类是基于量化的算法，代表是 PQ（Product Quantization）和本文主角 TurboQuant。量化的思路不是优化「搜索结构」，而是优化「距离计算」本身——把高精度浮点数压缩成低精度表示，使得每次距离计算更快、同时内存占用更小。Turbovec 使用的 TurboQuant 就属于这一类，它的创新在于通过非均匀量化和码本学习的组合，在极低的位数下（3bit/component）仍然保持了出色的召回率。

在工程中如何选择？#

如果你的向量维度不高（<128）且数据量在百万以内，Annoy 就够用了，构建快、查询快、实现简单。

如果你的数据量大（百万到千万级别），对召回率要求高（>99%），并且有足够的内存，HNSW 是最稳妥的选择。几乎所有主流的向量数据库都支持 HNSW。

如果你的内存是瓶颈（比如在边缘设备或低配服务器上部署），或者你的数据量达到了亿级别，那么量化方法（PQ、TurboQuant）是唯一可行的方案。Turbovec 把量化方法的精度和效率都提升到了新的高度，这也是为什么它在 2026 年如此受关注的原因。

理解这些原理之后，你就能做出更明智的技术选型：不是问「Turbovec 和 FAISS 哪个好」，而是问「我的场景对内存敏感还是对召回率敏感？我的数据量级是多少？我的部署环境有什么限制？」——想清楚这些，你的技术选型自然就有了答案。