LLM API活用における 業務要件の検討 2023/10/27 社内勉強会 

自己紹介 natsuume 所属：AIソリューション開発部（2019年入社） - CRAIS for Text チーム - Tech Magazine チーム 2 

背景 - 世のChatGPT話の多くが以下のどちらか - 「◯◯」という書き方をしたらいい感じの結果が出た！ - 既存のプロンプトチューニング手法の焼き直し - チェリーピッキング - 事実誤認 - OpenAI APIを使ってみた、OpenAI APIを利用してChatBot, RAG作ってみた - Slack Bot - GitHub Actions - プロダクト・サービスへの導入時に考慮すべき点などの情報が少ない 3 

概要 - 取り扱う内容 - 新規/既存プロダクト・プロジェクトで ChatGPT(LLM) APIやその関連API(Embeddingsなど)を利用 する際に考慮すべき点 - LLM API活用においてどのような観点をもとに利用検討、業務要件を考えるべきか - 取り扱わない内容 - ChatGPT（APIではない方）の効果的な使い方、ベータ版機能、プラグイン、動向など - 各種LLMの具体的な紹介 - LLMの理論的・技術的な話 - 具体的な実装方法 今回は技術以外の話が中心 4 

1. LLMの特性と限界を理解する - 1.1. 再現性 - 1.2. 事実性 - 1.3. 説明性・透明性 - 1.4. レスポンスタイム - 1.5. LLM APIサービス上の制約 5 

1.1. 再現性 - 再現性とは - 同じ入力であれば常に出力が同じにな ること - LLMに再現性はない - ある程度高確率で同じ結果を出すこと は可能だが、絶対ではない 6 ※https://speakerdeck.com/arusl/llm-in-production-number-2-meetup-231023?slide=10 「メルカリにおけるLLMを用いたプロダクト開発」 （LLM in Production #2 -LLMの勘所 -コスト・精度・パフォーマンス -） 

1.2. 事実性 - （既に知られている通り）LLMに事実性を期待すべきではない - ゼロショットの場合（出力に利用できる情報を与えない場合）は特に - ハルシネーション - 出力の事実性を高める手法 - 知識生成プロンプティング（ Generated Knowledge Prompting） - RAG（Retrieval Augmented Generation） 7 

1.3. 説明性・透明性 ML一般の話として、出力に対する説明性・透明性を担保するのは非常に困難 - 技術的観点とビジネス的観点での違い（と自分が思っていること） - 技術的観点：モデルのアーキテクチャや重みから考える 本当の意味での説明性・透明性 - ビジネス的観点：クライアントやステークホルダーに対する説明性・透明性 - 例えば、MLの出力をLLMに説明させればビジネス的観点の説明性・透明性は一 定解消できる？ - LLMがそれっぽく理屈をつけているだけで事実性は担保されない - とはいえ、与えた情報の変換・加工は LLMが比較的得意な所 8 

1.4. レスポンスタイム - 安定性 - 時間帯によるレスポンスタイムの変化 - 時々レスポンスタイムが跳ねるケース 9 ※https://gptforwork.com/tools/openai-api-and-other-llm-apis-response-time-tracker The response times are measured by generating a maximum of 512 tokens at a temperature of 0.7 every 10 minutes in 3 locations. 

1.4. レスポンスタイム - 出力長とレスポンスタイム - 基本的には比例の関係 - 実際には前ページのような 他要因の影響も受ける - 実験設定 - 出力トークン数：10, 50, 100 - 実験回数：50 - 右図は中央値の推移 雑な検証なので後でもっと精緻に検 証したい 10 

1.5. LLM APIサービス上の制約 - サービスによって許容されない内容がある - センシティブな表現 - 差別的な表現 - 暴力的な表現 - 法律・法令等に関する内容 - 既存の著作物に関する内容 - Rate Limit - 短時間に複数のリクエストを投げると、開示されている Rate Limitを超えていなくてもRate Limit扱 いで弾かれるケースも - OpenAI API：https://platform.openai.com/docs/guides/rate-limits/overview - 基本的にはOrganization単位 - （久々にdocs確認したらtierとかいう概念が知らぬ間に生えていたことを知った） 11 

2. 業務要件と技術的制約 - 2.1. 出力タイミング - 2.2. 結果の厳密性 - 2.3. 結果の説明性・解釈性 - 2.4. コスト・クオリティ - 2.5. AI倫理・リスク 12 

2.1. 出力タイミング - リアルタイムなレスポンスは必要か - リアルタイム or バッチ処理（API利用なので多くの場合、実際にはキュー） - 許容されるレスポンスタイムはどの程度か（リアルタイムの場合） - ms単位の速度が求められるなら LLM以外の選択肢を検討 - 出力内容は使い回せないか - 既存回答の再利用、テンプレートの生成など - コスト観点からも 13 

2.2. 結果の厳密性 - 外部知識となる情報源が存在するか - 事実性が求められる場合、その事実となる情報自体は何らかの方法で与える必要がある - 誤りを許容できるか - 結果を人間が確認するのが一番安全 - 次点で結果の正しさをチェックするフロー、間違えた際の修正フロー - 求められるのは多様性か再現性か - バリデーションやクラスタリング、フォーマット用途では再現性が大事 - アイデア出しなどの用途ではむしろ（破綻しない範囲で）多様であるほうが良い 14 

2.3. 結果の説明性・解釈性 - 出力結果のドメインに対するユーザの専門知識はどの程度か - 結果を人間が確認して、出力内容の是非を判断できるユースケースが望ましい - 結果に対する説明責任はあるか - 事実性とも関連が深い - 与えられた情報からそれっぽい根拠を生成することはできる - データに基づく説明が必要な場合、重要なのはむしろそれらのデータをどう取得するか - 説明性が求められないユースケースのほうが導入ハードルは当然低い 15 

2.4. コスト - ユーザが自由にリクエストを送れる形式か - ユーザが自由にリクエストを送れる場合、基本的にユーザ数と API利用料は比例関係 - 特にtoC向けの場合は注意が必要 - 自由な文言を投げれる場合、不適切な文言のフィルタリングや攻撃に対する対策なども必要 - 出力を何に使うか - LLMで生成させたスキーマ・テンプレートをルールベースシステムで利用する形もあり得る - 出力に求められるクオリティはどの程度か - 質を一定妥協できるならコスト面・速度面では GPT-4よりGPT-3.5-turboのほうが優位 16 

2.5. AI倫理・リスク - 法律との兼ね合い - 「非弁活動」として弁護士法に抵触するケースも - 法務省指針：https://www.moj.go.jp/housei/shihouseido/housei10_00134.html - 個人情報・機密情報の漏洩 - Few-Shot Prompting, Fine Tuningへの利用などは細心の注意を払う - バイアス - 審査、採用における判定への利用などは高リスク - ML一般の話として、学習データにバイアスが含まれる場合、出力にもバイアスが含まれる - 人種、学歴、性別などをデータとして利用するケースには注意が必要 17 

おまけ：ChatGPTの導入 - 「なんでもできる」は嘘 - QA, テキスト補間, 要約, 情報抽出, フォーマット, 誤り訂正など既存タスクとして整理する - ステルスリリース - ユーザが直接ChatGPTを利用するのは高リスク - まずはユーザに近くない所に導入してみて勘所を掴むのも手 - MLOps - ML一般の話として、様々な要因で MLモデルの性能はリリース時点から徐々に低下する - LLMにおいても同様 - 入力される内容の傾向が変化した、など - 監視・評価・改善の仕組みを整えるのが重要 18 

まとめ - LLMの特性と限界を考慮して業務要件との兼ね合いを考える - 必須の要件とそうでないものを区別する - 「オンライン」「対話形式」を前提としがちだが、必要性についてちゃんと考える - 解くべきタスクを意識する - ユーザとLLM活用機能の関係性に注意を払う - ※宣伝 - （執筆間に合えば）今回の勉強会+αの内容で技術書典15にオンライン出展予定 (pdfのみ) - 原稿の進捗ダメなのでこれから頑張って書く - 興味がある方は購入してくれると自分が大変喜びます 19