プラグインによる手動セグメントの出荷

事業部門アプリケーション開発者は、アプリケーションに手動セグメントを付属させて、アプリのインストール時点から機能するドメイン固有の保存済み検索を提供できます。

出荷の概要

手動セグメントは、ドメイン固有の保存済み検索をアプリケーションとともに送信するための推奨方法です。検索中に自動セグメントよりも優先度が高くなり、LLM は完全に無関係でない限りすべてのフィルターを保持するように指示されますが、自動セグメントフィルターは個別に批判されます。

プラグインを使用して手動セグメントを出荷すると、ユーザーは、使用パターンから自動セグメントが生成されるのを待たずに、ビジネス用語を使用してアプリケーションのデータについてすぐに自然言語で質問できます。

手動セグメントの出荷方法

1. 開発インスタンスで手動セグメント構成レコードを作成します。
2. それらが正しく同期され、期待される検索結果が生成されることを確認します。
3. アプリの更新セットに sn_query_gen_segment_table_config レコードを含めます。

プラグインインストールの動作

プラグインのインストール中に手動セグメントがどのように動作するかを理解することは、適切な期待値を設定するために重要です。

• プラグインのインストール中にビジネスルールが バイパス されます。非同期同期はインストール時に自動的に実行されません。
• レコードは、次回のセマンティックレイヤー生成スケジュール済みジョブの実行時 (インストール後) または週次同期セグメントジョブの実行時にsn_query_gen_segmentに同期されます。
• プラグインが重複レコードを出荷していないことを確認してください。データベースレベルでは一意の制約はありません。アドミニストレーターはエンティティごとに重複する名前がないことを確認する必要があります。

重要:

プラグインを介して出荷された手動セグメントは、インストール後にすぐには検索できません。これらは、次回のスケジュール設定済み同期ジョブの実行後にアクティブになります。

例:テーブルの完全な構成

次の例は、ITSM アプリケーションに付属する可能性がある インシデント テーブルの手動セグメントを示しています。

前提条件:インシデントテーブルには、enable_semantic_generation = trueとアクティブなエンティティを含むsn_query_gen_table_configレコードが必要です。

表 : 1. インシデントテーブルの手動セグメントの例

名前	説明	テーブル	フィルター
最重要のオープンインシデント	現在オープンで未解決の高優先度のインシデント。すべてのアサイン先グループが含まれます。	インシデント	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)

出荷セグメントのベストプラクティス

価値が高くトラフィックの多いテーブルに焦点を当てる

ユーザーが最もよく尋ねるテーブルに手動セグメントを集中させます。アプリのプライマリ テーブルで適切に作成されたいくつかのセグメントは、めったにクエリされないテーブルを広くカバーするよりも大きな影響を与えます。

技術コードではなくビジネス言語を使用します

セグメント名は、ユーザーがドメインについて自然に話す方法と一致する必要があります。「重大なオープンインシデント」は「P1_OPEN_INC」よりも優れています。

曖昧性除去のための説明を入力してください

同じテーブルに対して複数のセグメントを出荷する場合、説明は LLM が適切なセグメントを選択するのに役立ちます。説明がないと、LLM は類似した一致の中から任意に選択する可能性があります。

出荷前にテスト

セグメントが正しく同期され、関連する発言の検索結果に表示されることをテスト環境で確認します。クエリログをチェックして、一致する動作を確認します。

自動セグメントの重複を避ける

手動セグメントを作成する前に、自動セグメントが既に同じフィルターをカバーしているかどうかを確認してください。ソースは存在しても名前が悪い場合は、複製を作成するのではなく、ソースを改善することを検討してください。

出荷前のチェックリスト

プラグインに手動セグメントを含める前に、次のことを確認してください。

• 各ターゲットテーブルは、セマンティックレイヤーにアクティブなエンティティを持っています (enable_semantic_generation = trueでsn_query_gen_table_config)
• セグメント名は、技術的な速記ではなく、分かりやすいユーザー言語で記述されています
• 説明は、名前だけであいまいな可能性があるセグメントのために提供されます
• フィルターは有効なエンコードクエリであり、LLM プロンプトを含めるのに最適な 2,000 文字未満です
• 更新セットに重複レコード (同じ名前 + テーブルの組み合わせ) が存在しません
• すべての sn_query_gen_segment_table_config レコードがアプリの更新セットに含まれています
• セグメントが正しく同期され、関連する発言の検索結果に表示されることをテスト環境で確認済み

展開後のモニタリング

アプリケーションで手動セグメントを出荷した後:

• クエリログで一致するセグメントを監視する
• 生成されたクエリが意図したユースケースに対して正しいことを確認します
• クエリの精度と範囲に関するユーザーフィードバックを収集します
• 使用パターンに基づいてセグメント名と説明を反復処理します

セグメントが一致しているが、間違った結果を生成する場合は、通常、名前が一般的すぎるか、フィルターの幅が広すぎることが問題です。システムプロパティを調整する前に、名前と説明を絞り込んでください。

関連概念

• 手動セグメントデータモデルと同期動作
• セグメントのガイドライン

関連タスク

• 手動セグメントの作成