このドキュメントは AI によって自動翻訳されています。不正確な部分がある場合は、英語版 を参照してください。
はじめに#
このページは、モデルプラグインを通じて AI モデルを Dify と統合する際に実装するインターフェースとデータ構造の技術リファレンスです。
この API リファレンスに入る前に、概念モデルについては モデル設計ルール を、手順を追った解説については 新しいモデルプロバイダーの作成 を読むことをお勧めします。
クイック判断: どのメソッドを実装すべきか#
| モデルの種類 | 実装するもの |
|---|---|
| チャット/補完 LLM | LargeLanguageModel._invoke、_get_num_tokens |
| 埋め込みモデル | TextEmbeddingModel._invoke、_get_num_tokens |
| 音声認識 | Speech2TextModel._invoke |
| 音声合成 | Text2SpeechModel._invoke |
| モデレーション | ModerationModel._invoke |
すべてのプロバイダーは validate_provider_credentials(プロバイダーレベルの認証)も実装します。モデルがユーザーによって設定可能な場合は、モデルタイプごとに validate_credentials も実装します。
モデルプロバイダー#
すべてのモデルプロバイダーは __base.model_provider.ModelProvider 基底クラスを継承し、認証情報検証インターフェースを実装する必要があります。
プロバイダー認証情報検証#
プロバイダーの YAML 設定の provider_credential_schema で定義された認証情報。通常は api_key や organization_id などのフィールドです。
検証が失敗した場合、実装は CredentialsValidateFailedError 例外をスローする必要があります。これにより、Dify UI で適切なエラーハンドリングが行われます。
事前定義されたモデルプロバイダーの場合は、認証情報を API に対して検証する徹底した検証メソッドを実装してください。カスタムモデルプロバイダー(各モデルが独自の認証情報を持つ場合)では、簡略化された実装で十分です。
モデル#
Dify は 5 つの異なるモデルタイプをサポートしており、それぞれに独自のインターフェースがあります。すべてのモデルタイプは、以下の共通要件を満たします。
共通インターフェース#
タイプに関係なく、すべてのモデル実装はこれら 2 つの基本メソッドを実装する必要があります。
1. モデル認証情報検証#
検証する特定のモデル識別子(例: “gpt-4”、“claude-3-opus”)
プロバイダーの設定で定義された認証情報
2. エラーマッピング#
エラーマッピングに頼る代わりに、これらの標準化されたエラータイプをコード内で直接スローすることもできます。この方法では、エラーメッセージをより細かく制御できます。
LLM 実装#
大規模言語モデルプロバイダーを実装するには、__base.large_language_model.LargeLanguageModel 基底クラスを継承し、これらのメソッドを実装します。
1. モデル呼び出し#
このコアメソッドは、言語モデルへのストリーミングおよび非ストリーミング API 呼び出しの両方を処理します。
パラメータ
モデル識別子(例: “gpt-4”、“claude-3”)
API の認証情報
Dify の標準化された形式のメッセージリスト:
completionモデルの場合: 単一のUserPromptMessageを含めます。chatモデルの場合: 必要に応じてSystemPromptMessage、UserPromptMessage、AssistantPromptMessage、ToolPromptMessageを含めます。
モデルの YAML 設定で定義されたモデル固有のパラメータ(temperature、top_p など)
関数呼び出し機能のためのツール定義
検出されるとモデルの生成を停止するストップシーケンス
API 監視用のユーザー識別子
コードを整理し、保守しやすく保つために、ストリーミング呼び出しと非ストリーミング呼び出しで別々のヘルパーメソッドを実装することをお勧めします。
2. トークンカウント#
モデルがトークナイザーを提供していない場合は、基底クラスの _get_num_tokens_by_gpt2(text) メソッドを使用して妥当な近似値を求めることができます。
3. カスタムモデルスキーマ(オプション)#
このメソッドは、カスタムモデルをサポートするプロバイダーにのみ必要です。カスタムモデルが基本モデルからパラメータルールを継承できるようにします。
TextEmbedding 実装#
テキスト埋め込みモデルは、テキストを意味を捉えた高次元ベクトルに変換します。検索、類似性検索、分類に役立ちます。
テキスト埋め込みプロバイダーを実装するには、__base.text_embedding_model.TextEmbeddingModel 基底クラスを継承します。
1. コア埋め込みメソッド#
戻り値
以下を含む構造化されたレスポンス:
model: 埋め込みに使用したモデル。embeddings: 入力テキストと同じ順序の埋め込みベクトル。usage: トークン使用量とコストに関するメタデータ。
2. トークンカウントメソッド#
埋め込みモデルでは、正確なトークンカウントはコスト見積もりには重要ですが、機能上は重要ではありません。_get_num_tokens_by_gpt2 メソッドは、ほとんどのモデルに対して妥当な近似値を提供します。
Rerank 実装#
リランクモデルは、通常は初回の検索フェーズの後に、クエリとの関連性に基づいて候補ドキュメントのセットを並べ替えることで、検索品質の向上に役立ちます。
リランクプロバイダーを実装するには、__base.rerank_model.RerankModel 基底クラスを継承します。
戻り値
以下を含む構造化されたレスポンス:
model: リランクに使用したモデル。docs: index、text、score を持つRerankDocumentオブジェクトのリスト。
リランクは計算コストが高くなることがあり、特に大規模なドキュメントセットでは顕著です。タイムアウトや過度なリソース消費を避けるため、大規模なドキュメントコレクションにはバッチ処理を実装してください。
Speech2Text 実装#
音声認識モデルは、音声ファイル内の話し言葉を書き起こしテキストに変換します。文字起こしサービス、音声コマンド、アクセシビリティ機能などのアプリケーションを実現します。
音声認識プロバイダーを実装するには、__base.speech2text_model.Speech2TextModel 基底クラスを継承します。
戻り値
音声ファイルから書き起こされたテキスト
さまざまなファイルタイプを適切に処理するには、音声フォーマットの検出が重要です。例に示すように、ファイルヘッダーからフォーマットを検出するヘルパーメソッドの実装を検討してください。
一部の音声認識 API にはファイルサイズの制限があります。必要に応じて、大きな音声ファイルにはチャンク処理の実装を検討してください。
Text2Speech 実装#
音声合成モデルは、書かれたテキストを自然な音声に変換します。音声アシスタント、スクリーンリーダー、音声コンテンツ生成などのアプリケーションを実現します。
音声合成プロバイダーを実装するには、__base.text2speech_model.Text2SpeechModel 基底クラスを継承します。
ほとんどの音声合成 API では、モデルと一緒に音声を指定する必要があります。Dify のモデル識別子とプロバイダーの音声オプションを対応付けるマッピングの実装を検討してください。
長いテキスト入力は、音声合成の品質を高めるためにチャンク分割が必要になる場合があります。句読点、数字、特殊文字を適切に処理するため、テキストの前処理の実装を検討してください。
Moderation 実装#
モデレーションモデルは、有害、不適切、または安全でない可能性のある素材についてコンテンツを分析し、プラットフォームの安全性とコンテンツポリシーの維持に役立ちます。
モデレーションプロバイダーを実装するには、__base.moderation_model.ModerationModel 基底クラスを継承します。
戻り値
コンテンツの安全性を示すブール値:
False: コンテンツは安全です。True: コンテンツに有害な素材が含まれています。
モデレーションは安全機構として使われることが多くあります。実装にあたっては、偽陰性(有害なコンテンツを通過させてしまう)と偽陽性(安全なコンテンツをブロックしてしまう)の影響を考慮してください。
多くのモデレーション API は、単なるバイナリ結果ではなく、詳細なカテゴリスコアを提供します。アプリケーションで必要な場合は、有害なコンテンツの特定のカテゴリに関するより詳細な情報を返すよう、この実装を拡張することを検討してください。
エンティティ#
PromptMessageRole#
会話におけるメッセージのロール。
PromptMessageContentType#
メッセージコンテンツのタイプ: プレーンテキストまたは画像。
PromptMessageContent#
メッセージコンテンツの基底クラス。型宣言のためにのみ存在し、直接インスタンス化しないでください。
コンテンツは現在、テキストと画像の 2 つのタイプをサポートしており、1 つのメッセージでテキストと複数の画像を組み合わせることができます。代わりに TextPromptMessageContent と ImagePromptMessageContent をインスタンス化してください。
TextPromptMessageContent#
メッセージでテキストと画像を組み合わせる場合は、テキストをこのエンティティでラップして content リストに追加します。
ImagePromptMessageContent#
メッセージでテキストと画像を組み合わせる場合は、各画像をこのエンティティでラップして content リストに追加します。data には画像 URL または base64 エンコードされた画像文字列を指定できます。
PromptMessage#
すべてのロール固有メッセージの基底クラス。型宣言のためにのみ存在し、直接インスタンス化しないでください。
UserPromptMessage#
ユーザーメッセージを表します。
AssistantPromptMessage#
モデルの応答を表します。通常は few-shot の例やチャット履歴の入力に使用されます。
tool_calls は、リクエストに tools が含まれているときにモデルが返すツール呼び出しを保持します。
SystemPromptMessage#
システムメッセージを表します。通常はモデルのシステム指示を設定するために使用されます。
ToolPromptMessage#
ツールメッセージを表します。ツールの実行結果を次のステップの計画のためにモデルに渡します。
ツールの実行結果は、継承した content フィールドを通じて渡します。
PromptMessageTool#
LLMResult#
LLMResultChunkDelta#
ストリーミングレスポンスの各チャンク内の増分デルタ。
LLMResultChunk#
ストリーミングレスポンス内の単一チャンク。
LLMUsage#
TextEmbeddingResult#
EmbeddingUsage#
RerankResult#
RerankDocument#
関連リソース#
- モデル設計ルール: モデル設定の標準。
- モデルプラグイン入門: モデルプラグインの基本概念。
- 新しいモデルを素早く統合する: 既存のプロバイダーに新しいモデルを追加します。
- 新しいモデルプロバイダーを作成する: 新しいモデルプロバイダーをゼロから開発します。