Caché semántica para LLM en producción: arquitectura, aislamiento y frescura

Una caché semántica LLM convierte una pregunta en un embedding, busca entradas parecidas y puede devolver una respuesta ya generada si el candidato supera un umbral y pasa todos los filtros duros. Reduce una llamada completa al modelo; no reduce únicamente tokens de un prefijo.

La caché semántica calcula cercanía entre preguntas y puede servir un output anterior. Necesita embedding, filtros, umbral, TTL e invalidación, y puede equivocarse por una paráfrasis que cambia una condición. RAG recupera documentos o chunks para construir contexto fresco; normalmente llama al modelo y no reutiliza una respuesta final. Son capas combinables, no sinónimos.

Una comparación útil es: exacta = misma clave; prompt caching = mismo prefijo procesado; semántica = pregunta suficientemente parecida dentro del mismo ámbito; RAG = evidencia recuperada para volver a responder. Mézclalas en la arquitectura solo cuando puedas medir qué capa produjo el hit.

Arquitectura: las fronteras preceden a la similitud

El contexto autenticado deriva los filtros, nunca la pregunta ni un JSON libre del cliente. Como mínimo, el scope incluye tenant, usuario o rol, locale, modelo y versión de prompt, versión del corpus, ACL y versión de la política de seguridad. Añade ruta, canal, región, moneda o cualquier atributo que cambie la respuesta.

El orden recomendado es identidad verificada → filtros duros de scope y frescura → embedding de la consulta → KNN dentro del conjunto elegible → umbral calibrado por clase de intent → hit o miss → generación y escritura con el mismo scope. No recuperes vecinos globales para filtrarlos después: logs, métricas o un reranker ya podrían haber visto datos ajenos.

La entrada debe conservar prompt normalizado, respuesta, modelo, versiones, ACL efectiva o su hash, fecha de creación, fecha de expiración, procedencia y clase de intent. Una respuesta sin versión de corpus o policy no es invalidable de forma fiable.

<figure style="margin:34px 0;font-family:system-ui,sans-serif;"><img src="https://devaisemanal.com/content/images/2026/10/architecture-3.png" alt="Arquitectura de caché semántica LLM con identidad, filtros duros de tenant y ACL, embedding, KNN con umbral, hit o miss, generación e invalidación por versiones" style="width:100%;height:auto;border-radius:12px;border:1px solid #dbe3ef;background:#f8fafc;" /><figcaption style="font-size:14px;color:#64748b;margin-top:10px;line-height:1.5;">La similitud solo se calcula dentro de fronteras ya autorizadas; un hit no demuestra equivalencia y puede convertirse en miss por TTL o versión.</figcaption></figure>

Umbral, intents y falsos hits

Un umbral global suele ser una mala simplificación. Una consulta de saludo puede tolerar más similitud; una pregunta sobre precio, fecha, permisos o configuración necesita coincidencia más estricta o miss. Calibra threshold, top-k y TTL por clase de intent con un conjunto etiquetado de pares equivalentes y no equivalentes.

Rollout con holdout y apagado seguro

Empieza en shadow mode: calcula embedding y candidato, pero no sirvas hits; compara qué habría ocurrido con la generación real. Divide tráfico por clase de intent y conserva un holdout aleatorio sin caché para medir coste, latencia, calidad y frescura contra el mismo baseline.

Después activa una pequeña proporción con kill switch, TTL conservador y allowlist. Revisa falsos hits, fugas entre scopes, cambios de corpus y P95 de misses; aumenta gradualmente solo si la precisión y los tests negativos se mantienen. El fallback de seguridad es generar de nuevo, no relajar filtros ni umbral.

Prueba dos tenants con preguntas parecidas, roles distintos, locales diferentes, una nueva versión de prompt, una revocación y un corpus actualizado. El resultado esperado es miss o respuesta propia de cada ámbito. Documenta quién puede apagar la capa y cómo vaciarla sin intervención manual sobre cada entrada.