Redis 接入 AI：从缓存到记忆层，向量搜索与语义缓存实战

1. 为什么是 Redis：AI 应用对数据层的三个新要求

1.1 AI 应用到底缺什么：从"缓存"到"记忆层"

先把手头的事放一放，我要认真聊聊 Redis 正式接入 AI 这件事。过去一两年，AI 大模型把所有人的注意力都拉到了"生成能力"上，但真正把它落到业务里之后，你会发现最头疼的往往不是模型本身，而是数据层。模型是没有记忆的，它记不住上次对话的用户叫什么，也记不住你昨天埋点里用户最喜欢哪个品类，更不可能自己决定哪些上下文该留、哪些该丢。我之前带一个智能客服项目，刚开始把所有对话历史都塞到 prompt 里，一轮对话下来 token 消耗高得离谱，延迟也一路飙升。后来把短期会话状态、用户画像、语义摘要全部放到 Redis，模型只拿真正需要的片段，成本和响应时间同时降了一个量级。这就是我说的"从缓存到记忆层"的变化：Redis 不再只是挡在数据库前扛流量的那一层，而是 AI 应用的结构性组成部分，负责让它"记得住""找得快""省得下"。

为什么偏偏是 Redis？因为 AI 应用的数据需求实际上越来越像实时系统：需要毫秒级写入、需要低延迟读取、需要数据结构能覆盖字符串、哈希、列表、流、搜索索引。Redis 原有的数据类型本来就能覆盖这些场景，再加上新引入的向量搜索能力，它把"记忆层"该有的东西都凑齐了。另一个很现实的理由是平滑迁移。现在很多公司已经是 Redis 用户，再做 AI 项目时，最稳妥的路线不是引一个新的专用向量数据库，而是把现有 Redis 升级成带向量检索能力的版本。运维体系、监控、权限、灾备都沿用老一套，团队不用学习全新的基础设施。这个决策在业务迭代快的小团队里尤其重要——你很难为一个 PoC 项目单独维护一套专用向量库，但 Redis 本来就在那儿，成本几乎可以忽略。

1.2 Redis 凭什么接 AI：向量检索只是起点

Redis 接入 AI 最核心的技术点，是它补齐了"语义检索"这一环。以前的 Redis 只能做精确匹配，你说查"apple"，就绝对不会返回"苹果手机"相关的语义内容。但 AI 应用要求的是"相似语义召回"，比如用户问"怎么改密码"，系统能召回"密码修改流程"这篇文档，哪怕两个句子里没有一个字相同。这个能力叫 Vector Similarity Search，底层由 RediSearch 模块承载，支持 HNSW 和 FLAT 两类索引。HNSW 是典型的高召回率近似最近邻算法，适合大量向量、要求低延迟的场景；FLAT 是暴力精确计算，适合小数据集、要求绝对准确的情况。

它跟其他向量数据库的核心思路一样，都是把文本、图片等数据用 embedding 模型转成高维向量，再用余弦距离或欧氏距离度量相似性。Redis 的差异化在于，它把向量索引和传统数据结构放在了同一个进程里。你在做一个实时推荐系统的时候，一边用 Stream 接收用户行为事件，一边用 Hash 存用户特征，一边用向量索引做相似品召回，三件事不再需要三套中间件。还有一个容易忽略的点：Redis 的接入不是只服务"搜索"。AI Agent 需要短期工作记忆，需要从 Redis 读写状态；Agent 之间可能需要用 Redis Stream 传递事件；请求风暴时还要用分布式锁做并发控制。这些场景里，Redis 分布式锁、Redis 数据类型、Redis 集群这些经典话题全部回来了，只是它们的战场从传统 Web 应用搬到了 AI 应用里。所以那些还在背 Redis 分布式锁面试题的朋友，现在可以换个角度理解：分布式锁不是面试专用考点，而是 AI 服务治理的基础设施。

1.3 哪些 AI 场景已经跑起来了：RAG、Agent 记忆、语义缓存

目前 Redis+AI 的落地场景，基本集中在三条线。第一条线是 RAG，把企业知识库的文档切块、向量化后放进 Redis，用户提问时做向量召回，把相关知识片段拼进 Prompt 再交给大模型。这套方案已经是企业私有化知识库的默认做法，比微调模型便宜得多，而且知识更新只需重新写文档，不用碰模型。第二条线是 AI Agent 记忆。Agent 在完成复杂任务时，需要记住用户的目标、中间结果、历史决定。用 Redis 存这些状态，比用关系型数据库轻量，比存文件可靠，而且天然支持多实例共享。比如一个旅行规划 Agent，可以把用户预算、偏好城市、已选航班放到 Redis Hash 里，后续步骤按 Key 读取，任务中断了还能恢复现场。

第三条线是语义缓存。语义缓存解决的是大模型调用昂贵的问题。如果用户反复问"退款流程""发票怎么开"，这类高频问题命中缓存后，不需要再调用模型，直接在 Redis 返回历史答案。我见过一个客服项目，上线语义缓存后大模型调用量直接降了四成。类似的模式还有实时推荐、在线特征存储、AI 网关限流。Redis 在 AI 链路里扮演的角色，远不止"缓存"两个字能概括，而这些也正是最近热词里大量出现"redis ai 接入""ai agent""ai 大模型"的原因——大家都在找一条把现有组件用起来的通路。

2. 核心能力拆解：向量搜索、语义缓存与实时推理

2.1 向量搜索：让 Redis 变成一个轻量向量数据库

要把 Redis 当向量数据库用，关键是正确创建索引和写入向量。以 Redis Stack 为例，一条完整的索引命令大致长这样：

FT.CREATE idx_content ON HASH PREFIX 1 "doc:" SCHEMA \ text TEXT \ embedding VECTOR HNSW 6 TYPE FLOAT32 DIM 1536 DISTANCE_METRIC COSINE

这里的关键参数有两个。一个是TYPE FLOAT32，embedding 模型输出的向量通常用 float32 表示，精度和内存占用比较均衡；另一个是DIM 1536，这个数必须严格等于 embedding 模型输出的维度。我见过不少新手在这里翻车：换了一个模型没有同步改维度，结果写入时报错，或者查询时返回空结果。如果用的 OpenAI text-embedding-3-large，维度是 3072；用本地的 bge-m3 通常是 1024；具体以模型文档为准。

索引建好后，写入向量不能在 redis-cli 里直接塞数组，因为 RediSearch 期望的是紧凑的二进制字节。直接用命令行写极容易出错。我的建议是用客户端库，Python 生态里最顺的是 redis-py 加上 RedisVL。RedisVL 把创建索引、写入向量、查询封装成了很短的 API，内部处理了向量的序列化。一个标准的数据入库片段长这样：

import redis from redisvl.index import SearchIndex from redisvl.schema import IndexSchema schema = IndexSchema.from_dict({ "index": {"name": "idx_content", "prefix": "doc:"}, "fields": { "text": {"type": "text"}, "embedding": {"type": "vector", "dims": 1536, "distance_metric": "cosine"} } }) idx = SearchIndex(schema, redis_client=redis.Redis(host="localhost", port=6379)) idx.create(overwrite=True)

接着把文档内容生成 embedding 后，用idx.load(data)批量写入。数据少的时候一次几百条没问题，数据量大就分批写入，避免单次命令体量过大。这里其实隐含了一个非常重要的意识：Redis 单条命令延迟很低，但命令体积过大会拖慢整个实例，批量入库必须控制批次大小，通常 100 到 200 条一组比较合适。

查询的时候，用idx.query传入用户问题，RedisVL 会自动做 embedding 再执行 KNN 召回。如果你希望完全自己控制召回逻辑，可以直接用原生命令：

FT.SEARCH idx_content "*=>[KNN 5 @embedding $vec AS similarity]" \ RETURN 3 text similarity \ SORTBY similarity ASC \ DIALECT 2 \ PARAMS 2 vec "\x00\x01..."

注意SORTBY similarity ASC表示相似度越小越相近（余弦距离），业务上要展示相似度百分比时记得做转换。这里建议先用 RedisVL 跑通流程，再根据性能优化逐步切到原生命令，调试成本会低很多。

2.2 语义缓存：省掉大模型调用的重复开销

语义缓存的核心思路听起来很简单——用户问一个问题，先算它的 embedding，在 Redis 里找语义相似的历史问题；如果命中且相似度超过阈值，直接返回历史答案，不再调用大模型；如果没命中，调用大模型后把答案连同问题的 embedding 一起写回 Redis。但真做起来，有几个细节必须处理好。

第一个是阈值怎么定。这个取决于你用的 embedding 模型和业务对准确性的容忍度。我一般会统计一批真实问题对之间的相似度分布，找一个"既要召回率、又要低误报"的分界线。以 bge-m3 为例，余弦相似度在 0.85 以上基本是同一个意思；0.7 到 0.85 之间需要人工检查。上线前建议做一个小的标注集，避免拍脑袋定阈值。

第二个是缓存的数据类型怎么选。最简单的是把问题和答案放在同一个 Hash 里，用问题 ID 作字段名：

HSET cache:q:uuid_001 question "怎么开发票" answer "登录后..." embedding "<binary>"

但实际项目中我更喜欢用 RedisVL 的 semantic cache 接口，它把"向量相似度检索 + Redis 存取"封装好了，内部还会处理过期时间，适合快速上线。一个简单的用法是这样的：

from redisvl.extensions.semantic_cache import SemanticCache cache = SemanticCache( redis_client=redis.Redis(host="localhost", port=6379), distance_threshold=0.2, # 余弦距离小于 0.2 即命中 ) cached = cache.check("<用户问题>") if cached: return cached answer = call_llm("<用户问题>") cache.store("<用户问题>", answer)

需要强调的是，语义缓存不是一劳永逸的。当知识库内容更新后，旧问题的答案可能已经过时，单纯的 TTL 可能不够。我的做法是给缓存键加业务版本号，比如cache:qa:v12:{uuid}，版本升级时通过 SCAN 批量清理旧版本，而不是把所有缓存全部推倒，这样可以避免一次大流量回源。

第三个容易踩的坑是缓存污染。如果大模型偶尔给出错误或不满意的回答，这个坏答案也会被缓存下来，影响后面所有相同语义的请求。建议在写入缓存前加一道校验逻辑，比如结果中包含"我不知道""无法回答"等信号时跳过缓存；或者对低置信度答案设置更短的 TTL，宁可多调几次模型，也不能把坏答案长期留在库里。

2.3 实时特征与在线推理：Redis 支撑 AI 决策链路

除了向量能力，Redis 在 AI 决策链路里还有一个非常重要的位置：实时特征存储。在线推荐、反欺诈这些系统，需要在高并发下快速读取用户维度特征。把用户最近点击、浏览时长、设备环境等写到 Redis Hash 或者 Stream，实时特征服务就能在毫秒级把这些数据送到模型打分模块。这里用到的是 Redis 最基础的数据类型能力，但和 AI 场景结合起来后，价值完全不同。

在这个环节，Redis 分布式锁也是刚需。当一个请求触发的推理任务比较重，多个副本同时算同一份结果就是浪费。常见做法是用 SET NX PX 在 Redis 里抢锁：

SET lock:infer:{request_id} 1 NX PX 1000

拿到锁的节点负责执行推理，其他节点等待或直接复用已有结果。这个点的本质和传统电商秒杀是同一套逻辑，只是锁的粒度从"库存扣减"变成了"推理去重"。所以再回头看网上那些 Redis 面试题，你会发现它们并不是孤立的考点，而是 AI 系统落地时真正绕不开的工程组件。

3. 实操：从零搭建一个 Redis + AI 的 RAG 问答服务

3.1 环境准备：安装 Redis 与 RedisVL

动手之前先把环境装好，我用的是 Redis Stack，它自带 Search 和 JSON 模块，省去手动加载模块的坑。如果你想最快看到效果，直接用 Docker：

docker run -d --name redis-stack -p 6379:6379 redis/redis-stack-server:latest

在 macOS 上也可以用 Homebrew，不过要注意默认安装的 redis 不一定包含 Search 模块。我的建议是统一用 Redis Stack 的镜像或者官方安装包，因为后续跑向量搜索时，模块缺失会浪费你大量排查时间。启动后可以用redis-cli MODULE LIST确认模块是否加载，正常情况下列表里能看到 search 模块。在 Windows 上，我一般推荐用 WSL 或 Docker Desktop，直接在容器里跑，比装原生服务更干净。

Python 环境至少需要三个依赖：redis、redisvl、以及一个 embedding 模型。embedding 模型选择上，如果你只是本地验证，用 sentence-transformers 或者 Ollama 拉一个 bge-m3 就行；如果走云端 API，OpenAI 和阿里云都有对应接口。代码上要保证同一个模型服务商贯穿整个流程，不要前半段用模型 A 生成向量、后半段用模型 B 来 query，维度一样但向量空间不同，召回结果会很奇怪。这个错误我在很多项目里见过，属于"常识性坑位"，但文档里从来不会写。

安装命令：

pip install redis redisvl sentence-transformers

为了验证环境，找一个短的文档写入 Redis 再做一次 KNN 查询，能返回数据就说明整条链路是通的。不要一上来就接大模型，先把检索这一半跑通，后面调试会顺畅得多。

3.2 数据入库：文本切块、Embedding 与 Hash 存储

把文档喂给 RAG 之前，文本切块是关键一步。切得太长，召回粒度粗，多主题段落混在一起；切得太短，语义完整性丢失。我常用的参数是 chunk_size 512 字符、chunk_overlap 50 字符，具体业务可以调，但至少保证每个 chunk 有一个完整语义单元。切完之后逐个生成 embedding，存进 Redis。

读取 PDF 或 Markdown 文件后，用langchain_text_splitters的RecursiveCharacterTextSplitter做切分：

from langchain_text_splitters import RecursiveCharacterTextSplitter splitter = RecursiveCharacterTextSplitter(chunk_size=512, chunk_overlap=50) chunks = splitter.split_text(documents)

然后遍历 chunks 生成向量并入库。入库建议用 pipeline，逐个 HSET 和批量 SET 的性能差异很可观：

pipe = redis_client.pipeline(transaction=False) for i, chunk in enumerate(chunks): embedding = embedding_model.encode(chunk).astype("float32").tobytes() pipe.hset(f"doc:{doc_id}:{i}", mapping={ "text": chunk, "embedding": embedding, }) pipe.execute()

这里有一个容易被忽略的序列化问题：很多新手直接把embedding_model.encode(chunk)返回的 numpy 数组塞进 Redis，结果要么报类型错误，要么存进去再查询出来维度全乱了。正确做法是先转成float32，再调tobytes()转成二进制。你存入的是什么结构，查询时就要用同样的方式还原。redis-py 对 bytes 的支持最好，存 numpy 对象反而会引出一堆 pickle 兼容性问题，这在生产环境很危险。把向量序列化成二进制后再写 Hash 字段，既高效又能被 RediSearch 直接索引。

建索引的时机可以放在入库前：

from redis.commands.search.field import VectorField, TextField from redis.commands.search.index_definitions import IndexDefinition idx_def = IndexDefinition(prefix=["doc:"]) fields = [ TextField("text"), VectorField("embedding", "HNSW", {"TYPE": "FLOAT32", "DIM": 1024, "DISTANCE_METRIC": "COSINE"}) ] redis_client.ft("idx_docs").create_index(fields, definition=idx_def)

注意DIM参数这里写 1024 是因为我用的 bge-m3，如果你换成其他模型，务必同步修改。索引和维度不一致，通常不会报错，但召回结果会非常离谱，属于最难排查的一类问题。

3.3 查询链路：向量召回 + 大模型生成

查询链路整体上是"用户问题 -> embedding -> 向量召回 TopK -> 拼 Prompt -> 大模型生成"。我写一个简化但完整的 Python 片段：

user_question = "怎么申请发票" q_emb = embedding_model.encode(user_question).astype("float32").tobytes() query = ( "(*)=>[KNN 5 @embedding $vec AS similarity]" ) res = redis_client.ft("idx_docs").search(query, query_params={"vec": q_emb}) contexts = [doc.text for doc in res.docs] prompt = f"根据以下资料回答问题：\n\n{chr(10).join(contexts)}\n\n问题：{user_question}" answer = call_llm(prompt)

这里KNN 5表示召回 5 个文档片段。召回数量不是越大越好，我一般先用 3 到 5 个做验证，再根据回答质量往上调。片段太多会把不相关的内容塞进上下文，模型容易受噪声干扰，也会增加 token 开销。拼 Prompt 时，我会建议把最相关的片段放在前面，因为模型对上下文开头的注意力通常更强，这个说法在多个大模型上都有实证，不过效果也因模型而异，还是要多做对照测试。

大模型这块，本地用 Ollama 最省事。环境上用一个统一的 function 调用大模型，方便之后切换供应商。如果你在公司内网，可以对接私有化模型服务，协议基本兼容 OpenAI 格式，改 base_url 就行。整体流程跑通后，再往上叠加语义缓存、权限过滤、日志追踪这些工程细节。

3.4 跃迁进阶：给 Agent 加一个 Redis 记忆层

RAG 解决了知识检索，但一个真正能"干活"的 Agent，还需要记忆能力。这里我通常把记忆分成两层：短期工作记忆和长期记忆。短期工作记忆存的是当前任务上下文，比如一个编码 Agent 当前操作的文件、上一个完成步骤、用户最新反馈；长期记忆存的是用户偏好和跨会话知识。短期用 Redis 的 String 或 Hash，Key 里带会话 ID，TTL 设置几小时；长期用 Hash 或者 Stream，按用户 ID 存储。

举个具体例子：做一个会议纪要 Agent。用户上传了会议录音转写文本，Agent 需要记录"会议主题""参与人""待办事项"。第一次处理完后，把结构化结果写进 Redis：

HSET agent:memory:{session_id} topic "Q2 产品规划" attendees "Alice,Bob" todos "完成竞品分析; 下周评审原型"

用户继续提问"我们上次定的待办是什么"，Agent 直接从 Redis 读取 todos 字段，再结合当前轮次的问题生成回答，完全不需要把整个历史文本重新发给模型。这个模式不仅省 token，而且让 Agent 的行为变得可追溯、可调试。

Agent 之间也可以基于 Redis Stream 异步协作。比如文档解析 Agent 把处理完成的事件写到 Stream，摘要 Agent 监听该 Stream，读取消息后继续生成摘要。这块用到了 Redis 的发布订阅和 Stream 消费组，不展开，但它在复杂 Agent 架构里非常常用。总的来说，Redis 接 AI 不等于只会做一个向量库，它真正要做的是把 AI 应用运行时需要的"状态"统一管起来。

4. 生产环境注意：主从、集群、序列化与可视化排查

4.1 部署拓扑：单机、主从与集群怎么选

我在多个项目里看到过同样的纠结：Redis 接 AI 之后，数据量和并发上来了，到底该用单机、主从还是集群。先给结论：开发环境单机完全够用；生产环境建议从主从开始，数据量超过单机内存承载能力再上集群。主从的价值不仅是高可用，还能把读流量分散到从节点，向量检索这种 CPU 密集操作尤其适合放到从节点执行。用一个 Docker Compose 就能拉起主从：

services: redis-master: image: redis/redis-stack-server:latest command: ["redis-server", "--appendonly", "yes"] ports: ["6379:6379"] redis-slave: image: redis/redis-stack-server:latest command: ["redis-server", "--replicaof", "redis-master", "6379"] depends_on: - redis-master

集群方案需要额外引入 cluster mode，键的分布策略要考虑 AI 场景的特殊性。向量索引和普通键一样受哈希槽分布影响，业务上需要把同一类向量数据尽量集中，避免查询时跨节点聚合造成额外延迟。Redis 集群下的向量检索支持比较依赖 Redis Enterprise 或 Redis Stack 的集群模式，开源版在做大规模 ANN 检索时效果会受限。所以如果你明确要跑大规模的 AI 召回，我的建议是可以先评估专用向量库，Redis 更合适的定位是"与 AI 场景共生的通用数据层"，而不是把所有向量库能力全部替代。

部署上还有一个容易被忽略的点是持久化。向量数据重建成本很高，如果只依赖纯内存模式，实例重启后就必须重新对全部文档做 embedding。所以生产环境必须开启 AOF 或 RDB，最好两者结合。向量二进制数据保证了精确恢复，如果丢了，重新生成的时间成本可能比故障本身还高。

4.2 数据序列化：向量怎么存才不会踩坑

序列化是在 Redis 里存向量最容易踩坑的一环。我见过三种典型错误。第一种，直接在 Python 里redis.set("vec", np.array(...))，redis-py 默认会用 pickle 序列化 numpy 对象，写入和读取都能跑，但 Search 模块无法解析 pickle 数据，检索直接失败。第二种，把向量转成 JSON 数组存进去，虽然可读性强，但体积膨胀 3 到 5 倍，而且依然无法让 RediSearch 索引。第三种，维度类型不匹配，模型输出 float64，索引要求 float32，存进去以后查询结果全偏。

正确的姿势是：统一用astype("float32")转精度，再调用tobytes()转成 bytes，写入 Hash 字段；读出来的时候用np.frombuffer(data, dtype=np.float32)还原。如果你用 RedisVL，它内部已经把这些封装好，但你在手动调命令做调试时，还是要把这个原理刻在脑子里。序列化出了错，症状往往是"索引存在但查询为空"，或者"召回结果乱序"，非常迷惑，定位半天才发现是类型问题。

4.3 可视化与排障：从 Desktop Manager 到 RedisInsight

排查 Redis 向量问题时，光靠 redis-cli 不太够，我一般先把 RedisInsight 打开，它可以看到内存状态、Key 分布、慢查询记录，还能直接浏览 Hash 中的二进制字段。Another Redis Desktop Manager 和传统的 Redis Desktop Manager 我也都用过，日常看数据来说都够用，但 RedisInsight 对 Search 索引、拓扑、命令分析的支持更完整。建议至少装一个官方工具，生产排查效率会高很多。

如果碰上网上常说的redis command timed out; nested exception is io.lettuce.core.RedisCommandTimeoutException这类问题，先不要急着调大 timeout 参数。最常见的原因是连接池被打满或者大 Key 阻塞了单线程事件循环。向量写入时如果批量过大，一批几 MB 的命令会让 Redis 卡住几秒钟，后续所有读请求全部排队。这种问题靠加大 timeout 只会掩盖症状。我的处理套路是：先看慢查询日志确认哪些命令耗时长，再逐步调小批量写入大小、开启客户端连接池、必要的时候把检索流量分流到从节点。

4.4 常见问题速查表

我整理了一份高频问题表，基本覆盖了从安装到上线的排查路径。

这个表不会解决所有问题，但能帮你快速缩小排查范围。生产上的问题往往不只一个原因，我建议每次改一个变量、验证一个变量，不要同时调阈值、改批次、加索引，否则出了问题根本定位不准。

5. 踩坑心得：我反复强调的几条经验

5.1 内存与维度：向量数据的规模控制

向量库不是越大越好。Redis 毕竟是内存数据库，高维向量非常吃内存。以 1024 维 float32 为例，单个向量占用 1024 乘以 4 字节，也就是 4 KB。加上 Hash 的元信息、HNSW 索引的开销（通常是原始数据的 1.5 到 2 倍），一个向量最终占用的内存可能在 10 KB 到 15 KB 之间。100 万条文档就是 10 GB 到 15 GB。这个数字对 Redis 来说并不小，一台 32 GB 的机器放几百万条没问题，但你要处理上亿级数据时，内存成本会迅速失控。

控制内存有几个手段：只向量化需要检索的字段，不要把整篇文档都塞进向量字段；使用 PCA 等降维技术把 1536 维降到 256 维，召回效果会略降但内存占用大幅减少；对长文本先做摘要再向量化。这些手段要配合业务效果测试，不能只看内存指标。另外，Redis 的 maxmemory 策略要设置成 noeviction，或者至少对向量数据的业务库单独配置。如果使用 allkeys-lru，向量数据可能因为内存不足而被 Redis 自动淘汰，这会导致线上检索突然返回空结果。这个坑很隐蔽，因为 Redis 不会报错，只是召回数量少了，等到你注意到异常，内存里的好数据已经被换掉了一部分。

5.2 版本与阈值：embedding 模型的指纹管理

embedding 模型升级后，新旧向量语义空间不一致，混合索引会导致召回质量诡异下降。所以我在生产环境强制要求把模型版本号写进 Key 前缀，比如doc:embedv3:{id}。同时把模型版本、维度、度量方式记录在一个配置中心，索引命名直接带版本。这样每次模型升级都是一个独立索引，通过灰度切流量把全部数据重建之后再切换，避免新旧向量混用。这个操作看起来多费一步，但它是避免线上召回质量雪崩最有效的办法之一。

缓存阈值也不是一次调完就完事了。语义缓存命中率的合理区间因业务而异：FAQ 型业务可以追求高命中率，知识库问答型业务如果文档不断更新，命中率太低反而可能返回过时答案。我在每个版本上线前都会跑一轮离线评估，统计查询对之间的相似度分布，再结合线上日志调整阈值。没有数据支撑的阈值都是玄学，这句话我在团队里反复说。

5.3 定位与心态：Redis 是 AI 应用的运行底座

最后说点心态层面的。如果你问 Redis 接 AI 到底该怎么接，我认为先别把它当成一个"向量数据库"来调研，而是把它当成 AI 应用的运行底座。它负责管理状态、上下文、特征、任务队列和召回，向量搜索只是其中一项能力。你如果只盯着向量检索的性能对比，反而会忽略它在整个系统里更大的价值。

我现在新起一个 AI 项目，数据层的第一版方案几乎都长这样：状态和缓存用 Redis，向量召回在数据规模可控时也用 Redis，规模超过单机承载再考虑专用向量库。这套组合不是最前沿的，但它是调整成本最低、最能稳定支撑业务迭代的方案。先把 RAG 跑通，再加 Agent 记忆层、语义缓存，你会很快理解标题里那几个字的实际分量。跑过一次之后，你大概就能明白为什么 Redis 接 AI 会成为这几天最受关注的话题之一了。