作成日：2024年05月24日
更新日：2024年12月30日 Dify-v0.14.2に対応
１．はじめに
Difyの登場で今まで生成AIのLLMの評価に時間を費やしていた企業などは、Difyの利用により、その時間を短縮し、より効率的な開発作業に注力することが可能となりました。
Difyの利用によって、開発者はAIの評価にかかる時間を大幅に削減し、開発作業の効率化が可能となります。
また、生成AIがマルチモーダルへの進化を遂げていく中で、Difyのようなローコードプラットフォームを活用することで、短時間でのサービス立ち上げが可能となり、開発の効率化が更に進むと思われます。
２．Difyとは
Dify(Do It For Yourselves)は、Luyu Zhang氏がCEOの米国のデラウェア州のLangGenius, Inc.が展開するクラウドサービスのローコードLLM(大規模言語モデル)アプリケーション開発プラットフォームです。
Difyはオープンソースのため、Apache License 2.0で商用利用も可能です。
DifyはBaaS(Backend-as-a-Service)とLLMOpsの概念を組み合わせ、開発者が簡単に本番グレードの生成AIアプリケーションを構築できるようにしています。
プロンプト編集インターフェース、高品質なRAGエンジン、柔軟なエージェントフレームワークなどの主要技術スタックを統合しており、数百のモデルをサポートしています。開発者は再発明の手間を省き、イノベーションとビジネスニーズに集中できます。
公式の初心者向けのチュートリアル動画がありますので、以下にリンクを貼ります。
2.1. Difyの構造
Difyは現在、nginx、api、worker、web、sandbox、redis、db、ssrf_proxy、weaviateの９つのマイクロサービスで構成されています。(Dify-0.6.8よりdocker-ssrf_proxy-1が増えました。)
docker-nginx-1ではリバースプロキシーのような働きで外部80ポート(HTTP)を内部80ポート(HTTP)に中継しているようです。
サーバ証明書をnginxに導入すればTLS化も容易にできそうです。
PCの性能にもよりますが、WSL2で動かすと、VM＋Dockerと多段構成になるので、かなり動作が重いです。
本番運用するならば、物理LinuxサーバやAWS EC2などで動かした方が現実的かもしれません。
間違っていたら申し訳ありませんが、公式サイトのdocker-compose.pngを参考に過去の経験からまとめたコンテナの関連図を以下にまとめます。
※こちらの図はDifyコミュニティ版のGitHub langgenius/difyのdocker-compose.pngファイルを参考にまとめたものです。
公式サイトの図：
３．特徴
langgenius/dify(GitHub)のREADME_JA.mdより引用
| No | 機能 | 説明 | 備考 |
|---|---|---|---|
| １ | ワークフロー | ビジュアルキャンバス上で強力なAIワークフローを構築してテストし、以下の機能を活用してプロトタイプを超えることができます。 | |
| 2 | 包括的なモデルサポート | 数百のプロプライエタリ/オープンソースのLLMと、数十の推論プロバイダーおよびセルフホスティングソリューションとのシームレスな統合を提供します。GPT、Mistral、Llama3、およびOpenAI API互換のモデルをカバーします。サポートされているモデルプロバイダーの完全なリストはhttps://docs.dify.ai/getting-started/readme/model-providersをご覧ください。 | |
| 3 | プロンプトIDE | チャットベースのアプリにテキスト読み上げなどの追加機能を追加するプロンプトを作成し、モデルのパフォーマンスを比較する直感的なインターフェース。 | |
| 4 | RAGパイプライン | 文書の取り込みから取得までをカバーする幅広いRAG機能で、PDF、PPTなどの一般的なドキュメント形式からのテキスト抽出に対するアウトオブボックスのサポートを提供します。 | |
| 5 | エージェント機能 | LLM関数呼び出しまたはReActに基づいてエージェントを定義し、エージェント向けの事前構築済みまたはカスタムのツールを追加できます。Difyには、Google検索、DELL·E、Stable Diffusion、WolframAlphaなどのAIエージェント用の50以上の組み込みツールが用意されています。 | |
| 6 | LLMOps | アプリケーションログとパフォーマンスを時間の経過とともにモニタリングおよび分析します。本番データと注釈に基づいて、プロンプト、データセット、およびモデルを継続的に改善できます。 | |
| 7 | BaaS(Backend-as-a-Service) | Difyのすべての提供には、それに対応するAPIが付属しており、独自のビジネスロジックにDifyをシームレスに統合できます。 |
４．Difyのバージョン
以下のようにDifyのバージョンアップは１回／週程度で行われています。
| No | バージョン | ローンチ | タイトル |
|---|---|---|---|
| 1 | v0.6.8 | 2024年5月14日 | v0.6.8 GPT-4o is available now in Dify |
| 11 | v0.7.0 | 2024年8月14日 | v0.7.0 |
| 16 | v0.8.0 | 2024年9月10日 | v0.8.0 |
| 20 | v0.9.0 | 2024年9月30日 | v0.9.0 |
| 27 | v0.10.0 | 2024年10月21日 | v0.10.0 |
| 28 | v0.10.1 | 2024年10月24日 | v0.10.1 |
| 29 | v0.10.2 | 2024年10月28日 | v0.10.2 |
| 30 | v0.11.0 | 2024年10月28日 | v0.11.0 |
| 31 | v0.11.1 | 2024年11月11日 | v0.11.1 |
| 32 | v0.11.2 | 2024年11月18日 | v0.11.2 |
| 33 | v0.12.0 | 2024年11月25日 | v0.12.0 |
| 34 | v0.12.1 | 2024年11月26日 | v0.12.1 |
| 35 | v0.13.0 | 2024年12月03日 | v0.13.0 |
| 36 | v0.13.1 | 2024年12月05日 | v0.13.1 |
| 37 | v0.13.2 | 2024年12月09日 | v0.13.2 |
| 38 | v0.14.0 | 2024年12月16日 | v0.14.0 |
| 39 | v0.14.1 | 2024年12月18日 | v0.14.1 |
| 40 | v0.14.2 | 2024年12月23日 | v0.14.2 |
５．Difyのホスティング
Docker Composeでホスティングするのが簡単でお勧めです。
私の動作実績ではAWSのEC2、WSL2+Docker Composeで動作実績があります。
まだ試せていませんがAWS Amazon LightsailやACI(Azure Container Instances)などのマルチコンテナーに対応したクラウド環境でも動かせそうです。
Difyはマイクロサービスが９つも動作するのでIaaSのセキュリティ対策コストを感が無ければ、IaaSで立ち上げた方が安価にすむかもしれません。
そのうちACIなどでも動かしてコスト比較してみます。
| No | ホスティング環境 | 確認状況 | 備考 |
|---|---|---|---|
| 1 | Windows Docker | 未テスト | 個人環境でしか利用できないため評価していません。 |
| 2 | Linux Docker | Rocky Linux 9.3環境で動作実績あり | |
| 3 | Windows+WSL2+Docker | 動作実績あり | |
| 4 | Windows+Node.js+Python | 未テスト | どのようにAPIサーバなどが動作するのか興味あります |
| 5 | IaaS | 未テスト | EC2 UbuntuのDocker環境で動作実績あり。 |
| 6 | PaaS | 未テスト | AWS LightsailやAzure ACIでも動作させられそうです Lightsailで動作させる方法は@hidekiさんのDifyをAmazon Lightsailで動かす記事を参照してください Azure App Serviceの単一コンテナではコストが掛るため、プレビュー版の複数コンテナーで試してみましたが4000文字問題でDifyを起動することができませんでした。詳しくは「Azure Cloud Shellでの複数コンテナーApp Service作成」記事をご覧ください。 |
６．Difyの起動
Difyの構築はGitHubのソースコードからの構築とDocker Composeでの構築の２つの方法があります。
DifyはGitHubで最新版を取得します。
root@Ardbeg:~# git clone https://github.com/langgenius/dify.git
Cloning into 'dify'...
remote: Enumerating objects: 129154, done.
remote: Counting objects: 100% (23749/23749), done.
remote: Compressing objects: 100% (1582/1582), done.
remote: Total 129154 (delta 22874), reused 22175 (delta 22167), pack-reused 105405 (from 2)
Receiving objects: 100% (129154/129154), 65.33 MiB | 21.76 MiB/s, done.
Resolving deltas: 100% (96088/96088), done.
root@Ardbeg:~#
root@Ardbeg:~# cd dify/docker
root@Ardbeg:~/dify/docker# cp .env.example .env
root@Ardbeg:~/dify/docker# docker compose up -d
[+] Running 9/38
⠴ worker [⣿⣿⣿⣿⣿⣿⣿⣦⡀⣿⣿⠀] Pulling 7.5s
⠴ api Pulling 7.5s
⠴ nginx [⠀⠀⠀⠀⠀⠀⠀] Pulling 7.5s
⠼ db [⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀] Pulling 7.5s
⠼ redis [⠀⠀⠀⠀⠀⠀⠀] Pulling 7.5s
⠼ ssrf_proxy [⠀⠀⠀] Pulling 7.5s
⠼ web [⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀] Pulling 7.5s
⠼ sandbox [⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀] Pulling 7.5s
⠼ weaviate [⠀⠀⠀⠀] Pulling
[+] Running 11/11
✔ Network docker_ssrf_proxy_network Created 0.2s
✔ Network docker_default Created 0.2s
✔ Container docker-sandbox-1 Started 0.6s
✔ Container docker-db-1 Started 1.8s
✔ Container docker-web-1 Started 1.8s
✔ Container docker-ssrf_proxy-1 Started 1.7s
✔ Container docker-redis-1 Started 0.9s
✔ Container docker-weaviate-1 Started 1.8s
✔ Container docker-api-1 Started 2.8s
✔ Container docker-worker-1 Started 2.8s
✔ Container docker-nginx-1 Started
root@Ardbeg:~/dify/docker# docker ps
CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS
NAMES
6cccf873b8b0 nginx:latest "sh -c 'cp /docker-e…" 56 seconds ago Up 52 seconds 0.0.0.0:80->80/tcp, :::80->80/tcp, 0.0.0.0:443->443/tcp, :::443->443/tcp docker-nginx-1
30c34a335f80 langgenius/dify-api:0.14.2 "/bin/bash /entrypoi…" 56 seconds ago Up 53 seconds 5001/tcp
docker-api-1
a6bf2ff021ae langgenius/dify-api:0.14.2 "/bin/bash /entrypoi…" 56 seconds ago Up 54 seconds 5001/tcp
docker-worker-1
50e0a7391554 langgenius/dify-web:0.14.2 "/bin/sh ./entrypoin…" 56 seconds ago Restarting (0) 23 seconds ago
docker-web-1
2e17e2ade0e2 postgres:15-alpine "docker-entrypoint.s…" 56 seconds ago Up 55 seconds (healthy) 5432/tcp
docker-db-1
cd464767844b langgenius/dify-sandbox:0.2.10 "/main" 56 seconds ago Up 55 seconds (healthy)
docker-sandbox-1
1c68a313b73a redis:6-alpine "docker-entrypoint.s…" 56 seconds ago Up 55 seconds (healthy) 6379/tcp
docker-redis-1
cc1f53bb3437 semitechnologies/weaviate:1.19.0 "/bin/weaviate --hos…" 56 seconds ago Up 55 seconds
docker-weaviate-1
206426ce163a ubuntu/squid:latest "sh -c 'cp /docker-e…" 56 seconds ago Up 55 seconds 3128/tcp
docker-ssrf_proxy-1
root@Ardbeg:~/dify/docker#
※docker psの画面はv0.6.8の時のものです。
※私の環境では、docker-composeがすでに導入されているため、docker-composeを使用しています。docker composeコマンドでも動作は可能です。
- Dify-v0.6.7以前をお使いの方
Dify-v0.6.7を導入済みの方は2024年5月13日にローンチされたDifyの0.6.8の docker-compose.yamlファイル にアップデートが必要です。
アップデート手順は「v0.6.8 GPT-4o is available now in Dify」を参照してください。
[root@Ardbeg dify]# git checkout main
[root@Ardbeg dify]# git pull origin main
[root@Ardbeg dify]# cd docker
[root@Ardbeg docker]# docker-compose up -d
WARN[0000] /root/dify/docker/docker-compose.yaml: `version` is obsolete
[+] Running 35/27
⠋ api Pulling 107.0s
⠋ web [⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿] 17.82MB / 25.44MB Pulling 107.0s
✔ sandbox Pulled 22.9s
⠋ worker [⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿] 517.2MB / 526.7MB Pulling 107.0s
✔ ssrf_proxy Pulled 15.9s
- Dify-v0.6.12以降をお使いの方
2024年7月28日にローンチされたDify-v0.6.12以降ではdify/dockerフォルダ内の.env.exampleを.envにコピー(cp .env.example .env)する必要があります。
[root@Ardbeg ~]# git clone https://github.com/langgenius/dify.git
[root@Ardbeg ~]# cd dify/docker
[root@Ardbeg docker]# cp .env.example .env
[root@Ardbeg docker]# docker compose up -d
７．Difyへのアクセス
WSL2を使用して構築したDifyにはlocalhostでアクセス可能です。
http://localhost/
初回アクセスでは管理者のアカウントを設定します。
※ユーザ名は全員が今後使用するDifyの名前になるため、慎重に決めましょう。
起動したらバージョンがGPT-4oに対応する0.6.8になっていることを確認しましょう。
GitHubの「v0.6.8 GPT-4o is available now in Dify」ページ参照
８．v0.6.8のOpenAIのgpt-4oとAzure OpenAIのgpt-4o
DifyでのLLMサポートはOpenAIとAzure OpenAIでバージョンに差があります。
からなりReleases Noteを確認しましょう。
- OpenAI Service
まず、Difyのモデルプロバイダー一覧でOpenAIのgpt-4oがサポートされているかを確認します。(この画像はv0.6.8の時のキャプチャですがv0.10.1でも変わりはありません。)
-
Azure OpenAI Service
DifyのAzure OpenAI gpt-4o対応はv0.6.9なので、この時使用していたv0.6.8ではAzure OpenAIのgpt-4oは表示されません。(OpenAIとAzure OpenAIではサポートバージョンが異なるので注意が必要です。)
９．gpt-4oの設定
2024年5月25日(土)時点のv0.6.8ではgpt-4oは前途のようにOpenAI Serviceでしか導入できないため、OpenAIでのAPIキー設定例を以下に貼り付けます。
2024年10月26日(土)時点のv0.10.1ではOpenAI/Azure OpenAI共にgpt-4oはサポートされています。
OpenAIの設定ではOrganizationやAPI Baseなどは空欄で大丈夫です。
１０．使ってみる
Difyで作成したフローを「公開する」で公開し、「アプリを実行」とすると以下のようなアプリのURLが生成されブラウザが開くので、ここが一般ユーザがアクセスするサイトとなります。
チャットボットをローコードで作成して、URLを生成して一般公開という流れになります。
http://localhost/chat/DR5cAM133kvpxxqJ
10.1. 写真の説明
この画像には、バーのカウンターに並べられた飲み物のボトルとショットグラスが写っています。
中央には「Sauza Hacienda Tequila Silver」と明記された大きなテキーラのボトルがあり、その前に冷えたショットグラスが置かれています。
背景には他のアルコール飲料のボトルが見え、左上にオレンジ色の装飾物が少し写っています。
ボトルの裏側には「ALCOOL」や「STOLICHNAYA」のラベルが確認でき、おそらくリキュールやウォッカの一部です。
また、背景には「WORLD'S No.1 BO」の文字も確認できます。このシーンはバーかパブの一部と思われます。
10.2. 構成図の解説
システムプロンプト
あなたは優秀なAIアシスタントです。
ユーザーからの質問をStep-By-Stepで考えて、適切で分かりやすい回答をしてください。
回答できない場合は無理に回答せず、「知識が無くて回答できません。」と答えてください。
回答を作成する際は根拠となるホームページや情報のエビデンスを[1](https://yahoo.com/)形式で文章の最後に追加してください。
GPT-4-Visionで試してみたところ、アップロードボタンが表示され画像がアップロードできるようになった。
画像はpng、jpg、jpeg、webp、gifに対応している模様
試しに「すべてのファイル」にしてMarkdownをアップロードしてみたがアップロードは受け付けられなかった。)
１１．気に入った点
-
LLMの対応が早いこと
以下にAzure OpoenAIのLLMの対応日時をまとめておきます。
| No | LLM | 説明 | 備考 |
|---|---|---|---|
| 1 | Azure gpt-4o | v0.6.9 Workflow as Toolによればv0.6.9にて正式にAzure OpenAI gpt-4oに対応しています。 | |
| 2 | Azure gpt-4o-mini | 2024年8月6日にローンチのv0.6.16でサポート | |
| 3 | Azure o1-mini/o1-preview | 2024年10月14日にローンチのv0.9.2でサポート |
v0.6.9 Workflow as Toolによればv0.6.9にて正式にAzure OpenAI Serviceに対応されていますが、ここではOpenAIのgpt-4oで検証を実施します。
-
マルチモーダル
最近はPlayGroundの対応も早いですが画像のマルチモーダルが直ぐに試せます。
v0.10.0から画像以外のドキュメント、音声、動画など、様々なファイルがアップロードできるようになりましたが、まだ、直接LLMノードに渡せるわけではありません。2024年10月26日時点のv0.10.1ではアップロードしたファイル(sys.files)をDocument Extractorで自然言語化してLLMに渡す必要があります。
GPT-4o/GPT-4o-mini/o1-preview/o1-miniでは本来、音声や動画をサポートできるはずです。
ドキュメントはAzureのAssistant APIなどを有効にしないと渡せない仕様ですが、まだ試せていません。
画像についてはsys.filesでアップロードして従来通り、LLMに直接渡せます。 -
ollamaに対応していること
ローカル環境でLLMを動作させるollmaのAPIを設定できるため、MetaのLlama3やMicrosoftのPhiにも直ぐに対応できます。
Open WebUIでもよいかもしれませんが、他のLLMと環境を共存できます。 -
ワークフロー機能
LLMは多様な特性を持つため、フローを使用してマルチLLM環境で特性を活かしたチャットボットを作成できます。 -
Codeノード(Code Node)
Python、Javascriptのコードで入力を加工するブロックを作成することができます。
Codeノードはv0.6.12以降でデフォルトで動作するようになっています。 -
引用と帰属
基本チャットボットではサポートされていた機能ですが、v0.6.12以降でチャットフローでもRAG(Retrival Augumented Generations)を行った際に引用元を表示できるように改善されています。
１２．気になった点
12.1. GUIがかなりプア
会話のスレッド管理や画像アップロードなど、最低限の機能しかありません。
具体的にはMarkdown上のMermaidコードブロック等が表示できません。
この問題については「DifyのフローをChatbot UIから利用する(dify2openai)」の記事でdify2openaiという中継ツールを仕様してdifyのAPIをOpenAI API Compatibleに変換し、OpenAI LLMとしてDifyのチャットフローを利用する試みを実施しています。
-
Markdownの表の表示
-
Markdownのコードブロック
-
MarkdownのMermaidコードブロック
12.2. 画像ファイル以外のアップロード
v0.6.8～v0.9.2まではアップロードは画像ファイルに限定されておりましたが、v0.10.0以降で画像以外のドキュメント、音声、動画など、様々なファイルがアップロードできるようになりました。
ドキュメントをLLMに認識させるにはAssistant API(Code Interpreter)が必要ですし、動画などはアップロードできるかなどまた試せていません。
-
v0.9.2までのアップロード
-
v0.10.0以降のアップロード
12.3. チャット履歴のイメージ画像
アップロードしたファイルはブラウザセッションを開き直した時にチャット履歴に表示されません。（これは困る）
１３．使い方のアイデア
13.1. 埋め込みの活用
埋め込みでのチャットボットなどは簡単に作成できるので、RAGやRerankを使用した埋め込み型の問い合わせシステムを構築するにはよさそうです。
13.2. BaaS(Backend-as-a-Service)を活用
GUIがリッチなChatbot UIなどのカスタムLLMを使用して、Difyで作成したフローをChatbot UIのGUIから利用する。
DifyをBaaSとしてOpenAI APIの互換エンドポイントとして動作させるDifyのフローをChatbot UIから利用する(dify2openai)記事を執筆していますので、是非ご覧ください。
１４．留意事項
-
所有者のパスワードのリセット
Difyの公式ドキュメントの「よくある質問」の「４．管理者アカウントのパスワードをリセットする方法」に記載があります。
root@Ardbeg:~/dify/docker# docker exec -it docker-api-1 flask reset-password
None of PyTorch, TensorFlow >= 2.0, or Flax have been found. Models won't be available and only tokenizers, configuration and file/data utilities can be used.
2024-12-29 23:04:37,960.960 INFO [MainThread] [utils.py:148] - Note: NumExpr detected 16 cores but "NUMEXPR_MAX_THREADS" not set, so enforcing safe limit of 8.
2024-12-29 23:04:37,961.961 INFO [MainThread] [utils.py:160] - NumExpr defaulting to 8 threads.
Email: hoge@d6.dion.ne.jp
New password: hogehoge
Password confirm: hogehoge
-
python3.12のルート証明書
DifyのSandboxではPythonが動作しているが、企業内のサーバ証明書などを利用する場合、APIコンテナなどの
/app/api/.venv/lib/python3.12/site-packages/certifi/cacert.pemファイルなどをdocker-compose.yamlのvolumesなどで指定して書き込む必要がある。
この設定を入れないとdocker-api-1のログに「SSL: CERTIFICATE_VERIFY_FAILED」エラーが表示され企業内の
サーバーとの通信ができない。
参考：Dify GitHub discussions #4600
-- **所有者(管理者)のアカウントロックの解除
Difyではパスワードを何度か間違えるとLOGIN_LOCKOUT_DURATIONの値(86400)の設定により24時間アカウントがロックされる仕様があります。アカウントロック中は「Too many incorrect password attempts」エラーメッセージが表示されサインインできません。
langgenius/difyのissues #11759によればこれを強制的に解除するには「reset_login_error_rate_limit」というredis(一時的な状態を維持するDB)のエントリーを削除することにより強制的に解除することができるそうです。
root@Ardbeg:~/dify/docker# docker exec -it docker-redis-1 redis-cli
127.0.0.1:6379> keys login_error_rate_limit:*
1) "login_error_raite_limit:hogehoge@example.com"
127.0.0.1:6379> del login_error_raite_limit:hogehoge@example.com
(integer) 0
127.0.0.1:6379> keys login_error_rate_limit:*
(empty array)
127.0.0.1:6379> quit
１５．サポート要望
- Azure OpenAI Service Assistants API対応
OpenAIのCode InterpreterやOSSのOpen InterpreterのAzure版です。
マルチモーダル時代にはサポート必須の機能かと思います。
※Azure OpenAI Assistants API Support #6261
※Assistants APIの詳細はAzure OpenAI Assistants API (プレビュー)ページ参照
１６．関連記事
- DifyのフローをChatbot UIから利用する(dify2openai) (2024年9月20日(金) Qiita)
１７．参考サイト
- Dify.AI · The Innovation Engine for Generative AI Applications (LangGenius, Inc.：クラウドサービス)
- langgenius/dify (GitHub)
- langgenius/dify-docs (GitHub)
- Dify - Your Weekend GenAI Magics (GitHub)
- Dify License (GitHub:Apache License 2.0)
- コントリビュート (GitHub)
- Dify.AI v0.3.30 is here! Explore the Exciting GPT4-Vision Multimodal Model - Dify Blog
- DifyをAmazon Lightsailで動かす (@hidekiさん)