Amazon Bedrockのオプトアウト方法
結論：
Amazon Bedrockは、プロンプトをいかなるAWSモデルのトレーニングやサードパーティに配布したりするために使用しません。
また、サービスログにデータを保存したり記録したりもしません。
以下、ユーザーガイド p130(Data protection in Amazon Bedrock)から引用
Amazon Bedrock doesn't use your prompts and continuations to train any AWS models or distribute them to third parties. Your training data isn't used to train the base Amazon Titan models or distributed to third parties. Other usage data, such as usage timestamps, logged account IDs, and other information logged by the service, is also not used to train the models.
Amazon Bedrock uses the fine tuning data you provide only for fine tuning an Amazon Titan model.Amazon Bedrock doesn't use fine tuning data for any other purpose, such as training base foundationmodels.
Each model provider has an escrow account that they upload their models to. The Amazon Bedrockinference account has permissions to call these models, but the escrow accounts themselves don't haveoutbound permissions to Amazon Bedrock accounts. Additionally, model providers don't have access toAmazon Bedrock logs or access to customer prompts and continuations.
Amazon Bedrock doesn’t store or log your data in its service logs.
(日本語訳)
・Amazon Bedrock は、AWS モデルをトレーニングしたり、サードパーティに配布したりするためにプロンプトを使用しません。
・トレーニング データは、Amazon Titan基盤モデルのトレーニングに使用されたり、サードパーティに配布されたりすることはありません。
・使用状況のタイムスタンプ、記録されたアカウント ID、サービスによって記録されたその他の情報などの他の使用状況データも、モデルのトレーニングには使用されません。
・Amazon Bedrock は、提供されたファインチューニングデータを Amazon Titan モデルのファインチューニングにのみ使用します。Amazon Bedrock は、基盤モデルのトレーニングなど、他の目的にファインチューニングデータを使用しません。
・各モデルプロバイダーには、モデルをアップロードするエスクローアカウントを持っています。 Amazon Bedrockinference アカウントにはこれらのモデルを呼び出す権限がありますが、エスクロー アカウント自体には Amazon Bedrock アカウントへのアウトバウンド権限(アクセス権限?)がありません。 さらに、モデルプロバイダーは Amazon Bedrock ログにアクセスしたり、顧客のプロンプトや継続にアクセスしたりすることはできません。
・Amazon Bedrock は、サービス ログにデータを保存したり記録したりしません。
以上。
最急降下法と勾配降下法の違いは？
最急降下法（Gradient Descent）と勾配降下法（Gradient Descent）は、一般的には同じアルゴリズムを指す場合が多いです。しかし、厳密に言えば、「最急降下法」は特にバッチ勾配降下法（Batch Gradient Descent）を指すことが多く、「勾配降下法」はその派生として、確率的勾配降下法（Stochastic Gradient Descent, SGD）やミニバッチ勾配降下法（Mini-batch Gradient Descent）などの変種を含むことがあります。
最急降下法と勾配降下法の主な違い
バッチサイズの違い:
最急降下法: 訓練データセット全体を一度に使用して、目標関数の勾配を計算します。これにより、確実な収束が期待できますが、計算コストが高いことがあります。
勾配降下法: 訓練データを一つずつサンプルとして処理する確率的勾配降下法（SGD）や、少数のデータ点（ミニバッチ）を使うミニバッチ勾配降下法など、より小さなバッチサイズを使用することが一般的です。これにより、計算効率が向上し、局所最小値から抜け出す可能性が高まります。
更新の頻度の違い:
最急降下法: バッチ勾配降下法は、訓練データセット全体に対する勾配を計算し、一度の更新でパラメータを更新します。
勾配降下法: SGDやミニバッチ勾配降下法では、各データ点またはミニバッチごとにパラメータを更新します。そのため、更新の頻度が高くなります。
収束の速さの違い:
最急降下法：バッチサイズが大きい場合、収束が遅くなることがありますが、収束がより滑らかです。
勾配降下法：更新が頻繁でノイズが多いため、収束が速い反面、収束先が局所最小値から離れる可能性が高いです。 どちらの方法が最適かは、特定の問題やデータに依存します。大規模なデータセットや高次元のパラメータ空間では、ミニバッチ勾配降下法が一般的に使われ、計算効率が向上します。ただし、適切な学習率の設定や収束の制御が重要です。選択肢には、学習率のスケジューリングやモメンタムなどの手法も含まれます。
参考）勾配降下法の直観的な説明
あなた目隠しをしながら山を登っていて、山の頂上に行くのが目標です。でも、山の中にはたくさんの坂道があります。あなたは一歩一歩登っているとします。登る途中で、どの方向に進むべきかを知る必要があります。ここで、山を登るためのヒントを得るのが「勾配」です。
勾配は、あなたがいる場所から、山のどの方向が一番急な坂道かを教えてくれるものです。つまり、勾配は「上り坂」の方向を指し示しています。あなたはその方向に進むことで、山の頂上に近づくことができます。
勾配降下法はこの考え方を使います。AIモデルを訓練する際、「山」のような目標関数を最小化したいと考えます。現在の場所（モデルのパラメータ）から、どの方向が目標関数を最も減少させるかを勾配（上り坂の方向）から学びます。
人間であれば足元の感覚で勾配がわかりますが、AIには足がないのでわかりません。そこで、AIは代わりに「微分」というテクニックを使います。
以上をまとめると、
- 現在の場所（パラメータ）を確認します。
- 勾配（上り坂の方向）を計算します。足の代わりに微分を使います。
- 勾配の方向に一歩進みます。歩幅は「学習率」と呼ばれます。
AIはこのステップを繰り返し、目標関数を最小化するために一歩ずつ進んで学習していきます。勾配降下法は、山登りのように、最小値を見つけるために次第に良い方向に進んでいく方法です。
S3→Lambda関数を呼び出すダミーイベントJSONの書き方
以下、AWS公式のドキュメントから引用
Lambda コンソールページで関数の [コード] タブを選択します。
[コードソース] ペインで、[テスト] を選択します。
[テストイベントの設定] ボックスで、以下の操作を行います。
[イベント名] で、MyTestEvent と入力します。
[テンプレート] で、[S3 Put] を選択します。
Event JSONで、以下の値を置き換えます。
・us-east-1 をAmazon S3 バケットを作成したリージョンに置き換えます。
・example-bucket の両方のインスタンスをお使いの Amazon S3 バケットの名前に置き換えます。
・test%2FKey を前にバケットにアップロードしたテストオブジェクトの名前 (例えば、HappyFace.jpg) に置き換えます。
備考：
・principalIdは適当な値でOK.
・テストオブジェクトの名前は以前にアップロードしたことのあるオブジェクトでなければエラーになる
Dataflow(GCP)を最短距離で理解する
データ分析基盤勉強中。知識共有用。間違えている箇所あったら、そっとご指摘ください。
Dataflowとは？
Apache Beam(以下Beam)で記述されたデータ処理パイプラインを実行できる、Google Cloudのサーバーレスの分散処理サービスのこと。
Beamとはパイプライン作成に特化したプログラミングモデルで、バッチ処理とストリーミング処理を同じ書き方で記述できるのが特徴。2023年4月時点でPython、Java、Goのいずれかの言語で扱うことができる。
パイプラインというのは、データソースからデータを抽出し(Extract)、加工し(Transform)、データベースに保管する(Load)、いわゆるETL処理の一連の流れを指す。
具体的に何ができるの？
Cloud Strage等に保存されているJSON, CSV, AVROファイルや、PubSubから流れて来るストリーミングメッセージを好きな形に変換したり集計して、BigQuery等のデータウェアハウスや別のストレージに保存できる
Dataflowは何が凄いのか？
・Googleのインフラストラクチャを使用できるので、大規模なデータの分散処理が可能
・Googleによるフルマネージドサービスなので、環境構築やリソースの準備、ジョブの負荷に応じた拡張などの面倒くさい作業が不要
・バッチ処理（データの一括処理)とストリーミング処理(データのリアルタイム処理)の両方に対応してる
・Google提供のパイプラインテンプレートが既に数多く用意されている
・JavaやPython,Goを知らない非エンジニアでも、SQLで複雑なパイプラインが作成できる
・他のGCPサービス(BigQueryやCloud Strageなど)との連携が簡単にできる
他にも色々あります。詳細は公式ドキュメントをご覧ください
とりあえず使ってみる
一番手っ取り早く試せるのはおそらく公式ドキュメント内の以下チュートリアル。指示に従いぽちぽちボタンを押すだけで、文書内の出現単語数を調べるパイプラインを15分程度で作成できます。
または、GCPコンソールからDataflowを選び、ワークベンチからApache BeamがあらかじめインストールされているNotobookを開いて、作成したパイプラインを視覚的に確かめながら自由にプログラミングを試すこともできます。
https://console.cloud.google.com/dataflow/workbench/
テンプレートからDataflowを実行してみる
上でご紹介したチュートリアルはデータ数が有限のバッチ処理のパイプラインでしたが、無制限に流れてくるデータをストリーミング処理するチュートリアルも用意されています。
以下ではニューヨーク市のタクシー乗車記録を提供しているPubSubトピックからデータをリアルタイムで取得し、Google提供のDataflowテンプレートの一つ(PubSub topics to BigQuery)を使用してBigQueryにデータを保存できます。こちらも15分程度で簡単にDataflowによるストリーミング処理が体験できます。
パイプラインを独自カスタマイズする
前述したようにDataflowではGoogle提供のテンプレートが用意されているため、Cloudコンソールから簡単にパイプラインを使用できますが、独自の複雑な処理を加えたい場合、基本的にBeam(Python,Java,Go)でのコーディングが必要になってきます。以下はその際に必要になってくる言葉の説明です。
Pipeline(パイプライン):
データの読み取り、変換、データの書き込みの一連の作業が行われる場所。
Runner(ランナー)
Beamで記述したパイプラインの実行環境。パイプライン作成時にOptionで指定する。Dataflowのほか、Apache Spark、MapReduce、Flink、またテスト用にローカルコンピュータも指定できる。
PCollection(ピーコレクション):
パイプラインを通ることができるデータセット。PCollection内の各データを要素(element)と呼ぶ。各要素はパイプラインの中では不変(immutable)で、並列(parallel)に処理が実行される。
PTransform(ピートランスフォーム):
パイプライン内のデータ変換処理。PCollectionを入力として受け取り、指定の変換処理を行い、(新しく)PCollectionを作成する。(入力した元々のPCollectionの変更は行われないことに注意)
主なPTransformには以下の6種類がある。
・GroupByKey
キーと値がペアになったPCollectionを受け取り、キーごとに値をグルーピングする
例： cat, 1 dog, 3 cat, 2 ↓ cat, [1,2] dog, [3]
・CoGroupByKey
同じキータイプを持つ2つ以上のPCollectionのリレーショナル結合。以下例を見るとわかりやすい
例：
emails_list = [
('amy', 'amy@example.com'),
('carl', 'carl@example.com'),
('carl', 'carl@email.com'),
]
phones_list = [
('amy', '111-222-3333'),
('james', '222-333-4444'),
('amy', '333-444-5555')
]
↓
results = [
(
'amy',
{
'emails': ['amy@example.com'],
'phones': ['111-222-3333', '333-444-5555']
}
),
(
'carl',
{
'emails': ['carl@example.com', 'carl@email.com],
'phones': []
}
),
(
'james',
{
'emails': [],
'phones': ['222-333-4444']
}
)
]
・Combine
PCollectionの要素の結合に用いられる。 PCollection全体を結合するもの(CombineGlobally)と、Key,Valueを含むPCollectionの同じKeyの値を結合する(CombinePerKey)の2種類がある。 結合方法を定義した関数を渡す必要がある。
# CombineGlobally例 (sum()関数で結合する)：
input = [1,2,3]
↓
output = [6]
# CombinePerKey例 (lambda x : ','.join(x) で結合する)：
input =[('cat', 'tama'), ('dog', 'snoopy'), ('cat', 'doraemon')]
↓
output = [('cat', 'tama,doraemon'), ('dog','snoopy')]
・Flatten
複数のPCollectionを一つのPCollectionに統合する。
#例 pcoll1 = [1,2,3] pcoll2 = [4,5] ↓ flattened = [1,2,3,4,5]
ParDo (パードゥー. 並列[Parallel] + 処理[Do])
DoFn(後述)を継承したサブクラスを呼び出し、PCollectionの各要素に並列処理を行う(並列ではなく個別に処理する場合もある)。
DoFn (ドゥーエフエヌ) 並列処理の関数を定義するクラス。ParDoで呼び出される。DoFnを継承したサブクラスのprocessメソッド内にユーザー定義の処理を記載する。
ParDo具体例(PCollectionの各要素の文字数を返却する処理)
# The input PCollection of Strings.
words = ['hello', 'thank you', 'good bye']
# The DoFn to perform on each element in the input PCollection.
class ComputeWordLengthFn(beam.DoFn):
def process(self, element):
return [len(element)]
# Apply a ParDo to the PCollection "words" to compute lengths for each word.
word_lengths = words | beam.ParDo(ComputeWordLengthFn())
・Partition
一つのPCollectionを複数のPCollectionに分割する
詳細な説明はBeam公式プログラミングガイド参照
Beamでのパイプライン作成の流れは５ステップ
- パイプラインを作成する
- 入力データ(例えばCloud Strage)から最初のPCollectiomを作成する
- 変換処理(PTransform)を上記PCollectionに適用する
- PCollectionを外部ソース(例えばBigQuery)に出力する
- パイプラインを実行する
簡単なバッチ処理コード例 (ファイルを読み込み、文章をピリオドで区切る処理を行い、別ファイルに出力するパイプライン)
import apache_beam as beam
from apache_beam.io.textio import ReadFromText, WriteToText
input_path = "input/example.txt"
output_path = "output/example"
# 1. パイプラインの作成
p = beam.Pipeline()
# 2. 入力データを読み込みPCollectionを作成する
texts = p | "Read file" >> ReadFromText(input_path)
'''ファイル内文章:
Lorem ipsum dolor sit amet. Consectetur adipiscing elit. Sed eu velit nec sem vulputate loborti
In lobortis augue vitae sagittis molestie. Mauris volutpat tortor non purus elementum
Ut blandit massa et risus sollicitudin auctor
'''
# 3. PTransform (テキストをピリオド区切りで分割する処理)
lines = texts | "Split" >> FlatMap(lambda x: x.split(". "))
# 4. 変換したデータをファイルに出力
write = lines | "Write" >> WriteToText(file_path_prefix=output_path, file_name_suffix=".txt")
# 5. パイプライン(上記処理)の実行
p.run()
'''出力されたファイル内
Lorem ipsum dolor sit amet
Consectetur adipiscing elit
Sed eu velit nec sem vulputate loborti
In lobortis augue vitae sagittis molestie
Mauris volutpat tortor non purus elementum
Ut blandit massa et risus sollicitudin auctor
'''
上記はバッチ処理（データが有限）のパイプラインでしたが、データが無制限に増えていくストリーミングデータを処理する場合にはさらにいくつかの概念の理解が必要。
タイムスタンプ
最初にPCollectionを作成する際に各要素に割り当てられる。ストリーミングデータからPCollectionを作成する場合、データが時間順にパイプラインに送られてくるとは限らないので、データが処理される時刻ではなくデータイベントが発生した時刻(例：ツイートのつぶやかれた時刻)がタイムスタンプに使われる。
ファイルから入力データ(イベント時刻付き)を読み込む場合、タイムスタンプがそのイベント時刻に自動では設定されないので、TimestampedValueやPardoメソッド(* )を使用して手動で設定する(以下例)
'''入力データ例
[
{"user": "john", "product": "Laptop", "time": 1581870000}, #16:20 UTC
{"user": "rebecca", "product": "Videogame", "time": 1581870180}, #16:23 UTC
]
'''
# TimestampedValueで設定する
timestamped_items = items | 'PutTimestamp' >> Map(lambda x: window.TimestampedValue(x, x["time"]))
# Pardoで設定する
class AddTimestampDoFn(beam.DoFn):
def process(self, element):
# Extract the numeric Unix seconds-since-epoch timestamp to be
# associated with the current log entry.
unix_timestamp = extract_timestamp_from_log_entry(element)
# Wrap and emit the current entry and new timestamp in a
# TimestampedValue.
yield beam.window.TimestampedValue(element, unix_timestamp)
timestamped_items = items | 'PutTimestamp' >> beam.ParDo(AddTimestampDoFn())
- ParDo:一般的な並列処理のためのBeam変換.
ウィンドウ処理
タイムスタンプ(上記)に従ってPCollectionを細分化する処理。ウィンドウには以下の３種類があり、どのような集計処理(PTransform)をしたいのかの要件によって使い分ける。
- 固定時間ウィンドウ
- スライディングタイムウィンドウ
- セッション単位ウィンドウ
ざっくり説明すると、
- ウィンドウを指定した時間枠(1時間等)で区切る
- ウィンドウを指定した時間枠で区切るが、各ウィンドウは重なってもよい
- ウィンドウを最小ギャップ時間(ウィンドウ間の間隔)で区切る。各Key(例：ユーザー)ごとに設定できる。
(各ウィンドウの視覚的・詳細な説明はBeam公式ドキュメントにあるのでご覧ください)
具体的には、あるゲームの全プレイヤーの名前、スコア、プレイした時刻の一覧がある場合、
- を使用する要件例：毎時のプレイヤーごとの合計スコアを知りたい
- を使用する要件例：過去1時間の全プレイヤーの平均スコアが20分ごとに欲しい
- を使用する要件例：1日1時間しか続けてプレイできない場合で、各プレイヤーごとの合計スコアを知りたい
のように使い分けます。
適切なタイムスタンプが設定されているPCollectionにウィンドウを設定するにはWindowInto関数を使用します。
# 固定時間ウィンドウ(10分のウィンドウ) fixed = pcoll | "FixedWindow" >> WindowInto(window.FixedWindows(600)) # スライディングタイムウィンドウ(10分のウィンドウを5分間隔で) sliding = pcoll | "SlidingWindow" >> WindowInto(window.SlidingWindows(600, period=300))
ウォーターマーク
ウィンドウにあるすべてのデータがパイプラインに到着すると予想される時間。Dataflowが自動で計算、保持するのでユーザーは変更できない。ウォーターマークがウィンドウの終わりを過ぎると、その後到着したデータはすべて遅延データとみなされる。遅延データはデフォルトで破棄されるが利用するように設定することもできる。
トリガー
トリガーは集計結果をいつ出力するかを決定する。バッチ処理データの場合、すべての入力が処理された後に結果が出力される。ストリーミングデータの場合、ウォーターマークがウィンドウの境界を通過するときに結果が出力される。
DataflowSQLでパイプラインを記述する
またDataflowでは、Python等の言語を書けない非エンジニアでもSQLで複雑なパイプライン処理が実行できます。
例えば以下のSQLをコンソールから実行することで、ニューヨーク市のタクシー乗車データをリアルタイム配信するPub/Subトピックから、1 分ごとに総乗客数をカウントする(固定時間ウィンドウ)集計処理が実施できます。
SELECT DATETIME(tr.window_start) AS starttime, SUM(tr.passenger_count) AS pickup_count FROM TUMBLE ((SELECT * FROM pubsub.topic.`pubsub-public-data`.`taxirides-realtime`), DESCRIPTOR(event_timestamp), 'INTERVAL 1 MINUTE') AS tr WHERE tr.ride_status = "pickup" GROUP BY DATETIME(tr.window_start)
DataflowSQLの書き方については以下に詳しく書かれていますので、興味がある方は参照してください。
MeCab IPA辞書のcsvファイル概要
MeCab用のIPA辞書に登録されている単語数は392126個(活用含む)です。
各単語は.csvファイルに(表層形,左文脈ID,右文脈ID,生起コスト,品詞,品詞細分類...)の形で1行ずつ記載されています。
各csvファイル(全26)の中身は以下。
参照
MeCab: Yet Another Part-of-Speech and Morphological Analyzer
Postgresqlのログ出力先(Ubuntu)
Ubuntuですが探すのに時間かかったのでメモ。
・Postgresqlのログの場所
/var/log/postgresql/postgresql-(version)-main.log
・設定ファイル（pg_hba.conf、postgresql.conf等）の場所
/etc/postgresql/(version)/main/
ちなみに設定ファイルの記述間違いはログを見ると以下のように出力されます。
FATAL : configuration file "/etc/postgresql/(version)/main/postgresql.conf" contains errors
チューニングのヒントもそっと教えてくれます。
HINT: Consider increasing the configuration parameter "max_wal_size".
Djangoアプリをcloneしてサーバーで動かす
目的：あるサーバーで動いているDjangoアプリ(githubのプライベートレポジトリに存在)を別のサーバーに移転して動かしたい
前提：
webサーバー: Nginx
アプリケーションサーバー: Gunicorn
手順：
２．sshのconfig設定
~/.ssh直下にconfigファイル作成(無ければ),以下記載
Host github
HostName github.com
User git
IdentityFile (秘密鍵のパス)
３．クローンする
git clone github:ユーザー名/レポジトリ名.git
(備考：configでgithub = git@github.comと指定しているため、公式記載のgit@github.com:ユーザー名/レポジトリ名.git ではPermission errorとなる)
４．仮想環境作成
python -m venv .venv
５．Djangoプロジェクトのディレクトリに移動し、requirements.txtでライブラリ一括インストール
cd (Djangoプロジェクト名)
pip install -r requirements.txt
６．migrationsディレクトリの作成(Djangoアプリのディレクトリ内に無ければ)
cd (djangoアプリ名)
mkdir migrations
cd migrations
touch __init__.py
mkdir __pycache__
(備考：migrationsディレクトリ内に__init__.pyが無いとpython manage.py makemigrationsを実施してもmodels.pyは無視される)
７．モデルをmigrationsする
python manage.py makemigrations
python manage.py migrate
８．Nginxを再起動してNginxとDjangoをバインド
sudo nginx -s reload
gunicorn --bind 127.0.0.1:8000 django_app.wsgi -D
９．ブラウザからサイトにアクセス
以上
