En el post anterior montamos evaluación continua. Ahora atacamos el gasto. El costo es tokens_prompt + tokens_salida + llamadas. Tus palancas: routing, contexto, longitud, caching y retrys inteligentes.

¿Dónde se va el dinero?

• Contexto excesivo (Top-K alto, chunks largos, documentos ruidosos).
• Modelo sobredimensionado cuando un SLM/“turbo” bastaba.
• Reintentos ciegos por errores de formato o políticas mal definidas.
• Post-procesos redundantes (verificador caro en todos los casos).
• Embeddings y reindexación sin controlar lotes ni frecuencia.

Palancas de ahorro por capa

1) Routing de modelos (difícil vs. fácil)

• Clasifica la consulta: faq/simple → SLM barato; analítico/razonamiento → LLM grande.
• Ruta por tenant (SLA/presupuesto) y por riesgo (seguridad).
• Solo “subir” de modelo ante señales: longitud, necesidad de herramienta, RAG sin evidencia suficiente.

// Pseudocódigo de router
if (isFAQ(q) || short(q)) model = "slm-basic";
else if (needsTools(q) || long(q)) model = "llm-pro";
else model = "slm-plus";

2) Control del contexto (RAG disciplinado)

• Top-K prudente (2–4) + filtros de metadatos (fecha, fuente) antes del vector search.
• Chunking con títulos y anclas; evita duplicidad semántica.
• Reranker barato → manda pocos y buenos al prompt.
• Citas obligatorias para permitir abstención y evitar relleno caro.

3) Longitud y formato

• Fija límite de palabras o max_tokens.
• Contrato de salida (JSON/tabla) para evitar verborrea.
• Evita razonamientos largos si no aportan (pide respuesta directa + campos clave).

4) Caching y memoización

• Cache semántico para preguntas repetidas (hash de intent + idioma + tenant).
• Precomputados (resúmenes de documentos, embeddings por lote nocturno).
• TTL adaptativo: más largo para FAQs, corto para info dinámica.

5) Reintentos inteligentes

• Si falla JSON → retry con dif de errores (no re-generes todo).
• Si RAG no encuentra evidencia → reformula consulta (HyDE/sinónimos) y Top-K +1, una sola vez.
• Cap de reintentos (máx. 1–2) y modo seguro si persiste el fallo.

6) Embeddings y vector store

• Embebe por lotes y fuera de pico; detecta duplicados.
• Chunk de 300–800 tokens según dominio; evita “párrafos kilométricos”.
• Reindexa con criterio (delta por updated_at), no todo el corpus cada vez.

Quick wins (impacto inmediato)

1. Baja Top-K y añade reranker sencillo.
2. Impón límite de palabras y stop sequences al cierre del JSON.
3. Activa cache para FAQs + TTL por tenant.
4. Mueve verificaciones caras a “muestra aleatoria” (p.ej., 10%) o a casos de alto riesgo.
5. Introduce router (SLM → LLM) con fallback bajo señal de fracaso.

Métricas y presupuestos

• Costo por request (p50/p95) y por tenant.
• Tokens_in/out, tamaño de contexto, % cache hit.
• Win-rate vs. baseline de calidad (para no “ahorrar” rompiendo utilidad).

// Política de presupuesto por request
{
  "max_cost_usd": 0.01,
  "max_tokens_in": 1200,
  "max_tokens_out": 250,
  "max_retries": 1
}

Micro-workflow en n8n: “Optimizador de costos online”

1. Webhook → recibe {query, tenant, risk}.
2. Function (router) → decide modelo (slm-basic/slm-plus/llm-pro) y límites.
3. IF → si tenant low-cost → fuerza Top-K=2 y salida corta; si high-SLA → permite reranker.
4. LLM → ejecuta con max_tokens, stop y contrato de salida.
5. Function → valida JSON; si falla, retry con dif de errores (1 vez).
6. Database → registra costo, tokens y router_decision.
7. Notifier → alerta si p95 de costo supera umbral diario.

Tips Laravel/PHP

• Router de modelos como servicio: App\Services\ModelRouter con reglas y métricas.
• Cache con claves compuestas (sha1(tenant|lang|intent|query_norm)) y TTL por tipo.
• Rate limit y budgets por API key/tenant; cortar picos caros.
• FormRequest para validar contratos de entrada y evitar reintentos innecesarios.
• Tabla llm_costs: {request_id, tenant, model, tokens_in, tokens_out, cost_usd, router, created_at}.

A/B de costos (sin perder calidad)

Prueba variantes de Top-K, longitud de salida, modelo y cache. Promueve solo si:

• Win-rate ≥ baseline − 1pt y costo ≤ baseline − 10% (para “modo ahorro”).
• O bien, win-rate ≥ +3pts con costo ≈ baseline (para “modo calidad”).

Anti-patrones

• Ahorrar rompiendo groundedness (RAG sin filtro ni citas).
• Usar LLM “grande” por defecto en todo.
• Reintentos ilimitados para “arreglar” formato.
• Embeddings cada carga de página; hazlo por lotes y con deltas.

Conclusión

El cost engineering es arquitectura + política: router, contexto mínimo viable, contratos de salida, cache y presupuestos. Mide, itera y promueve solo lo que ahorra sin romper calidad.

← Anterior: Evaluación continua: asegurando que tu modelo no empeore con el tiempo

Siguiente: Privacidad, PII y cumplimiento: buenas prácticas al trabajar con datos sensibles →