Los LLM no se ponen de acuerdo

Un estudio reciente puso sobre la mesa una incomodidad que muchos equipos ya sospechaban: cinco modelos frontera pueden mirar la misma afirmación y no llegar al mismo veredicto en la mayoría de los casos. En concreto, el trabajo de Lenz.io reporta discrepancias en 67% de 1.000 afirmaciones reales de fact-checking. No estamos hablando de prompts mal escritos ni de una prueba artificial con ejemplos raros. Estamos hablando de afirmaciones del mundo real, de esas que se parecen bastante a lo que tú podrías enviar a un flujo de revisión, a un asistente interno o a un pipeline de RAG.

El dato no significa que los modelos sean inútiles. Significa algo más incómodo y más útil: cuando varios LLM de primera línea no coinciden, esa fricción se puede convertir en señal. Si trabajas en evaluación, en producto o en automatización asistida por IA, el desacuerdo entre modelos te ayuda a detectar zonas grises, a medir confianza con más cuidado y a evitar que una sola respuesta “bonita” se convierta en una decisión final sin revisión.

Qué midió el estudio y por qué importa

La idea del estudio es simple de explicar y difícil de ignorar. Se tomaron 1.000 afirmaciones reales de fact-checking y se compararon las respuestas de cinco modelos frontera. El resultado: en 67% de los casos hubo desacuerdo entre ellos. Eso no quiere decir que todos se contradijeran siempre, pero sí que en dos de cada tres afirmaciones al menos uno de los modelos se desalineó con el resto.

Para equipos que usan IA en tareas de verificación, soporte o análisis documental, ese porcentaje cambia la conversación. Ya no basta con preguntar “¿qué tan bueno es este modelo?”; también necesitas preguntar “¿qué pasa cuando otro modelo opina distinto?”. Esa segunda pregunta es la que te ayuda a diseñar mejores controles.

Hay una diferencia grande entre usar un LLM para redactar y usarlo para decidir. Redactar tolera más ambigüedad. Decidir no. Si tu flujo toma una respuesta del modelo como señal de aprobación, rechazo o escalamiento, el desacuerdo entre modelos te dice dónde necesitas más contexto, más fuentes o una validación humana.

El dato de 67% no es ruido estadístico

Cuando ves 67%, lo fácil es restarle importancia con la excusa de que “la IA siempre alucina”. Pero el valor real del estudio no está en confirmar que los modelos fallan. Está en mostrar que fallan de forma no uniforme. En otras palabras, no se equivocan todos igual ni en los mismos puntos.

Eso abre una oportunidad práctica. Si dos o tres modelos coinciden y uno se aparta, puedes tratar ese desvío como una alerta. Si los cinco divergen, probablemente el caso requiere fuentes externas, contexto adicional o una política de no respuesta. El desacuerdo deja de ser una molestia y pasa a ser un indicador operacional.

Qué cambia para producto y data teams

Si trabajas con RAG, el estudio te obliga a revisar algo básico: la calidad de una respuesta no depende solo del modelo, sino también de la cobertura y precisión del retrieval. Un LLM puede fallar porque no sabe, porque recuperó mal o porque interpretó mal una fuente. Si además otro modelo da una respuesta distinta con el mismo contexto, el problema ya no es solo “mejor prompt”.

Esto también afecta a equipos de compliance, legal, soporte y operaciones. En esos flujos, una respuesta incorrecta puede traducirse en un ticket mal cerrado, una política mal aplicada o una recomendación riesgosa. El desacuerdo entre modelos te permite construir una política de “doble lectura” sin depender de intuiciones.

Qué significa realmente que cinco modelos discrepen

No todos los desacuerdos son iguales. A veces los modelos difieren porque uno interpreta la afirmación como parcialmente cierta y otro como falsa. Otras veces uno responde con cautela y otro se va al extremo. Ese patrón importa más que el resultado aislado, porque te muestra cómo razona cada sistema bajo presión.

En la práctica, hay tres tipos de discrepancia que deberías observar:

1. Desacuerdo de veredicto: un modelo dice verdadero y otro falso.
2. Desacuerdo de matiz: uno clasifica como “probablemente cierto” y otro como “no verificable”.
3. Desacuerdo de cobertura: algunos modelos piden más contexto mientras otros responden directo.

El tercer caso suele pasar desapercibido, pero es muy útil. Si un modelo pide contexto y otro no, el primero te está diciendo que detectó ambigüedad. Eso puede ser una señal valiosa para tu sistema de scoring.

El desacuerdo como señal de incertidumbre

En vez de usar un único score de confianza del modelo, puedes calcular incertidumbre por consenso. Si cinco modelos frontera no coinciden, la confianza operativa en esa respuesta debería bajar, aunque una de las respuestas suene convincente.

Eso no es teoría. Es diseño de producto. Por ejemplo, en un asistente para analistas de riesgo, puedes definir reglas como estas:

• si 4 de 5 modelos coinciden, el sistema propone respuesta automática;
• si 3 de 5 coinciden, el sistema muestra advertencia y fuentes;
• si 2 o menos coinciden, el caso pasa a revisión humana.

No necesitas que el sistema sea perfecto. Necesitas que se comporte de forma predecible cuando la evidencia es débil.

Tabla: cómo leer el desacuerdo en producción

Ese tipo de tabla no reemplaza evaluación formal, pero sí te ayuda a convertir resultados dispersos en reglas de negocio entendibles.

Qué hacer si usas RAG, agentes o verificación asistida

Si tu producto usa RAG, el hallazgo del estudio te sirve como recordatorio de que el retrieval no es un detalle técnico secundario. Un modelo puede parecer inconsistente por culpa de documentos incompletos, chunks demasiado grandes, embeddings flojos o ranking pobre. Antes de culpar al LLM, revisa qué contexto está recibiendo.

También conviene separar dos capas: la capa de generación y la capa de decisión. La generación puede redactar una respuesta útil. La decisión necesita evidencia trazable. Si mezclas ambas, terminas con un sistema que suena seguro pero no te explica por qué llegó a ese resultado.

Según la documentación oficial de OpenAI sobre Evals, la evaluación debe ser repetible y basada en criterios observables, no en impresiones subjetivas. Puedes revisar esa guía aquí: https://platform.openai.com/docs/guides/evals. Si quieres trabajar con modelos de Anthropic, su documentación sobre tool use y prompts también ayuda a entender cómo estructurar salidas más controladas: https://docs.anthropic.com/.

Un flujo práctico para equipos de producto

Si hoy estás armando o revisando un flujo con LLM, este orden te puede ahorrar tiempo:

1. Define si el caso de uso es generación, clasificación o decisión.
2. Separa la respuesta del modelo de la acción automática.
3. Guarda el contexto recuperado junto con la salida.
4. Compara al menos dos modelos en una muestra representativa.
5. Mide desacuerdo por tipo de tarea, no solo por promedio global.
6. Crea umbrales de escalamiento basados en consenso.
7. Revisa casos donde el modelo más “seguro” se equivoca más.

Ese último punto suele ser el más valioso. Un modelo que responde con mucha seguridad no necesariamente es el más confiable. A veces es solo el que mejor disimula su incertidumbre.

Qué mirar en tus pruebas internas

No te quedes con accuracy agregado. En tareas de fact-checking o clasificación factual, mira al menos estas variables:

• tasa de desacuerdo entre modelos;
• porcentaje de casos con respuesta no verificable;
• frecuencia de falsas certezas;
• diferencia entre respuesta con y sin contexto recuperado;
• casos donde el modelo cambia de veredicto con una reformulación mínima.

Si una reformulación pequeña cambia el resultado, tu sistema todavía es frágil. Eso no es raro. Es una señal de que necesitas mejores prompts, mejores fuentes o una política de salida más conservadora.

Cómo usar el desacuerdo para evaluar confiabilidad

La tentación común es buscar “el mejor modelo” como si hubiera un ganador universal. El estudio sugiere otra cosa: la confiabilidad también se evalúa por estabilidad entre modelos. Si varios sistemas frontera no se ponen de acuerdo, el problema no es solo del modelo individual; es del espacio de tarea que estás intentando automatizar.

Eso es especialmente relevante en LatAm, donde muchas empresas están adoptando IA en procesos internos sin equipos grandes de evaluación. En esos contextos, el desacuerdo entre modelos puede servir como una métrica barata para priorizar revisiones. No resuelve todo, pero te ayuda a decidir dónde poner atención primero.

Además, el desacuerdo puede ayudarte a detectar datasets malos. Si una afirmación genera resultados muy distintos entre modelos, quizá la pregunta está mal formulada, la etiqueta es ambigua o la fuente base no es confiable. No siempre el problema está en el modelo.

Tres usos concretos en equipos reales

• QA de contenido: comparar dos o tres modelos antes de publicar una respuesta automática.
• Triage de soporte: escalar tickets donde los modelos no coinciden sobre la causa probable.
• Revisión documental: marcar contratos, políticas o notas internas con baja concordancia para revisión humana.

Si trabajas en una empresa mediana, esto se puede implementar sin montar una plataforma enorme. Basta con registrar outputs, calcular consenso y usar un umbral operativo simple.

Un ejemplo de scoring sencillo

Puedes empezar con un score de consenso como este, sin complicarte demasiado:

consensus_score = (n_modelos_que_coinciden / n_total_modelos) * 100

Luego defines reglas internas. Por ejemplo:

• 80% o más: respuesta confiable para autoaprobación;
• 60% a 79%: respuesta utilizable, pero con advertencia;
• menos de 60%: revisión humana obligatoria.

No necesitas que esos números sean perfectos desde el día uno. Necesitas que sean consistentes, medibles y ajustables con datos reales.

Lo que este estudio no prueba

También vale la pena poner límites. El estudio no demuestra que un modelo específico sea “malo” en términos absolutos. Tampoco prueba que el desacuerdo siempre se traduzca en peor producto. Lo que sí muestra es que, en fact-checking real, la variabilidad entre modelos es suficientemente alta como para no confiar ciegamente en una sola respuesta.

Eso importa porque muchas demos de IA se venden con un solo ejemplo bonito. En producción, el patrón cambia. Hay preguntas ambiguas, documentos incompletos, fuentes contradictorias y usuarios que escriben mal. Si tu sistema no tolera ese ruido, el problema aparece cuando ya está en manos del usuario.

También hay una lección para quienes hacen benchmarking. Evaluar solo un modelo contra una etiqueta de referencia puede ocultar zonas donde la tarea misma es discutible. Si cinco modelos frontera discrepan de forma sistemática, tal vez no estás midiendo una verdad única, sino una tarea que necesita taxonomía más fina.

Tabla resumen

Si tu equipo está evaluando asistentes, clasificadores o flujos de decisión con IA, este tipo de hallazgo te ahorra una mala costumbre: asumir que un modelo seguro equivale a una respuesta correcta. No es así. Cuando varios modelos frontera no se ponen de acuerdo, la diferencia entre un sistema útil y uno riesgoso está en cómo manejas esa duda.

La buena noticia es que la duda se puede medir. Y cuando la mides, puedes diseñar mejores reglas, mejores revisiones y mejores experiencias para el usuario.