Los modelos de lenguaje están entrenados para completar texto de forma plausible, no para medir su propia certeza. Enseñarles a decir "no sé" requiere ir contra ese sesgo por defecto — y hay técnicas concretas que lo logran de forma consistente.
El sesgo de entrenamiento de los modelos de lenguaje favorece respuestas que suenan completas y seguras sobre respuestas honestas que admiten un vacío. Esto no es un bug aislado — es consecuencia directa de cómo se entrenan y evalúan estos sistemas: una respuesta incompleta o dubitativa se penaliza más en muchos benchmarks que una respuesta incorrecta pero fluida. El resultado es que, sin instrucción explícita, el modelo casi siempre prefiere inventar algo plausible a admitir un vacío de información.
La solución no es un truco de prompt único — es una combinación de instrucción explícita, restricción estructural, y verificación posterior.
La instrucción más efectiva no es "sé honesto" (demasiado vaga para cambiar el comportamiento del modelo) — es dar permiso explícito y sin ambigüedad para responder con incertidumbre, y decir exactamente qué frase usar.
La frase "no serás penalizado por..." parece innecesaria pero es efectiva: contrarresta directamente el sesgo de entrenamiento hacia respuestas que suenan completas.
Pedirle al modelo que "diga si no está seguro" dentro de una respuesta en prosa es frágil — es fácil de ignorar bajo presión de completar la tarea. Forzar un campo de confianza explícito en un output estructurado hace que la incertidumbre sea un dato, no una opinión que el modelo puede omitir.
Con este schema, tu aplicación puede tratar `confianza: "insuficiente_informacion"` como una rama de código explícita — mostrar un mensaje distinto, escalar a un humano, o pedir más contexto — en vez de depender de que el modelo lo mencione espontáneamente en el texto.
Antes de asumir que necesitas más prompting, verifica si el modelo simplemente no tiene la información en su contexto. Un modelo bien instruido para decir "no sé" seguirá inventando si su contexto no incluye el dato correcto — porque desde su perspectiva, no hay diferencia entre "esto no está en mi contexto" y "esto no existe". Si tu sistema es RAG, revisa primero el recall del retrieval (ver el artículo de context engineering para RAG) antes de asumir que el problema es de calibración del modelo.
Para casos de alto riesgo, una segunda llamada que audita la primera respuesta contra el contexto detecta afirmaciones no respaldadas con más confiabilidad que pedirle al mismo modelo, en la misma llamada, que se autoevalúe mientras genera.
Usar un modelo más barato para este paso de verificación es razonable — la tarea de "comparar afirmación contra texto fuente" es más simple que la generación original, y no necesita el modelo más grande.
Algunos modelos, ante ciertas categorías de riesgo, se niegan directamente a responder en vez de intentar contestar con baja confianza. Este es un caso distinto al de "no sé" pero tu código debe manejarlo — nunca asumas que `response.content` siempre tiene contenido útil sin revisar primero `stop_reason`.
Un modelo bien calibrado no es el que nunca se equivoca — es el que, cuando se equivoca, expresó baja confianza; y cuando acierta, expresó alta confianza. Para medir esto en un set de evaluación:
Si tu evaluación muestra que el modelo declara "alta confianza" con la misma frecuencia de acierto que "baja confianza", el problema no es que el modelo no sepa cuándo dudar — es que tu prompt no le está dando una razón real para diferenciar, y necesitas revisar la instrucción de calibración desde el principio.
Carlos Montiel es arquitecto de soluciones IA empresarial. Implementa LLMs, Agentes, RAG y orquestadores en empresas de Guatemala y Latinoamérica. Contáctalo para una consultoría.
Contactar a Carlos Montiel