Técnicas de detección de incertidumbre en los LLM

• Entropix es un proyecto que busca leer la incertidumbre de un LLM en el momento de elegir el siguiente token y mejorar la calidad del razonamiento cambiando el método de muestreo según el estado
• Los criterios de decisión son la entropía y la varentropía (varentropy) de la distribución de logits, y con la combinación de ambos valores divide el estado de confianza del modelo en 4 categorías
• En estados de alta confianza, el muestreo argmax es adecuado, pero cuando hay varios candidatos fuertes se pueden comparar rutas mediante ramificación (branching)
• Un estado de alta entropía puede significar que el modelo realmente no sabe o que las opciones son prácticamente equivalentes, por lo que hacen falta respuestas como insertar un token de pensamiento (thinking token), ajustar la temperatura o ramificar
• Aún no hay una evaluación a gran escala, así que su efectividad sigue siendo incierta, pero el muestreo en tiempo de inferencia es un área donde se puede intentar mejorar con experimentos open source sin grandes presupuestos

---

El problema al que apunta Entropix

• Entropix es un proyecto desarrollado por XJDR que propone mejorar la inferencia cambiando la estrategia de muestreo cuando el modelo atraviesa momentos de incertidumbre
• Todavía no existe una evaluación a gran escala de Entropix, así que no está claro cuánto mejora realmente el rendimiento
• Aun así, el muestreo basado en incertidumbre ofrece un método experimental y un modelo mental distinto para entender la inferencia de los LLM

Dónde se manifiesta la incertidumbre en un LLM

• El muestreo es el proceso por el cual un LLM decide qué token elegir entre los logits, que representan la distribución de tokens posibles
• El grado de confianza del modelo puede observarse en la distribución de logits del siguiente token
  • Si la confianza es alta, la probabilidad se concentra claramente en algunos tokens
  • Si la confianza es baja, los candidatos al siguiente token se reparten de manera más amplia
• La incertidumbre no siempre es una mala señal, y puede tener varias causas
  • Cuando los tokens son sinónimos o en la práctica equivalentes, como good y great
  • Cuando existen rutas de ramificación, como en el caso de que un programa pueda escribirse en Java o en C
  • Cuando el modelo no sabe qué hacer o se enfrenta a una entrada fuera de distribución (out of distribution) que no vio en los datos de entrenamiento

Entropía y varentropía

• Entropix mide la incertidumbre con la entropía (entropy) y la varentropía (varentropy) de los logits
• La entropía representa cuánto difieren entre sí los logits predichos y muestra la incertidumbre respecto al resultado más probable
  • Con entropía baja, el modelo tiene bastante confianza en algunos logits
  • Con entropía alta, la distribución de logits se vuelve más uniforme y la confianza baja
• La varentropía es una métrica que muestra la forma (shape) de la incertidumbre
  • Una varentropía alta significa que algunos valores difieren mucho de otros
• Ambas métricas se basan en el concepto de surprisal (self-information)
  • El surprisal mide qué tan inesperado es un evento en relación con su probabilidad
  • Si la probabilidad del evento x es P(x), entonces su surprisal es I(x) = -log₂(P(x))
  • Si P(x) = 1/8, el surprisal es de 3 bits, y si P(x) = 1/2, es de 1 bit
• La entropía es el valor esperado del surprisal de todos los resultados posibles
• La varentropía se calcula como la varianza del surprisal y muestra cuánto más sorprendentes son algunos resultados en comparación con el surprisal promedio

4 estados de incertidumbre

• Si se observan juntas la entropía y la varentropía, el estado del modelo puede dividirse en 4 categorías
  • Entropía baja · varentropía baja: una distribución picuda en la que un solo resultado tiene una probabilidad muy alta
  • Entropía baja · varentropía alta: una distribución con varios picos distintos
  • Entropía alta · varentropía baja: una distribución uniforme o casi uniforme
  • Entropía alta · varentropía alta: una distribución extendida pero no uniforme

Muestreo adaptativo según el estado

• Entropía baja · varentropía baja

  • Es el estado ideal, donde el modelo tiene bastante certeza no solo sobre su primera opción, sino también sobre alternativas en caso de que esa elección sea incorrecta
  • Cuando la lista de candidatos está ordenada con claridad, el muestreo argmax, que elige el token con mayor probabilidad, resulta adecuado

• Entropía baja · varentropía alta

  • Es un estado en el que el modelo predice muy alto unas cuantas opciones
  • Puede significar una ruta de salida completamente nueva o una situación en la que varias expresiones son posibles, como ocurre con los sinónimos, así que es difícil de interpretar
  • Una respuesta posible es la ramificación (branching): predecir ambos logits, seguir cada ruta por separado y comparar los resultados después de cierto punto
  • Si los resultados de la ramificación tienen niveles de confianza parecidos pero contenidos distintos, eso podría convertirse en una pregunta para el usuario

• Entropía alta · varentropía baja

  • Puede ser un estado de baja confianza del modelo o una situación en la que todas las opciones son intercambiables
  • En este caso, Entropix propone insertar como siguiente token un token de pensamiento para llevar al modelo hacia un estado de mayor confianza
  • Un ejemplo es un token como Wait..
  • El token de pensamiento se inserta en la salida como señal de que el modelo debe dedicar más tiempo de cómputo a pensar antes de responder
  • Por ejemplo, si el modelo intenta predecir The capital of Germany is Paris pero no está seguro, puede insertar Wait y continuar como The capital of Germany is Paris… Wait, no, it’s actually Berlin

• Entropía alta · varentropía alta

  • No hay un candidato claramente superior, pero el modelo sí tiene más confianza en algunas salidas que en otras
  • Puede ocurrir que las opciones principales sean todas válidas, como sinónimos, por lo que se puede hacer una elección aleatoria con una temperatura (temperature) más alta
  • También se puede ramificar o insertar un token de pensamiento, igual que en los estados anteriores

Diferencia entre ramificación y token de pensamiento

• Ambos enfoques buscan usar más cómputo de inferencia cuando el modelo está en un estado incierto
• La predicción por ramificación sigue varios logits para verificar a qué otros tokens conducen
  • A esto se le suele llamar MCTS (Monte Carlo Tree Search)
  • Se ha intentado con frecuencia en LLM, pero los resultados han sido moderados
  • El principal trade-off es que cada rama no puede aprovechar el cómputo de las demás
• El token de pensamiento es una forma de obtener cómputo adicional en estados inciertos sin gastar recursos explorando ramas que luego podrían descartarse
  • Insertar Wait… hace que la IA reconozca que pudo haberse equivocado
• Cuál de las dos opciones, ramificación o token de pensamiento, es mejor sigue siendo una pregunta de investigación abierta

Señales basadas en atención

• Entropix también usa algunas otras métricas de entropía al ajustar la temperatura
• Attention Entropy indica si una cabeza de atención sigue un token específico o reparte su atención entre muchos tokens del contexto
• Attention Agreement muestra si varias cabezas de atención se enfocan en el mismo token o miran tokens distintos
• Si la entropía de las cabezas es baja y el agreement es alto, eso puede ser una señal adicional de que se puede muestrear el token de mayor probabilidad
• Si el agreement es bajo, distintas cabezas podrían estar contribuyendo a predicciones diferentes, así que valdría la pena considerar una ramificación

Por qué importa

• La idea de Entropix es fácil de entender y no es completamente nueva, pero hace replantear la mejora de la inferencia en LLM desde la etapa de muestreo
• Aunque todavía no se han confirmado grandes ventajas en las evaluaciones, este tipo de técnicas en tiempo de inferencia son relativamente fáciles de experimentar
• Puede convertirse en una dirección prometedora para que hackers open source intenten mejorar la inferencia sin grandes presupuestos

[GN⁺]

Opiniones de Hacker News

• Se dice que le preguntaron dos veces: “Sr. Babbage, si se ingresan números incorrectos en la máquina, ¿saldrá la respuesta correcta?”
  Es una frase de Charles Babbage, quien dijo que no podía comprender bien cuál era la confusión de pensamiento que daba lugar a una pregunta así.

  • La gente cree saber qué debería hacer la “IA”, pero cuando en la práctica se comporta de forma distinta a sus expectativas, la llama rota.
  • Es una pregunta bastante legítima y, más bien, parece que Babbage no la entendió o fingió deliberadamente no entenderla.

• Estas técnicas basadas en muestreo son uno de los pocos casos en los que se puede intentar mejorar modelos de última generación con hardware de consumo.
  No creo que dure mucho y, al final, aparecerán muestreadores entrenables, pero por ahora vale la pena trastear con esto todo lo que se pueda: https://github.com/codelion/optillm
  Los autores de optillm parecen considerar que el cómputo adicional de Entropics no ofrece mejores resultados que una decodificación simple de cadena de pensamiento. No sé si también comprobaron la eficiencia: https://x.com/asankhaya/status/1846736390152949966
  Muchos problemas de los LLM parecen venir de la fuga semántica o de que la atención se dispersa hacia información irrelevante, como en el paper GSM Symbolic, y quizá haya margen para mejorar la atención.
  También escribí algunos textos relacionados: https://zzbbyy.substack.com/p/semantic-leakage-quick-notes, https://zzbbyy.substack.com/p/llms-and-reasoning, https://zzbbyy.substack.com/p/o1-inference-time-turing-machi...

  • El problema con muchas de estas técnicas de muestreo está en cómo suele evaluarlas la gente.
    Hay quienes afirman que funcionan mejor, pero no hay benchmarks rigurosos que lo demuestren. Se dice cosas como “el texto sale mejor” o “el estilo se siente fresco”, y creo que LeCun tiene 100% de razón en este punto. Evaluar un modelo de propósito general diciendo que funciona bien en “poesía” o “prosa” se acerca mucho a la definición de sesgo, y es ponerse uno mismo la soga al cuello con anécdotas personales.
    Me gustaría ver resultados aplicados a programación o matemáticas. Por ejemplo, si un muestreador funciona mejor en problemas de olimpiadas matemáticas, quisiera que se hiciera un benchmark cuidadoso antes y después.
  • La fuga semántica puede ser simplemente una debilidad del modelo, o puede conectarse con el argumento de que el modelo no razona “de verdad”. También es posible que más entrenamiento ayude.
    O quizá sea una debilidad más fundamental del mecanismo de atención. Hoy ya están apareciendo alternativas.

• No tengo claro si este proyecto está basado en papers académicos, es decir, si usa una técnica publicada para determinar la incertidumbre de los LLM.
  Entre los trabajos recientes, este parece bastante relacionado: https://learnandburn.ai/p/how-to-tell-if-an-llm-is-just-gues...
  Ahí se usa una idea llamada entropía semántica, más sofisticada que la entropía estándar de los logits de tokens, y más adecuada para cuantificar estadísticamente si un LLM está adivinando o tiene alta confianza. El paper original es un artículo de Nature de autores de Oxford.

  • La idea central de la entropía semántica, es decir, estimar la entropía de la distribución de unidades semánticas en lugar de secuencias individuales del espacio de salida, es buena, pero resulta algo ingenua en la medida en que considera esas unidades semánticas como una partición bien definida del espacio de salida.
    También hay un trabajo [1] que generaliza más este enfoque, realizando una agrupación suave basada en la noción de equivalencia semántica entre salidas muestreadas.
    Aun así, hay que tener cuidado. Recientemente publicamos un paper [2] que hace un benchmark integral de las técnicas más recientes de estimación de incertidumbre en LLM, y en muchos casos los métodos que consideran el significado funcionan muy bien, pero en otras tareas líneas base simples, como la entropía promedio de la distribución de tokens, resultaron similares o incluso mejores que técnicas complejas.
    Además, estamos desarrollando una biblioteca open source en Python [3] que implementa técnicas modernas de estimación de incertidumbre aplicables a LLM, y facilita tanto el benchmark de métodos de estimación como la estimación de la incertidumbre de salida de modelos en operación.
    [1] https://arxiv.org/abs/2307.01379
    [2] https://arxiv.org/abs/2406.15627
    [3] https://github.com/IINemo/lm-polygraph
  • Esto se basa en el trabajo de esta cuenta anónima de Twitter: https://x.com/_xjdr
    Lo he seguido bastante de cerca, y me pareció interesante que los modelos pequeños podrían ser más eficientes con este muestreador. Si te interesa, vale la pena leer sus publicaciones, y este tipo de muestreo se siente como algo muy significativo.
  • No creo que sea un paper académico. Si viniera de la academia, esperaría que entendieran mejor la diferencia entre incertidumbre de tokens e incertidumbre semántica/corrección semántica, o que intentaran establecer una correlación basada en datos antes de afirmar una relación entre ambas.
    Como escribí también en otro comentario, el autor parece tener un malentendido fundamental, y por la nota al inicio del texto da la impresión de que eso quizá explica que no haya logrado resultados prácticos reales.
    No lo digo para culparlo ni para desalentarlo. Puede que haya captado algo, y vale la pena probar enfoques peculiares como este. Pero por las razones anteriores, si no tuvo un efecto positivo, habría sido difícil que saliera como paper; así que tampoco sorprende que no haya un paper académico sobre este enfoque.
  • Hasta donde sé, no es un paper académico, y por eso quise escribir este texto. Aun así, este proyecto tiene tanto seguidores fervientes como detractores fervientes en ML Twitter.
  • Mi comentario iba dirigido a lectores de HN interesados en la incertidumbre de los LLM; al autor del texto/repositorio le diría que me gustaría ver resultados de pruebas sobre qué tan bien identifica realmente la incertidumbre.

• Cuando la entropía es alta, creo que el modelo debería tener una salida de emergencia
  Debería activarse una señal de que la certeza de la respuesta completa es baja, e ir acumulando una puntuación de certeza durante la generación para que al final el usuario pueda verificar si la certeza de la respuesta fue pésima. Esas respuestas deberían poder descartarse o reemplazarse por “No lo sé”.

  • Normalmente se le llama abstención o rechazo
    En este campo, al comparar distintos métodos para cuantificar la incertidumbre del modelo, suele hacerse una validación de rechazo. Básicamente, se van rechazando los puntos de datos con alta incertidumbre y se observa cómo sube la calidad promedio de las salidas restantes. Una buena estimación de incertidumbre debería correlacionarse fuertemente con la calidad de la salida, así que la calidad promedio de las salidas con baja incertidumbre debería ser mayor.
    Un benchmark reciente de enfoques de estimación de incertidumbre en LLM [1] usó precisamente este método, y también se está desarrollando una biblioteca open source [2] que permite hacer este tipo de benchmarks. También puede generar puntuaciones de incertidumbre para salidas específicas de modelos, de modo que en entornos industriales se puede integrar en aplicaciones.
    [1] https://arxiv.org/abs/2406.15627
    [2] https://github.com/IINemo/lm-polygraph
  • El problema es que, en general, los clasificadores de redes neuronales profundas no están bien calibrados estadísticamente por defecto
    Por eso, cuando la entropía es alta muchas veces sí es una señal de “no tengo certeza”, pero el modelo también puede equivocarse con mucha confianza con bastante frecuencia. Así que usar la entropía de los logits como indicador de confiabilidad puede llevar fácilmente a malentendidos importantes.
    No soy especialista en LLM; es una opinión basada en mi entendimiento de clasificadores en general. Me pregunto si, con suficientes datos, esta consideración deja de aplicar.
  • Entropix te da un framework para hacer ese tipo de cosas. Por diseño, detecta el estado actual y luego ajusta la configuración del muestreador o cambia a una estrategia de muestreo completamente nueva
    También se puede experimentar empujándolo lo suficiente hacia respuestas de rechazo, y recomiendo probarlo directamente. El repositorio smollm-entropix [1] implementa todo como un notebook de Jupyter, lo que facilita más probar la idea.
    [1]: https://github.com/SinatrasC/entropix-smollm
  • Parece casi seguro que se agregarán muchos tokens adicionales al vocabulario. No solo tokens de thinking, sino posiblemente también tokens de “no sé”, y surgirán muchas estrategias de decodificación sofisticadas. Lo que hace falta es generar los datos.
  • En mi experiencia, el nuevo Claude Sonnet 3.5 hace algo de eso.

• Los grandes GPT modernos emiten logits de un clasificador enorme sobre todo el vocabulario de tokens
  Estos están en algún espacio, y no solo se puede asumir una variedad con propiedades de convexidad no triviales, sino que también se puede calcular empíricamente. El problema de determinar qué LLM escribió un texto —incluso cuando se le indicó usar cierto estilo— está bien definido o, en la práctica, cerca de estar resuelto.
  Esto no solo era un problema que se estaba investigando, sino un área donde había avances rápidos e impresionantes, hasta que en algún momento simplemente la apagaron.
  Ser el mejor en este campo es un negocio enorme. Y es el tipo de cosa típica que debería hacer una startup. Porque es difícil que aparezcan como competidores los incumbentes con mucho dinero: no porque ignoren el mercado, sino porque activamente no quieren que este mercado exista.

  • ¿Puedes explicar un poco más por qué esto sería útil? Por la descripción, parece que una parte considerable de las solicitudes modificaría la salida lo suficiente como para impedir la detección de un LLM específico. Además, el hecho de que los LLM nuevos usen muchos datos sintéticos/generados parece introducir una variable bastante grande.

• Esta forma de explicarlo suena casi como un algoritmo de exploración de laberintos. Aquí el tiempo de cómputo correspondería a “qué tan profundo seguir una ruta para probar si es una solución posible”
  Me pregunto si habrá otras similitudes. Por ejemplo, ¿habrá algoritmos para resolver laberintos que puedan aplicarse a los LLM?

  • Muestrear secuencialmente para encontrar la secuencia completa con la probabilidad conjunta más alta es claramente un problema de búsqueda. Por eso algoritmos como beam search se usan con frecuencia en el muestreo.
  • También planteé una pregunta sobre abordar la decodificación de LLM desde una perspectiva de navegación, aunque desde otro ángulo, en este post de Reddit: https://www.reddit.com/r/MachineLearning/comments/1dw2pqo/d_...
  • Sí, parece un área con margen para más investigación
    Si soy sincero, va en la dirección contraria a la Bitter Lesson (http://www.incompleteideas.net/IncIdeas/BitterLesson.html). Esa lección también surgió de haber tratado de forma demasiado elaborada la exploración de laberintos en ajedrez. Pero a la escala actual de los LLM, este tipo de mejoras quizá sí valga la pena.

• Cada vez que leo sobre estas posibles optimizaciones, me cuesta entender cómo la gente confía en los LLM y los usa con apenas supervisión
  ¿De verdad creen que los productos de “IA” que usan LLM son lo suficientemente competentes como para controlar una computadora o escribir código preciso? ¿No es todo, por diseño, una “alucinación” o una conjetura? ¿De verdad se puede superar eso?

  • Con ChatGPT y Python escribí o supervisé varios programas que usamos en el sistema de pruebas de producción de mi empresa
    Son programas que envían acciones a máquinas, consultan resultados/errores/salidas, los guardan en un .csv y luego los convierten en un archivo de Excel con formato agradable. También ofrecen una guía de inicio que muestra cómo debe conectar las cosas un técnico en pruebas específicas
    No soy programador, y en nuestra empresa tampoco hay programadores. Aun así, escribió código que funciona exactamente como pedí. Cuando el código se trababa durante el desarrollo, lo volvía a meter en ChatGPT para que lo resolviera, y al final resolvió todo. Me tomó más o menos un día; si lo hubiera hecho yo, habría tardado un mes, y si lo hubiera tercerizado, habría costado 10 mil dólares y una semana
    Los LLM pueden ser malos para proyectos de programación avanzada y de sueldos altos. Pero son una bendición para la gente que necesita hacer algo con una computadora, pero no logra cruzar la barrera del idioma de decirle a la computadora qué hacer
  • ¿Cómo la superan los humanos? Si lo piensas bien, llegarás a la conclusión de que los LLM pueden usarse para todo tipo de cosas. Por ejemplo, los humanos tampoco escriben código y lo mandan directamente a producción
  • Claro que confío. No es una pregunta hipotética. Casi todo mi código lo escribió Claude 3.5 Sonnet
    Es mucho más robusto y preciso que el código que suelo escribir yo. Llevo 20 años programando
  • Yo diría que no. Pero cuando los humanos invierten demasiado, ya sea emociones o dinero, no se echan atrás fácilmente; al contrario, terminan apostándolo todo
    Es solo otra burbuja de entusiasmo. Como Client/Server, Industry 4.0, Machine Learning, Microservices, Cloud o Crypto

• ¿Alguien habrá experimentado con qué pasa con la salida si haces que el modelo nunca pueda estar inseguro?
  Por ejemplo, que cada vez que la certeza cae por debajo de un umbral, el muestreador retroceda y elija otro token. Al final, cada token individual tendría una certeza por encima del umbral
  No eliminaría por completo las salidas no deseadas, pero sería interesante

  • ¿Entonces quizá no podría dar ninguna respuesta?
    O podría decir “No sé” con total certeza
  • Antes se obtenían salidas casi deterministas, parecidas a citas textuales, pero aun así se veían afectadas por errores de punto flotante

• Hay miles de millones de estrategias de muestreo para modelos de lenguaje
  El problema es que es muy difícil demostrar empíricamente que una estrategia de muestreo es mejor que el muestreo top-k o top-p estándar. Minimizar la perplejidad por sí solo no basta para probar la superioridad de un método específico. La estrategia propuesta en el artículo del blog tiene el mismo problema. En teoría suena plausible, pero en la práctica es una innovación no verificada

  • No necesariamente hace falta una prueba
    Es difícil probarlo porque cuesta definir con claridad qué significa “mejor”, y porque recopilar cosas como datos de preferencia es caro
    Después de ver muchas muestras, uno puede decir con sentido común: “si quieres optimizar X, este método parece funcionar mejor”

• Las limitaciones de las respuestas de los LLM tienen muchas más dimensiones que una sola “incertidumbre”
  Están cosas como “la pregunta/oración no tiene sentido”, “no hay información suficiente para responder” o “hay información de que el consenso de expertos es que ‘nadie puede saberlo realmente’”
  Existe una tendencia humana a reducir las razones por las que una pregunta dada es difícil de responder a un simple problema de incertidumbre, y por eso también se ven las respuestas de los LLM como si tuvieran un único nivel de incertidumbre. Pero eso es antropomorfizar
  Las imágenes de IA, y antes la fotografía, mostraron formas nuevas e inimaginadas en que una imagen puede estar equivocada: formas que parecen reales, pero son incorrectas. Las interacciones lingüísticas con IA hacen lo mismo, solo que de manera más sutil

  • De acuerdo. Pero si se puede detectar la posibilidad de haber entrado en uno de esos estados, entonces se puede revisar exactamente cuál es
    Hasta ahora se ha hecho sobre todo con aprendizaje por refuerzo, pero parece valer la pena explorar formas de detectarlo y manejarlo en tiempo de inferencia. Además, eso es mucho más accesible en open source. Ese tipo de aprendizaje por refuerzo es algo que solo pueden hacer los grandes laboratorios de ML
  • Es una expresión tan antropomórfica como llamar alucinación a la inexactitud de un modelo
    Siento que la antropomorfización es parte de la estrategia de marketing de los LLM
  • Es cierto que incertidumbre es un término definido de manera bastante laxa. Normalmente se usa como una especie de indicador sustituto de la probabilidad de que la salida del modelo sea correcta en algún sentido
    La incertidumbre también puede descomponerse en varios “sabores”. La descomposición más simple y discutida con frecuencia es entre incertidumbre aleatoria e incertidumbre epistémica. La incertidumbre epistémica, o incertidumbre basada en el modelo, suele referirse a los casos en que el modelo recibe un tipo de entrada que no ha visto antes y produce una mala salida, una situación en la que es difícil esperar que la maneje correctamente. En cambio, la incertidumbre aleatoria es inherente a los propios datos; piensa en la ambigüedad natural de la tarea o en etiquetas ruidosas
    En el campo de la estimación de incertidumbre hay mucho interés en desarrollar métodos para cuantificar estos distintos tipos de incertidumbre, y cada método puede ser más sensible a uno u otro
  • Parece muy relacionado con mi uso de LLM para estructurar datos. Necesito exactamente un buen indicador de incertidumbre para cada fragmento de datos
  • ¿No son esas también diferentes clases de incertidumbre?