提到 Redis，大多数开发者的第一反应是缓存、分布式锁、或者消息队列。但你可能不知道是，这个陪伴了我们很多年的老朋友，如今已经在向量数据库的赛道上一路狂奔------不仅跑得快，还跑得相当稳。
什么是向量检索？
传统搜索依托字面匹配逻辑：当输入"苹果"进行检索时，系统仅能定位到包含"苹果"二字的文档，若文本涉及"iPhone"或泛指水果，便无法被检索到。与之不同，向量检索采用语义匹配机制，它能够洞察"苹果"与"iPhone"在特定语境下的关联性，即便文本中未出现"苹果"一词，也能精准挖掘出相关内容。
计算机无法直接理解人类的语言或图像，其运算基础仅为数字。因此，向量检索的首要环节，便是将现实世界的事物转化为一组数字序列，即向量。例如，模型会将"狗"转化为由数百个小数构成的向量[0.5, 0.8, -0.2, ...]，将"猫"转化为[0.6, 0.7, -0.1, ...]。
在计算机的视角里，每一个向量都是高维空间中的一个坐标点。语义相似的内容，点与点之间就离得近；语义无关的，就离得远。向量检索要做的，就是在这个庞大的坐标地图上，快速找出离目标点最近的几个邻居。
当用户检索"小狗"时，系统会先将"小狗"转化为向量，随后在庞大的"坐标地图"中，迅速定位出与"小狗"向量点距离最近的点，如"幼犬""金毛"的向量点，并将距离最近的检索结果推送给用户。这一技术是推荐系统实现相似商品匹配、搜索引擎达成以图搜图功能的核心支撑，本质上，向量检索是将业务需求转化为数学问题，借助数学方法实现高效求解。
Redis的向量检索
Redis 的向量检索能力主要有两条技术路线，如果追求功能成熟、需要与现有 Hash/JSON 数据深度整合，选 Redis Search；如果追求极简、希望开箱即用并且用的是 Redis 8.0+，Vector Sets 是更清爽的选择。
Redis Search
通过 Redis Query Engine（前身是 RediSearch 模块），你可以在 Hash 或 JSON 文档中存储向量字段，建立向量索引，然后执行 KNN（K近邻）或向量范围查询，支持 FLAT（暴力搜索）和 HNSW（近似搜索）两种索引算法。
Vector Sets（8.0 原生方案）
这是 Redis 8.0 推出的重磅新特性------向量成为 Redis 原生支持的数据类型，Vector Set 类似于有序集合（Sorted Set），但每个元素关联的不再是一个分数（score），而是一个高维向量。
使用起来也极其简单：
- VADD：往向量集合里插入元素和它的向量
- VSIM：根据向量相似度查找最匹配的元素
不需要额外加载模块，不需要维护复杂的索引，开箱即用，每个 Vector Set 内部自动构建 HNSW 索引。
Redis优点：简单易用
延迟低到令人发指
速度是 Redis 的传统强项，向量检索也不例外。向量检索最怕慢，尤其是 RAG 应用里，用户问一个问题，背后可能要查好几次向量库，每次延迟累加起来体验就崩了。
Relevance AI 公司原本使用自建的向量数据库，AI 代理的响应延迟高达 2 秒。迁移到 Redis 后，搜索时间直接降到 10 毫秒，提速 99.5%
基准测试更夸张：单客户端场景下，Redis 的向量查询比 OpenSearch 快 18 倍；多客户端并发时，每秒查询数（QPS）高出 52 倍。在大规模场景下，Redis 8 已经验证了在 10 亿个 768 维向量上进行高精度实时搜索的能力。
简单到"开箱即用"
如果你已经在用 Redis 8.0 以上版本，向量检索是零额外成本的------不需要装模块，不需要配置复杂索引，几条命令就能上手：
- VADD：把向量存进去
- VSIM：按相似度搜索
这和用惯了 Redis 的开发者认知完全一致，学习曲线几乎为零。
不只是向量搜索：混合查询才是杀手锏
Redis 的独特优势在于------它本来就是个全功能数据库。你可以把向量搜索和全文检索、标签过滤、数值范围查询、地理空间查询组合在一起。比如：找出和这张图片语义相似的商品，同时价格低于 100 元、库存大于 0、且距离用户 5 公里以内------这种混合查询在 Redis 里是一条命令的事。
Redis 8.4 更进一步，推出了 FT.HYBRID 命令，支持全文检索与向量检索的深度融合，可以用 RRF 或线性加权两种方式融合两种检索的得分
写入即查，实时性极强
Redis 的向量索引是实时增量更新的------你写入一条带向量的数据，毫秒级内它就可以被检索到。
很多向量数据库需要等索引构建完成（秒级甚至分钟级）才能查询到新数据。如果你的场景是动态内容（如实时更新的推荐系统），Redis 的实时性非常有价值。
再谈缺点：Redis 的快，是有代价的
内存成本，一座绕不过的大山
这是 Redis 向量检索最核心的短板。所有向量数据必须常驻内存。768 维的 float32 向量，一条就要占约 3KB。1000 万条就是 30GB 内存，这还不算 HNSW 索引的额外开销（通常是向量本身的 2-3 倍）。
千万级是 Redis 向量检索的舒适区，亿级以上就要掂量掂量了。 实践中，Redis 向量规模的上限大约在 5000 万 左右，超出后成本将急剧上升。
可以开启 int8 量化省内存，但代价是召回率会下降几个百分点------省钱的代价是牺牲精度，这笔账得提前算清楚。
召回率不是最顶尖的
追求极致低延迟，有时要付出召回率的代价。在一些公开对比中，Redis 的召回率大约在 92% 左右，而专用向量数据库（如 Milvus、Qdrant）可以达到 95%-98%
在 1000 次检索中，Redis 可能比专用向量库多漏掉几十个相关结果。这对猜你喜欢类的推荐影响有限，但对于法律文书检索、医学文献查证这类场景，每一个漏掉的结果都可能带来实质性影响。
大规模分布式不是强项
Redis Cluster 虽然支持分片，但架构并非为百亿级向量检索设计。
- 扩展上限明显：当数据量达到十亿级别时，专用向量数据库（Milvus、Pinecone）的分布式扩展能力更强。
- 跨分片查询开销：集群模式下的向量搜索可能因为跨分片通信而影响性能。
如果你预估数据量会快速增长到亿级以上，可能需要从一开始就考虑 Redis 能否撑住。
高级索引能力有限
Redis 的 Vector Set 主打 HNSW 算法，简单高效，但选择单一。专用向量数据库提供了更多索引选项（IVF、DiskANN、HNSW 的多种变体），让你在召回率、延迟、内存占用、构建时间之间做更精细的调优。
成熟架构：别二选一，可以组合出拳
Redis 向量检索的真正定位，不是取代专用向量数据库，而是在"快"这个维度上做极致。
成熟的 AI 架构往往是组合式的：
- 全量向量数据 → 专用向量数据库（如 Milvus）
- 热点查询结果 → Redis 语义缓存
语义缓存是 Redis 向量检索最自然的应用场景：用户问了一个问题，LLM 返回了答案，把"问题向量 + 答案"缓存到 Redis。下次有人问语义相似的问题，直接从缓存返回，既省 LLM API 调用费，又把响应时间压到毫秒级。
同样的道理也适用于推荐系统的热门物品向量缓存、RAG 系统的高频文档片段缓存。
写在最后
Redis 做向量检索，不是能不能的问题，而是适合不适合的问题。
- 如果追求极致的低延迟、数据量在千万级以内、需要混合查询、希望运维简单------Redis 是非常优秀的选择。
- 如果数据量在亿级以上、对召回率有极致要求、需要丰富的索引调优能力------专用向量数据库更合适。
技术选型没有银弹，只有最合适的工具。Redis 这位老朋友的新技能，值得了解，但要不要用、怎么用，取决于真实场景。