语义缓存的 key 生成、命中后跳过哪些步骤、以及失效机制是怎么设计的?

[LetMeSleep8h]

读 ARCHITECTURE.md 时看到链路里有"语义缓存"一步,想确认几个细节:

1. 语义缓存的 key 是怎么生成的?是对问题原文做 embedding 相似度匹配,还是先经过意图分流/时间解析之后再匹配?如果用户问"上个月销售额"和"上月销售总额",命中缓存的阈值是多少?
2. 缓存的 value 存的是 SQL、查询结果,还是图表推荐?命中之后哪些链路步骤会被跳过?
3. 有没有失效机制?比如底层数据更新(Olist 订单表追加)后,旧缓存会不会返回过期结果?

[NewNewUp]

"\u4e09\u4e2a\u95ee\u9898\u5206\u522b\u56de\u7b54(\u4ee5\u5f53\u524d main \u5206\u652f\u5b9e\u73b0\u4e3a\u51c6):\n\n## 1. Key \u751f\u6210\u4e0e\u547d\u4e2d\u8303\u56f4\n\n\u7f13\u5b58\u5165\u53e3\u5728\u610f\u56fe\u5206\u6d41\u4e0e\u65f6\u95f4\u89e3\u6790**\u4e4b\u540e**,\u4e0d\u5728\u6700\u524d\u9762:query \u5148\u5b8c\u6210\u65f6\u95f4\u89e3\u6790,\u628a"\u4e0a\u4e2a\u6708""\u4e0a\u6708"\u8fd9\u7c7b\u76f8\u5bf9\u65f6\u95f4\u89c4\u7ea6\u6210\u7edd\u5bf9\u65f6\u95f4\u533a\u95f4,\u518d\u62fc\u4e0a\u610f\u56fe\u5206\u6d41\u7684\u6807\u7b7e(\u805a\u5408/\u660e\u7ec6/\u8d8b\u52bf)\u4e00\u8d77\u505a embedding\u3002\u6240\u4ee5\u4f60\u4e3e\u7684\u4e24\u4e2a\u95ee\u9898("\u4e0a\u4e2a\u6708\u9500\u552e\u989d"\u548c"\u4e0a\u6708\u9500\u552e\u603b\u989d")\u5728\u8bed\u4e49\u5411\u91cf\u4e0a\u9ad8\u5ea6\u63a5\u8fd1,\u8d85\u8fc7\u9608\u503c\u5373\u547d\u4e2d\u2014\u2014\u9608\u503c\u5728\u914d\u7f6e\u91cc\u53ef\u8c03,\u9ed8\u8ba4\u504f\u4fdd\u5b88\u4ee5\u907f\u514d\u8bef\u547d\u4e2d\u3002\n\n## 2. \u7f13\u5b58 value \u4e0e\u8df3\u8fc7\u8303\u56f4\n\nvalue \u5b58\u7684\u662f SQL + \u67e5\u8be2\u7ed3\u679c + \u56fe\u8868\u63a8\u8350\u4e09\u4ef6\u5957\u3002\u547d\u4e2d\u540e\u76f4\u63a5\u8df3\u8fc7:Schema \u53ec\u56de\u3001SQL \u751f\u6210(\u53cc\u5f15\u64ce)\u3001AST \u5b89\u5168\u6821\u9a8c\u3001\u53ea\u8bfb\u6267\u884c,\u56db\u6b65\u5168\u8df3\u3002\u53ea\u4fdd\u7559\u56fe\u8868\u63a8\u8350\u7ed3\u679c\u7684\u76f4\u63a5\u8fd4\u56de,\u6240\u4ee5\u547d\u4e2d\u8def\u5f84\u7684\u5ef6\u8fdf\u57fa\u672c\u662f\u6beb\u79d2\u7ea7\u3002\n\n## 3. \u5931\u6548\u673a\u5236\n\n\u6309**\u6570\u636e\u8868\u7c92\u5ea6**\u505a\u4e86\u5931\u6548:Olist \u8ba2\u5355\u8868\u8ffd\u52a0/\u66f4\u65b0\u65f6,\u76f8\u5173\u8868\u7684\u5199\u5165\u8def\u5f84\u4f1a\u6e05\u6389\u5f15\u7528\u4e86\u8be5\u8868\u7684\u7f13\u5b58\u6761\u76ee(\u53d6 SQL \u89e3\u6790\u51fa\u7684\u8868\u540d\u96c6\u5408\u505a\u53cd\u5411\u7d22\u5f15)\u3002\u6ca1\u6709\u505a TTL \u5168\u91cf\u8fc7\u671f,\u76ee\u7684\u662f\u5728"\u79bb\u7ebf\u5206\u6790\u6570\u636e\u4f4e\u9891\u66f4\u65b0"\u7684\u573a\u666f\u4e0b\u5c3d\u91cf\u4fdd\u547d\u4e2d\u3002\u5982\u679c\u4f60\u5f80\u8ba2\u5355\u8868\u704c\u4e86\u65b0\u6570\u636e\u4f46\u6ca1\u8d70\u9879\u76ee\u7684\u5199\u5165\u8def\u5f84(\u6bd4\u5982\u624b\u5de5\u76f4\u8fde MySQL \u6539\u8868),\u7f13\u5b58\u4e0d\u4f1a\u81ea\u52a8\u5931\u6548\u2014\u2014\u8fd9\u4e5f\u662f\u76ee\u524d\u660e\u786e\u7684\u8fb9\u754c,\u540e\u7eed\u53ef\u4ee5\u8003\u8651\u6309\u8868\u7684\u6700\u5927\u65f6\u95f4\u6233\u505a\u65c1\u8def\u6821\u9a8c\u3002\n"