Por qué tu Semantic Cache está devolviendo respuestas incorrectas

Un usuario informó que nuestro plugin de traducción devolvía el mismo resultado en caché para cada solicitud, independientemente de la entrada. Investigamos y descubrimos algo peor: el 95% de todos los aciertos de caché semántica en nuestra plataforma eran falsos positivos. 199 solicitudes de traducción diferentes, 198 cuerpos de solicitud únicos, una respuesta en caché servida para todos ellos.

Si te preocupa el estado de los agentes a largo plazo y el manejo de solicitudes en producción, esta publicación complementa bien Por qué tu agente de IA sigue perdiendo su memoria, la guía de chatbot con una sola clave y la guía de limitación de tasa de la API de IA.

Puntos clave

• El 95% de los aciertos de caché semántica en la plataforma eran falsos positivos, con 198 solicitudes únicas que recibían la misma respuesta en caché.
• La causa raíz es la entrada estructurada. El texto de plantilla fijo domina el vector de embedding, por lo que el contenido variable apenas altera la similitud de coseno.
• Aumentar el umbral de similitud no soluciona esto, porque las distribuciones de aciertos correctos e incorrectos se superponen. Investigaciones recientes sobre la fiabilidad de la caché semántica confirman el mismo patrón.
• La solución se ejecuta en dos capas: extraer el contenido significativo antes del embedding y luego verificar cada acierto con un hash de huella digital FNV-1a rápido. Esto redujo los falsos positivos de aproximadamente el 95% a menos del 5%.
• La elección del modelo afecta la exposición. Los prompts del sistema largos y las entradas envueltas en JSON empeoran el problema independientemente del modelo que sirva la finalización; consulta el directorio de modelos de TokenLab (observado el 07-07-2026) para ver las opciones actuales si estás decidiendo a través de qué modelos enrutar el tráfico en caché.

El informe de error

El informe era simple: "Desactivé la caché semántica, pero cada traducción devuelve el mismo resultado".

Tres IDs de solicitud, tres segmentos de traducción diferentes, respuestas en caché idénticas. Los cuerpos de solicitud variaban de 1,564 a 8,676 bytes. El ID de respuesta en caché era el mismo para todos ellos: chatcmpl-DG6J03nhdvcF7Ek0C8rJkjh7lN9pF.

Primera sospecha: la configuración de caché del usuario no se estaba aplicando. Resultó ser un error de sincronización de fuente de datos independiente (el panel de administración escribía en una tabla, la API gateway leía de otra). Solucionar eso solo resolvió la mitad del problema. Incluso con la caché habilitada y funcionando correctamente, la caché semántica estaba haciendo coincidir solicitudes que nunca deberían coincidir.

Los datos de producción

Extrajimos 24 horas de datos de aciertos de caché de ClickHouse. Los números eran malos.

Modelo	Total de solicitudes	Aciertos de caché	Solicitudes únicas	Respuestas únicas	Tasa de aciertos
DeepSeek V4 Flash	200	199	198	1	99.5%
glm-4.6-thinking	100	38	13	1	38%
gpt-5-nano	31	29	28	2	93.5%
gpt-oss-120b	18	17	17	1	94.4%
qwen3-vl-flash	17	16	16	1	94.1%

198 solicitudes de traducción únicas, todas devolviendo la misma respuesta en caché. Eso no es una caché. Eso es una función rota que devuelve una constante.

Cada modelo afectado compartía dos rasgos: todas las solicitudes provenían de un solo usuario y todas usaban una plantilla de prompt del sistema fija con contenido de usuario variable. Para obtener una lista actual de modelos disponibles en la plataforma, el directorio de modelos de TokenLab (observado el 07-07-2026) es la fuente de verdad, ya que las alineaciones cambian a menudo.

Cómo detectar esto en tu propio sistema

No necesitas nuestros registros para averiguar si tienes el mismo problema. La señal más rápida es la diversidad de respuestas por modelo. Si un modelo tiene una alta tasa de aciertos de caché pero casi ninguna respuesta única, estás sirviendo una respuesta a muchas preguntas diferentes.

Aquí está la consulta al estilo ClickHouse que usamos, generalizada:

SELECT
  model,
  count() AS total_hits,
  uniqExact(substring(response_body, 1, 200)) AS unique_responses,
  round(uniqExact(substring(response_body, 1, 200)) / count(), 3) AS diversity_ratio
FROM request_logs
WHERE cache_hit = true
GROUP BY model
ORDER BY total_hits DESC;

Una caché saludable tiene un diversity_ratio cercano a 1.0, lo que significa que la mayoría de los aciertos devuelven respuestas distintas para entradas distintas. Una proporción cercana a 0 significa que muchas solicitudes colapsan en un puñado de respuestas en caché. Cualquier valor por debajo de 0.5 en un modelo con variedad de entrada real merece ser investigado.

Si no registras los cuerpos de respuesta, un proxy más barato también funciona: compara el recuento de cuerpos de solicitud únicos frente al recuento de respuestas únicas servidas desde la caché. Cuando 198 solicitudes únicas se asignan a 1 respuesta, la caché no está haciendo coincidir el significado, está haciendo coincidir el texto repetitivo (boilerplate).

Un segundo indicador son las quejas de los usuarios que se agrupan en cargas de trabajo estructuradas. Los plugins de traducción, los resumidores, los rellenadores de formularios y las herramientas JSON-in/JSON-out son los sospechosos habituales porque envuelven contenido variable en una plantilla fija.

Por qué los embeddings fallan en entradas estructuradas

El plugin de traducción envía solicitudes como esta:

System: "Actúa como una API de traducción. Devuelve solo un único objeto JSON sin procesar.
         Entrada: {"targetLanguage":"<lang>","title":"...","segments":[...]}"

User:   {"targetLanguage":"zh","title":"Página de producto",
         "description":"Traducir descripciones de productos",
         "tone":"formal",
         "segments":[{"text":"contenido variable real aquí"}]}

El prompt del sistema es idéntico en todas las solicitudes. El mensaje del usuario es un objeto JSON donde targetLanguage, title, description y tone son fijos. Solo cambia segments[].text.

Cuando nuestra caché semántica extrae texto para el embedding, concatena el prompt del sistema y el mensaje del usuario. La plantilla fija representa aproximadamente el 80% del texto. El modelo de embedding (all-mpnet-base-v2, 768 dimensiones) comprime esto en un vector donde la estructura de la plantilla domina. El contenido de traducción real apenas mueve la aguja.

Resultado: la similitud de coseno entre "traducir 'Hola mundo'" y "traducir 'El informe financiero trimestral muestra un aumento del 15% en los ingresos'" supera el 0.95. Nuestro umbral es 0.95. Cada solicitud de traducción coincide con la primera entrada en caché.

Al revisar los registros, encontramos tres formas en las que esto falla:

El plugin de traducción es el peor infractor. Las claves y valores JSON fijos ahogan los segmentos de traducción reales. Tanto DeepSeek V4 Flash como gpt-5-nano caen en esto.

Un asistente de resumen de contexto tenía una variante diferente del mismo problema. Su prompt del sistema era tan largo que el contenido del usuario, que variaba de 5KB a 47KB, apenas se registraba en el embedding. Así es como glm-4.6-thinking terminó devolviendo el mismo resumen para cada conversación.

El tercer patrón fue más sutil. Para gpt-oss-120b y qwen3-vl-flash, los primeros 500 caracteres de cada solicitud eran idénticos byte por byte. El contenido variable venía después, pero el embedding ya estaba dominado por el prefijo compartido.

Lo que dice la investigación

Este no es un problema nuevo. Investigaciones recientes lo han cuantificado.

El proyecto vCache de UC Berkeley descubrió que las distribuciones de similitud de aciertos de caché correctos e incorrectos se superponen mucho, lo que significa que ningún umbral fijo separa claramente una coincidencia verdadera de una falsa estructuralmente similar. Ese hallazgo coincide exactamente con lo que vimos en producción: los falsos positivos del plugin de traducción se agruparon por encima de 0.95, dentro del rango donde también viven las coincidencias de paráfrasis legítimas.

Otros trabajos recientes sobre la fiabilidad de la caché semántica llegan a conclusiones similares: la similitud de embedding sin procesar es una señal necesaria pero no suficiente para la corrección de la caché, y cualquier sistema de producción que dependa solo de ella debería esperar una tasa significativa de falsos positivos en tráfico estructurado y cargado de plantillas.

La solución de dos capas

La capa 1 es la extracción de contenido. Antes del embedding, elimina el prompt del sistema fijo y el andamiaje de la plantilla, y embebe solo la carga útil variable: el contenido real de segments[].text, no las claves JSON circundantes ni el texto repetitivo. Esto por sí solo aumenta drásticamente la relación señal-ruido en el vector de embedding.

La capa 2 es la verificación de huella digital. Incluso con una mejor extracción, el contenido casi duplicado aún puede producir puntuaciones de similitud altas. Antes de servir un acierto de caché, calcula un hash rápido (usamos FNV-1a) sobre el contenido extraído tanto de la solicitud entrante como de la entrada en caché. Si los hashes coinciden exactamente, sirve la caché. Si no, pasa a una finalización nueva o, para tráfico de mayor valor, enruta a una llamada de verificación barata que califique el significado, no los bytes.

El error es omitir la verificación por completo y confiar en la similitud de coseno sin procesar. Todos los enfoques en la tabla superan eso. Comienza con el más barato que se ajuste a tu tipo de consulta y solo sube de nivel cuando midas fallos de paráfrasis reales.

Juntas, estas dos capas redujeron nuestra tasa de falsos positivos de aproximadamente el 95% a menos del 5% en el tráfico afectado.

Cuándo la caché semántica es la herramienta incorrecta

El almacenamiento en caché no es ingeniería gratuita, y algunas cargas de trabajo no valen la pena ser almacenadas en caché.

• Tráfico de alta cardinalidad y baja repetición. Si casi cada solicitud es única, por ejemplo, una generación creativa única, la tasa de aciertos es demasiado baja para justificar la sobrecarga de embedding. Pagas por embeber todo y rara vez obtienes beneficios.
• Salidas que deben ser frescas. Cualquier cosa sensible al tiempo, datos en vivo, resultados personalizados, cualquier cosa con un "hoy" en ella, puede devolver respuestas obsoletas desde la caché incluso cuando la coincidencia es técnicamente correcta. La respuesta era correcta hace una hora y ahora está mal.
• Dominios de estricta corrección. Para respuestas médicas, legales o financieras, un solo falso positivo puede ser peor que el costo que ahorró. Si almacenas en caché aquí, la capa de verificación es obligatoria, no opcional, y una verificación de nivel LLM puede ser la única aceptable.
• Prompts diminutos donde la llamada al modelo ya es barata. El embedding, la búsqueda de similitud y la verificación tienen su propio costo. Si la finalización subyacente es de unos pocos cientos de tokens en un modelo barato, el almacenamiento en caché puede costar más de lo que ahorra.

El almacenamiento en caché brilla en finalizaciones repetitivas, cargadas de plantillas y costosas, exactamente las cargas de trabajo donde un falso positivo también es más fácil de introducir. Esa tensión es la razón por la que la capa de verificación importa. Si tu objetivo es principalmente el control de costos, también vale la pena combinar el almacenamiento en caché con un enrutamiento de modelos más baratos. La comparación de precios y la guía de mejores modelos de IA para programación cubren de dónde provienen realmente los ahorros por token, y el directorio de modelos de TokenLab (observado el 07-07-2026) muestra las opciones actuales, incluidas opciones de enrutamiento de bajo costo como DeepSeek V4 Flash y Gemini 3.5 Flash, si estás sopesando qué modelo usar para enrutar el tráfico en caché frente al no almacenado en caché. Verifica los precios actuales en el directorio vinculado antes de comprometerte con un plan de enrutamiento.

¿Por qué no simplemente aumentar el umbral?

Nuestro umbral ya es 0.95. Aumentarlo no ayuda. El problema es que las entradas estructuralmente similares producen puntuaciones de similitud superiores a 0.95 sin importar lo que diga el contenido real.

Los datos de vCache respaldan esto: las distribuciones de similitud de los aciertos correctos e incorrectos se superponen tanto que ningún corte único los separa. Sube el umbral a 0.99 y eliminarás aciertos de caché legítimos para paráfrasis genuinas, mientras que las solicitudes estructuralmente idénticas, como nuestras cargas útiles JSON de traducción, seguirán agrupándose por encima de 0.99 independientemente del contenido. El umbral no es la palanca. La representación de la entrada lo es. Es por eso que la Capa 1 (extracción de contenido) y la Capa 2 (verificación de huella digital) funcionan donde un aumento de umbral no lo hace: cambian lo que se compara, no qué tan estricta es la comparación.

Si estás construyendo o manteniendo una caché semántica, trata el umbral como un filtro grueso, no como una garantía de corrección. Combínalo con la extracción de contenido para que el embedding realmente represente la parte variable de la solicitud, luego agrega un paso de verificación barato para que una coincidencia de embedding casi fallida nunca pueda convertirse silenciosamente en una respuesta incorrecta en producción.

Comienza con el directorio de modelos de TokenLab para comparar precios actuales y puntos de referencia entre modelos de frontera, de programación y de enrutamiento de bajo costo antes de conectar tu capa de verificación de caché. Independientemente del modelo que se encuentre detrás de tu endpoint de finalización, el enfoque de extracción más huella digital es lo que realmente soluciona los falsos positivos.

Preguntas frecuentes

¿Aumentar el umbral de similitud soluciona los falsos positivos de la caché semántica? No. La investigación de vCache y estudios relacionados muestran que las distribuciones de aciertos correctos e incorrectos se superponen en todo el rango del umbral, por lo que aumentar el corte bloquea coincidencias legítimas sin filtrar de manera confiable las solicitudes estructuralmente similares pero semánticamente diferentes.

¿Cuál es la forma más barata de verificar un acierto de caché semántica? Un hash de huella digital (FNV-1a o similar) sobre el contenido extraído y significativo añade menos de un milisegundo de latencia y es gratuito de calcular. No detectará paráfrasis, pero elimina los falsos positivos exactos como los descritos aquí, que es donde se produce la mayor parte del daño en las cargas de trabajo estructuradas.

¿Depende este problema de qué modelo sirve la finalización? No, el problema de los falsos positivos reside en la capa de embedding y coincidencia, no en el modelo de finalización. Cualquier modelo detrás de una caché semántica, ya sea DeepSeek V4 Flash, glm-4.6-thinking o algo más nuevo, se verá afectado de la misma manera si la caché embebe texto de plantilla fijo junto con contenido variable. Consulta el directorio de modelos de TokenLab (observado el 07-07-2026) para conocer la disponibilidad actual de modelos al decidir qué modelos enrutar a través de una tubería en caché.