ChatGPT / OpenAI API実用入門

2023/05/16
株式会社オプト、デジタルホールディングス内で実施したChatGPT勉強会の資料

Transcript

1. ChatGPT / OpenAI API 実用入門 2023/05/16
2. はじめに
3. - 経歴 - 株式会社オプト AIソリューション開発部 所属 - 2019年新卒入社（今年で5年目） - CTO室（Data Intelligenceチーム） - → AIソリューション開発部 - 2021年上期 準MVP - 2023年Q1 MA本部 Value個人賞, Valueチーム賞 - 主な業務 - テキスト広告自動生成に関するR&D - CRAIS for Textアプリケーション開発 - エンジニア組織横断活動 - Opt Technologies Magazine - Tech イベント - 組織貢献関連施策検討 箕輪 峻 (Minowa Takashi) • HN/表示名：natsuume 自己紹介
4. 前提 - 想定対象者 - ChatGPTに関する基本的な内容は知っている - Chat Completions APIを使う人、API利用に関わる人 - 勉強会を通して目指す状態 - OpenAI APIを使って何らかの処理を作成できる - あるニーズに対して実現可能性・実現方法の検討ができる - 求められる出力に対してプロンプトをチューニングできる
5. 扱うトピック - OpenAI APIの基本 - Chat Completions API - プロンプトエンジニアリング - 比較検証 - プロンプトインジェクション - ライブラリ - 実例
6. 主に参照するドキュメント - OpenAI API公式ドキュメント - Libraries, Chat completion, Embeddings, Moderation, Rate Limits, Safety best practices, Production best practices - OpenAI公式APIリファレンス - Authentication, Chat, Embeddings, Moderations, Parameter details - プロンプトエンジニアリングガイド - Few-shot prompting, Chain-of-thought prompting, Self-Consistency, ReAct, Generated Knowledge Prompting, Automatic Prompt Engineer - LlamaIndex - LangChain
7. OpenAI APIの基本
8. Account 登録時の設定項目 - メールアドレス - ログイン方法は後から変更不可 - 電話番号 - 1つの電話番号あたり最大 2アカウントまで紐づけ可能 - Organization Name（Optional） - First Name/ Last Name - たぶんなんでも良い - 生年月日 - たぶんなんでも良い
9. API利用可否の紐づけ先 結論：waitlist申請したOrganizationに対して紐づく - GPT-4 API inviteのメール本文より - Your OpenAI organization (org-XXXX) can now access GPT-4 models with 8K context via the existing OpenAI API. - inviteメールがOrganizationメンバー全体に送られるわけではないので少し誤解し やすい
10. API Keyの紐づけ先 結論：API Keyは各アカウントに対して紐づく Organizationに対してではないので注意 API KeyとOrganizationの紐づけはリクエストヘッダを用いる
11. Authentication - Authorization: Bearer $OPENAI_API_KEY (Required) - OpenAI-Organization: YOUR_ORG_ID (Optional) - 設定されていない場合は API Key発行アカウントが設定している Default Organization https://platform.openai.com/docs/api-reference/authentication
12. Organizationとアカウント - アカウント作成時に1つのOrganizationが割り当てられる - ユーザが独自にOrganizationを作ったりはできない
13. Chat（リクエスト） ※詳細は後述 以下は特に重要な項目 - model - message - role - content - temperature - n - max_tokens - user
14. Chat（レスポンス） - created：UNIXタイムスタンプ - usage：使用トークン数 - prompt_tokens：入力トークン数 - completion_tokens：生成トークン数 - total_tokens：合計 - choices：生成結果 - finish_reason：終了理由 - stop：正常終了 - length：トークン上限 - content_filter：OpenAIのコンテンツフィルタ - null：進行中 - stream = trueの際の逐次処理結果など
15. Embeddings Text → 埋め込み表現（ベクトル表現）への変換を提供するAPI - リクエスト形式 - model - text-embedding-ada-002を推奨 - input - 下記いずれか - 文字列 - トークンidの配列 - 文字列配列 - トークンid配列の配列 - コスト：$0.004 / 1K tokens
16. Embeddings（レスポンス）
17. Moderations 任意の文字列がOpenAIのコンテンツポリシーに違反していないかを確認できるAPI ※英語の入力以外では上手くいかない リクエスト - input：文字列（英語推奨） - model（Optional） - text-moderation-latest（Default） - text-moderation-stable
18. Moderations（レスポンス） - results：入力文字列に対する判定結果の配列 - flagged：コンテンツポリシーに違反しているか - categories：各コンテンツポリシーに違反しているか - category_scores：各コンテンツポリシーに対するスコア（ 0～1） - category_score ≠ 確率
19. カテゴリ一覧 - hate - 人種、性別、民族、宗教、国籍、性的指向、障害状況、カーストに基づくヘイトを表現、扇動、または促進する内 容 - hate/threatening - 標的とされる集団に対する暴力や深刻な害を含むヘイト的な内容 - self-harm - 自殺、切り傷、摂食障害などの自傷行為を促進、励行、または描写する内容 - sexual - 性的興奮を誘うような内容や性的サービスを促進する内容（性教育やウェルネスを除く） - sexual/minors - 18歳未満の個人が含まれる性的内容 - violence - 暴力を促進または称賛し、他者の苦痛や屈辱を祝う内容 - violence/graphic - 死亡、暴力、重度の肉体的損傷を極度にグラフィックな詳細で描写する暴力的な内容
20. Rate Limit RPM：Request per Minutes TPM：Tokens per Minutes この他、Organizationごとに利用料金のLimitが存在する 必要に応じて緩和申請が可能（ ※GPT-4のRate Limitsは現時点では対象外 ）
21. Chat Completions API
22. model （gpt-4系はwaitlistでの順次開放） - gpt-3.5-turbo, gpt-4 - 基本的にはこちらを利用すれば良い - APIのresponseではgpt-3.5-turbo-0301, gpt-4-0314をmodelパラメータで返してくるので、自動的 に最新のsnapshotを呼び出す仕様になっている？ - snapshot: gpt-3.5-turbo-0301, gpt-4-0314 - 新しいバージョンがリリースされてから 3ヶ月後に非推奨になる - 新しいsnapshotがリリースされたときに結果が変わらないようにしたい場合はこちらを明示的に指 定してもよい
23. messages いわゆる「文脈」＝入力に過去の履歴を与えている状態 ※APIの機能として何かを覚えておく機能はない - role：メッセージのrole - system：システムメッセージ - user：ユーザメッセージ - assistant：ChatGPTの返答 - content：メッセージ本文 - name(Optional)：メッセージ作成者の名前 - 半角英数+アンダースコア(_)、最大64文字
24. サンプリング設定(temperature, top_p) 出力の多様性を制御するパラメータ 両方変更すると各パラメータの影響度合いの判断が難しくなるので、 基本的にはどちらか1つの みの利用が推奨 共通で、値が小さいほど決定的に、値が大きいほど多様性が増す - temperature：サンプリング温度の設定 - 値の範囲：0～2 - Default: 1 - 確率分布自体を平坦に均したり尖らせたりするパラメータ - top_p：top-p sampling（nuclear sampling）の設定 - 値の範囲：0～1 - Default: 1 - 累積確率が指定した閾値（0.5なら50%）を超えるまでを候補として考慮するフィルタ
25. サンプリング設定の仕組み ChatGPT (LLM) temperature ︙ top_p sampling token A 0.2 token B 0.15 … … token X 0.01 output token ※図
26. ペナルティ設定(presence_penalty, frequency_penalty) 既に出現したトークンに対して与えるペナルティの設定 いずれも -2.0 ～ 2.0 の範囲の値を取る（デフォルトは0） -2.0に近づくほど既に出現したトークンの出現確率が増加し、2.0に近づくほど既に出現 したトークンの出現確率が低下する - presence_penalty：1度でも出現したtokenに対して適用されるペナルティ - frequency_penalty：トークンの出現回数に応じて適用されるペナルティ
27. トークンの出現確率に対するペナルティ計算 - トークンの出現確率（正確にはロジット = 正規化前の対数確率）の計算 - mu[j] -> mu[j] - c[j] * alpha_frequency - float(c[j] > 0) * alpha_presence - mu[j]：j番目のトークンのロジット - c[j]：現在位置までにj番目のトークンがサンプリングされた頻度 - float(c[j] > 0)：c[j] > 0 ? 1 : 0 - alpha_frequency：frequency_penalty - alpha_presence：presence_penalty - presence_penalty：これまでに出現した全トークンに対して等しくペナルティを課す - frequency_penalty：出現回数が多いトークンに対してより大きなペナルティを課す - 式には書かれていないが、関連するパラメータとして logit_bias もある
28. 生成数(n) 入力に対して生成するメッセージ数 1 <= n の値を取り、Defaultは1 n > 1の場合、レスポンスのchoicesが複数の要素を持つ 同一のプロンプト・パラメータでn回APIを呼び出すのと同義
29. トークンの生成確率(logit_bias) 特定のトークンの出現確率（正確にはロジット = 正規化前の対数確率）に対してバイア スを与える key=token id (string), value=bias（-100～100）のMap 扱いが非常に難しいので、基本的には使用しなくて良い （1文字が複数トークンに分割されることがある日本語では特に）
30. その他のOptionalパラメータ - stream：ChatGPTのWeb UIのように生成結果を逐次的に受け取る設定 - boolean - stop：特定の文字列が生成される前に自動的にストップする設定 - string[] - max_tokens：上限トークン数（最大値はデフォルト） - integer - logit_bias：トークン単位の生成確率制御 - トークンidとパラメータのMap - user：ユーザID - 何らかの問題が発生した際に OpenAIからのフィードバックに利用される（？）
31. プロンプトエンジニアリング https://www.promptingguide.ai/jp
32. LLMに関する基本的な概念のおさらい - マルコフ過程：あるタイミングでの値の確率分布が1ステップ前の状態のみで決定さ れる確率過程 - N階マルコフ過程：Nステップまでの値のみの影響を受ける確率過程 (マルコフ過程の拡張 ) ChatGPTをはじめとする学習済み言語モデル ↓ 非常に高度な高階マルコフ過程 （過去のトークン系列から次のトークンを予測するモデル）
33. Few shot 行うタスクに対して、事前にいくつかの例を示す
34. Chain of Thought 中間的な推論ステップを介して複雑な推論を可能にする
35. Self-Consistency Few Shot CoTの拡張（多様な推論例を与えることで性能を高める） - 何もしない例
36. Self-Consistency Few Shot CoTの拡張（多様な推論例を与えることで性能を高める）
37. Generated Knowledge Prompting 知識を入力に与える
38. Generated Knowledge Prompting
39. ReAct（Reason + Act） 返答に思考（Thought）、行動（Act）、観察 （Observation）を出力させる LangChainやAuto-GPTで利用されている手法 - Generated Knowledge Prompting + ReAct - Actの出力を予め定めたキーワードに制御することで、 外部の処理と接続できる
40. Chat APIの出力比較
41. GPT-4はRate Limitsの制限が厳しいため下記以外はGPT-3.5-Turboを検証に使用 - モデル比較 - メッセージ形式比較 実行時間については同時に複数リクエストを送っていることによる影響がありそうな点に 留意する必要がある （実際には実行時間への影響は出力token数とモデルの種類の影響が大きい） 各実験は10回リクエストを行っていくつかの結果をピックアップする
42. GPT-3.5-turboとGPT-4（利用したプロンプト）
43. GPT-3.5-turboとGPT-4（gpt-3.5-turbo）
44. GPT-3.5-turboとGPT-4（gpt-4）
45. GPT-3.5-turboとGPT-4（結果） gpt-3.5-turbo gpt-4 出力token数(max) 343 238 出力token数(min) 230 208 出力token数(avr) 290.7 220.2 実行時間(max) 18570 19068 実行時間(min) 9783 15959 実行時間(avr) 14023 16994
46. GPT-3.5-turboとGPT-4（考察） - 条件の解釈はGPT-4のほうが圧倒的に強い - 比較的雑な指定でも JSON形式などフォーマットが整う - GPT-4は比較的簡素な出力になりやすい - 文字数制限を付けない場合でも基本的に GPT-3.5-Turboよりもシンプルな出力が出る - 平均出力トークン数がGPT-4のほうが少ないが、実行時間はGPT-4のほうが長い
47. メッセージ形式（試行①: リクエスト）
48. メッセージ形式（試行②: リクエスト）
49. メッセージ形式（試行③: リクエスト）
50. メッセージ形式（試行①: gpt-3.5-turbo）
51. メッセージ形式（試行②: gpt-3.5-turbo）
52. メッセージ形式（試行③: gpt-3.5-turbo）
53. メッセージ形式（試行①: gpt-4）
54. メッセージ形式（試行②: gpt-4）
55. メッセージ形式（試行③: gpt-4）
56. メッセージ形式（試行①: 結果） gpt-3.5-turbo gpt-4 入力token数 384 384 出力token数(max) 350 185 出力token数(min) 128 129 出力token数(avr) 269.2 154.6 実行時間(max) 27662 33032 実行時間(min) 10555 22523 実行時間(avr) 21664 25423
57. メッセージ形式（試行②: 結果） gpt-3.5-turbo gpt-4 入力token数 363 363 出力token数(max) 349 171 出力token数(min) 17 150 出力token数(avr) 223.9 161.4 実行時間(max) 26112 29618 実行時間(min) 2011 23714 実行時間(avr) 17161 26296
58. メッセージ形式（試行③: 結果） gpt-3.5-turbo gpt-4 入力token数 372 372 出力token数(max) 283 187 出力token数(min) 47 166 出力token数(avr) 190.6 177.8 実行時間(max) 20248 30275 実行時間(min) 4097 23032 実行時間(avr) 14541 28055
59. メッセージ形式（考察） - GPT-4はSystem, Userの使い分けの影響はあまり無さそう - GPT-3.5-TurboはSystemよりもUserに条件を入れるほうが有効 - 試行②は一部、試行③はすべて JSON形式になった - 出力数、文字数に関しては試行③（ User発話にすべて入れる）でも揺れる few shotの回答例をUserに含めるかassistantにするかの違いも検証したかったが、組 み合わせが膨大になりすぎるので省略
60. 言語（プロンプト①）
61. 言語（プロンプト②）
62. 言語（プロンプト① 出力）
63. 言語（プロンプト② 出力）
64. 言語（結果） Prompt ① Prompt ② 入力token数 184 206 出力token数(max) 131 287 出力token数(min) 77 151 出力token数(avr) 96.6 219.5 実行時間(max) 9777 20581 実行時間(min) 6082 10907 実行時間(avr) 7551 16015
65. 言語（考察） - プロンプト・出力の両方を英語にするのが最も結果の質が高い - プロンプトを英語、出力を日本語で出力させるよりも、英語の出力を後段で翻訳す るほうが良い(?) - 出力を再度APIに投げるなど、途中で人間が見る必要がないなら特に - 日本語で出力させると token数も増えるので、実行時間も増える - ただし、実践例では英語プロンプト、日本語出力でもフォーマットがうまく行ったので、フォーマットが 崩れたのはプロンプトの問題かも - 日本語と比較してtoken数は半分程度
66. サンプリング設定(プロンプト)
67. サンプリング設定(temperature=0)
68. サンプリング設定(temperature=0.5)
69. サンプリング設定(temperature=1.5)
70. サンプリング設定(top_p=0)
71. サンプリング設定(top_p=0.5)
72. サンプリング設定（考察） - (Default値を考えると当然だが)出力に多様性を出したい場合はtemperature - top_pはDefaultが1なので出力を決定的にする方向しか調整できない - temperature = 1.5でも出力が壊れるときは壊れる - temperature, top_pを最低値(0)にしても完全に固定はされない
73. ペナルティ設定(プロンプト) ※frequencyは極端な値にすると無限に壊れた token列を生成するのでmax_tokens=500に設定
74. ペナルティ設定(presence_penalty = -2)
75. ペナルティ設定(presence_penalty = -1)
76. ペナルティ設定(presence_penalty = 1)
77. ペナルティ設定(presence_penalty = 2)
78. ペナルティ設定(frequency_penalty = -1)
79. ペナルティ設定(frequency_penalty = 1)
80. ペナルティ設定(結果) presence -2 -1 1 2 出力token数 (max) 662 707 655 623 出力token数 (min) 263 263 351 296 出力token数 (avr) 405.2 425.8 444.2 415.6 実行時間 (max) 44972 46416 42846 40998 実行時間 (min) 18096 18096 23438 19970 実行時間 (avr) 26525 28333 30520 27991 frequency -1 1 出力token数 (max) 500 500 出力token数 (min) 109 210 出力token数 (avr) 466.2 397.3 実行時間 (max) 35131 33794 実行時間(min) 30645 14374 実行時間(avr) 33004 26252
81. ペナルティ結果（考察） - presence_penalty - penalty=1, 2の場合でも（若干壊れているところはあるが） frequencyのような壊滅的な壊れ方はし ない - （プロンプトの話題が広かった影響もありそう） - frequency_penalty - 負数（一度出たtokenが出やすくなる）はかなり出力が壊れやすい - 無限に同じtokenを出力したりするので、検証でも max_tokenの設定が必要なレベル - 露骨に日本語として壊れているわけではないが、 1でも少し怪しい箇所はある - 総じてpresence_penaltyよりもfrequency_penaltyのほうが慎重にパラメータを調 整する必要がありそう - 出力の多様性制御はtemperatureだけでなくpenaltyの調整も重要
82. 生成数(n) - 利用プロンプト：メッセージ形式（試行③）のプロンプト n 1 10 50 参考値（試行③） 合計出力トークン数 297 2333 10900 1906 1出力あたりの平均 トークン数 297 233.3 218 190.6 実行時間(ms) 18111 18006 235838 145410 (average * 10) 1出力あたりの実行 時間 18111 1800.6 4716.76 14541
83. 生成数(n) （考察） - 入力トークンは1回分カウント - n = 10くらいまでは n = 1と実行時間ほとんど変わらない(?) 基本的には同じリクエストを複数回投げるよりはnで制御するほうが良さそう
84. プロンプトインジェクション
85. プロンプトインジェクション 事前に設定されたプロンプトやOpenAIのコンテンツポリシーに対する様々な攻撃 - 指示の上書き・回避等によって無効にする - 設定されているプロンプトを出力させる - 本来ユーザに非公開のプロンプトを暴く など ※アップデートが行われており、過去のプロンプトインジェクション例でも現在は問題な いものも多い
86. プロンプトインジェクションの例（正常な応答）
87. プロンプトインジェクションの例（自由記述のリスク）
88. ライブラリ
89. openai - OpenAI公式ライブラリ - Python, Node.jsの2種類が提供されている その他の言語については、Community Librariesを参照
90. LlamaIndexとLangChain - LlamaIndex - LLMと外部データの接続、構造化、 indexingに特化したライブラリ - LlamaHub（データローダーライブラリのコミュニティ） - chroma, discord, elasticsearch, github_repo, gmail, google_seetsなどがある - LangChain - LLMを利用したアプリケーション開発のための汎用的なライブラリ - Agents機能（ReAct的なやつ）が提供されている - 基本的なEmbeddingsの活用等はどちらのライブラリでも可能 - とりあえず外部ソースを使ってみる、程度であればLangChainがおすすめ - 外部データ利用やindexingをより詳細にカスタマイズしたい場合、 LlamaHub提供のLoaderを使い たい場合はLlamaIndex併用もあり
91. Loader ※一部抜粋 - Transform Loaders - CSV, Email, EverNote, Faccebook Chat, HTML, Images, Jupyter Notebook, Markdown, Microsoft PowerPoint, Pnadas DataFrame, PDF, URL, Selenium URL Loader, - Public dataset or service loaders - Arxiv, Bilibili, HuggingFace dataset, YouTube transcripts - Proprietary dataset or service loaders - AWS S3 File, ChatGPT Data, Discord, Figma, GitBook, Git, Google BigQuery, Notion DB, Reddit, Slack, Stripe, Twitter - Llama Hub - ChatGPT Plugin Loader(ChatGPT Retrieval Plugin), elasticsearch, faiss, json, gmail, github_repo, jira, metal, mongo, notion, trello, knowledge_base, readability_web, rss, simple_web, unstructured_web, wikipedia, wordpress
92. LangChainで提供されている機能 - Models：API呼び出し - Chat Models, Embeddings, LLMs - Prompts：いわゆるBuilder的な機能群 + 出力Parser - Prompt Templates, Output Parser, Example Selectors - Indexes：ドキュメント等を読み込んで言語モデルと組み合わせる機能群 - Document Loaders, Text Splitters, Vector Stores, Retrievers - Memory：短期記憶、長期記憶 - Conversation Summary, DynamoDB-Backend Chat Memory, など - Chains：LLMの入出力を連結する機能 - LLM Chain, Index Related Chains, Sequential Chain, Other Chains, Prompt Selectors - Agents：LLM以外の処理の利用 - Agents, Agent Executors, Tools, Toolkits, Additional Functionality
93. LangChain / LlamaIndexを採用すべきか - メリット - Embeddingsの活用やAgentsなど、応用的な使い方が手軽に試せる - 様々なData Loaderが提供されている - Custom Model実装することでOpenAI API以外のLLM対応も（恐らく）可能 - デメリット - 破壊的アップデートが行われることがある - Pythonライブラリなので言語が固定される - LangChainはJavaScript版もあるが、Python版と比べて更新は遅れていそう - GASやフロントエンドは必然的に JavaScript系になるので、LangChain.js以外を使うなら使用 する技術が増えるので 1人～少人数開発だと負担になる 結論：場合による （開発体制, メンバーの技術スタック, タスクの内容, 保守メンテの方針など）
94. 実例
95. API利用料を計算する - 料金表はハードコーディング - API Responseのusageを利用する
96. 出力フォーマットを制御する (プロンプト) - プロンプトは英語で記載する
97. 出力フォーマットを制御する（出力） - 英語プロンプトにするだけで割とうまくいく - 禁止単語とかは流石に稀に混入する - よくあるフォーマット違反 - 不要なカンマが挿入されている - コードブロックで出力される - JSONの前後に「以下が出力になります」のようなメッセージが 挿入される - 上手くいかない場合の対処 - Few Shotで例を記載する - プロンプトの書き方を改善する - 後段にAPIの返答を入力にJSONフォーマットに変換するプロ ンプトのリクエストを挟む
98. 評価に利用する（事前準備） 評価指標を作成する（temperature=0）
99. 評価に利用する（プロンプト） 作成した評価指標をもとに評価させる（temperature=0）
100. 評価に利用する（結果） - 評価点を指定していなかったので似たような範囲に収束 - totalScore：3.5～4 - memorability：3～4 - relevance：2.5～4 - uniqueness：2.5～3.5 - emotionalImpact：3～4 - clarity：3～4 - ※評価結果が出せる ≠ 数値が妥当である - 評価結果の妥当性は別途検証が必要 - 商材の情報がないのに relevanceの評価とは？