LLM 调用账单太吓人
工单助手每天上万次调用 GPT，账单一个月涨到三千刀。财务找过来时我才认真看数据：大量 query 语义相近（"怎么退货""退货流程""我要退钱"），答案其实一致，却每次都花 token 去问模型。用 Redis Stack 的向量检索做"语义缓存"，把相似问题直接命中缓存，调用量砍掉六成，这事儿值得记一笔。
Redis Stack 的向量检索
Redis Stack 提供 FT.CREATE 建向量索引，字段类型是 VECTOR，用 HNSW 算法，和专门的向量库思路一致：
FT.CREATE qa_idx ON HASH PREFIX 1 qa:
SCHEMA embedding VECTOR HNSW 6 DIM 768 DISTANCE_METRIC COSINE每条问答存成 hash，embedding 是问题向量的二进制：
HSET qa:1 embedding "\x12\x3f..." answer "7天内无理由退货"查询时把新问题向量化，用 KNN 搜最近的：
FT.SEARCH qa_idx "*" PARAMS 2 VECTOR embedding 768 "\x..."
SORTBY __embedding_score DIALECT 2语义缓存怎么降成本
流程：新问题先向量检索，如果余弦相似度大于 0.92，直接返回缓存答案，不调 LLM；否则调模型并把新问题加答案写回 Redis。代码骨架：
float sim = vectorStore.nearest(queryVec);
if (sim > 0.92) return cache.get(nearestId);
String ans = llm.ask(query);
cache.put(query, ans, queryVec);上线一个月，语义命中率 61%，LLM 调用从日均 1.2 万降到 4700，账单降到 1180 刀。命中延迟从 800ms 降到 12ms（纯 Redis 读），用户体验反而更好，因为不用等模型。
几个注意点
- 相似度阈值别定太高，0.95 会漏召回，用户问法稍变就命中不到；也别太低，0.85 会把不同问题混为一谈；
- embedding 模型要和热路径一致，否则向量空间对不上，检索全乱；
- 缓存要带 TTL，政策类答案会变，我们设 7 天过期，过期后重新问模型。
先到这
《Redis 在 AI 场景的应用：向量与语义缓存》这块我前前后后踩了不止一次。今天先写这些，后面想到新的再补。