Buenas, esto es BIMPRAXIS, el podcast donde el
BIM se encuentra con la inteligencia artificial.
Exploramos la ciencia, la tecnología y el futuro
desde el enfoque de la arquitectura, ingeniería y
construcción.
¡Empezamos!
Vale, vamos a meternos de lleno.
Hoy tenemos sobre la mesa un conjunto de
fuentes bastante ecléctico sobre una herramienta llamada LangGraph.
¡Um!
Sí, hay un poco de todo.
Hay de todo.
Desde guías para principiantes, la documentación oficial, que
es bastante densa, hasta hilos de debate muy
intensos en Reddit.
Ahí es donde está la salsa, claro.
Totalmente.
Y la misión es entender por qué algunos
la describen como algo fundacional, una palabra bastante
fuerte para construir aplicaciones de inteligencia artificial que
sean a la vez complejas y fiables.
Efectivamente.
Y el reto, yo creo, está en separar
un poco la promesa de la realidad.
Las fuentes no solo nos dicen qué es,
sino que abren un debate muy interesante sobre
por qué es necesaria.
Claro.
O sea, ¿qué problema resuelve que su predecesor,
Landchain, no podía?
Y sobre todo, ¿qué opinan los desarrolladores que
se están quejando con ella en el día
a día?
Es que es fascinante ver cómo una pieza
de software puede generar opiniones tan polarizadas, ¿verdad?
Muchísimo.
Pues empecemos por el principio, entonces.
¿Por qué nace LangGraph?
Una de las fuentes de un blog llamado
Q2B Studio dice algo que parece muy simple,
pero que es la clave de todo.
A ver.
Dice que la mayoría de aplicaciones de IA
no son lineales, no van en línea recta
del punto A al B.
¿A qué se refieran con eso exactamente?
Pues esa es la madre del cordero.
Su predecesor, Landchain, es fantástico para flujos de
trabajo que son como una cadena de montaje.
¿Una secuencia?
Eso es.
Coges un dato, se lo pasas a un
modelo, el resultado se lo pasas a otra
herramienta, y así sucesivamente.
Es una secuencia lineal.
Y es perfecto para un prototipo rápido o
un chatbot que responde preguntas simples.
Pero el mundo real no funciona así.
Para nada.
Es mucho más caótico.
Aquí es donde la cosa se pone interesante.
Las aplicaciones de verdad necesitan poder dudar, tomar
decisiones, volver sobre sus pasos si algo sale
mal, autocorregirse.
Claro.
La analogía que usan en las fuentes es
la de un diagrama de flujo, no una
línea recta.
Esa es la idea.
Exacto.
Piensa en un agente de IA que tiene
que reservar un viaje.
Primero busca vuelos.
Si no hay, no puede simplemente detenerse, ¿no?
Claro, tiene que probar otras fechas o algo.
Tiene que probar con otras fechas, si encuentra
un vuelo, busca uno tal.
Si el hotel es carísimo, quizás tiene que
volver atrás y buscar un vuelo a una
ciudad cercana.
¿Eso es un grafo?
Un mapa de decisiones.
Justo.
Un mapa de decisiones con bucles, bifurcaciones y
saltos condicionales.
LangGraph te da las herramientas para construir ese
mapa, con sus nodos, que son las acciones,
y sus aristas, que son las rutas que
conectan esas acciones.
Entiendo.
O sea, no es una tubería, Es una
red de carreteras y he visto que en
otra fuente, un curso de Hugging Face, lo
enmarcan en un concepto que me ha parecido
muy potente.
El equilibrio entre el control y la libertad
del modelo de lenguaje.
¿Cómo encaja LangGraph en esa balanza?
Ese punto es crucial.
A ver, darle total libertad a un LLM
es como darle las llaves del coche a
un adolescente muy inteligente pero sin experiencia.
Buena analogía.
Puede que llegue al destino, o puede que
acabe en otra ciudad porque vio un cartel
que le parece interesante.
Landchain a veces puede pecar un poco de
eso.
De darle demasiada libertad.
Sí.
LangGraph, en cambio, se posiciona firmemente en el
lado del control.
Te obliga a diseñar ese mapa de carreteras
de antemano.
El agente puede elegir qué ruta tomar en
una bifurcación, pero no puede salirse de las
carreteras que tú has dibujado.
Entiendo.
Es lo que llaman una arquitectura cognitiva controlable.
Exacto.
Y eso es fundamental para que una empresa
se fíe de poner esa IA de cara
a sus clientes.
Necesitas esa predictibilidad.
Vale.
Eso deja la diferencia conceptual muy clara.
Pero, en la práctica, si alguien está empezando
un proyecto, ¿cómo decide?
La guía de Q2B Studio da algunas pistas,
pero ¿cuál sería la regla de oro para
elegir?
La regla de oro es preguntarse.
¿Mi agente necesita pensar en varios pasos y
potencialmente corregir su rumbo?
Si la respuesta es sí, probablemente necesites LangGraph.
Vale.
Para prototipos, chatbots básicos que solo clasifican o
resumen texto, langchain es más que suficiente y
mucho más rápido de implementar, ¿verdad?
Pero si ya necesitas que razone, que maneje
errores de forma inteligente… Allí es donde langchain
se queda corto.
Si necesita llamar a herramientas externas, dependiendo de
una condición, o recordar el contexto de una
tarea larga, allí es donde langgraph se vuelve
indispensable.
Y ojo, que aquí no se trata de
que uno sea bueno y el otro malo,
¿verdad?
Por lo que entiendo, no compiten entre sí.
Para nada.
Más bien, se pasan el relevo.
LangGraph es la evolución natural cuando la complejidad
de un proyecto crece.
Es el siguiente paso lógico.
O sea que usa componentes de Landchain.
Claro.
De hecho, usa muchos de los componentes de
Landchain.
Simplemente los organiza de una manera diferente, más
robusta.
He visto que en la documentación de IBM
mencionan algo llamado grafos con estado.
Suena bastante técnico.
¿Qué significa exactamente en este contexto y por
qué es tan importante para LangGraph?
Es probablemente la característica más importante y la
que resuelve más dolores de cabeza.
Con estado significa simplemente que el sistema tiene
memoria de todo lo que ha pasado en
cada paso del camino.
Imagina que cada vez que la gente completa
una acción, un nodo del grafo, anota en
un cuaderno digital lo que ha hecho, los
datos que ha obtenido y el resultado.
Ese cuaderno es el estado.
Y se va pasando de un paso a
otro.
Se va pasando de nodo a nodo, de
forma que la gente siempre sabe de dónde
viene y qué información tiene disponible en ese
momento.
Vamos, que es como tener un registro de
vuelo detallado en todo momento.
Y supongo que eso es una maravilla para
depurar errores, ¿no?
puedes ver exactamente en qué punto se torció
el plan.
Exacto, tienes una transparencia total.
Y esa gestión centralizada del estado es lo
que evita el caos.
Hay una cita en uno de los hilos
de Reddit que lo resume de una forma
muy directa y brillante.
A ver, ¿qué dice?
Un usuario dice, Langchain es una capa de
abstracción para los clientes de chat de IA.
Langgraph es para cuando quieres orquestar a estos
agentes para lograr un resultado.
Orquestar, me gusta esa palabra.
Y termina diciendo, básicamente, si necesitas que múltiples
agentes trabajen juntos, usa LangGraph.
Y creo que no se puede explicar mejor.
Esa idea de la orquestación es muy potente.
Y supongo que para que esa orquesta suene
bien, no solo necesitan saber qué hacer, sino
también recordar la partitura.
Totalmente.
Eso nos lleva directamente al tema de la
memoria, que parece ser el otro gran pilar
de todo esto.
La capacidad es que el Unchain permita gestionar
de una forma mucho más estructurada.
La documentación oficial del Unchain profundiza mucho en
esto, y es fascinante como lo plantean.
Sí, lo dividen en dos grandes tipos que
ayudan a entenderlo, la verdad.
Por un lado, la memoria a corto plazo,
la que se usa dentro de una única
conversación.
La de aquí y ahora.
Eso es, la capacidad de recordar lo que
acabamos de hablar.
Correcto.
Esa memoria a corto plazo es parte de
ese cuaderno digital, de ese estado del que
hablábamos.
Es volátil y específica de la tarea actual.
Vale, pero luego está el verdadero cambio de
juego.
La memoria a largo plazo, la que persiste
entre diferentes conversaciones.
Es la que permite que una gente te
reconozca y recuerde tus preferencias de una semana
para otra.
Y aquí es donde a mí me voló
la cabeza, porque usan una analogía con la
memoria humana para categorizarla.
Hablan de tres tipos.
El primero es la memoria semántica.
La de los hechos.
Justo, para recordar hechos.
El ejemplo que dan es, al usuario le
gusta el lenguaje directo y habla inglés y
Python.
Datos puros y duros sobre alguien o algo.
Sí, esa es la base.
Luego suben un nivel con la memoria episodica,
que es para recordar secuencias de acciones o
conversaciones pasadas.
Experiencias, por así decirlo.
Exacto.
En la práctica, dicen que se usa para
darle al modelo ejemplos de interacciones exitosas.
Es como decirle, mira, la última vez que
pedí un resumen de un informe financiero lo
hiciste de esta manera y el resultado fue
perfecto.
Hazlo así otra vez.
Es enseñarle con el ejemplo.
Es aprender de la experiencia, literalmente.
Y el tercer tipo, que me parece increíble,
es la memoria procedural.
No se trata de recordar hechos ni experiencias,
sino reglas y procedimientos.
Ahí se pone la cosa muy interesante.
El ejemplo que ponen es el de un
agente que puede modificar sus propias instrucciones, su
system prompt, basándose en el feedback que recibe.
A este proceso lo llaman reflexión.
Es un concepto muy avanzado y muy potente.
Significa que el sistema no es estático.
Si un agente genera un tuit para una
campaña de marketing y un humano le dice
esto es demasiado informal, que pasa mucho, sé
creativo y divertido, su nueva regla podría ser
sé creativo y divertido pero mantén un tono
profesional.
Es un bucle de automejora real.
Exactamente.
Se va puliendo a sí mismo.
Vale.
En papel todo esto suena increíble, casi a
ciencia ficción.
Un sistema que se autocorrige, que recuerda, que
sigue un plan.
Pero, ¿qué pasa cuando los desarrolladores intentan usar
esto en el mundo real?
Claro.
Porque, en los hilos de Reddit que tenemos,
el panorama no es tan color de rosa
para todos.
No, para nada.
Aquí es donde chocamos con la dura realidad.
Hay un comentario muy directo en el subreddit
de Langchain que lo describe como una absoluta
pesadilla de mantenimiento en producción.
Uf, palabras mayores.
Y otro usuario se queja de que probar
un grafo complejo es un desastre.
Y hace una comparación que creo que muchos
desarrolladores entenderán.
¿Cuál?
Lo compara con las primeras versiones de TensorFlow,
el framework de Google.
Ostras.
Dice que era tan poco intuitivo y tan
difícil de depurar que la gente huyó en
masa a PyTorch.
Y cualquiera que lidiara con tef.session.trizates en aquella
época sabe exactamente a qué se refiere.
Esa sensación de caja negra, de que no
sabes qué está pasando dentro.
Es esa sensación de que el framework te
está combatiendo en lugar de ayudarte.
La crítica es que LangGraph puede sentirse así,
a veces.
Demasiado complejo, demasiadas capas de abstracción.
Esa crítica sobre la complejidad y el mantenimiento
aparece varias veces.
Pero claro, no todo es negativo.
Hay gente que lo defiende a capa y
espada.
Por supuesto.
Dicen que para flujos de trabajo de agentes
es de lejos la mejor opción.
Mencionan a uno de los creadores de LandChain,
Lance Martin, que confirmó que el bot de
atención al cliente de su propia empresa está
construido con LangGraph.
Sí, y no son los únicos.
Las fuentes mencionan casos de uso reales en
empresas grandes.
Norwegian Cruise Line, por ejemplo, lo usa para
mejorar la experiencia de reserva de sus clientes.
También mencionan a Ali, una empresa financiera.
Eso es, que lo está usando para sus
agentes.
Esto nos dice que, a pesar de las
dificultades, hay quienes están consiguiendo sacarle un valor
real en entornos de producción muy exigentes.
Entonces parece que la clave no es si
la herramienta es buena o mala, sino saber
cuándo merece la pena la inversión de complejidad.
Justo.
He encontrado un comentario en el softreddit de
IAI Agents que me ha parecido oro pulo.
Un desarrollador proponía un enfoque muy pragmático para
decidir cuándo usar LangGraph.
¿Te suena esta idea de empezar con algo
simple y solo migrar cuando la cosa se
complica de verdad?
Totalmente.
Es el principio de no uses un martillo
para matar una mosca.
Empezar con LangGraph para un bot sencillo es
una sobreingeniería tremenda.
Claro.
Ese consejo refleja una madurez de desarrollo.
Primero resuelve el problema de la forma más
simple posible, que a menudo es un simple
bucle en Python.
Exacto.
Y solo cuando ese bucle empieza a llenarse
de condiciones, de if, else, any dados, cuando
el diagrama de flujo mental empieza a tener
demasiadas flechas y fallos, es cuando dices, vale,
necesito una herramienta que me ayude a gestionar
este caos.
Ahí es cuando migras a LangGraph.
Es un consejo sensacional y basado en la
experiencia pura.
Evita comprometerse demasiado pronto con un framework y
te da la estructura justo cuando la necesitas.
La regla que propone este usuario es muy
clara, la verdad.
Si es un agente que va a tener
varios pasos y va a ir a producción,
la claridad y seguridad que te da LangGraph
valen la pena al esfuerzo inicial.
Y hablando de seguridad y producción, hay otra
funcionalidad que destacan varias fuentes, como la de
IBM, la intervención humana o Human in the
Loop.
Ah, eso es fundamental.
¿Por qué es tan clave para que las
empresas se atrevan a usar estos sistemas?
Porque es la red de seguridad.
Es la capacidad de diseñar tu grafo con
puntos de control.
imagina un agente que va a realizar una
serie de transacciones financieras.
Algo delicado.
Muy delicado.
Puedes programar el grafo para que justo antes
de ejecutar la transferencia final se detenga y
espere la aprobación de un supervisor humano.
Te permite pausar todo el proceso.
Exacto.
Permite pausar el flujo, inspeccionar el estado, ese
cuaderno del que hablábamos, y asegurarse de que
todo es correcto antes de proceder.
Es el botón de emergencia.
Y he leído que incluso permite hacer algo
que llaman viajar en el tiempo.
Suena muy espectacular.
Bueno, es una consecuencia directa de tener el
estado guardado.
Si en un punto de control detectas que
la gente ha tomado una mala decisión dos
pasos atrás… ¿Puedes volver?
Puedes literalmente retroceder a ese estado anterior y
forzarle a tomar un camino diferente.
Es un nivel de control y depuración que
es casi imposible de conseguir con un script
simple.
Combina lo mejor de los dos mundos.
Sí, combina la autonomía de la IA con
la supervisión humana, que ahora mismo es el
enfoque más robusto y seguro para aplicaciones críticas.
Entonces, si unimos todas las piezas, ¿qué significa
todo esto?
LangGraph no es simplemente una librería de código
más.
Parece más bien un cambio de mentalidad.
Un cambio de paradigma, sí.
Un cambio en cómo se diseñan y construyan
los agentes de IA.
Absolutamente.
Implica pasar de pensar en secuencias lineales y
simples a pensar en sistemas cíclicos, con estado,
donde el control, la memoria y la capacidad
de observación son los protagonistas.
¿Representa una madurez en el campo?
Totalmente.
Es el reconocimiento de que, para construir sistemas
fiables, no basta con la brillantez de un
modelo de lenguaje.
Se necesita una arquitectura sólida que lo guíe,
que lo corrija y que le permita aprender
de sus interacciones.
Es el andamiaje necesario para pasar de los
prototipos y las demos espectaculares a sistemas que
funcionan de verdad en el mundo real, con
todas sus complicidades e imprevistos.
Exacto.
Es un paso fundamental en esa dirección.
Y todo esto nos deja con una idea
final para darle vueltas.
Hemos hablado de la memoria procedural, de esa
capacidad de un agente para reescribir sus propias
instrucciones basándose en el feedback.
Si un sistema puede modificar sus reglas de
funcionamiento internas para adaptarse y mejorar, dónde queda
exactamente la línea que separa una herramienta que
sigue un diagrama de flujo muy sofisticado de
un sistema que empieza a aprender y adaptarse
por sí mismo de una forma mucho más
fundamental.
Buena pregunta para cerrar.
Es una línea cada vez más difusa.
Y hasta aquí el episodio de hoy Muchas
gracias por tu atención Esto es BIMPRAXIS Nos
escuchamos en el próximo episodio ¡Suscríbete al canal!