Make semantic cache observability easier out of the box
维护者通常 4 天内回复
还没有人认领这个 Issue。
评估
- 难度
- 5/5
- 预计耗时
- 一周以上
- 新手友好度
- 35/100
- Issue 类型
- 功能
- 描述清晰度
- 需要澄清
- 活跃度
- 冷清
- 技术栈
- python, redis
- 领域
- backend, observability
调研方向
该 issue 未指明任何文件、测试或现有的可观测性入口。首先定位同步和异步语义缓存的实现及其后端集成，然后检查缓存检查、命中、未命中、错误、延迟和存储目前是如何表示的。完成标准是定义一种明确的 opt-in 可观测性体验，记录信号语义，并确保同步和异步行为一致。
由索引模型根据 Issue 内容生成。
描述
Problem
RedisVL semantic caching can reduce LLM latency and cost, but customers do not currently have an easy, built-in way to understand how effectively a cache is working.
RedisVL exposes useful search index statistics, but those do not answer common semantic cache questions such as:
- What is the cache hit ratio?
- How many checks result in hits, misses, or errors?
- How long do cache lookups take?
- Is cache effectiveness improving or regressing over time?
Today, customers need to wrap cache calls with their own instrumentation. This adds setup work, leads to inconsistent metric definitions, and makes it harder to demonstrate the value of semantic caching. Redis server keyspace hit and miss statistics are not a substitute because they do not represent whether a semantic search produced an acceptable cache match.
Customer value
A more plug-and-play observability experience would help customers:
- Quantify latency and LLM cost savings from semantic caching.
- Tune thresholds, TTLs, and cache strategy using real workload data.
- Detect drops in cache effectiveness or increases in lookup errors and latency.
- Compare behavior across environments and releases.
- Connect semantic cache signals to the monitoring tools they already use with minimal application code.
Desired experience
Customers should be able to opt into semantic cache observability with very little setup and get clearly defined, documented signals for each cache. The experience should be consistent across synchronous and asynchronous usage and, where practical, across RedisVL semantic cache backends.
Useful signals may include cache checks, hits, misses, hit ratio, lookup latency, errors, stores, cache size, and match-distance information. This list is intended to describe customer needs rather than prescribe a particular API, metrics library, or implementation.
Observability should add minimal overhead, avoid exposing prompt or response content, and have metric semantics that customers can rely on in dashboards and alerts.
- 主要语言
- Python
- 星标
- 432
- 派生
- 111
- 平均合并
- 5 天 22 小时
- 30 天内合并 PR
- 13
环境准备
- 没有 Dockerfile 或 Docker Compose 文件
- 有 Pull Request 模板
- 阅读贡献指南
从这里开始
- 先读完整个 Issue，再读项目的贡献指南。
- 在 Issue 下留言说明你要接手 —— 这能避免两个人做同样的事。
- Fork 仓库，在一个分支上完成修改。
- 提交 Pull Request，并在描述里引用这个 Issue 编号。
redis/redis-vl-python 的其他 Issue
-
bug index
难度 2/5 1-3 小时 新手友好度 84/100
redis/redis-vl-python#787 ·
维护者通常 4 天内回复
-
bug
难度 2/5 1-3 小时 新手友好度 77/100
redis/redis-vl-python#786 ·
维护者通常 4 天内回复
-
exists() depends on exact FT.INFO error wording; an unrecognised "missing index" message makes create() never create the index (regression from #672)可能已有人在做 @nandanadileep 于 4 天前认领。 未关闭
难度 2/5 1-3 小时 新手友好度 75/100
redis/redis-vl-python#773 · 1 条评论 ·
维护者通常 4 天内回复
-
Vector field with index_missing=True cannot be created可能已有人在做 @RaphaelFakhri 于 10 天前认领。 未关闭
难度 2/5 1-3 小时 新手友好度 72/100
redis/redis-vl-python#770 ·
维护者通常 4 天内回复
-
Add Python 3.15 support可能已有人在做 @vishal-bala 于 11 天前认领。 未关闭
难度 2/5 1-3 小时 新手友好度 65/100
redis/redis-vl-python#757 · 1 条评论 · 1 个 reaction ·
维护者通常 4 天内回复
查看 redis/redis-vl-python 的全部 Issue
相似的 Issue
-
bug P1
难度 2/5 1-3 小时 新手友好度 76/100
Toloka/tolokaforge#1947 ·
维护者通常 1 天内回复
-
SageMaker provider: streaming fails with NoStreamDataError on DJL Serving (LMI) endpoints可能已有人在做 @balajiaru 今天认领。 未关闭
难度 2/5 1-3 小时 新手友好度 88/100
UKGovernmentBEIS/inspect_ai#6127 ·
维护者通常 2 天内回复
-
难度 2/5 1-3 小时 新手友好度 67/100
维护者通常 2 天内回复
-
难度 2/5 1-3 小时 新手友好度 68/100
letsencrypt/cp-cps#361 ·
-
难度 2/5 1-3 小时 新手友好度 65/100