Upgrade to Pro
— share decks privately, control downloads, hide ads and more …
Speaker Deck
Features
Speaker Deck
PRO
Sign in
Sign up for free
Search
Search
LLM API活用における業務要件の検討
Search
natsuume
October 26, 2023
Technology
0
120
LLM API活用における業務要件の検討
2023/10/27 株式会社オプト 社内勉強会資料
natsuume
October 26, 2023
Tweet
Share
More Decks by natsuume
See All by natsuume
5W1H ~LLM活用プロジェクトを推進するうえで考えるべきこと~
natsuume
0
130
自然言語処理基礎の基礎
natsuume
0
72
5分ですこしわかった気になる Deep Learning概要
natsuume
0
28
ChatGPT / OpenAI API実用入門
natsuume
0
130
Chat Completions APIにおける実行時間の検証
natsuume
0
270
Other Decks in Technology
See All in Technology
現場の失敗から学ぶ!プロダクトバックログアイテムの改善/Learn_from_On-Site_Failures!_Improving_Product_Backlog_Items
m_iyama
3
940
120リポジトリを1つのMonorepoに統合した理由
disc99
1
440
俺的 Four Keys 解釈
tetsuya28
0
220
ポストモーテム読書会のすすめ
taxin
0
260
機械学習クラスタ コンテナネットワーキング BoF
pfn
PRO
1
160
爆速開発文化を支えるProduct Engineerの 開発生産性向上の取り組み
shnjtk
10
3.5k
全社的な生成AI活用プラットフォームとしての Difyの導入事例紹介
tokita_kakaku
13
11k
LLM Prompt Recoveryコンペの振り返り
ktm
2
240
運用者の各領域で向き合うLLM
nwiizo
1
280
RDS for Db2 はじめの一歩・作り方編 #1 /20240628-RDSforDb2-dojo
mayumihirano
0
220
工場IoTを実現するClassmethod PLC Data to Cloudのご紹介 | DevelopersIO 2024 福岡
cmakky
0
210
2024年のRailsと自由について考える
takahashim
20
7.3k
Featured
See All Featured
Teambox: Starting and Learning
jrom
129
8.5k
Documentation Writing (for coders)
carmenintech
62
4.1k
Designing with Data
zakiwarfel
96
4.9k
Build The Right Thing And Hit Your Dates
maggiecrowley
27
2.1k
How To Stay Up To Date on Web Technology
chriscoyier
784
250k
The Pragmatic Product Professional
lauravandoore
28
6k
RailsConf & Balkan Ruby 2019: The Past, Present, and Future of Rails at GitHub
eileencodes
128
32k
Designing for humans not robots
tammielis
247
25k
Gamification - CAS2011
davidbonilla
77
4.8k
Creating an realtime collaboration tool: Agile Flush - .NET Oxford
marcduiker
15
1.6k
Embracing the Ebb and Flow
colly
80
4.3k
Code Reviewing Like a Champion
maltzj
516
39k
Transcript
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