Dify Agent ログインとナレッジベース権限

議論
1

以下の質問についてご教示ください。

  1. Difyエージェントでユーザーログイン情報を比較する際、どのような方法がありますか？
    ホワイトリストExcelを知識ベースとして比較に利用することは有効ですか？

  2. Dify知識ベースで1ユーザー1知識ベースのアクセス権限を実装するには、どのような方法がありますか？
    10ユーザー10データ権限の場合、10x10の知識ベースメタデータ設定を行うよりも、より良い解決策はありますか？

2

こんにちは！ご質問いただいた2つの点について、Difyの既存機能と一般的な実践に基づいてお答えします。

1. Difyエージェントでユーザーログイン情報を照合する方法は？ホワイトリストExcelを知識ベースとして照合することは適切か？

Dify自体はLLMアプリケーション開発プラットフォームであり、その核となるのはAIアプリケーション（エージェント）の構築と実行です。Difyのアプリケーションは通常ステートレスであるか、その状態管理は対話履歴とセッション変数に基づいて行われ、従来のユーザー認証および認可システムとは異なります。

ユーザーログイン情報の照合を実現するには、主に以下の方法があります。

  1. 外部認証システムの統合 (推奨方式)：

    • Dify外部での認証：最も一般的で推奨される方法は、Difyの外部に独立した認証層を構築することです。これは、独自のWebアプリケーション、APIゲートウェイ、またはその他の認証サービスである可能性があります。ユーザーはまずこの外部システムを通じてログインし、成功すると、外部アプリケーションはユーザーの身元情報（例：ユーザーID、ロールなど）を取得します。
    • ユーザー情報をDifyエージェントに渡す：
      • API呼び出し時のパラメータ渡し：外部アプリケーションがDifyエージェントのAPIを呼び出す際（例：send-chat-message）、検証済みのユーザーIDやその他の関連情報をuserパラメータ（またはカスタムのinputsフィールド）としてDifyに渡すことができます。Difyはこのuser情報を記録し、異なる対話セッションを区別するために使用します。
      • ワークフローでのユーザー情報の利用：Difyのワークフローでは、「開始ノード」を設定してこれらのユーザーIDやその他のカスタムパラメータを受け取ることができます。その後、「コードノード」または「HTTPリクエストノード」を使用して、これらのパラメータに基づいて外部のユーザーデータベースやシステムをさらにクエリし、よりきめ細かい権限制御やデータ照合を行うことができます。

  2. Difyの知識ベースをホワイトリストとして照合する (可能だが限界がある)：

    • 実現可能性：ユーザーログイン情報（ユーザー名/パスワードペアのハッシュ値、またはユーザー名のみなど）をDify知識ベースに保存し、エージェントのクエリを通じて照合することは、技術的には可能です。ユーザー情報を含むCSVまたはExcelファイルを知識ベースとしてアップロードできます。
    • 実現方法：
      • ユーザーはエージェントとの対話時にユーザー名とパスワードを入力します。
      • エージェントはRAG（検索拡張生成）を通じて知識ベースから一致するユーザー情報を検索します。
      • ワークフロー内の「コードノード」を通じて検索結果が一致するかどうかを判断し、「ログイン成功」を決定します。
    • 限界/非推奨の理由：
      • セキュリティリスク：機密性の高いログイン情報（ハッシュ値であっても）をDify知識ベースに直接保存し、RAGで照合することは、潜在的なセキュリティリスクを伴います。知識ベースは通常、意味理解や情報検索のために使用され、厳密な身元認証のためではありません。知識ベースが不正にアクセスされた場合、ユーザー情報が漏洩する可能性があります。
      • パフォーマンスと正確性：RAGシステムは主に「理解」と「関連情報の「検索」のために使用され、正確なデータベース検索や照合のためではありません。厳密なログイン検証の場合、そのパフォーマンスと正確性は従来のデータベースクエリに劣る可能性があります。誤判断（ハルシネーション）のリスクも従来の方法よりも高くなります。
      • ユーザーエクスペリエンス：照合ロジックが複雑な場合、エージェントの応答時間が増加する可能性があります。
      • 機能制限：知識ベースは、パスワード暗号化、ソルト値、セッション管理、トークン発行など、従来の認証システムの機能を処理できません。

まとめ：ユーザーログイン情報の照合については、Difyの外部で専門的な身元認証システムを実装し、認証済みのユーザー身元情報をAPIを通じてDifyエージェントに渡すことを強く推奨します。Excelを知識ベースとして直接ログイン情報を照合することは理論上可能ですが、セキュリティ、パフォーマンス、機能の観点から、推奨されるベストプラクティスではありません。

2. Dify知識ベースでユーザーごとに知識ベースアクセス権限を実装する方法は？10ユーザー10資料権限の場合、10*10の知識ベースメタデータ設定を構築するよりも良い解決策はあるか？

Difyの現在の知識ベース設計（私の知る限り）は、主にアプリケーションに共有の知識基盤を提供することを目的としており、「ユーザーごとに1つの知識ベース」や「ユーザーベースの知識ベースアクセス権限」といったきめ細かいネイティブ機能は直接提供していません。知識ベースはDifyアプリケーション（App）の一部であり、App自体は通常、複数のユーザーで共有して使用されます。

「10ユーザー10資料権限、10*10の知識ベースメタデータ設定を構築する」というあなたの考え方は、権限分離のニーズを反映していますが、Difyはこのような複雑なユーザーレベルの知識ベース分離をネイティブではサポートしていません。10個の独立したDifyアプリケーションを直接構築し、それぞれを1人のユーザーと1つの知識ベースにバインドする方法は、最も直接的ですが、最も重い方法かもしれません。

以下に、Difyのワークフローと外部システムを組み合わせる必要がある、いくつかの「より良い解決策」または実装のアイデアを示します。

  1. ワークフローと知識ベースのメタデータフィルタリングの利用 (推奨)：

    • 考え方：すべてのユーザーの資料（または異なる権限グループに属する資料）を1つまたは少数の大規模な知識ベースに保存します。ドキュメントをアップロードする際に、各ドキュメントまたは各ドキュメントチャンクにメタデータ (metadata) を追加します。例えば、user_id (ユーザーID) や access_group (アクセスグループ) などです。
    • 実装手順：
      1. ドキュメントの前処理：ドキュメントをDify知識ベースにアップロードする前に、APIまたはバッチ処理スクリプトを通じて、各ドキュメントチャンク（chunk）またはドキュメント全体に適切なメタデータ（例：{\"user_id\": \"userA\"} または {\"access_group\": \"group1\"}）を付加します。
      2. DifyワークフローでのユーザーIDの取得：最初の質問で述べたように、Difyワークフローの開始ノードで検証済みのユーザーIDを受け取ります。
      3. RAGノードでのメタデータフィルタリングの設定：ワークフロー内のRAG（検索拡張生成）ノードで、メタデータフィルターを設定します。例えば、user_idが現在のユーザーIDと一致するドキュメント、またはaccess_groupが現在のユーザーが属するグループを含むドキュメントのみを知識ベースから検索します。
    • 利点：
      • 高い柔軟性：かなりきめ細かい権限制御を実現できます。
      • 管理の容易さ：すべての資料が1つの知識ベースにあり、複数の知識ベースを維持するよりもメタデータ管理が効率的です。
      • 拡張性：ユーザー数と資料が増加しても、メタデータタグを追加するだけでよく、新しい知識ベースインスタンスを作成する必要はありません。
    • 課題：ドキュメントアップロード時にメタデータを正確に定義および管理し、ワークフローでフィルタリングロジックを正しく設定する必要があります。

  2. 外部コンテンツ管理 + Dify API (より複雑なシナリオに適用)：

    • 考え方：ユーザー資料をDify外部のプライベートストレージ（データベース、オブジェクトストレージ、ドキュメント管理システムなど）に保存し、外部アプリケーションで権限管理を行います。Difyエージェントが資料にアクセスする必要がある場合、ワークフロー内の「HTTPリクエストノード」を通じて外部APIを呼び出し、外部APIがユーザーの身元に基づいて動的に対応する資料を取得して返します。
    • 実装手順：
      1. 外部システムでの資料と権限の管理：外部アプリケーションがすべての資料の保存を担当し、各ユーザーのアクセス権限を厳密に管理します。
      2. Difyワークフローからの外部API呼び出し：ワークフロー内で、エージェントが資料を必要とする際にHTTPリクエストノードをトリガーします。このリクエストはユーザーID（開始ノードから取得）を外部APIに送信します。
      3. 外部APIからの資料返却：外部APIはユーザーIDとその権限に基づいて、プライベートストレージからそのユーザーがアクセス権を持つ資料を検索して返します。
      4. Difyエージェントによる返却資料の処理：ワークフロー内の次のノード（例：「コードノード」またはLLMへの直接入力）が外部APIから返された資料を処理し、LLMと組み合わせて回答します。
    • 利点：権限管理が完全に外部で行われるため、セキュリティが最も高く、既存の企業システムとの統合度も高くなります。
    • 課題：外部の資料管理およびAPIサービスを開発・維持する必要があり、システムが複雑になります。

  3. 複数のDifyアプリの作成 (ユーザー分離度が非常に高い場合)：

    • 考え方：独立した資料権限が必要なユーザー（またはユーザーグループ）ごとに独立したDifyアプリを作成し、各アプリに専用の知識ベースをバインドします。
    • 実現方法：これらのDifyアプリへのアクセス権限を管理する外部システムが必要です。ユーザーがログインする際、ユーザーの身元に基づいて、アクセス権を持つDifyアプリのAPIエンドポイントにリダイレクトします。
    • 利点：完全なユーザー分離が実現され、各アプリと知識ベースが独立しています。
    • 課題：管理コストが高く、ユーザー数が非常に多い場合、多数のDifyアプリを維持することは非常に複雑で手間がかかります。100人のユーザーに対して100個のアプリを作成することは推奨されません。

まとめ：

  • ユーザーレベルの知識ベースアクセス権限のニーズに対して、Difyには現在、そのまま使えるネイティブ機能はありません。
  • 最も推奨されるソリューションは「ワークフローと知識ベースのメタデータフィルタリングの利用」 です。1つまたは少数の知識ベースにすべてのデータを保存し、メタデータ（例：user_idやaccess_group）を通じてドキュメントの権限を識別します。Difyワークフローでは、ユーザーの身元と組み合わせて、RAGノードのメタデータフィルタリング機能を使用して権限制御を実現します。
  • 権限ロジックが非常に複雑な場合、または既存のエンタープライズ級権限システムとの深い統合が必要な場合は、「外部コンテンツ管理 + Dify API」のソリューションを検討できます。
  • ユーザーごとにDifyアプリを作成することは避けてください。これはスケーリング時に管理が困難になります。

実装する前に、機能はバージョンアップによって変更される可能性があるため、Difyのバージョンを明確にすることをお勧めします。