Ruta de consulta más inteligente para asistentes de SQL de IA: Cómo reducir costos sin sacrificar la calidad

Imagina que tu asistente de SQL es un cohete, atravesando consultas complejas. Luego, un día te das cuenta de que estás utilizando combustible de cohete para obtener una lista de compras.

Es emocionante, hasta que llega la factura del combustible. De repente, se vuelve claro que los recados simples no necesitan un cohete. Lo mismo sucede cuando cada solicitud de SQL, desde una búsqueda básica hasta un análisis de múltiples esquemas, se envía al mismo modelo de IA potente.

El proceso de obtener un asistente de SQL de IA suele ser el mismo. Al principio, la productividad aumenta: las consultas se realizan más rápido, el código de caldera desaparece y los desarrolladores dedican menos tiempo a escribir consultas de SQL de rutina. A medida que más equipos lo utilizan, el número de consultas aumenta. Cuando llega la factura de infraestructura, la economía cambia.

El problema está en la construcción. Cuesta mucho ejecutar modelos de IA de frontera que puedan pensar en planes de ejecución, esquemas y lógica de consulta compleja. Ese precio tiene sentido para tareas difíciles, ya que cuesta alrededor de $0.03 por consulta. Cuando se utiliza para declaraciones SELECT simples y operaciones CRUD, se convierte en un desperdicio a escala.

Pero la respuesta no es bajar el modelo. Es enviar las consultas al lugar correcto. La ruta de consulta inteligente clasifica cada solicitud por su dificultad y la envía al modelo de nivel adecuado. Este método puede reducir los costos de inferencia en un 40-70% en cargas de trabajo de SQL sin disminuir la calidad de la salida.

Este artículo explica cómo funciona esa arquitectura: definiendo niveles de complejidad de SQL, construyendo tuberías de clasificación y enrutamiento, y midiendo los verdaderos compromisos entre costo y calidad una vez que el sistema esté en funcionamiento. Estos patrones reflejan lecciones aprendidas mientras se desarrollaban capacidades de IA conscientes del esquema en dbForge AI Assistant.

Por qué un modelo no se adapta a todas las tareas de SQL

No todas las consultas de SQL son iguales en términos de complejidad. Una consulta que recupera un usuario por clave principal y una que reconstruye canalizaciones de sesión en varios esquemas con funciones de ventana son ambas SQL, pero el razonamiento necesario para generarlas es muy diferente.

Si un sistema las trata de la misma manera, el resultado es predecible: se desperdicia cómputo. En la mayoría de las cargas de trabajo empresariales, la mayoría de las consultas son de rutina. Búsquedas simples, lecturas de una sola tabla, inserciones básicas, correcciones de sintaxis. Nada complicado. Enviar todas esas a un modelo de frontera es como utilizar un ascensor de carga para transportar una libreta.

Una forma de pensar en el problema es dividiendo las consultas en niveles de complejidad:

La brecha de costo entre niveles es grande. Una consulta de Nivel 1 podría costar alrededor de $0.001 en un modelo ligero. La misma consulta enviada a un modelo de frontera cuesta cerca de $0.03. A 10,000 consultas por día, eso es $10 vs $300 en gastos diarios. Una diferencia de 30 veces, solo por decisiones de enrutamiento.

La conciencia del esquema también importa aquí. Las consultas de Nivel 3 no solo necesitan más cómputo. Necesitan contexto: relaciones entre tablas, claves foráneas, índices, sintaxis específica de la base de datos. Ese contexto debe ser inyectado durante la inferencia.

Ejecutar una consulta simple de Nivel 1 a través de la misma ruta pesada desperdicia tokens, agrega latencia y no mejora el resultado.

Una arquitectura práctica para la selección de modelos

Un sistema de enrutamiento suele tener cuatro etapas: clasificar, enrutrar, ejecutar y validar. Cada etapa hace un trabajo diferente, y cada una puede fallar de diferentes maneras. Ayuda a pensar en ellas por separado antes de armar la tubería completa.

La clasificación es el paso más importante. El clasificador recibe la consulta de SQL cruda o la solicitud de lenguaje natural que generará una y la asigna a un nivel de complejidad. Hay tres formas comunes de construir este clasificador.

Clasificación basada en reglas confía en patrones de regex y análisis de árbol de sintaxis abstracta (AST) para detectar señales de estructura: cosas como el recuento de tablas, la profundidad de anidación, funciones de ventana, subconsultas o operadores de agregación. Este enfoque es rápido y predecible, con casi ninguna sobrecarga. Funciona bien para casos obvios: las declaraciones SELECT simples y las operaciones DML básicas generalmente se pueden identificar sin involucrar un modelo en absoluto. 

Modelos de clasificación ligeros utilizan un modelo de lenguaje pequeño entrenado para estimar la complejidad de SQL. Esto agrega un paso extra, pero es una de las decisiones de mayor retorno de la inversión en toda la tubería. Una llamada al clasificador podría costar alrededor de $0.0001, lo que justifica fácilmente evitar una llamada al modelo de frontera de $0.03. 

En muchos entornos, estos modelos ligeros también pueden ejecutarse localmente, eliminando efectivamente el costo para las consultas de usuario simples. También pueden clasificar solicitudes de lenguaje natural antes de que se genere SQL, lo que es útil en flujos de trabajo de asistentes donde la consulta aún no existe. 

Clasificación híbrida combina ambos enfoques. La lógica basada en reglas maneja los casos claros a costo cero, mientras que el clasificador maneja el caso ambiguo: las consultas que parecen moderadas pero pueden requerir razonamiento consciente del esquema para generarlas correctamente. 

Enrutamiento ocurre después de la clasificación. Pero el nivel solo no es el único factor. Algunas otras cosas influyen en dónde debe ir una consulta. Estas incluyen: 

1. Requisitos de contexto de esquema. Algunas consultas necesitan que el modelo comprenda las relaciones entre claves foráneas, índices u otros detalles estructurales. Estas consultas llevan más contexto y generalmente necesitan ser enrutadas a un modelo de mayor capacidad. 
2. Tolerancia a la latencia. Las características orientadas al usuario, como la autocompletar o las sugerencias en línea, tienen presupuestos de latencia estrictos. Las tareas en segundo plano generalmente no. En esos casos, un modelo más lento pero más capaz puede ser aceptable. 
3. Umbral de confianza. A veces, el clasificador no está seguro del nivel. En esos casos, enrutrar hacia arriba generalmente es la opción más segura. Un descenso incorrecto puede producir una consulta mala y desencadenar reintentos, lo que a menudo cuesta más que usar el modelo más fuerte desde el principio. 

La capa de validación se ejecuta después de que se ha ejecutado el código. El trabajo de esta es detectar errores de enrutamiento antes de que lleguen al usuario. Después de la ejecución, se realizan comprobaciones para asegurarse de que la sintaxis sea correcta, que los resultados sean razonables (¿la consulta devolvió las formas de fila correctas?) y que el esquema sea coherente. Cuando un resultado falla la validación, el sistema mueve hacia arriba y vuelve a ejecutar la consulta.

En Devart, lo más importante para obtener la precisión del enrutamiento de dbForge AI Assistant fue construir contexto consciente del esquema en la decisión de clasificación. Sin contexto de esquema, las consultas que utilizaban nombres de tabla poco claros o dependían de relaciones implícitas siempre se clasificaban mal y se enviaban a modelos más baratos que no podían manejarlas. La solución fue darle al clasificador no solo la estructura de la consulta, sino también algunos metadatos del esquema.

Medir lo que importa: compromisos entre costo y calidad en la práctica

El caso de negocio para el enrutamiento solo se mantiene si la calidad se mantiene junto con él. La reducción de costos que causa una salida degradada, reintentos aumentados o desconfianza de los desarrolladores no es un ahorro, es una transferencia de costo de la factura de infraestructura al tiempo de ingeniería. Tres métricas determinan si un sistema de enrutamiento realmente funciona.

Costo por consulta por nivel establece la línea de base. Rastree el gasto real en cada nivel por separado, no como un promedio combinado. Combinar oscurece si el enrutamiento está funcionando, un sistema que enruta el 50% de las consultas al nivel incorrecto aún mostrará un costo promedio más bajo, mientras que silenciosamente produce resultados peores. 

La puntuación de calidad verifica la corrección, la completitud y el seguimiento de las mejores prácticas de SQL. La tasa de escalación es la señal de calidad más directa. Indica con qué frecuencia un modelo de Nivel 1 o Nivel 2 produce una salida que no pasa la validación y necesita ser enviada a un lugar diferente. Un sistema bien ajustado debe mantener la escalación por debajo del 5%. El clasificador necesita ser reentrenado por encima de ese nivel. Puede estar malinterpretando señales de estructura o puede que no tenga el contexto de esquema que necesita para distinguir entre moderado y complejo. 

Impacto de la latencia examina cuánto tiempo tarda una respuesta en moverse de un nivel a otro, incluyendo cualquier tiempo extra necesario para la clasificación. Los usuarios solo deben notar un retraso de 50 a 100 milisegundos en las interacciones que pasan por la capa de enrutamiento. Si la clasificación en sí se convierte en un problema, el enfoque híbrido (reglas para casos claros, clasificador solo para casos poco claros) lo soluciona sin perder precisión. 

En la vida real, un sistema de enrutamiento bien ajustado puede reducir los costos de inferencia en un 40-60%, mantener la escalación por debajo del 5% y mantener la calidad de la salida alta para consultas complejas. Para ahorrar el 70% o más, generalmente hay que hacer tareas de Nivel 1 por su cuenta con modelos más pequeños. Eso podría funcionar, pero también complica las cosas, lo que no todos los equipos quieren manejar.

El “impuesto de escalación” es otra cosa que debe considerarse. Si el enrutamiento es demasiado duro en los modelos más baratos, el sistema puede tener que hacer más trabajo en general: llamada al clasificador, llamada al modelo inicial, validación fallida, reenrutamiento y una segunda llamada al modelo. En algunos casos, eso cuesta más que enviar la pregunta al modelo de frontera desde el principio.

Solo mirar el costo por llamada pasa por alto este efecto. La tasa de escalación debe rastrearse junto con él.

Conclusión estratégica para los equipos de ingeniería

El enrutamiento inteligente no es solo un lujo para las implementaciones de SQL de IA maduras; es una necesidad para las de largo plazo. Los equipos que lo saltan intercambian un problema de presupuesto que no se puede resolver por un problema de arquitectura que se puede. Los patrones están allí; lo único que queda es decidir qué patrones seguir primero.

Comience con el clasificador, no con los modelos. La capa de enrutamiento decide si todo lo demás funciona. Un clasificador híbrido bien ajustado le dará la mayoría de los ahorros de costo sin complicar demasiado las cosas.

Utilice el contexto de esquema de la alimentación para ayudar a tomar decisiones de clasificación. Para las cargas de trabajo de SQL que involucran relaciones entre varias tablas o razonamiento específico del esquema, la estructura de la consulta sola no es suficiente. Los metadatos del esquema parciales en el momento de la clasificación aumentan en gran medida la precisión del nivel.

Utilice la tasa de escalación como la señal de calidad principal. Encuentra la mala clasificación más rápido que cualquier otra métrica y muestra exactamente dónde el clasificador necesita mejorar.

Antes del clasificador, planifique la capa de validación. Saber qué se ve como un fallo y qué causa una escalación hace que la lógica de enrutamiento sea más limpia y el sistema mejor equipado para manejar casos de borde.

El valor de la capa de enrutamiento aumenta, no disminuye, a medida que los modelos de código abierto mejoran y el costo de la inferencia local disminuye. Los modelos de Nivel 1 más baratos hacen que la diferencia de costo entre niveles sea más grande, lo que hace que la clasificación correcta sea más valiosa. La arquitectura de enrutamiento que se construye hoy será útil durante mucho tiempo, no solo como una solución rápida.