Reducir costos de RAG en Amazon Bedrock con compresión sensible a la consulta

Resumen ejecutivo

La entrada de tokens al modelo base en cada llamada representa una parte significativa del costo cuando se ejecutan aplicaciones de Retrieval Augmented Generation (RAG) a escala. Amazon Bedrock permite construir flujos RAG abiertos y componibles; una optimización útil es aplicar una etapa de compresión sensible a la consulta tras la recuperación y antes de la generación final. En este patrón, un modelo más pequeño filtra fragmentos recuperados, dejando solo los pasajes textuales relevantes que envía el modelo primario. El resultado: menos tokens procesados por el modelo caro, ahorro en costos y, como beneficio secundario, menos contexto irrelevante que puede inducir a hallucinations.

¿Qué es la compresión sensible a la consulta?

Es una etapa de post-recuperación que toma la consulta del usuario y los fragmentos devueltos por el retriever y los pasa a un modelo ligero. Ese modelo emite únicamente las porciones textuales (spans) que son textual y directamente relevantes a la consulta. Sólo ese contexto comprimido llega al modelo primario para la generación de la respuesta.

En la práctica descrita por AWS, se usa un par de modelos de la misma familia (por ejemplo, Anthropic Claude Haiku como compresor y Anthropic Claude Sonnet como modelo primario), aunque el patrón es compatible con otros pares de modelos disponibles en Amazon Bedrock.

Arquitectura general

• El usuario envía una consulta a la aplicación.
• La aplicación la embebe y el retriever (por ejemplo, una Amazon Bedrock Knowledge Base respaldada por Amazon OpenSearch Serverless) devuelve las top-k chunks.
• Esos fragmentos y la consulta se envían a una función AWS Lambda.
• Dentro de la Lambda se realiza una primera llamada a un modelo pequeño a través de la API Converse de Amazon Bedrock: la llamada de compresión.
• El modelo pequeño devuelve el contexto comprimido (solo los pasajes relevantes en forma literal).
• La Lambda hace la llamada final al modelo primario con la consulta y el contexto comprimido: la llamada de respuesta.
• El modelo primario genera y devuelve la respuesta al usuario.

Esta arquitectura añade una sola etapa (la compresión) al flujo RAG estándar y puede ejecutarse enteramente dentro de una Lambda, manteniendo la integración sencilla y componible con otros servicios en AWS.

Economía del patrón: cómo y por qué ahorra

El ahorro depende de dos factores principales:

1. La relación de precios por token entre el modelo pequeño y el modelo primario en Amazon Bedrock.
2. La relación de compresión que logra el modelo pequeño (cuánto reduce los tokens recuperados antes de enviarlos al modelo grande).

Si R son los tokens recuperados, c la ratio de compresión (c > 1), A los tokens de salida de la respuesta, y P_small_in / P_small_out y P_large_in / P_large_out los precios por token de entrada y salida de los modelos pequeño y grande respectivamente, entonces el flujo con compresión introduce un costo adicional menor (lectura de R tokens por el modelo pequeño) y reduce significativamente los tokens que el modelo primario lee (de R a R/c). Porque el modelo pequeño suele costar menos por token, eliminar contexto irrelevante antes de la llamada cara resulta en ahorro neto.

No es una fórmula mágica: el beneficio real depende del balance entre el costo de la llamada de compresión y la reducción efectiva de tokens que evita la llamada al modelo primario.

Latencia y trade-offs operativos

Agregar una llamada de compresión introduce latencia adicional porque se realiza una llamada extra al modelo pequeño. En muchos casos, esta latencia es aceptable frente a los ahorros económicos; en otros, especialmente en aplicaciones con requisitos estrictos de tiempo real, puede que no convenga. La implementación en Lambda permite mantener la lógica cercana al resto de la aplicación y controlar concurrency, timeouts y paralelismos para mitigar impacto de latencia.

La decisión de aplicar compresión debe basarse en pruebas reales del workload: medir cuánto comprime el modelo pequeño, el costo por token de cada modelo en su región de AWS y el impacto en el tiempo final de respuesta.

Calidad de respuestas y riesgo de pérdida de información

Para que la compresión sea viable, el modelo pequeño debe preservar los fragmentos verbatim relevantes que el modelo primario necesita para razonar. AWS evaluó calidad comparando respuestas con y sin compresión; el patrón pretende mantener la calidad de respuesta mientras reduce tokens de entrada. Además, al eliminar contexto irrelevante se reduce la superficie para que el modelo genere hallucinations.

Como práctica recomendada, evaluar en su propio corpus (documentación técnica, contratos, conocimiento local) y con métricas de calidad relevantes para el negocio antes de adoptar la compresión en producción.

Integración con otras capacidades de Amazon Bedrock

El patrón de compresión puede complementarse con:

• Knowledge Bases de Amazon Bedrock como retriever gestionado.
• Rerank API para ordenar resultados antes de la compresión y mejorar la precisión de lo que se pasa al compresor.
• Prompt caching e Intelligent Prompt Routing para optimizar costes y latencia adicionales.

Estas capas pueden combinarse para conseguir una reducción compuesta de tokens y costos.

Requisitos y pasos prácticos para implementar

Para desplegar este patrón en AWS, los pasos básicos incluyen:

• Tener una cuenta activa de AWS.
• Crear un rol de IAM para la función Lambda con permisos para llamar a Amazon Bedrock (y otros servicios necesarios).
• Solicitar acceso en la consola de Amazon Bedrock a los modelos necesarios en su región (por ejemplo, Claude Haiku y Claude Sonnet si se usan estos modelos).

La lógica de compresión y de llamada al modelo primario puede residir dentro de una sola Lambda que usa la API Converse de Amazon Bedrock.

Recomendaciones para tomadores de decisión en Latinoamérica

• Prioricen pruebas de compresión sobre muestras reales de su corpus y flujos de consultas. Los patrones de lenguaje y la densidad de información varían por dominio y región.
• Evalúen la relación costo-beneficio considerando precios locales y latencia: algunos casos de uso (atención al cliente asincrónica, búsqueda documental) toleran mayor latencia y se benefician más.
• Aprovechen Knowledge Bases gestionadas si buscan reducir la complejidad operativa; la compresión puede añadirse como capa ligera encima.
• Consideren la gobernanza y cumplimiento local: reducir contexto también puede limitar exposición de datos sensibles en la llamada al modelo primario.

Conclusión

La compresión sensible a la consulta es una forma práctica y compatible con Amazon Bedrock para reducir tokens de entrada al modelo primario en flujos RAG. Al introducir una llamada a un modelo más económico que elimina fragmentos irrelevantes, las organizaciones pueden reducir costos y, adicionalmente, disminuir riesgos de hallucination. Como con toda optimización, la implementación debe validarse con mediciones de compresión, costos por token y evaluación de calidad en su propio dominio antes de adoptarla en producción.