El router multiagente de Valyu de 0,6B: resultados, límites y adopción

Un router pequeño puede superar a un modelo mayor guiado solo por instrucciones si ha aprendido qué agentes de búsqueda devuelven pruebas útiles. En el estudio de Valyu, un Qwen3-0.6B posentrenado alcanzó un NDCG@10 medio de 0.771, frente a 0.594 de Amazon Nova Lite y 0.552 de Claude Haiku 4.5. La latencia media de selección fue de 120.1 ms. Son resultados de una arquitectura concreta, no una prueba de que un modelo de 600 millones de parámetros sea mejor que Haiku en general. [1]

La pregunta comercial no es si conviene sustituir todos los modelos grandes. Es si tu sistema de recuperación acumula suficientes errores de selección, datos fiables de evaluación y volumen de consultas para justificar un especialista entrenado. Esta revisión explica el resultado, una limitación importante de la métrica y las pruebas que debes reunir antes de encargar la implementación.

Fuentes revisadas el 13 de septiembre de 2026. Es un análisis documental, no una reproducción del experimento por Wavect. El trabajo figura en el programa del taller AgentSearch de SIGIR 2026; no lo presentamos como una aceptación en el programa principal de la conferencia. [2]

¿Qué superó realmente el router SLM de Valyu?

Los autores comparan un router entrenado con ajuste fino supervisado (SFT) y aprendizaje por refuerzo (RL) con dos modelos dirigidos mediante instrucciones. La selección se realiza sobre un conjunto fijo de 11 agentes especializados. El modelo pequeño también genera palabras clave y límites de fechas para la llamada de búsqueda posterior. [1]

La mejora absoluta de la media es de 0.177 respecto a Nova Lite y 0.219 respecto a Haiku. NDCG no es el porcentaje de respuestas correctas. Las medianas similares y las medias distintas indican que merece la pena analizar las consultas difíciles o fallidas, no solo la media favorable. La tabla conserva los separadores numéricos de la fuente original. [1]

En un subconjunto seleccionado específicamente por desajustes entre consulta y agente, las puntuaciones publicadas son 0.918, 0.539 y 0.490. Es evidencia sobre una categoría de fallos, no el resultado general. El artículo ilustra una consulta sobre estructura de proteínas que los modelos de referencia envían a genómica, mientras que el router entrenado elige búsqueda académica. Importa dónde está la información, no solo a qué tema se parecen las palabras. [1]

Seleccionar agentes de recuperación no es seleccionar modelos

Esta decisión forma parte de una arquitectura de generación aumentada por recuperación (RAG): seleccionar evidencia es un paso distinto de generar la respuesta final.

Un router de modelos elige qué modelo responde o ejecuta un paso. Un router de agentes de recuperación elige qué buscador especializado o fuente aporta evidencia. Un reranker reordena documentos después de recuperarlos. Son decisiones diferentes, aunque un mismo producto incluya las tres.

Valyu predice una máscara de bits para seleccionar agentes, palabras clave y un intervalo temporal. Puede elegir varios agentes. Hace más que clasificar temas, pero no coordina cualquier equipo de trabajadores autónomos. Las mejoras pueden proceder de la fuente elegida, de los parámetros de búsqueda o de su interacción. [1]

Para la arquitectura general, consulta nuestra guía de sistemas de agentes con varios modelos. Para infraestructura entre proveedores, utiliza la comparativa de gateways y routers LLM. Este artículo trata una decisión más concreta: entrenar un selector según los resultados de recuperación de un conjunto conocido de fuentes.

Cómo se combinan SFT y el aprendizaje a partir de resultados

SFT establece el contrato de salida. El trabajo describe un conjunto de 56.000 consultas para SFT, dividido en un 70% de entrenamiento, 15% de validación y 15% de prueba. Las etiquetas incluyen fuentes, palabras clave y fechas. Se usa LoRA de rango 16 y alfa 32, precisión bf16, dos épocas y una longitud máxima de secuencia de 512. Son parámetros del experimento, no recomendaciones universales de despliegue. [1]

RL evalúa lo que recupera la ruta elegida. A partir del punto de control supervisado, los autores utilizan REINFORCE++ con 11.000 consultas de registros de producción. La recompensa combina la adecuación de la ruta con la relevancia del contenido y la credibilidad de la fuente. No optimiza exclusivamente NDCG: intención, palabras clave y fechas siguen formando parte del objetivo. Una penalización KL limita la desviación respecto al modelo SFT. [1]

No sumes ambas cantidades y des por hecho que existen 67.000 ejemplos únicos. Describen etapas distintas, no un conjunto documentado sin solapamientos. En tu evaluación, separa familias de consultas parecidas y periodos temporales entre entrenamiento y prueba final.

La información de retorno se utiliza durante el entrenamiento. En ejecución, el router predice dónde enviar una consulta con lo aprendido. No inspecciona primero las respuestas actuales de todos los agentes. Un índice recién vaciado, una fuente modificada o un conector degradado siguen necesitando comprobaciones de salud y rutas alternativas limitadas.

La lección general es supervisar con resultados, no afirmar que SFT nunca pueda aprovecharlos. Un conjunto de etiquetas supervisadas también puede derivarse de evaluaciones de búsqueda. El estudio compara su entrenamiento progresivo con modelos guiados por intención; no descarta todas las demás formas de aprender la utilidad de una fuente.

La ficha pública de Qwen3-0.6B [3] describe el modelo base, no el router de Valyu. Descargar esos pesos no reproduce las puntuaciones. El artículo revisado no ofrece un enlace de descarga del router entrenado. Confirma la disponibilidad del punto de control, los datos y el código antes de presupuestar una instalación directa.

El detalle de NDCG@10 que cambia la interpretación

NDCG premia colocar los resultados más relevantes en las primeras posiciones. Aquí Claude Sonnet 4.6 evalúa resultados agrupados y mezclados sin saber qué router los produjo. Asigna relevancia de 0 a 3 y, después, cada resultado vuelve a su posición original para calcular la métrica. No se añade una etapa de reordenación. [1]

Lo decisivo es el denominador. La sección 4.5.1 calcula el orden ideal clasificando las puntuaciones de los propios resultados devueltos por cada sistema, en lugar de usar un conjunto ideal común. Si todos los resultados son irrelevantes, asigna cero. Las listas cortas no se rellenan hasta diez elementos. [1]

Esto limita las conclusiones posibles con esa cifra aislada. Como ejemplo matemático, diez resultados puntuados todos con 1 y diez puntuados todos con 3 obtienen NDCG@10 = 1 al normalizarse contra su propia lista ordenada. Su utilidad es claramente diferente. Una lista corta y bien ordenada tampoco demuestra una cobertura completa.

La observación no invalida la ventaja publicada. Significa que 0.771 no equivale a un 77,1% de exactitud, cobertura o exhaustividad. Tampoco conviene presentar el resultado, sin matices, como una comparación convencional contra un ideal compartido. Mide además NDCG con un conjunto común, cobertura de evidencia relevante, búsquedas totalmente fallidas y corrección de la respuesta final.

Una evaluación práctica conserva documentos o pasajes relevantes revisados por personas para cada consulta. Todos los routers se comparan con los mismos objetivos, versiones de fuentes y permisos. Guarda también las puntuaciones originales para evitar que una mejora dependa únicamente de cambiar el denominador.

Qué prometen y qué no prometen los 120.1 ms

Los 120.1 ms de media y 179.4 ms en P99 corresponden al selector medido. No incluyen toda la recuperación, reordenación y generación de una respuesta fundamentada. Un P99 observado tampoco es un acuerdo de nivel de servicio. Las colas, arranques en frío, lotes, límites de tokens y patrones de tráfico pueden alterar el resultado. [1]

Hay un detalle de hardware que conviene aclarar antes de reproducirlo. El trabajo menciona vLLM sobre una NVIDIA L4 con 48 GB de RAM, mientras que NVIDIA especifica 24 GB de memoria GPU para una L4. Los 48 GB podrían referirse a la RAM del servidor, pero la redacción no lo demuestra. No lo conviertas en un requisito de 48 GB de VRAM ni en una recomendación de compra. [1] [4]

Mide por separado el tiempo del router y el tiempo total sobre la infraestructura que utilizarás. Incluye arranques en frío, concurrencia representativa, tiempos de espera agotados y rutas alternativas. Un selector rápido ayuda, pero una fuente lenta puede seguir dominando la experiencia del usuario.

Cuatro cuestiones que resolver antes de encargar el router

• El entrenamiento no es equivalente entre sistemas. Se compara un SLM entrenado para el dominio con modelos mayores guiados por instrucciones, no modelos de distintos tamaños entrenados igual. El resultado respalda este sistema especializado, no una regla universal sobre la irrelevancia del tamaño.
• La mejora incremental de RL no queda aislada en la tabla principal. Los resultados de SFT sin RL incluyen coincidencia de fuentes, palabras clave, fechas y latencia, pero no NDCG@10 en la comparación central. Solicita esa ablación antes de atribuir todo el incremento a RL.
• El catálogo es fijo. Once agentes conocidos no equivalen a un mercado cambiante. Nuevas fuentes, cambios del índice y nuevos idiomas necesitan evaluaciones propias. La selección de agentes nuevos mediante representaciones explícitas de capacidades se plantea como trabajo futuro.
• Importan el juez y la composición de las pruebas. Mezclar resultados y ocultar su procedencia es útil, pero la valoración sigue siendo de un modelo. Pide tamaños de la evaluación final y del subconjunto difícil, controles de duplicados, intervalos de confianza y revisiones humanas independientes. La partición SFT no responde a todo ello.

Los propios autores señalan la necesidad de comparar con otros métodos aprendidos, probar distintas configuraciones de agentes y añadir juicios humanos. Son motivos para hacer una comparación controlada, no para descartar el trabajo. [1]

¿Reglas, selector aprendido o SFT más RL?

Empieza por el método menos costoso que supere una prueba de aceptación explícita. LTRR [5] aprende a ordenar recuperadores por su utilidad posterior. RAGRoute [6] estudia la selección ligera de fuentes en RAG federado. Sirven como ideas de comparación, no como implementaciones intercambiables del router de Valyu.

Calcula beneficio mensual = consultas elegibles × ahorro variable neto por consulta − costes fijos mensuales adicionales. Cuenta llamadas a fuentes, inferencia y reintentos en ambos caminos. Incluye amortización del entrenamiento, etiquetado, evaluación y operación entre los costes fijos. Un archivo de pesos pequeño no es un caso de negocio. La guía de coste por tarea desarrolla el marco presupuestario general.

Una arquitectura que separa selección y autorización

El siguiente patrón es una propuesta de implementación de Wavect. No afirmamos que el estudio haya implementado estos controles.

1. Filtra primero las fuentes elegibles. Resuelve organización, identidad, permisos documentales, regiones permitidas y disponibilidad fuera del modelo. El router solo puede elegir fuentes accesibles para la persona solicitante.
2. Valida toda la salida. Acepta únicamente identificadores conocidos, combinaciones permitidas y parámetros de palabras clave y fechas válidos. Limita expansión de llamadas, tamaño y duración. Una salida inválida no autoriza consultar todas las fuentes.
3. Recupera mediante adaptadores que apliquen permisos. Conserva la identidad del solicitante. La relevancia temática no concede acceso.
4. Establece una alternativa acotada. Listas vacías, fallos, dominios desconocidos o selección incierta pueden activar una ruta evaluada por separado, con los mismos permisos y presupuesto. Evita reintentos recursivos.
5. Versiona y observa la decisión completa. Registra versiones del router, catálogo elegible e índice, además de rutas, parámetros normalizados, latencia y resultado. Detecta degradaciones y conserva una reversión.

Almacena solo lo necesario para evaluar y establece límites de conservación y acceso. Las consultas y los fragmentos pueden contener datos de clientes. La inferencia local barata no vuelve seguros los registros de entrenamiento por sí sola. Para el sistema completo, consulta la lista de preparación de RAG para producción y la arquitectura de autorización MCP.

Un piloto de 30 días para enrutamiento de recuperación

Semana 1: identifica el fallo real. Reúne consultas utilizables con sus permisos, versiones de fuentes y resultados. Distingue errores de selección de problemas de fragmentación, indexación, documentos desactualizados o generación. Entrenar un router no repara un corpus defectuoso.

Semana 2: compara referencias económicas. Evalúa reglas, router actual y selector pequeño con etiquetas de resultados sobre las mismas consultas reservadas. Mantén grupos de casos ambiguos, sin resultados y de varias fuentes. Prueba cada idioma de producción: la capacidad multilingüe del modelo base no garantiza la del router entrenado.

Semana 3: mide el valor adicional de RL. Incorpora aprendizaje por resultados solo si la referencia anterior deja una oportunidad material. Compara SFT con SFT+RL, conserva el protocolo del juez y solicita revisión humana ciega de una muestra. Ejecuta en paralelo sin cambiar las respuestas visibles.

Semana 4: despliega de forma limitada o detén el proyecto. Acuerda de antemano calidad, latencia p95/p99, coste por respuesta aceptada y criterios de autorización. Cambia solo un segmento de tráfico si supera las pruebas y conserva una ruta de reversión. Descubrir que basta con búsqueda híbrida convencional también es un buen resultado.

¿Necesitas decidir si encaja en tu producto? La consultoría de IA de Wavect puede ayudarte a definir evaluación, integración y despliegue. El caso de Twinsoft AI aporta experiencia relacionada, no evidencia de que hayamos reproducido este router. La guía de software a medida frente a soluciones existentes ayuda a comparar propiedad y compra.

Consulta una evaluación de enrutamiento de recuperación con tus fuentes, errores recurrentes, tráfico y presupuesto de latencia. El primer entregable debe ser una decisión de implementación basada en pruebas, no la promesa de superar un benchmark.

Fuentes y metodología

1. Estudio de Valyu: métodos, tablas y protocolo de evaluación
2. AgentSearch en SIGIR 2026: programa del taller
3. Qwen3-0.6B: ficha del modelo base público
4. NVIDIA L4: especificación oficial de memoria de GPU
5. LTRR: aprendizaje para ordenar sistemas de recuperación
6. RAGRoute: selección ligera de fuentes para RAG federado

Cabecera: ilustración facilitada con el encargo, basada en la Figura 1 de Kondapalli et al. El artículo original está disponible bajo CC BY 4.0. La imagen se reproduce sin cambios y no representa una implementación de Wavect. [1]