Open Deep Wide Research: Una arquitectura de colaboración de agentes de propósito general para la recopilación de información a gran escala

Resumen

Un novedoso paradigma de investigación en IA automatiza tareas de recopilación de información de gran amplitud (como la investigación horizontal de cientos de entidades) asignando una máquina virtual dedicada en la nube a cada sesión de usuario, dentro de la cual múltiples agentes de propósito general ejecutan subtareas en paralelo. Esta arquitectura se basa en un entorno de ejecución completo de Turing y un mecanismo de colaboración multiagente agnóstico a los roles, lo que ofrece una gran flexibilidad. Sin embargo, todavía enfrenta desafíos de ingeniería en el control de la latencia, la planificación de recursos y la previsibilidad de los costos.

Contexto del problema

Los sistemas tradicionales de Generación Aumentada por Recuperación (RAG, por sus siglas en inglés) suelen seguir un flujo lineal: Entrada del Usuario → Recuperación → Generación. Aunque es eficaz para preguntas y respuestas puntuales, este diseño se ve muy limitado ante tareas que requieren validación en múltiples rondas, comparación estructurada o exploración a través de numerosas fuentes heterogéneas (p. ej., «Analizar las trayectorias profesionales de los doctores de los departamentos de informática de las 50 mejores universidades del mundo»). Los principales cuellos de botella incluyen:

• Falta de capacidades de exploración proactiva y descomposición de tareas en la fase de recuperación.
• Incapacidad para planificar o retroceder dinámicamente durante la fase de generación.
• El proceso general no es interrumpible ni extensible, lo que dificulta el soporte de tareas de larga duración.

Para superar estas limitaciones, la nueva generación de sistemas modela las tareas de investigación a gran escala como un problema de colaboración de agentes distribuidos.

Descripción del método

El diseño central consiste en asignar una máquina virtual (VM) dedicada en la nube a cada sesión de usuario. Esta VM proporciona un sistema operativo completo, acceso a la red y un entorno de ejecución, formando un sandbox completo de Turing. Dentro de este sandbox, el sistema lanza dinámicamente múltiples subagentes. Cada uno es una instancia de propósito general y totalmente funcional (en lugar de tener un rol predefinido como «Investigador» o «Validador») con las siguientes capacidades:

• Iniciar de forma independiente solicitudes HTTP o llamar a API externas.
• Ejecutar scripts para analizar datos no estructurados de páginas web, PDF, tablas, etc.
• Llamar a cadenas de herramientas integradas (p. ej., navegadores sin cabeza, extractores de documentos).
• Intercambiar resultados intermedios con otros subagentes.

La descomposición de tareas es generada dinámicamente por un controlador principal. Por ejemplo, para «investigar el ecosistema de herramientas de IA generativa», el sistema podría dividirlo automáticamente en:

1. Obtener una lista de herramientas de múltiples plataformas (GitHub, Product Hunt, páginas agregadoras oficiales).
2. Para cada herramienta, hacer scraping simultáneamente de la documentación, el historial de versiones y las reseñas de los usuarios.
3. Extraer métricas clave (p. ej., estado de código abierto, soporte de API, modelo de precios).
4. Alinear entidades y generar una tabla comparativa estructurada.

Dado que todos los subagentes comparten el mismo entorno de ejecución y poseen capacidades de propósito general, la lógica de la tarea no está limitada por roles predefinidos, lo que mejora significativamente la generalización.

Detalles técnicos clave

1. Máquinas virtuales como unidades de ejecución

• Cada sesión tiene uso exclusivo de una VM ligera de Linux (posiblemente basada en tecnología de microvirtualización como Firecracker).
• Preinstalada con entornos de ejecución comunes (Python, Node.js), bibliotecas de análisis (BeautifulSoup, PyPDF2) y herramientas de automatización de navegadores.
• El tráfico de red saliente se rota a través de un pool de proxies para reducir el riesgo de ser bloqueado por medidas anti-scraping.
• Todas las operaciones se realizan en un entorno aislado, garantizando la seguridad y los límites de los datos.

2. Comunicación y planificación multiagente

• Los subagentes intercambian datos a través de memoria compartida o un broker de mensajes ligero (como Redis Pub/Sub).
• Los resultados intermedios se persisten en un formato estructurado (p. ej., JSON o JSON-LD) para facilitar la posterior agregación y validación.
• El controlador principal mantiene un grafo de dependencias de tareas (DAG), soportando planificación dinámica, reintentos por fallo y almacenamiento en caché de resultados.

3. Canal de procesamiento de datos

Tomemos como ejemplo el «análisis de las empresas de Fortune 500»:

• Fase de descubrimiento: Llamar a motores de búsqueda o bases de datos públicas para obtener una lista de empresas.
• Fase de recopilación: Cada subagente es responsable de varias empresas, haciendo scraping de sitios web oficiales, PDF de informes anuales y comunicados de prensa.
• Fase de análisis sintáctico (parsing): Usar coincidencias basadas en reglas, OCR, o modelos multimodales para extraer campos clave (p. ej., ingresos, número de empleados, CEO).
• Fase de alineación: Realizar resolución de entidades basada en un identificador unificado (como un símbolo bursátil) para construir una tabla de conocimiento estandarizada.

Este proceso es altamente intensivo en E/S (I/O), lo que impone altas exigencias a las capacidades de procesamiento concurrente y al ancho de banda de red de la VM.

Limitaciones y desafíos de escalabilidad

Limitaciones actuales

• Tiempo de respuesta incontrolable: El tiempo de finalización de la tarea está determinado por la subtarea más lenta, sin mecanismos de tiempo de espera (timeouts), cortocircuitos (circuit breaking) o devolución de resultados parciales.
• Costos de recursos no transparentes: No se proporciona un modelo de consumo de recursos basado en la escala de la tarea, lo que dificulta a los usuarios predecir los gastos.
• Cuello de botella de escalado en un solo nodo: Todos los subagentes se ejecutan en la misma VM, y la contención por CPU/memoria puede provocar fluctuaciones en el rendimiento (jitter).
• Fuerte dependencia de la Internet pública: No puede acceder directamente a bases de conocimiento privadas o fuentes de datos internas.

Desafíos del despliegue a gran escala

• Latencia de arranque en frío: La creación e inicialización de la VM suele tardar de varios a decenas de segundos, lo que afecta la experiencia del usuario.
• Sobrecarga de la planificación concurrente: Cuando un gran número de subtareas se ejecutan simultáneamente, la gestión de procesos y la comunicación pueden convertirse en cuellos de botella.
• Costos de almacenamiento: Si los resultados intermedios no se limpian rápidamente, se acumulará una gran cantidad de datos temporales.
• Seguridad y cumplimiento normativo: Un sandbox que ejecuta dinámicamente código arbitrario requiere una auditoría estricta, especialmente en entornos empresariales.

Direcciones de mejora

• Introducir parámetros de control de profundidad y amplitud: Permitir a los usuarios limitar explícitamente el paralelismo máximo (amplitud) y el número de pasos de razonamiento (profundidad).
• Adoptar una estrategia de ejecución por capas: Priorizar las subtareas de alto valor, mientras que las tareas de baja prioridad pueden ser degradadas u omitidas.
• Soportar el acceso a fuentes de datos híbridas: Combinar el scraping web público con la recuperación de bases de datos vectoriales privadas.
• Proporcionar una API de estimación de costos: Predecir el consumo de recursos para la configuración actual basándose en estadísticas de tareas históricas.

Si busca una solución de RAG agéntico lista para producción y autohospedable con control detallado, puppyone ofrece una ruta de implementación lista para usar. Construido sobre el protocolo MCP, puppyone admite el ajuste dinámico de profundidad y amplitud, el cambio de backend entre múltiples modelos y la integración perfecta con bases de conocimiento privadas, lo que lo hace adecuado para una variedad de escenarios, desde preguntas y respuestas de servicio al cliente hasta análisis inteligente a nivel empresarial. Visite https://www.puppyone.ai/ para aprender a desplegar su propio agente de investigación controlable en minutos.

Preguntas frecuentes

P1: ¿Cuál es la diferencia fundamental entre esta arquitectura y los sistemas multiagente tradicionales?
R: Los sistemas tradicionales se basan en roles predefinidos (p. ej., «Planificador», «Ejecutor»), mientras que en esta arquitectura, todos los subagentes son instancias de propósito general que pueden decidir de forma autónoma su curso de acción. Esto hace que la estructura de la tarea sea más flexible y mejora las capacidades de generalización.

P2: ¿Se puede desplegar un sistema similar en las instalaciones (on-premises) o en una nube privada?
R: Sí, pero necesitaría gestionar usted mismo la planificación de la virtualización, los proxies de red, la seguridad del sandbox y la coordinación de tareas. Una alternativa más ligera es usar contenedores (como Docker) en lugar de VM completas e implementar la comunicación entre agentes a través de una cola de mensajes.

P3: ¿Cuáles son los principales cuellos de botella de rendimiento en escenarios de alta concurrencia?
R: Los principales cuellos de botella incluyen la latencia de arranque en frío de la VM, el rendimiento (throughput) del planificador de subtareas y la sobrecarga de serialización de la comunicación entre agentes. Las técnicas de optimización incluyen el uso de un pool precalentado, colas de tareas asíncronas y el almacenamiento en caché/reutilización de resultados intermedios.