生成AI時代のソフトウェアエンジニアが持つべきケイパビリティを考える

2024-07-25 Azure OpenAI Service Dev Dayの登壇資料です

Transcript

1. ⽣成AI時代 の ソフトウェアエンジニア が持つべき ケイパビリティ を考える 2024-07-25 Azure OpenAI Service Dev Day takuya kikuchi @ Algomatic シゴラクAIカンパニー CTO
2. © 2024 Algomatic Inc. 2 新領域 Algomatic シゴラクAIカンパニー CTO 菊池 琢弥 / Takuya Kikuchi ⾃⼰紹介 X: @pochi
3. ❶ Before ⽣成AI / After ⽣成AI、何が変わった？ ❷ エンジニアに必要なケイパビリティ ❸ 0 ➡ 1フェーズのはなし ❹ 1 ➡ 10 ➡ 100 のはなし ❺ まとめ 3 アジェンダ
4. Before ⽣成AI / After ⽣成AI、何が変わった？ 4
5. © 2024 Algomatic Inc. Before ⽣成AI / After ⽣成AI、何が変わった？ Before ⽣成AI • アクションフローの⽀援‧効率化 • ルールベースの処理⾃動化 5
6. © 2024 Algomatic Inc. Before ⽣成AI / After ⽣成AI、何が変わった？ After ⽣成AI • 「思考」の⽀援‧効率化 • 「判断」の⾃動化 6
7. © 2024 Algomatic Inc. Before ⽣成AI / After ⽣成AI、何が変わった？ ⽣成AIによって、「システム」のケイパビリティが広がった Before ⽣成AI: • アクションフローの⽀援‧効率化 • ルールベースの処理⾃動化 After ⽣成AI: • 「思考」の⽀援‧効率化 • 「判断」の⾃動化 7
8. エンジニアに必要なケイパビリティ 事業フェーズごとに考えてみる 8
9. © 2024 Algomatic Inc. プロダクトの 0 ➡ 1 フェーズで必要なケイパビリティ 価値あるプロダクトを作り、顧客に届けるためのケイパビリティ 1. プロンプトエンジニアリング ◦ ドメインエキスパートの思考の落とし込み 2. ソフトウェアエンジニアリング ◦ 思考過程にとりうるアクションのシステム化 3. ユーザーインターフェースの実装 ◦ 顧客の「WOW体験」を⽣み出す 9
10. © 2024 Algomatic Inc. プロダクトの 1 ➡ 10 ➡ 100 フェーズで必要なケイパビリティ プロダクトの価値を広く⾏き渡らせるために必要なケイパビリティ 1. プロンプトの抽象化および変更容易性の担保 ◦ スパゲティプロンプトを防ぐ 2. LLMの弱点と向き合う ◦ ⾼くて、遅くて、不安定なAPIを使いこなす 10
11. 0 ➡ 1フェーズに必要なケイパビリティ 11
12. © 2024 Algomatic Inc. 1. プロンプトエンジニアリング（思考のシステム化） ドメインエキスパートの思考をプロンプトに落とし込む。 ⼀⾜⾶びにアウトプットを求めることは難しい。なので、「過程」をプロンプト に落とし込む。 12 https://note.com/hokahokahoka18/n/nd4c9cf2891f2
13. © 2024 Algomatic Inc. 事例: 製品レビューの要約タスク レビュー内容: “この掃除機は普通かな。吸引⼒は悪くないけど、すごく パワフルってわけでもない。セットアップは簡単だけど、 説明書が読みにくかった。操作は⼤体直感的。バッテリー の持ちは悪くて、20分くらいしか使えない。デザインは⼤ きいけど、⻘⾊で我が家の雰囲気にはマッチしてる。 そういえば、昨⽇スーパーで掃除機売り場を⾒かけたん だ。いろんな種類があって⾯⽩かったな。 まあ、この掃除機は使えるけど、もっと良い選択肢があっ たかもしれない。掃除機選びって難しいよね。とりあえず 今のところはこれで頑張るしかないかな。” 13 アウトプット (GPT-4 Turbo): 普通の掃除機で、吸引⼒はまあまあだがパワフルではな い。セットアップ簡単だが説明書が不親切。バッテリーは 20分程度と短く、デザインは好みに合う。掃除機選びは 難しいと感じている プロンプト: 以下のレビューを100⽂字程度で要約してください。 レビュー: この掃除機は普通かな。吸引⼒は悪くないけど〜（略） 単に「良い感じに要約してくれ」だと微妙な出⼒になってしまう
14. © 2024 Algomatic Inc. 事例: 製品レビューの要約タスク - よりよいプロンプトを考える 14 改善プロンプト: 以下の家電製品レビューの要約をしてください。まずレビュー全体を読んで主要なポイントを抽出し、その後各評価ポイントについ て肯定的な点と否定的な点をリストアップしてください。各項⽬は、必ず客観的な事実である必要があります。要約は100⽂字程度 で評価ポイントをまとめてください。 詳細な⼿順を以下に⽰します。 1. レビュー全体を読み、客観的かつ主要なポイントを抽出します。 2. 次に、以下の評価ポイントに基づいて肯定的な点と否定的な点をリストアップします。 - 性能、使いやすさ、デザイン 3. 最後に、リストアップした肯定的項⽬と否定的項⽬に基づいて要約を作成し、100⽂字以内に収めます。 レビュー: この掃除機は〜（略） レビューを要約する際の思考過程をプロンプトに落とし込むことで、 望ましいアウトプットを得ることができる
15. © 2024 Algomatic Inc. 事例: 製品レビューの要約タスク - よりよいプロンプトを考える 15 アウトプット（改善プロンプト） 要約: 掃除機はサイズが⼤きく、バッテ リー持ちは短いが、⾒た⽬は良く、基本的 な吸引⼒と使いやすさを備えている。 レビューを要約する際の思考過程をプロンプトに落とし込むことで、 望ましいアウトプットを得ることができる アウトプット（旧プロンプト） 普通の掃除機で、吸引⼒はまあまあだがパ ワフルではない。セットアップ簡単だが説 明書が不親切。バッテリーは20分程度と短 く、デザインは好みに合う。掃除機選びは 難しいと感じている
16. © 2024 Algomatic Inc. 16 LLMは「ドメイン知識」を持っていない ➡ドメインエキスパートの思考過程を⼈間が紐解き、適切な粒度の課題に分解し てあげる必要がある ➡プロンプトテクニックだけでなく、ドメインエキスパートの思考を紐解き、⾔ 語化する能⼒が求められる 1. プロンプトエンジニアリング（思考のシステム化）
17. © 2024 Algomatic Inc. 2. ソフトウェアエンジニアリング（アクションのシステム化） ドメインエキスパートの思考過程を分析すると、「思考」意外にやることが多い ことに気づく。それらを柔軟にシステム化することが必要。 ここは従来のソフトウェアエンジニアリングと変わらないが、⾮常に⼤事 17
18. © 2024 Algomatic Inc. 2. ソフトウェアエンジニアリング（アクションのシステム化） たとえば... • 検索をして調べ物 ➡ Azure AI Search / Bing Search / Google Search / etc • 資料を読む ➡ Azure Document Intelligence / OCR / Web Scraping / etc • 動画を⾒る ➡ Whisper / etc • etc… 18
19. © 2024 Algomatic Inc. 3. ユーザーインターフェースの実装 ⽣成AIプロダクトの価値を他者に理解してもらうには... ➡「WOW体験」が⼤事 最速で他者に「WOW」を与えるため、プロトタイピングは⾮常に重要。 ⽣成AIによって⽣まれる価値は、理解されづらい。 19
20. © 2024 Algomatic Inc. 「作る前に売れ」という説もあるが GitHub Copilotを実際に触る以前、 「⾃分が書くより早く、AIが勝⼿にコードを書いてくれるんだ！すごいで しょ！」 と説明されて、その価値を理解できただろうか。 20
21. 1 ➡ 10 ➡ 100 フェーズで必要なケイパビリティ 21
22. © 2024 Algomatic Inc. 1. プロンプトの抽象化および変更容易性の担保 プロダクトが広がっていくにつれ、当初の想定より幅広い価値提供が求められ る。その時にプロンプトのメンテナンスが⾜枷となってはならない。 ➡ ハードコードされたプロンプトから、要件やパラメータの変化に柔軟に対応 できるプロンプトに進化させる必要がある 22
23. © 2024 Algomatic Inc. 先ほどのプロンプト プロンプト（再掲） 以下の家電製品レビューの要約をしてください。まずレビュー全体を読んで主要なポイントを抽出し、その後各評価ポ イントについて肯定的な点と否定的な点をリストアップしてください。各項⽬は、必ず客観的な事実である必要があり ます。要約は100⽂字程度で評価ポイントをまとめてください。⼤丈夫、あなたならできます。 詳細な⼿順を以下に⽰します。 1. レビュー全体を読み、客観的かつ主要なポイントを抽出します。 2. 次に、以下の評価ポイントに基づいて肯定的な点と否定的な点をリストアップします。 - 性能、使いやすさ、デザイン 3. 最後に、リストアップした肯定的項⽬と否定的項⽬に基づいて要約を作成し、100⽂字以内に収めます。 レビュー: この掃除機は〜（略） 23 このプロンプトに待ち受ける変更: • 遊園地レビューもできるようにしたいな...あと料理とスマホも • 新しいモデルが出てきた。これまでのテクニックがあまり効果がないらしいのでどうにかしたい • etc
24. © 2024 Algomatic Inc. プロンプトの構造解析 プロンプトを「ルール」「パラメータ」「テクニック」に分類 24
25. © 2024 Algomatic Inc. プロンプトの構造解析 - 実例 先ほどのプロンプトをルール、パラメータ、テクニック に分解してみる 25 以下の家電製品レビューの要約をしてください。まずレビュー全体を読んで主要なポイントを抽出し、その後各評価ポイントについ て肯定的な点と否定的な点をリストアップしてください。各項⽬は、必ず客観的な事実である必要があります。要約は100⽂字程度 で評価ポイントをまとめてください。⼤丈夫、あなたならできます。 詳細な⼿順を以下に⽰します。 1. レビュー全体を読み、客観的かつ主要なポイントを抽出します。 2. 次に、以下の評価ポイントに基づいて肯定的な点と否定的な点をリストアップします。 - 性能、使いやすさ、デザイン 3. 最後に、リストアップした肯定的項⽬と否定的項⽬に基づいて要約を作成し、100⽂字以内に収めます。 レビュー: この掃除機は〜（略）
26. © 2024 Algomatic Inc. 解析結果に基づいたプロンプトの分解 • 分析結果を元に、プロンプトを要素に分解し再構成 • 1つのプロンプトではなく、複数プロンプトに分離する⼿も有効 • テクニックはフレームワークの裏側に隠蔽される 26 Rule: string  ”以下の商品レビューの要約をしてください。まずレビュー全体を読んで主要なポイントを抽出し、その後各評価ポイントについて肯定的な点と否定的 な点をリストアップしてください。各項⽬は、必ず客観的な事実である必要があります。要約は100⽂字程度で評価ポイントをまとめてください。” Procedure: string[]  “レビュー全体を読み、客観的かつ主要なポイントを抽出します。”,  “次に、評価ポイントに基づいて肯定的な点と否定的な点をリストアップします。”  “最後に、リストアップした肯定的項⽬と否定的項⽬に基づいて要約を作成し、100⽂字以内に収めます” Parameters: { Category: string[], Points: string[] }  Category: 家電  Points:   “性能”, “使いやすさ”, “デザイン”
27. © 2024 Algomatic Inc. 解析結果に基づいたプロンプトの分解 • 遊園地、料理、スマホレビューに対応させる ➡ ⾚字部分を変更 • 新しいプロンプトテクニックを導⼊する➡フレームワーク側を変更 • よりよいドメインエキスパートの思考ロジックが得られた➡⻘字部分を変更 27 Rule: string  ”以下の商品レビューの要約をしてください。まずレビュー全体を読んで主要なポイントを抽出し、その後各評価ポイントについて肯定的な点と否定的 な点をリストアップしてください。各項⽬は、必ず客観的な事実である必要があります。要約は100⽂字程度で評価ポイントをまとめてください。” Procedure: string[]  “レビュー全体を読み、客観的かつ主要なポイントを抽出します。”,  “次に、評価ポイントに基づいて肯定的な点と否定的な点をリストアップします。”  “最後に、リストアップした肯定的項⽬と否定的項⽬に基づいて要約を作成し、100⽂字以内に収めます” Parameters: { Category: string[], Points: string[] }  Category: 家電  Points:   “性能”, “使いやすさ”, “デザイン”
28. © 2024 Algomatic Inc. 2. LLMの弱点と向き合う 「⾼くて遅くて不安定なAPI」に⽴ち向かうにはどうするか 28
29. © 2024 Algomatic Inc. 2. LLMの弱点と向き合う 「⾼くて遅くて不安定なAPI」に⽴ち向かうにはどうするか • ⾼い（Cost）→ 下がると信じる • 遅い（Latency）→ 早くなると信じる。遅さを許容する • 不安定（Reliability） → 失敗させない∕失敗を許容 29
30. © 2024 Algomatic Inc. コストは下がると信じる 現在のところ、LLMは「より安く」「より賢く」進化している • ここ1年で、GPT-4 Turbo / Claude3.0 Haiku / GPT-4o / GPT-4o-mini など 新モデル登場のたびに価格破壊は起きている • このトレンドがいつまで続くかは不明だが、何より今は「価値提供」にフル ベットしていくべきと考える ◦ 細かいコストチューニングは、コストが下げ⽌まってから、あるいはプ ロダクトの提供価値が盤⽯になったとき考えたい 30
31. © 2024 Algomatic Inc. レスポンスは気にしない コストと同様、LLMのレスポンス速度は向上している 1. ハイエンドモデルが⾼速化する ◦ e.g. ▪ GPT-4 -> GPT-4-Turbo -> GPT-4o 2. ローエンドモデルが⾼性能になる ◦ e.g. ▪ GPT-3.5 -> GPT-4o-mini ▪ Claude3 Sonnet -> Claude3.5 Sonnet ➡したがって、速度は向上していくと考えてよさそう。 ⽣成速度がプロダクトのコアな価値でない限り、現在そこを強く意識する必要はないと考える 31
32. © 2024 Algomatic Inc. LLMの不安定さは... LLMの出⼒はどこまでいっても不安定で、100%想定通り動くと考えてはならな い。これはLLMの性質上、当⾯変わらないはず。 ではどうするか？ ➡ 失敗しないようにする ➡ 失敗を許容する 32
33. © 2024 Algomatic Inc. 失敗しないようにする 厳格なバリデーションおよびリトライ 例: （TypeScript環境において）厳格な型検証を⾏い、失敗時はリトライする 33 erukiti: https://tech.algomatic.jp/entry/2024/05/23/140219
34. © 2024 Algomatic Inc. 失敗を許容する LLMの特性上、「⼈間では処理できないような⼤量のデータを処理する」ことは多い。そん なケースにおいては100%に拘らない⽅がよい。⼈間でも間違えることはある。 そんな時の失敗との関わり⽅: • 個別のLLM呼び出しは失敗を前提にロジックを組む • N=1の成功‧失敗には拘らない。たとえば100万件こなすうちの1件を気にしても仕⽅ がないので、⽬についた失敗ケースをいちいち気にしない • 代わりに、指標を適切に設定‧モニタリングした上で改善をしていく ◦ たとえば: ▪ 失敗ケースの分類を⾏い、発⽣数が多いパターンから修正していく 34
35. © 2024 Algomatic Inc. まとめ: エンジニアに求められるケイパビリティ 35 1. プロンプトエンジニアリング ドメインエキスパートの思考の落とし込み 2. システムエンジニアリング 思考過程にとりうるアクションのシステム 化 3. ユーザーインターフェースの実装 顧客の「WOW体験」を⽣み出す 1. プロンプトの抽象化および変更容易性の担保 スパゲティプロンプトを防ぐ 2. LLMの弱点と向き合う ⾼くて、遅くて、不安定なAPIを使いこなす 0 ➡ 1フェーズ 1 ➡ 10 ➡ 100 フェーズ