在本地部署大模型时，Ollama 能降低模型调用门槛，但重复问题仍会反复执行推理。例如“如何重置密码”和“忘记密码怎么办”表达不同，真实意图却高度相近。传统字符串缓存只能命中字面完全一致的请求，而将 Ollama Embedding 与 Redis 向量检索结合，可以在模型推理前识别语义近似问题，直接复用已有答案，从而改善响应速度与资源利用率。🚀
一、语义缓存的核心思路
语义缓存不是简单执行“问题字符串等于缓存键”的判断，而是先把问题转换为向量，再比较向量之间的距离。Ollama 的 /api/embed 接口可以生成文本嵌入，返回经过 L2 归一化的向量；官方建议在多数语义搜索场景中使用余弦相似度，并确保写入和查询使用同一个嵌入模型，具体可参考 Ollama Embeddings 文档[1]。
完整请求链路可以概括为：用户提问 → 文本规范化 → Ollama 生成向量 → Redis 查询相似问题 → 判断是否达到命中阈值。命中时直接返回缓存答案；未命中时调用 Ollama 生成答案，再将问题、向量、答案及业务元数据写入 Redis。这样既保留了本地模型的可控性，也利用 Redis 完成快速检索和生命周期管理。⚡
二、Redis 数据结构与索引设计
每条缓存记录至少应保存原始问题、规范化问题、向量、模型回答、嵌入模型名称、生成模型版本、创建时间和业务范围。业务范围可以包括租户、语言、知识库版本或应用场景，避免不同环境之间错误复用答案。
Redis 支持在 Hash 或 JSON 文档中存储向量和元数据，并可通过向量字段执行 KNN、范围查询及元数据过滤。索引可选 FLAT 或 HNSW，距离度量可采用 COSINE。数据规模较小且更关注精确结果时，可先使用 FLAT；数据增长后，再结合延迟、内存和召回要求评估 HNSW。相关能力可查看 Redis 向量搜索文档[2]。
- 键前缀：按应用划分，例如 cache:assistant:，便于隔离和清理。
- 向量维度：必须与 Ollama 嵌入模型实际输出维度一致。
- 模型标识：同时记录生成模型与嵌入模型，升级时可主动失效旧缓存。
- 过期时间：FAQ 可设置较长 TTL，价格、库存和状态类答案应使用较短 TTL。
三、从请求到命中的实现步骤
- 规范化输入：去除多余空格，统一大小写和常见标点，但不要随意删除否定词、时间、版本号等关键信息。
- 优先精确匹配：对规范化文本计算散列并查询普通 Redis Key。完全相同的问题无需再次生成向量。
- 执行语义检索：精确缓存未命中时，调用 Ollama 的 /api/embed，再使用返回向量查询 Redis 中距离最近的候选记录。
- 应用硬性过滤：在向量查询中限制租户、语言、模型版本、权限等级和知识库版本，防止“语义相近但业务上下文不同”的误命中。
- 判断阈值：只有最相近记录达到既定阈值时才返回缓存，否则继续调用生成模型。
- 回写缓存：保存新问题、答案、向量和元数据，同时设置 TTL，并记录本次为缓存未命中。
四、提高重复请求命中率的关键
采用两级缓存
一级缓存处理字面完全一致的问题，二级缓存处理改写、同义表达和轻微语序变化。精确缓存速度更快，也不会出现语义误判；语义缓存负责扩大覆盖范围。两者结合通常比只做向量检索更容易维护。
通过真实样本校准阈值
阈值不能直接照搬示例配置。阈值过宽可能把“如何退款”和“退款多久到账”误认为同一问题，阈值过严又会使合理改写无法命中。建议从脱敏后的历史问题中构造正样本与负样本，分别标注“可以复用”和“不可复用”，再观察不同阈值下的误命中率与漏命中率。Redis 的语义缓存说明也强调，阈值调优以及租户、语言、模型版本等硬边界是保证正确性的关键，参见 Redis Semantic Cache 说明[3]。
让缓存失效可控
知识库更新后，旧答案即使语义匹配也可能已经过时。可以把知识库版本写入元数据，并在检索时强制过滤；也可以通过标签批量删除指定主题的缓存。对于高时效内容，应优先缩短 TTL，而不是盲目追求高命中率。🔄
五、监控与质量保护
上线后应持续记录精确命中数、语义命中数、未命中数、向量生成耗时、Redis 查询耗时、模型推理耗时和人工判定的错误命中数。命中率提升并不等于效果一定更好，真正需要关注的是“正确命中率”。
建议在返回缓存结果时附带内部字段，如 cache_type、similarity、cache_age 和 model_version，便于排查问题，但不必直接展示给最终用户。
涉及个人数据、权限结果、一次性操作、实时余额或不可复用的会话状态时，应绕过语义缓存。若回答受到用户身份影响，还必须把权限或角色加入过滤条件，不能只依赖文本相似度。
总结
Ollama 接入 Redis 语义缓存的重点，不只是“把向量存进去”，而是建立精确缓存、语义检索、元数据隔离、阈值校准、TTL 失效和质量监控组成的完整闭环。实践中可以先从范围稳定、重复度高的 FAQ 场景开始，小流量观察误命中情况，再逐步扩大覆盖范围。只有在答案正确性得到保护的前提下，提高重复请求命中率才真正有价值。✅
