DeepEval Framework (2026 Edition)

Hola, soy Alex de DEV STORIES DOT EU. DeepEval Framework, episodio 1 de 18. La mayoría de los equipos evalúan sus modelos de lenguaje recién deployados leyendo manualmente una hoja de cálculo de respuestas. Es lento, está muy sesgado y es imposible de escalar a medida que la aplicación crece. DeepEval es el framework de evaluación open-source que reemplaza este trabajo manual, funcionando a todos los efectos como el Pytest para LLMs. Supongamos que tu equipo está haciendo el deploy de una nueva aplicación generativa. Necesitas asegurarte de que se comporta correctamente antes de subirla a producción. Con DeepEval, escribes tests exactamente igual que los tests unitarios estándar de Python. Creas un archivo llamado test example dot py. Dentro de ese archivo, construyes un test case. Este objeto test case contiene el prompt de entrada inicial, el output real generado por tu aplicación y cualquier respuesta objetivo esperada. Luego, aplicas una métrica de evaluación a este test case. En lugar de usar un check de igualdad estándar para ver si la variable A coincide perfectamente con la variable B, usas una función de assertion especializada proporcionada por el framework. Ejecutas este archivo desde tu línea de comandos usando el comando estándar de Pytest. El framework ejecuta los tests en paralelo, captura las assertions y reporta los tests que pasan y los que fallan directamente en tu terminal. Aquí está la clave. Los tests deterministas estándar no pueden evaluar la calidad o la precisión del lenguaje humano. Si un usuario le pide a tu aplicación un resumen de un documento, hay miles de formas correctas de escribir ese resumen. Los patrones regex y el string matching exacto son inútiles aquí porque no pueden interpretar el significado semántico. DeepEval maneja esta enorme variabilidad usando un concepto llamado LLM-as-a-judge. El framework usa un modelo de lenguaje generalizado y muy capaz para evaluar los outputs específicos de tu propia aplicación. El modelo juez lee el output de tu aplicación, lo compara con los criterios estrictos de la métrica que has seleccionado y calcula un score numérico. Más importante aún, devuelve un resultado booleano que indica si el score cumple con tu umbral predefinido, junto con una razón en plain text que explica exactamente por qué le ha dado ese score. Esto significa que un test fallido te da contexto de debugging inmediato. Al diseñar estos test cases, debes elegir entre dos modos de evaluación distintos. Es fácil confundir el alcance de estos modos, así que vamos a trazar una línea clara. La evaluación end-to-end solo se fija en el input inicial y el output final. La aplicación completa se trata como una caja negra. Tú le pasas un prompt, el sistema da una respuesta y el juez puntúa ese texto final. Ignora por completo cómo la aplicación ha generado la respuesta. La evaluación a nivel de componente es un enfoque de caja blanca. En lugar de simplemente comprobar la respuesta final, este modo rastrea los pasos internos específicos que dio tu aplicación para llegar hasta ahí. Si tu sistema busca en una base de datos para recuperar documentos de contexto antes de generar su texto, un test a nivel de componente evalúa ese paso de búsqueda específico. Comprueba si los documentos recuperados eran realmente relevantes para el prompt del usuario, de forma totalmente independiente de la respuesta final generada. Testeas la maquinaria interna, no solo el producto final. Puedes tener un sistema que pase un test end-to-end dando una respuesta correcta, pero que falle un test a nivel de componente porque sacó esa respuesta del documento interno equivocado. Evaluar un modelo de lenguaje ya no es un ejercicio de lectura subjetiva; es una pieza rígida, automatizada y repetible de tu pipeline de integración continua. Gracias por escuchar, ¡happy coding a todos!

Hola, soy Alex de DEV STORIES DOT EU. DeepEval Framework, episodio 2 de 18. No puedes medir lo que no has definido. Si tus evaluaciones automatizadas parecen inconsistentes, el problema suele empezar incluso antes de que se ejecute la métrica. Es probable que estés pasando los componentes equivocados de tu prompt a los límites de evaluación incorrectos. La solución es definir estrictamente la interacción con el LLM usando el blueprint del test case del LLM. Un test case de LLM en DeepEval sirve como la unidad atómica de evaluación. Te obliga a aislar una única interacción específica con tu sistema. No le pasas logs de conversación completos ni bases de datos raw a un evaluador. En su lugar, extraes exactamente qué entró, qué salió y qué datos de fondo intervinieron en un turno específico. Las interacciones multi-turn tienen su propio blueprint específico, pero el test case estándar se centra estrictamente en una request y una response aisladas. Cada test case requiere dos argumentos obligatorios. El primero es el input. Esta es la string exacta que un usuario o sistema envió al modelo. El segundo es el actual output. Este es el texto que tu LLM generó como respuesta. Aunque no evalúes nada más, tienes que proporcionar estos dos parámetros para medir métricas básicas como la toxicidad o la answer relevance. Imagina un chatbot de atención al cliente. El input es un usuario preguntando si puede devolver un par de zapatos usados después de treinta y cinco días. El actual output es tu modelo generando una respuesta que deniega la devolución. Para evaluar si esa denegación es realmente correcta, necesitas proporcionar una baseline truth. DeepEval te da dos parámetros opcionales diferentes para esto. Estos son el expected output y el context. Los developers los confunden constantemente. El context es estrictamente factual. Contiene la verdad raw y sin formato, como una string de texto de la política de tu empresa que establece un límite estricto de reembolso de treinta días. El expected output es mucho más específico. Dicta el tono, la lingüística y el formato. Usas el expected output cuando quieres que el evaluador compruebe si el modelo respondió con una disculpa cortés y específica, en lugar de simplemente devolver una denegación tajante. El context fundamenta los hechos. El expected output fundamenta el estilo y el fraseo exacto. Aquí está la clave. Cómo construyes el resto de este test case cambia dependiendo de tu arquitectura subyacente. Si estás evaluando un pipeline de Retrieval-Augmented Generation, tienes que definir el retrieval context. Este parámetro acepta una lista de strings que representan los chunks exactos de documentos que tu retriever sacó de la vector database. No lo confundas con el parámetro context estándar. El context es la verdad ideal que hardcodeas para el test. El retrieval context son los datos reales que tu pipeline encontró realmente en producción. Los evaluadores comparan los dos para determinar si tu algoritmo de búsqueda está recuperando los documentos correctos. Si estás construyendo un agent en lugar de un pipeline estándar, utilizas el parámetro tools called. Este acepta una lista de objetos o strings que representan las funciones específicas que el agent decidió invocar durante esta interacción aislada, como lanzar una calculadora de reembolsos interna. Proporcionar esto te permite evaluar las decisiones de routing del agent junto con la generación de texto final. La fiabilidad de una métrica automatizada depende completamente de la higiene de estos parámetros. Un evaluador nunca podrá penalizar una hallucination si no proporcionas el context factual estricto contra el que comprueba el output. ¡Gracias por escuchar, happy coding a todos!

Hola, soy Alex de DEV STORIES DOT EU. DeepEval Framework, episodio 3 de 18. Las métricas tradicionales de NLP, como BLEU y ROUGE, son pésimas para evaluar LLMs modernos, pero hacer deploy de un humano para cada test run es imposible. La solución para escalar tu evaluación sin sacrificar la comprensión semántica es el poder de LLM-as-a-Judge. Las métricas tradicionales buscan coincidencias exactas de palabras. Si tu modelo genera un resumen perfectamente preciso usando diferentes sinónimos, una métrica basada en exact string matching le dará un score bajo porque no puede comprender el significado. Usar un LLM como judge resuelve este problema. Lee el output, procesa el contexto y evalúa la semántica de forma similar a como lo haría un revisor humano, pero a velocidad de máquina. En DeepEval, una métrica evaluada por un LLM realiza tres acciones específicas. Primero, calcula un score entre cero y uno. Cero es un fallo total, uno es perfecto. Segundo, compara ese score con un threshold estricto que tú defines. Si tu threshold es cero coma siete y el modelo saca un score de cero coma seis, el test falla. Tercero, devuelve una razón. El LLM evaluador genera una explicación en texto detallando exactamente por qué asignó ese score específico. Esto te indica qué salió mal sin obligarte a leer manualmente los raw logs. DeepEval divide estas métricas en tres categorías. Las métricas de RAG evalúan los pipelines de retrieval-augmented generation. Las métricas agentic evalúan a los agents autónomos. Las custom metrics te permiten definir tus propios criterios de evaluación desde cero. Aunque los prompts subyacentes de estas difieren, todas utilizan el mismo mecanismo de judge. Al seleccionar una métrica, los desarrolladores suelen confundir las métricas reference-based y las referenceless. Aquí tienes la clave. Las métricas reference-based requieren un ground truth. Necesitan una respuesta correcta y conocida con la que comparar, lo que las hace muy efectivas durante las primeras etapas de desarrollo y testing. Las métricas referenceless no necesitan un ground truth. Evalúan el output basándose únicamente en el contexto proporcionado o en el propio input prompt. Como no dependen de una respuesta preescrita, las métricas referenceless son exactamente lo que usas para la monitorización en producción. Es tentador añadir una docena de métricas a cada prompt para asegurar la calidad. No lo hagas. La regla general es usar menos de cinco métricas por aplicación. Elige las métricas que realmente se alineen con tu lógica de negocio específica. Ejecutar métricas innecesarias solo resulta en tests más lentos y mayores costes de compute. Hablando de costes, usar un modelo comercial flagship para hacer de judge en miles de test runs diarios se vuelve caro rápidamente. DeepEval te permite cambiar el evaluator por defecto por custom models. Puedes configurar el framework para usar Azure OpenAI si tu infraestructura empresarial lo requiere. Alternativamente, puedes configurar un modelo local usando Ollama. Al ejecutar un modelo open-source capaz localmente en tu propio hardware, creas un judge gratuito e imparcial. Simplemente inicializas tu client local de Ollama y pasas ese model object directamente a la configuración de la métrica. DeepEval luego se encarga del resto, ejecutando todo el pipeline de evaluación sin llamar a APIs de facturación externas. El verdadero valor de un LLM judge no es solo el score numérico, sino el razonamiento automatizado que proporciona para ayudarte a debuggear cada fallo. Gracias por escuchar, ¡happy coding a todos!

Hola, soy Alex de DEV STORIES DOT EU. DeepEval Framework, episodio 4 de 18. Una cosa es que tu pipeline RAG responda a una pregunta. Es un problema completamente distinto si inventa con total seguridad detalles que no existen en tus documentos fuente. Hoy vamos a ver cómo evaluar RAG generators, específicamente cómo detectar esos fallos exactos. Un pipeline de Retrieval-Augmented Generation tiene dos partes móviles bien diferenciadas. El retriever obtiene los documentos relevantes. El generator coge esos documentos y redacta la respuesta final. Hoy vamos a ignorar el retriever. Asumimos que tu sistema ya ha obtenido los documentos correctos. Nuestro foco está estrictamente en el generator sintetizando el texto. Para asegurar que este texto sea tanto seguro como útil, te basas en dos métricas: Faithfulness y Answer Relevancy. La primera métrica es Faithfulness. Este es tu principal guardrail contra las alucinaciones. Faithfulness mide si la respuesta del generator, que DeepEval llama el actual output, puede justificarse por completo con el retrieval context. Imagina un escenario típico. Un usuario le pregunta a tu chatbot sobre el plan de salud de la empresa. El retriever obtiene el manual de recursos humanos correcto. El generator responde que el plan cubre atención médica, oftalmológica y dental integral. Sin embargo, el manual de recursos humanos no menciona en ningún momento la cobertura dental. El generator ha sintetizado una mentira muy plausible y bien formateada. La métrica de Faithfulness detecta exactamente este comportamiento. Aísla las afirmaciones hechas en el actual output y las verifica contra el retrieval context pieza por pieza. Si el generator incluye datos que no están en el contexto, el score de Faithfulness baja. No importa si el dato resulta ser cierto en el mundo real. Si no está respaldado explícitamente por el contexto proporcionado, la métrica lo marca como un fallo. Ahora, la segunda parte de esto es Answer Relevancy. Una respuesta fiel no es necesariamente una respuesta útil. El generator podría devolver un resumen perfectamente preciso del manual de recursos humanos que ignore por completo lo que el usuario preguntó realmente. Answer Relevancy mide lo bien que el actual output responde directamente al input original. Evalúa si la respuesta es completa, concisa y libre de divagaciones innecesarias. Si el usuario pregunta por el importe de la franquicia, y el generator indica la franquicia pero luego añade tres párrafos sobre la historia del seguro médico de la empresa, el score de Answer Relevancy baja. El sistema penaliza la información evasiva o de relleno con la misma severidad que la información que falta. Para evaluar estas métricas, creas un test case en DeepEval. Tienes que proporcionar tres variables. Primero, el input, que representa el prompt del usuario. Segundo, el actual output, que es el texto que produjo tu generator. Tercero, el retrieval context, que contiene el texto en crudo de los documentos que tu retriever le pasó al generator. Le pasas este test case a ambas métricas. DeepEval evalúa el texto y calcula un score entre cero y uno para cada una. Tú defines un umbral de aprobado. Si una respuesta saca un cero coma nueve en Faithfulness pero un cero coma cuatro en Answer Relevancy, sabes que el generator es seguro pero poco útil. Si los scores se invierten, tu generator es útil, pero está alucinando activamente. Aquí está la clave. Al evaluar generators, debes separar sistemáticamente la verdad del contexto. Un generator de éxito no dice la verdad absoluta; dice exactamente lo que los documentos proporcionados le permiten decir, respondiendo solo a lo que se le ha preguntado, y nada más. ¡Gracias por escuchar, feliz programación a todos!

Hola, soy Alex de DEV STORIES DOT EU. DeepEval Framework, episodio 5 de 18. Si tu LLM está dando malas respuestas, puede que no sea culpa del modelo. Puede que tu retriever simplemente le esté pasando basura. Hoy vamos a hablar de cómo evaluar retrievers en RAG, concretamente usando Contextual Precision, Contextual Recall y Contextual Relevancy. Imagina hacer una query a una gran base de conocimiento para buscar un detalle muy específico de una política. En lugar de extraer el párrafo exacto que de verdad necesitas, tu retriever coge diez páginas de texto que apenas tienen relación. El LLM se pierde en el ruido, los costes de los tokens se disparan y la respuesta final empeora. Para solucionar esto, tienes que medir el paso de retrieval de forma totalmente independiente del paso de generación. La primera métrica es Contextual Relevancy. Esta métrica analiza los chunks de texto en crudo que tu retriever saca de la base de datos y calcula el ratio de frases relevantes frente al total de frases. Si recuperas mil palabras solo para capturar una frase útil, tu puntuación de relevancy se desploma. Una relevancy alta significa que le estás pasando un contexto limpio y denso al prompt del LLM, sin desperdiciar tokens en información de fondo irrelevante. La siguiente es Contextual Recall. Esta evalúa si tu retriever ha encontrado toda la información necesaria para responder a la query del usuario. DeepEval calcula esto cogiendo el output esperado para una query y extrayendo de ahí todas las afirmaciones factuales. Luego escanea el contexto recuperado para ver si esas afirmaciones específicas están realmente presentes. Si falta un dato crucial en el contexto para dar la respuesta, la puntuación de recall cae. Un recall alto garantiza que el LLM tiene de verdad la materia prima que necesita para hacerlo bien. Luego tenemos Contextual Precision. La gente suele confundir precision con recall. Recall significa que no te has dejado nada. Precision significa que no has metido paja. En las evaluaciones de RAG, la precision tiene muy en cuenta el ranking. Comprueba si los chunks de contexto más relevantes aparecen en lo más alto de la lista recuperada. Si ese párrafo vital está enterrado en la posición número diez, por debajo de nueve chunks inútiles, tu puntuación de precision será baja. Los modelos de lenguaje generalmente prestan más atención a la parte superior del prompt, así que el orden del retrieval cambia por completo el resultado. Aquí está la clave. Hay una tensión constante entre precision y recall. Si configuras tu retriever para que devuelva cincuenta chunks cada vez, tu recall probablemente será perfecto porque estás lanzando una red enorme. Pero tu precision y relevancy se desplomarán porque la mayoría de esos cincuenta chunks son ruido. Por el contrario, si restringes el retriever a exactamente un chunk, tu relevancy será impecable, pero tu recall fallará en el momento en que una query del usuario requiera sintetizar dos datos diferentes de dos documentos distintos. Para ejecutar estos tests en el framework, defines un objeto test case. Este objeto contiene el input del usuario, el output esperado y una lista de los strings de contexto reales que tu retriever ha sacado de la base de datos. Instancias la métrica específica que quieras, como una métrica de Contextual Recall, y le pasas el test case. El framework utiliza entonces un modelo de evaluación por debajo para leer los strings, mapear las afirmaciones, calcular una penalización por la información que falta o que tiene un mal ranking, y devolver una puntuación numérica final entre cero y uno. Evaluar tu retriever te obliga a enfrentarte exactamente a lo que le estás pasando a tu modelo de generación. Un pipeline de RAG de alto rendimiento no se limita a echarle datos a un LLM; los filtra y los ordena por ranking sin piedad. ¡Gracias por escuchar, feliz programación a todos!

Hola, soy Alex de DEV STORIES DOT EU. DeepEval Framework, episodio 6 de 18. Evaluar una única respuesta de texto es sencillo, compruebas el output final frente al input. Pero, ¿cómo evalúas un agente autónomo que decide sus propios pasos, itera sobre múltiples procesos de pensamiento y activa tools externas? Si la respuesta final es correcta, pero el agente dio veinte pasos innecesarios y llamó a la base de datos equivocada para llegar hasta ahí, tu sistema está roto. Arreglar esto requiere Agentic Evaluation. Necesitamos separar una simple API call de un agent flow autónomo de múltiples pasos. Una integración estándar de un modelo de lenguaje sigue una ruta predefinida. Envías un prompt, y el modelo devuelve un string. Un agentic flow transfiere el control al modelo. El modelo recibe un objetivo general y decide de forma autónoma qué tools internas usar, en qué orden y qué argumentos pasarles. Si evalúas un agente mirando solo su output de texto final, te pierdes la mecánica real de su razonamiento. DeepEval soluciona esto usando la métrica de Task Completion. En lugar de parsear el string de la respuesta final, la métrica de Task Completion analiza el trace de ejecución del agente. Un trace es el registro completo y secuencial de cada pensamiento, acción y tool invocation que el agente hizo durante un run específico. La métrica de Task Completion lee este trace para determinar si el agente realmente cumplió la petición del usuario mediante acciones válidas. Imagina un agente planificador de viajes. Un usuario le pide que reserve un fin de semana en Roma con reservas para cenar. Para tener éxito, el agente debe invocar correctamente una tool de búsqueda de restaurantes, y luego pasar esos datos a una tool generadora de itinerarios. Si el agente devuelve un output con un itinerario perfectamente formateado, pero en realidad nunca ejecutó la tool de búsqueda de restaurantes, una métrica de evaluación de texto estándar probablemente lo dará por bueno. El output parece muy convincente. La métrica de Task Completion lo suspenderá. Al analizar el trace, la métrica ve que falta la ejecución necesaria de la tool. El agente alucinó los datos del restaurante en lugar de recuperarlos, y el trace lo demuestra. Esto mueve la evaluación del output final a los pasos operativos. También debes evaluar si las tools se usaron correctamente. Los test cases de DeepEval gestionan esto usando un parámetro llamado tools called. Cuando construyes un test case de evaluación, pasas la lista de tools que el agente invocó durante su ejecución a este parámetro tools called. Proporcionar estos datos permite al framework evaluar la Tool Correctness. La evaluación verifica si el agente seleccionó las tools adecuadas para el objetivo específico, si proporcionó los input arguments correctos a esas tools, y si procesó con éxito los datos que las tools devolvieron. Si tu agente planificador de viajes decidió correctamente usar la tool de búsqueda de restaurantes, pero pasó la ciudad de París en lugar de Roma como argumento, la evaluación de Tool Correctness detecta el error en el punto exacto del fallo. Sabes exactamente qué paso rompió la chain. Aquí está la clave. Evaluar agentes significa meterse dentro de la caja negra. Estás verificando la integridad del proceso de razonamiento del agente y sus acciones mecánicas paso a paso. Una respuesta final estructuralmente perfecta es completamente inútil si el agente llegó a ella a través de tools omitidas, datos alucinados y una lógica rota. Gracias por escuchar, ¡happy coding a todos!

Hola, soy Alex de DEV STORIES DOT EU. DeepEval Framework, episodio 7 de 18. Un chatbot puede dar una primera respuesta genial, pero olvidar por completo la intención del usuario o su propia personalidad para el tercer turno. Por eso usamos la evaluación de conversaciones multi-turno. Evaluar respuestas aisladas es fácil, pero los usuarios reales no envían prompts aislados. Hacen preguntas de seguimiento, cambian de opinión y hacen referencia a cosas que dijeron hace cinco minutos. Los métodos de evaluación estándar se quedan cortos aquí porque solo miran un único input y un único output. No tienen concepto de tiempo ni de memoria. Para probar cómo un modelo maneja un diálogo continuo, necesitas una estructura que capture todo el hilo. En el framework, esto lo gestionas con un objeto específico llamado ConversationalTestCase. En lugar de recibir un string de input y un string de output, recibe un parámetro llamado turns. El parámetro turns es una lista secuencial. Cada elemento de esta lista representa un único intercambio de ida y vuelta entre el usuario y el sistema. Ordenas estos intercambios desde el primer mensaje hasta el último. Envolver la secuencia en un ConversationalTestCase le dice al motor de evaluación que trate toda la lista como una interacción continua y stateful. Aquí hay una trampa común. No le pases un ConversationalTestCase a métricas estándar no conversacionales. Las métricas estándar están pensadas para outputs únicos. Si las usas en un objeto multi-turno, ignorarán por completo el contexto histórico. Tienes que usar métricas conversacionales dedicadas para evaluar la lista de turns. Las métricas conversacionales evalúan la conversación en su conjunto. Tienen en cuenta el contexto previo para juzgar el comportamiento sostenido del modelo. Dos ejemplos principales son Role Adherence y Knowledge Retention. Imagina un chatbot de atención al cliente al que se le indica explícitamente que actúe como un pirata. En el turno uno, el usuario saluda y el bot responde con jerga pirata. En el turno dos, el usuario hace una pregunta y el bot se mantiene en el personaje. Pero para el turno tres, cuando el usuario pregunta por un reembolso, el bot responde con una disculpa corporativa estándar. Se salió completamente del personaje. Puedes detectar este fallo automáticamente usando la métrica Role Adherence. Defines la personalidad objetivo en el setup de la métrica, y esta evalúa toda la conversación para verificar que el modelo nunca se salió del personaje, incluso a medida que el contexto se hacía más largo. Knowledge Retention resuelve un problema diferente. Si un usuario da un número de cuenta en el primer turno, y pide una actualización de estado en el cuarto turno, el bot no debería volver a pedir el número de cuenta. La métrica Knowledge Retention analiza la lista de turns para asegurar que el modelo recupera y aplica con éxito los datos introducidos antes en el historial del chat. Montar esto en código solo lleva unos pocos pasos. Primero, creas tus turns individuales, mapeando el input del usuario al output del modelo para cada paso del diálogo. Luego, le pasas toda esa secuencia a un nuevo ConversationalTestCase. Después, configuras tu métrica conversacional, asignando criterios como la personalidad esperada. Finalmente, ejecutas la métrica contra tu test case. El framework procesa todo el historial y devuelve un score basado en la interacción acumulada. Aquí está la clave. La evaluación multi-turno cambia tu testing de medir la precisión técnica aislada a medir la consistencia de comportamiento sostenida a lo largo del tiempo. ¡Gracias por escuchar, feliz programación a todos!

Hola, soy Alex de DEV STORIES DOT EU. DeepEval Framework, episodio 8 de 18. A veces, las métricas estándar no se ajustan a tu use case, como comprobar si un chatbot financiero altamente regulado suena lo suficientemente profesional. Necesitas una forma de medir rasgos subjetivos de manera fiable, y ahí es exactamente donde entra en juego la creación de métricas personalizadas con G-Eval. Antes de definir métricas personalizadas, establece qué tipo de lógica estás midiendo. G-Eval está diseñado exclusivamente para criterios subjetivos, como el tono, la coherencia o la fluidez conversacional. Si necesitas aplicar una lógica objetiva estricta, deberías usar DAGs. G-Eval maneja los matices del lenguaje humano. Para crear una métrica de Profesionalismo para un chatbot financiero, no escribes reglas de parsing complejas. Usas G-Eval para definir una métrica personalizada con lenguaje cotidiano. Instancias la métrica dándole un nombre y un string de criterios en lenguaje natural. Para este chatbot, tus criterios podrían decir: determina si el actual output mantiene un tono formal y respetuoso, y evita estrictamente la jerga o las frases informales. Aquí está la clave. La métrica no envía simplemente tus criterios a un Large Language Model para pedir un score rápido. G-Eval ejecuta un algoritmo de dos pasos de Chain of Thought. El paso uno es la generación. El algoritmo lee tus criterios en inglés sencillo y genera automáticamente una lista estructurada de pasos de evaluación. Escribe su propia rúbrica de calificación. Para la métrica de Profesionalismo, podría generar un paso para buscar saludos informales, y otro paso para verificar el uso de terminología financiera adecuada. El paso dos es la evaluación real. El algoritmo toma esos pasos generados y los aplica a los parámetros específicos de tu test case. Un test case estándar de G-Eval normalmente incluye el input del usuario y el actual output de tu modelo, pero también puedes incluir el expected output o el retrieval context. El evaluador ejecuta su rúbrica personalizada contra el texto, calcula un score final entre cero y uno, y proporciona una razón detallada explicando por qué restó puntos. Escribir criterios eficaces dicta la calidad de tu métrica. Trata el string de criterios como un prompt muy restringido. No escribas instrucciones vagas como comprueba si la respuesta es buena. Define exactamente qué significa buena. Si usar jerga debería resultar en un score automático de cero, indícalo explícitamente en los criterios. Los pasos de evaluación generados en el paso uno son solo tan precisos como las instrucciones que proporciones. Eso cubre las interacciones individuales. Las conversaciones presentan un desafío diferente. Un chatbot podría empezar siendo profesional, pero adoptar un tono informal para el cuarto mensaje. Para manejar esto, usas Conversational G-Eval. Conversational G-Eval aplica exactamente el mismo algoritmo de dos pasos a un chat multi-turn. La diferencia es el formato de input. En lugar de evaluar un solo input y actual output, le pasas un historial de conversación entero. Este historial consiste en turnos secuenciales alternando entre el usuario y el asistente. La métrica lee el transcript completo, genera sus pasos de evaluación basándose en tus criterios personalizados, y puntúa la interacción en su conjunto. Esto asegura que el output del modelo se mantenga consistente desde el primer saludo hasta la despedida final. La eficacia de cualquier métrica personalizada depende por completo de tratar tus criterios como una especificación rigurosa, donde la claridad siempre le gana a la brevedad. Gracias por escuchar, ¡feliz programación a todos!

Hola, soy Alex de DEV STORIES DOT EU. DeepEval Framework, episodio 9 de 18. Al evaluar reglas de formato complejas, un solo prompt denso puede hacer fácilmente que tu LLM evaluador alucine el score. Podría ver las palabras correctas en el texto, ignorar por completo el orden estructural y dar un aprobado a un test fallido. La solución para esto es la Evaluación Determinista con DAG. DAG significa Grafo Acíclico Dirigido. En este framework, una métrica DAG te permite construir un árbol de decisión estricto que controla cómo el LLM evalúa una respuesta. En lugar de pedirle a un modelo que procese un texto y lo puntúe basándose en un bloque masivo de instrucciones, desglosas la lógica en operaciones granulares paso a paso. Los datos fluyen estrictamente en una dirección, desde los nodos raíz al inicio de tu árbol hasta los nodos hoja al final. Para construir este árbol, te basas en tres componentes distintos. El primero es el Task Node. Un error común es tratarlo como un evaluador. No lo es. Un Task Node simplemente extrae o procesa datos del input o de la respuesta generada. A continuación, está el Binary Judgement Node. Este nodo coge los datos procesados por el Task Node y los evalúa según unos criterios específicos, devolviendo un sí o un no estricto. Finalmente, está el Verdict Node. Este actúa como un nodo hoja. Termina una rama de tu árbol de decisión y devuelve un score numérico final junto con una razón escrita. Vamos a aplicar esto a un escenario concreto. Estás probando un LLM que genera resúmenes de transcripciones de reuniones. Tu requisito estricto es que cada resumen debe tener exactamente tres encabezados: Intro, Body y Conclusion, en esa secuencia exacta. Empiezas tu métrica creando un Task Node raíz. Le indicas a este nodo que lea el resumen generado y extraiga una lista de todos los encabezados que encuentre. Ese es todo su trabajo. Aísla los datos de formato y pasa una lista de texto simple al siguiente nivel del árbol. Ahora, le pasas esa lista a un Binary Judgement Node. Defines los criterios para que este nodo compruebe si la lista contiene exactamente tres elementos. Si el nodo evalúa esto como false, enruta la ejecución hacia un Verdict Node. Ese Verdict Node suspende inmediatamente el test, asigna un score de cero y devuelve una razón indicando que el recuento de encabezados era incorrecto. Si el Binary Judgement Node evalúa a true, la ejecución pasa a un segundo Binary Judgement Node. Este nodo coge la misma lista extraída y comprueba la secuencia. Verifica si el primer elemento es Intro, el segundo es Body y el tercero es Conclusion. Si esto es true, enruta a un Verdict Node final dando un score perfecto. Si es false, enruta a un Verdict Node diferente asignando un cero debido a un fallo en el orden. Esta es la parte que importa. Al separar la extracción de información en un Task Node de la lógica de evaluación en los Judgement Nodes, obligas al LLM a seguir un camino inflexible. El modelo se encarga de la extracción semántica, mientras que tu grafo garantiza la ejecución determinista de las reglas. ¡Gracias por escuchar, feliz programación a todos!

Hola, soy Alex de DEV STORIES DOT EU. DeepEval Framework, episodio 10 de 18. Probar un modelo de lenguaje con cinco prompts manuales es muy bonito. Pero cuando actualizas a una nueva versión del modelo, esos cinco prompts no te dirán si te has cargado edge cases en cientos de interacciones históricas. Para estar production-ready, necesitas un repositorio de la verdad robusto y con control de versiones. Eso es lo que te da un Evaluation Dataset. Un Evaluation Dataset en DeepEval es simplemente una colección estructurada de elementos llamados Goldens. Antes de seguir, tenemos que aclarar un malentendido muy común. Los desarrolladores suelen confundir un Golden con un Test Case. No son lo mismo. Un Golden es la fila del dataset en crudo. Contiene tus parámetros de testing estáticos, como el user input, el expected output y el retrieval context. Representa el escenario ideal. Un Golden solo se convierte en un Test Case más adelante, en runtime, después de que tu live application procese el input e inyecte su output real. El Golden es la plantilla, mientras que el Test Case es el resultado ejecutado. Vamos a aterrizar esto con un escenario concreto. Tienes un log histórico de 500 consultas de atención al cliente guardado en un archivo CSV. Quieres probar rigurosamente una nueva versión del modelo contra este set exacto de consultas. No necesitas escribir parsing logic a medida. Simplemente inicializas un Evaluation Dataset y usas el método integrado para añadir datos desde un archivo CSV. Le pasas el file path y defines un mapping. Le dices al dataset qué columna del CSV corresponde al user input, cuál mapea al expected output y cuál contiene el contexto. El framework se encarga del parsing y construye 500 Goldens en memoria. Puedes hacer exactamente lo mismo con un archivo JSON, mapeando las keys del JSON a los campos del Golden. Aquí está la clave. El Evaluation Dataset controla un ciclo de vida específico que hace de puente entre tus datos estáticos y tu pipeline de evaluación dinámico. Primero, cargas y guardas tus Goldens en el dataset. Después, durante tu test run, iteras sobre el dataset. Extraes el input de cada Golden, se lo pasas a tu live language model y capturas la respuesta generada. Luego, adjuntas esa respuesta en vivo al Golden y lo conviertes en un Test Case oficial. Finalmente, le pasas ese Test Case completo a tus métricas para el scoring. Esto mantiene tus datos en crudo completamente separados de tu lógica de ejecución. Hasta ahora, hemos descrito datasets single-turn. Un user input, un expected output. Pero muchas aplicaciones incluyen interfaces de chat. Para esto, DeepEval soporta datasets multi-turn. En lugar de una string de input plana, un dataset multi-turn contiene una secuencia de interacciones. Un único Golden multi-turn guarda todo el historial de la conversación, registrando cómo interactúan el usuario y el sistema a lo largo de varios pasos. Esto permite que tus métricas evalúen el flujo y la retención de contexto de una conversación, en lugar de evaluar una única respuesta aislada. Estructurar tus datos en Evaluation Datasets formales garantiza que cada ajuste del prompt y cambio de modelo se mida contra un estándar histórico estricto e invariable. ¡Gracias por escuchar, happy coding a todos!

Hola, soy Alex de DEV STORIES DOT EU. DeepEval Framework, episodio 11 de 18. El mayor cuello de botella para evaluar large language models no es el testing framework que uses. Es la falta de test data de alta calidad para empezar. Generar synthetic data usando el DeepEval Synthesizer es como te saltas este bloqueo. Imagina una startup creando un bot interno de recursos humanos. Necesitas ejecutar tests inmediatamente para verificar que recupera las políticas correctas. Pero el bot es totalmente nuevo. Tienes cero query logs de usuarios reales. Este es el clásico problema de cold-start para la evaluation data. No puedes evaluar un retrieval system sin una lista robusta de preguntas realistas que hacerle. El DeepEval Synthesizer hace un bootstrap de un dataset de evaluación directamente desde tu knowledge base en bruto. En lugar de escribir cientos de test cases a mano, apuntas la herramienta hacia tus documentos fuente. El método principal para esto se llama generate goldens from docs. En DeepEval, un Golden es la terminología para un único test case que contiene un input, un expected output y un context. Para usarlo, primero inicializas un objeto Synthesizer. Luego, llamas al método generate goldens from docs y le pasas un array de document paths. Para el bot de recursos humanos, estas serían las file paths de tus manuales de empleado, políticas de vacaciones y PDFs de beneficios. Cuando ejecutas este método, el Synthesizer procesa los archivos y divide el texto en chunks manejables. Luego utiliza un evaluator language model para actuar como un usuario curioso. El modelo revisa un chunk específico del manual de recursos humanos y genera una pregunta relevante y realista basada puramente en ese texto. Esta pregunta se guarda como el synthetic input. El Synthesizer también guarda el chunk de texto exacto usado para inspirar la pregunta. Este se convierte en el expected context. Finalmente, el modelo formula la respuesta ideal y factual a la pregunta y la guarda como el expected output. Esta es la parte que importa. La gente a menudo malinterpreta los límites de la synthetic generation. El Synthesizer solo crea los inputs, el expected context y el expected output. No genera el actual output. Encontrar el actual output es el trabajo de tu propia aplicación de recursos humanos durante la fase de testing. Piensa en el Synthesizer como un profesor escribiendo un examen y creando una hoja de respuestas. Tu bot todavía tiene que hacer el examen. Puedes controlar el alcance de esta generación. Al llamar al método, puedes especificar cuántos test cases generar por documento. Esto mantiene el proceso rápido y barato para iteraciones rápidas, o puedes escalarlo para una cobertura completa. Una vez que el método termina, extraes los goldens generados y los guardas. Puedes exportar el dataset localmente como un archivo JSON, o hacerle push directamente a Confident AI para trackear las versiones de tu dataset a lo largo del tiempo. Hacer bootstrap de synthetic datasets te permite pasar de esperar a que usuarios reales expongan los fallos de tu sistema, a testear sistemáticamente los límites absolutos de la lógica de tus documentos desde el primer día. ¡Gracias por escuchar, happy coding a todos!

Hola, soy Alex de DEV STORIES DOT EU. DeepEval Framework, episodio 12 de 18. Las queries sintéticas básicas generadas a partir de tus documentos son demasiado fáciles. Los modelos de lenguaje modernos procesan sin dificultad preguntas sencillas, dejando lagunas lógicas peligrosas completamente sin probar. Para encontrar breaking points reales en tu aplicación, necesitas aumentar artificialmente la dificultad de tu test data. Lo logramos mediante la Evolving Synthetic Complexity. La generación estándar produce preguntas simples y directas. La evolución complica matemáticamente esas preguntas para hacer un stress-test a tu sistema. A veces la gente confunde esto con alterar los hechos subyacentes. Evolucionar una query sintética no significa cambiar el ground truth. Los datos de origen permanecen exactamente iguales. Lo que cambia es la dificultad estructural de la query que pregunta sobre esos datos. En DeepEval, controlas este proceso de mutación mediante la Evolution Config. Esta configuración aplica estrategias evolutivas específicas para transformar un prompt básico en un edge case con múltiples restricciones. Toma como ejemplo una pregunta sintética simple como: ¿cuál es la política de devoluciones? Es directa, pero demasiado genérica para ser un test riguroso. La primera estrategia que puedes aplicar es la Concretizing evolution. Esta toma una query abstracta y la fuerza hacia un escenario tangible y muy específico. En lugar de preguntar por la política general, el concretizing muta la query a algo como: si compré una camisa roja el martes, ¿puedo devolverla la semana que viene? El modelo ahora debe mapear las restricciones específicas del usuario con la regla general. La segunda estrategia es la Reasoning evolution. Esta introduce una capa de deducción necesaria. La pregunta evolucionada obliga al modelo a realizar pasos lógicos antes de poder proporcionar la respuesta final. En lugar de simplemente hacer retrieval de un dato, la query podría requerir que el sistema calcule fechas, compare valores o siga una chain de lógica condicional basada en el texto fuente antes de formar su respuesta. La tercera estrategia es la Multicontext evolution. Esta prueba el retrieval y la síntesis al obligar al modelo a extraer respuestas de información inconexa. Modifica la query para que la respuesta no pueda extraerse de un solo párrafo. Para tener éxito, el modelo de lenguaje debe combinar el plazo general de devoluciones de un documento con exclusiones específicas de artículos en liquidación de una sección completamente diferente. Cuando mutas artificialmente miles de queries mediante estas estrategias, algunas inevitablemente se degradan. Una pregunta evolucionada podría volverse tan enrevesada que resulte genuinamente imposible de responder, o podría alejarse de los hechos originales. Este es exactamente el problema que resuelve la Filtration Config. No puedes permitir que el ruido irresoluble contamine tu dataset de evaluación. El Filtration emplea un critic model independiente que actúa como un filtro de control de calidad. Revisa cada query recién evolucionada según criterios estrictos antes de guardarla. Si una pregunta mutada está rota lógicamente, ya no se alinea con el contexto original o degenera en un sinsentido, el critic model la rechaza directamente. Este proceso de dos pasos te asegura generar preguntas que son increíblemente difíciles, pero totalmente válidas. Una puntuación alta en datos sintéticos básicos no demuestra nada sobre la resiliencia de tu sistema; la verdadera fiabilidad de un modelo se mide únicamente por cómo gestiona los edge cases complejos y evolucionados intencionadamente que la generación estándar deja atrás. ¡Gracias por escuchar, happy coding a todos!

Hola, soy Alex de DEV STORIES DOT EU. DeepEval Framework, episodio 13 de 18. Las evaluaciones end-to-end te dicen si un sistema ha fallado, pero te dejan adivinando el porqué. El tracing a nivel de componente te dice exactamente qué función específica ha fallado. Hoy vamos a ver el tracing y la observabilidad de LLMs. Imagina un pipeline estándar de Retrieval-Augmented Generation. Un usuario hace una pregunta compleja y tu sistema devuelve una respuesta alucinada diez segundos después. Necesitas saber exactamente qué ha fallado. ¿La función de retrieval de embeddings sacó documentos irrelevantes de tu base de datos, o el paso final de generación del language model simplemente falló al sintetizar el contexto correcto? No puedes debuggear esto de forma eficiente solo mirando el output final. Necesitas inspeccionar los pasos internos. Para hacer esto, tienes que entender dos términos fundamentales que se confunden a menudo: Traces y Spans. Un Trace es el árbol de ejecución completo de una sola operación. Representa el timeline completo desde el momento en que el usuario envía un prompt hasta el momento en que el sistema entrega la respuesta final. Un Span, por otro lado, es un componente o función específica que opera dentro de ese Trace. La ejecución completa de tu pipeline es un Trace. La función que hace la query a la vector database es un Span. La función que formatea el prompt es otro Span. La propia llamada al large language model es un tercer Span. Cada Trace está construido a partir de estos Spans anidados. Cada Span registra su propia hora de inicio, hora de fin, parámetros de input y resultados de output. En DeepEval, capturas esta jerarquía usando el decorator observe. Simplemente pones la palabra observe con un símbolo de arroba directamente encima de las funciones de Python que quieres monitorizar. Lo añades a tu función main de entry-point, y lo añades a las helper functions internas como tu retriever y tu generator. Cuando tu aplicación se ejecuta, el decorator observe intercepta automáticamente la ejecución. Registra los argumentos exactos que se pasan a la función y los datos exactos que devuelve. También hace un seguimiento de la latency y de cualquier error que ocurra. Y lo que es más importante, entiende el contexto de ejecución. Si tu función principal del pipeline llama a tu función retriever, el decorator registra automáticamente el retriever como un child Span del Trace principal. Mapea las relaciones parent-child de tus funciones sin que tengas que enlazarlas manualmente. Aquí está la clave. Hacer tracing de esta manera es completamente no intrusivo. No tienes que reescribir el codebase de tu aplicación para generar telemetry. No necesitas alterar las signatures de tus funciones para pasar trace IDs u objetos de contexto por el call stack. Mantienes tu business logic limpia y simplemente envuelves los componentes que te importan. Al hacer esto, aíslas los datos de cada paso individual. Si más tarde quieres evaluar solo la lógica de retrieval, los inputs y outputs exactos de ese Span específico ya están registrados. Evalúas end-to-end para medir la experiencia final del usuario, pero haces tracing a nivel de componente para localizar y arreglar realmente el código subyacente. ¡Gracias por escuchar, feliz programación a todos!

Hola, soy Alex de DEV STORIES DOT EU. DeepEval Framework, episodio 14 de 18. En workflows complejos de agentes autónomos, no siempre sabes cuál debería ser el test case hasta que el agente realmente empieza a ejecutarse. No puedes escribir una test suite estática completa para decisiones intermedias que aún no se han tomado. Las evaluaciones dinámicas en runtime resuelven esta limitación al permitirte construir y evaluar test cases sobre la marcha. Normalmente, los desarrolladores definen los test cases estáticos externamente. Creas un archivo con inputs y outputs esperados rígidos, y luego ejecutas tu aplicación contra ellos. Ese enfoque falla cuando trabajas con sistemas autónomos. Cuando un agente recibe un prompt, puede enrutar la consulta, seleccionar una herramienta especializada y generar su propia search string interna. Esos inputs y outputs intermedios no existen hasta que el código se está ejecutando realmente. Las evaluaciones dinámicas prescinden del archivo externo. En su lugar, construyen el test case paso a paso a medida que las variables se rellenan dentro de la aplicación activa. Imagina un escenario específico. Necesitas evaluar la precisión del contexto dentro de una función retriever profundamente anidada. Quieres probar solo ese paso específico sobre la marcha, aislado del output final que ve el usuario. Para hacer esto, DeepEval proporciona dos funciones específicas para interceptar los datos de ejecución: update current span y update current trace. Un trace registra todo el ciclo de vida de una request, desde el input inicial del usuario hasta la respuesta final. Un span representa una operación específica dentro de ese trace, como tu función retriever. Cuando esa función retriever se ejecuta, las variables dinámicas por fin se materializan. Ahora tienes la search string exacta que generó el agente y los chunks de texto específicos que devolvió tu base de datos. Justo en este momento, dentro de la lógica del retriever, llamas a update current span. Usas esta función para interceptar esas variables en vivo y mapearlas directamente en un nuevo test case. Coges la search string interceptada y la asignas como el input del test. Coges los chunks en crudo de la base de datos y los asignas como el contexto de retrieval. Acabas de construir un golden test case durante la ejecución. Como construiste este golden dinámicamente dentro del span, puedes evaluarlo inmediatamente. Aplicas tu métrica de precisión de contexto justo ahí. La métrica se ejecuta contra los datos en vivo, puntúa el paso del retriever y adjunta esa puntuación directamente al span local. Cuando revisas tus traces más tarde, no solo ves que ocurrió un retrieval. Ves una evaluación muy específica de ese retrieval concreto, basada en las condiciones exactas de ese run. Eso cubre los pasos granulares. Sin embargo, a veces, una operación anidada descubre algo que cambia el contexto de toda la request. Aquí es donde update current trace se hace necesario. Mientras que update current span modifica el paso local, update current trace permite que una función profundamente anidada alcance y modifique el registro de ejecución global. Si tu agente descubre información sobre la marcha que cambia por completo cómo debería ser la respuesta final, llamas a update current trace para actualizar el output esperado de todo el run. Esto mantiene la evaluación global alineada con la realidad viva y cambiante de la lógica de ejecución. Aquí está la clave. Mover las evaluaciones de archivos externos al árbol de ejecución en runtime convierte el testing de un ejercicio post-mortem a un mecanismo de diagnóstico en vivo. Al vincular las métricas directamente a los spans mientras se ejecutan, dejas de adivinar por qué falló un agente de múltiples pasos y empiezas a medir exactamente qué traspaso interno causó el fallo. Gracias por escuchar, ¡happy coding a todos!

Hola, soy Alex de DEV STORIES DOT EU. DeepEval Framework, episodio 15 de 18. Tu LLM podría responder perfectamente a todas las preguntas normales. Pero, ¿qué pasa cuando un usuario malintencionado intenta activamente hacer un jailbreak a tu aplicación para que filtre datos sensibles? Eso requiere un enfoque completamente diferente, lo que nos lleva a una introducción al Red Teaming. Para entender el Red Teaming, tienes que cambiar cómo ves tu sistema. La evaluación estándar prueba la funcionalidad. Mide si tu modelo es útil, preciso y relevante cuando se usa correctamente. El Red Teaming prueba la seguridad, la protección y los guardrails. Requiere un cambio de mentalidad: pasar de comprobar que todo es correcto a simular actores maliciosos. Estás intentando activamente que el modelo falle. Imagina un escenario común. Si le pides directamente a tu aplicación de IA que devuelva un perfil de usuario, es probable que los guardrails estándar lo detecten. La IA se niega en rotundo a filtrar la Información de Identificación Personal, o PII. Una evaluación estándar marca esto como un éxito. Pero un actor malicioso no lo pedirá directamente. Podrían hacer un prompt al modelo usando un rol malicioso específico, dándole instrucciones a la IA para que actúe como un administrador de bases de datos senior haciendo un override de emergencia del sistema. De repente, la IA obedece y filtra voluntariamente la PII. El Red Teaming es el proceso sistemático de descubrir exactamente estos puntos ciegos antes de que lleguen a producción. DeepEval estructura este proceso en torno a cuatro componentes principales. El primer componente son las vulnerabilidades. Una vulnerabilidad es la debilidad, el riesgo o el daño específico que estás probando. Es el problema subyacente que quieres prevenir. En nuestro escenario de override de emergencia, la vulnerabilidad es la filtración de PII. Otras vulnerabilidades podrían incluir generar un output tóxico, mostrar sesgos no autorizados u ofrecer consejos peligrosos. El segundo componente son los ataques adversarios. Si la vulnerabilidad es el objetivo, el ataque es el arma. Los ataques son las técnicas o medios específicos que se usan para explotar una vulnerabilidad. Adoptar un rol de confianza para engañar a la IA es un tipo de ataque. Otros incluyen el prompt injection, donde las instrucciones maliciosas se ocultan en el input normal, o jailbreaks complejos diseñados para saltarse por completo el entrenamiento de seguridad del modelo. DeepEval separa la debilidad de la táctica porque una sola vulnerabilidad puede quedar expuesta por muchos tipos diferentes de ataques. El tercer componente es el sistema LLM objetivo. Esta es la aplicación real que estás evaluando. No es solo el foundation model en bruto, sino tu arquitectura específica. Esto incluye tus system prompts personalizados, tus mecanismos de retrieval y cualquier filtro de seguridad existente. Los ataques adversarios se ejecutan directamente contra este setup para ver cómo rinde tu producto real bajo presión. El cuarto componente son las métricas. Una vez que se ejecuta un ataque contra tu sistema objetivo para buscar una vulnerabilidad, necesitas un resultado cuantificable. Las métricas evalúan la respuesta del sistema. Determinan si el ataque logró saltarse los guardrails, o si el sistema rechazó la petición maliciosa de forma segura. Una métrica puntúa la interacción, dándote un pass o fail concreto basado en lo seguro que fue realmente el output. Aquí está la clave. No puedes asegurar una aplicación de IA solo demostrando que hace lo correcto cuando se lo pides amablemente; tienes que demostrar sistemáticamente que se niega a hacer lo incorrecto cuando está bajo ataque. ¡Gracias por escuchar, feliz programación a todos!

Hola, soy Alex de DEV STORIES DOT EU. DeepEval Framework, episodio 16 de 18. No deberías tener que introducir manualmente miles de inputs engañosos para encontrar fallos de seguridad en tu aplicación. En lugar de pagar a un equipo de seguridad para que intente romper tu sistema manualmente durante semanas, puedes dejar que una IA ataque a tu IA de forma autónoma. Hoy vamos a ver cómo ejecutar ataques adversarios. Para orquestar un ataque automatizado de LLM-on-LLM, el motor de escaneo necesita una línea de comunicación directa con tu aplicación. Estableces esta conexión definiendo un callback para el modelo objetivo. Es una función asíncrona de Python que escribes tú mismo. Recibe un único argumento de tipo string, que es el prompt adversario generado por el motor de pruebas, y debe devolver la respuesta en string de tu sistema. En un escenario típico usando un modelo de OpenAI, definirías esta función callback asíncrona, cogerías el parámetro prompt entrante, se lo pasarías a tu cliente de OpenAI, harías el await de la generación y devolverías el contenido de texto final. Este callback actúa como puente. El motor de red teaming no necesita conocer tu arquitectura interna, tus API keys ni el estado de tu base de datos. Solo necesita una función a la que pueda llamar continuamente con inputs maliciosos. Una vez que tu callback esté listo, se lo pasas a la función de red team. Este es el orquestador principal que ejecuta el escaneo. Para configurarlo, tienes que proporcionar dos listas distintas: vulnerabilidades y ataques. Es fundamental entender la diferencia entre ambas. Las vulnerabilidades son los fallos estructurales específicos o los comportamientos dañinos que quieres testear. Por ejemplo, si quieres asegurarte de que tu aplicación no devuelva prejuicios raciales o de género, importas y le pasas la vulnerabilidad Bias a la función de red team. Los ataques, por otro lado, representan la metodología que el motor utilizará para intentar exponer esa vulnerabilidad. Para forzar al modelo a hacer una declaración sesgada, puede que quieras que el motor utilice frases engañosas o técnicas de jailbreak. Esto lo haces pasándole el ataque de Prompt Injection. El motor ahora generará de forma autónoma prompts maliciosos dirigidos usando prompt injection, diseñados específicamente para saltarse tus system prompts y activar la vulnerabilidad Bias. Un punto común de confusión durante este setup es cómo se evalúan realmente los resultados. En una evaluación estándar, pasas mucho tiempo definiendo y ajustando métricas específicas. Al ejecutar ataques adversarios, no definas las métricas manualmente. El framework se encarga de esto completamente por detrás. Mapea automáticamente la vulnerabilidad que has seleccionado directamente a su métrica de evaluación interna correspondiente. Como le dijiste que testeara Bias, el motor ejecuta automáticamente un evaluador de sesgo contra cada una de las respuestas que devuelve el callback de tu modelo objetivo. Una vez que la función de red team termina de lanzar estos prompts generados y de evaluar las respuestas, devuelve un Risk Assessment completo. Este assessment proporciona un desglose claro del escaneo. Muestra exactamente cuántos ataques se intentaron, qué técnicas de ataque específicas lograron vulnerar tu sistema y los strings de input exactos que causaron el fallo. Te llevas una lista concreta de inputs que tu sistema actualmente no puede manejar. Aquí está la clave. El verdadero poder de este setup es desacoplar el método de ataque de la vulnerabilidad objetivo, lo que te permite multiplicar tu cobertura de seguridad emparejando un único fallo como el sesgo con docenas de vectores de ataque diferentes simultáneamente. ¡Gracias por escuchar, feliz programación a todos!

Hola, soy Alex de DEV STORIES DOT EU. DeepEval Framework, episodio 17 de 18. Jamás harías merge de una pull request de código tradicional sin antes ejecutar tus unit tests. Sin embargo, los equipos hacen deploy habitualmente de modelos de lenguaje no deterministas y simplemente esperan que los nuevos prompts sigan funcionando. Si quieres evitar que las actualizaciones defectuosas del modelo rompan producción, necesitas CI/CD y Continuous Evaluation. DeepEval trata las evaluaciones de modelos de lenguaje exactamente igual que los tests de software estándar, integrándose directamente con Pytest. Defines una función de test, inicializas tus métricas de evaluación y haces un assert para comprobar que la métrica pasa. Evaluar un modelo con un solo input es inútil, por lo que necesitas validar los cambios contra un gran batch de inputs de referencia aprobados y outputs esperados. Este es tu golden dataset. Para iterar sobre este dataset de forma eficiente, utilizas el decorator estándar mark parametrize de Pytest. Cargas tu dataset, extraes los casos de test individuales y los pasas al decorator. Cuando se ejecuta la test suite, Pytest genera dinámicamente una ejecución de test independiente para cada elemento de tu golden dataset. Aquí está la clave. Como el framework se integra tan bien con Pytest, los developers suelen asumir que pueden simplemente ejecutar comandos estándar de Pytest en su terminal. No hagas esto. Si ejecutas Pytest directamente contra tus archivos de evaluación, te encontrarás con errores inesperados relacionados con event loops asíncronos y falta de telemetry en las métricas. Siempre debes usar la command line interface dedicada. El comando correcto es deepeval test run seguido del nombre de tu archivo Python. Este wrapper gestiona el complejo setup asíncrono que requieren los modelos de lenguaje y garantiza que todos los resultados de los tests se capturen y logueen correctamente. Integrar este comando en tu pipeline de deployment te proporciona evaluación continua. Considera un setup típico de GitHub Actions. Configuras el workflow para que se dispare cada vez que un ingeniero abre una pull request hacia la rama main. El runner de la action hace checkout del repositorio, prepara el entorno de Python y ejecuta deepeval test run contra tu script del golden dataset. El framework evalúa el código o el prompt recién modificado contra todos los casos de test históricos. Si un developer altera un system prompt para que las respuestas sean más concisas, podría indicarle accidentalmente al modelo que elimine los avisos de compliance obligatorios. Cuando se ejecuta el pipeline de CI, la evaluación automatizada detecta esta falta de contexto de inmediato. Si la nueva lógica provoca que tu puntuación de evaluación caiga por debajo de tu umbral definido en cualquier caso de test, el assert falla. El script devuelve un exit code distinto de cero, la GitHub Action se pone roja inmediatamente y la pull request queda bloqueada para hacer merge. Este check automatizado pre-deployment actúa como un estricto gatekeeper. Detecta regresiones automáticamente. Ya no tienes que revisar manualmente los outputs ni esperar a que los usuarios se quejen de que un cambio de modelo ha roto un edge case específico. El pipeline demuestra matemáticamente si la actualización es segura para hacer deploy, eliminando por completo la subjetividad humana del proceso de release. La evaluación continua significa que dejas de tratar el prompt engineering como una apuesta operativa y empiezas a tratarlo como una release de software predecible respaldada por datos concretos. ¡Gracias por escuchar, feliz programación a todos!

Hola, soy Alex de DEV STORIES DOT EU. DeepEval Framework, episodio 18 de 18. Pasas horas ajustando un prompt en local, consigues una puntuación de evaluación genial y haces el deploy del código. Dos semanas después, otro ingeniero actualiza el modelo subyacente y, de repente, la aplicación falla en edge cases que nadie había trackeado. Ejecutar evaluaciones en local es solo la mitad de la batalla. Este episodio explica cómo escalar tu testing y trackear las regresiones a lo largo del tiempo usando Confident AI. Primero, una distinción necesaria. DeepEval es el framework open-source que ejecutas en tu terminal o entorno de Python para pasar los tests. Confident AI es la plataforma cloud alojada que está construida sobre él. Usas DeepEval para definir tus métricas y ejecutar las evaluaciones en sí. Usas Confident AI para centralizar, trackear y analizar esos reportes de evaluación en toda la organización de ingeniería. Coge scripts aislados en local y los transforma en un sistema de registro colaborativo. Pasar de la ejecución en local al logging en el cloud requiere un solo paso sencillo. En tu terminal, ejecutas el comando deepeval login. La CLI te pedirá que proporciones una API key generada desde tu workspace de Confident AI. Una vez que te autenticas, tu workflow diario se mantiene exactamente igual. Ejecutas tus archivos de testing usando el comando de test estándar. El framework detecta automáticamente la sesión activa y hace un stream de los resultados directamente al dashboard en el cloud, mientras los sigue imprimiendo en local. Centralizar los reportes te da la capacidad de trackear las regresiones de forma metódica. Una regresión ocurre cuando un cambio en tu código o configuración degrada sin querer el rendimiento del sistema. Para diagnosticar por qué ocurrió una regresión, necesitas trackear exactamente qué cambió entre las ejecuciones de los tests. Esto se hace logueando los hiperparámetros. En el contexto de las evaluaciones de modelos de lenguaje, un hiperparámetro es cualquier variable que altera el comportamiento de tu pipeline. Esto incluye la arquitectura del modelo, la configuración de temperatura, el chunk size usado para el retrieval, o incluso la versión específica del template del prompt. Cuando configuras DeepEval para loguear estos hiperparámetros, se adjuntan a cada ejecución de test enviada a Confident AI. Imagina un equipo que intenta actualizar su aplicación. Quieren saber si cambiar de GPT-4o a Claude 3.5 Sonnet realmente mejora la puntuación general de su pipeline. Configuran el nombre del modelo como un hiperparámetro trackeado. Cuando el ingeniero ejecuta la suite de evaluación usando el nuevo modelo, Confident AI loguea el nombre del nuevo modelo junto con las puntuaciones resultantes para métricas como la precisión contextual o la consistencia factual. Aquí está la clave. Como todas las ejecuciones históricas de los tests se guardan en el cloud, el equipo puede ver un timeline comparando los cambios exactos de los hiperparámetros con las puntuaciones de evaluación agregadas. Si cambiar al nuevo modelo aumenta la relevancia de las respuestas, pero reduce drásticamente la consistencia factual, el dashboard resalta esta regresión al instante. Todo el equipo ve los mismos datos. Ya no tienes que parsear antiguos outputs de consola ni depender de la memoria para decidir si un cambio de configuración fue un éxito. La evaluación continua requiere una baseline histórica. Sin un sistema centralizado que vincule tus configuraciones directamente con tus puntuaciones de evaluación, simplemente estás ejecutando experimentos aislados, no diseñando un sistema fiable. Con esto concluye nuestra serie sobre el framework DeepEval. Te animo muchísimo a que explores la documentación oficial y pruebes a montar estas evaluaciones de forma práctica. Si tienes temas técnicos que te gustaría ver en una futura serie, visita devstories dot eu para dejar una sugerencia. ¡Gracias por escuchar, feliz programación a todos!