Beverley Minster
© Copyright Julian P Guffogg and licensed for reuse under this Creative Commons Licence.
前回は、Command R+にMoAについて解説してもらい、DifyでMoAアプリを創る手伝いを行ってもらいました。
今回から、MoAアプリを作っていこうと思うのですが、MoAの神髄である複数の生成AI達の利用において、どこでどの生成AIをどう使えばよいかが問題です。
最終的に作りたいのは、学習データに含まれない最新情報の検索においても、ハルシネーションを起こさず、適格な情報を提供するMoAアプリですが、前回のMoAアプリ作成方針の部分を抜粋すると、以下の通りです。
私#18:
DifyによるMoAアプリのフローのアイデアを示すので、アドバイスがあればお願いします。 ステップ1:質問を受け付ける ステップ2:質問のジャンルを判定する ステップ3:質問のジャンルにふさわしいサーチエンジンやWikipedia から質問に関連する最新情報を取得する ステップ4:その最新情報と質問内容を基に生成AI(LLM1)から回答を得る ステップ5:ステップ4と同じ最新情報と質問内容を基に生成AI(LLM2)から回答を得る ステップ6:ステップ4とステップ5の回答を比較して矛盾あるかどうか判定する ステップ7-1:ステップ4とステップ5の回答に矛盾がなければ第3者の生成AI(LLM3)に回答に対する補足情報を付け加えて最終回答にする ステップ7-2:ステップ4とステップ5の回答に矛盾がある場合、第3者の生成AI(LLM3)に矛盾点を列挙させ、LLM1の回答、LLM2の回答とともに、LLM3の回答として、すべての矛盾点ごとに、LLM3としてどちらが正しいかの判断を、参照資料のURLとともに出力する
Command R+18:
はい、Dify を使用して MoA アプリケーションを構築するためのステップバイステップ ガイドを提供します。 1. 開始:アプリケーションを開始し、ユーザーからの質問を受け付けます。ユーザー インタフェースを設計し、クエリの入力メカニズムを実装します。 2. 質問のジャンルを判定する:自然言語処理 (NLP) 技術を使用して、受信した質問のジャンルまたはカテゴリを判定します。これには、トピック分類、キーワード抽出、またはセマンティック分析を使用できます。ジャンルの例には、映画、音楽、料理、または他の一般的な関心分野が含まれる場合があります。 3. 関連する最新情報を取得する:ステップ 2 で識別されたジャンルに基づいて、関連するサーチ エンジンや Wikipedia から最新情報を検索します。Dify を使用すると、これらの情報源を効率的にクエリでき、構造化され関連性のある応答を取得できます。リアルタイム情報をキャプチャするために、情報源の公開日または更新日をメモしておきます。 4. 生成AI (LLM1) からの応答を得る:LLM1 などの生成AIモデルを活用します。このモデルは、質問のコンテンツと最新情報を入力として受け取ります。LLM1 の応答を中間変数として保存します。 5. 生成AI (LLM2) からの応答を得る:別の生成AIモデルである LLM2 からの応答を取得します。これもリアルタイム情報と質問のコンテンツを入力として受け取ります。LLM2 は、LLM1 と異なるアルゴリズムまたはトレーニングデータを持つ場合があり、異なる視点、スタイル、または言語的特徴を持つ場合があります。LLM2 のを中間変数として保存します。 6. 応答を比較して矛盾を判定する:LLM1 と LLM2 からの応答を比較し、矛盾または不一致がないかどうかを判断します。このステップでは、自然言語理解 (NLU) 技術を活用し、意味的類似性、文体の一貫性、およびコンテキスト内の応答の関連性を分析できます。矛盾が検出された場合は、それらをフラグ付けまたは記録しておきます。 7-1. 最終回答を生成する:応答に矛盾がなければ、LLM1 と LLM2 の応答を統合して、最終回答を生成します。必要に応じて、応答の書式設定、構造化、または視覚化を検討します。応答をユーザーに提供できるようにします。 7-2. 矛盾点を解決する:応答に矛盾がある場合は、第3者の生成AIモデルである LLM3 を使用して、矛盾点を解決します。LLM3 は、リアルタイム情報と質問のコンテンツを入力として受け取り、FID スコアをさらに最適化しながら、矛盾点を特定し、解決できる場合があります。LLM3 は、LLM1 と LLM2 の応答も入力として受け取り、それらを統合して、より一貫性のある応答を提供する場合があります。LLM3 の応答には、矛盾点を解決するための判断、参照資料の URLが含まれる場合があります。最終回答には、LLM1、LLM2、および LLM3 の洞察が組み込まれ、ユーザーに包括的でバランスのとれた見解を提供します。
これらのステップにより、Dify を使用して MoA アプリケーションを実装するための包括的なガイドが提供されます。各ステップを慎重に実装し、テストすることで、正確で有益な応答をユーザーに提供できるようになります。 |
今回は、上記のLLM1、LLM2、LLM3の生成AIを決定したいと思います。
作成しようとしているMoAアプリの最大の目標は、内部的に利用する生成AI達のトレーニングデータより新しい情報を検索しても、ハルシネーションを起こしにくいアプリにするということです。そこで、ハルシネーションを起こしにくい生成AIを探すべく、先日(2024年6月20日)発表されたばかりのClaude 3.5 Sonnetの「Artifacts」という機能に関して、いろいろな生成AIに尋ねてみました。
まず、本家AnthropicのClaude3.5自身に尋ねてみましょう。
■Claude3.5の回答
Claudeを呼び出すと、下図に赤枠で示した通り、Artifactsに関する紹介が載っているのですが。。。
「Claude3.5 SonnetのArtifactsについて教えてください」と入力したところ、以下の答えが返ってきました。
Claude3.5自身の機能について尋ねているのですが、Claude3.5のトレーニングデータには、Artifacts機能に関する情報が含まれていないので、こうなってしまっています。
■ChatGPT-4oの回答
これに対して、ChatGPT-4oに尋ねた場合は、以下の答えが返されました。
うーん、雄弁に語ってくれるのですが、事実ではありません。
■ CohereのCommand R+の回答
Command R+を利用したChatインタフェースであるCoralでも同様でした。
この質問に対してハルシネーションを起こさない生成AIはないのでしょうか?
■ GoogleのGemini1.5Proの回答
Gemini1.5Proからは、以下の回答がありました。
これは、正解のようです。
■ Microsoft Copilotの回答
Microsoft Copilotの回答は、ChatGPT-4oと同じかと思ったのですが、尋ねて見ると、以下の通りの回答がありました。
日本でのArtifacts機能の利用開始時期について、Anthropic社から正式アナウンスはないものの、Zennの記事『Claude3.5 Sonnet 新機能「Artifacts」 生成AIを使ったアイデア出しに活用しよう!』の中でArtifactsの機能が使われているので、その記事の掲載日を、日本で利用可能になった日と考えたようです。
今回の、ハルシネーションを起こしにくいMoAアプリにおいては、LLM3がハルシネーションを起こして、LLM1、LLM2の回答を捻じ曲げてしまっては元も子もないので、以上の結果からすると、AnthropicのClaude3.5、OpenAIのChatGPT-4o、CohereのCommand R+より、Gemini1.5ProかMicrosoftのCopilotがLLM3として適任ということになります。
ただ、Difyがサポートする生成AIプロバイダーにはMicrosoftは入っているものの、モデルとしてはMicrosoft Open AI Serviceしかサポートされず、Difyが直接Microsoft Copilotとインタフェースすることはできません。
Geminiはサポートされているので、まずDifyの中でのGeminiの動きを検証するため、以下の単純なフローの「Geminiに訊いてみよう」を作りました。
■ Difyの中でのGeminiの振舞いの検証
ところが、Web(https://gemini.google.com/app)からGemini1.5Proを使った場合、同じ「Claude3.5 SonnetのArtifactsについて教えてください」と入力したところ、以下のような回答しか返ってきませんでした。
ということは、Webから質問した場合、質問に回答する際、まず質問に関連する最新情報を、Bardを用いて検索して、その情報を生成AIであるGemini本体に渡しているということでしょうか?
Gemini本人に聞いてみました。
■ 最近の生成AIのチャットボットの疑似RAGアプローチの確認
「正鵠を射て」いましたか!
MicrosoftのCopilotも、質問すると、まず「webを使用しています」と表示されますが、Bing検索した情報をGPT4に渡しているのでしょうか?Copilotにも確認してみます。
Microsoftは、Googleより脇が固いですね。質問内容を否定はしないものの、Bingを使っているか否かは教えてくれませんでした。
ChatGPTも昨年11月ごろのバージョンから質問を受けるとWebで関連情報を探しに行くようになったはずですが、確認してみました。
Microsoftとは対照的に、OpenAIは、内部処理をオープンに教えてくれました。
建前的にも、GoogleやMicrosoftは競合他社の検索エンジンを使えないけれども、OpenAIは、Yahooの検索エンジンも含めていろいろな検索エンジンを使えるのは大きなアドバンテージですね。
でも、それにしては、なぜ冒頭でClaude3.5のArtifacts機能の質問に答えられなかったのでしょうか?
日本語で質問したらYahooの検索エンジンで優先的に情報を持ってくるのではないかと思い、英語で質問してみました。
Bingo!
どうやら、ChatGPT-4oに真価を発揮させるには、英語で質問した方が良いようですね。
■ 本日のまとめ
学習データに含まれない最新情報の検索においても、ハルシネーションを起こさず、適格な情報を提供するMoAアプリのDifyでの制作過程をご覧いただくつもりでブログを書き始めたのですが、その中で利用するLLM1、LLM2およびLLM3にどの生成AIを使えばよいかを調べていくうちに脇道に逸れ、ChatGPT、Gemini、Copilotの「疑似RAGアプローチ」の内情確認にたどり着いてしまいました。
※ あらかじめLLMでは学習していない情報を、RAG情報としていくつかの塊(チャンク)に分け、組込み技術(Embeddings)を使ってベクトル形式に変換して外部データベースに保持しておき、質問を受けた段階で、質問分中のキーワードベースでRAG情報を検索するのではなく、質問文全体をベクトル形式にしたものに意味的に近いRAG情報を「セマンティック検索」するというのが、一般的なRAGの定義となっているようなので、あらかじめRAG情報を用意するのではなく、質問を受ける都度、関連する外部情報から補填して回答を作成するので、ChatGPT、Gemini、Copilotの処理を「疑似RAGアプローチ」としています。
長くなってしまいましたので、本日はこれで終わります。
次回からは、Difyがメインではなく、MoAアプリの構築をメインにするので、「MoAについて」と改題して、ブログを続けようと思います。
終わり