













下面这篇按你之前说的风格来写:标题简单,正文详细讲清楚。主题可以作为 java.li 向 AI 应用、RAG、向量检索方向扩展的一篇基础文章。
最后更新:2026-07-29
适用场景:向量数据库、语义搜索、RAG 知识库、AI 问答、相似内容推荐、图片搜索、商品搜索、Spring AI、Java 后端接入向量检索
这两年做 AI 应用,经常会听到一个词:向量数据库。
比如你想做一个知识库问答系统,用户问:
Spring Boot 3 为什么要求 JDK17?
传统数据库更擅长查这种:
select * from article where title like '%Spring Boot 3%'
但如果文章标题里没有完全一样的关键词,只是内容里讲了:
Spring Boot 3 基于 Spring Framework 6,最低要求 Java 17
普通关键词搜索可能就没那么好用了。
向量数据库解决的就是这类问题:不是只看关键词一样不一样,而是看语义接不接近。
Qdrant 就是一个常见的开源向量数据库。它可以把文本、图片、音频等内容对应的向量存起来,再根据相似度找出最接近的内容。Qdrant 官方文档也把向量搜索解释为一种超越关键词匹配的信息检索方式:先用 embedding model 把文本、图片、音频等非结构化数据转成向量,再在高维向量空间里查找语义相近的数据。(Qdrant)
简单说:
Qdrant 是一个用来存储和检索向量的数据库。
它最常见的用途是:
语义搜索
RAG 知识库
相似文章推荐
商品相似推荐
图片相似搜索
问答系统召回
AI Agent 记忆库
简历和岗位匹配
代码语义搜索
你可以把它理解成:
MySQL 擅长精确查数据
Elasticsearch 擅长关键词搜索
Redis 擅长缓存和快速读写
Qdrant 擅长“相似度搜索”
当然,这个类比不是绝对的。Qdrant 不是拿来替代 MySQL 的,它更适合解决“根据语义找相似内容”的问题。
比如:
用户问:Java 项目启动时报 DataSource 错误怎么办?
系统可以从知识库里找到:
Spring Boot Failed to configure a DataSource 解决办法
即使用户没有完全输入文章标题,系统也能根据语义找到相关内容。
向量本质上就是一组数字。
例如一段文本:
Spring Boot 启动时报 DataSource 错误
经过 embedding model 处理后,可能会变成类似这样的数字数组:
[0.12, -0.08, 0.45, 0.91, ...]
真实场景里,向量维度可能是:
384
768
1024
1536
3072
具体维度取决于你使用的 embedding 模型。
向量数据库不会凭空理解文本。一般流程是:
原始文本
↓
Embedding 模型
↓
向量
↓
写入 Qdrant
↓
用户问题也转成向量
↓
Qdrant 查找最相似的向量
↓
返回对应文章、段落、商品或图片
这点很重要:Qdrant 负责存储和检索向量,但“把文本变成向量”通常需要 embedding 模型来完成。
Qdrant 官方概览中也提到,向量搜索通常从 embedding model 开始,它会把非结构化数据转换成固定长度的 dense vector embeddings;查询时,用户请求也会被转换成 query vector,然后返回最接近的 Top-K 结果。(Qdrant)
这是现在最常见的场景。
比如你有一批文档:
公司内部文档
产品说明书
技术博客
客服问答
API 文档
法律条款
企业知识库
你可以把它们拆成小段,每一段生成一个向量,存进 Qdrant。
用户提问时:
怎么配置 Maven 国内镜像?
系统先把这个问题转成向量,然后从 Qdrant 里找出最相似的几段内容,再交给大模型组织答案。
这就是常见的 RAG 流程:
用户问题
↓
向量检索
↓
召回相关文档
↓
大模型结合文档回答
Qdrant 官方也把 Hybrid Retrieval 作为增强检索体验的一种方式,结合语义搜索和词法搜索来提高结果稳健性。(Qdrant)
传统搜索更依赖关键词。
比如用户搜:
JDK 环境变量不生效
传统搜索可能更容易匹配到标题里包含“JDK”“环境变量”的文章。
语义搜索更关注意思。它可能找到:
Windows 配置 JAVA_HOME 后 java -version 显示旧版本
javac 不是内部或外部命令怎么办
IDEA 配置本地 JDK 教程
这些内容不一定和用户输入完全一样,但语义相关。
对于技术站来说,语义搜索很适合用在:
站内搜索
文档搜索
报错搜索
FAQ 搜索
代码片段搜索
比如你的网站里有一篇文章:
Maven 依赖冲突怎么排查
系统可以根据这篇文章的向量,找出相似文章:
Maven 下载依赖失败怎么处理
Maven 国内镜像配置教程
No compiler is provided in this environment
Spring Boot 2 升级 3 指南
这比单纯按标签推荐更灵活。
标签推荐只能看到:
Maven
Java
Spring Boot
向量推荐能看到文章内容本身的相似度。
电商、内容社区、资讯站都可以用。
例如商品推荐:
用户正在看一款机械键盘
系统推荐相似手感、相似价格、相似品牌的键盘
内容推荐:
用户看了 Spring Boot DataSource 报错
系统推荐其他 Spring Boot 启动报错
简历匹配:
岗位描述转向量
简历内容转向量
找出匹配度高的候选人
向量不只用于文本。
如果你用图像 embedding 模型,可以把图片转换成向量。然后就能做:
以图搜图
相似商品图搜索
重复图片检测
图片素材推荐
图片风格相似度查找
Agent 应用里经常需要“记住”过去的信息。
比如:
用户偏好
历史对话
任务记录
文档片段
工具调用结果
这些内容可以写入向量数据库,后续根据当前任务语义召回相关记忆。
不过这里要注意:不是所有记忆都适合丢进向量库。结构化信息,比如用户 ID、权限、订单状态,还是更适合放在传统数据库里。
Qdrant 的概念不算复杂,先理解这几个就够了:
Collection
Point
Vector
Payload
Distance
Filter
Index
Collection 可以粗略理解为“一个向量集合”。
比如你可以建一个 collection:
java_articles
里面放你网站所有 Java 文章的向量。
也可以建:
product_vectors
里面放商品向量。
再比如:
faq_vectors
里面放 FAQ 问答向量。
一个 Collection 里会定义向量维度和相似度算法,比如:
向量维度:768
距离算法:Cosine
Qdrant 官方快速开始里也展示了创建 collection 的过程,创建时需要指定向量 size 和 distance,例如示例中用 VectorParams(size=4, distance=Distance.DOT) 创建测试集合。(Qdrant)
Point 是 Qdrant 里最核心的数据单位。
一个 Point 通常包含:
id
vector
payload
可以理解成:
一条可检索的数据
例如一篇文章的一个段落:
{
"id": 1001,
"vector": [0.12, 0.23, 0.34, 0.45],
"payload": {
"title": "Spring Boot DataSource 报错怎么处理",
"url": "/archives/spring-boot-failed-to-configure-datasource",
"category": "Spring Boot",
"tag": ["Spring Boot", "DataSource", "MySQL"]
}
}
Qdrant 官方文档对 Point 的定义很直接:Point 是 Qdrant 操作的中心实体,它是一条由 vector 和可选 payload 组成的记录;Point 可以按向量相似度在 collection 中被搜索。(Qdrant)
Vector 就是用来做相似度计算的那组数字。
比如:
[0.05, 0.61, 0.76, 0.74]
这只是演示向量,真实 embedding 向量通常维度更高。
Qdrant 支持多种向量结构,包括 dense vectors、sparse vectors 和 multivectors;一个 point 也可以挂多个不同类型或不同用途的 named vectors。(Qdrant)
简单理解:
| 类型 | 适合场景 |
|---|---|
| Dense Vector | 语义搜索、RAG、图片搜索 |
| Sparse Vector | 关键词、精确词项、文本检索 |
| MultiVector | ColBERT 这类 late interaction 模型 |
| Named Vector | 一个点里存多种向量,比如标题向量、正文向量 |
新手一开始不用把这些全用上,先用普通 dense vector 就够了。
Payload 就是附加信息,通常是 JSON。
比如:
{
"title": "Maven 国内镜像配置教程",
"url": "/archives/FtMJgXo1",
"category": "Maven",
"published": true,
"createdAt": "2026-05-12"
}
Payload 的作用不是计算语义相似度,而是方便你:
返回标题和链接
按分类过滤
按用户权限过滤
按时间过滤
按标签过滤
按价格过滤
按地区过滤
比如用户搜 Java 文章时,你只想返回:
category = Java技术交流
published = true
这就需要过滤。
Qdrant 官方 Filtering 文档说明,搜索或获取 points 时可以对 payload 和 point id 设置条件;这种过滤适合处理 embedding 无法表达的业务条件,比如库存、位置、价格范围等。(Qdrant)
Distance 决定了 Qdrant 怎么判断两个向量“像不像”。
常见距离方式有:
Cosine
Dot
Euclid
Manhattan
简单理解:
| 距离方式 | 常见用途 |
|---|---|
| Cosine | 文本语义搜索、RAG、文档检索 |
| Dot | 推荐系统、排序、部分 embedding 模型 |
| Euclid | 空间距离、聚类、异常检测 |
| Manhattan | 稀疏数据、部分数值场景 |
如果你不知道该选哪个,文本语义搜索通常优先看 embedding 模型文档。如果模型文档没说明,Qdrant 的距离指标课程里也提到,Cosine 常用于 NLP embeddings、semantic search 和 document retrieval;在不确定时,Cosine 往往是一个安全默认选择。(Qdrant)
很多人会问:
既然有 Elasticsearch,为什么还要 Qdrant?
简单说:
Elasticsearch 更偏关键词检索
Qdrant 更偏向量相似度检索
比如用户搜索:
Spring Boot 数据库连接失败
Elasticsearch 更擅长找包含这些词的文档。
Qdrant 更擅长找语义相近的内容,比如:
Failed to configure a DataSource
spring.datasource.url 未配置
MySQL 驱动缺失
application-dev.yml 没激活
它们不是非此即彼。
很多场景更适合混合:
关键词搜索 + 向量搜索
这就是 Hybrid Search。Qdrant 的 Hybrid Queries 文档也支持把 dense、sparse、multivector 等多路召回结果融合起来,并提供 RRF、DBSF 等融合方式;如果没有评测集也没有强分数先验,官方文档把 RRF 作为较安全的默认选择。(Qdrant)
MySQL 存的是结构化数据:
用户表
订单表
文章表
商品表
它适合:
select * from article where id = 1001;
select * from article where category = 'Java';
select * from order where user_id = 1;
Qdrant 存的是向量和 payload,适合:
找和这段话语义最接近的文章
找和这张图片最相似的图片
找和这个商品描述最接近的商品
找和这个问题最相关的知识库片段
实际项目里通常是:
MySQL 存业务主数据
Qdrant 存向量索引
Redis 做缓存
Elasticsearch 做关键词搜索
不要把所有数据都塞进 Qdrant。结构化、强事务、复杂关系查询,还是 MySQL 这类数据库更合适。
本地体验 Qdrant,最简单的方式是 Docker。
docker pull qdrant/qdrant
启动服务:
docker run -p 6333:6333 -p 6334:6334 \
-v "$(pwd)/qdrant_storage:/qdrant/storage:z" \
qdrant/qdrant
Qdrant 官方快速开始文档中也是先拉取 qdrant/qdrant 镜像,再映射 6333 和 6334 端口;默认配置下数据会存到 ./qdrant_storage 目录。(Qdrant)
启动后常用入口:
REST API: http://localhost:6333
Web UI: http://localhost:6333/dashboard
gRPC: localhost:6334
Qdrant 官方文档也明确列出了这三个默认访问方式:REST API 使用 6333,Web UI 在 6333 的 dashboard 路径,gRPC API 使用 6334。(Qdrant)
为了理解概念,先不用写 Java 代码,直接用 REST API 体验更直观。
curl -X PUT "http://localhost:6333/collections/java_articles" \
-H "Content-Type: application/json" \
-d '{
"vectors": {
"size": 4,
"distance": "Cosine"
}
}'
这里 size=4 只是演示。真实项目中,这个值要和你的 embedding 模型输出维度一致。
比如模型输出 768 维,你就要建 768 维的 collection。
curl -X PUT "http://localhost:6333/collections/java_articles/points" \
-H "Content-Type: application/json" \
-d '{
"points": [
{
"id": 1,
"vector": [0.1, 0.2, 0.3, 0.4],
"payload": {
"title": "Spring Boot DataSource 报错怎么处理",
"category": "Spring Boot",
"url": "/archives/spring-boot-failed-to-configure-datasource"
}
},
{
"id": 2,
"vector": [0.2, 0.1, 0.4, 0.3],
"payload": {
"title": "Maven 国内镜像配置教程",
"category": "Maven",
"url": "/archives/FtMJgXo1"
}
},
{
"id": 3,
"vector": [0.8, 0.1, 0.1, 0.2],
"payload": {
"title": "Windows 安装 JDK 教程",
"category": "JDK",
"url": "/archives/windows-install-jdk-java-home"
}
}
]
}'
官方快速开始里也用 upsert 写入点,并给每个点附带 payload;payload 可以理解为和向量关联的其他数据。(Qdrant)
curl -X POST "http://localhost:6333/collections/java_articles/points/query" \
-H "Content-Type: application/json" \
-d '{
"query": [0.11, 0.21, 0.31, 0.39],
"limit": 2,
"with_payload": true
}'
Qdrant 会返回最相似的点,以及相似度分数。
官方快速开始中也展示了 query_points 的用法:传入 query vector、limit 等参数后,Qdrant 会返回按相似度排序的结果。(Qdrant)
如果只想搜索 Spring Boot 分类:
curl -X POST "http://localhost:6333/collections/java_articles/points/query" \
-H "Content-Type: application/json" \
-d '{
"query": [0.11, 0.21, 0.31, 0.39],
"limit": 3,
"with_payload": true,
"filter": {
"must": [
{
"key": "category",
"match": {
"value": "Spring Boot"
}
}
]
}
}'
Qdrant 官方快速开始里也给出了带 filter 的查询示例,比如通过 payload 中的 city 字段过滤结果;官方还提醒,如果真实数据集上要让过滤搜索更快,建议创建 payload index。(Qdrant)
Qdrant 提供 REST 和 gRPC 接口,也有官方客户端。官方接口文档列出了 Python、JavaScript/TypeScript、Rust、Go、.NET、Java 等官方客户端;如果使用的语言不在列表中,也可以直接用 REST API 或通过 OpenAPI / protobuf 生成客户端。(Qdrant)
对于 Java 项目,有两种常见接入方式:
1. 用官方 Java Client
2. 直接调用 REST API
写稿时 Maven Central 页面显示,io.qdrant:client 的版本为 1.18.3,并标注为 Qdrant vector database 的官方 Java client。发布前你可以再到 Maven Central 查一下最新版本。(Maven Central)
<dependency>
<groupId>io.qdrant</groupId>
<artifactId>client</artifactId>
<version>1.18.3</version>
</dependency>
Qdrant Java Client 的 GitHub README 也说明,它是 Qdrant 的 Java 客户端,并且要求 Java 8 或以上。(GitHub)
官方快速开始里,Java Client 使用 gRPC 接口连接 Qdrant,示例端口是 6334。(Qdrant)
import io.qdrant.client.QdrantClient;
import io.qdrant.client.QdrantGrpcClient;
public class QdrantClientDemo {
public static void main(String[] args) {
QdrantClient client = new QdrantClient(
QdrantGrpcClient.newBuilder("localhost", 6334, false).build()
);
System.out.println("Qdrant client created");
}
}
一个常见 RAG 系统大概是这样:
文档采集
↓
文档清洗
↓
切分 chunk
↓
生成 embedding
↓
写入 Qdrant
↓
用户提问
↓
问题生成 embedding
↓
Qdrant 召回相关 chunk
↓
把 chunk 和问题一起交给大模型
↓
生成回答
在这个流程里,Qdrant 主要负责:
存储 chunk 向量
根据问题向量召回相似 chunk
根据 payload 过滤文档
返回相似度分数和元信息
它不负责:
自己生成 embedding
自己理解业务权限
自己判断答案一定正确
自己替代大模型生成回答
自己替代 MySQL 存业务数据
这点要分清楚。
假设你要给 java.li 做一个站内 AI 问答,可以把文章切成段落,每个段落写入 Qdrant。
一个 point 的 payload 可以这样设计:
{
"articleId": 1001,
"title": "Spring Boot DataSource 报错怎么处理",
"url": "/archives/spring-boot-failed-to-configure-datasource",
"category": "Java技术交流",
"tags": ["Spring Boot", "DataSource", "MySQL"],
"chunkIndex": 3,
"published": true,
"createdAt": "2026-07-23"
}
这样检索时可以做到:
只搜已发布文章
只搜 Java 分类
只搜 Spring Boot 标签
返回文章标题和链接
按时间或热度做额外排序
Payload 不是摆设。一个好的 payload 设计,后面会省很多事。
一开始数据很少时,不建也能跑。
但如果你经常按这些字段过滤:
category
tag
tenantId
userId
published
createdAt
price
location
就应该考虑 payload index。
Qdrant 官方 Indexing 文档解释得很清楚:向量索引用来加速向量搜索,payload index 用来加速过滤;如果搜索时要结合 filter,只靠向量索引是不够的。(Qdrant)
例如给 category 建索引:
curl -X PUT "http://localhost:6333/collections/java_articles/index" \
-H "Content-Type: application/json" \
-d '{
"field_name": "category",
"field_schema": "keyword"
}'
Qdrant 支持给 keyword、integer、float、bool、geo、datetime、text、uuid 等类型建立 payload index;官方文档也提醒,payload index 会占用额外资源,建议只给真正用于过滤的字段建立索引。(Qdrant)
只用 dense vector 有时会漏掉关键词。
比如用户搜:
No compiler is provided in this environment
这是一段非常具体的报错。如果只看语义,它可能召回 Maven、JDK、编译器相关内容,但不一定精准命中这句错误原文。
这时 sparse vector 或关键词检索就有用。
Qdrant 支持 sparse vectors,而且 sparse vectors 可以和 regular dense vectors 一起作为 named vectors 存在于同一个 point 中;官方文档也说明 sparse vectors 适合文本搜索,因为每个词可以表示为一个单独维度。(Qdrant)
所以更稳的检索通常是:
dense vector:理解语义
sparse vector:匹配关键词
rerank:重新排序
filter:做业务过滤
这就是常见的混合检索思路。
文章段落
知识库片段
商品描述
图片 embedding
问答对
代码片段
用户行为向量
简历文本
岗位描述
FAQ 内容
用户账号
订单数据
支付记录
权限配置
库存扣减
强事务数据
复杂关系数据
后台管理表单
这些还是更适合 MySQL、PostgreSQL 这类数据库。
Qdrant 可以存 payload,但不要把它当成传统业务数据库来用。
Collection 建的是:
size = 768
你写入的 vector 却是:
size = 1536
肯定会出问题。
向量维度必须和 collection 配置一致。
不同 embedding 模型生成的向量空间不一样。
不要这样做:
旧文章用模型 A 生成向量
新文章用模型 B 生成向量
然后混在一个 collection 里直接搜
这会让相似度结果变得不可靠。
换模型通常意味着:
重新生成向量
新建 collection
迁移数据
重新评估召回效果
如果只存向量,查出来你可能只知道:
id = 1001
score = 0.86
但不知道它对应什么文章、什么标题、什么链接。
至少要存:
title
url
source
chunkIndex
category
RAG 场景里,文档切片很重要。
太长:
包含太多无关信息,召回不精准
太短:
上下文不足,大模型不好回答
常见做法是:
按段落切
按标题层级切
控制 chunk 长度
保留标题、来源、序号
适当重叠
企业知识库里,不同用户能看的文档不一样。
不要只做向量召回,还要根据 payload 过滤:
tenantId
departmentId
userGroup
visibility
permissionLevel
否则可能出现用户搜到了不该看的内容。
Qdrant 本地 quickstart 默认没有认证和加密,官方文档也明确提醒:默认配置下任何能访问你机器的人都可能访问这个 Qdrant 实例,部署前要仔细阅读安全文档。(Qdrant)
生产环境至少要考虑:
不要直接暴露公网
开启 API Key 或认证机制
限制访问来源
放到内网
做好备份
监控磁盘和内存
合理配置资源
一个比较实际的架构是:
Spring Boot API
↓
文章 / 商品 / 文档服务
↓
Embedding 服务
↓
Qdrant
写入流程:
新增文章
↓
提取标题和正文
↓
切分段落
↓
调用 embedding 模型
↓
写入 Qdrant points
↓
payload 存文章 ID、标题、URL、分类
搜索流程:
用户输入问题
↓
调用 embedding 模型生成 query vector
↓
Qdrant 搜索相似 points
↓
根据 payload 拿到文章信息
↓
返回搜索结果或交给大模型生成回答
Java 项目里可以把 Qdrant 当成一个独立基础设施:
MySQL:存文章主数据
Qdrant:存文章向量
Redis:缓存热门搜索
Spring Boot:提供接口
大模型 API:生成 embedding 和回答
以 java.li 为例,假设你要做 AI 站内搜索,可以这样设计。
java_li_articles
正文 chunk 的 embedding
{
"articleId": 1001,
"title": "Maven 国内镜像配置教程",
"url": "/archives/FtMJgXo1",
"category": "Java技术交流",
"tags": ["Maven", "settings.xml"],
"chunkIndex": 2,
"published": true
}
Maven 下载依赖失败怎么解决?
Maven国内镜像配置教程
Maven下载依赖失败怎么处理
Maven依赖冲突怎么排查
No compiler is provided in this environment
这就比普通站内搜索更聪明。
学习和小项目:
Docker 单机就够了
个人站、内部工具、小型知识库:
单机 + 持久化 + 备份 + 内网访问
中大型项目:
再考虑集群、分片、副本、监控、快照、资源隔离
不要一开始就把架构搞得很复杂。先把 embedding、写入、检索、过滤、权限这些基本流程跑通,再谈集群。
如果你是 Java / Spring Boot 开发者,可以关注 Spring AI 对向量数据库的支持。Spring AI 参考文档中有 Qdrant VectorStore 章节,并介绍可以用 Qdrant 存储文档 embedding 和执行相似度搜索;文档中也提到 Qdrant 使用 HNSW 进行高效 k-NN 搜索,并提供基于 metadata 的过滤能力。(Home)
这意味着你以后可以这样做:
Spring Boot
↓
Spring AI
↓
Embedding Model
↓
Qdrant VectorStore
如果你只是想自己控制细节,也可以直接用 Qdrant Java Client 或 REST API。
开源
本地 Docker 启动简单
REST / gRPC 接口清晰
支持多语言客户端
支持 payload 过滤
适合 RAG 和语义搜索
支持 dense、sparse、multivector 等结构
可以做混合检索
需要额外的 embedding 模型
向量维度和距离算法要选对
换模型需要重新生成向量
payload 设计很重要
生产环境不能裸奔
大数据量下要考虑索引、内存、磁盘、备份
RAG 效果不只取决于向量库,还取决于切片、embedding、rerank 和提示词
一句话:Qdrant 很适合做向量检索,但它不是“AI 应用一键变聪明”的万能按钮。
如果你的需求是:
我要根据语义找相似内容
我要做 RAG 知识库
我要做智能站内搜索
我要做相似商品推荐
我要做相似图片搜索
我要让 AI 应用从文档里找上下文
那 Qdrant 很值得考虑。
如果你的需求是:
我要做订单系统
我要做用户登录
我要做库存扣减
我要做复杂报表
我要做强事务业务
那先用 MySQL / PostgreSQL,把业务主数据做好。Qdrant 可以作为补充,不要把它当主库。
通常不会。你需要先用 embedding 模型把文本转成向量,再写入 Qdrant。Qdrant 的核心职责是存储和检索向量。
不建议。Qdrant 适合向量相似度搜索,MySQL 更适合结构化数据、事务、关系查询和业务主数据存储。
适合。Qdrant 有官方 Java Client,也提供 REST 和 gRPC 接口。Java Client 官方仓库说明它要求 Java 8 或以上。(GitHub)
关键词搜索、日志检索、复杂文本检索,可以优先考虑 Elasticsearch。
语义搜索、RAG、相似推荐,可以考虑 Qdrant。
很多 AI 搜索场景可以混合使用。
看 embedding 模型建议。文本语义搜索常见选择是 Cosine;推荐系统或部分模型可能使用 Dot;数值距离或聚类场景可能用 Euclid。不要随便换距离算法,因为它会影响相似度结果。
不可以。Collection 的向量维度必须和 embedding 模型输出维度一致。
常见原因:
embedding 模型不适合中文或业务领域
文档切片太粗或太碎
没有做关键词混合检索
没有做 rerank
payload 过滤条件不合理
query 改写不好
文档质量本身不高
向量数据库只是其中一环,不要把所有效果问题都归因到 Qdrant。
Qdrant 可以简单理解成:
一个专门做向量相似度搜索的数据库。
它适合:
RAG 知识库
语义搜索
相似推荐
图片搜索
AI Agent 记忆
站内智能搜索
使用时要记住几个关键点:
先用 embedding 模型生成向量
再把向量和 payload 写入 Qdrant
Collection 决定向量维度和距离算法
Point 是一条向量数据
Payload 用来存元信息和过滤条件
搜索时用 query vector 找 Top-K 相似结果
真实业务里通常要结合 filter、payload index、rerank 和权限控制
对 Java 开发者来说,Qdrant 值得关注。尤其是你已经有 Spring Boot 项目、文档系统、站内搜索或知识库需求时,它可以很自然地接到现有后端服务里。
Spring Boot 接收 JSON 参数:
JSON 转 Java 实体类:
Spring Boot 与 JDK 兼容:
Maven 依赖冲突:
Java 学习资源导航:
Java 开发环境配置专题:
2026-07-29:
- 创建 Qdrant 向量数据库入门文章
- 增加向量、Collection、Point、Payload、Distance、Filter 等概念说明
- 增加 Docker 本地启动示例
- 增加 REST API 创建 Collection、写入 Point、查询和过滤示例
- 增加 Java Client 接入说明
- 增加 RAG、语义搜索、相似推荐、站内搜索等场景说明
- 增加 Qdrant 与 MySQL、Elasticsearch 的区别
此内容由惯性聚合(RSS阅读器)自动聚合整理,仅供阅读参考。 原文来自 — 版权归原作者所有。