Se puede entender que los LLMs razona de forma probabilista?
Sí y no, depende de qué entiendas por “razonar de forma probabilista”.
Sí, en el mecanismo de salida. Un LLM no produce una palabra, sino una distribución de probabilidad sobre todos los tokens posibles, y luego se elige uno (por muestreo o tomando el más probable). Todo el texto es una cadena de esas elecciones, así que la generación es probabilística de forma literal. Por eso la misma pregunta puede dar respuestas distintas.
No, en el sentido “bayesiano” fuerte. El cálculo interno (el forward pass) es determinista: multiplicaciones de matrices que transforman representaciones. La probabilidad solo aparece al final, en la última capa. El modelo no mantiene explícitamente hipótesis con su grado de creencia ni las actualiza con reglas de probabilidad. Además, cuando se le piden tareas explícitamente probabilísticas (tasas base, Bayes, combinatoria), comete errores parecidos a los humanos si no “razona por escrito”.
El matiz interesante. Los estudios de interpretabilidad muestran que dentro sí hay cómputo estructurado: pasos intermedios encadenados, planificación (por ejemplo, elegir la rima antes de escribir el verso) y representaciones de conceptos. No es una simple consulta de frecuencias tipo “qué palabra suele venir después”. También hay trabajos que interpretan el aprendizaje en contexto como una inferencia bayesiana implícita: el modelo se comporta como si infiriera de qué “tipo de tarea” se trata a partir de los ejemplos.
Una forma útil de verlo, como ingeniero: es un sistema determinista muy complejo que aprendió a aproximar una distribución condicional. Su salida es probabilística y su comportamiento a veces se parece a la inferencia probabilística, pero su “razonamiento” no está construido sobre reglas de probabilidad explícitas.
¿Quieres que lance una investigación con fuentes y citas sobre esto (interpretabilidad, calibración, inferencia bayesiana implícita)?
En que se basa?
Cada afirmación se apoya en trabajos concretos:
Te lo he dado de memoria, no lo he verificado ahora. Si lo quieres con enlaces y revisado contra las fuentes, lanzo la búsqueda.
Decia del razonamiento de los LLMs
Ah, perdona: en qué se basa el razonamiento en sí. Se apoya en tres cosas.
1. Entrenamiento para predecir texto. El modelo aprende a predecir el siguiente token en billones de palabras. Parece una tarea tonta, pero para predecir bien la conclusión de una demostración, la salida de un código o la respuesta a un problema, le compensa aprender la estructura que generó ese texto: reglas, relaciones causales y pasos lógicos. El razonamiento no se programa; emerge porque es útil para predecir.
2. Representaciones internas. Cada token se convierte en un vector, y los conceptos acaban siendo direcciones en ese espacio. La atención mueve información entre tokens (por ejemplo, “este ‘él’ se refiere a Juan”). Las capas MLP guardan asociaciones y hechos. Al apilar decenas de capas, se componen operaciones: buscar un dato, combinarlo con otro y sacar una conclusión. El límite es que cada token pasa por un número fijo de capas, así que el modelo solo puede encadenar unos pocos pasos “en silencio”.
3. Pensar por escrito. Por eso escribir pasos intermedios (chain of thought) funciona tan bien: el texto generado actúa como memoria de trabajo, y cada paso escrito permite otra pasada completa de cómputo. Los modelos “de razonamiento” actuales se entrenan además con aprendizaje por refuerzo en problemas verificables, como matemáticas o código. Se premian las cadenas de pensamiento que acaban en la respuesta correcta, y así aprenden a comprobar, retroceder y probar otra vía.
La limitación de fondo es que razonan a partir de patrones aprendidos. Funcionan muy bien en problemas parecidos a lo que han visto y son más frágiles ante variantes nuevas o con trampas, aunque esa frontera se va moviendo con cada generación.
Esos patrones hasta que punto son rígidos o flexibles
Están en un punto intermedio: bastante más flexibles que una plantilla, pero menos que una regla abstracta bien entendida. Depende mucho de lo abstracta que sea la representación que el modelo ha aprendido para cada cosa.
Donde son flexibles: - Combinan conceptos que nunca han visto juntos, como explicar termodinámica con metáforas de cocina o escribir código en un estilo nuevo. - Aprenden reglas nuevas en el propio prompt: le defines un mini-lenguaje inventado y lo usa. - Muchos conceptos se representan igual en distintos idiomas, señal de que no están atados a la forma superficial de las palabras.
Donde se ven rígidos: - Problemas clásicos con trampa. Le das el acertijo del lobo, la cabra y la col modificado para que sea trivial, y a veces responde con la solución memorizada del original. - Variantes contrafactuales. Rinden bien sumando en base 10 y bastante peor en base 9, aunque la lógica sea idéntica. Lo mismo con programar en una versión alterada de un lenguaje. - Cambios irrelevantes. En problemas de matemáticas escolares, cambiar nombres y números o añadir una frase que no importa baja el acierto de forma notable. - Asimetrías raras. Aprender “A es B” no garantiza saber que “B es A” (la llamada reversal curse).
Una forma de verlo: es como un ingeniero con muchísima experiencia y algo de vista para los casos típicos. Resuelve rápido lo que se parece a lo conocido, a veces reconoce mal un problema porque “le suena”, y razona de verdad cuando se para a hacerlo paso a paso. Los modelos de razonamiento recientes han reducido bastante estos fallos, justamente porque se les entrena a verificar en vez de responder por reconocimiento. Aun así, la frontera entre “entiende la regla” y “reconoce el patrón” sigue sin estar clara, y es un tema abierto de investigación.
Como son las reglas? Como una regla estricta lógica?
No. Se parecen más a un conjunto de heurísticas difusas que a reglas lógicas del tipo “si A entonces B”.
Cómo son realmente: - Graduales, no binarias. Un concepto no está “activado” o “desactivado”. Es una dirección en un espacio de vectores con cierta intensidad, y el resultado depende de cuánto pesa cada cosa. - Distribuidas. No hay una neurona o una línea de código que sea “la regla”. Está repartida entre muchas piezas, y cada pieza participa en muchas reglas a la vez. - Varias en paralelo. Un ejemplo muy claro sale del estudio de Anthropic sobre Claude: para sumar 36 + 59, el modelo usa dos caminos simultáneos. Uno estima a ojo la magnitud (“algo cerca de 90”) y otro calcula con precisión la última cifra (“termina en 5”). Combinados, dan 95. Ninguno es el algoritmo de sumar con acarreo que aprendimos en el colegio. - Dependientes del contexto. La misma “regla” se aplica con más o menos fuerza según lo que rodea al problema. Por eso un detalle irrelevante puede desviar la respuesta.
Cuándo se acercan a lo estricto: en tareas muy entrenadas y simples, la red a veces acaba implementando algo casi algorítmico. Por ejemplo, redes pequeñas entrenadas en aritmética modular aprenden un procedimiento limpio y exacto (curiosamente, basado en senos y cosenos). Y cuando el modelo razona por escrito paso a paso, puede seguir una regla lógica de forma bastante rigurosa, porque cada paso queda fijado en el texto y se puede revisar.
Como analogía de ingeniería: se parece más a un controlador fuzzy o a un conjunto de modelos combinados que a un motor de reglas. Eso explica tanto su flexibilidad como su fragilidad: no fallan como un programa con un bug, sino como alguien cuya intuición le engaña en un caso raro.
Y cuando la información es escasa?
Ahí está su punto débil más importante: tienden a rellenar huecos con lo típico, y lo hacen con la misma seguridad que cuando saben.
Escasez en el entrenamiento (datos poco frecuentes, temas de nicho): - Lo que aparece pocas veces se aprende mal. Hay estudios que muestran que el acierto en una pregunta factual sube claramente con el número de documentos sobre ese tema que había en el entrenamiento. - El modelo no “sabe que no sabe” de forma fiable. Anthropic encontró en Claude un mecanismo curioso: por defecto hay un circuito de “no lo sé”, que se apaga cuando el modelo reconoce algo como familiar. Si un nombre le suena pero no tiene datos sobre él, el circuito se apaga igual y el modelo inventa. Eso es una alucinación. - Además, el entrenamiento suele premiar dar una respuesta frente a abstenerse, igual que en un examen tipo test sin penalización, donde conviene adivinar.
Escasez en tu pregunta (poco contexto, ambigüedad): - Asume la interpretación más probable y sigue adelante, en lugar de preguntar. Si tu caso no es el típico, la respuesta puede ser correcta para otra pregunta.
Lo que sí hace bien: razonar desde principios generales cuando faltan datos concretos. Por ejemplo, estimar órdenes de magnitud o deducir cómo funcionará algo por analogía con casos parecidos. El problema es que esa estimación suena igual de segura que un dato verificado.
En la práctica: - Dale todo el contexto que tengas. - Pídele que separe lo que sabe de lo que supone, o que indique su nivel de confianza. - Para datos concretos de nicho (cifras, nombres, fechas, referencias), que busque fuentes en vez de responder de memoria. Lo hace bastante mejor así.
Como funciona chain of thought?
Funciona como hacer una división larga en papel en vez de de cabeza.
El mecanismo: cada token que genera el modelo pasa por un número fijo de capas, así que la cantidad de cálculo “en silencio” por token es limitada. Pero cada token nuevo puede leer todos los anteriores. Si el modelo escribe un resultado intermedio, ese resultado queda disponible para el siguiente paso, que hace otra pasada completa de cálculo sobre él. Escribir es, literalmente, ampliar la profundidad de cómputo y tener memoria de trabajo. Hay resultados teóricos que lo formalizan: un Transformer con pasos intermedios puede resolver clases de problemas que sin ellos no puede, como los que exigen muchos pasos en serie.
Cómo se llegó aquí: - 2022: se descubrió que bastaba con pedirlo. Dar ejemplos resueltos paso a paso, o simplemente añadir “pensemos paso a paso”, mejoraba mucho los resultados en matemáticas y lógica. - 2024 en adelante: los modelos de razonamiento se entrenan con aprendizaje por refuerzo. Se les deja generar cadenas largas y se premian las que acaban en una respuesta correcta y verificable. Sin que nadie lo programe, aprenden a comprobar resultados, detectar errores, retroceder y probar otro enfoque. Por eso sus cadenas son largas y algo caóticas, con frases como “espera, esto no cuadra”.
Una advertencia importante: lo que el modelo escribe no siempre refleja lo que realmente calculó. Hay experimentos en los que se le da una pista sesgada, el modelo la usa para responder y luego escribe una justificación que no la menciona. La cadena de pensamiento ayuda a calcular, pero no es una ventana perfecta a su “mente”. Se parece más a una explicación que también sirve de borrador.
Los conceptos y las reglas hasta que punto están completamente como las reglas formales
Solo parcialmente. La diferencia de fondo es esta: una regla formal vale igual para todos los casos, y la de un LLM vale bien cerca de los casos que ha visto y se va degradando al alejarse.
Los conceptos se parecen más a prototipos que a definiciones. Una definición formal tiene fronteras nítidas: un número es primo o no lo es. Los conceptos del modelo tienen un centro claro y bordes borrosos, como las categorías humanas (un gorrión es “muy pájaro”, un pingüino “algo menos”). Aun así, tienen bastante estructura: muchas relaciones son casi geométricas, como “rey − hombre + mujer ≈ reina”, y eso permite combinarlos de forma bastante sistemática.
Las reglas tienen cobertura limitada. Tres rasgos de las reglas formales que no se cumplen del todo: - Universalidad. Un modelo que suma bien números de hasta 10 cifras puede fallar con 20, aunque el algoritmo sea el mismo. No aprendió “la suma”, sino algo que funciona en el rango que vio. - Consistencia. Un sistema formal no puede afirmar A y no-A. Un LLM puede sostener cosas contradictorias en contextos distintos, porque nada le obliga a ser coherente globalmente. - Cierre lógico. Si sabe “A implica B”, no se sigue automáticamente que lo use para deducir sus consecuencias. La reversal curse es un ejemplo: saber “A es B” no le da “B es A”.
La solución práctica es híbrida. Cuando hace falta rigor formal de verdad, lo más fiable es que el modelo no lo haga “de cabeza”, sino que escriba código, use una calculadora o un verificador formal (como Lean para demostraciones matemáticas). El modelo pone la intuición y la traducción del problema, y la herramienta pone la garantía lógica. Es la dirección en la que van muchos sistemas actuales.
Hasta que punto un concepto u objeto está definido?
Está definido de forma sorprendentemente concreta en algunos aspectos y difusa en otros.
Lo que sí está bien definido. Muchos conceptos corresponden a una dirección identificable dentro del modelo, y se puede localizar. El ejemplo más famoso es de 2024: Anthropic encontró en Claude una “característica” del puente Golden Gate. Se activaba igual con texto en distintos idiomas y con imágenes del puente. Al amplificarla artificialmente, el modelo empezó a meter el puente en todas sus respuestas, e incluso a decir que era el puente. Así que el concepto existe como objeto interno, con un efecto causal medible.
Lo que es difuso: - No tiene una granularidad única. Al extraer conceptos con más resolución, uno se divide en varios más finos. Por ejemplo, “Golden Gate” se separa en “el puente como estructura”, “el puente como símbolo turístico”, etc. No hay una lista canónica de conceptos, sino distintos niveles de zoom. - Comparte espacio con otros. El modelo representa muchos más conceptos que dimensiones tiene, así que se solapan parcialmente (lo llaman superposición). Un concepto puede “contaminar” un poco a otros. - Cambia con el contexto. “Banco” de sentarse y “banco” de dinero empiezan igual y se van separando capa a capa según la frase. - El conocimiento sobre el objeto está repartido. Una cosa es reconocer “esto es la Torre Eiffel” y otra recuperar “está en París, la construyó Eiffel, mide unos 300 m”. Esos datos se almacenan sobre todo en las capas intermedias y se recuperan cuando hacen falta.
En resumen: un concepto no se define por una lista de propiedades, sino por su posición respecto a todos los demás conceptos y por lo que provoca en el modelo. Se parece más a cómo un ingeniero “sabe” qué es un buen diseño que a la definición de un diccionario. Es real y se puede medir, pero sus bordes son graduales.
Crea un artifact con mínimas referencias
Preparo un documento que resume la conversación, con solo las referencias clave, y lo guardo también en tu carpeta de Drive. Esquema listo; ahora redacto la primera sección. “Cómo razonan los LLMs” ya está listo: puedes editarlo directamente o comentarlo. También tienes una copia en tu carpeta de Drive Claude Artifacts. Las seis referencias del final las he puesto de memoria y no las he comprobado en esta sesión.