Qdrant：RAG的向量数据库 本地

#向量数据库的作用

嵌入模型会将文本转换为一串数字——即一个向量——使两段语义相近的文本得到两个相近的向量。因此，为一个问题查找相关段落，就相当于寻找与该问题的向量最接近的向量。对于一千个段落，对整个集合做一次简单计算就够了。对于一百万个段落，则需要索引结构，这正是向量数据库的职责：构建并维护这一结构，在几毫秒内给出响应，而不是逐一比较所有向量，并在语料库不断接收新文档的过程中保持结果正确。

这一步决定了后续的一切：即使模型很出色，收到不相关的文本片段也会答不好，而任何提示词指令都无法弥补检索不佳的问题。因此，向量数据库的选择虽然长期被视为可以随意替换的基础设施细节，却值得像选择语言模型本身一样认真对待。

#Qdrant带来的优势

该项目将自身描述为一个“高性能、大规模”的搜索引擎和向量数据库，专为广泛的筛选需求而设计——这使其区别于只进行无条件最近邻搜索的库。它使用 Rust 编写，作者认为这正是它在高负载下仍能保持快速、可靠的原因。在运行稳健性方面，项目文档还介绍了预写日志（write-ahead logging）机制：即使发生断电，也能保证已确认更新的数据持久保存；此外，还提供指标、遥测和审计日志，用于监控和调试生产环境中的部署。

独立服务器

一个容器、支持 HTTP 和 gRPC 的 API，以及 Python、Go、Rust、JavaScript/TypeScript、.NET 和 Java 的官方客户端。它独立于您的应用运行，应用可以重启，而不会丢失已构建的索引。

按payload进行过滤

每个向量都携带元数据——作者、日期、部门、文档类型——在检索过程中使用 should、must 和 must_not 子句依据这些元数据进行筛选，而不是在检索后筛选。这正是能在企业中实际使用的搜索与演示之间的区别。

向量的量化

压缩向量以显著降低内存占用（标量压缩可提升 4 倍，二进制压缩最高可达 32 倍），代价是可控的精度损失，但可被后续补偿。

稀疏向量与多向量

除了传统的稠密向量，Qdrant还支持用于全文检索的稀疏向量，以及包含多个嵌入向量的对象；后者适用于ColBERT等采用后期交互机制的模型。

混合搜索

在同一次查询中组合多个向量，以同时发挥语义理解和关键词精确匹配的优势，并通过可配置的策略融合结果，例如倒数排名融合（RRF）或基于分布的分数融合（DBSF）。

快照与恢复

备份一个集合，并在其他地方恢复它；当重新索引需要耗费数小时的 GPU 运算时间时，这一点就很重要。

分布式部署

通过分片和复制将一个集合分布到多个节点，并在不中断服务的情况下调整规模——这主要适用于超出严格本地使用范围的场景，但提前了解也很有用：当项目扩大、单台机器不再够用时，就不必从零开始重建一切。

#本地启动

最简便的方式是使用官方容器，并挂载一个卷，让数据在重启后仍然保留。项目将内置的 Web 界面描述为“一种以可视化方式与数据交互并监控部署健康状况的手段”。借助它，您随后可以浏览集合、管理数据和查询 REST API，无需编写任何代码——当回答不理想时，这是最好的诊断工具：直接查看实际检索到了什么，而不是重新阅读检索代码来猜测。

docker run -p 6333:6333 -p 6334:6334 \
  -v "$(pwd)/qdrant_storage:/qdrant/storage" \
  qdrant/qdrant

Python 客户端也可以完全不依赖服务器运行：使用 QdrantClient(":memory:") 进行一次性测试，或使用 QdrantClient(path="chemin/vers/db") 实现本地持久化存储。这对原型开发或自动化测试很有价值；之后只需修改一行连接代码，同一套代码就能改为连接服务器。自 2026 年起，项目文档还介绍了第二种集成方式——Qdrant Edge：这是为资源受限设备设计的轻量版本，直接在应用程序的进程内运行，而非采用客户端—服务器架构，并可与完整的 Qdrant 服务器同步。

#最基本的 Python 用法

1. 01
   连接

   先执行 from qdrant_client import QdrantClient，再执行 client = QdrantClient(url="http://localhost:6333")，即可连接到上面启动的容器。
2. 02
   创建一个集合

   client.create_collection(collection_name="docs", vectors_config=VectorParams(size=1024, distance=Distance.COSINE)) —— 向量大小必须与您的嵌入模型的维度完全一致。
3. 03
   插入数据点

   client.upsert(collection_name="docs", points=[PointStruct(id=1, vector=[...], payload={"service": "support"})]) 为每个向量关联一个标识符和可用于过滤的元数据。
4. 04
   查询

   client.query_points(collection_name="docs", query=vecteur_question, limit=5).points 返回最接近的五个段落，包含其得分和payload

#元数据过滤：一个忽视后会让您后悔的功能

在实际场景中，提问几乎从来不会涉及整个语料库。我们通常会在某个部门的文档、某个日期之后的文档、特定类型的文档，或提问用户有权访问的文档中搜索。Qdrant 在向量搜索过程中应用这些条件，提供丰富的过滤条件——关键词匹配、全文检索、数值范围、地理位置——并通过 should、must 和 must_not 逻辑子句将其组合起来，因此总能返回数量合适的相关结果，而事后过滤可能一个结果也留不下来。

访问控制值得单独说明：如果多人查询同一个索引，权限过滤机制可以防止模型向某人引用其无权阅读的文档。任何提示词指令都不能替代这种过滤机制。将过滤逻辑写在数据库层，而不是应用代码中，可以避免访问同一集合的新接口忘记应用该过滤机制。

#让向量装得进内存：向量量化

文档介绍的做法是先在压缩向量上检索，再用原始向量对最优候选项重新评分并排序（rescoring）。Qdrant 提供了过采样（oversampling）参数来调整这一权衡：当参数设为 2.4、结果数量上限为 100 时，会先从量化索引中筛选出 240 个候选项，再进行最终排序。这样可以保留大部分精度，同时将内存占用降至原来的四分之一甚至更低；对于还运行着一个模型的机器来说，这种节省十分必要。官方文档还宣称，相比原始向量，二值量化最多可带来 40 倍的加速；这一数字应在自己的数据集上验证，而不能视为理所当然。该项目在概述所有这些压缩选项与磁盘存储结合使用的效果时，宣称内存占用最多可减少 97%。这一数量级解释了为什么量化被视为核心功能，而非无关紧要的设置。

#选择 Qdrant 还是其他数据库

需要思考的问题不是“哪个向量数据库最好”，而是“我的项目当前有什么要求”。测试脚本只需要一个内存库。对于已经查询 PostgreSQL 的业务应用，添加向量扩展比再增加一个服务更有利。正是在以下多项需求同时出现时，Qdrant 才成为合适的选择：多个应用共享一个服务、对元数据进行精细过滤、语料库持续增长，以及不想自行重新实现持久化或快照功能。定期重新审视这一选择，而不是在第一个原型阶段就将其固定下来，既能避免对小型项目过度设计，也能避免为已经发展壮大的项目配置不足。

• 完整的本地RAG，涵盖数据摄入至响应全过程
• 选择适用于法语的嵌入模型
• 添加重排序器以提升相关性
• pgvector：什么时候 PostgreSQL 就够用了
• QuelLLM 本地 RAG 工具包
• 来源：Qdrant 官方 GitHub 仓库
• 来源：量化技术的官方文档
• 来源：Qdrant Python快速入门指南

#FAQ