# Evals para verificar resultados de IA generativa en trabajo de información
> Lo del ***human-in-the-loop*** para evaluar lo que responde la IA no escala. Fue bonito mientras duró, pero hace falta un mecanismo automatizado para evaluar el resultado de la IA. La respuesta se llama **evals**, vienen del mundo de desarrollo de software, y están llegando rápido al trabajo de oficina. Esta investigación repasa la información que disponemos a julio de 2026, orígenes y evolución.
## Resumen ejecutivo
En 2026, “eval” ya no significa solo benchmark académico ni test de laboratorio. En la práctica profesional, el término se usa para tres cosas a la vez: comparar modelos con benchmarks públicos, medir outputs con métricas y, sobre todo, construir pruebas propias para comprobar si una aplicación o agente hace bien el trabajo concreto que se le pide. OpenAI lo explicita así en su guía de buenas prácticas, y Anthropic añade una definición más operativa para agentes: input, salida, lógica de grading, trazas, estado final y harness de ejecución. [1](https://developers.openai.com/api/docs/guides/evaluation-best-practices)
El cambio importante no es semántico, sino de objeto evaluado. Entre 2022 y 2024 la conversación giraba sobre capacidades generales y software: HELM, lm-evaluation-harness, OpenAI Evals, SWE-bench, pruebas de código y benchmarks de razonamiento. Desde 2024 y, sobre todo, en 2025-2026, el foco se ha desplazado hacia agentes y trabajo de información: soporte, investigación, operaciones, análisis documental, Office automation, tareas browser-based y entregables profesionales completos. Esa transición se ve en WorkArena, OfficeBench, TheAgentCompany, GDPval, JobBench y CollabSkill. [2](https://crfm.stanford.edu/2022/11/17/helm.html)
La conclusión práctica es simple: en equipos white-collar, un eval útil no debe preguntar “¿qué nota saca el modelo?”, sino “¿deja un artefacto de trabajo correcto, útil, revisable y seguro dentro de nuestro proceso real?”. Esa es justo la crítica de la literatura más reciente sobre benchmarks de conocimiento: muchos scores dicen menos de lo que parece sobre el trabajo real porque no representan bien la actividad, el entorno ni el producto de trabajo. [3](https://arxiv.org/html/2605.23262v1)
También hay una segunda conclusión, menos cómoda: la evaluación en conocimiento profesional no se puede automatizar del todo. OpenAI insiste en que las anotaciones humanas son la forma más eficaz de incorporar feedback; Anthropic recomienda calibrar cualquier judge automático con expertos; Databricks ha construido review apps y sesiones de labeling para capturar feedback de SMEs; y Microsoft, en su documentación en español sobre red teaming, advierte de no determinismo, falsos positivos y necesidad de revisión humana. [4](https://developers.openai.com/api/docs/guides/evaluation-getting-started)
La literatura de los últimos seis meses empuja en cuatro direcciones claras. Primera, pasar de evals de output a evals de workflow, con trazas, handoffs y outcomes persistentes. Segunda, complementar pruebas locales con macro-evals que agregan patrones de fallo a escala de sistema. Tercera, mover los benchmarks hacia tareas económicamente valiosas y colaborativas, no solo hacia autonomía plena. Cuarta, asumir que benchmark contamination, saturación, validez ecológica y ruido de infraestructura ya no son problemas marginales, sino centrales. [5](https://developers.openai.com/api/docs/guides/agent-evals)
*Las cuatro direcciones, en formato de antes y ahora:*
```mermaid
flowchart LR
N1(["1"]):::num ~~~ A1["Evals de output"] --> B1["Evals de workflow:<br/>trazas, handoffs y<br/>outcomes persistentes"]:::ahora
N2(["2"]):::num ~~~ A2["Solo pruebas locales"] --> B2["Locales + macro-evals:<br/>patrones de fallo<br/>a escala de sistema"]:::ahora
N3(["3"]):::num ~~~ A3["Benchmarks de<br/>autonomía plena"] --> B3["Tareas económicamente<br/>valiosas y colaborativas"]:::ahora
N4(["4"]):::num ~~~ A4["Contaminación, saturación,<br/>validez ecológica y ruido<br/>como problemas marginales"] --> B4["Reconocidos como<br/>problemas centrales"]:::ahora
classDef num fill:#7c5cbf,color:#fff,stroke:none,font-weight:bold
classDef ahora stroke:#7c5cbf,stroke-width:2px
```
Para adopción en equipos de información, la recomendación no es “montar un gran framework”, sino empezar con una capa mínima pero seria: trazado de ejecuciones, 20-50 casos reales o fallos reales, una combinación de graders deterministas y rubricados, revisión experta semanal, red teaming separado de la calidad funcional, y uso disciplinado de suites de regresión antes de cada cambio de prompt, modelo, herramienta u orquestación. Anthropic dice explícitamente que 20-50 tareas reales bastan para empezar; OpenAI recomienda eval-driven development y datos representativos de producción; y MLflow, Langfuse y LangSmith ya estructuran ese ciclo de manera bastante madura. [6](https://www.anthropic.com/engineering/demystifying-evals-for-ai-agents)
> [!info]- Ejemplo: un grader determinista y uno rubricado
> Supongamos que la IA debe producir un informe breve de investigación con citas.
>
> #### Grader determinista:
> Preguntas cerradas de sí o no, sin opinar. ¿La respuesta incluye al menos 3 citas con URL? ¿La cifra final coincide con la de referencia? ¿El fichero entregable existe? Mismo input, mismo veredicto siempre: pasa o no pasa.
>
> #### Grader rubricado:
> Una IA (o una persona) que puntúa con una rúbrica explícita, en vez de un "¿está bien?" a ojo:
>
> 1. Fidelidad: ¿todas las afirmaciones están respaldadas por las fuentes citadas? (1-5)
> 2. Cobertura: ¿responde a las tres preguntas del encargo? (1-5)
> 3. Accionabilidad: ¿la recomendación final es concreta y ejecutable? (1-5)
> 4. Revisabilidad: ¿un experto puede verificar cada dato sin rehacer la búsqueda? (1-5)
>
> Aprobado si ninguna dimensión baja de 3 y la media supera 4. En la práctica se combinan: el determinista filtra barato (si faltan las citas, ni se molesta al juez) y la rúbrica mide la calidad. Un experto humano revisa una muestra de vez en cuando para comprobar que el juez automático puntúa como lo haría él.
## Qué significa “Eval” hoy
OpenAI distingue tres usos del término “evals”: benchmarks de industria, métricas numéricas estándar y tests concretos que cada equipo diseña para su aplicación. Su guía deja claro que la parte decisiva para producción es la tercera: tests propios, diseñados contra distribuciones reales y ejecutados de forma continua. Anthropic, por su parte, define un eval como un test para un sistema de IA al que se le da una entrada y cuya salida se mide con lógica de grading; para agentes, además, esa evaluación debe contemplar trazas, estado final y harness. [1](https://developers.openai.com/api/docs/guides/evaluation-best-practices)
Esta diferencia es relevante porque en el trabajo de oficina el resultado casi nunca es una respuesta corta con una única solución correcta. Es un informe, una presentación, una tabla, una acción en un sistema, una recomendación con sus fuentes o una decisión documentada. Por eso, para saber si la IA lo ha hecho bien, no basta con mirar el texto que ha escrito: hay que mirar el trabajo entregado (el documento o la acción final) y, muchas veces, también el camino que siguió para llegar hasta ahí. OpenAI y Anthropic ya evalúan las dos cosas por separado: el proceso paso a paso y el resultado final. Y los estudios recientes sobre trabajo de conocimiento insisten en lo mismo: la nota debe puntuar el trabajo realmente entregado, no una aproximación abstracta que se le parezca.[7](https://developers.openai.com/api/docs/guides/agent-evals)
### Definiciones
| Término | Definición operativa | Importancia en el trabajo de oficina | Fuente |
| ------------------ | ------------------------------------------------------------------------------------------------------------- | ---------------------------------------------------------------------- | ---------------------------------------------------------------------------- |
| **Eval** | Test estructurado para medir el rendimiento de un sistema de IA sobre entradas y criterios de éxito definidos | Obliga a concretar qué significa “hacer bien el trabajo” | [8](https://www.anthropic.com/engineering/demystifying-evals-for-ai-agents) |
| **Task** | Caso o prueba individual con inputs y criterios de éxito | Debe representar una unidad real de trabajo | [9](https://www.anthropic.com/engineering/demystifying-evals-for-ai-agents) |
| **Trial** | Cada intento de resolver una task | La variabilidad de modelos obliga a repetir | [9](https://www.anthropic.com/engineering/demystifying-evals-for-ai-agents) |
| **Grader** | Lógica que puntúa una dimensión del desempeño | Puede ser determinista, model-based o humana | [10](https://www.anthropic.com/engineering/demystifying-evals-for-ai-agents) |
| **Transcript o trace** | Registro completo de llamadas, herramientas, pasos, handoffs y outputs intermedios | Permite diagnosticar por qué falla un workflow, no solo si falla | [11](https://developers.openai.com/api/docs/guides/agent-evals) |
| **Outcome** | Estado final del entorno tras la ejecución | En agentes importa más el resultado real que la afirmación del modelo | [12](https://www.anthropic.com/engineering/demystifying-evals-for-ai-agents) |
| **Evaluation harness** | Infraestructura que ejecuta, registra, puntúa y agrega evals | Se convierte en parte del objeto evaluado cuando el sistema es agentic | [13](https://www.anthropic.com/engineering/demystifying-evals-for-ai-agents) |
| **Regression eval** | Suite con casi 100% de pass esperado para evitar retrocesos | Es la barrera mínima antes de tocar prompt, modelo o herramientas | [14](https://www.anthropic.com/engineering/demystifying-evals-for-ai-agents) |
| **Capability eval** | Suite diseñada para capturar progreso en casos aún difíciles | Sirve para hill-climbing y priorización de mejoras | [14](https://www.anthropic.com/engineering/demystifying-evals-for-ai-agents) |
Hay una consecuencia práctica de estas definiciones: un buen eval de trabajo de información no es solo una pregunta-respuesta. Suele combinar contexto, archivos, herramientas, restricciones, una forma de entregable y una rúbrica de revisión. GDPval lo hace con entregables profesionales y comparación ciega con expertos; JobBench con workspaces heterogéneos y rúbricas encadenadas; Databricks con apps de revisión y feedback natural de SMEs. [15](https://openai.com/index/gdpval/)
## De dónde viene y cómo llega al trabajo de información (de ingeniería al white-collar)
El origen reciente de “evals” está en la cultura de benchmarking de modelos fundacionales. HELM, en 2022, ya planteaba evaluación holística con múltiples escenarios y métricas para capacidades y riesgos, precisamente porque los LLM son interfaces generales y no sistemas cerrados de tarea única. Poco después, herramientas como lm-evaluation-harness y OpenAI/evals consolidaron la idea de un framework reusable para correr muchas pruebas sobre muchos modelos. [16](https://crfm.stanford.edu/2022/11/17/helm.html)
La primera traslación al mundo del software fue bastante natural. El lenguaje de “eval-driven development”, “test-driven LLM development” y “BDD para prompts” aparece en OpenAI, Promptfoo y MLflow: la aplicación con IA se trata como algo demasiado no determinista para pruebas tradicionales, pero suficientemente importante como para no vivir de demos ni de intuiciones. Ahí el objeto evaluado seguía siendo, en gran parte, código, clasificación, extracción estructurada o asistentes relativamente acotados. [17](https://developers.openai.com/cookbook/examples/partners/eval_driven_system_design/receipt_inspection)
La segunda traslación, la importante para white-collar, llega cuando los sistemas dejan de ser “una llamada a un modelo” y pasan a ser agentes con herramientas, navegación, ficheros, handoffs y memoria. Anthropic lo formula así: los mismos rasgos que hacen útiles a los agentes - autonomía, inteligencia, flexibilidad - los hacen más difíciles de evaluar. OpenAI responde con *trace grading* (puntuar el recorrido completo del agente paso a paso, no solo su respuesta final) y *surfaces* diferentes (pantallas o vistas separadas en su plataforma) para los conjuntos de datos de pruebas, *traces* (los registros detallados de todo lo quehacen los agentes) y *eval runs* (cada pasada completa de las pruebas, para comparar resultados entre versiones). El vocabulario cambia: de *prompt* y *response* a *workflow* (flujo de trabajo), *trace* (registro), *outcome* (resultado de final del agente), *harness* (infraestructura de ejecución y pruebas) y *macro-eval* (análisis agregado de patrones de fallo). [18](https://www.anthropic.com/engineering/demystifying-evals-for-ai-agents)
El tercer movimiento es económico y ocupacional. OpenAI presenta GDPval para medir tareas económicamente valiosas en 44 ocupaciones; Anthropic introduce “economic primitives” como complejidad, skill level, propósito, autonomía y éxito; JobBench desplaza el foco desde reemplazo económico hacia delegación deseada por trabajadores; y CollabSkill pasa de la autonomía a la colaboración humano-agente. Ya no se evalúa solo si un modelo “sabe”, sino si contribuye de forma útil a trabajo administrativo, legal, financiero, sanitario, de soporte o de análisis. [19](https://openai.com/index/gdpval/)
> [!cite] Se evalúa si un modelo contribuye de forma útil al trabajo de oficina
*Evolución reciente de "eval" hacia trabajo de información:*
```mermaid
flowchart LR
subgraph S1 [" "]
direction TB
A["<b>2022</b><br/><br/>HELM plantea evaluación holística<br/>de capacidades y riesgos en LLMs"]
A --> B["<b>2023</b><br/><br/>OpenAI/evals y lm-evaluation-harness<br/>consolidan frameworks reutilizables"]
B --> C["<b>2024</b><br/><br/>WorkArena y OfficeBench llevan la evaluación<br/>a knowledge workers y office automation<br/>···<br/>tau-bench introduce interacción<br/>agente-herramienta-usuario con reglas de dominio"]
end
subgraph S2 [" "]
direction TB
D["<b>2025</b><br/><br/>OpenAI impulsa eval-driven system design<br/>para workflows autónomos<br/>···<br/>TheAgentCompany y GDPval miden tareas<br/>profesionales y económicamente valiosas"]
D --> E["<b>2026</b><br/><br/>Anthropic formaliza traces, outcomes<br/>y harnesses para agentes<br/>···<br/>Macro-evals, JobBench y CollabSkill: foco en workflows,<br/>delegación y colaboración humano-agente<br/>···<br/>Saturación, contaminación, ruido de<br/>infraestructura y validez ecológica, al centro del debate"]
end
S1 ~~~ S2
style S1 fill:none,stroke:none
style S2 fill:none,stroke:none
```
La línea temporal reciente también muestra un matiz interesante. En paralelo al avance técnico, el ecosistema ha empezado a corregirse a sí mismo: papers sobre *knowledge-work benchmark design*, *real-world work alignment*, *contamination detection & saturation* están diciendo que muchas métricas heredadas de NLP o de coding no bastan para hacer evaluaciones serias sobre trabajo profesional. Esto no invalida los evals; los obliga a madurar. [20](https://arxiv.org/html/2605.23262v1)
## Metodologías que sí sirven
La práctica actual converge en una idea sana: ningún método de evaluación basta por sí solo. Los equipos que funcionan combinan varias capas. OpenAI recomienda mezclar casos reales del día a día, casos preparados por expertos, casos raros o extremos y casos diseñados a propósito para hacer fallar al sistema. Anthropic propone combinar tres tipos de corrector: programas que comprueban hechos verificables, IAs que puntúan siguiendo una rúbrica y personas. Y herramientas como MLflow recogen las correcciones de los revisores humanos para que los correctores automáticos no se desvíen del criterio de los expertos. [21](https://developers.openai.com/api/docs/guides/evaluation-best-practices)
### Comparativa de metodologías
| Metodología | Qué mide bien | Dónde encaja mejor | Ventaja fuerte | Riesgo principal | Fuente |
| ---------------------------- | ------------------------------------------------------------------------- | --------------------------------------------------------------------- | ---------------------------------------------- | --------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------ |
| Revisión humana con SMEs | Utilidad real, criterio de negocio, matices y calidad profesional | Legal, finanzas, compliance, investigación, soporte complejo | Es el estándar de referencia | Cara, lenta, difícil de escalar | [22](https://developers.openai.com/api/docs/guides/evaluation-best-practices) |
| Benchmarks públicos | Comparación externa y tracking de progreso general | Selección inicial de modelo y benchmarking sectorial | Reproducibles y comparables | Poca validez local, saturación y contaminación | [23](https://developers.openai.com/api/docs/guides/evaluation-best-practices) |
| Suites internas de regresión | Estabilidad tras cambios de prompt, modelo o herramientas | Operación continua y releases | Detectan backsliding | Falsas seguridades si la suite no se renueva | [24](https://www.anthropic.com/engineering/demystifying-evals-for-ai-agents) |
| Métricas deterministas | Correctitud verificable, formato, tool use, tests, estado final | Extracción, structured outputs, código, workflows con outcomes claros | Baratas, rápidas, objetivas | Se rompe con facilidad ante soluciones válidas no previstas | [10](https://www.anthropic.com/engineering/demystifying-evals-for-ai-agents) |
| LLM-as-a-judge | Calidad semántica, adecuación a rúbrica, comparación entre respuestas | Tareas abiertas con deliverables textuales o mixtos | Escala mejor que humanos | Sesgos, no determinismo, necesidad de calibración | [25](https://developers.openai.com/api/docs/guides/evaluation-best-practices) |
| Trace grading | Problemas de workflow, handoffs, uso de herramientas y fallos intermedios | Agentes y sistemas multi-step | Diagnóstico causal mejor que black-box | Más complejidad de instrumentación | [26](https://developers.openai.com/api/docs/guides/agent-evals) |
| Macro-evals | Patrones agregados de fallo y riesgo a escala de sistema | Multi-agent, operaciones con volumen, revisión de política | Conecta señales locales con impacto de negocio | Requiere buena telemetría previa | [27](https://developers.openai.com/cookbook/examples/partners/macro_evals_for_agentic_systems/macro_evals_for_agentic_systems) |
| Red teaming | Vulnerabilidades, bypasses, prompt injection, exfiltración, misuse | Antes de despliegue y tras cambios de arquitectura | Destapa fallos que la QA funcional no ve | Falsos positivos, baja representatividad de entornos sintéticos | [28](https://developers.openai.com/api/docs/guides/red-teaming) |
### Qué cambia al pasar de software a trabajo de información
En software, hablamos de artefactos propios de ingenierios como unit tests, linters, compilación, ejecución, pass/fail y, a veces, pass@k. **En información y conocimiento, el producto es más ambiguo**. Un documento legal puede ser razonable aunque no coincida palabra por palabra con el de referencia; una nota de investigación puede ser útil aunque siga una ruta distinta; una respuesta a RR.HH. puede ser formalmente correcta y, aun así, mala para la experiencia del empleado. Por eso Anthropic recomienda “*grade what the agent produced, not the path it took*” cuando el cumplimiento rígido del procedimiento castiga creatividad válida, y sugiere crédito parcial para tareas con varios componentes. [9](https://www.anthropic.com/engineering/demystifying-evals-for-ai-agents)
La consecuencia metodológica es que en white-collar conviene diseñar la evaluación alrededor de cuatro capas.
- Primera, outcome verificable cuando exista.
- Segunda, calidad del artefacto con rúbrica explícita.
- Tercera, trazas para entender errores de proceso.
- Cuarta, revisión humana para calibración y edge cases.
OpenAI y Anthropic coinciden en esa mezcla, y Databricks la ha convertido ya en producto: misma configuración de *judges* (IA configurada como corrector) y métricas para evaluación offline y monitorización online, más apps de revisión para stakeholders y SMEs. [29](https://developers.openai.com/api/docs/guides/agent-evals)
### Métricas que habría que usar con cuidado y criterio
Las métricas automáticas tradicionales siguen siendo útiles en tareas acotadas: exact match, regex, tests binarios, validación de JSON o verificación de herramientas (conceptos que vienen de la ingeniería de software).
OpenAI añade métricas de memoria del contexto (*context recall*: ¿la IA recuperó toda la información relevante?) y de precisión del contexto (*context precision*: ¿lo recuperado era realmente relevante?), además de métricas para salidas estructuradas (*structured outputs*, como JSON o tablas), pensadas para sistemas que buscan en documentos antes de responder (RAG) y para extracción de datos. Anthropic enumera comprobaciones de coincidencia de texto (*string match*), verificación del resultado final (*outcome verification*), llamadas a herramientas (*tool calls*) y métricas sobre el registro completo de la ejecución (*transcript metrics*). Promptfoo combina comprobaciones literales (*assertions*) con correctores que puntúan por rúbrica (*judges*). Y Microsoft Foundry mide la tasa de éxito de los ataques (*attack success rate*) en las pruebas de intrusión (*red teaming*). [30](https://developers.openai.com/api/docs/guides/evaluation-best-practices)
La métrica errónea para white-collar no es una métrica “mala”, sino una métrica desalineada. *ROUGE* puede servir para una primera aproximación en resúmenes, pero no para asegurar que una política interna está bien interpretada. *Exact match* sirve para una cifra final, pero no para determinar si un analista dejó una evidencia revisable. La literatura reciente sobre benchmarks de trabajo de oficina insiste precisamente en eso: definir la actividad, el entorno de trabajo y el producto entregado antes de elegir la forma de puntuar. [31](https://developers.openai.com/api/docs/guides/evaluation-best-practices)
## Herramientas y plataformas
Aquí habría que separar tres capas: herramientas para benchmark research, herramientas para evals de aplicación y herramientas para red teaming/safety. Mezclarlas confunde más que ayuda. En 2026 el ecosistema también se está reordenando: OpenAI ha deprecado su plataforma gestionada de evals y recomienda migración a Promptfoo para seguir y extender workflows de evaluación en local o CI. Eso no invalida el repositorio open-source openai/evals, que sigue existiendo como framework y registro de benchmarks, pero sí cambia la recomendación práctica para equipos nuevos. [32](https://developers.openai.com/api/docs/guides/evals)
### Comparativa de herramientas
> [!note] Nota
> Esta sección la dejo cerrada por defecto porque, para esta investigación, me interesan poco las herramientas técnicas, más aplicables a la ingeniería de software que al trabajo de oficina
> [!example]- Tabla comparativa de herramientas y conclusiones
>
>
>
> |Herramienta|Tipo|Qué hace mejor|Encaje en white-collar|Limitación relevante|Fuente|
> |---|---|---|---|---|---|
> |OpenAI evaluate agent workflows|Plataforma gestionada para traces, graders, datasets y eval runs|Instrumentación y grading de workflows agentic|Útil si ya trabajas dentro del stack OpenAI|La Evals platform gestionada está en retirada; no todas las piezas sobreviven igual|[33](https://developers.openai.com/api/docs/guides/agent-evals)|
> |openai/evals|Framework open-source y registro de evals|Baseline reusable y evals custom|Bueno como referencia histórica y técnica|No es el camino gestionado recomendado en 2026|[34](https://github.com/openai/evals)|
> |openai/simple-evals|Librería ligera de benchmarks|Transparencia en resultados publicados|Útil para benchmarking de capacidad general|El propio repo indica que dejó de actualizarse para nuevos modelos en julio de 2025|[35](https://github.com/openai/simple-evals)|
> |Promptfoo|CLI open-source para evaluaciones y red teaming|Config portable, CI/CD, assertions + judges, red teaming|Muy buen ajuste para equipos de producto y operaciones|Requiere disciplina de configuración y ownership técnico|[36](https://www.promptfoo.dev/docs/intro/)|
> |MLflow Agent Evaluation|Plataforma de evaluación, tracing y monitorización|Evaluation-driven development, feedback humano, judges y producción|Fuerte en organizaciones con stack de datos/ML maduro|Parte de la experiencia completa se articula mejor en Databricks|[37](https://mlflow.org/docs/latest/genai/eval-monitor/)|
> |LangSmith|Observabilidad y evaluación de apps/agentes|Evaluar agentes desde SDK, datasets y experiments|Práctico para equipos con LangChain u orquestación propia|La documentación consultada no especifica un marco ocupacional propio|[38](https://docs.langchain.com/langsmith/evaluate-llm-application)|
> |Langfuse|Observability + eval sobre observations, traces y experiments|Separar evaluación de operaciones individuales y workflows completos|Bueno para monitorizar producción con judges|Requiere diseño propio de métricas y datasets|[39](https://langfuse.com/docs/evaluation/overview)|
> |DeepEval|Framework open-source de evaluación|Integraciones amplias y foco developer|Útil para equipos que quieren tests en código desde el primer día|La fuente revisada no detalla criterios sectoriales específicos|[40](https://github.com/confident-ai/deepeval?utm_source=chatgpt.com)|
> |lm-evaluation-harness|Benchmark harness de investigación|Comparación de modelos en muchas tareas|Útil para selección base de modelo|Débil para workflows profesionales complejos|[41](https://github.com/EleutherAI/lm-evaluation-harness)|
> |LightEval|Toolkit de evaluación multi-backend|Evaluación sample-by-sample y debugging|Interesante para equipos research o open-source|Más orientado a evaluación de modelo que a operación de trabajo|[42](https://huggingface.co/docs/lighteval/index)|
> |Inspect AI|Framework de frontier evaluations|Tareas, scorers, logs, sandbox y evals complejas|Bueno para evaluaciones más rigurosas y reproducibles|Más exigente de operar que una simple librería de tests|[43](https://inspect.aisi.org.uk/)|
> |PyRIT|Red teaming open-source|Identificación proactiva de riesgos en GenAI|Adecuado para security teams y validación previa a despliegue|No sustituye revisión humana ni pruebas funcionales|[44](https://github.com/microsoft/PyRIT)|
> |garak|Vulnerability scanner para LLMs|Hallucination, leakage, prompt injection, jailbreaks|Bueno como capa de security scanning|No evalúa por sí solo utilidad de negocio|[45](https://github.com/NVIDIA/garak)|
>
> Dos observaciones importan aquí. La primera: las herramientas ganadoras no son necesariamente las más sofisticadas, sino las que se integran con el ciclo real de trabajo. Promptfoo empuja a evals portables junto al código; MLflow y Databricks llevan evaluación y feedback al ciclo de desarrollo y operación; Langfuse y LangSmith empujan fuerte en traces. El patrón común es trazabilidad, dataset versionado, comparación entre runs y posibilidad de feedback humano. [46](https://www.promptfoo.dev/docs/intro/)
>
> La segunda: hay poca estandarización completa entre plataformas. En la documentación revisada no queda especificado de forma homogénea el detalle exacto de los judge prompts, los criterios de calibración contra humanos o la comparabilidad directa entre scores de distintos proveedores. Eso no es un defecto menor. Significa que la portabilidad de la disciplina de evaluación es hoy mejor que la portabilidad de los números. [47](https://mlflow.org/docs/latest/genai/eval-monitor/)
>
> Cuando existen recursos en español, hoy aparecen más en el perímetro de plataforma y gobernanza que en la teoría de evals. Microsoft Learn documenta en español el agente de red teaming y advierte de no determinismo, falsos positivos y necesidad de revisión humana, y también ofrece documentación en español sobre MLflow/Databricks y evaluación/observabilidad de agentes. Esa oferta existe, pero sigue siendo bastante menos abundante que la documentación primaria en inglés. [48](https://learn.microsoft.com/es-es/azure/foundry/concepts/ai-red-teaming-agent)
>
## Qué está pasando ya en el trabajo white-collar
La mejor prueba de que “eval” ha entrado en trabajo de información no es un manifiesto, sino el tipo de benchmarks y productos que han aparecido. ServiceNow define WorkArena como tareas browser-based para medir la eficacia de agentes en rutinas de trabajo de oficina. OfficeBench evalúa automatización de trabajo de oficina entre Word, Excel, PDF, Calendar y Email. TheAgentCompany modela a un “digital worker” que navega la web, escribe código, ejecuta programas y se comunica con compañeros. GDPval toma 44 ocupaciones y deliverables reales de expertos. JobBench da otro paso y prioriza lo que los trabajadores quieren delegar, no solo lo que tiene valor económico. [49](https://servicenow.github.io/WorkArena/)
Anthropic aporta dos señales complementarias. Desde el lado del producto, su sistema multi-agent de research muestra que la evaluación de búsqueda de información en Internet e investigación profunda ya se piensa en términos de tareas de alto valor, capacidad de paralelización, trazas y viabilidad económica; el sistema ha mejorado frente al agente único, pero a costa de mucho más consumo de tokens. Desde el lado macro, el Economic Index ya mide uso de IA en trabajo con variables como complejidad, nivel de habilidad, autonomía y éxito, y enlaza encuestas con uso real en casi 9.700 usuarios conectados. [50](https://www.anthropic.com/engineering/multi-agent-research-system)
Microsoft ofrece el correlato organizativo. Su Work Trend Index habla de “human-agent teams” y del nuevo rol de “agent boss”, sobre una encuesta de 31.000 knowledge workers en 31 mercados. Es decir, la transición cultural ya se está nombrando desde la propia empresa que domina gran parte del stack de productividad corporativa. Ese lenguaje importa porque cambia quién debe participar en los evals: ya no basta con ingeniería; hacen falta negocio, operaciones y SMEs. [51](https://www.microsoft.com/en-us/worklab/work-trend-index/breaking-down-infinite-workday)
### Señal cuantitativa reciente
Los datos recientes apuntan en una dirección bastante clara: incluso en benchmarks diseñados para trabajo profesional, la autonomía útil sigue siendo parcial y desigual. WorkArena reporta 42,7% de éxito con su mejor configuración sobre tareas de knowledge workers; OfficeBench reporta 47,0% para GPT-4 Omni; TheAgentCompany reporta 30% de tareas completadas autónomamente por el agente más competitivo; Workspace-Bench-Lite muestra una media del 47,4% frente al 80,7% humano; y JobBench sitúa al mejor sistema en 45,9%. Esto no describe fracaso. Describe una zona intermedia en la que la IA ya sirve, pero todavía necesita diseño de entorno, evaluación y supervisión seria. [52](https://servicenow.github.io/WorkArena/?utm_source=chatgpt.com)
| Benchmark o estudio | Qué intenta representar | Resultado destacado | Lectura útil para equipos white-collar | Fuente |
| ------------------- | ------------------------------------------------------ | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------- | -------------------------------------------------------------------- |
| WorkArena | Tareas browser-based de knowledge workers | 42,7% de éxito con la mejor configuración | Los agentes ayudan, pero están lejos de automatización robusta | [53](https://servicenow.github.io/WorkArena/?utm_source=chatgpt.com) |
| OfficeBench | Office automation multiaplicación | 47,0% de éxito para GPT-4 Omni | Coordinar varias apps sigue siendo un cuello de botella | [54](https://arxiv.org/html/2407.19056v1?utm_source=chatgpt.com) |
| TheAgentCompany | “Digital worker” en una empresa simulada | 30% de tareas autónomas en el mejor agente | Buena parte del trabajo largo y contextual sigue fuera de alcance | [55](https://arxiv.org/abs/2412.14161) |
| Workspace-Bench | Workspaces reales con dependencia entre ficheros | 47,4% medio frente a 80,7% humano | El contexto organizativo y de archivos complica mucho más que una task aislada | [56](https://arxiv.org/html/2605.03596v1?utm_source=chatgpt.com) |
| GDPval | Deliverables económicamente valiosos en 44 ocupaciones | Claude Opus 4.1 queda “as good as or better than” humanos en algo menos de la mitad de las tasks; además, las tareas son 100x más rápidas y 100x más baratas en inferencia pura | La IA compite bien en tareas bien especificadas, pero el dato no incluye supervisión e integración real | [57](https://openai.com/index/gdpval/) |
| JobBench | Workflows que los trabajadores sí quieren delegar | 45,9% para el sistema más fuerte | El criterio de delegación humana cambia qué merece evaluarse | [58](https://arxiv.org/html/2605.26329v1) |
| CollabSkill | Colaboración humano-agente en trabajo real | Las clasificaciones difieren de benchmarks autónomos y el skill práctico humano importa mucho | Evaluar solo autonomía da una foto incompleta | [59](https://arxiv.org/abs/2606.09833?utm_source=chatgpt.com) |
### Estudios clave del último año
| Estudio o documento | Fecha | Aporte principal | Relevancia para adopción | Fuente |
| ------------------------------------------------------------ | -------- | ------------------------------------------------------------------------------------------ | --------------------------------------------------------------- | ---------------------------------------------------------------------------- |
| **Demystifying evals for AI agents** | ene 2026 | Formaliza task, trial, grader, transcript, outcome y harness; propone mezcla de graders | Excelente base operativa para equipos | [60](https://www.anthropic.com/engineering/demystifying-evals-for-ai-agents) |
| **Quantifying infrastructure noise in agentic coding evals** | feb 2026 | Mide cuánto puede mover el resultado la infraestructura, no el modelo | Imprescindible para no sobreinterpretar scores | [61](https://www.anthropic.com/engineering/infrastructure-noise) |
| **Eval awareness in BrowseComp** | mar 2026 | Documenta contaminación y un caso de “eval awareness” del modelo | Señal fuerte contra confianza ingenua en benchmarks web-enabled | [62](https://www.anthropic.com/engineering/eval-awareness-browsecomp) |
| **How Well Does Agent Development Reflect Real-World Work?** | mar 2026 | Analiza 43 benchmarks y 72.342 tareas; detecta sesgo fuerte hacia programación | Justifica crear suites propias para funciones corporativas | [63](https://arxiv.org/abs/2603.01203) |
| **JobBench** | may 2026 | Cambia el enfoque de reemplazo a tareas que las personas quieren delegar | Muy útil para diseñar evals orientados a adopción real | [58](https://arxiv.org/html/2605.26329v1) |
| **Design and Report Benchmarks for Knowledge Work** | may 2026 | Propone marco actividad-setting-producto | Sirve como checklist para diseñar evals con validez | [64](https://arxiv.org/abs/2605.23262?utm_source=chatgpt.com) |
| **CollabSkill** | abr 2026 | Evalúa colaboración humano-agente con trabajadores reales | Valioso para equipos que no buscan autonomía total | [59](https://arxiv.org/abs/2606.09833?utm_source=chatgpt.com) |
| **Benchmark saturation** | may 2026 | Muestra que edad y escala explican mejor la saturación que otros supuestos “guardarraíles” | Obliga a renovar suites y no vivir de un benchmark viejo | [65](https://arxiv.org/html/2602.16763) |
| **Reliability Gap in Benchmark Auditing** | jul 2026 | Enseña que la detección estadística de contaminación aún falla mucho en escenarios reales | Refuerza necesidad de datos y procedencia más transparentes | [66](https://arxiv.org/html/2606.03305v2) |
| **PolyWorkBench** | jul 2026 | Introduce workflows workplace multilingües y heterogéneos | Importante para entornos internacionales y empresas europeas | [67](https://arxiv.org/html/2607.06008v2?utm_source=chatgpt.com) |
Culturalmente, el cambio más fuerte es que “evaluar IA” deja de ser una actividad de laboratorio y pasa a ser un hábito de operación. Databricks habla explícitamente de feedback de stakeholders y SMEs, Knowledge Assistant y Supervisor Agent mejoran con lenguaje natural y review links, y OpenAI mueve la conversación hacia traces, eval runs, macro-evals y loops de mejora. El mensaje común es que la responsabilidad de calidad ya no es de ingeniería. Es de proceso funcional. [68](https://docs.databricks.com/aws/en/agents/agent-bricks/knowledge-assistant)
## Límites, debates y recomendaciones prácticas
El principal límite metodológico es la **validez**. Mucha evaluación sigue heredando la lógica de NLP clásico: pregunta cerrada, score único y claim excesivo. La literatura de 2026 lo cuestiona de frente. “Design and Report Benchmarks for Knowledge Work” pide definir actividad, setting y producto. El trabajo sobre ecological validity en periodismo muestra que los benchmarks suelen medir mal el uso real y los valores del dominio. Y el análisis de alineación con trabajo real detecta una desviación fuerte hacia programación frente a ocupaciones con mayor peso laboral y económico. [69](https://arxiv.org/html/2605.23262v1)
El segundo límite es la **integridad del benchmark**. Ya no basta con decir “es público” o “tiene test set privado”. El trabajo sobre la saturación de benchmarks encuentra que esos supuestos guardarraíles protegen menos de lo que se cree, mientras que edad y tamaño del benchmark predicen mejor la saturación. El paper sobre la contaminación de la auditoría muestra que muchos métodos de detección aún no son fiables a escala real. Y Anthropic documenta casos concretos de contaminación y hasta de modelos que infieren que están siendo evaluados y acaban localizando el benchmark. [70](https://arxiv.org/html/2602.16763)
El tercer límite es el **corrector automático**. OpenAI reconoce que estos correctores tienen sesgos: tienden a favorecer la respuesta que aparece en primera posición cuando comparan dos (*position bias*) y a puntuar mejor las respuestas más largas, sean o no mejores (*verbosity bias*). Por eso pide comprobar que el corrector automático coincide con las puntuaciones de revisores humanos antes de usarlo a gran escala. Anthropic dice lo mismo con otras palabras: usa programas de comprobación siempre que se pueda, correctores de IA cuando haga falta, y revisores humanos con cabeza, para validar. En otras palabras, la IA que corrige a otra IA es útil, pero no es un árbitro infalible. Es una forma barata de multiplicar el criterio de los expertos humanos, no de sustituirlo. [25](https://developers.openai.com/api/docs/guides/evaluation-best-practices)
El cuarto límite es **organizativo** y **ético**. GDPval y benchmarks afines pueden leerse en clave de sustitución, pero JobBench corrige ese sesgo y pregunta qué quieren delegar los trabajadores. CollabSkill va más allá y mide colaboración. Esto es relevante porque cada enfoque produce una política distinta: si solo mides reemplazo, optimizas para autonomía; si mides delegación y colaboración, optimizas para agencia, revisión y reparto correcto del trabajo. Podría parecer una diferencia filosófica, pero cambia qué se evalúa. [71](https://arxiv.org/html/2605.26329v1)
En seguridad, la tentación habitual es meter red teaming dentro del saco de “evals” y pensar que con eso ya está todo cubierto. No. OpenAI lo dice de forma explícita: red teaming complementa los evals porque busca casos de uso indebidos (*misuse cases*) y fallos de alto riesgo que la revisión ordinaria no captura. Promptfoo y Microsoft Foundry coinciden además en que estas pruebas son no deterministas, usan inputs adversarios simulados y requieren revisión humana antes de mitigaciones. Calidad funcional y resiliencia ofensiva son dos superficies distintas. [28](https://developers.openai.com/api/docs/guides/red-teaming)
### Recomendaciones prácticas para un equipo de información (white-collars)
La primera recomendación es empezar por el **producto de trabajo**, no por la herramienta. Antes de elegir plataforma, define qué entregable cuenta como éxito: informe, respuesta con citas, tabla, slide, ticket resuelto, decisión aprobable, borrador revisable. Si no puedes describir el artefacto y cómo se usa después, tu eval será decorativo. Las mejores referencias recientes van exactamente por ahí: work product, role, setting y downstream usability. [72](https://arxiv.org/html/2605.23262v1)
La segunda es **diseñar tres capas** separadas desde el principio. Una capa de **calidad funcional** con evals regresivos para no romper lo que ya funcionaba. Una capa de **evals de capacidad** para mejorar en tareas difíciles. Y una **capa de seguridad** con red teaming y guardaraíles. OpenAI, Anthropic y Promptfoo convergen en esta separación, y mezclarlo todo en una puntuación única suele esconder más de lo que revela. [73](https://www.anthropic.com/engineering/demystifying-evals-for-ai-agents)
La tercera es **instrumentar trazas** desde el día uno (esto es, trazabilidad detallada, registro muy detallado de todo lo que ocurre). Si tu sistema usa recuperación, herramientas, handoffs o contexto largo, el resultado final no basta para entender nada. OpenAI habla de *trace grading* como la forma más rápida de encontrar problemas a nivel de proceso; MLflow, Langfuse y Databricks convierten las trazas en la unidad de observabilidad, evaluación y feedback; y Anthropic insiste en transcript y outcome como piezas distintas. En Microsoft se habla de observabilidad en todas las capas. [74](https://developers.openai.com/api/docs/guides/agent-evals)
La cuarta es **empezar pequeño, pero con datos reales**. Anthropic recomienda 20-50 tareas simples, idealmente extraídas de fallos reales. OpenAI insiste en mezclar datos de producción, casos expertos, edge cases y adversarial cases. Para un equipo white-collar, eso suele traducirse en: diez casos felices, diez errores frecuentes, diez casos ambiguos, diez casos de alto riesgo y un pequeño lote de inyecciones/políticas conflictivas. [75](https://www.anthropic.com/engineering/demystifying-evals-for-ai-agents)
La quinta es hacer que los SMEs sean coautores de la evaluación. No solo revisores finales. Databricks lo operacionaliza con labeling sessions, natural-language feedback y review links. OpenAI admite que las annotations son la mejor vía para incorporar feedback humano. Si el experto solo entra al final para “validar”, casi siempre llega tarde y sin marco. [76](https://docs.databricks.com/aws/en/mlflow3/genai/human-feedback/concepts/labeling-sessions?utm_source=chatgpt.com)
La sexta es **no usar benchmarks públicos como criterio** de compra sin un puente local. Un modelo que gana MMLU o coding benchmarks puede no ser el mejor para responder políticas internas, sintetizar investigación de mercado, redactar presentaciones o interactuar con sistemas heredados. La evidencia de *real-world work mismatch*, más los resultados discretos en WorkArena, OfficeBench y TheAgentCompany, van justo en esa línea. Aquí conviene llevar la contraria al impulso habitual: elegir por tablas de clasificación generales es cómodo, pero puede ser una mala decisión. [77](https://arxiv.org/abs/2603.01203)
La séptima es **asumir que los números no son comparables si cambia el harness**. Infraestructura, presupuesto de tokens, límites de tiempo y herramientas disponibles alteran el test. Anthropic cuantifica este problema en agentes de desarrollo de software; en agentes de información pasa lo mismo, solo que a menudo peor porque el entorno es más heterogéneo. Todo informe interno de eval debería registrar, como mínimo, modelo, prompt/policy version, harness version, tools disponibles, dataset version, coste, latencia y criterio de grading. [78](https://www.anthropic.com/engineering/infrastructure-noise)
La octava es introducir una **tabla de decisión por riesgo**. No todo necesita el mismo nivel de evidencia. Para FAQ interna de baja criticidad puede bastar un evaluador automático más muestreo humano. Para cumplimiento, legal, RR.HH. o finanzas, la base debería ser entregable rubricado por experto, con evaluador automático solo como apoyo de escala. OpenAI reconoce que su evaluador automatizado de GDPval todavía no es suficientemente fiable como para sustituir a expertos. Esa frase conviene tatuarla en cualquier programa serio de GenAI corporativa. [57](https://openai.com/index/gdpval/)
### Un patrón mínimo viable de implantación
| Fase | Qué hacer | Salida esperada | Qué no está especificado en muchas fuentes |
| --------------- | ------------------------------------------------------------ | ------------------------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| Alcance | Elegir 1 proceso concreto y 1 entregable concreto | Definición de éxito y de fallo | El umbral “correcto” de calidad depende del dominio; no existe estándar universal [79](https://arxiv.org/html/2605.23262v1) |
| Instrumentación | Activar traces y versionado de datasets/prompts | Capacidad de diagnosticar y comparar runs | No todas las plataformas detallan igual sus prompts de judge o su esquema de calibración [80](https://developers.openai.com/api/docs/guides/agent-evals) |
| Dataset inicial | Reunir 20-50 casos reales y algunos adversariales | Primera suite de capability + regression + safety | La cobertura estadística exacta necesaria no está fijada; depende del efecto que busques medir [75](https://www.anthropic.com/engineering/demystifying-evals-for-ai-agents) |
| Grading | Mezclar checks deterministas, judge rubricado y muestreo SME | Señal rápida + ancla humana | No hay consenso interproveedor sobre cuándo un LLM judge está “suficientemente calibrado” [25](https://developers.openai.com/api/docs/guides/evaluation-best-practices) |
| Operación | Ejecutar en cada cambio y revisar semanalmente fallos nuevos | Flywheel de mejora | La comparabilidad interherramienta sigue sin estar plenamente estandarizada [81](https://www.promptfoo.dev/docs/intro/) |
| Gobierno | Separar calidad, seguridad y cumplimiento | Decisiones de release más serias | La documentación consultada rara vez publica una ontología común para estos tres planos [82](https://developers.openai.com/api/docs/guides/red-teaming) |
La mejor conclusión es poco vistosa y muy útil: “eval” se está convirtiendo en el sistema operativo de la adopción seria de IA generativa en conocimiento profesional. Ha salido del software no porque el software dejara de importar, sino porque el mismo problema de fiabilidad apareció en contextos mucho más caros, ambiguos y políticamente delicados: soporte, research, operaciones, legal, compliance, documentación y coordinación entre agentes. Donde antes bastaban benchmarks y demos, ahora hacen falta trazas, artefactos de trabajo, SMEs y disciplina de release. Esa es la evolución real del término. [83](https://www.anthropic.com/engineering/demystifying-evals-for-ai-agents)
---
[1](https://developers.openai.com/api/docs/guides/evaluation-best-practices) [21](https://developers.openai.com/api/docs/guides/evaluation-best-practices) [22](https://developers.openai.com/api/docs/guides/evaluation-best-practices) [23](https://developers.openai.com/api/docs/guides/evaluation-best-practices) [25](https://developers.openai.com/api/docs/guides/evaluation-best-practices) [30](https://developers.openai.com/api/docs/guides/evaluation-best-practices) [31](https://developers.openai.com/api/docs/guides/evaluation-best-practices) Evaluation best practices | OpenAI API
[_https://developers.openai.com/api/docs/guides/evaluation-best-practices_](https://developers.openai.com/api/docs/guides/evaluation-best-practices)
[2](https://crfm.stanford.edu/2022/11/17/helm.html) [16](https://crfm.stanford.edu/2022/11/17/helm.html) Stanford CRFM
[_https://crfm.stanford.edu/2022/11/17/helm.html_](https://crfm.stanford.edu/2022/11/17/helm.html)
[3](https://arxiv.org/html/2605.23262v1) [20](https://arxiv.org/html/2605.23262v1) [69](https://arxiv.org/html/2605.23262v1) [72](https://arxiv.org/html/2605.23262v1) [79](https://arxiv.org/html/2605.23262v1) Design and Report Benchmarks for Knowledge Work
[_https://arxiv.org/html/2605.23262v1_](https://arxiv.org/html/2605.23262v1)
[4](https://developers.openai.com/api/docs/guides/evaluation-getting-started) Getting started with datasets | OpenAI API
[_https://developers.openai.com/api/docs/guides/evaluation-getting-started_](https://developers.openai.com/api/docs/guides/evaluation-getting-started)
[5](https://developers.openai.com/api/docs/guides/agent-evals) [7](https://developers.openai.com/api/docs/guides/agent-evals) [11](https://developers.openai.com/api/docs/guides/agent-evals) [26](https://developers.openai.com/api/docs/guides/agent-evals) [29](https://developers.openai.com/api/docs/guides/agent-evals) [33](https://developers.openai.com/api/docs/guides/agent-evals) [74](https://developers.openai.com/api/docs/guides/agent-evals) [80](https://developers.openai.com/api/docs/guides/agent-evals) Evaluate agent workflows | OpenAI API
[_https://developers.openai.com/api/docs/guides/agent-evals_](https://developers.openai.com/api/docs/guides/agent-evals)
[6](https://www.anthropic.com/engineering/demystifying-evals-for-ai-agents) [8](https://www.anthropic.com/engineering/demystifying-evals-for-ai-agents) [9](https://www.anthropic.com/engineering/demystifying-evals-for-ai-agents) [10](https://www.anthropic.com/engineering/demystifying-evals-for-ai-agents) [12](https://www.anthropic.com/engineering/demystifying-evals-for-ai-agents) [13](https://www.anthropic.com/engineering/demystifying-evals-for-ai-agents) [14](https://www.anthropic.com/engineering/demystifying-evals-for-ai-agents) [18](https://www.anthropic.com/engineering/demystifying-evals-for-ai-agents) [24](https://www.anthropic.com/engineering/demystifying-evals-for-ai-agents) [60](https://www.anthropic.com/engineering/demystifying-evals-for-ai-agents) [73](https://www.anthropic.com/engineering/demystifying-evals-for-ai-agents) [75](https://www.anthropic.com/engineering/demystifying-evals-for-ai-agents) [83](https://www.anthropic.com/engineering/demystifying-evals-for-ai-agents) Demystifying evals for AI agents \ Anthropic
[_https://www.anthropic.com/engineering/demystifying-evals-for-ai-agents_](https://www.anthropic.com/engineering/demystifying-evals-for-ai-agents)
[15](https://openai.com/index/gdpval/) [19](https://openai.com/index/gdpval/) [57](https://openai.com/index/gdpval/) Measuring the performance of our models on real-world tasks | OpenAI
[_https://openai.com/index/gdpval/_](https://openai.com/index/gdpval/)
[17](https://developers.openai.com/cookbook/examples/partners/eval_driven_system_design/receipt_inspection) Eval Driven System Design - From Prototype to Production
[_https://developers.openai.com/cookbook/examples/partners/eval_driven_system_design/receipt_inspection_](https://developers.openai.com/cookbook/examples/partners/eval_driven_system_design/receipt_inspection)
[27](https://developers.openai.com/cookbook/examples/partners/macro_evals_for_agentic_systems/macro_evals_for_agentic_systems) Macro Evals for Agentic Systems
[_https://developers.openai.com/cookbook/examples/partners/macro_evals_for_agentic_systems/macro_evals_for_agentic_systems_](https://developers.openai.com/cookbook/examples/partners/macro_evals_for_agentic_systems/macro_evals_for_agentic_systems)
[28](https://developers.openai.com/api/docs/guides/red-teaming) [82](https://developers.openai.com/api/docs/guides/red-teaming) Red teaming | OpenAI API
[_https://developers.openai.com/api/docs/guides/red-teaming_](https://developers.openai.com/api/docs/guides/red-teaming)
[32](https://developers.openai.com/api/docs/guides/evals) Working with evals | OpenAI API
[_https://developers.openai.com/api/docs/guides/evals_](https://developers.openai.com/api/docs/guides/evals)
[34](https://github.com/openai/evals) GitHub - openai/evals: Evals is a framework for evaluating LLMs and LLM systems, and an open-source registry of benchmarks. · GitHub
[_https://github.com/openai/evals_](https://github.com/openai/evals)
[35](https://github.com/openai/simple-evals) GitHub - openai/simple-evals · GitHub
[_https://github.com/openai/simple-evals_](https://github.com/openai/simple-evals)
[36](https://www.promptfoo.dev/docs/intro/) [46](https://www.promptfoo.dev/docs/intro/) [81](https://www.promptfoo.dev/docs/intro/) Intro | Promptfoo
[_https://www.promptfoo.dev/docs/intro/_](https://www.promptfoo.dev/docs/intro/)
[37](https://mlflow.org/docs/latest/genai/eval-monitor/) [47](https://mlflow.org/docs/latest/genai/eval-monitor/) LLM and Agent Evaluation | MLflow AI Platform
[_https://mlflow.org/docs/latest/genai/eval-monitor/_](https://mlflow.org/docs/latest/genai/eval-monitor/)
[38](https://docs.langchain.com/langsmith/evaluate-llm-application) How to evaluate agents - Docs by LangChain
[_https://docs.langchain.com/langsmith/evaluate-llm-application_](https://docs.langchain.com/langsmith/evaluate-llm-application)
[39](https://langfuse.com/docs/evaluation/overview) Evaluation of LLM Applications - Langfuse
[_https://langfuse.com/docs/evaluation/overview_](https://langfuse.com/docs/evaluation/overview)
[40](https://github.com/confident-ai/deepeval?utm_source=chatgpt.com) confident-ai/deepeval: The LLM Evaluation Framework
[_https://github.com/confident-ai/deepeval?utm_source=chatgpt.com_](https://github.com/confident-ai/deepeval?utm_source=chatgpt.com)
[41](https://github.com/EleutherAI/lm-evaluation-harness) GitHub - EleutherAI/lm-evaluation-harness: A framework for few-shot evaluation of language models. · GitHub
[_https://github.com/EleutherAI/lm-evaluation-harness_](https://github.com/EleutherAI/lm-evaluation-harness)
[42](https://huggingface.co/docs/lighteval/index) Lighteval · Hugging Face
[_https://huggingface.co/docs/lighteval/index_](https://huggingface.co/docs/lighteval/index)
[43](https://inspect.aisi.org.uk/) Inspect
[_https://inspect.aisi.org.uk/_](https://inspect.aisi.org.uk/)
[44](https://github.com/microsoft/PyRIT) GitHub - microsoft/PyRIT: The Python Risk Identification Tool for generative AI (PyRIT) is an open source framework built to empower security professionals and engineers to proactively identify risks in generative AI systems. · GitHub
[_https://github.com/microsoft/PyRIT_](https://github.com/microsoft/PyRIT)
[45](https://github.com/NVIDIA/garak) GitHub - NVIDIA/garak: the LLM vulnerability scanner · GitHub
[_https://github.com/NVIDIA/garak_](https://github.com/NVIDIA/garak)
[48](https://learn.microsoft.com/es-es/azure/foundry/concepts/ai-red-teaming-agent) Agente de red teaming para IA - Microsoft Foundry | Microsoft Learn
[_https://learn.microsoft.com/es-es/azure/foundry/concepts/ai-red-teaming-agent_](https://learn.microsoft.com/es-es/azure/foundry/concepts/ai-red-teaming-agent)
[49](https://servicenow.github.io/WorkArena/) WorkArena: How Capable are Web Agents at Solving Common Knowledge Work Tasks?
[_https://servicenow.github.io/WorkArena/_](https://servicenow.github.io/WorkArena/)
[50](https://www.anthropic.com/engineering/multi-agent-research-system) How we built our multi-agent research system \ Anthropic
[_https://www.anthropic.com/engineering/multi-agent-research-system_](https://www.anthropic.com/engineering/multi-agent-research-system)
[51](https://www.microsoft.com/en-us/worklab/work-trend-index/breaking-down-infinite-workday) Breaking down the infinite workday
[_https://www.microsoft.com/en-us/worklab/work-trend-index/breaking-down-infinite-workday_](https://www.microsoft.com/en-us/worklab/work-trend-index/breaking-down-infinite-workday)
[52](https://servicenow.github.io/WorkArena/?utm_source=chatgpt.com) [53](https://servicenow.github.io/WorkArena/?utm_source=chatgpt.com) WorkArena: How Capable are Web Agents at Solving ...
[_https://servicenow.github.io/WorkArena/?utm_source=chatgpt.com_](https://servicenow.github.io/WorkArena/?utm_source=chatgpt.com)
[54](https://arxiv.org/html/2407.19056v1?utm_source=chatgpt.com) OfficeBench: Benchmarking Language Agents across ...
[_https://arxiv.org/html/2407.19056v1?utm_source=chatgpt.com_](https://arxiv.org/html/2407.19056v1?utm_source=chatgpt.com)
[55](https://arxiv.org/abs/2412.14161) [2412.14161] TheAgentCompany: Benchmarking LLM Agents on Consequential Real World Tasks
[_https://arxiv.org/abs/2412.14161_](https://arxiv.org/abs/2412.14161)
[56](https://arxiv.org/html/2605.03596v1?utm_source=chatgpt.com) Benchmarking AI Agents on Workspace Tasks with Large- ...
[_https://arxiv.org/html/2605.03596v1?utm_source=chatgpt.com_](https://arxiv.org/html/2605.03596v1?utm_source=chatgpt.com)
[58](https://arxiv.org/html/2605.26329v1) [71](https://arxiv.org/html/2605.26329v1) JobBench: Aligning Agent Work With Human Will
[_https://arxiv.org/html/2605.26329v1_](https://arxiv.org/html/2605.26329v1)
[59](https://arxiv.org/abs/2606.09833?utm_source=chatgpt.com) CollabSkill: Evaluating Human-Agent Collaboration On Real-World Tasks
[_https://arxiv.org/abs/2606.09833?utm_source=chatgpt.com_](https://arxiv.org/abs/2606.09833?utm_source=chatgpt.com)
[61](https://www.anthropic.com/engineering/infrastructure-noise) [78](https://www.anthropic.com/engineering/infrastructure-noise) Quantifying infrastructure noise in agentic coding evals \ Anthropic
[_https://www.anthropic.com/engineering/infrastructure-noise_](https://www.anthropic.com/engineering/infrastructure-noise)
[62](https://www.anthropic.com/engineering/eval-awareness-browsecomp) Eval awareness in Claude Opus 4.6’s BrowseComp performance \ Anthropic
[_https://www.anthropic.com/engineering/eval-awareness-browsecomp_](https://www.anthropic.com/engineering/eval-awareness-browsecomp)
[63](https://arxiv.org/abs/2603.01203) [77](https://arxiv.org/abs/2603.01203) [2603.01203] How Well Does Agent Development Reflect Real-World Work?
[_https://arxiv.org/abs/2603.01203_](https://arxiv.org/abs/2603.01203)
[64](https://arxiv.org/abs/2605.23262?utm_source=chatgpt.com) Design and Report Benchmarks for Knowledge Work
[_https://arxiv.org/abs/2605.23262?utm_source=chatgpt.com_](https://arxiv.org/abs/2605.23262?utm_source=chatgpt.com)
[65](https://arxiv.org/html/2602.16763) [70](https://arxiv.org/html/2602.16763) When AI Benchmarks Plateau: A Systematic Study of Benchmark Saturation
[_https://arxiv.org/html/2602.16763_](https://arxiv.org/html/2602.16763)
[66](https://arxiv.org/html/2606.03305v2) The Reliability Gap in Benchmark Auditing: Distribution Shift and Scale as Failure Modes of Contamination Detection
[_https://arxiv.org/html/2606.03305v2_](https://arxiv.org/html/2606.03305v2)
[67](https://arxiv.org/html/2607.06008v2?utm_source=chatgpt.com) Benchmarking Multilingual Long-Horizon LLM Agents
[_https://arxiv.org/html/2607.06008v2?utm_source=chatgpt.com_](https://arxiv.org/html/2607.06008v2?utm_source=chatgpt.com)
[68](https://docs.databricks.com/aws/en/agents/agent-bricks/knowledge-assistant) Use Knowledge Assistant to create a high-quality chatbot over your documents | Databricks on AWS
[_https://docs.databricks.com/aws/en/agents/agent-bricks/knowledge-assistant_](https://docs.databricks.com/aws/en/agents/agent-bricks/knowledge-assistant)
[76](https://docs.databricks.com/aws/en/mlflow3/genai/human-feedback/concepts/labeling-sessions?utm_source=chatgpt.com) Create and manage labeling sessions | Databricks on AWS
[_https://docs.databricks.com/aws/en/mlflow3/genai/human-feedback/concepts/labeling-sessions?utm_source=chatgpt.com_](https://docs.databricks.com/aws/en/mlflow3/genai/human-feedback/concepts/labeling-sessions?utm_source=chatgpt.com)