AWS mostró cómo abaratar text-to-SQL para empresas con Amazon Nova Micro y Bedrock

AWS mostró cómo obtener text-to-SQL para bases de datos internas sin costosos gastos de hospedaje permanente de modelos. La empresa ajustó Amazon Nova Micro para dialectos SQL no estándar e la implementó a través de Amazon Bedrock con precios de pago por solicitud.

Por qué es importante

Para escenarios corporativos, un modelo estándar a menudo no es suficiente: escribe SQL estándar razonablemente bien, pero comienza a cometer errores cuando una empresa tiene sus propias convenciones, funciones raras, esquemas de tablas especiales y reglas específicas del dominio. Por eso las consultas de texto del usuario necesitan adaptarse al dialecto específico y la estructura de la base de datos, lo que significa ajustar el modelo con tus propios ejemplos. Esto es especialmente notable en sistemas BI y chats analíticos internos, donde un error de sintaxis rompe inmediatamente todo el flujo de trabajo.

El problema es que el ajuste fino generalmente conlleva costos adicionales de infraestructura. Si mantienes un modelo personalizado en servidores dedicados, la empresa paga incluso cuando no hay consultas. AWS sugiere un enfoque diferente en su análisis: ajustar Amazon Nova Micro mediante LoRA e implementarla en Amazon Bedrock en modo de inferencia bajo demanda, donde la facturación es por token en lugar de capacidad previamente reservada.

Dos enfoques 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 valoran la simplicidad, un inicio rápido y la mínima complejidad de infraestructura ML.

Los datos se cargan en S3, se inicia un trabajo de ajuste fino a través de la consola o API, y AWS gestiona el entrenamiento e implementación posterior de la versión personalizada de Nova Micro. Este enfoque está dirigido a equipos de aplicaciones en lugar de una plataforma ML separada. El segundo camino es el entrenamiento a través de Amazon SageMaker AI.

Es más complejo pero ofrece más control sobre la receta de entrenamiento: puedes ajustar el tamaño del lote, dropout, parámetros del optimizador, ventana de contexto, configuraciones de LoRA y estrategia de calentamiento de la tasa de aprendizaje. En el ejemplo de AWS, utilizaron el conjunto de datos sql-create-context basado en WikiSQL y Spider, convirtiendo pares pregunta-SQL al formato bedrock-conversation-2024 para entrenamiento y validación. Esto conlleva una complejidad de configuración mayor y un trabajo de infraestructura más explícito.

• Bedrock — menos carga operativa y camino más rápido hacia un prototipo funcional
• SageMaker AI — más control sobre hiperparámetros e integración MLOps
• Ambos esquemas utilizan el mismo pipeline de preparación de datos y luego se implementan en Bedrock
• La inferencia final se ejecuta en un modelo sin servidor con facturación por token, sin hospedaje constante

Costo y latencia

AWS proporciona números específicos. Para ajuste fino gestionado de Bedrock, el costo de entrenamiento se calcula como $0,001 por 1.000 tokens por época: en el ejemplo con 2.

000 muestras, cinco épocas y aproximadamente 800 tokens por registro, resultó en alrededor de $8. Para la opción SageMaker, se utilizó una instancia ml.g5.

48xlarge a $16.288 por hora; el entrenamiento en un conjunto de datos de 20.000 filas tomó alrededor de cuatro horas y costó aproximadamente $65,15.

La tesis clave del artículo no es el costo único de entrenamiento, sino el costo operativo. AWS estimó una carga de producción típica de 22.000 solicitudes por mes, o 100 usuarios realizando 10 solicitudes por día durante 22 días laborales.

Con un tamaño promedio de solicitud de 800 tokens de entrada y 60 tokens de salida, la inferencia mensual para tal modelo personalizado de text-to-SQL fue de $0,80. Esto es posible porque un Nova Micro personalizado en Bedrock se factura igual que el modelo base, sin prima adicional por implementación sin servidor. En términos de velocidad, hay un compromiso, pero es moderado.

En arranque en frío, el tiempo promedio hasta el primer token aumentó a 639 ms, lo que es 34% más alto que el modelo base. En operación normal, el TTFT promedio fue de 380 ms en 50 llamadas — solo 7% peor que la línea de base. La latencia completa de generación fue de alrededor de 477 ms, con velocidad de salida mantenida en 183 tokens por segundo.

AWS validó la calidad no solo por latencia, sino a través de LLM-as-a-Judge, comparando el SQL generado con respuestas de referencia.

Qué significa esto

Para equipos que desean integrar text-to-SQL en productos de análisis, herramientas BI internas o interfaces de chat hacia bases de datos, el estudio de caso de AWS se ve práctico: puedes obtener un generador SQL personalizado sin costos constantes de infraestructura dedicada. Si la velocidad de lanzamiento importa más, Bedrock es la opción lógica; si necesitas control total sobre el entrenamiento, la combinación con SageMaker AI se ve más fuerte.