背景
毎日S3へ出力されるCSVファイルが存在しており、このCSVファイルが出力されるS3を
Bedrockのナレッジベース機能を用いたRAG構成に組み込む基盤を構成してみました。
ただ、ナレッジベースでの回答の精度が良くないのですが
プレイグラウンドのチャットで同じことをやると回答の精度がよく
「何が要因でこうなったんだろう？(・・?」となりました。
自分が強くなるためにもこの事象についてできる限り追っていきます！
※ この記事は今後も「お、これは？」みたいなことがあり次第追記していきます。
※ こういうのも気にしないといけないよっていうがあれば、教えてもらえると嬉しいです・・・
仮説
Bedrockのナレッジベースでデータを管理するときについて回るのが、Bedrockのチャンクという概念。
「このチャンクが原因でうまいこと回ってないのかな？」という仮説のもと切り分けを実施していきます。
仮説の調査手順
- チャンクとは？
- 取り込んでいたCSVファイルのトークン数
- ナレッジベースの動作状況
- プレイグラウンドの動作状況
1. チャンクとは？
チャンクの概要
「チャンク」とは、長いテキストやデータを小さな部分に分割したものです。
AWS Bedrockでは、大規模言語モデル(LLM)を活用してテキストの生成や解析を行いますが
モデルに渡すテキストにはサイズ制限があります。
このため、長文テキストを一定サイズの「チャンク」に分割し、それぞれのチャンクを順番に処理することで
大きなデータを効率的に扱うことができます。
例 (デフォルトのチャンキング戦略の場合)
Bedrock->ナレッジベースのデフォルトだと、「コンテンツを約 300 トークンのテキストチャンクに分割します。」
なので、ファイルを取り込んでからチャンクに分かれる部分を簡単に流れにすると
1. ファイル内の単語をトークンに変換
まず、文章は「トークン」というモデルが扱いやすい最小単位に分解されます。
トークンは単語全体やその一部、記号、スペースなどを含みます。
例えば、 Hello, world! という文章では、次のようにトークンに分けられることがあります。
・Hello
・,
・world
・!
2. 300トークンごとにチャンクに分割
次にBedrockのデフォルトのチャンキング戦略に合わせて
300トークンごとにチャンクを分けられていきます。
・チャンク1：最初の300トークン
・チャンク2：次の300トークン
・チャンク3：さらに次の300トークン そして、モデルはこれらのチャンクを順番に処理します。
3. 分割されたチャンクをベースにプロンプトへの回答
ナレッジベースのプロンプトに対して、使用できるチャンク数の最大値は100※1のためトークン数から考えると
100チャンク * 300トークン ＝ 約 30,000トークン
までのデータを取り込むことができる。
※1 チャンク数：最大値100について
2. 取り込んでいたCSVファイルのトークン数の確認
1日ごとに出力されるCSVファイルのトークン数をプレイグラウンドのチャットから確認してみると
約6,000トークンとなっていました。
→ 30,000トークンを超えてないので、サイズ制限としては問題なさそう。
3. ナレッジベースの動作状況
取り込んでいるデータ
(本当はもっとパラメータがあるんだけど、、一部抜粋という形で・・・)
| date_time | kwh |
|---|---|
| 2024/7/4 0:00 | 4.23992153 |
| 2024/7/4 0:30 | 6.07793782 |
| 2024/7/4 1:00 | 4.13306959 |
| 2024/7/4 1:30 | 4.24383129 |
| 2024/7/4 2:00 | 5.61762668 |
| 2024/7/4 2:30 | 7.13040468 |
| 2024/7/4 3:00 | 9.83573366 |
| 2024/7/4 3:30 | 5.92425413 |
| 2024/7/4 4:00 | 7.3881092 |
| 2024/7/4 4:30 | 0.99035554 |
| 2024/7/4 5:00 | 5.34351108 |
| 2024/7/4 5:30 | 6.8129601 |
| 2024/7/4 6:00 | 4.18388524 |
| 2024/7/4 6:30 | 2.98659963 |
| 2024/7/4 7:00 | 4.07226817 |
| 2024/7/4 7:30 | 0.55798515 |
| 2024/7/4 8:00 | 1.61170613 |
| 2024/7/4 8:30 | 7.21570604 |
| 2024/7/4 9:00 | 0.27187834 |
| 2024/7/4 9:30 | 5.44111139 |
| 2024/7/4 10:00 | 8.78746133 |
| 2024/7/4 10:30 | 8.95257094 |
| 2024/7/4 11:00 | 2.73453833 |
| 2024/7/4 11:30 | 9.54063288 |
| 2024/7/4 12:00 | 5.9262798 |
| 2024/7/4 12:30 | 3.61400972 |
| 2024/7/4 13:00 | 4.35717403 |
| 2024/7/4 13:30 | 5.67327082 |
| 2024/7/4 14:00 | 7.21628701 |
| 2024/7/4 14:30 | 3.51467464 |
| 2024/7/4 15:00 | 9.21620069 |
| 2024/7/4 15:30 | 6.93050951 |
| 2024/7/4 16:00 | 9.32553859 |
| 2024/7/4 16:30 | 8.89687991 |
| 2024/7/4 17:00 | 1.78286054 |
| 2024/7/4 17:30 | 7.10866202 |
| 2024/7/4 18:00 | 2.64673635 |
| 2024/7/4 18:30 | 5.73214406 |
| 2024/7/4 19:00 | 0.62799027 |
| 2024/7/4 19:30 | 4.75405802 |
ナレッジベースの結果
- モデル: Claude 3.5 Sonnet v1
- 埋め込みモデル: Embed Multilingualv3
- システムプロンプトはなしで、下記のユーザープロンプトのみとしています。
◆ユーザープロンプト
kwhが一番高い日時教えて
◆回答
提供された情報からは、kWhが一番高い日時を正確に特定することはできません。データには複数の日時のエントリーがありますが、kWhの値が明示的に示されていないため、最高値を判断することができません。データには様々な数値が含まれていますが、それらがkWhを表しているかどうかは不明です。
4. プレイグラウンドの動作状況
◆ユーザープロンプト
kwhが一番高い日時教えて
◆回答
データを確認したところ、kwhが最も高い値を示しているのは2024-07-04 03:00:00で、値は9.835733658651034です。
※ 日時とkwhも合ってる
5. まとめ
プレイグラウンドでうまくいって、ナレッジベースだとうまくいかなかったことを踏まえると
チャンクに分割するときにうまいこと分割してくれず、回答もあまりいい感じにしてくれなさそう。
CSVのような構造化データはナレッジベースにはあまり向かず
CSVデータを用いた生成AI基盤は、プレイグラウンド(Converse API/ConverseStream API)で処理したほうがいいのかな？という感覚でおります。