Crear las herramientas de un agente con LangChain es el paso que conecta tu base de datos vectorial con la lógica que el agente usará para responder preguntas. Aquí aprenderás a definir dos herramientas clave: una para búsqueda vectorial en MongoDB y otra para resumir documentos, todo dentro de un Jupyter Notebook.

¿Qué hace LangChain en la creación de herramientas para un agente?

LangChain es la librería que permite declarar funciones de Python como herramientas que un agente puede invocar. Más adelante también se encarga de la orquestación, es decir, decidir cuándo y cómo usar cada herramienta según la intención del usuario.

La mecánica es simple: defines una función normal en Python y le agregas el decorador @tool. Con eso LangChain reconoce esa función como una capacidad disponible para el agente [01:32].

¿Qué es una tool en LangChain? Es una función de Python marcada con el decorador @tool que el agente puede llamar para ejecutar una acción específica, como buscar en una base de datos o resumir un documento.

¿Por qué necesitas un modelo de embeddings para el query del usuario?

Cada pregunta que el usuario haga debe transformarse en vectores antes de consultar la base de datos. La regla es clara: usa el mismo modelo de embeddings con el que generaste los vectores guardados en MongoDB. Si usas modelos distintos, la comparación vectorial pierde sentido porque viven en espacios distintos.

¿Cómo se construye la herramienta de búsqueda vectorial en MongoDB?

La búsqueda vectorial se arma con un aggregation pipeline de MongoDB que apunta al índice donde están almacenados los embeddings [02:45]. No ejecutas queries tradicionales, ejecutas código que llama al API de la colección.

El flujo dentro de la función es el siguiente:

• Defines el aggregation pipeline indicando qué índice vectorial usar.
• Llamas al método aggregate sobre el objeto colección y le pasas el pipeline como parámetro.
• Recibes los documentos cuyos vectores están más cercanos al vector del query.

Esa cercanía vive en un espacio vectorial. Y aquí viene un matiz importante: cercano no siempre significa relevante.

¿Qué pasa si preguntas algo fuera del dominio de los datos?

La búsqueda vectorial siempre devuelve algo. Siempre. Aunque tu pregunta no tenga relación con los documentos cargados, el motor te traerá el documento más próximo en el plano vectorial, pero ese más próximo puede estar lejísimos en términos semánticos.

En la demostración se hicieron dos pruebas concretas:

• Pregunta dentro del dominio: ¿Cuáles son las mejores prácticas para hacer backups de datos en MongoDB? → resultados coherentes.
• Pregunta fuera del dominio: When Bogotá was founded? → la búsqueda devuelve un documento, pero no responde la pregunta.

¿Por qué la búsqueda vectorial devuelve resultados irrelevantes a veces? Porque solo mide proximidad en el espacio vectorial. Si no hay documentos realmente relacionados, el más cercano que encuentre será el resultado, aunque esté semánticamente lejos.

La única forma de validar si esa respuesta tiene sentido frente a la pregunta es pasarla por un modelo de lenguaje, paso que viene después en el flujo del agente.

¿Cómo defines la herramienta para resumir documentos?

La segunda herramienta tiene un objetivo distinto: traer una página específica de la base de datos para resumirla. También se declara como función con el decorador @tool y queda lista para que el agente la invoque cuando detecte que la intención del usuario es obtener un resumen, no una búsqueda.

Una vez definidas ambas funciones, se agrupan en un arreglo:

• Herramienta de búsqueda vectorial.
• Herramienta de resumen de documentos.

Ese arreglo es lo que recibirá el agente como su caja de herramientas disponibles [05:10].

¿Cómo pruebas que las herramientas funcionan antes de conectarlas al agente?

Antes de orquestar nada, conviene invocar cada herramienta de forma directa. En el laboratorio se hace así:

• Se ejecuta la búsqueda vectorial con una pregunta real sobre MongoDB y se revisa el documento devuelto.
• Se ejecuta la función de resumen sobre una página específica y se valida la salida.

Este paso confirma que las funciones, el pipeline y la conexión con la colección están funcionando. Si algo falla aquí, falla todo el agente después.

¿Qué es un embedding y por qué importa en este flujo?

Un embedding es un arreglo de números que captura las similitudes semánticas de los datos. En MongoDB, esos vectores pueden guardarse junto con la información a la que corresponden dentro del mismo documento, lo que simplifica la arquitectura porque no necesitas una base de datos vectorial aparte.

La búsqueda vectorial recupera los documentos cuyos embeddings están más cercanos al embedding del query. Es eficiente, pero ciega al contexto: por eso el agente combinará esta búsqueda con un modelo de lenguaje en el siguiente paso.

¿Ya tienes claro cómo vas a estructurar tus propias tools para un caso de uso real? Cuéntame en los comentarios qué herramienta definirías primero.