LLMプロダクトのロバスト性と運用
こんにちは、Algomaticのなんりです。
この記事は、LLM In Productionで登壇した「LLMプロダクトのロバスト性と運用」の資料を元に加筆した内容です。
背景が不足していたり、図が小さかったりしたので、追記も含めて更新しました。もし間違いがあれば教えてください。
自己紹介
会社概要と事業内容
いきなり余談で恐縮ですが、LLM in Productionの前回の勉強会で代表の大野が「LLMを活用した “反直感的”な新規サービス設計」という発表をしました。その中で「とりあえずサービスをリリースして、事業性がなくクローズした」という話をしています。
本勉強会の懇親会である方から、「事業ドメイン上、LLMプロダクトの取り組みは難しかったが、この話を聞き、チーム内でまず出してみようと動きになった。もうすぐプレスリリースも出します。」という声を頂きました。
市場全体でこういった事例が増えていくこと、本当に意義があることだと思うので、積極的に情報発信していこうと思います。コンプライアンス/ガバナンス上、公開出来ない話もあると思いますが、我々はスタートアップとして、泥臭くコミュニティを盛り上げていければと思っています。
LLMプロダクトの事業で困っている方がいれば、我々でよければいつでも壁打ちさせてください。是非私か大野にお気軽にご連絡ください！
気を取り直して本題に戻ります。
LLMプロダクトのロバスト性と運用
ロバスト性の定義
本資料では、「不確実な変化に対して、システムが継続的かつ安定的に処理できる状態であること」と定義しています。
LLMOpsの課題と背景
LLMプロダクトは、サービスとしての品質が不安定です。大きな理由は、モデルの出力をコントロールする術が少ないことだと考えています。MLプロダクトでも一般的な課題ではあると思いますが、MLプロダクトとの大きな違いは、市場の期待値です。
ChatGPTの出現によりLLMプロダクトへの期待値がこれまで以上に急激に高まる中、技術的な実体は追いついていません。期待値と実体の大きなギャップを埋めていくため、LLMOpsのケースを蓄積していく段階です。
LLMOpsとは、ユーザー課題を解決するためのLLMの開発と運用の仕組みづくりです。要素として「LLMプロダクトのロバスト性の向上」と「ロバスト性に左右されないプロダクト運用」があります。
LLMプロダクトのロバスト性の課題と対策
LLMプロダクトの構築パターン
詳細は、How to Match LLM Patterns to Problemsを参照してください。
構造化されており俯瞰しやすいです。また、具体的な手法に関しても言及されています。
日本語訳はこちら(噛み砕かれていて非常にわかりやすいと思います)
LLMプロダクト構築パターンのROI
LLMプロダクトの事業性としてROI(投資収益率)も外せない要素です。
Algomaticでは、ユーザー体験への即効性が高いところに優先度を置いています。(上図青色の項目)
この辺りは企業の戦略/戦術によって変わるため、一つの例として参考にしてください。
Algomaticのロバスト性へのアプローチ
Algomaticの現状の取り組み内容です。
プロンプトの制御(Defensive UX, Guardrails)
ベクターDBの活用(RAG)
ユーザー行動の評価(Collect feedback)
今回は、弊社のサービスであるシゴラクAIの事例を紹介したものです。シゴラクAIは、誰もが安全かつ簡単にChatGPTを活用できるように作られたWebサービスです。
ユーザーはChatGPTと同じチャットのインターフェースで情報を得ます。
ケース1: プロンプト制御(Defensive UX)
課題
良い出力を得るためのプロンプトノウハウがない。
0からプロンプトを作成するコストが高い。
アプローチ
固有の情報以外はテンプレートで固定化し、利用者のコストを削減する。テンプレート自体を自作できるため、熟練した人の知識を転移できる。
良い出力を得るためのプロンプトエンジニアリングには、さまざまな方法論が存在し、その要素を適応している。
AIシステムのデザインとして「不要なら無視できる優しいUI」を。
今後の展望
プロンプトエンジニアリングとデザインの改善です。
プロンプトエンジニアリング: LLMに対する入出力のデータセットログを残していくことで、自然言語生成(NLG)を評価するための基準を作ります。
デザイン: 利用者の課題に対して、最適なデザインパターンを適応します。チャットUIが最適なUXと考えていない一方、現状の課題に対してはチャット機構は良いインターフェースであると考えています。
ケース2: プロンプト制御(Guardrails)
課題
コンテンツの内容、一貫性を保つ方法がない。
法的/規制上の制御を効かせられない。
アプローチ
LLM入力前にシステムプロンプトによるコンテンツの方向付けを行う。内容的な方向付けと形式(特定のフォーマット)で指定すると効果的。
今後の展望
さまざまなLLMが出てくる中で、コンテンツのガバナンス/プライバシー情報の保護が大きな課題になることは間違いないのではないか。LLM内部の処理が非公開である限り、アプリケーション層でも処理する必要が出てくる。
ケース3: ベクターDBの活用(RAG, Guardrails)
この機能は、参照したい特定の情報源から、Q&Aや要約ができる。
課題
コンテンツの信頼性が低い。
特定の情報源から効率的に情報抽出ができない。
アプローチ
RAG(Retrieval Argumented Generation)の活用。外部情報を読み込ませることで、信頼性の高いコンテンツを生成する。この手法で検索インデックスを更新する方が、LLMのファインチューニングやプロンプトエンジニアリングよりも費用対効果が良い可能性がある。
外部情報をベクトル化し、データベース(ベクターDB)に保存する。
利用者の入力に対して、入力をベクトル化し、データベースから類似性を持つコンテンツを見つける。
LLMに入力する前にフォーマット化する。(refine query: 図には記載されていない前処理。)
LLMに投げて、出力を得る。
ツール
ベクトル化には、OpenAI社のtext-embedding-ada-002を活用(1536次元)
ベクターDBはpineconeを活用し、ハイブリット検索(単一の疎密インデックス)に対応可能。
今後の展望
ユースケースに沿ったSLAを設計する必要がある。
外部情報の更新/同期頻度、データサイズによるパフォーマンス低下を考慮に入れて、アーキテクチャ設計を実施する。
ケース4: ユーザー行動の評価(Collect feedback, Evals)
ユーザー行動の評価は、プロダクト改善の必須項目です。現状は、LLMプロダクトのユーザー行動の測定と改善の取り組み事例は少ない状況です。
課題
LLMのNLGの品質評価自体が難しい。関連して利用者の評価を測定できない状況に陥りやすい。
デザイン的な問題で、測定するべきデータが取得できていない。
ChatGPTのGood/Badボタンの活用率はかなり低いはずです。登壇時に利用したことがある人に挙手してもらいましたが、5-60人いた中で数人しか手を挙げていなかったと記憶しています。ユーザーフィードバックによる強化学習を目的とした機能のはずですが、データがとれないと改善はできません。
アプローチ
デザインの工夫により、利用者の評価データを集められるようにする。
活用されているプロンプトテンプレートの利用状況から、仮説をたて次の施策を行う。
実際に利用している利用者にインタビューする。
LLMのNLGの品質評価手法を試行する。
NLGに対する従来の評価手法
人間の判断に近い評価手法
今後の展望
ユーザー行動の評価は、今までのプロダクト開発と基本的には同じです。
NLGのボラティリティが高い分、継続的に評価できる仕組みを構築していく必要があります。
LLMプロダクトの技術ロードマップ
今後、LLMプロダクトで起こりそうな課題に対して、技術ロードマップを考えています。
オープンソースLLMの活用
オープンソースのLLMは今後も増えていきます。日本語ベースの大規模言語モデルは既に乱立し始めています。(オープンソース記載にも関わらず商用利用禁止のものも存在するのでライセンスを確認した上でご利用ください。)
今後はドメイン特化で精度をあげてくるLLMも出てきます。ユースケースに合わせてモデルを選択していく力が必要になっていくでしょう。
fine-tuning(RLHF)による最適化
短期的には、プロンプトエンジニアリングのROIが高い一方、データ量が増えれば、増えるほどfine-tuningによる改善も効果的になってくるはずです。ユーザーフィードバックによる強化学習(RLHF)でのfine-tuningは、事例が増えてくると考えています。
G-EvalによるLLM自体の継続的評価
LLMの性能の評価をLLMが実施していければと考えています。G-Evalに記載されているNLGの評価において、参照ベースのメトリクスは、特に創造性と多様性が求められるタスクにおいて、人間の判断との相関が比較的低いことが示されています。CoT(Chain of Thoughts)とフォーム入力の手法を活用するG-Evalでは、これまでのすべての手法を大幅に上回る結果を示したと記載されているため、今後注目しています。
システムパフォーマンスの最適化
現状、LLM活用における課題は大きなインフラコストです。事業として成立させるためのインフラ運用が急務です。アーキテクチャ設計により効率的なシステムにするために、キャッシュによるUX改善/インフラコストの削減などの施策を実行していきます。
ロバスト性に左右されないプロダクト運用
ロバスト性がたとえ低くても、品質を高められる運用はできるはずです。
課題に対する本質的なソリューション設計を行う
個人的なプロダクト開発の原則があります。
ユーザーの本質的な課題は何か？=> 解くべき課題は正しいか？
機能要件は間違っていないか？ => 解き方は合っているか？
解くべき課題が本質的でない場合、解決策が単一的になりやすいです。これは、本質的ではない≒WhyではなくHowによりやすい、ことが起因するのでは、と思っています。
結果的に、ロバスト性が低い解決策になりうるということです。ロバスト性の高い選択肢をとるために、本質的な課題を発見し解決策の選択肢を増やすこと、が効率的です。選択肢が増えれば、2の課題に向き合えます。
参考) ロバスト性の高いシステムアーキテクチャに変更した話の例: レストランにおける分散システムの構築と改善
顧客と長い関係性を求めて、期待値をすり合わせる
当たり前ですが、短期的な売上を求めて、過度な期待を煽り、顧客との関係性を喪失してはいけない、です。
現状は生成AIに対する市場の期待値が大きく、リード獲得コストが低いです。一方で、技術的な制約を正しく顧客に伝えるコストが高く、期待値のズレが生じやすいです。そのため、営業/CSへの適切な情報連携が重要な局面であると思っています。
LLMがAPI化されている分、非AIプロダクト的な売り方をしがちなのではないか？と考えていますが、従来のAIプロダクトのように積極的なPoCを検討し、顧客と適切にコミュニケーションしていくことが何より重要です。
まとめ
LLMプロダクトのロバスト性を高める手段とタイミングを知る。
構築パターン(Collect feedback, Defensive UX, Caching, Guardrails, RAG, Fine-tuning, Evals)を活用する。
また、プロダクトフェーズに合わせて、ROIを見極めパターンを組み合わせる。
ロバスト性に左右されない運用を行う。
本質的な顧客課題に対してロバスト性の低いソリューションを優先する
営業/CSの体制を厚めにし、顧客との良い関係性を築く。
メンバー大募集!!
Algomaticは4月に設立したばかりの会社で、絶賛採用中です。
我々の組織はまだ正社員が10名程度の状態で、どの事業も立ち上がり始めたばかりです。事業の成功は保証されておらず、一緒に事業の成功に向かって突き進める創業メンバーや仲間を探している段階です。
「銀の弾丸はない」とチューリング賞を受賞したフレデリック・ブルックスの言葉もありますが、事業の成功にも銀の弾丸はありません。Algomaticは誠実に、愚直に、泥臭く、前進し、社会によい影響を与えていこうと思っています。
募集職種
・事業開発、新規事業責任者
・ソフトウェアエンジニア（フロントエンド、バックエンド、インフラ）
・機械学習エンジニア（画像生成、言語生成）
・プロダクトマネージャー
・デザイナー
・セールス
・マーケティング
・カスタマーサクセス
・HR
カジュアル面談
ご興味ある方は、ぜひ一度お話ししましょう！
カジュアル面談はこちらから。