El umbral es del código; el modelo solo da una probabilidad

Si pones unos cientos de proyectos reales uno al lado del otro, el rasgo común más estable es este:

El modelo responde «cuán probable es». Tu código responde «¿es suficiente?».

No es una preferencia de estilo. Es la única conclusión segura que se puede sacar del hecho de que la confianza autodeclarada no es fiable — y hay una medición independiente que lo respalda en ¿Se puede confiar en las probabilidades?.

Cómo se ve en concreto

Choice y Score devuelven una respuesta con un confidence adjunto; Noul devuelve directamente una probabilidad de 0 a 1. La interfaz en sí no toma ninguna decisión por ti: el umbral es tuyo. En proyectos reales, eso se concreta en formas muy específicas:

Un filtro de groserías que corre en un Cloudflare Worker mantiene su umbral, su política de agregación max() y su schema OpenAPI público en el propio código del Worker. El modelo es solo una función que llama.
Una extensión de navegador que oculta comentarios mantiene 0.85 / 0.7 / 0.5 fijados en la propia extensión, y mantiene lo oculto cuando la comprobación falla — esa preferencia también forma parte de la política de umbral.
Una herramienta de triaje de incidentes define «avisar a alguien» como P(SEV1) + P(SEV2) ≥ 0.80, y ese 0.80 vive en su propia configuración, no en el modelo.

Los tres comparten una misma propiedad: cambia el modelo y el umbral no se mueve; reajusta el umbral y el modelo no se mueve. Si le entregas el umbral al modelo, esas dos cosas se vuelven una sola — y en ese momento «ajustar mi umbral» significa editar un prompt.

Por qué importa este principio

Porque mantiene separadas dos clases de fallo:

El modelo respondió mal: cambia la pregunta, cambia el estado, cambia el modelo.
El umbral está mal puesto: cambia el número en el código.

Si los mezclas, «la precisión no alcanza» podría ser cualquiera de los dos, sin forma de saber cuál. La herramienta de triaje puede poner 0.80 directamente en la configuración justamente porque ese número se puede revisar por sí solo.

El contraejemplo que debes conocer

El principio se apoya en una suposición: que el número que recibes es una probabilidad calibrada.

Un recálculo independiente encontró que el confidence que se devuelve para las preguntas de Score con frecuencia es solo la parte fraccionaria del score, y esas salidas están muy agrupadas (121 de ellas). Eso no es «el modelo tiene confianza»: parece un valor derivado del propio score.

La diferencia importa:

Si es una probabilidad calibrada, 0.85 permite razonar así: «acertaré en alrededor del 85% de casos como este».
Si es una función del score, 0.85 solo significa «este salió alto» y no dice nada sobre con qué frecuencia acierta — y ponerle un umbral significa fijar un listón para un número sin significado probabilístico.

Por separado, un informe de medición independiente contrastó los campos autodeclarados del modelo con la verdad de referencia y encontró valores mucho menos granulares de lo que sugiere la descripción (ver Críticas públicas).

Qué hacer en su lugar

Tres pasos, y el orden importa:

Usa el umbral de forma operativa, no semántica. Que 0.8 signifique «80% correcto» no es importante. Lo que importa es si, en tus datos, los casos por encima de 0.8 son mediblemente más precisos. Eso sí lo puedes comprobar contra un conjunto de validación.
Ajusta el umbral con tus propias etiquetas. Existen herramientas justo para esto: toma tus datos etiquetados, ajusta el umbral por pregunta que alcanza tu precisión objetivo, valida contra un conjunto de validación, y haz fallar CI cuando una actualización del modelo rompa un umbral bloqueado.
Pon el umbral en el código y dale una fecha de revisión. Los umbrales caducan con las versiones del modelo, igual que los precios. Es algo que una persona tiene que volver a mirar, no algo que fijas una sola vez.

En una frase

La fiabilidad del modelo debería reflejarse en tu umbral, no en el número que él mismo reporta. El primero lo puedes medir con tus propios datos; el segundo no.