Dify
日本語
日本語
  • 入門
    • Difyへようこそ
      • 特性と技術仕様
      • モデルプロバイダーリスト
    • クラウドサービス
    • コミュニティ版
      • Docker Compose デプロイ
      • ローカルソースコードで起動
      • aaPanelでのデプロイ方法
      • フロントエンドDockerコンテナを単独起動
      • 環境変数の説明
      • よくある質問
    • Dify Premium
    • Dify 教育版
  • マニュアル
    • モデル
      • 新しいプロバイダーの追加
      • 事前定義されたモデルの追加
      • カスタムモデルの追加
      • インタフェース
      • 配置ルール
      • 負荷分散
    • アプリ・オーケストレーション
      • アプリの作成
      • チャットボット
        • 複数モデルのデバッグ
      • エージェント
      • ツールキット
        • コンテンツモデレーション
    • ワークフロー
      • キーコンセプト
      • 変数
      • ノードの説明
        • 開始
        • 終了
        • 回答
        • LLM
        • 知識検索
        • 質問分類
        • 条件分岐
        • コード実行
        • テンプレート
        • テキスト抽出ツール
        • リスト処理
        • 変数集約
        • 変数代入
        • 反復処理(イテレーション)
        • パラメータ抽出
        • HTTPリクエスト
        • エージェント
        • ツール
        • 繰り返し処理(ループ)
      • ショートカットキー
      • オーケストレートノード
      • ファイルアップロード
      • エラー処理
        • 事前定義されたエラー処理ロジック
        • エラータイプの概要
      • 追加機能
      • プレビューとデバッグ
        • プレビューと実行
        • ステップ実行
        • 対話/実行ログ
        • チェックリスト
        • 実行履歴
      • アプリケーション公開
      • JSON形式での出力
      • 変更通知:画像アップロード機能がファイルアップロード機能に統合されました
    • ナレッジベース
      • ナレッジベース作成
        • 1. オンラインデータソースの活用
          • 1.1 Notion からデータをインポート
          • 1.2 Webサイトからデータをインポート
        • 2. チャンクモードの指定
        • 3. インデックス方式と検索オプションの設定
      • ナレッジベースの管理
        • ナレッジベース内ドキュメントの管理
        • APIを活用したナレッジベースのメンテナンス
      • メタデータ
      • アプリ内でのナレッジベース統合
      • リコールテスト/引用帰属
      • ナレッジベースの要求頻度制限
      • 外部ナレッジベースとの接続
      • 外部ナレッジベースAPI
    • ツール
      • クイック統合ツール
      • 高度統合ツール
      • ツールの設定
        • Google
        • Bing
        • SearchApi
        • StableDiffusion
        • Perplexity Search
        • AlphaVantage 株式分析
        • Dall-e
        • Youtube
        • Serper
        • SearXNG
        • SiliconFlow(Flux AI サポート)
        • ComfyUI
    • アプリ公開
      • シングルページWebアプリとして公開
        • Web アプリの設定
        • テキスト生成アプリ
        • 対話型アプリ
      • Webサイトへの埋め込み
      • API基づく開発
      • フロントエンドテンプレートに基づいた再開発
    • アノテーション
      • ログとアノテーション
      • アノテーション返信
    • モニタリング
      • データ分析
      • 外部Opsツール統合
        • LangSmithを統合
        • LangFuseを統合
        • Opikを統合
    • 拡張
      • API 拡張
        • Cloudflare Workers を使用した API ツールのデプロイ
        • コンテンツモデレーション
      • コード拡張
        • 外部データツール
        • コンテンツモデレーション
    • コラボレーション
      • 発見
      • メンバーの招待と管理
    • 管理
      • アプリの管理
      • チームメンバーの管理
      • 個人アカウントの管理
      • サブスクリプション管理
      • バージョン管理
  • ハンドオン工房
    • 初級編
      • ゼロからAI画像生成アプリの構築方法
      • AIエージェントの実践:個人のオンライン旅行アシスタントの構築方法
    • 中級編
      • チャットストリームエージェントを使用した Twitter アカウントの分析方法
      • ファイルアップロードを使用した記事理解アシスタントの構築方法
  • コミュニティ
    • サポートの求め
    • 貢献者ガイド
    • ドキュメントへの貢献
  • プラグイン
    • 機能紹介
    • クイックスタート
      • プラグインのインストールと活用
      • プラグイン開発の入門
        • 開発環境のセットアップ
        • ツール型プラグイン
        • モデル型プラグイン
          • モデルプロバイダーの構築
          • 定義済みモデルの組み込み
          • カスタムモデルの組み込み
        • エージェント戦略プラグイン
        • 拡張機能型プラグイン
        • バンドル
      • プラグインのデバッグ方法
    • プラグイン管理方法
    • スキーマ仕様
      • Manifest(マニフェスト)
      • Endpoint(エンドポイント)
      • Tool(ツール)
      • Agent(エージェント)
      • Model(モデル)
        • モデル設計規則
        • モデルスキーマ
      • 一般的な標準仕様
      • 永続化されたストレージ
      • Difyサービスの逆呼び出し
        • アプリ
        • モデル
        • ツール
        • ノード
    • ベストプラクティス
      • Slack Bot プラグインの開発
      • Dify MCP プラグインガイド:ワンクリックで Zapier に接続してメールを自動送信
    • プラグインの公開
      • プラグインの自動公開
      • Difyマーケットプレイスへの公開
        • プラグイン開発者ガイドライン
        • プラグインのプライバシー保護に関するガイドライン
      • 個人GitHubリポジトリへの公開
      • ローカルでの公開と共有
      • 第三者署名検証のためにプラグインに署名する
    • よくある質問
  • 開発
    • バックエンド
      • DifySandbox
        • 貢献ガイド
    • モデルの統合
      • Hugging Faceのオープンソースモデルを統合
      • Replicateのオープンソースモデルを統合
      • Xinferenceでデプロイしたローカルモデルを統合
      • OpenLLMでデプロイしたローカルモデルを統合
      • LocalAIでデプロイしたローカルモデルを統合
      • Ollamaでデプロイしたローカルモデルを統合
      • LiteLLM Proxyを使用してモデルを統合する
      • GPUStackとの統合によるローカルモデルのデプロイ
      • AWS Bedrock上のモデル(DeepSeek)の接続
    • 移行
      • コミュニティ版を v1.0.0 に移行する
  • もっと読む
    • 活用事例
      • DeepSeek & Dify連携ガイド:多段階推論を活用したAIアプリケーション構築
      • Ollama + DeepSeek + Dify のプライベートデプロイ:あなた自身のAIアシスタントの構築方法
      • あなた専用のQAチャットボットのトレーニング方法
      • コードなしでMidjourney プロンプトボットを作成する方法
      • Notion AI アシスタントを構築する
      • 数分で業務データを持つ公式サイトのAIチャットボットを作成する方法
      • DifyチャットボットをWixサイトに統合する方法
      • AWS Bedrockのナレッジベースに統合する方法
      • Difyで大規模言語モデルの「競技場」を体験する方法:DeepSeek R1 VS o1 を例に
      • Difyスケジューラーの構築
      • DifyクラウドでAI Thesis Slack Botを構築
    • さらに読む
      • LLMOpsとは何ですか?
      • 配列変数とは何ですか?
      • 検索拡張生成(RAG)
        • ハイブリッド検索
        • Rerank
        • リトリーバルモード
      • プロンプトエンジニアリング
      • DifyでJSONスキーマ出力を使用する方法
    • FAQ
      • ローカルデプロイに関するFAQ
      • LLM設定と使用に関するFAQ
      • プラグイン
  • ポリシー
    • オープンソースライセンス
    • ユーザ規約
      • 利用規約
      • プライバシーポリシー
      • 合規性レポートの入手方法
Powered by GitBook
On this page
  1. マニュアル
  2. モデル

事前定義されたモデルの追加

プロバイダー統合完了後、次にプロバイダーへのモデルの接続を行います。

まず、接続するモデルのタイプを決定し、対応するプロバイダーのディレクトリ内に対応するモデルタイプのmoduleを作成する必要があります。

現在サポートされているモデルタイプは以下の通りです:

  • LLM テキスト生成モデル

  • text_embedding テキスト埋め込みモデル

  • rerank ランク付けモデル

  • speech2text 音声からテキストへの変換モデル

  • TTS テキストから音声への変換モデル

  • moderation 審査

ここではAnthropicを例に挙げると、AnthropicはLLMのみをサポートしているため、model_providers.anthropicにllmという名前のmoduleを作成します。

事前に定義されたモデルについては、llm module の下に、モデル名をファイル名とするYAMLファイルを作成する必要があります、例えば、claude-2.1.yaml。

モデルのYAMLファイルのサンプル

model: claude-2.1  # モデル識別子
# モデル表示名。en_US英語、zh_Hans中国語の二つの言語を設定できます。zh_Hansが設定されていない場合、デフォルトでen_USが使用されます。
# ラベルを設定しない場合、モデル識別子が使用されます。
label:
  en_US: claude-2.1
model_type: llm  # モデルタイプ、claude-2.1はLLMです
features:  # サポートする機能、agent-thoughtはエージェント推論、visionは画像理解をサポート
- agent-thought
model_properties:  # モデルプロパティ
  mode: chat  # LLMモード、completeはテキスト補完モデル、chatは対話モデル
  context_size: 200000  # 最大コンテキストサイズ
parameter_rules:  # モデル呼び出しパラメータルール、LLMのみ提供が必要
- name: temperature  # 呼び出しパラメータ変数名
  # デフォルトで5つの変数内容設定テンプレートが用意されています。temperature/top_p/max_tokens/presence_penalty/frequency_penalty
  # use_template内でテンプレート変数名を設定すると、entities.defaults.PARAMETER_RULE_TEMPLATE内のデフォルト設定が使用されます
  # 追加の設定パラメータを設定した場合、デフォルト設定を上書きします
  use_template: temperature
- name: top_p
  use_template: top_p
- name: top_k
  label:  # 呼び出しパラメータ表示名
    zh_Hans: 取样数量
    en_US: Top k
  type: int  # パラメータタイプ、float/int/string/booleanがサポートされています
  help:  # ヘルプ情報、パラメータの作用を説明
    zh_Hans: 仅从每个后续标记的前 K 个选项中采样。
    en_US: Only sample from the top K options for each subsequent token.
  required: false  # 必須かどうか、設定しない場合もあります
- name: max_tokens_to_sample
  use_template: max_tokens
  default: 4096  # パラメータデフォルト値
  min: 1  # パラメータ最小値、float/intのみ使用可能
  max: 4096  # パラメータ最大値、float/intのみ使用可能
pricing:  # 価格情報
  input: '8.00'  # 入力単価、つまりプロンプト単価
  output: '24.00'  # 出力単価、つまり返答内容単価
  unit: '0.000001'  # 価格単位、上記価格は100Kあたりの単価
  currency: USD  # 価格通貨

すべてのモデル構成が完了した後に、モデルコードの実装を開始することをお勧めします。

同様に、model_providersディレクトリ内の他のサプライヤーの対応するモデル タイプ ディレクトリにあるYAML構成情報を参照することもできます。全てのYAMLルールについては、「」をご覧ください。

モデル呼び出しコードの実装

次に、llm module内に同名のPythonファイルllm.pyを作成し、コード実装を行います。

llm.py内にAnthropic LLMクラスを作成し、AnthropicLargeLanguageModel(任意な名前)という名前を付けます。このクラスは__base.large_language_model.LargeLanguageModel基底クラスを継承し、以下のメソッドを実装します:

  • LLM呼び出し

    LLM呼び出しの中核メソッドを実装し、ストリーミングと同期返り値の両方をサポートするメソッドを実装します。

    def _invoke(self, model: str, credentials: dict,
                prompt_messages: list[PromptMessage], model_parameters: dict,
                tools: Optional[list[PromptMessageTool]] = None, stop: Optional[List[str]] = None,
                stream: bool = True, user: Optional[str] = None) \
            -> Union[LLMResult, Generator]:
        """
        Invoke large language model
    
        :param model: model name
        :param credentials: model credentials
        :param prompt_messages: prompt messages
        :param model_parameters: model parameters
        :param tools: tools for tool calling
        :param stop: stop words
        :param stream: is stream response
        :param user: unique user id
        :return: full response or stream response chunk generator result
        """

    実装時には、同期返答とストリーミング返答を処理するために2つの関数を使用する必要があります。Pythonはyieldキーワードを含む関数をジェネレータ関数として認識し、返されるデータタイプが固定されるため、同期返答とストリーミング返答を別々に実装する必要があります。以下のように(以下の例では簡略化されたパラメータを使用していますが、実際の実装では上記のパラメータリストに従う必要があります):

    def _invoke(self, stream: bool, **kwargs) \
            -> Union[LLMResult, Generator]:
        if stream:
              return self._handle_stream_response(**kwargs)
        return self._handle_sync_response(**kwargs)
    
    def _handle_stream_response(self, **kwargs) -> Generator:
        for chunk in response:
              yield chunk
    def _handle_sync_response(self, **kwargs) -> LLMResult:
        return LLMResult(**response)
  • 事前計算入力トークン

    モデルが事前計算トークンインターフェースを提供していない場合は、0を返しても構いません。

    def get_num_tokens(self, model: str, credentials: dict, prompt_messages: list[PromptMessage],
                       tools: Optional[list[PromptMessageTool]] = None) -> int:
        """
        Get number of tokens for given prompt messages
    
        :param model: model name
        :param credentials: model credentials
        :param prompt_messages: prompt messages
        :param tools: tools for tool calling
        :return:
        """
  • モデル認証情報検証

    プロバイダーの認証情報検証と同様に、ここでは個別のモデルに対して検証を行います。

    def validate_credentials(self, model: str, credentials: dict) -> None:
        """
        Validate model credentials
    
        :param model: model name
        :param credentials: model credentials
        :return:
        """
  • 呼び出し異常エラーのマッピングテーブル

    モデル呼び出し異常時に、Runtime時に指定のInvokeErrorタイプにマッピングする必要があります。これにより、Difyは異なるエラーに対して異なる後続処理を行うことができます。

    ランタイムエラー(Runtime Errors):

    • InvokeConnectionError 呼び出し接続エラー

    • InvokeServerUnavailableError 呼び出しサーバー利用不可エラー

    • InvokeRateLimitError 呼び出しレート制限エラー

    • InvokeAuthorizationError 認証エラー

    • InvokeBadRequestError 呼び出し不正リクエストエラー

    @property
    def _invoke_error_mapping(self) -> dict[type[InvokeError], list[type[Exception]]]:
        """
        Map model invoke error to unified error
        The key is the error type thrown to the caller
        The value is the error type thrown by the model,
        which needs to be converted into a unified error type for the caller.
    
        :return: Invoke error mapping
        """
Previous新しいプロバイダーの追加Nextカスタムモデルの追加

Last updated 7 months ago

インターフェースメソッドの説明については:をご覧ください。具体的な実装については:を参照してください。

Interfaces
llm.py