AI技術の進化に伴い、社内情報検索や業務効率化を支援する対話型AIアプリへの期待が高まっています。その性能を最大限に引き出す鍵となるのが RAG（Retrieval Augmented Generation） の精度です。

今回は、Difyをフロントエンドとし、精度の高さが期待できるGraphRAGを組み合わせた社内対話型AIアプリ開発および精度の調査についてご紹介します。

プロジェクトの背景

これまで私たちはAzure側でRAGを参照したAI出力を行っていましたが、以下の観点からDify内で完結する高精度なRAG参照技術を実現できるプロジェクトをスタートしました。

1. Azureへの接続なしにDify内で完結させたいという要望
2. Difyが提供するRAGの精度に対する不安

特に後者については、Difyで構築したRAGの精度が悪いとする指摘する記事が存在していました。

こちらのRAGの精度は、正直に言うと結構悪い印象です。これはモデルではなくDify側に原因があります。 Difyでは、ナレッジから文章を取得する部分で埋め込みモデルを使用しない場合、 キーワード検索を行っているのですが、的確にキーワードを入力してあげないと取得してくれません。 埋め込みモデルを使用すると若干は良くなりますが、ヒットしないことがザラにあります。 （出典：https://www.skygroup.jp/tech-blog/article/1283/）

私たちも、Azure Search ServiceおよびDifyで構築したRAGの精度を比較したのですが、Difyで構築したRAGは重要な部分が欠落することがあり、AzureのRAGの方がかなり細かく教えてくれる印象でした。 以下は、両者に「自社の自転車通勤に関する規定について教えて」と尋ねた際の結果です。

Azure Search Serviceを用いたRAG

Difyで構築したRAG

解決策の模索：DifyとGraphRAGの組み合わせ

Dify単体でのRAG精度に懸念があったため、GraphRAGの技術を組み合わせることで精度を向上させられるかを検証することにしました。 GraphRAGの導入は以下の記事を参考に進めました。

参考記事：https://zenn.dev/fukurou_labo/articles/137b854648dad2

その上で、以下のような注意点がいくつかありました。

• 知識ベースの準備: GraphRAGが知識として扱えるのは、txt, csv, jsonファイルに限定されており、PDFファイルを直接扱えない点が不便でした。

• poetryのインストール：公式サイトのマニュアルインストールに従ってインストールしました。

python3 -m venv venv
venvbin/pip install -U pip setuptools
venv/bin/pip install poetry

• インデックス作成: poetry run poe index --root ./knowledge/01_ipa コマンドでインデックスを作成しましたが、これには時間がかかりました 。また、既存のバグ（[Bug]: AttributeError: ‘list’ object has no attribute ‘on_error’ #1505）によりエラーが発生しましたが、リソースを変更することで解決しました。

• Difyとの連携: HTTPリクエストのボディは、記事の指示とは異なりraw ではなくjson を指定する必要があることが判明しました 。 knowledgeに情報セキュリティに関連するテキストファイルを与え、以下のようにプロンプトを指定することで、エージェントも正常に動作し、ドキュメントに関係のない情報に対しては「それに基づいていない」と回答できることを確認しました。

あなたは、情報セキュリティに関する質問に回答するアシスタントです。
あなたの仕事は、情報セキュリティの専門家としてツールのGraphRAGの内容に基づいて質問に答えることです。
ユーザの質問に対して、ツールのGraphRAGを参照し、情報セキュリティの知識に基づいて回答します。
ツールのGraphRAGに該当する内容がない場合は、その旨を明記した上で、一般的な回答をしてください。
パラメータは{“active_docs”: “knowledge/01_Lobor”}です。

精度の調査

まず、知識ベースに一部のファイルのみを与えたDifyとGraphRAGの組み合わせで「弊社の自転車通勤についての規定を教えて」と尋ねたところ、ナレッジとして与えたデータを参照した回答を生成できることを確認できました 。

次に、知識ベースに全ての資料を与えた状態で動作を確認しました。GraphRAGは「許可について」「禁止事項・罰則」「通勤手当」など、必要なデータを参照している印象でした 。

Azure Search Serviceを用いたRAG

graphRAG

しかし、AzureのRAGを用いた場合と比べて、自転車通勤許可条件である「駐輪場の確保ができていること」が回答から脱漏していた点が気になりました。

HTTPリクエストの時点で返ってきていないこと、そして「駐輪場について教えて」と尋ねると返ってくることから、検索で上位に入っていないために弾かれている可能性が示唆されました。これはGraphRAGのプロンプトを調整することで解決できるかもしれません。

次に、育児休業に関する規定について尋ねたところ、GraphRAGとAzureのRAGはどちらも制度の概要、申請手続き、期間などについて必要最低限の情報は拾えていました。このケースでは、GraphRAGの方が精度が高いように感じられ、より詳細な規定内容を提示しました。

結論

今回の調査を通じて、DifyとGraphRAGを組み合わせることで、Dify単体でのRAG精度に関する懸念を払拭し、特に育児休業のような詳細な規定においてはAzureのRAGよりも高い精度を示すケースがあることを確認できました。

しかしながら、最終的な結論として、以下の点を考慮するとAzureのRAGで十分ではないかという見解に至りました 。

• URLの参照やPDFの直接的な取り扱い：GraphRAGはPDFを直接扱えず、txt変換が必要である
• 膨大なナレッジデータの顧客ごとの分離：大規模な知識ベースを効率的に管理し、顧客ごとに分離する必要性を考えると、AzureのRAGの方が便利

GraphRAGの精度は注目に値しますが、これらの点を考慮すると、AzureのRAGを用いても良いのかな、といった印象でした。

今回のプロジェクトは、Dify内で完結させるという当初の目標や、Dify RAGの精度に対する不安から始まりましたが、GraphRAGとの組み合わせ検証を経て、それぞれのRAGソリューションの特性と課題を深く理解する貴重な機会となりました。

今後も、より高精度で使いやすい社内対話型AIアプリの開発に向けて、最適なRAGソリューションの検討を続けていこうと思います。

​

​