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. モデル

カスタムモデルの追加

Previous事前定義されたモデルの追加Nextインタフェース

Last updated 6 months ago

イントロダクション

ベンダー統合が完了した後、次にベンダーの下でモデルのインテグレーションを行います。ここでは、全体のプロセスを理解するために、例としてXinferenceを使用して、段階的にベンダーのインテグレーションを完了します。

注意が必要なのは、カスタムモデルの場合、各モデルのインテグレーションには完全なベンダークレデンシャルの記入が必要です。

事前定義モデルとは異なり、カスタムベンダーのインテグレーション時には常に以下の2つのパラメータが存在し、ベンダー yaml に定義する必要はありません。

前述したように、ベンダーはvalidate_provider_credentialを実装する必要はなく、Runtimeがユーザーが選択したモデルタイプとモデル名に基づいて、対応するモデル層のvalidate_credentialsを呼び出して検証を行います。

ベンダー yaml の作成

まず、インテグレーションを行うベンダーがどのタイプのモデルをサポートしているかを確認します。

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

  • llm テキスト生成モデル

  • text_embedding テキスト Embedding モデル

  • rerank Rerank モデル

  • speech2text 音声からテキスト変換

  • tts テキストから音声変換

  • moderation モデレーション

XinferenceはLLM、Text Embedding、Rerankをサポートしているため、xinference.yamlを作成します。

provider: xinference # Specify vendor identifier
label: # Vendor display name, can be set in en_US (English) and zh_Hans (Simplified Chinese). If zh_Hans is not set, en_US will be used by default.
  en_US: Xorbits Inference
icon_small: # Small icon, refer to other vendors' icons, stored in the _assets directory under the corresponding vendor implementation directory. Language strategy is the same as label.
  en_US: icon_s_en.svg
icon_large: # Large icon
  en_US: icon_l_en.svg
help: # Help
  title:
    en_US: How to deploy Xinference
    zh_Hans: 如何部署 Xinference
  url:
    en_US: https://github.com/xorbitsai/inference
supported_model_types: # Supported model types. Xinference supports LLM/Text Embedding/Rerank
- llm
- text-embedding
- rerank
configurate_methods: # Since Xinference is a locally deployed vendor and does not have predefined models, you need to deploy the required models according to Xinference's documentation. Therefore, only custom models are supported here.
- customizable-model
provider_credential_schema:
  credential_form_schemas:

その後、Xinferenceでモデルを定義するために必要なクレデンシャルを考えます。

  • 3つの異なるモデルをサポートするため、model_typeを使用してこのモデルのタイプを指定する必要があります。3つのタイプがあるので、次のように記述します。

provider_credential_schema:
  credential_form_schemas:
  - variable: model_type
    type: select
    label:
      en_US: Model type
      zh_Hans: 模型类型
    required: true
    options:
    - value: text-generation
      label:
        en_US: Language Model
        zh_Hans: 言語モデル
    - value: embeddings
      label:
        en_US: Text Embedding
    - value: reranking
      label:
        en_US: Rerank
  • 各モデルには独自の名称model_nameがあるため、ここで定義する必要があります。

  - variable: model_name
    type: text-input
    label:
      en_US: Model name
      zh_Hans: 模型名称
    required: true
    placeholder:
      zh_Hans: 填写模型名称
      en_US: Input model name
  • Xinferenceのローカルデプロイのアドレスを記入します。

  - variable: server_url
    label:
      zh_Hans: 服务器URL
      en_US: Server url
    type: text-input
    required: true
    placeholder:
      zh_Hans: 在此输入Xinference的服务器地址,如 https://example.com/xxx
      en_US: Enter the url of your Xinference, for example https://example.com/xxx
  • 各モデルには一意の model_uid があるため、ここで定義する必要があります。

  - variable: model_uid
    label:
      zh_Hans: 模型 UID
      en_US: Model uid
    type: text-input
    required: true
    placeholder:
      zh_Hans: 在此输入你的 Model UID
      en_US: Enter the model uid

これで、ベンダーの基本定義が完了しました。

モデルコードの作成

次に、llmタイプを例にとって、xinference.llm.llm.pyを作成します。

llm.py内で、Xinference LLM クラスを作成し、XinferenceAILargeLanguageModel(任意の名前)と名付けて、__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:
      """

    時には、直接0を返す必要がない場合もあります。その場合はself._get_num_tokens_by_gpt2(text: str)を使用して予測トークン数を取得することができます。このメソッドはAIModel基底クラスにあり、GPT2のTokenizerを使用して計算を行いますが、代替方法として使用されるものであり、完全に正確ではありません。

  • モデルクレデンシャル検証

    ベンダークレデンシャル検証と同様に、ここでは個々のモデルについて検証を行います。

    def validate_credentials(self, model: str, credentials: dict) -> None:
        """
        Validate model credentials
    
        :param model: model name
        :param credentials: model credentials
        :return:
        """
  • モデルパラメータスキーマ

    カスタムタイプとは異なり、yamlファイルでモデルがサポートするパラメータを定義していないため、動的にモデルパラメータのスキーマを生成する必要があります。

    例えば、Xinferenceはmax_tokens、temperature、top_pの3つのモデルパラメータをサポートしています。

    しかし、ベンダーによっては異なるモデルに対して異なるパラメータをサポートしている場合があります。例えば、ベンダーOpenLLMはtop_kをサポートしていますが、全てのモデルがtop_kをサポートしているわけではありません。ここでは、例としてAモデルがtop_kをサポートし、Bモデルがtop_kをサポートしていない場合、以下のように動的にモデルパラメータのスキーマを生成します:

    def get_customizable_model_schema(self, model: str, credentials: dict) -> AIModelEntity | None:
        """
            used to define customizable model schema
        """
        rules = [
            ParameterRule(
                name='temperature', type=ParameterType.FLOAT,
                use_template='temperature',
                label=I18nObject(
                    zh_Hans='温度', en_US='Temperature'
                )
            ),
            ParameterRule(
                name='top_p', type=ParameterType.FLOAT,
                use_template='top_p',
                label=I18nObject(
                    zh_Hans='Top P', en_US='Top P'
                )
            ),
            ParameterRule(
                name='max_tokens', type=ParameterType.INT,
                use_template='max_tokens',
                min=1,
                default=512,
                label=I18nObject(
                    zh_Hans='最大生成长度', en_US='Max Tokens'
                )
            )
        ]
    
        # if model is A, add top_k to rules
        if model == 'A':
            rules.append(
                ParameterRule(
                    name='top_k', type=ParameterType.INT,
                    use_template='top_k',
                    min=1,
                    default=50,
                    label=I18nObject(
                        zh_Hans='Top K', en_US='Top K'
                    )
                )
            )
    
        """
            some NOT IMPORTANT code here
        """
    
        entity = AIModelEntity(
            model=model,
            label=I18nObject(
                en_US=model
            ),
            fetch_from=FetchFrom.CUSTOMIZABLE_MODEL,
            model_type=model_type,
            model_properties={ 
                ModelPropertyKey.MODE:  ModelType.LLM,
            },
            parameter_rules=rules
        )
    
        return entity
  • 呼び出しエラーマッピングテーブル

    モデル呼び出し時にエラーが発生した場合、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
    """

インターフェース方法の詳細については:をご覧ください。具体的な実装例については、を参照してください。

インターフェース
llm.py