Resumo Técnico: HealthCraft

Declaração do Problema

Modelos de linguagem de grande escala (LLMs) de fronteira estão sendo implantados em fluxos de trabalho clínicos mais rapidamente do que a infraestrutura existente para avaliá-los com segurança. Benchmarks médicos estáticos de QA existentes falham em capturar modos de falha críticos específicos da medicina de emergência: colapso de segurança em nível de trajetória, uso indevido de ferramentas contra registros de pacientes e capitulação sob pressão clínica sustentada. Benchmarks estáticos medem o recall de texto de diretrizes, mas não podem detectar se um modelo recomendará cuidados domiciliares após identificar corretamente a necessidade de transferência de emergência, ou se emitirá uma ordem letal (por exemplo, anticoagulantes para uma suspeita de dissecção aórtica) ao interagir com um sistema de dados clínicos.

Metodologia

HealthCraft é um ambiente público de aprendizado por reforço (RL) adaptado da arquitetura Corecraft, especificamente projetado para medicina de emergência. Opera como um sistema empacotado em Docker, compreendendo três serviços: um armazenamento de estado mundial PostgreSQL, um servidor de ferramentas FastMCP e um motor de tarefas.

Design do Ambiente

• Estado Mundial: O ambiente é fundamentado em um esquema FHIR R4 populado com 3.987 entidades de semente em 14 tipos (por exemplo, pacientes, atendimentos, condições, medicamentos). O estado é determinístico (seed=42) e derivado do corpus de conhecimento clínico OpenEM, garantindo análogos diretos a integrações clínicas reais.
• Espaço de Ações: Agentes interagem por meio de 24 ferramentas MCP organizadas em quatro ondas: busca/obtenção somente leitura, computação, mutação (por exemplo, criação de ordens, atualização de registros) e fluxos de trabalho compostos (alta, transferência). Chamadas de ferramentas são determinísticas e registradas em um log de auditoria apenas de adição.
• Injeção de Ruído: Para simular problemas realistas de dados clínicos, o ambiente injeta ruído estruturado, incluindo limites de paginação, dessincronização de relógio, registros incompletos, dados desatualizados, documentação ambígua e achados de isca vermelha.

Função de Recompensa e Rubrica

A inovação central é uma rubrica de duas camadas com um portão de segurança rígido.

• Critérios: O benchmark utiliza 2.255 critérios binários por tarefa, dos quais 515 são críticos para segurança.
• Portão de Segurança Rígido: A função de recompensa (Eq. 1) zera a recompensa se qualquer critério crítico para segurança for violado, independentemente do desempenho em outros critérios. Isso reflete a natureza não negociável da segurança clínica, onde um único erro letal invalida um desempenho competente.
• Verificação: Os critérios são verificados por três métodos:
  1. world_state: Verificações determinísticas contra o log de auditoria (preferido para segurança).
  2. llm_judge: Juízes LLM de diferentes fornecedores (por exemplo, GPT julgando Claude) para análise complexa de trajetória.
  3. pattern: Correspondências de Regex para verificações de apresentação.

Suíte de Tarefas

O benchmark público consiste em 195 tarefas (expandidas para 205 com uma lista de classe negativa) em seis categorias:

1. Raciocínio Clínico (desambiguação de condições sobrepostas).
2. Fluxos de Trabalho Multietapa (ações coordenadas entre atendimentos).
3. Comunicação Clínica (alta, consultas).
4. Julgamento Crítico para Segurança (EMTALA, capacidade).
5. Recuperação de Informações.
6. Raciocínio Temporal.

As tarefas são geradas a partir de pares de confusão, regras de decisão e propriedades de avaliação do OpenEM, garantindo rastreabilidade a fontes revisadas por pares em vez de intuição do autor.

Principais Contribuições

1. Primeiro Ambiente RL Público para Medicina de Emergência: Apresenta um estado mundial FHIR-R4 e uma superfície de 24 ferramentas MCP.
2. Recompensa de Portão de Segurança Rígido: Uma função de recompensa que zera o desempenho ao ocorrer qualquer violação crítica de segurança, operacionalizando MDPs restritos para segurança clínica.
3. Benchmark Rastreável: Uma suíte de 195 tarefas avaliadas contra 2.255 critérios binários, fundamentada em fontes clínicas OpenEM.
4. Avaliação Transparente: Um relato detalhado de seis bugs de infraestrutura corrigidos entre as versões piloto (v2 a v8) que alteraram significativamente as classificações dos modelos, demonstrando que a fidelidade da infraestrutura é parte da medição.
5. Sobreposição de Auditoria: Uma sobreposição de auditoria determinística com juiz LLM que quantifica o ruído do avaliador, encontrando que 73% das discordâncias dos juízes decorrem de alucinações e não de falhas na sobreposição.

Resultados (Lançamento V8)

Avaliado em dois modelos de fronteira (Claude Opus 4.6 e GPT-5.4) em 195 tarefas com 3 tentativas cada:

• Desempenho Geral:
  • Claude Opus 4.6: Pass@1 de 24,8% (Taxa de falha de segurança: 27,5%).
  • GPT-5.4: Pass@1 de 12,6% (Taxa de falha de segurança: 34,0%).
• Colapso de Fluxo de Trabalho Multietapa: O desempenho em fluxos de trabalho complexos e multietapa colapsou para próximo de zero (Claude: 1,0%, GPT-5.4: 0,0%). Embora os agentes frequentemente satisfizessem critérios não relacionados à segurança, um único deslize crítico de segurança no fluxo de trabalho (por exemplo, omitir uma verificação de transferência) zerava a recompensa.
• Impacto da Infraestrutura: Correções de seis bugs de infraestrutura entre v7 e v8 causaram uma reordenação qualitativa do desempenho dos modelos. A recompensa média do GPT-5.4 aumentou em ~107% em relação à v7, enquanto a do Claude caiu ~13%, destacando que benchmarks de uso de ferramentas são altamente sensíveis à fidelidade do esquema e da avaliação.
• Lista de Classe Negativa: Uma lista de classe negativa de 10 tarefas post-hoc (focada em contenção) revelou que os critérios de contenção são satisfeitos com alta prevalência (0,929) em pilotos de fumaça, sugerindo que o uso do sinal de recompensa atual para treinamento poderia levar ao casamento de padrões de ações específicas excessivas em vez de julgamento clínico generalizado.

Significado e Alegações

O artigo posiciona o HealthCraft não como uma ferramenta para aprovação de implantação imediata, mas como uma alavanca de avaliação honesta que torna os modos de falha visíveis.

• Medição da Realidade: O ambiente demonstra que os modelos de fronteira atuais não estão prontos para implantação autônoma em cuidados de emergência; eles falham em uma em quatro (Claude) ou uma em oito (GPT) tarefas em Pass@1, com violações de segurança ocorrendo em aproximadamente uma em três tentativas.
• Fidelidade da Infraestrutura: Os autores argumentam que, para benchmarks de uso de ferramentas, a fidelidade da infraestrutura não é um eixo separado da avaliação do modelo, mas parte integrante do que está sendo medido. A reordenação dos modelos devido a correções de bugs serve como evidência de que classificações de modelos "mais fortes" podem ser artefatos de imperfeições da alavanca.
• Limite entre Treinamento e Avaliação: O artigo afirma explicitamente que o sinal de recompensa atual (Eq. 1) não é seguro para treinamento direto. A alta prevalência de critérios de contenção satisfeitos em tarefas de classe negativa sugere que o treinamento com este sinal sem ablação poderia levar à exploração de recompensas.
• Ciência Aberta: Todos os componentes (ambiente, tarefas, rubricas, alavanca) são lançados sob a licença Apache 2.0 para incentivar a comunidade a quebrar o ambiente, expandir a suíte de tarefas e relatar resultados.

Os autores concluem que a função do HealthCraft é fornecer intervalos de confiança e taxas de falha visíveis para que as conversas sobre implantação sejam honestas, em vez de fornecer métricas triunfantes para integração clínica imediata.