クエリ生成セマンティックレイヤーのセグメント

  • リリースバージョン: Australia
  • 更新日 2026年03月12日
  • 所要時間:9分
  • セグメントは、ビジネス用語を特定のクエリフィルターにマッピングする事前定義されたフィルター条件であり、セマンティックレイヤーが自然言語の質問を正確なデータベースクエリに変換するのに役立ちます。

    セグメントは、セマンティックレイヤーが正しいエンティティ、ディメンション、および値を選択するのに役立つ、自明ではないコンテキストを提供します。たとえば、「オープンな緊急変更要求はいくつありますか?」という発言では、「オープン」が「アクティブ=true」を意味し、「緊急」が優先度ではなくタイプであることをセグメントが識別します。

    ユーザーが質問すると、クエリ生成エンジンは一致するセグメントを検索し、そのフィルターを LLM プロンプトに含めるため、モデルがそれらを再利用して正確なクエリを構築できます。

    セグメントには次の 2 つのタイプがあります。

    自動セグメント
    レポート、ダッシュボード、フィルター、モジュール、およびインジケーターソースからシステム生成。多くの場合、名前は「Incidents.Open」のように技術的なものです。
    手動セグメント
    手動セグメント構成テーブルを介して管理者によって作成されました。名前は分かりやすいものです (例:「重大なオープンインシデント」)。手動セグメントは、自動同期機能を備えた 2 つのテーブルからなるデータモデルを使用し、プラグインを介してアプリケーションとともに出荷できます。
    表 : 1. 比較:手動セグメントと自動セグメント
    手動セグメント 自動セグメント
    作成者 アドミン、更新セット経由で提供 レポート、ダッシュボード、フィルター、モジュールからシステム生成
    名称の品質 ユーザーフレンドリー、検索用に調整済み 多くの場合、「Incidents.Open」などの技術的なもの
    検索の優先度 自動化に比べて 5% ブースト (sn_query_gen.segments.manual_segment_scale_factorで調整可能) 標準採点
    LLM 処理 無関係でない限り、すべてのフィルターを保持します 各フィルターを個別に批評する
    プロンプトラベル user_defined_segment automated_segment
    ライフサイクル アドミンによるフルコントロール ソースレコードに関連付けられたアクティビティ/使用状況
    アプリに付属 はい (更新セット) いいえ (実行時に生成)

    セグメントの仕組み

    システムは AI 検索を使用して、ユーザーのクエリと意味的に類似したセグメントを検索します。AI 検索は、セグメントテーブルの [名前]、[説明]、[エンティティ]、および [フィルター] フィールドにインデックスを付け、それらをユーザーのクエリと比較して、関連するセグメントのサブセットを生成します。

    LLM コールでは、システムによって名前、説明、エンティティ、およびフィルターが渡されます。LLM は、新しいクエリを生成するための構成要素としてセグメントを使用します。たとえば、ユーザーが「サンディエゴにある未アサインのインシデント」と尋ね、「未アサインのインシデント」セグメントが LLM に渡された場合、LLM はセグメントのフィルターを開始点として使用し、セグメントの上に場所フィルター「サンディエゴ」を添付します。

    表 : 2. セグメントプロセスサマリー
    ステップ 目的 出力
    1:入力 ユーザーの自然言語クエリをキャプチャする 生のクエリテキスト
    2:検索 意味的に類似した構築済みセグメントを検索する 関連セグメントのサブセット
    3:採点 セマンティック類似性スコアに基づいて関連するセグメントのセットをランク付けします ランク付けおよびソートされている関連セグメントのサブセット
    4:コンテキスト セグメントメタデータを LLM に提供 構造化セグメントデータ
    5:生成 セグメントロジックと新しい条件の組み合わせ 実行可能クエリを完了

    手動セグメントの仕組み

    手動セグメントは、クエリ時に次の 2 つのロールを果たします。

    エンティティディスカバリー
    以前のコンテキストがない初回クエリでは、セグメント一致によってエンティティリストのエンティティを追加または強化できます。手動セグメント名との照合は、候補リストでエンティティを追加またはブーストすることで、目的のエンティティを識別するのに役立ちます。ユーザーが「重大なオープンインシデントを表示」と尋ね、インシデント [incident] テーブルに「重大なオープンインシデント」という名前の手動セグメントが存在する場合、 インシデント エンティティが結果で強化されます。
    プロビジョニングをフィルタリング
    一致するセグメントは、LLM プロンプトコンテキストに合わせてフォーマットされます。LLM には以下が表示されます。
    **Related Segments**:
    - **Critical Open Incidents** (user_defined_segment)
      - description : High priority incidents that are open and unresolved
      - entity : incident
      - filter : { conditions : [{"field":"incident.priority","operator":"=","value":"1"}, ...] }
    LLM は、クエリの構築時に、セグメントのフィルターを完全に再利用するか、部分的に再利用するかを決定します。手動セグメントはプロンプトで「 user_defined_segment 」とラベル付けされ、完全に無関係でない限りすべてのフィルターを保持するように LLM に指示します。

    手動セグメントスコアリングブースト

    手動セグメントの優先度が強化されます。エンジンは、関連するセグメントを検索するときに、セマンティック類似性 (セグメントの名前と説明がユーザーの質問とどの程度一致しているか) によって各結果にスコアを付けます。デフォルトでは、手動セグメントは、生の類似性スコアに加えて 5% のブーストが適用されます。

    ブースト係数は、システムプロパティ sn_query_gen.segments.manual_segment_scale_factorを使用して構成できます。たとえば 1.10 に増やすと、手動セグメントがより強力に昇格します。1.0 に設定すると、ブーストが完全に削除されます。

    実際には、自動セグメントの名前がユーザーの発話と部分的に一致することがよくあります。たとえば、「オープンインシデント」というレポートは、「重大なオープンインシデント」と呼ばれる手動セグメントと同様にスコアを付けることができます。強化により、手動でドメイン調整されたセグメントが、両者が近い場合に、システム生成セグメントよりも先に表示されるようになります。

    セグメントスコアリングの仕組み

    1. AI 検索 は、各候補セグメントの生のセマンティック類似性スコア (0.0 〜 1.0) を返します。
    2. 一致しきい値 (デフォルトは 0.70) を下回るセグメントは破棄されます。
    3. 手動セグメントスコアには尺度係数が乗算されます (デフォルトは 1.05)。
    4. 結果はブーストスコアでソートされ、結果制限で制限されます。

    自動セグメントソース

    既存のデータソースからスケジュールに従ってセグメントが自動生成されます。クエリ生成同期セグメントジョブはセグメントを自動的に作成し、インストール時に実行され、デフォルトでは毎週実行されます。

    表 : 3. 自動セグメントソース
    ソース プルする内容
    保存されたレポート (sys_report) 最近表示したレポートのレポートフィルター
    レポートソース (sys_report_source) アナリティクスデータソースフィルター
    PA インジケーター (pa_cubes) パフォーマンスアナリティクスインジケーターの条件
    保存済みフィルター (sys_filter) グローバル保存フィルターのみ (ユーザー固有およびグループ固有のフィルターを除く)
    アプリモジュール (sys_app_module) モジュールレベルのリストビューフィルター

    自動セグメントルール

    古いセグメントや無関係なセグメントからのノイズを減らすために、ジョブは特定のルールに従います。レポート、レポートソース、またはインジケーターソースに基づくセグメントは、レコードが特定の基準を満たしている場合にのみアクティブになります。

    • レポートは共有され、アナリティクスマネージャーロール (admin、dashboard_admin、report_admin、pa_admin、またはviz_admin) を持つユーザーによって作成され、最近 (デフォルトでは 180 日以内) 実行されている必要があります。
    • レポートソースは、データの可視化に含めるか、最近実行されたレポートで使用する必要があります。
    • インジケーターソースは、スコアが最近変更されたインジケーターにリンクする必要があります。
    重要:
    ドメインセパレーションされたインスタンス上のインジケーターソースまたはモジュールからセグメントを作成することはできません。

    レポートの場合、「最近実行」は sn_query_gen.segments.reports.last_viewed_threshold_days システムプロパティによって定義されます。デフォルト値は 180 日です。

    インジケーターソースの場合、「最近の変更」のタイムスパンはインジケーターの頻度によって異なります。

    • 日次:過去 7 日間
    • 週次:過去 30 日間
    • 隔週:過去 30 日間
    • 月次:過去 90 日間
    • 4 週間:過去 90 日間
    • 隔月:過去 90 日間
    • 四半期ごと:過去 180 日間
    • 会計四半期ごと:過去 180 日間
    • 6 か月:過去 12 か月
    • 年次:過去 24 か月間
    • 会計年度ごと:過去 24 か月

    インジケーターソースのタイムスパンを変更するには、 sn_query_gen.segments.indicator.inactivity_threshold_multiplier システムプロパティを使用して乗数を適用します。値は整数である必要があります。つまり、期間を長くするだけで、短縮することはできません。

    セグメントソースの無効化

    セグメントの作成は、全体で無効にすることも、個々のソースタイプに対して無効にすることもできます。トラブルシューティングのために、またはソースからのセグメントが「ノイズあり」である場合は、セグメント生成を無効にすることができます。各ソースタイプには、対応する sn_query_gen.segments.disable.* システムプロパティがあります。対応するシステムプロパティを true に設定して、そのソースのセグメントを無効にします。そのタイプのソースから作成されたすべての既存のセグメントは、 AI データエクスプローラー 検索結果から除外されます。そのタイプの新しいセグメントは作成されません。次のセグメント同期ジョブ中に、そのタイプのすべてのセグメントが非アクティブ化されます。詳細については、「クエリ生成プロパティ」を参照してください。