En esta lección, vamos a construir un agente CAG, y verás que es sorprendentemente sencillo una vez que conoces el método correcto. La técnica específica que utilizaremos se llama Prompt Caching.
¿Qué es el «Prompt Caching»?
Tanto OpenAI como Anthropic (el creador de Claude) utilizan esta técnica. Significa que si envías un prompt muy largo, el proveedor de la API «guarda en caché» la mayor parte de ese prompt automáticamente. La próxima vez que envíes una pregunta que comience con el mismo texto largo, el sistema reconocerá la parte que ya tiene guardada, la recuperará de la caché y solo procesará (y te cobrará por) la parte nueva de la pregunta.
Esto nos permite implementar CAG de manera muy directa.
Parte 1: Implementación con OpenAI (El Método Automático)
OpenAI hace que este proceso sea increíblemente fácil, ya que el cacheo es automático.
Reglas Clave de OpenAI:
- El cacheo se activa para prompts de más de 1024 tokens.
- Para que la caché funcione, el inicio del prompt (el «prefijo») debe ser idéntico en cada nueva pregunta.
Construyendo el Flujo en n8n
- Entrada de Datos: Usaremos un
Chat Trigger
para las preguntas y un nodo deGoogle Drive
para descargar nuestro documento de ejemplo (el informe de Netflix de 84 páginas). - Extracción de Texto: Usamos un nodo
Extract from File
para convertir el PDF en texto plano. - El Nodo
OpenAI
: Aquí ocurre la magia.- Seleccionamos la acción
Message a model
y elegimos un modelo comogpt-4o-mini
. - Estructura del Prompt: Este es el paso más importante. Construimos nuestro prompt de la siguiente manera:
Usa los siguientes documentos para determinar una respuesta relevante. No inventes información. ---DOCUMENTO--- {{ $json.text_del_documento }} ---FIN DEL DOCUMENTO--- Pregunta del usuario: {{ $json.pregunta_del_usuario }}
Con esta estructura, la parte larga y estática (el documento) actúa como el «prefijo» que OpenAI guardará en caché. La pregunta del usuario es la única parte que cambia. - Seleccionamos la acción
Puesta a Prueba y Verificación
- Primera Ejecución: Hacemos una pregunta, como «¿cuáles fueron los ingresos por streaming en 2024?». La primera vez, el proceso es más lento porque OpenAI tiene que procesar el documento completo.
- Análisis de la Salida: Para ver el cacheo, debemos desactivar la opción «Simplify Output» en el nodo de OpenAI. Al inspeccionar la salida, veremos un campo como este:
usage.cache.num_tokens_cached: 60544
Esto nos confirma que de los ~60,818 tokens totales, la gran mayoría fue guardada en caché.
- Segunda Ejecución: Si hacemos otra pregunta, la respuesta será mucho más rápida y el coste significativamente menor, porque OpenAI solo procesará los tokens de la nueva pregunta, recuperando el resto de la caché.
Parte 2: Implementación con Anthropic/Claude (El Método Manual con HTTP)
El nodo nativo de Anthropic en n8n (a fecha de agosto de 2025) no soporta la función de cacheo. Por lo tanto, debemos hacerlo manualmente a través de una llamada directa a su API usando el nodo HTTP Request
.
Construyendo el Flujo en n8n
- Configuración del Nodo
HTTP Request
:- URL:
https://api.anthropic.com/v1/messages
- Method:
POST
- Authentication:
Header Auth
. Usa una credencial predefinida de Anthropic con tu API Key. - Headers: Debes añadir dos cabeceras:
anthropic-version
:2023-06-01
Content-Type
:application/json
- URL:
- Cuerpo de la Petición (JSON): Aquí es donde le decimos a Anthropic que use la caché.JSON
{ "model": "claude-3-5-sonnet-20240620", "messages": [ { "role": "user", "content": "{{ JSON.stringify($json.texto_del_documento + '\n\nPregunta: ' + $json.pregunta_del_usuario) }}" } ], "cache_control": { "type": "ephemeral" } }
El parámetro clave escache_control: { "type": "ephemeral" }
. Esto le indica a la API de Anthropic que guarde en caché el contenido de esta petición.
Lección del Mundo Real: Los Límites de Tasa (Rate Limits)
Al probar este flujo con nuestro documento de 84 páginas, es posible que te encuentres con un error de límite de tasa.
- ¿Qué Ocurre? Aunque los modelos como Claude 3.5 Sonnet tienen una ventana de contexto enorme (200,000 tokens), los planes de API a menudo tienen un límite de cuántos tokens puedes procesar por minuto. Nuestro documento, aunque cabe en la ventana de contexto, puede superar el límite de procesamiento por minuto de nuestro plan.
- Lección Aprendida: CAG es potente, pero siempre debes tener en cuenta los límites de tu plan de API. Para documentos extremadamente grandes que superen estos límites, un sistema RAG (que procesa chunks más pequeños) podría seguir siendo la arquitectura más robusta y fiable.
Conclusión
Hemos implementado con éxito un sistema CAG de dos maneras diferentes. Hemos aprendido que es una alternativa a RAG sorprendentemente fácil de configurar, especialmente con OpenAI, y es ideal para casos de uso donde la velocidad es crítica y se trabaja con documentos grandes pero finitos. Sin embargo, también hemos descubierto sus limitaciones prácticas, como los límites de tasa, que nos recuerdan que no hay una solución única para todos los problemas. La elección entre RAG y CAG siempre dependerá de las necesidades específicas de tu proyecto.