モデルプロバイダーの作成
このドキュメントでは、モデルプロバイダープラグインを作成する方法について詳しく説明します。プロジェクトの初期化、モデル設定方法(事前定義モデルとカスタムモデル)の選択、プロバイダー設定YAMLファイルの作成、およびプロバイダーコードの作成の完全なプロセスが含まれます。
Modelタイプのプラグインを作成する最初のステップは、プラグインプロジェクトを初期化し、モデルプロバイダーファイルを作成することです。その後、具体的な事前定義済み/カスタムモデルのコードを記述します。既存のモデルプロバイダーに新しいモデルを追加したいだけの場合は、新しいモデルの迅速な統合を参照してください。
事前準備
- Dify プラグインスケルトンツール
- Python 環境、バージョン ≥ 3.12
プラグイン開発用のスケルトンツールを準備する方法の詳細については、開発ツールの初期化を参照してください。開始する前に、モデルプラグインの基本的な概念と構造を理解することをお勧めします。
新規プロジェクトの作成
スケルトンコマンドラインツールのパスで、新しい Dify プラグインプロジェクトを作成します。
このバイナリファイルを dify
にリネームし、/usr/local/bin
パスにコピーした場合、次のコマンドを実行して新しいプラグインプロジェクトを作成できます:
モデルプラグインテンプレートの選択
スケルトンツール内のすべてのテンプレートには、完全なコードプロジェクトが提供されています。LLM
タイプのプラグインテンプレートを選択します。
プラグイン権限の設定
このLLMプラグインに次の権限を設定します:
- Models
- LLM
- Storage
モデルタイプ設定の説明
モデルプロバイダーは、以下の2つのモデル設定方法をサポートしています:
-
predefined-model
事前定義済みモデル一般的な大規模モデルタイプで、統一されたプロバイダーの認証情報を設定するだけで、プロバイダー下の事前定義済みモデルを使用できます。例えば、
OpenAI
モデルプロバイダーはgpt-3.5-turbo-0125
やgpt-4o-2024-05-13
などの一連の事前定義済みモデルを提供しています。詳細な開発手順については、事前定義済みモデルの統合を参照してください。 -
customizable-model
カスタムモデル各モデルの認証情報設定を手動で追加する必要があります。例えば
Xinference
は、LLMとText Embeddingの両方をサポートしていますが、各モデルには一意の model_uid があります。両方を同時に統合したい場合は、各モデルに model_uid を設定する必要があります。詳細な開発手順については、カスタムモデルの統合を参照してください。
2つの設定方法は共存をサポートしており、つまり、プロバイダーが predefined-model
+ customizable-model
または predefined-model
などをサポートする場合、プロバイダーの統一された認証情報を設定することで、事前定義済みモデルとリモートから取得したモデルを使用できます。新しいモデルを追加した場合は、これに加えてカスタムモデルを使用できます。
新しいモデルプロバイダーの追加
新しいモデルプロバイダーを追加するには、主に次の手順が含まれます:
-
モデルプロバイダー設定YAMLファイルの作成
プロバイダーディレクトリに新しいYAMLファイルを追加し、プロバイダーの基本情報とパラメータ設定を記述します。ProviderSchemaの要件に従って内容を記述し、システム仕様との一貫性を確保します。
-
モデルプロバイダーコードの記述
プロバイダーのクラスコードを作成し、システムのインターフェース要件に準拠したPythonクラスを実装して、プロバイダーのAPIと連携し、コア機能を実現します。
以下は、各ステップの完全な操作詳細です。
1. モデルプロバイダー設定ファイルの作成
ManifestはYAML形式のファイルであり、モデルプロバイダーの基本情報、サポートされるモデルタイプ、設定方法、認証情報ルールを宣言します。プラグインプロジェクトテンプレートは、/providers
パスに設定ファイルを自動的に生成します。
以下は、Anthropic
モデル設定ファイル anthropic.yaml
のサンプルコードです:
接続するプロバイダーがカスタムモデルを提供する場合、例えばOpenAI
がファインチューニングモデルを提供する場合、model_credential_schema
フィールドを追加する必要があります。
以下は OpenAI
ファミリーモデルのサンプルコードです:
より完全なモデルプロバイダーYAML仕様については、モデルスキーマドキュメントを参照してください。
2. モデルプロバイダーコードの記述
/providers
フォルダに同名の Python ファイルを作成します。例えば anthropic.py
とし、__base.provider.Provider
基本クラスを継承する class
を実装します。例えば AnthropicProvider
です。
以下は Anthropic
のサンプルコードです:
プロバイダーは __base.model_provider.ModelProvider
基本クラスを継承し、validate_provider_credentials
プロバイダー統一認証情報検証メソッドを実装するだけで済みます。
もちろん、validate_provider_credentials
の実装を一旦プレースホルダとして残しておき、モデル認証情報検証メソッドの実装後に直接再利用することも可能です。
カスタムモデルプロバイダー
他のタイプのモデルプロバイダーについては、以下の設定方法を参照してください。
Xinference
のようなカスタムモデルプロバイダーの場合、完全な実装手順をスキップできます。XinferenceProvider
という名前の空のクラスを作成し、その中に空の validate_provider_credentials
メソッドを実装するだけです。
詳細説明:
• XinferenceProvider
は、カスタムモデルプロバイダーを識別するためのプレースホルダクラスです。
• validate_provider_credentials
メソッドは実際には呼び出されませんが、存在する必要があります。これは、その親クラスが抽象クラスであり、すべてのサブクラスにこのメソッドの実装を要求するためです。空の実装を提供することで、抽象メソッドが未実装であることによるインスタンス化エラーを回避できます。
モデルプロバイダーを初期化した後、次にプロバイダーが提供する具体的なLLMモデルを統合する必要があります。詳細については、以下の内容を参照してください:
参考リソース
- 新しいモデルの迅速な統合 - 既存のプロバイダーに新しいモデルを追加する方法
- プラグイン開発の基本概念 - プラグイン開発入門ガイドに戻る
- 新しいモデルプロバイダー作成の補足 - より高度な設定について学ぶ
- 一般仕様定義 - プラグインマニフェストファイルの設定を理解する