Hay una idea en la que tropiezo una y otra vez cuando trabajo con herramientas de IA para datos,: el modelo puede detectar patrones, resumir tendencias o producir explicaciones plausibles. A veces, sorprendentemente bien. Pero la parte realmente útil del trabajo sigue en otro sitio.
Está en el PORQUÉ.
Esto puede sonar obvio. No lo es. Porque cuando una herramienta es fluida, rápida y segura de sí misma, resulta muy tentador pensar que también entiende nuestra intención. Y ahí es donde las cosas empiezan a descarrilar.
El experimento
Usé un asistente de datos especializado en un área específica de negocio -hablaré de esto en unos días- para echar un vistazo a ciertas agrupaciones de datos y su tendencia. El asistente me presentó los resultados y dedujo una tendencia para cada grupo.
Como los números así en crudo costaban un poco leerlos, pedí al asistente que añadiese porcentajes por columna y mes. Lo hizo, pero entonces me cambió las tendencias sin que los datos hubieran cambiado. Tendría sentido porque estaba aparentemente calculando estas tendencias primero desde los raw numbers, y ahora desde los porcentajes… pero además sin contar febrero, solo viendo la fluctuación de enero a marzo.
Bien. Pero en ese punto pensé que para lo que yo necesitaba, calcular el incremento relativo de ese porcentaje tenía más relevancia. Me refiero a que si va de 2.0% a 2.5%, el delta no quería que fuera 0.5% (2.5 – 2.0), sino 25% ((2.5 – 2.0) / 2.0). Y entonces me encontrré con un tercer conjunto de tendencias. Algo más, mirando a la tabla bajo estas lineas, la leyenda dice ‘estoy considerando cambios de más de 5% en valor absoluto como lo suficientemente importantes para usar un icono’. Sin embargo, hay dos agrupaciones que están sobre este /5%/ en valor absoluto y se consideran estables ↔
Mi sospecha es que esto es debido a tener un valor intermedio cuyo cambio en direción no era consistente con el cambio global. Por ejemplo en una de las filas el share fue de 3.1% a 3.3%, y esto explica el delta de +6.5%, pero en Febrero descendió. but Lo mismo ocurre en el segundo caso. Le pregunté al Data Assistant y me dijo ‘You’re absolutely right’ (ninguna sorpresa). Y creó una nueva versión de la tabla.
La conclusión. La importancia del porqué.
Este experimento me recordó una conversación con mi compañero George, que luego derivó en un post. La idea principal era que los Agentes no necesitan specs exhaustivas porque son capaces de rellenar los huecos desde un prototipo, el codebase y un conjunto de validación. Pero lo que no pueden inventarse los agentes, lo que no pueden inferir es el porqué.
Parece trivial, pero no lo es. La tendendia es diferente dependiendo de para qué la quieres porque esto te lleva a tomar decisiones intermedias. Una buena parte del porqué está también en la propia database con lo que una buena documentación podría aparentemente permitir a un agente hacer inferencias acertadas. Pero las BDs pueden ser multipurpose, como normalmente ocurre. Y entonces son multi-porqué. Así que cuando usemos AI es vital evitar la tentación de ser demasiado lacónicos, lo cual sería equivalente a confiar en que el modelo sabe para qué quiero lo que estoy haciendo.
Nada nuevo bajo el sol, claro. Solo un recordatorio de que tenemos que enfocarnos en el problema más que en cómo solucionarlo. Esa es la revolución que ya predijo Carroll.
Leave a Reply