)
La compresión de prompts es la práctica de eliminar tokens de baja información de las entradas a un LLM antes de enviarlas al modelo, reduciendo el recuento de tokens entre un 20 y un 80% mientras se preserva el contenido semántico que determina la calidad de la salida.
El prompt comprimido cuesta menos procesar, responde más rápido y a menudo produce la misma o mejor salida que el original. Un prompt un 40% más corto no es un compromiso. A menudo es un prompt mejor.
TL;DR - Puntos clave
- La compresión de prompts elimina tokens redundantes y de baja información de las entradas al LLM antes de la inferencia. El modelo objetivo ve menos texto pero pierde casi nada del significado.
- LLMLingua (Microsoft Research) logra hasta 20x de compresión con menos del 2% de pérdida de calidad en benchmarks incluyendo CoQA, HotpotQA y TriviaQA. LongLLMLingua logra una mejora del rendimiento del 17,1% con compresión 4x en tareas de contexto largo.
- Selective Context, la técnica que estableció el campo, logró una reducción del contexto del 50% manteniendo un rendimiento comparable: solo 0,023 de degradación en BERTScore.
- Los pipelines RAG son el objetivo de mayor rentabilidad: las recuperaciones son de forma fiable redundantes, los ratios de compresión son más altos y el impacto en la calidad es el más bajo porque estás eliminando contexto que el modelo no estaba utilizando.
- La compresión manual: reestructurar prompts de sistema verbosos, reemplazar instrucciones en prosa con listas estructuradas, recortar ejemplos redundantes, no requiere herramientas y a menudo reduce los tokens en un 20-40% sin pérdida de calidad.
- TrustGate de NeuralTrust aplica políticas de tamaño de prompts en la capa de gateway, para que las reglas de compresión se apliquen de forma consistente en todas las aplicaciones.
¿Qué es la compresión de prompts?
El trimestre pasado, un equipo de ingeniería que conozco auditó su aplicación RAG principal. El prompt de sistema había crecido de 800 tokens en el lanzamiento a 4.200 tokens dieciocho meses después. Nadie había añadido deliberadamente 3.400 tokens. Se habían acumulado de la manera habitual: unas instrucciones para casos extremos aquí, un ejemplo aclaratorio allá, un párrafo explicando una política que había cambiado pero que nadie eliminó.
Esos 3.400 tokens extra iban en cada solicitud. A 3 dólares por millón de tokens de entrada en Sonnet 4.6, ejecutando 50.000 solicitudes al día, eso son 153 dólares diarios solo en residuos del prompt de sistema. No capacidad del modelo. No contexto útil. Residuos.
La compresión de prompts es la práctica de eliminar tokens de baja información de las entradas al LLM antes de enviarlas a un modelo mediante reestructuración manual, técnicas extractivas o modelos de compresión automatizados para reducir el coste y la latencia sin degradar la calidad de la salida.
La idea subyacente, establecida en el artículo de Selective Context (Li et al., 2023), es que no todos los tokens contribuyen por igual a la comprensión del modelo. La comprensión de un prompt por parte de un modelo de lenguaje grande está determinada principalmente por los tokens de alta información, los que tienen un significado distintivo. Los tokens de relleno (conjunciones, frases de cobertura, contexto repetido, ejemplos redundantes) a menudo pueden eliminarse con un efecto mínimo en lo que produce el modelo.
No es una compresión con pérdida en el sentido de las imágenes. No estás aproximando el prompt. Estás eliminando las partes que no estaban haciendo trabajo en primer lugar.
¿Por qué los prompts de sistema acumulan residuos con el tiempo?
Los prompts de sistema no se escriben una vez y se dejan solos. Crecen. Cada caso extremo que alguien encuentra, cada malentendido que reportó un usuario, cada requisito de cumplimiento añadido después del lanzamiento... todo se añade. Rara vez se elimina algo. El resultado, después de doce a dieciocho meses en producción, es un prompt que es tres a cinco veces más grande de lo necesario.
Los patrones son consistentes entre equipos:
1. Instrucciones redundantes.
La misma restricción expresada en tres formulaciones diferentes porque diferentes personas la añadieron en momentos distintos. "No incluyas información de contacto personal" aparece en el párrafo introductorio, de nuevo en las instrucciones de formato y de nuevo en el bloque de política final.
2. Ejemplos verbosos.
Un ejemplo trabajado de cinco oraciones que muestra el formato de salida correcto cuando un ejemplo de una oración demostraría el mismo patrón. Los ejemplos son uno de los elementos que consumen más tokens en un prompt de sistema.
3. Contexto obsoleto.
Instrucciones para gestionar una funcionalidad que fue abandonada. Explicaciones de una política que cambió. Gestión de casos extremos para un flujo de usuario que ya no existe.
4. Prosa donde una estructura sería suficiente.
Un párrafo que explica cinco reglas de formato cuando una lista de cinco puntos comunicaría las mismas reglas en la mitad de los tokens.
Nada de esto es exclusivo de equipos grandes o productos complejos. Es la entropía predeterminada de cualquier prompt que es activamente utilizado y mantenido por más de una persona.
Técnicas de compresión manual: sin herramientas
Por aquí hay que empezar. La compresión manual no requiere infraestructura, no añade nuevas dependencias y no tiene overhead de latencia. Hecha con cuidado, típicamente reduce los tokens del prompt de sistema en un 20-40% sin ninguna regresión de calidad.
Técnica 1: Auditar en busca de instrucciones duplicadas
Lee el prompt de sistema completo buscando específicamente la misma restricción o regla expresada más de una vez. Consolida la instancia más clara. Esto solo típicamente encuentra entre un 5 y un 15% de los tokens del prompt de sistema para eliminar.
Técnica 2: Reemplazar la prosa con listas estructuradas
Un párrafo que explica cinco reglas consume más tokens que una lista numerada de cinco reglas: y la lista es más fácil de seguir para el modelo. Convierte cualquier prosa instructiva a formato de viñetas o numerado.
Técnica 3: Acortar los ejemplos al mínimo que demuestre el patrón
Si tu prompt de sistema incluye ejemplos trabajados para mostrar el formato de salida, pregúntate: ¿cuál es el ejemplo más corto que sigue demostrando el patrón? Un ejemplo de un turno con una entrada corta y una salida corta demuestra el formato igual de bien que un ejemplo de cinco oraciones en la mayoría de los casos.
Técnica 4: Eliminar las instrucciones obsoletas
Revisa cada instrucción del prompt de sistema y pregúntate: ¿sigue siendo relevante para cómo se usa el sistema hoy en día? Las instrucciones obsoletas añaden tokens y pueden confundir activamente al modelo si entran en conflicto con el comportamiento actual.
Técnica 5: Usar delimitadores eficientes en tokens
Usa ### en lugar de ======= SEPARADOR DE SECCIÓN =======. P: y R: en lugar de Pregunta del usuario: y Respuesta del modelo:. Estas pequeñas sustituciones se suman a lo largo de un prompt largo.
)
Compresión automatizada: LLMLingua, Selective Context y cuándo usar cada una
La compresión manual gestiona los residuos acumulados en los prompts de sistema. La compresión automatizada gestiona el contenido dinámico (documentos recuperados, historiales de conversación largos, contexto inyectado) donde no puedes revisar manualmente cada entrada en tiempo de ejecución.
1. Selective Context
Selective Context (Li et al., 2023, arxiv:2310.06201) estableció los fundamentos de investigación del campo. Calcula la auto-información de cada unidad léxica (frases, oraciones o tokens) usando un modelo de lenguaje pequeño, y filtra las unidades cuyo contenido informativo cae por debajo de un umbral.
Los benchmarks muestran una reducción del contexto del 50% manteniendo un rendimiento comparable, con solo 0,023 de degradación en BERTScore y 0,038 en métricas de fidelidad. La técnica funciona especialmente bien con el contexto recuperado y el historial de conversación, entradas largas con contenido genuinamente redundante.
Ideal para: Compresión del historial de conversación, poda de documentos recuperados, cualquier entrada donde el contenido es variable y a menudo redundante.
2. LLMLingua
LLMLingua (Jiang et al., Microsoft Research, 2023) extendió este enfoque con un marco de compresión de lo general a lo específico. Usa un modelo de lenguaje pequeño para calcular la perplejidad de los tokens: los tokens con menor perplejidad contribuyen menos entropía informativa y pueden eliminarse de forma segura. Un controlador de presupuesto asigna ratios de compresión a diferentes segmentos del prompt.
Resultados del artículo original: hasta 20x de compresión con menos del 2% de pérdida de rendimiento en los benchmarks CoQA, HotpotQA y TriviaQA. A 5x de compresión en una carga de trabajo que gasta 20.000 dólares al mes en tokens de entrada, eso son 16.000 dólares ahorrados mensualmente sin cambios de modelo.
3. LLMLingua-2
LLMLingua-2 (Pan et al., Microsoft Research, ACL 2024) reformula la compresión como un problema de clasificación de tokens, entrenando un codificador de nivel BERT mediante destilación de datos de GPT-4. Supera a LLMLingua en todos los benchmarks con ratios de compresión equivalentes, con una inferencia más rápida. Reduce la latencia de extremo a extremo hasta 2,9x con ratios de compresión de 2x a 5x.
4. LongLLMLingua
LongLLMLingua (Jiang et al., 2024) está optimizado para escenarios de contexto largo: exactamente el caso de uso que crean los sistemas RAG. Usa compresión con consciencia de la pregunta que evalúa la relevancia entre segmentos de contexto y la consulta mediante perplejidad contrastiva. Resultados: hasta un 21,4% de mejora de rendimiento con aproximadamente 4x menos tokens en NaturalQuestions. Mejores salidas, menos tokens. Eso no es un compromiso. Es una victoria en ambas direcciones.
| Técnica | Ratio de compresión | Impacto en la calidad | Mejor caso de uso |
|---|---|---|---|
| Reestructuración manual | Reducción del 20-40% | Ninguno si se hace con cuidado | Prompts de sistema, instrucciones estáticas |
| Selective Context | ~50% de reducción | 0,023 de degradación en BERTScore | Historial de conversación, docs recuperados |
| LLMLingua | Hasta 20x | Menos del 2% en tareas de razonamiento | Contexto dinámico de propósito general |
| LLMLingua-2 | 2-5x típico | Menor que LLMLingua, más rápido | Cargas de trabajo en producción agnósticas de tarea |
| LongLLMLingua | ~4x | +17,1% en tareas de contexto largo | Pipelines RAG, contexto recuperado largo |
)
El balance calidad-compresión: lo que dice realmente la investigación
Existe una suposición común de que la compresión siempre intercambia calidad por coste. La investigación no respalda esto para la mayoría de los casos de uso en producción.
Un estudio de 2024 que comparó métodos de compresión en respuestas a preguntas sobre múltiples documentos encontró que la compresión extractiva basada en reranker logró +7,89 puntos F1 en 2WikiMultihopQA a 4,5x de compresión. La compresión mejoró la precisión filtrando el ruido. El mismo estudio mostró que la compresión abstractiva a ratios similares disminuyó el rendimiento en 4,69 puntos F1. La compresión extractiva a menudo supera a la abstractiva: estás eliminando tokens que el modelo no estaba usando bien de todas formas.
La implicación práctica: tu punto de partida importa. Un prompt de sistema verbose con instrucciones redundantes, un contexto RAG con 20 chunks recuperados cuando 5 son relevantes, un historial de conversación que preserva fielmente cada "gracias, entendido", estos son casos donde la compresión mejora tanto el coste como la calidad simultáneamente.
Dónde la compresión genuinamente intercambia calidad por coste: cadenas de razonamiento altamente estructuradas donde los pasos intermedios importan, especificaciones técnicas precisas donde se requiere una formulación específica, y código que no puede parafrasearse sin romper la funcionalidad. Estos son los casos a excluir de la compresión automatizada.
Ejemplos antes/después con recuentos de tokens
Ejemplo 1: Bloque de instrucciones del prompt de sistema
Antes (94 tokens):
Después (41 tokens):
Reducción de tokens: 56%. Contenido semántico preservado: 100%.
Ejemplo 2: Inyección de contexto RAG
Antes: 12 chunks de documentos recuperados, 3.200 tokens. Muchos chunks contienen información de fondo general en lugar de contenido específico a la consulta.
Después de LongLLMLingua (4x de compresión): 800 tokens. El contenido relevante para la consulta se preserva; el fondo general se filtra. Resultado en tareas estilo NaturalQuestions: mejora de rendimiento de hasta el 21,4%, no degradación.
Preguntas frecuentes sobre la compresión de prompts
1. ¿Qué es la compresión de prompts?
La compresión de prompts es la eliminación de tokens de baja información de las entradas al LLM antes de enviarlas a un modelo. Un proceso de compresión (ya sea reestructuración manual o un modelo automatizado como LLMLingua) identifica los tokens que contribuyen menos entropía informativa y los elimina, produciendo un prompt más corto que preserva el contenido semántico que el modelo necesita para generar una respuesta equivalente. El modelo objetivo ve menos texto, lo procesa más rápido y el resultado se factura al menor recuento de tokens.
2. ¿Cuánto puede reducir la compresión de prompts los costes de tokens?
Depende de la estructura de tu prompt y del tipo de tarea. La reestructuración manual de prompts de sistema verbosos típicamente logra una reducción del 20-40% sin pérdida de calidad. Selective Context logra aproximadamente un 50% de reducción con 0,023 de degradación en BERTScore. LLMLingua logra hasta 20x de compresión con menos del 2% de pérdida de rendimiento en benchmarks. LongLLMLingua logra 4x de compresión con una mejora del rendimiento del 17,1% en tareas de contexto largo.
3. ¿Degrada la compresión de prompts la calidad de la salida?
No siempre, y a veces la mejora. Un estudio de 2024 sobre preguntas y respuestas en múltiples documentos encontró que la compresión extractiva mejoró las puntuaciones F1 en 7,89 puntos a 4,5x de compresión al filtrar el ruido que el modelo no estaba usando eficazmente. La calidad sí se degrada para tareas que requieren cadenas de razonamiento precisas, especificaciones técnicas exactas o código que no puede parafrasearse. Estos deben excluirse de la compresión automatizada.
4. ¿Cuál es la diferencia entre LLMLingua y LLMLingua-2?
LLMLingua usa un modelo de lenguaje pequeño para calcular la perplejidad de los tokens y elimina los de baja perplejidad, logrando hasta 20x de compresión con menos del 2% de pérdida de calidad. LLMLingua-2 reformula la compresión como un problema de clasificación de tokens entrenado mediante destilación de datos de GPT-4, usando un codificador de nivel BERT. Supera a LLMLingua en todos los benchmarks con ratios de compresión equivalentes y es más rápido. Para cargas de trabajo en producción, LLMLingua-2 es la opción más práctica.
5. ¿Por dónde debo empezar con la compresión de prompts?
Empieza con la compresión manual de tus prompts de sistema. Sin herramientas necesarias, sin overhead de latencia, y es realista una reducción del 20-40% de tokens. Audita en busca de instrucciones duplicadas, convierte la prosa en listas estructuradas, acorta los ejemplos y elimina las instrucciones obsoletas. Una vez que hayas limpiado los elementos estáticos, aplica compresión automatizada a las entradas dinámicas, el contexto recuperado en los sistemas RAG es el objetivo de mayor rentabilidad.
Conclusiones clave
- La compresión de prompts elimina tokens que no están haciendo un trabajo significativo. El modelo produce una salida equivalente o mejor a una fracción del coste de entrada.
- Empieza manualmente. La mayoría de los prompts de sistema tienen entre un 20-40% de tokens que pueden eliminarse sin ninguna herramienta: instrucciones duplicadas, ejemplos verbosos, contenido obsoleto, prosa donde las listas estructuradas servirían.
- Para el contenido dinámico (contexto recuperado de RAG, historial de conversación, contexto inyectado largo) LLMLingua-2 y LongLLMLingua son herramientas listas para producción con resultados de benchmark documentados de Microsoft Research.
- La compresión a menudo mejora la calidad, no solo el coste. Filtrar el ruido del contexto RAG es una forma documentada de aumentar la precisión, no solo de reducir el gasto.
- TrustGate de NeuralTrust aplica políticas de tamaño de prompts en la capa de gateway en todas las aplicaciones conectadas, haciendo que la compresión sea sistemática.
- Para la estrategia completa de optimización de tokens en la que encaja la compresión, consulta nuestra Guía Completa de Optimización de Tokens de IA.
Artículos relacionados
Sobre el autor
Roger Howroyd es Head of Global SEO and AI en NeuralTrust, donde lidera la estrategia de búsqueda de la compañía en SEO, AEO, GEO y optimización para LLMs. Está especializado en búsqueda potenciada por IA, estrategia de contenidos, desarrollo de backlinks y SEM. Conecta en LinkedIn
NeuralTrust es una plataforma de seguridad para agentes de IA, reconocida en la Guía de Mercado de Gartner 2025 para AI Gateways y Guardian Agents, y en la KuppingerCole 2025 Leadership Compass for Generative AI Defense. Con sede en Barcelona y certificación ISO 27001.
)