Resumen Técnico: MAM-AI

1. Planteamiento del Problema

La mortalidad materna y neonatal sigue siendo críticamente alta en el África subsahariana, particularmente en Zanzíbar, donde la atención de partería suele ser brindada por enfermeras que carecen de una formación con estándares internacionales. Una barrera principal para una atención segura es la escasez de orientación autorizada y basada en evidencia en el punto de atención. Las guías existentes son extensas, y la dependencia de búsquedas en línea es poco fiable debido a la conectividad intermitente y los altos costos de datos. El desafío consiste en proporcionar un asistente de preguntas y respuestas médicas que sea totalmente offline, que se ejecute en hardware Android convencional, garantice la privacidad de los datos del paciente (que las consultas no salgan del dispositivo) y mantenga rigurosos estándares de seguridad.

2. Diseño del Sistema y Metodología

MAM-AI es un sistema de Generación Aumentada por Recuperación (RAG) diseñado para ejecutarse enteramente en el dispositivo. El flujo de trabajo consta de cuatro etapas:

1. Embedding: La pregunta clínica de un usuario se convierte en un embedding utilizando EmbeddingGemma-300M (768 dimensiones, cuantizado).
2. Recuperación (Retrieval): El embedding se coteja contra un almacén vectorial local SQLite que contiene 63,650 pasajes derivados de 87 documentos de guías clínicas curadas (OMS, NICE, ICM, estándares nacionales, etc.). Se seleccionan los 3 pasajes principales.
3. Aumentación: Los pasajes recuperados se inyectan en el prompt junto con la consulta.
4. Generación: Un modelo Gemma 4 E4B en el dispositivo (3.66 GB, cuantizado en int4) genera una respuesta transmitida (streamed) con citas en línea a los pasajes de origen.

Restricciones y Configuraciones Clave:

• Operación Offline: No se requiere conexión a Internet después de la configuración inicial de un solo uso (descarga del modelo y el corpus).
• La Seguridad es lo Primero: El sistema está definido explícitamente como un "prototipo de investigación exhaustivamente evaluado", no como un producto implementado en campo.
• Ingeniería de Prompts: Se desarrolló un prompt de sistema rediseñado (G1) para abordar la deflexión del modelo (negativa a responder), obligando al modelo a proporcionar el manejo de primera línea antes de sugerir derivaciones.
• Marco de Evaluación: Los autores emplean una metodología de base ascendente por capas que evalúa el sistema de extremo a extremo, el recuperador por sí solo, el generador por sí solo (bajo contexto de oráculo) y la latencia. La evaluación se realiza utilizando un juez de LLM validado (gpt-oss-120b) calibrado mediante rúbricas escritas por médicos.

3. Contribuciones Clave

• RAG Desplegable en el Dispositivo: Un asistente médico totalmente offline que se ejecuta en hardware Android convencional, utilizando modelos de código abierto (Gemma) y una base de conocimientos curada.
• Evaluación por Capas: Una suite de evaluación integral (extremo a extremo, recuperador, generador, latencia) aplicada a la configuración exacta desplegada, revelando que el "problema difícil" se ha desplazado de la recuperación al anclaje (grounding) de la generación.
• Selección de Modelo Basada en la Seguridad: Una demostración de que, en entornos de recursos limitados y de seguridad crítica, la fidelidad a las fuentes es un criterio de selección más importante que la capacidad bruta. Los autores eligieron un modelo menos "útil" pero más fiel (Gemma 4) en lugar de uno más capaz pero propenso a errores (Gemma 3n).
• Lanzamiento de Código Abierto: El sistema, el pipeline de la base de conocimientos, los benchmarks (mamabench, mamaretrieval) y el armazón de evaluación se liberan como código abierto.

4. Resultados Clave y Hallazgos

A. El Prompt es un Palanca Principal

El modelo base Gemma 4 deflectó en aproximadamente el 33% de las preguntas (respondiendo "consulte a un médico"). El prompt G1 rediseñado redujo la deflexión a aproximadamente el 3% y duplicó la recuperación de hechos clave, con un aumento insignificante en las respuestas inseguras. Este fue el mayor avance de extremo a extremo observado.

B. La Recuperación en el Dispositivo está Resuelta

El recuperador EmbeddingGemma-300M se desempeña competitivamente con sistemas en la nube, ocupando el tercer lugar de siete recuperadores probados y rivalizando con los mejores embedders en la nube.

• Hallazgo: Mejorar la recuperación (por ejemplo, cambiar Gecko por EmbeddingGemma o añadir un reordenador/reranker) no mejora la calidad de la respuesta de extremo a extremo en el pequeño generador. De hecho, añadir contexto recuperado a un generador pequeño suele ser neto-neutral o ligeramente negativo.
• Razón: El pequeño generador no logra utilizar el contexto recuperado de manera efectiva. La "ruptura" en el pipeline ocurre aguas abajo, en la capacidad del generador para anclarse (grounding) en la información, no en la recuperación de la misma.

C. Capacidad del Generador vs. Fidelidad

• Capacidad: La calidad aumenta drásticamente con el tamaño del modelo (hasta ~30B), donde un modelo de servidor de 30B supera significamente al modelo de 4B en el dispositivo. Sin embargo, el de 4B es el límite para el despliegue en el dispositivo.
• Compromiso de Seguridad: Entre dos candidatos del mismo tamaño (Gemma 4 vs. Gemma 3n), Gemma 3n era más útil (mayor recuperación) pero producía significativamente más errores peligrosos (consejos de dosificación y contraindicaciones específicos, pero erróneos y con apariencia de certeza). Gemma 4 fue aproximadamente el doble de fiel a sus fuentes y produjo efectivamente cero respuestas peligrosas genuinas.
• Decisión: El sistema despliega Gemma 4 (el modelo fiel) y recupera la utilidad mediante ingeniería de prompts, en lugar de desplegar el más capaz pero inseguro Gemma 3n.

D. La Calidad del Corpus es Decisiva

Debido a que el modelo pequeño depende fuertemente del contexto recuperado, la calidad del corpus es primordial.

• Si el corpus contiene el pasaje específico y accionable, la respuesta es específica y segura.
• Si el corpus recupera solo definiciones o ejercicios de estudio (debido a la formulación de la consulta), la respuesta se vuelve vaga.
• Cobertura: El corpus cubre aproximadamente el 96.5% de las consultas con un umbral permisivo, pero un ~10.6% de las consultas carece de un fragmento relevante en su totalidad, lo que representa un techo duro para las soluciones basadas únicamente en recuperación.

E. Latencia y Hardware

• Rendimiento: En un dispositivo de gama alta (Snapdragon 8 Elite), el sistema devuelve una respuesta en una mediana de ~43s en CPU y ~19s en GPU (opcional).
• Restricciones: El factor limitante es la memoria (RAM), no la velocidad. El sistema requiere ~6GB de RAM para el modelo de 4B.
• Error de Precisión: Ocurre un colapso de atención FP16 determinista en backends de GPU más allá de ~5,000 tokens de contexto, lo que requiere un límite de 4,096 tokens para la ruta de GPU.

5. Significado y Reivindicaciones

El artículo afirma que MAM-AI demuestra que un asistente médico totalmente offline y con citas de fuentes es factible en hardware convencional. Su principal significancia radica en reubicar el problema difícil:

1. La recuperación no es el cuello de botella: El embedding en el dispositivo es suficiente para encontrar los pasajes relevantes.
2. El anclaje (grounding) es el cuello de botella: La incapacidad del pequeño generador para utilizar eficazmente el contexto recuperado es el factor limitante.
3. Fidelidad sobre Capacidad: En contextos médicos de seguridad, elegir un modelo basado en su fidelidad a las fuentes (aunque sea menos capaz) es superior a elegir un modelo más capaz que alucina.

Los autores enfatizan que MAM-AI es un prototipo de investigación, no un producto clínico. Declaran explícitamente que no se han realizado pruebas de campo con enfermeras reales, y que todas las métricas de seguridad/calidad se derivan de jueces de LLM y benchmarks. El camino hacia el despliegue requiere más trabajo en el anclaje del generador (fine-tuning), expansión del corpus, reescritura de consultas y soporte para el idioma suajili.