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 (ECR3): arquitecturas ganadoras de agentes de IA
La Enterprise RAG Challenge 3 (ECR3) acaba de terminar. 524 equipos, más de 341.000 ejecuciones de agentes y solo el 0,4 % de los equipos alcanzó una puntuación perfecta. Ahora que la clasificación y los análisis son públicos, revisé las soluciones ganadoras para entender qué hicieron distinto los mejores equipos.
Este post explica qué es ECR3, cómo eran las tareas y qué patrones vi una y otra vez en las arquitecturas que funcionaron.
Resumen: Los pipelines multiagente superaron a los monolíticos. El equipo ganador usó ingeniería evolutiva de prompts a lo largo de más de 80 iteraciones automatizadas. Los ganadores dedicaron un esfuerzo serio a los guardrails (comprobaciones de seguridad previas, validadores en bucle y guardas posteriores a la ejecución) y a la estrategia de contexto. Importaba más qué entraba en el contexto que cuánto.
¿Qué es la Enterprise RAG Challenge?
La Enterprise RAG Challenge 3 es un proyecto de investigación a gran escala y colaborativo que evalúa cómo los agentes autónomos de IA manejan tareas empresariales complejas. A diferencia de los benchmarks estáticos, ECR3 se ejecuta sobre Agentic Enterprise Simulation (AGES), una simulación de eventos discretos que expone una API empresarial realista.
Por qué importa ECR3
A través de AGES, los agentes trabajan dentro de una empresa ficticia que tiene:
- Perfiles de empleados con habilidades y departamentos específicos
- Proyectos con asignaciones de equipo y relaciones con clientes
- Wiki corporativa con reglas de negocio y jerarquías de permisos
- Registro de tiempo y operaciones financieras
Cada tarea levanta su propia simulación con datos nuevos, así que los agentes no pueden memorizar nada entre ejecuciones.
El nivel de dificultad
La clasificación es dura:
| Métrica | Valor |
|---|---|
| Equipos registrados | 524 |
| Ejecuciones totales | 341.000+ |
| Tareas disponibles | 103 tareas empresariales únicas |
| Puntuación perfecta (100.0) | Solo 0,4 % de los equipos |
| Puntuación ≥ 0,9 | Solo 1,1 % de los equipos |
Tipos de tareas
Las tareas abarcan varias áreas de capacidad:
- Razonamiento multi-hop: Cruzar habilidades de empleados con asignaciones de proyectos
- Validación de permisos: Evitar cambios salariales o accesos a datos no autorizados
- Consultas ambiguas: Gestionar solicitudes de usuarios multilingües y parafraseadas
- Cumplimiento estricto del formato de salida: Incluir enlaces obligatorios a entidades en las respuestas
Qué fue lo que realmente ganó
Había cuatro patrones que se repetían en la parte alta de la clasificación:
- Los pipelines multiagente superaron a los agentes monolíticos. Dividir el trabajo funcionó mejor que un único agente grande intentando hacerlo todo.
- Los agentes más autónomos eran también los más restringidos. Los guardrails no eran algo secundario.
- La evolución automatizada de prompts superó a la ingeniería manual. Los mejores prompts pasaron por más de 80 generaciones.
- La estrategia de contexto hacía la mayor parte del trabajo. No más contexto, sino el contexto correcto.
Principales enfoques ganadores
Las cinco arquitecturas de abajo van en direcciones muy distintas, desde evolución de prompts totalmente automatizada hasta recuperación híbrida. Todas tienen piezas que merece la pena copiar.
1. Ingeniería evolutiva de prompts (Team VZS9FL / @aostrikov)
El enfoque con mayor puntuación automatizó la ingeniería de prompts mediante un bucle de auto-mejora.
En lugar de ajustar prompts a mano, el equipo construyó un bucle de tres agentes que permite al agente aprender de sus propios fallos.
Pipeline de tres agentes:
| Agente | Rol |
|---|---|
| Agente principal | Ejecuta el benchmark, registra todas las acciones y fallos |
| Agente analizador | Revisa tareas fallidas y formula hipótesis sobre las causas raíz |
| Agente versionador | Genera una nueva versión del prompt incorporando lo aprendido |
El resultado: El prompt de producción fue la 80.ª versión autogenerada. Cada versión corregía un patrón de fallo concreto que aparecía en los logs de la ejecución anterior. La mayoría eran el tipo de caso límite que solo detectas después de mirar una traza fallida durante una hora.
Stack: claude-opus-4.5 con Anthropic Python SDK y Tool Use nativo.
2. Pipeline secuencial multiagente (Team Lcnxuy / @andrey_aiweapps)
Este enfoque descartó el agente monolítico y construyó un pipeline secuencial de especialistas, cada uno lo bastante pequeño como para ser realmente bueno en su trabajo.
El pipeline de 4 etapas:
- Security Gate Agent: Comprobación previa a la ejecución que valida permisos frente a las reglas de la wiki antes de que arranque el bucle principal.
- Context Extraction Agent: Extrae las reglas críticas de prompts masivos y precarga datos de usuario, proyecto y cliente.
- Execution Agent: Planificación estilo ReAct con 5 fases internas (Identity → Threat Detection → Info Gathering → Access Validation → Execution).
- LinkGeneratorAgent: Integrado dentro de la herramienta de respuesta, analiza el contexto para incluir los enlaces obligatorios a entidades.
El agente LinkGenerator es la parte interesante. Solucionó uno de los modos de fallo más comunes: un agente que da la respuesta correcta pero olvida los enlaces de referencia obligatorios.
Stack: frameworks atomic-agents y instructor con gpt-5.1-codex-max, gpt-4.1 y claude-sonnet-4.5.
3. Razonamiento guiado por esquema con validación de pasos (Team NLN7Dw / Ilia Ris)
Este equipo combinó SGR con inferencia muy rápida y un validador en tiempo real. La apuesta: muchas decisiones rápidas y validadas superan a una respuesta lenta y muy deliberada.
Componentes clave:
| Componente | Función |
|---|---|
| StepValidator | Inspecciona cada paso propuesto. Si algo falla, lo devuelve para rehacerlo con comentarios. |
| Gestión de contexto | Plan completo del turno anterior, más historial comprimido para turnos más antiguos |
| Enriquecimiento dinámico | Extrae automáticamente perfil de usuario, proyectos y clientes; el LLM filtra para inyectar solo los datos relevantes para la tarea |
| Wrappers de autopaginación | Todos los endpoints de listas devuelven automáticamente los resultados completos |
La ventaja de velocidad viene de ejecutar sobre Cerebras a aproximadamente 3.000 tokens/segundo. A ese ritmo, el agente puede permitirse replantear un paso en lugar de comprometerse con una primera respuesta lenta de un modelo más pesado.
Stack: gpt-oss-120b sobre Cerebras, con una implementación personalizada de SGR NextStep.
4. Sistema de enrichers y guardas (Team J8Gvbi / @mishka)
Este enfoque acopló “pistas inteligentes” no bloqueantes y un sistema de guardas por niveles sobre una base SGR. A medida que llegan respuestas de la API, los enrichers las inspeccionan e indican discretamente al agente a qué debe prestar atención.
El sistema de enrichers:
Más de 20 enrichers inspeccionaban respuestas de la API e inyectaban pistas contextuales:
RoleEnricher: "You are LEAD of this project, proceed with update."
PaginationHintEnricher: "next_offset=5 means MORE results! MUST paginate."
Sistema de guardas de tres modos:
| Modo | Comportamiento |
|---|---|
| Bloqueo duro | Las acciones imposibles se bloquean de forma permanente |
| Bloqueo suave | Las acciones arriesgadas se bloquean en el primer intento, se permiten en el reintento |
| Pista suave | Orientación sin bloquear |
Wiki RAG híbrida: Tres flujos de búsqueda (regex, semántico y por palabras clave) ejecutándose en paralelo, dejando que gane el mejor para cada tipo de consulta.
Stack: qwen/qwen3-235b-a22b-2507 sobre el framework SGR de LangChain.
5. REPL de plan-ejecución (Team key_concept_parallel)
Esta arquitectura puso una separación estricta entre planificación y ejecución, y usó un bucle de generación de código. En la práctica, un REPL: el agente planifica un paso, genera código, lo ejecuta y decide qué hacer a continuación.
Modelos distintos para trabajos distintos: un planner planifica, un modelo de code-gen escribe Python y un modelo de decisión más pequeño decide qué hacer después de cada paso.
Configuración multimodelo:
| Etapa | Modelo |
|---|---|
| Planificación | openai/gpt-5.1 |
| Generación de código | deepseek/deepseek-v3.2 |
| Decisión tras el paso | openai/gpt-4.1 |
| Respuesta final | openai/gpt-4.1 |
El REPL de finalización de pasos:
- El planner crea un paso de alto nivel.
- El modelo de code-gen escribe un script de Python para ese paso.
- El script se ejecuta en un contexto aislado.
- El modelo de decisión analiza el resultado y elige: continuar, abortar o replantear.
La ruta de replanteamiento es donde este diseño demuestra su valor. Cuando un paso falla parcialmente, el modelo de decisión puede reescribir el resto del plan en lugar de seguir chocando con el que ya está roto.
Patrones que aparecían en todas partes
Más allá de las arquitecturas individuales, había unos cuantos hábitos presentes en casi todas las mejores propuestas.
La gestión del contexto hacía la mayor parte del trabajo
Los mejores equipos entendieron que la calidad del contexto marca el techo de lo bien que puede rendir un agente.
| Estrategia | Enfoque | Ideal para |
|---|---|---|
| Destilación de reglas | Preprocesar la wiki mediante LLM en un resumen de ~320 tokens | Prompts ligeros, arranque rápido |
| Precarga agresiva | Cargar datos de usuario/proyecto/cliente antes de la ejecución | Minimizar llamadas a herramientas |
| RAG híbrido | Flujos de búsqueda regex + semántico + por palabras clave | Necesidades complejas de recuperación |
| Compresión del historial | Mantener completos los turnos recientes y comprimir el historial antiguo | Conversaciones largas |
Trade-off: Los equipos Kc7F2N y f1Uixf comprobaron que la calidad del contexto supera a la cantidad. f1Uixf, de hecho, vio que comprimir el historial perjudicaba el rendimiento, así que mantuvieron el historial completo y se apoyaron en modelos de contexto largo.
Guardrails: cuanto más autónomo es el agente, más los necesita
Los agentes con mejores puntuaciones también tenían las restricciones más estrictas a su alrededor. Suena contradictorio, pero no lo es. Un agente autónomo tiene más formas de equivocarse, así que necesita más puntos en los que algo pueda detenerlo.
| Tipo de guardrail | Cuándo | Ejemplo |
|---|---|---|
| Puertas previas a la ejecución | Antes de que arranque el bucle principal | Security Gate Agent valida permisos frente a las reglas de la wiki |
| Validadores en bucle | Durante el razonamiento | StepValidator comprueba cada acción propuesta y fuerza una revisión si es defectuosa |
| Guardas posteriores a la ejecución | Antes del envío final | El sistema de guardas de tres modos valida la completitud de la respuesta |
Wrappers de herramientas inteligentes
Los mejores equipos construyeron capas de abstracción sobre la API en bruto:
- Autopaginación: Los wrappers recorren todas las páginas y devuelven el dataset completo.
- Normalización difusa: “Willingness to travel” se traduce al campo de API
will_travel. - Herramientas de razonamiento especializadas: herramientas
think,planycriticpara deliberación controlada.
Modos de fallo comunes y cómo los solucionaron los ganadores
Incluso los mejores agentes compartían los mismos puntos ciegos. Las soluciones fueron estructurales, no simples ajustes de prompts:
| Modo de fallo | Descripción | Solución arquitectónica |
|---|---|---|
| Bypass de permisos | Ejecutar acciones restringidas sin verificar los permisos del usuario | Security Gate Agent previo a la ejecución; secuencia obligatoria Identity → Permissions → Execution |
| Falta de enlaces a entidades | Respuesta textual correcta pero sin los enlaces de referencia obligatorios | LinkGeneratorAgent integrado en la herramienta de respuesta |
| Agotamiento por paginación | Procesar solo la primera página de los resultados de listas | Wrappers de autopaginación para todos los endpoints de listas |
| Bucles de llamadas a herramientas | Quedarse atascado llamando repetidamente a la misma herramienta con pequeñas variaciones | Límites de turnos; modelos centrados en razonamiento (Qwen3) |
| Sobrecarga de contexto | Llenar el contexto con secciones irrelevantes de la wiki | Destilación de reglas; filtrado dinámico de contexto |
Conclusiones
Si estás construyendo agentes y quieres aplicar esto:
- Usa pipelines multiagente. Los agentes monolíticos perdieron. Los mejores equipos usaron entre 3 y 5 especialistas para seguridad, extracción de contexto, planificación y ejecución.
- Automatiza la iteración de prompts. El prompt ganador era la versión 80. Un bucle encontrará patrones de fallo que nunca detectarías a mano.
- Dedica esfuerzo real a los guardrails. Comprobaciones de seguridad previas, críticos en bucle y guardas posteriores a la ejecución. Los agentes que parecían más autónomos eran los más acotados.
- Envuelve tus herramientas. Paginación, enriquecimiento de datos y fuzzy matching deben vivir en wrappers. Un equipo construyó más de 20 enrichers que observaban respuestas de la API en tiempo real.
- Tómate en serio la estrategia de contexto. Destilación de reglas (resúmenes de ~320 tokens), precarga y filtrado dinámico. La velocidad también ayuda. Un equipo corría a ~3.000 tokens/segundo, así que podía permitirse replantear con frecuencia.