トップ > 生成AI > Dify x Amazon Bedrock Knowledge Bases のRAG構成の作り方

Dify x Amazon Bedrock Knowledge Bases のRAG構成の作り方

生成AI Dify Amazon Bedrock Amazon Bedrock Knowledge Bases RAG
記事タイトルとURLをコピーする

はじめに

こんにちは、久保です。
生成AIを利用したソリューションを考えるにあたって、昨今ではRAG（Retrieval-Augmented Generation, 検索拡張生成）を検討しないことは少ないのではないかと思います。
本記事では、Difyを利用して"AWSのAmazon Bedrock Knowledge Bases"をRAGに利用する方法をハンズオン形式でご紹介します。

以下をご紹介します。

  • ローカル環境でのDifyの実行手順
  • Amazon S3 Vectorsを利用したAmazon Bedrock Knowledge Basesの作成手順
  • DifyでAWSのAmazon Bedrock Knowledge Basesを利用する2パターンの方法
    • 方法A) プラグイン "AWS Tools" による連携
    • 方法B) 自前のAPIサーバによる連携
  • Difyで認証情報等を安全に扱う方法（環境変数）

なお、Dify単体でも簡単にRAGを構築し利用できる機能を持っております。
こちらを利用する例は弊社ブログの以下記事をご参照ください。

blog.serverworks.co.jp

なお、本記事はAWS初心者の方やDifyを利用したことがない方でもお試しいただけます。
また、ローカルマシンでDifyを利用することと、Amazon Bedrock Knowledge BasesのベクトルストアをAmazon S3 Vectorsとすることでほとんどコストをかけずに試していただくことが可能です。（ほぼ利用したLLMの課金分のみ）

Difyとは

github.com

Dify is an open-source platform for developing LLM applications.

とあるとおり、LangGenius社が提供している、生成AIアプリケーションを作成するためのオープンソースプラットフォームであり、どなたでも利用することが可能なソフトウェアです。

GUIでアプリケーションの処理を定義することが可能で、非エンジニアの方であっても簡単に生成AIアプリケーションを構築することができます。

Difyの読み方

以前まで「ディファイ」という発音が主流であったと認識していますが、 2025年5月にリブランディングと合わせて読み方を正式に「ディフィ」としたそうです。

xtech.nikkei.com

本記事で構築する環境の構成

本記事ではmacOSのローカル環境でDockerを利用してDifyを構築し、LLMとRAGのためのナレッジベースはAWSを利用します。

本記事ではローカル環境でDifyを動作させ、RAGにAmazon Bedrock Knowledge Bases、LLMにBedrockを利用する構成とすることで使っていない間はAmazon Bedrock Knowledge Basesの料金以外0円となる構成とします。

また、Amazon Bedrock Knowledge Basesは先日プレビューでの提供が開始されたAmazon S3 Vectorsを利用することでベクトルDBのコストも最小限に抑えます。

参考に、AWSでのDify環境の構築は、AWSが提供しているワークショップの手順で構築するのが簡単です。 2.1. AWS マネジメントコンソールへログインし、Dify を AWS にデプロイする→(a) ご自身の AWS アカウントで実施する場合
catalog.us-east-1.prod.workshops.aws 本記事でご紹介する手順はほぼそのままEC2上のDifyにも適用可能です。（IAMユーザーが不要になる程度）

なお、本番環境でDifyを利用する場合はより本番想定された構成のsampleもございますので、そちらのご利用もご検討ください。
github.com

Difyのセットアップ

環境の前提事項

  • dockerコマンドが利用可能である必要があります。（Docker DesktopやRancher Desktop, Colimaなど）
  • gitが利用可能である必要があります。

macOSで行なっていますが、docker, gitが利用可能であればWindowsでも利用可能です。

Difyの起動

Difyのgithubリポジトリをcloneし、docker composeで起動するだけで大丈夫です。 適当なディレクトリ配下にcloneします。

mkdir ~/dev-dify
cd ~/dev-dify
git clone https://github.com/langgenius/dify.git
cd dify

dockerディレクトリに移動し、コンテナ群を起動します。

cd docker
cp .env.example .env
docker compose up -d

2025年9月1日現在では、以下の11個のコンテナが起動され、Webアプリケーションがlocalhost:80 でリスンされます。

docker-redis-1
docker-ssrf_proxy-1
docker-db-1
docker-weaviate-1
docker-web-1
docker-sandbox-1
docker-plugin_daemon-1
docker-worker-1
docker-api-1
docker-worker_beat-1
docker-nginx-1

初期設定(管理者登録)

コンテナが起動した後、ブラウザで以下にアクセスします。

http://localhost/install

管理者アカウントの設定画面になります。 項目をすべて入力し、「セットアップ」をクリックします。

これでトップ画面に自動遷移します。

一旦ここまででDifyの起動、初期設定は終わりです。

AWS側の設定

本記事の例では、米国(オレゴン)リージョン（us-west-2）を利用します。
Amazon S3 Vectorsの利用が可能で、かつ生成AI関連の機能追加が早く行われる傾向があるためです。

Bedrockモデルの有効化

AWSマネジメントコンソールにログインし、米国(オレゴン)リージョン（us-west-2）を選択します。 Bedrockの画面を表示し、「モデルアクセス」から利用する生成AIモデルを有効化します。

下記の環境では有効化済みとなっていますが、本記事の範囲では以下のモデルが有効になっていれば十分です。Anthropic社のCraude系も必要に応じて有効化ください。

  • Amazon
    • Nova Pro
    • Nova Premier
    • Rerank 1.0
    • Titan Text Embeddings V2

ナレッジベースの作成

Amazon S3 Vectorsを利用してナレッジベースを作成します。

データソース用バケットの作成

まずデータソースとするS3バケットを米国(オレゴン)で作成します。

バケット名に任意の名前を指定します。

最下部までスクロールし、「バケットを作成」をクリックします。

作成されたS3バケット名をクリックします。

こちらの画面からRAGのソースとしたいファイルをアップロードしておきます。

今回は弊社FY25 2月期の決算説明資料(PDF)をアップしておきます。

https://ssl4.eir-parts.net/doc/4434/tdnet/2593176/00.pdf

ナレッジベースの作成

Bedrockの画面にて、「ナレッジベース」→「作成」→「ベクトルストアを含むナレッジベース」をクリックします。

ナレッジベース名、サービスロール名はデフォルトで値が入っています。 必要に応じて変更します。（そのままでOKです）

データソースはS3とし、「次へ」をクリックします。

「S3のURI」の箇所で、「参照」をクリックするとS3バケットが選択できます。 先ほど作成したS3バケットを選択して反映し、「次へ」をクリックします。

ベクトルデータベースを選択する箇所で、「Amazon S3 Vectors」を選択します。

「モデルを選択」をクリックします。

「Titan Text Embeddings V2」を選択し、「適用」をクリックします。

「次へ」をクリックします。

確認画面が表示されるので内容を確認し、「ナレッジベースを作成」をクリックします。

数十秒程度で作成され、以下の画面に遷移します。 インデックスを作成する必要があるため、作成したデータソースを選択し、「同期」をクリックします。

これでデータソース用のS3バケットのファイルを元に検索用インデックスが作成されます。

IAMユーザの作成

DifyからBedrockにアクセスできるように、IAMユーザを作成します。 なお、AWS上にDifyを構築すればIAMユーザではなくより安全なIAMロールを利用して認証認可を行うことが可能ですが、今回はローカル環境でのお試しのためIAMユーザを作成しています。

IAMのユーザー画面を表示し、「ユーザーの作成」をクリックします。

任意のユーザー名を指定し、「次へ」をクリックします。 ※マネジメントコンソールアクセスは不要

「ポリシーを直接アタッチする」を選択し、"BedrockLimited"で検索して「AmazonBedrockLimitedAccess」をチェックします。 「次へ」をクリックします。 ※"AmazonBedrockLimitedAccess"はBedrockの限定的な利用権限を付与するものです。"AmazonBedrockFullAccess"もありますが権限が大きすぎるため避けます。

内容を確認し、「ユーザーの作成」をクリックします。

まだ権限の追加が必要です。

作成したナレッジベースのナレッジベースIDを確認しておきます。（あとで何度も利用しますので記録しておきます）

作成したユーザーの詳細画面を開き、「許可を追加」→「インラインポリシーを作成」をクリックします。

ポリシーエディタで「JSON」を選択し、以下jsonを貼り付けます。 最小権限となるよう、Resourceで先ほど確認したナレッジベースID(私の例では"ZUHGAWORFA")を元にしたナレッジベースの指定を行います。 "123456789012"の箇所はご自身のAWSアカウントのアカウントIDに置き換えてください。

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Sid": "AllowKBCombinedCallOnKnowledgeBaseInstance",
            "Effect": "Allow",
            "Action": [
                "bedrock:Retrieve",
                "bedrock:RetrieveAndGenerate"
            ],
            "Resource": [
                "arn:aws:bedrock:us-west-2:123456789012:knowledge-base/ZUHGAWORFA"
            ]
        }
    ]
}

ポリシー名に任意の名前を指定し、「ポリシーの作成」をクリックします。

※なお、BedrockのLLMを利用するIAMユーザーと、ナレッジベースを利用するIAMユーザーは分けることも可能です。

最後にアクセスキーを発行します。

「セキュリティ認証情報」タブから「アクセスキーを作成」をクリックします。

画像のように選択します。 なお、推奨された代替案に記載されているとおり、IAM Identity Centerによる認証等より安全な認証を行うことが推奨されますが、今回は限定権限でのテスト用とし、これで作成します。

必要に応じて説明用の内容を指定し、「アクセスキーを作成」をクリックします。

発行されたアクセスキー、シークレットアクセスキーを保存しておきます。 （取り扱いにご注意ください）

Dify側の設定

ここまででAWS側の準備は整いましたので、Dify側の設定を行います。

Difyのヘッダ右上のマークをクリックし「設定」をクリックします。

左ペインから「モデルプロバイダー」を選択し、「Amazon Bedrock」をインストールします。

インストール後、「セットアップ」をクリックします。

Bedrockの認証設定画面になります。 認証名には任意の名称（IAMユーザー名など）を指定し、 Access KeyとSecret Access KeyにAWS側で作成したアクセスキー、シークレットキーを入力します。 AWS RegionはOregonを選択し、「保存」をクリックします。

※なおこの設定でのアクセスキーの指定も、EC2などAWS環境上に構築すればIAMロールが利用可能なため不要です。

「システムモデル設定」も行なっておきます。（任意）

以下のようにシステムで利用するモデルを選択し、「保存」しておきます。 完了したら右上の「×」ボタンをクリックし設定画面を閉じます。

これでDify側でBedrockを利用する設定が完了しました。

RAG(Knowledge Bases)を利用する

DifyからAmazon Bedrock Knowledge Basesを利用する方法は主に2つあります。

  • 方法A) プラグイン "AWS Tools" による連携
  • 方法B) 自前のAPIサーバによる連携

方法A) プラグイン "AWS Tools" による連携

1つ目のaws-toolsとは aws-samples で提供されているDify向けの各種AWS連携ツールです。

github.com

こちらの方法が最も簡単にナレッジベースを利用することが可能で、Difyの画面からプラグインをインストールすることができます。

プラグインのインストール

Difyの画面右上の「プラグイン」をクリックします。

「マーケットプレイスを探索する」をクリックし、"aws"で検索して「AWS Tools」の「インストール」をクリックします。

対象を確認し、「インストール」します。

インストールが完了したら「閉じる」をクリックします。

これで利用する準備完了です。

チャットフローの作成

ヘッダの「スタジオ」→「最初から作成」をクリックします。

任意のアプリの名前を指定し、「作成する」をクリックします。

これで、チャットフローの作成画面となります。

環境変数に認証情報を設定

ナレッジベースを追加する前に、アクセスキーとシークレットキーを安全に指定できるよう、Difyの環境変数を設定しておきます。 ここでの環境変数とは、対象のチャットフロー内でのみ有効な変数です。

画面右上の「ENV」をクリックし「環境変数を追加」をクリックします。

タイプで「Secret」を選択し、変数名に"AWS_ACCESS_KEY"、値にAWS側で作成したIAMユーザーのアクセスキーを指定して「保存」します。

同じ要領で"AWS_SECRET_ACCESS_KEY"も登録します。 Secretで登録した値は自動的にマスクされ、管理者でも全文字の参照はできなくなります。

Difyでは作成したチャットフローやワークフローをDSL(YAML形式)でエクスポートすることが可能です。
上記のように環境変数にしておくことで、認証情報などの機密情報が平文でエクスポートされてしまう事態も回避できます。

RAGの追加

プラグインの利用は少しUI上わかりにくいです。 「開始」ノードの「+」をクリックし、「ツール」タブをクリックします。（ここにタブがあるというのがわかりにくい..）

すると利用可能なツールリストが表示されますので、「AWS Tools」をクリックします。

今回はAmazon Knowledge Basesの検索を利用するので「Bedrock Retrieve」をクリックします。

「Bedrock Retrieve」の設定画面になりますので、項目に入力していきます。

スラッシュ"/"を入力すると、利用可能な変数の候補を表示してくれます。 sys.queryを選択します。sys.queryはユーザが入力した質問です。

"AWS Access Key ID", "AWS Secret Access Key"の箇所も同様にスラッシュを入力し、先ほど設定した環境変数を指定します。

リージョンは"us-west-2"とし、result typeは"Text"のまま、「Bedrock Knowledge Base ID」には確認したナレッジベースのIDを指定します。

その他の項目はデフォルトのままとします。

設定右上の「×」をクリックすると閉じます（自動保存です）。

なお、result typeには"Text"と"JSON"があります。今回はシンプルにするためにTextとしますが、"JSON"にすることでより得られる情報が多く便利になりますので別の機会にご紹介できればと思います。

RAG結果をLLMノードに渡したいので、既存の接続部をクリックして選択し、キーボードのDelキーで削除します。

「BEDROCK RETRIEVE」のノードの「＋」をドラッグしてLLMノードに接続します。

ノードはドラッグで位置変更できます。 少し見やすくしておきました。 次に「LLM」のノードをクリックします。

AIモデルをクリックし、「Amazon Nova」をクリックします。

これでNova Proを利用する設定となりました。他の設定はそのままにしておきます。

次に、RAGの結果をLLMに渡して最終的な回答を生成するようプロンプトを設定します。 まずシステムプロンプトを指定します。 今回はこうします。

ユーザからの質問は<user-input></user-input>に、
質問を元に内部データを検索した結果が<rag-result></rag-result>に記載されています。
検索した結果を元にユーザからの質問に回答してください。

次にUSERのノードにプロンプトを指定します。 こうします。

<user-input>ここにsys.query</user-input>
<rag-result>ここにRAG結果のtext</rag-result>

ここでも同じようにスラッシュを入力すると利用可能な変数が表示されます。 それぞれ sys.query と、BEDROCK RETRIEVEの"text"を選択します。

これでLLMノードの設定も完了です。右上の「×」でLLMの画面を閉じます。

動作確認

右上の「プレビュー」から簡単に動作確認ができます。

サーバーワークスの決算説明資料をソースにしていますので、 「サーバーワークスの業績ハイライトは？」と聞いてみます。

資料を元に正しく答えられていそうです。 さらに「ワークフロー処理」をクリックすると、各ノードの詳細な結果が確認できます。

RAGの結果を覗いてみましょう。

RAGの入力（検索文字列）と出力（結果）が確認できます。 もし権限エラーなどがあった場合もここからデバッグ可能です。

以上がプラグインを利用したナレッジベースの利用の流れとなります。

Bedrock Retrieveのノードの設定画面を見ていただくとわかるのですが、 検索タイプでハイブリッド検索が指定できたり、リランクモデルが利用できたり、メタデータフィルタという、データソース側の属性に応じたフィルタなどにも対応しています。 ※S3 Vectorsの場合はハイブリッド検索は利用できません。

方法B) 自前のAPIサーバによる連携

こちらはコーディングが必要となりますが、Difyのドキュメントでも例が掲載されている方法です。

docs.dify.ai

このドキュメント通りのコードでは現在動作しないため、以下に調整版を記載しています。

こちらはDifyの「外部ナレッジベース」という機能を利用してDifyからAmazon Bedrock Knowledge Baseの検索を行う方法です。

以下のように、RAGを利用する際に自前のAPIサーバを経由することになります。

APIサーバ用コンテナの作成
cd ~/dev-dify/dify/docker
mkdir bedrock-api-proxy
cd bedrock-api-proxy

以下のファイルをbedrock-api-proxyディレクトリ配下に作成します。

app.py

from flask import Flask
from flask_restful import Api
from knowledge import BedrockRetrievalApi

app = Flask(__name__)
api = Api(app)

# Add the retrieval endpoint
api.add_resource(BedrockRetrievalApi, '/retrieval')

if __name__ == '__main__':
    # Run the Flask app
    app.run(host='0.0.0.0', port=5001, debug=True)

knowledge.py

from flask import request
from flask_restful import Resource, reqparse

from knowledge_service import ExternalDatasetService


class BedrockRetrievalApi(Resource):
    # url : <your-endpoint>/retrieval
    def post(self):
        parser = reqparse.RequestParser()
        parser.add_argument("retrieval_setting", nullable=False, required=True, type=dict, location="json")
        parser.add_argument("query", nullable=False, required=True, type=str,)
        parser.add_argument("knowledge_id", nullable=False, required=True, type=str)
        args = parser.parse_args()

        # Authorization check
        auth_header = request.headers.get("Authorization")
        if " " not in auth_header:
            return {
                "error_code": 1001,
                "error_msg": "Invalid Authorization header format. Expected 'Bearer <api-key>' format."
            }, 403
        auth_scheme, auth_token = auth_header.split(None, 1)
        auth_scheme = auth_scheme.lower()
        if auth_scheme != "bearer":
            return {
                "error_code": 1001,
                "error_msg": "Invalid Authorization header format. Expected 'Bearer <api-key>' format."
            }, 403
        if auth_token:
            # process your authorization logic here
            pass

        # Call the knowledge retrieval service
        result = ExternalDatasetService.knowledge_retrieval(
            args["retrieval_setting"], args["query"], args["knowledge_id"]
        )
        return result, 200

認証部分がpassとなっているとおり、本例ではAPIキーでの認証は行なっていません。
必要に応じてAPIキーによる認証を実装してください。

knowledge_service.py

import os
import boto3


class ExternalDatasetService:
    @staticmethod
    def knowledge_retrieval(retrieval_setting: dict, query: str, knowledge_id: str):
        # get bedrock client
        client = boto3.client(
            "bedrock-agent-runtime",
            aws_secret_access_key=os.getenv("AWS_SECRET_ACCESS_KEY"),
            aws_access_key_id=os.getenv("AWS_ACCESS_KEY_ID"),
            region_name=os.getenv("AWS_DEFAULT_REGION"),
        )
        # fetch external knowledge retrieval
        response = client.retrieve(
            knowledgeBaseId=knowledge_id,
            retrievalConfiguration={
                "vectorSearchConfiguration": {"numberOfResults": retrieval_setting.get("top_k"), "overrideSearchType": "SEMANTIC"}
            },
            retrievalQuery={"text": query},
        )
        # parse response
        results = []
        if response.get("ResponseMetadata") and response.get("ResponseMetadata").get("HTTPStatusCode") == 200:
            if response.get("retrievalResults"):
                retrieval_results = response.get("retrievalResults")
                for retrieval_result in retrieval_results:
                    # filter out results with score less than threshold
                    if retrieval_result.get("score") < retrieval_setting.get("score_threshold", .0):
                        continue
                    result = {
                        "metadata": retrieval_result.get("metadata"),
                        "score": retrieval_result.get("score"),
                        "title": retrieval_result.get("metadata").get("x-amz-bedrock-kb-source-uri"),
                        "content": retrieval_result.get("content").get("text"),
                    }
                    results.append(result)
        return {
            "records": results
        }

Dockerfile

FROM python:3.12-slim

WORKDIR /app

COPY requirements.txt .
RUN pip install --no-cache-dir -r requirements.txt

COPY app.py knowledge.py knowledge_service.py ./

EXPOSE 5001

CMD ["python", "app.py"]

docker-compose.yml

version: '3.8'

services:
  bedrock-api-proxy:
    image: bedrock-api-proxy:latest
    container_name: bedrock-api-proxy
    ports:
      - "10080:5001"
    env_file:
      - .env
    environment:
      - AWS_ACCESS_KEY_ID=${AWS_ACCESS_KEY_ID}
      - AWS_SECRET_ACCESS_KEY=${AWS_SECRET_ACCESS_KEY}
      - AWS_DEFAULT_REGION=${AWS_DEFAULT_REGION}
    restart: unless-stopped
    healthcheck:
      test: ["CMD", "curl", "-f", "http://localhost:5001/health"]
      interval: 30s
      timeout: 10s
      retries: 3
      start_period: 40s

作成したら、コンテナをビルドします。

docker build -t bedrock-api-proxy .

以下の内容で.envファイルを作成します。 your_aws_access_key_id_here、your_aws_secret_access_key_hereの箇所にはAWS側で作成したIAMユーザーの値を設定してください。

AWS_ACCESS_KEY_ID=your_aws_access_key_id_here
AWS_SECRET_ACCESS_KEY=your_aws_secret_access_key_here
AWS_DEFAULT_REGION=us-west-2

コンテナを起動します。

docker compose up -d

これで、http://localhost:10080でナレッジベースにアクセスするためのAPIサーバが起動します。

すでに起動しているDifyのコンテナからは localhost では見えません。そのためローカルMacのIPアドレスを確認し、そのIPアドレスでDifyから参照させる必要があります。

MacのプライベートIPアドレスを確認しておきます。 macOSではほとんどの場合以下で取得可能なはずです。 ここでは確認の結果、"192.168.1.34"だったと仮定します。

% ipconfig getifaddr en0
192.168.1.34
Difyの設定

ヘッダの「ナレッジ」をクリックし「外部ナレッジベース連携API」→「外部ナレッジベース連携APIを追加」をクリックします。

  • Name: 任意の名前（ここではBedrock Knowledge Bases API Proxy）
  • API Endpoint: http://確認したローカルマシンのIP:10080
  • API Key: 今回の実装は認証なしです。任意の値、例えばdummyを入力します

「保存」をクリックします。

次に「外部ナレッジベースと連携」をクリックします。

「外部ナレッジベース名」は任意の名前を指定します。 「外部ナレッジベース連携API」はさきほど設定したAPIを指定します。（デフォルトそうなっています） 外部ナレッジベースIDにAWSで確認したナレッジベースのIDを指定します。 トップKやスコア閾値も自由に設定し、「連携」をクリックします。

※プラグインによる連携では「スコア閾値」は指定できませんでした。AWSのRetrieve APIはそもそもスコア閾値を指定することはできないためです。こちらの方法は、Difyの外部ナレッジベース連携APIがスコア閾値を引数として受け取る仕様となっているため、API側で実装すればスコア閾値を使うことが可能です。本記事の実装では対応しています。

これで独自のAPIサーバ経由でナレッジベースを利用する準備が整いました。

チャットフローの作成

チャットフローを作成開始する手順は「プラグイン aws-tools による連携」の場合の同様のため割愛します。

開始ノードの「＋」から「知識検索」をクリックします。

ナレッジベースの「＋」をクリックします。

作成した外部ナレッジベースが表示されるので（まだ一つしかない）選択し、「追加」します。

なお、追加時に自動で「検索設定」が開きます。Rerankモデルの指定や、トップK、スコア閾値などを指定可能です。今回はそのままにします。

これで設定完了です。

残りのLLMノードと回答ノードの設定はプラグイン版とほぼ同じです。 一部、LLMの<rag-result>に記載する変数は 知識検索の"result" を指定します。

全体は以下のようになります。

動作確認

それではプレビューで動作確認します。 質問は同じく「サーバーワークスの業績ハイライトは？」です。

大丈夫そうです。 ワークフロー処理も見ておきます。

ちゃんと検索できていそうです。 なお出力の一部を以下に示します。

{
  "result": [
    {
      "metadata": {
        "_source": "knowledge",
        "dataset_id": "7806801d-3517-4fb8-a073-d6d089b07fac",
        "dataset_name": "Amazon Bedrock Knowledge Bases",
        "document_id": "s3://rag-datasource-001/00.pdf",
        "document_name": "s3://rag-datasource-001/00.pdf",
        "data_source_type": "external",
        "retriever_from": "workflow",
        "score": 0.5418152667218196,
        "doc_metadata": {
          "x-amz-bedrock-kb-source-uri": "s3://rag-datasource-001/00.pdf",
          "x-amz-bedrock-kb-document-page-number": 41,
          "x-amz-bedrock-kb-chunk-id": "7fade9ef-cebe-404c-90a8-6d1d1b5147f4",
          "x-amz-bedrock-kb-data-source-id": "U7LHIJT9JO",
          "score": 0.5418152667218196,
          "title": "s3://rag-datasource-001/00.pdf",
          "dataset_id": "7806801d-3517-4fb8-a073-d6d089b07fac",
          "dataset_name": "Amazon Bedrock Knowledge Bases"
        },
        "position": 1
      },
      "title": "s3://rag-datasource-001/00.pdf",
      "content": "25,000     30,000     35,000     40,000 35,717     1,536 3,066 4,477     6,811 8,029     (単位：百万円)     クラウド市場の拡⼤による需要の増加及びM&AやJV設立などのグループ組織拡⼤と成長に伴い 順調に売上を伸ばし高い成長率を維持     10,920     2016年２月期 2017年２月期 2018年２月期 2019年２月期 2020年２月期 2021年２月期 2022年２月期 2024年２月期     成長率     130%     17,295     2,294     サーバーワークスグループ     実績     2023年２月期 2025年２月期     27,510     過去10年間の売り上げ推移会社概要42     設立 2000年２月21日"
    },

参考：検索設定でスコア閾値を指定していると、この"score"の値（0〜1で、1に近いほど近似している）が閾値より高いもののみがヒットするようになります。

こちらの独自APIサーバの方法は、独自に実装する手間がかかりますが、逆に自由に処理を作り込むことができるため、何らかのフィルタ処理を入れるなど、独自の処理を行いたい場合には選択肢になり得ると思います。

方法Aと方法Bの比較

それぞれの連携方法の比較です。

観点 方法A：AWS Toolsプラグイン連携 方法B：自前APIサーバ連携
概要 Difyのプラグイン「AWS Tools」からBedrock Retrieveを呼び出し、Knowledge Base IDなどを指定して使う 自身で用意したAPIサーバにDifyからリクエスト→APIサーバがBedrock Retrieve APIを利用
導入の手軽さ DifyのUIでプラグインを入れて設定するだけ 実装・デプロイが必要
認証情報の扱い(IAMユーザの場合 *1 ) Difyの ENV（Secret） にアクセスキー等を保存して参照 APIサーバ側で管理（DifyにはIAM認証情報を直接持たせない設計も可能）
カスタマイズ性 低〜中：プラグインの設定範囲に依存 高：前処理・フィルタ・再ランキングなど独自ロジックを挿入可能
保守 低コスト：プラグインの更新に追随すればOK 自前コードの運用・更新コストが発生
失敗時の制御 プラグイン側の挙動に準拠 任意のリトライ/フォールバックを設計可能
向いている場面 まず動かしたいPoC、手早い検証・デモ 要件に合わせた作り込み、社内ルールに応じた前処理/監査が必要なときなど

おわりに

かなり長くなってしまいました。 ここまでお付き合いいただいてありがとうございます。 なお今回紹介したのは単純にDifyでAmazon Bedrock Knowledge Basesを利用できるようにするだけの簡単なものでした。 Difyでは多様な処理ノードを活用することで、生成AIによる回答精度改善の工夫が色々と考えられます。

機会がありましたらRAG精度の向上として例えばAdvanced RAG的な処理やRerankの試行なども試してご紹介したいと思います。

最後に、今回作成したIAMユーザーのアクセスキーは、試用が終わりましたら忘れず無効化し、削除されますようご注意ください。

*1:AWS環境であればIAMロールが利用可能なのであくまでIAMユーザの場合の観点です

久保 賢二(執筆記事の一覧)

猫とAWSが好きです。