NVIDIA NeMo Retriever anuncia un pipeline agentic que prioriza la generalizabilidad por encima de trucos específicos de conjunto de datos. ¿El resultado? El mismo diseño alcanzó el puesto #1 en ViDoRe v3 y #2 en la exigente BRIGHT, mostrando que una arquitectura agentic puede adaptarse a búsquedas visuales y a razonamiento profundo sin cambiar la base del sistema.
Qué es y por qué importa
La idea central es simple pero poderosa: juntar lo mejor de dos mundos. Los LLM piensan y razonan muy bien, pero no pueden mirar millones de documentos de golpe. Los retrievers hacen barridos masivos, pero carecen de razonamiento iterativo. ¿La solución? Un bucle activo entre el LLM y el retriever: el agente piensa, genera mejores consultas, recupera, evalúa y repite hasta converger.
Esto no es solo mejorar la similitud semántica. Cuando los documentos son visualmente complejos o las preguntas requieren pasos lógicos, necesitas algo que haga búsqueda iterativa, reformulación persistente y descomposición de consultas. Eso es exactamente lo que implementa el pipeline NeMo: un agente que actúa, reevalúa y sintetiza resultados.
Cómo funciona (arquitectura agentic)
El pipeline sigue una arquitectura tipo ReACT: en lugar de una única consulta, el agente itera. Usa herramientas internas como think para planear, retrieve(query, top_k) para explorar el corpus y final_results para devolver los documentos finales más relevantes.
Patrones emergentes que observaron:
- El agente genera mejores queries dinámicamente a medida que descubre información nueva.
- Refrasea persistentemente hasta encontrar señales útiles.
- Descompone consultas multi-paso en subconsultas claras y manejables.
Como medida de seguridad, cuando se alcanza el límite de pasos o de contexto, el pipeline cae en Reciprocal Rank Fusion (RRF) para combinar las listas de ranking de todas las llamadas del agente.
Optimización práctica: MCP vs retriever singleton en proceso
Al principio usaron un servidor MCP para dar acceso al LLM a herramientas externas. En la teoría suena bien, pero en la práctica creó fricción: cada experimento necesitaba levantar un MCP, cargar corpus en GPU, orquestar procesos y lidiar con latencia por round-trips de red. Eso reduce la velocidad de experimentación y aumenta las posibilidades de fallos silenciosos.
La solución ingeniosa fue reemplazar el servidor por un retriever singleton thread-safe que vive en el mismo proceso. Este singleton carga modelo y embeddings una sola vez, protege accesos con un reentrant lock y expone la misma interfaz retrieve() a múltiples tareas concurrentes. Beneficios:
- Elimina la serialización por red y reduce latencia.
- Mejora la utilización de GPU y la velocidad de experimentación.
- Reduce errores de despliegue y la complejidad operacional.
Resultados clave en ViDoRe v3 y BRIGHT
NeMo Agentic Retrieval (Opus 4.5 + nemotron-colembed-vl-8b-v2) alcanzó NDCG@10 = 69.22 y quedó #1 en ViDoRe v3. En BRIGHT, que es más orientado a razonamiento, su misma arquitectura quedó #2 con NDCG@10 = 50.90.
Comparativas relevantes:
- ViDoRe v3: agente (69.22) > dense retrieval (64.36) > INF-X-Retriever (62.31).
- BRIGHT: INF-X-Retriever lidera con 63.40; NeMo agentic queda segundo con 50.90.
Datos operativos (ejemplos medidos):
- En ViDoRe, Opus 4.5 promedió ~136.3 segundos por consulta y cerca de 9.2 llamadas de recuperación por consulta.
- En BRIGHT, Opus 4.5 promedió ~148.2 segundos por consulta y ~11.8 llamadas.
Sí, el agente es mucho más lento que un retriever denso, pero entrega un salto de calidad en tareas complejas.
Ablaciones y lecciones técnicas
Varias conclusiones prácticas de sus experimentos:
-
Model choice: cambiar Opus 4.5 por el abierto
gpt-oss-120ben ViDoRe provoca una caída moderada (69.22 -> 66.38 NDCG@10) y reduce el número de llamadas de recuperación. En BRIGHT la diferencia es mayor: las tareas de razonamiento profundo todavía se benefician significativamente de modelos frontier como Opus. -
Embeddings: usar embebidos especializados (
nemotron-colembed-vl-8b-v2para ViDoRe yllama-embed-nemotron-reasoning-3bpara BRIGHT) aumenta el techo de performance. Un retriever fuerte le da más margen al agente para brillar. -
Robustez cross-domain: soluciones altamente optimizadas para un dominio (por ejemplo INF-Query-Aligner) no siempre mejoran sobre el baseline denso en otros dominios. El loop agentic tiende a adaptarse mejor sin heurísticas específicas.
-
El agente reduce la brecha entre embeddings fuertes y débiles. En pruebas, el agente acortó diferencias de 8-19 puntos a unos 4-7 puntos dependiendo del caso.
Coste, latencia y cuándo usarlo
No hay almuerzo gratis: agentic retrieval consume más tokens y tiempo. En ViDoRe comentan números del orden de 760k tokens de entrada y 6.3k tokens de salida por consulta, medidos en una A100 con una llamada concurrente a Claude para reflejar tiempos reales.
Entonces, ¿usarlo o no? Piensa en esto:
- Si la consulta es sencilla y el corpus está bien alineado, el dense retrieval es rápido y suficiente.
- Si la consulta es compleja, multi-paso o el documento es visualmente rico, el agentic ofrece una precisión que compensa el coste.
Hacia dónde van: distilación y agentes ligeros
El equipo planea reducir costes: están trabajando para destilar patrones de razonamiento agentic en agentes más pequeños y de código abierto. La idea es entrenar modelos menores para orquestar nativamente el bucle think + retrieve, logrando precisión cercana a Opus con mucha menor latencia y coste.
Además, la arquitectura es modular: puedes emparejar tu agente preferido con el embedding que prefieras. Para producción, recomiendan probar llama-nemotron-embed-vl-1b-v2 como punto de partida práctico.
Reflexión final
NeMo Retriever muestra que vale la pena construir pipelines que piensen en múltiples pasos y se adapten al dato real, no solo a benchmarks aislados. ¿Te interesa un sistema que entienda documentos visuales y razone en profundidad? Entonces el enfoque agentic merece atención, sobre todo si tu problema es de alto valor y alta complejidad.
Fuente original
https://huggingface.co/blog/nvidia/nemo-retriever-agentic-retrieval