CARE-Bench: Benchmarking Patient-Facing LLM Triage

Sintesi Tecnica di CARE-BENCH: Benchmarking del Triage Gestito da LLM per il Paziente

Definizione del Problema
I Large Language Models (LLM) e gli agenti medici rivolti al paziente sono sempre più impiegati per rispondere a quesiti sui sintomi prima che i pazienti raggiungano i clinici. In questo contesto, la sfida primaria di sicurezza non è semplicemente l'accuratezza diagnostica o la qualità della risposta, ma determinare la prossima azione corretta che l'utente debba intraprendere. Gli attuali benchmark di valutazione si affidano spesso a vignette cliniche statiche o a compiti generici di QA sulla salute, che non riescono a catturare la natura dinamica del triage rivolto al paziente. Nelle interazioni del mondo reale, l'azione appropriata (ad esempio, chiedere chiarimenti, raccomandare l'autocura o scalare verso cure d'emergenza) dipende dalle informazioni divulgate ad ogni turno. I consigli prematuri possono portare a un sottotriage (ritardo nelle cure necessarie) o a un sovratriage (creazione di una domanda non necessaria), mentre le risposte ambigue possono confondere gli utenti con bassa alfabetizzazione sanitaria. Studi esistenti indicano che gli attuali modelli faticano con la calibrazione, spesso sottotriage nei casi di emergenza e sovratriage nei casi non urgenti, oppure forniscono segnali di azione misti che oscurano il passo successivo immediato.

Metodologia
Gli autori introducono CARE-BENCH, un benchmark basato su fonti (source-grounded) progettato per valutare il triage sequenziale rivolto al paziente come un compito di azione corrente per singolo turno.

• Formulazione del Task: Il benchmark tratta il triage come un problema di classificazione in cui il sistema riceve un "prefisso di divulgazione del paziente" (testo accumulato del paziente fino al turno corrente) e deve produrre una risposta. Questa risposta viene mappata in uno dei quattro etichette di azione:
  1. INFONEEDED (Informazioni Necessarie): È richiesto un chiarimento mirato prima che possa essere scelta un'assistenza.
  2. SELFCARE/MONITOR (Autocura/Monitoraggio): Le informazioni attuali supportano l'autocura, il monitoraggio o la creazione di una rete di sicurezza contingente al futuro.
  3. NONURGENTCARE (Cura Non Urgente): È necessaria una valutazione clinica senza linguaggio urgente.
  4. URGENTCARE (Cura Urgente): È necessaria un'assistenza nella stessa giornata, d'emergenza o in caso di pericolo nel ritardo.
• Costruzione del Dataset: Il dataset comprende 500 casi e 1.059 round ricostruiti da fonti di dialogo medico, consultazione e domande di follow-up (MedDialog/OpenMed, ChatDoctor, PriMock57 e Followup-Q). Un flusso di lavoro iterativo che coinvolge GPT-5.5 e revisori umani (inclusi un candidato al dottorato in salute pubblica e un tirocinante medico) astrae i fatti sorgente in divulgazioni sequenziali del paziente. Ogni round è etichettato con l'azione corrente dovuta in base allo stato informativo di quel particolare turno.
• Protocollo di Valutazione: Gli autori hanno valutato 11 modelli (che spaziano tra modelli chiusi, modelli a pesi aperti generali e modelli sanitari aperti) sotto due protocolli:
  1. Unprompted (Non sollecitato): Il modello riceve solo il testo del paziente, simulando una query generica dell'utente senza istruzioni specifiche.
  2. Prompted (Sollecitato): Viene aggiunta un'istruzione minima per essere "breve, sicura e orientata all'azione", senza fornire esempi o nomi di etichette.
• Scoring: Le risposte vengono mappate nello spazio delle quattro etichette utilizzando un mapper gpt-5.5 fisso. La metrica principale è la macro-F1, integrata da accuratezza, over/under-triage, e tassi di errore specifici per soglia (cure mancate, cure non necessarie, falsi negativi urgenti e falsa escalation urgente).

Contributi Chiave

1. Operazionalizzazione del Triage: Il paper operazionalizza il triage rivolto al paziente come un compito di valutazione dell'azione corrente per turno su prefissi controllati di divulgazione del paziente, andando oltre la classificazione statica delle vignette.
2. Benchmark Basato su Fonti: Rilascia un dataset di 500 casi e 1.059 round con grounding delle fonti verificabile, coprendo divisioni di sviluppo, validazione e test separati.
3. Valutazione Empirica: Fornisce una valutazione completa di 11 LLM, rivelando fallimenti persistenti nel timing delle azioni e nella calibrazione che non vengono risolti da un semplice prompting.

Risultati

• Performance: Gli score di macro-F1 unprompted erano bassi, variando dal 31,2% al 50,4%. Il prompting ha migliorato le performance per 10 modelli su 11, con una macro-F1 compresa tra il 46,9% e il 63,4%, ma rimanevano sostanziali errori di soglia.
• Fallimento del Chiarimento: Un modo di errore dominante è il fallimento nel riconoscere l'insufficienza delle informazioni. Quando l'azione corretta era INFONEEDED, solo il 19,0% degli output unprompted e il 33,5% degli output prompted hanno correttamente preservato la fase di richiesta di chiarimento; la maggioranza (81,0% degli unprompted e 66,5% dei prompted) ha raccomandato prematuramente l'assistenza.
• Compromessi di Soglia: Il prompting spesso sposta il comportamento del modello verso la raccomandazione di cure professionali. Sebbene ciò riduca le cure professionali mancate (falsi negativi), aumenta frequentemente le cure non necessarie (falsi positivi) e il sovratriage. Ad esempio, GPT-5.5 ha ottenuto un basso tasso di falsi negativi urgenti (9,8%) ma un alto tasso di cure non necessarie (56,9%).
• Analisi di Sensibilità: Le performance sono migliorate quando tutte le divulgazioni del paziente erano disponibili contemporaneamente (prefisso terminale), suggerendo che i modelli possono formulare meglio le raccomandazioni finali ma faticano con il timing delle azioni durante la fase di raccolta informazioni. L'esatta corrispondenza della traiettoria (azione corretta a ogni turno) è rimasta bassa (22,0% unprompted, 34,9% prompted).
• Variabilità dei Modelli: Nessun singolo modello è emerso come un chiaro leader in tutte le dimensioni di sicurezza. I modelli sanitari aperti non hanno superato uniformemente i modelli generali; ad esempio, HuatuoGPT-o1 ha mostrato alti tassi di falsi negativi urgenti nonostante sia un modello ottimizzato per la medicina.

Significatività e Claim
Il paper conclude che il triage rivolto al paziente non è un semplice problema di prompting. La persistenza degli errori — specificamente il fallimento nel ritardare i consigli sulle cure finché non sono state raccolte informazioni sufficienti — suggerisce che gli attuali modelli mancano della capacità di temporizzare appropriatamente le proprie azioni in base agli stati informativi in evoluzione.

Gli autori affermano che CARE-BENCH fornisce una risorsa controllata per studiare se gli LLM medici rivolti al paziente comunicano consigli sulla ricerca di cure con un timing e una calibrazione appropriati. Essi dichiarano esplicitamente che il benchmark valuta l'azione corrente comunicata al paziente, non il processo decisionale clinico all'interno di un sistema di cura. I risultati supportano la tesi che gli attuali modelli commettono errori di soglia sostanziali, in particolare quando è necessario un chiarimento prima di fornire consigli sulle cure. Il paper sottolinea che questi risultati supportano la necessità di una valutazione esplicita del timing delle azioni prima del deployment, piuttosto che affidarsi esclusivamente all'accuratezza aggregata o a ampi benchmark di QA sulla salute. Gli autori avvertono che il benchmark non certifica la sicurezza clinica, l'accuratezza diagnostica o l'idoneità per il routing autonomo.