Salió DocOps, un framework de evaluación determinista para agentes autónomos que manipulan documentos digitales. Lo presenta un paper en arXiv (2607.19865) del equipo de icip-cas, con código y página de proyecto públicos.

El hueco que cierra es concreto. SWE-bench mide agentes en código, y ahí sabemos qué funciona y qué no. Pero las operaciones sobre documentos, PDFs, Word, formularios, carecían de un banco de pruebas sistemático. Si en tu empresa estás pensando en encargar a un agente la cumplimentación de un contrato o la edición de un informe extenso, no tenías una forma estándar de saber si el modelo elegido aguantaba.

DocOps desglosa las operaciones sobre documentos en dimensiones atómicas y niveles de complejidad creciente, inspirándose en prácticas reales. La evaluación es verificable de forma determinista, no delegada a un LLM árbitro que puede alterar los resultados (un problema que ya hemos visto en otros benchmarks).

Los resultados del paper son honestos sobre dónde estamos: incluso las configuraciones más avanzadas muestran limitaciones profundas en tareas con muchas dependencias y horizonte largo. Los tres modos de fallo identificados son la parte más útil para quien construye: pérdida de estado en tareas largas, verificación semántica superficial y edición destructiva de metadatos estructurales. Son exactamente los defectos que te arruinan el día cuando un agente corrompe un archivo que no puedes recuperar.

Si quieres examinarlo de cerca, el repo está en GitHub (github.com/icip-cas/DocOps) con la página de proyecto en docopsbench.github.io.

En detalle

El punto de partida es una carencia real en la evaluación de agentes. SWE-bench, del que hablamos como banco de pruebas para código, mostró cómo se mide un agente en tareas verificables y realistas. DocOps aplica el mismo principio a un dominio que toca casi todos los profesionales: los documentos.

La estructura del benchmark se basa en una taxonomía jerárquica que descompone las operaciones sobre documentos en dimensiones atómicas (acciones elementales individuales) y luego las recombina en flujos de complejidad creciente. La idea es pasar del paso singular (cambia este valor en el formulario) al proceso largo (actualiza un informe de veinte páginas manteniendo coherencia entre secciones, referencias y metadatos). La verificación es determinista, es decir, se contrasta el estado final del documento contra un resultado esperado, sin depender de un modelo que vote.

Los tres modos de fallo que el paper aísla merecen atención porque son el tipo de problema que descubres en producción, no en demostración:

• Long-term state tracking collapse: el agente pierde la pista de lo que ya hizo y cómo conectan las partes del documento. Ocurre cuando la tarea exige mantener coherencia entre secciones distantes.
• Shallow semantic verification: el agente comprueba solo superficialmente que el resultado parezca correcto, sin verificar que el significado sea coherente con la intención del documento.
• Destructive editing of structural metadata: el agente modifica o borra información estructural del archivo (estilos, referencias, campos ocultos) mientras hace su trabajo, dañando el documento de forma que no se ve de inmediato pero emerge después.

Estos modos de fallo convergen con lo que contábamos el 20 de julio: la orquestación y la verificación importan más que el modelo individual (/es/radar/agent-failures-orchestration-over-model-three-papers). DocOps lo demuestra en un dominio nuevo y lo hace con un método verificable.

Para quien esté evaluando un agente para tareas documentales, la lección es directa: prueba en tareas largas y acopladas, no solo en operaciones singulares. El paper sugiere que ahí es donde falla todo. Y si no sabes por dónde empezar para construir tu propio banco de pruebas, la lección del curso sobre cómo evaluar sin benchmark es el lugar adecuado.

Limitaciones: el paper es reciente (publicado el 22 de julio de 2026) y el abstract no reporta números específicos de puntuación por modelo. El código es público, pero para ver las tablas completas hay que ir al repo o al PDF. El número de votos positivos en Hugging Face (2) sugiere que aún tiene poca difusión, y debe leerse como contribución de investigación, no como veredicto consolidado.