AWS muestra cómo abaratar el text-to-SQL con Amazon Nova Micro y Bedrock

AWS ha mostrado cómo obtener text-to-SQL para bases de datos internas sin pagar el alojamiento permanente y costoso de un modelo. La compañía ajustó Amazon Nova Micro para dialectos SQL no estándar y lo desplegó en Amazon Bedrock, pagando solo por las solicitudes reales.

Por qué importa

En escenarios corporativos, un modelo genérico a menudo se queda corto: escribe bastante bien SQL estándar, pero empieza a fallar cuando la empresa tiene convenciones propias, funciones poco comunes, esquemas de tablas particulares y reglas de dominio. Por eso la consulta en texto del usuario debe adaptarse a un dialecto y una estructura de base de datos concretos, lo que obliga a reentrenar el modelo con ejemplos propios. Se nota sobre todo en sistemas de BI y chats analíticos internos, donde un error de sintaxis rompe de inmediato todo el flujo.

El problema es que el ajuste fino suele arrastrar costes permanentes de infraestructura. Si el modelo personalizado se mantiene en servidores dedicados, la empresa paga incluso cuando no hay consultas. En su análisis, AWS propone otra opción: ajustar Amazon Nova Micro con LoRA y ejecutarlo en Amazon Bedrock en modo de inferencia on-demand, donde se factura por tokens y no por capacidad reservada de forma permanente.

Los dos enfoques de AWS

AWS describe dos escenarios para la misma tarea.

El primero es el ajuste fino gestionado dentro de Amazon Bedrock. Es adecuado para equipos que priorizan la sencillez, un arranque rápido y el mínimo esfuerzo con infraestructura de ML. Los datos se suben a S3, el trabajo de fine-tuning se lanza desde la consola o la API, y después AWS gestiona el entrenamiento y el posterior despliegue de la versión personalizada de Nova Micro. Esta opción está pensada más para un equipo de aplicaciones que para una plataforma de ML dedicada.

La segunda vía es el entrenamiento con Amazon SageMaker AI. Es más compleja, pero ofrece más control sobre la receta de entrenamiento: se pueden cambiar el tamaño de lote, el dropout, los parámetros del optimizador, la ventana de contexto, los ajustes de LoRA y la estrategia de calentamiento del learning rate. En el ejemplo, AWS usó el conjunto de datos sql-create-context, creado a partir de WikiSQL y Spider, y convirtió los pares pregunta-SQL al formato bedrock-conversation-2024 para el entrenamiento y la validación. El precio es una configuración más compleja y un trabajo más explícito con la infraestructura.

Así se diferencian las opciones en la práctica:

• Bedrock: menos carga operativa y un camino más rápido hacia un prototipo funcional
• SageMaker AI: más control sobre los hiperparámetros y la integración en MLOps
• Ambos esquemas usan el mismo pipeline de preparación de datos y luego se despliegan en Bedrock
• La inferencia final se ejecuta en un modelo sin servidor con pago por tokens, sin alojamiento permanente

Precio y latencia

AWS aporta cifras concretas. En el ajuste gestionado de Bedrock, el coste de entrenamiento se calcula a 0,001 $ por 1000 tokens y época: en el ejemplo con 2000 muestras, cinco épocas y unos 800 tokens por registro, salieron unos 8 $. En la variante con SageMaker se usó una instancia ml.g5.48xlarge a 16,288 $ por hora; el entrenamiento con un conjunto de 20 000 filas tardó unas cuatro horas y costó aproximadamente 65,15 $.

La tesis clave del artículo no es el precio puntual del entrenamiento, sino el coste de operación. AWS estimó una carga de producción de ejemplo de 22 000 solicitudes al mes, es decir, 100 usuarios con 10 consultas al día durante 22 días laborables. Con un tamaño medio de 800 tokens de entrada y 60 de salida, la inferencia mensual de ese modelo text-to-SQL personalizado fue de 0,80 $. Es posible porque Nova Micro personalizado en Bedrock se tarifica igual que el modelo base, sin recargo adicional por el despliegue sin servidor.

En velocidad hay una contrapartida, pero moderada. En un arranque en frío, el tiempo medio hasta el primer token subió a 639 ms, un 34 % más que el modelo base. En funcionamiento normal, el TTFT medio fue de 380 ms en 50 llamadas, solo un 7 % peor que la base. La latencia total de generación rondó los 477 ms, y la velocidad de salida se mantuvo en 183 tokens por segundo. AWS evaluó la calidad no solo por latencia, sino también con LLM-as-a-Judge, comparando el SQL generado con respuestas de referencia.

Qué significa

Para los equipos que quieren integrar text-to-SQL en productos analíticos, herramientas internas de BI o interfaces de chat para bases de datos, el caso de AWS resulta práctico: se puede tener un generador de SQL personalizado sin costes permanentes de infraestructura dedicada. Si importa más la rapidez de puesta en marcha, lo lógico es mirar hacia Bedrock; si se necesita control total sobre el entrenamiento, la combinación con SageMaker AI parece más sólida.