前提条件
- 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 を個別に設定する必要があります。
2 つの設定方法は、同一のプロバイダー内で共存できます。たとえば、一部の事前定義モデルを提供しつつ、ユーザーが特定の設定でカスタムモデルを追加できるようにするプロバイダーもあります。
ステップ 3: モデルプロバイダーファイルの作成
新しいモデルプロバイダーの作成には、2 つの主要なコンポーネントが含まれます:- プロバイダー設定 YAML ファイル:プロバイダーの基本情報、サポートされるモデルタイプ、認証情報の要件を定義します。
- プロバイダークラスの実装:認証検証やその他のプロバイダーレベルの機能を実装します。
3.1 モデルプロバイダー設定ファイルの作成
プロバイダー設定は、プロバイダーの基本情報、サポートされるモデルタイプ、設定方法、認証情報のルールを宣言する YAML ファイルです。これをプラグインプロジェクトのルートディレクトリに配置します。 以下は、anthropic.yaml 設定ファイルの注釈付き例です:
カスタムモデル設定
プロバイダーがカスタムモデルをサポートする場合は、各モデルに対してユーザーが設定する追加フィールドを定義するmodel_credential_schema セクションを追加します。これは、ファインチューニングされたモデルをサポートするプロバイダーや、モデル固有のパラメータが必要な場合に一般的です。
以下は OpenAI プロバイダーの例です:
3.2 モデルプロバイダーコードの記述
次に、/provider ディレクトリにプロバイダークラス用の Python ファイルを作成し、プロバイダー名に合わせて命名します(例:anthropic.py)。
プロバイダークラスは ModelProvider を継承し、少なくとも validate_provider_credentials メソッドを実装する必要があります:
validate_provider_credentials を呼び出します。そのため、このメソッドは次のように動作する必要があります:
- 簡単な 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