SemanticCache.check() unconditionally refreshes TTL on hit (sliding-window with no opt-out)
维护者通常 5 天内回复
评估
- 难度
- 3/5
- 预计耗时
- 1-2 天
- 新手友好度
- 70/100
- Issue 类型
- 功能
- 描述清晰度
- 描述清楚
- 活跃度
- 冷清
- 技术栈
- python, redis
调研方向
从 redisvl/extensions/cache/llm/semantic.py 中 SemanticCache.check() 的第 432 行附近开始,然后阅读周围的 SemanticCache 构造函数以及当前的 TTL 刷新路径。验证所提议的构造函数标志和每次调用的覆盖选项在禁用时仍保持默认行为并允许纯读取;当两种选项都得到支持且不改变现有调用方时,即表示完成。
由索引模型根据 Issue 内容生成。
描述
Current behavior
SemanticCache.check (redisvl/extensions/cache/llm/semantic.py:432) refreshes the TTL of every matched entry on every hit:
# Refresh TTL on all found keys
for key in redis_keys:
self.expire(key)
This is a sliding-window TTL: a popular entry effectively lives as long as it keeps getting hit. There is no constructor flag, per-call argument, or per-entry attribute to disable this.
Why this is a problem
Sliding window is the wrong default in any domain where the popularity of an entry correlates with the cost of it being stale:
- a procedure superseded by a regulatory bulletin that the cache has not yet invalidated
- a balance-patch-affected gameplay answer in a live-ops surface
- a pricing or eligibility answer that changed at midnight
In these domains the most-asked question is the most likely to be cached and the most likely to fan out a stale answer. The standard mitigation today — store an absolute expires_at numeric and filter on it at read time — works but requires every customer to discover the pattern independently.
Proposed API
SemanticCache(
name="cache",
redis_url=...,
refresh_ttl_on_hit=True, # current behavior, default unchanged
)
cache.check(
prompt=...,
refresh_ttl=None, # per-call override
)
refresh_ttl_on_hit=False would make check() a pure read. Customers wanting absolute expiry would set this to False, store a numeric expires_at filterable field, and filter on it.
Backwards compatibility
Default remains True. Existing behavior unchanged. Opt-in behavioral change for customers who need it.
Notes
Surfaced while writing a scoped semantic caching architecture spec; came up repeatedly when stress-testing the design against regulated and fast-mutating domains where sliding-window TTL is actively hostile.
- 主要语言
- Python
- 星标
- 433
- 派生
- 120
- 平均合并
- 8 天 28 分钟
- 30 天内合并 PR
- 34
环境准备
- 没有 Dockerfile 或 Docker Compose 文件
- 有 Pull Request 模板
- 阅读贡献指南
从这里开始
- 先读完整个 Issue,再读项目的贡献指南。
- 在 Issue 下留言说明你要接手 —— 这能避免两个人做同样的事。
- Fork 仓库,在一个分支上完成修改。
- 提交 Pull Request,并在描述里引用这个 Issue 编号。
redis/redis-vl-python 的其他 Issue
-
SVS-VAMANA `compression` does not survive `IndexSchema.to_dict()`, breaking YAML round-trips and migration planning可能已有人在做 @Bhavy-Ranka 于 8 天前认领。 未关闭
难度 2/5 1-3 小时 新手友好度 78/100
redis/redis-vl-python#808 · 2 条评论 ·
维护者通常 5 天内回复
-
RedisVL warnings are never shown when the application has not configured logging可能已有人在做 @hippi345 于 11 天前认领。 未关闭bug
难度 2/5 1-3 小时 新手友好度 77/100
redis/redis-vl-python#786 ·
维护者通常 5 天内回复
-
exists() depends on exact FT.INFO error wording; an unrecognised "missing index" message makes create() never create the index (regression from #672)可能已有人在做 @Yarmoluk 于 4 天前认领。 未关闭
难度 2/5 1-3 小时 新手友好度 75/100
redis/redis-vl-python#773 · 1 条评论 ·
维护者通常 5 天内回复
-
Vector field with index_missing=True cannot be created可能已有人在做 @RaphaelFakhri 于 21 天前认领。 未关闭
难度 2/5 1-3 小时 新手友好度 72/100
redis/redis-vl-python#770 ·
维护者通常 5 天内回复
-
SearchIndex.drop_keys does not validate cluster hash-tag co-location (inconsistent with drop_documents)可能已有人在做 @Hashim1999164 于 20 天前认领。 未关闭bug good first issue index
难度 2/5 1-3 小时 新手友好度 78/100
redis/redis-vl-python#601 ·
维护者通常 5 天内回复
查看 redis/redis-vl-python 的全部 Issue
相似的 Issue
-
难度 2/5 1-3 小时 新手友好度 66/100
维护者通常 1 天内回复
-
[Bug] vllm-sr config migrate drops providers.models[].deployment可能已有人在做 @Bevisy 今天认领。 未关闭needs-acceptance wg/developer-experience-ecosystem
难度 2/5 1-3 小时 新手友好度 86/100
vllm-project/semantic-router#5996 ·
维护者通常 2 天内回复
-
bugfix low-priority plugin:abstract plugin:leyline small-effort source:discussion
难度 2/5 1-3 小时 新手友好度 66/100
athola/claude-night-market#1132 ·
-
难度 2/5 1-3 小时 新手友好度 77/100
WeblateOrg/language-data#2773 ·
维护者通常 1 天内回复
-
kind/bug priority/medium qa_automation
难度 2/5 1-3 小时 新手友好度 78/100
yugabyte/yugabyte-db#37324 ·
维护者通常 1 天内回复