AI SQLアシスタントのスマートなクエリルーティング：質を犠牲にせずコストを削減する方法

SQLアシスタントが複雑なクエリを処理するロケットのように想像してください。ただし、ある日、ロケット燃料を使用して買い物リストを取得していることに気付きます。

それは興奮するものですが、燃料代が請求されるようになると、シンプルな買い物にはロケットが必要ないことがわかります。同じことが、基本的なルックアップからマルチスキーマ分析まで、すべてのSQLリクエストを同じ高性能AIモデルにルーティングする場合にも起こります。

AI SQLアシスタントを取得するプロセスは通常同じです。最初、生産性は向上します。クエリはより迅速に実行され、ボイラープレートコードはなくなり、開発者はルーチンSQLクエリの作成に費やす時間が減ります。ただし、チームがそれを使用するにつれて、クエリの数が増え、インフラストラクチャの請求書が来ると、経済性が変わります。

問題は、ビルの構造にあります。実行計画、スキーマ、複雑なクエリ論理を考慮できるフロンティアAIモデルを実行することは、高価です。そのコストは、難しいタスクには適しています。ただし、シンプルなSELECT文やCRUD操作に使用する場合は、無駄になります。

しかし、解決策はモデルを低下させることではありません。クエリを適切な場所に送信することです。スマートクエリルーティングは、各リクエストを難易度別に分類し、適切なモデル階層に送信します。この方法により、SQLワークロードの推論コストを40〜70%削減できます。

この記事では、そのアーキテクチャのしくみについて説明します。SQLの複雑さを分類し、分類およびルーティングパイプラインを構築し、システムが稼働している場合の実際のコストと品質のトレードオフを測定します。これらのパターンは、dbForge AIアシスタントのスキーマ認識AI機能を開発したときの教訓を反映しています。

一つのモデルではすべてのSQLタスクをカバーできない理由

すべてのSQLクエリは、複雑さの点で同じではありません。主キーでユーザーを取得するクエリと、複数のスキーマにわたるセッションファネルを再構築するクエリは、どちらもSQLですが、生成するために必要な推論は非常に異なります。

システムがそれらを同じように扱うと、予想通りの結果が得られます。計算リソースの浪費です。ほとんどのエンタープライズワークロードでは、ほとんどのクエリはルーチンです。シンプルなルックアップ、シングルテーブルリード、基本的な挿入、シンタックス修正など、複雑なものはありません。すべてのクエリをフロンティアモデルに送信することは、貨物用エレベーターでノートブックを運ぶようなものです。

クエリを複雑さ別に分類する方法の1つは、次のとおりです。

階層間のコスト差は大きいです。階層1のクエリのコストは、軽量モデルでは約0.001ドルです。一方、同じクエリをフロンティアモデルに送信すると、約0.03ドルかかります。1日10,000クエリの場合、10ドル対300ドルとなり、30倍の差になります。ルーティングの決定によってのみです。

スキーマ認識もここで重要になります。階層3のクエリは、単に計算リソースが必要なだけでなく、コンテキストも必要です。テーブル関係、外部キー、インデックス、データベース固有のシンタックスなどです。このコンテキストは、推論中に注入する必要があります。

シンプルな階層1クエリを同じ重いパスで実行すると、トークンが無駄になり、待ち時間が長くなり、結果は改善されません。

モデル選択のための実用的なアーキテクチャ

ルーティングシステムには、通常、4つの段階があります。分類、ルーティング、実行、検証です。各段階には異なる役割があり、異なる方法で失敗する可能性があります。システムを構築する前に、それらを個別に考えることが役立ちます。

分類は最も重要なステップです。クラシファイアは、生のSQLクエリまたはそれを生成する自然言語プロンプトを受け取り、複雑さの階層に割り当てます。クラシファイアを構築する一般的な方法は3つあります。

ルールベースの分類 は、正規表現パターンとAST（抽象構文木）パーサーを使用して、構造的な信号を検出します。テーブル数、ネストの深さ、ウィンドウ関数、サブクエリ、集約演算子などです。このアプローチは高速で予測可能であり、ほぼオーバーヘッドはありません。シンプルなSELECT文や基本的なDMLの場合、モデルを使用せずに通常識別できます。

軽量のクラシファイアモデル は、SQLの複雑さを推定するためにトレーニングされた小さな言語モデルを使用します。これにより、追加のステップが必要になりますが、これはパイプライン全体で最も高いROIの決定の1つです。クラシファイアのコールは約0.0001ドルかかる可能性がありますが、これは0.03ドルのフロンティアモデルコールを避けるのに十分です。

多くのセットアップでは、これらの軽量モデルはローカルで実行できるため、シンプルなユーザークエリのコストを完全に削減できます。また、SQLが生成される前に自然言語プロンプトを分類することもできます。これは、クエリがまだ存在しないアシスタントワークフローで役立ちます。

ハイブリッド分類 は、ルールベースのロジックとクラシファイアの両方を組み合わせます。明確なケースはゼロコストでルールベースのロジックで処理され、クラシファイアは曖昧な中間ケース、つまり複雑さが中程度のクエリを処理します。

ルーティング は、分類の後に発生します。ただし、階層だけが要因ではありません。クエリをどこに送るかを決定する他の要因もあります。これらには、次のものがあります。

1. スキーマコンテキストの要件。 一部のクエリでは、モデルが外部キー関係、インデックス、またはその他の構造的な詳細を理解する必要があります。これらのクエリには、より多くのコンテキストが含まれており、通常、より高度な能力を持つモデルにルーティングする必要があります。
2. 待ち時間の許容度。 ユーザー向けの機能、たとえば自動補完やインラインの提案には、厳格な待ち時間の予算があります。バックグラウンドタスクには通常、待ち時間の許容度がありません。そのような場合は、遅くてもより高度なモデルを使用できます。
3. 信頼度のしきい値。 一時的に、クラシファイアは階層について確信が持てない場合があります。そのような場合、ルーティングを上位に設定するのが一般的に安全な選択です。ダウングレードが不正解の場合、クエリが悪くなり、再試行が発生する可能性がありますが、これは最初からより強力なモデルを使用した場合よりもコストが高くなります。

検証レイヤーは、コードが実行された後に実行されます。その役割は、ルーティングのミスをユーザーに到達する前に検出することです。実行の後、シンタックスが正しいこと、結果が妥当であること（行の形状が正しいことを返したか）、スキーマが一貫していることを確認します。結果が検証に失敗した場合、システムは階層を上に移動し、クエリを再度実行します。

Devartでは、dbForge AIアシスタントのルーティングの精度を正しく取得するために最も重要なことは、分類の決定にスキーマ認識コンテキストを組み込むことでした。スキーマコンテキストなしでは、不明確なテーブル名を使用するクエリや暗黙の関係に依存するクエリは常に誤分類され、処理できないより安価なモデルに送信されていました。解決策は、クラシファイアにクエリ構造だけでなく一部のスキーマメタデータを提供することでした。

重要なものを測定する：実践におけるコストと品質のトレードオフ

ルーティングのビジネス上の理由は、品質が維持される場合にのみ有効です。品質が低下し、再試行が増えたり、開発者の信頼が低下したりするコスト削減は、節約ではありません。インフラストラクチャの請求書からエンジニアリング時間へのコストの転嫁です。ルーティングシステムが実際に機能しているかどうかを判断する3つのメトリックがあります。

各階層のクエリあたりのコスト は、ベースラインを確立します。各階層の実際の支出を個別に追跡し、平均を混ぜないでください。平均を混ぜると、ルーティングが機能しているかどうかがわかりません。50%のクエリを誤った階層にルーティングするシステムは、平均コストが低く表示されますが、結果は悪くなります。

品質スコア は、正確性、完全性、SQLのベストプラクティスに従っているかどうかを確認します。エスカレーション率は、最も直接的な信号です。Tier 1またはTier 2モデルが検証に合格しない出力を生成し、別の場所に送信する必要がある頻度を示します。システムが適切に調整されている場合、エスカレーション率は5%以下に抑える必要があります。クラシファイアをこのレベル以上で再トレーニングする必要があります。構造的な信号を誤解している可能性があります。必要なスキーマコンテキストが不足している可能性もあります。

待ち時間の影響 は、応答が1つの階層から別の階層に移動するのにかかる時間を調べます。分類に必要な追加の時間も含みます。ユーザーは、ルーティングレイヤーを介したインタラクションに50〜100ミリ秒の遅延しか感じないはずです。分類自体が問題になると、ハイブリッドアプローチ（明確なケースにはルール、不明確なケースにはクラシファイアのみ）を使用して、精度を失うことなく解決できます。

現実では、適切に調整されたルーティングシステムは、推論コストを40〜60%削減し、エスカレーション率を5%以下に抑え、複雑なクエリの出力品質を維持できます。70%以上削減するには、通常、Tier 1タスクを小さいモデルで自分で実行する必要があります。那も有効ですが、複雑さが増えるため、すべてのチームが対処することを望むわけではありません。

「エスカレーションタクシー」も考慮する必要があります。ルーティングが安いモデルに厳しすぎると、システムは全体としてより多くの作業を実行する可能性があります。クラシファイアのコール、初期モデルのコール、検証の失敗、ルーティング、2回目のモデルのコールなどです。場合によっては、これは最初からフロンティアモデルに質問を送るよりもコストがかかる可能性があります。

コールあたりのコストのみを確認すると、この効果は見落とされます。エスカレーション率を追跡する必要があります。

エンジニアリングチームのための戦略的収穫

スマートルーティングは、長期的なAI SQLデプロイメントにとって必要なものです。ルーティングを省略するチームは、解決できない予算の問題と解決可能なアーキテクチャの問題を交換します。パターンはあります。残っているのは、どのパターンに従うかを決定することだけです。

クラシファイアから始めましょう。ルーティングレイヤーは、他のすべてが機能するかどうかを決定します。適切に調整されたハイブリッドクラシファイアは、複雑さを増やさずにほとんどのコスト削減を提供します。

分類の決定を支援するために、フィードのスキーマコンテキストを使用します。複数のテーブル間の関係やスキーマ固有の推論を含むSQLワークロードの場合、クエリ構造だけでは不十分です。分類時に部分的なスキーマメタデータを提供すると、階層の精度が大幅に向上します。

エスカレーション率を主な品質信号として使用します。分類のミスを他のメトリックよりも迅速に検出します。クラシファイアを改善する必要がある場所を示します。

クラシファイアの前に、検証レイヤーを計画します。失敗の兆候とエスカレーションの原因を理解すると、ルーティングロジックがよりクリーンで、システムがエッジケースに対処する能力が向上します。

ルーティングレイヤーの価値は、オープンソースモデルが改善され、ローカル推論のコストが下がるにつれて、上昇します。安価なTier 1モデルは、階層間のコスト差を拡大し、正確な分類をより貴重にします。今日構築されるルーティングアーキテクチャは、短期的な解決策ではなく、長期にわたって役立つものです。