Evaluador-Optimizador (Evaluator-Optimizer)
Un LLM genera una respuesta mientras un segundo LLM la evalúa contra criterios y devuelve feedback; el generador revisa y el bucle se repite hasta que la evaluación pasa. Eleva la calidad en tareas con criterios de evaluación claros, a costa de llamadas extra.
Problema
Una salida de una sola pasada puede incumplir requisitos, y no hay un mecanismo incorporado para comprobarla y mejorarla antes de usarla.
Cuándo usarlo
Usa evaluador-optimizador cuando puedas articular criterios de evaluación claros y el refinamiento iterativo mejore el resultado de forma medible —por ejemplo calidad de traducción, código que debe pasar tests, o escritura contra una rúbrica.
Solución
Un generador produce un candidato; un evaluador (otra llamada al LLM o una comprobación determinista) lo puntúa contra criterios explícitos y devuelve feedback accionable. El generador revisa y el ciclo se repite hasta cumplir los criterios o alcanzar un presupuesto.
Separar generación de evaluación imita cómo un escritor humano se beneficia de un editor: el crítico atrapa problemas que el autor pasa por alto, y los criterios explícitos mantienen el bucle convergiendo.
Componentes
Beneficios
- Mayor calidad en tareas con criterios claros.
- Atrapa errores que una sola pasada publicaría.
- El feedback es explícito y accionable.
Riesgos
- Las llamadas extra añaden latencia y coste.
- Un evaluador débil da feedback engañoso.
- Los bucles pueden no converger sin un presupuesto.
Cuándo no usarlo
- Cuando los criterios no se pueden definir con claridad.
- Cuando una sola pasada ya es suficientemente buena.
- Cuando los presupuestos de latencia o coste son muy ajustados.
Tecnologías
Ejemplos
- Generar código, ejecutar tests y revisar hasta que pasen.
- Redactar una traducción y refinarla contra el original.
- Escribir contra una rúbrica con un crítico que exige cada criterio.
KPIs
- Tasa de aceptación
- Proporción de salidas que el evaluador acepta a la primera; demasiado alta indica un listón bajo, demasiado baja, un generador o rúbrica deficientes.
- Iteraciones hasta aceptar
- Bucles evaluar→revisar promedio antes de aceptar; si suben, el generador es débil o los criterios, vagos.
- Coste y latencia por salida aceptada
- Tokens y tiempo total de todas las iteraciones, no solo la llamada final: el bucle multiplica ambos.
- Concordancia evaluador–humano
- Con qué frecuencia el veredicto del evaluador coincide con un revisor humano en una muestra; el bucle vale lo que su evaluador.
Modos de fallo observados
- Reward hacking: el generador aprende a satisfacer la redacción del evaluador en vez del objetivo real.
- Evaluador débil o mal calibrado: acepta salidas malas o rechaza buenas, sumando coste sin calidad.
- Bucles infinitos u oscilantes cuando ningún candidato supera el listón; sin un tope de iteraciones el coste es ilimitado.
- Deriva de criterios: rúbricas vagas o cambiantes hacen la aceptación no determinista y difícil de auditar.
Lecciones aprendidas
- Limita las iteraciones y define un respaldo (devolver el mejor hasta ahora o escalar) para que el bucle siempre termine.
- Haz los criterios de aceptación explícitos y estables; un evaluador vale lo que su rúbrica.
- Valida el evaluador frente al juicio humano antes de confiar en él como puerta.
- Usa el bucle solo donde la calidad justifique el coste multiplicado, no para salidas baratas y de bajo riesgo.
FAQs
- ¿En qué se diferencia de la reflexión?
- La reflexión hace que el mismo modelo se autocritique. El evaluador-optimizador separa los roles: un evaluador distinto juzga al generador, lo que suele dar feedback más afilado y menos sesgado.
- ¿El evaluador puede ser determinista?
- Sí. Para código, un runner de tests es un evaluador ideal; para salida estructurada, sirve una comprobación de esquema. Usa un juez modelo para criterios con matices.
- ¿Cuántas iteraciones?
- Fija un presupuesto (p. ej. 2-3) y para cuando se cumplan los criterios. Los bucles sin límite malgastan coste y pueden no converger.