文章目录
- 前言
- [一、Redis 为什么能做向量数据库](#一、Redis 为什么能做向量数据库)
- 二、核心概念：向量索引怎么建
-
- 关键配置项
- [FLAT 还是 HNSW](#FLAT 还是 HNSW)
- [三、Spring AI 集成实战](#三、Spring AI 集成实战)
-
- [1. 依赖与配置](#1. 依赖与配置)
- [2. 基本用法](#2. 基本用法)
- [3. 元数据过滤](#3. 元数据过滤)
- [4. 距离度量与 HNSW 调优](#4. 距离度量与 HNSW 调优)
- [四、Redis 向量存储的典型适用场景](#四、Redis 向量存储的典型适用场景)
- 五、小结
前言
在 RAG 应用开发中，向量数据库的选择往往是最让人纠结的环节。Milvus、Pinecone、Qdrant 各有拥趸，但如果你已经有一套 Redis 基础设施，或者希望减少技术栈的维护成本，Redis 完全有能力胜任向量数据库的角色。
本文从 Redis 向量能力的基本原理讲起，最后落到 Spring AI 的实战集成。
一、Redis 为什么能做向量数据库
Redis 本质是一个内存数据结构存储，而向量检索恰好需要一个能高效组织高维数据、支持相似度计算、并且响应足够快的引擎。Redis 通过 Redis Query Engine（基于 RediSearch 模块）扩展了核心能力，使其支持：
- 在 Hash 或 JSON 文档中存储向量和元数据
- 向量索引：支持 FLAT（暴力搜索）和 HNSW（近似最近邻）两种算法
- 相似度搜索：支持 COSINE、L2、IP 三种距离度量
- 混合查询：向量相似度 + 全文检索 + 数值过滤 + 标签过滤的组合
Redis 本身是内存数据库，向量检索的延迟天然就在毫秒级。对于大多数 RAG 场景------知识库规模在百万级以内、对检索延迟敏感------Redis 是一个被低估的选择。
需要说明的是，基础的 Redis OSS 版本并不包含向量能力 ，你需要使用 Redis Stack 或 Redis Cloud。Redis 8 还引入了全新的 vector sets 数据类型，提供更轻量的向量相似性 API，但该功能目前仍处于 Beta 阶段。
二、核心概念：向量索引怎么建
要让 Redis 理解你的向量，需要先定义一个索引结构（Schema）。这份蓝图告诉 Redis：向量存在哪个字段、维度是多少、用什么距离度量、用什么算法建索引。
关键配置项
| 配置项 | 说明 | 常用值 |
|---|---|---|
| 字段名 | 向量在 Hash 中存储的字段名 | 如 embedding |
| 维度 | 必须与 Embedding 模型输出一致 | 如 1536 |
| 数据类型 | 决定内存占用 | FLOAT32 是标准 |
| 距离度量 | 计算相似度的方式 | COSINE 最适合文本 |
| 算法 | 索引组织方式 | HNSW 或 FLAT |
FLAT 还是 HNSW
这是两个最核心的算法选择：
- FLAT（暴力搜索） ：将查询向量与索引中每一个 向量逐一比较。结果完全精确 ，但数据量增长后查询会变慢。适合小数据集（小于 10,000 个向量）或对精确度要求极高的场景。
- HNSW（分层可导航小世界图） ：构建图结构，让 Redis 智能地在向量空间中导航，跳过无关区域 ，在数百万向量中也能毫秒级找到近似最近邻。以 95-99% 的准确率换取巨大的性能提升，大多数生产 AI 系统都选择 HNSW。
Spring AI 的 RedisVectorStore 默认使用 HNSW，但也支持切换为 FLAT。
三、Spring AI 集成实战
1. 依赖与配置
xml
<dependency>
<groupId>org.springframework.ai</groupId>
<artifactId>spring-ai-starter-vector-store-redis</artifactId>
</dependency>
yaml
spring:
data:
redis:
host: localhost
port: 6379
ai:
vectorstore:
redis:
initialize-schema: true # 自动创建索引
index-name: my-index # 索引名称
prefix: "doc:" # 键前缀这里有几个关键点：
initialize-schema: true会自动创建所需的索引结构，省去手动建索引的步骤。注意在 Spring AI 早期版本中这是默认行为，但现在需要显式开启。prefix决定了哪些键会被索引监控。比如设为doc:，那么所有以doc:开头的 Hash 都会被纳入向量索引。- 你需要一个配置好的
EmbeddingModelBean，否则向量存储无法工作。
2. 基本用法
Spring AI 的 VectorStore 接口提供了统一的操作入口：
java
@Autowired
VectorStore vectorStore;
// 添加文档（自动生成向量并存储）
List<Document> documents = List.of(
new Document("Spring AI 是 Spring 生态的 AI 应用框架",
Map.of("category", "framework")),
new Document("Redis 是一个内存数据结构存储",
Map.of("category", "database"))
);
vectorStore.add(documents);
// 相似度搜索
List<Document> results = vectorStore.similaritySearch(
SearchRequest.builder()
.query("什么是 Spring AI")
.topK(5)
.build()
);add() 方法内部会自动调用 EmbeddingModel 将文本转为向量，并存入 Redis Hash 中。similaritySearch() 则会将查询文本同样转为向量，然后执行 KNN 搜索。
3. 元数据过滤
这是 Redis 作为向量数据库的一个实用优势：你可以在向量相似度搜索的同时，按元数据字段做精确过滤。
java
List<Document> results = vectorStore.similaritySearch(
SearchRequest.builder()
.query("Redis 向量搜索")
.topK(5)
.filterExpression("category == 'database'") // 元数据过滤
.build()
);这背后的原理是 Redis 的混合查询能力：先通过标签/数值字段缩小候选集，再在候选集内做向量相似度计算。对于需要"在某个部门/某个年份/某个类别内找相似内容"的场景，这个能力非常实用。
4. 距离度量与 HNSW 调优
如果你需要自定义距离度量或调优 HNSW 参数，可以通过 Builder 配置：
java
RedisVectorStore vectorStore = RedisVectorStore.builder(jedisClient, embeddingModel)
.distanceMetric(RedisVectorStore.DistanceMetric.COSINE) // 默认 COSINE
.hnswM(32) // 每节点最大连接数，默认 16
.hnswEfConstruction(100) // 建索引时的候选列表大小，默认 200
.hnswEfRuntime(50) // 搜索时的候选列表大小，默认 10
.build();参数调优的直觉：
M越大，召回率越高，但内存占用和建索引时间也越大。典型范围 12-48。EF_CONSTRUCTION越大，索引质量越高，但建索引越慢。典型范围 100-500。EF_RUNTIME越大，搜索精度越高，但延迟越大。典型范围 10-100。
四、Redis 向量存储的典型适用场景
RAG 检索层：把 Redis 同时用作向量存储和语义缓存。用户提问先查缓存，语义相似的问题直接返回已有答案，能省下大量 LLM 调用成本。
对话记忆持久化 ：Redis 的 MessageHistory 可以将对话上下文存为向量，按相关性检索历史消息，而不是简单截断最近 N 轮。
语义路由：根据用户意图的向量相似度，将请求路由到不同的下游模型或服务。
五、小结
Redis 做向量数据库的核心优势在于一个组件解决多个问题：向量存储、元数据过滤、语义缓存、对话历史，全部可以放在同一个 Redis 实例里。对于中小规模的 RAG 应用，这能显著降低架构复杂度。
代价则是：Redis 的向量能力依赖 Redis Stack/Redis Cloud，基础 OSS 版本无法使用；HNSW 索引的内存占用需要提前规划；超大规模数据集（千万级以上）可能需要考虑专门的分布式向量数据库。
选型没有绝对的对错，只有场景是否匹配。如果你已经在用 Redis 做缓存，不妨把向量检索也放进去试试。
如需深入了解Agent核心架构设计、工具调用机制、记忆与上下文工程、多智能体协作模式、规划与推理策略、LangGraph状态图原理、中间件扩展体系、生产级Agent落地实践等内容，请持续关注本专栏《Agent智能体开发从入门到精通》系列文章。