AWS ha presentado un nuevo patrón para reducir las facturas de recuperación de IA en Amazon Bedrock. Si creas aplicaciones de generación aumentada por recuperación (RAG), esta configuración puede reducir tu gasto en tokens, pero tus usuarios podrían esperar más para recibir respuestas.
En una publicación del 2026-08-21 en el AWS Machine Learning Blog, AWS mostró cómo situar un modelo pequeño entre la recuperación y la respuesta final. En lugar de enviar fragmentos de texto largos a un modelo grande, un modelo rápido extrae primero únicamente las frases relevantes exactas.
Cómo funciona la configuración
El diseño de referencia se ejecuta dentro de una función AWS Lambda utilizando la Amazon Bedrock Converse API. Necesitas una cuenta de AWS, permisos de IAM y acceso a los modelos.
El pipeline divide el trabajo entre dos modelos:
– Claude Haiku actúa como compresor, seleccionando fragmentos de texto literales que coinciden con la pregunta del usuario.
– Claude Sonnet lee únicamente el texto recortado y redacta la respuesta final.
AWS probó tres enfoques en más de 500,000 documentos de nueve tipos de fuentes empresariales y 500 preguntas en 10 categorías: RAG base, compresión sola y rerank más compresión.
Qué muestran las cifras
Según AWS, reducir el contexto genera un gran ahorro:
– Volumen de tokens: Cae al 12% con compresión (8.6x menos tokens) y al 10% con rerank más compresión (10.1x menos tokens), frente al 100% del RAG base.
– Coste total: Cae al 67% (un ahorro del 33%) y al 64% (un ahorro del 36%).
– Puntuación de calidad: Se mantiene cerca del valor base (97.5% y 97.6% frente al 100%), según un evaluador LLM que puntuó corrección, completitud, precisión de citas y concisión.
– Tasa de alucinación: Cae del 51% en el modelo base al 44% con compresión y al 38% con reranking, con la fidelidad registrada por separado.
– Latencia: Aumenta un +19% con compresión y un +12% con rerank más compresión. La velocidad se resiente.
Las afirmaciones que deberías comprobar tú mismo
Estas cifras proceden exclusivamente de pruebas internas de AWS en un único corpus evaluado por un evaluador LLM. Nadie fuera de AWS las ha verificado de forma independiente, y no suponen una garantía de rendimiento para otras cargas de trabajo, niveles de precios o modelos. Añadir otra llamada a un modelo crea un nuevo punto de fallo. El compresor podría descartar accidentalmente datos vitales, debilitar las citas o fallar ante fragmentos mal estructurados e inyecciones de prompts.
Cómo probar este patrón
No cambies aún tu pipeline de producción. Haz pruebas primero con tus propios datos.
Configura un conjunto fijo de consultas de prueba con tu recuperador, ajustes de top-k, fragmentación e identificadores de modelo. Ejecuta las consultas a través de las tres vías: RAG base, compresión y rerank más compresión. Registra los tokens de entrada, tokens de salida, coste de Lambda, coste del modelo y la latencia tanto p50 como p95. Lo más importante: revisa directamente los fragmentos comprimidos. Comprueba qué se descarta. Si la latencia en cola se dispara o se pierde información clave, mantener tu vía de RAG base sigue siendo la opción más segura.