Los agentes y las canalizaciones de agentes se están creando y lanzando a un ritmo acelerado como nunca antes. Pero, ¿cómo podemos determinar lo buenos que son?
Por qué es importante evaluar a los agentes de IA
Piense en un agente de IA como en un rastreador de fitness. El rastreador siempre funciona, nunca dice "No se pueden obtener datos precisos" y siempre proporciona una lectura cuando se pulsa el botón, pero la mayoría de las veces, estas lecturas son poco precisas. Lo mismo ocurre con los agentes, cada equipo tiene uno para su caso de uso específico, y siempre generan una respuesta. Pero muy pocos saben lo bien que funcionan en escenarios reales. Suponemos que funcionan, sin saber realmente hasta qué punto.
Desarrollar marcos sólidos de evaluación de agentes de IA se ha convertido en algo esencial por varias razones de peso:
-
- Calidad garantía: A medida que los agentes de IA se vuelven más autónomos y se encargan de tareas críticas, la evaluación sistemática garantiza que cumplen las normas de fiabilidad antes de su despliegue.
- Rendimiento benchmarking: Las métricas objetivas permiten un seguimiento coherente del rendimiento en todas las iteraciones del modelo y la comparación con las normas del sector.
- Dirigido a mejora: El análisis detallado señala los puntos débiles específicos, lo que permite una asignación eficaz de los recursos de desarrollo.
- Alineación verificación: Garantiza que los agentes actúen de acuerdo con las intenciones del diseño y no desarrollen comportamientos inesperados en casos extremos.
- Conformidad y riesgo gestión: Facilita la documentación de las capacidades y limitaciones de los agentes para los requisitos reglamentarios y legales.
- Inversión justificación: Proporciona pruebas cuantitativas del valor y la mejora del sistema de IA a las partes interesadas y a los responsables de la toma de decisiones.
Desglose del proceso de evaluación de agentes
La evaluación de un agente, ya sea un chatbot, un sistema de generación de recuperación aumentada (RAG) o una herramienta que utilice LLM, requiere un enfoque sistemático para garantizar que su modelo sea preciso, fiable y robusto. Recorramos los pasos típicos de cómo se puede evaluar un flujo de trabajo agéntico:
-
- Preparar la verdad sobre el terreno: Utilice conjuntos de datos públicos si se ajustan a su caso de uso o, preferiblemente, genere datos sintéticos adaptados a la funcionalidad de su agente.
- Ejecutar el agente en el conjunto de datos: Alimentar cada entrada/consulta del conjunto de datos en el agente.
- Registrar toda la actividad de los agentesrespuestas finales, llamadas a herramientas, resultados y pasos de razonamiento, si procede
- Crear y realizar un experimento: Evalúe las respuestas del agente. Compara las respuestas del agente con las respuestas esperadas/de referencia. Maneje coincidencias parciales, salidas anidadas o datos estructurados utilizando lógica de comparación personalizada si es necesario. Agregue los resultados y calcule las métricas de evaluación (precisión, tasa de éxito, etc.).
- Persistir en los resultados: Almacenar los resultados de la evaluación para poder reproducirlos y consultarlos posteriormente. Identificar los puntos de fallo a partir de las métricas.

Un flujo de trabajo modular ideal utilizando el marco
Preparar la verdad sobre el terreno
Uno de los mayores retos a la hora de evaluar sistemas agenticos es la disponibilidad de datos de referencia, es decir, referencias con las que comparar las respuestas del agente para evaluarlo. Para evaluar eficazmente un agente típico, se necesitan datos de referencia exhaustivos que abarquen las llamadas a la herramienta, los parámetros de la herramienta, los resultados de la herramienta y las respuestas finales. Recopilar y etiquetar todos estos datos de la verdad sobre el terreno lleva mucho tiempo y requiere una gran contribución humana.
Si no disponemos de los recursos necesarios para preparar una verdad de base curada para la evaluación, tenemos dos opciones. O bien aprovechamos los conjuntos de datos de evaluación disponibles públicamente, o bien generamos datos sintéticos que puedan utilizarse como datos reales.
Un generador de datos sintéticos se encarga de la creación de la verdad sobre el terreno a partir de documentos sin procesar, entendiendo por documentos sin procesar cualquier documento que contenga información sobre el caso de uso del agente. Por ejemplo, si el agente es un planificador de viajes, se puede proporcionar un documento que contenga todas las ubicaciones junto con información sobre la ubicación como entrada al generador de datos que produce un conjunto de pares pregunta-respuesta que se pueden utilizar para evaluar a ese agente. Se pueden generar consultas de un solo salto (consultas que pueden responderse a partir de una única instancia de datos) o consultas de varios saltos (sólo pueden responderse a partir de varias fuentes).
Una muestra de la salida del generador:
|
1 2 3 4 5 6 |
{ "pregunta": "¿Cómo varían las normas de la casa en cuanto a niveles de ruido entre las opciones de alquiler disponibles en Hell's Kitchen, Manhattan?"., "respuesta": [ "Las normas de la casa para los niveles de ruido entre ......." ], } |
Pero esta solución tiene sus propias desventajas: los datos generados son indeterminados y siempre contendrán ruido en cierta medida. Además, se necesita un LLM realmente bueno para generar las mejores muestras, y estos LLM suelen consumir muchos recursos y son costosos.
Ejecutar el agente en la verdad sobre el terreno
Una vez que la verdad sobre el terreno está en su lugar, el siguiente paso es ejecutar el agente en este conjunto de datos. Ejecute el agente en los pares pregunta-respuesta creados por el generador, o en las verdades básicas de referencia anotadas manualmente y recupere el estado de salida, donde cada estado del agente está en el siguiente formato (este estado se registra por defecto si está utilizando marcos populares como LangGraph):
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 |
{ "pregunta": "¿Cuál es el precio del cobre?", "agente_respuestas": [ "El precio actual del cobre es de $0,0098 por gramo". ], "agent_tool_calls": [ { "nombre": "get_price", "args": { "item": "cobre" } } ], "agent_tool_outputs": [ "$0.0098" ], }, |
Pase esta salida del agente al modelo de datos (EvalDataset) para crear un conjunto de datos de oro (conjunto de datos dorado se refiere aquí al conjunto de datos que contiene todos los datos necesarios para la evaluación, es decir, la combinación de la salida del agente y la verdad básica sobre la que se ejecutó el agente). El framework incluye una clase LoadOperator para envolver y persistir estos datos. Garantiza que los conjuntos de datos sintéticos sean:
-
- Validación con respecto al esquema
- Versiones automáticas
- Almacenado en Couchbase con un significado dataset_description
Un componente clave en la recuperación y almacenamiento de datos es la LoadOperator. Maneja la entrada, almacenamiento y recuperación de conjuntos de datos de evaluación, abstrayendo los detalles del almacenamiento de Couchbase y exponiendo una interfaz limpia al resto del framework. Puedes cargar y recuperar el conjunto de datos de evaluación desde y hacia el almacén KV de Couchbase utilizando el comando dataset_id.
Crear y realizar un experimento
Una vez que tenemos las respuestas del sistema agentico (el conjunto de datos de oro), iniciamos un experimento (una única instancia gestionada de evaluación realizada en el conjunto de datos de oro) utilizando el marco con los datos de evaluación y un conjunto de opciones de experimento que consisten en las métricas (más sobre métricas en la siguiente sección) a utilizar y otra información relativa a su sistema agentico.
La gestión de experimentos en nuestro marco va más allá del mero registro de resultados, ya que proporciona un sistema completo y automatizado para el seguimiento de todos los aspectos de un proceso de evaluación. Cada experimento está vinculado a un conjunto de datos identificado de forma única, cargado y versionado con metadatos descriptivos y marcas de tiempo. Esto garantiza que cada conjunto de datos, ya sea sintético o real, pueda rastrearse y reutilizarse con total transparencia. Los parámetros configurables (p. ej., puntos de control del modelo, versiones de las instrucciones, cadenas de herramientas) también se almacenan junto con los resultados, creando un rastro de metadatos para cada ejecución.
El gestor de experimentos también le ofrece la posibilidad de iniciar una cadena de experimentos, en la que cada experimento sucesivo realiza un seguimiento de los cambios en el agente desde su experimento padre. Los experimentos se versionan utilizando Git, confirme su código y ejecute el experimento para desarrollar iterativamente sus agentes y comparar las evaluaciones realizadas en el mismo agente a través de las versiones. Los metadatos de cada experimento contienen registros de diferencias de código, métricas promediadas y configuraciones que pueden utilizarse para analizar si un cambio mejoró o no el sistema del agente. Además, todos los conjuntos de datos y experimentos utilizados en nuestro marco son versionables, consultables y escalables. Podemos almacenar grandes conjuntos de evaluación, recuperar subconjuntos para análisis específicos y rastrear metadatos como marcas de tiempo y descripciones de conjuntos de datos, lo que supone una enorme mejora con respecto a los flujos de trabajo basados en archivos planos, hojas de cálculo o documentos en memoria.
Persistir resultados en Couchbase
El resultado de un experimento consiste en archivos json y csv con instancias de datos y las puntuaciones correspondientes. A continuación se muestra un ejemplo de resultado para una conversación con un único agente (instancia de datos individual):
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 |
[ { "user_input": "¿Cuál es el precio del cobre?", "contextos_recuperados": null, "respuesta": null, "referencia": null, "agente_respuestas": [ "", "El precio actual del cobre es de $0,0098 por gramo". ], "agent_tool_calls": [ { "nombre": "get_metal_price", "args": { "nombre_del_metal": "cobre" } } ], "agent_tool_outputs": [ "0.0098" ], "reference_tool_calls": [ { "nombre": "get_metal_price", "args": { "nombre_del_metal": "cobre" } } ], "gt_answers": [ "", "El precio actual del cobre es de $0,0098 por gramo". ], "gt_tool_outputs": [ "0.0098" ], "respuesta_fidelidad": 3, "coherencia_lógica": 1.0, "agente_respuesta_correcta": 0.5 }, ] |
Los resultados se almacenan en el almacén KV de Couchbase con un ID de experimento. Los experimentos pueden recuperarse utilizando la función LoadOperatorque le permite consultar y comparar experimentos realizados durante una sesión diferente.
En resumen, con el marco, la ejecución de un experimento no es sólo una ejecución de script puntual. Es un proceso gestionado:
-
- Se carga o genera un conjunto de datos de la verdad sobre el terreno, que se versiona y describe
- Usted configura su agente y los parámetros de evaluación, todos los cuales se registran
- Usted ejecuta la evaluación y el marco almacena automáticamente los resultados, junto con todos los metadatos pertinentes.
- Más tarde, puede recuperar cualquier experimento, ver exactamente cuáles fueron los cambios realizados en el sistema, y compararlo con otras ejecuciones
- Este nivel de gestión de los experimentos es lo que hace que la evaluación deje de ser una "caja negra" para convertirse en un proceso transparente, repetible y colaborativo.
¿Cómo funciona?

Una arquitectura de nivel medio del marco
En el núcleo del marco hay cuatro componentes clave que trabajan juntos para producir los resultados finales.
Generador de datos sintéticos
El generador de datos crea pares sintéticos de pregunta-respuesta a partir de documentos. Estos pares de pregunta-respuesta pueden utilizarse como base para evaluar su sistema agéntico utilizando nuestro marco de trabajo. El generador de datos recibe documentos (CSV, JSON o texto sin formato) y aprovecha una base de datos de preguntas y respuestas. pocos disparos LLM afinado para generar los pares. El proceso de generación es el siguiente:
-
- Los documentos ingeridos se limpian y preprocesan
- A REBEL para extraer las relaciones entre entidades de cada documento. REBEL, un seq2seq modelo basado en BART que realiza la extracción de relaciones de extremo a extremo para más de 200 tipos de relaciones diferentes.
- Se crea un mapa entidad-relación para cada documento. Cada uno de estos mapas entidad-relación se incrusta utilizando el modelo de incrustación MiniLM-V2 (384 dim embeddings),
- Las incrustaciones de cada documento se agrupan utilizando algoritmos de agrupación de incrustaciones como HDBSCAN para obtener 'n' grupos de documentos semánticamente similares
- Estos clusters de documentos se proporcionan al LLM para generar pares de respuestas a consultas multisalto

Arquitectura del generador de datos sintéticos
También se puede proporcionar información adicional e instrucciones personalizadas si el usuario desea generar la consulta y las respuestas en un formato o estilo específico.
Conjunto de datos de evaluación
Estructura de datos central para la gestión de los datos de la verdad sobre el terreno. El sitio EvalDataset toma los datos reales y las salidas del agente (llamadas a la herramienta, respuestas del agente, etc.) y estructura los datos brutos en un formato fácil de procesar para el proceso de validación posterior. Transforma el conjunto de datos de oro (conjunto de datos que contiene la verdad sobre el terreno y las respuestas del agente para el mismo) en una lista de atributos que son importantes para la evaluación y pueden ser fácilmente procesados por el motor de validación. El conjunto de datos de evaluación creado tiene un ID de conjunto de datos que puede utilizarse para extraer el conjunto de datos del almacén de valores clave de Couchbase, eliminando la necesidad de almacenar y gestionar el conjunto de datos localmente.
Motor de validación
Procesa el conjunto de datos de evaluación y realiza la evaluación sobre el mismo. Conectado con un catálogo de métricas que proporciona a los usuarios todo un conjunto de métricas para evaluar todas y cada una de las partes del sistema agentic/RAG. El catálogo de métricas también está integrado con RAGAS, proporcionando a los usuarios la flexibilidad de utilizar las métricas de RAGAS si así lo requieren. El motor de validación calcula las métricas para el conjunto de datos de evaluación y combina los resultados para formar un marco de datos interpretable junto con un índice promediado que proporciona a los usuarios una idea de lo bueno que es el sistema en general.
Gestor de experimentos
Módulo central que conecta todos los demás componentes. Crea y gestiona experimentos de evaluación. Un experimento es una instancia individual de evaluación, que consiste en una salida detallada y metadatos, junto con capacidades de seguimiento de código para proporcionar a los usuarios una visión de los cambios que han hecho a su sistema agéntico entre dos experimentos.
El gestor de experimentos toma los datos de evaluación y un conjunto de opciones de experimento consistentes en las métricas a utilizar y otra información relativa a tu sistema agentico y se conecta al motor de validación para evaluar el conjunto de datos y obtener las puntuaciones calculadas. A continuación, las puntuaciones se procesan y formatean para producir un informe de evaluación junto con los metadatos del experimento, lo que permite inferir la evaluación y comparar diferentes experimentos.
El gestor de experimentos también ofrece a los usuarios la posibilidad de iniciar una cadena de experimentos, en la que cada experimento sucesivo realiza un seguimiento de los cambios en el agente desde su experimento padre. Esto permite a los usuarios desarrollar sus agentes de forma iterativa y comparar las evaluaciones realizadas sobre el mismo agente en distintas versiones. Los metadatos de cada experimento contienen registros de diferencias de código, métricas promediadas y configuraciones que pueden utilizarse para analizar si un cambio mejoró o no el sistema del agente.
Elegir las métricas adecuadas para su sistema agentico
A la hora de evaluar un sistema agentico, es fundamental seleccionar las métricas adecuadas para valorar con precisión su rendimiento. La elección de la métrica influye directamente en la forma de interpretar el resultado y realizar mejoras iterativas. Para los sistemas de IA, las métricas deben elegirse en función de las siguientes consideraciones:
Sistema Tipo
-
- Sistemas RAG: Se centra en las métricas de recuperación (precisión, recuerdo) y de generación (fidelidad, corrección de la respuesta).
- Sistemas agenéticos: Dar prioridad a la precisión de las llamadas, la coherencia lógica y la fidelidad de las respuestas.
Utilice Caso Requisitos
-
- Respuesta a la pregunta: Hacer hincapié en la corrección y pertinencia de las respuestas
- Recuperación de información: Centrarse en la precisión y la recuperación del contexto
- Tareas de razonamiento: Priorizar la coherencia lógica y la fidelidad
Técnico Consideraciones
-
- Coste de cálculo: Las métricas basadas en la incrustación pesan más que las basadas en tokens
- Dependencias de la API: Las métricas LLM-as-judge requieren acceso a la API
- Tratamiento por lotes: Algunas métricas permiten una evaluación eficaz por lotes
Para facilitarle el proceso anterior, éstas son cinco métricas que ofrecen la mejor visión general del rendimiento de su sistema de agenciamiento:
-
- Herramienta ctodos precisión: Evalúa si el agente utiliza las herramientas adecuadas con los parámetros correctos.
- Herramienta precisión: Compara los resultados de las herramientas con los resultados reales. Mide la precisión de las herramientas.
- Agente respuesta corrección: Evalúa la corrección de las respuestas de los agentes en comparación con la verdad sobre el terreno. Mide la calidad de la respuesta global del agente.
- Lógica coherencia: Evalúa el flujo lógico y el razonamiento en las respuestas de los agentes, ayuda a analizar la cadena de mando entre los agentes de un sistema y lo bien que trabaja cada agente entre sí para responder a la consulta del usuario.
- Respuesta fidelidad: Comprueba si la respuesta del agente es coherente con las salidas de la herramienta obtenidas por el agente.
La etapa final es el análisis: agregar resultados, calcular métricas y, sobre todo, comprender dónde y por qué ha fallado el agente. Aquí es donde la falta de estandarización y automatización en los pasos anteriores vuelve a atormentar al desarrollador. Depurar desajustes, rastrear errores hasta su origen e iterar sobre el agente o los datos es lento y propenso a errores.
Profundizar: interpretar eficazmente los resultados
Una vez seleccionadas las métricas adecuadas, realizado el experimento y obtenidos los resultados, ¿qué sigue? ¿Cómo dar sentido a los números aparentemente aleatorios que ha recopilado? La interpretación de estos resultados es un paso crucial para comprender el comportamiento y el rendimiento de su sistema. Existen varias estrategias eficaces para analizar los resultados, descubrir ideas y evaluar el impacto de los cambios realizados. Este paso transforma las métricas en bruto en conocimientos prácticos sobre los puntos fuertes y débiles de su agente, así como sobre las áreas susceptibles de mejora.
Técnicas de análisis comparativo
Cuando se comparan dos implementaciones o versiones de agentes diferentes:
Comparación de métricas
-
- Promedio de cada métrica en todos los casos de prueba para ambos agentes
- Calcular la mejora relativa entre sistemas (por ejemplo, "El agente B muestra una mejora de 12% en la precisión de la llamada a la herramienta con respecto al agente A").
- Utilice gráficos de radar para visualizar el panorama de rendimiento multidimensional
- Identificar los puntos fuertes complementarios (por ejemplo, "el Agente A destaca en la selección de herramientas, mientras que el Agente B produce respuestas más fieles").
Análisis por pares
-
- Comparar el rendimiento de consultas idénticas para identificar diferencias sistemáticas.
- Calcular el porcentaje de consultas en las que un agente supera al otro
- Identificar los tipos de consulta en los que las diferencias de rendimiento son más pronunciadas
Ejemplo de interpretación: "Aunque el Agente B tiene una mayor precisión media en las llamadas a herramientas (0,87 frente a 0,79), el Agente A obtiene mejores resultados en tareas de razonamiento complejas de varios pasos, lo que sugiere que el Agente B podría utilizar patrones más sencillos pero más fiables".
Enfoques de análisis de la distribución
Comprender la distribución de las puntuaciones de las métricas proporciona una visión más profunda que los promedios por sí solos:
Análisis de histogramas
-
- Trazar la distribución de las puntuaciones de cada métrica
- Identificar si el rendimiento sigue una distribución normal o muestra agrupación/bimodalidad.
- Comparación de la dispersión (varianza) entre distintas aplicaciones
Análisis de cuartiles
-
- Examinar los percentiles 25, 50 (mediana) y 75
- Una gran diferencia entre la mediana y el percentil 75 indica un rendimiento desigual.
- Centrar los esfuerzos de mejora en elevar el cuartil inferior
Ejemplo de interpretación: "La precisión de la herramienta de llamada del agente A tiene una distribución bimodal con picos en 0,4 y 0,9, lo que indica que funciona muy bien en algunos tipos de consulta pero tiene dificultades significativas en otros. El agente B muestra una distribución más estrecha centrada en 0,75, lo que indica un rendimiento más constante pero menos excepcional."
Análisis basado en umbrales
Establecer umbrales de rendimiento ayuda a cuantificar los porcentajes de éxito:
Cálculo del porcentaje de éxito
-
- Definir umbrales aceptables para cada métrica (por ejemplo, precisión de la llamada a la herramienta > 0,85).
- Calcular el porcentaje de muestras que superan cada umbral
- Determinar los umbrales más difíciles de alcanzar
Análisis multicriterio
-
- Definir el éxito como el cumplimiento de los umbrales en múltiples métricas simultáneamente.
- Calcular el porcentaje de muestras que cumplen todos los criterios
- Identificar los puntos de fallo más comunes
Ejemplo de interpretación: "Mientras que 78% de las respuestas del Agente A cumplen nuestro umbral de precisión de la herramienta de 0,9, sólo 62% cumplen simultáneamente nuestro umbral de fidelidad de la respuesta de 0,85. Esto sugiere que el agente produce ocasionalmente salidas correctas a través de caminos de razonamiento incorrectos. Esto sugiere que el agente ocasionalmente produce salidas correctas a través de rutas de razonamiento incorrectas."
Al aplicar estos enfoques analíticos a las métricas de los agentes, puede desarrollar una comprensión razonable del rendimiento de su sistema, tomar decisiones de mejora y establecer estándares de calidad fiables para su despliegue. Este análisis sistemático ayuda a ir más allá de las simples métricas para comprender realmente las capacidades y limitaciones del agente en diferentes contextos.
Ejemplo: evaluación de un agente de análisis de datos
Hemos probado este marco en un agente conversacional diseñado para responder a consultas basadas en datos almacenados en Couchbase. El agente recibe las preguntas de los usuarios, las envía a una herramienta NL2SQL++ que genera consultas SQL++ para obtener los documentos correspondientes del almacén, y genera una respuesta detallada y un informe de análisis de la pregunta del usuario utilizando los documentos recuperados.
Para nuestra evaluación, el agente se ejecutó en un conjunto de datos de listados de AirBNB que contiene los detalles de los listados de AirBNB en todo Estados Unidos. Se generaron preguntas y respuestas de referencia sobre las instancias de datos utilizando el generador de datos sintéticos. A continuación se muestra un ejemplo de pares de preguntas y respuestas generados por el generador de datos sintéticos:
|
1 2 3 4 5 6 7 8 9 10 |
[ { "pregunta": "¿Qué tipo de habitación se ofrece en la casa de apartamentos "limpia y tranquila" junto al parque?" "respuesta": "El tipo de habitación ofrecida en el anuncio "Clean and quiet apt home by the park" es una habitación privada. Esta conclusión se basa en los datos recuperados de los anuncios de Airbnb, donde se consultó la entrada específica de este nombre de anuncio para determinar el tipo de alojamiento ofrecido. Los datos indican claramente que el anuncio está clasificado como "habitación privada", lo que significa que los huéspedes dispondrán de un espacio privado dentro de una propiedad compartida". }, { "pregunta": "¿Cuál es la política de cancelación para el "Castillo Skylit Midtown"?" "respuesta": "La política de cancelación de "Skylit Midtown Castle" es moderada. Esta conclusión se extrae de los datos recuperados de los anuncios de Airbnb, donde se consultó la entrada específica de este nombre de anuncio para determinar las condiciones de cancelación. Los datos indican que el anuncio sigue una política de cancelación moderada, que normalmente permite una mayor flexibilidad en comparación con las políticas estrictas, ofreciendo a los huéspedes la posibilidad de cancelar dentro de un cierto plazo antes de la fecha de entrada para un reembolso completo." } ] |
Para este experimento se generó un conjunto de 40 pares de documentos de consulta. El agente se ejecutó en estas consultas generadas y el resultado se registró para crear el conjunto de datos de evaluación.
El conjunto de datos de evaluación (conjunto de datos dorados) consta de:
-
- Preguntas: Preguntas generadas sobre el conjunto de datos
- Respuestas correctas: Las respuestas de referencia (correctas) para las preguntas generadas.
- Contexto de referencia: La fuente de verdad a partir de la cual se generaron las consultas (resultados de la herramienta Ground truth).
- Contexto recuperado: Los documentos recuperados mediante la herramienta NL2SQL++ ejecutada en las consultas generadas (salidas de la herramienta).
- Respuestas del agente: Las respuestas del agente dada la consulta y el contexto recuperado.
Se creó un experimento con este conjunto de datos de evaluación utilizando 3 métricas: similitud semántica, precisión del contexto y relevancia de la respuesta. La similitud semántica mide la similitud entre los contextos recuperados y los de referencia. La precisión del contexto mide la exactitud de los contextos recuperados con respecto a la consulta y al contexto de referencia. La relevancia de la respuesta mide la pertinencia de la respuesta del agente con respecto a la consulta del usuario y el contexto recuperado.
A continuación se ofrecen las puntuaciones medias de las métricas junto con los metadatos del experimento en cuestión. Aquí, "promedio" se refiere a la media de cada métrica en todos los puntos de datos del conjunto de datos de evaluación:
|
1 2 3 4 5 6 7 8 9 10 11 12 13 |
{ "experiment_id":"experimento5", "timestamp":"2025-03-20T11:17:46.411457", "llm_model":"gpt-4o", "métricas":["similitud_semántica", "precision_contexto", "answer_relevancy"], "dataset_size":40, "dataset_id":"11b2d36a-4f00-40d2-bbe7-e614f4a77f1f", "avg_metrics":{ "similitud_semántica":0.85, "precision_contexto":0.99, "answer_relevancy":0.90, } } |
Una tabla de análisis de la calidad de las métricas puede ayudarnos a analizar el rendimiento general del agente en el conjunto de datos de la evaluación, utilizando un umbral para cada métrica y el número de puntos de datos que arrojaron una puntuación por encima del umbral dado.
| S.No | Métrica | Umbral | Muestras por encima del umbral | Número total de muestras | Precisión(%) |
| 1 | Similitud semántica | 0.70 | 40 | 40 | 100.00 |
| 2 | Contexto Precisión | 0.90 | 40 | 40 | 100.00 |
| 3 | Pertinencia de la respuesta | 0.70 | 37 | 40 | 92.50 |
En nuestra evaluación, NL2SQL++ demostró sistemáticamente un gran rendimiento, ya que las 40 muestras de prueba obtuvieron puntuaciones tanto de similitud semántica como de precisión contextual por encima del umbral predefinido. Esto indica que la herramienta capta con fiabilidad la intención del usuario y traduce con precisión las consultas en lenguaje natural a SQL estructurado.
El LLM encargado de generar las respuestas finales también obtuvo unos resultados excepcionales. Mientras que 37 de las 40 respuestas superaron el umbral métrico, las 3 restantes quedaron ligeramente por debajo. Esta pequeña desviación es de esperar, ya que los LLM generan de forma inherente secuencias de tokens novedosas en lugar de replicar el contenido de referencia línea por línea. A pesar de estas desviaciones, el modelo mantuvo una alta precisión en todas las respuestas, de lo contrario habríamos observado caídas más significativas de la métrica.
Se dispone de informes detallados de los experimentos para inspeccionar las muestras individuales, incluidas las que no alcanzaron el umbral, lo que permite saber cuánto se desviaron y las posibles razones.
Conclusión
Este marco se ha construido con el requisito básico de proporcionar a los usuarios un método persistente para evaluar los sistemas de IA en distintos dominios y casos de uso, simplificando la evaluación mediante el uso de un formato coherente para los datos, automatizando el manejo de datos y creando escenarios de ejemplo donde los reales son difíciles de recopilar. También hace un seguimiento de cada paso que da un agente, lo que ayuda cuando varios agentes trabajan juntos. En el futuro, esperamos que estas herramientas sigan mejorando, actualizando los casos de prueba a medida que cambien las necesidades del mundo real, generando informes fáciles de entender para todos e incluyendo comprobaciones para detectar sesgos o comportamientos inseguros. De este modo, nos aseguramos de que los agentes de IA sigan siendo fiables, transparentes y, lo que es más importante, acordes con las necesidades de los desarrolladores.