セマンティックメタデータのカスタマイズ

  • リリースバージョン: Australia
  • 更新日 2026年04月17日
  • 所要時間：6分

    • セマンティックメタデータ (説明、ラベル、使用方法) は、 クエリ生成 が自然言語の質問をどのように解釈するかを制御します。これらのメタデータをカスタマイズして、組織の用語とデータの精度を向上させます。

    セマンティックレイヤーのエンティティ (テーブル) とディメンション (フィールド) の両方に、質問を処理するときに クエリ生成 使用する 3 つのメタデータフィールドがあります。

    セマンティックラベル
    エンティティまたはディメンションの短縮名またはエイリアス。ユーザーの質問がデフォルトのフィールドラベルと一致しない場合に、AI 検索が正しいテーブルまたはフィールドを識別するのに役立つ検索キーワードとして機能します。
    セマンティックな説明
    エンティティまたはディメンションがビジネス用語で表す内容の自然言語記述。システムが類似のテーブルまたはフィールドを区別するのに役立つコンテキストを提供します。
    セマンティックな使用方法の説明
    エンティティまたはディメンションが選択されたときに LLM プロンプトに直接挿入される指示。データのクエリ方法 (たとえば、使用する演算子、省略形の処理方法、階層値を展開する方法など) をシステムに指示します。

    カスタマイズするタイミング

    メタデータは自動生成され、ベースライン状態で正常に機能します。一貫性のある反復可能な問題が確認された場合にのみカスタマイズしてください。

    • 間違ったテーブルが選択されたか、テーブルが見つからない — 説明とラベルを編集
    • 間違ったフィールドが選択されているか、フィールドがありません — 説明とラベルを編集
    • 組織が自動生成されたラベルとは異なる用語を使用しています — ラベルの編集
    • 正しいテーブルまたはフィールドが選択されているが、クエリが正しく構築されていない — 使用方法の説明を編集する
    注:
    何千もの次元があります。それらすべてを確認しようとしないでください。失敗したクエリに表示されるフィールドにフォーカスします。

    メタデータをカスタマイズする 2 つの方法

    2 つの方法が利用可能です。構成テーブルの編集がデフォルトのアプローチと見なされます。

    表 : 1. メタデータのカスタマイズ方法
    方法 (Method) テーブル 使用するタイミング
    [セマンティックテーブル構成] テーブルと [セマンティック列構成] テーブルのレコードを編集します セマンティックテーブル構成 [sn_query_gen_table_config] とセマンティック列構成 [sn_query_gen_column_config] 更新セットと互換性があります。カスタマイズは更新セットに含め、インスタンス間で転送できます。エンティティテーブルおよびディメンションテーブルで設定された値を上書きします。エンティティとディメンションの説明、およびディメンションの使用手順をサポートします。エンティティラベルや使用方法についてはサポートしていません。
    エンティティテーブルおよびディメンションテーブルのレコードを編集します エンティティ [sn_query_gen_entity] およびディメンション [sn_query_gen_dimension] よりシンプル。単一インスタンスでのテストに適しています。これらのカスタマイズはインスタンス間で転送することはできません。ただし、これはエンティティラベルとエンティティレベルの使用手順を変更する唯一の方法です。アップグレードによるテーブルの更新によって上書きされる可能性があります。
    注:
    どちらの方法でも sn_query_gen.admin 以上のロールが必要です。

    効果的な説明を書く

    セマンティックな説明とラベルを記述するときは、次のガイドラインに従ってください。

    • 説明は、ユーザーがこのデータを参照する方法に焦点を当てた 1 〜 2 文にしてください
    • ユーザーが言う一般的な同義語と略語を含める
    • 完全な段落は避けてください。簡潔な説明は、冗長な説明よりもマッチングします

    効果的な使用方法の記述

    セマンティックな使用方法の説明を記述するときは、次のガイドラインに従ってください。

    • 具体的かつ構造化してください。ルール、例、エッジケースを含める
    • ロジックが複雑な場合は、番号付きのステップまたはラベル付きのセクションを使用します
    • ユーザーの質問例とクエリの外観を含めます
    • フリーテキストフィールドの場合は、一致戦略 (CONTAINS、完全一致) と拡張ルールを指定します
    • 1 つのエンティティまたはフィールドのニーズに焦点を当てた指示を維持する

    使用方法とセグメント

    使用手順では、フィールドを動的にクエリする方法を LLM に学習し、LLM がルールに基づいて多くのシナリオを処理できるようにします。セグメントは特定のフィルター値をハードコードします。自由形式の場所などのフィールドでは、使用可能なすべての場所クエリを事前に定義することはできないため、使用方法が正しいアプローチです。セグメントは、「Sev1」= 優先度 1 などの固定ビジネス用語に適しています。

    セマンティックな説明

    インシデントエンティティの場合は、「インシデントテーブル」だけを使用する代わりに、「IT インシデント、機能停止、サービス中断、IT サポートチケット」などの説明を使用して、ユーザーが実際に言う用語を含めます。

    使用方法におけるデータ規則

    略語を格納する State フィールドの場合:

    "Values in this field may be full state names or two-letter abbreviations (for example, 'California' or 'CA'). Always query for both forms. For country names, also include common aliases (for example, 'United Kingdom' OR 'UK')."

    使用説明の複雑なクエリロジック

    これらの使用手順は、階層展開と同義語処理が行われたフリーテキストの [おおよその位置] フィールド用です。

    フィールド:おおよその場所:使用手順
    [おおよその位置] フィールドは、正規化されていないフリーテキストの文字列です。すべてのクエリーでは、大文字と小文字を区別しない CONTAINS 照合を使用し、階層展開を処理する必要があります。
    コアクエリロジック
    1. 地理的エンティティ (近隣、市区町村、都道府県、国、地域、または大陸) を識別します。
    2. クエリを実行する前に、より広範なエンティティをサブエンティティの明示的なリストに展開します。
    3. すべての展開された用語と同義語に OR ロジックを使用します。
    拡張ルール
    • 大陸:その大陸内のすべての主要国のリストに展開します。
    • 地域:関連する州または国に展開します (たとえば、「大西洋岸」 - ノースカロライナ州、バージニア州、フロリダ州など>)。
    • 州/都道府県:フルネームと標準の略語 (「ノースカロライナ」や「ノースカロライナ州」など) の両方を含めます。
    • 国: 一般的なエイリアスを含めます (例:「UK」または「United Kingdom」)。
    実装パターン
    1. 地理的インテントを抽出します。
    2. エンティティレベルを分類します。
    3. 下向きに展開するか (大陸>国)、同義語を含めます (州>略称)。
    4. OR ベースの CONTAINS フィルターを使用して単一のクエリ文字列を作成します。

    指示によってルールと例が定義され、LLM は指定したルールに基づいて多くの関連クエリを動的に処理できるというパターンに注目してください。ロジックを一度教えると、モデルはそれを任意の入力に適用します。

    クエリに変換されたユーザーの質問の例
    • ユーザー: 「日本のものを見せてください」 →クエリ: 場所 「日本」を含む

    • ユーザー: 「アジア諸国を教えてください」 → 分解: アジア -> [日本、中国、インドネシア...] →クエリ: 場所に「日本」が含まれているか、場所に「中国」が含まれているか、場所に「インドネシア」が含まれています...

    • ユーザー:「ノースカロライナ州のものを表示」 →クエリ:場所に「ノースカロライナ」を含む、または場所に「NC」を含む
    • ユーザー:「ヨーロッパのすべてを表示」 → 分解:ヨーロッパ > [英国、スペイン、フランス、ドイツ...] →クエリ: 場所に「英国」が含まれているか、場所に「英国」が含まれているか、場所に「スペイン」が含まれているか、場所に「フランス」が含まれています...