Cómo la ingeniería de contexto reduce el gasto de tokens
La ingeniería de contexto es la disciplina de decidir qué va realmente en un prompt antes de que llegue a Claude.
Se sitúa aguas arriba de la redacción del prompt y la selección del modelo, y a menudo es la palanca individual más grande que tiene un equipo sobre el costo de la API.
Un equipo que escribe un gran prompt pero pega un repositorio completo ya ha perdido la mayoría de los ahorros disponibles.
Esta página construye el modelo mental detrás de tres técnicas que se repiten a lo largo de esta sección: prompting de contexto mínimo, sumarización y selección de niveles de modelos.
Cada una de estas reduce el gasto de tokens, y cada una lo hace a través de un mecanismo diferente, por lo que vale la pena entenderlas como palancas distintas en lugar de una idea difusa de "ser eficiente".
Resumen
- Idea Central: El gasto de tokens es una función de lo que eliges enviar a Claude, no solo de cómo formulas la solicitud, por lo que recortar, condensar y enrutar el contexto son controles de costos directos.
- Por Qué Importa: Los tokens de entrada se facturan en cada llamada, y los contextos grandes también ralentizan las respuestas y pueden diluir la atención del modelo en las partes que importan.
- Conceptos Clave: prompting de contexto mínimo, sumarización, selección de niveles de modelos, recorte de grafos de dependencias, presupuesto de ventana de contexto.
- Cuándo Usar: Cualquier sistema de producción que envíe más de unos pocos cientos de tokens de material de apoyo por llamada, especialmente bucles de agentes, pipelines de RAG y asistentes de código.
- Limitaciones / Compensaciones: Recortar el contexto de forma demasiado agresiva puede eliminar información que Claude realmente necesitaba, por lo que cada técnica aquí intercambia cierto riesgo de sub-contexto por una reducción garantizada de costos.
- Temas Relacionados: recorte de grafos de dependencias, sumarización pre-llamada, el parámetro de esfuerzo, corrupción de contexto.
Fundamentos
Cada solicitud a Claude tiene un costo que escala con el número de tokens de entrada y tokens de salida involucrados.
Los tokens de entrada incluyen el prompt del sistema, el historial de la conversación, cualquier documento recuperado y cualquier resultado de herramienta inyectado en el contexto.
La mayoría de los equipos se centran primero en la longitud de la salida o en la elección de un modelo más económico, pero para muchas cargas de trabajo, el lado de entrada del balance es mayor y más fácil de controlar.
El prompting de contexto mínimo es la práctica de enviar solo los fragmentos específicos que una tarea necesita en lugar del archivo fuente completo, el documento completo o el repositorio completo del que se extrajeron.
La sumarización es la práctica de usar un modelo económico y rápido para comprimir un documento largo en una representación más corta antes de que esa representación se envíe a un modelo más costoso para el trabajo real.
La selección de niveles de modelos es la práctica de enrutar una solicitud al modelo más económico de una línea, como Claude Haiku 4.5, que aún puede cumplir con un estándar de calidad, y reservar un modelo más potente como Claude Opus 4.8 para las solicitudes que realmente lo necesitan.
Una analogía simple: piensa en la ventana de contexto de Claude como un escritorio.
Puedes apilar todo el archivador sobre el escritorio para que nada se pierda nunca, o puedes sacar solo las carpetas relevantes para la tarea que tienes delante.
El segundo enfoque cuesta menos de preparar y también mantiene el escritorio utilizable.
# Una llamada de contexto mínimo: solo la función relevante, no todo el archivo
prompt = f"""Revisa esta función en busca de un error de puntero nulo.
{relevant_function_source}
"""Mecánicas e Interacciones
Estas tres técnicas actúan en diferentes puntos del ciclo de vida de una solicitud, y comprender dónde se sitúa cada una aclara cuándo recurrir a ella.
El prompting de contexto mínimo actúa en el tiempo de ensamblaje: antes de construir la cadena del prompt, decides qué fragmentos, filas o párrafos son relevantes y excluyes el resto.
Esta suele ser la técnica de mayor apalancamiento porque elimina los tokens por completo en lugar de comprimirlos, por lo que no hay una llamada API secundaria ni costo de compresión.
La compensación es que requiere un trabajo inicial para saber qué es relevante, ya sea un paso de búsqueda, un grafo de dependencias o un índice de recuperación.
La sumarización actúa en el tiempo de preprocesamiento: existe un documento largo, es demasiado grande o demasiado poco enfocado para enviarlo completo, y un modelo más económico lo reduce antes de que el modelo costoso lo vea.
Esto agrega una llamada API adicional, pero esa llamada utiliza un modelo económico, por lo que el costo neto sigue siendo menor que enviar el documento completo al modelo costoso.
La sumarización es más valiosa cuando el mismo documento largo se referenciará en muchas llamadas, porque el costo de la sumarización se paga una vez y los ahorros se acumulan.
La selección de niveles de modelos actúa en el tiempo de enrutamiento: para cada solicitud entrante, se toma una decisión sobre qué modelo en la línea debe manejarla.
def choose_model(task_complexity: str) -> str:
if task_complexity == "simple_lookup":
return "claude-haiku-4-5"
if task_complexity == "standard_reasoning":
return "claude-sonnet-5"
return "claude-opus-4-8" # razonamiento multi-paso, salida de alto riesgoLas tres técnicas se componen bien juntas.
Un pipeline podría usar prompting de contexto mínimo para seleccionar archivos relevantes, sumarización para condensar cualquier archivo que aún sea demasiado largo y selección de niveles de modelos para decidir si la llamada final necesita Sonnet 5 o puede ejecutarse en Haiku 4.5.
Ninguna de ellas requiere las otras, pero apilarlas produce ahorros multiplicativos, no aditivos, porque cada técnica reduce una dimensión diferente del gasto.
Consideraciones Avanzadas y Aplicaciones
A escala, estas técnicas dejan de ser trucos aislados y se convierten en decisiones políticas que un equipo documenta y revisa.
Un presupuesto de ventana de contexto, por ejemplo, establece un límite estricto sobre cuánto contexto se le permite acumular a un agente antes de que algo tenga que ceder, ya sea sumarización, truncamiento o finalización de la sesión.
Las decisiones de selección de niveles de modelos se benefician de una lista de verificación explícita en lugar de llamadas ad hoc, porque "¿necesita esta tarea Opus?" es una pregunta que diferentes ingenieros responderán de manera inconsistente sin criterios compartidos.
El prompting de contexto mínimo para tareas de código escala aún más con grafos de dependencias: en lugar de elegir fragmentos manualmente, un grafo de importaciones y sitios de llamadas te dice exactamente qué archivos son estructuralmente relevantes para un cambio, lo que escala a bases de código grandes de una manera que la selección manual no lo hace.
Vale la pena ser honesto en que las tres técnicas pueden llevarse demasiado lejos.
Eliminar demasiado contexto, comprimir en exceso un documento o enrutar una tarea genuinamente difícil a un modelo económico produce un ahorro de costos que se paga en respuestas incorrectas, y una respuesta incorrecta que debe ser rehecha es más costosa que los tokens que ahorró.
| Técnica | Fortaleza | Debilidad | Mejor Ajuste |
|---|---|---|---|
| Prompting de contexto mínimo | Elimina tokens por completo, sin llamada adicional | Requiere saber qué es relevante | Revisión de código, preguntas y respuestas dirigidas, RAG |
| Sumarización | Comprime documentos largos reutilizables | Agrega una llamada, puede perder matices | Documentos largos referenciados repetidamente |
| Selección de niveles de modelos | Empareja el costo con la dificultad de la tarea | El nivel incorrecto degrada la calidad | Cargas de trabajo de alto volumen y dificultad mixta |
El hilo conductor en las tres es que son decisiones tomadas antes de la llamada al modelo costoso, no después.
Optimizar la redacción de un prompt después de que el contexto ya está inflado recupera muchos menos costos que decidir qué pertenece al prompt en primer lugar.
Conceptos Erróneos Comunes
- "Una ventana de contexto más grande significa que no necesito recortar el contexto." Una ventana más grande cambia lo que puedes enviar, no lo que deberías enviar; el contexto innecesario todavía cuesta tokens y aún puede degradar la calidad de la respuesta.
- "La sumarización siempre ahorra dinero." Solo ahorra dinero cuando el documento sumarizado se reutiliza en múltiples llamadas o es lo suficientemente grande como para que el costo de la llamada de sumarización en sí sea pequeño en comparación.
- "La selección de niveles de modelos significa usar siempre el modelo más económico." La selección de niveles significa emparejar el costo con la dificultad; enrutar una tarea genuinamente difícil a un modelo económico produce respuestas incorrectas y repeticiones, que cuestan más que los tokens ahorrados.
- "La ingeniería de contexto es solo ingeniería de prompts con un nuevo nombre." La ingeniería de prompts optimiza la redacción y la estructura; la ingeniería de contexto decide qué información entra en el prompt en primer lugar, lo cual es una decisión separada y anterior.
- "Recortar el contexto es arriesgado, por lo que es más seguro enviar todo." Enviar todo tiene su propio riesgo: corrupción de contexto, donde el material irrelevante degrada el enfoque del modelo en lo que importa, además del costo adicional garantizado.
Preguntas Frecuentes
¿Qué es la ingeniería de contexto, en una frase?
La ingeniería de contexto es decidir qué información incluir en un prompt, en lugar de cómo redactarlo o qué modelo debe recibirlo.
¿Es la ingeniería de contexto lo mismo que la ingeniería de prompts?
No.
- La ingeniería de prompts da forma a la redacción, las instrucciones y la estructura.
- La ingeniería de contexto da forma a qué material (fragmentos, documentos, historial) se incluye en absoluto.
- Las dos son complementarias y generalmente se aplican juntas.
¿Qué técnica debería implementar primero?
El prompting de contexto mínimo suele ser el punto de partida de mayor apalancamiento porque elimina tokens directamente sin llamadas API adicionales, mientras que la sumarización y la selección de niveles requieren cierta infraestructura para configurarse.
¿Enviar más contexto alguna vez perjudica la calidad de la respuesta, no solo el costo?
Sí.
- El contexto irrelevante o excesivo puede diluir la atención del modelo en los detalles que realmente importan.
- Este efecto a veces se denomina corrupción de contexto, y significa que recortar el contexto es una palanca de calidad, no solo una palanca de costos.
¿Cómo ahorra dinero la sumarización si requiere una llamada API adicional?
La llamada de sumarización utiliza un modelo económico y rápido, mientras que de lo contrario, el documento original se enviaría completo a un modelo más costoso en cada uso; cuando un documento se referencia muchas veces, el costo único y económico de la sumarización es mucho menor que el costo repetido de enviar el documento completo.
¿Qué es la selección de niveles de modelos en la práctica?
La selección de niveles de modelos enruta cada solicitud al modelo más económico de la línea de Claude, como Haiku 4.5, que aún puede cumplir con el nivel de calidad requerido, reservando modelos más potentes como Sonnet 5 u Opus 4.8 para tareas que realmente necesitan un razonamiento más profundo.
¿Se pueden combinar estas técnicas?
Sí, y combinar estas técnicas es típico en sistemas de producción.
- El prompting de contexto mínimo reduce lo que se envía.
- La sumarización comprime cualquier cosa que aún sea demasiado larga.
- La selección de niveles de modelos decide qué modelo maneja la solicitud resultante.
¿Qué es un grafo de dependencias y por qué se relaciona con la ingeniería de contexto?
Un grafo de dependencias mapea qué archivos o módulos importa o llama una pieza de código; enviar ese grafo más solo los fragmentos relevantes mantiene enfocado un prompt relacionado con el código, en lugar de pegar un repositorio completo.
¿Existe el riesgo de recortar el contexto de forma demasiado agresiva?
Sí.
- Si se excluye información relevante, el modelo puede producir una respuesta incorrecta o incompleta.
- Una respuesta incorrecta que deba corregirse o repetirse generalmente cuesta más que los tokens que se ahorraron al recortar.
¿Cómo se relaciona el parámetro de esfuerzo con la ingeniería de contexto?
El parámetro de esfuerzo controla cuánto razonamiento aplica el modelo a un prompt dado; es una palanca separada del tamaño del contexto, pero ambas se recorren y evalúan de la misma manera, desde una configuración económica hasta la más fuerte que aún pasa las verificaciones de calidad.
¿Se aplica la ingeniería de contexto fuera de las tareas relacionadas con el código?
Sí.
- El prompting de contexto mínimo se aplica a cualquier documento recuperado, ticket de soporte o fila de base de datos, no solo a código fuente.
- La sumarización se aplica a cualquier texto largo: transcripciones, informes, documentos legales.
- La selección de niveles de modelos se aplica a cualquier clasificación de dificultad de tarea, independientemente del dominio.
¿Cuál es el mayor error que cometen los equipos al intentar reducir el gasto de tokens?
Optimizar la redacción del prompt antes de abordar lo que se incluye en el prompt; los cambios de redacción ahorran un pequeño porcentaje, mientras que las decisiones de contexto a menudo representan la mayoría del gasto.
¿Cómo sé si mi sistema necesita ingeniería de contexto?
Si tus prompts incluyen regularmente archivos completos, documentos completos o historiales de conversación completos en lugar de las partes específicas relevantes para la solicitud actual, es muy probable que haya espacio para reducir el gasto sin tocar la elección del modelo.
Relacionados
- Fundamentos de Ingeniería de Prompts y Contexto - un recorrido práctico para recortar un prompt inflado y medir los ahorros.
- [Recorte de Contexto: Grafos de Dependencias en Lugar