(JSConf JP 2023) LLM (大規模言語モデル) 全盛時代の開発プラクティス

by Yuichiro Yamashita

Slide 1

Slide 1 text

LLM (大規模言語モデル)  全盛時代の  開発プラクティス  baseballyama 

Slide 2

Slide 2 text

自己紹介 (baseballyama)  ● 株式会社フライル  ○ TypeScript / Vue / Svelte  ○ Kotlin / Spring Boot  ○ Python / Fast API / Open AI  ○ AWS / Terraform  ○ MySQL / Fargate / S3 / SQS / その他     ● Svelteコアチームメンバー   ○ Svelte5に向けて活動中 (できる範囲で)  ■ Svelte コンパイラのバグ修正  ■ ESLint Parser の Svelte 5 対応  ■ ESLint Plugin の Svelte 5 ルール追加  ■ コミュニティからの質問対応     ● その他  ○ 本業では5月からLLM系の機能を主に担当しています  

Slide 3

Slide 3 text

始める前に  JavaScript の話  薄めです。すみません。 

Slide 4

Slide 4 text

1. GitHub Copilot の話  2. AIツールによる更なる効率化  a. 理想と現実  i. AIレビューツール  ii. Figma to Code  b. 理想と現実のギャップを埋める方法  i. AIレビューツール  ii. Figma to Code  c. ギャップを埋める実装ステップ  i. 実装する前に...  ii. 実装ステップ  3. まとめ  アジェンダ 

Slide 5

Slide 5 text

Slide 6

Slide 6 text

1. GitHub Copilot の話 

Slide 7

Slide 7 text

No content

Slide 8

Slide 8 text

⚡アンケート⚡    GitHub Copilot 使ってますか? 

Slide 9

Slide 9 text

個人的所感  ● 少しタイピングしたら数秒待って、サジェストされたコードをとりあえず Accept してその後精査する、という流れが基本になった  (Vue.js / TypeScript / 独自ユーティリティ有でも問題なくサジェストされる)    ● 実装が面倒なユーティリティ関数はコメントだけ書いて GitHub Copilot に実装して貰う、という場面も増えた    ● 飛行機などネットが使えないと GitHub Copilot が使えなくて辛い    ● Svelteコンパイラみたいな参考にできるコードが少ない系のプロジェクトではあまり採用できない感覚 

Slide 10

Slide 10 text

GitHub Copilot のサジェスト方法の説明  const で統一  function で統一  const と function 混在 

Slide 11

Slide 11 text

GitHub Copilot のサジェスト方法の説明  ● GitHub Copilot は現在開いているファイルを参考にサジェストする仕組みのようです    ● よって、既存の実装が (不必要に) 統一されていない場合、サジェストの精度が落ちてしまいます 

Slide 12

Slide 12 text

コードの書き方の変化  ● つまり、「統一感」を重視している開発チームの場合、「統一感」はこれまでにも増して重要になります。  コードベースに統一感がない場合、GitHub Copilot がサジェストするコードも統一感がなくなり、コードベースの統一感のなさが加速します。  ● (脱線: 外在性認知負荷) 個人的には「統一感」はチーム開発において重要な要素だと考えています。例えば、先ほどの const vs function の例の場合、なぜここは const を使用しているのだろうか、なぜここは function を使用しているのか、という疑問を持つ開発者が出ることが予想されます。これは「外在性認知負荷」と呼ばれます。つまりコーディングで達成したい目標と直接関係のない負荷です。このような認知負荷は少ないほど良いはずです。  

Slide 13

Slide 13 text

どうやって統一感を獲得するか  ● ESLint などの静的検査ツールを徹底的に活用しましょう  ○ 必要に応じて ESLint のカスタムルールを作りましょう  ○ ESLint のカスタムルールを作る時間がない場合は  一旦AIを使用したレビュープロセスを導入しましょう (詳しくは後述)    ● 過去の資産が多いなどの理由で既に統一感がない場合は  ○ まずはコーディングルールを策定しましょう  ○ ESLint の autofix などを活用して一括でリファクタリングしましょう  ○ 一括で対応するのが難しい箇所は、コードにTODOを貼りましょう 

Slide 14

Slide 14 text

先ほどの function にTODOを貼ると... 

Slide 15

Slide 15 text

まとめ  ● GitHub Copilot は現在開いているタブのコードを参考にする  ● 良いサジェストを得るにはコードの統一感が重要  ● 統一感を獲得するためにはESlintなどの静的検査を導入する  ○ すぐにできない場合はTODOを貼るだけでも有効 

Slide 16

Slide 16 text

統一感は大事 

Slide 17

Slide 17 text

時間配分  ヨシッ 

Slide 18

Slide 18 text

Slide 19

Slide 19 text

1. a  2. AIツールによる更なる効率化 

Slide 20

Slide 20 text

Slide 21

Slide 21 text

No content

Slide 22

Slide 22 text

例えば...  AIレビューツール 

Slide 23

Slide 23 text

最近流行りのAIレビューツールを使ってみた  Figma to Code  AIレビューツール 

Slide 24

Slide 24 text

最近流行りのAIレビューツールを使ってみた    「テストを追加しよう」とか「コメントを書きましょう」   とかごく一般的なことしか指摘してくれなかった。     テストは別の方法で対処しているので問題ないし、コメントはほとんどの場合はコメントを読めばわかるので、不必要に書く必要はないと考えている。     もっと実際に役立つ指摘をして欲しい。   Figma to Code  AIレビューツール 

Slide 25

Slide 25 text

最近流行りのAIレビューツールを使ってみた  理想 : 自社のルールやコンテキストを踏まえてレビューして欲しい  現実 : 一般的な指摘に終始する  Figma to Code  AIレビューツール 

Slide 26

Slide 26 text

(参考) LLMを使用したレビュー支援ツール  ● PR-Agent (https://github.com/Codium-ai/pr-agent ) (⭐2.6K)  ● AI-based PR reviewer and summarizer (⭐1K)  (https://github.com/coderabbitai/ai-pr-reviewer )  ● chatgpt-action (⭐556) (https://github.com/kxxt/chatgpt-action#chatgpt-action )  ● ChatGPT Code Review (⭐191) (https://github.com/domvwt/chatgpt-code-review#chatgpt-code-review )  ● AI Code Reviewer (https://github.com/freeedcom/ai-codereviewer ) (⭐144)  Figma to Code  AIレビューツール 

Slide 27

Slide 27 text

例えば...  Figma to Code 

Slide 28

Slide 28 text

Figma to Code  ● 自社特有のデザインシステムがあるから単に HTML / CSS が出てきても困る    ● Figma公式のコード生成はReactのみ    ● Builder.io は色々なライブラリに対応している  しかし自社向けなカスタマイズがどこまでできるかは不明  Figma to Code  AIレビューツール 

Slide 29

Slide 29 text

Figma to Code  理想 : 自社のコンテキストを踏まえたUIコンポーネントを出力して欲しい  現実 : コンテキストを踏まえないUIコンポーネントが出力される  Figma to Code  AIレビューツール 

Slide 30

Slide 30 text

AIツールの理想と現実  現実の業務でAIツールを活用するには、AIツールは自社特有のコンテキストを理解する必要があるが、現時点でこれを達成しているツールはあまりないと理解しています。    これは以下2つのどちらかの方法で解決する必要があります  1. 自動的に自社特有コンテキストを理解するAIを実装する (AGIに近い (?))  2. 我々がAIに自社特有のコンテキストを与える    今回は 2 の方法に関して具体的な経験を共有します。 

Slide 31

Slide 31 text

2. 理想と現実を埋める方法 

Slide 32

Slide 32 text

No content

Slide 33

Slide 33 text

最初に結論  AIはめちゃくちゃ知識があるが業務のことを何も知らない新人だと思うとわかりやすいと思います。  プロセスとデータを解釈の余地なく教える必要があります。  Figma to Code  AIレビューツール 

Slide 34

Slide 34 text

LLMと人間の違い  共通点  ● LLMは人間の脳の仕組みを模倣している  相違点  ● 知識獲得方法  ○ 人間 : (個人・組織に関わらず) 各々が十人十色の経験を基に独自の知識を獲得している   ■ 知識量は限られているが独自性に優れている   ○ LLM : webから収集できる一般的な知識を獲得している   ■ 知識量は膨大だがwebから収集できない独自情報は知らない   一番わかりやすい例は「あれどうなった?」で理解できるのが人間。  LLMは理解できない。  Figma to Code  AIレビューツール  免責 : 私はAI / LLM の専門家ではないため正確でない可能性があります。  

Slide 35

Slide 35 text

LLMと人間の違い  つまり、LLMは、私たちが普段意識することもなく共通認識とみなしているアレやコレを知らない訳です。  これはまさに会社に来た新人と似ている状況ではないでしょうか。  Figma to Code  AIレビューツール  免責 : 私はAI / LLM の専門家ではないため正確でない可能性があります。  

Slide 36

Slide 36 text

AIは新人  (めちゃくちゃ知識豊富だけど) 

Slide 37

Slide 37 text

AIレビューツールの理想と現実を埋める方法  理想 : 自社のルールやコンテキストを踏まえてレビューして欲しい  現実 : 一般的な指摘に終始する  理想に近づけるためには   1. まずはレビューのワークフローを言語化する  2. その後、AIレビューツールにそのワークフロー通りに処理させる  3. 各ワークフローで足りない情報があればAIに教える  Figma to Code  AIレビューツール 

Slide 38

Slide 38 text

AIレビューツールの理想と現実を埋める方法  やってみた結果  Figma to Code  AIレビューツール 

Slide 39

Slide 39 text

AIレビューツールの理想と現実を埋める方法  やってみた結果  結果  ● 自社のコーディングルールを基に  ● GitHub のPRに対して指摘  ● 改善案も提案    効果  ● 正しい指摘もある一方で誤りもある  ● コーディング規約を日々目にするようになるという副次効果    改善点  ● まだ false positive も多い  ● 本当に修正が必要な指摘だけをできるようにならないと狼少年になって人間に無視されるようになる  Figma to Code  AIレビューツール 

Slide 40

Slide 40 text

リポジトリはここに (ai-review-flex)  https://github.com/baseballyama/ai-review-flex   Figma to Code  AIレビューツール 

Slide 41

Slide 41 text

Figma to Code の理想と現実を埋める方法  理想 : 自社のデザインシステムを踏まえて自動生成して欲しい  現実 : 単にライブラリを使用したコードが生成されてしまう  理想に近づけるためには   1. まずはレビューのワークフローを言語化する  2. その後、AIレビューツールにそのワークフロー通りに処理させる  3. 各ワークフローで足りない情報があればAIに教える  Figma to Code  AIレビューツール 

Slide 42

Slide 42 text

Figma to Code 理想と現実を埋める方法  やってみた結果  Figma to Code  AIレビューツール 

Slide 43

Slide 43 text

Figma to Code の理想と現実を埋める方法  やってみた結果  結果  ● 自社のデザインシステムコンポーネントを基に  ● Vue 3 コンポーネントを実装してくれた    効果  ● Figmaと行き来する回数が大幅に減った  ● 今まで30分程度はかかっていただろう作業が5 分足らずで大枠が出来るのはかなり楽になった。    改善点  ● 生成したコードに対して vue-tsc や ESLint を実行してエラーがなくなるまで自動修正させればもっと手作業が減りそう。  (時間が足りなくて試せませんでした🙏)    Figma to Code  AIレビューツール 

Slide 44

Slide 44 text

公開リポジトリはありません。  Figma to Code  AIレビューツール 

Slide 45

Slide 45 text

3. ギャップを埋める実装ステップ 

Slide 46

Slide 46 text

No content

Slide 47

Slide 47 text

実装する前に... 

Slide 48

Slide 48 text

a. 実装する前に...  実装する前に以下の手順を踏むのが良いと思います。  作業プロセスと必要なデータを言語化する   ”単純作業” で “工数大” なプロセスを抽出する   静的検査で自動化できるか  自動化する  Yes  GitHub Copilot などの既存ツールで対処する   GitHub Copilot  などの既存ツールで対処できるか  Yes  LLM を活用して独自の対処方法を検討する   No  Yes  No 

Slide 49

Slide 49 text

a. 実装する前に...  実装する前に以下の手順を踏むのが良いと思いました。  作業プロセスと必要なデータを言語化する   ”単純作業” で “工数大” なプロセスを抽出する   静的検査で自動化できるか  自動化する  Yes  GitHub Copilot などの既存ツールで対処する   GitHub Copilot  などの既存ツールで対処できるか  Yes  LLM を活用して独自の対処方法を検討する   No  Yes  No  LLMはいわば「異様に能力が高いがプロジェクトのことを何も知らない人」です。  LLMへの指示は「解釈の余地なく」出す必要があります。  つまり、自動化したいタスクを解釈の余地なく言語化できる必要があります。  また、LLMはプロジェクトのことを何も知りません。よって、その作業プロセスに必要なデータも全て言語化する必要があります。 

Slide 50

Slide 50 text

Slide 51

Slide 51 text

a. 実装する前に...  実装する前に以下の手順を踏むのが良いと思いました。  作業プロセスと必要なデータを言語化する   ”単純作業” で “工数大” なプロセスを抽出する   静的検査で自動化できるか  自動化する  Yes  GitHub Copilot などの既存ツールで対処する   GitHub Copilot  などの既存ツールで対処できるか  Yes  LLM を活用して独自の対処方法を検討する   No  Yes  No  OpenAI を中心として、LLMを使用したサービスの成長速度が凄まじいです。  折角自作してもすぐに既存製品が対応する可能性があるので、  現時点では、既存製品を積極的に使用すると共に各社の動向を見て、製品側で対応されることで将来解決されそうな問題に対しては、自作するとしても深追いしすぎないなどの塩梅の調整が必要です。 

Slide 52

Slide 52 text

Slide 53

Slide 53 text

作らない 

Slide 54

Slide 54 text

LLMを活用して独自の仕組みを実装する場合は... 

Slide 55

Slide 55 text

b. 実装ステップ  私が今まで試した中では以下の手順が良いと思いました。  Chat GPT に指示と必要なデータを与える   差分に関して  なぜそのような回答をしたのかを聞く   指示とデータを修正して再度処理させる   返答と期待値に  差分があるか  Yes  Chat GPT にこれまでの指示をまとめさせる   新しいチャットにて、まとめた指示に対して   不明瞭な点や疑問がないかを聞く   (あればこれらがなくなるまで修正する)   この指示を使用するプログラムを実装する   返答と期待値に  差分があるか  運用開始  ※ 全指示とレスポンスはログに保存しておく   Yes 

Slide 56

Slide 56 text

Slide 57

Slide 57 text

LLMを活用して独自の仕組みを実装する場合は... 

Slide 58

Slide 58 text

指示とデータを与える  あなたは世界を代表するソフトウェアエンジニアです。あなたの仕事は git の diff をよく理解し、コーディング規約に違反しているコードを指摘することです。  以下のコーディング規約とdiffを基に指摘してください。    ## コーディング規約    ### プロダクションコードにコンソールログを残さない    本番コードからすべての `console.log` ステートメントを削除することで、情報の漏洩や出力の乱雑さを避けることができます。    ## diff    {{ git diff の結果 }} 

Slide 59

Slide 59 text

回答  Based on the coding standards you provided and the `diff` content, there is a clear issue that needs to be addressed:    The addition of `console.log(diff);` in the `splitForEachDiff` function violates the coding standard of not leaving console logs in production code. As per the standard, all `console.log` statements should be removed from production code to avoid information leakage and cluttered output. This newly introduced line directly contravenes this rule and should be removed or replaced with an appropriate logging mechanism suitable for production environments.  英語で返ってきたので日本語にしたい 

Slide 60

Slide 60 text

指示とデータを修正する  日本語で回答してください。 

Slide 61

Slide 61 text

回答  コーディング規則に基づいて、提供された `diff` の内容を検討すると、以下の問題点が明確になります：    `splitForEachDiff` 関数に追加された `console.log(diff);` は、本番コードにコンソールログを残さないという規則に違反しています。規則によれば、情報漏洩や出力の乱雑さを避けるために、本番コードからすべての `console.log` ステートメントを削除する必要があります。この新しく追加された行はこのルールに直接反しているため、削除されるか、本番環境に適した適切なロギング機構に置き換えられるべきです。  最初の文章は不要 

Slide 62

Slide 62 text

指示とデータを修正する  指摘だけを簡潔に返答してください。 

Slide 63

Slide 63 text

回答  `splitForEachDiff` 関数に追加された `console.log(diff);` は本番コードにコンソールログを残さないというコーディング規約に違反しています。この行は削除すべきです。  よさそう 

Slide 64

Slide 64 text

これまでの指示をまとめる  これまでの指示を整理してください。この指示はGPTへの命令に使用します。指示は解釈の余地がないようにしてください。 

Slide 65

Slide 65 text

回答 (1 / 2)    以下に、あなたがLLMに対して使用するための整理された命令を示します。これは、コーディング規約とdiffが変わることを考慮して変数として設定できるように構成されています。    ---    ### 命令のテンプレート    **命令:**  LLMに対して、特定のコーディング規約に基づいて、提供されたdiffの内容を分析し、規約違反がある場合はその指摘を行う。    **変数:**  1. `codingStandard`: コーディング規約の詳細（テキスト形式）。  2. `diffContent`: 分析するdiffの内容（テキスト形式）。   

Slide 66

Slide 66 text

回答 (2 / 2)    **具体的な指示:**  1. LLMは、`codingStandard` に示されたコーディング規約を理解し、遵守する。  2. LLMは、`diffContent` を分析し、`codingStandard` に違反している部分があるかどうかを判断する。  3. もし規約違反がある場合、LLMはその具体的な違反点と、それがどのように規約に反しているかを明確に指摘する。  4. 分析結果は簡潔かつ明確に提示する。    ---    このテンプレートを使用することで、LLMに対する指示を明確かつ一貫性を持たせることができます。また、変数を変更することで、異なるコーディング規約やdiff内容に対応することが可能です。 

Slide 67

Slide 67 text

Slide 68

Slide 68 text

まとめた指示に対して不明瞭な点や疑問がないかを聞く  以下の指示に関して、不明点や不明瞭な点があれば教えてください。     ---    **命令:**  特定のコーディング規約に基づいて、提供されたdiffの内容を分析し、規約違反がある場合はその指摘を行う。     **変数:**  1. `codingStandard`: コーディング規約の詳細（テキスト形式）。   2. `diffContent`: 分析するdiffの内容（テキスト形式）。     **具体的な指示:**   1. LLMは、`codingStandard` に示されたコーディング規約を理解し、遵守する。   2. LLMは、`diffContent` を分析し、`codingStandard` に違反している部分があるかどうかを判断する。   3. もし規約違反がある場合、LLMはその具体的な違反点と、それがどのように規約に反しているかを明確に指摘する。   4. 分析結果は簡潔かつ明確に提示する。  

Slide 69

Slide 69 text

回答  承知しました。このタスクを実行するためには、以下の情報が必要です：    1. **コーディング規約の詳細** (`codingStandard`)：これは、分析する際に参照するルールセットです。コーディング規約の詳細が提供されているか、あるいは特定の既存のコーディング規約（例えばPEP 8、Google Java Style Guideなど）を参照するかの指示が必要です。    2. **分析するdiffの内容** (`diffContent`)：これは、変更点を示すコードの差分（diff）です。diffがどのように表示されているか（例えば、 GitHub形式のdiff、単純なテキスト比較など）、そしてどのプログラミング言語で書かれているか（TypeScript、JavaScript、Kotlin、Java、 Pythonなど）の情報が必要です。    これらの情報を提供していただければ、指示に従って分析を行うことができます。どうぞよろしくお願いいたします。 

Slide 70

Slide 70 text

大丈夫そうなのでコードに落とし込んでみましょう。  

Slide 71

Slide 71 text

コードにしてみる  const response = await openai.chat.completions.create({  model: "gpt-4-1106-preview" ,  messages: [  {  content: buildPrompt(codingRule, diff),  role: "user",  },  ],  temperature: 0,  });  return response.choices[0]?.message?.content ?? "";    const buildPrompt = (  codingStandard: string,  diffContent: string,  ) => {  return `\  **命令:**  特定のコーディング規約に基づいて、提供されたdiffの内容を分析し、規約違反がある場合はその指摘を行う。    **変数:**  1. \`codingStandard\`: コーディング規約の詳細（テキスト形式）。  2. \`diffContent\`: 分析するdiffの内容（テキスト形式）。    **具体的な指示:**  1. LLMは、\`codingStandard\` に示されたコーディング規約を理解し、遵守する。  2. LLMは、\`diffContent\` を分析し、\`codingStandard\` に違反している部分があるかどうかを判断する。  3. もし規約違反がある場合、LLMはその具体的な違反点と、それがどのように規約に反しているかを明確に指摘する。  4. 分析結果は簡潔かつ明確に提示する。  5. 日本語で回答する。    ## codingStandard  ${codingStandard}    ## diffContent  ${diffContent}`;  };    指示が抜けていたので足しました。  

Slide 72

Slide 72 text

コードにしてみる  const response = await openai.chat.completions.create({  model: "gpt-4-1106-preview",  messages: [  {  content: buildPrompt(codingRule, diff),  role: "user",  },  ],  temperature: 0,  });  return response.choices[0]?.message?.content ?? "";  const buildPrompt = (  codingStandard: string,  diffContent: string,  ) => {  return `\  **命令:**  特定のコーディング規約に基づいて、提供されたdiffの内容を分析し、規約違反がある場合はその指摘を行う。    **変数:**  1. \`codingStandard\`: コーディング規約の詳細（テキスト形式）。  2. \`diffContent\`: 分析するdiffの内容（テキスト形式）。    **具体的な指示:**  1. LLMは、\`codingStandard\` に示されたコーディング規約を理解し、遵守する。  2. LLMは、\`diffContent\` を分析し、\`codingStandard\` に違反している部分があるかどうかを判断する。  3. もし規約違反がある場合、LLMはその具体的な違反点と、それがどのように規約に反しているかを明確に指摘する。  4. 分析結果は簡潔かつ明確に提示する。  5. 日本語で回答する。    ## codingStandard  ${codingStandard}    ## diffContent  ${diffContent}`;  };    指示が抜けていたので足しました。  

Slide 73

Slide 73 text

実行してみた (1 / 2)  ## 分析結果    ### 規約違反の指摘     **違反箇所:**   ```diff  + console.log(diff);   ``` 

Slide 74

Slide 74 text

実行してみた (2 / 2)  **違反理由:**   提供されたコーディング規約には「プロダクションコードにコンソールログを残さない」という指示が含まれています。この規約は、本番コードからすべての `console.log` ステートメントを削除することで、情報の漏洩や出力の乱雑さを避けることを目的としています。提供された `diffContent` の変更部分には、新たに追加された `console.log(diff);` という行があり、これは明確にコーディング規約に違反しています。     ### 修正提案    この `console.log` ステートメントは削除するか、デバッグ目的であれば、別のログメカニズムに置き換えることが望ましいです。例えば、ロギングフレームワークを使用して、開発環境でのみログを出力する設定にすることが考えられます。 

Slide 75

Slide 75 text

いい感じですね。  (ちょっと回答が長いけど) 

Slide 76

Slide 76 text

実際にはこんなことも実装しないといけない...  ● コーディング規約のファイルをルールごとに split する処理   ● diff を取得して1箇所ごとに分割する処理   ○ diff から削除行を削除する処理 (これをした方が精度が上がった)   ● 回答フォーマットをより厳密にするプロンプト調整   ○ 指摘対象の diff に対してコメントするためには指摘対象の行番号が必要   ● GitHub にコメントを投稿する処理   ● 並列処理 (GPT4 は遅いため)   ● OpenAI API のレート制限に引っかかった場合のリトライ処理     などなど... 

Slide 77

Slide 77 text

実装ステップ  私が今まで試した中では以下の手順が良いと思いました。  Chat GPT に指示と必要なデータを与える   差分に関して  なぜそのような回答をしたのかを聞く   指示とデータを修正して再度処理させる   返答と期待値に  差分があるか  Yes  Chat GPT にこれまでの指示をまとめさせる   新しいチャットにて、まとめた指示に対して   不明瞭な点や疑問がないかを聞く   (あればこれらがなくなるまで修正する)   この指示を使用するプログラムを実装する   返答と期待値に  差分があるか  運用開始  ※ 全指示とレスポンスはログに保存しておく   Yes 

Slide 78

Slide 78 text

運用開始 ※ 全指示とレスポンスはログに保存しておく  プロンプトを一度作っただけでは大抵うまくいきません。こういうケースではうまくいくけどこういうケースではうまくいかない、のような学びを得ることになります。   その度にプロンプトを改善する必要があります。     プロンプトを改善する方法は簡単です。単に「その回答をした理由を教えてください」と聞きましょう。  

Slide 79

Slide 79 text

運用開始 ※ 全指示とレスポンスはログに保存しておく 

Slide 80

Slide 80 text

運用開始 ※ 全指示とレスポンスはログに保存しておく 

Slide 81

Slide 81 text

運用開始 ※ 全指示とレスポンスはログに保存しておく  OpenAI の Playground を使用すれば Assiatants に任意の回答をさせた体でプロンプトを実行できます。  

Slide 82

Slide 82 text

運用開始 ※ 全指示とレスポンスはログに保存しておく  これをひたすら繰り返すことで精度改善をしましょう。  

Slide 83

Slide 83 text

継続的改善 

Slide 84

Slide 84 text

他に有用なテクニック  ● プロンプトエンジニアリング : ( https://www.promptingguide.ai/ )  ● ロール設定 : 「あなたはxxxの専門家です」 (https://platform.openai.com/docs/guides/text-generation/chat-completions-api )  ● EmotionPrompt : 「限界を超えましょう!」 ( https://arxiv.org/abs/2307.11760 )  ● Assistants API : 知識の埋め込み  ● ベクターDB : より柔軟な知識の埋め込み   ● Fine Tuning : モデルのカスタマイズ   GPTが知らない知識も使える   → 最新の技術はGPTが知らないから採用しない、のようなことは気にする必要はない。  

Slide 85

Slide 85 text

テストに関して  一般的にLLMの回答は毎回異なります。よってテストが難しいです。   LLMを使用した機能のテストに関してはまだ世界的にも手法が確立されていません。   それでも自分の経験から共有できることを共有しようと思います。     GPT モデルでは、パラメーターを設定することができるのですが、その中に「temperature」と呼ばれるパラメーターがあります。    これを設定すると、「最も確率の高い次のトークン」をひたすら返答し続けるので、プロンプト実行ごとの回答のブレが (ある程度) 少なくなります。     よって、この性質を利用することで、「めちゃくちゃ精度が落ちた」のようなことに気づける状態を構築することができます。 

Slide 86

Slide 86 text

テストに関して  弊社ではこれをCIに組み込むことで品質劣化がないかを確認しています。  

Slide 87

Slide 87 text

まとめ 

Slide 88

Slide 88 text

まとめ  ● (統一感は大事) AIの支援を最大化するために統一感がより重要になります   ● (AIは新人) AIは何も知らない新人です。プロセスとデータを解釈の余地なく教える必要があります  ● (作らない) AIの進化が激しいので不用意に独自のツールを作っても無駄になる可能性があります   ● (継続的改善) プロセスとデータを解釈の余地なく教えるのは至難の技です。例えば誰かが「明日の朝までに」と言った時にAさんは「日本時間の朝までに」と捉えるかもしれませんし、Bさんは「サンフランシスコの朝までに」と捉えるかもしれません。   よって、「継続的改善」が必須です。 

Slide 89

Slide 89 text

終わり良ければ全て  ヨシッ  ありがとうございました 