Hay una conversación que se repite en cada reunión sobre IA: ¿qué modelo usamos? Se comparan benchmarks, se discuten precios por millón de tokens, alguien menciona que salió uno nuevo la semana pasada.
Es una conversación casi irrelevante.
No porque los modelos sean iguales —no lo son— sino porque la diferencia entre un sistema de IA que funciona en producción y uno que no, casi nunca está en el modelo. Está en todo lo que lo rodea.
El experimento mental
Imaginá dos equipos construyendo el mismo asistente de soporte.
El equipo A usa el modelo más capaz del mercado, con un prompt de ochocientas palabras que describe todo el proceso: cómo clasificar, cuándo escalar, qué tono usar, qué no decir nunca.
El equipo B usa un modelo mediano, pero parte el proceso en cinco pasos explícitos. Cada paso tiene su propia llamada, su propia validación de salida, y un camino definido para cuando esa validación falla.
En el demo, A gana. Se ve más fluido, responde mejor a casos raros, y costó dos días en vez de dos semanas.
A los tres meses, B gana por goleada. Y la razón no es sutil.
Lo que pasa cuando falla
El sistema de A falla como una caja negra. El usuario reporta "respondió cualquier cosa", y el equipo tiene un prompt de ochocientas palabras y un log con una entrada y una salida. No hay forma de saber si el modelo clasificó mal, si no encontró el documento, o si lo encontró y lo interpretó al revés.
La respuesta típica es editar el prompt. Agregar una frase. "IMPORTANTE: nunca inventes políticas de devolución." Y funciona, hasta que rompe otra cosa que nadie estaba mirando.
El sistema de B falla en un paso concreto. El log dice: paso 2, recuperación de contexto, cero documentos sobre el umbral de similitud. El problema no es el modelo, es el índice. Y eso se arregla.
Las cuatro piezas que casi nadie construye
1. Fronteras explícitas entre pasos
Cada paso debe tener un contrato: qué recibe, qué devuelve, y en qué forma. Si el paso "clasificar intención" puede devolver cualquier string, no es un paso, es una esperanza. Debe devolver uno de siete valores conocidos, o fallar.
Esto es aburrido y es lo más importante del artículo.
2. Validación en la salida, no solo en la entrada
Validar el input del usuario es obvio. Validar el output del modelo lo hace muchísima menos gente, y es donde está el riesgo real. Si el modelo tiene que devolver JSON con tres campos, parsealo y verificá los tres campos antes de pasárselo a nada.
Cuando la validación falla, tenés opciones reales: reintentar con temperatura más baja, caer a un camino determinista, o escalar a una persona. Todas son mejores que propagar basura.
3. Trazabilidad por defecto
Cada ejecución debería dejar registro de cada paso con su entrada, su salida, su latencia y su costo. No como feature de observabilidad avanzada: desde el primer commit.
El día que un cliente pregunte por qué el sistema hizo algo, la diferencia entre poder responder en dos minutos o en dos días es exactamente esto.
4. Un set de evaluación que corra en CI
Veinte o treinta casos representativos, con la salida esperada, corriendo en cada cambio de prompt. No necesita ser sofisticado. Necesita existir.
Sin esto, cada modificación es una apuesta y el equipo desarrolla miedo a tocar nada. He visto prompts que nadie se atreve a cambiar porque "funciona y no sabemos por qué".
El corolario incómodo
Si construís bien estas cuatro piezas, el modelo pasa a ser una variable de configuración. Podés probar uno más barato y medir si la calidad cae. Podés cambiar de proveedor en una tarde. Podés usar un modelo distinto por paso.
Si no las construís, quedás casado con un modelo específico y con un prompt que nadie entiende del todo, incluido quien lo escribió.
La pregunta correcta no es "¿qué modelo usamos?". Es "¿cómo sabemos cuándo se equivocó?".
Qué hacer el lunes
Agarrá el sistema de IA que tengas corriendo y respondé tres preguntas:
- Si el modelo devuelve algo inesperado ahora mismo, ¿qué pasa?
- ¿Podés reconstruir por qué dio una respuesta específica de hace una semana?
- ¿Cuántos casos de prueba corren automáticamente cuando cambiás el prompt?
Si alguna respuesta es incómoda, ya sabés en qué trabajar. Y no es en cambiar de modelo.