タグ構成による自然言語クエリの改善
AI 命令は、自然言語クエリにビジネスコンテキストを追加します。ユーザーをガイドし、ユーザーのニーズと期待により近い応答を促進します。
AI 指示
AI の指示は、ナレッジグラフがユーザークエリを解釈し、データにアクセスする方法を明確にするのに役立ちます。ユーザーがクエリを送信すると、ノード、プロパティ、エッジなどの該当するすべてのレベルの関連する指示が考慮されます。
- ノード (エンティティ/テーブル) レベル
- プロパティ (列/属性) レベル
- Edge (関係性) レベル
常に含めるフラグ
常に含めるフラグを設定するオプションを使用すると、ユーザーは特定の指示を無条件に考慮する必要があることを示すことができます。これは、特に要求がない限り、特定の資産ステータスを常に除外するなど、重要なビジネスフィルターを適用する場合に便利です。
- ユーザークエリの言い回しに関係なく適用する必要があるビジネスクリティカルなフィルターには 、[常に含める] を使用します。
- 省略 関連する場合にのみ適用するコンテキスト依存の指示の場合は [ 常に含める ]。
- フラグ付き指示が互いに競合したり、重複した結果を生成したりしないことを確認します。
次の表は、AI の指示によってクエリの精度が向上し、より優れたビジネスコンテキストが提供される一般的なシナリオを示しています。
| 番号： | 指示パターン | サンプルクエリ | AI の指示のない動作 | AI 指示のサンプル | AI 指示による動作 |
|---|---|---|---|---|---|
| 1 | 誤った走査パスの防止 | ニューヨークにはどの会社がありますか? | 指示が追加されていない場合、クエリはデフォルトで core_company から cmn_location テーブルに移動し、市区町村フィールドでフィルタリングされます。ただし、ユースケースでcore_companyテーブルの city フィールドから場所をクエリする必要がある場合は、走査パスでシステムをガイドする AI 命令を記述する必要があります。 | テーブル core_company テーブルの説明: company-city クエリの場合は、常に core_company.city を直接使用します。cmn_locationを横断しないでください。 この手順により、システムは市区町村ベースの会社クエリcmn_locationパスを使用しないようにします。 |
指示が追加されると、クエリはテーブルの city フィールドと照合core_company、次に city=New York をフィルタリングして、一致するすべての会社を返します。 |
| 2 | 列固有のコンテキストの提供 | 茶色BBS0000013袋のセッションを主催したのは誰ですか? | AI の指示がない場合、システムはhost_sにトラバースせずにsys_idを返します。クエリhost_sホストに関するものである場合に、この列を使用するビジネスコンテキストを提供するために、列に指示を追加する必要があります。 | x_snc_brown_bags_sessionsテーブルのhost_sに関する列の説明:茶色のバッグセッションのホストには、s.sys_created_by ではなく、s.host_s または :host_s 関係を使用します |
指示が追加されると、クエリーはhost_s列から名前を正しく返します。 |
| 3 | 列固有のコンテキストの提供 | ケルシー・ロドリゲスの現在の在職期間 (月数) | AI の指示がない場合、在職期間列に誤った情報が提供される可能性があるため、正確な結果が得られない可能性があります。このようなクエリの右側の列を参照するようにシステムをガイドする指示を追加する必要があります。 | time_in_current_role列の列指示:クエリに「現在のロールでの在職期間」が含まれている場合、この列を優先します |
指示が追加されると、クエリーは time_in_current_role 列から時間を正しく返します。 |
| 4 | 類似のテーブルがある場合に何を優先するかに関するコンテキストの提供 | アリソン・ヒルのゴールが>0を過ぎたレポートの名前を教えてください。 |
AI の指示がない場合、LLM は、この情報が保存されている WDF テーブルにトラバースするのではなく、「sys_user」テーブルを直接参照してユーザーの詳細をフェッチします。 類似のテーブルがある場合に LLM が正しいテーブルを参照するようにガイドする指示を追加する必要があります。 |
WDF テーブルのテーブル命令 – 「x_snc_wdf_user」 「常にsys_userやその他のグライドテーブルよりも「x_snc_wdf_user」を優先する」 |
命令が追加されると、クエリは WDF テーブルを正しく参照し、結果を返します。 |
| 5 | 類似のテーブルがある場合に何を優先するかに関するコンテキストの提供 | 役職は何ですか? |
AI の指示がない場合、LLM は、この情報が保存されている「sn_hr_core_profile」テーブルにトラバースするのではなく、「sn_hr_core_job」テーブルを直接参照してジョブの詳細をフェッチします。 類似のテーブルがある場合に LLM が正しいテーブルを参照するようにガイドする指示を追加する必要があります。 |
テーブルのテーブル指示 – 「sn_hr_core_profile」 「ユーザーが役職について具体的に尋ねる場合は、常に「sn_hr_core_job」よりも「sn_hr_core_profile」を優先してください。 |
指示が追加されると、クエリは「sn_hr_core_profile」テーブルを正しく参照し、結果を返します。 |
| 6 | 複数の類似して紛らわしい選択値間の曖昧さを解消します | 正規化されたステータスのハードウェアモデルは何ですか? |
AI の指示がない場合、LLM は [正規化ステータス] 列の「正規化された」選択値を参照します。[正規化ステータス] フィールドには 5 つの選択値 (正規化済み、正規化されたメーカー、手動で正規化、一部正規化、一致が見つかりませんでした) があるため、LLM が他の選択値を使用するかどうかを混乱させる可能性があります。 正規化ステータスに含めるすべての選択肢について LLM をガイドする指示を追加する必要があります。 |
「列正規化ステータス」に関する列の説明: 「選択肢値が次のいずれかの選択肢である場合は、常に正規化ステータスを正規化済みと見なします。「正規化済み、正規化されたメーカー、手動で正規化済み」 |
指示が追加されると、クエリは「正規化済み、正規化されたメーカー、手動で正規化済み」の 3 つの選択肢すべてを正規化された状態として正しく考慮し、結果を返します。 |
AI 指示のベストプラクティス
AI 指示を作成するときは、次のガイドラインに従って、最適なパフォーマンスと精度を検証してください。
- ビジネスロジックに関連付けられた明確で明確で実用的な指示を記述します。常に正しいテーブル (ノード)、列 (プロパティ)、および関係 (エッジ) を参照します。[true のデフォルトのビジネス動作を強制する場合にのみ常に含める (Always include only when untrue)] などのフラグを使用します。
- 曖昧または矛盾した指示は避けてください。基礎となるデータモデルと一致しない指示は、システムを混乱させ、誤った結果につながる可能性があります。たとえば、列や条件を指定せずに「メーカーでフィルタリングする」などの指示はあいまいです。
- 条件を使用して、ロジックを適用するタイミングを制御します。ロジックを普遍的に適用するのではなく、指示を適用すべきタイミングを明確に示します (たとえば、ユーザーがホスト情報を要求した場合のみ)。
- 指示に焦点を絞り、一般化したものにしてください。手順は、単一の 1 回限りのケースを解決するのではなく、類似したクエリ全体にわたるインテント解釈を導く必要があります。
- 既に他の場所で処理されているロジックを複製しないでください。競合を避けるために、データフィルターによって既に適用されているフィルターまたは制約を再入力しないでください。
同義語、データフィルター、非表示列のサポート
同義語:
- 各エンティティには、最大 5 つの同義語を設定できます。
- 同義語は、一般的に使用される代替用語の幅広い範囲を促進します。
- 管理しやすい同義語セットを維持することで、クエリ解決のあいまいさが軽減されます。
データフィルター:
- フィルターは、暗号生成中ではなく、生成後に適用されます。
- 動的フィルターにより、ユーザーのコンテキストに基づいてリアルタイムで適応できます。
- 返されるデータの精度と関連性が向上します。コアグラフクエリは変更されません。
非表示の列:
非表示の列はクエリできず、結果には表示されません。
たとえば、従業員番号をテーブルの非表示列として追加してsys_userクエリ結果から従業員番号を非表示にします。