+ Esa, inspector, es la pregunta correcta.

Con esa frase terminaba una conversación entre el agente Spooner (Will Smith) y el holograma del doctor Lanning (James Cromwell). Youtube Esta frase es un recordatorio del poder de hacer las preguntas correctas, y hoy vamos a ver un ejemplo de que pasa cuando no hacemos las preguntas adecuadas y dejamos que el sesgo de confirmación nos haga perder tiempo y esfuerzo.

El problema que no era

La semana pasada estaba ayudando a un compañero que estaba teniendo problemas en integrar un SDK interno. Tras una rápida lectura a la documentación del mismo vi que tenía una limitación, y era que solamente se podía usar desde sub-regiones concretas (en el caso de AWS se llaman Availability Zones, pero otros vendors pueden usar otra nomenclatura).

Esto me había causado problemas en el pasado con esa misma pieza de software así que asumí que sería la misma causa, en un caso de sesgo de confirmación de libro. La solución pasaba por recrear nuestra infraestructura asegurándonos que el código solamente se ejecutaba en esas sub-regiones. Esto provocó borrar y re-crear recursos en desarrollo (no estábamos en producción aún) y bloquear las pruebas que estaba haciendo el equipo durante un par de días.

Sin embargo, tras volver a crear los recursos vimos que seguía fallando, y no tenía sentido porque habíamos solucionado el problema. Pero realmente ¿habíamos solucionado el problema?

El problema real

Para responder a esta pregunta, podemos seguir el proceso de Las 5 por qué. Este mecanismo, que solemos emplear en Amazon como parte de nuestro post mortem (que llamamos corrección de errores o COE) nos obliga a preguntar varias veces acerca del origen real de un problema (dependiendo del contexto y la complejidad) y nos permiten ir más allá de las causas comunes o los sesgos de confirmación. Tras darme cuenta que el problema no era el que pensaba, volví al fallo original y empecé a preguntarme ¿Por qué falla la conexión, exactamente?

Tras volver a la documentación y leer detalladamente (se ve que leer detalladamente no es una habilidad que se requiera para ser Sr. Engineer) descubrí que la limitación de sub-regiones no aplicaba a mi tipo de servicio, porque estábamos en un entorno serverless, entonces la pregunta fue ¿Si estamos en un entorno serverless, por qué falla la conexión? a lo que siguió la pregunta de ¿Cómo sabe el SDK que estamos en un entorno serverless?.

Esta fue la pregunta adecuada, ya que me permitió, leyendo el código del SDK, descubrir que la distinción se hacía con una variable de entorno, que aunque se fijaba al principio de mi sistema, por un problema de configuración se perdía por el camino. La solución fue una línea de código para volver a exponer la variable de entorno al SDK, y todo empezó a funcionar como debía.

Al final, el problema de configuración no tenía nada que ver con mi análisis inicial, y aunque las consecuencias fueron mínimas (un par de días perdidos y el orgullo herido) es una muestra de lo que perdemos cuando no hacemos las preguntas adecuadas.

Conclusiones: Las preguntas correctas en la era de IA

El sesgo de confirmación a la hora de hacer análisis en profundidad es algo de sobra conocido y es la razón por la que tenemos los 5 por qué en Amazon, pero el riesgo de hacer las preguntas erróneas es mayor hoy con la llegada de herramientas basadas en IA, donde la calidad de las preguntas influye significativamente en el resultado final.

Hace unos días en el podcast de Pragmatic Engineer, Chip Huyen, autora de AI Engineering mencionaba que hoy más que nunca es importante hacer los prompts adecuados para sacar el mayor partido de estas herramientas, lo que me hizo acordarme de este escenario y decidir compartirlo en el blog como ejemplo del uso de las preguntas erróneas.

Volviendo a la película de Yo Robot, el holograma nos da otra pista que nos permite entender la trama de la película Youtube y nos recuerda que, en todo sistema «las respuestas son limitadas, debes de hacer las preguntas adecuadas«.