Cuando el remedio es otro modelo: la nueva capa de maquillaje sobre Claude
Vomit no arregla el problema de fondo: lo esconde con otra llamada a un LLM. Es una solución ingeniosa para salir del paso, pero también una señal bastante clara de que estamos construyendo sistemas frágiles alrededor de modelos que aún no dan la talla solos.
📰 Qué ha pasado
Ha aparecido Vomit, una herramienta que usa un LLM adicional para limpiar la salida de tokens de Claude 5. La propuesta consiste en meter otro modelo en medio para “arreglar” la respuesta original antes de que llegue al usuario o al siguiente paso de la tubería. La propia descripción ya apunta a que esto es un parche sobre parche, más que una solución elegante. El interés está en que pone negro sobre blanco una práctica cada vez más común: orquestar alrededor del modelo para compensar sus defectos.
🧭 El contexto: por qué ahora
Esto encaja con una tendencia muy reconocible en IA generativa: el modelo base rara vez resuelve bien todo el flujo, así que se añaden capas de postprocesado, validación, reintentos, filtros y agentes auxiliares. En teoría, eso da flexibilidad; en la práctica, suele multiplicar latencia, coste y complejidad operativa. También revela una verdad incómoda: muchas demos de IA funcionan porque hay bastante ingeniería alrededor, no porque el modelo sea realmente robusto. Cuando el “output cleaning” necesita otro LLM, ya no estamos hablando de una salida fiable, sino de un sistema que depende de que dos modelos se equivoquen de la forma correcta.
🎯 A quién le afecta y cómo
- Si montas productos con LLM en producción: te sube el coste por llamada y te complica la observabilidad.
- Si haces pipelines de agentes: añades un nuevo punto de fallo y más comportamiento no determinista.
- Si trabajas en backend/infra: tendrás que medir latencia, reintentos y degradación cuando el limpiador falle.
- Si vendes IA como producto: esto te obliga a separar demo de arquitectura seria, porque el cliente paga la complejidad aunque no la vea.
⚖️ Nuestra opinión
Criterio propio, sin nota de prensa: lo bueno, lo malo y lo que haríamos nosotros.
La idea es lista, pero no es una buena base de arquitectura salvo para casos muy acotados. Usar otro LLM para limpiar la salida de Claude es admitir que el contrato de salida del primero no es confiable, y eso ya debería encender alarmas. Sí, puede servir para prototipos o para flujos donde el coste de un error es bajo y la velocidad de entrega importa más que la elegancia. Pero en cuanto el sistema empieza a depender de esa capa para funcionar, estás comprando fragilidad con una interfaz bonita.
El problema no es solo técnico, es de disciplina de producto. Cada modelo extra añade coste, latencia, dependencia de proveedor y más superficie para comportamientos raros, además de hacer más difícil depurar incidentes. Y lo peor es que estas soluciones suelen normalizar una mala práctica: aceptar salidas inconsistentes y taparlas con otra IA en vez de imponer esquemas, validadores y límites claros. Si el flujo necesita limpieza constante, la pregunta correcta no es “¿qué LLM uso para limpiar?”, sino “¿por qué estoy dejando que el modelo produzca basura en primer lugar?”.
Lo que haríamos nosotros es usar esto solo como parche temporal en experimentación, nunca como pilar de un sistema crítico. Primero intentaríamos forzar salidas estructuradas, validación estricta y fallback determinista; después, si aún hace falta, pondríamos un limpiador muy acotado y medido, con métricas de error, coste y latencia. Si no puedes explicar en una frase por qué esa capa extra existe, probablemente sobra.
✅ Qué hacer con esto
Acciones concretas si esto te toca de cerca.