2023-12-20

Amazon BedrockのKnowledge baseで簡単にRAGを構築

生成AI Bedrock

ポトフがおいしい季節ですね、菅野です。

Amazon BedrockのKnowledge baseがGAとなり、Amazon BedrockでもRAGが作成できるようになりました。

docs.aws.amazon.com

今回はKnowledgeベースを実際に作成して統計データを検索するRAGを構築してみます。

RAGとは

RAGアーキテクチャ（Retrieval-Augmented Generation）は、自然言語処理において、Google検索のような検索技術と、ChatGPTのような文章生成技術を組み合わせた技術です。
このアーキテクチャを利用すると、生成AIが学習していないデータ、例えば自社の内部レポートのようなデータを用いて、ChatGPTライクな応答システムを構築できます。
具体的には、何か質問を受けると、質問に関連した文章を検索し、その検索結果を元に自然となるような回答を生成する方法を採用しています。

Knowledge baseとは

Knowledge baseの概要

Knowledge baseは、Amazon Bedrockで簡単にRAGを実現するためのサービスです。次のように動作します。

前処理

まず前処理として、回答生成のためのデータを読み込みます。

ユーザーが回答生成時に参照させたいドキュメントのファイル一式を、S3にデータソース（図中のData Source）として登録します。
Knowledge baseはドキュメントをチャンクに分割(Splitting int chunks）、埋め込みモデル（Embedding Model)を用いてベクトル変換（Generating Embeddings）します。その結果をベクターDB（Vector DB）に保存します。
このようにすることで、次段の質問処理で、質問文と関連のある文章をスピーディーに検索することができるようになります。

質問処理

Knowledge baseは、ユーザの質問（User Query）を受け取ったら、前処理に使ったのと同じ埋め込みモデル（Embedding Model)を用いて質問をベクトル変換（Generating Embeddings）し、この質問文のベクトルと前処理で構築したベクターDBにあるベクトルたちと比較することで、質問文に一番近いドキュメントを引き当てます（Retrieve similar documents）。
文章モデル（Text Model）は、この引き当てられたドキュメントとユーザの質問文を拡張して（Augment User Query with retrieved documents）、ユーザへの応答を生成し、返します（Respond to User）。

詳細はAmazonの公式ページをご覧ください。

利用できるデータ、データ容量制限

利用できるデータは以下の形式になります。

.txt
.md
.html
.doc/.docx
.csv
.xls/.xlsx
.pdf

調べたり使ったりしてみたところ、次のような動きでした。

項目	内容
容量	1ファイルにつき最大50MBまでの制限があります。全体での容量制限はない模様です。
ディレクトリ階層	ディレクトリ階層を作ってアップロードしても、階層をたどって読み取ってくれます。
日本語対応	日本語でデータを登録して検索させることも可能です。
複数のファイル	質問のターゲットとなるようなファイルが複数あってもそれぞれに対して検索を実行してくれるようなので、ファイルの事前の結合処理なども不要なようです。
利用できるリージョン	現時点ではバージニア北部(us-east-1)、オレゴン(us-west-2)の二か所のみ対応しています。
利用できる言語モデル	現時点では、Anthropic Claude Instant v1、Anthropic Claude v2.0の２モデルが対応しています。

Knowledge base の構築

それでは実際にKnowledge baseを作成してみましょう。

利用するデータ

今回は、IPAが公開している以下の資料でKnowledge baseを作成していきます。

デジタルスキル標準 Ver.1.1
https://www.ipa.go.jp/jinzai/skill-standard/dss/ps6vr700000083ki-att/000106872.pdf

安全なウェブサイト運営にむけて

https://www.ipa.go.jp/security/todokede/vuln/ug65p90000019gda-att/000089537.pdf

上記pdfをダウンロードし、S3に以下のようなディレクトリ構造で配置します。

├─スキル
│      デジタルスキル標準.pdf
│
└─セキュリティ
        企業ウェブサイトのための脆弱性対応ガイド.pdf

Knowledge baseでは指定したバケット内を探索してデータを登録するため、上記のようにディレクトリ構造を作成しても全ファイルを対象として取得できる模様です。

データの中身は以下のようになっています。

Knowledge baseの作成

Bedrock画面の、Orchestration＞Knowledge baseから、Create knowledge baseを選択します。

Knowledge baseの詳細入力画面が出てくるのでそれぞれ以下の情報を入力しNextをクリックします。

項目	必須	入力内容
Knowledge base name	○	作成するKnowledge baseの名前
Knowledge base description		作成するKnowledge baseの詳細説明
Runtime role	○	既存のロールを選択するか、新規のロールを作成する
Agent resource role	○	Agentが利用するAWSのIAM Roleを自動で生成するかあらかじめ作成したIAM Roleを用いるかを選択
Service role name	○(自動で生成を選択した場合)	作成するRole名
Service role name	○(既存のロールを利用するを選択した場合)	利用するRole名を選択
Tags		生成されるAWSリソースへのタグ

データソースの定義を入力してNextをクリックします。

項目	必須	入力内容
Data source name	○	作成するデータソースの名前
S3 URI	○	利用するS3バケットを選択

ベクターDBの設定項目を入力してNextをクリックします。

項目	必須	入力内容
Embeddings model	○	埋め込みモデル（現時点ではTitan Embeddings G1以外選択不可）
Vector database	○	新規のベクターDB作成か、既存のベクターDBを利用するか選択

新規のベクターDBを作成をするとOpenSearch Serverlessのインスタンスが作成されます。こちらのインスタンスはKnowledgeBaseを削除しても残り続け、料金が発生し続ける為検証が完了したら直接OpenSerch Serverlessのコンソールに移動して削除を忘れないようにしましょう。

プレビューで今まで入力した情報が表示されるので、確認後Create knowledge baseを押下します。

無事Knowledge baseが作成されました、動作確認をする前にData sourceとのSyncを忘れずに実施しておきましょう。

このタイミングでTitan Embeddings G1モデルの利用申請をしていないとエラーになるので、Model Accessから申請をしておきましょう。

Knowledge baseを利用して文章を生成する

Knowledge baseのsyncが完了すると、Testボタンが表示されるようになります。
Testボタンを押下すると、テスト用のチャット欄が表示されます。

文章生成に利用するモデルを選択し、問い合わせのメッセージを入力しましょう。

出力された回答の括弧を押下すると、出典データが表示されます。

Show detailsで詳細データも確認することができます。

複数PDFに跨る検索も可能なようで、それぞれpdfのこの部分を要約して応答を作成してくれてますね。

まとめ

Amazon BedrockのKnowledge baseを利用してマネージドなRAGを作成しました。
エクセルファイルや、pdf、HTMLなど様々な形式のファイルをデータソースに設定できるので手軽に社内ドキュメントの検索タスクを生成AIに組み込んだりしていくことが出来そうです。
今後も生成AIの可能性を模索していきます。

Acroquest Technologyでは、キャリア採用を行っています。

ディープラーニング等を使った自然言語／画像／音声／動画解析の研究開発

Elasticsearch等を使ったデータ収集／分析／可視化

マイクロサービス、DevOps、最新のOSSやクラウドサービスを利用する開発プロジェクト

書籍・雑誌等の執筆や、社内外での技術の発信・共有によるエンジニアとしての成長

　少しでも上記に興味を持たれた方は、是非以下のページをご覧ください。 www.wantedly.com

2023-12-18

ElasticsearchのANNを利用して100万件のベクトル検索を高速化！

elastic 情報検索

この記事は Elastic Stack (Elasticsearch) Advent Calendar 2023 18日目の記事です。

こんにちは。
Acroquestのデータサイエンスチーム「YAMALEX」に所属する@shin0higuchiです😊
YAMALEXチームでは、コンペティションへの参加や自社製品開発、技術研究などに日々取り組んでいます。

さて、最近はLLMの発展に伴ってRAG（Retrieval-Augumented Generation）が盛んに活用されています。
その中で、キーワードベースの検索だけでなくベクトル検索を併用するケースが多く見られ、実際にElasticsearchが利用されているケースも多く目にします。そのため、Elasticsearchのベクトル検索に興味を持っている方も多いと思います。今回の記事では、Elasticsearchのベクトル検索の速度などを、簡単に計測してみました。

概要

検証環境のOS／ミドルウェアバージョン

OS/ミドルウェア	バージョン	備考
Elasticsearch	8.11.3
Kibana	8.11.3
OS	Ubuntu 22.04.3LTS	CPU 32コア, RAM 128GB。データ投入は別のWindowsマシンから実施

今回は以下の想定で検証を実施してみました。
RAGでよく用いるOpenAIのEmbeddingを用い、100万件の文章のベクトルをESに投入したと仮定して、その検索速度を計ってみたいと思います。
なお、OpenAIのEmbeddingを利用してベクトル化すると、各文章は1536次元のベクトルになります。

検証

インデックスのセットアップ

まずはデータを入れるためのインデックスにデータ型の定義を実施しておきます。
ここではシンプルに `vector` というフィールドのみを定義します。dense_vector型を指定し、1536次元を指定します。（上限はVer.8.11現在では4096次元です）

PUT single_vector_test
{
  "mappings": {
    "properties": {
      "vector": {
        "type": "dense_vector",
        "dims": 1536
      }
    }
  }
}

データ投入

データ投入にはLogstashを用います。
以下のような設定ファイルを作成して利用します。

input {
  file {
    path => "//pc-shin-gpu1/share/data/single_vector.txt"
    start_position => "beginning"
    sincedb_path => nul
  }
}

filter {
  mutate {
    rename => {"message" => "vector"}
  }
  json {
    source => "vector"
    target => "vector"
  }
  mutate {
    remove_field => ["message", "host", "path", "@version"]
  }
}

output {
  elasticsearch {
    hosts => ["https://pc-shin-gpu1:9200"]
    index => "single_vector_test"

    # ここでは検証を簡単化するためにSSLの検証をスキップさせたり、elasticユーザを利用しています。
    # 本番で利用する際は、SSLの設定を適切に行い、API Keyの利用なども検討してください。
    ssl_verification_mode => "none" 
    user => "elastic"
    password => "XXXXX"
  }
  stdout { codec => dots }
}

読み込む対象のデータは single_vector.txt に以下のようなフォーマットで保存されている前提です。

[2,31,0,212,6,.....,23] #1536次元
[83,11,5,0,0,.....,98]
....

Elasticsearch上でのデータ確認

Cat Indices APIで件数を確認してみます。1,000,000件入っていることが確認できます。
(レプリカ数)

# GET _cat/indices/single_vector_test?v

health status index              uuid                   pri rep docs.count docs.deleted store.size pri.store.size dataset.size
green  open   single_vector_test kNg4GFrKSzKrChb8EELNxA   1   0    1000000            0     33.4gb         33.4gb       33.4gb

検索処理

Elastisearchには正確に近傍検索をおこなう kNN と、近似計算で高速に処理をする ANN の２パターンがサポートされています。

kNN

GET single_vector_test/_search
{
  "size": 10,
  "query": {
    "script_score": {
      "query": {
        "match_all": {}
      }, 
      "script": {
        "source": "cosineSimilarity(params.queryVector, 'vector') + 1.0",
        "params": {
          "queryVector": [106, 142, 86, 87,...., 149]
        }
      }
    }
  }
}

500ミリ秒くらいかかっていますね。
(なお、32シャードに分割して同検証を実施すると170ミリ秒程度までは短縮されました)

{
  "took": 501,
  "timed_out": false,
  "_shards": {
    "total": 1,
    "successful": 1,
    "skipped": 0,
    "failed": 0
  },
  "hits": {
    "total": {
      "value": 10000,
      "relation": "gte"
    },
    "max_score": 2,
    "hits": [
      {
        "_index": "single_vector_test",
        "_id": "9D6UdowBpziQa9Jus0xV",
        "_score": 2,
        "_ignored": [
          "event.original.keyword"
        ],
        "_source": {
          "@timestamp": "2023-12-17T07:01:43.527208800Z",
          "log": {
            "file": {
              "path": "//pc-shin-gpu1/share/data/single_vector.txt"
            }
          },
          "vector": [.....]
        }
      }
    ]
  }
}

ANN

一方ANNはこちら。

GET single_vector_test/_search
{
  "knn": {
    "field": "vector",
    "k": 10,
    "num_candidates": 100,
    "query_vector": [....]
  }
}

12ミリ秒と非常に高速に検索できていることがわかります。
ただし、あくまでkNNと違い近似の結果にはなるので、正確に類似度順に取得する必要がある場合は kNNを利用するようにしてください。

{
  "took": 12,
  "timed_out": false,
  "_shards": {
    "total": 1,
    "successful": 1,
    "skipped": 0,
    "failed": 0
  },
  "hits": {
    "total": {
      "value": 10,
      "relation": "eq"
    },
    "max_score": 1,
    "hits": [
       ....
    ]
  }
}

まとめ

1536次元という比較的高次元なベクトルも、ANNを用いることでかなり高速に検索することができました。RAGに利用するという観点で言えば、検索結果の厳密性よりも高速にある程度の精度で類似検索ができるメリットは大きいように思います。
冒頭で触れた通り、キーワード検索とベクトル検索を併用できるElasticsearchはLLMの後ろで使うには非常に便利ですね。

ということで、今回の記事は以上となります。
お読みいただきありがとうございました。

Acroquest Technologyでは、キャリア採用を行っています。

ディープラーニング等を使った自然言語／画像／音声／動画解析の研究開発

Elasticsearch等を使ったデータ収集／分析／可視化

マイクロサービス、DevOps、最新のOSSを利用する開発プロジェクト

書籍・雑誌等の執筆や、社内外での技術の発信・共有によるエンジニアとしての成長

　
少しでも上記に興味を持たれた方は、是非以下のページをご覧ください。
Kaggle Grandmasterと一緒に働きたエンジニアWanted！ - Acroquest Technology株式会社のデータサイエンティストの採用 - Wantedlywww.wantedly.com

2023-12-18

GPT-4Vのモデルを利用してOCRできるか試してみた

ChatGPT 生成AI OCR

こんにちは、安部です。

気温の上下に翻弄されて最近風邪をひいてしまいましたが、皆さま元気にお過ごしでしょうか。

今回は、GPT-4Vのモデルを利用して、OCRができるか試していきます。

GPT-4Vによって、「ChatGPTに目ができた」などと騒がれましたが、文字認識はどれくらいできるのでしょうか？得意分野ではなさそうですが、GPTも進化が目覚ましいので分かりませんね。

検証では、日本語(漢字/ひらがな/カタカナ)・英語の2言語で精度など比較していきます。また、手書き・活字での違いも見ていきましょう。

一番簡単に試せるChatGPT（Web版）でOCRをさせようとするとエラーになることが多かったので、ここではAPIを使っていくこととします。

APIを呼び出すプログラム

以下のコードを使い、gpt-4-vision-previewというモデルを呼び出しています。画像は個人のgithub リポジトリにアップロードしておき、URLをモデルに渡します。余計なことをして欲しくないので、読み取った文章のみを返答するよう指示します。

from openai import OpenAI

def main():
    client = OpenAI(
        api_key= 'API Keyを入れる'
    )

    response = client.chat.completions.create(
        model="gpt-4-vision-preview",
        max_tokens=1024,
        messages=[
            {
                "role": "system",
                "content": "You are an Optical Character Recognition (OCR) machine. You will extract all the characters from the image file in the URL provided by the user, and you will only provide the extracted text in your response. As an OCR machine, You can only respond with the extracted text."
            },
            {
                "role": "user",
                "content": [
                    {"type": "text", "text": "Please extract all characters within the image. Return the only extracted characters."},
                    {
                        "type": "image_url",
                        "image_url": {
                            "url": "画像のURL",
                        },
                    },
                ],
            },
        ]
    )

    print(response.choices[0].message.content)


if __name__ == "__main__":
    main()

それでは、試していきましょう！

英語の活字を認識させる

まずは、一番簡単そうな英語・活字を認識できるか見ていきます。題材は、チューリングの有名論文の最初の1ページです。

読み取り結果は以下の通りです。間違っているところは赤い字にしています（ほとんどありませんが）。

ON COMPUTABLE NUMBERS, WITH AN APPLICATION TO THE ENTSCHEIDUNGSPROBLEM By A. M. TURING.

[Received 28 May, 1936.—Read 12 November, 1936.]

The “computable” numbers may be described briefly as the real numbers whose expressions as a decimal are calculable by finite means. Although the subject of this paper is ostensibly the computable numbers, it is almost equally easy to define and investigate computable functions of an integral variable or a real or computable variable, computable predicates, and so forth. The fundamental problems involved are, however, the same in each case, and I have chosen the computable numbers for explicit treatment as involving the least cumbrous technique. I hope shortly to give an account of the relations of the computable numbers, functions, and so forth to one another. This will include a development of the theory of functions of a real variable expressed in terms of computable numbers. According to my definition, a number is computable if its decimal can be written down by a machine.

In §§ 9, 10 I give some arguments with the intention of showing that the computable numbers include all numbers which could naturally be regarded as computable. In particular, I show that certain large classes of numbers are computable. They include, for instance, the real parts of all algebraic numbers, the real parts of the zeros of the Bessel functions, the numbers π, e, etc. The computable numbers do not, however, include all definable numbers, an example is given of a definable number which is not computable.

Although the class of computable numbers is so great, and in many ways similar to the class of real numbers, it is nevertheless enumerable. In §§ I examine certain arguments which would seem to prove the contrary. By the correct application of one of these arguments, conclusions are reached which are superficially similar to those of Gödel’s. These results

Gödel, “über formal unentscheidbare Satze der Principia Mathematica und verwandter Systeme I,” Monatshefte Math. Phys., 38 (1931), 173-198.

ほぼ、完璧ですね。ウムラウトやセクションマーク(§)、πなどのギリシャ文字も読み取れています。間違っているのは、"§8"が"§§"になっている点と、"Gödel † (ダガー記号)"が"Gödel’s"になっている点くらいでしょうか。

期待通り、英語の活字はかなりの精度で認識してくれました。

英語の手書き文字を認識させる

次に、手書き文字を認識させてみます。あまり長い文章を書くのは大変なので、短い文章ですがご容赦ください。

以下の画像を読み込ませてみます。 "My handwriting is very legible, so you should be able to recognize it."と書いてあります、念のため。

読み取り結果は以下の通りです。

My handwriting's very legible, so you should be able to recognize it.

isが短縮形にされてしまっている点以外、正しく認識されています（グニャグニャの筆記体で書いたら精度が下がるのかもしれませんが）。

日本語の活字を認識させる

では、日本語の認識精度はどうでしょうか？

まずは短い文章を認識させてみましょう。

こちらの画像を読み込ませました。

読み取り結果はこちら。

高齢者がつまずきやすい文字が認識できるかをテストする。

やはり、日本語は難しいようです。漢字だけでなく、ひらがなも読み違えていますね。

「認識」という文字が認識できているのに「大」が認識できないのは何故なんでしょうか...。

念のため、もう少し長い文章も試してみましょう。オー・ヘンリーの有名短編小説「賢者の贈り物」の冒頭部分の日本語版キャプチャを読み込ませます。

読み取り結果はこちら。

1ドル87セント。それで頂点。しかしもそのうちの2セントは小銭でした。
小銭は一回の買い物につき一枚か二枚づつ減り続けたものです。乾物屋や小倉屋や肉屋に無理強打はしませんでので、しまいに、こんなに値打あるんでという無言の押売で満腹分をはぼさせでした。デパは二回数えてみました。でもやっぱ
り1ドル87セント。明日はクリスマスだというのに。

これでは、またくのところ、精神性な小商子に窮しちまいかも試練です。
ですからデパはそうしませんで。そうしているうちに、人生というものは、
わあわあ泣くのと、しくしく泣くのと、微笑みとで済まそうか、しかも、しく
しく泣くのが大部分を占めていると思うようになりました。

かなり認識ミスが多いですね。日本語部分はともかく、"60セント"が"2セント"になってしまうのは想定外でした。

日本語の手書き文字を認識させる

日本語だと活字でも上手く認識されないので、手書き文字だとなおさらダメだと予想が付きますが、一応試してみます。

こちらの画像を読み込ませます。

結果は以下の通り。

記憶から大切なの文字を選びてコピーする e

...確かに、私の"。"は小さな"e"に見えなくもないですね笑。

大変な悪筆という訳でもないと思うので、日本語の認識が難しいということなのでしょう。

まとめ

今回は、GPT-4Vのモデル(gpt-4-vision-preview)を使ってOCRを試してみました。

結論としては、英語であれば手書き・活字ともにかなりの精度でOCRできますが、日本語はまだまだ難しそうでした。

	活字	手書き
英語	〇	〇
日本語	△	×

各クラウドベンダーが出している他のAIモデルなど、選択肢は豊富にあるので適材適所でやっていくのがよさそうですね。

それでは。

Acroquest Technologyでは、キャリア採用を行っています。

ディープラーニング等を使った自然言語／画像／音声／動画解析の研究開発

Elasticsearch等を使ったデータ収集／分析／可視化

マイクロサービス、DevOps、最新のOSSやクラウドサービスを利用する開発プロジェクト

書籍・雑誌等の執筆や、社内外での技術の発信・共有によるエンジニアとしての成長

　少しでも上記に興味を持たれた方は、是非以下のページをご覧ください。 www.wantedly.com

2023-12-13

Amazon Bedrock「Claude2.1」の最大20万トークンで何が変わるか確認してみた

生成AI Bedrock AWS ChatGPT

Amazon Bedrock Advent Calendar 2023 13日、
および Anthropic Claude Advent Calendar 2023 18日の記事です。

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

先日、 Bedrock 上で Claude 2.1 が使えるようになりました。

aws.amazon.com

このモデルは精度が高いことはもちろんですが、 20 万（ 200K ）トークンを一度に扱うことができる という特徴があります。
200K のトークンがあれば、約 15 万単語もしくは 500 ページの本を一度に扱える、と言われています。

とは言いますが、これは実際どれくらいインパクトがあることなのでしょうか？
今回は実際に本の要約タスクをさせてみて、トークンが大きいことの利点を確認します。

1. 扱うデータ
- 1.1. 前処理
2. 実験条件
- 2.1. プロンプト
3. 結果
4. 考察
5. 実装時の注意点
6. まとめ

1. 扱うデータ

今回は題材として、著作権が切れた作品を無料で公開している青空文庫から、スウィフト・ジョナサン『ガリバー旅行記』を選択しました。

物語が有名で多くの人があらすじをすでに知っている、かつ transformers の GPT2Tokenizer を用いてトークン数をカウントしてみたところ、約 162,000 トークンと今回の検証にぴったりの長さでした。

www.aozora.gr.jp

1.1. 前処理

ルビありのテキストファイルをダウンロードしましたが、このままでは読む人やビューワー向けの記述が多いため、これらを削除して、モデルが読みやすい形に変換します。

具体的には下記変換を行いました。

ルビの削除 %s/《(.*?)》//g
注の削除 %s/［(.*?)］//g
冒頭の凡例を削除
「著者から読者へに代えて」以下を削除

2. 実験条件

今回は下記条件で実験を行いました。

#	モデル	一度に要約するトークン数
①	OpenAI gpt-3.5-turbo-16k	約15K
②	Anthropic Claude 2.1	約15K
③	Anthropic Claude 2.1	全文（約162K）

①と②では、下記手順で要約を生成しました。

一行ずつ読み込み累積トークン数を計算する
15K トークンを超えた時点で 1 かたまりとし、モデルに要約文を生成させる
累積を 0 に戻し再び 15K トークン分を取得、モデルに直前の要約文と合わせて、このかたまりの要約文を生成させる
全文を読み込むまで 3. を繰り返す

③は単に 全文をまとめてモデルに入れる だけです。

2.1. プロンプト

分割して要約する①②と全文を一度に要約する③、それぞれに利用したプロンプトを以下に示します。
分割する場合に、ひとつ前の要約を加えている以外は同一の内容になっています。

①②分割して要約

  Task: Identify Significant Events: Based on the provided text, list the significant events in the book in Japanese. These should include major plot points, character developments, and any turning points in the story.
  Goal: The aim is to provide an engaging and informative summary for someone who hasn't read the book, and to recommend the book based on its strengths and appeal.
  Events up to now: {ひとつ前の要約}
  Input: {15Kトークン分の本文}

③全文を一度に要約

  Task: Identify Significant Events: Based on the provided text, list the significant events in the book in Japanese. These should include major plot points, character developments, and any turning points in the story.
  Goal: The aim is to provide an engaging and informative summary for someone who hasn't read the book, and to recommend the book based on its strengths and appeal.
  Input: {本文}

3. 結果

それぞれ最終成果物は下記のようになりました。

① GPT3.5 15K トークン

  Significant Events:
  1. 主人公が船で航海をしている途中、船員たちが海賊であるこ とが明らかになり、船長の私をとじこめる。
  2. 私が船から降ろされ、馬のいる地域にたどり着く。
  3. 私が馬と出会い、馬が私を不思議そうに見つめる。
  4. 馬がもう一匹やってきて、二匹が何かを相談しているように 見える。
  5. 馬が私を呼び止め、私が引き返して馬のそばに行く。       
  6. 馬が私に何かを伝えようとしているように見える。
  7. 私が洋服の秘密を主人に打ち明ける。
  8. 私が戦争や金銭の話を主人に説明する。
  9. 主人がヤーフの争いや好物の話をしてくれる。

  この本は、主人公が不思議な馬たちとの出会いを通じて、異なる文化や社会のあり方について考えさせられる物語です。馬たちの行動や意思疎通の試みなど、読者は彼らとの交流を通じて新たな視点を得ることができます。また、戦争や金銭の問題についても触れられており、人間の欲望や争いの根源について考えさせられます。この本は、異文化交流や社会問題に興味がある読者におすすめです。

② Claude 2.1 15K トークン

  はい、ここまでのガリバー旅行記の主な出来事を要約すると以下のようになります:

  1. ガリバーは海賊に捕らわれ、ある島に放置される
  2. 島で猿のようなヤーフに出会うが、馬に助けられる
  3. 馬とコミュニケーションをとろうとするが言葉が通じない
  4. 馬同士が相談する様子を見て、馬の賢さに驚く
  5. 馬の国の人々はさらに賢いのではないかと考える
  6. 馬に家に連れていかれ、馬の言葉を教えられる
  7. ヤーフと自分を比較される
  8. 馬に自分の身の上を話すが、理解してもらえないこともある
  9. 馬の家で生活し、馬の家族と交流する

  以上が、ガリバーが馬の国を訪れてからの主な出来事です。
  特にガリバーが馬の高い知能に驚き、コミュニケーションをとろうと努力する様子が印象的です。また、馬と人間の違いや人間社会の理解の難しさも描かれています。

③ Claude 2.1 全文

  ガリバー旅行記の重要な出来事を日本語で要約します。
  小人国リリパットでは、ガリバーは小人たちに捕らえられ、展示物のように見世物にされます。その後、小人国と戦争しているブレフスキュ島の艦隊を捕獲し、小人国の英雄となります。      
  次に訪れた大人国ブロブディングナグでは、ガリバーは巨人にとらえられます。彼は巨人の家で飼育され、展示物のように見せびらかされます。
  その後、空中都市ラピュタにたどり着きます。ここでは科学が発達していて、磁石の力で浮遊している島があります。ガリバーは国王に会う機会を得ます。
  最後に、馬の国ホイニームにたどり着きます。ここでは馬が文明化され、人間は野生の動物のように扱われます。ガリバーは人間をヤーフと呼ぶ馬の家族に飼育されますが、人間を特別扱いしていることが問題視され、追放されてしまいます。
  こうしてガリバーは多くの奇妙な世界を旅し、人間社会を相対的な視点から批評する機会を得ます。これは人間性や文明についての風刺として機能しています。

4. 考察

ここでざっくりと『ガリバー旅行記』のポイントを確認しておきましょう。

ガリバーが主に４つの国を訪れる物語である
1. 小人の国リリパット国
2. 巨人の国ブロブディンナグ国
3. 空とぶ島ラピュタ
4. 馬の国フウイヌム国
イギリス人の社会や慣習に対するスウィフトの批判的な風刺がちりばめられている

4.1. トークン数による違い

上のポイントを踏まえて、結果を見てみると、トークン数が小さい①②では、前半部分の国々が抜け落ちてしまっていることが分かります。
反対に一度に全文を入れた③では訪れた 4 つの国すべてが要約に登場しています。

トークン数が大きければ本一冊のように長い文章を渡しても、前半部分を忘れることなく、応答ができていることが分かります。
反対に、トークン数が少ない場合、分割して次々に新しい情報を与えていく過程で、過去分（物語の前半部分）が失われてしまっています。

今までであれば、少ないトークン数の中でいかに過去の情報を残していくかがプロンプトエンジニアの腕の見せ所、となっていたかもしれませんが、トークン数が多ければその必要はなく、初心者でも簡単に精度の高い結果を得られます。

4.2. 実行時間

実行時間は次のようになりました。

#	モデル	トークン数	全体所要時間
①	OpenAI gpt-3.5-turbo-16k	約15K	135秒
②	Anthropic Claude 2.1	約15K	349秒
③	Anthropic Claude 2.1	約162K	163秒

同じモデルを使っている②と③を比べた時に、分割して実行するよりも、まとめて実行したほうが早い、という結果になりました。

サンプル数が 1 つしかありませんが、実行環境とモデル間でのやり取りが複数回発生するオーバーヘッドが所要時間の増大に影響したのではないかと推測しています。

特に今回は東京-オレゴン間で通信を行っているため、往復は少ない方が通信時間は少なく済みそうです。

4.3. 実装時の違い

結果には表れていませんが、実装時に感じた大きな違いは実装の複雑さです。

全文をまとめてモデルに渡す場合、単純に渡すだけで事足ります。
しかし、分割してモデルに渡す場合、下記のような点に留意して実装をする必要があり、面倒でした。

これまでの要約文の与え方
分割単位の決定

段落単位／行単位／単語単位など、分割単位を変えるだけで、精度に影響が出ると考えられます。
適切な分割単位を検討する必要があります。
トークン数管理

本文を許容されるトークン以下に抑えたとしても、直前の要約文やシステムプロンプトにあたる文章などを付与すると、トークンを超過してしまう、ということが起こりえます。
実際にモデルに渡す文章のトークン数が許容トークン内に入るかを確認する必要があります。
レートリミット管理

トークン数の時速やリクエスト数の時速など、さまざまなレートリミットがかかることがあります。
ライブラリを導入するか自前で実装して、適切に処理する必要があります。

それと引き換えに、一度にまとめてモデルに渡す場合、雑に投げ込むだけである程度の結果が出る、というのがいいですね。

5. 実装時の注意点

大きなトークン数を扱うにあたって、一点発生した問題について、紹介します。

『ガリバー旅行記』全文を入力として boto3.client("bedrock-runtime").invoke_model に渡した際、ReadTimeout を超過するエラーが発生しました。

botocore.exceptions.ReadTimeoutError: Read timeout on endpoint URL: "https://bedrock-runtime.us-west-2.amazonaws.com/model/anthropic.claude-v2%3A1/invoke"

client 作成時に、 ReadTimeout までの時間を長くする設定を入れることで解決できました。

client = boto3.client(
    "bedrock-runtime",
    config=Config(read_timeout={十分に大きな値}),
)

6. まとめ

今回は大きなトークンが扱えると、どんな利点があるのか、実際に試してみました。

項目	トークン小	トークン大
長い文章全体を考慮して回答できる	×	○
すべてのトークンを処理する時間が短い	×	○
実装が楽	×	○

使えるトークン数が大きいことは、あるHTMLの構造を分析してもらう、 RAG においてコンテキストサイズについて悩むことなく検索結果を入れられるなど、有用な場面が多そうです。

それにしても、人間が数時間かけて読む本を 160 秒そこらで読んで、要約までしてくれるのは、やっぱりパワーを感じますね。

Acroquest Technologyでは、キャリア採用を行っています。

ディープラーニング等を使った自然言語／画像／音声／動画解析の研究開発

Elasticsearch等を使ったデータ収集／分析／可視化

マイクロサービス、DevOps、最新のOSSやクラウドサービスを利用する開発プロジェクト

書籍・雑誌等の執筆や、社内外での技術の発信・共有によるエンジニアとしての成長

　少しでも上記に興味を持たれた方は、是非以下のページをご覧ください。 www.wantedly.com

2023-12-08

Agents for Amazon Bedrock でEC2インスタンス作成エージェントを作ってみた

生成AI Bedrock

肌寒い日が続き、ついに我が家でも毛布を引っ張り出してきました、菅野です。

AWS re:Inventが開催され、AWSでは、150件以上の新サービスやアップデートの発表がありました。
Amazon Bedrockにも新機能が発表され、実際のシステムにも導入していきたいというかたも増えているのではないでしょうか？

今回のブログではGAになったAgents for Amazon Bedrockを実際に利用し EC2インスタンスを作成するエージェントを作ってみます。

aws.amazon.com

Agents for Amazon Bedrockとは

生成AIのアプリケーション作成を助けるシステムです。
ユーザーは、自然言語を用いてAIアプリで実施したいタスクを入力します。
Agents for Amazon Bedrockは上記のタスクを推論モデルを用いて細分化、複数ステップのタスクに自動で分割し、それぞれの実行結果をまとめ、
最終的なタスクの実行結果をユーザーに返すAIアプリケーションを生成します。

GA版となったAgentsでは、それぞれのステップの詳細にアクセスし、どのような推論の流れになっているのかを確認したりできるようになっています。
また、あらかじめ用意していたLambdaをタスクとして定義してAgentsで生成したアプリから呼び出せるようにしたり、KnowledgeBase（ユーザーが定義できる情報元）へアクセスすることも可能なようです。

実際に使ってみた

それでは、さっそくAgentsを使ってAIアプリを作成してみましょう。
今回はLambaを用いてEC2インスタンスを作成するAIエージェントを作成します。
以下のような構成になります。

Amazon Bedrockのサイドメニューから、Orchestration＞Agentsをクリックします。

Agentsのページが開いたら、Create Agentをクリックします。

Agentの詳細入力

Agentの詳細入力画面が出てくるのでそれぞれ以下の情報を入力しNextをクリックします。

項目	必須	入力内容
Agent name	○	作成するエージェントの名前
Agent description		作成するエージェントの詳細説明
User input	○	初回の入力から情報が足りない場合、エージェントがユーザーから追加の入力を求めるか否かの設定
Agent resource role	○	Agentが利用するAWSのIAM Roleを自動で生成するかあらかじめ作成したIAM Roleを用いるかを選択
KMS key selection		Agentとのやり取りの暗号化に用いるKMS Keyをカスタマイズするか（チェックが空の場合デフォルトKeyが用いられる）
Idle session timeout	○	ユーザーがAgentに入力をしない状態でどれだけセッションを維持するか
Tags		生成されるAWSリソースへのタグ

Agentのモデル情報入力

利用モデルの選択画面が出てくるので、利用するモデルと、Agentに実施してほしいタスクの説明を入力します。利用するモデルは現在以下が選択可能です。

モデルの開発元	モデル名
Anthropic	Claude V1
Anthropic	Claude V2

上記以外にもAmazonが開発している、Amazon Titan Express、Anthropicが開発しているClaude V2.1も将来的に選択できるようになる模様です。

実施してほしいタスクの説明は日本語でも入力可能なようです。
今回はClaude V2を利用し、以下を入力してみました。

あなたはEC2インスタンスを作成するエージェントです。
ユーザーの入力をもとに、EC2インスタンスのインスタンスタイプ、AMIを選択し、EC2インスタンスを作成してください。

アクショングループの追加(Optional)

作成するエージェントが独自のビジネスロジックを利用する必要がある場合（例えば、自身が開発したAPIにアクセスする）にはLambdaを経由して独自のアクションを定義することが可能です。
それぞれ以下の情報を入力します。

項目	必須	入力内容
Enter Action group name	○	作成するアクショングループの名前
Description - Optional		作成するアクショングループの詳細説明
Select Lambda function	○	利用するLambdaFunctionを選択
Select API Schema	○	LambdaFunctionの入出力を定義したOpenAPI形式のymlファイルをS3に配置したものを参照するように設定

Select API Schemaに配置したOpenAPI形式のファイルから、利用するLambdaFunctionのIN,OUTをBedrockが読み取り、適切な入力情報の抽出、アクション実行後の情報取得を行ってくれます。

今回は以下のようなLambda,openapi.yamlを作成し、設定しました。
Lambda

import boto3
import json

def lambda_handler(event, context):
    # Boto3 EC2クライアントの初期化
    ec2 = boto3.client('ec2')
    
    api_path = event["apiPath"]
    response_body = {"application/json": {"body": "api path not found"}}
    status_code = 404
    if api_path == '/create-ec2':
        # パラメータの取得
        param = event['requestBody']['content']['application/json']['properties']
        instance_type = next(item for item in param if item['name'] == 'instance_type')['value']
        ami_id = next(item for item in param if item['name'] == 'ami_id')['value']
        

        # EC2インスタンスの作成
        instances = ec2.run_instances(
            ImageId=ami_id,
            InstanceType=instance_type,
            MinCount=1,
            MaxCount=1
        )
        
        response_body = {"application/json": {"body": json.dumps('Instance Created: ' + str(instances))}}
        status_code = 200
    
    action_response = {
        "actionGroup": event["actionGroup"],
        "apiPath": event["apiPath"],
        "httpMethod": event["httpMethod"],
        "httpStatusCode": status_code,
        "responseBody": response_body,
    }

    api_response = {"messageVersion": "1.0", "response": action_response}
    return api_response

S3に配置するopenapi.ymlは以下のように作成しました。
openapi.yml

openapi: 3.0.0
info:
  title: Create EC2 API
  version: 1.0.0
  description: API for create EC2
paths:
  /create-ec2:
    post:
      summary: API for create EC2.
      description: Create EC2 that posted instance type, ami-id
      operationId: send
      requestBody:
        required: true
        content:
          application/json:
            schema:
              type: object
              properties:
                instance_type:
                  type: string
                  description: Instance Type
                ami_id:
                  type: string
                  description: AMI ID for Instance
              required:
              - instance_type
              - ami_id
      responses:
        '200':
          description: EC2 Creation Success
          content:
            application/json:
              schema:
                type: object
                properties:
                  body:
                    type: string
                    description: Information of Created Instance.

ナレッジベースの追加（Optional）

作成するエージェントが独自定義のナレッジベースを利用する必要がある場合にはこちらで定義を追加することができます。
ナレッジベースはOrchestration＞Knowledge baseから作成することができます。

プレビューとエージェントの作成

すべての情報を入力が完了したら、入力内容のプレビュー画面が出てきます。問題ない場合はCreate Aagentを押下するとエージェントが作成されます。

Lambdaへの実行権限付与

AgentからLambdaを呼び出すための権限設定をLambda側に行う必要があります。
対象のLambdaの設定タブ＞アクセス権限＞リソースベースのポリシーステートメントから、アクセス権限を追加をクリックします。

AWSのサービスをクリックし、必要事項を記入して保存をクリックします。

項目	必須	入力内容
サービス	○	Otherを選択
ポリシーステートメントID	○	ポリシーを一意にするIDを入力
プリンシパル	○	bedrock.amazonaws.comと入力
ソースARN	○	作成したLambdaのARNを選択
アクション	○	lambda:InvokeFunctionを選択

作成したエージェントを試してみる

エージェントが作成されると、エージェント画面へ自動で遷移します。
画面右側にテスト用のチャット欄が出てくるので早速試してみましょう。

入力

"ami-0c0d141edc4f470cc" のAMIをベースに、インスタンスタイプを”t2.micro"として、EC2インスタンスを作成してください。

出力

EC2 instance created successfully with the following details: AMI ID: ami-0c0d141edc4f470cc Instance Type: t2.micro

期待したEC2インスタンスが作成されました。

出力結果のShow Traceを押下すると、具体的にどのような推論がされているのかを閲覧することができます。

以下の部分でユーザーの入力内容からEC2作成Actionを実行することが適切であると推論されています。
また、ユーザーの入力文章からインスタンスタイプと、AMI IDを抽出し、入力として設定しています。

(前略)
  "rationale": {
    "text": "To answer this question, I will:\n\n1. Call the POST::CreateEC2::send function to create an EC2 instance with the provided AMI ID and instance type.\n\nI have double checked and made sure that I have been provided the POST::CreateEC2::send function.",
    "traceId": "a2ea9d5f-5322-408e-9485-ca9bc299640e-0"
  },
  "invocationInput": {
    "actionGroupInvocationInput": {
      "actionGroupName": "CreateEC2",
      "apiPath": "/create-ec2",
      "parameters": [],
      "requestBody": {
        "content": {
          "application/json": [
            {
              "name": "ami_id",
              "type": "string",
              "value": "ami-0c0d141edc4f470cc"
            },
            {
              "name": "instance_type",
              "type": "string",
              "value": "t2.micro"
            }
          ]
        }
      },
      "verb": "post"
    },
    "invocationType": "ACTION_GROUP",
    "traceId": "a2ea9d5f-5322-408e-9485-ca9bc299640e-0"
  },
(後略)

まとめ

生成AIアプリの作成を手助けしてくれる新サービス、Aagent for Amazon Bedrockを実際に試してみました。生成AIアプリを作る際に必要なユーザー入力から特定のタスクの分析、分割等を自動でやってくれる為、生成AIアプリに不慣れな人でも作成が容易な点がよかったです。
また、Lambdaを定義しオリジナルのタスクを作成できる点は拡張性が高いように見えました。
今後も生成AIの可能性を模索していきます。

Acroquest Technologyでは、キャリア採用を行っています。

ディープラーニング等を使った自然言語／画像／音声／動画解析の研究開発

Elasticsearch等を使ったデータ収集／分析／可視化

マイクロサービス、DevOps、最新のOSSやクラウドサービスを利用する開発プロジェクト

書籍・雑誌等の執筆や、社内外での技術の発信・共有によるエンジニアとしての成長

　少しでも上記に興味を持たれた方は、是非以下のページをご覧ください。 www.wantedly.com

2023-11-29

ragasを使ってRAGシステムを定量的に評価する

NLP GPT

皆さんこんにちは。データサイエンティストチームYAMALEXのSsk1029Takashiです。
YAMALEXは Acroquest 社内で発足した、会社の未来の技術を創る、機械学習がメインテーマのデータサイエンスチームです。

Acroquestでは検索とAzure OpenAI Serviceを組み合わせたQAシステムを提供中です。
こういったシステムを運用していく中で課題になるのが精度評価と改善の仕組みです。

今年7月の記事でPrompt Flowを使った回答評価を検証してみましたが、今回はOSSのragasというツールを使って検証してみます。

ragasとは

ragasはRAG（Retrieval Augumented Generation）の仕組みの良し悪しを評価するためにOSSで作成されたライブラリです。
以下のリポジトリがあり、Pythonのライブラリとして使用することができます。
github.com

RAGを運用しているとよくあるのは、システムが誤答を出した場合に何が問題なのか切り分けるポイントが多く手間がかかることです。
誤答を出したとしても、検索結果のコンテキストが悪いのかプロンプトが悪いのかでとるべき対策が変わってきます。
一つの回答について調査するだけならログを見ればわかりますが、システムとして評価するときには全体の傾向を見る必要があります。

そこでragasはLLMを使用したRAGの評価に特化しているため、質問・参照元のコンテキスト・回答をもとにいくつかの指標に分けて回答品質を評価できます。

ragasで使える評価指標

ragasでは標準で以下の4つの評価指標が用意されています。

名前	説明
Faithfulness	コンテキストと回答の一貫性を評価する指標です。回答の中にコンテキストから推測できない情報が含まれているほどスコアが下がります。
Context Precision	質問とコンテキストの関連度をスコアにします。コンテキストの中に質問に関係ない情報が含まれているほどスコアが下がります。
Context Recall	検索結果のコンテキストが期待する回答に対してどれくらいの情報をカバーできるかをスコアにします。この指標を測る場合には、質問に対して期待する回答を事前に定義する必要があります。
Answer Relevancy	質問と回答の関連度をスコアにします。質問に対して関係ないことが回答に含まれているほどスコアが下がります。

使ってみる

今回は以下の記事で使用した例を使ってragasによる評価を試してみましょう。
acro-engineer.hatenablog.com

動作させるのは非常に簡単で、datasetを作成→evaluateで評価を実行するだけです。
注意点としてragasはOpenAIのAPIを使用するため、事前に取得して、OPENAI_API_KEYという環境変数に設定して置く必要があります。

datasetを作成する

from datasets import Dataset

questions = [
    "Azure OpenAI Service上で利用できるGPT-4の最新版のモデルはバージョンは?",
    "Azure OpenAI Service上で利用できるGPT-4の最新版のモデルはバージョンは?",
    "text-embedding-ada-002モデルの次元数は?"
]

contexts = [
    ["Azure OpenAI Serviceで利用できるGPT-4のバージョンは0301, 0631があり、自動でアップデートする設定が使用可能です。"],
    ["Azure OpenAI Serviceで利用できるGPT-4のバージョンは0301, 0631があり、自動でアップデートする設定が使用可能です。"],
    ["text-embedding-ada-002はOpenAIから利用できる文章をベクトル化できるモデルで,1536次元のモデルを出力することが可能です。"]
]

answers = [
    "最新版のモデルのバージョンは0613です",
    "モデルは自動でアップデートする設定が使用可能です",
    "1536です"
]

dataset = Dataset.from_dict(
    {
        "question": questions,
        "answer": answers,
        "contexts": contexts,
    }
)

評価を実行する

評価を実行するにはスコアを出す評価指標を指定して実行するだけです。
評価指標は指定しない場合はFaithfulness、Context Precision、Context Recall、Answer Relevancyの4つが実行されます。
※ただし、今回の検証ではContext Recallに必要な期待する回答はない想定なので、Context Recall以外の3つを指定します。

from ragas import evaluate
from ragas.metrics import answer_relevancy, context_precision, faithfulness

# 評価
result = evaluate(dataset, [answer_relevancy, context_precision, faithfulness])
print(result)

こちらを実行すると以下の結果が得られます。

{'ragas_score': 0.7888, 'answer_relevancy': 0.7673, 'context_relevancy': 1.0000, 'faithfulness': 0.6667}

まずはこれで、全体のスコアは出せました。

ragas_scoreはそれぞれの評価指標での結果の調和平均をとったものになります。

調和平均というのは極端に値にペナルティを与えてスコアを計算する手法になります。
なぜ単純平均ではなくこの手法にしているかというと、一つの軸だけ極端によいという場合に全体のスコアに影響を出さないためです。

例えば評価結果でfaithfulnessが1でcontext_relevancyが0の場合を例にしてみましょう。
この場合コンテキストと回答は非常に一貫性が高いですが、質問とコンテキストが全く関係ないという状況なので、回答の質としては望ましいものではありません。
これを単純平均で計算すると0.5になりますが、調和平均にすると1.0という極端なスコアにペナルティをつけて0.0という結果になります。
このように、上記の指標は全体的に高いことが望ましいので、調和平均を使用しているようです。

また、全体のスコアだけでなく個別のQAについても評価軸ごとに結果を見ることができます。

result.to_pandas()

このようにto_pandas()を呼び出すことでDataFrameとして各QAごとの今回指定した3つの評価結果を得ることができます。
2問目のanswer_relevancyが低くなる想定ですが、結果としては3問目よりも高く出ています。
あくまで質問と回答の関連度なので、3問目が簡潔に回答しすぎなのと、2問目はモデルのバージョンについて言及しているという関連度が見られてスコアが高くなっているようです。

このようにOSSということもあり、評価方法については改善の余地はありそうです。
とはいえ、ローカルでここまで簡単に充実した回答評価を動かせるのはうれしいですね。

まとめ

今回はragasというライブラリを使用してRAGの回答を定量的に評価する仕組みを検証しました。
全面的に信用するというよりも考え方や、部分的に評価指標を利用するのが現実的な使い方になりそうです。
とはいえ、ここまで簡単にできる仕組みがあるのはうれしい部分でした。

それではまた。

Acroquest Technologyでは、キャリア採用を行っています。

ディープラーニング等を使った自然言語／画像／音声／動画解析の研究開発

Elasticsearch等を使ったデータ収集／分析／可視化

マイクロサービス、DevOps、最新のOSSを利用する開発プロジェクト

書籍・雑誌等の執筆や、社内外での技術の発信・共有によるエンジニアとしての成長

少しでも上記に興味を持たれた方は、是非以下のページをご覧ください。
www.wantedly.com

2023-11-24

AWSで生成AIアプリの開発が可能な『PartyRock』でポエムアプリを作ってみた

生成AI Bedrock

こんにちは、先日千葉に遊びにいったらアクアライン通行止めで東京湾迂回する羽目になった菅野です。

ChatGPTにて手軽にアプリケーションを自動で生成できるGPTsが世の中では大きな反響を呼んでいます。
プログラミングレスでChatGPTを利用するアプリを生成できるので、プログラマー以外の人がどんどん生成AIを利用するような流れが出来つつありますね。

さて、そのような流れにのってAmazonBedrockを利用してアプリを生成、共有するサービス、PartyRockがAWSからリリースされました。早速利用してみましょう。

https://partyrock.aws/partyrock.aws

PartyRockの始め方

アカウントの作成

PartyRockはAWSが提供するサービスではありますが、AWSアカウントとは別のアカウントを作成する必要があります。
PartyRockのサイトにアクセスし、Sign inボタンを押下するか、Build your own appを選択し、生成したいアプリの条件を入力後にアカウント作成ダイアログが表示されます。現時点ではGoogle, apple, amazonのアカウントを利用してのサインインのみ対応している模様です。

全体的にDJ、パーティーをテーマにしたポップなサイトデザインになっており、エンジニア以外の人でも手軽に利用してほしいというAWS側の意図を感じますね。

PartyRockにかかる料金

現時点では、PartyRockは無料トライアル中のためアカウント作成のみで無償で利用することができます。
将来的には有償化すると思われますので、様々なアプリを試しに作ってみるなら今のうちにやってみるのがよさそうです。

実際にPartyRockでアプリを生成してみた。

それでは実際にPartyRockでのアプリ生成を試してみましょう。

Build your own appを押下すると、アプリケーション生成ダイアログが表示されるので、そこに作りたいアプリの説明を入力します。
PartyRockのFAQでは、英語のみ対応となっておりますが、一応日本語で入力してもアプリは生成されるみたいです。
ただし、生成されるアプリは英語で説明されます。

生成したいアプリの内容を入力、Generate appを押下し、しばらくたつとアプリケーションが生成され、以下のような画面が表示されます。

赤枠で囲んだウィジェットがアプリの入力欄、今回のアプリでは作成したいポエムのテーマを入力する欄です。
そしてその下部にある黄緑色のヘッダのウィジェットがそれぞれポエムと挿絵を生成する出力欄になります。

試しに「紅葉」をテーマにポエムと挿絵を生成してもらいましょう。

以下のようなポエムと、挿絵が生成されました。

木々は色づき始めた 葉っぱの色はくれないに変わる 赤と橙と気が混ざり合い 美しい光景が広がる 小川だって紅葉を映す 風で葉は舞い落ちた 立ち木の上は色づき終えた 新芽が地面に散らばる  
年を経た木々は決別の時 自然の楽しみを見せてくれた 来る春を待ちわびる心に 紅葉が残した思い出

PartyRockのアプリを編集

それぞれのウィジェットは個別に編集することが可能です。

右上に表示されているスライダーアイコンをクリックすることで、編集内容が表示されます。
それぞれのウィジェットでは以下の項目を編集できます。

入力ウィジェット

タイトル、プレースホルダー、初期入力値等を設定できます。
固定文字ウィジェット

タイトル、文章を設定できます。
テキスト生成ウィジェット

タイトル、テキスト生成モデル、プロンプト、モデルへのパラメータを設定できます。
利用できるモデルは、Claude, Claude Instant, Jurassic-2 Mid, Jurassic-2 Ultra, Commandが選択できる模様です。
プロンプト内で＠を入力すると、それぞれのウィジェットの参照が選択できます。
画像生成ウィジェット

タイトル、プロンプトを設定できます。
テキスト生成とは異なりモデルの指定はできない模様です。Bedrockがバックグラウンドで動作していることを考えると、Stable Diffusionが動いているものと推察されます。

今回のアプリでは生成されませんでしたが、ChatBotを利用するウィジェットも存在します。

ChatBotウィジェット

タイトル、プレースホルダー、テキスト生成モデル、初期表示メッセージ、プロンプト、モデルへのパラメータを設定できます。

これらのウィジェットは自由に追加、削除できます。
追加する際には、上部のAdd Widgetボタンから、削除はそれぞれのウィジェットの編集メニュー下部のDelete Widgetから実行できます。

また、それぞれのウィジェットはドラッグでの移動や、サイズの変更も可能です。

作成したアプリの公開

アプリ作成時点ではPrivateに設定されていますが、作成したアプリはPublicに設定して公開することも可能です。
画面上部のMake public and Shareから公開できます。

今回作成してみたポエム生成アプリも公開したので以下のURLから試してみてください。

https://partyrock.aws/u/Ashihito/g4tODbku5/Poetry-and-Illustration-Creator

まとめ

AWSが提供する生成AIアプリを作成、公開するサービスPartyRockの紹介をしました。
AmazonBedrockがバックグラウンドで動作しているので、様々なモデルを利用できるのがGPTsとの差分になるように思います。
いずれにせよAIを活用するアプリをエンジニア以外の人が手軽に作成できる世の中になってきており、今後の動向もますます目が離せません。
それでは。

Acroquest Technologyでは、キャリア採用を行っています。

ディープラーニング等を使った自然言語／画像／音声／動画解析の研究開発

Elasticsearch等を使ったデータ収集／分析／可視化

マイクロサービス、DevOps、最新のOSSやクラウドサービスを利用する開発プロジェクト

書籍・雑誌等の執筆や、社内外での技術の発信・共有によるエンジニアとしての成長

　少しでも上記に興味を持たれた方は、是非以下のページをご覧ください。 www.wantedly.com