Claude Sonnet 5.5 juzga 5 modelos locales: 85% de aciertos

Cinco modelos locales y una pregunta incómoda

Cinco modelos pequeños corriendo en un solo portátil acertaron el 77,1% de 1.000 preguntas. Cuando el sistema añadió un verificador externo que revisa las fuentes citadas, la precisión subió al 85,0% sin reentrenar nada. Para un founder que ya tiene un RAG o un agente en producción, ese salto mide algo muy concreto: cuánta exactitud se puede ganar cambiando cómo se elige la respuesta, no cuánto sabe el modelo.

El experimento se llama Verify, Then Vote y sale de un proyecto personal publicado en el blog grainulation.org. La configuración es deliberadamente modesta: Llama 3.2 3B, Mistral 7B, Gemma 2 2B, Phi-3 mini y Qwen 2.5 3B, ejecutados con Ollama en un Apple M3 Pro con 36 GB de RAM. Una corrida completa tardó unas ocho horas, dejada corriendo de un día para otro.

Cada modelo escribía su propia consulta y recibía cinco pasajes: Wikipedia para preguntas generales, abstracts de investigación para afirmaciones científicas. Después entregaba una respuesta, declaraba su nivel de confianza y citaba hasta tres pasajes. Todo se guardaba antes de elegir cualquier respuesta.

Leíste lo que hace la IA. ¿Y en tu negocio?

Un agente de IA puede quedarse con parte de tu día: ordenar lo pendiente y pedirte el OK antes de actuar. El Kit «tu mano derecha con IA» trae un video de 11 minutos y una ficha para dejar al tuyo trabajando. CAR está cerrada por ahora; al anotarte, te avisamos cuando abra.

👥 Quiero el Kit →

¿Por qué votar entre modelos no alcanza?

La reacción obvia ante cinco respuestas distintas es una votación mayoritaria. El problema es que los modelos pueden compartir el mismo error, y una votación no puede detectar un error compartido: si cuatro de cinco repiten la misma confusión, la mayoría la consagra.

Por eso el proyecto separó tres pasos que normalmente van juntos: responder, verificar y elegir. La verificación no pregunta si la respuesta es cierta, sino si el pasaje citado la respalda. El ejemplo del propio trabajo es claro: si un pasaje afirma que Sídney es la capital de Australia, ese pasaje respalda la respuesta «Sídney», aunque la capital real sea Canberra. Es una diferencia clave y una advertencia sobre los límites del método.

¿Cómo funciona el verificador de fuentes?

El chequeo lo hizo Claude Sonnet 5.5 como modelo alojado aparte. Veía únicamente una oración con la respuesta y un pasaje citado, y dictaminaba si el pasaje la respaldaba, la contradecía o no decía lo suficiente. Nunca vio la respuesta correcta.

La regla de decisión parte de la respuesta más votada, rompe empates siempre de la misma forma y solo cambia a otra respuesta si el verificador dice que un pasaje citado la respalda. Cada cambio queda registrado con su pasaje y su chequeo, así que se puede reconstruir por qué se eligió una respuesta.

Además, los autores demostraron una propiedad con Lean 4, software que valida pruebas matemáticas: si la regla alguna vez cambia una respuesta correcta por una incorrecta, algún chequeo de fuentes tuvo que haber respaldado la respuesta equivocada. Eso no prueba que la fuente fuera verdadera ni que el verificador la leyera bien, pero señala dónde mirar cuando algo falla.

Los números: 91 aciertos recuperados y 12 errores nuevos

Tras ajustar los parámetros en un conjunto de práctica separado, corrieron la regla sobre 1.000 preguntas principales. La precisión pasó del 77,1% con votación mayoritaria simple al 85,0%.

En 526 de esas preguntas los modelos dieron una mezcla de aciertos y errores. Ahí la regla arregló 91 respuestas que la votación había fallado y rompió 12 que había acertado: la precisión subió del 71,5% al 86,5%. Hay un matiz importante: la votación rompía empates al azar y la regla los rompe siempre igual, así que parte de la mejora viene de cómo se manejan los empates.

Antes de empezar, el equipo fijó un límite a cuántas respuestas correctas la regla podía romper. De 376 respuestas correctas del voto, la regla arruinó 12, un 3,2%. Contemplando el azar, la tasa real podía llegar al 5,5%, por encima del límite del 5%. La regla original no pasó su propia prueba.

La regla revisada que sí pasó el test

Ese resultado sugirió un criterio más conservador: si la respuesta de partida ya tiene un pasaje que la respalda, se conserva. El cambio se escribió antes de recolectar respuestas de cinco modelos distintos sobre las mismas preguntas, reutilizando los chequeos ya existentes donde la respuesta y el pasaje coincidían.

Con los modelos nuevos, 547 preguntas tenían mezcla de aciertos y errores. La regla revisada arregló 73 y rompió 3, elevando la precisión del 73,1% al 85,9%. De 400 respuestas correctas del voto, tres se volvieron incorrectas, un 0,75%, con un peor caso del 2,2%, bien por debajo del límite del 5%.

El alcance está acotado y el propio trabajo lo aclara: como las preguntas eran las mismas y el cambio se diseñó después de ver los primeros resultados, esto demuestra que la regla se traslada a otros modelos, no que funcione con preguntas nuevas.

¿No era más simple dejar que Claude eligiera?

También lo probaron. Con las mismas respuestas y pasajes, Sonnet acertó el 93,9% de las 526 preguntas mixtas del primer grupo, frente al 86,5% de la regla. Y salió más barato: unos US$0,014 por pregunta, contra US$0,021 para el chequeo de fuentes. Ninguna de las dos cifras incluye el costo de que los modelos escriban sus respuestas.

El argumento en contra de dejar todo en manos del juez no es la precisión, sino la trazabilidad. Como cada chequeo queda guardado, se puede ver exactamente por qué se eligió una respuesta y probar otra regla sin pagar por verificaciones nuevas. Pedirle al juez que vuelva a elegir implica otra llamada al modelo.

Recalcular decisiones sin volver a llamar al modelo

Sobre las 1.100 preguntas totales, incluyendo un conjunto aparte de 100 de TruthfulQA, los modelos discreparon en 702. Para medir cuánto pesa cada modelo, un script en Python eliminó uno a la vez y pasó las respuestas guardadas a un programa en Rust para volver a elegir. Cinco repeticiones por pregunta sumaron 3.510 corridas.

Todas tardaron 23 segundos y ninguna hizo nuevas llamadas al modelo. La respuesta elegida cambió el 9,4% de las veces, lo que muestra cuánto depende el resultado de qué modelos participen. Repetir las 1.100 decisiones originales dio exactamente el mismo resultado.

Esto funciona porque responder, verificar y elegir están separados. Se puede cambiar cómo se eligen las respuestas mientras las respuestas y los chequeos guardados siguen intactos; respuestas o fuentes nuevas sí exigirían chequeos nuevos.

¿Qué significa esto para tu startup?

La lección no es «usa cinco modelos». Es que la elección de la respuesta es un componente diseñable, auditable y barato de iterar, y en la mayoría de los pipelines de IA se deja librado al comportamiento de un solo modelo.

Separa responder, verificar y elegir en tu arquitectura. Si todo ocurre dentro de una sola llamada, no puedes cambiar la regla de decisión sin volver a generarlo todo. Guardar respuestas y verificaciones como artefactos separados te permite experimentar sin pagar inferencia de nuevo.
Escribe la regla y su límite de tolerancia antes de ver los datos. Aquí el tope era que la regla rompiera como máximo el 5% de las respuestas correctas, y el resultado obligó a rehacerla. Sin ese límite previo, cualquier mejora agregada parece un éxito.
Mide la tasa de ruptura, no solo la de aciertos. La regla original subía la precisión general y a la vez rompía 12 respuestas correctas. Esa métrica de daño es la que decide si el sistema es desplegable.
Prueba primero el juez directo. En este experimento, dejar que el modelo verificador eligiera fue más preciso y más barato por pregunta que la regla. La ventaja de la regla aparece cuando necesitas auditar decisiones o recalcularlas sin costo adicional.
Vigila la correlación entre modelos. Quitar un solo modelo cambió la respuesta final en casi una de cada diez decisiones. Un ensemble de modelos con el mismo linaje no aporta la diversidad que promete.

Para dimensionar el problema: la documentación de Microsoft Learn sobre fundamentos de LLM recuerda que estos modelos pueden generar respuestas con total seguridad que son factualmente incorrectas y que cada llamada a la API es stateless. La verificación no es un lujo de equipos grandes, es el parche estándar contra una limitación estructural del modelo.

Conclusión

Verify, Then Vote no descubre un modelo mejor ni una técnica que reemplace el juicio del verificador. Descubre algo más útil para quien construye: verificar y decidir son pasos que conviene tratar como datos, no como código enterrado dentro de un prompt.

El hallazgo más honesto del trabajo es incómodo: la regla que subió la precisión al 85,0% falló su propio test por medio punto porcentual, y solo la versión revisada lo pasó, con un 0,75% de rupturas. Esa es la diferencia entre un experimento y un producto. Si tu agente toma decisiones que importan, define hoy la métrica de daño aceptable y guarda cada verificación que hagas: lo que querrás experimentar la próxima semana es la regla, no los datos.