生成AIを組み込んだシステムを開発する上で開発者目線で考慮したことについてまとめます。
背景
昨今の生成AI活用需要の高まりから、CNNやTransformerなどの深層学習モデルを生成AIモデルに置き換える動きが加速しています。
生成AIモデルに置き換えることで、精度向上やエンドユーザーの様々な検索クエリに対応した出力を可能にしたいといった目的、目標が根底にあるように感じています。
実際に生成AI関連の技術に関して調査・検討を進めた際、気を付けた点についてまとめます。
システム設計で考慮した点
「生成AIを利用したシステムを作成したい」という要望に対して具体的な入出力データの形式や取り扱うデータの規模感、開発にかかるコスト、効果を考慮しました。
ターゲットは誰にして、いつまでに、どのくらいお金をかけて、どの程度の性能のシステムを開発するかを定義する点が難しかったです。
生成AIの活用手段
生成AIを組み込んだシステム開発をする上で検討したポイントは大きく3つです。
①開発環境
②対象とするデータの規模
③学習方法
①開発環境
オンプレミスで動かすか、クラウドサービス上で動かすかを検討しました。
オンプレミスで動かす場合
マシンのGPUのメモリ容量を考慮したモデルの選定が必須となります。
一般にパラメータサイズが7B以上のものをオンプレミスで動かすとなると、GPUメモリが24GBであるNVIDIA GeForce3090などにギリギリ乗って動作するみたいです。
（動作検証したため推測値です）
クラウドで動かす場合
AmazonやMicrosoft、GoogleといったBigTechが提供するサービス利用料やAPI使用料について考慮する必要があります。
扱うデータ量が多くなる場合やユーザー利用者数が多くなる場合に、発生する利用コストについて概算見積を実施し、オンプレミスとクラウドの比較を行う必要があります。
②対象とするデータ
取り扱うデータの種類や量によって開発環境、生成AIモデルの選定に大きく影響が出ます。
小規模データでプロトタイプ作成のPoC開発もありますが、大規模データでの運用を考慮した開発の場合、クラウド利用料金が大きくなります。
動画や画像データを扱う際には、解像度の大きさやフレームレートもデータの量に直結します。
また、生成AIに入力するデータが日本語ドメインに依存する場合、日本語理解や多言語理解が可能なモデルを選定する必要があります。
トークナイザーにてトークン化する際、日本語の方が英語よりもトークン数が大きくなる点が有名です。
画像や図表などの非構造データ内部に日本語文字列が多く含まれる場合、日本語も理解可能なモデルが良いと考えます。
③学習方法
生成AIを用いて推論し、テキスト生成を行う際に、ドメイン適合について検討しました。
その際、プロンプトエンジニアリングやファインチューニング、RAGを考慮しました。
プロンプトエンジニアリングでは、生成AIモデルをそのまま利用し、指示プロンプトの形式を複数の事例を与えるfew-shotやChain-of-Thoughtなどの手法にて精度向上が期待できます。
生成AIモデルへのプロンプトの与え方を変えるだけなので開発コストが低く、導入しやすいです。
ファインチューニングのように特定のタスクに特化して再学習を行っていないため、プロンプトにて与えられた事例を一般的な知識をもとに回答生成するため、ハルシネーションを起こしてしまうことが注意点です。
ファインチューニングは社内データなどマイナーな知識に対する回答性能を向上させることができます。
生成AIモデルを独自データに特化させることや独自タスクに特化させるために利用される手法です。
マシンリソースや納期、開発リードタイムが潤沢に確保できる場合、ファインチューニングを選択すると、ドメイン適合による回答性能がプロンプトを工夫する手法と比較すると向上します。
ファインチューニングを行う開発環境を用意するためのコストや開発コストが大きい点が注意点です。
RAGは一度データベースへベクトルを保存し、都度検索クエリとデータベース内のベクトルの類似度を計算し、データベースからの検索結果だけに基づいて生成AIにて回答を生成する手法です。
生成AIの汎化性能を生かしつつドメイン知識に対応しているので、ハルシネーションを起こしにくいというメリットがあります。
社内に蓄積した膨大なリソースをもとにした生成AIによる回答を目的によく利用されています。
昨今、様々な企業が生成AIを導入する際に「RAG」を検討されています。
その多くが、社内蓄積の膨大なデータから特定の情報を検索クエリに基づき抽出したいという要求に基づくからだと考えています。
以降では、RAGに使用する生成AIモデルを検討する上で考慮・検討したことについてまとめます。
モデル・データベースの選定
RAGを使用するにあたりデータベースの作成やエンドユーザーからの検索、回答生成にわたるすべての詳細フローを絵に起こし、各モジュールにどんなモデルを使用するかを検討しました。
今回4種類のモデルとデータベースについて検討しました。
①VLM
②LLM
③Embedding model
④Reranker
⑤データベース
①VLM
画像や動画のフレーム画像を入力として画像、動画を説明させることによって、生成したテキストをメタデータとしてRAGに埋め込みます。
日本語関連タスクの性能が比較的高く、パラメータサイズが8B以下の中・小規模のモデルでは、「Qwen2.5-VL-7B-Instruct」や「Heron-NVILA-Lite-2B」のモデルがHeron-BenchやJVB-ItW、LLaVA-Benchといった性能評価指標にて高精度でした。
Instructモデルは、元の基盤モデルに対して指示への応答データで追加微調整されたものであり、プロンプトへの反応が良く、Few-shotによる追加の事例がなくても適切な応答を生成しやすい傾向があります。
②LLM
RAGのLLMはユーザーの質問に対する回答文章を生成します。
日本語での応答を想定している場合、llm-jp Leaderboardを用いて性能評価指標から選定すると良いでしょう。
軽量なモデルサイズかつNLI（自然言語推論）やRC（読解）などのタスクにて高精度のモデルがユーザーの意図した回答を生成しやすいモデルを推し量ることができると考えます。
③Embedding model
RAGのデータベースに対してベクトルデータを保存する前にデータをベクトル形式に変換するためのモデルです。
画像や動画を用いたRAGには、マルチモーダル埋め込みモデルを検討すると良いでしょう。
マルチモーダル埋め込みモデルの検討にはMTEB Leaderboardを用いて「image-text」, 「multi-lingual」などを指定してタスクに合うモデルを選択することが推奨されます。
Zero-shot分類タスクで高精度である点やモデルのパラメータサイズが軽量である点、入力画像の解像度がタスクに合致する点などを理由に選択することをオススメします。
④Reranker
RAGにて初回に取得した検索結果を再評価し高精度化するためにリランキングを行います。
リランキングは検索クエリと文脈、意味的につながりが強いほど高い検索スコアを出力します。
マルチモーダルのRerankerとして多言語のものはJina-reranker-m0とMonoQwen2-VL-v0.1の２例ありました。
どちらも発表年が2024年11月以降と、この一年以内に発表されたモデルでした。
加えて、どちらのモデルもQwen2-VL-2B-Instruct（多言語対応モデル）でファインチューニングしたモデルだそうです。
今後リリースを確認し、条件に合う最新モデルを利用すると良いと考えます。
⑤データベース
RAGにはデータベースとしてベクトルデータベースが用いられます。
ベクトルデータベースにはインデックス生成やストレージ、類似性の高いベクトルを取得といった役割があります。
スキーマとして構造データのみ扱う通常のデータベースと比較し、画像や音声などの非構造データを扱うことができます。
プロトタイプ開発用や大規模開発用に向け様々なベクトルデータベースが用意されています。
OSSのベクトルデータベースであり、オーケストレーションツールであるLangchain や LlamaIndexなどのフレームワークとの親和性の高さやスケーラビリティなどで選定すると良いでしょう。
まとめ
生成AIモデルを活用したシステム開発で考慮・検討したことをまとめました。
生成AIをシステムに組み込むことを検討する上で考慮事項が多く難しさを感じました。
生成AIは常に新しいモデルが公開されるため、定期的に使用するモデルをアップデートしていきたいと思います。
最後までお読みいただきありがとうございました。
