⚠️ このドキュメントはAIによって自動翻訳されています。不正確な部分がある場合は、英語版を参照してください。
前提条件
- Dify CLI
- 基本的な Python プログラミングスキルとオブジェクト指向プログラミングの理解
- 統合したいモデルプロバイダーの API ドキュメントへの精通
ステップ 1: 新しいプラグインプロジェクトの作成と設定
プロジェクトの初期化
モデルプラグインテンプレートの選択
利用可能なオプションからLLM タイプのプラグインテンプレートを選択します。このテンプレートは、モデル統合のための完全なコード構造を提供します。
プラグイン権限の設定
モデルプロバイダープラグインには、以下の必須権限を設定します:- Models - モデル操作の基本権限
- LLM - 大規模言語モデル機能の権限
- Storage - ファイル操作の権限(必要な場合)
ディレクトリ構造の概要
初期化後、プラグインプロジェクトは以下のようなディレクトリ構造になります(LLM と Embedding をサポートするmy_provider という名前のプロバイダーを想定):
ステップ 2: モデル設定方法の理解
Dify は、ユーザーがプロバイダーのモデルとどのようにやり取りするかを決定する 2 つのモデル設定方法をサポートしています:事前定義モデル(predefined-model)
これらは、統一されたプロバイダー認証情報のみで使用できるモデルです。ユーザーがプロバイダーの API キーやその他の認証詳細を設定すると、すべての事前定義モデルにすぐにアクセスできます。
例: OpenAI プロバイダーは、gpt-3.5-turbo-0125 や gpt-4o-2024-05-13 などの事前定義モデルを提供しています。ユーザーは OpenAI API キーを一度設定するだけで、これらすべてのモデルにアクセスできます。
カスタムモデル(customizable-model)
これらは、各特定のモデルインスタンスに追加の設定が必要です。このアプローチは、モデルがプロバイダーレベルの認証情報以外の個別パラメータを必要とする場合に便利です。
例: Xinference は LLM と Text Embedding の両方をサポートしていますが、各モデルには固有の model_uid があります。ユーザーは使用したい各モデルごとにこの model_uid を個別に設定する必要があります。
これらの設定方法は、単一のプロバイダー内で共存できます。たとえば、プロバイダーがいくつかの事前定義モデルを提供しながら、ユーザーが特定の設定でカスタムモデルを追加できるようにすることができます。
ステップ 3: モデルプロバイダーファイルの作成
新しいモデルプロバイダーの作成には、2 つの主要なコンポーネントが含まれます:- プロバイダー設定 YAML ファイル - プロバイダーの基本情報、サポートされるモデルタイプ、認証情報要件を定義
- プロバイダークラスの実装 - 認証検証やその他のプロバイダーレベルの機能を実装
3.1 モデルプロバイダー設定ファイルの作成
プロバイダー設定は、プロバイダーの基本情報、サポートされるモデルタイプ、設定方法、認証情報ルールを宣言する YAML ファイルで定義されます。このファイルは、プラグインプロジェクトのルートディレクトリに配置されます。 以下は、anthropic.yaml 設定ファイルの注釈付き例です:
カスタムモデル設定
プロバイダーがカスタムモデルをサポートする場合、各個別モデルに対してユーザーが設定する必要がある追加フィールドを定義するmodel_credential_schema セクションを追加する必要があります。これは、ファインチューニングされたモデルをサポートするプロバイダーや、モデル固有のパラメータが必要な場合に一般的です。
以下は OpenAI プロバイダーの例です:
3.2 モデルプロバイダーコードの記述
次に、プロバイダークラス実装用の Python ファイルを作成します。このファイルは、プロバイダー名に一致する名前で/provider ディレクトリに配置する必要があります(例:anthropic.py)。
プロバイダークラスは ModelProvider を継承し、少なくとも validate_provider_credentials メソッドを実装する必要があります:
validate_provider_credentials メソッドは、ユーザーが Dify でプロバイダー認証情報を保存しようとするたびに呼び出されるため、非常に重要です。このメソッドは:
- 簡単な API 呼び出しを行って認証情報を検証しようとする
- 検証が成功した場合は静かに戻る
- 検証が失敗した場合は、役立つメッセージとともに
CredentialsValidateFailedErrorをスロー
カスタムモデルプロバイダーの場合
カスタムモデルのみを使用するプロバイダー(各モデルに独自の設定が必要な場合)には、より単純なプロバイダークラスを実装できます。たとえば、Xinference の場合:
ステップ 4: モデル固有のコードの実装
プロバイダーの設定後、サポートする各モデルタイプの API 呼び出しを処理するモデル固有のコードを実装する必要があります。これには以下が含まれます:- 各特定モデルのモデル設定 YAML ファイルの作成
- API 通信を処理するモデルタイプクラスの実装
4.1 モデル設定の定義(YAML)
各特定モデルについて、適切なモデルタイプディレクトリ(例:models/llm/)に YAML ファイルを作成し、そのプロパティ、パラメータ、機能を定義します。
例(claude-3-5-sonnet-20240620.yaml):
4.2 モデル呼び出しコードの実装(Python)
サポートする各モデルタイプ用の Python ファイルを作成します(例:models/llm/ ディレクトリ内の llm.py)。このクラスは、API 通信、パラメータ変換、結果のフォーマットを処理します。
以下は LLM の実装構造の例です:
_invoke で、コア API 通信を処理します。このメソッドは:
- Dify の標準化された入力をプロバイダーの API が必要とする形式に変換
- 適切なエラー処理で API 呼び出しを実行
- API レスポンスを Dify の標準化された出力形式に変換
- ストリーミングモードと非ストリーミングモードの両方を処理
ステップ 5: プラグインのデバッグとテスト
Dify は、開発中にプラグインをテストできるリモートデバッグ機能を提供しています:- Dify インスタンスで「プラグイン管理」に移動し、「プラグインをデバッグ」をクリックしてデバッグキーとサーバーアドレスを取得
.envファイルでこれらの値をローカル環境に設定:
python -m mainでプラグインをローカルで実行し、Dify でテスト
ステップ 6: パッケージ化と公開
プラグインの準備ができたら:-
スキャフォールディングツールを使用してパッケージ化:
- 提出前にパッケージ化されたプラグインをローカルでテスト
- Dify 公式プラグインリポジトリにプルリクエストを提出
参考リソース
- 新しいモデルのクイック統合 - 既存のプロバイダーに新しいモデルを追加する方法
- プラグイン開発の基本概念 - プラグイン開発入門ガイドに戻る
- モデルスキーマ - 詳細なモデル設定仕様を学ぶ
- 一般仕様 - プラグインマニフェストファイルの設定を学ぶ
- Dify プラグイン SDK リファレンス - 基底クラス、データ構造、エラータイプを参照
Edit this page | Report an issue