Git Merge: Integrating changes

When you merge a branch into another, Git combines the changes made in the source branch into the target branch. This creates a new commit in the target branch, representing the merge. Merge commits are often visible in the commit history, which can make the history a bit more cluttered but also more accurately reflects the history of changes.

Git Rebase: Streamlining commit history

When you rebase a branch onto another branch, Git takes the changes in the source branch and reapplies them on top of the target branch. This essentially rewrites the commit history of the source branch to appear as if the changes were made directly on top of the target branch. Rebase results in a cleaner and linear commit history, but it can rewrite history, which can cause issues if the branch is shared or already pushed to a remote repository.

Git Squash: Consolidating commits

Squashing commits is a technique to combine multiple commits into a single commit. This is often used before merging or rebasing to tidy up the commit history and make it more cohesive. Squashing can be useful to keep the commit history clean and concise, especially for feature branches where multiple small commits might not be necessary or desirable in the main branch's history.

Choosing the right approach

The choice between merge, rebase, and squash depends on various factors, including project workflow, collaboration practices, and personal preferences. While merge is straightforward and preserves the original commit history, rebase and squash offer ways to create a cleaner, more streamlined history. However, it's crucial to consider the potential impact on collaboration and repository history when deciding which approach to use.

One common problem with rebase is the potential to rewrite commit history. When developers rebase their branches onto a common base branch, it alters the commit IDs and effectively creates new commits. While this can result in a cleaner commit history, it can also introduce confusion and conflicts, especially if other team members have already based their work on the original commits. Mismanaged rebases can lead to divergent branches and difficulties in reconciling changes.

Similarly, squash commits, while useful for tidying up a feature branch's history, can also obscure important details about the development process. When multiple commits are squashed into one, the individual changes and their respective messages are lost. This can make it harder to track down specific changes or understand the rationale behind them, especially when reviewing code or diagnosing issues in the future.

Ultimately, the key to avoiding these common problems lies in communication and collaboration within the development team. Developers should be transparent about their intentions when using Git operations like rebase and squash, and they should be mindful of the potential impact on shared branches and commit history. By following best practices and coordinating effectively, teams can harness the full power of Git while minimizing the risk of introducing unnecessary complexity or confusion.

One day, someone gave a talk about The 5AM Club book, in which the idea is to help you create a 1-hour morning routine that enables you to be more productive during your day. The suggested routine is:

• Do 20 minutes of exercise.

• Do 20 minutes of meditation.

• Take the last 20 minutes to learn something.

I was curious, so I decided to try it out.

After a week, I was finding myself being more productive, but not only that, I was also enjoying more my work.

I got a certain feeling of being present that reminded me of the times when I'm outside taking pictures and get so focus, that I eventually end up forgetting about the real world, and I would just observe everything, thinking about what my next photo should be and how I was going to compose it.

To give you an example, I can tell you about the time I went to the beach with some friends, I remember being on the seashore, and in the matter of seconds, I turned left and saw the sun, the shadows, and as I began to feel the light, the time began to slowdown, I could only hear the waves, a seagull, and a kid running into the sea. All I saw was silhouettes, and a clear image taking shape in my head. Finally, I raised my phone, and took the picture.

I used to call this phenomenon photography mood. However, I discovered a term that describes exactly what that being present feeling is.

The Flow State

I read about this term in Sarah Drasner's article Why flow matters more than passion where she describes it as follow:

The phenomenon in which a person is fully immersed in an activity that leads to focus, energized involvement, and enjoyment. A person in flow state is no longer thinking of multiple things, or even their sense of self, but is singularly focused on a task or challenge.

In my journey into the tech world, I've learnt to take advantage of the flow state, I see a lot of benefits in it.

• Solve complex problems: When in flow, complex problems seem easier than they really are.

• Keep myself motivated: There is something about the flow state that generates motivation when the flow is consistent. Better yet, this motivation last longer, it is intrinsic motivation.

• Work Smarter: When in flow, I might end a task that would normally take me a whole day in three or four hours. This allows me to use the remaining time to:

  • Rest from work.

  • Learn.

  • Improve the result of my task.

  • Work on contributions outside my role.

This, far from seeing it as stolen time from my company, I see it in a way in which I can generate more impact and improve the way people in the company see me.

Although this flow thing sounds good, it's not a switch you can get on and off whenever you want, but I think you can train your mind in a way that you can get into flow state in a more consistent way.

Generative Mental Spaces

Flow state happens when the subconscious mind takes over. If we want to enter flow state more often, we need to practice turning off our conscious mind and we need to do this consistently.

One way to do this is to create spaces in your day/week where you have no agenda, no pressure of accomplish something. These spaces are called Generative Mental Spaces, and they need to meet certain characteristics:

• They have no agenda, no pressure of accomplish something.

• It needs to be an activity in which your subconscious mind works more than your conscious mind.

• You need to do this consistently (make it a habit).

For example, my go to space is to take pictures. This space is normally me walking around observing and taking pictures without a goal and I tend to do it once a week.

Transitions

It is important that you let your mind and body know that you're entering an activity that requires you to be present. We need a way to transition from the world into our activity, this will help us to be present, and (hopefully) trick your mind into flow.

These transitions are little activities that you do before your main activity, and they have the following characteristics:

• They take no more than, let's say 20 minutes.

• They help you being present and clean the noise in your mind.

• You do them before your main activity, every time.

For example, before starting a drama class we do an exercise called exploring the space(caminar por el espacio), which consist of the group walking around the classroom while trying to have a balanced space between each person. During this exercise, the teacher instructs us to relax, breath and walk at different paces and levels. This transition allows us to leave the world behind and be present for the rest of the class.

In my day to day, a common transition activity is to clean my house/room/desk, depending on the day. After cleaning, I take a shower and then I start working.

Conclusion

I see the Flow State as a powerful tool to be better in my job. Unfortunately, is not a switch I can get on and off whenever I need it. This is why I've identified two strategies that help me get into Flow State more often:

• Generative Mental Spaces

• Transitions

By applying those strategies in my life, I'v been able get good results in my work. I'm still generating more ideas around this, so these are just my conclusions until now.

However, I hope you find these ideas useful, and if you do, let me know. :)

Para lograr lo anterior, utilizamos un Agente de Langchain que nos facilita la implementación y el uso de los modelos de OpenAI, así como los que estén disponibles. Este es muy útil para aplicaciones muy sencillas. Sin embargo, existen algunas problemáticas cuando se implementan más funcionalidades y el proyecto crece.

La problemática principal es que ahora el chatbot tiene varias funcionalidades y tiene que decidir cómo actuar dependiendo de lo que el usuario pide, disminuyendo su eficiencia al momento de responder. Nosotros, como desarrolladores, no podemos involucrarnos mucho en la manera en la que el agente toma decisiones.

Para intentar solucionar este problema, utilizamos LangGraph, una nueva herramienta que el equipo de LangChain desarrolló.

¿Qué es LangGraph?

Hace unos días, el equipo de LangChain anunció LangGraph. El objetivo de este es brindar al desarrollador un mayor control sobre el ciclo de ejecución de un Agente, pero con el uso de un grafo. Para lograrlo, se utilizan 3 elementos principales: stateGraph, Nodes y Edges.

Donde en el StateGraph se define el estado del grafo que va a viajar y mutar durante el ciclo de ejecución. Los Nodes se definen con un nombre y su función a ejecutar, y los Edges se encargan de conectar los nodos.

Los Edges se dividen en 3 grupos:

• The Starting Edge: Edge que conecta el inicio del grafo con un nodo en particular.

• Normal Edges: Edges donde un nodo siempre se ejecuta después de otro.

• Conditional Edges: Edge donde se utiliza una función para determinar qué nodo será el siguiente en ejecutarse cuando existen varias conexiones.

Existen diferencias entre un Agente de LangChain y una implementación de LangGraph. La principal diferencia es que LangGraph expone parte de la lógica interna de un AgentExecutor. Una funcionalidad notable es que se puede definir un nodoprincipal que siempre se va a ejecutar al inicio del proceso. Esto hace que el Agente ya no sea 100% autónomo, por lo que el equipo de LangChain decidió nombrar la implementación del grafo como una State Machine. Donde se combina la autonomía del Agente con instrucciones específicas que el desarrollador puede definir.

Por ejemplo, tal vez quieras:

• Forzar al agente a que ejecute una tool en específico primero.

• Tener mas control en como se van a ejecutar las tools.

• Tener diferentes prompts para el agente, dependiendo en el estado en que se encuente.

Implementación

Single Agent

Replicando el funcionamiento del chatbot de LangChain

Traduciendo la lógica de nuestro chatbot usando un AgentExecutor de LangChain a LangGraph, la implementación queda de la siguiente manera:

En el diagrama podemos observar los siguientes elementos:

Nodos:Agent, action, last_agent y END

El nodo Agent recibe el input del usuario y decide si necesita ejecutar alguna tool para realizar la tarea o si debe finalizar el proceso.

El nodo action se encarga de ejecutar las tools y devolver el output las veces que sean necesarias.

El nodo last_agent guarda la respuesta final en la base de datos antes de finalizar el proceso. Es importante mencionar que sin este nodo, el agente enviaría el mensaje directamente al nodo END para terminar el proceso y responder al usuario.

Modificaciones al proceso de ejecución

Un reto al que nos enfrentamos utilizando un agente de LangChain es indicar qué tools se deben ejecutar al momento de recibir la petición del usuario. Por ejemplo:

Input del usuario: Quiero viajar de Mérida a CDMX el 22 de febrero de 2024.

Para esta petición necesitamos varios elementos para generar la URL de viaje con las especificaciones del usuario. Necesitamos: origen, destino, fecha de salida, fecha de regreso y número de pasajeros.

La manera en que obtenemos estos parámetros es con una tool llamada params_extractor y esta debe ejecutarse al principio del ciclo. El problema es que el agente, al ser 100% autónomo, únicamente delimitado por el prompt del sistema, no siempre ejecuta esta tool y puede ocurrir un error al consultar los viajes y generar la URL.

Aprovechando que LangGraph te permite involucrarte en el proceso de ejecución, una modificación interesante, como antes se mencionó, es forzar al agente a primero ejecutar una tool al principio del proceso. Quedando de la siguiente manera:

En el diagrama se puede observar que hay un nuevo nodo,first_agent, que se comunica directamente con action para forzar la ejecución de la tool params_extractor y después seguir con el proceso. Con esto resolvemos el problema. Esta solución es ideal en el caso de que el chatbot solo sea capaz de consultar viajes disponibles y armar la URL de viaje.

¿Que pasaría si el chatbot tuviera mas funcionalidades?

Actualmente, el chatbot tiene varias funcionalidades:

• Generar una URL para viajes disponibles.

• Responder preguntas relacionadas al contenido que se encuentra en el sitio de Reservamos.com. Ej. ¿Qué es un boleto flexible?

• Proporcionar detalles de una compra previa (soporte al cliente).

A medida que se agregan nuevas funcionalidades, la lista de tools va creciendo, reduciendo la eficiencia del chatbot. Esto se debe a que, cuanto más funcionalidades tenga, aumenta el margen de error al momento de decidir qué tools ejecutar.

Un enfoque interesante es utilizar LangGraph Multi-Agent.

Multi-Agent

Un Chatbot con el enfoque Single Agent puede funcionar de manera efectiva usualmente utilizando un grupo de tools dentro de un único dominio, pero incluso utilizando modelos poderosos como gpt-4, puede ser menos efectivo al usar muchas tools.

Una manera de abordar tareas complicadas es a través de un enfoque de "divide y vencerás": crear un agente especializado para cada tarea o dominio y dirigir las tareas al "experto" correcto.

Ahora cada nodo es un agente con sus propias tools y se definen utilizando la clase AgentExecutor. Al seguir con este enfoque, nos podemos encontrar nuevamente con las limitantes de un Agente de LangChain. ¿Cómo puedo involucrarme en el proceso de cada agente? Para lograr esto, sería necesario que cada agente sea un subgrafo con sus propios flujos de ejecución en lugar de utilizar un AgentExecutor. Lo que genera nuevos puntos a considerar. Por ejemplo:

• ¿Cuántos tokens va a consumir?

• ¿Cuánto tiempo va a tardar en responder?

• ¿Qué tan preciso es?

Es importante tomar en cuenta las preguntas anteriores, ya que tenemos que asegurar que la eficiencia del chatbot se mantenga o mejore, mientras que el tiempo y costo de procesamiento no aumenten drásticamente.

Al ejecutar pruebas manuales, podemos notar un comportamiento interesante. Iniciamos estas pruebas con peticiones sencillas como: "Quiero viajar de <origen> a <destino> el 23 de marzo". Resultando en una respuesta correcta con un tiempo de ejecución dentro de un rango aceptable.

Mensaje inicial - Hola!

Recordemos que tenemos un chatbot y sabemos que normalmente los usuarios inician con un Hola y no con la petición que quieren. Entonces, el siguiente paso es observar el comportamiento del supervisor con un primer input saludando al chatbot. Resulta que no contesta a esos mensajes. Ya que, la responsabilidad del supervisor es delegar la tarea a uno de sus expertos y al no coincidir ninguno con el input, este decide terminar la ejecución.

Un primer enfoque para resolver esta situación puede ser agregar un agente nuevo que se encargue de contestar conversaciones casuales hasta que el usuario ingrese la información suficiente para ejecutar otro agente y dar una respuesta final. Lo cual parece la opción ideal, pero el supervisor no entiende que la respuesta que devuelve el nuevo agente no es un mensaje del usuario y la ejecución termina en un bucle.

Una forma de evitar esto es modificar manualmente el nodo responsable de llamar de nuevo al supervisor o terminar el proceso. Cuando recibe una respuesta de uno de sus agentes, devuelve la respuesta al usuario. Esto no es ideal ya que el propósito de este enfoque es que los agentes puedan interactuar entre ellos para generar una respuesta más precisa. Sin embargo, por ahora, esto solo es posible para peticiones específicas y no para mantener una conversación.

Aún así, podemos aprovechar esta idea de tener varios "expertos", dividir las responsabilidades y al mismo tiempo, mantener una conversación casual. ¿Cómo? Regresando al primer enfoque SingleAgent Chatbot Graph con algunas modificaciones. La idea es mantener la estructura de un Agente que tiene una lista de tools para ejecutar dependiendo del input del usuario. Pero ahora, estas tools las vamos a ver como "expertos", cada uno de ellos con un nombre y descripción de lo que pueden hacer. Cuando se invoquen, estas se encargarán de inicializar un Agente siendo un subgrafo con sus propios nodos y tools a ejecutar.

Con este nuevo enfoque logramos lo siguiente:

• El grafo principal puede mantener conversaciones casuales.

• Cada subgrafo tiene su propio flujo, sus nodos y hasta podemos utilizar diferentes modelos de IA para realizar sus tareas.

Con estos resultados, podemos afirmar que hemos logrado nuestro objetivo.

1. Como desarrolladores, podemos involucrarnos en el proceso de ejecución del Agente.

2. El chatbot es capaz de mantener una conversación casual sin consumir más memoria.

3. Los tiempos de respuesta y el consumo de tokens son similares a nuestro Agente de LangChain.

4. Implementamos la arquitectura multi-agente, lo que nos ofrece flexibilidad para implementar varios modelos de IA simultáneamente y experimentar con ellos.

Puntos a considerar

Para saber si es viable implementar LangGraph con Multi-Agent, hay una serie de puntos a considerar con sus respectivos criterios:

1. Asegurar que el chatbot responde de manera correcta a la petición del usuario.

   1. Ejecutando pruebas unitarias donde definimos una serie de preguntas que nos ayudan a validar el comportamiento del chatbot.

2. Mantener el tiempo de respuesta promedio del chatbot.

   1. Ejecutando las pruebas unitarias múltiples veces para calcular el promedio de tiempo de respuesta y compararlo.

3. Mantener el consumo de tokens por request.

   1. Ejecutando las pruebas unitarias múltiples veces para calcular el promedio de consumo de tokens por request y compararlo.

4. Analizar si mejora la escalabilidad del proyecto.

   1. Es importante mencionar que la complejidad del proyecto puede aumentar con el uso de LangGraph, ya que cada nodo puede tener su propio flujo de ejecución. Por lo tanto, un buen diseño y documentación son cruciales para mantener el proyecto manejable y escalable.