Como avaliar axentes de IA: conxuntos de probas, cualificadores e comprobacións de regresión

Detrás de todo gran produto de IA hai un sólido proceso de avaliación de axentes de IA, coñecido como evals, que detecta os erros cedo e garante o correcto funcionamento do axente. As evals son fundamentais para os axentes de IA que executan accións de alto risco, como reembolsos en nome doutra persoa.

Construír ese proceso require certos coñecementos técnicos e habilidades de análise de datos. Pero non é nin de lonxe tan intimidante nin inaccesible como podería parecer. Para axudarche a comezar, expuxemos seis pasos prácticos para avaliar axentes de IA e as ideas equivocadas máis comúns que estragan o proceso.

Que significa avaliar un axente de IA?

Avaliar un axente de IA significa valorar o seu rendemento á hora de completar tarefas correctamente e se as súas decisións cumpren os requisitos da organización. En termos prácticos, as avaliacións de axentes de IA, ou evals, son métricas específicas que axudan ás organizacións a determinar se o axente funciona con fiabilidade suficiente para o papel ao que está destinado.

Pensa nun axente de compras de IA nunha planta de fabricación que comproba o inventario de pezas de reposto e prepara solicitudes de reposición. Se unha peza aprobada non está dispoñible ou a información do provedor está desactualizada, sinalará o axente o problema ou recomendará un substituto non aprobado?

E se cambias o seu prompt do sistema para corrixir ese problema, como sabes que non introduciches outro?

Sen un proceso de avaliación, os xestores de produto, basicamente, só poden adiviñar. Por iso, as evals proporcionan un sinal de retroalimentación para medir o rendemento, detectar problemas recorrentes e probar cambios con maior confianza.

Dito isto, unha avaliación de axentes pode examinar varios aspectos dunha execución:

• A calidade do resultado final
• A información que utilizou o axente
• As ferramentas que chamou
• Se seguiu as regras que rexen o seu comportamento

Métricas habituais de avaliación de axentes de IA

As evals traballan con datos cualitativos e cuantitativos. A avaliación cualitativa axúdache a comprender que está a pasar e por que, o que inclúe revisar manualmente as decisións do axente. A avaliación cuantitativa converte esas observacións en sinais medibles, como contar a frecuencia de modos de fallo específicos ou calcular as taxas de éxito das tarefas.

Esta é a lista das métricas fundamentais de avaliación de axentes de IA:

• O éxito da tarefa mide se o axente conseguiu o resultado previsto; adoita medirse como a porcentaxe de execucións que producen resultados válidos.
• A corrección das accións mide se o axente utilizou as ferramentas de forma axeitada, seleccionou argumentos válidos e respectou os permisos.
• A calidade da resposta avalía se o resultado final é preciso, completo e útil. Pode incluír a exactitude factual, o cumprimento das instrucións e se o axente fundamenta as súas decisións coa información dispoñible.
• A fiabilidade mide a consistencia ao longo de ensaios repetidos, entradas variables e casos límite.
• O custo e a latencia miden os recursos necesarios para acadar un resultado satisfactorio, incluídos o tempo de execución, o consumo de tokens e as chamadas a ferramentas.

Dependendo do que esteas a medir, as evals poden avaliar o rendemento integral dun axente, a súa traxectoria de execución ou compoñentes individuais, como as chamadas a ferramentas e os pasos de recuperación.

Paso 1: decide como é unha execución satisfactoria do axente

Primeiro, describe de forma explícita o que se supón que debe lograr o axente: os requisitos do produto. Parece obvio, pero pode resultar sorprendentemente difícil. Mesmo ten un nome: a brecha de especificación.

Así é como recomenda abordalo Andrey Khomutov, o noso científico de datos sénior:

«Comeza con dúas preguntas: “Que contaría como facer o traballo?” e “Que faría que unha execución aparentemente satisfactoria resultase inaceptable?”

No caso dos axentes, desde unha perspectiva técnica, iso significa comprobar tanto o resultado como a forma en que os axentes chegaron a el.»

Un axente podería producir a resposta correcta accedendo a un solucionario filtrado ou realizar accións non autorizadas mentres completa a súa tarefa. Khomutov sinala que a filtración de respostas e as accións inseguras durante as avaliacións son motivos concretos para non xulgar só a resposta final.

«Espero que a inspección da traxectoria se converta nunha parte estándar dos conxuntos de evals de axentes, en lugar de algo que facemos só cando un resultado parece sospeitoso», engade.

Despois, implica unha persoa experta no dominio para validar os teus criterios de éxito. As persoas con coñecemento práctico do dominio poden dicir se as condicións que establecemos para un axente de IA reflicten un resultado satisfactorio.

Paso 2. Crea un conxunto de probas a partir de tarefas e fallos reais

Examina o comportamento real do axente para comprender como é un bo e un mal rendemento. Resiste a tentación de comezar xerando ducias de probas baseadas só no que cres que podería saír mal.

Hamel Husain, enxeñeiro de ML en Parlance Lab, e Shreya Shankar, investigadora de sistemas de ML e de evals de IA aplicada, recomendan comezar coa análise de erros, unha técnica tomada da aprendizaxe automática e da ciencia de datos. O proceso comeza cunha análise cualitativa das trazas de execución do axente: rexistros que mostran a entrada do usuario, as chamadas a ferramentas, a información recuperada e a saída do axente.

1. Revisa trazas individuais e anota os erros (codificación aberta). Pide a unha persoa experta no dominio que inspeccione as execucións do axente e escriba observacións breves sobre o que saíu mal. Céntrate no primeiro erro significativo.
2. Agrupa as observacións en modos de fallo (codificación axial). Cando teñas notas suficientes, usa un LLM para suxerir categorías para erros similares. Estas poderían incluír recomendacións de pezas incompatibles, recuperación inexacta do inventario e derivacións fallidas a persoas.
3. Conta as aparicións. Asigna cada observación a unha categoría e despois usa unha folla de cálculo ou unha táboa dinámica para calcular a frecuencia con que aparece cada modo de fallo.
4. Prioriza o que hai que abordar, tendo en conta tanto a frecuencia como a gravidade.
5. Converte os fallos importantes en casos de proba. Garda a entrada relevante, as condicións iniciais, o resultado esperado e os criterios de cualificación para poder volver probar o axente no mesmo escenario.

Cantas trazas deberías examinar? Arredor de 100, pero non hai un número máxico. Detente antes cando acades a saturación teórica: o punto no que revisar trazas adicionais deixa de revelar novos patróns de fallo significativos.

Aínda non lanzaches a aplicación? Os exemplos sintéticos poden axudar a crear un conxunto de probas inicial, aínda que os datos reais dos usuarios deberían alimentalo en canto estean dispoñibles.

O uso de benchmarks na avaliación de axentes de IA

Ademais de crear os teus propios casos de proba, podes usar coleccións existentes de tarefas de avaliación estandarizadas, coñecidas como benchmarks, para valorar as capacidades dos axentes.

Pero os benchmarks non son infalibles. As auditorías de SWE-bench, as revisións de benchmarks de Epoch AI e as respostas correctas rexeitadas inicialmente en TheoPhysEval ilustran como as tarefas ou as respostas esperadas defectuosas poden distorsionar os resultados da avaliación.

Tal como aconsella Khomutov, escolle benchmarks actualizados e relevantes para o teu dominio e investiga os aprobados ou suspensos sorprendentes antes de tratar as puntuacións como unha proba fiable do rendemento do axente.

Paso 3. Executa o axente nun contorno de probas reproducible

Un contorno de probas reproducible é unha configuración controlada na que podes executar un axente de IA cos mesmos casos de proba e nas mesmas condicións iniciais e comparar os resultados. Isto inclúe un cartafol de casos de proba, un script de Python que executa o axente ou un conxunto de comprobacións que avalían os resultados.

Podes comezar almacenando entradas representativas como ficheiros JSON e usando un script de Python para executar o fluxo de traballo do axente e comprobar as súas saídas con asercións. Para o axente de inventario da nosa planta de fabricación, un contorno de probas reproducible podería ter este aspecto:

Ampliar

Para configurar un contorno de probas reproducible, segue estes pasos:

1. Garda entradas representativas. Almacena eventos reais ou casos de proba coa mesma estrutura que recibe a túa aplicación en produción. No noso escenario, gardarías como ficheiro JSON unha solicitude de mantemento que contén o ID da máquina, a peza de reposto necesaria e a data de mantemento, xunto cunha instantánea do inventario e dos datos de pezas aprobadas.
2. Executa o fluxo de traballo. Pasa cada entrada polo axente, incluídos os seus pasos de recuperación, as chamadas a ferramentas e a xeración de respostas.
3. Rexistra o resultado e a traza. Captura a saída final e as accións intermedias relevantes (como as consultas de inventario) para poder ver non só se o axente fallou, senón onde.
4. Repite os casos segundo a gravidade e a frecuencia do fallo e a dificultade de corrixir o problema. As aplicacións de LLM son non deterministas (poden producir resultados diferentes a partir de entradas idénticas), polo que unha execución satisfactoria non garante que a seguinte tamén o sexa. Informa da proporción de ensaios satisfactorios e inspecciona os fallos.

Para isto último, Khomutov aconsella medir pass@1 (con que frecuencia ten éxito o axente nun único intento) e pass@k (a probabilidade de ter éxito polo menos unha vez nun número determinado de intentos). Se informas de pass@k, especifica o número de intentos, xa que producir unha resposta correcta entre varias non significa que o axente saiba cal escoller.

A medida que medre a túa aplicación, usa un marco de probas como pytest para organizar e executar as probas, e considera a posibilidade de almacenar nunha base de datos os conxuntos de datos de proba e os resultados de gran tamaño.

Paso 4. Escolle o cualificador axeitado para cada comprobación

Un cualificador (tamén chamado a miúdo avaliador) é un mecanismo, en forma de fragmento de código, de LLM guiado por unha rúbrica de cualificación ou de revisor humano, que comproba a saída ou a acción dun axente fronte a un criterio definido. Un cualificador devolve un xuízo de aprobado/suspenso e unha explicación que identifica as evidencias relevantes.

Información: Unha rúbrica de cualificación é un conxunto de criterios e instrucións que definen que se considera un resultado correcto ou aceptable.

O tipo de cualificador axeitado depende do que intentes verificar. Así se comparan os tres enfoques:

Ás veces, distintos aspectos dunha mesma execución poden requirir métodos de avaliación diferentes, polo que quizais necesites combinar cualificadores.

Como se combinan os cualificadores?

Pregúntaste: «Pódese verificar o resultado fronte a unha regra coñecida ou un valor esperado, ou require un xuízo de tipo humano?»

• Se podes verificar o resultado con exactitude, comeza cun cualificador baseado en código. Os cualificadores baseados en código tamén poden verificar saídas estruturadas, valores de campo válidos, argumentos de ferramentas ou o estado final dunha base de datos.
• Se a comprobación require interpretar o contexto, usa un LLM como xuíz.
• Recorre a revisores humanos para as decisións específicas do dominio ou en disputa.

Importante! Un cualificador LLM pode interpretar mal as evidencias ou aplicar unha rúbrica incorrectamente. Por iso necesita un paso de avaliación adicional: a calibración fronte a xuízos humanos.

Calibra o cualificador LLM fronte a xuízos humanos.

Basicamente, a calibración require que unha persoa experta no dominio valore execucións reais do axente. Despois, esa persoa compara os seus xuízos cos do LLM e perfecciona a rúbrica de cualificación a partir dos desacordos.

Este é un proceso de calibración do cualificador en cinco pasos:

1. Recompila exemplos de entradas, saídas e trazas relevantes do axente.
2. Pide a unha persoa experta no dominio que valore de forma independente se cada exemplo cumpre o criterio de avaliación.
3. Executa o cualificador LLM con eses exemplos.
4. Compara os xuízos humanos cos do modelo.
5. Investiga os desacordos e perfecciona a rúbrica do cualificador antes de probalo con novos exemplos.

Khomutov tamén subliña a importancia de probar por separado a consistencia do cualificador LLM:

«Dálle exactamente a mesma execución gardada e os mesmos ficheiros varias veces, sen volver executar o axente. Así podes separar a variación no traballo do axente da variación na cualificación.»

Se a mesma saída recibe veredictos diferentes, non deas por feito que todo cambio de puntuación se debe ao axente. En vez diso, examina unha matriz de confusión que mostre cando o cualificador identificou correctamente os erros, cando os pasou por alto e cando marcou incorrectamente saídas aceptables.

A revisión humana segue sendo esencial para establecer xuízos de referencia, resolver casos en disputa e descubrir novos modos de fallo que os cualificadores existentes non foron deseñados para detectar.

Paso 5. Compara versións e realiza comprobacións de regresión

Supón que a análise de erros revela que o teu axente de inventario recomenda con frecuencia pezas de substitución non aprobadas. Modificas o seu prompt do sistema para esixir unha comprobación explícita de compatibilidade. O caso que fallaba orixinalmente agora supera a proba. Pero como sabes que o cambio non afectou outras tarefas?

Aí é onde entran as probas de regresión.

As probas de regresión consisten en volver executar casos de proba que antes eran satisfactorios despois de cambiar o prompt, o modelo ou o fluxo de traballo dun axente, para garantir que o cambio non introduciu novos fallos.

1. Reproduce o fallo orixinal usando unha entrada gardada do conxunto de probas.
2. Fai un cambio específico no prompt, no modelo ou no fluxo de traballo.
3. Volve executar a proba que fallaba para comprobar se o problema se resolveu.
4. Executa as outras probas para comprobar que o cambio non estragou comportamentos que antes funcionaban correctamente.
5. Revisa os resultados e investiga calquera fallo novo.

Compara o axente de referencia e o actualizado empregando os mesmos casos de proba e criterios de cualificación para obter resultados precisos.

Paso 6: Supervisa o rendemento do axente de IA en produción

A avaliación de axentes non remata unha vez que despregaches a túa aplicación. Como explican Husain e Shankar, os mesmos avaliadores que empregas durante o desenvolvemento tamén se poden executar sobre datos reais de produción para medir como se comporta o teu axente co paso do tempo.

Isto coñécese como avaliación en liña e forma parte dun proceso máis amplo de supervisión en produción que axuda a detectar fallos recorrentes e outros ata entón descoñecidos.

O proceso é iterativo e consta de catro actividades complementarias:

• Executa xuíces LLM calibrados sobre trazas de produción. Toma mostras de interaccións reais do axente e aplica os avaliadores que xa validaches fronte a xuízos humanos.
• Fai un seguimento das taxas de fallo ao longo do tempo. Usa as categorías de fallo establecidas durante a análise de erros para cuantificar os problemas recorrentes.
• Continúa revisando trazas manualmente. Os cualificadores automáticos só detectan os problemas para os que foron deseñados. Inspecciona manualmente mostras de interaccións reais do axente para descubrir erros novos ou solicitudes pouco habituais dos usuarios.
• Usa probas A/B para medir resultados de negocio (só cando sexa axeitado). Compara distintos prompts, modelos ou fluxos de traballo con métricas como a finalización de tarefas, a satisfacción dos usuarios e o tempo de resolución. Este proceso axuda a determinar se un cambio mellora a experiencia real do produto, máis alá de superar probas individuais.

Unha observación importante: as avaliacións non teñen que estar pulidas á perfección. Abonda con que sexan o bastante boas para mellorar o teu produto.

Ideas erróneas habituais na avaliación de axentes de IA

• As avaliacións son só probas unitarias. Non o son; as probas unitarias son comprobacións pequenas e automatizadas que constitúen só unha parte da avaliación. As avaliacións tamén inclúen análise cualitativa de erros, xuízos humanos, supervisión en produción e experimentos para medir a calidade da aplicación.
• Unha plataforma de avaliación pode facelo todo por ti. As ferramentas listas para usar poden automatizar algunhas comprobacións, pero non poden determinar que modos de fallo (tipos de erros ou comportamentos non desexados do axente) importan para o teu produto.
• Podes deixar que un LLM o avalíe todo. Iso é unha gran falacia. A análise de erros dirixida por persoas e a calibración dos cualificadores seguen sendo esenciais, xa que os LLM carecen do contexto de negocio necesario para descubrir todos os problemas.
• As probas A/B ou simplemente usar o axente substitúen as avaliacións. Incorrecto. As probas A/B poden mostrar que versión funciona mellor segundo as métricas seleccionadas, pero non poden, por si soas, explicar os problemas subxacentes.

Preguntas frecuentes sobre a avaliación de axentes de IA

1. Cal é a diferenza entre a avaliación de axentes de IA e a avaliación de LLM?

A avaliación de LLM mide o ben que un modelo de linguaxe realiza unha tarefa determinada, como responder a unha pregunta, resumir un documento ou extraer información. A avaliación de axentes de IA avalía un sistema que executa de forma autónoma varios pasos para completar unha tarefa.

A diferenza dunha avaliación típica de LLM, a avaliación de axentes examina tanto o resultado final como a secuencia de accións realizadas para alcanzalo, incluídas as chamadas a ferramentas, as decisións e o cumprimento das regras predefinidas.

2. Métricas clave para a avaliación de axentes de IA

As métricas de avaliación de axentes de IA divídense en dúas grandes categorías:

• Métricas de rendemento técnico: taxa de éxito das tarefas, corrección das accións, calidade das respostas, fiabilidade (pass@1 e pass@k), latencia, uso de tokens e custo por tarefa completada con éxito.
• Métricas de negocio e de experiencia de usuario: satisfacción do cliente (CSAT), taxa de resolución de incidencias, taxa de escalado, taxa de conversión, tempo de finalización das tarefas e outros resultados específicos da función do axente.

Por exemplo, un axente de atención ao cliente podería avaliarse pola resolución satisfactoria de incidencias e a satisfacción do cliente, mentres que un axente de compras con IA podería medirse pola precisión das solicitudes de reposición, as taxas de aprobación e o tempo do ciclo de aprovisionamento.

As métricas axeitadas deben reflectir tanto a fiabilidade do rendemento do axente como se o seu traballo mellora os resultados de negocio.

3. Cales son as mellores ferramentas para avaliar axentes de IA?

Entre as opcións habituais están:

• Marcos de probas: as asercións de Python e pytest son útiles para executar casos de proba repetibles e comprobar condicións exactas, como se un axente seleccionou a ferramenta correcta ou devolveu un ID de peza válido.
• Marcos de avaliación de axentes de IA: DeepEval e o agent-eval toolkit de Google admiten avaliacións máis complexas, incluídas trazas de execución, cualificadores baseados en LLM e probas de regresión automatizadas.
• Plataformas de avaliación e observabilidade: LangSmith, Arize Phoenix e MLflow axudan os equipos a inspeccionar o comportamento dos axentes, xestionar conxuntos de datos de avaliación, comparar versións dos axentes e supervisar o rendemento en produción.

4. Como se automatizan as avaliacións de axentes de IA?

Podes automatizar as avaliacións de axentes de IA creando probas repetibles, aplicando cualificadores automáticos e integrando esas comprobacións nos fluxos de traballo de desenvolvemento e produción:

1. Crea un conxunto de datos de avaliación: recompila tarefas representativas dos usuarios, resultados esperados, fallos coñecidos e trazas de execución do axente. Inclúe casos límite como chamadas a ferramentas fallidas, información que falta e accións non autorizadas.
2. Automatiza a execución das probas e a cualificación: usa marcos como pytest ou DeepEval para executar casos de proba e aplicar comprobacións baseadas en código ou cualificadores LLM. Valida os cualificadores LLM fronte a xuízos humanos antes de confiar nas súas puntuacións.
3. Integra as avaliacións en CI/CD: volve executar automaticamente as probas de regresión cando os desenvolvedores actualicen os prompts, os modelos, as ferramentas ou o fluxo de traballo dun axente. Compara os resultados cunha versión de referencia e establece limiares de calidade que bloqueen o lanzamento de versións cando fallen comprobacións críticas.
4. Aplica cualificadores calibrados a mostras de trazas de produción, fai un seguimento das taxas de fallo e doutras métricas de rendemento e investiga os erros novos mediante revisión manual.