Mismo prompt y mismo commit, dos diffs: la mitad de las evaluaciones de agentes salen a veces

Un leaderboard publicado este mes imprime cada una de las ejecuciones de ocho modelos sobre diez tareas sacadas de bases de código privadas en producción, ocho pasadas por modelo y tarea. De las 80 celdas modelo-tarea, 6 pasaron las ocho, 33 fallaron las ocho y 41 salieron mixtas. En más de la mitad de los pares, la pregunta «¿puede el agente hacer esto?» se responde con un «a veces».

El caso más gráfico es una tarea de migración de cliente que devolvió 3, 1, 6, 3, 4, 3, 4 y 0 aciertos sobre ocho intentos. Mismo prompt, mismo commit, resultados distintos.

Temperatura 0 no arregla nada

El mecanismo de fondo es que cada token es un sorteo de una distribución, y la temperatura solo aplana o afila esa distribución antes del sorteo, no lo elimina. La documentación de la API de Anthropic lo dice en una línea: incluso con temperatura 0.0 los resultados no son totalmente deterministas. Y según el texto, sus modelos posteriores a Opus 4.6 ya no aceptan el parámetro.

Un trabajo de Thinking Machines del año pasado lanzó el mismo prompt 1.000 veces a un modelo abierto de 235.000 millones de parámetros con temperatura 0 y obtuvo 80 respuestas distintas: todas coincidían en los primeros 102 tokens y se separaban en el 103. La causa está en el lado del servicio, donde las sumas en coma flotante se agregan en distinto orden según cuántas peticiones compartan tu lote. En un chat eso cambia una palabra; en un agente cambia qué fichero se hace grep primero, y de ahí sale un plan distinto en el tercer turno.

pass@k y la k que nadie menciona

La rejilla también deja ver la diferencia entre métricas. El número del primer clasificado es 38,8%. Esas mismas ochenta ejecuciones, leídas como «resuelto al menos una vez en ocho», dan 70%. Otra fila pasa de 28,8% a 90% sin haber superado nunca una tarea ocho de ocho. Son las mismas pasadas y dos cifras, y la k es la parte que no se dice en voz alta.

El caso más claro en el trabajo propio de quien publica fue un A/B de compresión en el que una instancia discrepaba del resto; repetir cinco veces por rama dio 3/5 contra 3/5. Con una sola ejecución por rama se habría publicado una diferencia inexistente.

El cambio que propone es pasar a tres ejecuciones por lado y tarea, con el mismo arnés, anotando los dos números de versión y comparando recuentos. Queda sin medir cuánta dispersión viene del sampler y cuánta del lado del servicio, algo que no hay forma de separar desde fuera de una API pública; si tres pasadas bastan para algo más que las decisiones más gruesas; y si los CLI implicados pasan temperatura, porque ninguna de sus referencias de configuración la menciona.