Prompt Flow: The Complete Guide

Hola, soy Alex de DEV STORIES DOT EU. Prompt Flow: La guía completa, episodio 1 de 14. La mayoría de las librerías de IA intentan abstraer la complejidad ocultando tus prompts en lo más profundo de funciones wrapper. Pero cuando pasas a producción, esos prompts son exactamente lo que necesitas controlar. Esta es la filosofía central de Prompt Flow. Primero, aclaremos un malentendido muy común. Prompt Flow no es un framework como LangChain. LangChain es un framework de desarrollo que proporciona chains y agents preconstruidos, que a menudo encapsulan los prompts subyacentes. Prompt Flow es una suite de herramientas diseñada para la experimentación y la evaluación. Existe porque el principio tradicional de encapsulación de la ingeniería de software se convierte en un problema cuando estás construyendo aplicaciones con grandes modelos de lenguaje. En la programación estándar, ocultas la lógica compleja detrás de una interfaz de función limpia. No necesitas saber cómo funciona la función internamente, solo te importa lo que devuelve. Pero los prompts son muy volátiles. No son lógica estática. Si cambias tu modelo de una versión a otra, un prompt que funcionaba perfectamente ayer podría fallar hoy. Si estás usando una librería de terceros opaca para resumir documentos, y el prompt subyacente está bloqueado dentro de esa librería, no puedes arreglar un mal resumen. Dependes por completo de los maintainers de la librería. Prompt Flow le da la vuelta a este patrón de diseño exponiendo los prompts. Los trata como assets de desarrollo de primera clase. Necesitas verlos, ajustarlos y versionarlos continuamente. En lugar de una caja negra, obtienes un toolchain transparente donde controlas el texto exacto y las variables que entran al modelo de lenguaje. Esta es la parte que importa. Como los prompts son volátiles, construir aplicaciones de IA requiere una forma de trabajar fundamentalmente nueva. En el software estándar, escribes unit tests. Haces un assert para comprobar que un input específico produce un output específico. Los modelos de lenguaje son probabilísticos, lo que significa que no proporcionan respuestas deterministas. No puedes escribir un simple assertion para comprobar si un email generado es educado o si un resumen es preciso. En su lugar, debes adoptar un workflow centrado en la evaluación. Tienes que ejecutar tu prompt sobre cientos de ejemplos diferentes y medir métricas como la relevancia o la precisión del formato. Prompt Flow está construido directamente en torno a este workflow. Integra el prompt tuning con la evaluación masiva. Cuando cambias una sola palabra en tu prompt, las herramientas te ayudan a ver estadísticamente si ese cambio mejoró tu tasa de éxito en todo tu dataset o si la empeoró. El último pilar de esta filosofía es optimizar la visibilidad. Las aplicaciones de IA rara vez son una sola llamada a la API. Son grafos de ejecución complejos. Puedes coger una pregunta del usuario, consultar una base de datos vectorial, formatear los datos recuperados, inyectarlos en un prompt y luego llamar al modelo. Cuando la respuesta final es incorrecta, necesitas saber exactamente dónde se rompió la chain. Prompt Flow hace visible este grafo de ejecución. Puedes inspeccionar cada node para ver los inputs y outputs precisos en ese paso exacto del proceso, haciendo que el debugging sea muy sencillo. La conclusión más importante es que los prompts son variables vivas y volátiles que exigen observación constante, no código estático que puedes escribir una vez y esconder. Si estos episodios te resultan útiles 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. Prompt Flow: La guía completa, episodio 2 de 14. Antes de escribir una sola línea de código, tienes que dejar de pensar en las aplicaciones LLM como scripts monolíticos. Si intentas escribirlas de forma lineal, trackear dependencias y hacer debugging del estado en múltiples servicios externos se vuelve inmanejable rápidamente. La solución estructural para esto es ver tu aplicación como un grafo de llamadas a funciones independientes, un concepto conocido en Prompt Flow como flows y la arquitectura DAG. Un flow es simplemente un workflow ejecutable. En esencia, una aplicación LLM es una secuencia orquestada de llamadas externas unidas por lógica. Podrías llamar a un motor de búsqueda, hacer una query a una base de datos, ejecutar un script de Python para formatear los datos recuperados y, finalmente, enviar un prompt a un LLM. Prompt Flow modela esta secuencia como un Directed Acyclic Graph, o DAG. En este grafo, cada paso discreto de tu aplicación es un nodo, y las conexiones entre esos nodos representan el flow de datos. Es dirigido porque los datos avanzan de una función a la siguiente, y es acíclico porque la ruta de los datos no hace un loop sobre sí misma. Imagina una aplicación sencilla que responde preguntas basándose en datos internos de la empresa. El usuario hace una pregunta, que sirve como tu input inicial. Ese input fluye hacia el primer nodo, una función de Python que ejecuta una query a la base de datos. La base de datos devuelve un bloque de texto. Ese texto, junto con la pregunta original del usuario, fluye hacia el siguiente nodo, que hace la llamada real al LLM. El LLM genera una respuesta, que se convierte en el output final de todo el grafo. Al estructurar la app de esta manera, cada función está estrictamente aislada. Sabes exactamente qué entró en la llamada a la base de datos y exactamente qué salió antes incluso de hacer trigger al LLM. Al construir estos workflows, los desarrolladores a menudo se encuentran con dos términos y se preguntan cuál es superior: Flex flow y DAG flow. Aquí es donde la cosa se pone interesante. Ambos consiguen exactamente el mismo resultado. Simplemente ofrecen diferentes experiencias de desarrollo. Flex flow es un enfoque code-first. Encapsulas tu lógica dentro de una función o clase estándar de Python, la designas como el entry point, y escribes código puro. Prompt Flow simplemente lo ejecuta. DAG flow, por otro lado, define el routing usando un archivo YAML. Al listar explícitamente las funciones como nodos y enlazar sus inputs y outputs en YAML, permites que la plataforma renderice una representación visual de tu aplicación. Los DAG flows son muy UI-friendly, lo que hace fácil inspeccionar la arquitectura de un vistazo. Si eliges el enfoque DAG flow, trabajarás con tres tipos específicos de flows. El primero es el Standard flow. Este es tu pipeline de propósito general donde conectas tools, código Python y modelos para construir aplicaciones típicas. El segundo es el Chat flow. Este se basa directamente en el Standard flow, pero está diseñado específicamente para aplicaciones conversacionales. Añade soporte nativo para gestionar el historial de chat y configura los inputs y outputs de chat necesarios automáticamente. El tercer tipo es el Evaluation flow. No usas este flow para servir a los usuarios finales. En su lugar, ejecutas un Evaluation flow contra los outputs de tus Standard o Chat flows. Actúa como un mecanismo de testing para calcular métricas como la precisión factual o la relevancia basándose en los datos que produjo tu flow principal. Tanto si defines tu lógica en Python puro como si la conectas visualmente con YAML, tu aplicación LLM es, en última instancia, solo un pipeline haciendo routing de texto entre sistemas externos. Domina el grafo, y controlarás la aplicación. Eso es todo por este episodio. ¡Gracias por escuchar, y sigue construyendo!

Hola, soy Alex de DEV STORIES DOT EU. Prompt Flow: La guía completa, episodio 3 de 14. Has diseñado el workflow perfecto para tu aplicación de IA, pero un simple plano no procesa datos. Necesitas componentes que realmente ejecuten el trabajo, como hacer fetch de URLs, formatear strings y llamar a APIs. Si los flows son los planos de tu aplicación, las tools son los ladrillos. Hoy vamos a ver las Tools. En Prompt Flow, las tools son los bloques de construcción fundamentales y ejecutables de un flow. Cada nodo de tu grafo es una tool. Cuando tu flow se ejecuta, simplemente pasa datos de una tool a la siguiente. Aunque puedes extender la plataforma, hay tres tools integradas que usarás en casi todos tus proyectos: la Python tool, la Prompt tool y la LLM tool. Veamos un escenario práctico para entender cómo encajan. Quieres una aplicación que haga fetch de una página web, formatee el raw text y genere un resumen. Primero, necesitas obtener el contenido de la página web. Para ello, usas la Python tool. Esta tool te permite escribir scripts de Python personalizados y actúa como tu puente con el mundo exterior. Escribes un pequeño script que recibe una URL como input, hace una petición HTTP y devuelve el raw text de la página. La Python tool se encarga de la ejecución y pasa ese raw text al siguiente paso como output. A continuación, necesitas preparar las instrucciones para el modelo de lenguaje. Usas la Prompt tool. Esta tool recibe inputs de texto, como el raw text de tu Python tool y un system prompt que define la personalidad de la IA, y los formatea en un único string limpio. Esta es la parte importante. La Prompt tool no llama a un modelo de IA. Estrictamente prepara y formatea texto. Separar este paso hace que tu flow sea mucho más fácil de leer y testear, especialmente cuando trabajas con prompts complejos de varias partes. Finalmente, envías ese string preparado al modelo usando la LLM tool. Esta tool gestiona la conexión real con un endpoint de un Large Language Model. Le pasas el string formateado de tu Prompt tool, configuras los parámetros del modelo, como la temperature, y te devuelve el resumen generado. La LLM tool hace el trabajo pesado de formatear el payload de la API e interactuar con el proveedor. Aunque estas tres cubren la mayoría de los casos de uso principales, no son tus únicas opciones. Prompt Flow soporta partner tools proporcionadas por terceros. Un ejemplo común es la tool Vector DB Lookup, que busca texto similar en bases de datos vectoriales basándose en embeddings. También puedes instalar paquetes personalizados o crear tus propias tools para integraciones muy específicas. Independientemente de su origen, todas funcionan exactamente con el mismo principio: reciben inputs, ejecutan una función específica y devuelven un output. Lo más importante que debes recordar es la estricta separación de responsabilidades. No escribas código Python para formatear prompts, y no uses la LLM tool para concatenar strings. Usar la tool integrada adecuada para su propósito exacto mantiene tus grafos limpios y fáciles de depurar. Gracias por estar ahí. Espero que hayas aprendido algo nuevo.

Hola, soy Alex de DEV STORIES DOT EU. Prompt Flow: La guía completa, episodio 4 de 14. Nada arruina un deploy en producción más rápido que una API key commiteada accidentalmente al control de versiones. Incluso si evitas ese desastre, lidiar con credenciales entre entornos de desarrollo local y en la nube suele acabar en archivos de configuración caóticos y riesgos de seguridad. Gestionar secretos con conexiones resuelve esto aislando completamente tus datos sensibles de la lógica de tu flow. Una conexión en Prompt Flow es un recurso dedicado que almacena los endpoints y las credenciales necesarias para interactuar con servicios externos. Si tu flow necesita llamar a un modelo de lenguaje externo, buscar en la web usando un servicio externo o consultar una base de datos remota, necesita autorización. En lugar de escribir las API keys directamente en tus scripts de Python o archivos de configuración, creas una conexión. Tu flow entonces hace referencia a esa conexión por su nombre. Al usar conexiones, desacoplas tus datos secretos de tu lógica de ejecución. Tu código solo sabe que necesita una conexión llamada, por ejemplo, main_language_model. No conoce la API key real. Veamos cómo funciona esto al pasar un proyecto de tu portátil a la nube. Cuando desarrollas en local, tus conexiones se almacenan en tu disco local. Para mantener la seguridad, Prompt Flow cifra los valores secretos usando una encryption key local. Puedes hacer la build y probar tu flow usando este setup local sin dejar keys en texto plano expuestas en tu directorio de trabajo. Cuando estés listo para hacer el deploy de este flow en Azure AI, el entorno cambia, pero tu código no. En Azure AI, las conexiones están respaldadas de forma segura por Azure Key Vault. Los secretos se almacenan y gestionan dentro de la infraestructura de Key Vault, protegidos por estrictas políticas de acceso. Esta es la parte que importa. Como tu flow solo hace referencia a la conexión por su nombre, la transición de un entorno local a la nube requiere cero cambios en la lógica de tu flow. Simplemente te aseguras de que exista una conexión con el mismo nombre en tu workspace de Azure. Cuando el flow se ejecuta en la nube, pide main_language_model. El sistema intercepta esa petición de forma transparente y proporciona las credenciales respaldadas por Key Vault en lugar de las cifradas en local. Tu código se mantiene limpio y agnóstico al entorno. Prompt Flow clasifica estas conexiones en dos tipos principales. El primero son las conexiones fuertemente tipadas. Son templates integrados para servicios muy utilizados como Azure OpenAI. Proporcionan campos predefinidos para la URL del endpoint, la API key y el tipo de API. El sistema sabe exactamente cómo manejar estos campos, lo que mantiene sencilla la configuración estándar de la tool. El segundo tipo es la conexión custom. Cuando necesitas integrar una API interna de la empresa o un servicio de terceros que no tiene un template integrado, usas una conexión custom. Esta actúa como un diccionario flexible donde defines tus propios pares key-value. Puedes marcar explícitamente keys específicas como secretos. Una vez marcados, esos secretos custom reciben exactamente el mismo cifrado local y protección de Key Vault que las conexiones integradas. El valor definitivo de las conexiones es que actúan como una capa de abstracción estricta para la autenticación, asegurando que tu flow se mantenga completamente portable y tus secretos permanezcan seguros en cualquier entorno de ejecución. Eso es todo por este episodio. Gracias por escuchar, ¡y sigue construyendo!

Hola, soy Alex de DEV STORIES DOT EU. Prompt Flow: La guía completa, episodio 5 de 14. Deja de enterrar los prompts de tu modelo de lenguaje dentro de enormes strings de Python. Cuando haces hardcode de los prompts en la lógica de tu aplicación, el seguimiento de cambios, la ejecución de tests independientes y la colaboración con los prompt engineers se convierten en una auténtica pesadilla. La solución es la especificación Prompty. Un Prompty es un formato estándar para gestionar prompts. Saca tu prompt de tu código y lo pasa a un único archivo markdown con control de versiones y extensión punto prompty. El archivo se divide en dos secciones distintas. En la parte superior, tienes el front matter de YAML. En la parte inferior, tienes un prompt template con formato Jinja. Tres guiones separan ambas secciones. El bloque YAML actúa como centro de control. Puedes definir metadatos básicos como el nombre, la descripción y el autor. Y lo que es más importante, contiene la configuración del modelo. Especificas el tipo de API, como chat o completion. Defines los detalles de configuración, como apuntar a un deployment de Azure OpenAI de GPT-3.5. También fijas los parámetros del modelo justo aquí. Si un prompt específico requiere una temperatura de cero coma siete y un límite de max tokens de mil, lo declaras en el YAML. Esto vincula los ajustes de ejecución directamente al texto del prompt, asegurando que el prompt se comporte de forma consistente sin importar dónde se utilice. La sección YAML también define los inputs y los datos de ejemplo. Si tu prompt espera una variable dinámica, la listas aquí y proporcionas valores de ejemplo. Esto hace que el archivo sea completamente autocontenido. Cualquiera que lo abra sabe exactamente qué datos espera sin tener que hacer ingeniería inversa del código de tu aplicación. Debajo del YAML y los tres guiones se encuentra el prompt template real. Esta sección utiliza la sintaxis Jinja2 para inyectar dinámicamente los inputs que definiste arriba. Como los modelos de lenguaje modernos usan interfaces de chat, el template soporta la asignación de roles. Defines los roles usando un formato de texto simple, separando las instrucciones del sistema de los inputs del usuario. Considera un escenario de chat mínimo donde quieres un prompt que salude a un usuario por su nombre. En la parte superior de tu archivo punto prompty, escribes el front matter de YAML. Defines la sección de tu modelo, ajustando el tipo de API a chat y apuntando la configuración a un deployment de GPT-3.5. Luego, añades una sección de inputs declarando una variable llamada first name. También añades un bloque de ejemplo donde first name se define como Jane. Escribes tres guiones para terminar el front matter de YAML. Ahora construyes el template. Escribes la palabra system seguida de dos puntos, y luego le das al modelo sus instrucciones base, como decirle que sea un asistente útil. Debajo de eso, escribes la palabra user seguida de dos puntos. Finalmente, escribes el saludo, encerrando la variable first name entre llaves dobles para que el motor Jinja sepa dónde inyectar el texto. Ahora tienes un recurso completo y reutilizable. Tratar los prompts como archivos autocontenidos en lugar de strings sueltos en tu código es el primer paso hacia un prompt engineering riguroso, porque fuerza un contrato claro entre la aplicación que proporciona los datos y el modelo de lenguaje que genera la respuesta. Gracias por dedicarme unos minutos. Hasta la próxima, cuídate.

Hola, soy Alex de DEV STORIES DOT EU. Prompt Flow: La guía completa, episodio 6 de 14. Creas una plantilla de prompt cuidadosamente optimizada para producción, pero cuando quieres probarla con un modelo más económico o ajustar la temperatura para un edge case específico, te encuentras editando manualmente el archivo fuente. Una plantilla estática genera fricción cuando tu entorno o tu lógica necesitan cambiar sobre la marcha. Esa fricción es precisamente lo que la ejecución dinámica de Prompty está diseñada para eliminar. Un asset Prompty normalmente define la configuración del modelo, como el nombre del deployment, la conexión a la API y los parámetros, dentro de su bloque de header. Sin embargo, hardcodear estos valores limita cómo puedes usar el archivo en diferentes entornos. La ejecución dinámica te permite tratar el archivo Prompty como una capa base flexible, sobrescribiendo sus configuraciones directamente en Python o mediante la línea de comandos en runtime. Para ejecutar un archivo Prompty en Python, usas la función load prompty de la librería core de Prompt Flow. Le pasas la ruta del archivo a esta función y te devuelve un objeto callable en memoria. Para ejecutarlo, simplemente llamas a ese objeto, pasando las variables de tu prompt como keyword arguments estándar. La librería se encarga de la compilación y la llamada a la API, devolviendo el output de texto final. Aquí es donde la ejecución dinámica demuestra su valía. Puedes interceptar la ejecución para hacer un override de la configuración del modelo sin tocar el archivo subyacente. Supongamos que tienes un Prompty configurado para un deployment estándar de Azure OpenAI, pero para un batch job específico, necesitas apuntarlo a un endpoint de Azure diferente y subir la temperatura para obtener respuestas más variadas. En lugar de duplicar el archivo, defines un diccionario en tu código Python con tu nueva configuración. Añades tu endpoint alternativo y tu nuevo valor de temperatura a este diccionario. Luego, cuando llamas a tu objeto Prompty cargado, pasas este diccionario al keyword argument model, junto con los inputs estándar de tu prompt. El runtime de Prompt Flow fusiona tu diccionario con la configuración del archivo base. Tus overrides dinámicos tienen prioridad, el prompt se ejecuta con la nueva configuración y el archivo original permanece completamente inalterado. Esto te permite intercambiar API keys, cambiar los max tokens o redirigir el target del modelo programáticamente según el estado de tu aplicación. A veces, no quieres escribir un script de Python solo para comprobar si un prompt produce un buen resultado. Para una validación rápida, puedes probar un archivo Prompty directamente desde tu terminal. Usas el comando pf flow test, indicando la ruta a tu archivo con la flag source. Puedes añadir la flag inputs para pasar tus variables directamente al comando como pares key-value. La interfaz de línea de comandos ejecuta el Prompty e imprime la respuesta del modelo directamente en el standard output. Esto te proporciona un feedback loop inmediato durante el desarrollo sin necesidad de escribir código wrapper. El verdadero valor de un asset Prompty no reside en bloquear las configuraciones, sino en aislar el texto del prompt del entorno de ejecución. Al inyectar overrides del modelo dinámicamente en runtime, un solo archivo puede servir sin problemas a tu sandbox de testing local, tus pipelines automatizados y tus endpoints de producción. Eso es todo por este episodio. Gracias por escuchar, ¡y sigue programando!

Hola, soy Alex de DEV STORIES DOT EU. Prompt Flow: La guía completa, episodio 7 de 14. Quizás pienses que usar un framework especializado para Large Language Models implica aprender una interfaz visual compleja o mantener archivos de configuración enormes. Pero si ya sabes escribir un script de Python, ya tienes los conocimientos suficientes para crear una aplicación totalmente trackable. Los Flex Flows basados en funciones resuelven esta tensión por completo. En el desarrollo estándar de Prompt Flow, creas un Directed Acyclic Graph. Esa estructura es muy eficaz para pipelines estrictos de varios pasos, pero a veces los desarrolladores quieren escribir código puro de Python sin adaptarse a un sistema visual de nodos. Los Flex Flows te permiten hacer exactamente eso. Encapsulas la lógica de tu aplicación LLM dentro de funciones estándar de Python, y la plataforma se encarga del tracking y la orquestación en segundo plano. Piensa en el enfoque basado en funciones. Empiezas escribiendo una función normal de Python. Le das un nombre descriptivo, como chat, y defines sus inputs, como recibir una pregunta como parámetro string. Dentro de esta función, escribes tu lógica justo como lo harías normalmente. Podrías cargar un archivo Prompty para obtener tu system message, inicializar el cliente de tu modelo de lenguaje, pasarle la pregunta al modelo y, después, devolver la respuesta de texto como un string. En esta etapa, simplemente tienes un script estándar de Python. Se ejecuta localmente, es fácil de probar y no requiere conocimientos especiales de ningún framework. Para convertir este script puro de Python en un componente trackable de Prompt Flow, importas el decorator trace del package de tracing de promptflow. Colocas este decorator justo encima de tu función chat. Al ejecutar tu código, este decorator le indica al sistema que monitorice la ejecución de forma silenciosa. Registra automáticamente los inputs pasados a la función, el output de texto devuelto, el tiempo exacto de ejecución y cualquier error interno. Si aplicas el decorator trace a otras funciones auxiliares dentro de tu script, el sistema construye un call tree completo. Obtienes la observabilidad completa de un flujo visual, incluyendo la posibilidad de ver el trace de ejecución en la interfaz de usuario local, sin cambiar cómo estructuras tu lógica. Ahora, las herramientas necesitan una forma de saber que esta función específica es el entry point de tu aplicación. Esto lo consigues creando un único archivo de configuración muy corto llamado flow.flex.yaml en el mismo directorio que tu código. Este archivo no define un routing graph complejo. Solo necesita una información fundamental, que es el entry mapping. Escribes la palabra entry seguida del nombre de tu module de Python, dos puntos, y el nombre de tu función. Si tu archivo se llama app.py y tu función es chat, tu valor de entry es simplemente app dos puntos chat. Cuando pruebas o ejecutas este flujo usando la herramienta de command line de Prompt Flow o la extensión de VS Code, el sistema lee ese archivo yaml. Busca la función chat en tu module app, inyecta los inputs proporcionados, ejecuta tu código puro de Python y recopila los traces generados por el decorator. La verdadera potencia de los Flex Flows basados en funciones es que eliminan la fricción entre prototipar un script y hacer el deploy de una aplicación en producción; tu lógica pura de Python permanece completamente bajo tu control, mientras que un único decorator y un archivo de configuración de dos líneas desbloquean una observabilidad de nivel empresarial. Eso es todo por este episodio. Gracias por escuchar, ¡y sigue construyendo!

Hola, soy Alex de DEV STORIES DOT EU. Prompt Flow: La guía completa, episodio 8 de 14. Haces deploy de una nueva app de language model, pero cada vez que un usuario envía un mensaje, tarda unos segundos preciosos solo en establecer la conexión con la base de datos y cargar las credenciales del client. Cuando tu app necesita mantener una conexión persistente o recordar el historial de la conversación, un standalone script falla porque empieza completamente desde cero en cada run. La respuesta a este problema son los Flex Flows: desarrollo basado en clases. Cuando creas apps que escalan, el state management se convierte en una preocupación principal. Si tu flow depende de un recurso externo, como un client de Azure OpenAI, inicializar ese client requiere leer secretos, verificar endpoints y asignar memoria. Si metes esa lógica dentro de una secuencia de ejecución básica, pagas ese enorme coste de startup cada vez que entra una request. Usar una clase de Python como entry point para tu Flex Flow te permite separar fundamentalmente tu lógica de inicialización de tu lógica de ejecución. Un flow basado en clases depende de dos métodos estándar de Python para gestionar este lifecycle. El primero es el constructor, o el método init. Esta es tu fase de setup. Prompt Flow ejecuta este método exactamente una vez cuando el flow se carga por primera vez en memoria. Aquí es donde haces todo el trabajo pesado. El segundo método es el método call. Esta es tu fase de ejecución, y se ejecuta cada vez que el flow es activado por una request del usuario. Imagínate una clase de chat flow. Defines tu método init para que acepte un objeto de conexión de Azure OpenAI y un string de system prompt. Dentro del método init, creas tu client de Azure OpenAI y lo guardas como una propiedad en la propia instancia de la clase. El client ya está listo y esperando. A continuación, defines tu método call. Este método acepta una nueva pregunta del usuario y una lista de mensajes pasados que representan el historial del chat. Como el client ya está completamente inicializado, el método call formatea inmediatamente el prompt, envía el historial del chat al language model y devuelve la respuesta. La ejecución es rápida porque el costoso setup del client se omitió por completo. Para que esto funcione, Prompt Flow necesita saber cómo instanciar tu clase. Configuras esto creando un archivo YAML para tu flow. El entry point en este archivo de configuración usa un formato específico, nombrando el módulo de Python seguido de dos puntos y el nombre de tu clase. Esta es la parte que importa. Tu configuración YAML no solo apunta a la clase, sino que define los parámetros que requiere tu método init. Si el constructor de tu clase requiere una conexión de Azure y un nombre de modelo, declaras esos inputs en el archivo YAML bajo una sección init dedicada. Cuando el motor de Prompt Flow arranca, lee el YAML, inyecta esos parámetros configurados en el constructor de tu clase, y luego mantiene ese objeto instanciado vivo en memoria para gestionar las calls entrantes. Testear un flow basado en clases localmente es increíblemente sencillo porque se basa en el comportamiento estándar de Python. No necesitas un test harness complejo. Simplemente escribes un script estándar de Python, importas tu clase, creas una instancia pasándole mock connections o credenciales locales al constructor, y luego invocas el objeto directamente pasándole un mensaje de prueba. Puedes depurar la lógica de setup y la lógica de ejecución de forma independiente. La conclusión principal es que los flows basados en clases te dan la estructura arquitectónica para separar el trabajo pesado de la inicialización del trabajo repetitivo de la ejecución, manteniendo tu estado persistente y tus respuestas rápidas. Si estos episodios te resultan útiles 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. Prompt Flow: La guía completa, episodio 9 de 14. A veces, mirar un muro de código no basta para entender una aplicación compleja. Cuando los prompts, los scripts y las llamadas a la API interactúan de docenas de maneras, necesitas ver físicamente los datos moviéndose entre ellos para detectar los cuellos de botella. Los DAG flows son la respuesta para los equipos que buscan una claridad arquitectónica explícita. DAG significa Grafo Acíclico Dirigido. En Prompt Flow, un DAG flow es un método para construir aplicaciones de IA enlazando diferentes tools como nodos. En lugar de escribir un único script enorme, defines la estructura de tu aplicación en un archivo llamado flow punto dag punto yaml. Este archivo actúa como el plano maestro. Declara los inputs iniciales, los pasos individuales y los outputs finales de tu aplicación. Cada paso en un DAG flow se llama nodo. Un nodo representa una tool específica que realiza una única tarea. Podrías tener un nodo que ejecuta un snippet de Python, otro nodo que formatea un prompt, y un tercer nodo que llama a un Large Language Model. El archivo YAML describe cómo se relacionan estos nodos entre sí mediante dependencias de input y output. Este mapeo de dependencias es lo que hace que el flow funcione. No le dices manualmente al sistema en qué orden ejecutar los pasos. En su lugar, especificas que el nodo B requiere el output del nodo A. Como el nodo B no puede empezar hasta que el nodo A termina, se forma un orden de ejecución de manera natural. Si añades un nodo C que solo depende del input inicial del usuario, Prompt Flow reconocerá que no necesita esperar al nodo A o B. Ejecutará el nodo C en paralelo automáticamente. El motor lee el archivo YAML, resuelve el grafo y se encarga de la orquestación. Escribir y mantener este archivo YAML a mano puede volverse difícil a medida que tu aplicación crece. Por eso, la mayoría de los desarrolladores usan la extensión de Prompt flow para VS Code. Esta extensión lee tu archivo flow punto dag punto yaml y renderiza una interfaz de usuario visual de arrastrar y soltar. Puedes ver tu aplicación como un mapa literal de bloques conectados. Considera un escenario concreto. Estás construyendo una aplicación para leer informes financieros y escribir resúmenes ejecutivos cortos. En el editor visual, creas un nodo de tool de Python y lo llamas Extract Text. Al lado, añades un nodo de tool de LLM llamado Summarize. En lugar de escribir código para gestionar el estado entre estas dos operaciones, usas la interfaz. Haces clic en el puerto de output del nodo Extract Text y arrastras una línea hasta el puerto de input del nodo Summarize. Acabas de conectar visualmente la ruta de los datos. La extensión actualiza al instante el archivo YAML subyacente para registrar esa conexión. Obtienes la velocidad y claridad de un builder visual low-code, pero sigues generando un archivo de configuración en texto plano que puedes rastrear en el control de versiones. Este enfoque visual fuerza la disciplina arquitectónica. El grafo es acíclico, lo que significa que los datos solo pueden fluir hacia adelante. No hay bucles infinitos. Los datos entran, pasan por tu secuencia de tools, y salen. Este flow direccional estricto hace que el debugging sea muy sencillo. Si un resumen final se ve mal, puedes abrir el grafo visual, hacer clic en la conexión entre los nodos de extracción y resumen, e inspeccionar el string de texto exacto que se pasó por ese cable. Sabes exactamente de dónde vinieron los datos y a dónde fueron. La verdadera ventaja de un DAG flow es que el diagrama de arquitectura de tu sistema y tu aplicación ejecutable son exactamente lo mismo. Eso es todo por este episodio. ¡Gracias por escuchar, y sigue programando!

Hola, soy Alex de DEV STORIES DOT EU. Prompt Flow: La guía completa, episodio 10 de 14. Cuando un modelo de lenguaje devuelve una respuesta basura alucinada, ¿cómo sabes si el modelo en sí falló, o si la lógica de formateo de tu prompt tenía un bug? Puedes esparcir print statements por toda tu aplicación, pero eso se vuelve imposible de mantener a medida que tu aplicación crece. Hacer tracing de las interacciones con el LLM soluciona esto capturando el contexto exacto de cada ejecución. El tracing convierte una aplicación LLM de caja negra en una secuencia de eventos transparente que puedes debuggear. Registra con precisión qué datos entran en una función, qué datos salen y cuánto tiempo tarda la ejecución. En este ecosistema, esto lo gestionas con el paquete promptflow-tracing. Los datos que genera se basan en la especificación OpenTelemetry, lo que significa que tus registros de ejecución siguen un formato estándar de la industria para la observabilidad. Para capturar las interacciones base con un modelo, usas una función llamada start trace. Si llamas a esta función justo al principio de tu script de Python, Prompt Flow instrumenta automáticamente los clientes de modelos compatibles. Por ejemplo, si estás usando el paquete estándar de Python de OpenAI, no necesitas modificar tus API calls en absoluto. El tracer intercepta la interacción de forma silenciosa, registrando el system message, el user prompt, los parámetros específicos del modelo y el string de respuesta final. Capturar la API call es solo la mitad de la batalla. La lógica previa a esa llamada suele ser donde se esconden los bugs. Para hacer tracing de la lógica de tu propia aplicación, aplicas el decorador trace a tus funciones personalizadas. Considera una función llamada math to code. Esta función recibe a un usuario que describe un problema matemático, obtiene el contexto necesario, construye un prompt y, finalmente, pide código Python a GPT-4. Al colocar el decorador trace justo encima de la definición de la función math to code, le dices a Prompt Flow que registre cada ejecución de este bloque de lógica específico. Registrará el string de input del usuario, el código final devuelto y la latencia de toda la operación. Como también ejecutaste start trace al principio de tu archivo, el sistema entiende la relación entre tu código y la llamada al modelo. Construye un registro jerárquico. Tu función math to code se convierte en el parent span, y la llamada interna a OpenAI se convierte en un child span anidado dentro de él. Puedes ver esta jerarquía usando la Trace UI local. Cuando ejecutas un script con tracing, Prompt Flow inicia un servidor local que puedes abrir en tu navegador web. Esta interfaz te proporciona una línea de tiempo visual del flujo de tu aplicación. Puedes seleccionar el parent span de math to code para verificar los argumentos que recibió. Luego, puedes seleccionar el child span de OpenAI para inspeccionar el string exacto del raw prompt que se envió correctamente al modelo a través de la red. Si a la lógica de ensamblaje de tu contexto le faltó una variable, verás el espacio vacío en el raw prompt inmediatamente. El verdadero poder del tracing no es solo recopilar logs de ejecución, sino demostrar de forma concluyente qué pasó exactamente en el límite entre el código de tu aplicación y el modelo externo. Eso es todo por ahora. ¡Gracias por escuchar y sigue desarrollando!

Hola, soy Alex de DEV STORIES DOT EU. Prompt Flow: La guía completa, episodio 11 de 14. Has dedicado tres meses a desarrollar una aplicación compleja con LangChain. La lógica funciona en su mayor parte, pero cuando un agente entra de vez en cuando en un bucle infinito o pierde el contexto, averiguar exactamente dónde falló es una pesadilla, y reescribir todo solo para tener mejores logs está totalmente descartado. El tracing avanzado para LangChain y AutoGen es cómo solucionas esto directamente. Cuando desarrollas con frameworks de orquestación, ganas velocidad gracias a la abstracción. El framework oculta los detalles engorrosos de la secuenciación de prompts, la ejecución de tools y el parsing. Pero la abstracción crea por naturaleza una caja negra. Cuando tu agente devuelve una respuesta confusa, necesitas ver su chain of thought interno. Necesitas saber el sub-prompt exacto que generó, la respuesta raw de la API que recibió y qué tool call específico falló. Prompt Flow incluye una capacidad de tracing independiente diseñada exactamente para esto. No te obliga a usar Prompt Flow para tu lógica o ejecución. Mantienes tu código existente de LangChain o AutoGen exactamente como está. Simplemente le añades el sistema de tracking de Prompt Flow a tu aplicación externa. Piensa en tu script de Python actual ejecutando un agente de LangChain. Para tener visibilidad total, no tocas las definiciones de tus chains. Solo tienes que ir al principio de tu archivo de ejecución principal. Importas la función de configuración del trace desde el módulo de Prompt Flow, y la llamas una vez antes de que tu agente empiece a hacer su trabajo. Ese único comando es toda la integración. Cuando llamas a esa función, instrumenta tu entorno. Como el tracing de Prompt Flow está basado en los estándares de OpenTelemetry, sabe cómo escuchar los eventos específicos que disparan estos populares frameworks. Mientras se ejecuta tu aplicación de LangChain, la instrumentación intercepta automáticamente las llamadas a la API subyacentes. Captura los inputs, la duración de la ejecución, los outputs y el uso de tokens para cada paso. Esto también se aplica perfectamente a AutoGen. Los setups multiagente en AutoGen son notoriamente difíciles de debuggear porque múltiples agentes se envían mensajes de un lado a otro de forma autónoma. Hacer el tracking de quién le pasó qué contexto a quién normalmente significa escarbar entre enormes muros de texto en la terminal. Al inicializar el trace al principio de tu script de AutoGen, cada intercambio de mensajes se captura y estructura automáticamente. Una vez que tu script termina de ejecutarse, abres la Trace UI local de Prompt Flow. En lugar de hacer scroll por los print statements de la consola, obtienes un timeline visual. Ves un árbol de ejecución claro. Haces clic en el run del agente de nivel superior, expandes el nodo y ves la secuencia de llamadas LLM anidadas y ejecuciones de tools. Si un agente alucinó en el paso cuatro, puedes hacer clic directamente en el paso cuatro para leer el texto exacto y sin formato que se envió al modelo. Obtienes visibilidad completa de un framework opaco sin tener que migrar ni una sola línea de tu lógica de negocio real. La verdadera ventaja aquí es la libertad arquitectónica; puedes orquestar tu aplicación utilizando el framework que mejor se adapte a tu equipo, manteniendo tu debugging y observabilidad centralizados en una interfaz visual y limpia. Como siempre, gracias por escuchar. Nos vemos en el próximo episodio.

Hola, soy Alex de DEV STORIES DOT EU. Prompt Flow: La guía completa, episodio 12 de 14. Tu prompt funcionó perfectamente con tu pregunta de prueba, pero ¿qué pasa cuando lo ejecutas contra diez mil consultas de usuarios reales? Normalmente falla. Probar un prompt manualmente con dos ejemplos es fácil, pero demostrar que funciona en cientos de edge cases requiere algo más robusto. Ahí es donde entra Scaling Up: Batch Runs with Data. Un batch run coge tu flow individual y lo ejecuta sobre un dataset grande. Esto te hace pasar de construir la lógica a verificarla a gran escala. En lugar de escribir inputs en una user interface, lanzas este proceso usando la command line interface. El comando principal es pf run create. Al ejecutar esto, le estás indicando a Prompt Flow que levante una nueva run instance, lea un flow directory específico y le pase un archivo que contiene todos tus registros de prueba. El motor procesa estos registros ejecutando todo tu flow graph de forma independiente para cada línea de tu dataset. El formato de datos requerido para este archivo de input es JSONL. JSONL significa JSON Lines. Si estás acostumbrado al JSON estándar, puede que esperes un único array grande envolviendo todos tus objetos. JSONL elimina el array. Cada línea del archivo de texto es su propio objeto JSON válido e independiente, que representa exactamente un caso de prueba. Este formato es muy popular en machine learning y data pipelines porque es ligero y se hace stream fácilmente. El motor puede leerlo línea a línea sin cargar un archivo enorme en memoria de golpe. Considera un flow de web-classification. Tu flow está diseñado para coger una dirección web, hacer scrape del contenido y usar un language model para categorizarlo. El flow graph espera un input string específico llamado url. Quieres probar esta lógica contra cien sitios web diferentes para ver cómo maneja los edge cases. Construyes tu archivo JSONL. Cada línea contiene un objeto JSON con una key, quizá llamada web link, que contiene la dirección de destino. Para iniciar el batch run, escribes pf run create. Especificas tu flow directory usando la flag flow, y apuntas a tu archivo JSONL usando la flag data. Pero hay un desajuste estructural inmediato. La lógica de tu flow requiere estrictamente un input llamado url, mientras que tu archivo de data proporciona un campo llamado web link. Si ejecutas el comando ahora mismo, fallará. El motor no adivina qué campos de data pertenecen a qué inputs del flow. Salvas esta distancia usando la flag de column mapping. Esta flag le dice al execution engine exactamente cómo conectar las keys de tu archivo JSONL a los input nodes específicos de tu flow. En tus command line arguments, escribes el nombre del input del flow, un signo igual, y luego una referencia a la columna de data. Prompt Flow usa una binding syntax específica para estas referencias. Escribes un signo de dólar, seguido de la palabra data, un punto, y luego el nombre de la columna de tu archivo. Para el escenario de web-classification, lo mapeas escribiendo url igual a signo de dólar data punto web link. Esta instrucción explícita vincula el campo de data al requisito del flow. El motor ahora extraerá el string de web link de la línea uno de tu archivo JSONL y lo inyectará en el input url de tu flow. Luego repite ese proceso exacto para la línea dos, la línea tres, y así sucesivamente hasta que se procesa todo el archivo. Puedes mapear múltiples inputs de esta manera. Si tu flow espera una url y un user id, simplemente añades otra instrucción de mapping al mismo comando. Desacoplar tu test data de los inputs de tu flow usando column mapping explícito significa que nunca tienes que alterar tu código principal solo para ejecutar un nuevo dataset. Gracias por pasar unos minutos conmigo. Hasta la próxima, cuídate.

Hola, soy Alex de DEV STORIES DOT EU. Prompt Flow: La guía completa, episodio 13 de 14. No puedes escribir un unit test estándar que compruebe que la respuesta de un Large Language Model es un string exacto. Si el output cambia cada vez, ¿cómo demuestras matemáticamente que tu aplicación funciona de verdad antes de hacer el deploy? La respuesta es el paradigma de evaluación. En la ingeniería de software tradicional, el unit testing es determinista. Le pasas un input específico a una función y esperas un output exacto. Los Large Language Models son estocásticos. Son inherentemente impredecibles. Pídele a un modelo que clasifique una página web, y puede que te devuelva la palabra deportes, o que te diga que la categoría es deportes, o que simplemente te dé un emoji relacionado. Un assert de un test estándar fallará en dos de esos tres casos, aunque en el fondo el modelo haya acertado la respuesta. Para demostrar que estás listo para una release, tienes que ir más allá de los unit tests y adoptar la evaluación estadística. En Prompt Flow, esto se gestiona mediante un Evaluation Flow. Un Evaluation Flow es solo un flow normal, pero en lugar de generar texto para un usuario final, su único trabajo es evaluar el output de otro flow. Coge las predicciones que generó tu aplicación principal, las compara con un conjunto conocido de respuestas correctas y devuelve métricas calculadas. Vamos a hacerlo más concreto. Imagina que acabas de terminar un batch run de un flow de clasificación web. Ha procesado cien direcciones web y ha devuelto una categoría predicha para cada una. Ahora necesitas saber exactamente cómo de precisas son esas predicciones. Coges los outputs de ese base run y los pasas a un nuevo Evaluation Flow dedicado, diseñado para calcular la precisión de la clasificación. Lanzas esto desde la línea de comandos usando el comando run create. Especificas tu Evaluation Flow, pero en lugar de darle simplemente un archivo estático con nuevos inputs, le pasas una referencia a tu batch run anterior. El Evaluation Flow necesita dos datos para hacer su trabajo. Necesita la predicción del modelo, y necesita el ground truth, que es la respuesta históricamente correcta. Tú proporcionas un data mapping que conecta estos puntos. Le dices al sistema que mapee el input de predicción del Evaluation Flow al output de categoría de tu base run. Luego, mapeas el input del ground truth a la columna de la etiqueta real ubicada en tu dataset de test original. Esta es la parte que importa. El Evaluation Flow se ejecuta fila por fila, recorriendo todo el historial del run anterior. Para cada fila, mira lo que predijo tu flow principal y lo compara con el ground truth. Asigna un score para esa interacción específica. En nuestro escenario de clasificación, eso podría ser un simple uno para un acierto y un cero para un fallo. Otros Evaluation Flows podrían usar un modelo de lenguaje para juzgar la calidad de un resumen en una escala del uno al cinco. Una vez que el flow termina de evaluar cada fila, agrega esos scores individuales en una métrica final general. No obtienes simplemente un log masivo de unos y ceros. Obtienes un número definitivo de alto nivel, como una precisión general del noventa y dos por ciento. Luego puedes ver estas métricas agregadas para decidir si la versión actual de tu aplicación está lista para producción. Ya no tienes que adivinar si un ajuste en el prompt mejoró tu sistema; tienes pruebas estadísticas de exactamente cuánto mejor o peor funciona en todo tu dataset. Gracias por escucharnos. ¡Hasta la próxima!

Hola, soy Alex de DEV STORIES DOT EU. Prompt Flow: La guía completa, episodio 14 de 14. Has creado, traceado y evaluado tu flow de modelo de lenguaje, y funciona a la perfección. Pero ahora mismo, está en tu entorno de desarrollo, completamente aislado de tus usuarios reales. Sacarlo de tu IDE y convertirlo en un servicio estable y accesible es precisamente lo que veremos hoy al llevar los flows a producción. En reposo, un prompt flow es simplemente una carpeta. Contiene un archivo YAML de configuración y tus scripts de Python o plantillas de Jinja. Para que esa carpeta haga algo en el mundo real, necesitas un entorno de ejecución que cargue esos archivos y escuche las requests HTTP entrantes. Durante el desarrollo, probablemente usaste el servidor local integrado. Ejecutas un comando simple y levanta un endpoint local para probar los inputs y outputs. Esto está bien para verificar la lógica, pero no está diseñado para manejar tráfico concurrente en producción, gestionar la memoria de manera eficiente ni sobrevivir a una caída del sistema. Para llegar a producción, necesitas contenerización. Prompt Flow está diseñado para integrarse directamente con Docker. En lugar de escribir tu propio servidor web desde cero, utilizas las herramientas de Prompt Flow para exportar tu flow como un contenedor de Docker. Al ejecutar el proceso de exportación, el sistema genera un Dockerfile. Este archivo define una imagen base, copia el directorio de tu flow en ella, instala las dependencias de Python exactas que se especifican en tu archivo de requirements, y configura un servidor web listo para producción que sirve el flow como una API REST. Esta es la parte que importa. Una vez que tu flow está en un contenedor de Docker, deja de ser un experimento especial de machine learning y se convierte en un artefacto de software estándar. Puedes tratarlo como cualquier otro microservicio. Pongamos un escenario concreto. Tienes un flow de chat de atención al cliente validado. Haces la build de la imagen de Docker y le haces push a tu container registry privado. A continuación, haces el deploy de esa imagen en un clúster de Kubernetes. Escribes una configuración de deployment estándar que le indica a Kubernetes que levante tres réplicas de tu contenedor del flow de chat, y colocas un load balancer delante de ellas. Ahora, tu aplicación frontend envía requests HTTP estándar al load balancer, que distribuye el tráfico entre tus contenedores. Si tu flow de chat se satura con requests de usuarios, Kubernetes simplemente escala más instancias de tu flow. Si no quieres gestionar un clúster de Kubernetes, esa misma imagen de Docker funciona perfectamente en servicios de plataforma gestionados. Puedes hacer el deploy directamente en Azure App Service o en cualquier otro proveedor de cloud que aloje contenedores. Al flow le da igual dónde se ejecute, siempre que tenga un runtime de contenedores. Existe un patrón de deployment alternativo. Si no estás creando un servicio web, puedes distribuir un flow como una aplicación ejecutable. Esto empaqueta el flow y sus dependencias de runtime en un archivo ejecutable independiente. Esto es útil si necesitas ejecutar la lógica directamente en una máquina cliente o en un dispositivo edge, evitando por completo la necesidad de instalar Python o configurar un servidor. Pasar un prompt flow a producción no requiere hosting propietario ni infraestructura especializada de machine learning. Al exportar a Docker, los flows de tu modelo de lenguaje se integran a la perfección en las mismas pipelines de continuous delivery y orquestadores de contenedores que ya utilizas para tus servicios de backend tradicionales. Si quieres profundizar en esto, te animo a leer la documentación oficial de Prompt Flow, a probar a hacer el deploy de un contenedor tú mismo, o a visitar devstories dot eu para sugerir temas que te gustaría ver en futuras series. Me gustaría tomarme un momento para darte las gracias por escucharnos; nos ayuda muchísimo. ¡Que tengas un buen día!