ServiceNow convierte los fallos de los agentes en datos de entrenamiento

Cada equipo que ha desplegado un agente de IA en un sistema empresarial real conoce el mismo dolor. El modelo es ampliamente capaz, y luego se topa con tus herramientas concretas, tus políticas concretas, tu lío concreto de máquina de estados, y tropieza.

El brazo de investigación de ServiceNow, CoreAI, ha publicado un sistema que intenta convertir esos tropiezos en un activo. Se llama AutoSynthData, y su premisa es que los fallos de un modelo son la materia prima más valiosa que tienes para entrenarlo.

El movimiento central

El pipeline comienza ejecutando un modelo objetivo y un modelo maestro más fuerte contra las mismas tareas de diagnóstico en un entorno real. Donde el modelo objetivo falla y el maestro tiene éxito, hay una brecha de capacidad. AutoSynthData destila esa brecha en lo que el equipo llama tarjetas de especificación de capacidades: descripciones saneadas de las herramientas, flujos de trabajo, estados finales y variaciones permitidas implicados, despojadas de los prompts de evaluación originales y de los detalles de entidades.

Esas tarjetas siembran la generación de nuevas tareas. De forma crucial, el generador nunca ve las trayectorias de evaluación originales, por lo que los datos resultantes ponen a prueba la competencia subyacente en lugar de secuencias memorizadas. El framework escala esto en dos fases. Una fase objetivo crea tareas centrales en paralelo. Una fase de multiplicación toma las tareas verificadas y genera variantes con nuevas formulaciones, nuevas configuraciones de entidades y nuevos estados iniciales. Una regla evita que los datos se desvíen: una muestra multiplicada nunca puede sembrar otra multiplicación.

Tres condiciones para una tarea que vale la pena generar

ServiceNow es explícito en que una solicitud que parece plausible no es suficiente. Una tarea generada debe satisfacer tres cosas a la vez.

Tiene que ser factible, es decir, debe existir al menos una ruta ejecutable a través del entorno que complete la solicitud respetando las reglas. Tiene que ser realista, es decir, debe reflejar trabajo que un usuario real pediría de verdad, en lugar de una acción técnicamente válida que nadie realizaría. Y tiene que ser difícil, es decir, debe apuntar a una debilidad genuina. Una tarea trivial no enseña nada, y una imposible enseña la lección equivocada.

Cada tarea se entrega con un verificador, y el verificador tiene que cumplir su propio estándar. Debe ser consistente con el prompt y el estado del sistema, lo bastante sólido como para rechazar violaciones de restricciones, y lo bastante completo como para aceptar cualquier solución funcional en lugar de insistir en una única ruta de referencia.

Los controles de calidad son el verdadero producto

La parte de esto que merece atención no es la generación de tareas. Es la comprobación.

Cada candidato pasa por dos controles. Un control positivo ejecuta la solución de referencia dentro del entorno para confirmar que la respuesta prevista satisface de verdad al verificador, lo que detecta discrepancias entre el prompt, el estado inicial y los criterios de éxito. Un control negativo muta después deliberadamente el estado final para confirmar que los resultados incorrectos se rechazan de verdad. Ese segundo control es el que detecta verificadores subespecificados, del tipo que recompensaría encantado una trayectoria de agente malformada.

Cuando un candidato falla, un crítico diagnostica el fallo, detectando referencias rotas o estados contradictorios, y dirige una reparación acotada en lugar de descartar el trabajo directamente. Por encima del nivel de muestra, una revisión por lotes observa el agregado: qué grupos de tareas están sobrerrepresentados, qué dimensiones faltan, qué patrones de generación se siguen atascando. El controlador orienta entonces el siguiente lote hacia las brechas que quedan.

Por qué se necesitan datos sintéticos en absoluto

Vale la pena dar un paso atrás para preguntar por qué importa esto. Los datos de entrenamiento ideales para un agente empresarial son un registro de personas reales haciendo trabajo real en el sistema real, correctamente etiquetado. Esos datos son escasos, sensibles y caros de recopilar, y gran parte de ellos no pueden salir de la organización por motivos de privacidad o cumplimiento.

La generación sintética es la válvula de escape, pero viene con un modo de fallo conocido. Si generas tareas a partir de un modelo, heredas sus puntos ciegos, y los datos resultantes pueden parecer abundantes mientras enseñan muy poco. Toda la contribución de AutoSynthData es la maquinaria alrededor de la generación que mantiene los datos honestos: controles que rechazan tareas malas, comprobaciones de diversidad que evitan la repetición y un currículo que sigue apuntando a lo que el agente aún no domina. La generación sin verificación es ruido. Este es un intento de convertirla en señal.

Lo que dicen los números, y lo que no dicen

En pruebas sobre EnterpriseOps Gym, un entorno de código abierto para tareas de agentes empresariales, un modelo basado en Gemma ajustado con 2.000 muestras de AutoSynthData mejoró su métrica Pass@1 en un 35 % respecto a la línea base en un dominio híbrido. En el dominio ITSM, el ajuste fino supervisado sintético elevó el Pass@1 medio del 18,77 % al 27,18 %.

Son ganancias reales en un benchmark específico, lo que no es lo mismo que un resultado general. La dependencia central del pipeline es honesta y vale la pena decirla claramente: necesita un modelo maestro significativamente más fuerte que demuestre el comportamiento correcto, y un entorno de simulación preciso en el que probar. En una empresa sin un sandbox de alta fidelidad y verificadores deterministas fiables, construir la capa de ejecución es en sí mismo un proyecto de ingeniería serio. AutoSynthData no elimina ese trabajo. Cambia para qué sirve el trabajo.

La trampa del modelo maestro

Hay una dependencia en este diseño que merece su propia frase. Todo el pipeline funciona sobre la brecha entre un modelo débil y uno fuerte. En los experimentos, el maestro era un modelo mucho más grande que el objetivo. Eso funciona cuando tienes un sistema de frontera del que tomar prestado. Funciona menos bien cuando tú eres la frontera, o cuando la tarea es tan especializada que no existe ningún modelo más fuerte que la demuestre. En ese caso, el pipeline no tiene nada de lo que aprender, y la brecha de capacidad de la que depende es simplemente un muro. La investigación sobre generación de datos de entrenamiento siempre termina topando con esto: el método escala siempre que alguien, en algún lugar, ya haya resuelto el problema.

Por qué esta es la forma de la IA empresarial

Lo interesante de este lanzamiento es lo que admite sobre dónde está realmente la IA empresarial. El cuello de botella ya no es conseguir un modelo capaz. El cuello de botella es conseguir que un modelo capaz opere correctamente dentro de una organización concreta, con sus herramientas y reglas concretas, donde los fallos son sutiles y el espacio de estados es grande.

Durante años, la respuesta fue la anotación manual, que es lenta, cara y difícil de escalar. AutoSynthData es un argumento de que los fallos mismos contienen la señal, si puedes extraerlos, verificarlos y diversificarlos sin filtrar el conjunto de evaluación. El pipeline está disponible para investigación en Hugging Face, y el equipo dice que lo siguiente es el aprendizaje por refuerzo con la misma metodología.

Si funciona de forma generalizada, la implicación es que la habilidad escasa en IA empresarial cambia. Deja de tratarse de adquirir datos y pasa a tratarse de construir entornos lo bastante buenos como para generar datos fiables dentro de ellos. Ese es un problema más difícil, y más duradero, porque el entorno de una empresa es lo que ningún competidor puede copiar.