Resumo Técnico: MAM-AI

1. Declaração do Problema

A mortalidade materna e neonatal permanece criticamente alta na África subsaariana, particularmente em Zanzibar, onde o cuidado de obstetrícia é frequentemente prestado por enfermeiros que carecem de treinamento nos padrões internacionais. Uma barreira primária ao cuidado seguro é a escassez de orientação autoritativa e baseada em evidências no ponto de atendimento. As diretrizes existentes são extensas, e a dependência de buscas online é pouco confiável devido à conectividade intermitente e aos altos custos de dados. O desafio é fornecer um assistente de perguntas e respostas médicas que seja totalmente offline, execute em hardware Android comum, garanta a privacidade dos dados do paciente (nenhuma consulta sai do dispositivo) e mantenha padrões rigorosos de segurança.

2. Design do Sistema e Metodologia

MAM-AI é um sistema de Geração Aumentada por Recuperação (RAG) projetado para rodar inteiramente no dispositivo. O pipeline consiste em quatro estágios:

1. Embedding: A pergunta clínica de um usuário é transformada em embedding usando o EmbeddingGemma-300M (768 dimensões, quantizado).
2. Recuperação (Retrieval): O embedding é correspondido contra um repositório vetorial SQLite local contendo 63.650 passagens derivadas de 87 documentos de diretrizes clínicas curadas (OMS, NICE, ICM, padrões nacionais, etc.). As 3 principais passagens são selecionadas.
3. Aumentação (Augmentation): As passagens recuperadas são injetadas no prompt junto com a consulta.
4. Geração: Um modelo Gemma 4 E4B no dispositivo (3,66 GB, quantizado em int4) gera uma resposta transmitida (streamed) com citações inline das passagens de origem.

Principais Restrições e Configurações:

• Operação Offline: Nenhuma conexão com a internet é necessária após a configuração inicial única (download do modelo e do corpus).
• Segurança em Primeiro Lugar: O sistema é explicitamente definido como um "protótipo de pesquisa Thoroughly Evaluated" (rigorosamente avaliado), não um produto implementado em campo.
• Engenharia de Prompt: Um prompt de sistema redesenhado (G1) foi desenvolvido para abordar a deflexão do modelo (recusa em responder), forçando o modelo a fornecer o manejo de primeira linha antes de sugerir encaminhamentos.
• Estrutura de Avaliação: Os autores empregam uma metodologia de base ascendente (bottom-up) em camadas, avaliando o sistema de ponta a ponta, o recuperador isoladamente, o gerador isoladamente (sob contexto oracle) e a latência. A avaliação é conduzida usando um juiz de LLM validado (gpt-oss-120b) calibrado contra rubricas escritas por médicos.

3. Principais Contribuições

• RAG Implementável no Dispositivo: Um assistente médico totalmente offline rodando em hardware Android comum, utilizando modelos de código aberto (Gemma) e uma base de conhecimento curada.
• Avaliação em Camadas: Uma suíte de avaliação abrangente (ponta a ponta, recuperador, gerador, latência) aplicada à configuração exata implantada, revelando que o "problema difícil" mudou da recuperação para o ancoramento (grounding) do gerador.
• Seleção de Modelo Orientada pela Segurança: Uma demonstração de que, em contextos de baixa escala e alta criticidade de segurança, a fidelidade às fontes é um critério de seleção mais crítico do que a capacidade bruta. Os autores escolheram um modelo menos "útil", mas mais fiel (Gemma 4), em vez de um mais capaz, porém propenso a erros (Gemma 3n).
• Lançamento Open-Source: O sistema, o pipeline da base de conhecimento, os benchmarks (mamabench, mamaretrieval) e a estrutura de avaliação são lançados como código aberto.

4. Principais Resultados e Descobertas

A. O Prompt é uma Alavanca Importante

O modelo base Gemma 4 apresentou deflexão em cerca de 33% das perguntas (respondendo "consulte um médico"). O prompt G1 redesenhado reduziu a deflexão para cerca de 3% e dobrou a recall de fatos-chave, com um aumento negligenciável em respostas inseguras. Esta foi a maior ganho de ponta a ponta observado.

B. A Recuperação no Dispositivo está Resolvida

O recuperador EmbeddingGemma-300M performa de forma competitiva com sistemas em nuvem, ocupando o terceiro lugar entre sete recuperadores testados e rivalizando com os melhores embedders de nuvem.

• Descoberta: Melhorar a recuperação (ex: trocar Gecko por EmbeddingGemma ou adicionar um reranker) não melhora a qualidade da resposta de ponta a ponta no gerador pequeno. Na verdade, adicionar contexto recuperado a um gerador pequeno é frequentemente neutro ou levemente negativo.
• Razão: O gerador pequeno falha em utilizar o contexto recuperado de forma eficaz. O "rompimento" no pipeline ocorre downstream, na capacidade do gerador de ancorar suas respostas, e não na recuperação da informação.

C. Capacidade do Gerador vs. Fidelidade

• Capacidade: A qualidade aumenta acentuadamente com o tamanho do modelo (até ~30B), onde um modelo de servidor de 30B supera significamente o modelo de 4B do dispositivo. No entanto, o modelo de 4B é o limite para implantação no dispositivo.
• Trade-off de Segurança: Entre dois candidatos de mesmo tamanho (Gemma 4 vs. Gemma 3n), o Gemma 3n era mais útil (maior recall), mas produzia significativamente mais erros perigosos (conselhos de dosagem e contraindicações específicos, porém errados e confiantes). O Gemma 4 foi aproximadamente duas vezes mais fiel às suas fontes e produziu efetivamente zero respostas perigosas genuínas.
• Decisão: O sistema implanta o Gemma 4 (o modelo fiel) e recupera a utilidade via engenharia de prompt, em vez de implantar o mais capaz, porém inseguro, Gemma 3n.

D. A Qualidade do Corpus é Decisiva

Como o modelo pequeno depende fortemente do contexto recuperado, a qualidade do corpus é primordial.

• Se o corpus contém a passagem específica e acionável, a resposta é específica e segura.
• Se o corpus recupera apenas definições ou exercícios de estudo (devido à fraseologia da consulta), a resposta torna-se vaga.
• Cobertura: O corpus cobre ~96,5% das consultas em um limiar permissivo, mas ~10,6% das consultas carecem inteiramente de um fragmento relevante, representando um teto rígido para soluções baseadas apenas em recuperação.

E. Latência e Hardware

• Performance: Em um dispositivo topo de linha (Snapdragon 8 Elite), o sistema retorna uma resposta em uma mediana de ~43s na CPU e ~19s na GPU (opcional).
• Restrições: A restrição vinculante é a memória (RAM), não a velocidade. O sistema requer ~6GB de RAM para o modelo de 4B.
• Bug de Precisão: Ocorre um colapso determinístico de atenção FP16 em backends de GPU além de ~5.000 tokens de contexto, necessitando de um limite de 4.096 tokens para o caminho da GPU.

5. Significância e Alegações

O artigo afirma que o MAM-AI demonstra que um assistente médico totalmente offline e com citações de fontes é viável em hardware comum. Sua principal significância reside em relocalizar o problema difícil:

1. A recuperação não é o gargalo: O embedding no dispositivo é suficiente para encontrar passagens relevantes.
2. O ancoramento (grounding) é o gargalo: A incapacidade do gerador pequeno de utilizar efetivamente o contexto recuperado é o fator limitante.
3. Fidelidade sobre Capacidade: Em contextos de segurança médica, escolher um modelo baseado em sua fidelidade às fontes (mesmo que menos capaz) é superior a escolher um modelo mais capaz que alucina.

Os autores enfatizam que o MAM-AI é um protótipo de pesquisa, não um produto clínico. Eles declaram explicitamente que nenhum teste de campo com enfermeiros reais foi realizado, e todas as métricas de segurança/qualidade são derivadas de juízes de LLM e benchmarks. O caminho para a implantação requer trabalho adicional em ancoramento do gerador (ajuste fino), expansão do corpus, reescrita de consultas e suporte ao idioma Suaíli.