Validación mediante autocrítica

La autocrítica utiliza un LLM para evaluar la salida de otro LLM según una rúbrica o política. Detecta fallos sutiles que los validadores deterministas no pueden expresar: incoherencias fácticas, tono, utilidad e infracciones de políticas difíciles de detectar.

Es el complemento basado en modelos de los validadores de esquemas y reglas.

Ejecute la crítica como una llamada independiente con su propio prompt, no como una instrucción al final de la generación. Un evaluador con contexto limpio, al que solo se le pide juzgar, es mucho más fiable que pedirle al autor que se califique a sí mismo durante la generación, cuando está sesgado a favor de su propia respuesta.

Haga que el evaluador emita veredictos estructurados para que el flujo pueda actuar mediante programación. Una crítica en texto libre no se puede procesar automáticamente.

Combine el evaluador con un revisor. El evaluador detecta los problemas; el autor revisa la respuesta usando la crítica; repita hasta obtener la aprobación o agotar el presupuesto. Este es el equivalente basado en modelos del bucle de reparación.

Una instrucción imprecisa («¿es esto bueno?») produce veredictos ruidosos. Una rúbrica concreta, con criterios explícitos y comprobables, produce veredictos coherentes. Descompóngala en preguntas de sí o no que el evaluador responda individualmente.

Para detectar alucinaciones, proporcione al evaluador el contexto de origen y pídale que señale cualquier afirmación que no se desprenda de él. Así la autocrítica se convierte en una comprobación de implicación, mucho más sólida que preguntar «¿es esto cierto?» sin pruebas.

El evaluador también es un LLM y puede fallar:

• Complacencia: aprobar sin más la respuesta del autor.
• Exceso de crítica: señalar como incorrecta una salida válida.
• Puntos ciegos compartidos: el mismo modelo no detecta los mismos errores.

Mitigue estos problemas usando una familia de modelos distinta como evaluador, un rol de revisor estricto y umbrales calibrados.

El evaluador no tiene que ser el modelo más caro. A menudo, un modelo más pequeño con una rúbrica precisa es una barrera rentable, y usar una familia de modelos diferente reduce los puntos ciegos correlacionados. Reserve el modelo más potente para generar la respuesta.

La autocrítica reduce los errores, pero no constituye una prueba. Para contenido de bajo riesgo, basta con una sola pasada de crítica. Para salidas de alto riesgo, combine la autocrítica con validadores deterministas y revisión humana; no permita nunca que un modelo sea el único árbitro de decisiones críticas para la seguridad.

La autocrítica casi duplica el número de llamadas por solicitud. Contrólela: condicione la crítica a las comprobaciones deterministas (critique solo lo que haya superado el esquema y las reglas), almacene en caché las críticas de borradores idénticos y limite las rondas de revisión. Ejecute la crítica en paralelo con el trabajo no bloqueante cuando sea posible.

Valide el evaluador antes de confiar en él. Cree un conjunto de salidas etiquetadas por personas, ejecute el evaluador y mida la concordancia (precisión y exhaustividad frente a los veredictos humanos). Ajuste la rúbrica y el rol hasta que los juicios del evaluador se correlacionen con los de las personas; vuelva a comprobarlo después de actualizar el modelo.

Quiere que el evaluador detecte de forma fiable las alucinaciones en una respuesta de RAG. ¿Qué mejora más la fiabilidad?

Validación mediante autocrítica:

• Un evaluador independiente, con contexto limpio, juzga la salida del autor.
• Emita veredictos estructurados e impulse un bucle de crítica y revisión.
• Las rúbricas concretas y las comprobaciones de implicación fundamentadas mejoran la fiabilidad.
• Preste atención a la complacencia y a los puntos ciegos compartidos; use un modelo evaluador diferente.
• Controle el coste, combine la autocrítica con comprobaciones deterministas y calíbrela con evaluaciones humanas.

Ha completado la sección sobre barreras de seguridad. Siguiente curso: red teaming y evaluación adversarial.