Routage de requêtes intelligent pour les assistants SQL IA : Comment réduire les coûts sans sacrifier la qualité

Imaginez que votre assistant SQL est un fusée, traversant des requêtes complexes. Puis un jour, vous réalisez que vous utilisez du carburant de fusée pour récupérer une liste de courses.

C’est excitant, jusqu’à ce que la facture de carburant arrive. Soudain, il devient clair que les courses simples ne nécessitent pas de fusée. La même chose se produit lorsque chaque requête SQL, d’une recherche de base à une analyse multi-schéma, est acheminée vers le même modèle d’IA puissant.

Le processus d’obtention d’un assistant SQL IA est généralement le même. Au début, la productivité augmente : les requêtes sont effectuées plus rapidement, le code de base disparaît et les développeurs passent moins de temps à écrire des requêtes SQL de routine. À mesure que davantage d’équipes l’utilisent, le nombre de requêtes augmente. Lorsque la facture d’infrastructure arrive, l’économie change.

Le problème réside dans la structure. Il en coûte cher pour exécuter des modèles d’IA Frontier qui peuvent réfléchir aux plans d’exécution, aux schémas et à la logique de requête complexe. Ce prix est justifié pour les tâches difficiles, car il coûte environ 0,03 $ par requête. Lorsqu’il est utilisé pour des instructions SELECT simples et des opérations CRUD, cela devient un gaspillage à grande échelle.

Mais la réponse n’est pas de diminuer le modèle. Il s’agit d’envoyer les requêtes au bon endroit. Le routage de requêtes intelligent trie chaque demande en fonction de sa difficulté et l’envoie au bon niveau de modèle. Cette méthode peut réduire les coûts d’inférence de 40 à 70 % dans les charges de travail SQL sans diminuer la qualité de la sortie.

Cet article explique comment cette architecture fonctionne : en définissant les niveaux de complexité SQL, en construisant des pipelines de classification et de routage, et en mesurant les véritables compromis coût-qualité une fois le système en fonctionnement. Ces modèles reflètent les leçons tirées lors du développement de capacités d’IA sensibles aux schémas dans dbForge AI Assistant.

Pourquoi un modèle ne convient pas à toutes les tâches SQL

Toutes les requêtes SQL ne sont pas identiques en termes de complexité. Une requête qui récupère un utilisateur par clé primaire et une qui reconstruisent des tunnels de session sur plusieurs schémas avec des fonctions de fenêtrage sont toutes deux des requêtes SQL, mais la réflexion nécessaire pour les générer est très différente.

Si un système les traite de la même manière, le résultat est prévisible : gaspillage de calcul. Dans la plupart des charges de travail d’entreprise, la plupart des requêtes sont de routine. Recherches simples, lectures de table unique, insertions de base, corrections de syntaxe. Rien de compliqué. Envoyer toutes ces requêtes à un modèle de pointe est comme utiliser un ascenseur de marchandises pour transporter un cahier.

Une façon de penser au problème est de diviser les requêtes en niveaux de complexité :

Le fossé entre les niveaux est grand. Une requête de niveau 1 pourrait coûter environ 0,001 $ sur un modèle léger. La même requête envoyée à un modèle de pointe coûte environ 0,03 $. À 10 000 requêtes par jour, cela représente 10 $ contre 300 $ de dépenses quotidiennes. Une différence de 30 fois, juste en raison des décisions de routage.

La conscience du schéma compte également ici. Les requêtes de niveau 3 ne nécessitent pas seulement plus de calcul. Ils ont besoin de contexte : relations entre tables, clés étrangères, indexes, syntaxe spécifique à la base de données. Ce contexte doit être injecté pendant l’inférence.

Exécuter une requête de niveau 1 simple via le même chemin lourd gaspille des jetons, ajoute de la latence et n’améliore pas le résultat.

Une architecture pratique pour la sélection de modèle

Un système de routage comporte généralement quatre étapes : classification, routage, exécution et validation. Chaque étape a un rôle différent et peut échouer de différentes manières. Il est utile de les considérer séparément avant de rassembler le pipeline complet.

La classification est l’étape la plus importante. Le classificateur reçoit soit la requête SQL brute, soit la invite de langage naturel qui générera une requête et l’attribue à un niveau de complexité. Il existe trois façons courantes de construire ce classificateur.

Classification basée sur des règles repose sur des modèles de regex et l’analyse de l’arbre de syntaxe abstrait pour détecter des signaux structurels : choses comme le nombre de tables, la profondeur de nidification, les fonctions de fenêtrage, les sous-requêtes ou les opérateurs d’agrégation. Cette approche est rapide et prévisible, avec presque aucun surcoût. Elle fonctionne bien pour les cas évidents : les instructions SELECT simples et les opérations DML de base peuvent généralement être identifiées sans impliquer de modèle du tout.

Modèles de classificateurs légers utilisent un petit modèle de langage formé pour estimer la complexité SQL. Cela ajoute une étape supplémentaire, mais c’est l’une des décisions à plus haut rendement dans l’ensemble du pipeline. Un appel de classificateur peut coûter environ 0,0001 $, ce qui justifie facilement l’évitement d’un appel de modèle de pointe à 0,03 $.

Dans de nombreux paramètres, ces modèles légers peuvent également s’exécuter localement, supprimant efficacement le coût pour les requêtes utilisateur simples. Ils peuvent également classer les invites de langage naturel avant que la requête SQL ne soit générée, ce qui est utile dans les flux de travail d’assistant où la requête n’existe pas encore.

Classification hybride combine les deux approches. La logique basée sur des règles gère les cas clairs à zéro coût, tandis que le classificateur gère les cas ambigus : les requêtes qui semblent modérées mais peuvent en fait nécessiter une réflexion sensible au schéma pour être générées correctement.

Routage se produit après la classification. Mais le niveau seul n’est pas le seul facteur. Quelques autres choses influencent où une requête doit aller. Ceux-ci incluent :

1. Exigences de contexte de schéma. Certaines requêtes nécessitent que le modèle comprenne les relations entre tables étrangères, les indexes ou d’autres détails structurels. Ces requêtes transportent plus de contexte et doivent généralement être acheminées vers un modèle plus capable.
2. Tolérance à la latence. Les fonctionnalités orientées utilisateur comme l’autocomplétion ou les suggestions en ligne ont des budgets de latence stricts. Les tâches en arrière-plan ne le font généralement pas. Dans ces cas, un modèle plus lent mais plus capable peut être acceptable.
3. Seuils de confiance. Parfois, le classificateur n’est pas sûr du niveau. Dans ces cas, le routage vers le haut est généralement l’option la plus sûre. Une dégradation incorrecte peut produire une requête incorrecte et déclencher des réessais, ce qui coûte souvent plus cher que l’utilisation du modèle plus puissant en premier lieu.

La couche de validation s’exécute après que le code ait été exécuté. Le travail de celle-ci est de détecter les erreurs de routage avant qu’elles n’atteignent l’utilisateur. Après l’exécution, des vérifications sont effectuées pour s’assurer que la syntaxe est correcte, que les résultats sont raisonnables (la requête a-t-elle renvoyé les bonnes formes de ligne ?) et que le schéma est cohérent. Lorsqu’un résultat échoue à la validation, le système passe à un niveau supérieur et exécute à nouveau la requête.

Chez Devart, la chose la plus importante pour obtenir la précision du routage de dbForge AI Assistant était de construire un contexte sensible au schéma dans la décision de classification. Sans contexte de schéma, les requêtes qui utilisaient des noms de table ambigus ou reposaient sur des relations implicites étaient toujours mal classées et envoyées à des modèles moins chers qui ne pouvaient pas les gérer. La solution consistait à donner au classificateur non seulement la structure de la requête, mais également certains métadonnées de schéma.

Mesurer ce qui compte : compromis coût-qualité dans la pratique

Le cas d’affaires pour le routage ne tient que si la qualité est maintenue avec lui. La réduction des coûts qui entraîne une sortie dégradée, des réessais accrus ou une méfiance des développeurs n’est pas une économie, c’est un transfert de coût de la facture d’infrastructure au temps d’ingénierie. Trois métriques déterminent si un système de routage fonctionne réellement.

Coût par requête par niveau établit la base de référence. Suivez les dépenses réelles à chaque niveau séparément, et non comme une moyenne pondérée. La moyenne obscurcit si le routage fonctionne, un système qui achemine 50 % des requêtes vers le mauvais niveau affichera toujours un coût moyen plus bas, tout en produisant silencieusement de mauvais résultats.

Le score de qualité vérifie l’exactitude, l’exhaustivité et le respect des meilleures pratiques SQL. Le taux d’escalade est le signal le plus direct. Il indique combien souvent un modèle de niveau 1 ou 2 produit une sortie qui ne passe pas la validation et doit être envoyée à un emplacement différent. Un système bien réglé devrait maintenir l’escalade en dessous de 5 %. Le classificateur doit être réentraîné au-dessus de ce niveau. Il peut mal interpréter les signaux structurels ou il peut ne pas avoir le contexte de schéma dont il a besoin pour faire la différence entre modéré et complexe.

Impact de la latence examine le temps qu’il faut pour qu’une réponse se déplace d’un niveau à l’autre, y compris tout temps supplémentaire nécessaire pour la classification. Les utilisateurs ne devraient remarquer qu’un retard de 50 à 100 millisecondes dans les interactions qui passent par la couche de routage. Si la classification elle-même devient un problème, l’approche hybride (règles pour les cas clairs, classificateur uniquement pour les cas peu clairs) le corrige sans perdre de précision.

Dans la vie réelle, un système de routage bien réglé peut réduire les coûts d’inférence de 40 à 60 %, maintenir l’escalade en dessous de 5 % et maintenir la qualité de sortie élevée pour les requêtes complexes. Pour économiser 70 % ou plus, vous devez généralement effectuer des tâches de niveau 1 vous-même avec des modèles plus petits. Cela peut fonctionner, mais cela rend également les choses plus compliquées, ce que chaque équipe ne veut pas gérer.

La “taxe d’escalade” est une autre chose qui doit être examinée. Si le routage est trop dur pour les modèles moins chers, le système peut devoir effectuer plus de travail au total : appel de classificateur, appel de modèle initial, validation échouée, réacheminement et deuxième appel de modèle. Dans certains cas, cela coûte plus cher que d’envoyer la question au modèle de pointe en premier lieu.

Ne regarder que le coût par appel manque cet effet. Le taux d’escalade doit être suivi avec lui.

Principales conclusions pour les équipes d’ingénierie

Le routage intelligent n’est pas seulement un élément agréable à avoir pour les déploiements d’IA SQL matures ; c’est un élément essentiel pour les déploiements à long terme. Les équipes qui le sautent échangent un problème de budget qui ne peut pas être résolu pour un problème d’architecture qui peut être résolu. Les modèles sont là ; il ne reste plus qu’à décider lesquels suivre en premier.

Commencez par le classificateur, et non par les modèles. La couche de routage décide si tout le reste fonctionne. Un classificateur hybride bien réglé vous donnera la plupart des économies de coûts sans rendre les choses trop compliquées.

Utilisez le contexte de schéma de l’alimentation pour aider à prendre des décisions de classification. Pour les charges de travail SQL qui impliquent des relations entre plusieurs tables ou une réflexion spécifique à un schéma, la structure de requête seule ne suffit pas. Les métadonnées de schéma partielles au moment de la classification améliorent considérablement la précision du niveau.

Utilisez le taux d’escalade comme principal signal de qualité. Il trouve la mauvaise classification plus rapidement que n’importe quelle autre métrique et montre exactement où le classificateur doit s’améliorer.

Avant le classificateur, planifiez la couche de validation. Savoir à quoi ressemble l’échec et ce qui provoque une escalade rend la logique de routage plus propre et le système mieux à même de gérer les cas limites.

La valeur de la couche de routage augmente, et non diminue, à mesure que les modèles open source s’améliorent et que le coût de l’inférence locale diminue. Les modèles de niveau 1 moins chers font que la différence de coût entre les niveaux est plus importante, ce qui rend la classification correcte plus précieuse. L’architecture de routage construite aujourd’hui sera utile pendant longtemps, et non seulement comme solution rapide.