2026-01-11 · Actualizado 2026-07-15

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

Desafío empresarial RAG 3 (ECR3): Diseñando arquitecturas de agentes AI eficaces

El desafío Enterprise RAG Challenge 3 (ECR3) solicitó a los agentes que realizaran tareas empresariales frente a una empresa simulada API. La tabla de clasificación con resultados fijos resulta excepcionalmente útil, ya que muchos participantes no solo publicaron su puntuación, sino también información sobre su arquitectura, combinación de modelos, costes y observaciones relativas a fallos.

Revisé esas descripciones públicas para responder a una pregunta más específica: ¿qué decisiones de diseño aparecieron con frecuencia en las propuestas de alto rendimiento, y cuáles de ellas resultan útiles fuera de este benchmark?

TL;DR: No existió una topología única ganadora. Las propuestas más sólidas iban desde un agente sencillo que solo realizaba llamadas a herramientas hasta sistemas especializados pipelines y de planificación y ejecución. Las ideas recurrentes eran más concretas: aprender de los registros de ejecución fallida, validar los pasos de alto riesgo justo antes de su ejecución, definir de forma explícita las políticas de contexto, y ocultar peligros API como la paginación detrás de envoltorios fiables. La prompt en producción del ganador era su 80ª versión generada automáticamente.

¿Cuál es el desafío de RAG en el ámbito empresarial?

El desafío Enterprise RAG 3 es un proyecto de investigación a gran escala basado en colaboración comunitaria que evalúa cómo los agentes autónomos AI gestionan tareas empresariales complejas. A diferencia de los modelos benchmarks estáticos, ECR3 se ejecuta en la Agentic Enterprise Simulation (AGES), una simulación de eventos discretos que proporciona acceso a empresa realista API.

Qué prueban los benchmark

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

• Perfiles de empleados con habilidades y departamentos específicos
• Proyectos con asignaciones de equipo y relaciones con clientes
• Wiki corporativo con reglas empresariales y jerarquías de permisos
• Control de tiempo 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 tanto, un agente no puede resolver todo el conjunto memorizando el estado de la empresa en un solo caso.

Considere las puntuaciones como una instantánea del estado actual

ECR3 ahora ofrece tanto una tabla de clasificación de la competición congelada como un benchmark público al que se siguieron enviando ejecuciones incluso después de finalizar el evento. Estas páginas responden a preguntas diferentes. Las cifras que se presentan a continuación describen la tabla de premios en el momento del corte de la competición, y no las sesiones con mejores resultados posteriores:

La página en tiempo real de benchmark puede presentar puntuaciones más altas, ya que incluye las ejecuciones realizadas posteriormente. Por eso, la tabla de clasificación congelada constituye la fuente adecuada para determinar quién ganó la competición.

Tipos de tareas

Las tareas abarcan varios ámbitos de habilidad:

• Razonamiento multi-hop, como la correspondencia entre las habilidades de los empleados y las asignaciones de proyectos.
• Validación de permisos, como el bloqueo de cambios no autorizados en salarios o del acceso a datos.
• Consultas ambiguas, que incluyen solicitudes multilingües y reformuladas.
• Cumplimiento estricto de los resultados, que implica la inclusión obligatoria de enlaces a entidades en las respuestas.

Qué sugieren realmente las propuestas presentadas

Los informes públicos no permiten llegar a una conclusión clara del tipo “multi-agent supera al agente único.” La propuesta que obtuvo el cuarto puesto era explícitamente un diseño basado en un solo agente. Sin embargo, sí se pueden extraer cuatro observaciones más específicas:

1. La descomposición resultaba útil cuando permitía aislar 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, en lugar de recurrir a “roles de agente” arbitrarios.
2. La validación se realizaba más cerca de las acciones irreversibles. Varios sistemas verificaban los permisos antes de ejecutar, revisaban cada paso por separado o protegían la respuesta final.
3. Era importante iterar mediante seguimiento de trazas. El ganador del premio convirtió las ejecuciones fallidas en revisiones prompt mediante un bucle automatizado; otros equipos documentaron correcciones con herramientas igualmente concretas y prompt.
4. La política de contexto era una elección arquitectónica. Los equipos probaron técnicas como destilación, precarga, recuperación de información y compresión de historial. Sus propios informes difieren sobre si la compresión realmente ayudaba, por lo que no existe una solución universal.

Cinco enfoques informativos

Estos no corresponden a los cinco primeros según el orden de clasificación. Los he seleccionado porque sus descripciones públicas revelan cinco métodos distintos para construir el sistema: revisión automatizada de prompt, fases especializadas, validación paso a paso, mecanismos de protección de respuestas e isolamiento entre la fase de planificación y la ejecución. Cuando interpreto por qué un diseño resulta útil, indico dicha interpretación en lugar de considerarla como un resultado obtenido a partir de una lista de mejores prácticas.

1. Evolución prompt engineering (Equipo VZS9FL / @aostrikov)

El el enfoque con la puntuación más alta La automatización de prompt engineering mediante un bucle de auto-mejora.

En lugar de ajustar manualmente el prompt en producción, el equipo desarrolló un triple agent loop que convierte los rastreos fallidos en revisiones candidatas.

Tres agentes pipeline:

El resultado: La producción prompt fue el 80.ª versión generada automáticamente. El equipo describe este bucle como un proceso que analiza las tareas fallidas, propone posibles causas y decide qué sugerencias incorporar. La tabla de clasificación determina la puntuación final y el número de iteraciones; no permite distinguir con precisión cuánto de esa mejora se debe a la automatización y cuánto a los modelos, las herramientas o los comentarios acumulados mediante benchmark.

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

2. Multi-agent secuencial pipeline (Equipo Lcnxuy / @andrey_aiweapps)

Esta propuesta implementó un flujo de trabajo secuencial en el que los componentes especializados se encargaban de las comprobaciones de seguridad, la extracción de contexto, la ejecución y el formateo de enlaces entre entidades.

Los componentes documentados:

1. Agente de Puerta de Seguridad: Comprobación previa a la ejecución que valida los permisos en función de las reglas del wiki antes de que se ejecute el bucle principal.
2. Agente de Extracción de Contexto: Extrae las reglas críticas de archivos masivos prompts y carga por adelantado los datos del usuario, del proyecto y del cliente.
3. Agente de Ejecución: Planificación al estilo ReAct que consta de 5 fases internas (Identidad → Detección de Amenazas → Recopilación de Información → Validación de Acceso → Ejecución).
4. LinkGeneratorAgent: Integrado dentro de la herramienta de generación de respuestas, analiza el contexto para incluir los enlaces a las entidades necesarias.

El agente LinkGenerator es la parte más transferible. Al integrarlo en la herramienta de respuesta, se cumple con un requisito de benchmark —enlaces obligatorios a entidades— que convierte esta característica en una propiedad inherente a la interfaz, en lugar de ser solo otra instrucción que el modelo de ejecución podría olvidar.

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

3. Razonamiento guiado por esquemas con validación por pasos (Equipo NLN7Dw / Ilia Ris)

Este equipo combinó SGR con una inferencia rápida y un validador en cada paso propuesto. Este diseño permite realizar revisiones de forma sencilla: se rechaza un paso defectuoso antes de que se convierta en un tool call, y luego se solicita al flujo principal que lo vuelva a procesar teniendo en cuenta los comentarios del validador.

Componentes clave:

El equipo informó que ejecutó gpt-oss-120b en Cerebras a una tasa de hasta aproximadamente 3.000 tokens por segundo. La inferencia rápida redujo la penalización por latencia en la fase de validación, aunque el ranking no ofrece un análisis de ablación que permita separar el factor velocidad del resto de los aspectos del diseño.

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

4. Sistema de enriquecimiento y protección (Equipo J8Gvbi / @mishka)

Esta contribución incorporó indicaciones no bloqueantes y un sistema de protección por niveles sobre una base SGR. A medida que llegaban las respuestas de API, los enriquecedores las analizaban y añadían orientación operativa al contexto posterior.

El sistema enriquecedor:

Más que 20 enriquecedores Se examinaron las respuestas de API e se injetaron pistas contextuales:

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

Sistema de protección de tres modos:

Wiki híbrido RAG: Tres flujos de búsqueda —basados en expresiones regulares, semánticos y por palabras clave— que gestionaban distintos tipos de consultas en la wiki de la empresa.

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

5. REPL de planificación-ejecución (Equipo key_concept_parallel)

Diferentes modelos se encargaban de tareas distintas: uno se dedicaba a la planificación, otro a escribir código en Python, y un modelo de toma de decisiones separado elegía qué acción realizar después de cada paso.

Configuración multimodelo:

El REPL de finalización de pasos:

1. El planificador crea un paso de alto nivel.
2. El modelo de generación de código funciona en un contexto de modelo nuevo y escribe un script en Python para él.
3. El script se ejecuta en una REPL con ámbito de tarea cuyas variables persisten entre pasos.
4. El modelo de toma de decisiones analiza el resultado y elige: continuar, abortar o replanificar.

La ruta de replanificación corresponde a la idea reutilizable. Cuando un paso falla parcialmente, el modelo de toma de decisiones puede conservar el trabajo ya realizado y reescribir únicamente el plan restante.

Patrones que se repitieron en las entregas

Las implementaciones eran diferentes, pero varios aspectos técnicos surgían una y otra vez en las descripciones públicas.

La gestión de contexto era explícita

Ningún equipo podría proporcionarle al modelo todas las reglas, registros y pasos anteriores sin tener que tomar una decisión relativa a la política a seguir. La diferencia relevante radicaba en el lugar donde cada sistema filtraba la información.

Compromiso: NLN7Dw comprime los turnos anteriores, mientras que f1Uixf Se informó que la compresión de historial perjudicaba los experimentos y que, en su lugar, se mantenía toda la conversación completa. Hay que considerar la compresión como una decisión deliberada, y no como la opción predeterminada.

Se han establecido límites de seguridad en distintas fronteras de fallo

Varias equipos insertaron puntos de verificación antes, durante o después del bucle principal. Estos mecanismos abordan riesgos distintos y no deben ser agrupados en un único “agente crítico” genérico.

Envoltorios de herramientas inteligentes

Varias equipos desarrollaron capas de abstracción alrededor del API en bruto:

• Auto-paginación: Los wrappers recorren cada página y devuelven el contenido completo de dataset.
• Normalización difusa: La “disposición a viajar” se traduce a la will_travel Campo API.
• Herramientas de razonamiento especializadas: think, plan, y critic Herramientas para la deliberación controlada.

Modos de fallo y las soluciones estructurales reportadas por los equipos

Los informes mencionan reiteradamente fallos en API y en los límites de las políticas. Las soluciones más reutilizables han consistido en incorporar dicho requisito directamente al código o en establecer un paso de validación específico para ello:

Un orden de adopción práctico

ECR3 es una empresa simulada, y no constituye un estudio de ablación de agentes generales. Úsala como fuente de hipótesis de diseño y, a continuación, verifica dichas hipótesis mediante tus propios registros. Un orden de implementación razonable es:

1. Primero, haga que la corrección de API sea determinista. Pagine automáticamente los puntos finales de las listas, normalice los campos difusos, valide los esquemas y genere los enlaces necesarios dentro de la herramienta de respuesta.
2. Añada comprobaciones en los límites donde realmente existe riesgo. Verifique la identidad y los permisos antes de realizar una mutación; valide cada paso antes de su ejecución únicamente cuando la llamada adicional al modelo detecte fallos que justifiquen el costo.
3. Elabore una política de contexto. Decida qué contenido se cargará por adelantado, qué se recuperará, qué se comprimirá o qué se mantendrá tal cual. Mida el cumplimiento de dicha política según fragmentos de tarea y no solo en función del número de tokens.
4. Convierta las trazas fallidas en casos de regresión. Clasifique el fallo, modifique un mecanismo y ejecute nuevamente el fragmento afectado. Automatice la revisión de prompt únicamente después de que dicho ciclo resulte fiable.
5. Descomponga cuando quede más clara la responsabilidad. Un componente separado está justificado cuando pueda gestionar una restricción específica, utilizar un modelo o herramienta distinta, o ser probado de forma independiente; no simplemente porque “multi-agent” parezca más capaz.

La lección más importante no es que una arquitectura haya salido victoriosa, sino que las entregas fiables hacen que los requisitos operativos ocultos queden visibles a través de herramientas, validadores y ciclos de evaluación.

Referencias

• Desafío 3 de Enterprise RAG - Página oficial
• Clasificaciones ECR3
• Benchmark: erc3-prod
• Notas de la versión