メインコンテンツまでスキップ

REFERENCE

開発者リファレンス

認証、API、SDK、Flow Agent のプロセッサ、パラメータ解決のリファレンスです。

LLM Query Database

自然言語の質問をモデルに渡して SQL を生成・実行し、結果と SQL の両方を変数に格納します。

LLM Query Database は自然言語の質問を SQL に変換して実行するプロセッサーです。型は llm-query-database です。

  1. 基本的な使い方​

    設定された質問を指定の言語モデルに渡し、モデルは意味モデル（Semantic Layer）が記述する構造に基づいて SQL を生成します。その SQL を実行し、結果と生成された SQL の両方を指定の変数に書き込み、後続のプロセッサーで利用できるようにします。

    SQL プロセッサーとの違いは、誰が SQL を書くかです。SQL プロセッサーは文をあらかじめ用意する必要があり、条件が固定された検索に向きます。LLM Query Database はモデルがその場で文を生成するため、質問がユーザーから来て事前に列挙できない場合に向きます。

    LLM Completion に意味モデルを掛ける方法と比べると、このプロセッサーの範囲は狭く、「質問を SQL に変換して実行する」一回のみを行います。多段の推論も他のツールの呼び出しもないため、結果は予測しやすくなります。

    このプロセッサーは Workflow CRD からのみ設定できます

    Odin の Flow Agent のビジュアルエディターには llm-query-database のノードがなく、キャンバスのノードメニューにも現れません。利用するには Workflow CRD を直接記述します。

    Workflow.spec.processors[].type の有効な値は CRD で定義されており、llm-query-database はその一つです。

  2. 設定のしかた​

    Workflow CRD の spec.processors に宣言します。

    apiVersion: asgard-ai.com/v1alpha1
    kind: Workflow
    metadata:
      name: wf-sales-question
    spec:
      variables: []
      entries:
        - name: entry-main
          handlingProcessor: proc-ask
      exits: []
      processors:
        - name: proc-ask
          type: llm-query-database
          labels:
            display_name: 自然言語での検索
          configs:
            - name: semanticLayer
              value: sl-retail-pos
            - name: query
              expression: prevMessage
            - name: resultField
              value: queryResult
            - name: completionModel
              value: cm-builtin-balanced
            - name: maxTokens
              value: "4096"

    各 config は value、expression、template のいずれか一つだけを使います。これは CRD の階層で強制されています。

  3. 設定項目​

    semanticLayer（必須）​

    問い合わせる意味モデルの名前です。モデルはその意味モデルが記述するテーブルと列の構造から SQL を生成するため、意味モデルの範囲がこのプロセッサーの答えられる範囲になります。

    query（必須）​

    SQL に変換する自然言語の質問です。実務では expression でユーザーの質問を渡します。詳しくはExpression の概要 — 値の取得を参照してください。

    resultField（必須）​

    結果を受け取る変数の名前です。結果は JSON オブジェクトで、検索結果とモデルが生成した SQL の両方を含みます。

    SQL も一緒に返る点はデバッグで役立ちます。結果が期待と異なるとき、実際にどの文が実行されたかを確認でき、問題が意味モデルの記述にあるのか、質問の表現にあるのかを判断できます。

    completionModel（必須）​

    SQL を生成する言語モデルの名前です。

    maxTokens（必須）​

    モデルが生成する内容の token 上限です。

    temperature​

    モデルのランダム性です。SQL の生成は正確さが求められる作業なので、通常は低い値にして文のばらつきを抑えます。

  4. 接続関係​

    success​

    SQL の生成と実行が完了すると、この接続点から次へ進み、結果は resultField の変数に入ります。

    failure​

    モデルが妥当な SQL を生成できない場合、または SQL の実行が失敗した場合、この接続点から続き、prevError 変数にエラー情報が入ります。

  5. 注意事項​

    1. SQL の正しさは、意味モデルの列の説明の質でほぼ決まります。名前が曖昧だったり説明が欠けていると、モデルは誤ったテーブルを選びがちです。

    2. failure の分岐を接続してください。意味モデルの範囲外の質問ではこのプロセッサーは失敗し、開放的な質問ではそれが頻繁に起こります。

    3. ビジュアルに編集する必要があるワークフローでは、あらかじめ文を用意した SQL プロセッサー、または意味モデルを掛けた LLM Completion を使ってください。どちらも Flow Agent エディターにノードがあります。

始める準備はできましたか？

Asgard をチームでどう活用できるか、お気軽にご相談ください。

お問い合わせ