Cachear respuestas de LLM: cuándo y cómo

Las llamadas a un modelo de lenguaje son, para los estándares del software, lentas y caras. Toman una cantidad notable de tiempo y cuestan dinero por petición. La caché —reutilizar un resultado almacenado en lugar de volver a hacer la llamada— es la palanca más directa que tienes sobre ambos. Pero los LLM complican la caché de maneras que la caché web ordinaria no, porque la misma pregunta puede formularse de mil maneras y el modelo puede responder de forma distinta al mismo prompt cada vez. Esta guía explica cuándo ayuda la caché, los tipos disponibles y cómo aplicarlos sin servir en silencio respuestas obsoletas o erróneas.

Por qué la caché vale la molestia

El argumento a favor de la caché se apoya en tres beneficios que se acumulan a medida que escalas.

• Coste. Cada acierto de caché es una llamada al modelo que no pagaste. A volumen, con cargas repetitivas, esta es la diferencia entre un producto viable y uno caro.
• Latencia. Devolver una respuesta almacenada es drásticamente más rápido que generar una nueva. Para productos interactivos, esa velocidad la sienten directamente los usuarios.
• Estabilidad. Una respuesta cacheada es idéntica cada vez. Para flujos de trabajo donde la consistencia importa más que la novedad, ese determinismo es una virtud, no una limitación.

El tamaño de estos beneficios depende por completo de cuán repetitiva sea tu carga de trabajo. Una app donde los usuarios hacen preguntas similares una y otra vez tiene un potencial de caché enorme. Una app donde cada petición es única casi no tiene ninguno. Saber cuál tienes es la primera decisión.

Caché por coincidencia exacta: el inicio simple y seguro

El enfoque más directo es indexar la caché por la petición exacta. Si llega de nuevo el prompt idéntico, con el modelo y los parámetros idénticos, devuelve la respuesta almacenada en lugar de llamar al modelo.

Esto es seguro y fácil de razonar porque la coincidencia es literal: no hay juicio sobre si dos peticiones son "lo bastante parecidas". Brilla para peticiones genuinamente repetidas: un prompt de sistema fijo procesando el mismo documento, una pregunta popular hecha al pie de la letra, o trabajos automatizados que reejecutan entradas idénticas. La limitación es igual de clara: el lenguaje natural es variado, y "¿Cuál es vuestra política de reembolsos?" y "¿Cómo obtengo un reembolso?" son cadenas distintas que ambas fallarán en una caché de coincidencia exacta pese a querer la misma respuesta. La caché por coincidencia exacta es el lugar correcto para empezar precisamente porque nunca sirve una respuesta errónea a la pregunta equivocada: simplemente falla más a menudo.

Caché semántica: potente y más arriesgada

La caché semántica aborda el problema de la variedad coincidiendo por significado en lugar de por texto exacto. Incrusta la petición entrante, busca una petición almacenada cuyo embedding esté lo bastante cerca y, si hay una próxima, devuelve esa respuesta cacheada.

Esto eleva drásticamente la tasa de aciertos para cargas de lenguaje natural, porque ahora las paráfrasis coinciden. También introduce un riesgo real: "lo bastante cerca" es un juicio, y un umbral de similitud fijado demasiado laxo servirá la respuesta a una pregunta parecida pero distinta. Las dos consultas "¿Cómo cancelo mi suscripción?" y "¿Cómo cambio mi suscripción?" son semánticamente próximas y sustancialmente distintas, y una caché laxa devolverá con gusto la equivocada. La caché semántica es potente, pero cambia la seguridad literal de la coincidencia exacta por cobertura. Úsala donde las respuestas erróneas-pero-plausibles sean tolerables, ajusta el umbral de forma conservadora y vigila lo que sirve.

Caché de prefijo de prompt: una ventaja a nivel de proveedor

Un tipo distinto de caché opera dentro del proveedor del modelo en lugar de delante de él. Muchos proveedores permiten cachear el procesamiento de un prefijo largo y estable —un gran prompt de sistema, un conjunto fijo de instrucciones o un bloque grande de contexto reutilizado entre muchas peticiones— para que el trabajo repetido no se rehaga en cada llamada.

Esto es especialmente valioso cuando envías el mismo contexto grande repetidamente con solo una pequeña parte variable al final, algo común en flujos de recuperación y de agentes. El beneficio es un coste y una latencia reducidos en la porción compartida, mientras que la cola variable se sigue procesando fresca, así que la respuesta final no queda obsoleta. Como la mecánica y las restricciones difieren según el proveedor, la documentación de Anthropic y OpenAI es el lugar para confirmar cómo se estructura la caché de prefijo y qué requiere. El punto clave es que esto cachea el cómputo sobre un prefijo estable, no la respuesta final, así que compone bien con la caché de respuestas anterior en lugar de competir con ella.

Qué puedes y qué no puedes cachear con seguridad

La seguridad de la caché depende de para qué es la petición, y vale la pena ser explícito sobre la distinción.

• Respuestas estables, factuales, de estilo referencia se cachean bien. Si la respuesta correcta no cambia entre dos peticiones idénticas, reutilizarla es seguro y beneficioso.
• Respuestas personalizadas o dependientes del contexto son peligrosas de cachear sin cuidado. Una respuesta calculada para los datos de un usuario nunca debe servirse a otro. Las claves de caché para cualquier cosa personalizada deben incluir la identidad o el contexto relevante, o arriesgas un grave fallo de fuga de datos.
• Respuestas sensibles al tiempo se vuelven obsoletas. Cualquier cosa que dependa del estado actual tiene una vida útil, y la caché debe respetarla mediante expiración.
• Salidas intencionadamente variadas o creativas quizá no quieran caché en absoluto. Si los usuarios esperan una versión fresca cada vez, una repetición cacheada socava el propósito.

La regla transversal: una clave de caché debe capturar todo lo que debería cambiar la respuesta. Olvida incluir el usuario, el contexto o los parámetros, y habrás construido un fallo que sirve la respuesta de una persona a otra.

Mantener la caché fresca

Una caché que nunca expira se convierte en una fuente de respuestas erróneas. Dos mecanismos la mantienen honesta. Primero, la expiración basada en tiempo: fija una vida útil apropiada a cuán rápido cambia la información subyacente, corta para contenido volátil y larga para material de referencia estable. Segundo, la invalidación al cambiar: cuando los datos fuente detrás de una respuesta cacheada se actualizan, la entrada cacheada debe limpiarse para que la siguiente petición la regenere. El fallo clásico es actualizar tu base de conocimiento y seguir sirviendo respuestas construidas desde la versión antigua. Decide tu política de frescura de forma deliberada para cada caché, en lugar de dejar que "para siempre" sea el valor por defecto accidental.

Un orden de adopción práctico

Despliega la caché en orden creciente de riesgo. Empieza con la caché por coincidencia exacta, que nunca puede servir una respuesta errónea a la pregunta equivocada y captura de inmediato las peticiones genuinamente repetidas. Añade la caché de prefijo del proveedor donde reutilizas contexto grande y estable, ya que es una ganancia de coste y latencia de bajo riesgo. Recurre a la caché semántica solo una vez que entiendas tu tráfico y puedas ajustar y monitorizar un umbral de similitud, porque es el único enfoque que puede servir con confianza la respuesta equivocada. En cada capa, construye claves de caché que incluyan todo lo que afecta a la respuesta, y fija una política de frescura antes de lanzar, no después de que una respuesta obsoleta te avergüence.

En resumen

La caché es la palanca más directa sobre el coste y la latencia de un LLM, pero los modelos de lenguaje la hacen más delicada que la caché ordinaria porque la formulación varía y las respuestas pueden ser personalizadas o sensibles al tiempo. Empieza con la caché por coincidencia exacta por su seguridad literal, suma la caché de prefijo del proveedor para contexto reutilizado, y adopta la caché semántica con cuidado donde las respuestas plausibles-pero-erróneas sean tolerables. Sobre todo, haz que cada clave de caché capture lo que debería cambiar la respuesta y dale a cada entrada una política de frescura. Hecha con esa disciplina, la caché es una victoria grande y segura; hecha sin cuidado, es una máquina silenciosa de servir rápido la respuesta equivocada.