Context engineering para PYMEs: cómo bajar el coste de IA sin perder calidad

A medida que los proyectos de IA pasan del piloto a la operación diaria, el cuello de botella deja de ser la calidad del modelo y empieza a serlo el coste por sesión. En las últimas semanas han aparecido herramientas que documentan reducciones notables: Semble informa hasta un 98% menos de tokens en code search frente a grep+read, agent-desktop reporta entre un 78% y un 96% menos en automatización de escritorio, y enfoques híbridos como DeepClaude prometen hasta 17 veces menos coste para tareas de bajo riesgo.

Para una PYME, la pregunta práctica no es cuál es el modelo más potente. Es cuál es la combinación que mantiene calidad aceptable a un coste sostenible.

Respuesta corta

El coste de inferencia se reduce con context engineering: dar al modelo solo lo necesario, en el formato más compacto posible, y delegar a un modelo más barato lo que no necesita el más caro. La calidad se mantiene si las decisiones de routing y reducción se sustentan en evals y observabilidad.

Dónde se va el dinero

Origen del gasto	Ejemplo
Lectura completa de archivos	Agente que hace grep + abre 20 ficheros enteros para localizar una función
Dump entero del árbol de la app	Automatización de escritorio que serializa toda la UI en cada paso
Conversaciones largas sin resumen	Sesiones que arrastran historial irrelevante turno tras turno
Modelos premium para tareas mecánicas	Refactor masivo ejecutado con el modelo más caro disponible
Reintentos sin política	Bucles que vuelven a llamar al modelo ante cada fallo trivial

Cada uno tiene una palanca de optimización distinta.

Técnicas con impacto medible

Técnica	Ahorro reportado	Cuándo aplica
Retrieval por embeddings + BM25 (estilo Semble)	Hasta 98% en code search	Búsqueda de código en repos medianos o grandes
Snapshot por accessibility tree (estilo agent-desktop)	78-96% en automatización desktop	Control de Slack, Notion, VS Code y similares
Resumen incremental de contexto	30-60% en sesiones largas	Cualquier asistente con memoria de turno
Model routing por dificultad	Hasta 17x según mezcla	Tareas heterogéneas con margen de calidad
Caching de respuestas	Variable	Prompts repetidos o plantillas estables
Skills versionadas y AGENTS.md	Indirecto pero alto	Equipos con contexto reutilizable

Estos números son orientativos. El ahorro real depende del stack, la naturaleza del problema y la disciplina del equipo.

Mapa de routing

flowchart LR
  A[Tarea entrante] --> B{¿Riesgo o calidad alta?}
  B -- Sí --> C[Modelo premium]
  B -- No --> D{¿Plantilla o repetitiva?}
  D -- Sí --> E[Modelo barato + cache]
  D -- No --> F[Modelo intermedio]
  C --> G[Validación humana]
  E --> H[Validación automática]
  F --> H

El objetivo es enviar cada tarea al modelo más barato que cumple el criterio de calidad. No es un dogma técnico, es una decisión de coste.

Reducción de contexto sin perder calidad

Patrón	Qué hace	Cuándo evitarlo
Top-k retrieval	Devuelve solo los fragmentos más relevantes	Cuando la respuesta requiere visión global
Resumen rolling	Comprime turnos antiguos	Si se pierden referencias clave del inicio
Schemas estrictos	Limita el output a lo necesario	Tareas exploratorias
Skills versionadas	Reutiliza convenciones del repo	Sin disciplina, se quedan desfasadas
Memoria explícita	Guarda decisiones del proyecto	Si no hay revisión, se llena de ruido

El principio común: cada token enviado al modelo debe justificar su existencia. Lo que no aporta a la respuesta, se va.

Caso típico en una PYME

Contexto	Antes	Después
Asistente interno con RAG	Cada consulta hace grep global	Indexación con embeddings + BM25
Automatización de Slack y Notion	Captura de pantalla y OCR	Snapshot por accessibility tree
Refactor mecánico semanal	Modelo premium con prompts largos	Modelo intermedio con plantilla y diff
Generación de informes	Cadena larga sin cache	Plantilla fija + caching por tipo
Soporte a clientes	Conversación sin compresión	Resumen rolling cada 10 turnos

La suma de pequeñas optimizaciones suele rendir más que reemplazar el modelo principal.

Métricas que importan

Métrica	Qué indica	Cómo medirla
Coste por tarea cerrada	Eficiencia real	Coste total / tareas completadas y aceptadas
Coste por turno útil	Detecta sesiones derrochadoras	Coste / mensajes con valor aportado
Tasa de aceptación	Calidad percibida	% de respuestas usadas sin retoque
Latencia media	Experiencia de usuario	Tiempo desde la petición hasta la respuesta final
Tasa de fallback	Estabilidad del routing	% de tareas que escalan a un modelo más caro

Sin estas métricas, optimizar coste se convierte en una sensación. Con ellas, en una decisión.

Errores frecuentes

1. Cambiar de modelo sin antes reducir el contexto.
2. Aplicar caching agresivo sin invalidación clara.
3. Routing automático sin evals que detecten regresiones.
4. Confundir “menos tokens” con “menos calidad” sin medirlo.
5. Reducir contexto para tareas que necesitan visión global.
6. Optimizar el modelo principal y olvidar el ruido en sesiones largas.

Reglas firmes para no romper la calidad

1. Cada técnica de ahorro pasa por una eval antes de extenderse.
2. Las decisiones de routing son auditables.
3. La compresión de contexto se prueba con casos límite reales.
4. La cache tiene política explícita de invalidación.
5. Las tareas críticas pueden saltar al modelo premium si el riesgo lo justifica.
6. La observabilidad cubre coste, latencia y calidad por igual.

Indicadores de avance

Indicador	Bueno	Malo
Reducción de tokens medida	Datos antes y después por flujo	”Notamos que es más barato”
Routing	Reglas explícitas y revisadas	Configuración heredada sin revisión
Evals	Suite que se ejecuta en cada cambio	Pruebas manuales esporádicas
Latencia	Dentro del SLA acordado con el negocio	Variable y no medida
Coste por tarea	Tendencia descendente sostenida	Solo se mira la factura mensual

Criterio final

El coste de inferencia es un problema de ingeniería, no de modelo. Cuando una PYME mide bien y reduce contexto con disciplina, la factura baja sin sacrificar calidad. La diferencia entre tener IA “cara” y tener IA sostenible está en quién decide qué llega a cada modelo y por qué.

Fuentes de trabajo

• Documentación pública de Semble sobre indexación con Model2Vec, BM25 y RRF.
• Documentación pública de agent-desktop sobre snapshot por accessibility tree.
• Buenas prácticas de retrieval y prompt engineering en proyectos LLM en producción.
• Las decisiones técnicas deben adaptarse al stack, criticidad y volumen de cada empresa.