公開日:

Dify - この素晴らしきLLMアプリ開発環境

Authors
  • author image
    Name
    代表取締役 宮永邦彦
    Twitter
    @miyanaga

  • 画像軽量化とWebフロントエンドのスピード改善の専門家です。Web系のIT技術大好き。

    このサイトではスピード改善のリアルや、日々の技術的な気づきを共有します。

LLMアプリの開発プラットフォームDifyを使い始めた。もう楽しすぎる。

「便利そうだけど、APIを使ってプログラミングした方が柔軟じゃないか？」とすぐに飛びつかなかったかつての自分に、「Difyはいいぞ！」と諭すつもりで、どんなことができて、どんなメリットがあるか紹介したい。

まだ触りたてなので間違っているところもあるかもしれない。間違いは容赦いただきたい。

まずはLLMモデル登録 ​

Difyは、当然であるのだが、LLMモデルを内蔵していない。ChatGPTをはじめ外部のAPIを利用する。

何はなくともまずは右上のメニューから設定を開き、モデルプロバイダーに自身の持っているAPIを登録する。

モデルプロバイダー

複数のモデルを登録して、同じチャットメッセージにどう反応するか比較することもできる。

Difyはワークフローエンジン・中核の「スタジオ」 ​

Difyは本質的には、LLM特化型のワークフローエンジンという印象である。n8nやZapierに近い。

曜日を計算するフローチャート

最近、n8nやZapierを触っていないのだが、今やLLMノードを備えている可能性は高いだろう。両者は近づいているかもしれない。

しかしDifyは、LLMアプリ開発に振り切ったところがある。他のワークフロー型サービスに慣れた人でも、乗り換える価値はあるだろう。

ワークフローとユースケース ​

Difyでアプリを作成するとき、次のダイアログが表示される。

アプリの作成画面

裏側ではワークフロー型プログラムであるが、以下のユースケースについては簡単にフォームで設計できるようになっている。

  • チャットボット ChatGPTライクなチャットUI。
  • テキストジェネレーター フォーム入力に対しテキストを生成。
  • エージェント フォーム入力に対し他のサービスを操作。

ユースケースは設定ウィザードのようなもので、ユースケースで作り始め、途中からワークフローに変換することもできる(その逆にユースケースに戻すことはできない)。

ユースケース間の使い分け ​

テキストジェネレーターとエージェントはよく似ている。いずれも設計されたフォームをインプットとするが、アウトプットが、

  • テキストジェネレーターは文字通りテキスト
  • エージェントはSlackなど他のサービスのAPIを呼び出す

その違いに過ぎないようだ。

また、チャットボットとテキストジェネレーターも似ている。こちらはアウトプットが同じテキストであるが、

  • チャットボットは入力が自然言語テキストで繰り返し会話できる
  • テキストジェネレーターは入力がフォームで一度の処理で終わる

という違いがある。

ワークフローとチャットフロー ​

テキストジェネレーターとエージェントはワークフローに還元すると文字通り「ワークフロー」になるが、チャットボットは「チャットフロー」という扱いになるらしい。

しかしこれらも、開始ブロックと終了ブロックの違いしか無いように見える。

  • ワークフロー
    • 開始ブロックは入力フォームを設計できる
    • 終了ブロックで終了する
  • チャットフロー
    • 開始ブロックは自然言語のテキストをひとつ入力する
    • 終了ブロックではなく回答ブロックで、回答のあとは自動で開始ブロックに戻る

チャットフローの開始ブロックでも入力フォームを設計できる。しかしこれはチャットボット全体のパラメータのようなもので、チャット開始前に選択する。

IPAで公開されているセキュリティ関連資料を語るんだチャットボットです

チャット中はあくまで自然言語によるテキストひとつのみが入力できる。

ブロックの種類 ​

ワークフローでは次のブロックを利用できる。ツールは後述する外部のAPI群で、外部サービスの情報を参照したり、作用を及ぼすことができる。

ブロックのリスト

ブロック間の入出力の受け渡し ​

ブロック間には当然、入出力がある。最近のワークフローシステムによく見られるように、ブロックからは他の任意のブロックの出力値を参照して入力値にできる。

例えば以下では、Weekday Calculatorというブロック(ツール)はパラメータ抽出ブロックの出力値を参照しているが、他のブロックの値も参照できる。

曜日を計算する

ブロック間のつながりは入出力ではなく、実行順序に過ぎないというイメージだ。

ログや統計データ ​

ワークフローエンジンの利点はビジュアルプログラミングだけではない。ログの記録や利用統計の集計など、自前のプログラミングだと毎回、億劫になる部分を初めから備えている。

ログ機能では会話の再現が見られる。

クレジットカード情報を安全に扱うための方法

利用統計も充実している。特にLLMアプリには、「トークン」という単位の仕入れがある。このあたりも細かく抑えておきたいところだが、自作アプリだとつい後手に回ってしまうところだろう。

4つのグラフが並んでいる。

コラボレーションを容易にする注釈機能 ​

チャットボット(チャットフロー)には注釈という機能がある。これも素晴らしい機能で、チャットボットを簡単に矯正できる。

デバッグしたり、ログを見ながら気づいた点があれば、「こういう質問がきたら、こう返して欲しい」というフィードバックを残せる。

「注釈の返信」をONにしておくと、注釈をそのまま回答にすることもできる。

チャットボットとの会話

LLMアプリでは、仕組みを実装するエンジニアとコンテンツを提供する人が別であることがほとんどだ。簡単にコラボレーションする仕組みとしてよく考えられている。

作ってそのままAPI公開可能 ​

作成したアプリはそのままAPIとしても公開される。このあたりもエンドポイントをどこに実装するかや、HTTPとの繋ぎ込みなど、本来のロジックと別に思索を巡らせるところだ。初めからノーコードで実現できるのはありがたい。

認証方式はAPIキーである。Bearerとして、Authorizationヘッダに渡す。

APIキーはアプリごとに発行されるので、APIキー自体がアプリを一意に定める役割がある。

リファレンスによると、APIには音声処理もある。音声からの文字起こし、テキストからの音声生成、いずれも備えているようだ(どのモデルを使うかは不明)。したがってUIの音声対応もDifyのワンストップで実現できる。

ベクトルデータベースによる外部知識「ナレッジ」 ​

LLMが備えていないニッチな専門知識を組み合わせる手法としてRAGがある。

RAGの実現にはまずベクトルデータベースを用意して、ニッチな専門知識を取り込む必要がある。そして回答を生成する際にはそのデータベースを適切に参照する。これらの操作もまた敷居が高い。

しかしDifyには初めからベクトルデータベースと、いくつかのインポート機能が備わっており、非常に簡単に専門知識をインストールできる。

  • テキストファイルのインポート テキストファイルはもちろん、PDFやWordファイル、CSVなどにも対応している。
  • Notionから同期 まだ試せていないが、Notionのデータベースと同期できると思われる。
  • ウェブサイトから同期 Firecrawlと連携し、Webサイトをクローリングして情報をインポートできる。

例えば以下は、IPAが公開しているセキュリティ関連のガイドラインPDFをいくつかベクトルデータベースに取り込んだチャットボットだ。

クレジットカード情報の安全な取り扱い方の問い合わせ

このくらいならLLMに含まれている知識かもしれないが、引用元のPDFが示されている。

Firecrawl ​

今のところ、ナレッジのWebクローラーはFirecrawlにのみ対応しているようで、別途そのAPIキーの用意も必要になる。

FirecrawlもAGPL-3.0のオープンソースなので、セルフホストもできる。

DifyとFirecrawlのセルフホストはまた別の記事で解説したいと考えている。

ベクトルデータベースはかなり高負荷か？ ​

現在、Difyをセルフホスティングしていろいろと試しているが、ウェブサイトのクローリングで弊社サイトを取り込んでみたところ、サーバーのロードアベレージが100以上で張り付いてしまい、Dockerも応答せずサーバーの再起動を余儀なくされた。

ベクトルデータベースにはWeaviateが使われているようだ。

ページ数は250程度とそこまでの規模ではなく、サーバーには8GBのメモリを割り当てていた。ZIPファイルも取り込みの対象になってしまったからだろうか。詳しい原因は不明だが、運用上の懸念が残った。

外部連携を担う「ツール」 ​

静的なナレッジ以外にも、APIによる外部サービスとの連携も充実している。Difyでは外部連携のユニットをツールと呼ぶ。

ツールにはGoogleやBindなどの検索系、Wikipedia、Slackなどのメッセージ系などさまざな用意があるが、自分のAPIサーバーも追加できる。

様々な検索エンジンの紹介

カスタムツールによる自前のAPI連携 ​

自前のAPIを連携対象に加えるには、OpenAPI Swaggerによるスキーマ記述が必要になる。

一手間かかることにはなるが、スキーマが明示的であるおかげでワークフロー上でのビジュアルプログラミングが容易になり、ユーザーのラフな入力も正確にマッピングすることを担保できる。

カスタムルール作成画面

既存ワークフローのツール ​

すでに作成済みのワークフローも、ツールの一種として他のワークフローにインクルードできる。

しかしチャットフローはツール化できない。

Difyはどんなシーンに使えるか ​

爆速プロトタイピング ​

LLMの業務利用はまだまだ手探りの状態だ。

ChatGPTのビジネス利用が進んでいると言われているが、まだまだパーソナルアシスタントとしてに過ぎない。現実の業務にどう絡めていくか、最適解が見つかるのはこれからだ。

まだ予想まかせで大きく賭けてはいけない。かといって従来の延長で未来を予測することもできない。いま必要なのは、小さく作って実際に触ってもらいフィードバックを得る、その繰り返しで手応えを積むことである。

そのような小回りを効かせた体験的PoCに、Difyによるプロトタイピングは

場合によっては本番利用も ​

前述の通り、Difyには「いざ自前で実装しようとすると億劫な補助的実装」が一通り揃っている。そして外部ツールとの連携も開かれている。本番環境におけるプラットフォームとしても十分、考慮に値する。

しかし実際はケースバイケースであろう。

  • アプリケーションへの組み込み 小規模な仕掛けであれば最終的に対象の業務アプリケーションの機能として組み込んだ方がよいこともある。
  • パフォーマンスとスケーラビリティ Difyには性能の上限がある。特に大規模RAGは専用のベクトルデータベースが必要になりそうだ。
  • 依存先の増加 Dify自体が落ちると共倒れになる。クリティカルなシステムを増やすリスクを抱えるか。

2024年10月4日追記

ベクトルデータベースはweaviate以外にも選択できるようだ。

https://github.com/langgenius/dify/blob/main/docker/.env.example

# Supported values are `weaviate`, `qdrant`, `milvus`, `myscale`, `relyt`, `pgvector`, `pgvecto-rs`, `chroma`,`opensearch`,`tidb_vector`,`oracle`,`tencent`,`elasticsearch`,`analyticdb`

また、ストレージシステムも外部を利用できる。

# Supported values are `local` and `s3` and `azure-blob` and `google-storage` and `tencent-cos` and `huawei-obs`

スケーラビリティの点はどうにかなりそうだ。

まとめ ​

組織でのLLM活用を本格的に検討する上で、Difyを使わないのは大変なロスであると言わざるを得ない。

同時にはじめて、AI失業は自分の身にも起こり得るなと思った。本当に素晴らしいソフトウェアだ。