最近 Redis 宣布与 AI 深度集成的消息让我这个用 Redis 写了八年生产环境的老家伙有点坐不住了。以前我们聊 Redis无非是缓存、队列、分布式锁这些老生常谈但这一轮 AI 接入之后Redis 的定位发生了质变它不再只是躲在 MySQL 前面挡流量的“缓存层”而是成了大模型应用里真正存记忆、做召回、扛并发的核心数据底座。我最近刚把一个基于大模型做的 AI Agent 知识库项目从“临时方案”重构成“Redis 主程”这一套做下来最大的感受是Redis 和 AI 的结合不是把 Redis 当缓存那么简单而是要把 Redis 的数据结构、部署形态、运维习惯全部重新审视一遍。这篇文章就基于我这次重构的实战经验讲讲 Redis 接入 AI 后应该怎么设计、怎么落地、怎么排坑给正在做 AI 应用或者准备把 Redis 用起来的同学一个可参考的完整路径。1. AI 应用的“数据底座”为什么 Redis 成了刚需1.1 大模型应用面临的真实数据难题先说我这次项目的背景。团队做了一个多轮对话式知识助手底层接的是大模型接口核心流程是用户提问 - 召回相关知识片段 - 拼进 Prompt - 调用模型 - 流式返回答案。听起来很简单但一旦放上生产三个问题立刻跳出来。第一大模型接口调用是有成本和时延的。一次普通问答可能消耗几百到几千 token接口响应时间 2 到 5 秒用户可没耐心每次都等你慢慢思考。第二多轮对话必须有上下文记忆但模型本身不保存任何历史所有历史都得我们自己维护。第三知识库检索RAG需要做向量召回向量的存储和相似度计算放在哪里直接决定召回响应速度。这些问题传统数据库很难兼顾。MySQL 能存数据但扛不住高并发读ES 倒是适合检索但太重直接拿内存数组做缓存又完全没有持久化和淘汰策略。Redis 恰好站在了中间内存级读写速度、丰富的数据结构、灵巧的过期策略、原生的持久化和主从方案几乎是为大模型应用的数据特征量身定做的。1.2 Redis 在大模型链路中具体解决哪些问题我把这次项目中 Redis 承担的角色整理成一张职责表你们感受一下覆盖面。场景Redis 具体用途传统方案痛点多轮会话历史Hash 存储会话消息List 维护消息时间线MySQL 拼接历史太慢影响首字时延RAG 向量召回向量索引做相似度检索能直接算出 TopK 知识点MySQL 不支持余弦距离计算拿 Python 硬算效率极低大模型响应缓存String 缓存相同问题的回答降低 API 开销直接不缓存一次问答就烧一次钱请求限流与配额计数器 滑动窗口限制单用户每秒请求数代码里拿全局变量计数一重启就归零知识库热点统计ZSet 维护热点问题排名助力 Prompt 优化日志离线分析滞后严重所以你看Redis 接入 AI 之后它解决的不只是“缓存 Key-Value”的问题而是大模型应用里时效性最强、并发最高、最容易成为瓶颈的那些环节。理解了这一点后面的技术选型和实操路径就顺理成章了。1.3 什么样的团队适合马上跟进如果你属于下面几类情况这个思路可以马上用到项目里正在做 AI Agent、智能客服、知识库问答等大模型应用被上下文管理和成本问题困扰。团队已经引入 Redis 但只用了 String 缓存想知道怎么把 Hash、ZSet、Stream 都用起来。负责 RAG 链路优化想找一个比单独的向量数据库更轻量的中间方案。当然如果你只是刚接触 Redis这文章里的命令和配置也足够你跟着跑一遍我会在实操部分把每一步都展开。2. 数据结构选型把 8 种 Redis 类型映射到 AI 应用2.1 String大模型响应的第一道缓存String 是 Redis 最基础的类型但在 AI 场景里它的作用反而被很多人低估。我这次项目里String 承担了两类关键任务。一类是大模型响应缓存。用户问“Redis 支持哪些数据结构”系统把问题做归一化处理之后先查一个 key 格式为llm:resp:{question_hash}的 String如果命中就直接返回缓存的回答如果没命中才真正调用大模型接口拿到回答后再写回 Redis 并设置过期时间。这里有个细节问题归一化很重要否则“你好”和“你好 ”多了个空格会被当成不同问题缓存命中率直线下降。我通常是转小写、去掉首尾空格、压缩连续空格之后再做 Hash。另一类是 Token 计数与成本统计。我用INCRBY命令维护用户每天的 Token 消耗数把 Key 设计成user:{id}:tokens:{yyyyMMdd}到点自动过期。每天统计报表直接GET出来再和账单对比基本能精确算出每个用户的成本。这比单独搭一套日志分析系统轻量太多。这里必须说一个注意事项String 缓存大模型响应时value 别直接存超长全文。我的经验是如果回答超过 2KB建议先压缩或者只缓存摘要否则 Redis 内存会涨得很快。对于动辄几千字的长回答设置合理的过期时间比盲目追求命中率更重要。2.2 Hash 与 List多轮会话的“记忆抽屉”多轮对话的记忆存储是 AI 应用最容易写崩的地方。最初我们用的是关系表把每一轮 user 和 assistant 的消息存成行取历史时要查一轮再拼 JSON接口响应时间直接多了几十毫秒。重构后我改用 Hash List 组合。Hash 的 key 设计成session:{session_id}内部字段是user_name、model、created_at这些会话元信息List 的 key 设计成session:{session_id}:messages消息按顺序 LPUSH/RPUSH 进去每条消息是一个 JSON 字符串包含 role 和 content 字段。取历史时用LRANGE直接拿最近 20 条拼进 Prompt不仅少了一次数据库查询还天然保持了顺序。这么做最大的好处是可控。你可以用LTRIM把 List 裁剪到固定长度比如只保留最近 10 轮对话防止 Prompt 过长把上下文窗口撑爆。这个裁剪操作要在调用大模型之前做而不是之后。我曾经因为忘记裁剪把 60 轮对话全塞进 Prompt结果 Token 费用翻了近一倍模型回复质量反而下降了。2.3 ZSet 与 Set热点跟踪和知识去重ZSet 在 AI 应用里是个被忽视的宝。我在项目的“热点问题榜”上用了 ZSetkey 是hot:questions:{date}member 是问题原文score 是提问次数。用户每次提问执行一条ZINCRBY hot:questions:20250321 1 Redis 分布式锁怎么实现。排行榜天然按分数排序我每天定时把 Top 100 捞出来交给运营同学用来反推知识库缺什么内容。Set 则用来做知识片段的去重。RAG 召回时经常出现同一个知识点以不同文本形式被重复插入向量库的情况我把每个片段的文件 MD5 加行号拼接成字符串用SADD判断是否存在存在就跳过。这一手直接把向量库的重复率从 8% 降到 0.3%检索准确率明显提升。2.4 Stream 与 TimeSeries让 Agent 消息跑起来如果你做的 AI Agent 涉及多节点协作比如一个节点负责意图识别、另一个节点负责知识检索、还有一个节点负责调用模型节点之间的消息传递用 Redis Stream 非常舒服。Stream 有点类似 Kafka 但轻量得多。我用一个agent:events队列各节点通过XADD写入事件下游节点用XREADGROUP消费。最香的是它有消费组机制多个 Agent 实例可以分摊同一条消息流的处理压力不会重复消费。对我们这种中小规模 Agent 场景没必要为了消息队列再引入一套 KafkaRedis Stream 足够了。TimeSeries 模块可能用得少一些但它监控 AI 应用的指标是真的方便。我会记录每次大模型调用的耗时、Token 消耗、缓存命中情况用TS.ADD写入指标再用TS.RANGE拉出最近一小时的趋势图。Redis 官方文档里 TimeSeries 支持聚合查询做 PV/UV、响应时间分位数统计比自己在代码里写聚合函数靠谱得多。3. 从部署到调优AI 场景下的 Redis 实操全流程3.1 安装与基础配置别再用裸机跑生产我见过很多团队在生产环境用 Windows 装个 Redis 就开始跑业务说实话测试可以生产真的不建议。我的建议是生产环境优先使用 Linux Docker 部署全程可控可复现。Docker 拉镜像这块直接docker pull redis:7.2-alpine就行alpine 版本体积小适合常规部署。如果你需要在本地验证和跑测试Windows 用户也可以去 Redis 官网下载 Windows 移植版或者用 WSL 跑 Linux 版本但请记住这只是本地开发环境不是生产方案。单机部署很简单跑一条命令即可docker run -d --name redis-ai \ -p 6379:6379 \ -v /data/redis:/data \ redis:7.2-alpine \ redis-server --appendonly yes --requirepass your-strong-password注意两个参数--appendonly yes开启 AOF 持久化防止重启丢数据--requirepass设置密码。有些团队内网环境不设密码Redis 端口一旦暴露公网不出半小时就会被扫描并写满垃圾数据这是基本功别省。3.2 主从部署AI 高并发读写的基础保障AI 应用的并发读写往往远超普通 Web 应用因为前端一个流式响应后端可能同时触发多路检索和调用。为了保证 Redis 的可用性主从架构是底线。我这次用 Docker 搭了一主一从步骤很简单。先建主节点docker run -d --name redis-master \ -p 6379:6379 \ -v /data/redis-master:/data \ redis:7.2-alpine \ redis-server --appendonly yes --requirepass master-pass再建从节点docker run -d --name redis-slave \ -p 6380:6379 \ -v /data/redis-slave:/data \ redis:7.2-alpine \ redis-server --appendonly yes \ --masterauth master-pass \ --replicaof 宿主机IP 6379需要注意从节点的--masterauth必须填主节点的密码否则同步会反复报MASTER aborted replication的错。配置完成后在从节点执行INFO replication看到role:slave且master_link_status:up说明主从同步正常。为什么要强调主从因为 AI 应用里大量读操作知识检索、响应缓存、Session 读取可以打到从节点主节点专写读写分离后主节点压力大幅下降。我实测下来单靠主从分离Redis 的查询吞吐能提升 60% 以上而且主节点崩溃后从节点可以快速提升为主业务不中断。3.3 客户端选型与可视化工具开发阶段提效AI 场景下Redis 客户端我推荐两个方向Java 技术栈用 Lettuce 或 RedissonPython 技术栈用 redis-py。我这次项目是 Python 后端直接pip install redis就够用配合redis.asyncio做异步操作性能和代码可读性都很不错。至于调试工具Redis Desktop Manager现在改叫 RedisInsight 了基本人手一个。它能图形化展示所有 key 的类型、TTL、内存占用还能直接执行命令对于排查“为什么这个 key 没有过期”这类问题效率极高。另外还有一个轻量级选择是 Another Redis Desktop ManagerUI 更符合国人习惯而且免费开源。我个人的习惯是日常 debug 用可视化工具上线后的自动化运维脚本一律走 redis-cli避免人工误操作。3.4 缓存策略计算怎么设置 TTL 才合理AI 应用的缓存 TTL 设置不能拍脑袋。我总结了一个参考表你们可以直接套数据类型推荐 TTL原因大模型响应缓存10~30 分钟热知识变化不快但太长时间容易给用户旧答案会话上下文2~4 小时多轮对话一般不会持续太久过期后自动清理向量召回结果5~10 分钟知识库更新后需要及时反映到召回结果Token 计数当天 24 点过期按自然日统计过期时间设为次日零点TTL 设置其实是在“缓存命中率”和“数据新鲜度”之间找平衡。比如你做一个新闻问答助手新闻每五分钟更新一次响应缓存 TTL 超过五分钟就会出现旧闻当新闻的尴尬但如果你做的是法律条文问答条文本就不常变TTL 可以放到一小时。经验是先根据业务判断合理范围再上线观察缓存命中率命中率低于 50% 就调长 TTL高于 90% 且数据常有变化就调短。4. 核心环节实现把 AI 能力真正落到 Redis 上4.1 用 Redis 实现可扩展的 Agent 记忆管理上一节讲数据结构时提到 Hash List 存会话这里我给出完整可跑的代码。我用 Python 的 redis-py 演示逻辑清晰换其他语言也一样。import redis import json import hashlib r redis.Redis(hostlocalhost, port6379, db0, decode_responsesTrue) def save_message(session_id: str, role: str, content: str): session_key fsession:{session_id} msg_key fsession:{session_id}:messages # 保存会话元信息不存在时才设置 r.hsetnx(session_key, created_at, time.time()) # 追加消息 msg json.dumps({role: role, content: content}, ensure_asciiFalse) r.rpush(msg_key, msg) # 裁剪到最近 20 条防止上下文过长 r.ltrim(msg_key, -20, -1) def get_recent_messages(session_id: str, limit: int 10): msg_key fsession:{session_id}:messages raw_list r.lrange(msg_key, -limit, -1) return [json.loads(item) for item in raw_list]这里的关键点是ltrim的用法。我从第 21 条消息开始裁剪保证列表里最多保留 20 条。这 20 条拼进 Prompt加上系统提示词和检索到的知识片段总 Token 基本可控。大家注意裁剪之后别忘记检查消息里是否还有系统级的工具调用结果如果 Agent 内部产生很长的函数返回内容最好单独存 Hash不要混在对话消息里否则照样撑爆上下文。4.2 RAG 召回缓存让每次检索都快 10 倍知识库问答最耗时的环节是向量检索。我用 Redis 给 RAG 召回加了一层缓存效果立竿见影相同问题第二次询问时响应时间从 2 秒直接降到 100 毫秒。实现思路也不复杂。用户问题进来后先做归一化和哈希查缓存 Keydef get_rag_context(question: str): norm_question normalize(question) # 小写、去空格、去停用词 cache_key frag:ctx:{hashlib.md5(norm_question.encode()).hexdigest()} cached r.get(cache_key) if cached: return json.loads(cached) # 未命中走向量检索 docs vector_search(norm_question, top_k5) context format_docs(docs) r.setex(cache_key, 300, json.dumps({context: context, docs: docs})) return {context: context, docs: docs}接下来还要配套缓存更新机制。我启动了一个定时任务每 10 分钟检查知识库是否有新文件入库如果有就用命令批量删除以rag:ctx:开头的 key防止旧缓存继续被命中。删除前缀 key 在生产环境不要用KEYS尤其是 key 量大时会导致 Redis 阻塞。正确姿势是用SCAN游标遍历删除或者直接维护一个索引 Set记录所有rag:ctx:的 key清理时遍历 Set 再删既快又安全。4.3 分布式锁防止大模型接口重复调用AI 应用里有一种很隐蔽的并发问题用户连续点了两次“生成”如果前端没有做防抖两个请求同时到达后端就会对大模型接口发起两次完全相同的调用造成双倍费用。我解决这个问题用的就是 Redis 分布式锁。def generate_with_lock(user_id: str, question: str): lock_key flock:gen:{user_id}:{hashlib.md5(question.encode()).hexdigest()} # 尝试获取锁设置 10 秒自动过期防止死锁 acquired r.set(lock_key, 1, nxTrue, ex10) if not acquired: return {status: duplicate, message: 相同问题正在生成中} try: result call_llm(question) return result finally: r.delete(lock_key)这里的nxTrue表示只有当 key 不存在时才能设置成功天然满足互斥性ex10是锁的自动过期时间避免进程宕机后锁永远不释放。Python 的 redis-py 在较新版本支持set(name, value, nxTrue, exseconds)这种写法老版本需要分两步走建议升级版本。业务上我额外加了一个优化获取锁失败时如果这个 key 正好缓存了之前的生成结果直接返回缓存否则客户端可以轮询几秒再获取结果。这样用户连续点击也不会报错只会得到同一个结果体验反而更顺滑。4.4 大模型请求限流配额控制不求人成本控制这件事被动的缓存优化是一方面主动的限流则是另一方面。我给每个用户设置了一个 Qt 1 秒最多 5 次请求的配额实现方式用的是滑动窗口。def allow_request(user_id: str, limit: int 5, window: int 1): key frate:{user_id}:{int(time.time() // window)} count r.incr(key) if count 1: r.expire(key, window 1) if count limit: return False return True这是最简单的固定窗口限流对于大多数 AI 应用已经够用。如果你的流量曲线很尖同一秒内可能涌入大量请求建议用 ZSet 做真正意义的滑动窗口每次请求把当前毫秒时间戳写入 ZSet然后删除窗口之前的所有记录再统计集合大小判断是否超限。不过实话说固定窗口在绝大多数场景不会出问题先把业务跑稳比追求算法上的完美重要。5. 序列化、缓存治理与常见问题排查实录5.1 序列化方式怎么选直接影响内存和速度Redis 存中文和复杂对象时序列化方案选不对内存占用能差出一倍多。我见过很多团队直接用 JDK 原生序列化一个普通对象序列化后带着类描述头体积膨胀严重。在我 Python 项目里我统一用 JSON 序列化存进去之前json.dumps取出来之后json.loads简单直接且跨语言兼容。Java 团队我推荐用 Jackson 序列化成 JSON或者用 Kryo 这类高性能序列化库。如果业务包含二进制向量数据Redis 的 String 可以直接存纯字节数组我习惯是把向量用 numpy 转成 float32 字节流再写进 Redis读取时直接np.frombuffer还原比 Base64 字符串省内存且转码更快。这里切记别把向量转成 Python 的 list 再存一个 1024 维向量在 Redis 里能占几十 KB但转成字节流只有 4KB 左右差距非常大。5.2 缓存穿透、击穿、雪崩AI 场景同样躲不过这三个问题老生常谈但 AI 场景下表现略有不同。缓存穿透多发生在恶意用户用随机问题反复刷接口时每次请求都因为 key 不存在而穿透到大模型接口既消耗算力又烧钱。处理方案是布隆过滤器或缓存空结果。我项目里简单粗暴但有效查不到结果时在 Redis 里写一个空值标记TTL 设 60 秒后续相同问题直接命中空缓存不再调用模型。缓存击穿在 AI 场景表现为某个热门问题的缓存刚好过期同时涌入大量请求全部穿透到大模型接口。解决方案就是上文提到的分布式锁加缓存重建同一时间只允许一个请求去调模型其他请求等待。缓存雪崩则是大量 key 同时过期导致数据库或模型接口被瞬间打爆。规避办法很简单设置 TTL 时加一个随机偏移比如基础 TTL 是 300 秒实际设置时在 270 到 330 之间随机取值。这个细节很多人知道但经常忘吃过亏之后就长记性了。5.3 主从延迟和内存告警的处理主从架构下读写分离后最怕的是主从延迟。如果从节点读到刚写入的数据失败AI 应用的会话历史就可能“丢失”。我的处理方式是把每个用户的会话写入和读取都绑定到主节点只把知识检索这类可容忍旧数据的读操作分到从节点。业务上还可以根据角色做路由必须读新的操作走主允许最终一致的操作走从。内存监控方面我会用INFO memory定时观察used_memory的增长曲线同时开启maxmemory和合适的淘汰策略。AI 应用里我推荐allkeys-lru内存满了优先淘汰最久没访问的 key。一定别用默认的noeviction否则内存满了直接写入报错线上事故十有八九就是这么来的。5.4 日志排查与可视化工具实战Redis 的日志文件默认输出到容器 stdout排查问题时直接看 Docker 日志docker logs redis-ai --tail 100如果怀疑某个命令执行很慢开启慢查询日志CONFIG SET slowlog-log-slower-than 10000 CONFIG SET slowlog-max-len 128 SLOWLOG GET 10阈值单位是微秒所以 10000 表示记录超过 10ms 的命令。慢查询日志能直接暴露哪些 key 被频繁执行复杂操作比如大 Hash 的HGETALL或者大 List 的LRANGE 0 -1都是潜在杀手。定位之后优化的方向就是把大 key 拆分或者把复杂度降下来。可视化工具里RedisInsight 有一个非常有用的分析面板能一眼看出内存占用 Top 10 的 key。我排查内存增长问题时85% 的情况是靠这个面板直接定位到某个没设 TTL 的缓存 key然后针对性补上过期时间。用了它的分析功能基本就不需要再人肉遍历 key 了。6. 更进一步的玩法AI 反向赋能 Redis 开发6.1 让 AI 帮你写 Redis 命令和数据模型聊完 Redis 支撑 AI 应用再聊一个很多人忽略的方向AI 反过来辅助 Redis 开发。我自己实践后觉得价值最大的场景就是让大模型帮你生成数据模型设计方案。以前我设计 Redis key 和数据结构时靠的是经验和文档查阅现在我的做法是把业务需求直接写成提示词扔给 AI 大模型例如“我现在要做多轮对话助手消息按 session 存储需要在 2 小时内保留上下文最多保留 20 轮还要做热点问题排行按天统计请帮我设计 Redis key 的命名规则、数据结构选择和 TTL 建议并给出 Python 代码。”它给出的方案一般八九不离十我再基于对业务的判断微调。这个流程最大的价值不是替代思考而是快速试错一个问题提出 2 秒内就能拿到一个相对完整的设计草稿比查文档、翻代码快得多。6.2 AI 辅助排查 Redis 故障的提示词技巧Redis 报错信息往往晦涩比如MISCONF Errors writing to the AOF file这种新手看一眼就懵。以前是复制报错去搜索引擎一个个查现在我直接丢给 AI 解释“Redis 出现 MISCONF Errors writing to the AOF file我的 Docker 部署命令是 xxxAOF 持久化开启了请分析可能原因并给出排查步骤。”它会列出磁盘满、权限不对、AOF 写入路径不存在等常见原因我再照着检查。经验是给的信息越完整AI 的分析越准最好把部署命令、配置文件关键项、最近的操作一并附上而不是只丢一行报错。6.3 用 AI 生成测试用例Redis 逻辑回归利器我项目里有一段缓存重建逻辑改动频率高容易出回归问题。以前手写测试用例要模拟缓存命中、未命中、并发覆盖、缓存过期各种场景代码量不小。现在我用 AI 写测试用例把函数源码粘给它然后要求“帮我生成 pytest 测试用例覆盖缓存命中、未命中、并发竞争、过期删除四个场景使用 fakeredis 模拟”。它能在一分钟内生成一个可运行的测试文件。我唯一要做的就是把生成的测试代码里与自己业务命名不一致的变量修正一下然后跑通。这个流程让我省下了大量繁琐的测试模板时间而且覆盖度比我手写还完整AI 的确更擅长穷举边界条件。7. 踩坑记录与调参心得7.1 最容易忽略的“连接数打满”问题AI 应用是异步链路Python 的异步 Redis 客户端默认连接池只有 10 个连接并发上来了直接报Connection pool is full。这个坑我踩过一次因为本地测试根本触发不了高并发一上生产就被打脸。解决方案是用redis.asyncio.ConnectionPool(max_connections50)手动创建连接池同时给每个请求加统一的超时时间pool redis.asyncio.ConnectionPool( hostlocalhost, port6379, db0, max_connections50, socket_timeout3, socket_connect_timeout3 ) r redis.asyncio.Redis(connection_poolpool)socket_timeout3很关键如果 Redis 集群故障但没设超时你的应用线程会全部卡在等待响应上直接拖垮整个服务。设置超时后故障会快速暴露为错误而不是无限期阻塞。7.2 大 key 删除导致 Redis 阻塞有一次清理缓存时我用了一条DEL big_key结果 Redis 整整阻塞了 5 秒。原因是那个 key 是一个存了 50 万元素的 ListDEL 一个大数据结构需要的时间超乎想象。Redis 是单线程模型命令执行期间其他所有请求都会被阻塞。正确做法是用UNLINK替代DEL后者是异步释放内存不会阻塞主线程。我后来把所有涉及大 key 的删除操作都换成了 UNLINK线上再没出现过这种瞬间卡顿。7.3 AOF 持久化策略怎么调才不丢数据AOF 默认的appendfsync always性能开销大everysec可能丢 1 秒数据。AI 应用里会话历史可以容忍丢失几秒但账单相关的计数不行。我给不同 key 分了实例会话和缓存放主 RedisAOF 设置为everysec账单和限流计数放到另一个小型 RedisAOF 设置为always保证不丢数据。虽然多维护一个实例成本高一点但业务安全性完全不同量级。8. 生产环境最后的检查清单如果你正打算把 Redis 接入自己的 AI 项目别急着动手先对着这个清单过一遍所有访问 Redis 的入口是否设置了密码和网络白名单。是否根据业务将读多写少的操作分流到从节点。数据结构的 TTL 是否已经结合业务实际设置而不是默认不过期。大 key 的清理由 DEL 改成了 UNLINK。客户端是否配置了合理的连接池大小和超时时间。是否做了主从切换演练或者至少知道手动提升从节点的命令REPLICAOF NO ONE。缓存穿透、击穿、雪崩三个场景代码层面是否都已有应对方案。这套下来我不敢说生产环境 100% 稳但至少能把 90% 的常见坑提前堵死。最终我个人的体会是Redis 接入 AI 这件事本质上是把你对业务数据流的理解转换成对数据结构的选择和节奏的控制。数据结构选对了AI 应用的响应速度和成本都会收获意外惊喜选错了再快的模型也救不回架构层面的浪费。这几年做下来我最大的心得就是八个字“先定结构再聊优化”希望这篇实践记录能给正在折腾 Redis 和 AI 的你一点实实在在的参考。