Esta es la publicación número 2 de mi serie Ivory Tower Notes. En la publicación número 1, escribí sobre el problema: cómo comienza cada proyecto de datos e inteligencia artificial.
Esta vez, el tema es la metodología, y por qué “acelerar y salir” es lo que a menudo sucede cuando nos lo saltamos.
Entrar rápido, salir
Sonreí levemente cuando una de mis conexiones comentó: “Me enviaste AI Slop” en una publicación aleatoria que tenía cientos de “me gusta”. La publicación, que contenía una matriz de decisiones, ofrecía orientación sobre qué plataforma utilizar para cargas de trabajo de datos específicas, aunque con criterios cuestionables. Dejando a un lado la calidad, realmente se veía genial.
Mi diversión no terminó ahí cuando pensé en cómo AIS, es decir, “AI Slop”, debería agregarse como un botón a todas las redes sociales ahora junto con el botón Me gusta.
Si alguna persona de YouTube lee esto, es una idea de función en lugar de preguntar a la gente: “¿Esto se siente como una falla de IA?”
No obstante, YouTube logró la parte de “sensación” porque todos tendemos a tomar decisiones basadas en las emociones, a menudo a expensas del pensamiento crítico.
¿Por qué invertiríamos energía en empirismo, racionalismo y escepticismo cuando ahora tenemos IA? Los plazos no están de nuestro lado y tenemos esta nueva herramienta que nos proporciona resultados, independientemente del efecto de “entrada rápida, salida lenta”.
Pero supongamos que está realmente interesado en cómo se compara la Plataforma A con la Plataforma B en términos de capacidades de aprendizaje automático (ML), porque ha notado que dos equipos de datos en su empresa utilizan plataformas separadas para casos de uso de ML casi idénticos. Por lo tanto, su objetivo es compilar una descripción objetiva de ambos y proponer reducir los costos de desarrollo manteniendo solo uno.
¿Y ahora qué? ¿Cómo se determina si se deben consolidar las cargas de trabajo de ML?
Seguramente no confiando exclusivamente en la IA, sino más bien en…
El camino de la indagación
Y así regresas a los días de la Torre de Marfil, donde te enseñaron que cada descubrimiento está cubierto por “La metodología”:
El problema → La hipótesis → Probar la hipótesis → Las conclusiones
Además, le enseñaron que encontrar el problema es la mitad del trabajo y que el arte de llegar allí consiste en hacer buenas preguntas para reducirlo a algo específico y comprobable.
Por lo tanto, se toma la pregunta vaga: “¿Deberíamos consolidarnos en una plataforma de aprendizaje automático?” y se sigue reescribiendo hasta que se convierte en algo que una prueba pueda responder:
¿La Plataforma A ejecuta nuestro proceso de abandono con una precisión comparable y un costo menor que la Plataforma B?
Ahora ha definido un tema, una comparación y cosas que puede medir, lo cual es suficiente para convertir una pregunta de negocios en una hipótesis comprobable.
Pero primero, haga su tarea y recopile información adicional, como cuánto cuesta la Plataforma B por trabajo hoy, qué precisión alcanza y cómo está diseñada (por ejemplo, los datos, el algoritmo y los hiperparámetros que utiliza), para que pueda reproducir la canalización en la Plataforma A.
Luego, antes de que comiencen a llegar opiniones sobre su pregunta, usted afirma:
Si ejecutamos el mismo proceso de abandono en la Plataforma A en lugar de la Plataforma B, utilizando datos, algoritmos e hiperparámetros idénticos, entonces el costo medio por trabajo se reducirá al menos un 15%, mientras que la precisión media se mantiene dentro de 1 punto porcentual de la Plataforma B.
Con esta formulación de “si-entonces”, logró acallar (al menos algunas) respuestas obstinadas, sabiendo que la prueba de concepto viene a continuación. Por lo tanto, para probar la presunción establecida, diseña y ejecuta la PoC, donde cambia solo la variable independiente, que es la plataforma. Junto con esto, congela las variables de control: el conjunto de datos, el algoritmo y los hiperparámetros, y mide el costo y la precisión, que son sus variables dependientes.
También repite la ejecución varias veces para separar la señal del ruido mediante la recopilación de múltiples puntos de datos, considerando cómo una sola ejecución puede verse sesgada por el ruido ambiental (por ejemplo, caché) y desea evitar ese escenario. Luego se tienen en cuenta más matices, por ejemplo, activar ejecuciones en diferentes momentos del día (mañana, tarde o noche), para exponer ambas plataformas a la misma combinación de condiciones.
Finalmente, recopila todos los resultados y evalúa los datos con respecto a su hipótesis, lo que lo lleva a uno de estos tres resultados:
Resultado 1: Los datos respaldan su hipótesis*. Las múltiples ejecuciones muestran cómo la Plataforma A es al menos un 15% más barata y la precisión se mantuvo dentro del umbral definido. (*Solo para la nota: los datos respaldarán, pero no probarán, su hipótesis, es decir, le darán una razón para aferrarse a ella, lo que en ciencia es lo más cercano a un “sí” que pueda obtener). Resultado 2: Los datos rechazan su hipótesis. Las múltiples ejecuciones muestran cómo la Plataforma A no cumplió con uno o ambos criterios; era solo un 5% más barato o el costo bajaba, pero la precisión se degradaba más allá del umbral definido. Resultado 3: Tus ejecuciones son demasiado ruidosas para llamarlas de cualquier manera, y la única respuesta es seguir probando antes de sacar conclusiones.
Cualquiera que sea el escenario en el que se encuentre, tendrá hallazgos: confirmó su suposición, aprendió algo nuevo o descubrió que necesita seguir realizando pruebas.
Y para ser claros con este breve ejemplo: las dos primeras conclusiones no le darán luz verde para consolidar dos plataformas. La realidad corporativa (y una evaluación exhaustiva) es un poco más confusa que eso, y hay más datos (que deben recopilarse y evaluarse) que afectan a las personas y los procesos de los que una prueba de concepto de alcance único puede resolver.
Muy bien, podemos detenernos con la metodología ahora, porque la mayoría de ustedes probablemente estén leyendo los pasos anteriores y preguntándose…
¿Qué diablos? ¿Dónde está la IA en todo esto?
Solo puedo imaginar cómo algo similar a: “MCP, marcos agentes, agentes…” se te pasó por la cabeza al leer los pasos anteriores. No podría estar más de acuerdo, todo es bueno y así es como se puede acelerar el proceso.
Sin embargo, simplemente publicar resultados de IA a partir de un mensaje como: “Dame una descripción general de cómo se compara la Plataforma A con la Plataforma B para cargas de trabajo de ML”, es donde ocurre el problema y “si no estás haciendo la práctica, es muy probable que tu opinión al respecto sea completamente incorrecta”.
“Si no estás haciendo la práctica, es muy probable que tu opinión al respecto sea completamente errónea”.
La relevancia y la influencia positiva no provienen de publicaciones bonitas de IA o de infografías de presentación, y pueden dañar las relaciones laborales.
Cuando ya estás influyendo y quieres ser visto como una autoridad, sería más eficaz compartir puntos de vista y hallazgos de experimentos de la vida real y tu propia experiencia comprobada.
En lugar de comenzar sus publicaciones diciendo “Aquí es donde debe usar la Plataforma A en lugar de la Plataforma B para…”, intente algo más concreto (si es cierto, por supuesto):
“Cuando nosotros (yo) cambiamos el [independent variable] para ver cómo afecta [dependent variable]manteniendo el [control variables] lo mismo, nuestro (mío) los hallazgos fueron…”
Y luego vea si el número de seguidores aumenta e informe los hallazgos.
La inspiración para esta publicación vino de un artículo croata del profesor Mladen Šolić, “Uvod u znanstveni rad” (Introducción a la investigación científica, 2005, [LINK]). Lo leí por primera vez cuando era estudiante y sigue siendo una de las explicaciones más claras sobre cómo realizar investigaciones científicas que he encontrado.
Gracias por leer.
Si esta publicación le resultó valiosa, no dude en compartirla con su red. 👏
Conéctese para ver más historias en Medium ✍️ y LinkedIn 🖇️.