Latencia, coste y caché: la economía de un RAG

La entrega anterior dejó el plano de una arquitectura de producción y un presupuesto de latencia por etapas. Toca ahora la otra mitad de la ecuación: qué cuesta cada consulta, por qué la factura casi nunca está donde uno cree, y qué se puede recortar con caché sin que la calidad se resienta.

Dónde se va el tiempo

Conviene separar dos relojes que se confunden con frecuencia. Uno es la latencia total: desde que llega la petición hasta que el último token sale. Otro es el tiempo hasta el primer token, que es lo que el usuario percibe como «tarda» cuando la respuesta va en streaming. Optimizar el primero cuando el usuario sólo nota el segundo es esfuerzo mal dirigido.

Repasando el recorrido de una consulta, el reparto típico es este. El embedding de la pregunta cuesta decenas de milisegundos: es un texto corto y una sola llamada. La búsqueda en el vectorial también son decenas de milisegundos si el índice está bien dimensionado y cabe en memoria; cuando empieza a tardar cientos, casi siempre es porque el índice ha crecido más allá de la RAM disponible o porque un filtro de metadatos muy selectivo obliga al motor a recorrer más candidatos de los que su índice aproximado esperaba.

El reranking es la primera etapa cara de verdad. Un cross-encoder (el modelo que puntúa la pareja pregunta-fragmento leyendo las dos a la vez, frente al bi-encoder que las codifica por separado) tiene que procesar cada candidato de forma independiente. Reordenar cincuenta candidatos cuesta del orden de cientos de milisegundos, y el coste crece de forma casi lineal con el número de candidatos. Es el parámetro más directo que tienes para comprar latencia: pasar de cincuenta a veinte candidatos recorta esa etapa a menos de la mitad, con una pérdida de calidad que hay que medir en el golden dataset antes de decidir.

Y luego está la generación, que domina. El tiempo hasta el primer token depende sobre todo de cuántos tokens de entrada tiene que procesar el modelo, y el resto depende de cuántos tokens escribe. Aquí hay una consecuencia poco intuitiva: meter más fragmentos en el contexto no sólo cuesta más dinero, también retrasa el primer token. El contexto no es gratis en ninguno de los dos ejes.

Dónde se va el dinero

La factura de un RAG tiene cuatro partidas, y en la inmensa mayoría de los sistemas están muy desequilibradas.

• Tokens de entrada del generador. Casi siempre la partida dominante, y con diferencia. Es aritmética simple: la pregunta del usuario son decenas de tokens, pero los fragmentos recuperados son miles. Si envías ocho fragmentos de quinientos tokens, estás pagando cuatro mil tokens de entrada por consulta más las instrucciones del sistema. La pregunta es ruido estadístico dentro de esa cifra.
• Tokens de salida. Menos volumen, pero precio por token varias veces superior al de entrada en la mayoría de proveedores. En respuestas cortas —lo habitual en atención al cliente— siguen quedando por debajo de la entrada. En respuestas largas o en formatos estructurados extensos, pueden acercarse.
• Embeddings. En la ruta de consulta son casi despreciables: un texto corto por pregunta, a un precio por millón de tokens muy inferior al de un modelo generador. En la ruta de indexación son un coste real pero de una sola vez por versión de documento, salvo que reindexes con frecuencia o cambies de modelo de embeddings, que obliga a recalcularlo todo.
• Infraestructura. Base vectorial, almacén de documentos, cómputo de la API, cola, observabilidad. Es un coste fijo mensual que no escala con la consulta sino con el tamaño del corpus y con el pico de tráfico. En sistemas de bajo volumen puede ser la partida mayor de todas; en sistemas de alto volumen se diluye.

Un cálculo por consulta, en órdenes de magnitud

No voy a dar tarifas, porque cambian cada pocos meses y quedarían obsoletas antes de que leas esto. Lo que no cambia es la estructura del cálculo, y esa sí conviene tenerla presente. Llamemos Pe al precio por millón de tokens de entrada y Ps al de salida.

Tokens de entrada por consulta
  = instrucciones del sistema      (~   300)
  + k fragmentos x tamaño medio    (8 x 500 = 4.000)
  + pregunta e historial           (~   200)
  ≈ 4.500 tokens

Tokens de salida por consulta      ≈   300 tokens

Coste generación = 4.500/1e6 x Pe  +  300/1e6 x Ps
Coste embedding consulta ≈ 30/1e6 x Pemb   (dos órdenes de magnitud menor)

Con precios típicos de un modelo de gama media, el resultado cae
en el orden de fracciones de céntimo por consulta.
Con un modelo de gama alta, en el orden de céntimos.

La utilidad de escribirlo así no es el número final, sino ver qué palanca mueve qué. Reducir k de ocho a cinco fragmentos recorta el coste dominante en más de un tercio y además acelera el primer token. Cambiar de modelo generador puede multiplicar o dividir la factura por un factor grande sin tocar una línea del pipeline. Reducir el tamaño medio del fragmento tiene el mismo efecto que reducir k, con la diferencia de que afecta también a la calidad de la recuperación, así que no es una palanca libre.

Multiplica ese coste por el volumen mensual y compáralo con el coste fijo de infraestructura. El punto en que el variable supera al fijo es la frontera a partir de la cual merece la pena invertir en cachés y modelos más pequeños; por debajo, optimizar tokens es teatro.

Las tres cachés

Hay tres mecanismos distintos que se llaman «caché» en un RAG y que no compiten entre sí: se acumulan.

1. Caché exacta de respuestas

La clave es un hash de la pregunta normalizada más todo lo que cambia la respuesta: identificador de tenant, conjunto de permisos del usuario, versión del corpus, versión del prompt y modelo. El valor es la respuesta completa con sus citas. Un acierto salta el recorrido entero y devuelve en milisegundos.

Es la caché más segura y la más aburrida. Su tasa de acierto depende por completo del patrón de uso: en un asistente de soporte con preguntas muy repetidas puede ser alta; en un buscador interno donde nadie escribe dos veces lo mismo es prácticamente cero. Mídela antes de fantasear con ella.

Lo delicado no es la caché, es la invalidación. Si un documento cambia, todas las respuestas cacheadas que lo citaban están potencialmente obsoletas. Funcionan dos estrategias: un tiempo de vida corto y agresivo, o invalidación por etiquetas, guardando junto a cada respuesta los documentos que la fundamentan y purgando por documento al reindexar. La segunda es mejor y cuesta más.

2. Caché semántica

Aquí la clave no es la pregunta literal sino su embedding. Ante una consulta nueva se busca en un pequeño índice de preguntas ya respondidas y, si la más parecida supera un umbral de similitud, se devuelve su respuesta sin ejecutar el pipeline. La promesa es evidente: «¿cuál es el plazo de devolución?» y «¿cuántos días tengo para devolver un pedido?» son la misma pregunta y deberían compartir respuesta.

La promesa es real y el riesgo también. La similitud de embeddings mide parecido temático, no equivalencia de pregunta, y hay pares de consultas muy próximas en el espacio vectorial cuya respuesta correcta es distinta o incluso opuesta. «¿Puedo cancelar el plan anual?» y «¿puedo cancelar el plan mensual?» se parecen muchísimo. Igual ocurre con negaciones, cambios de año y nombres propios sustituidos.

Reglas para que no te estropee el sistema:

• Umbral alto y calibrado con datos reales, no elegido a ojo. Se calibra midiendo cuántos aciertos de caché habrían devuelto una respuesta incorrecta sobre el golden dataset.
• La clave incluye siempre el tenant y los permisos. Una caché semántica compartida entre usuarios con distinto nivel de acceso es una fuga de datos, no una optimización.
• Desactivada para consultas con entidades específicas —fechas, importes, códigos de producto, nombres— donde un pequeño cambio léxico invierte la respuesta. Detectarlas con una regla sencilla es suficiente.
• Registrada en la traza. Toda respuesta servida desde caché semántica debe quedar marcada como tal, o el día que aparezca una respuesta rara nadie sabrá por qué.

3. Caché de contexto del proveedor

Varios proveedores de modelos permiten marcar un prefijo del prompt como cacheable: las instrucciones del sistema, los ejemplos, un bloque de contexto estable. En consultas posteriores ese prefijo no se vuelve a procesar entero y se factura a una tarifa reducida, además de reducir el tiempo hasta el primer token.

Es la caché de menor riesgo, porque no cambia la respuesta: sólo evita recomputar algo idéntico. Su rendimiento depende de una decisión de diseño concreta, que es poner al principio del prompt lo que no cambia y al final lo que cambia. Un prompt que intercala fragmentos recuperados entre las instrucciones del sistema desperdicia esta caché por completo. Activación, tamaño mínimo de prefijo y duración varían por proveedor, pero el principio de ordenación es universal.

Límites y contraindicaciones

La optimización de coste tiene una trampa reconocible: casi todas las palancas que abaratan también degradan algo. Menos fragmentos es menos coste y menos recall. Un modelo más pequeño es más barato y menos fiel al contexto. Un umbral de caché semántica más laxo es más ahorro y más respuestas equivocadas. Ninguna de estas decisiones debería tomarse sin pasar el golden dataset antes y después, que es exactamente para lo que servía el trabajo de la entrega 40.

Y hay un coste que no aparece en ninguna factura: el de mantener tres cachés con su invalidación. Empieza por la caché de contexto del proveedor, que es gratis en complejidad. Añade la exacta cuando midas repetición real. Deja la semántica para cuando el volumen justifique el riesgo y tengas evaluación automatizada para vigilarla.

Qué viene ahora

La siguiente entrega entra en el problema que más desconfianza genera en cualquier sistema RAG: las alucinaciones. No como categoría única, sino como cuatro fallos distintos con cuatro diagnósticos y cuatro remedios que no se pueden intercambiar. La parte útil no es la lista de causas, sino el procedimiento para saber, ante una respuesta mala concreta, cuál de las cuatro tienes delante.

Los tres libros gratuitos de los que nace esta serie están disponibles en PDF y EPUB: RAG para tu negocio (nivel básico), RAG por dentro (intermedio) y RAG en producción (avanzado).

Aviso de contenido generado con inteligencia artificial.
Este artículo ha sido redactado con la asistencia de sistemas de inteligencia artificial y revisado antes de su publicación. Se informa de ello de forma expresa en cumplimiento de la normativa vigente sobre transparencia en el uso de IA.