miércoles, 28 de octubre de 2026

Tres grafos para un agente

Aunque quizá de forma poco visible para el gran público, quizá sin ocupar titulares ni muchos comentarios (al menos que yo haya percibido), parece que el uso de grafos de conocimiento ('knowledge graphs') ocupa un papel cada vez mayor en la arquitectura de los agentes de inteligencia artificial.

Y, parece que, a falta de uno, los agentes tienden a utilizar hasta tres grafos diferentes con misiones diferentes.

Veamos.


La necesidad de una representación del conocimiento


En el post 'El retorno de la representación del conocimiento' comentaba cómo en la inteligencia artificial clásica, la simbólica, una parte importantísima era la llamada representación del conocimiento, es decir, la captura del conocimiento (generalmente residente en humanos) y volcado a alguna estructura o repositorio formal, siguiendo estructuras normalmente de tipo lógico.

También recordé cómo, con la aparición de una inteligencia artificial basada en datos (el famoso 'machine learning') rematada con el enfoque conexionista ('deep learning'), la representación del conocimiento desapareció o, si se quiere, el conocimiento se diluyó en los parámetros del modelo, perdiendo capacidad expresiva (que no operativa) y explicativa.

Sin embargo, con la llegada de los agentes, surge la necesidad, o al menos el interés, de recuperar alguna forma de representación del conocimiento.

Los agentes disponen de memoria que, de alguna manera simple, podría considerarse una forma poco estructurada de recoger cierto conocimiento. Y, sobre todo, se disponen de bases de conocimiento externas implementadas como almacenes vectoriales y gestionadas según el paradigma RAG ('Retrieval Augmented Generation').

Sin embargo, todavía RAG, que parece la forma más sofisticada que teníamos de recoger conocimiento en sistemas basados en grandes modelos de lenguaje (LLM, 'Large Language Models'), se nos queda corta. En cierto sentido es una representación de conocimiento (que en el fondo suele ser texto representado por un vector 'embedding') muy amplia pero poco estructurada, poco formalizada.

Y los agentes necesitan conocer mejor, estructurar mejor el conocimiento, para poder usarlo de manera efectiva.


Los grafos al rescate


Y es en este punto donde surgen los grafos, un formalismo sencillo pero enormemente potente y ya muy estudiado, para recoger el conocimiento en forma de entidades y relaciones entre ellas, representados como nodos y arcos.

De las carencias de RAG, y de la necesidad y papel de los grafos, ya escribí en este mismo blog en un artículo reciente 'La hora de los grafos: agentes y conocimiento'.


Los tres grafos


Aunque no estoy seguro de que la arquitectura que propone se use de forma generalizada, en el libro 'Agentic GraphRAG: Integrating Knowledge Graphs, Reasoning, and Agency for Enterprise AI' de Anthony Alcaraz y Sam Julien se habla del uso, no sólo de un grafo sino de tres. En concreto, los autores proponen los siguientes:


  • Grafo de conocimiento: Es el que, al menos para mi, es más fácil de imaginar y entender, y que más se corresponde con una representación del conocimiento como tal. En él se recoge la estructura de entidades y relaciones del dominio sobre el que trabaja el agente y que normalmente representará objetos o conceptos del mundo real y las relaciones entre ellos. Este permite al agente razonar sobre relaciones entre entidades, trazar causalidades, etc

  • Grafo de workflow: En este grafo se representan, no entidades y relaciones del mundo real (o del dominio de trabajo del agente) sino la propia lógica de tareas o plan que el agente va a realizar para conseguir un objetivo. Por ejemplo, se representan mediante grafos acíclicos dirigidos (DAG, 'Directed Acyclic Graphs') donde los nodos representan tareas y los arcos relaciones entre ellas. Permite, por ejemplo, detectar tareas independientes que se pueden realizar en paralelo o crear estructuras recursivas.

  • Grafo de log: Aunque los autores hablan en todo el libro de una arquitectura dual en grafos ('dual-graph architecture'), refiriéndose a los dos anteriores, al grafo de conocimiento y al grafo de workflow, al final de la obra hablan de este tercer grafo de log, quizá para mí un poco difícil de visualizar. Entiendo que es un grafo donde se registran los eventos que han ido sucediendo durante la ejecución del plan que lleva a cabo el agente (o durante todo el funcionamiento del agente), con algún tipo de relaciones entre esos eventos y que, posteriormente, puede ser usado para investigar incidentes, estudiar comportamientos, etc. Es decir, si lo he entendido bien, no es tanto un grafo pensado para la ejecución normal del agente sino para operación, gestión e  investigación.


Esta es la propuesta, tres grafos, sobre todo los dos primeros, como una forma de representación del conocimiento (y su almacenamiento y recuperación, claro) para apoyar el funcionamiento de los agentes y, sobre todo, los planes que establecen y las decisiones que adoptan durante su ejecución.


Conclusiones


Los agentes de IA modernos, se benefician de volver a utilizar grafos como una forma eficaz de representación del conocimiento. Existen dos grafos muy importantes, el que proporciona conocimiento del dominio (grafo de conocimiento) y el que recoge la estructura del trabajo y tareas (grafo de workflow). A estos dos grafos fundamentales, pudiera unirse un tercero (grafo de log) a efectos de operación, monitorización y eventual investigación y diagnóstico.


lunes, 26 de octubre de 2026

Perfiles de desarrollo software con inteligencia artificial

La inteligencia artificial está impactando en la forma de realizar muchas, muchísimas tareas y, en ocasiones, perfiles de trabajo completos, e incluso sectores.

Uno de los ámbitos que, en este momento, está en fuerte transformación, y hasta cierto punto peligro, el la ingeniería de software.  


Pinceladas sobre la transformación de la ingeniería de software


La ingeniería de software, específicamente el desarrollo de software, ha sido siempre una tarea intensiva en mano de obra (en trabajo humano) y también una actividad intelectual, al menos en lo relativo al diseño y también en muchos casos a la propia codificación, prueba y operación.

Sin embargo, la inteligencia artificial generativa ha venido a revolucionar todo esto.

Por un lado, hace la construcción de software muchísimo más sencilla, ya que en gran medida se reduce a pedirle al modelo adecuado o agente lo que se necesita (sin necesidad de conocer ni lenguajes de programación, frameworks ni arquitecturas técnicas) y además, a pedirlo en lenguaje natural. Por otro lado, y como consecuencia de lo anterior, baja enormemente la barrera de entrada para la incorporación de profesionales capaces de desarrollar.

Ya el auge del 'Low-Code' había supuesto un primer paso para poner al alcance de profesionales no desarrolladores la construcción de herramientas informáticas para su día a día, dando lugar al concepto del 'citizen developer'. 

Pero la inteligencia artificial supone un paso más allá y un cambio radical porque ya no es ni siquiera necesario conocer asuntos como variables o estructuras de control, ya no es necesario saber usar una herramienta concreta. Ahora la herramienta es el lenguaje natural y el foco se pone, más que en saber cómo se debe hacer el software en qué queremos que haga ese software, que ya la IA se encarga de decidir el cómo. Es como quedarnos en lo que en los modelos tradicionales de ingeniería software se denominaba la especificación de requisitos, delegando en la inteligencia artificial el diseño y la construcción.

No quisiera, de todas formas, exagerar la simplicidad. Ese mundo tan ideal probablemente aplica a soluciones software relativamente sencillas y, sobre todo, 'muy trilladas', de esas que existen miles y miles de ejemplos construidos y que se hace siempre más o menos igual: una 'landing' page', la gestión simple de registros en una base de datos, un cuadro de mando, etc.  En otras aplicaciones más novedosas, complejas, críticas o especializadas, es posible que todavía se requiera importante concurso humano.

Ya hace unos meses comenté en un post titulado 'Lo que no reluce en el 'Vibe coding': retos, limitaciones y equilibrios' algunas de las problemáticas que pueden aparecer si delegamos en exceso en la inteligencia artificial.

En cualquier caso, el ámbito de aplicación seguro de la inteligencia artificial en materia de construcción de software es muy amplio y el impacto profundo.


Perfiles para ingeniería software


El cambio está servido, es profundo y afecta notablemente, casi de forma radical, a cómo se lleva a acabo la actividad de diseño, construcción y prueba de software.

Y eso, claro, tiene impacto en los perfiles profesionales.

Acabando la lectura del excelente libro 'An Illustrated Guide to AI Agents' de Maarten Grootendorst y Jay Alammar, me he encontrado una tipología de perfiles que, aunque simple, me ha parecido interesante, precisamente por su simplicidad y la claridad de su estructura.

En el último capítulo del libro, abordan los autores la temática de los agentes de código, aquellos agentes especializados precisamente, en construir software. Aunque hablo de 'especializados', y aunque los autores no dan una pista concreta, creo que hoy en día, incluso chatbots generativos como ChatGPT (especialmente en el caso de Codex) o Claude (especialmente Claude Code) se pueden considerar agentes de código 'especializados'. 

Y, al hilo de este tema, los autores identifican cinco perfiles o, si se prefiere, cinco tipologías de uso. Tres de esos perfiles caen bajo e paraguas del término 'usuario' y dos bajo el paraguas de 'constructores'.


Los tres perfiles usuarios


Cuando los autores hablan de 'usuarios' se refieren a perfiles profesionales que utilizan un agente de código ya construido para, con él, a su vez, crear nuevo software. Los tres tipos que porponen son los siguientes:

  • Usuarios orientados sólo a los resultados ('result-only users'): Desarrollan elementos relativamente modestos como un análisis, un cuadro de mando o una 'landing page', y no tienen el más mínimo interés en el software en sí mismo sino sólo en lo que crean, en el resultado. Aunque los autores no lo mencionan con esta claridad, me los imagino sobre todo como usuarios que crean pequeños elementos muchas veces integrados dentro de su chatbot generativo (por ejemplo, creando artefactos en Claude).

  • 'Vibe coders': Sí tienen interés en el software pero lo construyen utilizando únicamente la definición en lenguaje natural y dejando los detalles de implementación a la inteligencia artificial, al agente de código. De nuevo, me los imagino usando Claude o ChatGPT pero también otras herramientas como Lovable, Windsurf o Cursor.

  • Ingenieros de software ('software engineers'): Exhiben un perfil similar a un desarrollador tradicional, conocen los lenguajes de programación y los elementos técnicos y, aunque se apoyan en la inteligencia artificial, son capaces de directamente instrucciones más técnicas o revisar el código generado. Me los imagino usando inteligencia artificial pero integrada dentro de otros entornos de desarrollo como Visual Studio Code, Anaconda o Jupyter Notebooks.


Los dos perfiles constructor


Cuando los autores nos hablan, sin embargo, de constructores, están pensando en perfiles desarrollador que crean los propios agentes de código, que luego terceros (los usuarios) utilizan para crear software. En este apartado, distinguen dos perfiles:
 
  • Constructores de agentes: Parten de modelos de inteligencia artificial especializados en código ya construidos y, alrededor de esos modelos, crean el resto del agente incluyendo la gestión del contexto, gestión de herramientas, interacción con el usuario, etc.

  • Constructores de modelos: Los que construyen y entrenan a los modelos propiamente dichos.


Conclusiones


No cabe ninguna duda de que la inteligencia artificial, está transformando radicalmente toda la disciplina de la ingeniería de software y los perfiles profesionales que trabajan en ella de una forma u otra.

En el post hemos visto una tipología sencilla y clara de cinco perfiles en relación con el uso o construcción de agentes de código.


jueves, 15 de octubre de 2026

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. 


miércoles, 7 de octubre de 2026

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.


lunes, 5 de octubre de 2026

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



viernes, 2 de octubre de 2026

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.


jueves, 1 de octubre de 2026

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