Make semantic cache observability easier out of the box
Los mantenedores suelen responder en 4 días
Nadie ha tomado este issue todavía.
Evaluación
- Dificultad
- 5/5
- Tiempo estimado
- Más de una semana
- Aptitud para principiantes
- 35/100
- Tipo de issue
- Nueva funcionalidad
- Claridad
- Necesita aclaración
- Estado de actividad
- Tranquilo
- Stack tecnológico
- python, redis
- Área
- backend, observability
Línea de trabajo
El issue no nombra archivos, tests ni puntos de entrada de observabilidad existentes. Empieza localizando las implementaciones síncrona y asíncrona de la caché semántica y sus integraciones con el backend; después, revisa cómo se representan actualmente las comprobaciones de caché, los aciertos, los fallos, los errores, la latencia y los almacenamientos. Se considera terminado cuando exista una experiencia de observabilidad opt-in definida, con la semántica de las señales documentada y un comportamiento síncrono y asíncrono coherente.
Escrito por el modelo de indexación a partir del texto del issue.
Descripción
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.
- Lenguaje dominante
- Python
- Estrellas
- 432
- Forks
- 111
- Merge medio
- 5 d 22 h
- PR fusionados (30 d)
- 13
Preparar el entorno
- Sin Dockerfile ni archivo de Docker Compose
- Tiene una plantilla de pull request
- Leer la guía de contribución
Primeros pasos
- Lee el issue completo y luego la guía de contribución del proyecto.
- Comenta en el issue que vas a ocuparte — evita que dos personas hagan lo mismo.
- Haz un fork del repositorio y trabaja en una rama.
- Abre un pull request que haga referencia al número del issue.
Más de redis/redis-vl-python
-
from_existing fails on SVS-VAMANA indexes created without compressionPosiblemente ocupada Un pull request vinculado a esta issue está abierto o ya se fusionó. Abiertobug index
Dificultad 2/5 1-3 horas Aptitud para principiantes 84/100
redis/redis-vl-python#787 ·
Los mantenedores suelen responder en 4 días
-
RedisVL warnings are never shown when the application has not configured loggingPosiblemente ocupada Un pull request vinculado a esta issue está abierto o ya se fusionó. Abiertobug
Dificultad 2/5 1-3 horas Aptitud para principiantes 77/100
redis/redis-vl-python#786 ·
Los mantenedores suelen responder en 4 días
-
exists() depends on exact FT.INFO error wording; an unrecognised "missing index" message makes create() never create the index (regression from #672)Posiblemente ocupada @nandanadileep la tomó hace 4 días. Abierto
Dificultad 2/5 1-3 horas Aptitud para principiantes 75/100
redis/redis-vl-python#773 · 1 comentario ·
Los mantenedores suelen responder en 4 días
-
Vector field with index_missing=True cannot be createdPosiblemente ocupada @RaphaelFakhri la tomó hace 10 días. Abierto
Dificultad 2/5 1-3 horas Aptitud para principiantes 72/100
redis/redis-vl-python#770 ·
Los mantenedores suelen responder en 4 días
-
Add Python 3.15 supportPosiblemente ocupada @vishal-bala la tomó hace 11 días. Abierto
Dificultad 2/5 1-3 horas Aptitud para principiantes 65/100
redis/redis-vl-python#757 · 1 comentario · 1 reacción ·
Los mantenedores suelen responder en 4 días
Todos los issues de redis/redis-vl-python
Issues similares
-
backlog
Dificultad 1/5 Menos de una hora Aptitud para principiantes 91/100
EchoTools/nevr-runtime#1108 ·
Los mantenedores suelen responder en 1 día
-
parse names a key after a top-level multi() threshold Bitcoin Core v31.1 refuses as not validAbierto
Dificultad 2/5 1-3 horas Aptitud para principiantes 78/100
btclib-org/btclib-wallet#587 · 1 comentario ·
Los mantenedores suelen responder en 1 día
-
Dificultad 2/5 1-3 horas Aptitud para principiantes 75/100
-
Dificultad 2/5 1-3 horas Aptitud para principiantes 72/100
Los mantenedores suelen responder en 1 día
-
documentation
Dificultad 2/5 1-3 horas Aptitud para principiantes 68/100
Judgment-Pack/judgment-pack-spec#275 ·
Los mantenedores suelen responder en 1 día