Skip to content

LLM Gatewayの管理

LLM Gatewayの管理では、組織の管理者が、組織において、LLMモデルに対するきめ細かなアクセス権限、登録ポリシー、および非推奨時のフォールバックを設定できます。 これらのアクセスルールは、すべてのエージェントワークフローに適用されます。

プロバイダー、作成者、およびモデルへのアクセスを管理するには、管理者設定を開き、LLM Gatewayの管理タイルをクリックします。 左側のパネルには、モデルのカテゴリー(最上位カテゴリーとしてプロバイダー、子カテゴリーとして作成者)に加え、アクセス情報を一目で確認できるバッジが表示されます。

バッジ 説明
組織 組織全体で有効になっています。
カスタム ユーザーやグループごとにアクセスルールがカスタマイズされています。
継承 親プロバイダーに設定されたすべてのアクセスルールを採用しています。
無効 組織全体で無効になっています。

左側のパネルでプロバイダーまたは作成者を選択すると、アクセスルールと関連するモデルが表示されます。 モデルが選択されると、その領域にはそのモデルのアクセスルールが表示され、そのモデルがどこから 権限を継承しているかが説明されます。

アクセス設定

管理者は、プロバイダー、作成者、およびモデルレベルでアクセス制御ルールを割り当てることができます。 アクセスルールを設定するには:

  1. 左側のパネルでプロバイダーまたは作成者を選択するか、いずれかを選択した状態で、モデルセクション内のモデルをクリックします。
  2. 次に、誰がこれを使用できますか?の横にあるオーバーライドを編集をクリックします。 ドロップダウンのオプションを使用して、1つ以上のアクセス条件を割り当てます。

    • アクセス:許可する、拒否する
    • ターゲットタイプ:組織、グループ、ユーザー
    • ターゲット:ターゲットタイプに関連付けられたエンティティ

    たとえば、Amazon Bedrockへの組織全体のアクセス権を割り当てるには、許可する組織を選択します。 アクセス条件が既存の権限と競合する場合、影響を受けるターゲットフィールドの値が赤く強調表示され、その下に詳細情報が記載されたメッセージが表示されます。

  3. 保存をクリックして、アクセスルールを適用します。

アクセスルールをすばやくリセットするには、アクセスルールを編集の横にある削除をクリックします。

アクセスルールの解決

モデルレベルでは、プロバイダー、作成者、およびモデルに対してアクセスルールがどのように解決されるかを確認でき、モデルがどこから権限を継承しているかが詳細に示されます。 アクセスルールを正しく読み取るには、モデルから始めて、上方向へと順に確認します。 この表では、以下のバッジが使用されています。

バッジ 説明
有効 モデルによって採用されたアクセスルール。
継承 上位エンティティからアクセスルールが継承されています。
オーバーライド アクセスルールは、階層内でオーバーライドされているため、モデルに適用されません。

例1:継承されたルール

  • モデルにアクセスルールがない場合、作成者からルールを継承し、右側に継承バッジが表示されます。
  • 作成者にもアクセスルールがない場合、モデルはプロバイダーからルールを継承します。
  • プロバイダーに組織を許可というルールが設定されている場合、モデルはこのルールに基づいてアクセス権を決定し、右側に有効バッジが表示されます。 この場合、モデルは組織全体で利用可能です。

例2:オーバーライドされたルール

このモデルには組織を許可というアクセスルールが設定されていますが、作成者とプロバイダーにもアクセスルールが設定されています。 この場合、作成者とプロバイダーのルールはモデルのルールによってオーバーライドされるため、このモデルは組織全体で利用可能となります。 モデルには有効バッジが表示され、作成者とプロバイダーの両者にはオーバーライドバッジが表示されます。

アクセスのフローチャート

この例では、モデルLLM Model gpt-4oを使用してチャットの補完をリクエストしていますが、その前に、DataRobotがモデルへのアクセス権限を評価する必要があります。 DataRobotは親プロバイダー、作成者、およびモデルのルールを収集し、「これらの各リソースに対して個別にどのようなアクセスルールが設定されているか?」という問いに対して回答する必要があります。

最初のステップとして、DataRobotは内部のアクセス制御システムにおいて、収集した各リソースについて、どのレベルにおいても明示的な拒否がないかを確認します。 拒否が1つでも存在する場合、結果は「拒否」となります。 また、ルールが一切存在しない場合も、結果は「拒否」となります。 (明示的な拒否がなく)いずれかのレベルで許可がある場合、結果は「許可」となります。

次に、DataRobotはモデル自体からプロバイダーまで、モデルに対して明示的な許可があるかどうかのチェックを開始します。 ここでも、これら3つすべてにアクセスルールが存在しない場合、結果は「拒否」となります。 このプロセスが終了すると、アクセスが拒否されてエラー「404 - Not found error: Model not found in catalog」が表示されるか、またはチャットの補完に進むことができます。

flowchart TD
    classDef allow fill:#90EE90,stroke:#4CAF50,color:#000
    classDef deny fill:#FFB6C1,stroke:#F44336,color:#000

    A["/chat/completion/responses<br/>llm: azure/gpt-4o"] --> B{Access evaluation}

    B --> C["Internal DataRobot Access Control System"]
    C --> D["LLM Provider<br/>entity: Azure<br/>user: user1"]
    C --> E["LLM Creator<br/>entity: Azure/OpenAI<br/>user: user1"]
    C --> F["LLM Model<br/>entity: azure/gpt-4o<br/>user: user1"]

    D & E & F --> G{Explicit allow for<br/>LLM Model gpt-4o?}

    G -- Yes --> ALLOW1([Allow]):::allow
    G -- No --> H{Explicit deny for<br/>LLM Model gpt-4o?}
    H -- Yes --> DENY1([Deny]):::deny
    H -- No --> I{Explicit allow for<br/>LLM Creator Azure/OpenAI?}
    I -- Yes --> ALLOW2([Allow]):::allow
    I -- No --> J{Explicit deny for<br/>LLM Creator Azure/OpenAI?}
    J -- Yes --> DENY2([Deny]):::deny
    J -- No --> K{Explicit allow for<br/>LLM Provider Azure?}
    K -- Yes --> ALLOW3([Allow]):::allow
    K -- No --> DENY3([Deny]):::deny

    ALLOW1 & ALLOW2 & ALLOW3 --> L{Allow?}
    DENY1 & DENY2 & DENY3 --> L

    L -- No --> M[Raise 404 Not Found]
    L -- Yes --> N[Proceed with chat completion]