Esta semana fue intensa. Mucha experimentación, muchas reuniones, y un par de insights que quiero compartir porque creo que le van a resonar a más de uno.
Cuándo usar un LLM y cuándo no
Estamos incorporando agentes de inteligencia artificial en los análisis de analítica que hacemos, y el nivel de productividad que se puede lograr es increíble. Pero hay una lección que fui aprendiendo a los golpes: no todo debería pasar por un LLM.
Imaginen que le paso a un agente el desempeño de mil personas, cinco competencias cada una, más la gerencia, el perfil del cargo, el evaluador y el evaluado. Son miles y miles de datos. El agente va a consumir una cantidad enorme de tokens simplemente leyendo eso, y el costo se dispara. Ese es el primer problema: el costo.
Pero hay un segundo problema, distinto: la confiabilidad. Si quiero algo repetible —algo que voy a correr una y otra vez con el mismo tipo de input y necesito exactamente el mismo output— un LLM no es la herramienta correcta. Lo que corresponde es construir un programa. Trabajado con IA, sí, pero un programa concreto que haga el análisis de manera consistente y predecible.
La respuesta no está en sacar el LLM del proceso, sino en encontrarle su lugar correcto: interpretar los resultados del análisis. Ahí es donde brilla. No como motor de cómputo, sino como intérprete.
El problema de los sesgos en las evaluaciones de desempeño
Un ejemplo concreto de esto lo viví el fin de semana. Corrimos alrededor de 15 experimentos para entender cuáles son las variables más importantes que generan sesgo en las evaluaciones de desempeño. Es un tema que me preocupa mucho, porque si el dato inicial no es confiable, todas las decisiones que vienen después —talento, sucesión, ajuste de sueldos— tampoco lo son.
Lo que encontramos es que básicamente hay dos fuentes de sesgo:
Un evaluador que consistentemente evalúa muy alto o muy bajo a todo su equipo.
Un evaluador que no discrimina entre los miembros de su equipo (los evalúa a todos igual).
¿Cuál de las dos importa más? La diferencia entre evaluadores. Eso significa que en el proceso de calibración, lo primero que hay que mirar son los jefes que en promedio están dejando a sus equipos demasiado arriba o demasiado abajo. Si identificamos eso, podemos mejorar mucho la consistencia de nuestras decisiones.
Estos 15 experimentos los corrimos con un programa —repetible, confiable, siempre el mismo resultado. El LLM entró después, para interpretar qué nos estaban diciendo los números. Exactamente lo que había aprendido, puesto en práctica.
Dashboards con IA: la arquitectura lo es todo
También estuvimos trabajando en cómo construir dashboards usando inteligencia artificial. El desafío principal que apareció tiene que ver con la arquitectura: dónde usar IA, dónde no usarla y dónde es mejor automatización pura.
Y eso depende completamente del caso de uso. No hay una receta universal.
Además, empezamos a explorar cómo evaluar perfiles de cargos con IA generativa. Todavía en etapa exploratoria, pero con mucho potencial.
El aprendizaje de la semana: simplicidad
Tuve varias reuniones con clientes esta semana, y el concepto que me quedó dando vueltas fue simpleza.
Muchas veces —y yo he caído en ese error— construimos cosas muy complejas que agregan valor real, pero que el cliente no es capaz de tomar y aprovechar. La complejidad se vuelve un obstáculo en vez de un activo.
Esto no significa bajar la vara. No vamos a hacer dashboards que solo muestran promedios. El desafío está en cómo presentar cosas complejas —modelos estadísticos, análisis sofisticados— de una forma tan simple que el cliente pueda sacar conclusiones por sí solo.
Ahí veo una oportunidad muy interesante: la combinación de un buen dashboard, un modelo estadístico sólido, y una IA que pueda interpretar los resultados y traducirlos a lenguaje humano. Eso sí que cambia las cosas.
Eso fue la semana. Seguimos aprendiendo, seguimos construyendo.
Nos vemos la próxima.
Pablo
