セグメントのガイドライン
セマンティックレイヤーのセグメントを効果的に使用するために、次の提案に従ってください。
セグメントの一般的なガイドライン
- 一致する自然言語の質問をして、セグメントをテストします。セグメントは次の場所に表示されます .
- クエリログを監視して、セグメントが正しく一致していることを確認し、最も価値のあるセグメントを特定します。
- 複数の手動セグメントで過剰適合しようとするのではなく、ノイズの多い自動生成セグメントを無効にします。
- ユーザーの実際の話し方に一致する自然な表現を使用します。
- 混乱を避けるために、コンセプトごとに 1 つのセグメントを保持します。
- ユーザーからのフィードバックと使用パターンに基づいて、セグメント名と説明を絞り込みます
- 既存のセグメントでは適切に処理されない繰り返し発生する質問に対して、手動セグメントを作成することを検討してください。
手動セグメントのガイドライン
手動セグメントは、ドメイン固有の保存済み検索をアプリケーションとともに送信するための推奨方法です。検索中に自動セグメントよりも優先度が高くなり、LLM は、まったく無関係でない限りすべてのフィルターを保持するように指示されます。
- 価値が高くトラフィックの多いテーブルから開始
- ユーザーが最もよく尋ねるテーブルに手動セグメントを集中させます。インシデント、sc_req_item、またはアプリケーションのプライマリテーブルのいくつかの適切に作成されたセグメントは、めったにクエリされないテーブルを広範囲にカバーするよりも大きな影響を与えます。
- 選択肢の多いすべてのフィルターを明確な名前とペアリングする
- セグメントが選択値 (
state=6^priority<=2など) でフィルタリングする場合、セグメント名はそれらのコードをビジネス言語に翻訳する必要があります。LLM がフィルターではなく名前で一致します。「解決済みの重大および高インシデント」は検索可能ですが、state=6^priority<=2は検索できません。 - 説明を使用して、類似のセグメントを明確にします
- 同じテーブルに対して複数のセグメント (「オープンインシデント」や「重大なオープンインシデント」など) を提供する場合、説明は LLM が適切なセグメントを選択するのに役立ちます。説明がない場合、LLM は 2 つの近い一致から任意に選択する可能性があります。
- フィルターにフォーカスを合わせる
- 15 個のフィルター条件を持つセグメントは、LLM が推論するのが難しく、切り捨てられる可能性があります。複雑なユースケースがある場合は、よりシンプルなフィルターを使用して複数のセグメントに分割します。LLM は、クエリを構築するときに、さまざまなセグメントのフィルターを組み合わせることができます。
- セマンティックな説明をセグメントで補完する
- 手動セグメントとセマンティック記述 (エンティティ/列構成) は連携して機能します。説明は、LLM がテーブルとその列が何を表している か を理解するのに役立ちます。セグメントは、 ユーザーが通常そのテーブルをフィルタリングする方法 を LLM が理解するのに役立ちます。最良の結果を得るには、両方を出荷してください。
- 自動セグメントの重複を避ける
- 手動セグメントを作成する前に、自動セグメントが既に同じフィルターをカバーしているかどうかを確認してください。使用しても名前が不適切な場合は、重複する手動セグメントを作成するよりも、レポートの名前を変更するなど、ソースを改善する方が良い方法であるかどうかを検討してください。
- 展開後のレビュー
- 出荷後、どのセグメントが一致しているか、生成されたクエリが正しいかどうかを監視します。セグメントが一致しているが、間違った結果を生成する場合は、通常、名前が一般的すぎるか、フィルターの幅が広すぎることが問題です。システムプロパティを調整する前に、まず名前と説明を反復処理します。
プロパティ調整の提案
セグメントのパフォーマンスが期待どおりに行われていない場合は、これらの提案を使用してシステムプロパティを調整します。すべてのセグメントプロパティとそのデフォルトの完全なリストについては、「 クエリ生成プロパティ」を参照してください。
- セグメントがユーザーの質問と一致していません
- 下限 segments_match_threshold (
たとえば、0.60に設定します)。デフォルトの0.70は、ユーザーの言い回しがセグメント名と異なるドメイン固有の用語では厳しすぎる可能性があります。低い位置から始めて、十分なセグメントができたら締めます。 - 手動セグメントは自動セグメントに取って代わられつつあります
- manual_segment_scale_factorを増やすと手動セグメントの優位性が向上しますが、ブーストが高いほど必ずしもより良い結果が得られるとは限りません。名前が正しくない手動セグメントを、真に関連性の高い自動セグメントよりも強化すると、クエリの品質が低下します。ブーストを調整する前に、まず手動セグメントの名前と説明が適切に記述されているかどうかを確認してください。通常、それが本当の解決策です。手動セグメントが高品質でありながら、弱い自動一致に負けていると確信できる場合にのみ、係数を増やしてください。
- LLM プロンプトに無関係なセグメントが多すぎます
- 小 segments_result_limit (
6や8など)。プロンプトのセグメントが少ないほど、LLM のノイズは少なくなりますが、カバレッジも小さくなります。ドメインの残高を見つけます。あるいは、低品質のマッチがすり抜ける場合は、 segments_match_threshold を上げてください。 - 長いフィルターが切り捨てられる
- セグメントに複雑なフィルターが必要な場合は、 max_filter_length を増やします。フィルターが長いほど LLM のコンテキストウィンドウをより多く消費し、全体的な生成品質が低下する可能性があることに注意してください。代わりに、複雑なセグメントを複数のフォーカスされたセグメントに分割することを検討してください。
- バッチ検索が無効で、手動セグメントが表示されない
- AI 検索プロパティsegments.ais_batch_fetch_enabledを有効にします。バッチ検索を使用しないと、手動セグメントと自動セグメントが同じ結果スロットをめぐって競合します。バッチ検索では、各タイプに専用の検索が提供されるため、手動セグメントのカバレッジが大幅に改善されます。