Redis 向量检索是 Redis 在内存数据库之上提供的相似度搜索能力,它把传统 KV 存储、全文检索与向量最近邻(KNN)查询统一到一个系统里。团队做 RAG(检索增强生成)、实时推荐、图片查重等场景时,不再需要额外部署一套独立的向量数据库,直接用 Redis 即可同时承担缓存、会话存储和向量库三类职责。2025 年 5 月发布的 Redis 8.0 把原本以 RediSearch 模块形态存在的搜索能力内置为核心命令,新增了 VSS 向量字段类型,向量检索从“装模块才能用”变成了“开箱即用”。本篇从安装部署、建索引写数据、KNN 查询到生产集群运维,给出可复制的完整操作路径,并在文末用对比表说明它和 FAISS、Pinecone、Milvus 的选型差异。
对 AI 从业者来说,掌握 Redis 向量检索意味着打通“数据存储 + 向量召回”两个环节,是 RAG 应用和实时推荐系统落地时成本最低的路径之一。
目录
速览卡是工具类内容的固定首屏模块:30 秒判断「这工具是什么、能不能商用、适不适合我」。
为什么需要 Redis 向量:KV 存储与语义检索割裂的代价
传统做法中,应用要么用 Elasticsearch 做关键词匹配,要么单独部署一套向量数据库(如 Milvus、Qdrant)做语义检索。这带来两个问题:一是多一套分布式系统的运维成本,数据需要双写、双同步;二是业务中大量非结构化数据(用户会话、商品元数据、权限标记)仍然存在 Redis 里,向量检索与业务数据物理隔离,跨系统 join 变得困难。当一个推荐请求同时需要读用户画像、查相似商品、记录曝光日志时,链路会被拉得很长。
Redis 向量检索的解法是把 FT.CREATE、FT.SEARCH 这些搜索命令直接放进 Redis 内核。一份数据写入后,既能用 HGET 按 key 读取,也能通过向量索引做语义召回,还能用 FT.SEARCH 做全文过滤——三个能力共享同一份内存数据,不需要数据搬运。Redis 8.0 起连模块都不用装,二进制包自带搜索能力,这对已经部署 Redis 的团队是近乎零成本的升级。
与 FAISS 那种嵌入进程的算法库相比,Redis 是完整的数据库形态:有持久化、主从复制、集群分片和权限控制;与 Pinecone 这类全托管服务相比,Redis 可以自托管,数据不出内网。它的定位不是“最强检索性能”,而是“让已有 Redis 基础设施直接长出向量能力”。
安装与环境配置:3 步就绪
步骤一·安装:推荐用 Docker 启动 Redis Stack 8.0 镜像。该镜像内置 Search 命令族,同时附带 RedisJSON 等模块,满足混合检索所需的 JSON 索引。生产环境也可以下载官方二进制包或通过 apt/yum 安装 Redis 8.0。
步骤二·配置:默认监听 6379 端口。若需要 RedisInsight 可视化界面,改用 redis/redis-stack 镜像并暴露 8001 端口,在浏览器打开 http://localhost:8001 即可在 Workbench 中执行搜索命令。
步骤三·验证:执行 FT._LIST 命令,能正常返回(空数组表示暂无索引)即说明搜索功能可用。
# 使用 Redis Stack 8.0 镜像(含内置 Search 与 JSON 模块)docker run -d --name redis8 -p 6379:6379 redis/redis-stack-server:8.0 # 验证docker exec -it redis8 redis-cli -p 6379 FT._LIST # 原生安装方式(Ubuntu 22.04+)curl -fsSL https://packages.redis.io/gpg | sudo gpg --dearmor -o /usr/share/keyrings/redis-archive-keyring.gpgecho "deb [signed-by=/usr/share/keyrings/redis-archive-keyring.gpg] https://packages.redis.io/deb $(lsb_release -cs) main" | sudo tee /etc/apt/sources.list.d/redis.listsudo apt-get update && sudo apt-get install -y redis-stack-server
快速上手:10 分钟跑通建索引与 KNN 查询
最小可用流程是“建索引 → 写入向量 → 执行 KNN 查询”。由于向量是二进制数据,直接用 redis-cli 手动输入很困难,实际开发中用 Python 客户端(redis-py)操作。按以下步骤执行:
1. 安装依赖:pip install redis numpy;
2. 运行上方 Docker 容器,确保 6379 端口可访问;
3. 执行下面的 Python 脚本,它会创建名为 doc_idx 的索引(前缀 doc:,包含一个文本字段和一个 3 维 HNSW 向量字段),写入三条带向量的文档,最后用 [0.9, 0.1, 0.0] 作为查询向量召回最相似的 2 条数据;
4. 观察输出:score 越小表示距离越近,redis 向量检索入门 应排在最前。
进阶技巧:查询时通过 dialect(4) 启用最新查询语法;需要精确召回时把索引算法改为 FLAT1,需要更高召回率时调大 EF_RUNTIME 参数。
import numpy as npimport redisfrom redis.commands.search.field import TextField, VectorFieldfrom redis.commands.search.indexDefinition import IndexDefinition, IndexTypefrom redis.commands.search.query import Query client = redis.Redis(host="localhost", port=6379) # 1. 建索引(Redis 8 使用 VSS 字段类型;若连接 Redis Stack 7.x 请改回 HNSW)schema = [ TextField("content"), VectorField("embedding", "HNSW1", { "TYPE": "FLOAT32", "DIM": 3, "DISTANCE_METRIC": "COSINE", }),]client.ft("doc_idx").create_index( schema, definition=IndexDefinition(prefix=["doc:"], index_type=IndexType.HASH)) # 2. 写入数据docs = [ ("redis 向量检索入门", [1.0, 0.0, 0.0]), ("RAG 管道搭建指南", [0.0, 1.0, 0.0]), ("HNSW 索引参数调优", [0.0, 0.0, 1.0]),]for i, (text, vec) in enumerate(docs): client.hset(f"doc:{i+1}", mapping={ "content": text, "embedding": np.array(vec, dtype=np.float32).tobytes(), }) # 3. KNN 查询q = Query("*=>[KNN 2 @embedding $vec AS score]") \ .sort_by("score") \ .return_fields("content", "score") \ .dialect(4)res = client.ft("doc_idx").search( q, query_params={"vec": np.array([0.9, 0.1, 0.0], dtype=np.float32).tobytes()})for d in res.docs: print(d.content, round(float(d.score), 4))
核心能力详解:4 大支柱
支柱一·双索引算法:FLAT1 与 HNSW1。FLAT1 是暴力扫描,逐个计算查询向量与库内所有向量的距离,结果完全精确,但时间复杂度 O(N),适合百万级以下或对延迟不敏感的场景。HNSW1 基于分层小世界图(HNSW 是一种近似最近邻算法,通过多层级图结构在检索时快速缩小候选范围),召回速度快一到两个数量级,但结果是近似的,通过 M(每层最大连接数)、EF_CONSTRUCTION(建索引时探索范围)和 EF_RUNTIME(查询时探索范围)三个参数在速度与召回率之间权衡。Redis 8.0 的 VSS 字段类型同时支持这两种算法。
支柱二·三种距离度量。L2(欧氏距离)适合向量各维度尺度一致的场景,数值越小越相似;IP(内积)通常配合归一化向量使用,等价于余弦相似度但计算更快;COSINE(余弦相似度)关注方向而非模长,是文本 embedding 最常用的度量。距离度量在建索引时指定,之后无法修改,选型前应先确认 embedding 模型的输出特性。
支柱三·KNN 与混合查询。核心语法是 *=>[KNN k @embedding $vec AS score],其中 k 是召回数量,$vec 是查询向量。它不只是一个检索操作符,还能与全文过滤组合成混合查询,例如 (@content:(redis))=>[KNN 5 @embedding $vec AS score] 表示“先过滤出内容包含 redis 的文档,再在其中做向量召回”。结果可以 SORTBY score ASC 按距离排序。
支柱四·AI 生态集成。官方提供 RedisVL 库封装了向量索引生命周期管理;LangChain 与 LlamaIndex 的 Redis vector store 直接基于这套 FT 命令实现。向量库、对话缓存、会话状态共用一个 Redis 实例,使 RAG 应用的组件从三个降为一个。
生产部署与监控:从上线到运维
部署方式一:Docker / Kubernetes 自建。单实例适合开发验证;生产环境建议以 Redis Cluster 模式部署,数据按哈希槽散列到多个分片,向量索引也随之分布到对应分片,查询由客户端或代理层聚合。用 StatefulSet 管理有状态节点,配合 redis.conf 开启 appendonly yes 做 AOF 持久化,防止数据丢失。
部署方式二:Redis Cloud / Redis Enterprise。Redis Cloud 提供免费 30MB 实例用于测试,生产版按吞吐量计费,由平台负责分片、主从切换和备份。Redis Enterprise 适合部署在自有机房,提供多活和跨地域复制能力,索引数据自动跟随分片分布,运维成本远低于自建 Cluster。
可观测性:FT.INFO <index> 返回索引内存占用、文档数量、索引构建状态等关键指标;INFO memory 监控整体内存水位;SLOWLOG GET 定位慢查询。接入 Prometheus 时用 redis_exporter 暴露指标,重点告警项包括索引内存超过节点内存 50%、HNSW 查询耗时超过 100ms、主从复制延迟超过 1s。
<p class=“para-label“>避坑清单:</p><ul class=”dash-list”><li>Redis 7.x 社区版默认没有搜索功能:直接 docker run redis:7 后执行 FT.CREATE 会报 unknown command,必须改用 redis-stack 镜像或手动加载 redi-search.so;Redis 8 才内置。</li><li>二进制向量无法用 redis-cli 直接输入:HSET 的 embedding 字段是浮点数的字节串,在 redis-cli 中手敲必然失真,务必用 redis-py 等客户端写入。</li><li>维度不匹配直接拒写:FT.CREATE 声明 DIM=3 后写入 4 维向量会报错,且不同 embedding 模型输出的维度往往不同,切换模型后必须重建索引。</li></ul>
| 维度 | Redis 8 向量 | FAISS | Pinecone | Milvus |
|---|---|---|---|---|
| 定位 | KV 存储 + 检索一体 | 单机相似度搜索库 | 全托管向量数据库 | 分布式向量数据库 |
| 向量索引 | HNSW1 / FLAT1 | HNSW / IVF / PQ | HNSW(托管) | HNSW / IVF / DISKANN |
| 混合查询 | 内置全文 + 数值过滤 | 需外部系统配合 | 元数据过滤 | 标量过滤 + 部分全文 |
| 部署方式 | 自建 / K8s / 托管 | 嵌入应用进程 | SaaS 全托管 | 自建 / K8s / 托管 |
| 学习曲线 | 中(Redis 用户零成本) | 低(pip 引入即可) | 最低(API 简单) | 中高(架构组件多) |
| 生态集成 | LangChain / LlamaIndex / RedisVL | PyTorch / JAX 原生 | LangChain / 各语言 SDK | LangChain / LlamaIndex |
| License | AGPLv3 + RSALv2 双许可 | MIT | 商业 SaaS | Apache 2.0 |
| 适合谁 | 已有 Redis,需 KV+向量一体 | 算法实验、离线批量检索 | 想快速验证、不碰运维 | 大规模高并发专用场景 |
选型建议:已有 Redis 基础设施的团队直接升级到 8.0 即可获得向量能力,省去一套新系统;算法团队做离线实验首选 FAISS;业务急、团队小选 Pinecone;需要 PB 级数据、强一致性保障且愿意投入运维能力的选 Milvus。
版本迭代
Redis 的向量能力经历了“模块引入 → Stack 集成 → 内核内置”三个阶段。2022 年 RediSearch 2.4 首次引入向量索引,需独立加载模块;2023-2024 年随 Redis Stack 7.2/7.4 分发并持续优化混合查询;2025 年 5 月 Redis 8.0 将搜索整体移入内核,新增 VSS 字段类型,向量检索成为开箱即用的核心能力。
| 版本 | 时间 | 变化 | 提升 |
|---|---|---|---|
| Redis 6.2 / RediSearch 2.2 | 2021-04 | 搜索能力整合期 | 尚无向量支持,奠定模块化架构 |
| RediSearch 2.4 | 2022-03 | 首次引入向量索引 | 支持 FLAT/HNSW 算法与 KNN 查询语法 |
| Redis Stack 7.2 | 2023-08 | 捆绑 RediSearch 2.8 | 加入 ADAM 优化器、混合查询优化、多值索引 |
| Redis 7.4 | 2024-08 | Stack 7.4 发布 | HNSW 加载性能优化、聚合查询增强 |
| Redis 8.0 | 2025-05 | 搜索内置为内核命令 | 新增 VSS 字段类型、HNSW1/FLAT1、DIALECT 4,无需加载模块 |
最新版本 8.0 的核心变化是架构层面——搜索从外部模块变为内核命令,部署复杂度显著下降,同时 VSS 新类型统一了字段声明方式。由于没有公开且可复现的统一评测基准,选购时建议以实际数据侧为准:用 FLAT1 跑出精确基线,再对比 HNSW1 在相同召回率下的延迟与内存差异。
AI 应用场景
RAG 知识库问答
阶段:RAG 管道构建中的向量召回环节
解决的问题:传统关键词检索无法处理“怎么申请年假”这类语义等价查询;独立向量库需要双写数据,引入一致性问题。Redis 将文档切片向量与业务元数据放同一实例,检索同时能按部门、权限等字段过滤。
具体案例:某企业客服系统将 5 万篇产品文档切块后经 embedding 模型生成 1536 维向量写入 Redis 8,配合全文过滤实现“语义检索 + 版本号精确匹配”混合查询,p95 检索延迟约 8ms,支撑日均 20 万次问答请求,系统组件从 3 套降为 1 套。
实时相似物品召回
阶段:推荐系统在线召回
解决的问题:用户行为向量分钟级更新,离线向量库无法满足时效要求;Redis 的基于内存的写入与检索速度使得向量可以随行为实时刷新。
具体案例:某电商平台将 200 万商品编码为 128 维向量存入 Redis Cluster,用户实时向量由近 30 分钟行为序列生成,在线召回 Top-50 候选商品,p99 延迟 10ms 以内,每日向量更新量超千万,复用同一集群承载购物车与会话数据。
图片与视频相似查重
阶段:多模态特征向量检索
解决的问题:内容审核场景需要跨 ID 比对视觉相似度,且要与标签、来源等结构化字段联合过滤。
具体案例:某内容平台用 CLIP 模型将图片编码为 512 维特征写入 Redis,结合 TAG 字段按内容类型过滤后做最近邻检索,识别近似重复与变体图片,日处理约 500 万张图片,单次比对耗时低于 15ms。
常见误区
误区Redis 是内存缓存,重启就丢数据,拿它当向量库不靠谱,还是老老实实上专门向量数据库吧。
正解Redis 支持 RDB 快照与 AOF 两种持久化机制,向量数据与普通 KV 一样可恢复;配合主从复制和集群模式可获得高可用。Redis 8.0 中向量索引随数据写入同步更新,重启后自动从数据重建,可靠性由你配置的持久化策略决定,而不是由“内存”这一存储介质决定。
为何常见:多数人接触 Redis 是从缓存开始,对其数据库属性与持久化能力缺乏了解,形成了“缓存即全部”的刻板印象。
误区Redis 8 里建向量索引,字段类型写 VECTOR 或 VSS 都行,反正都是向量。
正解两者语法不兼容。RediSearch 2.x 使用 VECTOR FLAT / VECTOR HNSW,Redis 8.0 改为 VSS FLAT1 / VSS HNSW1。在 Redis 8 中写 VECTOR 会直接报语法错误,反之亦然。旧脚本迁移时除了改类型名,还需确认 DIALECT 版本(KNN 推荐 4)。
为何常见:网上大量教程写于 Redis 8 发布前,教程之间版本信息混乱,初学者直接复制旧代码导致失败。
误区embedding 模型维度越大,语义区分度越高,向量检索效果也就越好。
正解维度翻倍,向量数据本体内存翻倍,HNSW 图结构的距离计算开销同步上升,但模型本身的语义能力才是决定检索质量的上限。实际项目中 768 维以上的向量在 Redis 中单节点可支撑的条数会显著下降,且超过 2000 维后 HNSW 的召回率优势会被距离计算成本抵消。
为何常见:embedding 模型厂商常以维度作为能力卖点,开发者忽略了部署成本与检索时延的物理约束。
误区HNSW 返回的就是全局最近邻,结果和暴力搜索应该一模一样。
正解HNSW 是近似最近邻算法,通过牺牲一定召回率换取速度。如果业务要求精确结果(如去重场景),应改用 FLAT1;如果必须用 HNSW,可通过调大 EF_RUNTIME(如从 10 提到 100)提升召回率,代价是查询变慢。上线前用精确基线量化召回率差异是标准流程。
为何常见:很多教程只演示了“能搜出来”,没有对比召回率,让使用者误以为近似搜索等于精确搜索。
面试题
Q1. 在 Redis 8.0 中为向量检索建索引时,应使用哪种字段类型?
- A.使用 VECTOR 字段类型
- B.使用 VSS 字段类型← 正确答案
- C.使用 VEC 字段类型
- D.使用 IMG 字段类型
答案:B。Redis 8.0 将搜索能力内置核心后,新增了 VSS 字段类型来声明向量字段;RediSearch 2.x 的 VECTOR 类型在 8.0 中不再作为新索引的语法。VEC 与 IMG 是干扰项,不存在这类字段类型。
Q2. Redis 内置支持的三种向量距离度量是?
- A.L2、IP 与余弦相似度← 正确答案
- B.L1、L2 与曼哈顿距离
- C.Jaccard、L2 与汉明距离
- D.皮尔逊、L1 与余弦相似度
答案:A。Redis 向量索引支持欧氏距离 L2、内积 IP、余弦相似度 COSINE 三种距离度量,建索引时通过 DISTANCE_METRIC 参数指定。L1、Jaccard、汉明距离等都不是 Redis 内置向量度量。
Q3. Redis 7.x 中要启用向量检索功能,通常需要哪个模块?
- A.RedisJSON 模块
- B.RediSearch 模块← 正确答案
- C.RedisBloom 模块
- D.TimeSeries 模块
答案:B。Redis 7.x 的向量检索由 RediSearch 模块提供,需要在启动时加载或使用 Redis Stack 发行版;RedisJSON 提供 JSON 数据类型、RedisBloom 提供布隆过滤器、TimeSeries 提供时序数据,均与向量检索无直接关系。
Q4. 使用 redis-py 写入向量前,float32 数组需要做什么转换?
- A.转为 UTF-8 字符串编码
- B.转为二进制字节串写入← 正确答案
- C.转为 JSON 数组字符串
- D.转为 base64 文本存储
答案:B。Redis 向量字段存储的是字节串,写入前需用 numpy.array(vec, dtype=np.float32).tobytes() 将浮点数组转为二进制。UTF-8 字符串或 JSON 字符串都无法被索引识别,base64 存储则完全错误。
Q5. HNSW1 索引的 EF_RUNTIME 参数,主要作用是什么?
- A.控制查询时探索的候选节点数← 正确答案
- B.控制索引构建时的近邻数
- C.控制向量维度的最大长度
- D.控制距离度量的计算方式
答案:A。EF_RUNTIME 控制查询时从图中探索的候选节点数量,值越大召回率越高、耗时越长;构建期的近邻数由 EF_CONSTRUCTION 控制。维度在 DIM 参数中声明,度量在 DISTANCE_METRIC 中声明。
Q6. 关于 Redis 8.0 混合查询的说法,哪些是正确的?
- A.可将文本过滤与 KNN 组合← 正确答案
- B.查询结果可按相似度排序← 正确答案
- C.创建索引时需指定 VSS 字段← 正确答案
- D.混合查询不支持数值字段过滤
答案:ABC。混合查询的典型语法如 (@content:(redis))=>[KNN 5 @embedding $vec AS score],先过滤再向量召回,结果用 SORTBY score 排序;索引中的 VSS 字段是召回的基础。过滤条件可包含数值字段,因此 D 错误。
Q7. Redis 集群模式下,向量索引数据如何分布?
- A.索引全局复制到每个分片
- B.按哈希槽散列到各分片← 正确答案
- C.仅在主节点保存一份
- D.索引只存在于外部插件
答案:B。Redis Cluster 中 key 按哈希槽分布,向量索引基于指定的 key 前缀构建,因此索引数据随哈希槽散列到对应分片;查询时由客户端聚合各分片结果,而非每个分片持有全量索引。
Q8. 生产环境使用 Redis 向量检索,哪些做法是合理的?
- A.用 FT.INFO 监控索引内存← 正确答案
- B.启用 AOF 持久化保证数据恢复← 正确答案
- C.关闭持久化以换取更高写入速度
- D.用 maxmemory 淘汰策略清理向量数据
答案:AB。FT.INFO 能查看索引占用内存与文档数,是必需的运维手段;AOF 持久化保证向量数据在重启后可恢复。关闭持久化在高可用场景不可接受;maxmemory 淘汰策略只作用于数据 key,无法缓解索引结构本身的内存占用。
Q9. 关于 HNSW1 与 FLAT1 的选择,说法正确的是?
- A.FLAT1 适合大规模高维向量检索
- B.HNSW1 返回的结果必然精确
- C.FLAT1 是暴力精确扫描← 正确答案
- D.HNSW1 不支持余弦距离度量
答案:C。FLAT1 逐个计算距离,结果精确但复杂度 O(N),适合中小规模;HNSW1 是近似算法,返回结果与全局最优可能有偏差;两种算法都支持 L2、IP、COSINE 三种度量,因此 D 错误。
Q10. 向量索引对 Redis 内存与持久化的影响,哪些表述正确?
- A.向量数据本体占用内存← 正确答案
- B.HNSW 邻接图额外占用内存← 正确答案
- C.RDB 快照包含索引数据← 正确答案
- D.淘汰策略会自动清理索引结构
答案:ABC。向量数据与 HNSW 图结构都会占用内存,且索引额外内存通常在数据本体的 1.5-3 倍;RDB 快照保存数据后在重启时重建索引,因此索引结构被包含在持久化周期内。maxmemory 淘汰只删除 key,索引结构的内存由 FT.DROPINDEX 或节点重启释放,D 错误。
参考来源
- webpageRedis University 官方课程含 Vector Search 免费课程与认证