Resumen Técnico: Evaluación de LLM Locales para la Conversión de Lenguaje Natural a SQL en la Fabricación Biofarmacéutica

Declaración del Problema

La fabricación biofarmacéutica opera bajo marcos regulatorios estrictos (FDA 21 CFR Parte 11, EU GMP, Ley de IA de la UE) que imponen requisitos de residencia y soberanía de datos, lo que crea barreras significativas para la adopción de servicios de IA basados en la nube. Si bien los modelos de lenguaje extensos (LLM) desplegados localmente ofrecen una alternativa que preserva la privacidad para la generación de Lenguaje Natural a SQL (NLQ-to-SQL), existe una falta de evidencia empírica sobre su viabilidad y rendimiento en hardware de consumo dentro de este dominio específico. Los benchmarks existentes (por ejemplo, Spider, BIRD, BiomedSQL) se centran en conjuntos de datos de propósito general o razonamiento científico sobre datos genómicos, fallando al no abordar los vocabularios de columnas específicos, los patrones de consulta y los contextos regulatorios de los Sistemas de Ejecución de Manufactura (MES) y los registros de lote. Además, no está claro si el preentrenamiento biomédico específico de un dominio proporciona una ventaja sobre los modelos de propósito general o ajustados para código para la generación de T-SQL estructurado.

Metodología

El estudio evaluó cuatro LLM de código abierto de 7B–8B parámetros desplegados localmente mediante el motor de inferencia Ollama en hardware de consumo (Intel Core i7-9750H, 32GB RAM, NVIDIA GTX 1650 4GB VRAM). Los modelos evaluados fueron:

• Qwen 2.5 Coder 7B: Centrado en código, fuertemente entrenado en programación y SQL.
• Llama 3.1 8B: De propósito general con ajuste de instrucciones y una amplia ventana de contexto.
• Mistral 7B: De propósito general con atención de ventana deslizante.
• Meditron 7B: Variante de Llama 2 ajustada médicamente (preentrenada en PubMed/guías clínicas).

Configuración Experimental:

• Conjunto de Datos: Una base de datos sintética de MS SQL Server llamada PharmaBatchDB que contiene aproximadamente 63,000 filas en siete tablas que abarcan tres módulos: Lote (Batch), MES y Limpieza en el Sitio (CIP).
• Conjunto de Evaluación: 60 pares de pregunta-referencia de NLQ-a-T-SQL específicos del dominio, estratificados por módulo (20 por módulo) y dificultad (18 fáciles, 24 medias, 18 difíciles).
• Arquitectura del Sistema: Un pipeline local (PharmaBatchDB AI) construido con FastAPI. Este impone un usuario de base de datos de solo lectura, valida el SQL mediante la inspección del AST de sqlglot (bloqueando sentencias que no sean SELECT y tablas fuera de alcance) y mantiene registros de auditoría de solo anexión.
• Prompting: Estrategia zero-shot con un prompt de sistema que contiene las reglas de sintaxis T-SQL y el esquema completo del módulo activo. La temperatura se estableció en 0.1 para un output casi determinista.
• Métricas:
  • Tasa de Extracción de SQL: Proporción de preguntas que producen SQL extraíble.
  • Tasa de Cumplimiento de SQL: Proporción de SQL extraído que es válido, exclusivamente SELECT y dentro del alcance del módulo.
  • Consistencia Factual (FC): Similitud de Jaccard entre los conjuntos de resultados de las consultas generadas frente a las de referencia (métrica de calidad primaria).
  • ROUGE-L: Similitud léxica con las consultas de referencia (métrica secundaria).
  • Tasa de Alucinación: Proporción de SQL extraído que falla en el cumplimiento.
  • Rendimiento: Tokens Por Segundo (TPS) y Tiempo hasta el Primer Token (TTFT).

Se realizó un experimento de seguimiento en Meditron 7B utilizando un prompt de esquema truncado (<1,000 tokens) para aislar las limitaciones de la ventana de contexto de las deficiencias de capacidad de generación.

Resultados Clave

1. Niveles de Rendimiento de los Modelos

• Mejores Desempeños: Qwen 2.5 Coder 7B y Llama 3.1 8B alcanzaron un 100% de Tasas de Extracción de SQL.
  • Llama 3.1 8B mostró el mayor Cumplimiento de SQL con un 93.33% (56/60) y una Tasa de Alucinación del 6.67%.
  • Qwen 2.5 Coder 7B logró un 88.33% de Cumplimiento (53/60) con una Tasa de Alucinación del 11.67%.
  • Nota Estadística: La diferencia del 5% en el cumplimiento entre Llama y Qwen no fue estadísticamente significativa (p de la prueba exacta de Fisher = 0.529). Ambos modelos superaron significativamente a Mistral y Meditron.
• Nivel Medio: Mistral 7B logró un 100% de extracción pero solo un 25.00% de Cumplimiento (15/60). Demostró una alta sensibilidad a la complejidad del esquema, con el cumplimiento cayendo del 40% en el módulo simple de Batch al 15% en el complejo módulo MES.
• Nivel Inferior: Meditron 7B logró un 0.00% de Cumplimiento de SQL en todas las 60 preguntas en la condición estándar. Solo extrajo SQL de 1/60 preguntas debido al desbordamiento de la ventana de contexto (límite de 2,048 tokens).

2. Impacto de la Ventana de Contexto y el Entrenamiento de Dominio

El experimento de seguimiento de Meditron 7B (esquema truncado) reveló que, si bien reducir el tamaño del prompt permitió extraer SQL de 28/30 preguntas (frente a 1/30), todas las 28 consultas extraídas fallaron la validación de cumplimiento (tasa de alucinación del 100%). Esto indica que el fallo no se debió únicamente al desbordamiento del contexto; el modelo carecía de la capacidad inherente para generar T-SQL válido para esquemas de manufactura, lo que sugiere que el preentrenamiento biomédico sobre la base de Llama 2 no transfirió habilidades de generación de SQL y pudo haberlas diluido.

3. Dificultad y Sensibilidad del Módulo

• Llama 3.1 8B mantuvo un cumplimiento constante a través de los niveles de dificultad (94.4% en Difícil, 91.7% en Medio).
• Qwen 2.5 Coder 7B mostró una caída notable en el rendimiento en preguntas de dificultad media (83.3% de cumplimiento), las cuales involucraban agregaciones multitabla y filtrado condicional.
• El rendimiento de Mistral 7B se degradó monótonamente con la dificultad, cayendo al 5.56% de cumplimiento en preguntas difíciles.

4. Métricas de Rendimiento

• Consistencia Factual: Qwen (0.34) superó ligeramente a Llama (0.30), aunque ambos puntajes son modestos, lo que indica que incluso las consultas que cumplen suelen recuperar conjuntos de resultados parciales o ligeramente incorrectos.
• Latencia: En hardware de CPU de consumo, el TPS osciló entre 3.2 y 4.4 tokens/segundo, con un TTFT de alrededor de 11 segundos. Esto es suficiente para flujos de trabajo analíticos pero no para tableros interactivos.

Contribuciones Clave

1. Benchmark Específico de Dominio: Introducción de PharmaBatchDB AI, un benchmark sintético diseñado específicamente para tareas de NLQ-a-SQL de fabricación farmacéutica, abordando un vacío en la literatura existente.
2. Evidencia Empírica de Despliegue Local: Demostración de que un pipeline de NLQ totalmente local y alineado con GxP (con registro de auditoría, acceso de solo lectura y validación AST) es factible en hardware de consumo.
3. Perspectivas de Selección de Modelos: Evidencia de que los modelos de propósito general ajustados para código (Qwen, Llama) superan sustancialmente a los modelos biomédicos de dominio (Meditron) en tareas de T-SQL estructurado en este contexto, principalmente debido a la capacidad de la ventana de contexto y las capacidades del modelo base, más que al preentrenamiento de dominio.
4. Marco de Alineación Regulatoria: Un mapeo de las características del sistema con requisitos regulatorios específicos (FDA 21 CFR Parte 11, Ley de IA de la UE), proporcionando un plano para el despliegue local de IA conforme a la normativa.

Significado y Reivindicaciones

El artículo sostiene que, si bien los LLM de 7B–8B locales pueden servir como herramientas de redacción de consultas dentro de un entorno regulado, no están listos para la toma de decisiones operativas no supervisadas. Los modestos puntajes de Consistencia Factual (0.30–0.34) hacen necesaria la revisión humana y una capa de validación descendente para cualquier uso relevante de GxP.

El estudio concluye que:

• El preentrenamiento biomédico no es un sustituto de la capacidad de SQL: El fallo de Meditron 7B resalta que el ajuste fino de dominio en arquitecturas antiguas (Llama 2) sin ventanas de contexto adecuadas puede resultar en una pérdida de habilidades de generación estructurada.
• Los modelos generalistas son candidatos viables: Llama 3.1 8B y Qwen 2.5 Coder 7B son candidatos plausibles para el despliegue, siendo Llama un modelo que muestra una tasa de cumplimiento numéricamente (aunque no estadísticamente) superior, lo que lo convierte en una opción por defecto de menor riesgo en ausencia de capas de validación robustas.
• Los datos sintéticos son una herramienta válida de pre-certificación: El benchmark sintético permite la validación técnica y la recopilación de evidencia para presentaciones regulatorias antes de tocar datos de producción, reduciendo las barras de adopción.

Los autores enfatizan que el ranking detallado entre Llama y Qwen permanece estadísticamente sin resolver con la muestra actual (n=60) y que el trabajo futuro debe validar estos hallazgos contra esquemas de producción del mundo real y consultas de referencia de múltiples autores.