Enterprise RAG Challenge 3: lecciones de las candidaturas públicas

Viacheslav Dubrov

2026-01-11 · Actualizado 2026-07-15 · 11 min · Agentes de IA

Traducción automática Este artículo se tradujo automáticamente a partir de la versión original en inglés.

Enterprise RAG Challenge 3 (ERC3) pidió a agentes completar tareas empresariales contra la API de una empresa simulada. La clasificación congelada de premios resulta especialmente útil porque muchos participantes publicaron algo más que una puntuación: arquitectura, combinación de modelos, coste y notas sobre fallos.

He revisado esas descripciones públicas para responder a una pregunta más concreta: ¿qué decisiones de diseño se repetían en las candidaturas más sólidas y cuáles son útiles fuera de este benchmark?

Al final, deberías poder convertir estas observaciones en hipótesis de diseño para tus propias trazas de agentes y probarlas con tu combinación de tareas y el coste de los fallos.

En resumen: no hubo una única topología ganadora. Las candidaturas más sólidas iban desde un agente sencillo con tool calling hasta pipelines especializados y sistemas de planificación y ejecución. Las ideas recurrentes eran más concretas: aprender de las trazas fallidas, validar los pasos de riesgo cerca del punto de ejecución, hacer explícita la política de contexto y ocultar los riesgos de la API, como la paginación, tras wrappers fiables. El prompt de producción del ganador se encontraba en su 80.ª versión generada automáticamente.

¿Qué es Enterprise RAG Challenge?

Enterprise RAG Challenge 3 es un proyecto de investigación colaborativo y de gran escala que evalúa cómo gestionan los agentes autónomos tareas empresariales complejas. A diferencia de los benchmarks estáticos, ERC3 se ejecuta sobre Agentic Enterprise Simulation (AGES), una simulación de eventos discretos que expone una API empresarial realista.

Qué evalúa el benchmark

A través de AGES, los agentes trabajan dentro de una empresa ficticia que cuenta con:

• Perfiles de empleados con habilidades y departamentos específicos
• Proyectos con asignaciones de equipos y relaciones con clientes
• Wiki corporativa con reglas de negocio y jerarquías de permisos
• Seguimiento de horas y operaciones financieras

Cada tarea inicia una simulación aislada. La wiki de la empresa es compartida, pero los registros operativos varían según la tarea, por lo que un agente no puede resolver el conjunto memorizando el estado de una única empresa.

Interpreta las puntuaciones como una instantánea

ERC3 ofrece ahora tanto una clasificación congelada de la competición como un benchmark público que siguió recibiendo ejecuciones después del evento. Cada página responde a preguntas distintas. Las cifras siguientes describen la clasificación de premios en el cierre de la competición, no las sesiones posteriores con mejor rendimiento:

La página del benchmark activo puede mostrar puntuaciones superiores porque incluye ejecuciones posteriores. Por eso, la clasificación congelada es la fuente adecuada para afirmar qué ganó la competición.

Tipos de tareas

Las tareas abarcan varias áreas de capacidad:

• Razonamiento multi-hop, como relacionar las habilidades de los empleados con las asignaciones de proyectos.
• Validación de permisos, como bloquear cambios salariales o accesos a datos no autorizados.
• Consultas ambiguas, incluidas solicitudes multilingües y parafraseadas.
• Cumplimiento estricto del formato de salida, incluidos enlaces obligatorios a entidades en las respuestas.

Qué sugieren realmente las candidaturas

Los informes públicos no permiten extraer una conclusión tajante como «multi-agent supera a single-agent». La candidatura que quedó cuarta en la clasificación de premios era explícitamente un diseño sencillo de single-agent. Sí respaldan cuatro observaciones más concretas:

1. La descomposición era útil cuando aislaba un límite de fallo conocido. Los equipos separaban las comprobaciones de permisos, la validación de pasos, la ejecución de código o el formato de respuesta, no roles arbitrarios de «agente».
2. La validación se acercó a las acciones irreversibles. Varios sistemas comprobaban los permisos antes de ejecutar, revisaban pasos individuales o protegían la respuesta final.
3. La iteración basada en trazas era importante. El ganador convertía las ejecuciones fallidas en revisiones del prompt mediante un bucle automatizado; otros equipos documentaron correcciones igualmente concretas en herramientas y prompts.
4. La política de contexto era una decisión arquitectónica. Los equipos probaron destilación, precarga, retrieval y compresión del historial. Sus propios informes discrepan sobre si la compresión ayudaba, así que no existe una receta universal.

Cinco enfoques informativos

No son los cinco primeros en orden de clasificación. Los he seleccionado porque sus descripciones públicas muestran cinco formas distintas de construir el sistema: revisión automatizada del prompt, etapas especializadas, validación por paso, protecciones de respuesta y aislamiento entre planificación y ejecución. Cuando interpreto por qué ayudó un diseño, señalo esa interpretación en lugar de presentarla como un hallazgo de la clasificación.

1. Prompt engineering evolutivo (equipo VZS9FL / @aostrikov)

El enfoque con mayor puntuación automatizó el prompt engineering mediante un bucle de auto-mejora.

En lugar de ajustar manualmente el prompt de producción, el equipo construyó un bucle de tres agentes que convertía las trazas fallidas en revisiones candidatas.

Pipeline de tres agentes:

El prompt de producción era la versión 80 generada automáticamente. El equipo describe el bucle como un proceso que analiza tareas fallidas, propone causas y decide qué sugerencias incorporar. La clasificación confirma la puntuación final y el número de iteraciones. No permite aislar cuánto de la mejora procedía de la automatización frente a los modelos, las herramientas o el feedback acumulado del benchmark.

Stack: claude-opus-4.5 con Anthropic Python SDK y Tool Use nativo.

2. Pipeline secuencial multi-agent (equipo Lcnxuy / @andrey_aiweapps)

Esta candidatura construyó un flujo secuencial en el que componentes especializados se encargaban de las comprobaciones de seguridad, la extracción de contexto, la ejecución y el formato de enlaces a entidades.

Componentes documentados:

1. Security Gate Agent: comprobación previa a la ejecución que valida los permisos según las reglas de la wiki antes de iniciar el bucle principal.
2. Context Extraction Agent: extrae las reglas críticas de prompts enormes y precarga los datos de usuarios, proyectos y clientes.
3. Execution Agent: planificación al estilo ReAct con 5 fases internas (Identidad → Detección de amenazas → Recopilación de información → Validación de acceso → Ejecución).
4. LinkGeneratorAgent: integrado en la herramienta de respuesta, analiza el contexto para incluir los enlaces obligatorios a entidades.

LinkGeneratorAgent es la parte más transferible. Al situarlo dentro de la herramienta de respuesta, un requisito del benchmark (los enlaces obligatorios a entidades) pasa a ser una propiedad de la interfaz, en lugar de otra instrucción que el modelo de ejecución puede olvidar.

Stack: frameworks atomic-agents y instructor, con gpt-5.1-codex-max, gpt-4.1 y claude-sonnet-4.5.

3. Razonamiento guiado por schema con validación de pasos (equipo NLN7Dw / Ilia Ris)

Este equipo combinó SGR con inferencia rápida y un validador para cada paso propuesto. El diseño hace barata la revisión: rechaza un paso defectuoso antes de convertirlo en un tool call y pide al flujo principal que lo rehaga con los comentarios del validador.

Componentes clave:

El equipo informó de ejecuciones de gpt-oss-120b en Cerebras de hasta aproximadamente 3.000 tokens por segundo. Combinó la validación con inferencia de alto throughput, lo que podría haber reducido su coste de latencia. El resultado público no permite aislar ese efecto.

Stack: gpt-oss-120b en Cerebras, con una implementación personalizada de SGR NextStep.

4. Sistema de enricher y guard (equipo J8Gvbi / @mishka)

Esta candidatura añadió sugerencias no bloqueantes y un sistema de guards por niveles sobre una base SGR. Cuando llegaban respuestas de la API, los enrichers las inspeccionaban y añadían orientación operativa al contexto posterior.

Más de 20 enrichers inspeccionaban las respuestas de la API e inyectaban sugerencias contextuales:

RoleEnricher: "You are LEAD of this project, proceed with update."
PaginationHintEnricher: "next_offset=5 means MORE results! MUST paginate."

Sistema de guards en tres modos:

Wiki híbrida con RAG: tres streams de búsqueda (regex, semántica y palabras clave) cubrían distintos tipos de consulta sobre la wiki de la empresa.

Stack: qwen/qwen3-235b-a22b-2507 sobre el framework SGR de LangChain.

5. REPL de planificación y ejecución (equipo key_concept_parallel)

Esta arquitectura establecía una separación estricta entre planificación y ejecución, y utilizaba un bucle de generación de código. Aparecía en la clasificación general de Ultimate, no entre las cinco primeras de la clasificación congelada de premios. Su descripción pública sigue siendo útil porque muestra otra forma de descomposición: separar por fase de ejecución en lugar de por rol empresarial.

Distintos modelos se encargaban de trabajos diferentes: uno planificaba, otro escribía Python y un modelo de decisión independiente elegía qué hacer después de cada paso.

Configuración multi-model:

La REPL de finalización de pasos:

1. El planificador crea un paso de alto nivel.
2. El modelo de code-gen trabaja en un contexto nuevo del modelo y escribe un script de Python para ese paso.
3. El script se ejecuta en una REPL con ámbito de tarea cuyas variables persisten entre pasos.
4. El modelo de decisión analiza el resultado y elige: continuar, abortar o replantear.

La ruta de replanteamiento es la idea reutilizable. Cuando un paso falla parcialmente, el modelo de decisión puede conservar el trabajo completado y reescribir únicamente el resto del plan.

Patrones recurrentes en las candidaturas

Las implementaciones eran diferentes, pero en las descripciones públicas se repetían varias preocupaciones de ingeniería.

La gestión del contexto era explícita

Ningún equipo podía proporcionar al modelo todas las reglas, registros y pasos anteriores sin tomar una decisión de política. La diferencia interesante era dónde filtraba la información cada sistema.

Trade-off: NLN7Dw comprimía los turnos antiguos, mientras que f1Uixf informó de que la compresión del historial perjudicaba sus experimentos y mantuvo la conversación completa. Trata la compresión como una decisión que debe medirse, no como un valor predeterminado.

Los guardrails se situaban en distintos límites de fallo

Varios equipos colocaban comprobaciones antes, durante o después del bucle principal. Estos mecanismos abordaban riesgos distintos y no deberían agruparse bajo la etiqueta genérica de «critic agent».

Tool wrappers

Varios equipos construyeron capas de abstracción alrededor de la API sin procesar:

• Auto-pagination: los wrappers recorren todas las páginas y devuelven el dataset completo.
• Fuzzy normalization: «Willingness to travel» se traduce al campo de la API will_travel.
• Specialized reasoning tools: herramientas think, plan y critic para una deliberación controlada.

Modos de fallo y correcciones estructurales comunicadas por los equipos

Los informes mencionan repetidamente fallos en los límites de la API y de las políticas. Las correcciones más reutilizables trasladaban el requisito al código o a un paso de validación dedicado:

Orden práctico de adopción

ERC3 se basa en una única empresa simulada, no en un estudio general de ablación de agentes. Úsalo como fuente de hipótesis de diseño y prueba después esas hipótesis con tus propias trazas. Un orden de adopción razonable es:

1. Haz determinista primero la corrección de la API. Aplica auto-pagination a los endpoints de listado, normaliza los campos fuzzy, valida los schemas y genera los enlaces obligatorios dentro de la herramienta de respuesta.
2. Añade comprobaciones en los límites de riesgo reales. Verifica la identidad y los permisos antes de una mutación; valida un paso antes de ejecutarlo solo cuando la llamada adicional al modelo detecte fallos cuyo coste justifique esa llamada.
3. Documenta una política de contexto. Decide qué se precarga, qué se recupera, qué se comprime y qué se conserva literalmente. Mide la política por segmento de tareas, no solo por número de tokens.
4. Convierte las trazas fallidas en casos de regresión. Clasifica el fallo, cambia un único mecanismo y vuelve a ejecutar el segmento afectado. Automatiza la revisión del prompt solo cuando ese bucle sea fiable.
5. Descompón cuando la responsabilidad quede más clara. Un componente independiente está justificado cuando puede hacerse cargo de una restricción, utilizar un modelo o una herramienta diferentes, o probarse de forma aislada; no simplemente porque «multi-agent» parezca más capaz.

En estos informes, las candidaturas fiables hacían visibles los requisitos operativos ocultos mediante herramientas, validadores y bucles de evaluación.

Referencias

• Enterprise RAG Challenge 3 - Sitio oficial
• Clasificaciones de ERC3
• Benchmark: erc3-prod
• Notas de la versión