La línea que trazamos alrededor de un modelo de lenguaje

La pregunta de ingeniería interesante sobre los modelos de lenguaje ya no es qué pueden hacer. Es qué decisiones deberían poder asumir. Son preguntas distintas, y confundirlas es como un prototipo prometedor se convierte en un producto que hace lo incorrecto en silencio y a escala.

Un modelo que acierta el noventa y cinco por ciento de las veces es extraordinario como resultado de investigación e inaceptable como acción irreversible ejecutada mil veces al día. El cinco por ciento restante no se reparte con educación. Así que antes de entregar una decisión a un modelo, hacemos tres preguntas.

1. ¿Es reversible la acción?

Redactar un correo es reversible. Enviarlo no. Proponer una planificación es reversible. Cancelar las citas para aplicarla no. Este es el filtro más barato y fiable que tenemos, y aplicarlo no cuesta nada: separa la generación de una propuesta de su ejecución, y mantén a una persona en el segundo paso siempre que el primero no se pueda deshacer.

El modo de fallo aquí no es el modelo. Es la decisión de producto de fundir dos pasos en uno porque la demo quedaba más fluida.

2. ¿Se puede comprobar la respuesta más barato de lo que costó producirla?

Esta es la asimetría que hace que algunas tareas se puedan automatizar con seguridad. Si un modelo propone una ruta, un solver verifica las restricciones en microsegundos. Si extrae una cifra de un documento, una expresión regular confirma que esa cifra aparece en el original. Si escribe código, los tests se ejecutan.

Donde existe un verificador barato, el modelo está haciendo búsqueda y el verificador está decidiendo — y el sistema compuesto es mucho más fiable que el modelo solo. Donde no existe verificador, la salida del modelo es la decisión, y la confianza en ella tiene que venir de otro sitio completamente distinto.

Generar no es la parte difícil. La fiabilidad sale, en realidad, de la verificación.

3. ¿Notaría el usuario que está mal?

Esta es la que se infravalora. Una respuesta equivocada que el usuario reconoce inmediatamente como equivocada es una molestia. Una respuesta equivocada que resulta plausible, bien formateada y sobre un dominio que el usuario consultó precisamente porque no sabe la respuesta es otra cosa. La fluidez de la interfaz se convierte en la prueba de que el contenido es correcto.

En ese régimen no publicamos la salida cruda del modelo. O la anclamos en una fuente recuperable que el usuario puede abrir, o la restringimos a un espacio estructurado donde las respuestas inválidas no se puedan representar, o le acoplamos un cálculo determinista que el modelo no tiene permiso para sobrescribir.

Cómo se ve esto en la práctica

• Salida estructurada antes que texto libre siempre que el resultado alimente otro sistema. Un esquema que el parser rechaza es un fallo que se ve; un párrafo sutilmente equivocado no.
• Recuperación con citas visibles, para que la confianza del usuario se apoye en la fuente y no en la fluidez de la prosa.
• Cálculo determinista para todo lo numérico. El modelo puede elegir la fórmula; no le toca evaluarla.
• Una suite de evaluación que se ejecuta en cada cambio, con casos recogidos de fallos reales y no imaginados.
• Un límite de rechazo declarado — el conjunto de preguntas que el producto responde con «esto necesita a una persona», escrito antes del lanzamiento y no renegociado después bajo la presión de una hoja de ruta.

Nada de esto es una limitación de lo que los modelos de lenguaje pueden hacer. Es la disciplina ordinaria de construir sobre un componente con una tasa de error conocida, algo que los ingenieros llevan décadas haciendo con sensores, redes y aritmética en coma flotante. Que el componente sea nuevo no es motivo para abandonar la práctica.