El agente de búsqueda de Amazon SageMaker mejora con RL multi-turno, pero un benchmark retrocede

Amazon informó que su agente de búsqueda de Amazon SageMaker mejoró la calidad de recuperación en un 23,7 por ciento en un benchmark tras una sola época de entrenamiento. El agente Qwen3.6-27B ajustado también redujo su tasa de fallos en esa prueba del 22,89 por ciento al 0,68 por ciento. Sin embargo, no mejoró en todas las evaluaciones.

Ese resultado mixto importa más que una puntuación perfecta. AWS está probando si las empresas pueden enseñar a un modelo más pequeño a navegar sus herramientas de búsqueda en vez de recurrir repetidamente a prompts para un modelo de frontera. El éxito desplazaría parte de la competencia entre agentes desde el tamaño del modelo hacia el entrenamiento específico para cada entorno.

El experimento también revela los límites de ese argumento. AWS comparó el modelo ajustado con su propio modelo base sin ajustar, no con un modelo de frontera actual. Sus benchmarks midieron el comportamiento de recuperación dentro de una configuración controlada, en lugar de la precisión, la latencia y el coste operativo en una implementación empresarial real.

AWS aportó cifras concretas al entrenamiento de agentes multi-turno

El cambio relevante no es que SageMaker pueda ajustar un modelo, sino que AWS evaluó a un agente a lo largo de trayectorias completas de búsqueda.

AWS publicó el experimento el 2 de octubre de 2026, varios meses después de lanzar el aprendizaje por refuerzo multi-turno de SageMaker AI. La empresa utilizó el servicio para personalizar un modelo Qwen3.6-27B destinado a recuperación de información de estilo empresarial.

El agente tenía acceso a dos métodos de búsqueda. BM25, un método de recuperación léxica, encuentra documentos mediante términos exactos y patrones de frecuencia de palabras. La búsqueda vectorial convierte consultas y documentos en representaciones numéricas, lo que ayuda a relacionar conceptos expresados con formulaciones distintas.

Elegir entre esas herramientas es solo una parte de la tarea. El agente también debe reformular consultas débiles, examinar el material recuperado, decidir si conviene realizar otra búsqueda y detenerse antes de agotar sus límites. Cada decisión modifica el contexto disponible para la siguiente.

Esa dependencia explica por qué AWS utilizó aprendizaje por refuerzo multi-turno, o MTRL. La técnica puntúa el comportamiento a lo largo de una secuencia de acciones en vez de tratar cada respuesta del modelo como un evento aislado. La documentación de MTRL de SageMaker describe el objetivo como la maximización de la recompensa acumulada durante toda la secuencia.

Para este experimento, la recompensa fue nDCG@10. La Ganancia Acumulada Descontada Normalizada en el puesto 10 mide si los documentos relevantes aparecen cerca de la parte superior de los diez primeros resultados. Una puntuación de 1 representa una clasificación ideal, mientras que cero significa que el sistema no recuperó ningún documento relevante.

AWS aplicó esa puntuación después de que el agente terminara su trayectoria de búsqueda. También asignó una recompensa de menos uno cuando el agente superaba su límite de turnos o el presupuesto de tokens de un solo turno. Esa penalización convirtió la finalización eficiente en parte del objetivo de aprendizaje.

La empresa reunió material de entrenamiento procedente de FRAMES, BRIGHT, Enterprise RAG, ESCI, Musique y MLQA. Estos conjuntos de datos abarcan preguntas multi-hop, recuperación que exige razonamiento, documentos empresariales, búsqueda de productos y comprensión multilingüe.

El benchmark Enterprise RAG contiene más de 500.000 documentos sintéticos de empresas y 500 preguntas. AWS reservó el 5 por ciento de cada conjunto de datos de entrenamiento para validación.

Las pruebas utilizaron cuatro conjuntos de datos independientes. WixQA cubre preguntas de soporte basadas en la documentación de Wix. Wands evalúa la relevancia en búsqueda de productos, mientras que FreshStack se centra en preguntas recientes de desarrolladores. BrowseComp-Plus pone a prueba consultas de investigación complejas frente a aproximadamente 100.000 documentos web verificados por humanos.

Esa separación es importante porque reduce la probabilidad de que la evaluación simplemente premie ejemplos de entrenamiento memorizados. No elimina todas las formas de contaminación de benchmarks o solapamiento de distribuciones. Aun así, los conjuntos de datos reservados hacen que las mejoras reportadas sean más significativas que las puntuaciones de entrenamiento por sí solas.

AWS modificó solo tres configuraciones expuestas respecto de sus valores predeterminados. Ejecutó una época, utilizó un tamaño de lote global de 128 y permitió 32 rollouts simultáneos. Un rollout es un intento muestreado del agente para completar una tarea de varios pasos.

El servicio más amplio gestiona la recopilación de trayectorias, los checkpoints y las actualizaciones del modelo. También registra recompensas y trazas por turno mediante MLflow gestionado. Según el experimento original del agente de búsqueda, las recompensas de entrenamiento y validación aumentaron antes de estabilizarse hacia el final.

Ese es el hecho detrás del titular. AWS cuenta ahora con un ejemplo público en el que su servicio MTRL gestionado modificó tanto la clasificación de recuperación como el comportamiento de fallo en conjuntos de datos no vistos. La pregunta más importante es qué efecto tiene ese resultado sobre la estrategia predeterminada para crear agentes.

El modelo de frontera predeterminado está ahora bajo presión

AWS cuestiona la premisa de que la fiabilidad debe proceder de invocar el modelo de propósito general más capaz disponible.

Un modelo de frontera suele manejar herramientas desconocidas mejor que un modelo más pequeño porque sus capacidades generales de razonamiento y seguimiento de instrucciones son superiores. Esa ventaja puede convertirlo en el punto de partida más seguro para prototipos. También puede ocultar debilidades en el diseño del entorno del agente.

Un modelo más grande todavía no comprende de forma inherente los índices de búsqueda, filtros, permisos, metadatos o reglas de detención de una empresa. Los equipos suelen describir esos detalles mediante prompts y esquemas de herramientas. Luego pagan para que el modelo interprete esa guía en cada tarea.

AWS propone una división del trabajo diferente. La organización define el entorno y la métrica de éxito, mientras que el aprendizaje por refuerzo convierte la interacción repetida en comportamiento del modelo. El modelo resultante se vuelve más especializado y menos dependiente de instrucciones extensas en tiempo de ejecución.

Ese enfoque presiona la vía de “prompt más modelo de frontera”. La competencia pasa de qué modelo sabe más a qué sistema aprende la secuencia correcta de acciones locales. En la búsqueda empresarial, esas acciones pueden ser acotadas incluso cuando las preguntas subyacentes son variadas.

Por ejemplo, un agente de búsqueda de soporte puede necesitar reconocer códigos de error, priorizar primero las coincidencias exactas, ampliar la consulta cuando los resultados son escasos y detenerse después de encontrar un procedimiento autorizado. Un modelo general puede inferir esa política. Un modelo especializado puede codificarla mediante entrenamiento.

El argumento económico sigue siendo una afirmación, no un resultado de esta evaluación específica. AWS sostiene que los modelos especializados más pequeños pueden ofrecer menor latencia y menor coste de inferencia. Sin embargo, la tabla publicada no contiene mediciones de latencia, totales de tokens, costes de implementación ni una comparación directa con modelos de frontera.

El servicio pasó a estar disponible de forma general como una capacidad serverless de personalización de SageMaker el 3 de junio de 2026. AWS indicó que el lanzamiento incluía orquestación de rollouts, recopilación de trayectorias, entrenamiento, gestión de checkpoints y evaluación. Su anuncio de lanzamiento también mencionó Qwen3.6-27B, Nova Lite 2.0, GPT-OSS-20B y Gemma-4-31B-it entre los modelos y regiones compatibles.

El entrenamiento serverless reduce la barrera de infraestructura, pero no elimina el trabajo de aplicación. Los equipos aún necesitan un entorno de agente invocable, tareas representativas, una verdad de referencia fiable y una recompensa que refleje el éxito real. Las recompensas mal elegidas pueden enseñar a un modelo a optimizar la puntuación sin alcanzar el objetivo empresarial.

Ese requisito favorece a las organizaciones con flujos de trabajo medibles. La calidad de búsqueda funciona bien porque los equipos pueden etiquetar documentos relevantes y calcular métricas de clasificación. La atención al cliente, la ejecución de código y las operaciones estructuradas también pueden producir resultados verificables.

La investigación abierta es más difícil. Una respuesta plausible puede ser incompleta, carecer de respaldo o basarse en una fuente engañosa. Una única puntuación terminal puede no captar esas distinciones.

Por tanto, la presión práctica recae en dos grupos. Los proveedores de modelos deben demostrar por qué sigue valiendo la pena utilizar un modelo general más grande para tareas repetidas y acotadas. Los equipos de IA empresarial deben decidir si sus cargas de trabajo son lo bastante estables como para justificar el entrenamiento de una política especializada.

Para los equipos que crean sistemas internos consultables, esa decisión comienza por la calidad de los datos y no por la selección del modelo. Una base de conocimiento de ingeniería fiable todavía necesita documentos actualizados, propiedad clara y fuentes trazables. El entrenamiento no puede recuperar información que la capa de recuperación no contiene.

Cómo aprendió el agente de búsqueda de Amazon SageMaker toda la trayectoria

El mecanismo funciona porque SageMaker recompensa el resultado final de la búsqueda mientras conserva la cadena de decisiones que lo produjo.

El ajuste supervisado enseña a un modelo a imitar ejemplos. Para un agente de búsqueda multi-turno, esos ejemplos deben mostrar trayectorias completas y de alta calidad. Los expertos tendrían que demostrar consultas útiles, elecciones sensatas de herramientas, inspección de evidencias, recuperación ante resultados débiles y un punto de detención adecuado.

Producir esas demostraciones es costoso. También dependen del entorno. Una trayectoria creada para un índice documental puede no servir para otro sistema con metadatos, herramientas de recuperación o controles de acceso diferentes.

El aprendizaje por refuerzo de un solo turno evita algunos costes de demostración, pero crea otro desajuste. Puntuar una salida cada vez no puede captar plenamente decisiones cuyo valor solo se hace visible varios turnos después.

Una consulta vectorial amplia puede parecer poco productiva al principio. Sus resultados podrían revelar un identificador exacto de producto que haga que la siguiente consulta BM25 tenga éxito. Penalizar la primera acción de forma independiente ignoraría su contribución a la búsqueda completada.

MTRL mantiene intacta esa relación. El agente interactúa con el entorno, recibe resultados de búsqueda, actualiza su contexto y elige otra acción. SageMaker recopila la trayectoria resultante y utiliza la recompensa final para ajustar la política que sustenta esas decisiones.

El diseño de recompensa de AWS combinó calidad de recuperación con evitación explícita de fallos. nDCG@10 valoró la clasificación del conjunto final de documentos. La recompensa negativa desalentó trayectorias que superaban los turnos o tokens permitidos.

Esa combinación parece fundamental para el mayor resultado de fiabilidad. En BrowseComp-Plus, el agente base falló en el 22,89 por ciento de 830 preguntas. La versión ajustada falló en el 0,68 por ciento.

El resultado sugiere que el modelo aprendió cuándo terminar, no solo cómo recuperar una clasificación mejor. El promedio de turnos también descendió de 7,0 a 6,3 en ese benchmark. Menos turnos pueden indicar una mayor eficiencia, aunque la evaluación publicada no traduce esa reducción en latencia o coste.

El mismo patrón no apareció en todas partes. En WixQA, los turnos medios aumentaron de 4,3 a 4,5. Wands subió de 2,2 a 2,9. FreshStack descendió de 3,1 a 2,8.

Estas diferencias muestran por qué “menos turnos” no es una medida universal de un mejor comportamiento del agente. Una consulta adicional puede mejorar la cobertura de evidencias, mientras que una detención temprana puede generar una respuesta débil. La medida correcta debe conectar el número de turnos con la calidad de recuperación y la finalización de la tarea.

SageMaker ejecuta rollouts y actualizaciones de gradiente de forma asíncrona. La obsolescencia acotada fuera de política limita hasta qué punto los ejemplos de entrenamiento pueden alejarse de la versión del modelo que se está optimizando en ese momento. La plataforma también admite pérdidas PPO, CISPO y de muestreo por importancia con varios estimadores de ventaja.

AWS dejó esas opciones con sus valores predeterminados en este experimento. Eso facilita reproducir la configuración, pero también oculta qué decisiones algorítmicas impulsaron las mejoras. Los usuarios reciben una ruta gestionada, no una ablación detallada de cada componente del entrenamiento.

La dirección subyacente cuenta con respaldo más allá de esta única publicación de blog. El artículo revisado por pares WebAgent-R1, escrito por investigadores de Amazon e instituciones académicas, entrenó agentes mediante interacción integral de varios turnos.

En WebArena-Lite, ese trabajo elevó el éxito en tareas de Qwen2.5-3B del 6,1 % al 33,9 %. Elevó Llama-3.1-8B del 8,5 % al 44,8 %. Los autores también determinaron que el calentamiento mediante clonación de comportamiento afectó los resultados, lo que complica las afirmaciones de que el aprendizaje por refuerzo por sí solo resuelve el entrenamiento de agentes.

El experimento de SageMaker es más limitado que WebAgent-R1. Se centra en la recuperación de documentos, en lugar de acciones a través de sitios web cambiantes. Sin embargo, ambos apuntan al mismo mecanismo: el modelo mejora cuando el entrenamiento preserva las interacciones entre acciones, observaciones y resultados diferidos.

Una Mejor Fiabilidad No Implicó Mejoras Universales en la Recuperación

La evidencia más sólida respalda una especialización mejorada, no la afirmación general de que el RL de varios turnos mejora todas las tareas de búsqueda.

El modelo ajustado mejoró nDCG@10 en tres de los cuatro benchmarks reservados. BrowseComp-Plus pasó de 0,5136 a 0,6354, una ganancia relativa del 23,7 %. WixQA aumentó de 0,5725 a 0,6781, una ganancia del 18,4 %.

Wands pasó de 0,5762 a 0,6112, una mejora del 6 %. FreshStack avanzó en sentido contrario, al caer de 0,4112 a 0,4089.

Esa regresión es pequeña, pero analíticamente importante. Impide que el experimento respalde una conclusión simplista de que «el entrenamiento mejora la búsqueda». El modelo aprendió una política cuya transferencia fue desigual entre dominios.

FreshStack contiene preguntas recientes de desarrolladores derivadas de Stack Overflow y documentación técnica. Estas consultas pueden depender de terminología específica de versiones y de hechos que cambian rápidamente. Una política entrenada con conjuntos de datos de recuperación más amplios podría no mejorar esa distribución.

AWS no publicó un análisis de errores que explicara la regresión. Sigue sin estar claro si el problema procedió de la selección de herramientas, la reformulación de consultas, material fuente desactualizado, la alineación de recompensas o variaciones normales de la evaluación.

Las cuatro pruebas también diferían sustancialmente en tamaño. Incluían 147 preguntas de Wands, 400 de WixQA, 672 de FreshStack y 830 de BrowseComp-Plus. AWS no informó intervalos de confianza ni significación estadística.

Esa omisión no invalida las mediciones. Limita la confianza con que los lectores pueden generalizar las diferencias más pequeñas, en particular la ganancia del 6 % en Wands y el leve descenso de FreshStack.

La evaluación también combina tareas fallidas con calidad de recuperación al asignar a las ejecuciones fallidas una puntuación nDCG@10 de cero. Ese tratamiento es defendible porque un agente fallido no produce una salida clasificada útil. Sin embargo, implica que parte del aumento de la puntuación de BrowseComp-Plus proviene de evitar fallos.

La distinción importa para los compradores. Un sistema que deja de fallar es claramente más útil, incluso si sus búsquedas exitosas clasifican los documentos de forma similar. Sin embargo, la mejora de la fiabilidad y la mejora de la relevancia describen resultados de ingeniería distintos.

Ninguna parte independiente ha reproducido estos resultados exactos de SageMaker. AWS diseñó la configuración, realizó la evaluación y publicó el análisis. El informe proporciona valores detallados de los benchmarks, pero no libera todos los artefactos de entrenamiento ni las trayectorias necesarias para una auditoría completa.

Tampoco hay comparación con ajuste fino supervisado, un modelo de frontera mediante prompting u otra plataforma MTRL gestionada. El agente base Qwen3.6-27B es la única referencia directa. Por tanto, la afirmación más amplia de AWS sobre una fiabilidad de nivel frontera sigue sin ponerse a prueba aquí.

Investigaciones relacionadas de Amazon ofrecen más evidencia para el enfoque general, pero no una confirmación independiente. En otro conjunto de experimentos, investigadores de Amazon informaron de que el aprendizaje por refuerzo elevó la finalización de tareas de un agente de asistente personal Qwen2.5-32B del 39,20 % al 72 %.

El mismo estudio sobre personalización de agentes informó de mejoras para modelos de recuperación más pequeños en Natural Questions y Musique. Esos resultados fortalecen el argumento de que la interacción con el entorno puede mejorar los agentes. Aun así, proceden de trabajo afiliado a Amazon y usan modelos, datos y tareas diferentes.

La seguridad y la gobernanza crean otra incertidumbre. Durante el entrenamiento, el agente llama repetidamente a herramientas reales o simuladas. Un entorno mal aislado podría exponer datos sensibles, desencadenar acciones no intencionadas o recompensar atajos que resultarían inaceptables en producción.

Los sistemas de búsqueda también cambian. Se añaden documentos, se actualizan los servicios de clasificación y evolucionan los esquemas de las herramientas. Una política ajustada para un entorno puede perder precisión después de esos cambios, incluso cuando el checkpoint del modelo permanece sin cambios.

Las organizaciones necesitarán pruebas de regresión para el sistema completo del agente. La evaluación del modelo por sí sola no detectará todos los fallos creados por un índice, una regla de permisos o una respuesta de herramienta modificados.

Por tanto, la evidencia respalda una conclusión acotada. El RL de varios turnos mejoró la fiabilidad de este agente y la mayoría de sus puntuaciones de recuperación en la evaluación de AWS. No estableció transferencia universal, paridad con modelos de frontera ni ahorros garantizados.

La Competencia entre Agentes Avanza Hacia los Entornos y las Recompensas

El activo estratégico está pasando a ser el entorno de entrenamiento capaz de indicar a un agente cuándo una tarea completa tuvo éxito.

Los modelos fundacionales siguen siendo importantes porque determinan la calidad de los rollouts iniciales. Un modelo base débil podría no descubrir suficientes trayectorias exitosas para que el aprendizaje por refuerzo las refuerce.

La propia investigación de AWS señala este efecto. Los modelos base más capaces pueden generar mejores comportamientos candidatos, creando señales de entrenamiento más sólidas. La especialización no elimina el valor de la capacidad general del modelo.

Sin embargo, un modelo por sí solo no define un agente empresarial. El sistema también incluye herramientas, índices, permisos, estado, límites de tareas y reglas de evaluación. MTRL convierte esos componentes circundantes en parte del bucle de entrenamiento.

Ese cambio modifica dónde pueden las empresas desarrollar un rendimiento defendible. Dos organizaciones pueden partir del mismo modelo abierto y, aun así, producir agentes diferentes porque sus entornos y funciones de recompensa codifican conocimientos operativos distintos.

La búsqueda es un terreno de prueba especialmente adecuado. Los juicios de relevancia proporcionan comentarios medibles, y los documentos recuperados pueden compararse con respuestas conocidas. La búsqueda también obliga al agente a equilibrar coincidencia exacta, recuperación semántica, reformulación de consultas y comportamiento de detención.

Otros flujos de trabajo son menos cooperativos. La investigación comercial puede tener varias salidas aceptables. Las investigaciones pueden descubrir evidencia válida que no estaba presente en un benchmark. El trabajo de conocimiento suele valorar la novedad, el matiz y la procedencia junto con la finalización de tareas.

Una única recompensa terminal puede comprimir esas cualidades de forma excesiva. Los equipos pueden necesitar evaluaciones compuestas que midan por separado la calidad de la evidencia, la precisión de las citas, el cumplimiento de políticas y la eficiencia de las acciones.

Por tanto, la carrera de infraestructura implicará más que entrenamiento gestionado. Los proveedores deben ayudar a los clientes a construir entornos seguros, depurar trayectorias, comparar checkpoints y detectar el hacking de recompensas.

La integración de MLflow de SageMaker aborda parte de esa necesidad al exponer trazas y recompensas a nivel de turno. Los trabajos reanudables también ayudan porque los rollouts de varios turnos pueden tardar más que el ajuste fino convencional. AWS afirma que el límite predeterminado de sus trabajos es de 24 horas, aunque los usuarios pueden ajustarlo y reanudar desde checkpoints.

La compatibilidad de modelos y la disponibilidad regional siguen siendo restricciones. En el momento del experimento, Qwen3.6-27B era compatible con MTRL en la región US West, Oregon. Una empresa con requisitos de residencia de datos o un modelo no compatible podría necesitar un plan de despliegue distinto.

La interfaz serverless también crea dependencia de la plataforma. AWS gestiona la orquestación de rollouts y los detalles de optimización que un equipo autoalojado controlaría de otro modo. Esa compensación puede acelerar el despliegue, a la vez que dificulta la experimentación de bajo nivel.

La investigación abierta continúa desarrollando alternativas. Frameworks como WebAgent-R1 exponen una mayor parte del diseño del entrenamiento, incluidos rollouts paralelos y compresión de contexto. Los servicios gestionados empaquetan ideas similares para organizaciones que no desean operar infraestructura distribuida de aprendizaje por refuerzo.

La división probable no será entre gestionado y abierto en términos absolutos. Las empresas elegirán según la sensibilidad de la carga de trabajo, los requisitos del modelo, la capacidad de ingeniería y el valor de controlar cada componente del entrenamiento.

La ventaja de AWS es la integración. Los equipos pueden conectar agentes alojados mediante diversos servicios de AWS, entrenar con SageMaker, inspeccionar trazas y desplegar el modelo resultante en endpoints de SageMaker o Amazon Bedrock.

Su desafío pendiente es la prueba. Los compradores necesitan evidencia de que la ruta gestionada produce mejoras repetibles en sus propias tareas y se mantiene estable después de que cambie el entorno.

Tres Señales Pondrán a Prueba la Tesis de AWS sobre los Agentes Más Pequeños

La próxima fase debe juzgarse mediante reproducción externa, economía de producción y estabilidad entre entornos.

La primera señal es la replicación independiente. Otro equipo necesita reproducir las ganancias de recuperación utilizando los conjuntos de datos divulgados, una referencia comparable de Qwen3.6-27B y los mismos límites de tareas. Igualar el resultado de fiabilidad de BrowseComp-Plus reforzaría la afirmación central de AWS.

Una reproducción debería separar las ganancias de clasificación de la evitación de fallos. También debería incluir estimaciones de incertidumbre y ejecuciones repetidas. Si la mejora desaparece bajo esos controles, el resultado actual parecerá más específico de la configuración de evaluación de AWS.

La segunda señal es una comparación directa en producción con un modelo de frontera. Los equipos deberían medir la calidad de las respuestas, la relevancia de la recuperación, la latencia de extremo a extremo, los tokens consumidos y las tasas de intervención sobre la misma carga de trabajo. El gasto de entrenamiento debería incluirse junto con el comportamiento de inferencia.

Si un modelo especializado iguala al modelo más grande mientras utiliza menos recursos durante el despliegue, el argumento económico se vuelve concreto. Si los equipos deben reentrenar con frecuencia o mantener una infraestructura de recompensas compleja, parte de los ahorros esperados se trasladará a otra parte de la pila.

La tercera señal es el rendimiento después de que cambie el entorno. Una prueba útil modificaría el corpus documental, actualizaría el esquema de una herramienta o introduciría un nuevo filtro de búsqueda. Los evaluadores podrían medir entonces si el agente se adapta mediante prompting o requiere otro ciclo de entrenamiento.

Un rendimiento estable respaldaría la afirmación de AWS de que MTRL enseña comportamiento de búsqueda transferible. Un descenso pronunciado mostraría que el modelo aprendió una política de interfaz estrecha estrechamente vinculada a su entorno original.

Los desarrolladores también deberían vigilar la regresión de FreshStack. Los experimentos futuros deben explicar por qué una política que ayudó a tres conjuntos de datos perjudicó levemente a este. Un análisis de errores específico revelaría si la actualidad, el vocabulario técnico o la estrategia de consulta causaron la diferencia.

Los compradores empresariales no necesitan elegir entre modelos de frontera y agentes especializados para cada tarea. Una arquitectura práctica puede dirigir las búsquedas comunes y medibles a un modelo ajustado y escalar el trabajo desconocido a un modelo más amplio.

Ese enfoque híbrido preserva la flexibilidad mientras prueba si la especialización produce ahorros fiables. También limita el riesgo de imponer una política única a cada necesidad de información.

El resultado del agente de búsqueda de Amazon SageMaker hace que valga la pena realizar ese experimento. Muestra una reducción medible de los fallos y una mejor clasificación en la mayoría de las pruebas reservadas. También deja suficiente incertidumbre como para requerir una evaluación frente a los documentos y flujos de trabajo propios de cada organización.

Para los equipos que estén considerando esta vía, el siguiente paso adecuado no es el despliegue inmediato. Creen un conjunto de pruebas representativo, definan con precisión qué constituye un fallo y comparen el agente ajustado con la base de referencia existente más sólida. Luego, pregúntense si la mejora se mantiene ante documentos nuevos, herramientas modificadas y casos límite difíciles.