生成AIを使ったプロダクト、作っていますか？
生成AIがこの世に現れてから、はや数年が経ったわけですが、みなさんは生成AIを使ったプロダクトを作っているでしょうか。
私は社内の様々な クソみたいな上司からの要望に答えて生成AIを使ったプロダクトを作っては破棄してきましたSDGsとは程遠い行動ですが･･･
作ってきた（そして破棄した）もの一覧
- チャットボット（RAG活用）
- マニュアルの検索精度が悪いと言われて却下
そもそもマニュアルが良くない作りであることが問題な気もしている
- とあるデータの解析と要約をする仕組み
- 生成AIが得意な要約用途だったはずが、「感動しない」と言われて却下
- 感動とは･･･?
まぁ、そんなこんなでこの一年、生成AIを使ったプロダクト開発にそこそこ携わってきたこともあるので、私は日頃から考えている生成AIを使ったプロダクトリリースに関する勘所を考えてみます。
大前提
生成AIの回答は必ずしも正しいとは限らない
これに尽きると思います。
なので、正確性や完全性を求めるプロダクトに利用することはハードルが高いと思っています。
- 子どもへの学習教育：与えられた問題の、正しい答えと解放教えることが求められる
- 法律分野：判例や法規制の解釈を誤ると、重大な損害を招きかねない
- 金融分野：誤ったデータや推奨に基づく判断が経済的損失を招く恐れがある
逆に言えば、答えが存在しない分野、正確でなくても良いことを前提とした分野では採用ハードルが低いです。例えば
- クリエイティブ分野：小説や詩、ストーリーのアイデア生成
- ブレインストーミング：新商品やサービスのアイデア出し
- プロトタイプ・試行錯誤：複数のアイデアを素早く比較・評価するための下書き作成。
もちろん、今後（今現在も）様々な研究や技術発展によって上記で難しいと感じた分野にも、安定的に利用できる時代が来るかもしれまんね。
身近なところでいうと、よくあるRAGを活用したQAチャットボットです。
私も経験がありますが、よほど元となるマニュアルが行儀よく作られていないと、そのままのPDFマニュアル文書を使ったRAGを作ったとしても、そこそこの精度しか出ません。（もちろんプロンプトやベクトル検索などである程度はカバー可能）
それを「こんな質問をしたら間違った回答が返ってきた！」と重箱の隅をつつくようなことを言っていると、生成AIを使ったプロダクトリリースなんて夢のまた夢･･･
2024/12/10追記
興味深い記事だったので追記します。
ミスが出来ない業務の100%をAIに任せるのではなく、AIのミスを前提とした設計、AIのミスを減らすための両輪の仕組みを考えることが大切、まさにそのとおりですね。
重要なことは、生成AIの利点、そして限界を正しく理解した上でプロダクトを考えることです。
勘所はどこにあるのか
シンプルに考えると、「生成AIへの理解度」と「費用対効果」の2つだと考えています。
生成AIの限界を正しく理解できているか？
軽く触った人であればわかると思いますが、生成AIに正確性を求めるのには限度があります。 もちろん、出力形式をプロンプトで指示すればという話はあるのですが、生成AIの特徴を考えると、エンジニアとしてはそれで安心な設計とは言い切れないと思っています。
持論ではありますが、生成AIはあくまで人間のサポートに用途くらいで留めておいたほうがいいと思います。もちろん生成AIは素晴らしいものですし、技術革新の可能性も感じます。ですが、生成AIを利用する人間は完璧主義なので、間違っていることが前提の生成AIと人間はその点がどうやっても相容れないわけです。
こういった前提を"正しく"理解した上で、生成AIを使ったプロダクトをどのように設計するかを考える必要があります。
生成AIを使うプロダクトは何を意識するのか
- 生成AIは賢いけども、敢えて正答率7-8割を意識する
- 人の手が完全に離れられるわけではないと思っておく
- 人間によるダブルチェックはある程度必要になる
- 間違いがある可能性を完全に排除しない
- 出力結果を過信せず、ユーザーが後から修正できるようにする
- チーム全体が生成AIに対する正しい知識と認識を持つ
- 特に上司や経営層が間違った認識を持っていると危険
人間が仕事をしてミスをしたら、次から気を付けてね、で済ましますよね。それと同じ気持ちを生成AIにも持つべきです。もちろん、人間がミスしても許されないことってありますよね？そういったものを生成AIに一任すべきではないです。
費用対効果は得られるか？
chatGPTやAzure OpenAIをはじめとする生成AIの言語モデルを利用すると、当然費用がかかります。参考までにAzure OpenAIのgpt4oモデルを使うと、以下の費用体系になっています。
| モデル | 入力トークン単価 (1M Tokens) | 出力トークン単価 (1M Tokens) |
|---|---|---|
| GPT-4o | $2.50 | $10.00 |
言語モデルを利用した場合の費用体系で特徴的なのは、トークン数あたりの費用が発生するということです。トークン数ってなんだという件については、以下を参考にしてください。
入力トークン
ポイントとしては以下の2点です
- システムプロンプトをたくさん設定すると、リクエスト毎の費用が大きくなる
- 会話履歴を多く維持すると、会話すればするほど、費用が大きくなる
入力に使ったトークン数で、会話履歴を含めた入力値すべてのトークン数が換算されます。特徴としてシステムプロンプトや会話履歴が大きければ大きいほど、入力トークンは大きくなります
これの意味するところとしては、例えば生成AIに特定の役割を持たせるために膨大なシステムプロンプトを設定した場合、そのシステムプロンプトを毎回投げることになるので、それだけで入力トークンが恒常的に大きくなります。
また、会話の履歴をたくさん持たせたい場合、ユーザー入力と言語モデルからの応答をすべて送信する必要があるので、会話が続けば続くほど、入力トークンが大きくなります。
出力トークン
出力トークンは、入力に比べると考え方はシンプルです。出力には言語モデルからの回答しか含まれないので、それがどれくらいの大きさかだけに起因します。
出力の量はシステムプロンプトやユーザー入力である程度制御できますし、API実行時の設定値でも制御が可能です（max_tokens)
一方で、出力が大きくなると、会話を維持するには大きくなった出力を入力トークンに含む必要が出てきます。可能な範囲で出力量を制御すれば、ある程度は出力トークンによる費用を抑えることが可能です。
微調整モデルを使う場合
つまり、言語モデルに追加でデータを学習させて使う場合は、さらに費用体系が変わります。
| モデル | 1,000 トークンごとのトレーニング | 1 時間あたりのホスティング | 1,000 トークンあたりの入力使用量 | 1,000 トークンあたりの出力使用量 |
|---|---|---|---|---|
| GPT-4o | $0.0275 | $1.70 | $0.0028 | $0.011 |
まず、言語モデルへのトレーニングに際してトークン毎の費用が発生します。 これは一過性の費用ではありますが、学習量が膨大だったり、何度も学習をさせる場合、その費用を考慮する必要が出てきます。
加えて、トレーニングされた微調整モデルをホスティングする時間に依っても費用が発生します。これはトークン数毎ではなく、ホスティングした時間による費用です。通常のモデルと異なり、使うだけで必要が発生することも頭に入れておく必要があります。
これ、使っていなくても費用がかかるのか、それとも回答生成のために稼働している時間を指しているのかが執筆時点で筆者はわかっていません。今後試したら明記します。
シンプルな課題だからこそ難しい
これまで話してきたことって、正直、当たり前のことが多いですよね。でも、その「当たり前」だからこそ、意外と理解されにくいと感じています。特に上司や経営層に説明するのが難しいんですよ。
たとえば、こんなことありませんか？
- 人間のミスには「しょうがない」で済むのに、生成AIがミスすると厳しい態度を取られる
- 「そんなにお金かけなくても大丈夫でしょ」と思われがち
費用面なんて特にそうで、コンシューマ向けのChatGPTが無料で便利に使える分、「少ないコストで何でもできる」みたいな誤解が広がりやすいんですよね。でも、会社でちゃんと活用するなら、Azure OpenAIみたいな信頼できる環境を用意して、そこにお金をかけるのは避けられないんです。このギャップを埋めるのが結構難しい。
人間側が変わらないといけない
よく 「人間側が生成AIを受け入れる準備ができてない」 って言われますけど、本当にその通りだと思います。AIを活用するだけじゃなくて、それを扱う人間側も変わらないといけない時代なんですよね。ただ技術を導入するだけじゃなく、マインドセット自体をアップデートする必要があると思います。