LLM treinado em vários hospitais sem o dado sair: o paper MEDAL

MEDAL ajustou adapters do LLaMA 3.1 8B em sequência entre hospitais, sem mover dado de paciente, e superou modelos como o GPT-5 em até 16,6 pp.

Rogério Rodrigues

Rogério Rodrigues

Rogério numa estação de trabalho de hospital; ao lado, o paper MEDAL no Journal of Biomedical Informatics: treinar LLM em vários hospitais sem o prontuário sair, até 16,6 pontos percentuais acima de modelos de fronteira.

Dá pra treinar um LLM com nota clínica de vários hospitais sem que nenhum prontuário saia de onde está. O MEDAL, publicado no Journal of Biomedical Informatics em 17/09/2026, fez isso com o LLaMA 3.1 8B: adapters leves ajustados em sequência entre instituições, cada uma com seus próprios dados, sem transferir dado de paciente. Resultado: desempenho perto do modelo treinado com tudo junto, acima de cada hospital sozinho e até 16,6 pontos percentuais acima de modelos de fronteira como o GPT-5 nas duas tarefas testadas.

Li o resumo estruturado e os metadados do artigo no PubMed. Não consegui abrir o texto completo, então tudo que vai abaixo sai do que os autores puseram no resumo. Onde o resumo não responde, eu digo que não responde.

O que o MEDAL fez

O nome vem de Multi-institutional Efficient/Distributed Adapter Learning. A ideia é simples de explicar. Você não mexe nos 8 bilhões de parâmetros do modelo base. Treina só um adapter, um conjunto pequeno de pesos extras que fica pendurado no modelo. Pelo resumo, o que avança de uma instituição pra outra é o adapter ajustado, não o dado.

O roteiro foi este:

  1. Modelo base: LLaMA 3.1 8B.
  2. Duas tarefas sobre sumário de alta: identificar sepse e identificar óbito durante a internação.
  3. Três bases separadas: MIMIC-IV, uma coorte de UTI adulto da UCSF e uma coorte de UTI pediátrica da UCSF.
  4. Uma GPU por site, distribuídas entre a Universidade do Texas em Austin e a UCSF.
  5. O adapter é ajustado num site e a próxima instituição continua o ajuste. Sequencial, sem transferir dado de paciente. O resumo não detalha como o adapter circula entre os sites.

Depois compararam o modelo MEDAL com três coisas: um modelo treinado com todos os dados juntos (o teto teórico), modelos treinados em cada centro isolado, e o GPT-5. Pra ver se o método aguenta mais participantes, quebraram o MIMIC-IV em 10 centros virtuais e rodaram a sequência por eles.

Por que sequencial e não federated learning clássico

No federated learning de livro, cada nó treina, manda gradiente ou peso pra um servidor, o servidor faz a média e devolve. Os autores citam lacunas técnicas do FL como um dos freios pra levar isso a LLM em saúde. O resumo não descreve a mecânica além de “sequencial”. Minha leitura, não dos autores: se o desenho for um revezamento de adapter, como o nome sugere, cada hospital só precisa receber um arquivo, treinar e passar adiante. Pra um time de TI hospitalar, isso parece mais simples de operar do que manter um servidor de agregação conversando com todo mundo.

O número, com o contexto certo

“Bateu o GPT-5 em 16,6 pontos” é o tipo de frase que vira manchete. O resumo diz “até 16,6 pontos percentuais”. Isso é a maior diferença encontrada, não a média. Em algum cenário avaliado a vantagem foi essa. Nas outras, menor. O resumo não traz a tabela, então não sei qual combinação nem quanto foi nas demais.

Os outros resultados, como os autores descrevem:

  • F1 do MEDAL “se aproximando” do modelo com dados centralizados. Ou seja, ficou abaixo do teto, perto dele.
  • Superou de forma consistente os modelos treinados em um centro só, nas tarefas avaliadas.
  • No teste com 10 centros virtuais, a performance convergiu rápido e ficou estável entre rodadas.

A leitura honesta: um modelo de 8B especializado na tarefa, com dado de três bases, ganhou de um modelo de fronteira genérico numa classificação estreita. Isso é esperado. O resultado que interessa mais é o outro: treinar em revezamento chegou perto de juntar tudo num lugar só. É esse que muda a conversa de governança.

O que isso significa pra um hospital brasileiro com LGPD

Dado de saúde é dado pessoal sensível na LGPD (art. 5º, II). Na prática, o jurídico de qualquer hospital trava quando alguém propõe mandar prontuário pra fora, seja pra nuvem de terceiro, seja pra outro hospital. O desenho do MEDAL conversa direto com essa trava: o dado fica na instituição, o que sai da instituição, se o desenho for esse, é um arquivo de pesos.

Isso abre um cenário concreto. Uma rede de hospitais, ou um consórcio de hospitais universitários, poderia treinar um modelo pra uma tarefa específica sobre nota clínica em português sem montar um data lake compartilhado. Cada um com sua GPU, cada um no seu perímetro.

Mas tem três cuidados que eu não pularia.

O adapter não é neutro

Pesos treinados com dado de paciente podem memorizar trechos desse dado. Isso vale pra modelo inteiro e vale pra adapter. Então o arquivo que viaja precisa ser tratado como artefato sensível: contrato entre as instituições, controle de quem recebe, registro de cada passagem. “O dado não saiu” é verdade. “Nada derivado do dado saiu” não é.

Anonimizar antes de treinar continua valendo

Se a nota vai entrar no treino, tirar nome, CPF e afins antes reduz o que o adapter consegue decorar. Já mostrei aqui que detector padrão falha com documento brasileiro, então essa etapa precisa ser testada com dado nacional, não só ligada.

Português clínico é outro bicho

O estudo usou sumários de alta em inglês, de hospitais americanos. Abreviação de prontuário brasileiro, evolução de enfermagem escrita às pressas, CID misturado com texto livre: nada disso foi testado. O método pode funcionar. O número não se transfere.

Como fica em código

O código do MEDAL não está no resumo e não achei repositório público. O padrão de passar um adapter LoRA adiante pra continuar o treino, porém, é o da biblioteca PEFT da Hugging Face. No hospital A:

from transformers import AutoModelForCausalLM
from peft import LoraConfig, TaskType, get_peft_model

model = AutoModelForCausalLM.from_pretrained("meta-llama/Llama-3.1-8B")
peft_config = LoraConfig(r=16, lora_alpha=32, task_type=TaskType.CAUSAL_LM)
model = get_peft_model(model, peft_config)
model.print_trainable_parameters()

# treina com os dados do hospital A (ex.: transformers Trainer)
model.save_pretrained("adapter-hospital-a")

No hospital B, que recebe só a pasta do adapter:

from transformers import AutoModelForCausalLM
from peft import PeftModel

base = AutoModelForCausalLM.from_pretrained("meta-llama/Llama-3.1-8B")
model = PeftModel.from_pretrained(base, "adapter-hospital-a", is_trainable=True)

# continua o treino com os dados do hospital B
model.save_pretrained("adapter-hospital-b")

O is_trainable=True é o detalhe que importa. Sem ele o adapter carrega em modo de inferência e não aprende nada no segundo site. Os valores de r e lora_alpha acima são os do exemplo do README do PEFT, não os do paper. O uso de is_trainable está na documentação de configuração de modelos PEFT.

Limites do estudo

  • Poucas instituições reais. Três bases, duas instituições físicas. Os 10 centros do teste de escala são pedaços do mesmo MIMIC-IV, com a mesma origem, o mesmo jeito de escrever e o mesmo perfil de paciente. Hospitais de verdade diferem muito mais entre si.
  • Duas tarefas, ambas de classificação. Sepse e óbito na internação. Nada de gerar texto, resumir ou responder pergunta.
  • “Identificar”, não “prever”. As tarefas rodam sobre o sumário de alta, escrito no fim da internação. Achar óbito num documento que muitas vezes registra o óbito é bem diferente de prever risco na admissão. Só o texto completo responde como os autores trataram isso.
  • Comparação com o GPT-5. Modelo ajustado na tarefa contra modelo de uso geral. O resumo não diz como o GPT-5 foi instruído (zero-shot, poucos exemplos, prompt elaborado). Isso pode mudar bastante a diferença.
  • Ordem do revezamento. Em treino sequencial, a ordem dos sites pode influenciar o resultado. O resumo não diz se testaram ordens diferentes.
  • Infraestrutura. Cada participante precisa de GPU capaz de ajustar um 8B. Hospital público pequeno no Brasil não tem isso parado no rack.

Quando não usar

  • Quando um hospital só tem dado suficiente pra tarefa. Aí treina local e pronto, sem coordenação entre instituições.
  • Quando a tarefa se resolve com regra ou com um classificador clássico sobre dado estruturado. LLM de 8B pra achar óbito que já está num campo do prontuário é desperdício.
  • Quando não existe acordo jurídico pra o adapter circular. Sem contrato, o arquivo de pesos vira o novo problema.
  • Quando ninguém consegue avaliar o modelo final com dado local de cada site. Média boa pode esconder um hospital onde o modelo vai mal.

Fonte e como reproduzir

Não rodei o treino. Os dados da UCSF não são públicos e o MIMIC-IV exige credenciamento. O que dá pra reproduzir hoje é o padrão de revezamento do adapter, com dado sintético, usando o código acima.

In English

MEDAL (J Biomed Inform, 2026) fine-tuned a LLaMA 3.1 8B adapter sequentially across MIMIC-IV and two UCSF ICU cohorts without moving patient data, approaching pooled-data F1 and beating frontier models such as GPT-5 by up to 16.6 percentage points on sepsis and in-hospital mortality identification. Small scale, two tasks, English notes. I read the abstract; I could not open the full text.

Última revisão em 07/10/2026.

Gostou? O próximo teste sai primeiro no LinkedIn e no Instagram.

Se você põe dado pessoal brasileiro em IA no trabalho e tem uma dúvida, me escreve. O que der pra responder em público vira artigo aqui.