手動セグメントの作成

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

    • 手動セグメントは、クエリ生成セマンティックレイヤーの自然言語の質問とデータベースフィルターを橋渡しするわかりやすい名前を持つ、アドミンが作成した保存済み検索です。

    始める前に

    必要なロール:sn_query_gen.admin 以上

    このタスクについて

    手動セグメントを使用して、ドメイン固有の保存済み検索をアプリケーションとともに送信します。検索中に、自動セグメントよりも優先的にブーストされます。このブーストは sn_query_gen.segments.manual_segment_scale_factorに設定されています。LLM は無関係でない限りすべてのフィルターを保持しますが、自動セグメントフィルターは個別に批判されます。

    次の状況では、手動セグメントを作成します。
    • 組織には、特定のフィルターにマップする標準の用語があります (「Sev1」、「VIP」、「期限切れ」など)
    • ユーザーが同じフィルター済みの質問を繰り返し行っても、システムが自動的に適切なフィルターを選択しない
    • フィールド値だけでは推測できないビジネスロジックをエンコードする場合 (たとえば、「リスクのあるアカウント」= 複数の条件の組み合わせ)
    • 組織の特別な用語がフィルター条件に正確に翻訳されていません
    ヒント:
    名前と説明は、AI 検索が照合するものです。ユーザーが言う自然な表現を使用します。コンセプトごとに 1 つのセグメントを保持します。質問をし、セグメントがログに表示されるかどうかを確認してテストします。

    セグメント名を作成するときは、ユーザーが質問するときに使用するのと同じ言語を使用します。名前は、セマンティック検索中に LLM が照合するプライマリフィールドです。略語、内部コード、または専門用語は避けてください。このセグメントが回答する質問に対してユーザーがどのように表現するかを考えてみましょう。

    命名のガイドライン

    セグメント名と説明を作成するときは、次のガイドラインに従ってください。

    分かりやすい言葉を使用
    ユーザーが質問するときに使用するのと同じ言語で名前を記述します。ユーザーが認識できないような技術的な略語や内部コードは使用しないでください。
    ユーザーの立場で考える
    ユーザーがこのデータに関する質問をどのように表現するかを考えてみましょう。セグメント名は自然言語パターンと一致する必要があります。
    具体的かつ明確にする
    名前は、対象者が理解できるように、類似のセグメントと区別できる十分な説明性を付加する必要があります。
    コンテキストの説明を使用
    セグメント名があいまいな場合は、[説明] フィールドを使用して、一般的に使用される用語を使用して追加のコンテキストを提供します。

    手順

    1. 移動先 クエリ生成 > アドミニストレーション > 手動セグメント構成.
    2. [ 新規] を押します。
    3. [手動セグメント構成] フォームで、次の情報を入力します。
      表 : 1. 手動セグメント構成フォーム
      フィールド 説明
      テーブル名 セグメントが適用されるテーブル (エンティティ)。セマンティックレイヤーにアクティブなエンティティが必要です。最初にエンティティテーブルが検索され、次にそのテーブル内のセグメントが検索されます。
      名前 ユーザーが質問するときに使用する分かりやすい言葉でセグメントを説明する分かりやすい名前。ユーザーが質問するときに使用するのと同じ言語を使用します。略語、内部コード、または専門用語は避けてください。最大 255 文字。例:「P1_OPEN_INC」(不満) の代わりに「重大なオープンインシデント」(良好)、「アクティブな福利厚生 HR ケース」(不満) の代わりに「アクティブな福利厚生 HR ケース」(良好)
      説明 オプションですが、強くお勧めします。セグメントが関連しているかどうかを判断するための追加のコンテキストを LLM に提供します。よく使用される用語を使用し、セグメントがキャプチャする内容を説明します。類似のセグメントの曖昧さを解消するのに役立ちます。最大 4,000 文字。例:「現在オープンで未解決の高優先度のインシデント。すべてのアサイン先グループが含まれます。エグゼクティブダッシュボードとエスカレーションレポートに役立ちます。(良い) ではなく、「優先度 1 のフィルター」(不満) になっています。
      フィルター セグメントのフィルター条件を定義するエンコードクエリ。条件ビルダー (v2) を使用します。最大 4,000 文字ですが、2,000 文字を超えるフィルターは LLM プロンプトで切り捨てられる場合があります。
      有効 システムがセグメントを使用するかどうか。デフォルトは選択済みです。オフにすると、セグメントは非アクティブ化され、検索から除外されます。
    4. [送信] を押します。
      ビジネスルールが非同期に実行され、検索時にクエリーされる sn_query_gen_segment テーブルにレコードが同期されます。

    タスクの結果

    手動セグメントはアクティブで、 クエリ生成 検索に使用できます。

    インシデントテーブルの手動セグメント

    次の例は、 インシデント テーブルに対して適切に作成された手動セグメントを示しています。

    表 : 2. 手動セグメントの例
    名前 説明 テーブル フィルター
    最重要のオープンインシデント 現在オープンで未解決の高優先度のインシデント。すべてのアサイン先グループが含まれます。 インシデント priority=1^state!=7^state!=8
    自分のチームの期限切れインシデント 現在のユーザーのグループに割り当てられた、SLA 期日を過ぎたインシデント。 インシデント assignment_group=javascript:getMyGroups()^sla_due<javascript:gs.nowDateTime()^state!=7
    最近の P1 および P2 エスカレーション 過去 7 日間にエスカレートされた優先度 1 および 2 のインシデント。 インシデント priority<=2^escalation=1^sys_updated_on>=javascript:gs.daysAgoStart(7)