Actualización / corrección: después de publicar este artículo, una pregunta técnica me llevó de vuelta al request.json primario preservado de la corrida. Verifiqué que el artefacto revisado corresponde byte a byte al original.
Las condiciones relevantes sí estaban presentes, pero no pude confirmar que la versión candidata fusionada estuviera incluida exactamente como la recordaba.
Por eso retiro la localización de este caso específicamente en Interpretación. El punto exacto donde ocurrió el fallo queda, por ahora, no determinado.
Estoy probando modelos locales en tareas de análisis de código y hace poco apareció un fallo que me obligó a revisar cómo estaba usando una palabra bastante común en IA:
“alucinación”.
El caso parecía sencillo.
El modelo encontró fragmentos relevantes del código.
No inventó otro archivo.
No citó evidencia inexistente.
Mi primera lectura fue que había encontrado la evidencia necesaria y luego la había entendido al revés.
Después de volver al artefacto primario, tuve que estrechar esa conclusión.
Ese detalle terminó siendo más interesante para mí que el error en sí.
Porque decir simplemente:
“el modelo alucinó”
me permite saber que algo salió mal.
Pero no me dice qué salió mal.
Encontrar la evidencia no es lo mismo que entenderla
Seguí revisando errores de este tipo dentro de una campaña más amplia de evaluación con modelos locales.
Y empecé a notar que estaba agrupando bajo una misma palabra problemas que, desde el punto de vista de ingeniería, requieren soluciones completamente diferentes.
Por ejemplo:
- puede que la evidencia necesaria ni siquiera esté disponible;
- puede que esté disponible, pero la respuesta no quede correctamente vinculada con ella;
- puede que el modelo encuentre el fragmento adecuado y lo atribuya al objeto equivocado;
- puede leer correctamente el fragmento, pero interpretar mal su significado;
- puede interpretar bien la evidencia y aun así formular una afirmación que ya no está soportada;
- o puede llegar a una afirmación correcta y estropearla al usarla en el siguiente paso.
Terminé representándolo provisionalmente así:
Evidencia
↓
Binding
↓
Atribución
↓
Interpretación
↓
Claim
↓
Transformación
No estoy proponiendo esto como una taxonomía universal ni definitiva.
Es simplemente una herramienta que surgió de mis propias pruebas y que me está ayudando a formular una pregunta mucho más útil:
¿en qué punto exacto se rompió el proceso?
Por qué importa distinguirlos
Supongamos que el modelo da una respuesta incorrecta.
Si la información necesaria nunca estuvo dentro del contexto disponible, el primer problema probablemente no es el modelo.
Podría ser el mecanismo que construyó ese contexto.
En cambio, si la evidencia correcta estaba presente y el modelo la identificó, pero después entendió al revés lo que significaba, arreglar el sistema de recuperación probablemente no resolverá nada.
Es otro fallo.
Y pide otra respuesta.
**En el caso que me llevó a escribir esto, hoy puedo sostener algo más estrecho:
las condiciones relevantes sí estaban presentes en el payload.
Lo que no pude confirmar al volver al artefacto primario fue que la candidata fusionada estuviera incluida exactamente como la recordaba.
Por eso ya no puedo localizar limpiamente este caso en Interpretación.
Y justamente por eso “alucinación” sigue pareciéndome demasiado gruesa como diagnóstico: saber que hubo un fallo no basta para saber dónde ocurrió.**
Ahí “alucinación” dejó de resultarme suficientemente útil como diagnóstico.
Del error del modelo al error del sistema
Esta distinción también cambió una pregunta que me hacía al evaluar modelos.
Antes era fácil reducir el resultado a algo parecido a:
ACIERTO
FALLO
Ahora me interesa mucho más conocer la ruta:
¿Tenía la evidencia?
↓
¿La vinculó correctamente?
↓
¿La atribuyó correctamente?
↓
¿Entendió lo que significaba?
↓
¿Su afirmación estaba soportada?
↓
¿Usó correctamente esa afirmación después?
Porque cada respuesta cambia qué componente debería revisar.
Tal vez necesito mejorar el contexto.
Tal vez el problema está en cómo enlazo las fuentes con la respuesta.
Tal vez necesito restringir la tarea.
O quizá el modelo simplemente no debería tener autoridad para realizar ese tipo concreto de juicio sin otra capa de validación.
Esa última posibilidad es especialmente importante para mí.
No estoy intentando construir sistemas donde el modelo siempre tenga razón.
Estoy mucho más interesado en sistemas donde podamos saber qué conservar cuando se equivoca.
Una palabra útil, pero demasiado gruesa
No creo que “alucinación” sea necesariamente una palabra incorrecta.
El problema aparece cuando se convierte en la explicación final.
Dos respuestas pueden ser igualmente incorrectas y tener causas completamente distintas.
Y si las causas son distintas, también deberían serlo nuestras mitigaciones.
Por eso, después de estas pruebas, estoy intentando separar:
el síntoma
de
el lugar donde ocurrió el fallo.
“Alucinación” puede seguir nombrando el primero.
Pero todavía necesito diagnosticar el segundo.
Me interesa especialmente contrastar esto con quienes estén evaluando LLMs sobre código, RAG, agentes o flujos donde el modelo recibe evidencia externa:
cuando evalúan un modelo que recibe evidencia externa, ¿cómo distinguen en qué parte del proceso ocurrió realmente el fallo?
Transparencia: utilicé modelos de lenguaje como asistencia para revisar y editar la redacción. El experimento y los registros provienen de mi propio trabajo. La interpretación técnica de este caso fue corregida después de volver al artefacto primario preservado.
Top comments (0)