NVIDIA y LangChain afinan Nemotron 3 Ultra para agentes

NVIDIA y LangChain han presentado una configuración específica de LangChain Deep Agents para Nemotron 3 Ultra, el modelo de lenguaje de NVIDIA orientado a tareas complejas. El anuncio importa menos por un nuevo entrenamiento del modelo que por el método: el rendimiento se ha elevado modificando las instrucciones, las herramientas y la ejecución del agente.

Según NVIDIA, esa configuración logra la mayor precisión entre los modelos abiertos en el benchmark público Deep Agents de LangChain y alcanza una paridad en tareas empresariales con los modelos cerrados mejor puntuados. La compañía también asegura un coste de inferencia por ejecución diez veces inferior al de los principales modelos cerrados.

El agente no es solo el modelo

Un agente de IA es un sistema que no se limita a responder texto: puede consultar información, usar herramientas de software, conservar contexto y encadenar pasos para completar una tarea. En esos sistemas, el modelo es una pieza importante, pero no trabaja solo.

LangChain ha centrado el ajuste en lo que denomina harness, el entorno que coordina al agente. El equipo analizó los registros de ejecución de Nemotron 3 Ultra en su conjunto de pruebas para identificar en qué pasos perdía puntuación. Después retocó las instrucciones de sistema, las descripciones de las herramientas y el software intermedio que organiza las llamadas del agente.

No hubo, de acuerdo con el anuncio, reentrenamiento ni ajuste fino de los pesos del modelo. Es una distinción relevante para las empresas: reentrenar un modelo grande exige datos, capacidad de cálculo y tiempo; mejorar la capa de orquestación puede ser más rápido y estar al alcance de equipos de producto.

El resultado tampoco debe interpretarse como que un modelo abierto haya superado de forma general a todos los modelos propietarios. Las cifras proceden del benchmark Deep Agents y miden el comportamiento dentro de ese marco de evaluación. La utilidad real dependerá de las herramientas conectadas, los datos internos, las tareas y los controles de cada organización.

Una pila abierta para desplegar y controlar

El trabajo se distribuye mediante NemoClaw para LangChain Deep Agents, un plano de referencia abierto de NVIDIA. Combina el código de Deep Agents adaptado a Nemotron 3 Ultra con OpenShell, un entorno de ejecución diseñado para que las acciones del agente se realicen con controles de seguridad.

La propuesta busca que una empresa pueda controlar las tres capas del sistema: el modelo, el mecanismo que coordina herramientas y memoria, y el entorno donde se ejecutan acciones. Eso resulta especialmente importante cuando los agentes acceden a aplicaciones corporativas, bases de datos o procesos que afectan a clientes y operaciones.

La apertura de la pila no elimina por sí misma los riesgos. Un agente puede seguir equivocándose al interpretar una instrucción, seleccionar una herramienta inadecuada o actuar con permisos excesivos. Por eso, la promesa de poder inspeccionar y modificar cada capa tiene valor si se acompaña de evaluaciones continuas, límites de acceso y revisión de acciones sensibles.

El coste decide qué agentes llegan a producción

NVIDIA sostiene que el perfil afinado permite completar más tareas con mayor rendimiento y por una décima parte del coste de inferencia de modelos cerrados líderes. Si ese ahorro se confirma en despliegues propios, puede cambiar la economía de los agentes: las compañías podrían probar más configuraciones, evaluar sus sistemas de forma recurrente y reservar modelos más caros para casos donde aporten una ventaja medible.

LangChain afirma contar con más de 200 millones de descargas mensuales de su plataforma, una escala que convierte esta integración en una vía de distribución relevante para NVIDIA. El perfil ajustado ya puede obtenerse desde LangChain, mientras que Nemotron 3 Ultra está disponible alojado en Baseten, Crusoe Cloud, DeepInfra, Fireworks, Nebius y Together AI.

La siguiente prueba no será el benchmark, sino el uso sostenido en procesos reales. Las organizaciones tendrán que medir no solo cuántas tareas completa el agente, sino cuánto cuesta supervisarlo, qué errores comete y si el control de una pila abierta compensa la responsabilidad adicional de operarla.

Un cambio de harness puede parecer un cambio de inteligencia

El tutorial de NVIDIA describe un ciclo: ejecutar la evaluación, leer trazas, proponer cambios en instrucciones o middleware y volver a pasar la prueba. Ese método puede corregir fallos reales. También puede sobreajustar el sistema al conjunto conocido si las mismas tareas guían cada decisión. Por eso hace falta reservar casos que los diseñadores no vean hasta el final.

Modelo, prompt, descripción de herramientas, memoria, bucle de ejecución y entorno forman el sistema evaluado. Cambiar cualquiera puede alterar el resultado sin tocar los pesos. Una comparación reproducible debe versionar todas esas capas y conservar las trazas. Decir solo «Nemotron 3 Ultra» borra parte de la intervención que produjo la puntuación.

Cómo comprobar que la mejora es transferible

Primero se divide el conjunto entre desarrollo y prueba cerrada. Después se clasifican los fallos por causa: información ausente, herramienta mal elegida, argumento incorrecto, lectura incompleta, acción no autorizada o respuesta final defectuosa. Una corrección debe mejorar su categoría sin aumentar otra. Ejecutar varias veces revela la variabilidad que una única puntuación oculta.

La cifra de coste necesita denominador. «Una décima parte» puede referirse a precio de tokens por ejecución, pero un agente barato que repite pasos o exige más supervisión puede costar más por tarea resuelta. Hay que sumar llamadas, tokens, tiempo, infraestructura, revisión y recuperación de errores, y medirlos solo entre resultados que superan el mismo umbral de calidad.

El repositorio abierto de Deep Agents permite inspeccionar el harness y fijar versiones. La apertura es útil para auditoría y modificación; no convierte en seguros los permisos. Un agente debe recibir identidad propia, mínimo acceso, límites de gasto, confirmación antes de acciones irreversibles y un registro que una persona pueda reconstruir.

Las descripciones de herramientas merecen una prueba específica. Una frase ambigua puede hacer que el modelo elija una operación de escritura cuando bastaba leer, confunda identificadores o omita un parámetro. Cada herramienta debería declarar precondiciones, efectos, errores, reversibilidad y ejemplos negativos. Después se incluyen pares de herramientas parecidas en la evaluación para comprobar que el agente distingue sus límites. Mejorar una descripción puede elevar la precisión sin cambiar el modelo, pero también amplía el contrato que el equipo debe mantener cuando la API evoluciona.

La memoria introduce otro componente. Conservar todo aumenta contexto y exposición; resumir puede perder una restricción. La prueba debe incluir instrucciones que cambian, secretos que no deben reaparecer y objetivos largos, y comprobar qué recuerda el agente, durante cuánto tiempo y quién puede borrarlo. Una mejora de continuidad no merece desplegarse si conserva datos que el usuario esperaba retirar. El borrado debe poder verificarse y quedar registrado sin reproducir el contenido sensible.

La prueba de producción

Antes de desplegar, una organización puede escoger tareas frecuentes y adversas, fijar criterios de éxito y medir finalización, exactitud, intervención humana, coste y daño potencial. Después ejecuta el perfil nuevo y el anterior sobre los mismos casos sin revelar al revisor cuál es cuál. Solo entonces decide si el cambio merece pasar a un entorno limitado.

La capacidad transferible es evaluar al agente como una pila versionada, no atribuir todo al modelo. Una mejora de instrucciones puede valer mucho, pero debe sobrevivir a tareas nuevas, repetición, costes completos y límites de autoridad.