Qué tan razonable es hacer feature engineering sin perder contexto?

[RyanL]

Hace unos meses empecé a trabajar con un dataset de transacciones para detectar anomalías, y aunque he probado varios modelos, tengo la sensación de que me estoy perdiendo algo fundamental en la fase de preparación de los datos. Me cuesta decidir cuándo una transformación o limpieza en particular está realmente justificada por el problema y cuándo es solo un hábito que traigo de otros proyectos. Me pregunto si alguien más ha sentido que el proceso de feature engineering a veces se vuelve un poco automático y desconectado del contexto específico.

[Jeffrey_J]

Me suena a ese truco llamado feature engineering y a veces parece que nos perdemos en transformaciones sin contexto claro. A veces una variable derivada ayuda a ver patrones raros en transacciones, pero otras veces es solo hábito heredado de otros proyectos. Preguntar que problema concreto resuelve cada paso ayuda a no perder el rumbo.

[NoraZM]

Quien dice que la limpieza que funciona en una base sirve en otra puede estar vendiendo humo. La ingeniería de características suena poderosa pero a veces es una excusa para evitar discutir el problema real. ¿No sería mejor empezar por definir un objetivo concreto y medir si la transformación aporta valor o no?

[LunaQJ]

En mi caso el feature engineering a menudo se apoya en suposiciones sobre la distribución de las transacciones y eso condiciona las expectativas del usuario. Si el modelo falla las primeras veces parece que la gente quiere un truco nuevo en lugar de una explicación simple. Tal vez convenga documentar la intuición detrás de cada característica y ver si el beneficio es real.

[Jeffrey60]

Algunas decisiones de limpieza parecen salir de un librito de reglas sociales más que de la lógica del negocio y eso se nota en la detección de anomalías. La ingeniería de características a veces responde a intuiciones personales en lugar de datos. Mejor probar cada cambio con ejemplos claramente difíciles.

[Evelyn.W]

Puede que el data drift haga que lo que parecía útil ayer no sirva mañana y entonces el feature engineering se desinfla si no hay monitoreo continuo.

[EricFJ]

Y si el verdadero objetivo no es detectar cualquier anomalía sino entender el comportamiento normal de esa base de datos, la pregunta cambia de raíz. También conviene preguntar qué tan tolerante debe ser el sistema ante errores y qué espacio hay para la incertidumbre.