Lo que aprendí al probar tres modelos de IA para detectar errores en reportes radiológicos
Antes de conectar cualquier modelo a un flujo de trabajo clínico real, hay que medir. Esto es lo que encontré cuando lo hice. Los errores de reportes existen por eso los Addendums.
Soy radiólogo. Y como radiólogo sé que los errores en los reportes no son la excepción — son una realidad sistémica que la profesión lleva décadas intentando controlar. La tasa global de error diagnóstico se estima entre el 3 y el 5% anual: aproximadamente 40 millones de errores diagnósticos al año en el mundo. El 75% de las demandas por responsabilidad médica contra radiólogos involucra este tipo de fallas.
Pero hay un detalle que me parece crítico y que a veces se pierde en esa estadística: entre el 60 y el 80% de esos errores no son de conocimiento clínico. No son diagnósticos difíciles que cualquier radiólogo habría errado. Son errores mecánicos — el reporte que dice "izquierda" cuando el hallazgo es derecho, el campo de medición que quedó vacío, el hallazgo crítico descrito en el cuerpo del texto que nunca llegó a la conclusión.
Cuando uno de esos errores sale del departamento, el mecanismo correctivo es el addendum. Un documento que corrige el reporte original después de que el médico tratante ya lo leyó y tomó decisiones con él. El error ya llegó al clínico. El daño potencial ya ocurrió.
Eso es lo que quiero interceptar. Y la pregunta que me hice fue simple: ¿puede un modelo de lenguaje detectar esos errores antes de que yo firme?
Para saberlo, diseñé un benchmark.
La taxonomía: qué errores quería detectar
Antes de evaluar cualquier modelo, tuve que definir con precisión qué estaba midiendo. Trabajé sobre dos marcos de referencia establecidos en la literatura: la clasificación de Renfrew et al. (1992), que propone 12 tipos de error según su origen cognitivo y comunicacional, y la clasificación de Brook et al. (2010), que incorpora factores sistémicos más allá del error humano individual.
De ahí construí una taxonomía operacional centrada en los errores detectables por análisis de texto — es decir, errores que no requieren acceso a las imágenes para identificarse. La organicé en tres categorías:
Término incorrecto — el reporte dice algo equivocado. Lateralidad invertida, órgano inconsistente con el sexo del paciente, grado de clasificación discrepante entre hallazgos y conclusión, errores léxicos del sistema de reconocimiento de voz.
Término ausente — falta algo que debería estar. Un hallazgo descrito en el cuerpo que no aparece en la conclusión, una lesión sin medidas, una pregunta clínica de la indicación que nunca fue respondida.
Campo incompleto — el campo existe en la plantilla pero no fue llenado. Medidas en blanco, unidades no especificadas, dosis radiológica no registrada.
En total: 24 tipos de error clasificados, cada uno con su categoría, su clase de Renfrew correspondiente, y su nivel de severidad según impacto clínico potencial.
El benchmark: cómo lo diseñé
La decisión metodológica clave
Decidí correr el benchmark sin ejemplos few-shot en el prompt. Eso significa que los modelos recibieron las 24 reglas de clasificación pero ningún ejemplo de cómo aplicarlas. El objetivo era medir el rendimiento base de cada arquitectura antes de cualquier optimización — establecer el piso real desde el cual partir.
Evalué tres familias de modelos con escalas de parámetros distintas: uno mediano, uno grande, y uno compacto de alta eficiencia. Los corrí desde el mismo servidor de producción que va a operar el sistema definitivo, para que las mediciones de latencia fueran representativas de condiciones reales y no de un entorno de laboratorio.
Los casos de prueba
Construí cinco reportes radiológicos sintéticos con errores conocidos y verificables. Los redacté en español colombiano, con la terminología y los patrones de dictado propios del contexto latinoamericano — porque si el sistema va a funcionar en Colombia, tiene que ser probado en las condiciones de Colombia.
| Caso | Modalidad | Errores sembrados | Críticos |
|---|---|---|---|
| TC-01 | Ecografía renal | Órgano incorrecto para sexo, lateralidad invertida, hallazgo ausente en conclusión | 3 |
| TC-02 | TC de tórax | Campo de medición vacío, sin comparativo previo, contraste no documentado | 0 |
| TC-03 | TC de abdomen | Órgano extirpado descrito como normal, pregunta clínica no respondida, antecedente no abordado | 3 |
| TC-04 | Ecografía hepática | Hallazgo prioritario omitido en conclusión, campos vacíos, error de reconocimiento de voz | 1 |
| TC-05 | RM de rodilla | Grado de clasificación discrepante entre hallazgos y conclusión | 2 |
Las métricas
Para comparar los modelos usé las métricas estándar de recuperación de información: precisión (de lo que detectó, ¿qué era real?), recall (de lo que era real, ¿qué detectó?) y F1 como media armónica de ambas. También medí latencia promedio y proyecté el costo mensual a 800 estudios.
Los resultados: lo que encontré
El modelo mediano — el que mejor funcionó
| Métrica | Resultado |
|---|---|
| F1 promedio | 31% |
| Precisión | 45% |
| Recall | 65% |
| Latencia promedio | 13.4 s |
| Costo estimado (800 estudios/mes) | $0.70 USD |
El rendimiento fue heterogéneo. Excelente en TC-04 (F1 del 75%), donde los errores eran directamente observables en el texto. Cero en TC-03 y TC-05, que requerían razonamiento contextual cruzado entre secciones. Lo que me llamó la atención: cuando detectó algo, lo detectó con especificidad. Su precisión del 45% con recall del 65% me dice que el modelo tiende a ser conservador — cuando emite una detección, generalmente tiene razón, aunque se le escapen cosas.
El modelo grande — el resultado más sorprendente
| Métrica | Resultado |
|---|---|
| F1 promedio | 22% |
| Precisión | 20% |
| Recall | 18% |
| Latencia promedio | 12.6 s |
| Costo estimado (800 estudios/mes) | $0.72 USD |
Este fue el hallazgo más contraintuitivo de todo el ejercicio: el modelo más grande tuvo el peor F1. Al revisar las respuestas caso por caso encontré el patrón: en cuatro de cinco casos, el modelo devolvió listas de los errores 1 al 5 o 1 al 6 — los más comunes estadísticamente — independientemente de lo que decía el reporte específico que había recibido. No estaba leyendo el texto. Estaba respondiendo lo que le parecía más probable que hubiera en un reporte radiológico genérico.
El modelo compacto — rápido pero insuficiente
| Métrica | Resultado |
|---|---|
| F1 promedio | 10% |
| Precisión | 8% |
| Recall | 13% |
| Latencia promedio | 4.7 s |
| Costo estimado (800 estudios/mes) | $0.19 USD |
En cuatro de cinco casos no detectó nada — devolvió arrays vacíos. Solo en TC-01, el caso más morfológicamente obvio (un órgano anatómicamente imposible para el sexo del paciente), tuvo detección parcial. Su latencia de 4.7 segundos lo hace interesante como filtro rápido en una arquitectura de dos etapas, pero solo — no es suficiente.
Lo que aprendí
El tamaño del modelo no predice el rendimiento en tareas especializadas
Este es probablemente el aprendizaje más importante, y el que más me sorprendió. Intuitivamente uno esperaría que más parámetros impliquen mejor razonamiento. Pero en esta tarea específica — aplicar 24 reglas de clasificación sobre texto médico en español con contexto clínico — el modelo grande sobre-generaliza. Tiene tanta capacidad de generar respuestas plausibles que, sin señal contextual suficiente, produce la respuesta "más esperada" para el dominio en lugar de razonar sobre el texto concreto que recibió.
El modelo mediano, con menos capacidad de generalización, resulta paradójicamente más honesto: cuando no sabe con certeza, no inventa.
La implicación práctica es clara: la selección del modelo para una tarea de dominio especializado no puede hacerse en función del número de parámetros ni del rendimiento en benchmarks generales. Requiere evaluación empírica en el dominio específico.
Sin few-shot, los modelos adivinan la distribución de errores más común
El benchmark sin ejemplos establece el piso. La literatura en prompting documenta consistentemente que la incorporación de few-shot mejora el F1 entre 20 y 35 puntos porcentuales en tareas de clasificación estructurada. Para el modelo seleccionado, eso proyecta un F1 de entre 51% y 66% con un prompt optimizado que incluya ejemplos representativos de los 24 tipos de error.
La adaptación supervisada al dominio con datos reales — reportes etiquetados por radiólogos — es el paso siguiente, con un objetivo de F1 superior al 75% basado en estimaciones de la literatura.
La latencia es el condicionante real, no el F1
La latencia de 13.4 segundos del modelo seleccionado es consecuencia directa del tamaño del prompt: aproximadamente 6,400 tokens de sistema en la versión base, que subirán a más de 8,000 con los ejemplos few-shot. Con esos números, no es posible implementar respuesta síncrona — el radiólogo no puede esperar 13 segundos antes de firmar cada reporte.
La consecuencia es que la fase inicial de despliegue tiene que ser asíncrona: el reporte se envía al sistema al finalizar el dictado, el análisis corre en background, y la alerta llega por canal dedicado sin interrumpir el flujo de firma. El radiólogo ve la alerta, la revisa, y decide. Sin fricción en el proceso.
La respuesta síncrona — que el sistema devuelva el resultado antes de que el radiólogo pueda firmar — solo se vuelve viable cuando se reduzca la latencia a menos de 5 segundos. Eso requiere que el modelo internalice las reglas de clasificación en sus pesos en lugar de recibirlas en el contexto en cada llamada.
El costo de inferencia no es una variable de decisión
A 800 estudios por mes, la diferencia de costo entre el modelo ganador y el más barato es de $0.51 mensuales. Incluso a 12,500 estudios mensuales, el costo total no supera los $9 USD. El costo no es el problema.
Una cosa que el benchmark no captura — y que descubrí en producción
Los valores de F1 no cuentan toda la historia. Hay algo que aprendí al conectar el sistema a un workflow de automatización real que no aparece en ninguna tabla de resultados: el consumo de tokens tiene consecuencias arquitectónicas que van mucho más allá del costo.
El prompt completo con las 24 reglas más los ejemplos few-shot suma alrededor de 6,400 tokens de entrada por cada reporte. El reporte en sí añade 200-400 tokens más, y la respuesta estructurada en JSON otros 400. En total: entre 7,000 y 7,800 tokens por análisis. A 800 estudios mensuales, son más de 6 millones de tokens al mes. A escala de un centro de alta complejidad con 12,500 estudios, la cifra supera los 90 millones mensuales.
El costo sigue siendo marginal — eso ya lo discutí. Pero ese volumen de tokens en el prompt de sistema es exactamente el responsable de los 13 segundos de latencia. Y esa latencia es lo que hace inviable la respuesta síncrona hoy.
La consecuencia práctica: reducir el consumo de tokens no es solo una decisión de costo — es una decisión de arquitectura clínica. Un modelo que haya internalizado las reglas necesita un prompt de ~200 tokens en lugar de 6,400. La latencia cae a 3-5 segundos. Y con esa latencia, la alerta puede llegar antes de la firma.
Eso es lo que viene en el futuro.
Limitaciones
Siendo honesto: este benchmark es pequeño. Cinco casos sintéticos no son representativos de la distribución real de errores en un servicio de radiología en producción. Los valores de F1 que reporté no son generalizables — son una línea de referencia.
Además, corrí el benchmark sin ajuste de temperatura ni otros hiperparámetros, y sin few-shot. Eso es intencional — quería el rendimiento base — pero significa que los números van a cambiar, y esperablemente para mejor, cuando optimice el prompt.
Lo que sí es válido: la comparación relativa entre modelos, la observación sobre el comportamiento de sobre-generalización del modelo grande, y la implicación arquitectónica de la latencia. Eso no cambia con más casos de prueba.
Conclusiones
Tres cosas quedaron claras después de este ejercicio:
Primero: los modelos de escala mediana pueden detectar errores mecánicos en reportes radiológicos en español con un rendimiento base aceptable como punto de partida. No es suficiente para producción todavía, pero es suficiente para empezar a capturar datos reales.
Segundo: el tamaño del modelo no predice el rendimiento en tareas de dominio especializado. Hay que medir en el dominio. Siempre.
Tercero: la latencia de inferencia — no el F1 — es el principal determinante de cómo se puede integrar el sistema en el flujo clínico. Un sistema con F1 moderado que no interrumpe el trabajo del radiólogo es más viable que uno más preciso que lo frena.
Estos resultados son consistentes con los hallazgos reportados en mi trabajo prestando en RSNA 2025 junto con Acosta-Buitrago et al. en la sesión M2-QI-4 de la RSNA 2024 (Enhancing Radiology Reporting Accuracy With AI-Driven Error Detection):
En este trabajo que exploró con php, n8n una arquitectura similar y documentó reducciones significativas de error en los tipos 2, 10 y 19 — lateralidad, pregunta clínica no respondida, y hallazgo prioritario ausente en conclusión — que coinciden exactamente con los casos donde mi sistema mostró el rendimiento más variable. Leer ese trabajo después de correr mi propio benchmark fue una de esas coincidencias que confirman que uno está mirando el problema correcto.
Lo que viene ahora es la validación clínica real: reportes de verdad, de-identificados, con radiólogos reales etiquetando los resultados. Cada confirmación y cada rechazo va a un dataset de correcciones que eventualmente va a permitir que el modelo aprenda las reglas en lugar de recibirlas en el prompt. Cuando eso pase, la latencia baja, la alerta llega antes de la firma, y el sistema deja de ser una herramienta de monitoreo para convertirse en una segunda revisión real antes de que el reporte salga del departamento.
Ese es el objetivo. Este benchmark fue el paso cero. Vendrás mas en el futuro...
Esta publicación pienso será el proceso de desarrollo de RAD·QC, un sistema de control de calidad automatizado para reportes radiológicos. El sistema analiza únicamente el texto del reporte después de un proceso de anonimización, sin acceso a imágenes diagnósticas ni participación en decisiones clínicas. El radiólogo retiene siempre la autoridad final!!