Mover los agentes de IA de los prototipos a la producción plantea un desafío que las pruebas tradicionales no pueden abordar. Los agentes son flexibles, adaptables y conscientes del contexto por diseño, pero las mismas cualidades que los hacen poderosos también hacen que sean difíciles de evaluar sistemáticamente.
Las pruebas de software tradicionales se basan en resultados deterministas: la misma entrada, el mismo resultado esperado, siempre. Los agentes de IA rompen esta suposición. Generan lenguaje natural, toman decisiones que dependen del contexto y producen resultados variados incluso a partir de entradas idénticas. ¿Cómo se evalúa sistemáticamente algo que no es determinista?
En esta publicación, mostramos cómo evaluar agentes de IA sistemáticamente utilizando Strands Evals. Analizamos los conceptos básicos, los evaluadores integrados, las capacidades de simulación de múltiples giros y los enfoques y patrones prácticos para la integración. Strands Evals proporciona un marco estructurado para evaluar agentes de IA creados con el SDK de Strands Agents, ofreciendo evaluadores, herramientas de simulación y capacidades de generación de informes. Ya sea que necesite verificar que su agente utilice las herramientas adecuadas, produzca respuestas útiles o guíe a los usuarios hacia sus objetivos, el marco proporciona infraestructura para medir y rastrear estas cualidades sistemáticamente.
Por qué evaluar los agentes de IA es diferente
Cuando le preguntas a un agente "¿Cómo está el clima en Tokio?", existen muchas respuestas válidas y ninguna es definitivamente correcta. El agente puede informar la temperatura en grados Celsius o Fahrenheit, incluir la humedad y el viento, o centrarse únicamente en la temperatura. Estas variaciones podrían ser correctas y útiles, que es exactamente la razón por la que las pruebas tradicionales basadas en afirmaciones se quedan cortas. Más allá de la generación de texto, los agentes también actúan. Un agente bien diseñado llama a herramientas, recupera información y toma decisiones a lo largo de una conversación. Al evaluar únicamente la respuesta final se pasa por alto si el agente tomó las medidas adecuadas para alcanzar esa respuesta.
Incluso las respuestas correctas pueden quedarse cortas. Una respuesta puede ser objetivamente precisa pero inútil, o útil pero infiel a los materiales originales. Ninguna métrica captura estas diferentes dimensiones de calidad. Las conversaciones añaden otra capa de complejidad porque se desarrollan con el tiempo. En interacciones de múltiples turnos, las respuestas anteriores afectan a las posteriores. Un agente puede manejar bien consultas individuales pero no lograr mantener un contexto coherente a lo largo de una conversación. Al probar giros individuales de forma aislada se pasan por alto estos patrones de interacción.
Estas características exigen una evaluación que requiere juicio en lugar de comparación de palabras clave. La evaluación basada en modelos de lenguaje grande (LLM) aborda esta necesidad. Al utilizar modelos lingüísticos como evaluadores, podemos evaluar cualidades como la ayuda, la coherencia y la fidelidad que resisten la verificación mecánica. Strands Evals adopta esta flexibilidad y al mismo tiempo ofrece evaluaciones de calidad rigurosas y repetibles.
Conceptos básicos de Strands Evals
Strands Evals sigue un patrón que debería resultar familiar para cualquiera que haya escrito pruebas unitarias, pero lo adapta para la evaluación basada en juicios que requieren los agentes de IA. El marco presenta tres conceptos fundamentales que funcionan juntos: casos, experimentos y evaluadores.
Figura: Arquitectura de alto nivel
Un caso representa un escenario de prueba único. Contiene la entrada que desea probar, tal vez la consulta de un usuario como "¿Qué tiempo hace en París?", junto con resultados esperados opcionales, secuencias de herramientas esperadas conocidas como trayectorias y metadatos. Los casos son la unidad atómica de evaluación. Cada uno define un escenario que desea que su agente maneje correctamente.
from strands_evals import Case case = Case( name="Consulta meteorológica", input="¿Cómo es el clima en Tokio?", expected_output="Debe incluir temperatura y condiciones", expected_trajectory=["weather_api"])
Un experimento agrupa varios casos junto con uno o más evaluadores. Piense en ello como un conjunto de pruebas en las pruebas tradicionales. El Experimento organiza el proceso de evaluación. Toma cada caso, ejecuta su agente en él y aplica los evaluadores configurados para calificar los resultados.
Los evaluadores son los jueces. Examinan lo que produjo su agente (el resultado real y la trayectoria) y lo comparan con lo que se esperaba. A diferencia de las simples comprobaciones de afirmaciones, los evaluadores de Strands Evals se basan principalmente en LLM. Utilizan modelos de lenguaje para emitir juicios matizados sobre calidad, relevancia, utilidad y otras cualidades que no pueden reducirse a una comparación de cadenas.
Separar estas preocupaciones ayuda a mantener el marco flexible. Puede definir qué probar con Casos, cómo probarlo con evaluadores y el marco maneja la orquestación y la generación de informes a través de Experimentos. Cada pieza se puede configurar de forma independiente para que pueda crear conjuntos de evaluación que se adapten a sus necesidades específicas.
La función de la tarea: conectar a los agentes con la evaluación
Los casos definen sus escenarios y los evaluadores emiten su criterio. Pero, ¿cómo se conecta realmente su agente a este sistema de evaluación? Ahí es donde entra en juego la función de tarea.
Una función de tarea es un elemento invocable que usted proporciona al experimento. Recibe un caso y devuelve los resultados de ejecutar ese caso a través de su sistema. Esta interfaz permite dos patrones de evaluación fundamentalmente diferentes.
Figura: Patrones de funciones de tareas
La evaluación en línea implica invocar a su agente en vivo durante la ejecución de la evaluación. Su función de tarea crea un agente, le envía la entrada del caso, captura la respuesta y el seguimiento de ejecución y los devuelve para su evaluación. Este patrón se recomienda durante el desarrollo cuando desea probar los cambios inmediatamente o en canalizaciones de integración y entrega continuas (CI/CD) donde necesita verificar el comportamiento del agente antes de la implementación.
de hilos importar Agente def tarea_en línea(caso): agente = Agente(herramientas=[herramienta_búsqueda, herramienta_calculadora]) resultado = agente(caso.entrada) return { "salida": cadena(resultado), "trayectoria": agente.sesión }
La evaluación fuera de línea funciona con datos históricos. En lugar de invocar a un agente, su función de tarea recupera rastros registrados previamente de registros, bases de datos o sistemas de observabilidad. Analiza estos rastros en el formato que esperan los evaluadores y los devuelve para su juicio. Este patrón funciona bien cuando necesita evaluar el tráfico de producción, realizar análisis históricos o comparar versiones de agentes con el mismo conjunto de interacciones de usuarios reales.
def offline_task(case): trace = load_trace_from_database(case.session_id) session = session_mapper.map_to_session(trace) return { "salida": extract_final_response(trace), "trayectoria": sesión }
Ya sea que esté probando la implementación de un nuevo agente o analizando meses de datos de producción, se aplican los mismos evaluadores e infraestructura de informes. La función de tarea adapta su fuente de datos al sistema de evaluación.
Evaluadores integrados para una evaluación integral
Con su función de tarea conectando la salida del agente al sistema de evaluación, ahora puede decidir qué aspectos de la calidad medir. Strands Evals se envía con diez evaluadores integrados, cada uno diseñado para evaluar una dimensión diferente de la calidad del agente.
Figura: Tipos de evaluador
Evaluadores basados en rúbricas
Los evaluadores más flexibles le permiten definir criterios personalizados a través de rúbricas en lenguaje natural.
OutputEvaluator juzga la respuesta final que produce su agente. Usted proporciona una rúbrica, una descripción de cómo se ve bien y los evaluadores usan un LLM para calificar el resultado según ese criterio. Esto funciona bien para controles de calidad generales en los que desea definir estándares específicos para su caso de uso. from strands_evals.evaluators import OutputEvaluator output_evaluator = OutputEvaluator( rubric="Puntuación 1,0 si la respuesta responde correctamente a la pregunta y está bien estructurada. " "Puntuación 0,5 si es parcialmente correcta. Puntuación 0,0 si es incorrecta o irrelevante". ) TrajectoryEvaluator extiende esto para examinar la secuencia de acciones (normalmente llamadas a herramientas) que realizó su agente. Más allá de simplemente mirar la respuesta final, puede verificar que el agente utilizó las herramientas adecuadas en un orden lógico. Los evaluadores incluyen tres funciones de puntuación integradas para comparar trayectorias reales versus esperadas: coincidencia exacta, coincidencia en orden y coincidencia en cualquier orden. Estos puntuadores se proporcionan como herramientas para la evaluación LLM, que elige el más adecuado en función de su rúbrica. InteractionsEvaluator maneja sistemas multiagente donde se comunican varios componentes. Evalúa secuencias de interacciones entre agentes o componentes del sistema. Esto es útil cuando su arquitectura involucra orquestadores, subagentes o cadenas de herramientas complejas.
Evaluadores semánticos
Algunas dimensiones de calidad son lo suficientemente comunes como para que Strands Evals proporcione a los evaluadores prediseñados indicaciones y escalas de puntuación cuidadosamente diseñadas.
HelpnessEvaluator evalúa las respuestas desde la perspectiva del usuario utilizando una escala de siete puntos que va desde "Nada útil" hasta "Más allá". Evalúa si la respuesta realmente responde a las necesidades del usuario, no sólo si es técnicamente correcta. FaithfulnessEvaluator comprueba si la respuesta se basa en el historial de conversaciones. Esto es particularmente importante para los sistemas de generación aumentada de recuperación (RAG), donde es necesario asegurarse de que el agente no alucine información. La escala de cinco puntos va desde “Para nada” fiel hasta “Totalmente sí”. HarmfulnessEvaluator realiza comprobaciones de seguridad, lo que ayuda a determinar si las respuestas contienen contenido dañino, inapropiado o peligroso. Proporciona juicios binarios de sí/no para una toma de decisiones clara.
Evaluadores a nivel de herramienta
Cuando su agente utiliza herramientas, a menudo es necesario evaluar no solo el resultado final, sino también la calidad de las invocaciones de herramientas individuales.
ToolSelectionAccuracyEvaluator examina cada llamada de herramienta en contexto y juzga si la selección de esa herramienta en particular estaba justificada dado el estado de la conversación. Responde: "En este punto de la conversación, ¿era razonable llamar a esta herramienta?" ToolParameterAccuracyEvaluator profundiza y verifica si los parámetros pasados a cada herramienta fueron correctos y apropiados. Ayuda a detectar errores sutiles en los que se eligió la herramienta correcta pero se utilizó con argumentos incorrectos o incompletos.
Evaluadores a nivel de sesión
GoalSuccessRateEvaluator adopta la visión más amplia y evalúa sesiones de conversación completas para determinar si el usuario finalmente logró su objetivo. Para los agentes orientados a tareas, el éxito se define por los resultados más que por una única respuesta.
Elegir a los evaluadores adecuados
La elección depende de lo que más importa para su aplicación. Un agente de servicio al cliente podría priorizar la amabilidad y el éxito de los objetivos. Un asistente de investigación podría enfatizar la fidelidad. Comience con un pequeño conjunto de evaluadores que cubran sus dimensiones principales de calidad, luego agregue más a medida que aprenda cómo falla su agente.
Simulación de usuarios para pruebas de múltiples turnos
Los evaluadores mencionados anteriormente funcionan bien para interacciones de un solo turno en las que usted proporciona una entrada, obtiene una salida y la evalúa. Las conversaciones de varios turnos presentan un desafío más difícil. Los usuarios reales no siguen guiones. Hacen preguntas de seguimiento, cambian de dirección y expresan confusión. ¿Cómo se prueba esto? Strands Evals incluye un ActorSimulator que crea usuarios simulados con tecnología de inteligencia artificial para impulsar conversaciones de varios turnos con su agente.
Figura: Flujo del simulador de usuario
ActorSimulator comienza con un caso de prueba que define lo que el usuario quiere lograr. A partir de esto, genera un perfil de usuario realista utilizando un LLM, que incluye rasgos de personalidad, nivel de experiencia, estilo de comunicación y un objetivo específico. Este perfil determina cómo se comporta el usuario simulado durante la conversación.
from strands_evals import Case, ActorSimulator from strands import Agent case = Case( input="Necesito ayuda para configurar una nueva cuenta bancaria", metadata={"task_description": "Abrir con éxito una cuenta corriente"} ) user_sim = ActorSimulator.from_case_for_user_simulator( case=case, max_turns=10 )
Durante la interacción, el usuario simulado envía mensajes a su agente, recibe respuestas y decide qué decir a continuación. Este ciclo continúa hasta que se logra el objetivo, indicado mediante la emisión de una ficha de parada especial, o hasta que se alcanza el recuento máximo de turnos.
agente = Agente(system_prompt="Eres un asistente bancario útil.") user_message = case.input while user_sim.has_next(): agent_response = agente(user_message) user_result = user_sim.act(str(agent_response)) user_message = str(user_result.structured_output.message)
Luego puede pasar la transcripción de la conversación resultante a evaluadores a nivel de sesión como GoalSuccessRateEvaluator para evaluar si su agente ayudó exitosamente al usuario simulado a lograr su objetivo. En lugar de escribir manualmente guiones de varios turnos, usted define objetivos y deja que el simulador cree patrones de interacción realistas. Podría plantear preguntas de seguimiento inesperadas, expresar confusión o llevar la conversación en direcciones que usted no anticipó, detectando casos extremos que las pruebas programadas pueden pasar por alto.
Niveles de evaluación: comprender la jerarquía
Ya sea que utilicen conversaciones simuladas o reales, diferentes evaluadores operan con diferentes granularidades. Strands Evals utiliza un TraceExtractor para analizar los datos de la sesión en el formato que cada evaluador necesita.
La evaluación a nivel de sesión analiza la conversación completa de principio a fin. El evaluador recibe el historial completo, las ejecuciones de la herramienta y comprende todo el contexto. GoalSuccessRateEvaluator funciona en este nivel porque determinar el logro de objetivos requiere comprender toda la interacción.
La evaluación del nivel de seguimiento se centra en turnos individuales, cada mensaje del usuario y par de respuestas del agente. Los evaluadores de este nivel reciben el historial de conversaciones hasta ese momento y juzgan la respuesta específica. Los evaluadores de utilidad, fidelidad y nocividad trabajan aquí porque estas cualidades se pueden evaluar paso a paso.
La evaluación a nivel de herramienta profundiza en las invocaciones de herramientas individuales. Cada llamada a una herramienta se evalúa en contexto, con acceso a las herramientas disponibles, la conversación hasta el momento y los argumentos específicos pasados. Los evaluadores de selección de herramientas y parámetros de herramientas operan con esta granularidad.
Puede utilizar el diseño jerárquico para componer conjuntos de evaluación que verifiquen la calidad en múltiples niveles simultáneamente. En una sola ejecución de evaluación, puede verificar que las llamadas a herramientas individuales sean sensatas, que las respuestas sean útiles y que se logren los objetivos generales.
Verdad fundamental y comportamientos esperados
En muchos niveles de evaluación diferentes, los evaluadores pueden beneficiarse de tener puntos de referencia para comparar. Strands Evals brinda soporte de primera clase para la verdad sobre el terreno a través de tres campos esperados en Casos.
El campo expected_output especifica lo que debe decir el agente. Esto es útil cuando hay respuestas correctas o formatos de respuesta estándar. El campo expected_trajectory define la secuencia de herramientas o acciones que el agente debe realizar. Es posible que necesite que un agente de servicio al cliente verifique el estado de la cuenta antes de realizar cambios, o que un agente de investigación consulte varias fuentes antes de sintetizar. No todos los casos necesitan todos los campos. Usted define las expectativas en función de lo que importa para sus objetivos de evaluación. Cuando se proporcionan los valores esperados, los evaluadores reciben los resultados esperados y reales, lo que permite una puntuación basada en comparaciones junto con una evaluación de calidad independiente.
Poniéndolo todo junto
Repasemos un flujo de trabajo de evaluación típico para ver cómo se combinan estos conceptos.
Figura: Flujo de evaluación
Primero, define sus casos de prueba, es decir, los escenarios que desea que su agente maneje bien. Pueden provenir de consultas de usuarios reales, generación sintética o casos extremos que haya identificado.
from strands_evals import Experiment, Case from strands_evals.evaluators import OutputEvaluator, TrajectoryEvaluator from strands_evals.extractors import tools_use_extractor cases = [ Case( name="Weather Query", input="¿Cómo es el clima en Tokio?", expected_output="Debe incluir temperatura y condiciones", expected_trajectory=["weather_api"]), Case( name="Calculadora Usage", input="¿Cuánto es el 15% de 847?", expected_output="127.05", expected_trajectory=["calculadora"] ) ]
A continuación, configura los evaluadores con rúbricas o configuraciones apropiadas.
output_evaluator = OutputEvaluator( rubric="Puntuación 1,0 si la respuesta es precisa y responde directamente a la pregunta." "Puntuación 0,5 si es parcialmente correcta. Puntuación 0,0 si es incorrecta o irrelevante." ) trayectoria_evaluator = TrajectoryEvaluator( rubric="Verifique que el agente haya utilizado las herramientas adecuadas para la tarea." )
Luego, crea un experimento que agrupa casos y evaluadores.
experimento = Experimento (casos = casos, evaluadores = [evaluador_salida, evaluador_trayectoria])
Finalmente, ejecuta la evaluación con su función de tarea y examina los resultados.
def mi_tarea(caso): agente = Agente(herramientas=[herramienta_climatológica, herramienta_calculadora]) resultado = agente(caso.entrada) return { "salida": str(resultado), "trayectoria": herramientas_uso_extractor.extract_agent_tools_used(agente.messages) } informes = experimento.run_evaluaciones(mi_tarea) para informe en informes: report.display()
El Informe de evaluación proporciona puntuaciones generales, desgloses por caso, estado de aprobación/reprobación y razonamiento detallado de cada evaluador. Puede mostrar los resultados de forma interactiva en la consola, exportarlos a JSON para realizar análisis adicionales o integrarlos en canalizaciones de CI/CD. Para conjuntos de pruebas más grandes, Strands Evals admite la evaluación asincrónica con paralelismo configurable:
informes = en espera de experimento.run_evaluaciones_async(my_task, max_workers=10)
Generando casos de prueba a escala
El flujo de trabajo anterior supone que tiene casos de prueba listos. Crear conjuntos de pruebas integrales a mano resulta tedioso a medida que crecen las capacidades de su agente. Strands Evals incluye un ExperimentGenerator que utiliza LLM para crear casos de prueba y rúbricas de evaluación a partir de descripciones de alto nivel.
from strands_evals.generators import ExperimentGenerator from strands_evals.evaluators import OutputEvaluator generador = ExperimentGenerator( input_type=str, output_type=str, include_expected_output=True ) experiment = await generador.from_context_async( context="Un agente de servicio al cliente para una plataforma de comercio electrónico", task_description="Manejar consultas de clientes sobre pedidos, devoluciones y productos", num_cases=20, evaluador=OutputEvaluator)
El generador crea diversos casos de prueba que cubren diferentes aspectos del contexto especificado, con niveles de dificultad adecuados. También puede generar rúbricas de evaluación que se adapten a la tarea. Los casos generados son particularmente valiosos durante el desarrollo inicial, cuando desea una cobertura amplia pero aún no ha identificado patrones de falla específicos. A medida que su práctica de evaluación madure, complemente los casos generados con escenarios hechos a mano dirigidos a casos extremos conocidos.
Integrar la evaluación en su flujo de trabajo
La evaluación ayuda a ofrecer el máximo valor como parte de su flujo de trabajo de desarrollo habitual. Durante el desarrollo, ejecute evaluaciones con frecuencia a medida que realiza cambios. La retroalimentación rápida lo ayuda a detectar regresiones tempranas y comprender cómo los cambios afectan las diferentes dimensiones de calidad.
En los procesos de CI/CD, incluya la evaluación como puerta de calidad antes de la implementación. Establezca umbrales de puntuación que deben cumplirse para que se apruebe una compilación. Esto ayuda a evitar que las regresiones de calidad lleguen a la producción. Para el seguimiento de la producción, utilice la evaluación fuera de línea para evaluar periódicamente las interacciones reales de los usuarios. Esto revela patrones que las pruebas de desarrollo podrían pasar por alto: consultas inusuales, casos extremos que no anticipó o cambios graduales en el comportamiento de los agentes. Realice un seguimiento de los resultados de la evaluación a lo largo del tiempo. Las métricas de tendencias le ayudan a comprender si la calidad está mejorando o degradándose.
Mejores prácticas para la evaluación de agentes
Comience poco a poco y repita: comience con un puñado de casos de prueba que cubran los escenarios de usuario más críticos. A medida que observe cómo su agente falla en la práctica, agregue casos específicos que aborden esos modos de falla específicos. Un conjunto de pruebas enfocado que detecte problemas reales es más valioso que un conjunto grande con poca cobertura. Haga coincidir los evaluadores con sus objetivos de calidad: elija evaluadores que midan directamente lo que importa para su caso de uso. Un agente de atención al cliente podría priorizar HelpnessEvaluator y GoalSuccessRateEvaluator, mientras que un asistente de investigación podría darle más importancia a FaithfulnessEvaluator. Evite la tentación de agregar a todos los evaluadores disponibles, ya que esto aumenta el costo y puede diluir el enfoque. Escriba rúbricas claras y específicas: los evaluadores basados en rúbricas son tan buenos como las rúbricas que usted proporciona. Evite criterios vagos como “buena respuesta” en favor de estándares específicos y mensurables. Incluya ejemplos de lo que constituye puntuaciones altas, medias y bajas. Pruebe sus rúbricas en resultados de muestra antes de ejecutar evaluaciones completas. Combine la evaluación en línea y fuera de línea: utilice la evaluación en línea durante el desarrollo para obtener comentarios rápidos sobre los cambios de código. Complemente esto con una evaluación fuera de línea de los seguimientos de producción para detectar problemas que solo aparecen con el comportamiento real del usuario. Los dos enfoques revelan diferentes tipos de problemas. Establezca umbrales significativos: defina umbrales de aprobación/rechazo basados en sus requisitos de calidad reales, no en números arbitrarios. Un umbral de 0,8 no significa nada si sus usuarios necesitan una precisión de 0,95. Analice los resultados de la evaluación para comprender qué puntuaciones se correlacionan con buenos resultados de los usuarios y luego establezca los umbrales correspondientes. Realice un seguimiento de las tendencias a lo largo del tiempo: las evaluaciones individuales proporcionan instantáneas, pero las tendencias revelan la trayectoria. Almacene los resultados de la evaluación y realice un seguimiento de las métricas clave en todas las versiones. La degradación gradual puede ser más difícil de notar que las fallas repentinas, pero igualmente dañina. Invierta en diversidad de casos de prueba: cubra toda la gama de entradas que encontrará su agente: consultas comunes, casos extremos, entradas contradictorias y conversaciones de varios turnos. Utilice ExperimentGenerator para obtener una cobertura amplia y luego complételo con casos hechos a mano dirigidos a debilidades conocidas. Evalúe en múltiples niveles: el éxito a nivel de sesión puede enmascarar problemas a nivel de herramienta y viceversa. Un agente puede lograr los objetivos del usuario mediante pasos intermedios ineficientes o incorrectos. Cree conjuntos de evaluaciones que verifiquen la calidad en los niveles de sesión, rastreo y herramienta para obtener una imagen completa.
Conclusión
Crear agentes de IA confiables requiere más que intuición y controles aleatorios. Requiere una evaluación sistemática que rastree la calidad en múltiples dimensiones a lo largo del tiempo. Strands Evals ayuda a proporcionar esta base a través de un marco diseñado específicamente para los desafíos únicos de la evaluación de agentes.
Las funciones de tareas separan la invocación del agente de la lógica de evaluación, lo que permite realizar pruebas en línea durante el desarrollo y análisis fuera de línea de los seguimientos de producción. Los evaluadores de LLM brindan el juicio que requiere la evaluación de calidad. Los niveles de evaluación jerárquica permiten la evaluación en múltiples granularidades, desde llamadas a herramientas individuales hasta sesiones de conversación completas. Y el simulador de usuario transforma las pruebas de varios turnos de un ejercicio de secuencias de comandos a una simulación realista del comportamiento del usuario.
Estas capacidades lo ayudan a generar confianza en sus agentes de IA a través de evidencia en lugar de suposiciones. Puede medir si los cambios mejoran o degradan la calidad, detectar regresiones antes de que lleguen a producción y demostrar a las partes interesadas que sus agentes cumplen con los estándares de calidad definidos.
Le animamos a explorar Strands Evals para sus necesidades de evaluación de agentes. El repositorio de muestras contiene ejemplos prácticos que puede adaptar a sus propios casos de uso. Comience con algunos casos de prueba que representen sus escenarios de usuario más importantes, agregue evaluadores que coincidan con sus criterios de calidad y ejecute evaluaciones como parte de su flujo de trabajo de desarrollo. Con el tiempo, amplíe su conjunto de pruebas para cubrir más escenarios. La evaluación sistemática es la base que le ayuda a enviar agentes de IA con confianza.
Acerca de los autores
Ishan Singh
Ishan Singh es científico aplicado sénior en Amazon Web Services, donde ayuda a los clientes a crear soluciones y productos de IA generativa innovadores y responsables. Con una sólida experiencia en IA/ML, Ishan se especializa en la creación de soluciones de IA generativa que impulsan el valor empresarial. Fuera del trabajo, le gusta jugar voleibol, explorar senderos para bicicletas locales y pasar tiempo con su esposa y su perro, Beau.
Akarsha Sehwag
Akarsha Sehwag es científica de datos de IA generativa para el equipo de Amazon Bedrock AgentCore. Con más de 6 años de experiencia en IA/ML, ha creado soluciones empresariales listas para producción en diversos segmentos de clientes en los dominios de IA generativa, aprendizaje profundo y visión por computadora. Fuera del trabajo, le gusta caminar, andar en bicicleta y jugar al bádminton.
Po-Shin Chen
Po-Shin Chen es un desarrollador de software que se centra en el desarrollo y las evaluaciones de IA agente en Amazon Web Services. Con experiencia en ingeniería y ciencia, su trabajo se centra en la creación de capacidades centrales para el marco agente (Strands SDK), liderando y desarrollando el marco de evaluación de agentes (Strands Evals).
Jonathan Buck
Jonathan Buck es ingeniero de software sénior en Amazon Web Services. Su trabajo se centra en la creación de entornos de agentes, evaluación e infraestructura posterior a la capacitación para respaldar la productización de sistemas de agentes.
Smeet Dhakecha
Smeet Dhakecha es ingeniero de investigación en Amazon y trabaja dentro del equipo científico de Agentic AI. Su trabajo abarca sistemas de evaluación y simulación de agentes, así como el diseño y la implementación de infraestructuras de procesos de transformación de datos para respaldar la investigación científica en rápido avance.