Intelligentere Abfrage-Weiterleitung für AI-SQL-Assistenten: Wie man Kosten reduziert, ohne die Qualität zu beeinträchtigen

Stellen Sie sich vor, Ihr SQL-Assistent wäre ein Rakete, die durch komplexe Abfragen schießt. Dann stellen Sie eines Tages fest, dass Sie Raketenkraftstoff verwenden, um eine Einkaufsliste abzurufen.

Es ist aufregend, bis die Kraftstoffrechnung kommt. Plötzlich wird klar, dass einfache Besorgungen keine Rakete benötigen. Das Gleiche passiert, wenn jede SQL-Anfrage, von einer einfachen Abfrage bis hin zu einer Analyse mehrerer Schemata, an das gleiche leistungsstarke AI-Modell weitergeleitet wird.

Der Prozess der Beschaffung eines AI-SQL-Assistenten ist normalerweise der gleiche. Zunächst steigt die Produktivität: Abfragen werden schneller ausgeführt, Boilerplate-Code verschwindet und Entwickler verbringen weniger Zeit mit dem Schreiben von Routine-SQL-Abfragen. Wenn mehr Teams es verwenden, steigt die Anzahl der Abfragen. Wenn die Infrastruktur-Rechnung kommt, ändert sich die Wirtschaftlichkeit.

Das Problem liegt im Gebäude. Es kostet viel, Frontier-AI-Modelle zu betreiben, die über Ausführungspläne, Schemata und komplexe Abfrage-Logik nachdenken können. Dieser Preis ist für schwierige Aufgaben gerechtfertigt, da er etwa 0,03 $ pro Abfrage kostet. Wenn sie jedoch für einfache SELECT-Anweisungen und CRUD-Operationen verwendet werden, wird es zu einer Verschwendung im großen Maßstab.

Aber die Antwort besteht nicht darin, das Modell herabzustufen. Es geht darum, die Abfragen an den richtigen Ort zu senden. Eine intelligente Abfrage-Weiterleitung sortiert jede Anfrage nach ihrer Schwierigkeit und sendet sie an die richtige Modell-Stufe. Diese Methode kann die Inferenzkosten in SQL-Workloads um 40-70 % reduzieren, ohne die Qualität der Ausgabe zu beeinträchtigen.

Dieser Artikel erklärt, wie diese Architektur funktioniert: Definieren von SQL-Komplexitätsebenen, Aufbau von Klassifizierungs- und Weiterleitungs-Pipelines und Messen der tatsächlichen Kosten-Qualitäts-Trade-Offs, wenn das System läuft. Diese Muster spiegeln die Erfahrungen wider, die bei der Entwicklung von schema-bewussten AI-Fähigkeiten in dbForge AI Assistant gesammelt wurden.

Warum ein Modell nicht für alle SQL-Aufgaben passt

Nicht alle SQL-Abfragen sind in Bezug auf die Komplexität gleich. Eine Abfrage, die einen Benutzer nach Primärschlüssel abruft, und eine, die Sitzungskanäle über mehrere Schemata mit Fensterfunktionen neu aufbaut, sind beide SQL, aber die erforderliche Argumentation, um sie zu generieren, ist sehr unterschiedlich.

Wenn ein System sie gleich behandelt, ist das Ergebnis vorhersehbar: verschwendete Rechenleistung. In den meisten Unternehmens-Workloads sind die meisten Abfragen Routine. Einfache Abfragen, Lesevorgänge auf einer Tabelle, grundlegende Einfügungen, Syntaxkorrekturen. Nichts Kompliziertes. Wenn all diese an ein Frontier-Modell gesendet werden, ist es, als würde man einen Frachtaufzug verwenden, um ein Notizbuch zu transportieren.

Ein Weg, das Problem zu betrachten, besteht darin, die Abfragen in Komplexitätsebenen zu unterteilen:

Die Kostenlücke zwischen den Stufen ist groß. Eine Abfrage der Stufe 1 könnte etwa 0,001 $ auf einem leichten Modell kosten. Die gleiche Abfrage, die an ein Frontier-Modell gesendet wird, kostet etwa 0,03 $. Bei 10.000 Abfragen pro Tag sind das 10 $ vs. 300 $ an täglichen Ausgaben. Ein Unterschied von 30-mal, nur durch Weiterleitungsentscheidungen.

Schema-Kenntnis ist auch hier wichtig. Abfragen der Stufe 3 benötigen nicht nur mehr Rechenleistung. Sie benötigen Kontext: Tabellenbeziehungen, Fremdschlüssel, Indizes, Datenbank-spezifische Syntax. Dieser Kontext muss während der Inferenz injiziert werden.

Das Ausführen einer einfachen Abfrage der Stufe 1 durch denselben schweren Pfad verschwendet Token, verursacht Latenz und verbessert das Ergebnis nicht.

Eine praktische Architektur für die Modellauswahl

Ein Weiterleitungssystem besteht normalerweise aus vier Stufen: Klassifizierung, Weiterleitung, Ausführung und Validierung. Jede Stufe hat eine andere Aufgabe und kann auf unterschiedliche Weise fehlschlagen. Es hilft, sie getrennt zu betrachten, bevor die gesamte Pipeline zusammengesetzt wird.

Die Klassifizierung ist der wichtigste Schritt. Der Klassifizierer erhält entweder die rohe SQL-Abfrage oder den natürlichen Sprachprompt, der eine Abfrage generieren wird, und ordnet sie einer Komplexitätsebene zu. Es gibt drei gängige Methoden, diesen Klassifizierer zu erstellen.

Regelbasierte Klassifizierung basiert auf Regex-Mustern und AST (abstrakter Syntaxbaum)-Analyse, um strukturelle Signale zu erkennen: Dinge wie Tabellenanzahl, Nesting-Tiefe, Fensterfunktionen, Unterabfragen oder Aggregationsoperatoren. Dieser Ansatz ist schnell und vorhersehbar, mit fast keinem Overhead. Er funktioniert gut für offensichtliche Fälle: einfache SELECT-Anweisungen und grundlegende DML können normalerweise ohne Modell identifiziert werden.

Leichtgewichtige Klassifizierungsmodelle verwenden ein kleines Sprachmodell, das zur Schätzung der SQL-Komplexität trainiert wurde. Dies fügt einen zusätzlichen Schritt hinzu, aber es ist eine der rentabelsten Entscheidungen in der gesamten Pipeline. Ein Klassifizierer-Aufruf könnte etwa 0,0001 $ kosten, was leicht die Vermeidung eines 0,03 $-Frontier-Modell-Aufrufs rechtfertigt.

In vielen Einrichtungen können diese leichten Modelle auch lokal ausgeführt werden, was die Kosten für einfache Benutzerabfragen effektiv entfernt. Sie können auch natürliche Sprachprompts klassifizieren, bevor SQL generiert wird, was in Assistant-Workflows nützlich ist, in denen die Abfrage noch nicht existiert.

Hybrid-Klassifizierung kombiniert beide Ansätze. Regelbasierte Logik behandelt klare Fälle ohne Kosten, während der Klassifizierer den zweideutigen Mittelbereich behandelt: Abfragen, die moderat aussehen, aber tatsächlich schema-bewusste Argumentation erfordern, um sie korrekt zu generieren.

Weiterleitung erfolgt nach der Klassifizierung. Aber die Stufe allein ist nicht der einzige Faktor. Einige andere Dinge beeinflussen, wohin eine Abfrage gesendet werden sollte. Dazu gehören:

1. Schemakontext-Anforderungen. Einige Abfragen benötigen, dass das Modell Tabellenbeziehungen, Indizes oder andere strukturelle Details versteht. Diese Abfragen tragen mehr Kontext und benötigen normalerweise eine Weiterleitung an ein Modell mit höherer Fähigkeit.
2. Latenz-Toleranz. Benutzerorientierte Funktionen wie Autovervollständigung oder Inline-Vorschläge haben strenge Latenz-Budgets. Hintergrund-Aufgaben haben normalerweise keine. In diesen Fällen kann ein langsameres, aber leistungsfähigeres Modell akzeptabel sein.
3. Vertrauensschwellen. Manchmal ist der Klassifizierer nicht sicher über die Stufe. In diesen Fällen ist die Weiterleitung nach oben normalerweise die sicherere Option. Eine falsche Herabstufung kann zu einer schlechten Abfrage führen und Retries auslösen, was oft mehr kostet, als das leistungsfähigere Modell von Anfang an zu verwenden.

Die Validierungsschicht läuft nach der Ausführung des Codes. Ihre Aufgabe besteht darin, Weiterleitungsfehler vor dem Benutzer zu erkennen. Nach der Ausführung werden Überprüfungen durchgeführt, um sicherzustellen, dass die Syntax korrekt ist, dass die Ergebnisse vernünftig sind (hat die Abfrage die richtige Zeilenform zurückgegeben?) und dass das Schema konsistent ist. Wenn ein Ergebnis die Validierung nicht besteht, verschiebt das System die Stufe nach oben und führt die Abfrage erneut aus.

Bei Devart war es für die Erhöhung der Genauigkeit der Weiterleitung in dbForge AI Assistant am wichtigsten, den schemabewussten Kontext in die Klassifizierungsentscheidung einzubauen. Ohne schemabewussten Kontext wurden Abfragen, die unklare Tabellennamen verwendeten oder von impliziten Beziehungen abhängig waren, immer falsch klassifiziert und an billigere Modelle weitergeleitet, die sie nicht verarbeiten konnten. Die Lösung bestand darin, dem Klassifizierer nicht nur die Abfragestruktur, sondern auch einige Schemameta-Daten zu geben.

Messen, was zählt: Kosten-Qualitäts-Trade-Offs in der Praxis

Der Geschäftsfall für die Weiterleitung gilt nur, wenn die Qualität erhalten bleibt. Eine Kostensenkung, die zu einer Verschlechterung der Ausgabe, erhöhten Retries oder einem Vertrauensverlust der Entwickler führt, ist kein Einsparung, sondern eine Übertragung der Kosten von der Infrastruktur-Rechnung auf die Entwicklungzeit. Drei Metriken bestimmen, ob ein Weiterleitungssystem tatsächlich funktioniert.

Kosten pro Abfrage nach Stufe legt die Grundlage fest. Verfolgen Sie die tatsächlichen Ausgaben für jede Stufe separat, nicht als gemittelten Durchschnitt. Die Mittelung verschleiert, ob die Weiterleitung funktioniert, ein System, das 50 % der Abfragen an die falsche Stufe weiterleitet, zeigt immer noch eine geringere durchschnittliche Kosten, während es stillschweigend schlechtere Ergebnisse produziert.

Die Qualitätsbewertung überprüft die Richtigkeit, Vollständigkeit und Einhaltung der SQL-Best-Practices. Die Eskalationsrate ist das direkteste Signal. Sie zeigt, wie oft ein Modell der Stufe 1 oder 2 Ausgaben erzeugt, die die Validierung nicht bestehen und an eine andere Stelle weitergeleitet werden müssen. Ein gut abgestimmtes System sollte die Eskalation unter 5 % halten. Der Klassifizierer muss über diesen Wert hinaus neu trainiert werden. Er könnte strukturelle Signale falsch interpretieren oder nicht den schemabewussten Kontext haben, den er benötigt, um zwischen moderaten und komplexen Abfragen zu unterscheiden.

Latenz-Einfluss untersucht, wie lange es dauert, bis eine Antwort von einer Stufe zur nächsten verschoben wird, einschließlich der zusätzlichen Zeit, die für die Klassifizierung benötigt wird. Benutzer sollten nur eine Verzögerung von 50 bis 100 Millisekunden bei Interaktionen bemerken, die durch die Weiterleitungsschicht laufen. Wenn die Klassifizierung selbst zu einem Problem wird, behebt der hybride Ansatz (Regeln für klare Fälle, Klassifizierer nur für unklare Fälle) dies, ohne die Genauigkeit zu verlieren.

In der Praxis kann ein gut abgestimmtes Weiterleitungssystem die Inferenzkosten um 40-60 % senken, die Eskalation unter 5 % halten und die Ausgabekualität für komplexe Abfragen hoch halten. Um 70 % oder mehr zu sparen, muss man normalerweise Aufgaben der Stufe 1 mit kleineren Modellen selbst durchführen. Das kann funktionieren, aber es macht die Dinge auch komplizierter, was nicht jeder Entwickler möchte.

Die “Eskalationssteuer” ist ein weiterer Aspekt, der berücksichtigt werden muss. Wenn die Weiterleitung zu hart auf billige Modelle ist, muss das System möglicherweise mehr Arbeit leisten: Klassifizierer-Aufruf, initialer Modell-Aufruf, fehlgeschlagene Validierung, Umleitung und ein zweiter Modell-Aufruf. In einigen Fällen kostet dies mehr, als die Abfrage von Anfang an an das Frontier-Modell zu senden.

Das Betrachten der Kosten pro Aufruf allein verfehlt diesen Effekt. Die Eskalationsrate muss zusammen mit ihr verfolgt werden.

Strategische Erkenntnisse für Entwickler-Teams

Eine intelligente Weiterleitung ist nicht nur ein Nice-to-Have für reife AI-SQL-Deployments, sondern ein Muss für langfristige. Teams, die dies übergehen, tauschen ein Budgetproblem, das nicht gelöst werden kann, gegen ein Architekturproblem, das gelöst werden kann. Die Muster sind da; das Einzige, was noch zu entscheiden ist, ist, welche zuerst zu befolgen sind.

Beginnen Sie mit dem Klassifizierer, nicht mit den Modellen. Die Weiterleitungsschicht entscheidet, ob alles andere funktioniert. Ein gut abgestimmter hybrider Klassifizierer wird Ihnen die meisten Kosteneinsparungen bieten, ohne die Dinge zu kompliziert zu machen.

Verwenden Sie den schemabewussten Kontext der Feed, um die Klassifizierungsentscheidungen zu unterstützen. Für SQL-Workloads, die Beziehungen zwischen mehreren Tabellen oder schema-spezifische Argumentation erfordern, reicht die Abfragestruktur allein nicht aus. Partielle Schemameta-Daten zur Klassifizierungszeit erhöhen die Stufengenauigkeit erheblich.

Verwenden Sie die Eskalationsrate als Hauptqualitätssignal. Sie findet Fehlklassifizierungen schneller als jedes andere Metrik und zeigt genau, wo der Klassifizierer verbessert werden muss.

Planen Sie die Validierungsschicht, bevor Sie den Klassifizierer planen. Das Wissen, wie ein Fehler aussieht und was eine Eskalation verursacht, macht die Weiterleitungslogik sauberer und das System besser in der Lage, Randfälle zu verarbeiten.

Der Wert der Weiterleitungsschicht steigt, nicht sinkt, wenn Open-Source-Modelle besser werden und die Kosten für lokale Inferenz sinken. Billigere Modelle der Stufe 1 machen die Kostenlücke zwischen den Stufen größer, was eine korrekte Klassifizierung wertvoller macht. Die Weiterleitungsarchitektur, die heute aufgebaut wird, wird für lange Zeit nützlich sein, nicht nur als schnelle Lösung.