LLM solo o pipeline de agentes para explicar mortalidad en UCI

Sobre 2.353 ingresos en UCI con una mortalidad del 8,1%, un XGBoost alcanza un AUROC de 0,855 (IC del 95%: de 0,796 a 0,906) y un AUPRC de 0,332 (de 0,217 a 0,494). El modelo predice razonablemente bien. Lo que no hace es decirle nada aprovechable a quien está delante del paciente, y ese hueco es el que intenta cubrir un estudio de viabilidad publicado en arXiv el 28 de agosto, que compara dos formas de generar la explicación clínica: un LLM trabajando solo y un pipeline de agentes de cuatro pasos con las tareas separadas.

Merece la pena detenerse un segundo en el AUPRC. Con una prevalencia del 8,1%, un clasificador que ordenara al azar rondaría 0,081, así que 0,332 es unas cuatro veces la línea base. No es una cifra brillante leída en frío, es lo que suele salir cuando el evento es poco frecuente.

Qué separa el pipeline

El pipeline está especificado de antemano, no lo improvisa el modelo, y parte la tarea en fases: interpretación de los datos, comprobación contra guías clínicas y redacción final. La hipótesis de los autores es que separar responsabilidades reduce las ocasiones que tiene el modelo de inventarse el razonamiento por el camino. La alternativa, el LLM aislado, recibe el caso junto a la atribución y escribe la explicación de una sola pasada.

Los datos vienen del eICU Demo, un subconjunto público y pequeño de la eICU Collaborative Research Database, lo que facilita reproducir el experimento pero limita cualquier conclusión sobre generalización a otras unidades.

El reparto de virtudes

Sobre un subconjunto estratificado de 38 casos, el LLM aislado produjo una explicación con fuga explícita del desenlace: mencionaba el resultado real del ingreso, información que por definición no debería estar disponible al explicar una predicción. El pipeline de cuatro pasos no produjo ninguna.

En los 14 casos que solapaban con la revisión SHAP, el reparto se invierte en parte:

El LLM aislado quedó más alineado con las atribuciones SHAP (Jaccard medio de 0,171 frente a 0,077) y fue más consistente en la dirección del efecto (92,9% frente a 78,6%).
El pipeline de agentes ancló mucho mejor en guías clínicas (0,762 frente a 0,143).

Cómo leerlo sin exagerar

38 casos y 14 solapados son muy pocos. Los propios autores encuadran el trabajo como estudio de viabilidad y se trata de una versión revisada de un texto anterior, así que las diferencias apuntan una dirección, no la fijan. Lo relevante no es quién gana, porque no gana nadie del todo: son dos perfiles de error distintos. El LLM directo se parece más a lo que el modelo ponderó de verdad; el pipeline dice menos cosas que no pueda respaldar.

Lo que se lleva quien construye agentes

El compromiso queda bastante nítido. Al insertar pasos intermedios, la explicación se aleja de la atribución real del modelo y gana disciplina externa. Si el criterio de aceptación es «no afirmes nada que no puedas fundamentar en una guía», el pipeline es la opción; si el criterio es «describe este modelo con fidelidad», el LLM directo estaba más cerca. Elegir la métrica antes que la arquitectura ahorra bastantes discusiones después.

En la práctica, nada impide combinarlos: un paso de atribución que consulte SHAP como herramienta, un paso de verificación contra guías y un paso de redacción, cada uno evaluado por separado. En Claude Code eso se traduce en subagentes con un contrato explícito por fase y el cálculo estadístico detrás de un MCP server, en lugar de un único prompt largo al que se le pide todo a la vez. La ventaja no es la elegancia, es que puedes medir en qué paso se rompe. El fragmento público del resumen tampoco entra en coste ni en latencia, y entre cuatro llamadas y una esa diferencia pesa a la hora de desplegar.

La lección que nos llevamos es barata pero incómoda: la métrica con la que definas «buena explicación» decide qué arquitectura gana antes de escribir una línea de código. Y nos gustaría ver la tasa de fuga del desenlace reportada siempre en este tipo de comparativas, no solo cuando el número sale favorable.