Entropy Tolerance: La Pregunta de Software Más Importante Que No Estás Haciendo

En el desarrollo de software, hay muchas preguntas que nos hacemos. ¿Quiénes son mis usuarios? ¿Cuáles son los requisitos para esta característica? ¿Cuál es la stack que debería usar? ¿Cómo debería desplegar? ¿Dónde debería desplegar? Y en la era de la AI, creo que hay una pregunta faltante. Y así que vamos a discutir aquí en esta charla cuál es esa pregunta y cómo puede ayudarnos a tomar mejores decisiones cuando se trata de implementar AI, utilizar AI, en software. Así que esta charla trata sobre la tolerancia a la entropía, la pregunta de software más importante que no estás haciendo.

Para empezar, necesitamos hablar sobre la diferencia entre software determinista y no determinista. Cuando decimos la palabra determinismo, eso significa que cuando damos a un sistema un cierto conjunto de entradas, siempre obtenemos las mismas salidas si damos las mismas entradas. Toda la era digital se basa en la confiabilidad de los procesos deterministas. Por ejemplo, solo un ejemplo muy simple. Pensemos en una calculadora. Supongamos que tienes una calculadora que solo suma dos números. Entonces digo, ¿cuánto es uno más uno? Y obtengo un dos. Esa es una respuesta esperada. Es la correcta. Y la próxima vez que use la calculadora, si le doy esos mismos dos inputs, obtengo la misma salida. Los mecanismos internos del sistema son deterministas.

Pero para nuestros propósitos, usemos el mismo ejemplo de calculadora, pero un ejemplo que es más útil para pensar en modelos de lenguaje grandes y AI. Supongamos que tengo la misma idea de una calculadora que solo suma dos números, y puedo darle entradas. ¿Cuánto es uno más uno? Pero la calculadora, en lugar de realizar un proceso determinista, lleva a cabo una revisión de cada posible respuesta que se ha registrado por ahí. Diremos que es un corpus de posibles respuestas. La mayoría de las respuestas son correctas. Algunas de ellas no lo son. Y la forma en que esta calculadora funciona es que cuando le das dos entradas, esencialmente lanza un par de dados y elige de ese corpus, de ese conjunto de posibles respuestas que se han registrado en su memoria, para darnos entonces un resultado final.

Ahora, la primera vez que usamos la calculadora, parece precisa. Pero la próxima vez que usemos la calculadora, después de suficientes veces, eventualmente, podemos lanzar un dado y obtener una respuesta incorrecta seleccionada porque los internos del sistema no tienen concepto de correcto o incorrecto, solo un comportamiento probabilístico basado en un gran conjunto de posibilidades. Así que terminamos con una salida diferente para las mismas entradas. Ese es un comportamiento no determinista. En este caso, debido al comportamiento probabilístico o estocástico, es inconsistente.

Ahora, aquí está la pregunta de negocio. ¿Cómo te sentirías acerca de una calculadora muy rápida que a veces, de manera impredecible, podría darte la respuesta incorrecta? ¿Cuáles son los pros y los contras que estás sopesando con el uso de esta calculadora? Bueno, realmente depende de lo que estás tratando de calcular. No se trata tanto de la calculadora, sino del proceso que estás usando para apoyar con la calculadora. Si el proceso que estás usando para apoyar puede manejar que las cosas sean incorrectas de vez en cuando, entonces la velocidad de la calculadora podría ser un riesgo que valga la pena.

Pero si no puedes tolerar la incorrección, entonces esa velocidad, el valor de esa velocidad, ya no coincide con el riesgo. Imaginemos un piloto automático no determinista en un avión. En lugar de tener un sistema determinista donde obtienes esas entradas de sensores y siempre obtienes la misma salida con una entrada sensorial particular, ¿qué pasaría si reemplazamos eso con un modelo de lenguaje grande que simplemente está improvisando como nuestro piloto automático? Ahora, imagina que estás sentado en una puerta, listo para abordar el avión, y se anuncia que en este vuelo, será operado por un piloto automático, que en realidad es un modelo de lenguaje grande, que recibirá las entradas sensoriales y luego dará la salida a los sistemas del avión para navegar. Y no hay pilotos humanos en los asientos. ¿Abordarías el avión? Te diré, yo no lo haría. Y apuesto a que muchos de ustedes tampoco lo harían. Porque sabemos que el factor de riesgo es demasiado alto para el valor que estás obteniendo de un proceso no determinista, un modelo de lenguaje grande, que está extrayendo posibles valores, una máquina de predicción basada en un corpus de datos tremendo y enorme en el que ha sido entrenado. Y sin embargo, estamos añadiendo no determinismo todos los días a los procesos empresariales sin una forma de juzgar o medir el peligro.

Así que, como líderes técnicos, necesitamos ir más allá del bombo, más allá del marketing de AI, y pensar críticamente sobre lo que estamos añadiendo a los procesos empresariales subyacentes cuando añadimos e integramos AI y LLMs en esos procesos. Pero necesitamos una forma de medirlo. Tenemos todas estas métricas para el desarrollo, pero el problema es que no tenemos una forma intrínseca de medir este riesgo. Así que, lo que he hecho es que en realidad he introducido una idea, creado un término, y te invito a usarlo si lo encuentras útil en tu liderazgo. Para explicarlo, primero necesitamos hablar sobre la idea de entropía. Ahora, la entropía tiene algunos significados diferentes dependiendo de la ruta científica o matemática de la que estés hablando. Pero en nuestro caso, estamos hablando de lo que se llama entropía de Shannon, nombrada así por Claude Shannon, que es de donde se nombra el Claude AI. Y esa entropía tiene que ver con las ciencias de la información. Y la idea es que el nivel promedio de incertidumbre de un valor a través de una distribución de probabilidad es su entropía. Ahora, eso es un poco matemático, pero vamos a usar eso como inspiración para dar una idea algo más simplista. Que la entropía de algo es la cantidad de azar o probabilidad en un proceso. Así que, esa es la definición con la que vamos a avanzar para este propósito.

Así que, introducimos la pregunta fundamental, la pregunta que deberías hacerte a medida que integramos AI en el software, en los procesos empresariales. ¿Cuál es la tolerancia a la entropía de un proceso? Eso significa cuánta casualidad puede manejar el proceso que estás llevando a cabo. La tolerancia a la entropía no se trata de si deberías o no usar la generación de código AI, no puramente eso. Realmente se trata de los procesos subyacentes que un software particular apoya, porque el software realmente está apoyando siempre algún proceso subyacente. Entonces, ¿ese proceso tolera la inexactitud potencial? ¿Tolera la influencia y los efectos de las probabilidades compuestas? Así que, lo que me gustaría hacer ahora es mostrarte un marco de decisión que puedes usar con esta idea de tolerancia a la entropía. Así que, este es el marco de decisión de tolerancia a la entropía. Identificas una tarea, una tarea que el software va a apoyar y que quizás vas a integrar AI en ella. Y esto podría ser el desarrollo del software en sí. Así que, eso podría ser una característica de AI que se está añadiendo a un proceso particular o a una pieza particular de software. O, podría ser cuánta generación de código AI sin verificaciones humanas vas a tener involucrada. En el proceso, sea lo que sea, vas a identificar lo que estás haciendo, el proceso en el que estás tratando de participar.

Y te vas a preguntar primero, ¿tolera este proceso la aleatoriedad? Y veremos algunos ejemplos en solo un minuto. Pero esa es la pregunta central. ¿Cuál es su tolerancia a la entropía? Si es una baja tolerancia, eso significa que no puedes tener mucha probabilidad en juego. Y si es una alta tolerancia, entonces está bien. Así que, definiremos tres niveles. Tenemos una baja tolerancia, lo que significa que debemos ser exactos. Esto es un alto riesgo para el valor. Si tenemos problemas, si tenemos inexactitudes, si tenemos alucinaciones de AI, es un alto riesgo. Medio está en algún lugar intermedio. Tenemos algo de flexibilidad. Probablemente podríamos manejar alguna inexactitud, pero no siempre. Y luego tenemos una tolerancia muy alta para la entropía, para procesos probabilísticos, no deterministas. Eso podría ser procesos de muy bajo riesgo, donde la inexactitud está realmente bien.

La siguiente fase, sin importar cuál sea la tolerancia a la entropía, es ¿cuál es el valor para el proceso de usar AI en primer lugar? Y eso podría ser bajo, o podría ser alto. Así que, bajo valor o alto valor de usar AI en este proceso. Entonces, si tenemos un proceso de baja tolerancia, baja tolerancia a la entropía, no podemos manejar, no podemos tolerar demasiada inexactitud, alucinación, aleatoriedad, salidas inesperadas en este proceso. Bueno, si no hay mucho valor en usar AI, entonces simplemente mantenlo centrado en humanos. Haz que los humanos lo hagan. No significa que los humanos no cometan errores. Pero como sabemos, con humanos en el proceso, tenemos una mejor oportunidad de detectar esos errores a medida que avanzamos. Porque la cantidad de salida de un humano es a la velocidad de la verificación humana.

Por otro lado, alto valor de usar AI para una baja tolerancia, bueno, entonces puede que quieras incluir AI. Pero tendrás que verificar la salida de AI. Tendrás que tener humanos en el bucle. Así que, se convierte en una colaboración AI-humano si hay un alto valor con baja tolerancia a la entropía. Para tolerancia media, bueno, es muy similar. Podrías querer mantenerlo centrado en humanos si hay algún riesgo en absoluto. Aunque esta puede ser una elección que tengas que hacer dentro de tus propias organizaciones y estructuras y partes interesadas, etc. Y, de nuevo, colaboración humano-en-el-bucle, si hay un alto valor en usar AI, si el valor de agregar procesos de AI va a ser alto, entonces podrías querer seguir adelante y lidiar con esa tolerancia. Pero humano-en-el-bucle te mantendrá seguro.

Y si hay una tolerancia muy alta, bueno, genial. Si realmente no obtienes mucho valor de la AI, entonces podrías tener algún tipo de colaboración híbrida. Tal vez algunas personas quieran usar AI para su trabajo particular. Otros no. Si no hay mucho valor en la AI y es una tolerancia muy alta, realmente no importa demasiado. Pero si hay un valor muy alto en usar AI y tiene una tolerancia muy alta, una tolerancia a la entropía muy alta, donde la inexactitud está bien, no va a ser el fin del mundo, no va a ser un gran riesgo para ti, para la organización, para el negocio, para lo que sea que estés liderando. Eso podría ser un proceso liderado por AI. Eso podría ser un proceso codificado por vibración. Así que al tener este marco de decisión, podemos tomar decisiones.

Por ejemplo, supongamos que la tarea que vamos a realizar es tratar con solicitudes de clientes para tickets de soporte en algún tipo de sistema de tickets que comienza con un chatbot. Entonces la pregunta es, ¿tolera este proceso la aleatoriedad? Bueno, podría depender de qué sistema es, qué tipo de tickets estamos recibiendo de los clientes. Si es un sistema bancario donde se están realizando transacciones financieras y recibimos un ticket de soporte porque algo salió mal con la transacción financiera, eso podría ser muy diferente de un ticket de soporte para algo mucho menos urgente. Entonces, sea lo que sea, digamos que decidimos como organización, como líderes, que es de tolerancia media, tenemos algo de flexibilidad, entonces la pregunta se convierte en, ¿cuál es el valor? Bueno, supongamos que el valor es muy alto, porque si añadimos AI y LLM para clasificar los tickets, tratar con los tickets, responder a los tickets, resaltar la urgencia, bueno, eso podría permitirnos tratar con otras cosas, otros problemas que son potencialmente más importantes y puede sacar a la luz las cosas realmente importantes en las que necesitamos enfocarnos.

Así que eso sería, para esto, tal vez decidirías que es una colaboración humano-en-el-bucle. Podríamos tener una AI tal vez como el primer nivel de interfaz con el cliente, pero permitir que el cliente lo actualice a un humano, o tal vez tener la AI categorizada por urgencia y luego tener humanos revisando dependiendo del nivel de urgencia, por ejemplo. Así que como podemos ver, al tomar esas decisiones, comenzando con la pregunta, ¿cuál es la tolerancia a la entropía, eso ayuda a definir cómo tratamos con AI dentro del proceso en sí. Hay otros ejemplos que podríamos pensar, de procesos de baja, media y alta tolerancia a la entropía. Por ejemplo, ¿cuáles podrían ser algunos procesos de baja tolerancia? Sistemas de diagnóstico médico, muy baja tolerancia a la inexactitud, procesamiento de transacciones financieras, muy baja tolerancia a números ligeramente incorrectos que no son deterministas, que no son consistentes.

Una auditoría de vulnerabilidades de seguridad del código. Quizás un sistema de AI inicialmente tenga algunas respuestas a eso, algunas recomendaciones, pero eso no significa que un humano no necesite también echar un vistazo, humano-en-el-bucle, al código que se está generando. Entonces, eso podría ser de baja tolerancia, y por lo tanto principalmente liderado por humanos, con colaboración humano-AI y humano-en-el-bucle. Para media, tal vez eso podría ser como un chatbot de servicio al cliente, como mencionamos, tal vez extrayendo datos de PDFs pero solo para informes, no para actualizar datos en una base de datos, y eso dependería del tipo de decisiones que se tomen a partir del informe.

Tal vez asistencia en la revisión de código, sugerencias mientras tus desarrolladores están codificando. Bueno, eso también podría ser algún tipo de colaboración humano-AI con un poco más de tolerancia a lo que la AI está haciendo. Luego tenemos alta. Alta sería el prototipado de software para pruebas de usuario. No importa. Puedes codificar un prototipo, no va a producción, puedes probar con usuarios, y podrías generar todo con LLMs. Está bien. Lluvia de ideas y generación de ideas de marketing, no va a dañar nada. Creación de borradores de contenido para blogs, solo sacando algunas ideas antes de que sean editadas y refinadas. Todos esos tienen una tolerancia muy alta, y así podemos hacer un juicio sobre cómo integrar AI en esos procesos.

Así que como líderes técnicos, yendo más allá del bombo, más allá de cualquiera de esas ideas que un marketing podría producir, sino más bien siendo líderes técnicos fuertes teniendo soluciones pragmáticas, entonces estamos pensando en escepticismo y realismo cuando se trata de LLMs. Entendemos lo que son. No son personas que piensan. Son máquinas de predicción de grandes corpus de texto. Y así, porque son estos sistemas probabilísticos no deterministas, somos escépticos de sus resultados. Entendemos dónde necesitamos verificación. Dónde necesitamos tener juicio de sus resultados. E integramos nuestra AI, ponderamos esa integración según la tolerancia a la entropía.