2024-07-26

AzureでElasticsearch(Elastic Cloud)を使う時のポイント 2024年版（運用編１）

こんにちは、Elastic認定資格３種(※)を保持しているノムラです。
※Elastic社の公式認定資格（Elastic Certified Engineer / Elastic Certified Analyst / Elastic Certified Observability Engineer）

こちらはAzure編の記事になります。

AzureでElasticsearch(Elastic Cloud)を使う時のポイントの記事一覧は以下です。
①構築編
acro-engineer.hatenablog.com
②運用編2
＜運用編２近日公開予定!!＞

本記事では運用編1として、Elastic Cloudを運用するにあたり必要な各種設定を実施する手順を紹介します。

はじめに
 1. Monitoring設定（Metric／Logs）
2. Snapshot設定
 3. 監視設定
 まとめ

はじめに

本記事では、Elastic Cloud(Elasticsearch Service)の名称を統一して「Elastic Cloud」と記載します。
「AWS編」と「Azure編」の2つのシリーズを公開しています。Elastic Cloud固有の設定については、AWS／Azureで共通の内容になりますが、構築編の記事から通してご覧いただくことを考慮し、意図的に別の記事としております。ご注意ください。

1. Monitoring設定（Metric／Logs）

Monitoring機能について

Monitoring機能を利用することでクラスタの状態が一目で分かり、かつ何らか問題が発生した際もリソースとログの両面から素早く問題調査することが可能です。

Elastic CloudでMonitoring機能を有効化する

Monitoring機能はデフォルトでは有効化されていません。
そのため以下の手順で有効化していきます。

(1) Elastic CloudのDeploymentの画面にアクセスしメニューの「Logs and metrics」を押下

(2) 「Ship to a deployment」の「Enable」を押下

(3) 構築したDeploymentを選択し「Save」を押下

Monitoring機能が有効化されます。

Metricを確認する

MetricではElastic Stackがそれぞれどれ位サーバリソースを利用しているかを確認可能です。

(1) Kibana画面の左側のメニューから「Stack Monitoring」を押下

(2) Elasticsearchの「Overview」を押下

OverviewではElasticsearch全体の検索性能／インデキシング性能をリアルタイムに確認可能です。

(3) Elasticsearchの「Nodes」からインスタンスを１つ選び押下

各サーバ毎のリソースの状況がリアルタイムに確認可能です。

Logsを確認する

Logsではリアルタイムにログを確認／絞り込みを行いながら調査することが可能です。

(1) Kibana画面の左側のメニューから「Logs」を押下

Stream画面ではElasticsearchに取り込んでいる各種ログがリアルタイムに表示されます。

(2) 画面上部の検索窓に「error」と入力し、ログの絞り込みを実行

ログを絞り込みながら問題調査を実施することが可能です。

Metricの保持期間を変更する

Metricの保持期間はデフォルトでは３日に設定されています。要件毎に保持期間は異なると思いますので、設定を変更してみましょう。

(1) Kibana画面の左側のメニューから「Stack Management」を押下

(2) 「Index Lifecycle Policies」を押下

(3) 検索窓に「.monitoring」と入力し表示される「.monitoring-8-ilm-policy」を押下

Elasticsearchはインデックスをフェーズと呼ばれている状態で管理しており、フェーズの遷移条件をILM(Index Lifecycle Management)で定義しています。詳細については以下をご参照ください。
ILM: Manage the index lifecycle | Elasticsearch Guide [8.14] | Elastic

変更前の設定は以下の通りとなっています。

フェーズ	設定値
Hotフェーズ	インデックス作成から3日経過 or プライマリーシャードのサイズが50GB以上になった際インデックスをRolloverする
Warmフェーズ	セグメント数が1になるようにForcemergeを実行する
Deleteフェーズ	Rollover後、3日経過したインデックスを削除する

Hotフェーズで定義されているRolloverというのは簡単に言うと特定条件を満たした際に新しいインデックスを作成する機能です。詳細については以下をご参照ください。
Rollover | Elasticsearch Guide [8.14] | Elastic

(4) Deleteフェーズの値を「3 days」から「31 days」に変更し「Save Policy」を押下

上記の手順で、Rollover後31日経過したインデックスを削除するように設定を変更できました。

2. Snapshot設定

Snapshot設定について

Elastic Cloudではデフォルト設定で30分に1回スナップショットを取得します。こちらも設定確認／設定変更していきましょう。

(1) Kibana画面の左側のメニューから「Stack Management」を押下

(2) 「Snapshot nad Restore」を押下

(3) 「Policies」タブを押下し、「cloud-snapshot-policy」右側の「Edit」ボタンを押下

(4) 「Schedule」の設定値を変更

時刻の設定はCron表現で設定可能です。また、UTCであることにご注意ください。詳細については以下のドキュメントを参照ください。
API conventions | Elasticsearch Guide [8.14] | Elastic

(5) 必要に応じて「Expiration」「Snapshots to retain」の設定値を変更

(6) 「Save policy」を押下

(7) 「cloud-snapshot-policy」を押下し「Summary」を表示

変更した結果、毎日0時（JST）にスナップショットが取得されるようになりました。

3. 監視設定

Elastic Cloudの監視機能について

Elastic CloudではAlert機能を利用することで監視／通知を行うことができます。またデフォルトで多くの監視項目が設定可能なため、簡単に監視設定を行うことが可能です。デフォルトルールを作成して監視機能を利用してみましょう。

(1)左のメニューから「Stack Monitoring」を押下し、Monitoring画面右上の「alerts and rules」を選択し「Create default rules」を押下

(2) 「Create」を押下

これで監視設定ができました。最後に作成されたルール一覧を確認してみましょう。

(3) 「Stack Management」を押下し、「Alerts」を選択、その後画面右上の「Manage rules」を押下

作成されたルール一覧が表示されます。ルールを編集することで条件の変更や通知設定を行うことも可能です。

例えば「CPU Usage」のルールはCPU使用率の5分間の平均が85％を超えた場合検知／通知されます。

また通知先はデフォルトではKibanaログに出力される設定になっていますが、メールやSlack等の多くのコネクタが利用可能です。

まとめに

ここまで構築編、運用編1と構築／セキュリティ設定／運用設定を実施してきました。これでかなりポイントを押さえたElastic Cloudの利用が可能となっていると思います。また実際に運用していくと、上記の３点以外に以下も必要になることがあるかもしれません。

バージョンアップ対応
監査ログ

そこで次回の記事では上記の内容についても解説していきたいと思います。

2024-07-25

ChatGPTとOneDriveを連携させて業務効率化

生成AI ChatGPT

はじめに

こんにちは、イワツカです。
最近は湿度と気温が高く蒸し暑いので海やプールで涼みたいものですね。

さて今回は、OpenAIからChatGPTのExcelデータの分析機能が進化したという発表があったので、OneDrive上のファイルをもとにExcelデータをどのように分析できるのか試してみます。

概要

今回、ChatGPTにデータ分析機能の強化として以下2点の新機能が発表されました。
・OneDrive・Google Driveからファイル連携
・テーブルデータをプロンプトによってインタラクティブに操作できるようになった。

Google Drive・Microsoft OneDriveからのファイル連携

今までファイルを直接アップロードするしかChatGPTに読み込ませる方法がなかったのが、Google Drive・Microsoft OneDriveをChatGPTと連携させて、ファイルを読み込ませることができるようになりました。

https://openai.com/index/improvements-to-data-analysis-in-chatgpt/

テーブルデータのインタラクティブな操作

ChatGPT PlusやChatGPT Team、ChatGPT Enterpriseユーザー向けですが、ChatGPTに連携したファイルの表データをプロンプトを通してインタラクティブに編集したり、グラフを作成したりできるようになりました。
今までだと、一度読み込ませたデータはプロンプトで変更はできますが、別ファイルとして出力させて、中身を確認するためにはダウンロードする必要がありました。
それが、今回画面にデータを表示しながら操作できるようになり、より直感的にプロンプトで分析できるようになりました。

この記事で試すこと

この記事ではOneDriveとの連携方法や実際にOneDriveからファイルをアップロードし、テーブルの操作や図の生成を通してデータを分析してみます。
題材は都道府県別の日本の人口を扱い、どのような人口変化があるのかを見ていきます。

OneDriveとの連携方法

ChatGPTとOneDriveの連携は以下の4ステップで可能です。
1. アップロード方法を選択
2. 接続するMicrosoft OneDriveを選択する
3. Microsoftアカウントでサインインする ※既にサインイン済の場合は不要
4. OneDriveへのアクセスを許可

それでは、具体的な方法を順に見ていきます。

アップロード方法を選択
ChatGPTの画面のメッセージ入力欄の左にあるアップロードボタンを押すと、アップロード方法を選択できます。
OneDriveとの連携を行っていない場合は、下図のようにOneDriveとの接続という項目が現れるのでそれを選択してください。

アップロード方法を選択
接続するMicrosoft OneDriveを選択する
Microsoft OneDriveには個人用(personal)と仕事/学校用(work/school)があるので、利用する方のOneDriveを選択してください。

Microsoft OneDriveに接続する
Microsoftアカウントでサインインする
Microsoftアカウントにサインインしていない場合は下図の画面に遷移するので、サインインしてください。
既にサインインしている場合はこの画面は出てきません。

Microsoftアカウントでサインイン
OneDriveへのアクセスを許可
最後にChatGPTからOneDriveへのアクセスを許可すれば連携完了です。

OneDriveへのアクセスを許可

OneDriveからファイルをアップロードしてみる

OneDriveとの連携ができたので、実際にOneDriveにあるファイルを直接ChatGPTにアップロードしてみます。
方法はコンピューターからアップロードする場合と同様、チャット入力欄の左側にあるアップロードボタンからできます。

ポップアップする画面からファイルを選択すればアップロードは完了です。

ChatGPTでデータ分析する

今回使用するのは、都道府県ごとの人口データが載ったExcelファイルです。2013年と2023年のシートがあります。

アップロードされたExcelのテーブルを見る

まずは特に指示を与えずにChatGPTにファイルのみ与えます。
すると、インタラクティブなテーブルが生成されます。

データの分析機能のアップデートにより、Excelファイルの複数のシートも切り替えて見えるようになっています。

また、テーブルの右上のボタンから拡大したテーブルを見ることができます。
これにより画面左側に分析中のテーブル、右側にデータを操作するためのチャット画面という配置になり、以前よりもデータ分析がしやすくなっています。

テーブルをプロンプトから操作

次に2013年から2023年までの10年間で人口が増えている都道府県を見てみます。
入力したプロンプトはこちらです。

出力は、人口が増えた都道府県のみのテーブルとなりました。

グラフを出力

最後に日本全国の年齢別の人口変化をグラフとして見てみます。
入力プロンプトはこちらです。

出力として、年齢別の人口変化グラフが生成されました。
左から順に、15歳未満、15-64歳、65歳以上について2013年と2023年が比較できるグラフになっています。

インタラクティブに操作できるようになっており、右上にあるボタンから色を変更することができます。

まとめ

まとめ OneDriveとの連携により、ファイルをChatGPTに連携することが簡単になりました。
加えて、データ分析機能の改善により自然言語だけで自由にデータ分析をできるようになり、便利になりました。

データの分析やグラフ描画などを色々と試してみると、例えば、複数のグラフを描画させた場合に、グラフ次第ではインタラクティブな操作がうまくできないケースなどもありましたが、生成AIの可能性を感じられる機能だと思いました。

プログラミングやExcelの知識が無くてもデータ分析ができるので、ぜひ試してみてください。

2024-07-22

DifyとKnowledge bases for Amazon Bedrockを連携させてRAGを構築する

生成AI Dify AWS

こんにちは。ベランダで育てていたバジルが虫に食べられてしまいました。ハヤトです。
しかし植物の生命力というのはすごいもので、残った茎から再び葉っぱが成長してきています。次はぜひ私が食べたいものです。

さて、成長著しいといえば生成AIアプリ開発の分野はまさに日進月歩ですが、
なかでも「Dify」は、LLMワークフローが特に便利で、注目度が急上昇中です。
今回はそんなDifyとKnowledge bases for Amazon Bedrockを連携させてRAGを構築してみます。

Difyとは？

Difyは、生成AIアプリを手軽に構築できるオープンソースのLLMアプリ開発プラットフォームです。
簡易的なチャットボットであれば、プログラミング知識がなくてもノーコードで作成できてしまいます。

dify.ai

Knowledge bases for Amazon Bedrockとは？

Amazon Bedrockで検索拡張生成（RAG）を簡単に構築するためのサービスです。
RAGは、生成AIにモデルが学習していない外部情報を組み合わせることで回答の精度を高める手法です。

aws.amazon.com

今回作成するチャットボットについて

DifyにもRAGで使用するナレッジを作成する機能は組み込まれていますが、2024年7月現在では選択できるデータソースは以下に限られています。

テキストファイルからインポート
Notionから同期
ウェブサイトから同期

そのため今回は、データソースとしてより多くの社内データなどを扱う実際的なユースケースを想定して、
Knowledge bases for Amazon BedrockをDifyのナレッジとして使用するRAGチャットボットの構築手順を説明していきます。

構成イメージ：

AWS側の設定手順

AWS側では、Knowledge bases for Amazon Bedrockを使ってナレッジベースを作成し、
そこから知識取得を行うAPIをLambda + API Gatewayで構築します。

ナレッジベースの作成

今回はサンプルとして、IPAが公開している以下の資料を情報として持つナレッジベースを作成します。

作成手順については、以下の記事で詳細を説明しているのでこちらに従います。
acro-engineer.hatenablog.com

ナレッジベースが作成できたら次のステップで使用する「ナレッジベース ID」をメモしておきます。

APIの作成

Knowledge base for Amazon Bedrockには、クエリに対してナレッジベースに基づいた回答を生成する
「RetrieveAndGenerate API」が用意されています。
docs.aws.amazon.com

今回はこれを使用して、先ほど作成したナレッジベースから回答を取得するAPIを作成します。

Lambdaの作成

RetrieveAndGenerate APIを実行するLmbdaを作成します。

今回は最小限の内容で、以下のような形式のリクエストを受け取ってqueryに対する回答を取得する実装になります。

{
  "query": "安全なウェブサイトの作り方を教えてください。"
}

コードから「lambda_function.py」を以下の内容に編集します。
※{作成したナレッジベースのID}は先ほどメモしたナレッジベース IDに置き換えてください。

import boto3
import json

KNOWLEDGE_BASE_ID = '{作成したナレッジベースのID}'

print('Loading function')
client = boto3.client('bedrock-agent-runtime')


def lambda_handler(event, context):
    response = client.retrieve_and_generate(
        input={
            'text': event['query']
        },
        retrieveAndGenerateConfiguration={
            'knowledgeBaseConfiguration': {
                'knowledgeBaseId': KNOWLEDGE_BASE_ID,
                'modelArn': 'anthropic.claude-v2:1'
            },
            'type': 'KNOWLEDGE_BASE'
        }
    )

    return response

参考ドキュメント：
boto3.amazonaws.com

注意点としては、AmazonBedrockへのアクセス権限の付与が必要となります。今回は「AmazonBedrockFullAccess」を付与しました。
（今回は簡単のため上記の設定としていますが、本来は必要最小限の権限だけに限定するのが適切です）
また、RetrieveAndGenerate APIの応答には時間がかかるのでLambdaのタイムアウトは30秒に変更しました。

設定ができたら作成したLambdaをテストしてみましょう。

正しく設定できていれば、作成したナレッジベースに基づく質問に対する回答が得られます。

API Gatewayの作成

次に、作成したLambdaを実行するAPIをAPI Gatewayで作成します。

POSTメソッドとして先ほど作成したLambdaを実行するメソッドを作成します。

リクエストボディの形式を指定するために、以下の内容でモデルを作成します。

{
  "$schema": "http://json-schema.org/draft-04/schema#",
  "title" : "Query Schema",
  "type" : "object",
  "properties" : {
    "query" : {
      "type" : "string"
    }
  }
}

メソッドリクエストの編集からリクエスト本文として作成したモデルを設定します。
あわせてAPIキー認証を有効にしておきます。

ここまでの設定ができたらAPIをデプロイします。
APIキー認証のために、デプロイしたステージとAPIキーの紐づけが必要なので、以下を参考に設定を行います。
docs.aws.amazon.com

認証の設定ができたのでAPIを呼び出してみましょう。
APIのURLをコピーします。

今回はPostmanでAPIを呼び出してみました。
Headersで「x-api-key」に作成したAPIキーを設定する必要があります。

無事、Lambdaの実行時と同等のレスポンスを得られました。
作成したAPIのOpenAPIスキーマをこのあと使用するので、
API Gatewayの「ステージ>ステージアクション>エクスポート」を選択しておきます。

AWS側の準備はこれで以上になります。

Dify側の設定手順

Dify側では、AWS側で構築した知識取得のAPIを実行するカスタムツールと、
そのレスポンスを元にユーザへの回答を行うチャットボットを構築します。

DifyはOSS版を自分でデプロイして使うことも出来ますが、
今回はブラウザから手軽に利用できるSaaS版を使いました。

カスタムツールの作成

Difyで「ツール>カスタム>カスタムツールを作成する」を選択します。
先ほどエクスポートしたOpenAPIスキーマを一部編集して設定します。

servers.urlが変数を含む形になっているので実際のパスに置き換える。
paths.postに以下の設定を追加する（「利用可能なツール」の表示に必要）。

summary: Retrieve And Generate
operationId: retrieveAndGenerate

「認証方法」からリクエストに使用するAPIキーを設定します。

「利用可能なツール>テスト」でAPIを呼び出せたら設定OKです。

チャットボットの作成

いよいよ最後のステップです。「スタジオ>最初から作成」でチャットボットを作成します。
はじめからノードベースで構築したいので、「チャットボットのオーケストレーション方法」はChatflowを選択します。

開始ブロックの後ろに先ほど作成したカスタムツールを追加し、ユーザが入力したクエリを受け取るようにします。

次に後続のLLMブロックがカスタムツールで取得した情報を元に回答をするように設定します。
※カスタムツールのレスポンス内にBedrock側で生成した回答も含まれていますが、
レスポンスのパース処理を書くよりLLMに解釈させる方が楽なので今回はそのようにしています。

以下の設定を行いました。

モデルをgpt-4o-2024-05-13に変更
コンテキストにカスタムツールの出力内容を設定
SYSTEM、USERプロンプトに以下を設定

SYSTEM

あなたはユーザの言語に合わせて回答を行うQAチャットボットです。
質問に対する回答は、事前知識ではなく取得した以下のコンテキストに基づいて行ってください。
---
{{#context#}}
---

USER

コンテキストに基づいて、以下のユーザからに質問に答えてください。
---
{{#sys.query#}}
---

以上で設定は完了です。

デバッグとプレビューで会話を試してみましょう。

質問文：

DX推進スキル標準で定義されている人材類型について教えてください。

質問文：

IPAがウェブサイトの脆弱性に関する届出を受けた場合の、脆弱性対策の流れを教えてください。

それぞれカスタムツールで取得したナレッジベースの情報を元に回答してくれていることがわかりますね。

まとめ

今回は手軽に生成AIアプリを開発できるDifyと、企業レベルのユースケースにも対応したナレッジベースを構築できる
Knowledge bases for Amazon Bedrockを連携させたRAGチャットボットを作成しました。
Difyのカスタムツールを使用すれば、今回使用したナレッジベースに限らず様々なサービスと連携させられそうで夢が広がりますね。

2024-07-12

AWSでElasticsearch(Elastic Cloud)を使う時のポイント 2024年版（運用編1）

AWS Elasticsearch Kibana Elastic Cloud

こちらはAWS編の記事になります。

AWSでElasticsearch(Elastic Cloud)を使う時のポイントの記事一覧は以下です。
①構築編
acro-engineer.hatenablog.com
②運用編2
＜運用編２近日公開予定!!＞

本記事ではElastic Cloudを運用するにあたり、必要な各種設定を実施する手順を紹介します。

はじめに
 1. Monitoring設定（Metric／Logs）
2. Snapshot設定
 3. 監視設定
 まとめ

はじめに

以下本記事ではElastic Cloud(Elasticsearch Service)の名称を統一して「Elastic Cloud」で記載します。

1. Monitoring設定（Metric／Logs）

Monitoring機能について

Elastic CloudでMonitoring機能を有効化する

Monitoring機能はデフォルトでは有効化されていません。
そのため以下の手順で有効化していきます。

(1) Elastic CloudのDeploymentの画面にアクセスしメニューの「Logs and metrics」を押下

(2) 「Ship to a deployment」の「Enable」を押下

(3) 構築したDeploymentを選択し「Save」を押下

Monitoring機能が有効化されます。

Metricを確認する

MetricではElastic Stackがそれぞれどれ位サーバリソースを利用しているかを確認可能です。

(1) Kibana画面の左側のメニューから「Stack Monitoring」を押下

(2) Elasticsearchの「Overview」を押下

OverviewではElasticsearch全体の検索性能／インデキシング性能をリアルタイムに確認可能です。

(3) Elasticsearchの「Nodes」からインスタンスを１つ選び押下

各サーバ毎のリソースの状況がリアルタイムに確認可能です。

Logsを確認する

Logsではリアルタイムにログを確認／絞り込みを行いながら調査することが可能です。

(1) Kibana画面の左側のメニューから「Logs」を押下

Stream画面ではElasticsearchに取り込んでいる各種ログがリアルタイムに表示されます。

(2) 画面上部の検索窓に「error」と入力し、ログの絞り込みを実行

ログを絞り込みながら問題調査を実施することが可能です。

Metricの保持期間を変更する

Metricの保持期間はデフォルトでは３日に設定されています。要件毎に保持期間は異なると思いますので、設定を変更してみましょう。

(1) Kibana画面の左側のメニューから「Stack Management」を押下

(2) 「Index Lifecycle Policies」を押下

(3) 検索窓に「.monitoring」と入力し表示される「.monitoring-8-ilm-policy」を押下

フェーズ	設定値
Hotフェーズ	インデックス作成から3日経過 or プライマリーシャードのサイズが50GB以上になった際インデックスをRolloverする
Warmフェーズ	セグメント数が1になるようにForcemergeを実行する
Deleteフェーズ	Rollover後、3日経過したインデックスを削除する

(4) Deleteフェーズの値を「3 days」から「31 days」に変更し「Save Policy」を押下

上記の手順で、Rollover後31日経過したインデックスを削除するように設定を変更できました。

2. Snapshot設定

Snapshot設定について

Elastic Cloudではデフォルト設定で30分に1回スナップショットを取得します。こちらも設定確認／設定変更していきましょう。

(1) Kibana画面の左側のメニューから「Stack Management」を押下

(2) 「Snapshot nad Restore」を押下

(3) 「Policies」タブを押下し、「cloud-snapshot-policy」右側の「Edit」ボタンを押下

(4) 「Schedule」の設定値を変更

(5) 必要に応じて「Expiration」「Snapshots to retain」の設定値を変更

(6) 「Save policy」を押下

(7) 「cloud-snapshot-policy」を押下し「Summary」を表示

変更した結果、毎日0時（JST）にスナップショットが取得されるようになりました。

3. 監視設定

Elastic Cloudの監視機能について

(1)左のメニューから「Stack Monitoring」を押下し、Monitoring画面右上の「alerts and rules」を選択し「Create default rules」を押下

(2) 「Create」を押下

これで監視設定ができました。最後に作成されたルール一覧を確認してみましょう。

(3) 「Stack Management」を押下し、「Alerts」を選択、その後画面右上の「Manage rules」を押下

作成されたルール一覧が表示されます。ルールを編集することで条件の変更や通知設定を行うことも可能です。

例えば「CPU Usage」のルールはCPU使用率の5分間の平均が85％を超えた場合検知／通知されます。

また通知先はデフォルトではKibanaログに出力される設定になっていますが、メールやSlack等の多くのコネクタが利用可能です。

まとめに

バージョンアップ対応
監査ログ

そこで次回の記事では上記の内容についても解説していきたいと思います。

2024-07-09

Difyを使ってノーコードでAIエージェントを作成する

Dify ChatGPT LLM 生成AI

こんにちは、機械学習チーム YAMALEX の駿です。
YAMALEX は Acroquest 社内で発足した、会社の未来の技術を創る、機械学習がメインテーマのデータサイエンスチームです。
（詳細はリンク先をご覧ください。）

最近は GPT-4o や Claude 3 を使ったアプリを、せっせと実装したりしていたのですが、Difyの登場により「もう、これでいいじゃん」という気持ちが抑えきれていません。

今回はそんなDifyを使って、「LLM自体の知識が足りないときにGoogle検索を行って回答するチャットボット」を作ってみました。

Google検索して答えてくれる

1. 概要

1.1. Difyとは

Difyは、大規模言語モデル（LLM）を活用したアプリケーションを開発するためのオープンソースプラットフォームです。

注目するべき特徴として、以下の４点があると考えます。

GUIを使って複雑なタスクを実行するAIエージェントを簡単に作成することができる
複数モデル（ChatGPT、Bedrock、Llamaなど）を包括的に利用できる
作成したエージェントをAPIとして公開し、既存のアプリケーションに組み込むことができる
LLMOps 機能が組み込まれている

今回は特に 1. 、 2. に注目します。

dify.ai

2. 環境構築

DifyはSaaSのサービスとしても提供されていますが、今回はDockerコンテナを利用して、ローカルにサーバを立てて実行してみます。

docker-compose.yaml が用意されているため、簡単にローカルで起動できます。

Githubからコードを取得する

 git clone https://github.com/langgenius/dify.git

適宜、 docker/docker-compose.yaml を編集する

name: dify を追加するのがおすすめです。

サーバを Docker Compose で立ち上げる

 docker compose -f docker/docker-compose.yaml up -d

http://localhost にアクセス
ユーザ作成画面が開くので、ユーザを作成する

3. アプリ作成

「スタジオ」>「アプリを作成する」>「最初から作成」を押下

最初から作成
「チャットボット」>「Chatflow」を選択し、アプリの名��を入力

Chatflow を選択
ブロックをつないでアプリを作成

ブロックをつないでアプリを作る

3.1. 各ブロックの簡単な説明

質問分類器「質問分類」

LLMを使って、ユーザの質問をいくつかのクラスに分類します。
この分類結果によって、後続の処理を切り替えることで複数の役割を持つエージェントを作成することができます。
LLM「チャット」「Q＆A」「履歴要約」「回答生成」

モデル、システムプロンプト、ユーザ入力などを指定して、LLMを呼び出します。

ブロックごとにモデルを指定することができるのがいいですね。
今回は裏側の処理はGPT-3.5-Turboを使い、高速化・安価化を狙いつつ、
最終的にユーザに返答する部分ではGPT-4oを使って、ベストな出力ができるようにしています。
パラメーター抽出「クエリ抽出」

ユーザ入力から、後続のブロックで必要なパラメータを抽出することができます。
Function calling のような機能です。

「ツールからインポート」するオプションがあるため、基本的に自分でパラメータを設定する必要はありません。
楽です。
GoogleSearch

見たまんま、Googleで検索して、結果をLLMが読み込める形で返してくれます。

内部で SerpApi を利用しているため、会員登録とAPIキーの設定が必要です。
出力

チャットボットの返答として返却する文字列を指定します。

4. 動かしてみる

「デバッグとプレビュー」機能を使って、実際に想定通りの分岐をたどっているか、検索ができているかを確認します。

下の図で線が青くハイライトされている部分が、分岐の結果、実際に実行されているフローを表しています。

一般的な知識を質問してみる

 User:
 ワインを発酵させると酢になるってホント？

 Q&A:
 はい、部分的には本当です。
 ワインが酵素に長時間さらされると、酵母や細菌がアルコールを酢酸に変えることで、ワインビネガー（酢）になります。
 これは、アセトバクターという最近の働きによるものです。
 ただし、通常のワインの発酵は、アルコールを生成するプロセスですので、適切に管理された環境では酢にはなりません。

一般的な知識

各ブロックの実行時間

# ブロック実行時間（秒）

1 Start 0.001

2 質問分類 1.317

3 Q&A 1.693

4 出力 0.004

計 3.076

専門知識について質問してみる

 User:
 Amazon Bedrockについて教えて

 GoogleSearch:
 content: What is Amazon Bedrock? ... Using Amazon Bedrock, you can easily experiment with and evaluate top FMs for your use case, privately customize them with your data ...
 link: https://aws.amazon.com/bedrock/
 content: With this new capability, AWS makes it easy for organizations to choose a combination of Amazon Bedrock models and their own custom models via ...
 link: https://www.aboutamazon.com/news/aws/amazon-bedrock-new-innovations-generative-ai-applications
 <略>

 回答生成:
 Amazon Bedrockは、AWSが提供するフルマネージドサービスで、
 主要なAI企業からの基盤モデル（Foundation Models, FMs）を利用可能にします。
 ユーザーは自身のユースケースに合わせて、これらのモデルを簡単に実験し評価することができ、
 さらに自分のデータを使ってプライベートにカスタマイズすることもできます。
 このサービスはAPIを通じてアクセスでき、組織がAmazon Bedrockモデルとカスタムモデルを組み合わせて使用することを容易にします。

 詳細については、こちらをご覧ください。

専門知識

各ブロックの実行時間

#	ブロック	実行時間（秒）
1	Start	0.001
2	質問分類	1.141
3	履歴要約	2.708
4	クエリ抽出	0.818
5	GoogleSearch	1.050
6	回答生成	3.799
7	出力	0.002

	計	9.612

質問以外のチャットをしてみる
```
 User:
 今日もジムに行って疲れちゃった

 チャット:
 お疲れ様！それだけ頑張った証拠だね。どんなトレーニングしてきたの？
```
チャットする
- 各ブロックの実行時間
  
  # ブロック実行時間（秒）
  
  1 Start 0.001
  
  2 質問分類 1.117
  
  3 チャット 0.578
  
  4 出力 0.001
  
  計 1.732

ちゃんとLLMの知識を使ったQ&AとGoogle検索を使ったRAGが切り替えられています。
また、質問ではない入力については、気さくに返答するように指示したので、他の２例のように事務的な返答ではなく、楽しい会話ができそうです。

マウスでブロックをつなげて、簡単な指示を日本語で入力するだけで、これだけのAIエージェントが作れてしまうのは、強力ですね。

また、今回はGPT-3.5-TurboとGPT-4oしか使っていませんが、 Bedrock と接続して Claude 3 を使うこともできます。
それもプルダウンで選択するモデルを変更するだけ、という手軽さなので、そのタスクに応じて適切なモデルを指定する、などを気軽に行えます。

5. まとめ

さて、今回はDifyを使って、「知識が足りないときにGoogle検索を行って回答するチャットボット」を作成しました。

繰り返しになりますが、Difyを使うと、GUIのみで複雑なAIエージェントを簡単に作成することができます。
これを使わない手はないですね。

さらに、今回は扱っていませんが、 Custom ToolやAPI公開など、魅力的な機能がDifyにはまだまだあります。
全部使いこなして最高のAIエージェントを作りたいですね。

2024-07-08

AzureでElastic Cloudを利用する 2024年版（構築編）

Azure Elastic Cloud Elasticsearch Kibana

Elastic CloudはElastic社が提供しているSaaSサービスで、クラウドプロバイダはAWS、Azure、GCPをサポートしています。
最新バージョンのクラスタ構築や、既存クラスタのバージョンアップを数クリックで実施できるため、導入がお手軽です。

しかし実際に利用するとなるとアクセス制限やEntra IDとのSAML連携など、考慮すべきことが多くあります。
意外にハマりどころが多い所だと思うので、手順や注意事項などをまとめてみました。

AzureでElasticsearch(Elastic Cloud)を使う時のポイントの記事一覧は以下です。
①運用編1
acro-engineer.hatenablog.com
②運用編2
＜運用編２近日公開予定!!＞

本記事ではAzure Marketplaceを利用してElastic Cloudを構築し、Security設定／認証設定を実施する手順を紹介します。
AWS上でElastic Cloudの構築、Security設定／認証設定を行いたい方はこちらの記事を是非ご覧ください。
acro-engineer.hatenablog.com

はじめに
 1. Marketplace経由で構築
 2. Security強化(IPフィルタリング設定)
3. Security強化(Private Link設定)
4. KibanaにEntra IDによるSAML認証を追加
 まとめ

はじめに

以下本記事ではElastic Cloud(Elasticsearch Service)の名称を統一して「Elastic Cloud」で記載します。

AzureでElastic Cloudを構築するステップ

以下の４つのステップでAzure上にElastic Cloudを構築することが可能です。

Marketplace経由で構築
Security強化(IPフィルタリング設定)
Security強化(Private Link設定)
KibanaにEntra IDによるSAML認証を追加

構成イメージは下図です

以下それぞれのステップについて構築／設定方法を解説していきます。

1. Marketplace経由で構築

Marketplaceでの導入手順

１つ目のSTEPとして、Azure Marketplace経由でElatic Cloudを構築していきます。

(1) Azure MarketplaceのElatic Cloudのページにアクセスし、「購読する」を押下

azuremarketplace.microsoft.com

(2) サブスクリプション、リソースグループ、リソース名を設定する

(3) 画面下に表示されている「Review + create」を押下する

(4) Review で問題が無いことを確認し「Create」を押下する

(5) DeployしたKibanaにログイン確認する

無事作成されたDeploymentのKibanaにログインできました。
URLは「https://＜Deployment名＞.kb.westus2.azure.elastic-cloud.com/app/home」のように作成されたDeployment名が付与されます。

2. Security強化(IPフィルタリング設定)

次のステップとして構築したDeploymentにIPフィルタリングを設定していきます。

IPフィルタリングで出来ること／メリット

IPフィルタリングを設定することで、Deployment(Elasticsearch、Kibana)へのアクセス制限が可能となります。
詳細については以下のブログを参照ください。
www.elastic.co

では実際に設定してみましょう。

IPフィルタリング設定方法

(1) 作成したDeploymentの管理画面から「Features」を押下

(2) 「Add traffic filters」を押下し、「Create filter」を押下

(3) IPアドレス等の条件を入力後、「Create filter」を押下

作成に成功すると以下のように作成されたIPフィルタリングの定義が表示されます。

(4) DeploymentのSecurity設定画面の「Apply filter」を押下し、作成したルールをDeploymentに適用

作成したIPフィルタリングの定義を適用します。

以上でElastic Cloud上に構築したDeploymentにIPフィルタリングの定義を適用することができます。

3. Security強化(Private Link設定)

続いてPrivate Linkも設定していきましょう。
Private Linkを設定することで、インターネットを経由しない通信となりセキュアにすることが可能です。

Private Link設定方法

(1) AzureのEndpointを作成

作成方法については以下を参照ください
www.elastic.co

注意点としては、Azure Private Link Service aliasの値は各Region毎に異なるためご利用のRegionに応じて値を設定してください。

(2) 「Add traffic filters」を押下し、「Create filter」を押下

IPフィルタリングの時と同様にfilter作成画面を開きます

(3) Filter typeで[Private link endpoint]を選択し、Resource nameとResource IDに(1)で作成したEndpointの情報を入力し「Create filter」を押下

(4) IPフィルタリングと同様に作成したルールをDeploymentに適用

IPフィルタリングとPrivate Linkの２つのSecurity設定が適用されました

4. KibanaにEntra IDによるSAML認証を追加

ElasticsearchはSAML(Security Assertion Markup Language)による認証が可能です。
SAML連携による認証のメリットはユーザ管理を１つのサービスに集約可能なため管理／運用が容易になります。

そこで最後にKibanaにEntra IDによるSAML認証を追加しましょう。

Entra IDによるKibana認証設定方法

SAML認証の設定は以下の手順が必要です。詳細は公式ドキュメントを参照ください。
www.elastic.co

Azure ID プロバイダーの構成
SAML認証の設定
role mapping (Kibana操作権限の設定)

(1) AzureポータルにログインしEntraに移動し「エンタープライズアプリケーション」に新しいアプリケーションを追加

(2) 「独自のアプリケーションを作成する」を押下し、名前を入力して、「ギャラリーに見つからないその他のアプリケーションを統合する」オプションを選択し作成する

(3) 作成したアプリケーションに移動後「ユーザーとグループ」を押下し、必要なユーザーとグループを追加

ここで追加したユーザーとグループのみが Elastic スタックへアクセス可能です。

(4) シングルサインオンを押下し、「基本的なSAML構成」を設定

以下の通りそれぞれURLを設定し「保存」を押下し、設定を反映します。

SAML構成設定	設定値
識別子 (エンティティ ID)	＜Kibana_Endpoint_URL＞
応答 URL (Assertion Consumer Service URL)	＜Kibana_Endpoint_URL＞/api/security/saml/callback
ログアウト URL	＜Kibana_Endpoint_URL＞/logout

(5) 作成したDeploymentの管理画面から「Edit」を押下

(6) Elasticsearch右側のリンク「Manage user settings and extensions」を押下

(7) ElasticsearchにSAML設定を適用

設定内容は以下

xpack.security.authc.realms.saml.kibana-realm:
            order: 2
            attributes.principal: nameid
            attributes.groups: "http://schemas.microsoft.com/ws/2008/06/identity/claims/groups"
            idp.metadata.path: "https://login.microsoftonline.com/<Tenant ID>/federationmetadata/2007-06/federationmetadata.xml?appid=<Application_ID>"
            idp.entity_id: "https://sts.windows.net/<Tenant_ID>/"
            sp.entity_id: "<Kibana_Endpoint_URL>"
            sp.acs: "<Kibana_Endpoint_URL>/api/security/saml/callback"
            sp.logout: "<Kibana_Endpoint_URL>/logout"

「Application_ID」には(1)で作成したアプリケーション ID、「Tenant ID」にはEntraのテナントIDをそれぞれ設定してください。

(8) Kibana右側のリンク「Edit user settings」を押下

(9) KibanaにもSAMLログイン用の設定を適用

設定内容は以下

xpack.security.authc.providers:
  saml.kibana-realm:
    order: 0
    realm: kibana-realm
    description: "Log in with Azure AD"
  basic.basic1:
    order: 1

(10) 画面下の「Save」を押下し設定を適用

(11) Kibana画面左側メニューの「Stack management」を押下し、その後「Role mappings」を押下

Role mappingsを定義することで、Entra IDで認証されたユーザに対してKibana操作権限の設定が可能です。

(12) 「Create role mapping」を押下し、SAML認証のアカウントに権限を紐づける

以下の通り、SAML認証経由でログインしたユーザの権限を設定していきます

Kibanaへのログイン

設定後、登録したユーザでログインが可能です。

まとめ

AzureでもElastic Cloudであれば構築／Security設定が容易です。
現在ご利用頂いているクラウドサービスに合わせてElastic Cloudを検討してみてください。

2024-07-05

Amazon Q Businessで色々なデータソースを扱ってみた

AWS 生成AI

はじめに

昨日の記事に続き、新人エンジニアの木介が、Amazon Q Businness の紹介をしたいと思います。
この記事では、Amazon Q Businnessで、さまざまなデータソースを用いたRAGアプリケーションの作成方法と、guardrailsの機能を利用した回答を適切に制限する方法について紹介をしていきます。

acro-engineer.hatenablog.com

Amazon Q Businessの概要

Amazon Q BusinessとはRAGアプリケーションを各項目を設定するだけで簡単に作成できるサービスであり、その特徴については以下にまとめます。

1. 回答に利用された情報源への引用を明示することが可能
2. Amazon Q Appsで簡単にアプリケーションを作成できる
3. さまざまなデータソースを利用可能
　・ S3やTeams、Webサイトなど、30種類以上のさまざまなデータソースを利用可能
4. アクセス制限によるデータ及びアプリケーションへのセキュリティの保証
　・ガイドラインに基づいた不要なトピックやキーワードの回答の禁止
　・アプリケーションへアクセスできるユーザーの制限が可能

1、2の項目については以下の記事で説明していますので、まだ読まれていない方はぜひそちらをご覧ください。

acro-engineer.hatenablog.com

本記事では特に3、4の項目のさまざまなデータソースを扱える点とguardrailsにより回答を制限できる点について触れていきたいと思います。

さまざまなデータソースで作成してみる

では早速Amazon Q Business でさまざまなデータソースを用いてアプリケーションを作成して行きたいと思います。
まずAmazon Q Businessで現在取り扱えるファイルとしては以下のものとなっています。

ドキュメント形式	ドキュメントの取り扱い
PDF	HTMLに変換され、プレーンテキストが抽出されます。スキャンされたPDFはサポートされていません。
HTML	HTMLタグがフィルタリングされ、プレーンテキストが抽出されます。コンテンツはメインHTML開始タグと終了タグ（content）の間にある必要があります。
XML	XMLタグがフィルタリングされ、プレーンテキストが抽出されます。
XSLT	タグがフィルタリングされ、プレーンテキストが抽出されます。
Markdown (MD)	コンテンツはMarkdown構文を保持したプレーンテキストとして抽出されます。
CSV	各セルからプレーンテキストが抽出され、単一ファイルが単一ドキュメント結果として扱われます。Amazon QはCSVの分析質問をサポートしておらず、定性的な質問のみをサポートしています。
Excel (XLS, XLSX)	各セルからプレーンテキストが抽出され、単一行が単一ドキュメント結果として扱われます。Amazon QはExcelファイルの分析質問をサポートしておらず、定性的な質問のみをサポートしています。
JSON	JSON構文を保持したプレーンテキストとしてコンテンツが抽出されます。
RTF	RTF構文がフィルタリングされ、プレーンテキストコンテンツが抽出されます。
PowerPoint (PPT, PPTX)	PowerPointスライドからプレーンテキストコンテンツのみが抽出されます。画像やその他のコンテンツは抽出されません。
Word (DOCX)	Wordページからプレーンテキストコンテンツのみが抽出されます。画像やその他のコンテンツは抽出されません。
Plain text (TXT)	テキストドキュメント内のすべてのテキストが抽出されます。

docs.aws.amazon.com

必要そうな形式は大体サポートされていますね！
今回はWebサイト、S3内のPDFをそれぞれデータソースとして試していこうと思います。

1. S3内のデータのQA

まずS3内のデータのQAを試していきたいと思います。
データソースの選択より、Amazon S3を選択することで利用可能です。

以下の設定画面が表示されますので、まずはデータソース名を入力。
このデータソース名についてはインデックス内で一意である必要があります。

IAM roleは新規に作成をします。

次に以下の設定によりデータソースとして扱うS3バケットを、Maximum file sizeの設定により取り扱うファイル容量の最大値を選択することができます。
今回は以下の設定で作成をしました。

こちらの設定にて同期する方法とタイミングを選択することができます。
以下のように設定し、変更があった箇所のみを手動で同期するようにします。

最後に「Add data source」を選択することでデータソースを追加することができます。

ではApplicationでデータソースを元にした回答が可能かを検証していきます。
予めS3バケットに先ほどと同じ労働条件ハンドブックの英語版をアップロードしていますので、先ほどと同じ質問を試してみましょう。

同様の回答が生成出来ていることが確認できました。

S3にアップロードしたファイルに対して要約し、回答できていることが確認できました。
S3内にソースとしたいドキュメントを集約する仕組みを作れば簡単にQAシステムが作成できそうです。

2. Webサイトの要約

次にWebサイトの要約を行いたいと思います。
やり方は先ほどと同じくデータソースの追加からWeb crawlerを選択します。
以下のような設定画面が表示されるので、入力していきます。

スクロールして、以下の画面でデータソースとして取り込むWebページを選択することができます。
今回はSource URLsを選択し、データソースとしてはAmazon Q Businessの以下のドキュメントを入力していきます。

docs.aws.amazon.com

登録したWebページの認証については以下から選択することができます。
ログイン処理といった認証が必要なページの場合にはNTLMやSAML、フォームでの認証の内のそれぞれ合致するものを適用することでクロールが可能です。
今回は公開ページなのでNo Authenticationを選択します。

IAM roleについても別途設定が必要となります。
今回は新しくroleを作成します。

その他の設定に関してはデフォルト値で作成を行います。
同様にしばらく待つと同期が完了します。
では早速Applicationで試してみましょう。

今回はWeb ページの要約を試したいので以下の質問を行います。

引用を明記し、要約出来ていることが分かります。

guardrailsによる回答の制限

では最後に、機密情報などの回答を制限するためのguardrails機能について試していきます。
まず右側のサイドメニューのAdmin controls and guardrailsを選択してguardrailsの設定に移ります。

以下の画面が表示されます
こちらに書いてある通り、特定のキーワードに対して回答を拒否するGlobal controlsと特定のトピックが出た際に指定のメッセージを回答するTopic specific controlsがあります。
まずはGlobal controlsから試していきましょう。

下部にあるGlobal controlsの編集で以下の画面が表示されます。
Response settingsでは質問の回答がデータソース内に存在しないときに、独自の答えを返すかどうかを設定することができます。
Blocked wordsでは回答を拒否するキーワードを指定することができます。
今回はS3上に存在するファイル名を知られないように「file name」をBlocked wordsとして登録してみます。

では次にTopic specific controlsの設定に移ります。
コチラも同様にAdmin controls and guardrails画面の下部にあるTopic specific controlsのCreate topic controlで作成できます。

以下の画面に遷移するのでNameに特定のトピックを指定します。
今回は「email address」をトピックとして指定しました。

Ruleを設定することでトピックが検出された際の挙動と、表示するメッセージなどが設定できます。
今回は以下のように、トピックが検出されると回答を拒否し、メッセージを表示するように設定しました。

では設定ができているか確認していきます。
まずはBlock wordに指定したfile nameについて質問してみましょう。
ブロックされていることが確認できます。

次にトピックに指定したmail addressについて質問をしてみます。
こちらも検出し、メッセージを回答出来ていることが確認できました。

このように簡単に生成AIアシスタントの回答に対して制限を付けることが出来るので、機密情報の漏洩の対策などが簡単に行えそうです。

まとめ

今回はノーコードでRAGを使った生成AIアシスタントシステムを構築可能なAmazon Q Businessを試してみました。
ノーコードでさまざまなデータソースを用いたRAGサービスを作成できる点が魅力的なサービスとなっていました。
今回紹介した機能以外にも対話をしなが��アプリケーションを作成するAmazon Q Appsなどのさまざまな機能がありますので、皆さんもぜひ利用してみてください。