LlamaIndex: Context-Augmented LLM Applications

Hola, soy Alex de DEV STORIES DOT EU. LlamaIndex: Aplicaciones LLM con context augmentation, episodio 1 de 14. Los modelos preentrenados son brillantes, pero no saben absolutamente nada sobre los documentos privados que creaste esta mañana. Le pides a un LLM que resuma tu nueva presentación financiera del Q3, y este adivina a ciegas o te dice que no puede ayudarte. El imperativo del context augmentation es cómo solucionas esto. Los Large Language Models poseen capacidades de razonamiento increíbles, pero su conocimiento está congelado en el tiempo y se limita a datos públicos. No tienen acceso a tus wikis internas, tus tickets de soporte al cliente ni tus informes financieros privados. LlamaIndex existe para cerrar exactamente esta brecha. Actúa como el tejido conectivo entre los modelos fundacionales y tus datos privados y localizados. Cuando le pides a un modelo que resuma esa presentación del Q3, no puedes simplemente enviar la pregunta. Necesitas un sistema que encuentre las diapositivas relevantes, extraiga el texto y le pase esa información específica al modelo junto con tu prompt. Este proceso es el context augmentation. Le estás dando al modelo el contexto exacto que necesita para aplicar sus habilidades de razonamiento a tus datos privados. LlamaIndex proporciona la infraestructura para ingerir, organizar y recuperar tus datos, de modo que el context augmentation ocurra de forma fiable. Recuperar texto y responder a una sola pregunta es solo la base. Las aplicaciones modernas requieren más autonomía. Esto nos lleva a las aplicaciones agénticas. Una aplicación agéntica no sigue simplemente una línea recta desde una pregunta a una base de datos y luego a una respuesta. Toma decisiones por el camino para gestionar intenciones complejas del usuario. La primera pieza de esto es el routing. Cuando un usuario hace una pregunta, el sistema necesita decidir qué fuente de datos o herramienta es la adecuada. Si el usuario pide un resumen corporativo de alto nivel, el router dirige la query al index de la presentación del Q3. Si el usuario pide el desglose numérico exacto de las ventas regionales, el router podría enviar la query a una base de datos SQL estructurada en su lugar. El routing garantiza que el modelo use la herramienta adecuada para el trabajo en función del input. La segunda pieza es el prompt chaining. Las tareas complejas suelen fallar cuando le pides a un modelo que las gestione en un solo prompt masivo. El prompt chaining divide un objetivo complejo en tareas más pequeñas y secuenciales. El sistema podría ejecutar un prompt para extraer las cifras de ingresos de la presentación, pasar esas cifras a un segundo prompt que las compare con datos históricos, y enviar ese output a un tercer prompt que redacte un resumen ejecutivo. El output de un paso se convierte en el contexto exacto para el siguiente paso. Aquí es donde la cosa se pone interesante. Incluso con los datos correctos y una chain estructurada, los modelos cometen errores. Esto introduce la reflection. La reflection es un paso de control de calidad automatizado. Antes de entregar el resumen final de la presentación del Q3 al usuario, la aplicación agéntica usa un prompt independiente para evaluar su propio borrador. Comprueba si el texto generado está totalmente respaldado por las diapositivas recuperadas. Si el paso de reflection detecta una alucinación o una métrica clave omitida, rechaza el borrador y lanza una corrección. El verdadero poder de las aplicaciones context-augmented no es solo darle a un LLM un documento para leer, sino darle un workflow estructurado y autocorrectivo para razonar de forma segura sobre tus datos privados. Si quieres ayudar a que el programa siga adelante, puedes buscar DevStoriesEU en Patreon y apoyarnos allí. Eso es todo por este episodio. ¡Gracias por escuchar y seguid creando!

Hola, soy Alex de DEV STORIES DOT EU. LlamaIndex: Aplicaciones LLM con Contexto Aumentado, episodio 2 de 14. No puedes simplemente meter un PDF de 500 páginas en la context window de un LLM y esperar una respuesta precisa. El modelo perderá el hilo, alucinará o simplemente rechazará el payload por exceder sus límites. Para que los archivos masivos sean útiles, tienes que dividirlos en trozos muy pequeños y traducirlos a un formato matemático que la máquina pueda buscar. Ese proceso es exactamente lo que cubre hoy Data Ingestion: Documents and Nodes. Imagina procesar un enorme manual de recursos humanos para empleados. El texto vive en un PDF gigante, que abarca docenas de capítulos complejos. El primer paso en una pipeline de Retrieval-Augmented Generation es la fase de carga. Aquí es donde entran en juego los Data Connectors, a menudo llamados Readers. Un conector coge tu fuente de datos en crudo —ya sea un PDF local, una tabla de base de datos remota o la respuesta de una API externa— y la envuelve en una estructura de datos llamada Document. La gente suele confundirse con este término. En este framework, un Document no significa un archivo de Word o un PDF. Un Document es simplemente un contenedor genérico para cualquier fuente de datos ingerida. Contiene el texto en crudo junto con algunas propiedades básicas. Sin embargo, un único Document que represente un manual de 500 páginas es completamente inútil para una búsqueda precisa y rápida. Tienes que dividirlo. Esto nos lleva a los Nodes. Un Node es la verdadera unidad atómica de datos en LlamaIndex. Es un chunk más pequeño y manejable de un Document padre; quizá un solo párrafo que detalla la política de permiso parental. Cuando procesas el manual de recursos humanos, el framework coge el Document masivo y lo divide en miles de Nodes. Aquí está la clave. Los Nodes no solo contienen texto aislado. Llevan metadata enriquecida y relaciones estructurales. Un Node sabe exactamente de qué Document padre proviene. También sabe qué Node le precede lógicamente y qué Node le sigue. Esta estructura enlazada es lo que permite al sistema sintetizar un contexto mayor más adelante si un solo chunk no contiene toda la respuesta. Una vez que tienes tus datos troceados en Nodes precisos, pasas a la fase de indexación. Necesitas una forma robusta de encontrar el Node correcto cuando un usuario haga una pregunta más tarde. Esto requiere traducir el lenguaje humano a un formato numérico llamado embedding. Un embedding es un array de números en coma flotante que representa el significado semántico del texto dentro del Node. Pasas cada Node por un modelo de embeddings. El modelo lee el chunk y devuelve un vector de alta dimensión. Si dos Nodes tratan temas conceptualmente similares —como la baja por enfermedad y las vacaciones pagadas— sus vectores numéricos estarán matemáticamente cerca el uno del otro en el espacio. Con estos vectores generados, construyes un Index. El Index es el componente estructural central que organiza tus Nodes para que puedan ser consultados. Para la mayoría de las aplicaciones, este Index está respaldado por un Vector Store. El Vector Store actúa como una base de datos especializada diseñada explícitamente para guardar estas representaciones matemáticas y realizar cálculos de similitud altamente eficientes sobre ellas. El flujo lógico es muy predecible. Primero, configuras un Data Connector para apuntar a tu manual de recursos humanos. El conector lee el archivo y devuelve un único objeto Document. A continuación, un parser coge ese Document y lo divide en un array de objetos Node independientes. Finalmente, pasas ese array de Nodes a un Index, que coordina la creación de los embeddings vectoriales y los guarda en el Vector Store. Toda la pipeline de Data Ingestion existe para resolver una limitación fundamental. Los grandes modelos de lenguaje no pueden leer libros enteros de una sola vez de forma fiable, pero pueden calcular al instante la distancia matemática entre dos arrays de números. Traducir tus archivos en crudo a Documents, cortarlos en Nodes enlazados y codificarlos en Indexes vectoriales es lo que salva esa brecha. Eso es todo por este episodio. ¡Gracias por escuchar, y sigue construyendo!

Hola, soy Alex de DEV STORIES DOT EU. LlamaIndex: Context-Augmented LLM Applications, episodio 3 de 14. Coges el chunk de documento correcto, lo envías al modelo de lenguaje y aun así obtienes una mala respuesta porque estaba enterrado bajo diez chunks irrelevantes. Encontrar el texto es solo la mitad de la batalla. Filtrar, rankear y decidir cómo hacer el fetch en primer lugar es donde el sistema realmente triunfa o fracasa. Hoy vamos a ver la fase de ejecución de RAG, en concreto el Query Pipeline: Retrievers y Routers. En esta fase, tus datos ya están cargados e indexados. Un usuario envía una query. El primer componente que intercepta esta query suele ser un router. Un router es un motor de decisión. Analiza la pregunta entrante y determina qué tool o index subyacente es el más adecuado para responderla. Imagina que un usuario hace una pregunta compleja sobre un evento histórico concreto que también incluye acrónimos muy específicos. Una vector search estándar podría captar el significado semántico del evento, pero perderse los acrónimos. Una keyword search clavará los acrónimos, pero perderá el contexto general. El router evalúa la query y decide enviarla por dos caminos simultáneamente. Enruta la petición tanto a una vector search como a una keyword search. Esto nos lleva a los retrievers. Un retriever se encarga de definir exactamente cómo hacer el fetch del contexto relevante desde un index. No genera respuestas. Solo hace fetch de datos. Siguiendo nuestro escenario, el vector retriever convierte la query del usuario en un embedding y extrae los nodes matemáticamente más similares, que no son más que chunks de tus documentos de origen. Al mismo tiempo, el keyword retriever extrae los nodes que contienen coincidencias de texto exactas para esos acrónimos. Ahora tienes dos montones distintos de nodes. No puedes simplemente añadirlos todos a ciegas al prompt de tu modelo de lenguaje. Las context windows son limitadas, y los modelos se distraen fácilmente con datos irrelevantes. Aquí es donde entran en juego los node postprocessors. Esta es la clave. Los node postprocessors actúan como un guardián entre los retrievers y el modelo de lenguaje. Aplican transformaciones, filtrado o lógica de re-ranking a los nodes obtenidos. Por ejemplo, un postprocessor puede aplicar un similarity cutoff, descartando cualquier node que tenga una puntuación por debajo de un umbral específico. Puede deduplicar nodes si la vector search y la keyword search han extraído exactamente el mismo párrafo. También puede hacer un re-ranking de los nodes restantes para que el chunk absolutamente más relevante se sitúe en lo más alto de la context window. Una vez que el postprocessor ha limpiado y ordenado los datos, el sistema se los pasa al response synthesizer. El synthesizer tiene un solo trabajo. Coge la lista pulida de nodes y la query original del usuario, los combina en un prompt estructurado y los envía al modelo de lenguaje. El modelo de lenguaje genera entonces la respuesta final legible por humanos basándose únicamente en ese contexto proporcionado. La fase de ejecución de la query es estrictamente un pipeline. Enrutas la query, recuperas los raw nodes, filtras y rankeas esos nodes con un postprocessor, y finalmente sintetizas el texto. Si controlas lo que ve el modelo de lenguaje, controlas la calidad del output. Gracias por pasar unos minutos conmigo. Hasta la próxima, cuídate.

Hola, soy Alex de DEV STORIES DOT EU. LlamaIndex: Aplicaciones LLM con Contexto Aumentado, episodio 4 de 14. Estás creando un agente que gestiona tickets de soporte IT, pero la mitad de los envíos son solo fotos hechas con el smartphone de luces de error parpadeando. El procesamiento de solo texto te obliga a crear pipelines de visión separados o a eliminar por completo el contexto visual. Hoy vamos a ver cómo interactuar con LLMs y los inputs multimodales, lo que resuelve esto directamente en la capa del modelo. En LlamaIndex, la interacción con un modelo de lenguaje pasa por la clase LLM base. Esta actúa como una interfaz unificada. Tanto si llamas a un modelo de OpenAI, a uno de Anthropic o a un proveedor distinto, los métodos principales que usas son idénticos. Esta abstracción protege la lógica de tu aplicación de los cambios de API específicos de cada proveedor. Cuando quieres una respuesta del modelo, eliges entre dos métodos principales. El primero es el método complete. Le pasas un único string de texto que contiene tu prompt, y te devuelve una única respuesta de texto. Está pensado para tareas directas de tipo single-shot, como resumir un documento o extraer un dato específico. El segundo método es el método chat. Está diseñado para conversaciones o interacciones estructuradas. En lugar de un solo string, le pasas una lista de objetos de mensajes de chat. Cada mensaje tiene un rol específico asociado, normalmente system, user o assistant. Al pasarle una lista, el método chat le da al modelo todo el contexto de un intercambio de mensajes antes de generar su siguiente respuesta. Tanto complete como chat esperan a que el modelo termine toda su generación antes de devolver el output. Si el modelo está escribiendo una respuesta larga, tu aplicación se queda inactiva. Para solucionar esto, usas streaming. En su lugar, llamas a stream complete o stream chat. Estos métodos devuelven un generador. A medida que el modelo produce tokens, tu código los recibe en pequeños chunks. Iteras sobre este generador para imprimir la respuesta en una interfaz de usuario en tiempo real, eliminando la percepción de latencia. Ahora bien, la segunda parte de esto es gestionar datos que no son de texto. Aquí es donde la cosa se pone interesante. Los LLMs modernos analizan información visual, y LlamaIndex soporta esto mediante content blocks. En lugar de pasar un simple string de texto dentro de un mensaje de chat de usuario, puedes pasar una lista de bloques. Piensa de nuevo en el ticket de soporte IT con el rack de servidores averiado. Necesitas que el modelo mire la foto y lea tus instrucciones de diagnóstico. Primero, creas un ImageBlock. Le pasas a este bloque los datos de la imagen. LlamaIndex te permite pasar un path de archivo local, una URL directa o bytes en crudo codificados en base sesenta y cuatro. A continuación, creas un TextBlock. Le pasas tu prompt de texto, pidiéndole al modelo que identifique el fallo de hardware que se muestra en la foto. Metes tanto el ImageBlock como el TextBlock en una única lista, y adjuntas esa lista a un nuevo mensaje de chat de usuario. Cuando le pasas este mensaje al método chat de un modelo con capacidad de visión, el LLM procesa la disposición visual del rack de servidores junto con tus instrucciones de texto. Devuelve un diagnóstico basado en ambos inputs combinados. Aquí está la clave. El verdadero poder de esta arquitectura es su consistencia. Tanto si estás enviando un string de una sola línea, haciendo streaming de una respuesta en tiempo real, o pasando un array complejo de bloques de texto e imagen, el patrón de interacción con la clase LLM se mantiene completamente estandarizado en todo tu codebase. Eso es todo por este episodio. ¡Hasta la próxima!

Hola, soy Alex de DEV STORIES DOT EU. LlamaIndex: Aplicaciones LLM Aumentadas por Contexto, episodio 5 de 14. Nada rompe un pipeline de producción más rápido que un LLM decidiendo añadir "Claro, aquí tienes tu JSON" justo antes del payload de datos real. Pides un output legible por máquina, recibes texto conversacional de relleno y tu parser falla al instante. Cerrar la brecha entre el lenguaje natural no estructurado y los tipos programáticos fiables es exactamente lo que resuelve la extracción de datos estructurados con Pydantic. Consideremos el caso de parsear una bandeja de entrada de correo electrónico desordenada, llena de mensajes de proveedores, recordatorios de pago y recibos no estructurados. Tu sistema necesita extraer datos estructurados de facturas de este texto. Si dependes de la generación de texto estándar, obtienes resultados impredecibles. Una respuesta podría usar camel case para las keys, otra podría formatear las fechas de forma diferente, y los precios a menudo vuelven como strings con símbolos de moneda adjuntos. Acabas escribiendo una lógica interminable de manipulación de strings solo para obtener un número útil de la respuesta. En lugar de pedirle JSON al modelo y esperar que cumpla, defines tus requisitos exactos usando un base model de Pydantic. Creas una clase de Python llamada Invoice. Dentro de esta clase, declaras los tipos de datos precisos que espera tu aplicación. Defines la fecha como un string, los artículos comprados como una lista de strings, y el precio total estrictamente como un float. Aquí está la clave. LlamaIndex toma tu clase de Pydantic y la serializa automáticamente en un JSON schema estricto. Cuando envías el texto del correo electrónico al modelo, LlamaIndex adjunta este schema y activa el structured output o la API de function-calling del modelo subyacente. El schema actúa como un límite estricto. El LLM ya no está generando texto libre. Está obligado a rellenar los campos del JSON schema específicamente con los tipos que has pedido. También puedes dirigir el razonamiento del modelo directamente dentro de tus estructuras de datos. Al adjuntar un field description a un atributo, le das al LLM instrucciones específicas. Para el atributo price, puedes añadir un field description indicando que extraiga el coste total final, ignorando los gastos de envío. El LLM lee esta descripción como parte de la definición del schema y aplica esa lógica durante la fase de extracción. Cuando vuelve la respuesta, LlamaIndex no te entrega un raw string ni un diccionario genérico. Procesa la respuesta a través de Pydantic y devuelve un objeto Invoice completamente instanciado. Los datos ya están validados. Como el framework aprovecha las funciones nativas de structured output, el modelo sabe de antemano que debe proporcionar un float real para el precio, no una representación en string del mismo. Puedes acceder inmediatamente al atributo invoice punto price en tu código y realizar operaciones matemáticas con él. No hay necesidad de limpiar el texto conversacional de relleno, quitar signos de dólar, ni castear strings a números. La transición del lenguaje natural a la lógica de la aplicación ocurre sin problemas en la capa de extracción. Al empujar tu data schema directamente en el proceso de extracción, obligas al LLM a adaptarse al código de tu aplicación, en lugar de escribir código de aplicación frágil para tolerar el comportamiento impredecible del LLM. Eso es todo por este episodio. Gracias por escuchar, ¡y sigue construyendo!

Hola, soy Alex de DEV STORIES DOT EU. LlamaIndex: Aplicaciones LLM con Contexto Aumentado, episodio 6 de 14. ¿Qué pasaría si tu aplicación pudiera decidir qué funciones ejecutar según la intención del usuario, en lugar de un conjunto rígido de sentencias condicionales? Esa es la idea principal detrás de la creación de agentes de funciones autónomas. Cuando creas un pipeline de consultas estándar, tú dictas la ruta de ejecución. Un agente le da la vuelta a este paradigma. Proporcionas un conjunto de tools, y un motor de razonamiento automatizado usa un LLM para decidir a qué tools llamar, y en qué orden, para resolver un problema. Antes de seguir, tenemos que aclarar un malentendido común. El propio LLM no ejecuta tu código Python. Simplemente genera una request de texto estructurado diciendo que quiere llamar a una función específica con unos argumentos específicos. El framework de agentes de LlamaIndex intercepta esa request, ejecuta tu código Python en local, y luego le devuelve el resultado al LLM. Para que este routing autónomo funcione, necesitas tools. Una tool es básicamente una función estándar de Python envuelta en una clase de LlamaIndex llamada FunctionTool. Pero como el LLM necesita saber cuándo y cómo usar tu función, los metadatos de tu código se convierten en una parte crítica del sistema. El framework extrae el nombre de la función, los type hints y el docstring, y se los pasa al LLM como instrucciones. Veamos un escenario concreto. Quieres que tu agente resuelva problemas matemáticos de texto. Escribes dos funciones en Python, una llamada add y otra llamada multiply. Para la función multiply, tus type hints especifican que recibe dos enteros y devuelve un entero. Y lo que es más importante, escribes un docstring que dice claramente que esta función multiplica dos números. Envuelves ambas funciones en tools y las pasas en una lista, junto con el LLM que hayas elegido, para inicializar el agente. Aquí es donde la cosa se pone interesante. Le preguntas al agente: cuánto es dos más dos, multiplicado por tres. El agente entra en un bucle de razonamiento. Primero, el LLM analiza el prompt y mira las tools disponibles. Lee tus docstrings y decide que primero necesita sumar. Genera una request para llamar a la tool add con los argumentos dos y dos. El framework ejecuta tu función de Python en local y le devuelve el resultado, cuatro, al agente. El agente no ha terminado. Mira el resultado intermedio y su objetivo original. Decide que ahora necesita multiplicar. Pide la tool multiply, pasándole el cuatro que acaba de recibir y el tres de tu prompt original. El framework ejecuta la multiplicación y devuelve doce. Finalmente, el LLM reconoce que el problema está resuelto y genera una respuesta conversacional para el usuario. Aquí no hay reglas hardcoded ni lógica de routing explícita. El agente descubrió las dependencias y el orden de las operaciones por sí solo, basándose en las tools disponibles. Esto significa que la forma en la que escribes tus definiciones de Python dicta directamente lo inteligente que es tu agente. Tus type hints y tus docstrings ya no son solo para otros desarrolladores, son el prompt literal que impulsa la lógica autónoma del agente. Si le estás sacando valor a estos episodios y quieres apoyar el programa, puedes buscar DevStoriesEU en Patreon. Eso es todo por este episodio. ¡Gracias por escuchar, y a seguir programando!

Hola, soy Alex de DEV STORIES DOT EU. LlamaIndex: Aplicaciones LLM con Contexto Aumentado, episodio 7 de 14. Estás creando un agente que necesita consultar precios de acciones, obtener mensajes de Slack o consultar una base de datos. Podrías pasar días leyendo la documentación de la API, gestionando esquemas de autenticación y escribiendo código boilerplate de integración. O podrías simplemente coger el trabajo ya terminado que un desarrollador de la comunidad ha escrito y verificado. Este episodio trata sobre cómo extender agentes con las tools de LlamaHub. Los agentes dependen de tools para interactuar con el mundo exterior. Aunque puedes escribir cada integración a mano, LlamaHub existe específicamente para eliminar ese trabajo redundante. Funciona como un inmenso registro open-source de tool specs preconstruidas. Un tool specification, o tool spec, es esencialmente una clase de Python que agrupa múltiples llamadas a la API relacionadas en un solo paquete. Al meterlas directamente en tu proyecto, te saltas todo el proceso de escribir la lógica subyacente para servicios de terceros. Para usar una de estas integraciones, instalas su paquete específico. Si quieres que tu agente responda preguntas sobre el precio de las acciones de una empresa, no escribes una request HTTP personalizada a la API de Yahoo. En su lugar, usas tu gestor de paquetes estándar para instalar el paquete de tools Llama Index Yahoo Finance. Una vez instalado, importas la clase Yahoo Finance Tool Spec en tu script. Aquí está la clave. No le pasas la clase tool spec directamente al agente. Como un tool spec es un paquete de múltiples capacidades, primero tienes que desempaquetarlo. Esto lo haces creando una instancia del Yahoo Finance Tool Spec, y luego llamando a un método específico llamado to tool list. Este método separa el paquete y devuelve un array plano estándar de tools individuales que el agente puede leer y ejecutar. Este diseño modular significa que no estás limitado a usar solo tools externas o solo tools internas. Puedes combinarlas sin problemas. Supongamos que ya tienes una function tool local y personalizada que formatea números de divisas específicamente para el dashboard interno de tu empresa. Simplemente creas una lista estándar de Python. Dentro de esa lista, metes tu tool personalizada de formateo de divisas, y también haces un append de las tools desempaquetadas de la tool list de Yahoo Finance. Luego, coges este array combinado y se lo pasas directamente a tu agente durante la inicialización, asignándolo al parámetro tools. Cuando le haces un prompt al agente con una pregunta sobre el precio actual de una acción, el agente evalúa la request del usuario comparándola con las descripciones de todas las tools de esa lista combinada. Reconoce que la tool de Yahoo Finance es la opción correcta para obtener los datos del mercado. Extrae el ticker de la empresa del prompt del usuario, ejecuta la tool de Yahoo Finance, recupera el precio en tiempo real y, opcionalmente, puede hacer un chain de ese resultado raw hacia tu tool de formateo local antes de devolver la respuesta final al usuario. Acabas de darle a tu aplicación capacidades complejas de búsqueda financiera instalando un paquete, instanciando una clase y llamando a un método de desempaquetado. Este patrón arquitectónico se aplica a cientos de integraciones en LlamaHub, desde leer documentos de Google Drive hasta consultar Wikipedia. El verdadero potencial de un agente autónomo no se encuentra solo en la capacidad de razonamiento del modelo de lenguaje subyacente, sino en la inmensa variedad de sistemas externos a los que puede acceder al instante mediante tool specs preconstruidas. Eso es todo por este episodio. Gracias por escuchar, ¡y seguid construyendo!

Hola, soy Alex de DEV STORIES DOT EU. LlamaIndex: Aplicaciones LLM con Contexto Aumentado, episodio 8 de 14. Le pasas a un modelo de lenguaje un prompt masivo pidiéndole que investigue un tema, escriba un informe y revise críticamente su propio trabajo. Falla. La context window se desorganiza, las tools se usan mal y el resultado es una solución a medias. La solución es dividir ese prompt masivo en un enjambre de especialistas usando Multi-Agent Swarms con AgentWorkflow. Un único agente sobrecargado sufre porque tiene demasiadas tools e instrucciones contradictorias. Tiene que decidir cuándo buscar, cuándo redactar y cuándo editar, todo mientras gestiona un context interno masivo. AgentWorkflow resuelve esto permitiéndote definir una red de agentes muy enfocados. Cada agente opera con un system prompt muy acotado, un set restringido de tools y un único objetivo. Piensa en un pipeline de generación de contenido. En lugar de un megaagente, creamos tres FunctionAgents distintos. Primero, el Investigador. Equipamos a este agente con una tool de búsqueda web y le damos la instrucción estricta de recopilar datos. No redacta texto. Luego, definimos al Redactor. Le quitamos por completo las tools de búsqueda para evitar que se distraiga. Su único trabajo es coger los datos en bruto y redactar párrafos limpios. Finalmente, definimos al Revisor. Le damos guidelines sobre el tono y la precisión de los datos, indicándole que critique el texto. Aquí está la clave. Tener varios agentes es inútil si no pueden coordinarse, pero darles vía libre para hablar con cualquiera crea el caos. Tienes que conectarlos explícitamente. En AgentWorkflow, haces esto definiendo permisos de handoff. Cuando configuras tus agentes, especificas una propiedad llamada can handoff to. Esta acepta una lista de otros agentes. Para nuestro pipeline, le damos al Investigador permiso para hacer handoff al Redactor. Le damos al Redactor permiso para hacer handoff al Revisor. También le damos al Revisor permiso para hacer handoff de vuelta al Redactor si el texto necesita revisión. Esto crea un grafo dirigido y estricto de agentes. El framework impone estos límites. El Investigador no puede saltarse al Redactor y enviar las notas en bruto directamente al Revisor. Simplemente no tiene la autorización. Para ejecutar esto, le pasas tu lista de agentes a una instancia de AgentWorkflow. Empiezas el proceso ejecutando el workflow con una query inicial del usuario, apuntando al Investigador para arrancar. El framework del workflow gestiona el state compartido y el routing automáticamente. El Investigador ejecuta sus tools de búsqueda, recopila los datos y decide internamente que su trabajo ha terminado. Luego usa su tool de handoff para pasar el control, junto con los datos recopilados, al Redactor. El Redactor coge ese context, redacta el informe y hace handoff al Revisor. Si el Revisor detecta un fallo, lanza un handoff de vuelta al Redactor con feedback. Este bucle continúa hasta que un agente decide que el trabajo está completo y devuelve una respuesta final al usuario en lugar de lanzar otro handoff. Limitar un agente a un solo rol y definir explícitamente sus rutas de comunicación es la forma más fiable de forzar un razonamiento complejo de múltiples pasos en los modelos de lenguaje. Eso es todo por este episodio. Gracias por escuchar, ¡y sigue construyendo!

Hola, soy Alex de DEV STORIES DOT EU. LlamaIndex: Aplicaciones LLM con contexto aumentado, episodio 9 de 14. Si dejas que los agentes autónomos se pasen el control peer-to-peer, es muy fácil acabar con bucles infinitos o perdiendo el context. A veces no puedes fiarte de que los agentes se pasen el control entre ellos. Necesitas un gestor central al mando de toda la operación. Ese es el patrón Orchestrator Agent. En un sistema multiagente, dejar que los agentes hablen directamente entre ellos suena genial, pero enseguida se convierte en una pesadilla de debugging. Pierdes la pista de quién está al mando, y gestionar el state global de la aplicación se vuelve increíblemente complejo. El patrón Orchestrator resuelve esto forzando estrictamente un modelo hub-and-spoke. Hay un agente orchestrator de nivel superior, y todos los demás agentes se tratan estrictamente como tools para que las use ese orchestrator. Veamos un escenario donde tu sistema necesita generar un informe técnico muy documentado. Configuras un agente orchestrator para que actúe como un gestor estricto. Este gestor es el dueño del state global. Recuerda el prompt original del usuario, mantiene el context maestro y hace un seguimiento de lo que se ha conseguido hasta ahora. No hace el trabajo duro por sí mismo. En su lugar, tú le proporcionas tools. Estas tools no son simples wrappers de API ni calculadoras básicas. Son subagentes totalmente independientes y funcionales. Puedes crear un subagente dedicado a investigar, equipado con vector search y capacidades de web scraping. Puedes crear un segundo subagente dedicado a redactar, equipado con guías de estilo y lógica de formateo. En LlamaIndex, coges estos subagentes y expones sus métodos run como tools. Al hacer esto, estás envolviendo todos sus loops de razonamiento interno detrás de una tool interface estándar con un nombre y una descripción. Para el orchestrator, estos subagentes parecen exactamente funciones estándar de Python. Cuando el usuario pide el informe, el orchestrator evalúa el objetivo general basándose en las descripciones de las tools que le has proporcionado. Decide llamar primero a la tool de investigación y le pasa los parámetros necesarios. El control pasa temporalmente al subagente de investigación. Este subagente ejecuta su propio loop autónomo. Puede hacer tres o cuatro tool calls internas para recopilar datos, sintetizar los hechos y formular una respuesta. Una vez que el agente de investigación termina, colapsa todo ese trabajo en un string de texto final y lo devuelve. Aquí está la clave. El orchestrator en realidad nunca cede el control del proceso principal. Simplemente espera a que la tool devuelva un valor. El orchestrator recibe el resumen de la investigación, lo añade a su propio context y evalúa el siguiente paso. Se da cuenta de que la información tiene que redactarse en un documento, así que llama a la tool de redacción, pasándole la investigación recién hecha como parámetro de input. El subagente de redacción toma el control, hace su propio procesamiento interno y devuelve el texto terminado. El orchestrator ve que se ha cumplido el objetivo final y entrega la respuesta al usuario. Esta estricta separation of concerns hace que tu sistema sea altamente predecible. El agente de investigación no necesita saber que el agente de redacción existe. Ningún subagente tiene que preocuparse de pasar el context, formatear la respuesta final del usuario o decidir cuándo se ha terminado el trabajo global. El orchestrator centraliza toda la lógica de toma de decisiones de alto nivel. Al forzar a los subagentes a operar puramente como tools aisladas dentro del loop de un gestor central, puedes construir sistemas multiagente enormemente capaces que siguen siendo totalmente predecibles y fáciles de debuggear. Eso es todo por este episodio. ¡Nos vemos en la próxima!

Hola, soy Alex de DEV STORIES DOT EU. LlamaIndex: Aplicaciones LLM con Contexto Aumentado, episodio 10 de 14. La orquestación de agentes integrada es genial hasta que tu lógica de negocio empieza a parecer un plato de espaguetis. Cuando los hand-offs estándar no logran capturar tus reglas de scheduling tan específicas, las abstracciones se convierten en un blocker. Ahí es exactamente cuando necesitas Custom Multi-Agent Planners. Un custom planner es tu vía de escape como power-user. Te permite montar tu propio loop de orquestación desde cero usando un Workflow estándar de LlamaIndex. En lugar de depender de un supervisor preconstruido para dictar qué agente actúa después, tú controlas todo el proceso de scheduling de forma imperativa en Python. Tú dictas el orden de ejecución, el routing de datos y la gestión del estado. El proceso suele empezar dentro de una clase custom, a menudo llamada PlannerWorkflow. La primera fase es el planning. Cuando un usuario envía una petición, tu workflow envía un prompt a un modelo de lenguaje grande. Este prompt incluye la query del usuario y una descripción estricta de las tools o agentes que tienes disponibles. Le indicas explícitamente al modelo de lenguaje que genere un plan paso a paso en un formato altamente estructurado. Por ejemplo, puedes decirle al modelo que envuelva cada acción dentro de un bloque XML usando tags step, o que lo formatee como un array JSON. Cuando el modelo responde, tú parseas ese output estructurado. Usas una librería como Pydantic para validar el XML o JSON y convertirlo en una lista concreta de tareas sobre la que tu código puede iterar. Ahora entras en la fase de ejecución. Esta parte depende completamente de tu lógica custom. Tu workflow itera uno a uno por la lista de pasos parseada. Para cada paso, comprueba la acción solicitada. Usas lógica condicional estándar para decidir qué hacer a continuación. Si el paso parseado especifica una tarea de research, tu código llama explícitamente a tu agente de research. Si el siguiente paso requiere un cálculo, activas tu agente matemático. Aquí está la clave. Como estás escribiendo el loop tú mismo, mantienes el control total del estado. Normalmente, creas un diccionario de contexto compartido que vive durante toda la ejecución del workflow. Cuando tu agente de research termina su tarea, tu workflow coge el resultado y lo escribe directamente en ese diccionario. Cuando el siguiente paso activa el agente matemático, tu lógica custom puede pasarle los datos exactos que necesita desde ese diccionario compartido. No estás esperando que un orquestador de caja negra pase las variables correctas. Tú mapeas explícitamente los outputs de un agente a los inputs del siguiente. Una vez que el loop completa todos los pasos de tu plan validado, tu workflow hace cualquier formateo final y devuelve la respuesta. Construir un custom planner significa que cambias la comodidad out-of-the-box por un control total. Si un agente falla, puedes escribir una lógica de retry custom para ese paso específico. Si un paso necesita validación de una API externa, puedes pausar el loop. Estás escribiendo código imperativo estándar que, casualmente, usa modelos de lenguaje como funciones. El valor definitivo de un custom planner es la predictibilidad. Al forzar al modelo de lenguaje a generar un plan XML rígido y ejecutarlo con loops y diccionarios estándar de Python, eliminas por completo las conjeturas de la orquestación de caja negra. Eso es todo por este episodio. ¡Gracias por escuchar, y seguid programando!

Hola, soy Alex de DEV STORIES DOT EU. LlamaIndex: Aplicaciones LLM con Contexto Aumentado, episodio 11 de 14. Creas un agente para gestionar tu infraestructura, y decide que la mejor manera de resolver un error es eliminar una base de datos en producción. Nunca permitas que un agente autónomo realice una acción destructiva sin antes pedirle permiso explícito a un humano. Para evitar esto, necesitas workflows Human-in-the-Loop. Human-in-the-Loop es un mecanismo basado en eventos que pausa un agente, solicita un input externo y reanuda la ejecución basándose en la respuesta. En lugar de dejar que el agente se ejecute sin interrupciones durante su ciclo de pensamiento y acción, interceptas las operaciones de alto riesgo. Esto lo consigues en los Workflows de LlamaIndex usando tres componentes específicos: el InputRequiredEvent, el método wait_for_event y el HumanResponseEvent. Imagina una tool peligrosa diseñada para eliminar un recurso en la nube. El agente decide que necesita usar esta tool y activa el step correspondiente del workflow. Si la tool se ejecuta inmediatamente, el recurso desaparece. En su lugar, el step del workflow intercepta la ejecución. Antes de eliminar nada, el step crea un InputRequiredEvent. Este evento lleva un payload que contiene detalles sobre la acción, como el nombre del recurso de destino y un prompt pidiendo al usuario que confirme la eliminación. El step emite este evento hacia la aplicación principal. Aquí está la clave. El step del workflow no puede quedarse simplemente en un bucle activo esperando una respuesta. Tienes que suspender su estado. Esto lo haces llamando a wait_for_event en el contexto del workflow, especificando que el step ahora está escuchando un HumanResponseEvent. Esta acción devuelve el control al entorno. El motor del workflow pausa el step por completo, congelando al agente en su estado actual sin consumir recursos de computación mientras espera. Fuera del workflow, tu capa de aplicación captura el InputRequiredEvent. Lees el payload y le muestras el prompt de confirmación al usuario en su interfaz de línea de comandos. El humano lee la advertencia y escribe sí o no. Ahora tienes que reanudar al agente. Tu aplicación coge el input del usuario y lo envuelve dentro de un HumanResponseEvent. Envías este nuevo evento directamente de vuelta al motor del workflow en ejecución. El motor reconoce el tipo de evento y lo enruta al step exacto que fue suspendido. El método wait_for_event se resuelve, devolviendo el string de la respuesta humana a la lógica de la tool. La tool evalúa la respuesta. Si el humano escribió sí, la tool procede con la llamada a la API para eliminar el recurso en la nube. Si el humano escribió no, la tool aborta la eliminación. En cualquier caso, la tool devuelve un mensaje de estado final al agente. El agente procesa este resultado, entiende si la acción tuvo éxito o fue bloqueada por el usuario, y decide su próximo movimiento. Al usar eventos para pausar y reanudar la ejecución, tu agente mantiene todo su contexto de razonamiento y memoria mientras espera horas o incluso días a que un humano tome una decisión. Eso es todo por este episodio. Gracias por escuchar, ¡y sigue programando!

Hola, soy Alex de DEV STORIES DOT EU. LlamaIndex: Aplicaciones LLM con Contexto Aumentado, episodio 12 de 14. Cuando un agente autónomo comete un error, bucear entre los print statements estándar de Python para encontrar el problema es una auténtica pesadilla. Haces una pregunta sencilla, obtienes una respuesta alucinada, y el stack trace estándar no te dice absolutamente nada de por qué el modelo mintió. Para solucionarlo, necesitas una forma de ver dentro de la caja negra. Este episodio trata sobre Observabilidad y Tracing. Las herramientas de debugging tradicionales se quedan cortas con los grandes modelos de lenguaje. Un stack trace te indica dónde crasheó el código, pero los bugs de los LLMs suelen ser lógicos. El código se ejecuta perfectamente, pero el sistema recupera el documento equivocado o malinterpreta un prompt. El logging estándar de Python es tu primera línea de defensa. Al configurar el nivel de logging en debug, LlamaIndex genera un feed raw de todo lo que hace. Verás los prompts exactos enviados al modelo de lenguaje y las respuestas HTTP raw. Esto es útil para comprobar si falló una llamada de red, pero para un workflow de agente de varios pasos, leer un muro de texto no estructurado es increíblemente tedioso. Aquí está la clave. No solo necesitas un log de eventos; necesitas ver el call graph. Necesitas una vista estructurada de cómo fluyen los datos desde la query inicial, pasando por los retrievers, hasta el modelo de lenguaje y de vuelta. LlamaIndex gestiona esto mediante un sistema de callbacks. Los callbacks son hooks que se disparan en puntos específicos del ciclo de ejecución. El framework proporciona una herramienta integrada llamada Llama debug handler. Inicializas este handler y lo añades a tu configuración global. A partir de ese momento, registra silenciosamente cada operación. Supongamos que ejecutas un query engine y te devuelve un dato completamente inventado. Sin tracing, no tienes ni idea de si el modelo alucinó o si tu base de datos le pasó mala información. Con el debug handler conectado, puedes pedirle que imprima el trace una vez que termine la query. El trace revela la secuencia exacta de eventos. Ves la query inicial. Ves el paso de retrieval. Y lo que es crucial, ves los nodos de texto exactos que el retriever sacó de tu índice. Inspeccionas esos nodos en el trace y descubres que se recuperó un documento obsoleto. El modelo de lenguaje no alucinó; simplemente leyó datos erróneos. Corriges el índice y el bug queda resuelto. Los traces en la terminal son geniales para el desarrollo local, pero no escalan bien cuando tienes agentes complejos dando docenas de pasos de razonamiento. Para producción, LlamaIndex ofrece lo que llama one-click observability. Configurando una variable de entorno específica o añadiendo una sola línea de configuración, puedes enrutar todos esos datos de los callbacks a una plataforma de observabilidad dedicada. Estas plataformas ingieren los datos del trace y generan dashboards visuales. Puedes navegar haciendo clic por un árbol visual del workflow de tu agente, inspeccionando la latencia exacta, el uso de tokens y el payload de cada paso. No necesitas instrumentar cada función manualmente; los callbacks nativos del framework se encargan del trabajo pesado. La diferencia entre un prototipo frágil y una aplicación de producción fiable es si puedes explicar exactamente por qué el sistema generó una respuesta específica. Si te ha resultado útil y quieres apoyar el programa, puedes buscar DevStoriesEU en Patreon. Eso es todo por este episodio. ¡Gracias por escuchar y sigue construyendo!

Hola, soy Alex de DEV STORIES DOT EU. LlamaIndex: Aplicaciones LLM con Contexto Aumentado, episodio 13 de 14. Cambias tu embedding model y, de repente, tus respuestas te suenan un poco raras, pero no sabes muy bien por qué. Si solo revisas los outputs a simple vista para comprobar la calidad, tu pipeline está dando palos de ciego. Para dejar de guiarte por intuición y prevenir regresiones en producción, necesitas métricas de evaluación RAG. Crear una aplicación RAG es fácil, pero hacerla robusta es difícil. Constantemente tendrás que ajustar el tamaño de los chunks, los prompts y las estrategias de retrieval. Si dependes de la revisión humana para probar cada cambio, ralentizarás el desarrollo o harás deploy de regresiones. Necesitas mediciones automatizadas y objetivas. Como RAG consta de dos pasos distintos, encontrar la información correcta y generar una respuesta basada en ella, debes evaluar ambas etapas por separado. Veamos primero la generación. Esto se llama Response Evaluation. La métrica principal aquí es el faithfulness. El objetivo es detectar alucinaciones. Una respuesta faithful es aquella en la que el modelo de lenguaje se basa completamente en el contexto recuperado, en lugar de inventar hechos a partir de sus propios datos de preentrenamiento. En LlamaIndex, esto lo gestionas con el FaithfulnessEvaluator. Esta herramienta utiliza un modelo de lenguaje por debajo para actuar como juez. Inicializas el evaluador y luego le pasas la query original, el array de nodos de contexto recuperados y el texto final generado. El evaluador devuelve un objeto de evaluación que contiene un boolean binario de pass o fail, indicando si la respuesta está estrictamente respaldada por el contexto proporcionado. También proporciona un string de razonamiento que explica por qué el juez tomó su decisión. Si tu puntuación de faithfulness baja después de una actualización, es posible que tu prompt o tu modelo de lenguaje se estén volviendo demasiado creativos. Ahora bien, la segunda parte de esto. Incluso el mejor modelo de lenguaje no puede generar una respuesta faithful si le pasas los documentos equivocados. Aquí es donde entra en juego el Retrieval Evaluation. La clave está en lo siguiente. Evalúas el retrieval comprobando si el sistema obtuvo los nodos de origen exactos que esperabas para una query dada, ignorando por completo el texto final generado. Esto lo gestionas con el RetrieverEvaluator. Imagina un escenario donde quieres probar un nuevo embedding model. En lugar de hacerle deploy y adivinar si es mejor, creas un dataset de evaluación. Este dataset contiene una lista de queries emparejadas con los identificadores de documentos específicos que contienen las respuestas correctas. Pasas todo tu batch de queries a través del RetrieverEvaluator. El evaluador calcula dos métricas cruciales: Hit Rate y MRR. El Hit Rate es sencillo. Comprueba si el documento esperado apareció en algún lugar de tu top de resultados recuperados. Si recuperas cinco documentos y el correcto está ahí, eso es un hit. Mide el recall puro. Pero la posición importa. Si el documento correcto siempre está en quinto lugar, tu modelo de lenguaje podría ignorarlo debido a los límites de contexto o al attention decay. Aquí es donde entra en juego el Mean Reciprocal Rank, o MRR. El MRR analiza la posición del primer documento relevante. Si el documento correcto está arriba del todo, la puntuación es uno. Si está segundo, la puntuación es un medio. Si es el tercero, un tercio. El evaluador hace la media de estas fracciones en todo tu dataset. Un MRR más alto significa que tu retriever está empujando consistentemente la información más relevante a lo más alto de la context window. Al comparar el Hit Rate y el MRR de tu antiguo embedding model con el nuevo, obtienes una prueba matemática de qué modelo funciona mejor. Puedes hacer un seguimiento de estos números a lo largo del tiempo y ejecutar este pipeline automáticamente en cada pull request. Lo más valioso que puedes hacer por tu pipeline RAG es separar la evaluación de lo que recuperas de cómo generas la respuesta final. Gracias por pasar unos minutos conmigo. Hasta la próxima, cuídate.

Hola, soy Alex de DEV STORIES DOT EU. LlamaIndex: Aplicaciones LLM con Contexto Aumentado, episodio 14 de 14. Deja de copiar y pegar la misma API y el mismo boilerplate de React cada vez que quieras probar una nueva idea de Retrieval-Augmented Generation. Ya entiendes la mecánica del framework, pero configurar una interfaz limpia para usar tus modelos sigue requiriendo horas de trabajo repetitivo. Hoy, veremos las starter tools que te permiten hacer scaffolding a producción en segundos. Crear una aplicación funcional requiere mucho más que un index y un query engine. Necesitas un servidor backend para gestionar las requests entrantes de forma segura. Necesitas rutas de la API para intercambiar mensajes. Necesitas un cliente frontend para mostrar el historial del chat, renderizar los estados de carga y parsear las respuestas. Escribir esta infraestructura desde cero para cada nuevo dataset o prototipo te consume mucho tiempo. Para solucionar esto, LlamaIndex proporciona una utilidad de línea de comandos llamada create-llama. Esta herramienta genera una aplicación web completa, full-stack, preconfigurada con las best practices de LlamaIndex. Abres tu terminal y ejecutas el comando create-llama. Luego, la herramienta te guía a través de una serie de opciones. Te pregunta si quieres un backend en Python usando FastAPI, o un backend en Node usando Express. Te pregunta si quieres un frontend en Next JS para darle a tus usuarios una interfaz web pulida. Después, te pide tu fuente de datos. Puedes apuntar la herramienta directamente a una carpeta local que contenga tus archivos PDF. Una vez que terminas con los prompts, create-llama toma el control. Instala todas las dependencias necesarias. Monta el scaffolding de la estructura de directorios. Escribe el script de ingesta para parsear tus PDFs. Conecta los endpoints de la API para que tu frontend pueda hablar con tu retrieval engine. Finalmente, configura las variables de entorno. Ejecutas un comando start, e inmediatamente tienes una interfaz de chat con estilos corriendo en tu navegador. Puedes escribir una pregunta, y la interfaz hará una petición al backend generado, recuperará el contexto de tus PDFs, y devolverá la respuesta por stream a tu pantalla. Pasas de una carpeta vacía a un prototipo full-stack funcional en unos treinta segundos. Eso cubre las aplicaciones web. Pero a veces, un servidor web y una interfaz gráfica son overkill. Si acabas de descargar una especificación técnica larga y necesitas lanzarle una query inmediatamente sin salir de tu línea de comandos, usas la RAG CLI. La RAG CLI es una herramienta construida puramente para la interacción con documentos basada en terminal. La instalas, y luego ejecutas un comando para apuntarla a tu directorio local de documentos. La CLI ejecuta automáticamente el proceso de ingesta. Divide el texto en chunks, genera embeddings, y los almacena en una vector database local ahí mismo en tu máquina. Cuando termina la ingesta, ejecutas el comando chat. El prompt estándar de tu terminal se transforma en una sesión de chat. Haces una pregunta, la CLI recupera los datos relevantes, hace una query al language model, e imprime la respuesta generada directamente en tu consola. No hay componentes visuales ni rutas web que configurar. Es la forma absolutamente más rápida de hablar con tus datos en local. Aquí está la clave. Ahora entiendes la mecánica profunda de las aplicaciones de contexto aumentado, desde hacer chunking de documentos hasta construir agent routers complejos. Estas herramientas de scaffolding existen para que puedas dejar de pelear con la infraestructura básica y dediques tu tiempo a tunear esas estrategias core de retrieval. Como este es el último episodio de nuestra serie de LlamaIndex, el mejor siguiente paso es ir a la documentación oficial y probar a construir estos pipelines de forma práctica. Si tienes una idea para un tech stack completamente diferente que quieras que cubramos, visita devstories dot eu para sugerir un tema. Eso es todo por este episodio. Gracias por escuchar, ¡y sigue construyendo!