La hora de los grafos: agentes y conocimiento

Los grafos son un recurso matemático e informático descritos y utilizados desde hace muchísimos años, tanto como forma de recoger información y ontologías, como para el guiado de ciertos algoritmos.

Los grafos han estado ahí y se han seguido explicando y utilizando durante años y años y así hasta hasta la actualidad.

Pero en estos momentos están ganando una enorme relevancia en lo que viene a ser la punta de lanza tecnológica actual: los agentes de inteligencia artificial. 

Grafos: recordatorio muy básico

Aunque asumo que la mayoría de los lectores de este blog conocen, al menos aproximadamente, lo que es un grafo, lo recuerdo brevemente: un grafo es un formalismo para representar entidades o conceptos y las relaciones entre ellos.

Dibujo de un grafo no dirigido.
Fuente: Wikimedia

Desde un punto de vista visual, los grafos constan de unos nodos que representan las entidades o conceptos y que se suelen representar como círculos, y de unos arcos o aristas ('edges') que representan las relaciones entre los nodos y que se suelen representar como líneas.

Existen grafos dirigidos en que existe alguna forma de orden en las relaciones entre los nodos, y grafos no dirigidos en que no existe ningún tipo de orden en las relaciones. A la hora de representarlos gráficamente, los arcos terminan en una punta de flecha indicando la dirección.

 

Las memorias externas en agentes y chatbots generativos

Las aplicaciones basadas en grandes modelos de lenguaje, y particularmente los agentes de IA, deben utilizar mecanismos para volcar y/o recuperar información: las memorias. Esa información puede ser generada por el propio agente durante su trabajo (y en ese sentido, el nombre de memoria alcanza su plena significación) o, en otros casos, es información externa, una base de conocimiento o fuente de conocimiento.

Este tipo de aplicaciones utilizan varios mecanismos técnicos para implementar esas memorias (algo de lo que quizá valga la pena que comente en este blog) pero, cuando hablamos de bases de conocimiento, la técnica reina es RAG ('Retrieval Augmented Generation').

Bases de datos vectoriales y RAG

RAG utiliza dos elementos técnicos relevantes.

Por un lado, tenemos una capacidad fundamental de los sistemas generativos, que consiste en generar para tokens, documentos, etcétera lo que se denominan 'embeddings', unos vectores de alta dimensión que, de manera indirecta, contienen información semántica. Digo indirecta porque no es que marquen realmente un significado estricto y 'anclado ('grounded'), pero sí la cercanía o lejanía semántica entre aquellos conceptos que representan.

Por otro, tenemos las bases de datos vectoriales un tipo de base de datos NoSQL especializada en trabajar, precisamente, con vectores, y que es donde se almacenan y recuperan los 'embeddings'.

Cuando queremos añadir, por ejemplo, un documento PDF a una base de conocimiento, éste se trocea (en los denominados 'chunks') y para cada 'chunk' se genera su 'embedding'. Estos 'embedings' se almacenan en una base de datos vectorial.

Cuando queremos recuperar conocimiento ligado a alguna temática (con frecuencia expresada como 'prompt'), creamos un 'embedding' que represente ese 'prompt' y buscamos en la base de datos vectoriales, los vectores que sean 'cercanos semánticamente'. Para cada uno de esos 'embeddings' recuperados se accede a su 'chunk' y ¡voila! ya tenemos conocimiento relacionado con lo que nos interesa

Las limitaciones de RAG

En el libro 'Agentic GraphRAG: Integrating Knowledge Graphs, Reasoning, and Agency for Enterprise AI' de Anthony Alcaraz y Sam Julien se nos explica que RAG funciona muy bien para recuperación de información ligada a una consulta pero que, sin embargo, no funciona tan bien cuando de lo que se trata es de trabajar con razonamientos complejos y datos densos o especializados.

Y, precisamente, ese razonamiento complejo es lo que esperamos que hagan muchos agentes.

Los autores, concretando más, nos señalan las siguientes limitaciones de RAG:

• Gaps semánticos: En ocasiones la representación semántica mediante 'embeddings' de un texto (un 'chunk') no siempre está suficientemente cercana al 'embedding' de la consulta pese a que, objetivamente, el verdadero conocimiento necesario sí está en el texto original


• Compromisos de granularidad: Es necesario adoptar compromisos entre la cantidad de información o el nivel de información que representamos en un 'embedding', típicamente, si actuar en el nivel documento completo o en el nivel 'chunk' e, incluso, el tamaño de esos 'chunks'. Según la decisión de granularidad adoptada, el comportamiento puede resultar mejor o no en ciertos casos.


• Limitaciones en razonamiento: El razonamiento suele requerir coordinar varios conocimientos o contenidos que pueden estar contenidos en 'chunks' diferentes y representados por 'embedding' diferentes. Eso complica el acceso al conocimiento necesario y no siempre funciona correctamente.


• Amnesia contextual: En general la representación mediante vectores es estática y sin ningún tipo de referencia temporal. Los 'embeddings' están congelados y si se produce una evolución, pero los vectores originales siguen en la base de datos, el agente puede encontrarse con información obsoleta.


• Gap de asociatividad: Los sistemas RAG no son capaces de expresar relaciones transitivas o construir cadenas lógicas cuando enlaza conocimientos contenidos en 'chunks' diferentes.

Los grafos como alternativa

Ante este panorama, están ganando fuerza los grafos, y en concreto los denominados grafos de conocimiento ('Knowledge Graphs'), como alternativa o complemento de los sistemas RAG.

Los grafos son capaces de aportar esa interrelación entre conceptos, esas relaciones transitivas, esa perspectiva evolutiva o temporal, etc que los agentes necesitan y que no encuentran bien resueltas en RAG. 

Por ello, al auge de los agentes, le está acompañando el auge de los grafos de conocimiento. No voy a profundizar más ahora pero, en próximos posts, hablaré algo más de estos grafos de conocimiento y su uso en agentes y aplicaciones basadas en modelos frontera.

Los grafos como representación del conocimiento

No me resisto, no obstante, antes de finalizar el artículo, a hacer referencia a mi artículo anterior 'El retorno de la representación de conocimiento' en que hablaba de cómo una disciplina muy presente en la inteligencia artificial clásica, es decir en la inteligencia artificial simbólica, como era la representación del conocimiento, se había perdido con la expansión de la inteligencia artificial basada en datos ('machine learning') y especialmente el enfoque conexionista ('deep learning') estaba experimentando un cierto resurgir.

Pues bien, quizá el exponente más relevante, aunque aún emergente, de ese retorno de la representación del conocimiento, sean estos grafos, como de alguna forma ya transmiten en su propio nombre: grafos de conocimiento. 

Conclusiones

La explosión de la inteligencia artificial agéntica, está implicando el recuperar planteamientos anteriores para dotarles de conocimiento y contexto. Eso supone el retorno de la representación del conocimiento y, en particular, al auge de los gafos de conocimiento. 

El retorno de la representación del conocimiento

Cuando la inteligencia artificial era aún una disciplina bastante joven, existía una especie de subdisciplina que era capital en aquellos tiempos y que se presentaba como anexo necesario en cualquier discurso o estudio sobre la inteligencia artificial: la representación del conocimiento ('knowledge representation').

Sin embargo, con el auge del enfoque basado en datos, el 'machine learning', que ahora domina, especialmente bajo la variante 'deep learning', en la inteligencia artificial moderna esta subdisciplina de la representación del conocimiento, desapareció casi completamente de la práctica de la inteligencia artificial y absolutamente del discurso público.

Y, sin embargo, de forma quizá inesperada y sin meter ningún ruido, me da la sensación de que la representación de conocimiento vuelve a ser importante y seguramente lo va a ser más. No se la denomina así (al menos yo no he escuchado ni leído recientemente el término 'representación del conocimiento') pero está cada vez más presente y el auge de los agentes parece impulsarla.

Representación del conocimiento

Repasando una referencia muy antigua de un libro que en seguida citaré, podemos entender la representación del conocimiento como:

una serie de formalismos capaces de recoger de forma estructurada información acerca del mundo.

Esa información la queremos no como un mero almacén, sino como una base en que se apoya la inferencia en los algoritmos de la inteligencia artificial.

Mis primeros encuentros con la representación del conocimiento

Decía que en los primeros tiempos de la inteligencia artificial el tema de la representación del conocimiento era fundamental. Y lo ilustro con dos detalles anecdóticos.

La primera formación que recibí sobre inteligencia artificial tuvo lugar, nada más y nada menos, que en 1987, al apuntarme a un curso voluntario sobre el lenguaje LISP (entonces muy en boga en el campo de la inteligencia artificial) que ofreció la entonces ETS Ingenieros Industriales de Gijón, hoy rebautizada como Escuela Politénica de Ingeniería de Gijón donde yo cursaba mis estudios de ingeniería industrial. Y ¿Cómo se titulaba el curso? Pues su título era 'Introducción al LISP y a la representación del conocimiento'. Realmente, el curso fue sobre LISP sin más...pero es muy sintomático que en el título apareciese el término 'representación del conocimiento'.

Unos pocos años más tarde, ya en Madrid, y haciendo cursos de doctorado en la Escuela de Ingenieros Industriales de Madrid dentro del marco de un programa titulado 'Control de procesos e inteligencia artificial', adquirí algunos de los libros que constaban en la bibliografía recomendada. 

El más importante era la segunda edición de 'Inteligencia Artificial' de Elaine Rich y Kevin Knight, un libro de cerca de setecientas páginas que me devoré y que, de las tres partes que constaba, una (de algo más de doscientas páginas páginas) estaba dedicada a la representación del conocimiento. 

La otra referencia está completamente dedicada a la representación del conocimiento: el libro 'Knowledge representation' de Han Reichgelt y es la fuente de donde he extraído una especie de definición del campo de la representación del conocimiento.

La representación del conocimiento tradicional

Es importante entender que en la 'era dorada' de la representación del conocimiento, estábamos inmersos en la denominada inteligencia artificial simbólica, muy orientada a hacia la aplicación de la lógica trabajando sobre representaciones de aspectos del mundo (los símbolos). 

De esta época, quizá  la más alta realización de la inteligencia artificial fuesen los sistemas expertos, unas soluciones que recogían en una denominada base de conocimiento, los datos objetivos y las heurísticas fruto de la experiencia de expertos humanos en el tratamiento de un cierto problema. A partir de esa base de conocimiento, y ante una situación nueva, el motor de inferencia aplicaba reglas que solían encadenar heurísticas y que, eventualmente, resolvían el problema. Evidentemente, para conformar esas bases de conocimiento había que decidir cómo representar el conocimiento, de manera que fuese fiel a la realidad y que, además, se pudiese utilizar de manera eficaz en el proceso de inferencia.

En aquella época, las técnicas fundamentales de representación del conocimiento eran cosas como la lógica de predicados ('predicate logic'), reglas de producción ('production rules'), las redes semánticas ('semantic nets') o los marcos ('frames').

El machine learning y el conocimiento implícito

Y entonces llegó el auge del 'machine learning'.

Ante la dificultad (por desconocimiento o por escala del problema) para conseguir de los humanos un buen conocimiento, no solo fáctico o descriptivo, sino también operativo (es decir, realización de inferencias o resolución de problemas) el campo de la inteligencia artificial viró hacia los enfoques basados en datos.

En estos enfoques (el 'machine learning') renunciamos a proporcionarle a los algoritmos el conocimiento explícito y, a cambio, le enseñamos cómo debe aprender a adquirir ese conocimiento (algoritmos de aprendizaje) y le proporcionamos montañas de datos para que, a partir de ellos, detecte los patrones subyacentes, aprenda y adquiera el conocimiento.

Al renunciar a proporcionarle al algoritmo el conocimiento explícito, estamos eliminando la representación del conocimiento. Y el algoritmo, una vez entrenado, tampoco nos proporciona ese conocimiento explícito en forma de representación del conocimiento.

El conocimiento, que de alguna manera sigue estando presente, lo está de manera implícita, diluida entre los miles o millones de parámetros del modelo, pero no lo representamos explícitamente y, desde luego, no usamos símbolos. Es la desaparición de la representación del conocimiento (que, por cierto, está en la raíz de muchas de las problemáticas de explicabilidad de los algoritmos).

Quizá, en nichos concretos todavía se mantuvieran algunos aspectos de la representación del conocimiento. Así, por ejemplo, las ontologías del lenguaje humano, usadas en el procesamiento del lenguaje natural (NLP, 'Natural Language Processing') en tareas como la desambiguación del sentido de palabras (WSD, 'Word Sense Disambiguation') puede considerarse una forma de representación del conocimiento.

El conocimiento en los grandes modelos de lenguaje

Y llegamos a los grandes modelos de lenguaje que dominan el panorama de la inteligencia artificial actual.

Los grandes modelos de lenguaje (LLM, 'Large Language Model') están conformados todos ellos por redes neuronales y, por tanto, se realizan con base en 'deep learning', es decir, una forma particular de 'machine learning'. Y, por tanto, no utilizan una representación de conocimiento explícita. El conocimiento está, de nuevo, diluido entre sus millones de parámetros.

Suelo insistir en clases y charlas en que sí tienen conocimiento. Tienen conocimiento estructural (morfológico y semántico) del lenguaje humano, tienen conocimiento semántico y tienen conocimiento del mundo, todo ello, en gran medida, debido a la magia de los 'embeddings' y a un entrenamiento absolutamente masivo en datos. Pero, de nuevo, se trata de un conocimiento implícito, indirecto, no representado.

Y, sin embargo...

Las nuevas representaciones del conocimiento

Y, sin embargo, cada vez más las aplicaciones basadas en grandes modelos de lenguaje, comenzando por los copilotos y chatbots generativos y siguiendo por los agentes, incorporan mecanismos que creo que pueden entenderse como una nueva forma de representación del conocimiento.

Empezando por lo más sencillo, y quizá todavía algo discutible, sabemos que chatbots generativos como ChatGPT o Claude, no responde únicamente al 'prompt' del usuario sino que incorporan información de contexto. Un contexto que proviene, entre otras cosas, de las preguntas y respuestas anteriores de la conversación.  Pues bien, aunque bastante  poco estructurado, y representado de manera fundamentalmente textual, ese contexto incorpora una especie de conocimiento de corto plazo. Y a esto se une, por ejemplo, el mecanismo de memorias en que se resumen elementos de conocimiento que el chatbot ha adquirido sobre el usuario. De nuevo, es un conocimiento expresado de forma muy básica, mediante texto, pero conocimiento al fin y al cabo y representado de manera explícita.

Igualmente, ahora que se han puesto de moda las skills, podemos decir que las skills, una especie de prompts reutilizables que marcan cómo realizar una tarea, no dejan de ser una forma de conocimiento, de carácter fundamentalmente procedimental eso si, que aporta un usuario para indicar cómo realizar una labor concreta.

En el caso de usar RAG ('Retrieval Augmented Generatión'), creamos unos almacenes vectoriales en que, precisamente, introducimos conocimiento, normalmente a partir de documentos. De nuevo, la representación es sencilla: 'chunks' de texto (en que hemos subdidivido, por ejemplo, un documento PDF) acompañado de su vector 'embedding' que posibilita la búsqueda semántica.  De hecho, podemos hablar con bastante propiedad de que esos almacenes vectoriales actúan como bases de conocimiento, por lo que esos 'chunks' de texto con su embedding correspondiente no deja de ser otra forma no muy estructurada de representar el conocimiento.

Pero quizá, lo que más nos retorna a la disciplina de la representación del conocimiento, y lo que más me ha inspirado para escribir este post, es el auge de los grafos, especialmente en el campo de los agentes. No voy a profundizar aquí en ello porque próximamente publicaré varios posts sobre grafos pero, es una técnica en auge y que proporciona un conocimiento, bastante estructurado y, de hecho, se suele hablar de grafos de conocimiento ('knowledge graphs').

Aunque creo que mecanismos como el contexto, las memorias, las skills o los almacenes vectoriales de RAG pueden ser consideradas formas de representación de conocimiento, entendería que hubiese quien no los considerase como tales.

Pero, en el caso de los grafos, veo clarísimo que es una forma de representación de conocimiento 'de primera división', de carácter simbólico y en el mismo estilo que las técnicas que dominaron la representación del conocimiento cuando la inteligencia artificial era, precisamente, simbólica. 

Y si los agentes son un tema en fuerte auge, y los grafos son un tema también en auge que los acompaña, creo que, en efecto, asistimos al retorno de la representación del conocimiento.

Conclusiones

Acompañando a la antigua inteligencia artificial simbólica, existían, y eran muy importantes, las técnicas de la denominada representación del conocimiento. Con el auge del machine learning y el 'deep learning' esa representación del conocimiento prácticamente desapareció, quedando todo el conocimiento implícito en los parámetros del modelo, pero sin representación explícita.

Si embargo, las modernas aplicaciones basadas en grandes modelos de lenguaje, particularmente los chatbots generativos y, sobre todo, los agentes,  incorporan técnicas como el contexto, las memorias o los almacenes vectoriales que, aunque de manera algo desestructurada , se las puede  considerar formas de representación de conocimiento.

Y, sobre todo, la eclosión de los grafos de conocimiento alrededor de los agentes, suponen, creo, el espaldarazo definitivo a ese retorno de la representación el conocimiento.

Cómo hacemos que un modelo razone (y VI): destilado

Con este post pongo fin a la serie de artículos dedicados a ver los mecanismos que se utilizan para convertir un gran modelo de lenguaje (LLM, 'Large Language Model') en un modelo razonador (LRM, 'Large Reasoning Model').

Y todo ello siguiendo, como en el caso de los post anteriores, el hilo argumental del libro  'Building a resoning model (from scratch)' de Sebastian Raschka.

En esta ocasión, vamos a hablar del destilado ('distillation') y añadir alguna otra consideración adicional.

Un breve recordatorio 

Muy brevemente recordar que en posts anteriores hablamos de tres tipos de estrategias. 

La primera estrategia suponía utilizar técnicas fundamentalmente de prompting sin re-entrenar el modelo. Hablamos del uso de la cadena de pensamiento (CoT, 'Chain-Of-Thought') y la autoconsistencia ('self-consistency'). Y también hablamos del auto-refinamiento ('self-refinement') en que, de alguna forma, el modelo dialoga consigo mismo. En estos métodos, el modelo en sí mismo no cambia (su arquitectura y parámetros no se modifican) y, simplemente, lo guiamos desde, digamos, el exterior. Eso sí, para ello vamos a necesitar de un notablemente mayor esfuerzo computacional. Uniendo la idea de que estas técnicas se utilizan en tiempo de inferencia (no de entrenamiento) y de que exigen mayor esfuerzo computacional, hablábamos de métodos de escalado en tiempo de inferencia ('inference-time scaling').

La segunda estrategia sí que re-entrena el modelo (interviene durante el 'fine-tuning') y aplica aprendizaje por refuerzo. Vimos dos alternativas: el uso de recompensas verificables (RLVR, 'Reinforcement Learning with Verifiable Rewards') en que, de forma objetiva se puede deducir la recompensa a dar al modelo ante una respuesta) y el uso de realimentación por parte de anotadores humanos (RLHF, 'Reinforcement Learning with Human Feedback').

Destilado

Y nos toca ahora ver la tercera estrategia: el destilado ('distillation').

Como también ocurre con todas las técnicas vistas hasta ahora, no se trata de algo que se utilice específicamente para conseguir modelos razonadores, sino que es una estrategia de entrenamiento utilizada ya en otros ámbitos (por ejemplo, para conseguir modelos especializados más compactos).

En el destilado se utilizan dos modelos: un gran modelo ya entrenado que actúa como maestro y otro modelo (generalmente menor) que actúa como estudiante y que es el que realmente queremos entrenar. Es una técnica que, más allá de los modelos razonadores se utiliza, precisamente, para absorber la parte principal del conocimiento de un gran modelo en uno bastante más pequeño y de menor exigencia computacional (y, por tanto, menor coste en inferencia).

La idea es que ante una misma pregunta, al modelo estudiante se le muestra la respuesta dada por el modelo maestro y eso sirve como feedback para el entrenamiento.

En el caso de usar el destilado para conseguir un modelo razonador, con frecuencia se trabaja, no sólo con la respuesta final del modelo maestros sino también las trazas, es decir unos resultados intermedios que, de alguna manera, muestran cómo ha razonado el modelo maestro.

Tipos de destilado

Lo anterior lleva a dos estrategias básicas de destilado.

En el destilado duro ('hard distillation'), se entrena al estudiante sólo con el resultado (la respuesta) ofrecido por el modelo maestro.

En el destilado blando ('soft distillation') se entrena al modelo estudiante con resultados intermedios e internos del modelo maestro. En concreto, con las distribuciones de probabilidad asignadas a los tokens del catalogo ante una petición concreta.

Como suele ocurrir, también existen estrategias híbridas que mezclan ambas opciones.

Esto es casi todo

Y esto todo lo que quería contar sobre la conversión de grandes modelos de lenguaje en modelos razonadores. Bueno, casi todo. Quería antes de cerrar este post y esta serie hacer dos muy breves consideraciones.

Antes de acabar: una pieza de la que no hemos hablado

La primera tiene que ver con los datos de entrenamiento, para las dos últimas estrategias que suponen un 'fine tunning' del modelo y, por tanto, un entrenamiento. 

Parece lógico, aunque no se ha mencionado hasta ahora, que debemos disponer de datos de entrenamiento diseñados específicamente para forzar un razonamiento: problemas matemáticos, lógicos o complejos de alguna manera.

En la referencia bibliográfica que he empleado, menciona con frecuencia, por ejemplo, el banco de datos MATH-500 que, como insinúa su nombre, contiene 500 problemas de naturaleza matemática habitualmente usados en el entrenamiento de modelos razonadores y que podemos encontrar, por ejemplo, en Hugging Face.

Una pequeña reserva

La segunda consideración es sólo una impresión o intuición personal y sin ninguna justificación teórica, más que esa intuición.

Se trata de que me ha sorprendido que, como comentaba más arriba, realmente ninguna técnica usada es realmente específica ni de la inferencia ni del entrenamiento de modelos razonadores y pueden usarse (y se usan) con modelos no razonadores. Tampoco parece (al menos yo no he visto nada al respecto) que haya ningún cambio en la arquitectura interna de estos modelos.

Y, aunque eso seguramente sea bueno y una demostración de la potencia y versatilidad de los grandes modelos de lenguaje, en el fondo me quedo preguntándome ¿De verdad eso es todo? ¿No hay nada más?

Aparentemente la respuesta es que no, pero seguiré leyendo e investigando a ver qué encuentro. Si aparece algo nuevo, puede que reabra la serie de posts para comentarlo.

Conclusiones

Y con esto cerramos, salvo sorpresas, la serie dedicada a ver las técnicas para convertir un gran modelo de lenguaje en un modelo razonador. Hemos visto tres estrategias y cinco técnicas a lo largo de seis posts.

Aunque vale la pena seguir observando la evolución a nivel de arquitectura y entrenamiento de los modelos razonadores, al menos ya tenemos una base para saber mejor cómo se crean.

Artículos de este blog relacionados

• Cómo hacemos que un modelo razone (V): aprendizaje por refuerzo con feedback humano (RLHF)
• Cómo hacemos que un modelo razone (IV): aprendizaje por refuerzo basado en recompensas verificables (RLVR)
• Cómo hacemos que un modelo razone (III): auto-refinamiento
• Cómo hacemos que un modelo razone (II): técnicas de prompting
• Cómo hacemos que un modelo razone (I): tres grandes estrategias

Los agentes IA y la delegación cognitiva

Hace unos días publicaba en este blog un post basado en la lectura del paper  es 'Thinking—Fast, Slow, and Artificial: How AI is Reshaping Human Reasoning and the Rise of Cognitive Surrender' escrito por Steven D. Shaw y Gideon Nave de Wharton.

El post, que titulé 'La inteligencia artificial y la rendición cognitiva', se centraba en el fenómeno de la rendición cognitiva ('cognitive surrender'), pero también mencionaba otro fenómeno, u otro comportamiento: la delegación cognitiva ('cognitive offloading') que también podríamos traducir como descarga cognitiva.

En este nuevo post me voy a fijar en ese segundo fenómeno, la delegación cognitiva. Y lo haré para resaltar un hecho que me ha llamado la atención: el uso de la delegación cognitiva por parte de las aplicaciones basadas en modelos generativos en general, y de los famosos agentes IA en particular.

La delegación cognitiva

El concepto de delegación cognitiva proviene del campo de la psicología y hace referencia al uso de herramientas externas para reducir nuestro esfuerzo cognitivo. Con mucha frecuencia la usamos como ayuda para recordar, pero también se extiende a la ayuda en otras tareas cognitivas como calcular o decidir, por ejemplo. Aunque cada vez se habla más de este fenómeno ligado al uso de herramientas digitales y especialmente de la inteligencia artificial, en realidad es algo natural y que hacemos desde antes de la existencia de herramientas digitales.

Si hacemos una lista de la compra para ayudarnos a recordar lo que tenemos que adquirir en el supermercado, estamos haciendo delegación cognitiva para evitar tener que recordar nosotros lo que teníamos que comprar. Si utilizamos una calculadora para hacer unas cuentas en lugar de hacerlo mentalmente, estamos aplicando delegación cognitiva.

Ya en el ámbito digital, pero en casos muy cotidianos, si utilizamos la lista de contactos de nuestro móvil para marcar un número, estamos haciendo delegación cognitiva, evitando tener que recordar nosotros ese número. Y si utilizamos el GPS y Google Maps para que nos marque el camino, estamos haciendo descarga cognitiva, evitando tener que recordar nosotros ese camino u orientarnos mientras conducimos.

Agentes

Los agentes IA son una forma de aplicación basada en un gran modelo de lenguaje y, en concreto un gran modelo razonador. Ese modelo razonador les dota de 'inteligencia' y de 'conocimiento' y, salvando las distancias, jugaría un rol equivalente al cerebro de las personas.

Pero los agentes interactúan con su entorno para ser verdaderos agentes (para hacer). Y para ello se rodean de las llamadas herramientas 'tools' que, con mucha frecuencia vía conectores o servidores MCP les permite interactuar con todo tipo de aplicaciones y servicios externos.

Mecanismos de delegación

Y creo identificar un paralelismo entre cómo estamos construyendo aplicaciones basadas en grandes modelos de lenguaje (como son los agentes, pero como son también los chatbots generativos como ChatGPT o Claude AI) y este mecanismo de delegación cognitiva. 

Así, si pensamos en el 'recuerdo', este tipo de aplicaciones incluyen muchos elementos auxiliares para que su 'cerebro' no tenga que recordar. El propio y famoso contexto no deja de ser una forma de memoria externalizada, al menos externa al modelo de lenguaje (aunque realmente no al chatbot o al agente).

En la misma línea podríamos situar las denominadas memorias (cosas que el chatbot o agente aprende sobre el usuario) o los almacenes vectoriales que sirven de repositorio sobre el que actúa el mecanismo RAG ('Retrieval-Augmented Generation').

Los mecanismos que menciono arriba están 'embebidos' dentro de la aplicación, y quizá haya quien considere que realmente no tiene la característica de externalización propia de la delegación cognitiva.

Pero el uso de las 'tools' abre posibilidades adicionales de delegación, en realidad en unas posibilidades inmensas. Así, abre el paso, por ejemplo, a descargar el recuerdo de datos en bases de datos externas o a invocar a una calculadora externa para un cálculo matemático o, en el fondo, a casi cualquier aplicación que pueda realizar una tarea, en este caso de naturaleza cognitiva, descargando así de ese 'esfuerzo cognitivo' al modelo de lenguaje.

Biomímesis y patrones cognitivos

No sé si me he dejado llevar por la imaginación (la verdad es que creo que no), pero aprecio que, de una forma probablemente no intencionada sino guiada por necesidades funcionales y técnicas, en la arquitectura de aplicaciones basadas en IA, en particular los agentes, les estamos dotando de potentes mecanismos de delegación cognitiva.

Y dado que, aunque presuntamente de forma no intencionada, estamos imitando, uno de los mecanismos cognitivos del cerebro humano, la delegación cognitiva, podríamos, quizá, hablar de una forma de biomímesis en este caso de naturaleza cognitiva o de la existencia de unos patrones (casi unas buenas prácticas) de actividad cognitiva.

Y si estos patrones que estamos introduciendo en los agentes provienen de la naturaleza, o están expresados en la naturaleza, en este caso nuestra propia naturaleza cognitiva, seguramente eso sea señal de que estamos adoptando un buen diseño en las arquitectura de los agentes. 

Conclusiones

Las aplicaciones basadas en grandes modelos de lenguaje, particularmente el caso de los agentes, parecen imitar, probablemente de manera no intencionada, un mecanismo absolutamente natural en la cognición humana como es la delegación cognitiva. Eso pudiera ser, eventualmente, una buena señal, un indicador de un buen diseño.

Cómo hacemos que un modelo razone (V): aprendizaje por refuerzo con feedback humano (RLHF)

Abordamos con ésta, la quinta entrega de la serie de posts que estoy publicando acerca de los mecanismos para conseguir que un gran modelo de lenguaje (LLM, 'Large Language Model') se convierta en un modelo razonador (LRM, 'Large Reasoning Model') y todo ello apoyándome en la estructura y aportaciones del libro 'Building a resoning model (from scratch)' de Sebastian Raschka.

En el post anterior anuncié que éste sería el último... pero me equivoqué: éste será el penúltimo y aún habrá, por tanto, otro post en esta serie

Dónde nos habíamos quedado

En los posts anteriores habíamos visto, en primer lugar, algunos métodos que realmente no alteraban en modelo en sí, es decir no modifican ni su arquitectura ni sus parámetros (sus pesos). En el fondo, 'el modelo se queda como está' y lo que hacemos es hacerle razonar mediante técnicas de 'prompting', en concreto, la cadena de pensamiento (CoT, 'Chain-Of-Thought') y la autoconsistencia ('self-consistency'). 

Y también vimos el auto-refinamiento en que  de alguna forma el modelo establece un diálogo consigo mismo y se proporciona 'feedback' sobre las respuestas que ha aportado.

Estos tres métodos se encuadraban dentro de lo que el autor denomina escalado en tiempo de inferencia ('inference-time scaling') porque, por un lado, se aplican ya en producción (en inferencia) y no durante el entrenamiento y, por otro, suponen un mayor esfuerzo computacional.

El último de los mecanismos que habíamos revisado se aplicaba ya en tiempo de entrenamiento y sí que modifica el modelo en sí mismo (sus pesos). Se trataba de un método, aprendizaje por refuerzo con recompensas verificables (RLVR, 'Reinforcement Learning with Verifiable Rewards'), que aplicaba aprendizaje por refuerzo y en el que la recompensa que se ofrece al modelo (la indicación de lo bien o mal que lo ha hecho) se basa en alguna de forma de reglas claramente calculables o verificables (por ejemplo mediante la aplicación de una calculadora para un problema matemático simple).

Vamos ahora otra variante de aprendizaje por refuerzo. 

El aprendizaje por refuerzo con feedback humano (RLHF)

Esta variante es realmente muy popular y, de hecho, se mencionó frecuentemente ya desde el momento del lanzamiento de ChatGPT cuando la propia OpenAI explicaba cómo había entrenado su modelo GPT-3.

Aunque RLHF se nos propone como una técnica para conseguir un modelo razonador, en realidad se utiliza con frecuencia para entrenar modelos de lenguaje no razonadores. De hecho, GPT-3, por ejemplo, no era un modelo razonador.

El aprendizaje por refuerzo con feedback humano (RLHF, 'Reinforcement Learning with Human Feedback') se definió originalmente (o explicó, mejor dicho) en el paper 'Training language models to follow instructions with human feedback'.

La idea del aprendizaje con feedback humano es que sea una persona quien indique cómo de buena o mala es la respuesta del modelo y, aplicando algún algoritmo sobre esta valoración, se actualice la política que se aplica (en el fondo el propio modelo) de una manera que recuerda de alguna forma al etiquetado en aprendizaje supervisado.

Sin embargo, en este caso, con frecuencia el feedback humano se recoge de una manera 'muy astuta': como supongo que todos hemos tenido ocasión de experimentar con ChatGPT: de vez en cuando te da dos opciones y te pide que elijas una como la más adecuada. Bueno, pues eso es feedback humano y digo que es 'astuta' porque nos recluta a todos los usuarios para dar ese feedback.

En RLHF hay un doble entrenamiento: primero se entrena un modelo que proporciona las recompensas en función del feedback humano y, con ese modelo ya entrenado, se realiza el entrenamiento del modelo propiamente dicho. Es en el primer entrenamiento, el entrenamiento del modelo que genera las recompensas, donde realmente se utiliza el feedback humano. A partir de ahí ese modelo generador de recompensas se utiliza para entrenar al modelo objetivo ya sin intervención humana.

Un tipo de algoritmo que se utiliza mucho en RLHF es PPO ('Proximal Policy Optimization') que, a partir de las recompensas generadas por el modelo generador de recompensas, 'decide' cómo actualizar el modelo que está siendo entrenado.

PPO ('Proximal Policy Optimization')

Lo que busca PPO es una forma de actualizar políticas, digamos, 'poco a poco', evitando cambios bruscos que puedan perjudicar el aprendizaje. En este caso, cuando hablamos de políticas, estamos hablando en el fondo del propio modelo en entrenamiento.

PPO utiliza el famoso descenso de gradiente ('Gradient Descent') para calcular cómo ajustar los pesos en la nueva política (en el modelo). Pero, para evitar los cambios bruscos, lo que hace es comparar la probabilidad de una respuesta con la política nueva (el modelo eventualmente actualizado) frente a la probabilidad con la política antigua (el modelo sin actualizar) calculando un 'ratio' de la siguiente forma:

r = probabilidad con política nueva (modelo modificado) / probabilidad con política antigua (modelo sin modificar)

Si ese 'ratio' se aleja mucho de 1 (es decir, los resultados de ambas políticas son muy diferentes) aplica lo que se denomina 'clipping' (recorte) y no tiene en cuenta el cambio. Esta forma de actuar es lo que evita cambios bruscos y lo que aporta la primera palabra del nombre del algoritmo: 'proximal' (próximo) 

Se trata de un tipo de algoritmos muy estables y muy sencillos de implementar, de ahí su popularidad. Además, funciona muy bien con ese tipo de acciones básicas como elegir simplemente entre dos opciones.

Conclusiones

Hemos visto una segunda forma de aprendizaje por refuerzo que se puede utilizar para el entrenamiento de grandes modelos de lenguaje a la hora de convertirlos en modelos razonadores. Una forma en que, además, nos apoyamos en la opinión de personas, de humanos. Se trata del el RLHF, es decir, el aprendizaje por refuerzo con 'feedback' humano, una forma de entrenamiento que se utiliza también en modelos no razonadores.

Artículos de este blog relacionados

• Cómo hacemos que un modelo razone (IV): aprendizaje por refuerzo basado en recompensas verificables (RLVR)
• Cómo hacemos que un modelo razone (III): auto-refinamiento
• Cómo hacemos que un modelo razone (II): técnicas de prompting
• Cómo hacemos que un modelo razone (I): tres grandes estrategias