この記事の目的
基盤モデルを使用する際の考慮事項について、ざっくりと学ぶ。
モデルを選ぶ選択基準
事前にトレーニングされたモデルは一つではないため、使用する前に解決したいタスクと照らし合わせ、最適なものを選ぶ必要がある。
主に以下の観点が存在するようだ。
コスト
モデルの使用料や、開発にかかる人件費。
大規模な開発環境ではよりコスパのよいモデルが求められるが、小規模な開発ではそもそものAPIの呼び出し基本料金等を気にする方が良い。
モダリティ
データ形式について考えること。例えば、処理をするデータが画像ならそれに適したモデルを使う必要があるし、マルチモーダルが必要ならそこも考量する必要がある。
レイテンシー
出力にどれくらいの時間的猶予が許されるか。
チャットボットなら即座に応答が必要だが、一日の決まった時間に決まった処理をするようなモデルならレイテンシーはそこまで気にしなくてよい。
多言語
モデルが多言語の処理を必要とするか。必要とする場合、言語間でパフォーマンスにどのような影響があるか等。
何があっても英語しか受け付けません！というような男気タスクなら気にしなくても良いかも。
モデルサイズ
どれくらい大規模なモデルを使うか。
一般的にモデルが大きいほど精度が高い傾向だがもちろんコストは増す。
モデルの複雑さ
モデルが実行するタスクの複雑さ。
犬、猫を判別するような単純モデルなのか、画像を読み取りそれがなんという動物なのか全哺乳類の中から識別するような複雑モデルなのか。
カスタマイズ
カスタマイズ（ファインチューニング）等がどの程度できるか。
特殊なタスクを処理する可能性がある場合は、カスタマイズが可能なモデルを選ぶ。
入力/出力の長さ
モデルが入力、出力に対し、どの程度のトークン数対応できるか。
短い応答でも問題がなければ軽量のモデル、等の選び方をする。
推論パラメータについて
基盤モデルを使用するにあたり、自分で推論パラメータ（モデルの挙動を調整できる数字のこと）をいじる必要がでてくるかもしれない。
その際はなんとなくこの数字が好きだから…という感じにフィーリングで決めるのではなく、結果に与える影響を考え、ふさわしい数値を設定する。
温度
生成される応答のランダム性（創造性）の度合いを制御するパラメータ。最大は1。
温度を下げると一貫性が上昇する。あげると多様性が上昇する。
定められた文書の作成等、厳密な応答が必要な場合は低い方が良いが、面白い話をしてほしいなー！等、創造性が必要な場合は高い方が良い。
Top K
出力された応答の上からK個目までを選択すること。
Kの数値が低いほど現実的で、高いほど創造性が増す。
Top P
出力された答えの確率の合計値がPを超えない範囲まで選択すること。
こちらも数値が低いほど現実的。
検索拡張生成 (Retrieval-Augmented Generation) について
RAGとは、モデルと外部の検索情報を組み合わせることで、モデルの性能や信頼性を向上させる方法。
ユーザーの質問に対し、モデルが検索をして情報を得て、その情報を盛り込んだうえで答えを生成すること。
Amazon Bedrock ナレッジベース
S3などに保存した文章や情報を使用してRAGを実装できるサービス。
Amazon Bedrock の エージェントについて
ユーザーの問いかけに対し、モデルが自ら必要な情報を聞き出して答えを生成する仕組み。
事前にエンジニアが指示を与えて調整する必要があるが、一度作成してしまえば何回も使える。
公式ページ
https://aws.amazon.com/jp/bedrock/agents/
プロンプトエンジニアリング
モデルを使用する際は、プロンプトにも気を配る必要がある。
https://qiita.com/ei_540/items/a1aa62d1cf28bf22fd74
Few-Shot Learning
ラベル付きデータを少数与え、答えを導き出してもらうこと。
例：「猫の子供は子猫。犬の子供は子犬。それでは羊の子供は？」
Zero-Shot Learning
正解のないデータに対して応答できるようにトレーニングをすること。