Cuándo no construir un modelo
La presión por tener un programa de IA es real, y tiende a producir proyectos elegidos por cómo suenan y no por lo que cambiarían. Una evaluación útil produce dos listas, y la segunda es la más valiosa.
Cuando la decisión ya es determinista
Si la regla se puede escribir, escríbela. Un modelo que aprende una política existente es más difícil de auditar, más difícil de cambiar y peor explicándose que las veinte líneas de código que codifican esa política directamente.
Cuando nadie va a actuar sobre la salida
Una predicción que llega después de tomar la decisión, o que aterriza en alguien que no puede actuar sobre ella, no cambia nada. Antes de construir, traza el camino desde la salida del modelo hasta una persona o sistema con la autoridad y el momento para hacer algo distinto. Si ese camino no existe, el modelo no es la pieza que falta.
Cuando los datos no describen el resultado
Solo se aprende de resultados que se han registrado. Si nadie anotó qué pasó después de cada decisión —y muchas veces nadie lo hizo—, el primer proyecto honesto es instrumentar eso, no modelarlo. Es poco vistoso y es un requisito previo.
Cuando basta un modelo alojado con buena recuperación
Para muchas tareas de lenguaje, un modelo alojado con una recuperación bien construida y un conjunto de evaluación decente te lleva casi todo el camino a una fracción del coste. Entrenar el tuyo merece la pena cuando tienes datos que nadie más tiene, o una restricción de latencia o privacidad que descarta las alternativas; no por defecto.
Lo que queda merece hacerse bien
Descartar todo eso suele dejar una lista corta de candidatos realmente buenos: decisiones que se toman a menudo, con resultados registrados, por alguien que puede actuar sobre una respuesta mejor. Esas merecen la infraestructura de serving, la monitorización y el banco de evaluación. Las otras nunca iban a devolverlo.
