AWS explica cómo ajustar Amazon Nova con un LLM como juez para tareas empresariales complejas

AWS ha detallado cómo aplicar reinforcement fine-tuning con el enfoque LLM-as-a-judge a los modelos Amazon Nova. En lugar de etiquetado manual o de un conjunto de reglas rígidas, un modelo de lenguaje independiente evalúa la calidad de la respuesta, y su veredicto se convierte en la señal de recompensa para el entrenamiento.

Para qué sirve el juez

Según AWS, el RFT habitual puede construirse bien sobre reglas verificables, como la coincidencia exacta de una cadena, bien sobre un esquema en el que otro LLM evalúa la respuesta con varios criterios a la vez. La segunda opción es para los casos en que la calidad no se puede reducir a una sola fórmula.

En tareas empresariales no importa solo la precisión factual, sino también el tono, la seguridad, la exhaustividad, la relevancia y el cumplimiento de las políticas internas. En este enfoque, el modelo juez no se limita a poner una nota: también ayuda a entender por qué una respuesta es mejor que otra. AWS subraya que este esquema acelera las iteraciones: el equipo ve exactamente dónde falla el modelo y puede corregir antes la función de recompensa. Esto resulta especialmente útil en ámbitos donde el error no parece un fallo evidente, sino que aparece en los matices de la redacción, en un riesgo omitido o en una argumentación débil.

Seis pasos de configuración

AWS divide la implantación de LLM-as-a-judge en varios pasos prácticos. Primero hay que elegir el tipo de evaluación: rubric-based, donde el juez asigna una puntuación absoluta a una sola respuesta, o preference-based, donde compara dos variantes y elige la mejor. Si no se dispone de preferencias ya hechas, la compañía aconseja empezar con el enfoque de rúbrica y criterios sencillos de pass/fail en lugar de una escala de 1 a 10.

• Elegir el modo de juicio: evaluación absoluta o comparación por pares
• Definir con claridad los criterios de calidad, con rasgos observables
• Seleccionar el modelo juez según el dominio y el presupuesto a través de Amazon Bedrock
• Exigir una respuesta JSON estructurada para poder analizar la recompensa de forma fiable
• Vincular la función de recompensa con las métricas de producción y añadir una capa Lambda robusta

AWS pone un énfasis especial en la infraestructura. Aconseja no depender solo del juez y complementarlo con comprobaciones deterministas rápidas: validez del JSON, longitud de la respuesta, coincidencia de idioma y filtros de seguridad. La propia Reward Lambda debe soportar miles de evaluaciones por paso de entrenamiento, por lo que se recomiendan exponential backoff en las llamadas a Bedrock, paralelización mediante ThreadPoolExecutor o patrones async, un timeout de hasta 15 minutos y provisioned concurrency de en torno a 100 en las configuraciones típicas. Si el juez o la API fallan, es mejor devolver una recompensa neutra que romper todo el paso de entrenamiento. Además, se aconseja mantener un conjunto de pruebas de regresión para el propio pipeline del juez.

El caso de los contratos

Como demostración, AWS describe un proyecto con un socio del sector jurídico. La tarea consiste en analizar automáticamente contratos nuevos, compararlos con normas internas, contratos anteriores y requisitos legales, y generar como salida un JSON con comentarios, tipos de observaciones y acciones recomendadas.

El conjunto de datos original era pequeño y contenía contratos etiquetados por expertos, por lo que el supervised fine-tuning clásico daba un efecto limitado. Para el RFT se usó un modelo juez independiente, GPT OSS 120B, y un system prompt personalizado. El juez comprobaba si el comentario se apoya realmente en un fragmento del propio contrato, si concuerda con el documento de referencia y si se puede actuar a partir de él. Después se envolvió todo en una función Lambda y se lanzó el entrenamiento con el Nova Forge SDK, con varias generaciones por ejemplo y un límite de 100 llamadas concurrentes.

Como resultado, Amazon Nova 2 Lite tras el RFT obtuvo una puntuación agregada de 4,33 sobre 5 y una validación perfecta del esquema JSON, superando a Claude Sonnet 4.5 y a Claude Haiku 4.5. AWS señala aparte que en las versiones SFT aparecían artefactos como comentarios repetidos y caracteres Unicode extraños, mientras que en los checkpoints de RFT no ocurría. Más importante aún: el modelo mantuvo buenos resultados incluso después de cambiar el judge prompt, es decir, aprendió patrones generales de calidad y no una fórmula de evaluación concreta. El inconveniente también se menciona sin rodeos: el RFT requirió de 4 a 8 rollouts por cada ejemplo de entrenamiento y costó más en cómputo.

Qué significa

AWS promueve de hecho el RFT con LLM-as-a-judge como una vía viable para adaptar modelos a escenarios empresariales sensibles, donde las reglas simples no bastan y el etiquetado manual es demasiado caro. Si el enfoque con Amazon Nova realmente se traslada a producción, las empresas de los sectores jurídico, financiero y sanitario obtienen una forma de ajustar modelos a sus propios estándares y, a la vez, controlar mejor el formato, la calidad y la explicabilidad de las respuestas.